Estrategias de actualización en Proxmox: patrones de automatización reales
Hay un momento familiar que tarde o temprano le llega a todo usuario de Proxmox. Inicias sesión en la interfaz web, quizá solo para revisar la consola de una VM, y ahí está: actualizaciones disponibles. Actualizaciones del kernel y parches de seguridad, un pequeño recordatorio de que la entropía vuelve a ganar terreno.
Te dices que ya te encargarás más tarde. Ese "más tarde" pasa a ser la próxima semana, la próxima semana se convierte en "cuando termine este proyecto" y al final te encuentras ante un clúster que técnicamente funciona, pero solo porque nadie ha soplado demasiado fuerte cerca de él.
Esto es algo que rara vez se dice en voz alta sobre el software de Proxmox Server Solutions en casa o en entornos pequeños. Proxmox VE es sumamente sólido, pero no resuelve la parte más difícil por ti: decidir cómo deben realizarse las actualizaciones entre el host, tus VMs, tus contenedores LXC y el caos de Docker que hayas montado encima.
Pregunta a diez usuarios de Proxmox cómo gestionan sus actualizaciones y obtendrás once respuestas distintas. La mayoría se sitúa en algún punto intermedio entre una automatización impecable y un "reinicié y recé para que arrancara".
La paradoja de las actualizaciones en todo homelab
Sobre el papel, actualizar es simple: mantén los sistemas parcheados, reduce riesgos y sigue con tu vida. En la práctica, actualizar impone respeto porque tú eres el técnico de guardia, el plan de marcha atrás y el autor del informe de incidencias.
A diferencia de los entornos corporativos, la mayoría de los despliegues de Proxmox no disponen de clústeres de pruebas, ventanas de mantenimiento aprobadas por comités ni contratos de soporte de pago al otro lado del teléfono. Lo que sí tienen son snapshots, copias de seguridad y un profundo apego emocional al tiempo de actividad. Por eso las estrategias de actualización tienden a agruparse en varios bandos bien definidos.
Grupo uno: "Instala unattended-upgrades y listo"
Es el enfoque minimalista. Instalas unattended-upgrades en tus LXCs y VMs, dejas que el sistema se parche en segundo plano y confías en que Debian no te arruine el fin de semana.
A muchos usuarios esto les funciona sorprendentemente bien. Los contenedores y las VMs son fáciles de restaurar, por lo que si algo falla, reviertes el cambio, tomas nota y sigues adelante. Hay quien extiende esta filosofía al propio host de Proxmox, aunque ahí es donde suelen empezar a flaquear los nervios.
La lógica es sencilla: si un contenedor cae, resulta molesto; si cae el host, la noche se vuelve mucho más larga. Por eso a menudo verás actualizaciones desatendidas en todas partes excepto en el host. El host recibe actualizaciones manuales, ejecutadas cuando las copias de seguridad están frescas y nadie en casa está reproduciendo nada importante por streaming.
Es una postura prudente y tranquila, y para mucha gente resulta más que suficiente.
Grupo dos: Ansible, en todas partes y a la vez
Luego están los entusiastas de Ansible. Son las personas que miraron la tarea de iniciar sesión en veinte VMs y dijeron: "Ni hablar".
Con Ansible, actualizar pasa a ser la pulsación de un botón o una tarea programada. Las VMs se actualizan por SSH y los LXCs mediante plugins de conexión específicos. Los contenedores Docker descargan imágenes nuevas, se reinician y limpian las sobrantes, se envían notificaciones y los reinicios ocurren solo si son estrictamente necesarios.
Para algunos, el proceso termina ahí. Para otros, es donde empieza lo interesante: snapshots antes de cada actualización, reversión automática si algo falla, actualizaciones mensuales del host, semanales para las VMs y refresco diario de contenedores. De pronto el homelab empieza a parecerse sospechosamente a una plataforma profesional.
Hay una broma recurrente en estos entornos: ejecutas el playbook, reinicias si hace falta y rezas. Aunque ese rezo resulta mucho más sereno cuando sabes que hay un snapshot esperando por si las cosas se tuercen.
La era de Watchtower y su declive gradual
Los contenedores Docker introducen su propia dosis de incertidumbre a la hora de actualizar. Ahí apareció Watchtower, la herramienta que prometía mantener tus contenedores al día mientras dormías plácidamente.
Durante un tiempo funcionó. Los contenedores se actualizaban, los servicios seguían en línea y todo el mundo estaba contento.
Luego los discos se llenaron de imágenes antiguas, los contenedores empezaron a reiniciarse en momentos inoportunos y el ritmo de desarrollo se frenó en seco. Algunos usuarios siguieron utilizándolo añadiendo banderas de limpieza y tareas cron. Otros abandonaron el barco por completo, sustituyendo Watchtower por despliegues controlados con Ansible o herramientas que solo envían notificaciones para que una persona mantenga el control.
Nadie concluyó que la automatización fuera mala. Lo que inquietaba era la automatización a ciegas, porque actualizar está bien, pero las caídas sorpresa no.
Actualizaciones manuales: la estrategia infravalorada
Entre tantos scripts y paneles de control existe un grupo menos visible que opta por algo radical: actualizar a mano.
Una vez al mes inician sesión en la interfaz de Proxmox, leen el registro de cambios, pulsan actualizar, reinician y siguen adelante. Las VMs se actualizan de la misma forma, a menudo en paralelo mediante paneles de tmux o varias sesiones SSH simultáneas.
Parece ineficiente hasta que reparas en que estos entornos suelen ser más compactos: diez VMs en vez de cincuenta y un puñado de servicios en lugar de una plataforma masiva. Para ellos, las actualizaciones manuales son rápidas, previsibles y controladas. Si algo se rompe no hay misterio, porque sabes con certeza qué ha cambiado. Estabas ahí presente cuando ocurrió.
Snapshots: el sistema de apoyo emocional
Cualquiera que sea la estrategia elegida, los snapshots son el hilo conductor que lo sostiene todo. Quienes automatizan los valoran, quienes actualizan a mano confían en ellos y todos duermen más tranquilos sabiendo que existen.
Los contenedores LXC se benefician en especial de este planteamiento. Son ligeros, se congelan en un snapshot en segundos y se restauran sin esfuerzo. Por eso muchos usuarios se sienten cómodos automatizando por completo las actualizaciones de LXC mientras mantienen a las VMs y a los hosts bajo una supervisión más estrecha.
Los snapshots no hacen que actualizar sea seguro; hacen que el fallo sea tolerable y recuperable, y esa distinción lo cambia todo.
Actualizaciones del host: donde muere la valentía
Casi todo el mundo coincide en un punto: automatizar las actualizaciones del host de Proxmox parece una temeridad.
El host es diferente porque gestiona el almacenamiento, las redes y cada VM y contenedor que te importa. Si no levanta, nada más lo hará.
Por eso las actualizaciones del host suelen ser más lentas, deliberadas y manuales. Los calendarios mensuales son habituales. Los saltos de versión mayor se posponen hasta que la comunidad ha probado el terreno a fondo. Los reinicios se programan en horarios valle, a menudo con alguien físicamente cerca de la máquina, por si acaso. Esa prudencia nace del respeto al host, más que del miedo.
Un abanico de opciones, no una solución única
De todas estas alternativas no surge una única práctica perfecta, sino un abanico continuo de posibilidades.
En un extremo se sitúan la automatización completa, las actualizaciones nocturnas, los sistemas autorreparables y la lógica de reversión automática. En el otro están las actualizaciones manuales, la lectura atenta de las notas de la versión y los reinicios pausados.
La mayoría de los administradores se queda en un punto intermedio: automatizado donde resulta seguro, manual donde impone respeto y con la flexibilidad necesaria para adaptarse cuando falta tiempo. La lección de los homelabs con Proxmox es que la meta es un esfuerzo proporcionado, sabiendo que el esfuerzo cero no existe.
Las actualizaciones como reflejo de la confianza
La forma en que actualizas tu entorno Proxmox dice mucho de en qué confías. Unos confían en la automatización y otros en su propio criterio técnico. La mayoría confía en las copias de seguridad, los snapshots y la posibilidad de deshacer errores.
Y sí, a veces todo se reduce a ejecutar un playbook, reiniciar y cruzar los dedos para que la consola vuelva a responder en verde.
Cuando lo hace, cuando todo arranca limpio y los servicios siguen rodando como si nada hubiese pasado, se siente esa pequeña satisfacción de saber que tu estrategia funcionó, al menos esta vez. En un homelab, cada actualización es una tarea de mantenimiento y un pequeño acto de fe al mismo tiempo.