Запуск приложения с начальной настройкой

Введение

Работающий экземпляр полезен только тогда, когда его приложение правильно инициализировано. Вы используете Terraform, чтобы прочитать подготовленный AMI приложения, запустить экземпляр EC2 в предоставленной сети и настроить приложение через User Data.

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

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

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

Чтение AMI и запуск приложения

На этом шаге вы свяжете подготовленный AMI, сетевые входные значения и User Data с ресурсом EC2 в Terraform, а затем проверите ответ инициализированного приложения.

Откройте Terminal и AWS View. Эталонный сервер уже работает. Сеть приложения готова, но application-server пока нет. Эта лабораторная работа не использует VM или ресурсы предыдущей работы.

Перейдите в рабочий каталог и изучите подготовленные входные значения:

cd /home/labex/project/application-launch
cat terraform.tfvars.json

Эти значения определяют предоставленные AMI, подсеть и группу безопасности. Сеть уже назначает публичные IP при запуске, имеет маршрут в интернет и разрешает клиенту User доступ на порт приложения 8081. Terraform подготовлен для среды курса; личные учётные данные не нужны.

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

aws ec2 \
  describe-images \
  --filters Name=name,Values=report-server-ubuntu-2204 \
  --query 'Images[].{Image:ImageId,Name:Name,Architecture:Architecture}'

Имя — report-server-ubuntu-2204, архитектура — x86_64, а идентификатор совпадает с входным значением ami_id. Источник данных Terraform читает существующий объект; ресурс управляет жизненным циклом объекта. Вы прочитаете этот AMI с помощью data.aws_ami.application, затем создадите экземпляр с помощью aws_instance.application.

Создайте application.tf. Внешний heredoc с разделителем в кавычках записывает HCL без подстановок оболочки. Внутри HCL ${...} подставляет результат выражения Terraform, а jsonencode преобразует сообщение в корректный JSON. Внутренний heredoc CONFIG с разделителем в кавычках записывает этот JSON в конфигурацию подготовленного приложения, когда User Data выполняются в новой гостевой системе.

cat > application.tf <<'HCL'
data "aws_ami" "application" {
  most_recent = true
  filter {
    name   = "image-id"
    values = [var.ami_id]
  }
}

resource "aws_instance" "application" {
  ami                    = data.aws_ami.application.id
  instance_type          = "t3.micro"
  key_name               = "report-key"
  subnet_id              = var.subnet_id
  vpc_security_group_ids = [var.security_group_id]

  user_data_replace_on_change = true
  user_data = <<-SCRIPT
    #!/bin/bash
    set -eu
    cat > /etc/report-app/config.json <<'CONFIG'
    ${jsonencode({ message = var.message })}
    CONFIG
  SCRIPT

  tags = {
    Name = "application-server"
  }
}

output "instance_id" {
  value = aws_instance.application.id
}

output "image_id" {
  value = data.aws_ami.application.id
}
HCL

Экземпляр ссылается на источник данных AMI, а не на скопированный идентификатор образа. Предоставленные входные значения подсети и группы подключают его к подготовленной сети. User Data выполняются при первой загрузке для настройки приложения; это не команда интерактивного входа. Входное значение message по умолчанию — Terraform report application. user_data_replace_on_change делает последующие изменения стартовой конфигурации явной заменой экземпляра; это поведение выпуска рассматривается в одной из следующих лабораторных работ.

Инициализируйте, отформатируйте и проверьте конфигурацию:

terraform init
terraform fmt
terraform validate

Если init сообщает Incomplete lock file information for providers, речь идёт о контрольных суммах для других платформ. Эта подготовленная VM использует linux_amd64; продолжайте после успешного завершения инициализации и валидации.

Изучите план. Он читает предоставленный AMI и предлагает создать один экземпляр EC2. Он не должен заменять эталонный сервер или создавать новый AMI.

terraform plan

Примените изменения и введите yes в ответ на запрос:

terraform apply

Сохраните и выведите полученные идентификаторы экземпляра и образа:

INSTANCE_ID=$(terraform output -raw instance_id)
echo "$INSTANCE_ID"
IMAGE_ID=$(terraform output -raw image_id)
echo "$IMAGE_ID"

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

aws ec2 \
  describe-instances \
  --instance-ids "$INSTANCE_ID" \
  --query 'Reservations[].Instances[].{ID:InstanceId,State:State.Name,Image:ImageId,Subnet:SubnetId,Groups:SecurityGroups[].GroupId,PublicIP:PublicIpAddress}'

В AWS View выберите application-server, User · 198.51.100.10 и Application · 8081, затем нажмите Send request. Ожидайте Connected · 200 и Terraform report application. Фактический ответ приложения показывает, что стартовая конфигурация дошла до рабочей нагрузки; одного running для подтверждения этого результата недостаточно.

Пример контрольной точки: AWS View показывает работающее приложение и его фактическое сообщение после инициализации. Идентификаторы ресурсов и адреса различаются в каждой VM.

Изучите сопоставление Terraform и подтвердите согласованность:

terraform state list
terraform plan

Состояние содержит источник данных AMI и ресурс экземпляра; план сообщает No changes.

Удаление экземпляра с сохранением предоставленной инфраструктуры

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

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

terraform plan -destroy

Ожидайте удаление одного управляемого экземпляра. Затем выполните удаление и введите yes:

terraform destroy

Запросите тот же идентификатор экземпляра. Его состояние должно быть terminated; неудачный запрос не доказывает завершение работы экземпляра.

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

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

aws ec2 \
  describe-images \
  --image-ids "$IMAGE_ID" \
  --query 'Images[].{Image:ImageId,Name:Name}'

Проверьте оставшееся состояние:

terraform state list

Управляемого ресурса приложения быть не должно. В AWS View завершённый экземпляр больше нельзя выбрать как работающую цель. Выберите reference-server, источник User и порт 8081 и отправьте запрос. Ответ по-прежнему должен быть Connected · 200 с Reference application.

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

Резюме

Вы разобрались в различии между источником данных AMI и ресурсом EC2, подключили предоставленные сетевые входные значения, инициализировали приложение через User Data и проверили его фактический ответ. Вы подтвердили план без изменений и удалили только управляемый экземпляр, сохранив образ, сеть и эталонное приложение.