Dejar los Proxmox Community Scripts: por dónde empezar

Si tus servicios en Proxmox funcionan bien, no necesitas reconstruir todo el homelab para dejar de usar los Community Scripts. Mantén activos los servicios actuales, aprende cómo está montado uno de ellos, reprodúcelo a mano o con tu propia automatización y migra paso a paso. Así resuelves el problema real: depender de una infraestructura que no entiendes del todo.

Cualquiera que empiece con Proxmox puede acabar fácilmente con un entorno de servicios clave desplegado a base de scripts cómodos. Home Assistant corre en una VM. AdGuard Home, Tailscale, Paperless-ngx, Immich, Uptime Kuma, una base de datos documental, paneles y otros servicios diarios se ejecutan en contenedores LXC. Todo funciona, incluidas las actualizaciones. Pero, al cabo de un año, surge una pregunta incómoda: si esto se rompiera mañana, ¿sabrías reconstruirlo sin volver a pulsar el mismo botón de instalación? Responder a eso enseña mucho más que limitarse a arrancar software.

¿De verdad necesitas dejar los Community Scripts?

No, pero sí conviene dejar de verlos como una caja mágica. Los administradores con más experiencia repiten siempre la misma idea: los Community Scripts son útiles porque ahorran tiempo. Cambiar cada servicio que ya funciona por una arquitectura más enrevesada solo para demostrar que sabes hacerlo no supone una mejora automática. Usar automatización está muy bien; depender de ella a ciegas es donde empiezan los problemas.

Imagina que un script crea un LXC con Debian, añade un repositorio de paquetes, escribe un archivo de configuración, habilita un servicio e instala una utilidad para actualizar. Ninguno de esos pasos tiene misterio, pero un instalador que se ejecuta con un solo comando se los oculta por completo a quien está aprendiendo.

Por eso tu primera migración no tiene por qué mover nada. Elige un servicio que ya tengas y revisa cómo se instaló. Identifica los paquetes del sistema operativo, los archivos de la aplicación, las rutas de datos, la unidad de servicio, los puertos, los permisos, los puntos de montaje y el método de actualización, y anótalo todo en un lugar bajo tu control. Cuando seas capaz de explicar cómo funciona ese servicio, el Community Script dejará de ser imprescindible.

Es un punto de partida mucho más prudente que reemplazar diez servicios en producción a la vez solo para descubrir que tu flamante arquitectura "limpia" tiene diez formas nuevas de fallar.

El hub de Proxmox en Mr.PlanB resulta útil en este punto porque el tipo de invitado es solo una capa. El almacenamiento, la red, el backup, la configuración del clúster y los ajustes del propio huésped influyen directamente en la facilidad con la que se recupera un servicio.

¿Cuál es el paso más sencillo para continuar?

Crea tú mismo un contenedor LXC básico con Debian. Es la recomendación más habitual porque elimina la abstracción sin obligarte a cambiar de arquitectura. Si la mayoría de tus servicios ya se desenvuelven bien en LXC, no hace falta introducir Docker, Podman, Kubernetes, Terraform y un modelo de almacenamiento distinto al mismo tiempo.

Configura un contenedor Debian modesto en Proxmox, asígnale red y almacenamiento. Instala un servicio sencillo a mano y ajústalo. Haz una copia de seguridad, rómpelo a propósito y restáuralo. Aprenderás más con ese ejercicio práctico que sustituyendo cada LXC por una máquina virtual completa.

Proxmox clasifica sus instancias LXC como contenedores de sistema. Comparten el kernel del host en lugar de emular una máquina entera, y por eso su sobrecarga en ejecución suele ser mucho menor que la de una VM tradicional. Además, Proxmox los integra de forma nativa con sus herramientas de almacenamiento, cortafuegos, backup y alta disponibilidad.

La contrapartida es el aislamiento, ya que los contenedores dependen del kernel del anfitrión. Proxmox aplica restricciones mediante namespaces, AppArmor, seccomp, cgroups y otros mecanismos, pero su propia documentación recuerda que las máquinas virtuales completas ofrecen un aislamiento más robusto.

Esa es una razón de peso para combinar enfoques. Un servicio de DNS interno encaja de maravilla en un LXC. Una carga de trabajo que requiera mayor aislamiento puede ir en una VM. Un servicio cuyo desarrollador ofrece soporte mediante Docker Compose encajará mejor en una VM con Docker. La pureza arquitectónica no importa tanto; lo fundamental es tener claro por qué cada carga de trabajo está donde está.

¿Conviene ejecutar Docker en un LXC o en una VM?

Para un diseño ordenado en Proxmox, una VM dedicada es la opción más fácil de justificar.

