Передача существующего ресурса под управление

Введение

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

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

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

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

Изучение существующего хранилища и желаемой конфигурации

На этом шаге сравните ресурс, который уже существует в AWS, с конфигурацией, которой вы собираетесь управлять. AWS View над Terminal отображает те же ресурсы S3, которые читает ваш CLI. Разверните report.txt в карточке handover-daily-reports, чтобы изучить данные отчёта; finance-reference-reports принадлежит другой команде и должен остаться без изменений.

Адрес ресурса Terraform, например aws_s3_bucket.reports, определяет блок конфигурации. Имя бакета определяет удалённый ресурс AWS. Состояние хранит сопоставление между этими двумя идентификаторами. Один лишь файл конфигурации такого сопоставления не устанавливает.

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

cd /home/labex/project/report-storage
cat main.tf

Аргумент bucket выбирает handover-daily-reports. Значение Owner должно остаться reporting; новый тег ManagedBy будет отмечать передачу в управление. force_destroy = false не позволяет Terraform автоматически опустошать непустой бакет при последующем удалении. Это настройка поведения Terraform, отдельная от отчёта, хранящегося в бакете.

Изучите существующие теги:

aws s3api \
  get-bucket-tagging \
  --bucket handover-daily-reports

Изначально существует только Owner=reporting. Получите исходный отчёт в стандартный вывод, указав - в качестве назначения:

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

Ожидаемый отчёт:

Daily sales: 120 orders

Инициализируйте рабочий каталог. init устанавливает провайдер фиксированной версии для этой корневой конфигурации; бакет при этом не импортируется и не создаётся:

terraform init

Изучите предлагаемые действия, не применяя их:

terraform plan

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

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

Импорт существующего бакета и изучение различий

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

Выполните импорт, указав сначала адрес в конфигурации, а затем имя существующего бакета:

terraform import aws_s3_bucket.reports handover-daily-reports

Найдите сообщение Import successful!. Проверьте, какой адрес теперь находится под управлением:

terraform state list

Ожидаемый адрес:

aws_s3_bucket.reports

Прочитайте его атрибуты:

terraform state show aws_s3_bucket.reports

И id, и bucket должны указывать на handover-daily-reports. report.txt остаётся в S3; импорт бакета не передаёт объект под управление по отдельному адресу aws_s3_object. Финансовый бакет не должен появляться в состоянии этой корневой конфигурации.

Импорт не гарантирует, что план сразу окажется пустым. Некоторые настройки поступают от удалённого сервиса; другие, включая force_destroy, описывают собственное поведение Terraform и после импорта могут требовать согласования с конфигурацией. Такое различие не означает, что ваш отчёт повреждён.

Сохраните план для проверки. -out=handover.tfplan сохраняет запланированные действия, чтобы на следующем шаге можно было применить тот же проверенный план:

terraform plan -out=handover.tfplan

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

terraform show handover.tfplan

Ожидайте обновление на месте (~), добавление тега ManagedBy=Terraform и, возможно, приведение force_destroy к false. Сводка должна быть такой:

Plan: 0 to add, 1 to change, 0 to destroy.

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

Применение согласованных изменений и проверка сохранности

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

terraform apply handover.tfplan

Ожидайте Resources: 0 added, 1 changed, 0 destroyed. Теперь бакет находится под управлением, а тег передачи в управление соответствует конфигурации.

Прочитайте текущие теги, чтобы проверить результат в AWS:

aws s3api \
  get-bucket-tagging \
  --bucket handover-daily-reports

Должны присутствовать и Owner=reporting, и ManagedBy=Terraform; порядок тегов неважен.

Прочитайте отчёт ещё раз:

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

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

Проверьте согласованность текущей конфигурации, состояния и ресурса AWS после обновления сведений о нём:

terraform plan

Ожидаемый результат:

No changes. Your infrastructure matches the configuration.

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

Дополнительные сведения приведены в документации HashiCorp о процессе импорта через CLI.

Резюме

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