No le doy mantenimiento a mi Homelab

• Para reducir la carga de operar un Homelab personal, se enfoca en una configuración de servidor único y en actualizaciones automáticas, eliminando así la mayoría de las tareas de ajuste del día a día
• Al consolidar varios servidores en uno solo, disminuyó la complejidad del entorno y el mantenimiento medido por cantidad de servidores se redujo en 75%
• Una Raspberry Pi 4 queda aparte con Home Assistant OS, y la red se deja a las actualizaciones automáticas y programadas de UniFi, reduciendo los puntos de administración manual
• Los servicios de Docker se actualizan con un crontab que ejecuta docker compose pull y docker compose up -d una vez por semana, mientras que el crontab de root se usa sobre todo para respaldos
• Salvo emergencias, el mantenimiento mensual toma unos 15 minutos, y posponer apt update y los reinicios casi no tiene impacto inmediato en los servicios

---

Infraestructura simplificada

• Los servicios del Homelab se consolidaron de varios equipos en un solo servidor
  • Antes se usaban 4 servidores, pero ahora los servicios están reunidos en un único servidor físico
  • En lugar de clústeres, hipervisores o nube híbrida, todo corre en un solo equipo físico en el sótano
  • Esta simplificación redujo en 75% la carga de mantenimiento medida por servidor
• La Raspberry Pi 4 sigue separada, pero Home Assistant OS gestiona sus propias actualizaciones, así que la carga administrativa es baja
  • Técnicamente se parece más a un servidor, pero en la práctica se siente más como un dispositivo IoT que se mantiene solo
• El equipo de red funciona con una instalación de UniFi en un mini rack
  • Incluye una UniFi Dream Machine Pro, un switch y varios AP
  • Como admite actualizaciones automáticas y programadas, el equipo de red tampoco necesita intervención manual frecuente

Actualizaciones automáticas de software y respaldos

