Asigna a cada entorno su propio estado

Introducción

Una configuración raíz de trabajo de vista previa selecciona el estado del entorno equivocado, aunque ambos entornos y sus objetos de estado válidos ya existen. Establece la relación correcta entre la configuración raíz y la clave, y realiza un cambio exclusivo de vista previa sin perjudicar a desarrollo.

Necesitas conocer los módulos locales, el estado remoto en S3 y los conceptos de bloqueo nativo de las unidades anteriores. Este entorno nuevo e independiente incluye ambos almacenes de informes y ambos estados; no necesitas una VM anterior ni una cuenta personal de AWS.

Relación con las certificaciones

Vista general del laboratorio

Identifica cada entorno antes de realizar cambios

En este paso, distingue dos entornos de dos copias de un mismo entorno. Cada configuración raíz siguiente tiene sus propias variables y su propio bucket de informes existente. Ambos estados remotos válidos ya existen en el backend con control de versiones environment-team-state.

cd /home/labex/project/environment-states
cat dev/terraform.tfvars
cat preview/terraform.tfvars

Las entradas indican los nombres isolated-dev-reports e isolated-preview-reports. Un directorio raíz o un archivo de variables no aísla automáticamente el estado: el bucket y la clave del backend seleccionan la correspondencia que utilizará Terraform.

Inspecciona el recurso seleccionado por la configuración raíz de vista previa:

terraform -chdir=preview state show aws_s3_bucket.reports

Actualmente muestra el ID del bucket de dev, aunque las entradas de vista previa describen otro bucket. Inspecciona su selección actual de backend:

cat preview/environment.s3.tfbackend

El backend almacenado en caché y el archivo seleccionan environments/dev.tfstate. Las claves previstas ya existen por separado:

aws s3api \
  list-objects-v2 \
  --bucket environment-team-state \
  --prefix environments/

Confirma que existen tanto environments/dev.tfstate como environments/preview.tfstate. AWS View también muestra ambos almacenes de informes; despliega sus objetos report.txt para ver los datos originales diferentes.

Inspecciona el plan inseguro de vista previa sin aplicarlo:

terraform -chdir=preview plan

Intenta conciliar las entradas de vista previa con la correspondencia de desarrollo y puede proponer sustituir el bucket equivocado. No lo apliques. Un valor de variable diferente no es una instrucción para asumir la gestión del estado de otro entorno.

Selecciona el estado existente de vista previa sin copiar el estado

En este paso, vuelve a vincular la configuración raíz de vista previa con su estado ya válido. La migración copia una correspondencia actual a otro backend. La reconfiguración descarta la selección de backend almacenada en caché e inicializa el backend existente solicitado sin copiar la correspondencia anterior.

Mantén sin cambios el archivo de desarrollo. Corrige el bucket y la clave elegidos para vista previa:

cat > preview/environment.s3.tfbackend <<'HCL'
bucket       = "environment-team-state"
key          = "environments/preview.tfstate"
region       = "us-east-1"
use_lockfile = true
HCL

Inicializa esa clave existente con -reconfigure. El archivo de conexión suministrado sigue estando separado de tu selección de entorno:

terraform -chdir=preview init \
  -reconfigure \
  -backend-config=backend-connection.hcl \
  -backend-config=environment.s3.tfbackend

No uses aquí -migrate-state ni -force-copy. Copiar el estado de desarrollo seleccionado en la clave válida de vista previa sobrescribiría el registro de gestión de vista previa, en lugar de seleccionarlo.

terraform -chdir=preview state show aws_s3_bucket.reports
terraform -chdir=preview plan

Debes ver el ID isolated-preview-reports y No changes. Comprueba desarrollo de forma independiente:

terraform -chdir=dev state show aws_s3_bucket.reports
terraform -chdir=dev plan

Desarrollo sigue seleccionando isolated-dev-reports, también con No changes. Ambas claves válidas y ambos informes originales deben permanecer intactos; esto es selección de entorno, no recuperación de un estado dañado.

Demuestra que un cambio de vista previa se limita a vista previa

En este paso, cambia únicamente la revisión de vista previa después de establecer su vinculación correcta. terraform.tfvars proporciona valores para las variables declaradas de esa configuración raíz; el código de configuración y la dirección del recurso pueden ser los mismos en los distintos entornos.

cat > preview/terraform.tfvars <<'HCL'
bucket_name = "isolated-preview-reports"
environment = "preview"
revision = "two"
HCL

Revisa el plan de vista previa:

terraform -chdir=preview plan -out=preview.tfplan

Debes ver 0 to add, 1 to change, 0 to destroy, afectando únicamente a la etiqueta de revisión de vista previa. Aplica el plan guardado desde esa misma configuración raíz:

terraform -chdir=preview apply preview.tfplan

Inspecciona las etiquetas actuales de cada entorno:

aws s3api \
  get-bucket-tagging \
  --bucket isolated-preview-reports

Vista previa debe tener Environment=preview y Revision=two.

aws s3api \
  get-bucket-tagging \
  --bucket isolated-dev-reports

Desarrollo debe seguir teniendo Environment=dev y Revision=one. Lee ambos informes originales:

aws s3 \
  cp s3://isolated-preview-reports/report.txt -
aws s3 \
  cp s3://isolated-dev-reports/report.txt -

Debes ver preview daily report y dev daily report. La comprobación en segundo plano también compara los bytes originales del estado de desarrollo, las versiones de ambos objetos y las correspondencias de recursos de las dos claves del backend.

terraform -chdir=preview plan
terraform -chdir=dev plan

Ambas configuraciones raíz deben indicar No changes. Conserva ambos almacenes de informes y su backend para sus propietarios. Los nombres de directorio, las claves de for_each y las variables de Terraform no sustituyen el aislamiento explícito del estado; otra copia de trabajo de desarrollo debe seleccionar intencionadamente la misma clave de desarrollo, mientras que vista previa debe seleccionar su propia clave.

Resumen

Has distinguido las copias de trabajo de los entornos, seleccionado un estado existente mediante la reconfiguración del backend y demostrado que una actualización exclusiva de vista previa deja sin cambios los recursos, los datos y el estado de desarrollo.