Despliegues sin caída (symlink)

El problema

Mi portafolio se edita desde un panel, y cada cambio de contenido termina en un sitio nuevo. Si publicar significara detener el servidor, copiar archivos encima de los viejos y volver a levantarlo, habría segundos en los que alguien podría ver una página rota o a medio copiar. Quería que actualizar fuera algo que pudiera hacer varias veces al día sin pensarlo.

La respuesta no fue Kubernetes ni un balanceador de carga: fue un symlink.

Cómo funciona

1. Cada cambio de contenido dispara un build automático.
2. Un candado (flock) garantiza que solo corra un build a la vez, y una pausa corta agrupa en uno solo los cambios que llegan seguidos.
3. El sitio se compila en una carpeta nueva dentro de releases/. La versión en línea ni se toca.

¿Y si el build falla?

Se borra esa carpeta y listo. El enlace current sigue apuntando a la versión anterior, así que quien visita el sitio no se entera de nada. Corrijo, guardo y el siguiente build sale bien.

El cambio atómico

Cuando el build sale bien, cambio el symlink current de golpe (los nombres son de ejemplo):

ln -s releases/version-nueva current.tmp
mv -Tf current.tmp current

mv usa la llamada rename(2), que es atómica: el servidor web ve la versión vieja o la nueva, nunca un estado intermedio. Después hago una recarga suave del servidor web, y las peticiones que estaban en curso terminan sin cortarse.

Por qué lo hice así

• Sin ventanas de mantenimiento. Publicar no interrumpe a nadie.
• Rollback en un comando. Conservo las últimas cinco versiones; volver atrás es apuntar el symlink a la anterior.
• Fallos aislados. Un build roto nunca llega a estar en línea, porque se construye al lado y no encima.
• Poca maquinaria. Para un sitio estático, un clúster habría añadido más piezas que mantener que problemas resueltos.

Lo que aprendí

No todo necesita un orquestador. Muchas veces Linux ya trae la herramienta correcta: un enlace simbólico, un candado de archivo y una operación atómica del sistema de archivos bastan para desplegar un sitio estático sin caída.

La clave fue separar dos momentos: construir, que es lento y puede fallar, y publicar, que es instantáneo y no puede quedar a medias. Este patrón encaja con artefactos que se pueden construir completos de antemano, como un sitio estático; un servicio con estado pide otras estrategias.

¿Y tú?

¿Cómo despliegas: blue-green, contenedores, symlinks o un git pull y a rezar? Cuéntamelo en los comentarios de la red donde viste el video.