Inicie uma aplicação com inicialização automatizada

AWSBeginner
Pratique Agora

Introdução

Uma instância em execução só é útil quando sua aplicação foi inicializada corretamente. Você usará o Terraform para ler uma AMI de aplicação preparada, iniciar uma instância EC2 na rede fornecida e configurar a aplicação por meio de User Data.

Você deve conhecer variáveis e referências a recursos do Terraform, roteamento de sub-redes públicas, grupos de segurança e os fundamentos da inicialização de instâncias EC2. Este novo ambiente fornece a AMI, o par de chaves, a rede e uma aplicação de referência separada. Você criará e removerá sua própria instância de aplicação.

Relação com certificações

Certificação Tarefa do exame Prática
Cloud Practitioner (CLF-C02) Tarefa 3.1 Provisionar uma aplicação EC2 inicializada por meio de infraestrutura como código e inspecionar seu estado implantado com a AWS CLI.

Visão geral do laboratório

Visão conceitual: o Terraform lê uma AMI existente, cria uma instância EC2 e fornece User Data que altera a resposta da aplicação.

Leia uma AMI e inicie a aplicação

Nesta etapa, você conectará uma AMI preparada, entradas de rede e User Data a um recurso EC2 do Terraform e, em seguida, verificará a resposta da aplicação inicializada.

Abra o Terminal e o AWS View. O servidor de referência já está em execução. A rede da aplicação está pronta, mas ainda não existe um application-server. Este laboratório não reutiliza a VM nem os recursos de um laboratório anterior.

Entre no diretório de trabalho e inspecione seus valores de entrada preparados:

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

Esses valores identificam a AMI, a sub-rede e o grupo de segurança fornecidos. A rede já atribui IPs públicos na inicialização, tem uma rota para a internet e permite o cliente User na porta 8081 da aplicação. O Terraform está preparado para o ambiente do curso; não são necessárias credenciais pessoais.

Localize a imagem de aplicação fornecida por meio de uma consulta independente à AWS. Uma AMI descreve a imagem usada quando uma instância é criada; ler uma AMI existente não cria uma nova imagem.

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

O nome é report-server-ubuntu-2204, sua arquitetura é x86_64 e seu ID corresponde à entrada ami_id. Uma fonte de dados do Terraform lê um objeto existente; um recurso gerencia o ciclo de vida de um objeto. Você lerá esta AMI com data.aws_ami.application e criará uma instância com aws_instance.application.

Crie application.tf. O heredoc externo com delimitador entre aspas escreve HCL sem expansão pelo shell. Dentro do HCL, ${...} interpola uma expressão do Terraform, e jsonencode converte a mensagem em JSON válido. O heredoc interno CONFIG, com delimitador entre aspas, escreve esse JSON na configuração da aplicação preparada quando User Data é executado na nova instância convidada.

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

A instância faz referência à fonte de dados da AMI, em vez de usar um ID de imagem copiado. As entradas de sub-rede e grupo fornecidas a conectam à rede preparada. User Data é executado durante a primeira inicialização para configurar a aplicação; não é um comando de login interativo. O valor padrão da entrada message é Terraform report application. user_data_replace_on_change torna as alterações posteriores da configuração de inicialização substituições explícitas; você explorará esse comportamento de lançamento em um laboratório posterior.

Inicialize, formate e valide:

terraform init
terraform fmt
terraform validate

Se init informar Incomplete lock file information for providers, a mensagem descreve somas de verificação para outras plataformas. Esta VM preparada usa linux_amd64; continue depois que a inicialização e a validação forem concluídas com sucesso.

Revise o plano. Ele lê a AMI fornecida e propõe criar uma instância EC2. Não deve substituir o servidor de referência nem criar uma nova AMI.

terraform plan

Aplique e digite yes quando solicitado:

terraform apply

Salve e exiba os IDs resultantes da instância e da imagem:

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

Consulte a instância de forma independente. Confira seu estado de execução, imagem, sub-rede e grupo de segurança em relação às entradas preparadas.

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}'

No AWS View, selecione application-server, User · 198.51.100.10 e Application · 8081 e clique em Send request. Espere Connected · 200 e Terraform report application. A resposta efetiva da aplicação demonstra que a configuração de inicialização chegou à carga de trabalho; running, por si só, não comprovaria esse resultado.

A aplicação inicializada responde por meio de sua rede preparada.

Exemplo de ponto de verificação: o AWS View mostra a aplicação em execução e sua mensagem efetivamente inicializada. Os IDs e endereços dos recursos variam em cada VM.

Inspecione o mapeamento do Terraform e confirme a convergência:

terraform state list
terraform plan

O estado contém a fonte de dados da AMI e o recurso de instância; o plano informa No changes.

Remova a instância e preserve a infraestrutura fornecida

Nesta etapa, você destruirá apenas a instância de aplicação gerenciada pelo Terraform, preservando sua imagem de origem, a rede preparada e a aplicação de referência.

Uma fonte de dados não é responsável pelo ciclo de vida da imagem que lê. A VPC, a sub-rede, a rota, o grupo de segurança e o par de chaves também foram fornecidos fora deste estado. Revise o escopo de exclusão antes de aprová-lo:

terraform plan -destroy

Espere uma instância gerenciada a destruir. Em seguida, execute a exclusão e digite yes:

terraform destroy

Consulte o mesmo ID de instância. Seu estado deve ser terminated; uma solicitação com falha não comprova o encerramento.

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

A imagem preparada ainda deve existir com seu ID original:

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

Verifique o estado restante:

terraform state list

Não deve haver nenhum recurso gerenciado da aplicação. No AWS View, a instância encerrada deixa de ser um destino em execução selecionável. Selecione reference-server, a origem User e a porta 8081 e envie uma solicitação. Sua resposta ainda deve ser Connected · 200 com Reference application.

Mantenha os arquivos HCL para revisão. A configuração preservada proporia uma nova instância em um plano comum posterior; isso não significa que a operação de destruição falhou.

Resumo

Você distinguiu uma fonte de dados de AMI de um recurso EC2, conectou entradas de rede fornecidas, inicializou uma aplicação por meio de User Data e verificou sua resposta efetiva. Confirmou um plano sem alterações e removeu apenas a instância gerenciada, preservando a imagem, a rede e a aplicação de referência.