Ansible без агентов: плейбук nginx на 10 серверах за 2 минуты

Puppet существует с 2005 года, Chef появился в 2009-м. Мы поглядывали на обоих, читали доки, несколько раз пытались взлететь - и каждый раз застревали примерно на одном и том же: агенты. Агент надо поставить, его надо обновить, он иногда падает, иногда конфликтует с SELinux, и поддержка этого зоопарка сама по себе становится задачей. При парке в 5-15 разношёрстных серверов у клиентов это казалось избыточным.

В начале года появился Ansible 0.9 - инструмент управления конфигурациями от Майкла Де Хааана, который принципиально отказался от агентов. Управление через SSH, Python на управляемом хосте - и всё. Мы решили наконец его попробовать на реальной задаче.

Задача: nginx на 10 серверах клиента

У одного из клиентов, которых мы ведём в рамках управляемой поддержки, несколько Linux-серверов на CentOS 6.x. Задача периодически одна и та же: развернуть nginx, прописать конфиг под реверс-прокси, включить сервис. Машин сейчас десять, и каждый раз делать это руками через ssh в цикле - скучно и чревато расхождениями между серверами.

Попробовали закрыть это Ansible.

Как это выглядит

Структура получилась минималистичная. Файл инвентаря hosts с десятью IP-адресами, сгруппированными в секцию [web]. Плейбук - один YAML-файл:

- hosts: web
  sudo: yes
  tasks:
    - name: установить nginx из epel
      yum: name=nginx state=present

    - name: скопировать конфигурацию
      copy: src=files/nginx.conf dest=/etc/nginx/nginx.conf
      notify: перезапустить nginx

    - name: включить автозапуск
      service: name=nginx enabled=yes state=started

  handlers:
    - name: перезапустить nginx
      service: name=nginx state=restarted

Всё. Запускаешь ansible-playbook -i hosts site.yml - и Ansible по очереди заходит на каждый хост по SSH, проверяет состояние (идемпотентность - это не просто слово в доке, оно реально работает), ставит пакет если его нет, кладёт конфиг, включает сервис. Если конфиг не изменился - handler на перезапуск не срабатывает.

На десяти серверах прогон занял около двух минут - с параллельным выполнением через параметр forks.

Что понравилось

YAML читается. Puppet-манифест и рецепт Chef человек без контекста должен расшифровывать. Ansible-плейбук можно показать сисадмину, который никогда про него не слышал, и он поймёт, что происходит. Это не мелочь: когда через полгода к файлу возвращаешься или передаёшь задачу - это экономит час объяснений.

Никакой инфраструктуры под сам инструмент. Puppet Master, Chef Server, Certificate Authority - всего этого нет. Ansible работает с управляющей машины, где он установлен, и больше ничего не нужно. Для клиентского парка в 10-20 серверов это честное упрощение.

Идемпотентность без плясок. В Puppet это концепция, которую нужно аккуратно соблюдать при написании ресурсов. В Ansible модули yum, service, copy - идемпотентны по умолчанию. Повторный запуск плейбука на уже настроенном сервере просто ничего не изменит.

Что вызвало вопросы

Скорость на большом парке. Десять серверов - это быстро. Сотня - уже другой разговор. SSH-соединение на каждый таск плюс Python overhead дают ощутимую латентность при росте парка. Для нашего кейса это некритично, но надо держать в уме.

SSH-доступ как единственная точка входа. С одной стороны - просто. С другой - нужно аккуратно управлять SSH-ключами и правами sudo на целевых машинах. Если ключ утёк или sudo настроен слишком широко, радиус поражения большой. Это не проблема Ansible как такового, но agentless-подход переносит ответственность за безопасность транспорта на вас.

Отсутствие pull-режима. Puppet и Chef работают в push/pull-режимах: агент сам ходит к серверу и применяет конфиг. Ansible - только push, с управляющей машины. Для нашего сценария это нормально, но если нужно «сервер сам себя настроил при старте» - придётся думать отдельно.

Где мы сейчас

Плейбук ушёл в работу. Nginx на десяти машинах развернулся чисто, конфиги одинаковые, сервисы запущены. Теперь пишем аналогичные вещи для других типовых задач: настройка syslog-агентов, раскатка мониторинговых клиентов, управление пользователями.

Puppet мы в ближайшее время серьёзно смотреть не перестанем - для сложных иерархий с наследованием классов он, судя по всему, мощнее. Но для практических задач на скромном парке серверов Ansible оказался тем инструментом, который не требует недели на раскрутку.

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