Parametriza un almacén privado de informes

AWSBeginner
Practicar Ahora

Introducción

Tu equipo necesita almacenes de informes de desarrollo y de vista previa con contenido diferente. Reutilizarás una configuración, seguirás las referencias del bucket al objeto y demostrarás que dos configuraciones raíz independientes gestionan recursos de AWS distintos.

Parte del primer laboratorio de Terraform en AWS y de tus conocimientos de variables y valores de salida. Las herramientas, el acceso y la conexión del proveedor ya están preparados; no se reutilizan recursos de una VM anterior.

Relación con las certificaciones

Certificación Tarea del examen Práctica
Cloud Practitioner (CLF-C02) Tarea 3.1 Usar definiciones de infraestructura repetibles y consultas operativas de recursos.
Developer – Associate (DVA-C02) Tarea 3.3, habilidad 3.3.4 Práctica básica de despliegue de una definición de infraestructura.
DevOps Engineer – Professional (DOP-C02) Tarea 2.1 Práctica básica de gestión de recursos mediante una definición de IaC.

Vista conceptual de los recursos de este laboratorio y de los límites de lo que debe conservarse.

Despliega el almacén de desarrollo

En este paso, usarás variables de entrada y una referencia a un recurso para crear un almacén de informes de desarrollo a partir de una configuración.

Las dos configuraciones raíz preparadas, report-dev y report-preview, comienzan vacías salvo por el archivo de conexión del proveedor. Cada configuración raíz mantendrá su propio estado local. Esto es distinto de cambiar las entradas en una sola configuración raíz: esta sigue gestionando los recursos ya registrados en su estado.

Entra en la configuración raíz de desarrollo y crea la plantilla de recursos. Las variables environment y report son entradas de tipo cadena. ${var.environment} inserta el nombre del entorno en el nombre del bucket. El argumento bucket del objeto hace referencia al ID del recurso de bucket, por lo que Terraform puede descubrir la dependencia y crear primero el bucket. content_type indica a los lectores cómo interpretar los bytes.

cd /home/labex/project/report-dev
cat > main.tf <<'EOF'
variable "environment" { type = string }
variable "report" { type = string }

resource "aws_s3_bucket" "reports" {
  bucket = "terraform-reports-${var.environment}"
  tags = {
    Project     = "TerraformReports"
    Environment = var.environment
  }
}

resource "aws_s3_object" "report" {
  bucket       = aws_s3_bucket.reports.id
  key          = "reports/current.csv"
  content      = var.report
  content_type = "text/csv"
}

output "bucket_name" { value = aws_s3_bucket.reports.id }
output "report_key" { value = aws_s3_object.report.key }
EOF

Crea un archivo de variables para este entorno. La secuencia de escape \n representa un salto de línea en la cadena del informe. Mantener separados los valores permite reutilizar la misma plantilla de recursos.

cat > dev.tfvars <<'EOF'
environment = "dev"
report      = "orders,12\n"
EOF

Inicializa, valida y revisa esta configuración raíz. -var-file selecciona el archivo de valores; no selecciona un estado diferente.

terraform init
terraform validate
terraform plan -var-file=dev.tfvars

Deben añadirse dos recursos: el bucket y su objeto de informe. Aplica las mismas entradas e introduce yes cuando se solicite:

terraform apply -var-file=dev.tfvars

Los valores de salida identifican el bucket y la clave del objeto. Guarda y muestra esos valores mediante $(...), que captura la salida de un comando. -raw muestra una salida de tipo cadena sin las comillas de Terraform.

BUCKET=$(terraform output -raw bucket_name)
echo "$BUCKET"
KEY=$(terraform output -raw report_key)
echo "$KEY"

Lee el informe realmente almacenado a través de AWS, en lugar de considerar un valor de salida o una entrada del estado como prueba de los datos. La respuesta incluye ContentType: text/csv; el archivo de destino contiene los bytes.

aws s3api \
  get-object \
  --bucket "$BUCKET" \
  --key "$KEY" \
  dev-downloaded.csv
cat dev-downloaded.csv

Debes ver orders,12. AWS View también permite desplegar reports/current.csv dentro de terraform-reports-dev. Deja sin cambios el informe de referencia independiente del equipo. AWS View después del despliegue: el almacenamiento gestionado aparece junto al informe de referencia que se conserva.

Reutiliza la plantilla con un estado independiente

En este paso, desplegarás la misma plantilla con las entradas de vista previa y conservarás el almacén de desarrollo.

