Переименование ресурсов без повторного создания

Введение

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

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

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

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

Сравнение логических адресов и идентификатора удалённого ресурса

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

cd /home/labex/project/report-refactor
terraform state list

Исходный адрес — aws_s3_bucket.reports. Прочитайте идентификатор соответствующего удалённого ресурса:

terraform state show aws_s3_bucket.reports

id = "rename-daily-reports" определяет существующий бакет AWS. Переименование блока Terraform меняет его логический адрес, а не это имя бакета.

Прочитайте предоставленную конфигурацию и убедитесь в отсутствии исходных расхождений:

cat main.tf
terraform plan

Ожидайте No changes. В AWS View разверните отчёт в rename-daily-reports; оставьте rename-finance-reference без изменений. Прочитайте те же байты отчёта в Terminal:

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

Ожидайте Daily sales: 120 orders. Цель — изменить адрес, по которому управляется это хранилище, сохранив его идентификатор и исходную версию объекта.

Описание переименования с помощью блока moved

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

Here-document записывает конфигурацию между маркерами HCL в main.tf; > заменяет этот файл. Измените только локальную метку блока на report_archive, сохранив имя удалённого бакета и атрибуты без изменений:

cat > main.tf <<'HCL'
resource "aws_s3_bucket" "report_archive" {
  bucket        = "rename-daily-reports"
  force_destroy = false
  tags = { Owner = "reporting" }
}
HCL

Изучите результат до любого применения:

terraform plan

Без связи между адресами Terraform видит отсутствие старого адреса и новый адрес без записи в состоянии. Ожидайте 1 to add, 0 to change, 1 to destroy. Не применяйте этот план и не удаляйте отчёт, чтобы сделать удаление бакета возможным.

Блок moved объявляет связь между старым и новым адресами. В отличие от изменения имени бакета AWS, это фиксирует рефакторинг конфигурации. Поместите объявление в отдельный файл .tf; Terraform совместно читает все файлы .tf в этом корневом каталоге:

cat > moved.tf <<'HCL'
moved {
  from = aws_s3_bucket.reports
  to   = aws_s3_bucket.report_archive
}
HCL

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

terraform plan -out=rename.tfplan

Ожидайте aws_s3_bucket.reports has moved to aws_s3_bucket.report_archive и 0 to add, 0 to change, 0 to destroy. Запланированный адрес в состоянии меняется, а ресурс AWS не требует повторного создания. Храните объявление вместе с конфигурацией, чтобы более старые копии состояния тоже могли учитывать рефакторинг.

Применение миграции адреса и сохранение отчёта

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

terraform apply rename.tfplan

Сводка ресурсов должна показывать 0 added, 0 changed, 0 destroyed. Изучите полученное сопоставление:

terraform state list
terraform state show aws_s3_bucket.report_archive

В списке указан только новый адрес, а идентификатор его бакета остаётся rename-daily-reports. Проверьте фактический отчёт:

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

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

terraform plan

Ожидайте No changes. Независимая проверка также сравнивает исходный VersionId и соседнее хранилище и строит план текущей конфигурации в одноразовой копии. Сохраните оба рабочих отчёта нетронутыми для следующего специалиста по обслуживанию.

О роли сохраняемых объявлений moved при развитии модулей читайте в документации HashiCorp по рефакторингу ресурсов.

Резюме

Вы разобрались в различии между адресом Terraform и идентификатором ресурса AWS, отказались от разрушительного плана прямого переименования и применили объявление moved без повторного создания бакета или отчёта.