Gestionar varios servidores Linux: herramientas útiles

Qué va a implementar

No es una herramienta, sino una pila pequeña, elegida según el número real de servidores que tenga. Ese número es el único dato que importa y es el que omiten todas las listas de «herramientas de administración de servidores Linux». El error clásico es adoptar una solución para 200 servidores cuando sólo se tienen cuatro VPS y pasar un mes alimentando la herramienta en lugar de administrar los servidores. El segundo error clásico es que una persona con dieciocho servidores siga conectándose por SSH a cada uno manualmente y aplique «el mismo» cambio de dieciocho formas ligeramente distintas.

Por eso, esta guía está organizada por tamaño de la flota: de 2 a 5 servidores, de 5 a 20 y más de 20, además de la capa transversal que se aplica a cualquier tamaño y que nadie documenta: un inventario, una gestión correcta de las claves, una única vía de acceso y copias de seguridad que realmente haya restaurado. Para cada herramienta se indican tres aspectos: qué sustituye, cuánto cuesta configurarla en minutos y cuál es el único inconveniente que realmente puede causar problemas. He administrado un host VPS durante quince años. La lista siguiente incluye lo que resiste una interrupción a las 2:00, no lo que funciona bien en una demostración.

Requisitos previos y advertencias importantes

Necesita que el acceso SSH basado en claves ya funcione en todos los servidores. Si todavía escribe contraseñas, solucione eso primero. Tardará diez minutos y todo lo siguiente presupone que usa claves. También necesita un usuario con permisos sudo que no sea root y servidores que ejecuten versiones actuales. Los comandos de esta sección presuponen Ubuntu 24.04, pero nada es específico de Ubuntu salvo apt.

Antes de revisar las herramientas, tenga en cuenta dos advertencias importantes. En primer lugar, la proliferación de herramientas es un problema de administración por sí misma. Cada agente que instala es otro daemon que debe actualizar en todos los equipos. Por tanto, el criterio para añadir uno debería ser «esto sustituye trabajo manual que hice esta semana», no «parece útil». En segundo lugar, todo lo que se describe aquí es software libre y el coste real es el tiempo de configuración. Por eso cada herramienta incluye una estimación en minutos. Cuando la estimación indique una tarde, créala.

2 a 5 servidores: ~/.ssh/config es la herramienta más infravalorada que ya tiene

Qué reemplaza: el archivo de texto con direcciones IP, la arqueología del historial del shell (ssh 203.0, después Ctrl-R y esperar), y escribir -p 2222 -i ~/.ssh/other_key una y otra vez. Coste de configuración: 15 minutos, una sola vez. El problema: los sockets de multiplexación obsoletos, que se explican más abajo.

Con este tamaño no necesita software; necesita configurar el cliente que ya tiene, de forma coherente con su uso. ~/.ssh/config convierte cada servidor en un nombre de una sola palabra y codifica el enrutamiento para que no tenga que volver a pensar en él:

Host *
    ServerAliveInterval 30
    ControlMaster auto
    ControlPath ~/.ssh/cm-%r@%h-%p
    ControlPersist 10m

Host bastion
    HostName 10.0.0.10
    User matt

Host web1
    HostName 10.8.0.11
    User matt
    ProxyJump bastion

Host db1
    HostName 10.8.0.12
    User matt
    Port 2222
    ProxyJump bastion

Tres ajustes hacen todo el trabajo. ProxyJump dirige las conexiones a través de un bastion en un solo salto, de modo que ssh db1 desde una cafetería crea un túnel transparente a través de bastion, sin reenvío del agente ni invocaciones de ProxyCommand, y los servidores privados no necesitan puertos SSH públicos (se explica con más detalle en la sección transversal). ControlMaster auto con ControlPersist multiplexa las conexiones sobre una sola sesión TCP, por lo que el segundo y todos los ssh, scp o rsync posteriores al mismo host se conectan al instante en lugar de renegociar. La diferencia se vuelve notable cuando entra en juego Ansible. Además, como scp, rsync y Ansible leen este mismo archivo, todos los nombres que defina aquí funcionan en todas partes.

