Hay algo especialmente satisfactorio en administrar un servidor desde una terminal. Sin web ni escritorios remotos, ni consumir recursos de más. Un teclado, una conexión SSH y control total.
Pero cuando pasas de administrar un par de servidores a mantener un pequeño clúster con varias decenas de máquinas virtuales y contenedores, la situación cambia, Actualmente tengo unos 54 contenedores, 4 maquinas virtuales y un nodo con 3 clusters.
Empiezas a acumular sesiones SSH, IPs de las que nunca te acuerdas. Y terminas preguntándote si no habrá una manera más cómoda de hacer todo eso.
En mi caso, la respuesta ha sido Zellij, una herramienta que he descubierto recientemente y que me ha parecido la caña.
Con algo de Bash, la API de Proxmox y unos cuantos ajustes, he terminado construyendo mi propia consola de administración remota. Todo en modo texto, pero con una interfaz visual que poco tiene que envidiar a muchas aplicaciones gráficas.
El punto de partida: mi cluster
Mi infraestructura doméstica, está organizada alrededor de un clúster de Proxmox VE con tres nodos:
- OBUXO
- OTOXO
- OCARBALLO
En ellos ejecuto distintos servicios: servidores web, bases de datos, aplicaciones que desarrollo, herramientas de monitorización, almacenamiento y otros proyectos personales.
Entre las aplicaciones están mi biblioteca digital, un gestor de reuniones con inteligencia artificial, varios sitios web y otras cosas con las que voy cacharreand.
La mayoría de estos servicios se ejecutan sobre contenedores LXC, aunque también utilizo máquinas virtuales cuando lo necesito.
Proxmox ofrece una interfaz web muy chula para administrar toda esta infraestructura. Y sigo utilizándola para operaciones como crear máquinas, modificar recursos, gestionar almacenamiento o realizar migraciones, pero para el día a día me muevo mejor con una shell: entrar en una máquina, comprobar algo, modificar una configuración, reiniciar un servicio o revisar un log, hacer un git pull ...
Para eso, abrir el navegador, localizar el contenedor, entrar en su consola y repetir la operación varias veces no resulta especialmente ágil. Además al estar alejado del cluster, tenía que abrir un tailscale, que para no instalarlo en los nodos lo tenía instalado en un Kasm al que me conectaba en remoto y abría un navegador en él, de cine, vamos ... ;(
Mi objetivo: una única terminal para gobernarlos a todos
La idea era bastante sencilla.
Quería abrir mi terminal habitual, conectarme a un servidor de administración y disponer inmediatamente de una interfaz desde la que pudiera:
- Ver todas las máquinas agrupadas por nodo Proxmox.
- Acceder rápidamente a mis servicios favoritos.
- Conocer su estado y consumo de recursos.
- Buscar cualquier máquina escribiendo parte de su nombre.
- Conectarme mediante SSH pulsando Enter.
- Cambiar de nodo sin perder el contexto.
- Trabajar cómodamente desde macOS o Windows que son mis estaciones de trabajo.
Y, sobre todo, quería que todo funcionase desde una terminal convencional.
El descubrimiento de Zellij
Zellij es un multiplexor de terminal moderno, escrito en Rust.
Si habéis utilizado tmux o GNU Screen, el concepto os resultará familiar: permite organizar múltiples terminales dentro de una misma sesión, dividir la pantalla en paneles y conservar sesiones de trabajo.
Sin embargo, Zellij tiene algo que me ha gustado especialmente: su aproximación a la experiencia de usuario.
Es visual, tiene una barra de navegación bastante intuitiva, permite definir distribuciones personalizadas y ofrece numerosas posibilidades para automatizar su comportamiento.
Además, su configuración utiliza KDL, un formato bastante legible con el que se pueden describir pestañas, paneles y comandos.
Lo importante es que Zellij no pretende sustituir a SSH ni a Proxmox. Es la capa que organiza nuestra forma de trabajar con ellos.
Y esa distinción es precisamente la que hace interesante la solución.
Así es como ha quedado
El funcionamiento es muy sencillo:
- Con las flechas selecciono la máquina.
- Pulsando Enter abro su conexión SSH.
- Con Alt + izquierda o derecha cambio de pestaña.
- Escribiendo en el buscador filtro los servidores de la lista.
Cada fila muestra el nombre del servicio, su dirección IP, el tiempo de actividad, el uso de disco, CPU y RAM.
Un indicador de color permite distinguir rápidamente las máquinas accesibles de las que no lo están.
En la parte inferior aparece una pequeña representación de los tres nodos físicos, con sus porcentajes de CPU y memoria.
Toda esta información se presenta con caracteres de terminal, colores ANSI y algunos símbolos Unicode.
La arquitectura: menos componentes, mejor
Mi solución está formada por cuatro piezas principales.
1. Un servidor de administración
Utilizo un servidor Debian como punto central de acceso.
Desde mi equipo ejecuto SSH hacia ese servidor, donde está instalado Zellij y reside toda la configuración.
Esto tiene una ventaja importante: no necesito replicar mis herramientas ni la configuración de cada máquina en todos los equipos desde los que trabajo.
Puedo utilizar mi Mac habitual, un ordenador con Linux o una terminal de Windows. La experiencia es esencialmente la misma.
2. Zellij como organizador
Zellij gestiona las pestañas y los paneles.
He definido espacios específicos para la pantalla principal, los servicios favoritos, los distintos nodos Proxmox y las herramientas de monitorización.
Cada pestaña ejecuta un pequeño programa de terminal encargado de mostrar las máquinas correspondientes.
Zellij aporta la estructura, mientras que mis scripts aportan el comportamiento.
3. Bash para construir la interfaz
La interfaz que se ve en las capturas no es una aplicación gráfica.
Está construida con scripts Bash que presentan los servidores en forma de tabla, gestionan la selección mediante teclado, aplican filtros y ejecutan las conexiones SSH.
El script central, llamado wickle-servers, se encarga de mostrar el contenido correspondiente a cada pestaña.
Por ejemplo, una de las pestañas ejecuta un comando equivalente a:
bash -lc "$HOME/bin/wickle-servers OTOXO"
El argumento determina qué grupo de máquinas debe aparecer.
La ventaja de este planteamiento es que resulta fácil añadir servicios, cambiar nombres o reorganizar los favoritos sin tocar la configuración principal de Zellij.
4. La API de Proxmox para consultar el estado
Una de las partes que más me interesaba era evitar que la interfaz fuese simplemente un listado estático de direcciones IP.
Proxmox VE dispone de una API REST que permite consultar el estado de los nodos, las máquinas virtuales y los contenedores.
Por ejemplo, los recursos de la API incluyen rutas como:
/api2/json/nodes/{node}/lxc
/api2/json/nodes/{node}/qemu
A partir de esa información puedo obtener datos como el estado de ejecución, el tiempo de actividad y el consumo de memoria, CPU y disco que Proxmox expone para cada recurso.
La consulta puede realizarse desde Bash con curl y procesarse utilizando jq.
En lugar de mantener permanentemente procesos de monitorización dentro de cada contenedor, aprovecho la información que ya recopila Proxmox.
Para las métricas de los nodos físicos utilizo el mismo principio, consultando sus estadísticas desde la API.
Una única fuente de información para toda la infraestructura.
El detalle que marca la diferencia: las pestañas
Inicialmente podría haber resuelto el problema con un único menú de terminal.
Pero las pestañas han terminado convirtiéndose en una de las mejores características de la solución.
Cada nodo dispone de su propio espacio, por lo que puedo pasar rápidamente de OBUXO a OTOXO u OCARBALLO.
También tengo una pestaña TOP que agrupa los servicios que utilizo habitualmente, independientemente del nodo físico donde estén alojados.
Y una pestaña MONITORING reservada para tareas de supervisión.
Esta organización es especialmente útil cuando estás investigando un problema que afecta a varios servicios y necesitas saltar entre diferentes máquinas.
Además, Zellij permite dividir la terminal en varios paneles.
Puedo mantener una conexión SSH abierta mientras consulto otra máquina, reviso un fichero o ejecuto comandos en paralelo.
No necesito abrir nuevas ventanas del terminal ni recordar en cuál estaba trabajando.
De la navegación a la conexión SSH
El menú es deliberadamente sencillo.
Al seleccionar una máquina y pulsar Enter, se inicia una conexión SSH.
El objetivo no es introducir una capa adicional de administración, sino facilitar el acceso a las herramientas habituales de Linux.
Una vez conectado, sigo trabajando exactamente como siempre:
systemctl status nginx
journalctl -u nginx -f
htop
df -h
La ventaja es que he eliminado buena parte de la fricción previa: buscar la máquina, recordar su IP y abrir manualmente una nueva conexión.
En mi configuración, al entrar en una máquina, la conexión ocupa el espacio de trabajo necesario para utilizar la terminal cómodamente.
Y al salir, vuelvo al menú desde el que había iniciado la conexión.
Es un cambio pequeño, pero cuando realizas esta operación muchas veces al día, se agradece enormemente.
Una interfaz bonita no necesita ser gráfica
Reconozco que esta era una parte importante del proyecto.
No quería limitarme a mostrar un listado de nombres con un número delante.
Quería una interfaz agradable, alineada, con colores discretos, indicadores visuales y una distribución que aprovechase bien el espacio disponible.
La tabla contiene columnas para servicio, IP, uptime, disco, CPU y RAM.
Los servidores incorporan pequeños iconos que ayudan a reconocerlos rápidamente.
En la parte inferior aparecen las estadísticas de los nodos físicos dentro de cajas dibujadas con caracteres de terminal.
Y he procurado que el comportamiento del teclado sea consistente entre las diferentes pestañas.
Puede parecer algo puramente estético, pero tiene una consecuencia práctica: cuando una herramienta resulta agradable de utilizar, terminas utilizándola más.
Y si además permite identificar rápidamente un servidor con problemas, la estética se convierte en usabilidad.
Eso sí, hay algunos desafíos específicos del mundo terminal: las diferencias de ancho entre caracteres Unicode, el comportamiento del foco entre paneles y el espacio disponible cuando se divide la pantalla.
Son detalles que requieren ajustes, pero también forman parte de la diversión de construir estas pequeñas herramientas.
Algunas decisiones de diseño
Durante el desarrollo he procurado mantener ciertos principios.
Evitar componentes innecesarios. No quería desplegar otra aplicación web únicamente para organizar conexiones SSH. Zellij, Bash y unas consultas a Proxmox son suficientes para este caso.
No convertir el menú en un monitor en tiempo real. Las métricas sirven como referencia rápida, no como sustituto de una herramienta de observabilidad. He preferido evitar actualizaciones automáticas constantes que pudieran interrumpir la navegación o consumir recursos innecesariamente.
Separar navegación y administración. El menú identifica máquinas y facilita las conexiones. Las operaciones administrativas siguen realizándose con las herramientas habituales del sistema.
Priorizar el teclado. Una vez dentro de la consola, prácticamente todas las operaciones se pueden realizar sin utilizar el ratón.
Mantener la configuración centralizada. Incorporar una máquina nueva debe ser tan sencillo como registrarla en la configuración correspondiente, sin modificar cada pestaña individualmente.
¿Y la seguridad?
Centralizar el acceso a decenas de máquinas desde un único servidor es cómodo, pero exige prestar atención a la seguridad.
En mi caso, el servidor de administración forma parte de la infraestructura privada del homelab.
El acceso remoto debe realizarse mediante SSH, preferiblemente con autenticación por claves, y la comunicación con la API de Proxmox debe utilizar credenciales o tokens con los permisos estrictamente necesarios.
También conviene recordar que la información mostrada en el menú no sustituye a los mecanismos de autorización de cada servidor.
Zellij organiza las sesiones; no gestiona por sí mismo los permisos de acceso a las máquinas.
Precisamente por eso me gusta esta arquitectura: reutiliza mecanismos que ya existen y cuya seguridad conocemos, en lugar de crear otro sistema de autenticación para una aplicación nueva.
¿Por qué Zellij y no tmux?
La pregunta es razonable.
tmux es una herramienta fantástica, madura y extraordinariamente flexible. De hecho, podría construir gran parte de esta solución utilizando tmux.
Pero Zellij me ha resultado más agradable para este proyecto.
Sus barras de navegación, su gestión visual de pestañas y paneles, y la posibilidad de describir espacios de trabajo mediante layouts encajan muy bien con lo que quería construir.
No se trata de que Zellij sea objetivamente superior a tmux para cualquier situación.
Se trata de que, para mi forma de trabajar, proporciona una base visual muy cómoda sobre la que construir una pequeña aplicación de terminal.
Y además ha sido una buena excusa para aprender una herramienta nueva.
Conclusiones: el placer de volver a la terminal
Llevo muchos años trabajando con servidores Linux y herramientas de línea de comandos.
He utilizado interfaces web de administración, paneles gráficos, herramientas de monitorización y multitud de soluciones para conectarme a diferentes máquinas.
Pero de vez en cuando descubres una herramienta que te hace reconsiderar cómo realizas una tarea cotidiana.
Eso me ha sucedido con Zellij.
Lo que comenzó como una forma de organizar mis conexiones SSH ha terminado convertido en una consola de administración para mi clúster Proxmox.
No pretende reemplazar la interfaz web de Proxmox ni competir con plataformas de monitorización profesionales.
Su propósito es mucho más modesto: hacer que administrar mis servidores desde una terminal sea rápido, sencillo y agradable.
Y lo consigue.
Hay algo bonito en comprobar que, con herramientas relativamente pequeñas y un poco de imaginación, todavía se pueden construir interfaces extraordinariamente útiles sin salir del modo texto.
A veces, la mejor interfaz gráfica es la que no necesitas.