Rechaza la infraestructura no válida antes de planificar

Introducción

Tu equipo ya tiene almacenamiento de informes gestionado por Terraform. Antes de incorporar despliegues automatizados, necesitas una tarea que rechace las configuraciones con formato incorrecto o estructura no válida antes de llegar a la planificación.

Configurarás dos controles estáticos, observarás cómo cada uno detiene una tarea en ejecución y repararás la configuración. Ya debes conocer la configuración de Terraform, los planes y el estado, los fundamentos de Git y los códigos de salida del shell. El entorno preparado no requiere una cuenta personal de AWS.

Relación con las certificaciones

Añade comprobaciones antes del plan

En este paso, conectarás comprobaciones estáticas a una tarea secuencial suministrada. El bucket y el informe existentes forman parte de la infraestructura de apoyo: este laboratorio debe dejar sus datos y el estado de Terraform sin cambios.

Usa la interfaz Terminal. Entra en el repositorio Git suministrado y carga el entorno de sus herramientas. source aplica las variables preparadas al shell actual; no despliega infraestructura.

cd /home/labex/project/report-delivery
source environment.sh

Inspecciona la configuración del recurso y las etapas actuales de la tarea. cat muestra cada archivo para que puedas ver qué gestiona la tarea y qué ejecuta.

cat main.tf pipeline.json

El bucket tiene una etiqueta Purpose. Por ahora, la tarea solo tiene una etapa plan. Que un plan termine correctamente no demuestra por sí solo que antes se hayan ejecutado las comprobaciones de formato y estructura.

terraform fmt -check comprueba el formato canónico de Terraform sin reescribir los archivos. terraform validate comprueba si la configuración inicializada es coherente internamente, incluidos los atributos admitidos por los recursos. Ninguno de los dos demuestra que la configuración cumpla los requisitos del negocio; las aserciones de módulos se tratarán en el siguiente laboratorio.

El ejecutor suministrado asocia los nombres de las etapas con comandos fijos de Terraform y se detiene ante el primer error. Mantén run-job.py sin cambios: tu tarea es configurar pipeline.json, no reescribir el ejecutor suministrado. Las comprobaciones confirman que el punto de entrada utilizado coincide con el original suministrado antes de evaluar su comportamiento. Añade ambas comprobaciones antes de la planificación. El documento incrustado escribe en pipeline.json el JSON situado entre sus delimitadores; poner EOF entre comillas conserva literalmente su contenido.

cat > pipeline.json <<'EOF'
{"stages":["fmt","validate","plan"]}
EOF

Ejecuta la tarea con el intérprete estándar de Python. Este es un ejecutor local con fines didácticos; sus etapas ejecutan comandos estándar de Terraform.

python3 run-job.py

Debes ver [fmt] native exit 0, [validate] native exit 0 y [plan] native exit 0. El plan no indica cambios porque la infraestructura suministrada ya coincide con su configuración. Un error detiene las etapas posteriores. Un plan con cambios usa el código de salida nativo 2, que el ejecutor considera una vista previa correcta, nunca un permiso para aplicar los cambios.

Inspecciona tu cambio con Git. -- separa la ruta de las opciones del comando.

git diff -- pipeline.json

La comparación debe mostrar los dos controles nuevos antes de plan. Esta tarea no incluye ninguna etapa de aplicación.

Detén la tarea ante un error de formato

En este paso, introducirás una expresión HCL válida con un espaciado que no sigue el formato canónico y demostrarás que el control de formato detiene la tarea antes de la planificación.

Añade un pequeño bloque de salida al final del archivo. >> añade contenido al archivo existente. El espaciado compacto es intencionado; esta salida no gestiona ningún recurso nuevo.

cat >> main.tf <<'EOF'

output "format_probe" {value="spacing"}
EOF

Vuelve a ejecutar la tarea. Se espera que este comando falle; ese fallo es el resultado útil.

python3 run-job.py

