Traslada el estado local a S3

Introducción

La persona responsable del mantenimiento necesita una ubicación compartida para las correspondencias de recursos de un conjunto de infraestructura en funcionamiento. Migra un estado local a un backend de S3 independiente con control de versiones, conservando el informe existente, y observa después el historial del estado y el ciclo de vida independiente del backend.

Debes conocer el estado de Terraform, la importación, los planes guardados y las versiones de objetos de S3. Todos los recursos de este laboratorio se preparan en este entorno nuevo; no necesitas un estado anterior ni una cuenta personal de AWS.

Relación con las certificaciones

Vista general del laboratorio

Establece el límite entre el estado local y el backend

En este paso, identifica el bucket de negocio y el destino independiente para el estado. La configuración raíz de informes suministrada ya gestiona migration-daily-reports; su estado local es independiente de la referencia de finanzas. El equipo de plataforma prepara el bucket con control de versiones maintenance-team-state para que exista antes de que esta configuración raíz empiece a utilizarlo.

cd /home/labex/project/state-migration
terraform state list
terraform state show aws_s3_bucket.reports

Confirma que el ID del bucket remoto es migration-daily-reports. Un backend almacena correspondencias de recursos; no es el proveedor que crea y lee los recursos de AWS. Los ajustes de conexión del proveedor y del backend se preparan por separado en este entorno.

Guarda una copia de seguridad local privada antes de cambiar dónde se almacena el estado. La redirección (>) escribe el JSON del estado en un archivo; no incluyas archivos de estado ni planes en un sistema público de control de versiones:

terraform state pull > local-before-migration.json
chmod 600 local-before-migration.json

Comprueba el control de versiones del backend y su inventario inicialmente vacío:

aws s3api \
  get-bucket-versioning \
  --bucket maintenance-team-state

Debes ver Status: Enabled.

aws s3api \
  list-objects-v2 \
  --bucket maintenance-team-state

Todavía no debe existir ningún objeto de estado. Es importante elegir un destino vacío: migrar a una clave que ya pertenece a otro entorno puede sobrescribir su registro de gestión. Deja intacto migration-finance-reference.

Migra la correspondencia existente a la clave de S3 prevista

En este paso, configura un backend remoto y copia la correspondencia local de recursos existente a su destino vacío. Una clave es el nombre del objeto de estado dentro del bucket del backend; elígela para un entorno concreto.

Escribe una declaración parcial de backend de S3. Los ajustes de conexión se suministran por separado y el siguiente archivo especifica el bucket y la clave que has elegido:

cat > backend.tf <<'HCL'
terraform {
  backend "s3" {}
}
HCL

Crea la configuración de backend específica del entorno. use_lockfile = true activa el archivo de bloqueo nativo de S3 de Terraform para futuras escrituras:

cat > reports.s3.tfbackend <<'HCL'
bucket       = "maintenance-team-state"
key          = "reports/production.tfstate"
region       = "us-east-1"
use_lockfile = true
HCL

-migrate-state solicita a Terraform que traslade la correspondencia existente al nuevo backend. Terraform pregunta si debe copiar el estado existente; la canalización con printf proporciona la respuesta yes. Ejecuta esto solo después de confirmar que la clave de destino de este laboratorio estaba vacía:

printf 'yes\n' | terraform init \
  -backend-config=backend-connection.hcl \
  -backend-config=reports.s3.tfbackend \
  -migrate-state

La configuración del backend de S3 y la inicialización deben completarse correctamente. No uses la migración como forma de cambiar a un entorno que ya existe: seleccionar un estado existente es una operación diferente que se tratará más adelante en este curso.

Inspecciona la correspondencia desde su nueva ubicación:

terraform state show aws_s3_bucket.reports

El ID del recurso debe seguir siendo migration-daily-reports. Confirma que S3 contiene ahora el objeto de estado real:

aws s3api \
  head-object \
  --bucket maintenance-team-state \
  --key reports/production.tfstate

