От 8 часов до 15 минут: автоматизация 40 серверов через Ansible

Семёнов Евгений Сергеевич, директор АйТи Фреш. Расскажу про реальный проект 2025 года: веб-студия из 18 человек, 40+ серверов клиентских проектов, штатный сисадмин, который тратил полные рабочие дни на накатывание обновлений. После полутора недель внедрения Ansible вместо 8 часов получили 15 минут — и не потеряли ни одного сервиса. Делюсь, как это было устроено и где мы поначалу набили шишек.

С чем мы пришли

Веб-студия в районе Электрозаводской: разработка и сопровождение сайтов на Битрикс, Tilda, кастомных WordPress-сборок. У них в обслуживании было 42 сервера у 14 клиентов — Debian 11/12, CentOS Stream, у двух клиентов — Ubuntu 22.04. На каждом примерно одинаковый набор: Nginx, PHP-FPM 8.1/8.2, MariaDB, Redis, fail2ban, ssh-ключи команды, бэкап rsync на NAS клиента.

Сисадмин у них был один — толковый парень, но затопленный рутиной. Каждое второе утро начиналось с обхода 10–12 серверов: накатывание обновлений безопасности через apt, проверка свободного места, перезапуск зависших php-fpm пулов, добавление сотрудников в access-листы. Полный обход всех серверов занимал около 8 часов и делался раз в две недели — в результате обновления накапливались, мелкие ошибки тоже накапливались, и в итоге каждый второй понедельник он фигачил с 9:00 до 19:00 без обеда.

Почему именно Ansible

Когда меня позвали на консультацию, я предложил три варианта: Ansible, SaltStack или Puppet. Объяснил разницу:

• Ansible — без агента, нужен только SSH, синтаксис YAML, низкий порог входа, идеально для команд из 1–3 инженеров.
• SaltStack — мощнее в больших инсталляциях, работает быстрее на 1000+ узлах, но требует minion-агента и сложнее в освоении.
• Puppet — Ruby DSL, агентная модель, исторически в крупных банках и телекомах. Для веб-студии — overkill.

Решили на Ansible — он закрывает 95% задач малого и среднего бизнеса в Москве и не требует от инженера переучиваться с админа на разработчика. За пятнадцать лет работы с инфраструктурами я могу сказать: на масштабе до 200 серверов лучше Ansible нет ничего. После — стоит смотреть в сторону GitOps и Argo CD, но это уже другая история.

Архитектура решения

Мы развернули следующую схему. Управляющий узел — небольшой Debian 12 на 2 vCPU/2 GB RAM в их собственной серверной (нет смысла платить за виртуалку, Ansible сам по себе ничего не нагружает). На нём:

• Сам Ansible 9.x из официального PPA.
• Git-репозиторий со всеми плейбуками и ролями (на их Gitea, локально).
• Структура каталогов по best practice: inventories/, group_vars/, host_vars/, roles/, playbooks/.
• Ansible Vault для секретов — пароли БД, ключи API, SMTP-учётки.
• Sshd на управляющем узле слушает только из VPN, доступ только по ключам, root отключён.

На каждом из 42 управляемых серверов — отдельный сервисный пользователь ansible с sudo-правами без пароля. Доступ ему настроен только с управляющего узла по ключу. Это безопаснее, чем ходить под root, и проще, чем держать персональные ключи на каждом сервере.

Inventory: как структурировать 42 сервера

Главный совет, который я даю всем, кто внедряет Ansible впервые: вложите время в продуманный inventory с самого начала. Перепиливать его потом — больно. Мы пошли по двухуровневой схеме:

inventories/
  production/
    hosts.yml              # сами хосты с IP
    group_vars/
      all.yml              # глобальные переменные
      webservers.yml       # для всех веб-серверов
      dbservers.yml        # для всех БД
      client_acme.yml      # для всех серверов клиента ACME
    host_vars/
      web01.acme.local.yml # уникальные настройки конкретного хоста

В hosts.yml серверы группировались по двум измерениям одновременно: по роли (webservers, dbservers, cache, monitoring) и по клиенту (client_acme, client_beta, client_gamma). Это позволило одной командой обновить все веб-серверы либо все серверы конкретного клиента, не путаясь.

Роли: переиспользуемая основа

Мы написали восемь базовых ролей, которые покрывали 90% потребностей:

• common — обновления, базовые пакеты (htop, vim, mc, curl), tzdata, locale, NTP.
• users — учётки команды веб-студии с их ssh-ключами, sudo-настройки.
• ssh-hardening — отключение root login, password auth, перенос порта, fail2ban с разумными настройками.
• firewall — UFW с базовыми правилами, отдельные роли наследуют и добавляют свои порты.
• nginx-php — связка Nginx + PHP-FPM с переменными для версии PHP и пулов.
• mariadb — MariaDB с настройками my.cnf под размер сервера, root-пароль из Vault.
• backup-rsync — бэкап-скрипты с расписанием в cron, мониторинг успешности.
• monitoring-agent — установка node_exporter с правилами для Prometheus.

Каждая роль документирована в README.md внутри роли: какие переменные она ожидает, какие меняет файлы, как тестировать. Это стало золотым правилом — чтобы через полгода новый инженер мог разобраться без помощи автора.

Vault: где живут секреты

Все секреты — пароли БД, ключи Yandex Object Storage для бэкапов, токены Telegram-ботов мониторинга — в Ansible Vault. Один мастер-пароль, который знают только два человека (сисадмин клиента и я как куратор). Структура файлов:

group_vars/
  client_acme/
    vars.yml      # обычные переменные, в git как есть
    vault.yml     # зашифрованные секреты

