Cuánto rompe un apply

Qué ha pasado

El radio de impacto es el estado

Un apply puede tocar cualquier cosa que esté en el estado sobre el que se ejecuta, y nada más. Por eso el radio de impacto del marcador no depende del cambio, sino del estado: a la izquierda, 2.000 recursos y seis críticos (la red de producción y las tres bases de datos), aunque el cambio sea la memoria de desarrollo. Un error en el código, un módulo actualizado sin querer, un drift que nadie ha visto: todo eso puede acabar en el mismo apply. A la derecha, el estado de la app de desarrollo tiene 460 recursos y ninguno crítico. Si algo sale mal, sale mal ahí.

El tamaño se paga también en tiempo. El plan lee cada recurso del estado antes de comparar, y la API de la nube tiene un límite de peticiones por segundo: a la izquierda, casi tres minutos por plan, con el estado bloqueado durante el plan y el apply. A la derecha, unos cuarenta segundos, y solo se bloquea el estado de la app de desarrollo.

Por capa y por entorno

Partir el estado sigue dos ejes. Por entorno, porque un cambio en desarrollo no debería poder tocar producción. Por capa, porque cada capa cambia a un ritmo distinto y la tocan personas distintas: la red cambia unas pocas veces al año y es de plataforma; la app cambia varias veces al día y es del equipo de la app. Cada estado tiene su lock, así que los cambios en la app ya no esperan a los de la red.

Para los entornos hay dos formas habituales. Con directorios, cada entorno es una carpeta (envs/dev, envs/pro) con su propio estado; el código común va en módulos y cada carpeta los usa con sus valores. Con workspaces, el mismo directorio tiene varios estados y se elige cuál con terraform workspace select. Los workspaces evitan copiar, pero el entorno pasa a ser algo que no se ve en el código. Pon el mando en workspaces, cambia la red de producción y luego la app de desarrollo: el workspace seleccionado sigue siendo pro, y el cambio va a producción. Los directorios tienen el problema contrario: como cada entorno es una copia, divergen sin querer (un arreglo que se hizo en desarrollo y nunca llegó a producción). Separar los entornos en cuentas distintas de la nube, que es la frontera más fuerte, es cosa del episodio 6.

Contratos entre estados

Al partir, lo que antes era una referencia dentro del mismo grafo (module.red_pro.subred_app) pasa a cruzar de un estado a otro. La app necesita el id de su subred, y hay tres formas de conseguirlo:

# 1. Leer el estado de la red
data "terraform_remote_state" "red" { config = { key = "red/pro.tfstate" } }
# 2. Leer un valor que la red publica
data "nube_parametro" "subred_app" { nombre = "/red/pro/subred_app" }
# 3. Preguntar a la nube
data "nube_subred" "app" { etiquetas = { capa = "app", entorno = "pro" } }

Con remote state, la app lee el estado de la red entero y coge las salidas; necesita permiso para leer todo ese estado, secretos incluidos, y queda atada a cómo lo organiza la red. Con valores publicados, la red escribe en un almacén de parámetros lo que ofrece y la app lee solo eso: es un contrato explícito, y la red puede reorganizarse por dentro sin avisar a nadie mientras siga publicando lo mismo. Con un data source, la app pregunta a la nube por la subred con ciertas etiquetas, y le da igual quién o cómo la creó; a cambio, depende de que esas etiquetas sean únicas y no cambien. Es la misma pregunta que en DDD: qué se expone entre dos partes y qué se queda dentro.

Cuándo hace daño: el orden que nadie escribió

Cambia la red de producción. A la izquierda, un solo apply lo hace todo: la subred nueva y, en el mismo grafo, los 38 recursos de la app que la usan, en orden. Es la gran ventaja del estado único: Terraform ve todas las dependencias.

A la derecha, el estado de la red se aplica solo. Su radio es pequeño y el apply termina bien. Pero la app de producción sigue apuntando a la subred vieja, que ya no existe: los contratos se leen al planificar, y el estado de la app no se ha planificado. Hay un orden entre estados, primero la red y luego la app, que no está escrito en ningún sitio. Con nueve estados, se lleva en la cabeza, en un README o en el pipeline, que aplica en ese orden.

Activa ahora un estado por recurso, el extremo contrario, y repite. El radio de cada apply es de un recurso, pero los 38 recursos de la app que usan la subred son 38 estados, y hay que aplicarlos todos después de la red, cada uno con su plan. El grafo que antes calculaba Terraform ya no lo tiene nadie. Partir no quita las dependencias; las saca del grafo y las convierte en trabajo de personas.

Criterio

1. ¿Hay partes que cambian a ritmos distintos o que tocan equipos distintos?La red y la app; producción y desarrollo.
   un estado por cada parte, con contratos explícitos entre ellas
2. no ↓
3. ¿El plan tarda tanto que la gente deja de leerlo?O el lock hace esperar a otros a menudo.
   partir por donde menos dependencias crucen
4. no ↓
5. Un estado. Partir tiene un coste: cada corte es un contrato que mantener y un orden que alguien tiene que saber.

En el mundo real

El orden entre estados es el problema que resuelve Terragrunt: cada estado declara de qué otros depende y lee sus salidas, y terragrunt run-all apply los aplica en orden. Las stacks de HCP Terraform y las dependencias entre stacks de Spacelift hacen lo mismo como servicio. Sin ellos, lo habitual es un pipeline que aplica las capas en un orden fijo y lanza la siguiente cuando cambian las salidas de la anterior.

Los workspaces de la CLI de Terraform son los que se ven en este episodio: varios estados para el mismo código. Los de HCP Terraform se llaman igual pero son otra cosa, más cercana a un directorio con su propio estado, sus variables y sus permisos. Para publicar valores entre estados se usan almacenes como AWS SSM Parameter Store, Azure App Configuration o Google Secret Manager y Runtime Configurator, o las salidas de los workspaces de HCP Terraform, que se pueden compartir con permisos explícitos.

No hay un tamaño correcto, pero hay una señal: cuando la gente deja de leer el plan porque es demasiado largo, o empieza a usar -target para aplicar solo una parte, el estado es demasiado grande. -target existe para emergencias; usarlo de costumbre es partir el estado sin decirlo.

Siguiente episodio

La red de la app ya tiene su estado. Entonces el equipo de Notificaciones pide una VPC igual, y Marta, en lugar de copiar, la convierte en un módulo de plataforma. La pregunta es qué enseña el módulo y qué esconde.

← Todos los episodios · Episodio 3: Dos personas, un estado · Cuentas en el mapa de BCPS Bank