Reutilize e altere uma implantação de aplicação

Introdução

Uma implantação de aplicação pode mudar sem que toda alteração substitua sua instância. Você usará um módulo local fornecido, revisará uma atualização de tag que preserva a carga de trabalho e publicará uma nova configuração de inicialização que a substitui. A aplicação lê seu relatório de um armazenamento externo fornecido.

Este laboratório pressupõe conhecimentos básicos de chamadas de módulos, planos e estado do Terraform, além dos laboratórios anteriores de EC2 e funções de cargas de trabalho. Um novo ambiente fornece a implantação inicial, a rede, a AMI, a função e o perfil, os relatórios privados e a aplicação de referência. Você alterará a chamada do módulo e observará a identidade dos recursos, os arquivos locais e os dados externos em cada etapa.

Relação com certificações

Visão geral do laboratório

Leia a interface do módulo e aplique uma atualização

Nesta etapa, você lerá as entradas e saídas do módulo fornecido, alterará sua entrada de tag de release e verificará se a instância e o arquivo local existentes permanecem intactos.

O AWS View acima observa os mesmos recursos que o Terminal e envia solicitações efetivas à carga de trabalho. A implantação do módulo já está em execução. A função e o perfil fornecidos concedem apenas a leitura exigida do relatório; a rede, a função e o bucket de relatórios permanecem fora da responsabilidade deste diretório raiz.

Inspecione a chamada do diretório raiz e a pequena interface do módulo:

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" seleciona o diretório local do módulo. A chamada passa entradas da infraestrutura preparada, além de message e release_label. O módulo filho cria o recurso EC2, e sua saída expõe o ID efetivo da instância por meio da saída do módulo raiz. Portanto, os endereços no estado começam com module.application.

O módulo mapeia release_label para a tag ReleaseNote. Ele mapeia message para User Data e habilita user_data_replace_on_change. Você alterará as entradas do chamador, preservando esta implementação fornecida. Mantenha os três arquivos em modules/application/ inalterados e use esse módulo local fornecido. Faça suas alterações na chamada do módulo raiz.

No AWS View, selecione application-server, User · 198.51.100.10, Application · 8081 e Health e clique em Send request. Espere Connected · 200 e Application release one. Escolha Local report file e envie novamente: a instância preparada contém local,existing-record. Escolha Private report para ler o relatório S3 separado, period,total / Q1,320.

Altere apenas a entrada de tag de initial para reviewed. Isso reescreve a pequena chamada do módulo raiz, mantendo todas as referências de infraestrutura e a mensagem de inicialização:

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

Revise uma atualização no próprio recurso da tag da instância do módulo, sem criação nem destruição de instância. Aplique e digite yes:

terraform apply

Compare o ID efetivo e a tag nativa:

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

O ID permanece inalterado, e ReleaseNote é reviewed. No AWS View, envie solicitações Health e Local report file à mesma instância. Sua mensagem continua sendo Application release one, e seu registro local existente permanece. Uma atualização de tag não executa novamente a inicialização.

terraform plan

Espere No changes.

Revise e aplique a substituição pela configuração de inicialização

Nesta etapa, você alterará a mensagem de inicialização, inspecionará um plano salvo de substituição e verificará a nova carga de trabalho, preservando o relatório externo.

A mensagem faz parte de User Data. A configuração user_data_replace_on_change deste módulo torna uma alteração de configuração de inicialização uma substituição explícita de instância. O registro local existente pertence ao sistema de arquivos da instância antiga; o relatório S3 pertence a um armazenamento separado fornecido.

Altere a mensagem da chamada e salve o plano:

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

Revise a substituição -/+ da instância e o User Data alterado. O plano não deve destruir a rede, a função, o perfil, a imagem, o bucket nem a aplicação de referência fornecidos. release.tfplan salva o plano revisado para o próximo comando.

Aplique esse plano salvo:

terraform apply release.tfplan

Aplicar um plano salvo não solicita outro yes; o comando aplica as ações salvas. Aguarde a conclusão e compare as duas identidades efetivas de instância:

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

Os IDs são diferentes: a original está terminated, e a nova está running na mesma AMI preparada. Compare os IDs, em vez de depender da ordem das linhas.

No AWS View, selecione a entrada application-server em execução e envie Health. Espere Connected · 200 e Application release two. A instância antiga encerrada não é mais um destino em execução selecionável.

Envie Local report file. Seu conteúdo agora é local,initialized, criado por User Data na nova instância. O registro local da instância antiga não foi preservado pela substituição. Em seguida, envie Private report: o relatório S3 externo ainda retorna Connected · 200 com period,total / Q1,320. Envie Unrelated private object e espere Connected · 403 com Access denied.

Por fim, selecione reference-server, User, a porta 8081 e Health e envie uma solicitação. Ele ainda deve retornar Connected · 200 e Reference application.

terraform plan

Espere No changes. A nova instância é gerenciada pelo módulo, enquanto os dados externos e o ambiente de referência permanecem intactos.

Destrua a carga de trabalho do módulo e preserve suas dependências

Nesta etapa, você removerá a instância substituta gerenciada, preservando a infraestrutura fornecida, a função da carga de trabalho e os dados externos dos relatórios.

Registre o ID da imagem antes de destruir os recursos gerenciados do diretório raiz:

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

Espere uma instância gerenciada a destruir. A fonte de dados da AMI lê uma imagem existente; a rede, o perfil, a função e o bucket foram passados ao módulo como entradas fornecidas. Aplique a exclusão e digite yes:

terraform destroy

Consulte o estado nativo de encerramento da instância substituta e inspecione o estado restante:

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

Espere terminated e nenhuma instância gerenciada restante no estado. A imagem e o perfil fornecidos ainda devem existir:

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

Use o operador do Terminal para ler o relatório S3 preservado. Isso verifica a preservação dos dados externos; o acesso de escopo restrito da própria carga de trabalho foi verificado antes da destruição.

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

Seus bytes continuam sendo period,total / Q1,320. No AWS View, selecione reference-server, User, a porta 8081 e Health e envie uma solicitação. Espere Connected · 200 com Reference application.

Mantenha os arquivos do módulo raiz e do módulo filho para revisão. O HCL preservado proporia uma nova instância em um plano comum posterior; a limpeza exige a exclusão nativa da carga de trabalho gerenciada, não um plano futuro vazio.

Resumo

Você usou as entradas e saídas de um módulo fornecido para atualizar uma carga de trabalho existente e publicar uma substituta. Revisou o impacto sobre recursos e dados, aplicou um plano salvo, distinguiu arquivos locais da instância de relatórios externos preservados e limpou apenas a carga de trabalho sob responsabilidade do módulo.