Docker en LXC sobre Proxmox: riesgos, compromisos y lecciones aprendidas

En los homelabs basados en Proxmox, hay una pregunta que surge con puntualidad matemática: ¿conviene ejecutar Docker dentro de un contenedor LXC o es mejor ir sobre seguro e instalarlo en una máquina virtual? Parece una decisión simple, ya que los contenedores LXC son más ligeros, rápidos y consumen menos recursos. Sin embargo, bajo esa apariencia eficiente acechan riesgos que hacen dudar a muchos usuarios.

Desde caídas completas del anfitrión hasta bloqueos del kernel o kernel panics, el debate se nutre más de la experiencia directa que de la teoría. Decenas de usuarios de homelab han compartido lo que funciona, lo que falla y lo que les habría gustado saber antes de confiar la estabilidad de sus servicios a contenedores dentro de contenedores. Esta es la visión de la comunidad sobre si meter Docker en un LXC es una genialidad, una temeridad o ambas cosas a la vez.

El atractivo: rapidez, sencillez y eficiencia

Si hay algo en lo que coinciden los usuarios de Proxmox es en que los LXC son ágiles. Arrancan en segundos, consumen muchos menos recursos que una VM y te permiten afinar la asignación de hardware con precisión quirúrgica, lo que resulta muy tentador para alojar Docker.

«Utilizo varios LXC. La gestión me resulta mucho más sencilla: sé que este contenedor hace una sola cosa y nada más», explicaba un usuario, resumiendo la filosofía de un contenedor por servicio.

Otros prefieren agrupar varios servicios dentro de un único LXC con Docker, sobre todo cuando se trata de herramientas ligeras. Para muchos es una opción cómoda y eficiente: si ya dominas Docker y los archivos de compose, meterlo en un LXC surge de forma espontánea.

Algunos van todavía más lejos: «Tengo 50 LXCs y 1 VM con Docker. No es nada difícil de administrar si automatizas las tareas habituales». Eso sí que es escala.

Los problemas: cuando Docker en LXC te juega una mala pasada

Aquí es donde empiezan las complicaciones. Un usuario compartía una experiencia reveladora: «Un proceso dentro de mi LXC con Docker provocó un kernel panic y tiró abajo todo mi host. Si hubiera sido una VM, solo se habría caído esa máquina virtual». Es el peor escenario posible, y no fue un incidente aislado.

LXC comparte el kernel del anfitrión Proxmox, por lo que si algo se descontrola dentro del contenedor, puede arrastrar consigo a todo el servidor. Varios usuarios lo han descubierto por las malas.

«Estás combinando dos frentes de seguridad distintos», advertía otro usuario. «LXC tiene vulnerabilidades y Docker también las tiene. Juntos abres vectores de ataque adicionales».

Otros se toparon con que Docker en LXC sencillamente no encaja bien con ciertas aplicaciones: «No todos los contenedores de Docker funcionan en LXC. Mi servidor de correo fallaba constantemente, probablemente por culpa de AppArmor o configuraciones similares».

Montar recursos compartidos por NFS o pasar hardware como tarjetas GPU añade más dolores de cabeza. En una VM esto se configura sin dramas, mientras que en un LXC puede convertirse en una auténtica pesadilla de permisos.

Privilegiados frente a no privilegiados: elige tu bando

Gran parte del riesgo depende de si configuras tu contenedor LXC como privilegiado o no privilegiado.

Los LXC privilegiados se comportan de forma más cercana al sistema anfitrión y permiten un acceso más directo al hardware, lo que facilita la vida a Docker, especialmente al configurar passthrough de GPU o conectar dispositivos USB. Pero también entrañan más peligro: cualquier proceso que se desmadre podría saltar el aislamiento y comprometer el host Proxmox.

Los LXC no privilegiados son bastante más seguros. Aíslan los procesos de manera estricta, pero Docker no siempre funciona de forma limpia en ellos.

Un usuario probaba esta vía alternativa combinándola con Podman sin privilegios de root: «¿Tenías el LXC en modo privilegiado? Yo opté por un LXC no privilegiado y Podman rootless. No veo cómo podría ocurrir una caída en esta configuración». Aunque ni siquiera eso ofrece garantías absolutas.

Otro usuario lo dejaba claro: «No todas las aplicaciones funcionan en modo no privilegiado. Depende de lo que le pidas hacer a tu Docker».

