Конфигурация накапливалась годами
На сервере четыре года ручных правок: забытые пакеты, изменённые лимиты, скрипты в /etc/cron.d. Никто не знает, что из этого критично, а что — мусор. Пересоздать такую машину нельзя.
Инфраструктура как код
Инфраструктура описана кодом а не в голове администратора
Описываем серверы, сети, балансировщики и базы в Terraform и Ansible. Изменения инфраструктуры проходят ревью и попадают в историю, стенд поднимается одной командой, а восстановление после аварии перестаёт зависеть от памяти конкретного человека.
Или сразу: +7 (962) 368-39-51 Telegram
plan
изменения видны до применения
ревью
инфраструктура меняется через pull request
дрейф
расхождения ловятся автоматически
DR
восстановление проверено учениями
Сервер, который нельзя пересоздать
Самая дорогая форма технического долга: инфраструктура, воспроизводимость которой держится на памяти одного-двух инженеров.
Дрейф между прод-1 и прод-2
Два сервера за балансировщиком должны быть одинаковыми, но различаются версиями расширений и настройками кэша. Часть запросов работает иначе — в зависимости от того, куда попал пользователь.
Правки в продакшене без следов
Срочный фикс делается руками по SSH и не попадает ни в репозиторий, ни в документацию. Следующая пересборка стенда это изменение молча потеряет.
Доступы и ключи без учёта
Общий root-доступ у подрядчиков, ключи не ротируются, вход по паролю открыт наружу. При уходе сотрудника никто не уверен, что доступ закрыт.
Стенда нет: тестировать негде
Окружение под новую задачу собирается вручную и потом живёт месяцами в полурабочем состоянии. Проверка интеграций и нагрузочных сценариев откладывается до продакшена.
План восстановления существует только на словах
Документ про disaster recovery написан для аудита, но переезд на резервный контур ни разу не проводился. Реальное время восстановления измеряется сутками, а не часами.
Что мы описываем кодом
Начинаем с импорта того, что уже работает, а не с чистой страницы: сначала фиксируем текущее состояние, потом меняем.
Ресурсы в Terraform
Облачные ресурсы, сети, балансировщики, DNS и управляемые базы описываются декларативно и создаются одинаково в любом окружении.
- Импорт существующих ресурсов в код без пересоздания инфраструктуры
- Модули для типовых окружений: прод, стенд, окружение под нагрузочные тесты
- Remote state с блокировками и разделением по окружениям
- План изменений в CI: любой выкат инфраструктуры виден на ревью
Конфигурация серверов в Ansible
Пакеты, системные параметры, службы, cron и права описываются идемпотентными ролями, а не набором shell-скриптов.
- Роли и инвентарь по окружениям, единая точка правды для всех серверов
- Идемпотентность: повторный прогон не меняет систему и отчитывается об отсутствии изменений
- Развёртывание приложения, очередей, планировщика и агентов мониторинга
- Тестовый прогон на одноразовой виртуальной машине перед применением на прод
Секреты и доступы
Секреты не живут в репозитории. Доступ к серверам выдаётся по ключам и ролям, любые изменения оставляют след.
- Хранилище секретов (Vault, SOPS или менеджер облака) с разграничением прав
- Вход только по SSH-ключам через бастион, root-доступ и пароли закрыты
- Ротация ключей и токенов по регламенту, а не по факту инцидента
- Изоляция секретов от состояния Terraform: state тоже требует защиты
Дрейф, образы и восстановление
Инфраструктура считается исправной только тогда, когда её состояние совпадает с кодом, а не когда серверы просто отвечают на пинг.
- Ночная проверка дрейфа: расхождения между кодом и реальностью попадают в отчёт
- Golden image или контейнерный образ: сервер пересоздаётся, а не ремонтируется
- Runbook восстановления из кода и учения по подъёму контура с нуля
- Документация по инфраструктуре генерируется из репозитория и не устаревает
Как мы переводим инфраструктуру в код
Ничего не пересоздаём «с нуля»: сначала код описывает то, что уже работает, и только затем мы меняем инфраструктуру через ревью.
-
01 2–4 недели
Инвентаризация
Составляем карту серверов, сетей, баз и внешних сервисов. Находим ручные настройки, от которых зависит работа продакшена, и фиксируем их в описании.
-
02 1–2 недели
Импорт и структура
Переносим ресурсы в Terraform, настраиваем окружения и модули, описываем конфигурацию серверов ролями Ansible. Первый прогон должен не менять прод, а подтвердить совпадение.
-
03 1–2 недели
Конвейер для инфраструктуры
Подключаем план изменений в CI, проверку дрейфа по расписанию, ограничения на ручные правки и порядок согласования опасных операций.
-
04 1 неделя
Восстановление и передача
Поднимаем тестовый контур целиком из кода, замеряем время, проводим учения по восстановлению и передаём команде документацию и доступы.
Как перевести в код инфраструктуру, которая уже работает
Переписывать прод с нуля опасно, поэтому мы начинаем с импорта. У Terraform для этого есть блоки import: ресурс описывается в коде, сопоставляется с существующим объектом у провайдера, после чего план должен показать отсутствие изменений. Если план что-то меняет — значит, описание расходится с реальностью, и это надо разобрать до применения.
Такой подход даёт два эффекта. Во-первых, продакшен не трогается до того, как код начнёт точно описывать текущее состояние. Во-вторых, сразу вскрываются «теневые» ресурсы: серверы, созданные вручную и не упомянутые ни в одной схеме, о которых часто не помнит никто, кроме бывшего администратора.
Почему Ansible-скрипты ломаются на втором прогоне
Разница между набором shell-команд и ролью Ansible — в идемпотентности. Команда echo ... >> /etc/nginx/nginx.conf при повторном запуске добавит строку второй раз, а модуль lineinfile приведёт файл к описанному состоянию. Именно поэтому роли пишутся на модулях, а не через модуль shell.
Дополнительно мы проверяем каждую роль на одноразовой виртуальной машине: прогон с нуля, затем повторный прогон, который обязан показать отсутствие изменений. Только после этого роль применяется к боевым серверам. Такой порядок ловит большинство ошибок до продакшена и делает обновление парка серверов предсказуемым.
Где хранить секреты, если инфраструктура в git
Репозиторий с описанием инфраструктуры удобен, но в него нельзя помещать пароли к базам, ключи API и приватные ключи. Мы используем внешнее хранилище секретов: приложение или провижн получает значение во время работы, а в репозитории остаётся только ссылка на него.
Отдельного внимания требует состояние Terraform: в нём могут оказаться чувствительные значения, включая пароли управляемых баз, созданных через провайдера. Поэтому state хранится в защищённом бэкенде с ограниченным доступом, разделяется по окружениям и не попадает в открытые артефакты конвейера. Чувствительные выходные значения помечаются как sensitive, а доступ к бэкенду ограничивается ролями.
Частые вопросы
С инвентаризации и импорта. Сначала фиксируем реальное состояние: какие серверы, сети, базы и внешние сервисы используются и какие ручные настройки критичны для работы. Затем описываем это в Terraform и Ansible так, чтобы план изменений был пустым, то есть код совпадал с продакшеном. Только после этого начинаем менять инфраструктуру через репозиторий и ревью.
Они решают разные задачи и обычно используются вместе. Terraform создаёт и изменяет ресурсы: виртуальные машины, сети, балансировщики, управляемые базы, DNS. Ansible настраивает то, что внутри машин: пакеты, службы, конфигурационные файлы, права. Попытка делать всё одним инструментом приводит либо к хрупким скриптам, либо к лишним пересозданиям ресурсов.
Функционально инструменты почти совместимы, и выбор чаще определяется требованиями к лицензированию и поддержке. OpenTofu развивается как открытый форк с сообществом и совместим с большинством провайдеров и модулей. Мы работаем с обоими вариантами и выбираем тот, который подходит вашей юридической и инфраструктурной ситуации; миграция между ними, как правило, сводится к замене бинарника и проверке состояния.
Серверы можно пересоздавать, данные — нет. Поэтому всё состояние выносится за пределы машин: базы данных, объектные хранилища, кэш и очереди. Для данных настраиваются резервные копии и, где это применимо, восстановление на момент времени, а восстановление регулярно проверяется на отдельном контуре. Принцип простой: машина — расходный материал, данные — актив, который требует отдельного плана.
DevOps: другие направления
Смежные задачи, которые обычно решаются в одном проекте с этой.
Сколько времени займёт подъём вашей инфраструктуры с нуля?
Если ответ «не знаю» — это и есть задача, которую мы решаем. Расскажите о контуре, предложим план.