Infrastructure Testing: Terratest и kitchen-terraform для Terraform

Terratest: почему ручная проверка Terraform не масштабируется

Ручное тестирование инфраструктуры выглядит надёжным ровно до первого изменения, которое проходит ревью и тихо ломает окружение. Инфраструктура как код описывает желаемое состояние, но само описание никто не исполняет — инженер читает terraform plan глазами и решает, что всё выглядит разумно. Проверка terraform в таком режиме сводится к сверке diff с ожиданиями в голове, а не к фактическому применению и замеру результата.

Дальше появляется расхождение описания и окружения. Кто-то поправил правило файрвола через консоль, доработал политику доступа вручную, добавил ресурс вне репозитория — и следующее применение либо затирает ручную правку, либо падает из-за конфликта. Дрейф копится бесшумно, потому что в репозитории всё чисто, а в реальности уже нет.

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

Отсюда и предел масштабирования: чем больше окружений и модулей, тем дороже каждая ручная проверка и тем меньше вероятность, что её вообще проведут. Terratest закрывает это тем, что разворачивает настоящую инфраструктуру в изолированном проекте, проверяет её доступность и поведение кодом и сносит после прогона. Разбираем, как такая проверка встраивается в конвейер выпуска.

Что даёт автоматическая проверка инфраструктурного кода

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

Какие классы отказов уходят

План применения описывает намерение, но не проверяет, что после него сервис отвечает. Тесты на Terratest разворачивают окружение с нуля и проверяют результат: доступность по сети, привязку прав, наличие ресурса после повторного применения. Уходит целый класс отказов «конфигурация применилась, но сервис не поднялся» — такие ошибки ловятся до слияния, а не в момент выката.

Сколько времени занимает проверка изменения

Ручная проверка изменения в тестовом окружении занимает часы: поднять, применить, убедиться. Один прогон на изолированной копии укладывается в минуты, а прогоны разных ветвей идут параллельно. Ответ «изменение безопасно» разработчик получает до слияния, и очередь на выкат не простаивает в ожидании проверяющего.

Предсказуемость выката в рабочие окружения

Сценарий проверки один и тот же для тестового и рабочего окружения — отличаются только наборы переменных и масштаб. Добавляется проверка повторного применения: если второй прогон не меняет план, конфигурация идемпотентна и не «дрейфует» со временем. Доля выкатов, требующих ручных правок после применения, снижается, а откат опирается на тот же отработанный сценарий.

Terratest и kitchen-terraform: подходы к проверке конфигураций

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

Terratest и kitchen-terraform закрывают именно интеграционный уровень: они поднимают изолированный полигон, применяют конфигурацию и проверяют фактический результат, а затем снимают за собой ресурсы. Локальный эмулятор инфраструктуры заметно быстрее, но не воспроизводит поведение провайдера. Ниже — варианты, между которыми реально выбирают.

Варианты проверки

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

Этапы внедрения проверок инфраструктурного кода

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

1. Аудит инфраструктуры. Разбираем описания ресурсов, модули и историю изменений: где правка одного ресурса тянула за собой пересоздание зависимых, где конфигурация расходилась с фактическим состоянием. Результат — перечень узких мест с оценкой частоты и цены сбоя.
2. Схема проверок. Определяем, что проверяем на этапе плана (состав ресурсов, связи, значения атрибутов), а что — только на развёрнутом окружении: доступность сервисов, права доступа, идемпотентность повторного применения.
3. Настройка полигона. Собираем изолированный проект с тестовыми учётными записями, ограничением по времени жизни и автоматической уборкой ресурсов — окружение не копит мусор и не мешает соседним командам.
4. Набор проверок. Terratest закрывает сценарии «подняли — проверили — снесли», kitchen-terraform — сверку фактического состояния с ожидаемым. Набор разбит по уровням: быстрый контур, интеграционный, сквозной.
5. Подключение к сборочному конвейеру. Быстрые проверки идут на каждый коммит, полный полигон — на релизные ветки. Проверки запускаются параллельно в отдельными проектах, а результат блокирует применение изменений при падении.
6. Разбор ложных срабатываний. Нестабильные проверки лечим причиной — гонками, общими ресурсами, слишком короткими таймаутами, а не отключением. Держим правило: отключённая проверка возвращается в тот же день.
7. Передача. Отдаём регламент сопровождения, описание уровней проверок и инструкцию по добавлению нового модуля — команда расширяет набор без нас.

На выходе каждое изменение проходит проверку за минуты, а не после выката в рабочее окружение. Обсудите задачу — вернёмся с оценкой и планом.

Артефакты внедрения: конфигурации, схемы, регламенты

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

• Модули описания инфраструктуры — параметризованные блоки с переменными и значениями по умолчанию: окружения поднимаются из одного набора, отличия задаются значениями, а не копиями конфигураций.
• Комплект проверок на Terratest — набор сценариев, который до применения изменений разворачивает контур, проверяет связи между ресурсами и удаляет его за собой; плюс статические проверки формата и корректности ссылок.
• Конфигурация полигона — изолированный тестовый контур, где проверки прогоняются целиком до продакшена, с отдельными правами и без доступа к рабочим данным.
• Схема ролей и доступов — разграничение прав доступа по ролям: кто вносит изменения, кто согласует, у кого только чтение состояния; применение изменений идёт от отдельной учётной записи.
• Документация инфраструктуры — карта ресурсов и зависимостей, описание переменных, точек расширения и того, какие проверки покрывают какой участок.
• Регламент сопровождения — порядок внесения изменений: обязательные проверки, требования к ревью, условия, при которых изменение не пропускается в рабочее окружение.
• Инструкция по откату — пошаговый сценарий возврата к предыдущему состоянию с указанием, что проверяется после отката.