El problema es que la conexión maestra puede seguir activa después de dejar de ser útil, y los dos modos de fallo son distintos. Cuando el servidor se reinicia o se interrumpe la conexión Wi-Fi, el proceso maestro conserva una sesión TCP desconectada que aún no ha detectado, y el siguiente ssh web1 se bloquea en silencio sobre un socket que no conduce a ninguna parte. Por separado, sshd limita a 10 las sesiones por conexión (MaxSessions en sshd_config), por lo que la undécima sesión multiplexada con un host muestra:

mux_client_request_session: session request failed: Session open refused

Ambos problemas tienen la misma solución: ssh -O exit web1 termina el proceso maestro y la siguiente conexión inicia uno nuevo. También puede ver ocasionalmente ControlSocket ~/.ssh/cm-matt@web1-22 already exists, disabling multiplexing. No es peligroso: dos sesiones compitieron por la conexión y esta sigue funcionando, pero sin multiplexación.

Hay dos complementos útiles para este tamaño. tmux en cada servidor reemplaza nohup, evita perder el trabajo cuando se interrumpe la conexión Wi-Fi y resuelve el problema de «no puedo cerrar el portátil porque hay una migración en curso». Coste de configuración: sudo apt install -y tmux, dos minutos, más la memoria muscular de tmux new -s work y tmux attach -t work. El problema es el anidamiento: tmux dentro de tmux intercepta la tecla de prefijo. Ejecútelo en el servidor o en el portátil, pero no en ambos. Si ejecuta sesiones de agentes de larga duración, esto es especialmente importante. Es el mismo patrón que ejecutar Claude Code en tmux en un VPS, donde la sesión debe sobrevivir a la conexión SSH.

Un archivo de alias compartido evita volver a escribir sus doce comandos de una sola línea favoritos en cada equipo. Mantenga un .bash_aliases en un repositorio git y cópielo en cada servidor. El problema es que se desincroniza en cuanto lo edita directamente en un servidor en lugar de hacerlo en el repositorio. Esa es también su primera muestra de por qué existe el siguiente nivel.

De 5 a 20 servidores: configuración como código o gana la desviación

Cuando se superan los cinco servidores, «lo haré en cada máquina» deja de ser un método y se convierte en una mentira que uno se cuenta. Todas las herramientas de este nivel combaten el mismo problema: la desviación de configuración.

Ansible reemplaza el bucle de shell sobre los nombres de host, la página wiki titulada «configuración del servidor nuevo» que está desactualizada en tres pasos y la incertidumbre de no saber si web3 recibió realmente la corrección. Coste de configuración: 30 minutos hasta tener el primer playbook funcional, sudo apt install -y ansible en el portátil o en un equipo de administración (apt proporciona una versión anterior de Ansible, que es suficiente para todo lo descrito aquí; la ruta con pipx del tutorial instala versiones actuales), sin agentes en los servidores y con todo funcionando mediante la configuración de SSH que ya creó. Es la mejora individual más importante de esta página. El recorrido completo está en el tutorial del primer playbook de Ansible. Esta es la estructura del inventario que permite hacerlo funcionar:

[web]
web1 ansible_host=10.8.0.11
web2 ansible_host=10.8.0.12

[db]
db1 ansible_host=10.8.0.21 ansible_port=2222

[all:vars]
ansible_user=matt
ansible_ssh_common_args='-o ProxyJump=bastion'

Como Ansible ejecuta el binario de OpenSSH, el ~/.ssh/config que escribió en la sección anterior ya se aplica. Un inventario con nombres simples como web1 funcionaría sin variables. Las variables anteriores hacen que el inventario sea autónomo. Esto resulta útil el día que lo ejecute desde una máquina que no sea su portátil.

