Ansible без агентов: playbook на 50 строк разворачивает сервер с нуля

Puppet у нас уже работает - писали про это в феврале. Манифесты живут в git, cron тянет и применяет. Всё хорошо, но когда коллега попросил помочь с новым клиентом на сопровождении - парк из пятнадцати серверов, ничего ещё не настроено - встал вопрос: разворачивать привычную Puppet-инфраструктуру или попробовать Ansible, о котором в последнее время всё больше разговоров.

Попробовали Ansible. Результат оказался неожиданно убедительным.

Главное отличие - никакого агента

С Puppet на каждой управляемой машине должен стоять puppet agent. Нужно его установить, настроить, он должен знать про puppet master, там надо подписать сертификат. Если puppet master - это puppet apply без сервера, то надо раскидать манифесты или придумать схему с git pull. Не сложно, но это дополнительный слой.

Ansible работает только через SSH. На управляемых машинах ничего нет, кроме Python и SSH-сервера - а это есть на любом Linux из коробки. Управляющий узел - твой ноутбук или отдельная машина - подключается по SSH и делает всё там. Никаких агентов, никаких сертификатов, никакого puppet master.

Это не просто удобство. На практике это означает: поднял новый сервер, прописал в инвентарь, проверил SSH-доступ - и сразу можно применять playbook. Без предварительной подготовки машины.

Playbook на развёртывание с нуля

Первый рабочий playbook получился примерно в 50 строк YAML. Структура простая:

• установить базовые пакеты (ntp, rsyslog, curl, htop, vim)
• настроить sysctl - net.ipv4.tcp_syncookies, лимиты файловых дескрипторов
• разложить конфиг rsyslog с нужным syslog-сервером
• добавить служебного пользователя с SSH-ключом
• включить ufw, разрешить SSH и нужные порты
• отключить root-логин по SSH

YAML после Puppet DSL читается легче. Синтаксис Puppet - это свой язык со своими правилами, к которому привыкаешь несколько дней. Ansible-плейбук выглядит как структурированный список задач, и новый человек в команде разберётся в нём без обучения.

Запуск:

ansible-playbook -i hosts site.yml

hosts - это инвентарный файл, просто список IP-адресов или имён по группам. site.yml - playbook. Всё.

На чистую машину ушло меньше часа: написали playbook, прогнали на тестовой ВМ, поправили пару мелочей, применили на остальных. Новый сервер с этого момента разворачивается минут за десять.

Где Puppet сильнее

Честности ради: Puppet не просто так существует, и отказываться от него в тех проектах где он уже есть - незачем.

Отчёты и инвентаризация. Puppet master знает состояние каждого агента: когда последний раз применял каталог, были ли ошибки, какие ресурсы изменились. Ansible запустился, отработал, ты видишь вывод - и всё. Если нужно понять состояние парка через неделю - в Puppet это один запрос, в Ansible надо снова прогнать playbook или использовать что-то отдельное.

Постоянная конвергентность. Puppet agent ходит к master каждые 30 минут и сам исправляет drift - расхождение фактического состояния с желаемым. Ansible применяет конфигурацию когда ты запускаешь - не чаще. Если кто-то вручную изменил конфиг на сервере, Ansible об этом не узнает пока ты снова не прогонишь playbook.

Сложные зависимости между ресурсами. Граф зависимостей в Puppet - это полноценная возможность языка. В Ansible порядок выполнения - это просто порядок задач в файле. Для небольших playbook'ов это проще, но в сложных сценариях может стать ограничением.

Для каких случаев что выбирать

На текущий момент у нас складывается такой подход: Ansible хорошо работает там, где парк небольшой (до нескольких десятков серверов), нужно быстро начать без поднятия инфраструктуры, и важна читаемость конфигурации для людей которые не занимаются этим каждый день.

Puppet имеет смысл там, где инфраструктура уже есть и работает, нужна постоянная конвергентность без ручного запуска, или важны детальные отчёты об изменениях.

Это не конкуренция за место - это разные точки входа с разными компромиссами. Мы, скорее всего, будем держать оба инструмента в зависимости от клиента и задачи.

Что оказалось неожиданным

Idempotency в Ansible не гарантирована по умолчанию - в отличие от Puppet, где она встроена в модель. Большинство стандартных модулей (apt, service, copy, template) идемпотентны - но если использовать shell или command для произвольных команд, то за идемпотентность отвечает автор playbook. Флаг creates помогает, но это уже ручная работа.

Ещё одна вещь: переменные и шаблоны в Ansible через Jinja2 - это мощно, но Jinja2 внутри YAML иногда даёт неожиданные результаты с кавычками и спецсимволами. Пара часов ушла на то, чтобы понять почему шаблон не рендерится так как ожидалось. Решение простое (кавычки вокруг значения с {{ }}), но неочевидное с первого раза.

В целом - инструмент рабочий, порог входа низкий, для задач быстрого развёртывания и разовых изменений по всему парку работает хорошо. Посмотрим как будет с более сложными сценариями.