Алексей Кузнецов работает системным архитектором в департаменте DMP X5 Group три года. Всё это время в DMP X5 Group применяют Ansible, чтобы обеспечить непрерывную конфигурацию на серверах и автоматизировать ручную работу.

В поддержку своего курса «Ansible: Infrastructure as Code» Слёрм собирает интересные кейсы использования Ansible в российских компаниях. Мы поговорили с Алексеем и узнали, почему в его департаменте выбрали именно Ansible, с какими проблемами столкнулись в проекте и как их решили. Ещё немного затронули тему санкций. Передаём слово Алексею.

Почему выбрали Ansible

Когда я пришёл в X5 Group, наш департамент поддерживал только одно решение — это платформа Big Data — и около 80 серверов. Системы управления конфигурациями не было. Точнее, у Big Data есть собственное решение управления конфигурациями — ambari. Но оно не решает множество задач. Например, подготовку сервера к добавлению в кластер приходилось делать вручную, и это занимало много времени.

Чтобы автоматизировать процесс, мы решили внедрить систему управления конфигурациями. До прихода в X5 Group я пользовался Puppet, и сначала мы собирались работать с ним, но столкнулись с организационными проблемами и стали искать альтернативу.

Причины, почему выбрали Ansible:

1. Нет клиента на стороне сервера. Нам понравилось, что можно управлять инфраструктурой, не ставя на ноды дополнительные сервисы.

2. Низкий порог входа. У Ansible очень низкий порог входа — когда мы решили использовать инструмент, нам хватило восьми часов, чтобы построить проект и настроить автоматический деплой, хотя никто из нас раньше не работал с Ansible.

3. Прост в эксплуатации. К примеру, манифест в Puppet пишется гораздо дольше, чем плейбук в Ansible.

Сначала у нас была одна роль, которая автоматически добавляла серверы в кластер. Потом проект стал расширяться и усложняться:

• Появилось много других сервисов: Kafka, утилиты для неё, Nifi.

• Увеличилось количество серверов, в том числе и пользовательских, на которых работают дата-сайентисты.

• Выросло число ролей — сейчас их больше 100.

• Появились теги для параллельной отработки ролей.

Также мы отказались от GitLab CI и ушли в AWX. В AWX есть слайсы — это такая удобная штука, которая позволяет создавать отдельные срезы запуска для группы хостов. В нашем Big Data множество одинаковых datanodes — ими пользуются дата-сайентисты для вычислений. Мы поделили datanodes на слайсы и для каждого слайса прописали тег, что ускорило проигрывание Ansible-плейбука.

Как работает наш Ansible

Сейчас наш Ansible работает через AWX. Там есть большая job — Workflow Template. Workflow Template состоит из темплейтов поменьше, через которые прописаны зависимости — условия запуска темплейтов. Один темплейт — это блок из слайса хостов, ролей, которые будут проигрываться на этом слайсе, и тега. Всего в нашем Workflow Template около 30 мини-темплейтов.

Workflow Template запускается при каждом коммите. Он проверяет, были ли изменения в проекте, соответствуют ли они Git и если да, применяет ко всему проекту. Если придёт несколько коммитов одновременно, Workflow поставит их в очередь и выполнит последовательно.

Раз в три часа Ansible запускается сам, по шедулеру, чтобы вне зависимости от коммитов всегда поддерживать инфраструктуру в актуальном состоянии, как в Git. С проектом работает множество людей, поэтому важно, чтобы все изменения вносились только через Git и Ansible. Это позволяет хранить подробную историю изменений и исключает человеческий фактор, когда на сервере что-то поменяли руками, а через полгода всё поломалось и никто не понимает почему.

Если Ansible обнаруживает изменения, которых нет в Git, он откатывает проект до версии в Git. Но иногда, например, при тестировании, дебаге, диагностике всё-таки требуется вносить изменения руками. В этом случае в AWX нужный хост переводится в режим disable и «выключается» для Ansible.

Проблемы конфигурации

Наша конфигурация работает хорошо, но долго. Мы сталкиваемся с двумя основными проблемами.

Проблема №1 — долгая обработка очереди из коммитов.

Если приходит несколько коммитов одновременно, они выстраиваются в очередь. Тому, чей коммит стал последним, приходится долго ждать, чтобы его изменение применилось.

Например, я хочу для всех наших Data Note добавить или поменять параметры ядра. Я коммичу изменения, и в этот же момент ещё двое коллег что-то коммитят. Наши коммиты встают в очередь, и может оказаться, что мне придётся ждать 40 минут, чтобы моё изменение применилось. Это пустая трата рабочего времени. Плюс бывают срочные изменения, которые нужно внести быстро, а не спустя час.

Параллелить коммиты не всегда возможно. Например, нельзя параллельно запустить разные теги установки пакета на разных хостах — это может сломать плейбуки. Последовательность выполнения важна, поэтому сейчас мы запускаем все коммиты только последовательно.