Pruébelo con ansible all -i inventory.ini -m ping. Un resultado correcto muestra "ping": "pong" para cada host, en verde. El primer error que encontrará tendrá este aspecto:

web1 | UNREACHABLE! => {
    "changed": false,
    "msg": "Failed to connect to the host via ssh: matt@10.8.0.11: Permission denied (publickey).",
    "unreachable": true
}

No es un problema de Ansible. Un ssh matt@10.8.0.11 normal falla de la misma forma. Corrija primero SSH, siempre. Ansible sólo puede ser tan fiable como la capa subyacente. El único inconveniente adicional es que Ansible necesita Python en ambos extremos. Por eso una imagen realmente mínima puede responder /usr/bin/python3: not found, ejecutar un apt install python3 y no volver a causar problemas.

unattended-upgrades sustituye a la persona que aplica los parches de seguridad en N servidores. Ubuntu Server 24.04 lo incluye preinstalado y normalmente ya habilitado para las actualizaciones de seguridad. Por tanto, aquí hay que verificarlo, no instalarlo:

cat /etc/apt/apt.conf.d/20auto-upgrades

Las dos líneas deben terminar en "1". Algunas imágenes mínimas y de proveedores cloud lo incluyen deshabilitado. sudo dpkg-reconfigure -plow unattended-upgrades vuelve a escribir ese archivo si es su caso. Coste de configuración: dos minutos para comprobarlo en cada servidor o una tarea de Ansible para todos. El inconveniente es que, de forma predeterminada, nunca reinicia el sistema. Por eso las actualizaciones de seguridad del kernel quedan aplicadas sólo parcialmente hasta que se reinicia el servidor. La guía específica de unattended-upgrades explica los reinicios automáticos, cómo elegir qué se actualiza y cómo leer sus registros.

Monitorización centralizada evita enterarse por un cliente, que es el sistema de monitorización más caro que se ha diseñado. Hay dos herramientas, con una línea sobre cuándo usar cada una: Uptime Kuma responde a «¿está disponible?». Realiza comprobaciones HTTP, TCP y ping, envía alertas a cualquier destino y se instala en diez minutos con Docker. Zabbix responde a «¿está a punto de fallar?». Muestra tendencias de disco, memoria y CPU mediante un agente en cada host, y su configuración requiere, en términos realistas, una tarde. Empiece con Kuma. Añada Zabbix cuando el estado «disponible pero degradado» empiece a costarle dinero. El inconveniente de ambas herramientas es su ubicación. Es un aspecto lo bastante importante como para introducir la sección de errores que aparece a continuación.

Un panel web, sólo si es necesario. Webmin evita tener que recordar dónde guarda Ubuntu cada configuración. Para un equipo con distintos niveles de experiencia o para un servidor que se administra dos veces al año, resulta realmente útil. La configuración requiere diez minutos. El inconveniente es que se trata de una aplicación web con privilegios equivalentes a root, escuchando en el puerto 10000. Internet busca este tipo de servicio constantemente. Si lo ejecuta, vincúlelo a localhost o a una dirección de VPN, nunca a 0.0.0.0 en una interfaz pública. Si está considerando un panel porque SSH parece lento, vuelva a leer la sección anterior. ~/.ssh/config junto con Ansible es más rápido que cualquier panel una vez configurado.

Más de 20 servidores: dónde termina honestamente esta guía

Con más de 20 servidores, ya administra una flota y el conjunto de herramientas cambia: Terraform u OpenTofu para que los propios servidores sean reproducibles; cloud-init o imágenes base para que un equipo sea desechable en lugar de reparable; configuración basada en pull o canalizaciones de CI que ejecuten Ansible, porque el modelo push desde un portátil deja de escalar; y una gestión de secretos real. Ansible no falla al llegar a 20 servidores. Muchas organizaciones lo ejecutan en cientos de nodos. Sin embargo, las prácticas que lo rodean deben ser más rigurosas, y eso corresponde a otro tipo de artículo distinto de los que publica este sitio. Si trabaja a esa escala, la sección siguiente también es para usted, porque el inventario, las claves y una disciplina estricta de acceso son precisamente los elementos que las herramientas para flotas dan por supuestos.

