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

Привет всем! Я, Семёнов Евгений Сергеевич, директор ITFresh. Сегодня расскажу вам про один крутой кейс, который случился у нас в 2025 году. Только представьте: приходит к нам веб-студия с командой в 18 человек, у них больше 40 клиентских серверов, и один-единственный сисадмин, чья работа сводилась к бесконечным накатываниям обновлений. Знакомо? Мы внедрили Ansible, и теперь вместо восьми часов на всю эту рутину уходит всего 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/.
• Для всех ваших секретов — будь то пароли от баз данных, ключи API или учётные записи SMTP — мы используем Ansible Vault. Это надёжно.
• На управляющем узле 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. У нас есть один-единственный мастер-пароль, известный строго двум людям: сисадмину клиента и мне, как куратору всего проекта. Структура файлов внутри 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 вам нужен, а когда — нет

За пятнадцать лет в IT я насмотрелся всякого: как Ansible бездумно пихают куда ни попадя, а где он реально спасает, его почему-то игнорируют. Делюсь своими выводами:

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

• У вас, например, пять или больше однотипных серверов, и вы постоянно выполняете на них одни и те же операции. Зачем тратить время вручную?
• Работает команда из двух и более инженеров? Тогда вам просто необходима согласованность, чтобы каждый не изобретал велосипед, а все делали по единому стандарту.
• Постоянно приходится разворачивать новые серверы? Это может быть частью вашего DevOps-цикла или просто запуск очередных новых проектов.
• Вам нужен чёткий след: кто, когда и что именно менял на серверах? Это не роскошь, а необходимость.
• Приходят аудиторы и требуют показать, «как именно настроены серверы»? Представлять им Git-репозиторий с чёткими ролями куда убедительнее, чем слушать долгие рассказы инженера. Всё на виду, всё прозрачно.

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

• Если же у вас всего пара-тройка серверов, и они стоят себе годами, почти не меняясь, возможно, Ansible вам пока и не нужен.
• Знакомо, когда за всю систему отвечает только один инженер, и все знания у него в голове? Мы в ITFresh часто видим такой сценарий: все критически важные данные и навыки сконцентрированы в одном человеке. Что произойдет, если он заболеет, уйдёт в отпуск или решит сменить работу? Ваша IT-инфраструктура рискует оказаться в подвешенном состоянии, а вы — без поддержки.
• Ваши серверы не клоны, верно? На нашей практике мы постоянно убеждаемся, что каждый из них выполняет свою, часто принципиально уникальную роль — от базы данных и бэкенда до файлового хранилища или почтового шлюза. Здесь нет места однотипным решениям или повторяющимся паттернам. Каждый сервер требует глубокого, индивидуального подхода, потому что одинаковых задач просто не бывает.

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

Когда клиент приходит к нам, в ITFresh, за внедрением 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 руб.