• Las actualizaciones de los servicios Docker se ejecutan semanalmente mediante una sola entrada de crontab en el servidor
  • 0 0 * * 0 docker-update
  • docker-update ejecuta sudo docker compose pull y sudo docker compose up -d en cada directorio bajo ~/docker/*/
• El crontab del usuario root se usa principalmente para respaldos
  • Genera un reporte del sistema todos los días
  • Crea dumps de PostgreSQL para Immich y Piped
  • Hace respaldos con rsync hacia un pool ZFS de Plex, el servidor web, la configuración de Nginx, los directorios de Docker y los archivos SSH
  • En el respaldo de los directorios de Docker se excluyen bases de datos, cachés, archivos temporales y algunas rutas de logs
• Lo único que queda como trabajo manual es ejecutar apt update, apt upgrade, apt autoremove y reiniciar si hace falta
  • Ese trabajo toma alrededor de 60 segundos
• Si no hay una situación urgente, el tiempo de mantenimiento es de unos 15 minutos al mes
  • Aunque no se conecte por SSH ni actualice nada durante un mes, en la práctica no afecta los servicios
  • Probablemente no fallaría aunque no se toque por más de 6 meses, pero no hay planes de probarlo a propósito
• La configuración actual ofrece un equilibrio entre privacidad, seguridad y conveniencia incluso con una agenda ocupada

[GN⁺]

Opiniones en Lobste.rs

• Opero mi servidor casero de forma similar.
  En Debian tengo activadas las actualizaciones de seguridad desatendidas, todo corre en contenedores rootless con versiones fijadas, y systemd los administra mediante Podman Quadlet.
  El auto-update de Podman se encarga de actualizar los contenedores, y los timers de systemd se ocupan de tareas recurrentes como respaldos y limpieza de imágenes.
  Solo entro para reiniciar cuando hay una actualización del kernel o cuando subo la versión de una imagen, y eso lo maneja Ansible.

  • Me confunde la parte donde se usan juntos “versiones fijadas” y “Podman auto-update”.
    Entendía que fijar la versión significa no traer actualizaciones automáticamente, pero en la práctica parece que sí se actualiza, así que no me queda claro si se están actualizando cosas distintas.
  • Llevo más de 10 años usando una configuración casi igual, y cada dos años la subo a la stable más reciente.
    El único equipo que administro por separado es un router, que usa OpenBSD, así que lo actualizo más o menos cada 6 meses cuando sale una nueva versión.
    Ambos son aburridamente estables.

• Algo parecido, pero no actualizo nada hasta que aparece alguna función que quiero.
  Lo bueno del software autoalojado es que puedo actualizar según mi propio calendario.
  Si todo funciona bien, solo se accede mediante Tailscale y no está expuesto directamente a internet, entonces, salvo por fallas de hardware, es estable simplemente dejándolo quieto.

  • Me intriga por qué sería distinto que una aplicación esté expuesta directamente a internet o mediante Tailscale.
    Los datos que llegan a la aplicación al final son los mismos, así que me parece que podrían explotarse las mismas vulnerabilidades.

• Si estás en ese punto, es una situación bastante buena.
  Yo también intento llegar ahí, pero todavía no lo logro del todo.
  Las actualizaciones mayores de Debian siguen requiriendo trabajo manual cada 2 años: "Issues to be aware of for trixie", "Obsolescence and deprecation", "Cleanup after the upgrade"
  Un Ansible viejo no puede manejar sistemas Debian recientes, así que cuando actualizo el servidor Debian también tengo que subir la versión de Ansible, y al final corregir los playbooks para que funcionen con el Ansible nuevo.
  Ahora intento reducir eso usando más contenedores Docker, pero parece difícil reemplazar Ansible por completo.
  También hay servicios en línea que no quiero alojar yo mismo, como freeDNS y dynv6.net, y ellos también hacen cambios que rompen cosas de vez en cuando.
  Aun así, en general está bastante bien.
  Para ser honestos, la administración de un homelab “sin mantenimiento” en realidad se la estamos delegando a los desarrolladores open source de todo el mundo que mantienen el software, los paquetes y las imágenes de Docker que usamos.

• Me cuesta llamar “homelab” a mi configuración, pero es un NAS con unRAID que corre varios contenedores Docker.
  Una de las razones por las que estoy conforme pagando por unRAID es que su soporte para Docker es razonablemente bueno, permite actualizar contenedores automáticamente con un plugin y el resto del mantenimiento también es bastante simple.

• Personalmente, me hace algo de ruido que un “lab” se parezca más a un lugar para experimentar, y que el experimento en sí no necesariamente tenga que mantenerse.
  Usar contenedores tiene ventajas y desventajas.
  En algunos proyectos, los contenedores son un mecanismo de distribución de primera clase, así que por esa vía puedes recibir actualizaciones correctamente.
  Pero parece que mucha gente corre contenedores con mantenimiento dudoso, y creo que de ahí saldrán muchos problemas.
  La clave está en identificar cuál es la vía oficial para recibir actualizaciones del software que uso.
  Yo opero principalmente clones de RHEL con actualizaciones automáticas, y Nagios me avisa si hace falta reiniciar.
  La mayoría de los servicios están dentro de RHEL o EPEL, así que requieren bastante poco mantenimiento.

• Para el mantenimiento de mi homelab, pyinfra me dio justo el nivel adecuado de pereza.
  Puedo dejar el proceso de configuración escrito como código, es especialmente útil para cosas como archivos de configuración, y si hace falta puedo llamar a apt sin ponerme a pensar cómo manejaría esto en nix.
  No es una herramienta tremendamente inteligente, pero es mejor que un único script de shell, y quiero seguir desarrollando más ese enfoque.
  Si usas codificación con agentes, también está el bonus de poder mostrarle a Claude los archivos de pyinfra y recibir ayuda para depurar la configuración.

• Uso NixOS en el servidor y lo actualizo de vez en cuando cuando me acuerdo.
  Casi siempre se reduce a nix flake update && nix run .#deploy, así que no me preocupa demasiado.

• Estoy en una situación muy parecida, y aunque no me gusta admitirlo, en buena medida se debe simplemente a que la configuración terminó siendo más simple.
  Antes me gustaba tener todo un stack de observabilidad, incluso con logs rotados, pero en los últimos más de 2 años todos los dolores de cabeza recientes vinieron de problemas menores causados por esa complejidad.
  Cosas como que el disco se llenara por los logs y las métricas.
  La solución es muy fácil, pero ya no quiero seguir lidiando con esas cosas.

• Me gusta Watchtower para mantener actualizadas las configuraciones de docker-compose.
  https://hub.docker.com/r/nickfedor/watchtower
  Tiene opciones de configuración bastante buenas para seguir subiendo versiones y, a la vez, tener en cuenta hasta cierto punto los cambios importantes.
  En el sistema operativo base dejo Debian LTS solo con actualizaciones desatendidas activadas, y entro a reiniciar cuando sale un kernel nuevo.
  Realmente no da mucho trabajo, y estoy de acuerdo con lo de menos de 15 minutos al mes.