Рассказываем как мы Bash на Ansible променяли
Год назад в Gems был запущен процесс перехода с одного метода развертывания продуктов компании на другой. DevOps-инженер Адиль Чобан в статье расскажет как проходил переход с Bash (The Bourne-Again Shell) на Ansible, и как живется командам в новой реальности.
– Почему были необходимы перемены?
– Прежний подход к развертыванию перестал удовлетворять потребности компании и не соответствовал требованиям времени. Нам нужно было решение, которое позволило бы облегчить процессы развертывания (то есть установки и обновления) системы Geometa и её компонентов.
– Что было не так с Bash?
– Главная проблема была в том, что в основе его работы скрипты, а скрипты — это не всегда хорошо.
– Почему?
– По нескольким причинам:
а) мы зависим от одного конкретного человека — автора скрипта, а значит, здесь сразу бонусом идут все минусы присутствия человеческого фактора: забывчивость, невнимательность, усталость, болезнь и другое;
б) под каждый новый компонент или модуль нашего продукта нужно писать новый скрипт, а это занимает время;
в) тяжело отслеживать процесс, то есть до завершения установки и проверки первичного функционала не всегда понятно, адекватно ли установилась система;
г) невозможно автоматизировать и масштабировать процесс развертывания, так как разработчик скрипта становится узким горлышком, то есть с увеличением числа команд и продуктов время на одно развертывание остается неизменным, а в массе растет.
– Почему перешли именно на Ansible?
– На старте мы выбирали между push- и pull-системами. Первые работают благодаря конфигурации и установке специального агента, который и будет делать запросы к мастер-сервису, то есть его работа основана на неком программируемом посреднике. Вторые же работают с мастер-сервисом напрямую, а значит, позволяют облегчить работу с серверами. Собственно, выбор push системы был для нас очевиден, оставалось определиться с конкретным ПО.
Наша команда проголосовала за Ansible.
– Почему?
– Во-первых, это бесплатное open source решение с огромной базой знаний и не меньшим комьюнити.
Во-вторых, для его работы не нужно устанавливать дополнительный софт на стендах заказчиков и основном стенде Geometa. Для применения конфигураций на серверах достаточно соблюдения двух условий: наличия доступа от SSH (включен и открыт соответствующий порт) и админская учётка (должны быть известны логин и пароль/SSH-ключ от учетной записи с правами sudo).
В-третьих, первый запуск возможен даже в стандартной конфигурации.
В-четвертых, новый человек легко разберется с тем, что уже реализовано, без посторонней помощи.
В-пятых, есть возможности для интеграций с другими системами, например, Jenkins.
В-шестых, система легко поддерживается, масштабируется и автоматизируется.
– Как работает Ansible?
– Для пользователя всё очень просто: запускаете приложение, конфигурируются переменные, запускаете команду и ждёте результат.
– Так просто?
– Почти, но давайте разберём по этапам процесс развертывания.
На первом этапе вам необходимо сформировать сборку под проект, поскольку конфигурация модулей и приложений индивидуальна для каждого проекта, тут нашим коллегам в Gems помогает специальная утилита, которую мы разработали для автоматизации процесса формирования сборки сервисов и модулей под проект.
У такого решения есть побочка — Ansible не увидит структуры, созданные вручную. Таким образом, первый шаг сводится к запуску этой утилиты.
На втором этапе вам предстоит подготовить inventory-файл под проект. Он должен содержать IP-адреса, логины и пароли для подключения к стендам. Разумеется, данные для подключения к стендам необходимо зашифровать, для этого используется встроенный в Ansible функционал — ansible-vault, но сегодня не о нём.
На третьем этапе определяется конфигурация переменных под проект, здесь наши коллеги фиксируют то, что раньше писали в командной строке при запуске скрипта.
На четвертом шаге вы должны сгенерировать docker-команду. Для облегчения этого шага команда DevOps собрала специальный docker-образ, который позволяет запустить Ansible даже с недоступной ОС Windows.
Ну, и финальный этап — запуск установки или обновления с помощью Ansible.
– А есть ли какие-то ограничения по работе с Ansible?
– Функционирование системы зависит от операционных систем и количества стендов. Нам уже удалось реализовать решения для поддержки CentOS и Astra Linux.
Для примера возьмем CentOS.
Если мы работаем с локальным единичным стендом, то мы можем установить весь перечень модулей Geometa и необходимый софт. Под единичным стендом мы имеем в виду сервер, на котором расположено приложение, база данных и геосервер.
Если мы работаем с несколькими стендами, то здесь мы уже можем развернуть наши инфраструктурные составляющие на разных серверах. Классно, что процесс может быть запущен синхронно, а значит, и результат мы увидим быстрее, то есть кратно количеству проектов.
– Ты говорил про возможности интеграции, ею воспользовались?
– Разумеется, нам удалось «поженить» Ansible и Jenkins, это позволило автоматизировать процесс развертывания обновления стендов и использовать ресурсы коллег максимально эффективно.
Например, раньше, чтобы обновить стенд, нужно было пройти девять кругов ада, станцевать с бубном и надеяться, что ничего не рухнет. Ну, может быть, не совсем так, но долго, нудно, сложно контролируемо и почти неуправляемо.
Например, тестировщикам для обновления своего командного стенда предстояло:
- Скачать артефакты с GitLab.
- Сформировать типовую сборку под проект, чтобы проверить функционал, реализованный разработчиками.
- Скопировать файлы на тестовый стенд.
- Запустить скрипт.
- Стартануть автотесты и проверить, что при запуске скрипта не было ошибок, то есть убедиться, что система развернулась корректно.
Ребятам нужно было следить за процессом, а это делать приходилось вручную, рискуя ошибиться или пропустить что-то. Процесс был очень трудоемким.
Благодаря же нашей интеграции время по этой задаче и реальные человеческие усилия сведены к минимуму:
- Подождать пока в репозитории сформируются необходимые артефакты Geometa.
- Запомнить номер релиза (pipeline).
- Открыть веб-интерфейс Jenkins’а, выбрать собранный ранее релиз, указать пароль, который используется для шифрования учетных данных от сервера и запустить процесс обновления
- Всё – задача выполняется в фоновом режиме.
Ниже можно увидеть скриншоты информационной панели Jenkins’а, на которых отображена информация о конфигурируемых в п.3 параметрах и последних запусках обновления стенда команды тестирования.
– Сколько времени занял переход с Bash на Ansible?
– Наверное, месяцев семь или восемь. Работать над задачей мы начали с коллегой в октябре 2021-го года. Полностью рабочий функционал мы презентовали только в апреле прошлого года.
За это время мы провели масштабную аналитическую работу: изучили работу скриптов, используемых на Bash; проработали структуру единого функционала, который позволил связать стенды на различных операционных системах; сформировали список необходимых для развертывания переменных и многое другое.
– С какими сложностями вы столкнулись и как их преодолели?
– Не всё шло гладко.
Начиная с того, что нам предстояло разработать уникальное решение, которое применимо только для наших продуктов. Причина заключается в том, что Ansible по сути представляет собой программное решение, которое превращает набор сценариев, описанных в YAML формате, в набор команд, которые передаются удалённому серверу по SSH. Определенный сценарий направлен на решение конкретной задачи, таким образом, невозможно использовать наш набор сценариев, например, для развертывания продуктов иной компании.
Ну, и наконец, при первом внедрении нам было несладко — тяжело объяснить ребятам новые принципы работы, которые на тот момент и мы сами не совсем до конца понимали.
А вообще нам повезло, ведь многие ждали реализацию этого функционала.
Мы благодарны команде «Тюююленька» (ранее «Тюменька») за готовность пойти навстречу, ведь именно они первыми полноценно затестили новые возможности. Отдельное спасибо хочется сказать Юрию Коровину, инженеру-аналитику команды, за его помощь в продвижении нового метода развертывания ПО и предоставленной обратной связи.
– Каких результатов удалось достичь?
– Пилотный запуск дал нам силы для нового этапа, и для специалистов команд внедрения мы запустили обучение по организации процесса обновления продуктов компании с помощью Ansible.
Изначально идея была масштабнее, мы хотели провести ликбез и для тестировщиков команд разработки, но она не увенчалась успехом. Именно эта промашка стала причиной старта работ по интеграции с Jenkins’ом, которая так полюбилась нашим коллегам и сделала их жизнь проще и приятнее. В итоге ребята довольны, даже новички быстро осваивают процесс обновления своих тестовых стендов.
Почти год спустя мы видим результаты, которые радуют. Команды разработки пользуются связкой инструментов Ansible и Jenkins для обновления своих тестовых стендов, но далеко не для всех проектов есть такая возможность. Команды же внедрения используют функционал лишь частично.
– Планируются ли ещё какие-то доработки?
– Да, планы есть, и не маленькие. Во-первых, оптимизация скорости работы заложенного функционала: некоторые вещи не доведены до идеала, и это нужно исправить.
Во-вторых, нужно закончить интеграцию с Jenkins для тех проектов, которые по-прежнему развертывают/обновляют систему лишь с помощью Ansible.
В-третьих, завершить работу над системой уведомлений с использованием push-уведомлений в Telegram-канал, чтобы сделать более удобным отслеживание и контроль статусов запущенных обновлений.
Хотите узнать больше технических деталей реализации? Ставьте «лайк» и пишите свои вопросы в комментариях.