В vars.yml ссылки на секреты вида db_password: "{{ vault_db_password }}", а сами значения — в зашифрованном vault.yml. Это позволяет хранить весь репозиторий в Git, в том числе на собственном Gitea клиента, без риска утечки.

Тестовый прогон: как мы избежали падения 42 сайтов

Главный страх руководителя клиента, когда я предложил автоматизацию — «а если оно сломает все 42 сервера одновременно?» Чтобы этого не случилось, мы выстроили дисциплину прогона:

1. Любой плейбук сначала тестируется в режиме --check --diff — Ansible показывает, что собирается изменить, не делая этого.
2. Реальный прогон сначала на одном тестовом сервере (мы выделили под это пустую виртуалку).
3. Потом на 1–2 серверах одного клиента поспокойнее (внутренний проект студии, не клиентский).
4. Только после успешного прохождения — на production-серверах с использованием --limit по группам и serial: 5 в плейбуке (обновляем по 5 серверов одновременно, чтобы не положить всё сразу).

За полтора месяца внедрения у нас был один инцидент — на двух серверах сломался PHP из-за того, что в роли мы зафиксировали версию 8.1, а у клиента стояла кастомная сборка 8.2 с PECL-модулем. Откат через git revert и повторный прогон занял 8 минут. С тех пор перед обновлением PHP мы всегда смотрим, какие нестандартные модули установлены — и зашиваем это в host_vars.

Что получили в итоге

Через шесть недель после старта внедрения метрики выглядели так:

Финансовый эффект клиент посчитал сам: освободившиеся 60–70 часов в месяц у штатного сисадмина превратились в работу над проектами, которые раньше отдавали на сторону. Зарплату ему увеличили на 20% (заслуженно), но это всё равно вышло дешевле, чем нанимать второго инженера или платить за внешние подрядки.

Грабли, на которые мы наступили

Чтобы вы не повторяли наших ошибок:

• Несовместимые версии Ansible и Python на удалённых хостах. Старые CentOS 7 не дружили с Ansible 9. Решилось установкой Ansible 2.14 LTS на отдельный venv для legacy-серверов.
• Идемпотентность не подразумевается, она проектируется. Первая версия роли nginx-php не была идемпотентной — каждый запуск перезагружал nginx, даже если ничего не менялось. Пришлось переделывать handlers.
• Vault-пароль в текстовом виде. Мы поначалу хранили его в скрипте-обёртке. Потом переделали на vault-id с keyring на управляющем узле.
• Параллельность по умолчанию — 5. Когда обновляли 42 сервера, скорость падала. Подняли forks до 20 в ansible.cfg — стало в 4 раза быстрее.
• Логи плейбуков не сохранялись. Добавили callback_plugin для записи в файл — теперь в любой момент можно поднять, что и когда делалось.

Когда Ansible вам нужен, а когда — нет

За пятнадцать лет работы я видел, как Ansible внедряют там, где он не нужен, и не внедряют там, где он критичен. Мои наблюдения:

Ansible нужен, если:

• У вас 5+ однотипных серверов и операции на них повторяются.
• Команда из 2+ инженеров, и важна согласованность работы.
• Часто разворачиваются новые серверы (DevOps-цикл, новые проекты).
• Нужен audit trail — кто что менял на серверах.
• Аудиторам нужно показать «как именно настраиваются серверы» — Git-репозиторий с ролями отвечает на этот вопрос лучше, чем устные рассказы инженера.

Ansible не нужен, если:

• У вас 2–3 сервера и они не меняются годами.
• Один инженер, и все знания у него в голове.
• Серверы выполняют принципиально разные роли и нет повторяющихся паттернов.

Сколько стоит внедрение под ключ

Когда мы в АйТи Фреш делаем внедрение Ansible для клиента, типовой проект выглядит так:

• Аудит инфраструктуры (1 день) — описываем, что есть, что повторяется, что дублируется. 18 000 руб.
• Развёртывание управляющего узла + базовые роли (2 дня) — common, users, ssh, firewall, monitoring. 36 000 руб.
• Роли под ваши сервисы (3–5 дней) — Nginx/Apache/PHP/Python/Postgres/MySQL и что у вас есть. От 54 000 руб.
• Vault и безопасность (1 день) — настройка хранения секретов, аудит доступов. 18 000 руб.
• Документация и обучение вашего инженера (1 день) — мы не оставляем клиента с «чёрным ящиком». 18 000 руб.

Типовой бюджет — 95 000–180 000 руб. за полное внедрение с обучением вашего штатного сисадмина. Окупается за 2–4 месяца только за счёт экономии времени на рутине.

FAQ — частые вопросы по Ansible

С какого количества серверов имеет смысл внедрять Ansible?

Окупается с 5–7 однотипных серверов. На двух-трёх можно ходить руками. С двадцати становится критично, с пятидесяти — без Ansible невозможно.

Сколько занимает внедрение Ansible с нуля?

Базовая инфраструктура — inventory, 5–7 ролей, vault, документация — 3–5 рабочих дней инженера. Полная автоматизация типового веб-стека — 10–15 дней.

Нужен ли отдельный сервер под Ansible?

Нет, Ansible не требует серверной части на узлах — только SSH. Управляющий узел можно держать на ноутбуке инженера, на bastion-сервере или в виде CI-раннера в GitLab/Gitea.

Что выбрать — Ansible или Puppet/Chef?

В 2026 году Ansible занимает 70%+ рынка благодаря YAML-синтаксису и отсутствию агента. Puppet/Chef остаётся в крупных корпорациях, где исторически используется.

Можем ли мы заказать внедрение Ansible под ключ?

Да, в АйТи Фреш мы делаем полный цикл: аудит инфраструктуры, написание ролей под ваши сервисы, документация, обучение ваших инженеров. Бюджет от 95 000 руб.