Перенос локального состояния в S3

Введение

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

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

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

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

Определение границы между локальным состоянием и backend

На этом шаге определите бизнес-бакет и отдельное место назначения для состояния. Предоставленная корневая конфигурация отчётов уже управляет migration-daily-reports; её локальное состояние независимо от финансового эталонного хранилища. Бакет maintenance-team-state с управлением версиями подготовлен платформенной командой, поэтому он существует до того, как эта корневая конфигурация начнёт его использовать.

cd /home/labex/project/state-migration
terraform state list
terraform state show aws_s3_bucket.reports

Убедитесь, что идентификатор удалённого бакета — migration-daily-reports. Backend хранит сопоставления ресурсов; он не является провайдером, который создаёт и читает ресурсы AWS. Настройки подключения провайдера и backend в этой среде подготовлены отдельно.

Сохраните закрытую локальную резервную копию перед изменением места хранения состояния. Перенаправление (>) записывает JSON состояния в файл; не размещайте состояние или планы в публичной системе контроля версий:

terraform state pull > local-before-migration.json
chmod 600 local-before-migration.json

Проверьте управление версиями backend и его изначально пустой список объектов:

aws s3api \
  get-bucket-versioning \
  --bucket maintenance-team-state

Ожидайте Status: Enabled.

aws s3api \
  list-objects-v2 \
  --bucket maintenance-team-state

Объекта состояния пока быть не должно. Важно выбирать пустое место назначения: миграция в ключ, уже принадлежащий другой среде, может перезаписать её запись управления. Оставьте migration-finance-reference нетронутым.

Перенос существующего сопоставления в нужный ключ S3

На этом шаге настройте удалённый backend и скопируйте существующее локальное сопоставление ресурсов в его пустое место назначения. Ключ — это имя объекта состояния внутри бакета backend; выбирайте его для одной конкретной среды.

Запишите частичное объявление backend S3. Настройки подключения предоставлены отдельно, а следующий файл задаст ваш выбор бакета и ключа:

cat > backend.tf <<'HCL'
terraform {
  backend "s3" {}
}
HCL

Создайте конфигурацию backend для конкретной среды. use_lockfile = true включает собственный файл блокировки S3 в Terraform для будущих операций записи:

cat > reports.s3.tfbackend <<'HCL'
bucket       = "maintenance-team-state"
key          = "reports/production.tfstate"
region       = "us-east-1"
use_lockfile = true
HCL

-migrate-state просит Terraform перенести существующее сопоставление в новый backend. Terraform спрашивает, нужно ли скопировать существующее состояние; конвейер с printf передаёт ответ yes. Выполняйте эту команду только после подтверждения, что целевой ключ этой лабораторной работы был пуст:

printf 'yes\n' | terraform init \
  -backend-config=backend-connection.hcl \
  -backend-config=reports.s3.tfbackend \
  -migrate-state

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

Изучите сопоставление из его нового места хранения:

terraform state show aws_s3_bucket.reports

Идентификатор ресурса по-прежнему должен быть migration-daily-reports. Убедитесь, что S3 теперь содержит фактический объект состояния:

aws s3api \
  head-object \
  --bucket maintenance-team-state \
  --key reports/production.tfstate

ETag и VersionId показывают сохранённый объект состояния. Одних этих метаданных недостаточно: фоновая проверка также читает его сопоставление ресурсов и сравнивает идентификатор и байты существующего отчёта.

terraform plan

Ожидайте No changes. Миграция состояния не должна заново создавать бизнес-бакет.

Наблюдение за новой версией удалённого состояния

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

Добавьте тег ревизии, сохранив имя бакета, владельца и настройку удаления без изменений:

cat > main.tf <<'HCL'
resource "aws_s3_bucket" "reports" {
  bucket        = "migration-daily-reports"
  force_destroy = false
  tags = { Owner = "reporting", Revision = "two" }
}
HCL

Изучите сохранённый план:

terraform plan -out=revision.tfplan

Ожидайте 0 to add, 1 to change, 0 to destroy. Примените только это обновление на месте:

terraform apply revision.tfplan

Изучите версии объекта backend:

aws s3api \
  list-object-versions \
  --bucket maintenance-team-state \
  --prefix reports/production.tfstate

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

aws s3 \
  cp s3://migration-daily-reports/report.txt -

Отчёт по-прежнему содержит Daily sales: 120 orders. AWS View показывает бизнес-хранилище, финансовое эталонное хранилище и backend как отдельные бакеты. Файлы состояния могут содержать конфиденциальные значения; изучайте только метаданные, необходимые для этого упражнения.

terraform plan

Ожидайте No changes. Проверьте это рабочее состояние перед началом отдельного этапа очистки.

Удаление бизнес-ресурсов с сохранением backend

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

force_destroy = false не позволяет Terraform незаметно опустошить бакет отчётов с управлением версиями. Перед удалением отчёта этой лабораторной работы явно определите его исходную версию. Подстановка команды сохраняет её идентификатор; выведите этот несекретный идентификатор:

VERSION_ID=$(aws s3api \
  head-object \
  --bucket migration-daily-reports \
  --key report.txt \
  --query VersionId \
  --output text)
echo "$VERSION_ID"

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

aws s3api \
  delete-object \
  --bucket migration-daily-reports \
  --key report.txt \
  --version-id "$VERSION_ID"
terraform destroy -auto-approve

-auto-approve пропускает запрос подтверждения; здесь используйте его только для единственного одноразового бизнес-бакета, который вы только что проверили. Ожидайте 1 destroyed.

Убедитесь, что его запись управления всё ещё существует в backend:

aws s3api \
  head-object \
  --bucket maintenance-team-state \
  --key reports/production.tfstate

Backend сохраняется и теперь содержит состояние без управляемых бизнес-ресурсов. Финансовое эталонное хранилище должно оставаться доступным. Удаление стека не удаляет хранилище, используемое его backend. Оставьте этот backend нетронутым для его владельца; не запускайте ещё один обычный apply, который заново создаст желаемый бизнес-бакет.

О конфигурации backend и собственных файлах блокировки читайте в документации по backend S3.

Резюме

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