Cómo automatizé la gestión de 366 servidores y dejé de pasar noches haciendo tareas rutinarias

Cuando tienes un servidor — te conectas por SSH y haces lo que haga falta. Cuando son diez — escribes scripts bash. Cuando son más de trescientos — o automatizas todo hasta el final, o la infraestructura te gobierna a ti, y no tú a ella.

He recorrido ese camino. Una decena de proyectos, más de 400 servidores en siete países — Países Bajos, Polonia, Estados Unidos, Alemania, India, Kazajistán, Rusia. En cierto momento quedó claro: mantener todo en la cabeza y teclear a mano ya no funciona. O sistema, o caos. Elegí el sistema — y ahora una nueva nodo en cualquier punto del mundo se levanta en unos minutos sin una sola sesión SSH manual.

Contaré cómo funciona.

Cómo era antes

Poner en marcha un servidor nuevo era una búsqueda del tesoro. Abrir SSH, recordar (o encontrar en las notas) los comandos necesarios, ejecutarlos en orden, olvidar añadir algo en DNS, volver, añadirlo, agregarlo al monitoring por separado, registrarlo en el panel por separado. Una hora o una hora y media por nodo — y eso si todo va bien. Y cada vez con una probabilidad no nula de hacer algo ligeramente distinto que la vez anterior.

A escala de más de 400 servidores eso deja de ser solo incómodo. Incluso si tocas cada uno una vez al mes — son cientos de horas al año en trabajo mecánico. Además, la infraestructura se convierte poco a poco en una caja negra: nadie recuerda bien qué está configurado en cada servidor, por qué está así y quién lo hizo.

Qué hay dentro

La base de todo es Ansible junto con Semaphore. Ansible permite describir la configuración de los servidores como código: escribes una vez, lo ejecutas en cualquier número de máquinas. Semaphore es una interfaz web simple encima de ello, para no andar con el terminal y ver lo que pasa en tiempo real.

Todo el repositorio — 49 playbooks, 39 roles, 11 archivos inventory. Un playbook es un guion: una secuencia de pasos para un servidor. Un role es un bloque reutilizable de lógica, por ejemplo “configurar firewall” o “emitir certificado”. El inventory es la lista de todos los servidores con parámetros: rol, país, puertos, versiones de servicios. Toda la infraestructura vive en git — cualquier cambio se ve en el historial, cualquier estado es reproducible. Cuando algo sale mal, la respuesta siempre está en el código, no en la cabeza de la persona que “recuerda cómo lo hizo la última vez”.

Cada servidor tiene un rol: nodo normal, edge, shared, máquina base, monitorización. Los playbooks leen ese rol y omiten automáticamente los pasos que no corresponden — el proxy no recibirá la pila VPN, el nodo shared no pasará por el hardening completo. Sin filtrado manual.

El inventory está organizado de forma jerárquica: proyecto → región → host. Necesitas cambiar un parámetro para todas las nodos en Países Bajos — cambias una línea. Necesitas actualizar solo un servidor o solo una región concreta — indicas el filtro apropiado al ejecutar. Sin código adicional, sin copy-paste.

Cómo se ve el despliegue desde dentro

Poner en marcha una VPN-node es el ejemplo más ilustrativo. Un clic en Semaphore, nueve pasos en cadena, 8–12 minutos de tiempo real. Mientras la nodo se despliega, yo me ocupo de otra cosa.

Qué ocurre por dentro: primero se comprueba la accesibilidad por SSH — no tiene sentido lanzar la cadena en un servidor muerto. Luego bootstrap: paquetes base, Docker, swap. Después hardening — se cierran puertos innecesarios, se configura protección contra brute force, se aplican parámetros del kernel para optimizar la red. A continuación se copian configs y archivos del proyecto. A través de la API de Cloudflare se crean el registro DNS y el certificado SSL. La nodo se registra en el panel de control, se levanta el stack Docker. Al final — los registros DNS para balanceo de tráfico.

Cada paso está descrito en código y ejecutado decenas de veces. La probabilidad de error humano tiende a cero — no porque las personas sean más cuidadosas, sino porque la persona ha sido simplemente eliminada del proceso.

Detalles que ahorran nervios

La monitorización se añade sola. En cada servidor, durante el provisioning se levanta un agente que registra la máquina en el registro común. Prometheus descubre nuevos servidores a través de ese registro — nada de listas estáticas, nada de “no te olvides de añadirlo”. Añadiste el servidor al inventory, ejecutaste el playbook — ya está en las métricas. Dado de baja un servidor — un playbook separado limpiará por él todas las entradas.

Los certificados SSL ya no son una tarea. El sistema los emite a través de Cloudflare, soporta wildcard (comodines) y múltiples dominios, y los renueva automáticamente. Un servidor puede emitir un certificado y compartir el estado con otras nodos — cómodo cuando cien máquinas trabajan bajo un mismo dominio.

Playbook de verificación de estado. Cualquier infraestructura viva tarde o temprano se desvía de lo que está escrito en el código — algo se arregló a mano, algo falló por sí mismo. Este playbook consulta el panel de control, lo compara con el inventory, revisa puertos, comprueba las reglas del firewall. El resultado es un informe concreto: esta nodo está en el panel pero no en el inventory; aquí no coincide el perfil; aquí falta la regla necesaria. Sin esta herramienta, esas discrepancias se acumulan sin notarlo.

Resultados en Telegram. Después de cada playbook llega un mensaje: cuántos hosts fueron procesados, cuántos con éxito, cuántos fallaron, qué exactamente y un enlace a los detalles. Actualizas 50 nodos — no necesitas quedarte mirando la pantalla. Lo lanzas, te ocupas de lo tuyo y recibes el resultado en el teléfono.

Sobre herramientas aburridas

Ahora está de moda poner agentes de IA para todo. Yo mismo trabajo activamente con IA y entiendo su valor. Pero hay tareas donde un modelo de lenguaje no es lo que se necesita. Cuando lo que necesitas no es un “asistente inteligente que se apañe”, sino un sistema determinista: lo ejecutas y obtienes exactamente el resultado que describiste. Sin interpretaciones, sin alucinaciones, sin enfoques creativos a las 3 de la mañana en producción.

Ansible es aburrido. Probado. Predecible. Montas la estructura una vez — y el servidor número doscientos se configura exactamente igual que el primero. Esto es ingeniería — no cuando es bonito, sino cuando funciona.

En conclusión

Las cifras son simples. Un servidor manualmente — 60–90 minutos. Con automatización — 8–12 minutos, y la mayor parte de ese tiempo no estoy pendiente. A escala de 366 máquinas son cientos de horas al año que antes se gastaban en mecánica.

Pero, honestamente — el valor principal no está en la velocidad. El valor principal es que la infraestructura dejó de ser una caja negra. Cualquier servidor en cualquier proyecto está configurado igual: los mismos parámetros del kernel, el mismo orden de pasos, las mismas comprobaciones. Cuando algo falla — buscas la causa en el código, no intentas recordar quién hizo algo a mano hace tres semanas.

Y otro detalle que empiezas a valorar solo cuando tienes que reiniciar toda la infraestructura: reinicio gradual. El playbook reinicia los servidores de uno en uno, espera cada uno antes del siguiente. Reiniciar 89 nodos de un proyecto — una ejecución, sin riesgo de tirarlo todo de una vez. Antes era una operación de varias noches con supervisión constante. Ahora — lo lanzas y te olvidas.

400 servidores, siete países — un repositorio. No porque haya usado la herramienta más moderna. Sino porque elegí la correcta.