Всем привет, меня зовут Сергей Прощаев, и в этой статье я расскажу, как перестать бояться деплоев по пятницам и построить Continuous Delivery с помощью Ansible и GitLab CI.

Я Tech Lead и руководитель направления Java / Kotlin разработки в FinTech & E‑commerce, а ещё преподаю на курсах разработки и архитектуры в OTUS — так что тема автоматизации деплоя для меня и личный вызов, и профессиональный интерес.

Если вы хоть раз в три часа ночи правили конфиг прямо на проде, потому что «нужно срочно пофиксить баг», а потом оказывалось, что вы забыли обновить сервис на одном из серверов — добро пожаловать в клуб. Именно с этого все когда‑то начинают внедрять нормальный CD. И сегодня разберём, как настроить процесс, который не стыдно показать коллегам, а главное — который экономит время и бизнесу деньги.

Почему «ручной деплой» — это технический долг с огромными процентами

В сети есть описание одного проекта в FinTech‑компании: команда из десяти разработчиков, пять микросервисов, деплой — через SSH и bash‑скрипты. Вроде бы всё работало, пока однажды в пятницу не выкатили версию PaymentService с неправильным файлом конфигурации.

Пропустили символ в URL шлюза — платёжный API лёг на сорок минут. Сорок минут процессинг не работал. Убытки? Приличные! А причина банальная: человек скопировал конфиг не на тот сервер. После этого случая ни у кого больше не возникало сомнений: «Всё, автоматизируемся».

Ручной деплой страшен не ошибками самих разработчиков — он страшен непредсказуемостью. Невозможно гарантировать, что на двух серверах лежит одна и та же версия, что рестарт сервиса произошёл именно после копирования артефакта, что не потерялась какая‑то зависимость. И главное — каждый раз это стресс. А стресс, как известно, лучший способ выгореть раньше срока.

Что мы строим: CD глазами того, кто потом будет дебажить в два часа ночи

Прежде чем кидаться в код, давайте договоримся о терминах. Continuous Delivery (CD) в нашем контексте — это автоматический процесс, который после успешного прохождения тестов подхватывает артефакт, доставляет его на целевые серверы и аккуратно обновляет сервис. Без даунтайма. С возможностью быстро откатиться. И, что важно для sleep‑deprived инженера, с читаемыми логами каждого шага.

Мы будем использовать связку GitLab CI (оркестрация пайплайна) и Ansible (управление конфигурациями и собственно деплой). Почему не только GitLab Runner? Потому что когда у вас десяток серверов с чуть разными окружениями, Ansible даёт идемпотентность: вы описываете желаемое состояние, а не набор bash‑команд. Это как Terraform, только для софта на серверах.

В итоге цель — чтобы разработчик, замержив MR в master, через 15 минут мог увидеть свой код в продакшене, и при этом система ни разу не ответила клиенту 500-й ошибкой.

Разбор реального кейса: как мы мигрировали с Capistrano на Ansible и перестали страдать

До Ansible мы пользовались Capistrano — это Ruby‑инструмент, неплохой, но со своими заморочками. Когда проект начал расти, появились серверы на разных ОС, требования к тому, чтобы деплой шёл строго последовательно с паузами для health‑check«ов. Capistrano становился узким местом. И вот однажды мы решились.»

Первая же проблема: инвентаризация. Мы не знали точно, какой софт стоит на каждом сервере. Решили её просто — я написал небольшой Ansible playbook, который собирал факты с хостов и выгружал их в централизованный файл. Только после этого начали проектировать роли.

Роли сделали такие:

• common — базовые пакеты, пользователи, мониторинг;

• java — установка нужной версии JDK;

• app — непосредственно деплой сервиса (копирование JAR, настройка systemd unit, старт);

• nginx — обновление конфигурации reverse‑proxy.

Особый момент — обработка секретов. Пароли к БД и ключи API мы храним в GitLab CI Variables, а в Ansible они попадают через ‑extra‑vars на этапе выполнения плейбука. Никакого хардкода в репозитории.

Самая большая удача: мы сделали деплой с предварительным drain‑соединений. Перед остановкой старого экземпляра Ansible дергает health‑endpoint, если он отвечает 200 — идём дальше; если нет — стоп, алерт в Slack. Примерно вот так:

- name: Wait for service to become healthy
  uri:
    url: "http://{{ inventory_hostname }}:{{ nginx_port }}/actuator/health"
    method: GET
    return_content: yes
  register: health_check
  until:
    - health_check.status == 200
    - "'\"status\":\"UP\"' in health_check.content"
  retries: 12
  delay: 5

Теперь:

• Ansible не падает сразу

• Мы реально проверяем, что приложение UP, а не просто отвечает

Такая простая проверка помогает, когда новый билд стартовал, но не может подключиться к базе из‑за миграций.

Структура проекта: Ansible Galaxy не нужен, если у вас всё в одном репозитории

Некоторые любят раскладывать роли Ansible по Galaxy и подключать их через requirements.yml. В небольших и средних проектах я предпочитаю монорепозиторий: каталог ansible/ в корне приложения. Внутри:

