Ansible Galaxy: берём роли с полки вместо написания с нуля

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

Писали про Ansible 2.0 preview ещё в июле - тогда же упомянули, что Galaxy смотрим с осторожностью. С тех пор кое-что изменилось. Реестр вырос, появились роли с нормальной документацией и тестами, авторы вроде geerlingguy выпустили целые наборы под типовые задачи. Критическая масса, похоже, набралась.

Как это выглядело раньше

Настройка нового типового сервера - web под LAMP или аналог - занимала у нас от трёх до четырёх часов инженерного времени. Это плейбуки писанные руками под конкретного клиента, потом адаптация под его окружение, потом пробный прогон, потом доводка. Каждый раз заново: системные пользователи, SSH-харденинг, NTP, firewall, базовый мониторинг, потом уже сам стек.

Большую часть уходило именно на общую часть - то что одинаково от проекта к проекту. Специфика проекта - настройки приложения, его переменные, нюансы окружения - это меньшая часть работы, но именно она требует думать. А думать приходилось после четырёх часов рутины.

Что изменили

Начали брать роли из Galaxy как отправную точку. Не копируем вслепую - изучаем, проверяем что делает, адаптируем под нашу структуру group_vars и инвентарь.

Схема выглядит так: есть requirements.yml в репозитории, там перечислены роли с версиями. ansible-galaxy install -r requirements.yml скачивает их в vendor-директорию. Свои роли живут рядом - в roles/, Galaxy-роли в vendor/roles/. В плейбуке можно ссылаться на оба места.

# requirements.yml
- src: geerlingguy.security
  version: 1.0.0
- src: geerlingguy.ntp
  version: 1.0.4
- src: geerlingguy.firewall
  version: 1.0.6

Версию фиксируем - это важно. Без фиксации galaxy install может поставить новую версию которая поменяла поведение, и это выяснится в самый неподходящий момент.

Общая часть - системный харденинг, NTP, базовый firewall - теперь закрывается Galaxy-ролями с минимальной конфигурацией через переменные. Специфичное под проект - своя роль, написанная руками.

Результат

Типовой сервер сейчас встаёт примерно за 30 минут инженерного времени. Основное время уходит именно на проектную специфику: что именно должно быть открыто, какие пользователи, какие параметры приложения. Общая часть раскатывается почти без участия.

Это не значит что взяли с полки и забыли. Несколько вещей всё равно приходится делать:

• Читать что роль делает - некоторые роли на Galaxy агрессивно меняют системные настройки по умолчанию, и это надо знать заранее.
• Тестировать на стенде - особенно при обновлении версии роли. Разработчики иногда меняют имена переменных без предупреждения.
• Держать форк если роль не поддерживает нужную версию ОС или делает что-то что нам не подходит. Forking некрасиво, но лучше чем патчить чужой код через хаки в плейбуке.

Последнее случилось с одной ролью под nginx - автор решил что знает лучше как управлять конфигами и убрал возможность передавать произвольные директивы через переменные. Форкнули, поставили свою версию.

Про доверие к чужому коду

Это отдельный разговор. Роль из Galaxy - это чужой код который бежит под root на вашем сервере. Мы смотрим что внутри перед тем как добавить в requirements.yml. Правило простое: если не понимаешь что роль делает - не используешь.

Авторы у которых несколько популярных ролей и заметная история коммитов вызывают больше доверия чем анонимная роль с тремя звёздами и коммитом год назад. Это не гарантия, но ориентир.

Всё это живёт в GitLab - requirements.yml зафиксирован, изменения версий идут через MR с ревью. Обновить Galaxy-роль - это изменение в инфраструктуре, а не «быстро поправил».

Что не взяли из Galaxy

Роли под приложения - базы данных, веб-серверы с нетривиальной конфигурацией - пока пишем сами. Galaxy-роль под PostgreSQL или nginx написана для общего случая, а у нас обычно есть специфика которая требует контроля над деталями. Проще написать 80 строк под себя чем переопределять половину дефолтных переменных в чужой роли на 400.

Системная часть из Galaxy работает хорошо именно потому что она действительно типовая. SSH должен быть одинаково захардён везде - здесь чужая роль с нормальными дефолтами и тестами только в помощь.

На сопровождении сейчас около пятидесяти хостов. С Galaxy-ролями для системной части и своими для специфики - управляемо. Посмотрим как это ощущение изменится когда хостов станет больше.