Комплект передаём с разбором на вашей стороне: показываем, как запустить проверки, добавить новую и расширить модуль под задачу, которой сейчас нет.

Кейс: автоматические проверки до применения изменений

Заказчик — платформенная команда с тридцатью окружениями и общей веткой модулей. Проверкой изменений служил ручной просмотр плана: три изменения из десяти доходили до рабочего окружения и откатывались, а ошибка уровня «удалён ресурс из состояния» могла жить в конфигурации неделями, пока её не находил очередной запуск.

Что сделали

На каждый модуль появились тесты на Terratest: они поднимают реальную инфраструктуру в изолированном проекте, применяют конфигурацию, проверяют фактические свойства созданных объектов и удаляют всё за собой. Для машин добавили kitchen-terraform — он проверяет не только применение, но и состояние внутри: запущенные службы, права, пути, доступность портов.

План стал обязательным шагом с контролем ожиданий: число создаваемых и удаляемых объектов сверяется с эталоном, а незапланированное удаление останавливает процесс проверки до разбора инженером.

Что стало

Доля изменений, дошедших до рабочего окружения и откаченных, снизилась с 30% до нуля за квартал. Проверка, которая занимала два дня ручной работы, укладывается в 25 минут и идёт параллельно по окружениям. Класс отказов «конфликт типов и удаление занятых ресурсов» закрыт полностью: тест на повторное применение и последующее удаление обязателен для каждого модуля, и релиз без него не собирается.

Отдельный эффект — предсказуемость разбора: инженер получает лог с конкретным несоответствием, а не набор догадок. Среднее время от обнаружения проблемы до исправления сократилось вчетверо, потому что окружение для воспроизведения поднимается тестом, а не руками.

Что делать, если часть инфраструктуры описана вручную?

Ручная инфраструктура появляется почти одинаково: срочный релиз, ресурс подняли в консоли провайдера, «временное» решение живёт месяцами. Сносить и пересоздавать такое по коду нельзя — на этих объектах уже данные и трафик. Первый шаг здесь не переписывание, а заведение существующих ресурсов в описание состояния, чтобы код и реальность сошлись без простоя.

Инвентаризация ресурсов: собираем всё, что реально существует, через интерфейсы провайдеров, сверяем с конфигурацией и размечаем — под управлением, вне управления, дублирующееся. Отдельно фиксируем связи между объектами: сеть, правила доступа, привязки томов. Порядок переноса задают именно эти зависимости, иначе первым же переносом можно порвать маршрут до сервиса.

Поэтапный перенос идёт по одному контуру или сервису за раз, и критерий готовности этапа простой — пустой план изменений: код описывает ровно то, что есть, и не собирается ничего удалять. Для ресурсов с данными сначала запрещаем пересоздание, и только потом правим описания.

Проверки подключаем до следующего этапа: Terratest прогоняет план и применение на изолированном окружении и подтверждает, что сеть, права доступа и балансировщик собираются в нужной конфигурации. Состояние держим в удалённом хранилище с блокировкой и версиями — откат к предыдущему снимку занимает минуты.

Итог: сначала инвентаризация, затем по одному контуру с пустым планом, и лишь после этого — регламент, отсекающий ручные правки. Опишите, что у вас создано в обход описаний, — вернёмся с оценкой и порядком этапов.

Частые технические вопросы о проверке инфраструктуры

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

Как быть с секретами в проверках?

Секреты не попадают ни в код, ни в описания ресурсов: значения подтягиваются из переменных окружения и хранилища секретов в момент прогона. В журналах они маскируются. В репозитории остаются только имена переменных и примеры фиктивных значений — набор можно показывать и передавать без риска утечки.

Можно ли запускать проверки локально?

Да, если у инженера есть доступ к тестовому аккаунту — набор запускается с рабочей машины той же командой, что и на сервере проверок. Там, где доступ выдавать нежелательно, тот же прогон идёт в контейнере. Это снимает очередь и позволяет отлаживать модуль сразу после правки.

Кто поддерживает набор проверок?

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

Обсудим задачу: как проходит первый разбор

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

Что мы приносим и разбираем на первой встрече:

• Карту репозиториев и модулей: где описано состояние, что переиспользуется, где дублирование и расхождения.
• Перечень окружений и различий между ними — что настроено руками, а что описано кодом и воспроизводится.
• Инвентаризацию проверок: какие уже есть, какие пути изменений не покрыты и где ошибка дойдёт до рабочего контура.
• Разбор тестового контура на Terratest: как проверяется применение конфигураций, сколько идёт прогон, что мешает запускать его на каждое изменение.
• Схему доставки изменений и точек отказа: где процесс останавливается, где нужен ручной шаг и почему.
• Риски отката: где нет резервных копий состояния, какие изменения необратимы и как это обходится.
• Оценку и план работ: этапы, критерии готовности каждого, состав команды и порядок приёмки результата.

Опишите задачу — вернёмся с оценкой и планом и назовём срок первого разбора. Если по его итогам вам достаточно своих сил, мы передадим материалы в вашем формате и не будем предлагать лишние этапы.