La primera etapa indica el código de salida nativo 3 y muestra main.tf. La tarea imprime Job stopped; later stages did not run. No debe aparecer ninguna línea [validate] ni [plan]. El formato se puede corregir sin contactar con AWS.

Inspecciona los cambios de formato exactos que se proponen. -diff los muestra, mientras que -check deja el archivo sin cambios.

terraform fmt -check -diff

Este comando también devuelve intencionadamente un código de salida distinto de cero. Conserva el defecto de formato para la comprobación de este paso; lo repararás en el siguiente.

Distingue el formato de la validez

En este paso, repararás el formato y después introducirás un error diferente que solo detecta la validación estructural.

Primero, deja que Terraform reescriba el espaciado en el propio archivo. Ejecutar fmt sin -check realiza el cambio de formato.

terraform fmt

La salida muestra main.tf. Confirma que la configuración reparada supera la tarea.

python3 run-job.py

Deben ejecutarse todas las etapas. La salida adicional puede hacer que el plan devuelva el código de salida nativo 2; propone un cambio en una salida sin aplicarlo.

Ahora añade una referencia a un atributo que el recurso de bucket de S3 no exporta. Este bloque usa el formato canónico, por lo que puede superar el primer control.

cat >> main.tf <<'EOF'

output "missing" {
  value = aws_s3_bucket.reports.missing_attribute
}
EOF

Comprueba primero solo el formato.

terraform fmt -check

Devuelve cero sin mostrar ninguna salida. Después, ejecuta la tarea completa.

python3 run-job.py

El control de formato debe superarse y, a continuación, validate debe devolver el código de salida nativo 1 y un diagnóstico Unsupported attribute. No debe aparecer ninguna línea de la etapa de planificación. La expresión tiene el formato correcto, pero hace referencia a un atributo no admitido. Conserva este error para la comprobación del paso.

Repara la configuración y conserva el entorno

En este paso, restaurarás la configuración válida conocida del recurso, volverás a ejecutar la tarea con sus controles y comprobarás que el almacenamiento de informes no ha cambiado.

git restore -- main.tf restaura únicamente este archivo a partir del commit inicial del repositorio. Elimina las dos salidas experimentales y conserva los cambios independientes que has hecho en pipeline.json.

git restore -- main.tf

Vuelve a ejecutar la tarea completa.

python3 run-job.py

Las tres etapas deben devolver el código de salida nativo 0. El plan no debe indicar cambios. Superar las comprobaciones estáticas permite planificar; no aprueba ni aplica un despliegue.

Lee el informe directamente del almacenamiento. - envía su contenido a la salida estándar en lugar de guardar otra copia local.

aws s3   cp s3://delivery-gates-reports/report.csv -

Debes ver:

quarter,total
Q1,320

Inspecciona el informe vecino que este ejercicio debe conservar.

aws s3   cp s3://delivery-gates-neighbor/keep.txt -

Debe seguir diciendo preserve neighboring report. Revisa la comparación final de Git para confirmar que el cambio que conservas es la configuración de la canalización.

git diff -- main.tf pipeline.json

No destruyas ninguno de los dos buckets preparados: representan infraestructura existente que pertenece al equipo. La tarea no tiene ninguna etapa de despliegue ni de guardado de planes, por lo que no deja recursos nuevos en la nube ni artefactos de plan que debas limpiar. Los experimentos de salidas temporales se han eliminado al restaurar main.tf. Conserva tus controles de calidad para la comprobación final.

Resumen

Has creado una tarea secuencial de Terraform con comprobaciones de formato y validación estructural antes de la planificación. Has observado cómo un fallo de formato y otro independiente de atributo no admitido detenían las etapas posteriores y, después, has reparado la configuración y conservado los datos de los informes y el estado.

La validez estática es una capa de calidad. En el siguiente laboratorio, las aserciones ejecutables de módulos comprueban si una configuración válida produce el comportamiento previsto. Consulta las referencias oficiales de fmt y validate para conocer las comprobaciones utilizadas aquí.