Proxmox diferencia con claridad los contenedores de sistema de los contenedores de aplicaciones, y su documentación actual de LXC recomienda ejecutar contenedores de aplicaciones como Docker dentro de una VM de QEMU. Así Docker cuenta con su propio límite a nivel de kernel y se conservan ventajas propias de las VMs, como un aislamiento más firme frente al host.

El esquema mental también resulta más limpio. Proxmox gestiona la VM, dentro corre Debian o tu distribución Linux preferida, Docker administra los contenedores de aplicaciones y Compose define cómo se articulan las piezas de cada servicio.

Compose funciona especialmente bien para herramientas como Immich o Paperless-ngx, ya que la definición de la aplicación queda recogida en un archivo YAML legible que detalla servicios, redes, volúmenes, variables de entorno y dependencias. Puedes guardar ese archivo en un repositorio de Git en lugar de depender de una lista de comandos de instalación anotados deprisa.

Varios administradores de homelab prefieren tener una única VM de Docker para múltiples servicios. Otros reparten las cargas en un puñado de VMs: una de producción siempre encendida, otra de pruebas, Home Assistant y una máquina dedicada a multimedia. Si la memoria RAM no sobra, cualquiera de estos dos esquemas es más fácil de mantener que crear una VM completa para cada pequeña utilidad.

Conviene no cambiar una caja negra por otra. Descargar una imagen de contenedor desconocida sigue implicando confiar en el proceso de compilación de un tercero, por lo que dejar los Community Scripts solo traslada tus decisiones sobre la cadena de suministro a otro punto. El principio se mantiene: debes saber qué estás ejecutando, dónde residen los datos persistentes y cómo recuperarlos.

¿Por qué Ansible aparece tanto como siguiente paso?

Ansible transforma la pregunta "¿cómo instalo esto?" en "¿puedo describir esta instalación de forma reproducible?".

Los playbooks de Ansible son definiciones de automatización en YAML que ejecutan tareas en sistemas gestionados, y la documentación oficial los describe como planos de automatización para desplegar y configurar nodos. Tras montar un LXC a mano, son el paso natural que conviene aprender. Supongamos que tu proceso manual incluye:

1. Crear un huésped con Debian.
2. Instalar cinco paquetes.
3. Añadir un repositorio.
4. Crear una cuenta de servicio.
5. Escribir dos archivos de configuración.
6. Montar una ruta NFS.
7. Habilitar e iniciar la aplicación.

Hacerlo a mano una vez te enseña qué necesita el servicio. A la quinta repetición es solo trabajo mecánico, y ahí es donde Ansible marca la diferencia. El playbook se convierte en una descripción ejecutable de la instalación que puedes guardar en Git, revisar con control de versiones y volver a lanzar siempre que necesites reconstruir la máquina.

Me pareció la conclusión más valiosa del debate, porque no te obliga a elegir entre un script comunitario de un solo clic y hacerlo todo a mano para siempre. Puedes entender tu infraestructura y automatizarla a la vez.

¿Hace falta meter Terraform también?

Probablemente no desde el primer día. Algunos usuarios avanzados definen la infraestructura de los huéspedes con Terraform u OpenTofu y luego emplean Ansible para configurar el interior. El código de infraestructura establece que la VM de Immich necesita cierta cantidad de vCPU, memoria, red y una conexión NFS, mientras que Ansible gestiona los paquetes y los archivos de la aplicación. Es un modelo razonable cuando el entorno adquiere cierto tamaño.

Pero también es una vía rápida para convertir un homelab pequeño en un segundo trabajo a tiempo completo, añadiendo capas de automatización más deprisa de lo que puedes asimilarlas. Si nunca has usado Ansible, empieza solo por ahí. Consigue que un playbook funcione sobre un LXC o una VM creados a mano, súbelo a Git, borra el huésped de prueba y vuelve a levantarlo. Cuando esa tarea te resulte rutinaria, el aprovisionamiento de infraestructura será un paso lógico.

Kubernetes queda aún más lejos. Varios participantes en la conversación lo mencionaron como una opción futura, mientras que otros con experiencia profesional en Kubernetes recordaron que su complejidad supera con creces la de Docker Compose. Con apenas una veintena de servicios en un homelab, cada gramo de complejidad extra debe justificarse con claridad.

¿Se puede migrar sin tener que rehacer todo?

Sí, y este es sin duda el punto práctico más importante. Un servicio que funciona no tiene por qué trasladarse solo porque hayas decidido cuál será tu arquitectura ideal en el futuro.

