Проверка и применение изменения хранилища

Введение

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

Эта независимая среда подготавливает небольшое исходное хранилище и локальное состояние. Используйте знания о plan/apply, файлах переменных и запросах S3; удалённое состояние и автоматизированные одобрения не требуются.

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

Проверка и применение сохранённого плана

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

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

cd /home/labex/project/storage-change
cat main.tf
cat release.tfvars
terraform state list
aws s3api \
  get-bucket-tagging \
  --bucket terraform-change-reports

Файл входных значений сейчас выбирает выпуск 1. Изменение имени ресурса могло бы заменить хранилище, а изменение тега может обновить существующий бакет. Измените только входное значение выпуска:

cat > release.tfvars <<'EOF'
release = "2"
EOF
terraform plan -var-file=release.tfvars -out=change.tfplan

Ожидайте обновление бакета на месте: 0 to add, 1 to change, 0 to destroy. -out записывает собственный артефакт плана Terraform, который содержит эту конфигурацию и эти входные значения. В отличие от несохранённого предварительного просмотра, применение этого файла использует проверенный план, а не создаёт новый на основе последующих правок. В реальных проектах планы могут содержать конфиденциальные значения, поэтому обращайтесь с ними как с артефактами проекта.

Прочитайте сохранённый план перед применением:

terraform show change.tfplan

Убедитесь, что Release меняется с 1 на 2 и ни объект, ни бакет не заменяется. Затем примените артефакт. Для сохранённого плана дополнительный запрос yes не появляется:

terraform apply change.tfplan

Запросите текущий тег и прочитайте отчёт:

aws s3api \
  get-bucket-tagging \
  --bucket terraform-change-reports
aws s3api \
  get-object \
  --bucket terraform-change-reports \
  --key reports/current.csv \
  retained.csv
cat retained.csv

Ожидайте выпуск 2 и orders,12. Сохранённый план полезен только тогда, когда изменённый ресурс и сохранённые данные соответствуют проверенному изменению.

Обнаружение и исправление дрейфа тега

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

Дрейф — это различие между развёрнутым ресурсом и его желаемой конфигурацией. Используйте AWS CLI, чтобы изменить тег вне Terraform. Это намеренное упражнение меняет реальный атрибут ресурса, который провайдер может прочитать; оно не редактирует локальный маркер успеха.

aws s3api \
  put-bucket-tagging \
  --bucket terraform-change-reports \
  --tagging '{"TagSet":[{"Key":"Project","Value":"TerraformReports"},{"Key":"Release","Value":"unexpected"}]}'

Попросите Terraform сравнить текущий ресурс с желаемым выпуском. -detailed-exitcode различает 0 (нет изменений), 2 (предлагается изменение) и 1 (ошибка). Следующий план намеренно возвращает 2; это означает, что он нашёл различие тега, а не что развёртывание завершилось неудачно.

terraform plan -var-file=release.tfvars -detailed-exitcode

План предлагает вернуть unexpected к 2. Изучите и сохраните исправление, затем примените этот артефакт:

terraform plan -var-file=release.tfvars -out=repair.tfplan
terraform show repair.tfplan
terraform apply repair.tfplan

Подтвердите текущий тег и план без расхождений:

aws s3api \
  get-bucket-tagging \
  --bucket terraform-change-reports
terraform plan -var-file=release.tfvars -detailed-exitcode

Тег равен 2; итоговый план сообщает No changes и завершается с кодом 0. Отчёт остаётся без изменений. Это демонстрирует дрейф тега, доступный для чтения провайдером, а не обнаружение всех возможных изменений данных вне Terraform. О сохранённых планах и подробных кодах завершения читайте в документации Terraform plan.

Удаление изменённого хранилища

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

Изучите и выполните удаление, введя yes для destroy:

terraform plan -destroy -var-file=release.tfvars
terraform destroy -var-file=release.tfvars

Объект отчёта удаляется раньше своего бакета. Запросите оставшиеся ресурсы и пустое сопоставление:

terraform state list
aws s3api \
  list-buckets \
  --query 'Buckets[].Name'
aws s3api \
  head-object \
  --bucket team-reference-reports \
  --key keep.txt \
  --query ContentLength

Эталонный отчёт команды сохраняется. Сохранённые локальные планы — артефакты проверки; их наличие не означает, что удалённые ресурсы AWS всё ещё существуют.

Резюме

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