ansible/
  playbooks/
    deploy-app.yml
  roles/
    app/
      tasks/
        main.yml
      handlers/
        main.yml
      templates/
        service.j2
      defaults/
        main.yml

Это дисциплинирует: инфраструктура как код лежит рядом с самим кодом, изменения ревьюятся вместе с фичами.

Zero‑downtime деплой: лучшие практики, которые мы выстрадали

Теперь к самому интересному — как обновлять сервис, чтобы пользователи не заметили. Мы используем подход Rolling Update, но без оркестратора, чисто средствами Ansible. Если у вас, скажем, три сервера за балансировщиком, Ansible идёт по ним последовательно.

Вот ключевые моменты из нашей роли app:

1. Drain connections: перед остановкой экземпляра мы вызываем эндпоинт /actuator/health с хидером X‑Drain: true, Nginx начинает возвращать 503 для этого узла и исключает его из upstream.

2. Ожидание завершения текущих запросов: даём несколько секунд, чтобы ответили клиенты.

3. Остановка старого сервиса, копирование нового JAR, запуск.

4. Health‑check нового экземпляра: если не отвечает 200 за 60 секунд — откат. Откат реализован через handler: если task с проверкой здоровья фейлится, мы вызываем restore previous version — переименовываем backup JAR обратно и стартуем его.

Визуализация того, что происходит под капотом

Вот так выглядит последовательность деплоя в виде диаграммы (рис. 2). Она помогает договориться с командой о том, какие шаги и в каком порядке выполняются, и когда какие проверки срабатывают.

При rolling update Ansible обновляет серверы по очереди, а не все сразу. Перед остановкой экземпляра на конкретном сервере балансировщик временно исключает его из обработки трафика (drain connections), чтобы активные запросы завершились без ошибок. Только после успешного health‑check нового экземпляра трафик возвращается на сервер, и процедура повторяется на следующем узле. Таким образом, клиенты ни на секунду не теряют доступ к сервису — в каждый момент времени хотя бы один узел остаётся работоспособным и принимает запросы.

Обработка ошибок: что мы проверяем до деплоя и после

Многие думают, что CD — это только про раскатку. Нет. Это ещё и про предсказуемость. Мы добавили в пайплайн шаг pre‑deploy checks:

• все эндпоинты health отвечают;

• на сервере достаточно свободного места (df ‑h, Ansible модуль shell с assert);

• синтаксис конфигов Nginx валиден (nginx ‑t).

После деплоя автоматически запускаются smoke‑тесты: обстрел основного API на пару критичных сценариев. Это не E2E, а именно лёгкий ping‑проверка, что приложение не просто стартануло, а способно ответить на бизнес‑запрос.

Когда я рассказываю про такой подход на курсах, многие удивляются: «Неужели оно всё само?» Да, само. И именно это освобождает голову для более важных вещей — архитектуры и продуктовых фич.

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

Небольшое отступление о безопасности и секретах

Я упомянул, что пароли не должны лежать в репозитории. Но этого мало. В Ansible мы также используем ansible‑vault для шифрования чувствительных переменных в инвентарных файлах (да, staging и prod шифруются разными ключами). А для деплоя в CI мы применяем GitLab CI Variables, которые маскируются в логах.

Ещё один совет: ограничьте права деплой‑пользователя. У нас ansible_user имеет sudo‑доступ только к определённым командам: systemctl restart for конкретного сервиса, копирование в /opt/app и тому подобное. Это снижает риск, даже если ключ утечёт.

История, которая напоминает, зачем всё это нужно

В 2012 году команда Etsy (тогда ещё живой пример DevOps) практиковала деплой 50 раз в день. Они использовали свои инструменты, но философия была та же: каждый коммит, прошедший тесты, автоматически идёт в прод, при этом развертывание инкрементальное и обратимое.

Когда случался сбой, они не запрещали деплои, а искали слабое место в пайплайне. Эта культура «fail forward and fix» здорово повлияла на меня. Однажды после крупного инцидента мы не стали вводить долгие согласования, а просто добавили ещё один health‑check и улучшили мониторинг. Результат: среднее время восстановления (MTTR) сократилось с полутора часов до 10 минут.

Заключение

Организация CD с Ansible и GitLab CI — это не магия, а инженерная дисциплина. Когда у вас есть pipeline, который можно запустить одной кнопкой (или вообще автоматически), когда деплой занимает минуты, а не часы, и когда ошибка приводит к автоматическому откату, а не к панике, — вы начинаете по‑другому смотреть на доставку ценности. Высвобождается энергия на творчество, а не на тушение пожаров.

Если вы чувствуете, что пора перестать править прод в midnight commander и хочется освоить современные DevOps‑практики, приглашаю вас на бесплатный открытый урок курса «DevOps практики и инструменты» на платформе OTUS. Мы подробно разбирем CI/CD, Ansible, Docker, Kubernetes и мониторинг.

➡ 19 мая в 20:00 «Организуем CD с помощью Ansible и GitLab CI». Записаться

Приходите, будет полезно. И помните: автоматизация не заменяет людей, она убирает рутину, чтобы люди могли думать.