Migrar a Kubernetes en un solo cambio

ClickFortify empezó en una sola VM con docker-compose. Hoy se ejecuta en Kubernetes sobre GCP y se despliega con ArgoCD. Este artículo trata del paso de uno a otro, y de por qué acabé haciéndolo en un solo cambio en lugar de con una migración gradual.

El producto no puede detenerse

ClickFortify recoge clics publicitarios sobre tráfico real, los puntúa y escribe exclusiones de vuelta en Google Ads y Meta. Los clics llegan a todas horas. Un plan de migración que necesite una ventana de mantenimiento, o que deje el tracker mitad en un stack y mitad en el otro, cuesta presupuesto real a anunciantes reales.

Así que la pregunta no era "¿cómo lo movemos todo?". Era "¿cómo hacemos que el cambio sea un paso único, pequeño y reversible?".

Primero, un proceso de despliegue fiable

Antes de mover cualquier tráfico, el clúster necesitaba un proceso de despliegue en el que yo confiara. La configuración de GitOps usa tres repositorios: la aplicación, los manifiestos que despliega ArgoCD y la infraestructura de la plataforma. El plan original mantenía los manifiestos dentro del monorepo de la aplicación. Los separé porque ArgoCD vuelve a clonar el repositorio en cada actualización y el monorepo es grande, porque la plataforma tiene su propio ciclo de vida y sus propios revisores, y porque así la CI de la aplicación no tiene ningún acceso al repositorio de la plataforma.

Eso importa en una migración. Si el lado nuevo se despliega de la misma forma en que se desplegará siempre a partir de entonces, verificarlo el primer día también verifica el proceso de lanzamiento.

Un conjunto paralelo de hostnames de staging

El plan por el que me decidí tenía tres pasos:

1. Desplegar el stack nuevo completo en el clúster detrás de un conjunto paralelo de hostnames de staging, como stage.example.com.
2. Verificarlo allí.
3. Redirigir los hostnames de producción al clúster en un solo cambio.

Nada de producción cambió mientras se probaba el lado nuevo. La VM antigua siguió atendiendo todas las peticiones reales, y los hostnames de staging me dieron un lugar donde probar el stack nuevo de principio a fin.

Sin migración de datos, y la trampa que conlleva

Ambos lados usaban las mismas bases de datos. Eso es lo que hizo posible un único cambio: no había ninguna copia que ejecutar, ninguna sincronización que mantener coherente y ningún momento en que los dos stacks discreparan sobre los datos. Cuando se movió el DNS, el stack nuevo ya estaba leyendo y escribiendo las mismas filas que el antiguo.

La trampa es que el lado de staging nunca fue realmente un sandbox. Todo lo que escribía acababa en datos de producción. Las pruebas usaron un espacio dedicado reservado para ello, y nunca se apuntó el script de ningún cliente real al tracker de staging.

Por qué el worker se quedó en cero

El worker es el servicio que ejecuta las tareas programadas. Con una base de datos compartida, dos workers significan que cada tarea programada se ejecuta dos veces: los correos se envían dos veces y las limpiezas borran dos veces. Por eso el worker del lado nuevo se mantuvo en cero réplicas durante todo el periodo de staging.

# Illustrative: keep the new side's worker off until the flip
kubectl scale deployment worker --replicas=0

El cambio, y comprobar que se mantuvo

El cambio en sí fue una modificación de DNS: los hostnames de producción se apuntaron al clúster. Antes de eso, comprobé que los digests de las imágenes que se ejecutaban en el clúster coincidían con lo que esperaba lanzar.

Después, la comprobación más importante fue la del tracker. Está detrás de una CDN y un proxy inverso, y averiguar la IP real del visitante detrás de eso es justo el tipo de cosa que se rompe cuando cambia la topología. El tráfico real del tracker tras el cambio mostraba IP reales de visitantes y ninguna dirección de los nodos de la CDN. Una vez confirmado eso, se eliminaron los hostnames de staging.

Justo después del cambio, la marcha atrás era el mismo movimiento a la inversa: volver a apuntar los hostnames a la VM antigua, que detuve en lugar de eliminarla.

Lo que le diría a alguien que haga la misma migración

1. Si ambos lados pueden compartir las bases de datos, hazlo. Elimina la migración de datos y convierte el cambio en una sola modificación de DNS.
2. Haz una lista de cada tarea programada y asegúrate de que se ejecute en exactamente un lugar durante el staging, aunque eso signifique que un servicio no se pueda ensayar.
3. Vacía o exporta las tareas en cola y diferidas antes del cambio. Viven fuera de la base de datos.
4. Decide la comprobación de verificación antes del cambio, y que se base en tráfico real, no en endpoints de salud.