Comprensión de los estados y los backends de Terraform

Uno de los conceptos más importantes de la infraestructura como código (IaC) es el concepto de estado. Los servicios de IaC mantienen el estado, lo que le permite declarar un recurso en un archivo de IaC sin tener que volver a crearlo cada vez que se implementa. Los archivos IaC documentan el estado de todos los recursos al final de una implementación para poder comparar ese estado con el estado objetivo, tal como se declara en la siguiente implementación. Por lo tanto, si el estado actual contiene un depósito de Amazon Simple Storage Service (Amazon S3) my-s3-bucket denominado y los cambios entrantes también contienen ese mismo depósito, el nuevo proceso aplicará todos los cambios encontrados en el depósito existente en lugar de intentar crear un depósito completamente nuevo.

En la siguiente tabla, se proporcionan ejemplos del proceso general de estado de la IaC.

Estado actual	Estado objetivo	Acción
No se ha nombrado ningún bucket de S3 my-s3-bucket	Nombre del bucket de S3 my-s3-bucket	Cree un depósito de S3 con el nombre my-s3-bucket
my-s3-bucketsin configurar el control de versiones del bucket	my-s3-bucketsin configurar el control de versiones de bucket	Sin acciones
my-s3-bucketsin configurar el control de versiones de bucket	my-s3-bucketcon el control de versiones de bucket configurado	my-s3-bucketConfigúrelo para tener el control de versiones en bucket
my-s3-bucketcon el control de versiones de bucket configurado	No se ha nombrado ningún bucket de S3 my-s3-bucket	Intento de borrarlo my-s3-bucket

Para entender las diferentes formas en que AWS CloudFormation Terraform rastrea el estado, es importante recordar la primera diferencia básica entre las dos herramientas: CloudFormation está alojada dentro de una y Terraform es esencialmente remota. Nube de AWS Este hecho permite CloudFormation mantener el estado internamente. Puedes ir a la CloudFormation consola y ver el historial de eventos de una pila determinada, pero el propio CloudFormation servicio hace cumplir las reglas estatales por ti.

Los tres modos en los que CloudFormation funciona un recurso determinado son CreateUpdate, yDelete. El modo actual se determina en función de lo que ocurrió en la última implementación y no se puede influir en él de otro modo. Quizás puedas actualizar CloudFormation los recursos manualmente para determinar el modo que se determine, pero no puedes pasarle un comando CloudFormation que diga «Para este recurso, opera en Create modo».

Como Terraform no está alojado en el Nube de AWS, el proceso de mantenimiento del estado debe ser más configurable. Por esta razón, el estado de Terraform se mantiene dentro de un archivo de estado generado automáticamente. Un desarrollador de Terraform tiene que tratar con el estado de forma mucho más directa de lo que lo haría con él. CloudFormation Lo importante es recordar que el seguimiento del estado es igual de importante para ambas herramientas.

De forma predeterminada, el archivo de estado de Terraform se almacena localmente en el nivel superior del directorio principal en el que se ejecuta la pila de Terraform. Si ejecuta el terraform apply comando desde su entorno de desarrollo local, verá cómo Terraform genera el archivo terraform.tfstate que utiliza para mantener el estado en tiempo real. Para bien o para mal, esto te da mucho más control sobre el estado en Terraform del que tienes en él. CloudFormation Si bien nunca debe actualizar el archivo de estado directamente, hay varios comandos CLI de Terraform que puede ejecutar para actualizar el estado entre las implementaciones. Por ejemplo, la importación de terraform te permite añadir recursos creados fuera de Terraform a tu pila de despliegues. Por el contrario, puedes eliminar un recurso del estado ejecutando terraform state rm.

El hecho de que Terraform necesite almacenar su estado en algún lugar lleva a otro concepto que no se aplica CloudFormation: el backend. Un backend de Terraform es el lugar en el que una pila de Terraform almacena su archivo de estado tras su implementación. También es donde espera encontrar el archivo de estado cuando comience una nueva implementación. Al ejecutar la pila de forma local, como se ha descrito anteriormente, puede guardar una copia del estado de Terraform en el directorio local de nivel superior. Esto se conoce como backend local.

Cuando se desarrolla para un entorno de integración e implementación continuas (CI/CD), el archivo de estado local generalmente se incluye en el archivo.gitignore para mantenerlo fuera del control de versiones. Por lo tanto, no hay ningún archivo estatal local en la canalización. Para que funcione correctamente, esa fase de la canalización debe encontrar el archivo de estado correcto en alguna parte.Esta es la razón por la que los archivos de configuración de Terraform suelen contener un bloque de backend. El bloque de fondo indica a la pila de Terraform que necesita buscar el archivo de estado en otro lugar que no sea su propio directorio de nivel superior.

Un backend de Terraform se puede ubicar prácticamente en cualquier lugar: un bucket de Amazon S3, un punto final de API o incluso un espacio de trabajo remoto de Terraform. El siguiente es un ejemplo de un backend de Terraform almacenado en un bucket de Amazon S3.

terraform {
  backend "s3" {
    bucket = "my-s3-bucket"
    key    = "state-file-folder"
    region = "us-east-1"
  }
}

Para evitar almacenar información confidencial en los archivos de configuración de Terraform, los backends también admiten configuraciones parciales. En el ejemplo anterior, las credenciales necesarias para acceder al depósito no están presentes en la configuración. Las credenciales se pueden obtener a partir de variables de entorno o mediante otros medios, como AWS Secrets Manager. Para obtener más información, consulte Proteger los datos confidenciales mediante AWS Secrets Manager HashiCorp Terraform.

Un escenario de backend común es un backend local que se utiliza en su entorno local con fines de prueba. El archivo terraform.tfstate se incluye en el archivo.gitignore para que no se envíe al repositorio remoto. Luego, cada entorno de la canalización de CI/CD mantendría su propio backend. En este escenario, es posible que varios desarrolladores tengan acceso a este estado remoto, por lo que conviene proteger la integridad del archivo de estado. Si varias implementaciones se están ejecutando y actualizando el estado al mismo tiempo, el archivo de estado podría dañarse. Por este motivo, en situaciones con backends no locales, el archivo de estado suele estar bloqueado durante la implementación.