Una guía práctica para migrar Terraform State a GitLab CI/CD

Como profesional de software que maneja infraestructura como código (IaC), es probable que trabaje mucho con Terraformar . Al ayudar a nuevos clientes a usar IaC, es común simplificar las cosas, pero administrar un archivo de estado de Terraform es el primer desafío al que se enfrenta. Esencialmente, el estado de Terraform contiene información confidencial que el control de fuente no debe almacenar pero, al mismo tiempo, no se escalará si tiene varios usuarios trabajando en el mismo estado de Terraform. ¿La respuesta a eso? Backends.

Es importante tener en cuenta que podría almacenar ese archivo de estado en un depósito S3 y usar DynamoDB para administrar el estado de bloqueo. Sin embargo, este enfoque lo obligará a crear recursos adicionales, lo que lo convierte en una opción complicada, especialmente si el cliente usa GitLab. GitLab recientemente redujo la barrera de entrada a la integración de Terraform al proporcionar una forma de almacenar y administrar el estado de Terraform, así como una manera fácil de configurar un CI a su alrededor.

En esta publicación de blog, explicaremos qué es un archivo de estado de Terraform, cómo migrarlo a GitLab y configurar una canalización de CI para él. Puedes visitar nuestro repositorio aquí .

Tabla de contenido

• ¿Qué es el estado Terraform?
• Cómo hacer que GitLab administre el estado de Terraform
• Cómo hacer que GitLab ejecute su IaC a través de una canalización de CI
• Consejo adicional: Infracosto
• Conclusión

¿Qué es Terraform State?

Terraform registra cualquier información sobre la infraestructura definida en su código a través de un archivo de estado. Escrito en JSON, esencialmente registra un mapeo del código de Terraform a los recursos reales creados. A continuación se muestra un ejemplo de cómo se vería un terraform.tfstate.

Principalmente, cada vez que ejecute Terraform obtendrá el estado más reciente para su instancia EC2 y lo comparará con su configuración de Terraform para determinar qué cambios deben aplicarse.

 { "version": 4, "terraform_version": "0.12.0", "serial": 1, "lineage": "1f2087f9-4b3c-1b66-65db-8b78faafc6fb", "outputs": {}, "resources": [ { "mode": "managed", "type": "aws_instance", "name": "example", "provider": "provider.aws", "instances": [ { "schema_version": 1, "attributes": { "ami": "ami-0c55b159cbfafe1f0", "availability_zone": "us-west-2a", "id": "i-00a123a0accffffff", "instance_state": "running", "instance_type": "t2.micro", "(...)": "(truncated)" } } ] } ] }

De forma predeterminada, este terraform.tfstate se almacena localmente donde tiene sus archivos de Terraform, planifica y aplica sus cambios. Para un proyecto personal en el que solo está ejecutando algunas pruebas, está bien, pero no es la forma recomendada, he aquí por qué:

• Almacenado en una ubicación compartida: si hospedara este archivo de estado en su estación de trabajo local y tuviera que trabajar con otro ingeniero, las cosas se complicarían. Ambos deberán asegurarse de estar usando la última versión del estado y podrían encontrarse en condiciones de carrera si ejecutan un plan Terraform o lo solicitan al mismo tiempo.
• Proteja la información confidencial: un archivo de estado generado puede contener claves de cifrado y contraseñas de infraestructura. Sin embargo, los archivos de estado no están encriptados de forma predeterminada y almacenar información confidencial en texto sin formato es una mala idea.
• Bloqueo: la mayoría de los sistemas de control de versiones no admiten ninguna forma de bloqueo que impida que dos miembros del equipo ejecuten Terraform apply simultáneamente en el mismo archivo de estado. Esta es otra razón por la que no veremos un archivo de estado administrado por el control de código fuente.

‍

Cómo hacer que GitLab administre el estado de Terraform

Dado que Terraform se considera el estándar en el aprovisionamiento de infraestructura en la nube, ha pasado más o menos un año desde que GitLab comenzó a ofrecer una forma de almacenar y administrar su estado de Terraform. Por este motivo, queríamos compartir con usted el proceso de migración, ya que recientemente comenzamos a usar GitLab para administrar nuestro IaC.

