Terraform 25: State remoto con el backend azurerm
easy⏱ 5 mincourseterraform
backend.tf apunta a un contenedor de storage
El bloque backend "azurerm" nombra cuatro cosas: el resource group y la storage account que contienen el state, el container dentro de ella, y el key (el nombre de archivo del blob). El blob de state se crea en terraform init. Dale a cada servicio/entorno un key único para que sus states nunca choquen.
# backend.tf (environment: dev)
terraform {
backend "azurerm" {
resource_group_name = "myorg-tfstate-dev-rg"
storage_account_name = "myorgtfstatedev"
container_name = "tfstate"
key = "dev/orders.tfstate"
}
}
La config del backend no admite variables
Terraform inicializa el backend antes de evaluar las variables, así que no podés escribir key = var.env. Dos patrones estándar: mantener un backend.tf chico por entorno (como arriba), o dejar el bloque parcial y pasar los valores que difieren en el init con -backend-config. Ambos mantienen secretos y nombres de entorno fuera de un único archivo compartido.
# Partial backend — values supplied at init time
terraform {
backend "azurerm" {
container_name = "tfstate"
}
}
# terraform init \
# -backend-config="resource_group_name=myorg-tfstate-dev-rg" \
# -backend-config="storage_account_name=myorgtfstatedev" \
# -backend-config="key=dev/orders.tfstate"
El backend no necesita access key en el archivo
No hardcodees una access_key de storage. El backend azurerm se autentica con tu login de Azure CLI, una identidad administrada, o un token federado OIDC en CI — la misma cadena de credenciales que usa el provider. Así el propio secreto del state queda fuera del repo.
Armá el key de state
Implementá stateKey(env, service) para que devuelva "{env}/{service}.tfstate". Por ejemplo stateKey("dev", "orders") debe devolver "dev/orders.tfstate". El starter loguea esa llamada.