Copia únicamente la plantilla de recursos en la configuración raíz de vista previa preparada. En este ejercicio, copia solo main.tf, porque cada configuración raíz preparada se inicializará por separado. No clones terraform.tfstate ni el directorio .terraform/ inicializado para crear otro entorno: pueden arrastrar la correspondencia original de recursos o backend. El archivo de bloqueo de dependencias .terraform.lock.hcl es diferente: registra versiones del proveedor y sumas de comprobación, puede compartirse o incluirse en commits junto con la configuración y no contiene correspondencias de recursos de un entorno. La configuración raíz de vista previa ya tiene su propio archivo de conexión del proveedor.

cp /home/labex/project/report-dev/main.tf /home/labex/project/report-preview/main.tf
cd /home/labex/project/report-preview
cat > preview.tfvars <<'EOF'
environment = "preview"
report      = "orders,25\n"
EOF

Inicializa esta configuración raíz y revisa el plan de vista previa:

terraform init
terraform plan -var-file=preview.tfvars

De nuevo deben añadirse dos recursos, con terraform-reports-preview como nombre del bucket. Una eliminación inesperada del bucket de desarrollo indicaría que has reutilizado el estado equivocado. Aplica los cambios e introduce yes:

terraform apply -var-file=preview.tfvars

Lee el valor de salida y el informe de vista previa. La entrada del entorno cambia el nombre y la etiqueta; la entrada del informe cambia los bytes realmente almacenados.

BUCKET=$(terraform output -raw bucket_name)
echo "$BUCKET"
aws s3api \
  get-object \
  --bucket "$BUCKET" \
  --key reports/current.csv \
  preview-downloaded.csv
cat preview-downloaded.csv

Debes ver orders,25. Compara los valores de salida y las listas del estado de ambas configuraciones raíz con la opción global -chdir de Terraform, que ejecuta el comando en la configuración raíz indicada sin cambiar el directorio de tu shell:

terraform -chdir=/home/labex/project/report-dev output bucket_name
terraform -chdir=/home/labex/project/report-dev state list
terraform -chdir=/home/labex/project/report-preview output bucket_name
terraform -chdir=/home/labex/project/report-preview state list

Ambas configuraciones raíz tienen direcciones como aws_s3_bucket.reports, pero cada una corresponde a un bucket de AWS diferente. Confirma que los datos de desarrollo siguen intactos:

aws s3api \
  get-object \
  --bucket terraform-reports-dev \
  --key reports/current.csv \
  dev-retained.csv
cat dev-retained.csv

Debes ver orders,12. Son estados locales independientes, no espacios de trabajo ni un backend compartido. La documentación de variables de entrada de Terraform explica con más detalle la selección de archivos de variables. AWS View muestra los dos almacenes de informes gestionados e independientes junto a la referencia del equipo que se conserva.

Elimina ambos almacenes gestionados

En este paso, destruirás los recursos de cada configuración raíz sin eliminar el informe de referencia del equipo.

Cada configuración raíz necesita sus propias entradas durante la destrucción. Revisa el plan de eliminación de desarrollo y, después, ejecuta la destrucción e introduce yes. El objeto se elimina antes que su bucket porque Terraform conoce su dependencia.

terraform -chdir=/home/labex/project/report-dev plan -destroy -var-file=dev.tfvars
terraform -chdir=/home/labex/project/report-dev destroy -var-file=dev.tfvars

Ahora elimina únicamente los recursos de la configuración raíz de vista previa y confirma de nuevo con yes:

terraform -chdir=/home/labex/project/report-preview destroy -var-file=preview.tfvars

Cada destrucción informa de dos recursos eliminados. Comprueba que ambas correspondencias estén vacías y que el informe de referencia ajeno siga existiendo:

terraform -chdir=/home/labex/project/report-dev state list
terraform -chdir=/home/labex/project/report-preview state list
aws s3api \
  list-buckets \
  --query 'Buckets[].Name'
aws s3api \
  head-object \
  --bucket team-reference-reports \
  --key keep.txt \
  --query ContentLength

Solo queda el bucket de referencia. Un listado autenticado obtenido correctamente demuestra la ausencia de los otros buckets; un fallo de acceso o de red no lo haría. Conserva las credenciales preparadas hasta que termine la comprobación final.

Resumen

Has reutilizado una plantilla de bucket y objeto con dos archivos de variables, leído los bytes reales de los informes y su Content-Type, mantenido independiente el estado de cada configuración raíz y eliminado únicamente tus dos entornos.