Para este artículo, asumimos que está utilizando un estado local y tiene su estado administrado con un AWS S3 Bucket u otra solución de back-end.

En primer lugar, deberá cambiar su backend.tf para usar HTTP.

 terraform { backend "http" {} }

A continuación, deberá configurar 4 variables en su terminal:

• PROJECT_ID: puede encontrar esto fácilmente navegando a su repositorio en la página de descripción general del proyecto

__ __

‍

• TF_USERNAME: nombre de usuario de Gitlab que tiene acceso al repositorio en el que está trabajando.
• TF_PASSWORD: token de acceso generado a partir de su usuario de GitLab.
• TF_ADDRESS: URL del backend de estado remoto

 PROJECT_ID="28450092" TF_USERNAME="florianpialoux" TF_PASSWORD="123456789" TF_ADDRESS="https://gitlab.com/api/v4/projects/${PROJECT_ID}/terraform/state/aws-buckets"

Ahora puede ejecutar el comando de migración que moverá su estado de Terraform desde su ubicación anterior a GitLab con el siguiente comando:

 terraform init \ -migrate-state \ -backend-config=address=${TF_ADDRESS} \ -backend-config=lock_address=${TF_ADDRESS}/lock \ -backend-config=unlock_address=${TF_ADDRESS}/lock \ -backend-config=username=${TF_USERNAME} \ -backend-config=password=${TF_PASSWORD} \ -backend-config=lock_method=POST \ -backend-config=unlock_method=DELETE \ -backend-config=retry_wait_min=5

Deberá proporcionar una confirmación con un "sí" para que GitLab pueda comenzar a administrar su archivo de estado. Aquí hay un ejemplo de un estado local a GitLab:

__ __

Ejemplo s3 a GitLab

__ __

Ahora puede navegar a Infraestructura > Terraform desde la interfaz de GitLab y ver su estado:

__ __

Me di cuenta de que algunos de los archivos de estado que tenía de s3 estarán en blanco incluso después de usar el comando de estado de migración ejecutado anteriormente, en este caso, puede ejecutar esto:

 terraform state pull > aws-buckets.json

Copie y pegue el contenido del estado s3 y ejecute una inserción:

 terraform state push -lock=true aws-buckets.json

GitLab admite el control de versiones para su archivo de estado de Terraform, pero ver/restaurar versiones anteriores a través de WebUI requerirá que use un Plan Premium de GitLab . De lo contrario, deberá crear una API GraphQL pedido .

‍

Cómo hacer que GitLab ejecute su IaC a través de una canalización de CI

GitLab proporciona una imagen acoplable que contiene GitLab-Terraform, que es un script de envoltura delgado alrededor del binario oficial de Terraform. Como alternativa, podría utilizar el imagen acoplable oficial por Hashicorp. Puede encontrar más información sobre GitLab Terraform Image aquí .

Una vez que se ejecuta el trabajo de aplicación de terraformación, podrá ver cuándo se usó el estado y con qué canalización.

__ __

Obtenga más información sobre cómo se ve nuestro gitlab-ci.yml aquí . A continuación se muestran las variables que deberán definirse a nivel de proyecto:

__ __

Consejo adicional: Infracosto

Como habrás notado, mirando nuestro gitlab-ci.yaml agregamos Infracosto lo que nos permite tener más control sobre nuestra facturación en la nube, ya que le brinda una estimación de costos cada vez que define un nuevo recurso para su IaC. Para obtener más información sobre Infracost, puede consultar nuestro detallado artículo sobre lo que implica, y nuestro paso a paso guía sobre cómo integrarlo con Terraform.

Conclusión

Tener su estado de Terraform y CI ejecutándose en Gitlab es una excelente manera de seguir las mejores prácticas de GitOps. Ambos hacen una gran combinación para desarrollar e implementar IaC. Dado que es posible que la mayoría de ustedes ya esté usando GitLab para sus repositorios, se vuelve mucho más simple tener su IaC bajo un mismo techo y dejar que GitLab administre su estado de Terraform al admitir el cifrado en tránsito y en reposo, así como la creación de versiones, el bloqueo y el desbloqueo de la estado.