Reutiliza y cambia un despliegue de aplicación

Introducción

Un despliegue de aplicación puede cambiar sin que cada cambio sustituya su instancia. Usarás un módulo local suministrado, revisarás una actualización de etiqueta que conserva la carga de trabajo y publicarás después una configuración de arranque nueva que la sustituye. La aplicación lee su informe desde almacenamiento externo suministrado.

Este laboratorio presupone conocimientos básicos de invocaciones de módulos, planes y estado de Terraform, además de los laboratorios anteriores de EC2 y roles de cargas de trabajo. Un entorno nuevo proporciona el despliegue inicial, la red, la AMI, el rol y perfil, los informes privados y la aplicación de referencia. Cambiarás la invocación del módulo y observarás la identidad de los recursos, los archivos locales y los datos externos en cada etapa.

Relación con las certificaciones

Vista general del laboratorio

Lee la interfaz del módulo y aplica una actualización

En este paso, leerás las entradas y salidas del módulo suministrado, cambiarás su entrada de etiqueta de versión y comprobarás que la instancia existente y el archivo local permanezcan intactos.

AWS View, en la parte superior, observa los mismos recursos que Terminal y envía solicitudes reales a la carga de trabajo. El despliegue del módulo ya está en ejecución. El rol y perfil suministrados conceden únicamente la lectura del informe requerido; la red, el rol y el bucket de informes quedan fuera de la gestión de esta configuración raíz.

Inspecciona la invocación raíz y la pequeña interfaz del 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" selecciona el directorio del módulo local. La invocación pasa las entradas de infraestructura preparadas junto con message y release_label. El módulo hijo crea el recurso EC2 y su salida expone el ID real de instancia mediante la salida raíz. Por eso las direcciones del estado comienzan por module.application.

El módulo asigna release_label a la etiqueta ReleaseNote. Incorpora message a User Data y habilita user_data_replace_on_change. Cambiarás las entradas de quien invoca el módulo conservando esta implementación suministrada. Mantén sin cambios los tres archivos de modules/application/ y usa ese módulo local suministrado. Realiza tus cambios en la invocación raíz.

En AWS View, selecciona application-server, User · 198.51.100.10, Application · 8081 y Health y haz clic en Send request. Debes ver Connected · 200 y Application release one. Elige Local report file y vuelve a enviar: la instancia preparada contiene local,existing-record. Elige Private report para leer el informe independiente de S3, period,total / Q1,320.

Cambia únicamente la entrada de etiqueta de initial a reviewed. Esto reescribe la pequeña invocación raíz conservando todas las referencias de infraestructura y el mensaje de arranque:

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

Revisa una actualización en el mismo recurso de la etiqueta de la instancia del módulo, sin crear ni destruir la instancia. Aplica los cambios e introduce yes:

terraform apply

Compara el ID real y la etiqueta 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}'

El ID no ha cambiado y ReleaseNote es reviewed. En AWS View, envía solicitudes Health y Local report file a la misma instancia. Su mensaje sigue siendo Application release one y su registro local existente se conserva. Una actualización de etiqueta no vuelve a ejecutar la inicialización de arranque.

terraform plan

Debes ver No changes.

Revisa y aplica la sustitución por cambio de configuración de arranque

En este paso, cambiarás el mensaje de arranque, inspeccionarás un plan guardado de sustitución y comprobarás la nueva carga de trabajo conservando el informe externo.

El mensaje forma parte de User Data. El ajuste user_data_replace_on_change de este módulo hace que un cambio de configuración de arranque implique una sustitución explícita de la instancia. El registro local existente pertenece al sistema de archivos de la instancia anterior; el informe de S3 pertenece a un almacenamiento independiente suministrado.

Cambia el mensaje de la invocación y guarda el plan:

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

Revisa la sustitución -/+ de la instancia y el cambio de User Data. El plan no debe destruir la red, el rol, el perfil, la imagen, el bucket ni la aplicación de referencia suministrados. release.tfplan guarda el plan revisado para el siguiente comando.

Aplica ese plan guardado:

terraform apply release.tfplan

Aplicar un plan guardado no solicita otro yes; el comando aplica las acciones guardadas. Espera a que termine y compara después las dos identidades reales de instancia:

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

Los ID son diferentes: la instancia original está terminated y la nueva está running con la misma AMI preparada. Compara los ID en lugar de depender del orden de las filas.

En AWS View, selecciona la entrada application-server en ejecución y envía Health. Debes ver Connected · 200 y Application release two. La instancia anterior terminada ya no se puede seleccionar como destino en ejecución.

Envía Local report file. Su contenido es ahora local,initialized, creado por User Data en la nueva instancia. La sustitución no ha conservado el registro local de la instancia anterior. Después, envía Private report: el informe externo de S3 sigue devolviendo Connected · 200 con period,total / Q1,320. Envía Unrelated private object y debes ver Connected · 403 con Access denied.

Por último, selecciona reference-server, User, el puerto 8081 y Health y envía una solicitud. Debe seguir devolviendo Connected · 200 y Reference application.

terraform plan

Debes ver No changes. El módulo gestiona la instancia nueva, mientras los datos externos y el entorno de referencia permanecen intactos.

Destruye la carga de trabajo del módulo y conserva sus dependencias

En este paso, eliminarás la instancia de sustitución gestionada, conservando la infraestructura suministrada, el rol de la carga de trabajo y los datos externos de informes.

Registra el ID de la imagen antes de destruir los recursos gestionados de la configuración raíz:

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

Debe destruirse una instancia gestionada. La fuente de datos de AMI lee una imagen existente; la red, el perfil, el rol y el bucket se pasaron al módulo como entradas suministradas. Aplica la eliminación e introduce yes:

terraform destroy

Consulta el estado nativo de terminación de la instancia de sustitución e inspecciona el estado restante:

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

Debes ver terminated y ninguna instancia gestionada restante en el estado. La imagen y el perfil suministrados deben seguir existiendo:

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

Usa el operador de Terminal para leer el informe de S3 conservado. Esto comprueba la conservación de datos externos; el acceso limitado de la propia carga de trabajo se verificó antes de la destrucción.

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

Sus bytes siguen siendo period,total / Q1,320. En AWS View, selecciona reference-server, User, el puerto 8081 y Health y envía una solicitud. Debes ver Connected · 200 con Reference application.

Conserva los archivos raíz y del módulo para revisarlos. El HCL conservado propondría una instancia nueva en un plan ordinario posterior; la limpieza exige la eliminación nativa de la carga de trabajo gestionada, no un futuro plan vacío.

Resumen

Has usado las entradas y salidas de un módulo suministrado para actualizar una carga de trabajo existente y publicar una sustitución. Has revisado el impacto en los recursos y los datos, aplicado un plan guardado, distinguido los archivos locales de la instancia de los informes externos conservados y limpiado únicamente la carga de trabajo gestionada por el módulo.