Migra un servicio cada vez. Empieza por algo prescindible o fácil de recuperar, no por Immich ni por el DNS del que depende toda tu casa. Construye el reemplazo en paralelo al servicio existente, restaura o copia su configuración y sus datos, y verifica la red, el almacenamiento, las actualizaciones, la monitorización y los backups. Después redirige el tráfico y conserva la instancia antigua el tiempo necesario para confirmar que la nueva responde con estabilidad.

Es además un momento perfecto para separar el estado de la aplicación del propio huésped. Si un servicio guarda datos importantes en un NAS, documenta con precisión cómo se monta el recurso compartido y qué UID, GID, permisos y dependencias de red exige. La integración del almacenamiento suele ser mucho más difícil de reconstruir que el propio paquete del programa.

Un usuario describió una estructura sencilla con una VM de Docker que monta carpetas NFS desde un NAS y las enlaza mediante bind-mounts a volúmenes de Docker. Otro incluía los recursos NFS en las definiciones de infraestructura como parte de la configuración del huésped. El método exacto importa menos que tu capacidad para reproducirlo: si reconstruir un servicio depende de acordarte de un comando de montaje que escribiste hace dieciocho meses, sigues dependiendo de tu memoria.

¿Cómo gestionar las actualizaciones sin los scripts?

No cambies un botón de actualizar por veinte listas de tareas manuales. Los contenedores LXC nativos pueden seguir utilizando el gestor de paquetes habitual de su sistema operativo, y las actualizaciones de aplicaciones pueden seguir el procedimiento oficial del desarrollador. En el caso de aplicaciones en contenedores, fija versiones concretas en Compose y actualízalas de manera deliberada.

Ansible puede asumir las tareas repetitivas de mantenimiento del sistema operativo en múltiples huéspedes, pero las actualizaciones automáticas requieren criterio, y aplicar cada parche en el minuto en que se publica no equivale a un buen mantenimiento. Un enfoque más controlado consiste en mantener las versiones a la vista, probar primero en un entorno de pruebas cuando sea posible, leer las notas de versión de los servicios críticos y desplegar el cambio mediante la misma automatización que levantó la máquina.

La gran ganancia es un ciclo de vida único y documentado que abarca tanto la instalación como el mantenimiento. Si solo sabes reconstruir un servicio con un script de instalación y solo sabes actualizarlo con otra utilidad distinta, tienes dos sistemas que asimilar. Cuando tu playbook o tu archivo Compose describe el estado en producción, esa brecha se reduce casi por completo.

¿Consumirá demasiada RAM migrar todo a VMs?

Las máquinas virtuales consumen más recursos que los contenedores LXC equivalentes, pero si eso supone un problema real depende de tu servidor y de la carga de trabajo.

Proxmox presenta los contenedores como una alternativa ligera frente a las máquinas virtuales completas porque comparten el kernel del host. Una VM cuenta con su propio kernel y hardware virtualizado, lo que genera una sobrecarga superior. Ese consumo no las vuelve ineficientes: simplemente aprovecha su aislamiento donde realmente aporte valor.

Un patrón muy sensato surgido del debate consistía en aplicar aislamiento estricto en servicios expuestos a internet y utilizar LXC sin privilegios para las herramientas internas de confianza. Otra alternativa era una única VM dedicada a Docker que albergue múltiples contenedores. Ambos modelos evitan malgastar memoria dando una VM entera a cada utilidad pequeña.

Si dudas, compruébalo tú mismo. Levanta una VM con Debian y un contenedor LXC con Debian ejecutando la misma carga de trabajo sencilla, y mide el uso de memoria en reposo, el espacio en disco, el tamaño del backup, el tiempo de arranque y el esfuerzo de mantenimiento en tu propio hardware. Eso te aportará datos más útiles que cualquier discusión teórica entre contenedores y máquinas virtuales.

Si todavía estás configurando la plataforma base, consulta la guía de instalación de Proxmox antes de añadir capas de automatización adicionales.

El objetivo: saber reconstruir lo importante

Dejar atrás los Proxmox Community Scripts consiste en eliminar incógnitas; deshacerse de los scripts en sí es secundario.

Mantén los servicios que funcionan y aprende a fondo cómo opera uno de ellos. Construye un reemplazo limpio para ese servicio concreto, guarda su configuración en Git, automatiza las tareas mecánicas y verifica las copias de seguridad. Luego pasa al siguiente.

Es muy posible que termines con contenedores LXC gestionados a mano, una VM con Docker, playbooks de Ansible y un par de Community Scripts cumpliendo tareas que no tienes ninguna necesidad de reinventar. Es un resultado perfectamente válido, siempre que entiendas cómo funciona cada elemento.