Проблема №2 связана с тем, как работает сам Ansible.

Мы создаём группы хостов и на каждую группу запускаем свой плейбук. Если в какой-то группе один хост сразу не отдаёт connection refused, а начинает отбиваться по таймауту, «зависает» вся группа и отыгрывания роли приходится долго ждать.

В нашем же случае роль может вообще не прогнаться: на каждый темплейт в AWX стоит ограничение в 25 минут. Мы так сделали, чтобы другим специалистам из-за недоступности одного хоста не пришлось слишком долго ждать обработки своего коммита.

Важно подчеркнуть, что проблемы со скоростью работы Ansible возникнут не у каждого проекта. Если использовать Ansible «привычно», например, для первоначальной настройки и ручной поддержки сервисов, проблемы со скоростью вряд ли появятся. Более того, для решения таких задач Ansible выигрывает у любого другого инструмента за счёт объёмной документации и множества модулей и плагинов.

У нас проблемы со скоростью проигрывания плейбука появились не потому, что проект разросся. Дело в подходе. Через Ansible мы настраиваем абсолютно всё: хосты, конфиги, сервисы — и хотим, чтобы конфигурация на серверах была непрерывной. По сути, мы хотим, чтобы наш Ansible работал как Puppet.

Как ускорить работу Ansible

Ускорить работу нашего Ansible стандартными средствами сложно. Можно было бы наращивать саму инфраструктуру, делать больше слайсов. Но тесты показали, что от увеличения слайсов мало профита — весь Workflow Template проигрывается всего на несколько минут быстрее.

Вариант перейти на Puppet мы даже не рассматривали. Переход на другой инструмент — это огромный объём работы. Пришлось бы:

• Переписать и протестировать все роли, а в проекте их больше 100.

• Пересмотреть всю структуру проекта.

• Переучиться писать роли, добавлять параметры и т. д. При этом я уже говорил — Puppet сложнее, чем Ansible.

Для ускорения Ansible мы собрали подобие агента с режимом работы local. Он позволяет более мобильно и быстро управлять инфраструктурой.

Как работает агент

Оговорюсь, что эта функциональность — не прямо агент. Мы не изобретали велосипед. Мы взяли API Ansible, у которой по умолчанию есть тип коннекшена local, и на её основе стали запускать Ansible. Дальше собрали бинарный файл, внутрь которого добавили модуль Ansible и отдельно пакетом задеплоили Ansible Collection. Этот файл положили на тестовые серверы.

Агент работает так. Он скачивает репозиторий Git и запускается локально на каждом сервере. У него есть запуск при обновлении — агент включается раз в 30 секунд при изменении в проекте, смотрит, был ли коммит и, если да, запускает плейбук Ansible, который локально проходит по своим ролям.

Также раз в 25 минут агент запускает Ansible вне зависимости от того, был ли коммит, чтобы поддерживать инфраструктуру в том же состоянии, что в Git.

Пока мы только тестируем агента на 10 серверах, но результаты нам уже нравятся. Агент действительно ускоряет Ansible — после коммита вся инфраструктура обновляется за 3,5 минуты. 

Единственный минус агента — безопасность. Наш проект пока лежит локально. Мы используем шифрование, пароли и т. д. Но если злоумышленник очень постарается и получит доступ к одному серверу, то через файл агента сможет добраться до всего проекта. Придётся заморочиться, но такое возможно. Мы пока не знаем, как решить этот вопрос. Идеи есть, но они ещё не протестированы.

Логичный вопрос: если бы мы знали, что нам понадобится решение для ускорения Ansible, выбрали бы мы три года назад этот инструмент? Да, потому что плюсы перевешивают минусы.

1. Ansible прост, понятен и логичен. Он написан на популярном языке программирования Python, в котором легко разобраться. Например, в Jinja2, который использует Ansible, циклы пишутся, как в учебниках по программированию для новичков. Puppet написан на Ruby. Для меня Ruby сложнее. Я спрашивал коллег — они со мной согласны.

2. У Ansible много готовых модулей и плагинов. Кажется, что есть решения подо всё. Если какого-то решения нет, можно написать и использовать своё. Это просто. Чтобы использовать собственный плагин, не нужно пересобирать проект заново. Достаточно в модуле проекта создать папку и положить туда новый плагин.

Санкции, Ansible и инфраструктура

На мой взгляд, санкции Ansible не грозят. Если скачать сервис и сохранить локально на компьютере, доступ останется навсегда.

Другой вопрос с обновлениями. Но здесь тоже не вижу проблемы. Допустим, доступ к Ansible заблокируют по российским IP. В чём проблема купить сервер, условно, в Индии и скачивать обновления через него?

Если говорить о нашей инфраструктуре в целом, то санкции нас не коснулись. Мы используем только Open Source. Правда, с некоторыми вещами мы подстраховались. Например, выкачали часть самых критичных для сборки репозиториев для Hadoop. В остальном поможет сервер в условной Индии ????.