Configurar el estado remoto de Terraform en GitHub Actions resuelve el problema de que tu workflow no recuerde los recursos previamente desplegados. Si ya automatizaste tus despliegues con CI/CD pero notas que Terraform intenta recrear todo en cada ejecución, este flujo te muestra cómo conectar tu pipeline con una Storage Account de Azure para preservar el estado entre corridas.

Por qué necesitas un estado remoto en tu pipeline

Cuando una GitHub Action ejecuta Terraform sin un backend remoto, cada corrida arranca sin memoria de lo que ya existe. Esto provoca conflictos al recrear recursos que ya están desplegados o, peor, destruir lo que acabas de crear.

La solución es guardar el archivo tfstate en una cuenta de almacenamiento de Azure, igual que se hace en entorno local, pero ahora autenticando desde el workflow.

¿Qué es el estado remoto en Terraform? Es un archivo tfstate almacenado fuera de tu máquina, en un servicio como Azure Blob Storage, que registra todos los recursos administrados por Terraform para que cualquier ejecución sepa qué existe y qué falta crear.

Cómo preparas el contenedor y el SAS token en Azure

Necesitas dos piezas para que el backend funcione: un contenedor dentro de tu Storage Account y un SAS token válido. [01:00]

Dentro del grupo de recursos donde tienes tu cuenta de almacenamiento, ve a la sección Containers y crea uno nuevo con el nombre que vas a referenciar desde el archivo backend.tf. En este caso, el contenedor se llama githubactions-state.

Para generar el SAS token, sigue estos pasos:

• Entra a la sección de seguridad de tu Storage Account.
• Selecciona el tipo de recurso blob.
• Habilita acceso a contenedor y a objeto.
• Define una fecha de expiración, por ejemplo una semana.
• Genera el token y cópialo de inmediato.

Ese token es la llave que tu GitHub Action usará para escribir el estado.

Cómo conectas el backend con tu workflow YAML

Con el contenedor y el token listos, toca llevarlos a GitHub. [02:30]

Dónde guardas el SAS token de forma segura

Entra al repositorio en GitHub y navega a Settings, luego a la categoría de seguridad, Secrets and variables, Actions. Ahí selecciona new repository secret, nómbralo sas_token y pega el valor que copiaste de Azure.

Guardar el token como secreto evita exponerlo en el código y permite referenciarlo desde cualquier paso del pipeline.

Cómo modificas el archivo backend.tf

En tu Visual Studio Code agrega el archivo backend.tf junto a tu main.tf. El contenido es el mismo que usaste para el estado remoto local, pero ajusta el nombre del contenedor a githubactions-state para que apunte al espacio recién creado.

Cómo pasas el token al comando terraform init

En el archivo YAML del workflow, en el paso de terraform init, agrega el flag -backend-config con el valor del secreto:

yaml

• name: Terraform Init run: terraform init -backend-config="sas_token=${{ secrets.sas_token }}"

Con esto, el backend de Azure RM queda configurado al inicio de cada ejecución y Terraform sabe dónde leer y escribir el estado.

Cómo validas que el estado remoto esté funcionando

Después de hacer git add, git commit y git push, corre a la pestaña Actions de tu repositorio. [05:30]

En los logs deberías ver el mensaje de que el backend se configuró correctamente para Azure RM, seguido por un terraform validate exitoso, un terraform plan que detecta los cambios y un terraform apply que ejecuta la creación.

Mientras la action corre, puedes ir al contenedor githubactions-state en Azure y ver cómo aparece el archivo estados.tfstate. Ese archivo es la prueba de que tu pipeline ya está registrando todo.

¿Qué pasa si dos despliegues se ejecutan muy rápido seguidos? Las GitHub Actions corren tan rápido que un recurso puede intentar destruirse y crearse al mismo tiempo, causando errores de superposición. Una segunda ejecución con un cambio mínimo suele resolver el conflicto porque ya existe el estado de referencia.

Cómo despliegas nuevos recursos solo con un commit

El beneficio real llega después. [08:00]

Para probarlo, agrega un nuevo bloque de recurso en main.tf, por ejemplo otro azurerm_storage_container llamado container_oscar apuntando a una Storage Account distinta. Haz commit con un mensaje claro como contenedor de Oscar agregado y un push a la rama main.

A partir de ese momento, tu GitHub Action:

• Inicializa Terraform con el backend remoto.
• Valida la sintaxis.
• Genera el plan comparando contra el tfstate.
• Aplica solo los cambios necesarios.

No necesitas correr ningún comando de Terraform desde tu máquina. El flujo completo de infraestructura como código con CI/CD queda automatizado: editas, commit, push, y la nube responde.

¿Has probado este flujo con otros proveedores de nube como AWS o GCP? Cuéntame en los comentarios cómo adaptaste el backend.