El término medio: las soluciones híbridas ganan terreno

Cada vez más usuarios de Proxmox eligen una postura intermedia: utilizan VMs para pilas de Docker complejas o críticas y reservan los contenedores LXC para servicios auxiliares y ligeros.

Un aficionado al homelab lo explicaba con claridad: «Uso LXC para mis servicios más importantes y tengo una VM para servicios Docker cuya caída no me preocupa demasiado. Nada de Docker sobre los LXC».

Otro prefería el camino inverso: ejecutaba Docker en LXC para servicios menores y reservaba las VMs para aplicaciones pesadas como Frigate o Immich, que exigían acceso a la GPU o un aislamiento riguroso.

Un tercero añadía: «Tengo un LXC dedicado exclusivamente a Docker donde corren mis servicios secundarios. Jamás he tenido un solo problema con Docker en LXC».

Queda claro que no existe una verdad absoluta. Todo depende de lo que valores más en tu entorno, ya sea el aislamiento estricto, la portabilidad o la sencillez de mantenimiento.

La apuesta por las VMs: estabilidad, seguridad y tranquilidad

Muchos usuarios, en especial aquellos que sufrieron fallos extraños o bloquearon su nodo Proxmox, defienden a ultranza alojar Docker en una VM.

«Por lo que entiendo, LXC tiene sus fallos de seguridad y Docker los suyos. Si los juntas, multiplicas los problemas», señalaba un usuario.

La propia documentación oficial de Proxmox sugiere, con bastante sensatez, que Docker debería ejecutarse dentro de una VM completa para garantizar un aislamiento adecuado. Además, cuando aplicas actualizaciones en Proxmox, los contenedores dentro de tu VM de Docker siguen funcionando sin inmutarse. Intentar hacer lo mismo con LXC puede darte sorpresas desagradables.

A eso se suma el reto de las copias de seguridad: «Los contenedores LXC no admiten dirty bitmaps para los backups», alertaba un usuario. «Eso significa que cada vez que lanzas una copia, el sistema tiene que leer todo el almacenamiento. Las VMs son infinitamente más eficientes en este aspecto».

Configuraciones reales: lo que la gente hace en la práctica

El usuario A ejecuta una VM con Docker y passthrough de GPU para cargas de IA, manteniendo una arquitectura limpia y modular. El usuario B gestiona 11 LXCs, uno por cada servicio, en un servidor de muy bajo consumo para controlar cada vatio. El usuario C centraliza en un único LXC todas sus aplicaciones que solo existen como imagen de Docker, argumentando que le da menos trabajo que adaptar cada servicio a un entorno nativo.

El usuario D ejecuta Docker en contenedores LXC para servicios secundarios, asumiendo algún susto ocasional como peaje a cambio de un consumo mínimo. Y el usuario E dio el salto a Kubernetes distribuido en VMs, descartando tanto LXC como Docker en LXC en favor de una infraestructura moderna y escalable.

Cada diseño refleja prioridades personales, las especificaciones del servidor y el nivel de complejidad que estás dispuesto a tolerar cuando algo se tuerce.

Conclusión: más parecido al Jenga que a una bomba de relojería

Entonces, ¿es Docker en un LXC una bomba de relojería a punto de estallar? En realidad se parece más a una partida de Jenga. Puedes levantar una estructura esbelta, elegante y eficiente, pero si tocas la pieza equivocada (actualizar el kernel indebido, lanzar un contenedor problemático o errar en un archivo de configuración), la torre puede derrumbarse con estrépito.

Si tu infraestructura se limita a herramientas internas y te divierte trastear, Docker en LXC funciona perfectamente. Entra conociendo los riesgos y ten a mano un plan de recuperación: los snapshots, las copias de seguridad externas y el endurecimiento de la configuración serán tus mejores aliados.

Por el contrario, si alojas servicios esenciales (todo lo expuesto a internet o que gestione autenticación, bibliotecas multimedia, modelos de IA o APIs públicas), conviene montar una VM. El pequeño sobrecoste de recursos compensa con creces la tranquilidad que ganas.

Y no olvides que esto es tu propio homelab. No necesitas dar con la arquitectura perfecta desde el primer día: experimenta, detecta los fallos rápido y reconstruye con mejor criterio.