La capa que nadie documenta

Hay cuatro prácticas que se aplican a cualquier tamaño de flota. Omitirlas hace que administrar muchos servidores parezca más difícil de lo que es.

Un archivo de inventario, aunque sea de texto. En cuanto tenga tres servidores, anote el nombre, la IP, el proveedor, qué se ejecuta en cada uno y por qué existe. Un servers.md en un repositorio de git es suficiente; el inventario de Ansible anterior es mejor porque también sirve como documentación ejecutable. Sustituye la pregunta de las 2 de la madrugada: «espera, ¿qué es 10.0.0.40?». Coste de configuración: diez minutos. El problema: sólo funciona si crear un servidor y añadir la línea son el mismo acto, nunca dos acciones separadas.

Higiene de claves: rotación desde ahora y una CA de SSH cuando sea necesario. Enumere dónde están sus claves (cat ~/.ssh/*.pub en su equipo y ~/.ssh/authorized_keys en cada servidor), elimine los equipos antiguos y las claves de antiguos colaboradores, y rote cualquier clave cuya antigüedad impida saber dónde se ha utilizado. Una autoridad certificadora de SSH, con certificados firmados de corta duración en lugar de claves estáticas, es la solución adecuada a escala. Pero el consejo práctico es que, con menos de diez servidores, una gestión disciplinada de authorized_keys mediante Ansible proporciona el 90% del beneficio con el 10% de la complejidad administrativa.

Un solo punto de entrada, no veinte. Cada puerto SSH público multiplica la superficie de ataque por N. El patrón que escala consiste en usar un bastion host o, mejor aún, una VPN WireGuard en un VPS que controle, y vincular el SSH de los demás servidores sólo a sus direcciones privadas. Las líneas ProxyJump de la configuración anterior ya presuponen este diseño. Todo lo que deba permanecer público debe tener fail2ban de forma predeterminada. Coste de configuración: una hora, una sola vez. El problema: compruebe que el acceso alternativo (la consola del proveedor) funciona antes de cerrar el puerto 22 en todas partes, no después.

Copias de seguridad verificadas mediante restauraciones. Una copia de seguridad no probada es sólo una hipótesis. Use el mecanismo que use, snapshots del proveedor, restic o rsync en un segundo equipo, la herramienta que realmente importa es una entrada del calendario para restaurar un servidor en un VPS nuevo y confirmar que arranca y presta servicio. Todas las historias de terror sobre copias de seguridad que he oído en quince años de hosting contienen la frase «teníamos copias de seguridad».

Los errores

Los modos de fallo a escala de varios servidores no se deben a las herramientas, sino a los hábitos. Cuatro de ellos explican casi todos los problemas.

Servidores copo de nieve. Cada equipo se configuró manualmente, es ligeramente distinto y nadie puede reconstruirlo. El problema se descubre cuando falla un disco. La solución es poco interesante: todos los cambios pasan por Ansible o, como mínimo, se añaden a la sección de ese servidor en el documento de inventario. Cualquier servidor que no pueda reconstruir a partir de las notas esta tarde es deuda técnica con una fecha límite que no puede elegir.

Agujeros «temporales» en el firewall. ufw allow 5432 para depurar un problema y, 18 meses después, Postgres sigue expuesto a Internet. Audite cada equipo con sudo ufw status numbered o todos de una vez con ansible all -i inventory.ini -a "ufw status numbered" --become, y elimine todo lo cuya razón actual no pueda explicar. Si una regla es realmente temporal, el ufw delete correspondiente se añade a la misma ventana de tmux antes de cerrarla.

Monitorización alojada en un equipo monitorizado. Si Uptime Kuma se ejecuta en el servidor que supervisa, la alerta que indica «todo está caído» también estará caída. Así habrá creado una versión más pequeña y menos eficiente del centro de datos menos eficiente del mundo. La monitorización debe estar en un dominio de fallo distinto: una VPS económica de otro proveedor es la opción clásica o, como mínimo, una comprobación externa de un nivel gratuito que supervise el sistema de monitorización.

SSH de root en todas partes. Una única clave de root compartida en toda la flota significa que un solo portátil comprometido obtiene el control de todo. Además, no queda un registro de auditoría que indique quién hizo cada cosa. Use usuarios individuales, sudo y PermitRootLogin no en /etc/ssh/sshd_config en cada host. Una vez más, esto es una tarea de Ansible de tres líneas en lugar de una tarde escribiendo comandos.

Cuando la flota supera unos pocos servidores, su primer playbook de Ansible automatiza las tareas repetitivas.

FAQ

¿Cuál es la mejor herramienta gratuita para administrar varios servidores Linux?

Para entre 2 y 5 servidores, un ~/.ssh/config bien escrito junto con tmux supera a cualquier herramienta que pueda instalar. A partir de unos cinco servidores, Ansible es la opción estándar: no requiere agentes, es gratuito, funciona mediante el SSH que ya tiene y convierte la configuración de servidores en archivos almacenados en git. Añada Uptime Kuma para las alertas de disponibilidad; todas las herramientas mencionadas en esta guía son software libre.

¿Puedo administrar varios servidores Linux sin Ansible?

Sí. Por debajo de unos cinco servidores, una buena configuración de SSH, un archivo de alias compartido y disciplina son suficientes, y muchas personas trabajan así durante años. A partir de ese punto, la alternativa a Ansible no es «nada», sino una divergencia de configuración sin documentar: dieciocho servidores configurados manualmente de forma ligeramente distinta. Si Ansible le parece demasiado complejo, empiece con un playbook que sólo administre authorized_keys y unattended-upgrades; eso por sí solo compensa la curva de aprendizaje.

¿Cómo ejecuto el mismo comando en varios servidores Linux a la vez?

ansible all -i inventory.ini -a "uptime" es la opción adecuada y no necesita playbooks, sólo el archivo de inventario. Para trabajar de forma interactiva y lado a lado, tmux puede difundir las pulsaciones de teclas a todos los paneles mediante setw synchronize-panes on, pero considérelo sólo una demostración, porque difundir comandos interactivos a servidores de producción es la forma de que un error tipográfico provoque una interrupción multiplicada por N.

¿Necesito un panel de control como Webmin para administrar servidores Linux?

No es necesario. Todo lo que hace un panel, SSH y Ansible lo hacen de forma más reproducible. Webmin resulta útil cuando personas con distintos niveles de experiencia administran los mismos equipos, o cuando accede a un servidor con tan poca frecuencia que volver a localizar las rutas de configuración consume un tiempo considerable. Si ejecuta uno, trátelo como la aplicación web con privilegios equivalentes a root que es: vincúlela a localhost o a una dirección de VPN, nunca a una interfaz pública.

¿Cuántos servidores Linux puede administrar de forma realista una sola persona?

Con administración manual, la calidad empieza a disminuir en algún punto por debajo de diez servidores. Con la configuración como código, la aplicación automatizada de parches y la monitorización centralizada, una persona cuidadosa puede administrar entre 20 y 50 servidores como trabajo a tiempo parcial; la limitación pasa a ser la frecuencia con la que aparece un fallo nuevo, no el mantenimiento rutinario. La cifra importante no es el número de servidores por administrador, sino el número de servidores con configuraciones únicas por administrador: manténgalo cerca de cero y el límite será alto.