Отдельное состояние для каждой среды

Введение

Рабочая корневая конфигурация preview выбирает состояние неверной среды, хотя обе среды и их корректные объекты состояния уже существуют. Установите правильную связь между корневой конфигурацией и ключом и внесите изменение только в preview, не повредив dev.

Вам нужны знания о локальных модулях, удалённом состоянии S3 и собственных блокировках Terraform из предыдущих разделов. Эта независимая новая среда включает оба хранилища отчётов и оба состояния; предыдущая VM или личная учётная запись AWS не нужны.

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

Обзор лабораторной работы

Определение каждой среды до внесения изменений

На этом шаге отличите две среды от двух копий одной среды. У каждой приведённой ниже корневой конфигурации есть собственные переменные и существующий бакет с отчётами. Оба корректных удалённых состояния уже существуют в backend environment-team-state с управлением версиями.

cd /home/labex/project/environment-states
cat dev/terraform.tfvars
cat preview/terraform.tfvars

Входные значения задают имена isolated-dev-reports и isolated-preview-reports. Корневой каталог или файл переменных не изолирует состояние автоматически: бакет и ключ backend выбирают сопоставление, которое будет использовать Terraform.

Изучите ресурс, выбранный корневой конфигурацией preview:

terraform -chdir=preview state show aws_s3_bucket.reports

Сейчас она сообщает идентификатор бакета dev, хотя входные значения preview описывают другой бакет. Изучите её текущий выбор backend:

cat preview/environment.s3.tfbackend

Кэшированная конфигурация backend и файл выбирают environments/dev.tfstate. Нужные ключи уже существуют отдельно:

aws s3api \
  list-objects-v2 \
  --bucket environment-team-state \
  --prefix environments/

Убедитесь, что существуют и environments/dev.tfstate, и environments/preview.tfstate. AWS View также показывает оба хранилища отчётов; разверните их объекты report.txt, чтобы увидеть разные исходные данные.

Изучите небезопасный план preview, не применяя его:

terraform -chdir=preview plan

Он пытается согласовать входные значения preview с сопоставлением dev и может предложить замену не того бакета. Не применяйте его. Другое значение переменной не является указанием взять под управление состояние другой среды.

Выбор существующего состояния preview без копирования состояния

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

Оставьте файл dev без изменений. Исправьте выбор бакета и ключа preview:

cat > preview/environment.s3.tfbackend <<'HCL'
bucket       = "environment-team-state"
key          = "environments/preview.tfstate"
region       = "us-east-1"
use_lockfile = true
HCL

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

terraform -chdir=preview init \
  -reconfigure \
  -backend-config=backend-connection.hcl \
  -backend-config=environment.s3.tfbackend

Не используйте здесь -migrate-state или -force-copy. Копирование выбранного состояния dev в корректный ключ preview перезаписало бы запись управления preview вместо её выбора.

terraform -chdir=preview state show aws_s3_bucket.reports
terraform -chdir=preview plan

Ожидайте идентификатор isolated-preview-reports и No changes. Независимо проверьте dev:

terraform -chdir=dev state show aws_s3_bucket.reports
terraform -chdir=dev plan

Dev по-прежнему выбирает isolated-dev-reports, также с No changes. Оба корректных ключа и оба исходных отчёта должны остаться нетронутыми; это выбор среды, а не восстановление повреждённого состояния.

Подтверждение того, что изменение preview остаётся в preview

На этом шаге измените только ревизию preview после установления её правильной привязки. terraform.tfvars передаёт значения объявленных переменных этой корневой конфигурации; исходная конфигурация и адрес ресурса могут оставаться одинаковыми в разных средах.

cat > preview/terraform.tfvars <<'HCL'
bucket_name = "isolated-preview-reports"
environment = "preview"
revision = "two"
HCL

Изучите план preview:

terraform -chdir=preview plan -out=preview.tfplan

Ожидайте 0 to add, 1 to change, 0 to destroy; изменение должно затрагивать только тег ревизии preview. Примените сохранённый план из той же корневой конфигурации:

terraform -chdir=preview apply preview.tfplan

Изучите текущие теги каждой среды:

aws s3api \
  get-bucket-tagging \
  --bucket isolated-preview-reports

У preview должны быть Environment=preview и Revision=two.

aws s3api \
  get-bucket-tagging \
  --bucket isolated-dev-reports

У dev по-прежнему должны быть Environment=dev и Revision=one. Прочитайте оба исходных отчёта:

aws s3 \
  cp s3://isolated-preview-reports/report.txt -
aws s3 \
  cp s3://isolated-dev-reports/report.txt -

Ожидайте preview daily report и dev daily report. Фоновая проверка также сравнивает исходные байты состояния dev, обе версии объектов и сопоставления ресурсов в обоих ключах backend.

terraform -chdir=preview plan
terraform -chdir=dev plan

Обе корневые конфигурации должны сообщить No changes. Оставьте оба хранилища отчётов и их backend владельцам. Имена каталогов, ключи for_each и переменные Terraform не заменяют явную изоляцию состояния; другая рабочая копия dev должна намеренно выбирать тот же ключ dev, тогда как preview должна выбирать собственный ключ.

Резюме

Вы отличили рабочие копии от сред, выбрали существующее состояние с помощью перенастройки backend и доказали, что обновление только preview оставило ресурсы, данные и состояние dev без изменений.