¿Cómo administrar el estado de Terraform?

Nota del editor: Esta publicación apareció originalmente en CloudSkiff.com. CloudSkiff se unió a Snyk en octubre de 2021.

¿Cómo administrar el estado de Terraform? Y, por cierto, ¿qué es un archivo TFState? ¿En qué se diferencia el código de Terraform del de otras herramientas de administración de configuración y cuáles son las prácticas recomendadas?

¿Cómo administrar el estado de Terraform?

Es fundamental saber cómo administrar el estado de Terraform. Primero que nada, ¿qué es exactamente un TFState?

El archivo TFState de Terraform es lo que lo hace muy diferente de otros sistemas. Puedes crear e implementar infraestructura con otras herramientas de administración de configuración, como Chef, Saltstack y Ansible, pero la mayor diferencia de Terraform está en este estado.

Puedes ver el archivo TFState como una gran estructura JSON que representa la realidad de tu infraestructura y que, junto con el código de Terraform, declara el llamado “estado deseado” que quieres alcanzar.

Este estado deseado es declarativo. Esto significa que, cuando declaras en tu código que quieres un recurso específico con una configuración determinada y apply ese código, Terraform se comunica con la API de tu proveedor de nube y crea todos esos recursos. Cuando termina, escribe en este archivo JSON la realidad de la implementación en el lado del proveedor de nube.

Al final, tienes 3 situaciones con 3 elementos:

• tu código

• la realidad de tu cuenta en el proveedor de nube

• el archivo de estado

El archivo de estado es exactamente el reflejo de la última ejecución exitosa de apply de tu código. Funciona con todo tipo de recursos. Esto significa que puedes usarlo con tu proveedor de nube si quieres implementar recursos de infraestructura, pero también con cualquier otro tipo de proveedor.

Supongamos que implementas gráficos de Helm con Terraform. En ese caso, también tendrás un archivo de estado de tus implementaciones. Lo mismo ocurre con GithHub. Si usas el proveedor de GitHub, defines usuarios y el mismo usuario se utiliza en un proyecto de Google Cloud y en un IAM de AWS como usuario de GithHub, se volcará la información de ese usuario específico; todo quedará vinculado en el archivo de estado de Terraform.

Considéralo como la referencia a la realidad de la infraestructura existente, a la que puedes acceder desde tu código.

En resumen, un archivo de estado representa la realidad de tu implementación en el proveedor de nube, según lo que declaraste en tu código de Terraform.

¿Cómo administras el estado y dónde guardas el estado de Terraform?

De forma predeterminada, no hay ninguna opción. La primera vez que inicializas tu repositorio de Git con código de Terraform y ejecutas un poco de código de Terraform, se crea el TFState directamente en la raíz de tu repositorio de GitHub. Tienes que guardar ese archivo en algún lugar. De forma predeterminada, podrías sentir la tentación de subirlo a GitHub, como hace mucha gente, pero no es una de las prácticas recomendadas, porque puede contener secretos y probablemente no quieras subir secretos a GitHub.

Aun así, debes guardar el archivo de estado, porque, si no lo haces, perderás lo que Terraform considera la “infraestructura existente”. Si lo eliminas y vuelves a ejecutar apply, Terraform intentará aplicar toda la infraestructura nuevamente como si fuera “nueva”, y probablemente no quieras que eso ocurra.

La práctica recomendada es compartirlo en algún lugar, normalmente en un bucket de Amazon S3 o cualquier tipo de bucket de almacenamiento en AWS, Azure o Google Cloud:

1resource "aws_instance" "vm" {
2  ami                    = data.aws_ami.amazon-linux.id
3  instance_type          = var.instance_type
4  tags = {
5    Name = "DEMO VM DESTROY ME - ${terraform.workspace}",
6    Terraform = "true"
7  }
8}
9
10data "aws_ami" "amazon-linux" {
11  most_recent = true
12  owners = ["amazon"]
13
14  filter {
15    name   = "name"
16    values = ["amzn-ami-hvm-*"]
17  }
18
19}

Básicamente, declaras tu backend. En este caso, es un código muy sencillo que implementa una sola VM. Es solo una demostración. Lo uso para probar mis espacios de trabajo de Terraform, así que no lo consideres adecuado para un trabajo importante.

Puedes configurar Terraform con la palabra clave Terraform y decir: “Para Terraform, quiero que mi backend sea S3 y que el bucket de S3 sea este”.

Indicas dónde quieres que esté tu archivo de estado. Así de sencillo. En la siguiente ejecución de Terraform apply, Terraform usará un archivo de estado temporal de forma local y luego lo subirá a tu bucket de S3.

Después, cada vez que quieras trabajar en él, usará ese archivo.

1terraform {
2  backend "s3" {
3    bucket = "cs-tfstates-demo-sj-frankfurt-1"
4    key    = "tfstates/terraform.tfstate"
5  }
6}

Un último consejo: no olvides agregar también un archivo de bloqueo en una base de datos. Así, si existe ese bloqueo, dos personas no podrán iniciar una acción destructiva ni ejecutar apply en Terraform al mismo tiempo.

Protege tu código de Terraform

Snyk IaC protege tus configuraciones de Terraform (¡y también tus plantillas de Kubernetes, CloudFormation y ARM!) mientras programas, con correcciones guiadas para que puedas fusionar los cambios y seguir adelante. Puedes hacer pruebas mientras escribes, monitorear los cambios en tus repositorios de Git y automatizar las pruebas en tus pipelines de compilación antes de la implementación. Empezar con un plan gratuito toma solo unos minutos, mientras que una brecha causada por una configuración incorrecta de IaC puede provocar daños irreparables. Regístrate y empieza a proteger tus configuraciones.