Отклонение некорректной инфраструктуры до планирования

Введение

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

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

Связь с сертификацией

Добавление проверок перед планированием

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

Используйте интерфейс Terminal. Перейдите в предоставленный репозиторий Git и загрузите его окружение инструментов. source применяет подготовленные переменные к текущей оболочке; инфраструктуру эта команда не развёртывает.

cd /home/labex/project/report-delivery
source environment.sh

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

cat main.tf pipeline.json

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

terraform fmt -check проверяет каноническое форматирование Terraform, не перезаписывая файлы. terraform validate проверяет внутреннюю согласованность инициализированной конфигурации, включая допустимые атрибуты ресурсов. Ни одна из этих проверок не доказывает соответствие конфигурации бизнес-требованиям; проверки утверждений для модулей рассматриваются в следующей лабораторной работе.

Предоставленный исполнитель сопоставляет имена этапов с фиксированными командами Terraform и останавливается при первой ошибке. Сохраните run-job.py без изменений: ваша задача — настроить pipeline.json, а не переписать предоставленный исполнитель. Прежде чем оценивать поведение рабочей точки входа, проверки подтверждают её соответствие предоставленному оригиналу. Добавьте обе проверки перед планированием. Here-document записывает JSON между своими разделителями в pipeline.json; кавычки вокруг EOF сохраняют содержимое буквально.

cat > pipeline.json <<'EOF'
{"stages":["fmt","validate","plan"]}
EOF

Запустите задание стандартным интерпретатором Python. Это учебный локальный исполнитель; его этапы выполняют стандартные команды Terraform.

python3 run-job.py

Ожидайте [fmt] native exit 0, [validate] native exit 0 и [plan] native exit 0. План сообщает об отсутствии изменений, потому что предоставленная инфраструктура уже соответствует своей конфигурации. Ошибка останавливает последующие этапы. План с изменениями возвращает собственный код завершения 2, который исполнитель считает успешным предварительным просмотром, но никогда — разрешением на применение.

Изучите своё изменение с помощью Git. -- отделяет путь от параметров команды.

git diff -- pipeline.json

В diff обе новые проверки должны находиться перед plan. В этом задании нет этапа apply.

Остановка при ошибке форматирования

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

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

cat >> main.tf <<'EOF'

output "format_probe" {value="spacing"}
EOF

Запустите задание ещё раз. Эта команда должна завершиться с ошибкой; именно ошибка здесь является полезным результатом.

python3 run-job.py

Первый этап сообщает собственный код завершения 3 и выводит main.tf. Задание печатает Job stopped; later stages did not run. Строк [validate] и [plan] быть не должно. Форматирование можно исправить без обращения к AWS.

Изучите точные предлагаемые изменения форматирования. -diff показывает их, а -check оставляет файл без изменений.

terraform fmt -check -diff

Эта команда тоже намеренно возвращает ненулевой код завершения. Оставьте дефект форматирования для проверки этого шага; на следующем шаге вы его исправите.

Различие между форматированием и корректностью

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

Сначала дайте Terraform исправить пробелы непосредственно в файле. Запуск fmt без -check изменяет форматирование.

terraform fmt

В выводе указан main.tf. Убедитесь, что исправленная конфигурация проходит задание.

python3 run-job.py

Должны выполниться все этапы. Дополнительное выходное значение может привести к тому, что plan вернёт собственный код завершения 2; он предлагает изменение выходного значения, не применяя его.

Теперь добавьте ссылку на атрибут, который ресурс бакета S3 не экспортирует. Этот блок использует каноническое форматирование, поэтому может пройти первый контрольный этап.

cat >> main.tf <<'EOF'

output "missing" {
  value = aws_s3_bucket.reports.missing_attribute
}
EOF

Сначала проверьте только форматирование.

terraform fmt -check

Команда возвращает ноль и ничего не выводит. Затем запустите полное задание.

python3 run-job.py

Ожидайте успешного прохождения проверки форматирования, затем собственного кода завершения 1 у validate и диагностического сообщения Unsupported attribute. Строки этапа планирования быть не должно. Выражение отформатировано правильно, но ссылается на неподдерживаемый атрибут. Оставьте эту ошибку для проверки шага.

Исправление конфигурации и сохранение среды

На этом шаге вы восстановите заведомо корректную конфигурацию ресурса, повторно запустите задание с контрольными этапами и проверите, что хранилище отчётов не изменилось.

git restore -- main.tf восстанавливает только этот файл из начального коммита репозитория. Команда удаляет оба экспериментальных выходных значения и сохраняет отдельные изменения в pipeline.json.

git restore -- main.tf

Запустите полное задание ещё раз.

python3 run-job.py

Все три этапа должны вернуть собственный код завершения 0. План должен сообщить об отсутствии изменений. Успешные статические проверки разрешают планирование; они не одобряют и не выполняют развёртывание.

Прочитайте отчёт непосредственно из хранилища. - отправляет его содержимое в стандартный вывод вместо сохранения ещё одной локальной копии.

aws s3   cp s3://delivery-gates-reports/report.csv -

Ожидайте:

quarter,total
Q1,320

Изучите соседний отчёт, который необходимо сохранить в этом упражнении.

aws s3   cp s3://delivery-gates-neighbor/keep.txt -

В нём по-прежнему должно быть preserve neighboring report. Изучите итоговый diff Git, чтобы убедиться, что вашим сохраняемым изменением является конфигурация конвейера.

git diff -- main.tf pipeline.json

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

Резюме

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

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