Coordina dos directorios de trabajo de Terraform

Introducción

Dos responsables de mantenimiento tienen copias de trabajo del mismo entorno. Observa un proceso que escribe realmente en el estado compartido, un plan concurrente rechazado por su bloqueo nativo y una operación correcta desde el otro directorio después de la liberación normal del bloqueo.

Necesitas conocer el estado remoto en S3 y los planes y aplicaciones habituales de Terraform. Este entorno nuevo proporciona ambas copias de trabajo inicializadas, un cambio controlado con una duración determinada, almacenamiento de informes y una referencia de finanzas; no necesitas una VM anterior ni una cuenta personal de AWS.

Relación con las certificaciones

Vista general del laboratorio

Identifica dos copias de un mismo entorno

En este paso, comprueba que dos directorios de trabajo gestionan intencionadamente el mismo entorno. No son despliegues separados de desarrollo y vista previa: ambas configuraciones de backend seleccionan reports/shared.tfstate en coordination-team-state.

cd /home/labex/project/shared-state-operators
cat operator-a/shared.s3.tfbackend
cat operator-b/shared.s3.tfbackend

Ambas usan use_lockfile = true. Terraform crea un objeto de bloqueo nativo de S3 junto a este estado mientras opera un proceso de escritura, para que otro no actúe sobre una instantánea incompatible.

terraform -chdir=operator-a state show aws_s3_bucket.reports
terraform -chdir=operator-b state show aws_s3_bucket.reports

Ambas identifican coordinated-daily-reports. Lee su informe real y deja sin cambios la referencia de finanzas:

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

Debes ver Daily sales: 120 orders. Inspecciona el cambio controlado suministrado:

cat operator-a/pending-change.tf

Solo para este ejercicio, un recurso terraform_data pausa su creación durante 30 segundos mediante local-exec. Esa pausa permite observar el bloqueo de un proceso de escritura real. Las actualizaciones habituales de recursos también mantienen un bloqueo; una espera artificial no es una recomendación para despliegues de producción. Este cambio controlado del estado está presente en ambas configuraciones, pero no se ha aplicado.

Observa la contención real y la liberación normal

En este paso, ejecuta un proceso de escritura real y un plan concurrente desde el segundo directorio. Usa todo el bloque siguiente como una única operación para que las pausas de lectura no consuman el intervalo de observación.

& inicia el operador A en segundo plano; $! captura su ID de proceso. Su salida se dirige a un registro para que el error del segundo operador resulte legible. El bucle acotado espera al bloqueo real de S3, en lugar de suponer un tiempo de arranque fijo. La instrucción if permite inspeccionar el fallo esperado del plan y wait devuelve el estado real de finalización del proceso de escritura. Son dos procesos de Terraform independientes, aunque los inicies desde una misma Terminal.

terraform -chdir=operator-a apply -auto-approve > /tmp/operator-a.log 2>&1 &
WRITER_PID=$!
echo "$WRITER_PID"
for attempt in $(seq 1 60); do
  if aws s3api head-object \
    --bucket coordination-team-state \
    --key reports/shared.tfstate.tflock > /dev/null 2>&1; then
    break
  fi
  sleep 1
done
aws s3api get-object \
  --bucket coordination-team-state \
  --key reports/shared.tfstate.tflock \
  /tmp/current-lock.json
cat /tmp/current-lock.json
if terraform -chdir=operator-b plan -lock-timeout=0s; then
  echo 'Unexpected: the competing plan acquired the lock.'
  false
else
  PLAN_EXIT=$?
  echo "$PLAN_EXIT"
fi
wait "$WRITER_PID"
cat /tmp/operator-a.log

El plan concurrente debe terminar con el código 1 y Error acquiring the state lock. Un error de autenticación o conexión no demuestra contención. La información del bloqueo pertenece al proceso de escritura real; subir un archivo con el nombre del bloqueo no demostraría la coordinación entre procesos de escritura.

El operador A debe completar correctamente su creación controlada y liberar el bloqueo de forma normal. No desactives el bloqueo, no elimines el bloqueo de un proceso de escritura activo ni uses force-unlock para permitir que el segundo operador continúe. En AWS View, los almacenes de informes siguen disponibles en todo momento; el bloqueo coordina la gestión, no el acceso de lectura a los informes.

Continúa desde la otra copia de trabajo después de la liberación

En este paso, deja que el operador B acceda al backend normalmente una vez finalizado el proceso de escritura. La segunda copia de trabajo debe leer ahora el estado compartido actualizado, en lugar de crear por su cuenta otra copia de los recursos.

terraform -chdir=operator-b plan -lock-timeout=5s

Debes ver No changes. El mismo comando que estaba bloqueado durante la escritura ahora puede adquirir y liberar el bloqueo de forma normal.

Inspecciona el estado resultante desde ambos directorios:

terraform -chdir=operator-a state list
terraform -chdir=operator-b state list

Cada uno muestra aws_s3_bucket.reports y terraform_data.coordination. Se trata del mismo entorno y del mismo registro de gestión compartido, no de dos despliegues.

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

El texto original sigue disponible. Inspecciona el historial de versiones del estado:

aws s3api \
  list-object-versions \
  --bucket coordination-team-state \
  --prefix reports/shared.tfstate

El estado real tiene historial y no debe quedar ningún .tflock activo en el inventario actual de objetos. Las versiones históricas del bloqueo o los marcadores de eliminación no son un bloqueo de escritura activo.

terraform -chdir=operator-a plan

Aquí también debes ver No changes. Las comprobaciones en segundo plano distinguen la contención real entre procesos de Terraform de un bloqueo proporcionado manualmente y verifican las versiones originales de los informes, la liberación normal y el acceso correcto posterior. Deja el almacenamiento compartido y el backend para sus propietarios.

Resumen

Has distinguido dos copias de trabajo de un mismo entorno de entornos separados, observado contención real por un bloqueo nativo y continuado de forma segura después de la liberación normal del proceso de escritura, sin eliminar un bloqueo activo.