Повторное использование и изменение развёртывания приложения

Введение

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

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

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

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

Изучение интерфейса модуля и применение обновления

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

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

Изучите корневой вызов и небольшой интерфейс модуля:

cd /home/labex/project/application-releases
cat application.tf
cat modules/application/variables.tf
cat modules/application/outputs.tf
cat modules/application/main.tf
terraform state list
ORIGINAL_ID=$(terraform output -raw instance_id)
echo "$ORIGINAL_ID"
REPORT_BUCKET=$(terraform output -raw report_bucket)
echo "$REPORT_BUCKET"

source = "./modules/application" выбирает каталог локального модуля. Вызов передаёт подготовленные входные данные инфраструктуры, а также message и release_label. Дочерний модуль создаёт ресурс EC2, а его выходное значение предоставляет фактический идентификатор экземпляра через корневое выходное значение. Поэтому адреса в состоянии начинаются с module.application.

Модуль сопоставляет release_label с тегом ReleaseNote. Он передаёт message в User Data и включает user_data_replace_on_change. Вы измените входные значения вызывающей конфигурации, сохранив эту предоставленную реализацию. Оставьте все три файла в modules/application/ без изменений и используйте этот предоставленный локальный модуль. Вносите изменения в корневой вызов.

В AWS View выберите application-server, User · 198.51.100.10, Application · 8081 и Health, затем нажмите Send request. Ожидайте Connected · 200 и Application release one. Выберите Local report file и отправьте запрос снова: подготовленный экземпляр содержит local,existing-record. Выберите Private report, чтобы прочитать отдельный отчёт S3 — period,total / Q1,320.

Измените только входное значение тега с initial на reviewed. Это перезаписывает небольшой корневой вызов, сохраняя все ссылки на инфраструктуру и стартовое сообщение:

cat > application.tf <<'HCL'
module "application" {
  source = "./modules/application"
  ami_id = var.ami_id
  subnet_id = var.subnet_id
  security_group_id = var.security_group_id
  profile_name = var.profile_name
  report_bucket = var.report_bucket
  message = "Application release one"
  release_label = "reviewed"
}
output "instance_id" { value = module.application.instance_id }
output "image_id" { value = module.application.image_id }
output "report_bucket" { value = var.report_bucket }
HCL
terraform fmt
terraform validate
terraform plan

Изучите обновление на месте тега экземпляра модуля без создания или удаления экземпляра. Примените изменения и введите yes:

terraform apply

Сравните фактический идентификатор и тег в сервисе:

echo "$ORIGINAL_ID"
terraform output -raw instance_id
aws ec2 \
  describe-instances \
  --instance-ids "$ORIGINAL_ID" \
  --query 'Reservations[].Instances[].{ID:InstanceId,State:State.Name,Tags:Tags}'

Идентификатор не изменился, а ReleaseNote равен reviewed. В AWS View отправьте запросы Health и Local report file тому же экземпляру. Его сообщение по-прежнему Application release one, а существующая локальная запись сохраняется. Обновление тега не запускает стартовую инициализацию повторно.

terraform plan

Ожидайте No changes.

Проверка и применение замены из-за стартовой конфигурации

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

Сообщение — часть User Data. Настройка user_data_replace_on_change этого модуля делает изменение стартовой конфигурации явной заменой экземпляра. Существующая локальная запись принадлежит файловой системе старого экземпляра; отчёт S3 принадлежит отдельному предоставленному хранилищу.

Измените сообщение вызова и сохраните план:

sed -i 's/Application release one/Application release two/' application.tf
terraform fmt
terraform validate
terraform plan -out=release.tfplan
terraform show release.tfplan

Изучите замену экземпляра -/+ и изменённые User Data. План не должен удалять предоставленные сеть, роль, профиль, образ, бакет или эталонное приложение. release.tfplan сохраняет проверенный план для следующей команды.

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

terraform apply release.tfplan

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

NEW_ID=$(terraform output -raw instance_id)
echo "$ORIGINAL_ID"
echo "$NEW_ID"
aws ec2 \
  describe-instances \
  --instance-ids "$ORIGINAL_ID" "$NEW_ID" \
  --query 'Reservations[].Instances[].{ID:InstanceId,State:State.Name,Image:ImageId}'

Идентификаторы различаются: исходный экземпляр — terminated, а новый — running на том же подготовленном AMI. Сопоставляйте идентификаторы, не полагаясь на порядок строк.

В AWS View выберите работающую запись application-server и отправьте Health. Ожидайте Connected · 200 и Application release two. Старый завершённый экземпляр больше нельзя выбрать как работающую цель.

Отправьте Local report file. Теперь содержимое — local,initialized, созданное User Data в новом экземпляре. Локальная запись старого экземпляра не сохранилась при замене. Затем отправьте Private report: внешний отчёт S3 по-прежнему возвращает Connected · 200 с period,total / Q1,320. Отправьте Unrelated private object и ожидайте Connected · 403 с Access denied.

Наконец выберите reference-server, User, порт 8081 и Health, затем отправьте запрос. Он по-прежнему должен возвращать Connected · 200 и Reference application.

terraform plan

Ожидайте No changes. Новый экземпляр управляется модулем, а внешние данные и эталонная среда остаются нетронутыми.

Удаление рабочей нагрузки модуля с сохранением зависимостей

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

Запишите идентификатор образа перед удалением управляемых ресурсов корневой конфигурации:

IMAGE_ID=$(terraform output -raw image_id)
echo "$IMAGE_ID"
terraform plan -destroy

Ожидайте удаление одного управляемого экземпляра. Источник данных AMI читает существующий образ; сеть, профиль, роль и бакет переданы в модуль как предоставленные входные данные. Выполните удаление и введите yes:

terraform destroy

Запросите фактическое завершённое состояние заменяющего экземпляра и изучите оставшееся состояние:

aws ec2 \
  describe-instances \
  --instance-ids "$NEW_ID" \
  --query 'Reservations[].Instances[].{ID:InstanceId,State:State.Name}'
terraform state list

Ожидайте terminated и отсутствие управляемого экземпляра в состоянии. Предоставленные образ и профиль должны по-прежнему существовать:

aws ec2 describe-images --image-ids "$IMAGE_ID" --query 'Images[].{ID:ImageId,Name:Name}'
aws iam \
  get-instance-profile \
  --instance-profile-name supplied-application-reader \
  --query 'InstanceProfile.{Name:InstanceProfileName,Roles:Roles[].RoleName}'

Используйте оператора Terminal для чтения сохранённого отчёта S3. Это проверяет сохранность внешних данных; собственный ограниченный доступ рабочей нагрузки был проверен до удаления.

aws s3api get-object --bucket "$REPORT_BUCKET" --key report.csv /tmp/g5-retained-report.csv
cat /tmp/g5-retained-report.csv

Его байты остаются period,total / Q1,320. В AWS View выберите reference-server, User, порт 8081 и Health, затем отправьте запрос. Ожидайте Connected · 200 с Reference application.

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

Резюме

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