Un ETag y un VersionId muestran el objeto de estado almacenado. Esos metadatos por sí solos no bastan: la comprobación en segundo plano también lee su correspondencia de recursos y compara la identidad y los bytes del informe existente.

terraform plan

Debes ver No changes. Migrar el estado no debe volver a crear el bucket de negocio.

Observa una nueva versión del estado remoto

En este paso, realiza una actualización de configuración revisada y observa el historial de estado resultante. El control de versiones conserva los objetos de estado anteriores; este laboratorio observa el historial, sin restaurar un estado dañado.

Añade una etiqueta de revisión manteniendo sin cambios el nombre del bucket, el propietario y el ajuste de destrucción:

cat > main.tf <<'HCL'
resource "aws_s3_bucket" "reports" {
  bucket        = "migration-daily-reports"
  force_destroy = false
  tags = { Owner = "reporting", Revision = "two" }
}
HCL

Revisa un plan guardado:

terraform plan -out=revision.tfplan

Debes ver 0 to add, 1 to change, 0 to destroy. Aplica únicamente esa actualización en el mismo recurso:

terraform apply revision.tfplan

Inspecciona las versiones del objeto del backend:

aws s3api \
  list-object-versions \
  --bucket maintenance-team-state \
  --prefix reports/production.tfstate

Después de la migración y la actualización deben existir al menos dos versiones del estado. Describen el historial de gestión; son distintas de las versiones del informe de negocio en el otro bucket.

aws s3 \
  cp s3://migration-daily-reports/report.txt -

El informe sigue siendo Daily sales: 120 orders. AWS View muestra el negocio, la referencia de finanzas y el backend como buckets independientes. Los archivos de estado pueden contener valores sensibles; inspecciona únicamente los metadatos necesarios para este ejercicio.

terraform plan

Debes ver No changes. Verifica este estado en funcionamiento antes de empezar la fase de limpieza independiente.

Elimina los recursos de negocio y conserva el backend

En este paso, retira este conjunto desechable de recursos de negocio una vez superadas las comprobaciones de funcionamiento y conservación de datos. El backend del equipo de plataforma y la referencia de finanzas independiente quedan fuera del alcance de la eliminación.

force_destroy = false impide que Terraform vacíe silenciosamente el bucket de informes con control de versiones. Identifica expresamente la versión original del informe antes de eliminar el informe de este laboratorio. La sustitución de comandos guarda su ID; muestra ese identificador no secreto:

VERSION_ID=$(aws s3api \
  head-object \
  --bucket migration-daily-reports \
  --key report.txt \
  --query VersionId \
  --output text)
echo "$VERSION_ID"

Elimina exactamente esa versión desechable y, después, destruye el recurso de negocio. Estos comandos ponen fin intencionadamente a la disponibilidad del informe solo después de la comprobación de conservación del paso anterior:

aws s3api \
  delete-object \
  --bucket migration-daily-reports \
  --key report.txt \
  --version-id "$VERSION_ID"
terraform destroy -auto-approve

-auto-approve omite una solicitud de confirmación; úsalo aquí únicamente para el único bucket de negocio desechable que acabas de revisar. Debes ver 1 destroyed.

Confirma que su registro de gestión sigue existiendo en el backend:

aws s3api \
  head-object \
  --bucket maintenance-team-state \
  --key reports/production.tfstate

El backend se conserva y ahora contiene un estado sin recursos de negocio gestionados. La referencia de finanzas debe seguir disponible. Destruir un conjunto de recursos no elimina el almacenamiento utilizado por su backend. Deja ese backend intacto para su propietario; no vuelvas a ejecutar una aplicación normal de la configuración, que volvería a crear el bucket de negocio deseado.

Consulta la documentación del backend de S3 para conocer la configuración del backend y los archivos de bloqueo nativos.

Resumen

Has diferenciado las funciones del proveedor y del backend, guardado una copia de seguridad y migrado una correspondencia existente a S3, observado las versiones del estado y eliminado un conjunto de recursos de negocio sin borrar su backend de propiedad independiente.