¿Qué es el drift de configuración, y cómo lo previene la infraestructura inmutable?

#Dos servidores que empezaron siendo idénticos

El drift de configuración es lo que ocurre cuando máquinas que empezaron siendo copias exactas entre sí dejan de serlo, poco a poco. Aprovisionas diez servidores de aplicación desde la misma imagen base, pasan las mismas pruebas de humo, se comportan de forma idéntica durante el primer mes... y seis meses después el servidor 7 corre una versión menor distinta del runtime porque alguien entró por SSH durante un incidente y lo parchó a mano, el servidor 3 tiene un cron? job extra que nadie recuerda haber agregado, y el servidor 9 tiene una variable de entorno obsoleta que apunta a una réplica de base de datos ya dada de baja. Ningún cambio individual parecía grave por sí solo. Lo que te destruye es la acumulación: eventualmente un deploy que funciona bien en nueve servidores lanza un error inexplicable en el décimo, y la única forma de averiguar por qué es comparar dos máquinas que se suponía eran idénticas y que nunca se auditaron.

El drift casi siempre entra por la puerta trasera de los "arreglos rápidos". Un incidente en producción necesita un parche inmediato, alguien entra y edita un archivo de configuración directamente en lugar de pasar por el pipeline de despliegue, y el arreglo funciona, pero ahora solo existe en esa instancia, invisible para el control de versiones, invisible para la próxima persona que aprovisiona un servidor de la manera "normal". El autoescalado empeora esto, no lo mejora: una instancia nueva que se levanta durante un pico de tráfico se construye a partir de lo que capturó la imagen base o la última corrida completa de aprovisionamiento, que a menudo ya está desactualizada respecto a las instancias parchadas a mano que están al lado, en el mismo pool del balanceador de carga. Ahora tu flota no solo se desvió de su especificación original: es internamente inconsistente consigo misma, y qué versión de "normal" recibe una petición depende de a qué instancia decidió enrutarla el balanceador.

Las herramientas de gestión de configuración (Ansible, Chef, Puppet, Salt) fueron la respuesta de la primera generación, y sí ayudan genuinamente, pero solo si se ejecutan de forma continua y se trata cualquier cambio manual como una violación que hay que corregir, no solo documentar. Una herramienta que reconcilia el estado una vez al día sigue dejando una ventana de 24 horas donde un cambio manual está activo y sin detectar, y si los ingenieros saben que la herramienta "lo va a arreglar eventualmente", la tentación de saltarse el pipeline para un arreglo rápido por SSH nunca desaparece. El problema más profundo es que estas herramientas normalmente se aplican a una máquina que ya tiene historia: paquetes que se instalaron y nunca se desinstalaron, archivos que sobraron de tres despliegues atrás, un directorio /tmp que nadie limpia. La convergencia te acerca al estado deseado; no borra lo que se acumuló antes de que la herramienta empezara a gestionar esa máquina.

#Reemplazar, no parchar

La infraestructura inmutable resuelve el drift eliminando la operación que lo causa: a nadie se le permite jamás modificar una instancia en ejecución. En cambio, cada cambio —una actualización de dependencia, un valor de configuración, un parche de seguridad— se incorpora a la fuente de verdad (un Dockerfile, una plantilla de Packer, un pipeline de construcción de AMI), se construye y prueba una imagen completamente nueva, y se reemplaza la flota con instancias arrancadas desde esa imagen nueva. Las instancias viejas se terminan, no se parchan. Si la imagen nueva tiene un error, no lo depuras en el lugar: haces rollback de la flota a la imagen anterior, que sigues teniendo, idéntica byte por byte a lo que corría hace una hora.

Esto obliga a algunas disciplinas que vale la pena mencionar porque son justo lo que preguntan en las entrevistas. Primero, las instancias deben ser sin estado: todo lo que necesite sobrevivir a la muerte de una instancia —datos de sesión, archivos subidos, estado de la aplicación— tiene que vivir fuera de la instancia, en una base de datos, un almacenamiento de objetos o un caché, porque la instancia misma es desechable por diseño. Segundo, la configuración debe inyectarse al arrancar (variables de entorno, un gestor de secretos, un servicio de metadatos) en lugar de quedar fija dentro de la imagen o editarse después, de modo que la misma imagen pueda servir a desarrollo, staging y producción sin ser imágenes distintas. Tercero, "arreglar" algo en producción ahora es, por definición, un viaje completo de ida y vuelta por el pipeline de construcción, lo cual se siente más lento en el momento y es exactamente la propiedad que hace confiable a la flota: ya no existe forma de que un arreglo exista sin estar en control de versiones.