Почему всегда нужно смотреть план перед запуском Terraform

Вы только что закончили писать конфигурацию Terraform для нового сервера и базы данных. Файл выглядит правильно. Вы запускаете terraform apply и ждете. Через несколько секунд вы понимаете, что сервер в два раза мощнее, чем нужно, а база данных находится не в том регионе. Теперь придется все удалять и начинать заново.

Этот сценарий постоянно повторяется в командах, которые только начинают работать с Infrastructure as Code. Желание пропустить шаги и сразу применить изменения очень велико. Но есть один шаг, который экономит время, деньги и нервы: просмотр плана перед выполнением.

Что происходит, когда вы пропускаете план

Когда вы запускаете terraform apply напрямую, Terraform немедленно начинает создавать, изменять или удалять ресурсы в соответствии с вашей конфигурацией. Если что-то не так, вы узнаете об этом только после того, как изменения уже внесены. Откат может быть простым для одних ресурсов, но для других он может включать ручную очистку, тикеты в поддержку облачного провайдера или даунтайм для пользователей.

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

Вам нужен способ предварительного просмотра того, что сделает Terraform, прежде чем он это сделает.

Как работает Terraform Plan

Команда terraform plan генерирует так называемый план выполнения. Она читает ваши конфигурационные файлы и сравнивает их с текущим состоянием вашей инфраструктуры, которое хранится в файле состояния Terraform. Вывод показывает, какие ресурсы будут созданы, изменены или удалены, а также детали каждого изменения.

Ключевое отличие в том, что terraform plan не вносит никаких изменений. Он только читает и сравнивает. Никакие ресурсы не создаются, не обновляются и не уничтожаются. Вы можете запускать его сколько угодно раз без какого-либо влияния на инфраструктуру.

Вот что происходит, когда вы его запускаете:

terraform plan

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

  • Будет создан один виртуальный сервер с 2 ядрами CPU и 8 ГБ RAM
  • Будет создана одна база данных с хранилищем на 100 ГБ
  • Оба ресурса будут соединены через внутреннюю сеть

Если у вас уже есть работающий сервер и вы меняете его конфигурацию, план покажет, что существующий сервер будет обновлен на месте, а не уничтожен и создан заново. Это различие важно, потому что обновления на месте обычно безопаснее и быстрее, чем замена.

Почему план важен для вашего рабочего процесса

План выполнения дает вам три вещи, которые иначе получить сложно.

Во-первых, вы можете проверить, что ваши изменения соответствуют задуманному. Прежде чем принять решение о применении изменений, у вас есть возможность просмотреть детали. Случайно указали не тот тип инстанса? Верна ли версия движка базы данных? План показывает эти детали четко.

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

В-третьих, вы можете поделиться планом с другими людьми. В командной работе не всем нужно понимать синтаксис Terraform. Но большинство инженеров могут прочитать вывод плана и заметить потенциальные проблемы. Администратор базы данных может проверить, подходит ли конфигурация хранилища. Инженер по безопасности может проверить, не слишком ли разрешающие правила сети.

Использование плана в CI/CD пайплайнах

В командной среде terraform plan обычно автоматизирован в CI/CD пайплайне. Когда кто-то открывает pull request с изменениями конфигурации инфраструктуры, пайплайн автоматически запускает terraform plan и публикует результат в виде комментария к pull request.

Этот рабочий процесс позволяет всей команде просмотреть, что изменится, до того, как код будет слит. Обсуждение ведется вокруг вывода плана, а не вокруг абстрактных описаний того, что код может сделать. Вопросы вроде "Почему этот ресурс заменяется?" или "Должна ли эта группа безопасности быть открыта в интернет?" получают ответы до того, как какие-либо изменения будут применены.

Следующая блок-схема иллюстрирует типичный цикл "план-рецензирование-применение", используемый в CI/CD пайплайнах:

flowchart TD A[Изменение кода] --> B[Terraform Plan] B --> C{Рецензирование плана} C -->|Одобрено| D[Terraform Apply] C -->|Не одобрено| E[Исправление кода] E --> A D --> F[Инфраструктура обновлена]

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

Распространенная ошибка: устаревшие планы

Есть одно важное ограничение, которое нужно понимать. План выполнения — это снимок того, что Terraform сделал бы в момент запуска команды. Если кто-то другой изменит инфраструктуру между запуском terraform plan и terraform apply, план может стать неточным.

Например, предположим, вы запустили terraform plan и увидели, что будет создан один сервер. Прежде чем вы запустите terraform apply, ваш коллега вручную создает тот же сервер через консоль облака. Когда вы запускаете terraform apply, Terraform обнаружит конфликт и завершится ошибкой, или, что еще хуже, может создать дублирующий ресурс в зависимости от того, как написана ваша конфигурация.

Вот почему в хороших рабочих процессах шаги plan и apply выполняются близко друг к другу. В CI/CD пайплайнах один и тот же запуск пайплайна обычно выполняет оба шага последовательно. Для локальной разработки вы должны запускать plan непосредственно перед apply, а не за часы или дни до этого.

Некоторые команды также используют блокировку состояния, чтобы предотвратить одновременные изменения. Когда один человек или пайплайн выполняет plan или apply, другие блокируются от внесения изменений до завершения операции.

Практический чек-лист для использования Terraform Plan

  • Запускайте terraform plan перед каждым terraform apply, даже для небольших изменений
  • Проверяйте вывод плана на предмет неожиданных замен или удалений ресурсов
  • Убедитесь, что количество создаваемых ресурсов соответствует вашим ожиданиям
  • Обращайте внимание на изменения в группах безопасности, сетевых правилах и IAM политиках
  • Делитесь выводом плана с соответствующими членами команды для рецензирования
  • В CI/CD публикуйте план в виде комментария к pull request
  • Держите шаги plan и apply близко друг к другу по времени
  • Используйте блокировку состояния для предотвращения конфликтов в командной работе

Что вы получаете от этой привычки

Привычка запускать terraform plan перед каждым изменением переводит ваш рабочий процесс из реактивного в осознанный. Вместо того чтобы обнаруживать проблемы после создания ресурсов, вы ловите их, пока они еще просто текст на экране. Стоимость исправления ошибки в плане равна нулю. Стоимость ее исправления после apply может составлять часы отладки, ручной очистки и координации с командой.

В следующий раз, когда будете писать конфигурацию Terraform, сначала запустите план. Внимательно прочитайте вывод. Затем решите, применять ли изменения. Этот один дополнительный шаг отделяет команды, которые уверенно управляют инфраструктурой, от команд, которые постоянно устраняют последствия своих действий.