Proxmox 9.1 puede ejecutar contenedores Docker, pero no como imaginas
Proxmox 9.1 puede ejecutar contenedores Docker, pero lo hace convirtiendo cada imagen OCI en un invitado LXC, sin que intervenga ningún motor Docker. La mañana en que llegó la función, probablemente algún administrador de clúster se recostó en su silla, miró fijamente el registro de cambios de Proxmox 9.1 y murmuró: "No puede ser que lo hayan hecho de verdad". Durante años, ejecutar Docker en Proxmox de forma "nativa" ha sido una especie de ilusión en el mundo del homelab. Había quien envolvía Docker dentro de LXC, otros lo metían en máquinas virtuales ligeras y unos pocos valientes simulaban que todo iba bien mientras ignoraban las quejas ocasionales del kernel. Cada uno tenía su truco y cada uno arrastraba sus marcas de guerra.
Proxmox 9.1 introdujo un nuevo método: contenedores basados en OCI que se comportan como invitados LXC ligeros creados directamente a partir de imágenes de Docker. De la noche a la mañana, un rincón del sector de la infraestructura se llenó de publicaciones, comentarios y vídeos explicativos en YouTube. Algunos estaban entusiasmados, otros confundidos, y otros advertían a los demás de que, por favor y por el bien de la disponibilidad del servicio, respirasen hondo antes de lanzarse.
Proxmox 9.1 OCI: The Weird New Way to Run Containers (Not a Docker Replacement!)
La mejor forma de comprender cómo se recibió la función es escuchar a quienes la probaron a fondo durante esas primeras horas. Proxmox brindó técnicamente a los usuarios una forma de "ejecutar contenedores Docker", pero lo que obtuvieron es un híbrido con el sello propio de Proxmox: ingenioso, prometedor, un poco peculiar y no un sustituto de Docker, al menos por ahora.
La reacción inicial: esperanzada, pero prudente
Una de las primeras respuestas captó perfectamente el ambiente: "Creo que no voy a sustituir mis máquinas virtuales todavía, pero me gusta la idea y la dirección que toma". Muchos usuarios ejecutan contenedores con Portainer dentro de una máquina virtual dedicada porque les proporciona un aislamiento limpio, espacios de nombres y la operativa conocida de Docker, y esos usuarios no tienen prisa por desmontar ese despliegue de repente.
Otro usuario reconoció que le gustaba demasiado la gestión de espacios de nombres de Docker como para renunciar a ella. Para él, agrupar contenedores con límites de red claros y puertos asignados bajo una única dirección IP es la base de todo su diseño autoalojado, mucho más allá de una simple comodidad. En ese sentido, a varias personas les decepcionó que los contenedores OCI de Proxmox se comporten como LXC, donde cada uno recibe su propia IP y eso es todo. ¿Quieres una docena de servicios colgando de una sola IP con puertos diferentes? Mala suerte. Un proxy inverso podría ayudar, pero ese no era el objetivo.
Aun así, quienes trabajan con recursos limitados vieron un potencial evidente. Ejecutar máquinas virtuales completas para servicios mínimos resulta un desperdicio, y los LXC que alojan Docker pueden presentar comportamientos anómalos según las funciones del kernel. Que Proxmox despliegue una carga de trabajo similar a un contenedor sin Docker, Podman ni capas de sistema operativo intermedias es un avance notable para equipos pequeños.
Entonces surgió la pregunta que marcó el tono del resto del debate: "¿Cuál es el caso de uso real?". Resultó que la gente tenía muchas respuestas y también muchos reparos.
La primera oleada de confusión: un momento, ¿cómo funciona esto realmente?
El error más común en la conversación fue pensar que Proxmox ejecutaba "Docker dentro de contenedores". Varios intentaron corregirlo, algunos con delicadeza y otros de forma más tajante.
Muchos comentaristas incidieron en el mismo punto central: Proxmox convierte una imagen OCI en un LXC. El contenido del contenedor procedente de la imagen se convierte en un sistema de archivos ligero para un invitado LXC privilegiado. No hay ningún motor Docker, Podman ni demonio de Docker involucrado. No ejecutas docker ps, no supervisas el socket de Docker ni gestionas pilas de múltiples contenedores.
El proceso es más bien:
- Descargar una imagen de Docker
- Desempaquetar su sistema de archivos
- Usar eso como el sistema de archivos raíz de un LXC
- Iniciarlo como un servicio del sistema
Es ingenioso, pero abre la puerta a problemas si la imagen espera un comportamiento que solo un entorno de ejecución de Docker proporciona, como reinicios efímeros, montajes consistentes, supuestos de red o sistemas de archivos superpuestos (overlay). Las imágenes de Docker no se diseñaron para ser sistemas de archivos raíz completos, y eso puede pasarte factura.
Por eso un participante escribió simplemente: "La mayoría de los contenedores Docker no me funcionan. Por eso es una revisión tecnológica". Exacto, ahí está el quid de la cuestión.
El problema de las actualizaciones
Casi todo el mundo coincidió en el mayor dolor de cabeza: actualizar contenedores OCI en Proxmox resulta engorroso en este momento.
Con un contenedor en Docker, basta con hacer un pull y reiniciar. El entorno de ejecución descarga las capas nuevas y el carácter efímero del contenedor evita preocuparse por lo que ocurra con el sistema de archivos raíz por debajo.
En Proxmox, tu LXC derivado de OCI se comporta como cualquier otro LXC, lo que implica que mantiene estado. A menos que tengas mucho cuidado con el almacenamiento montado, actualizar supone:
- Reconstruir una instancia nueva
- Volver a conectar los montajes
- Copiar la configuración
- Reemplazar el contenedor antiguo
No resulta elegante. Un creador de contenido en YouTube recomendó ese método por ahora, y sinceramente, así tendrán que ser las cosas hasta que Proxmox añada un flujo real de actualización. Un usuario resumió bien la situación actual: "Quizá use SMB en vez de volúmenes, si es que eso funciona, ni idea".
Montajes, red y aspectos complejos
Varios usuarios tropezaron con limitaciones tempranas.
Los montajes compartidos no resultan evidentes
Alguien intentó montar recursos compartidos SMB y se encontró con un muro. Otros señalaron que LXC sí admite montajes de tipo bind locales, pero no de una forma que imite con limpieza el comportamiento de un volumen de Docker.
La red se comporta como LXC en lugar de Docker
Si vienes del modelo de Docker de "una IP, muchos puertos", pasar a que "cada contenedor tenga una pila IP completa" choca bastante. Proxmox asigna automáticamente a sus contenedores OCI configuraciones de red como a los LXC, incluyendo direcciones MAC, bridges y reglas de cortafuegos. Un proxy inverso soluciona esto, pero añade una configuración extra que la gente no esperaba.
Nada de configuraciones con varios contenedores
Los seguidores de Immich preguntaron por Compose y stacks. La respuesta fue unánime: de momento no. Al no haber demonio de Docker no hay capa de orquestación, por lo que cada contenedor OCI es un único entorno de ejecución con una aplicación, un sistema de archivos raíz y un comando de inicio. Eso resulta estupendo para servicios pequeños y desastroso para cualquier cosa que exija orquestación compleja.
El caos en YouTube: intentos de explicarlo y discusiones cruzadas
Como era de esperar, en cuanto se publicó la función, los creadores de YouTube se apresuraron a cubrirla. A algunos les gustó el resumen de Techno Tim. Otros dijeron que el vídeo generaba confusión al dar a entender que los contenedores se ejecutaban dentro de contenedores. Él lo aclaró después, pero el mal ya estaba hecho y muchos espectadores se quedaron con una idea equivocada. Otros recomendaron un análisis más técnico, asegurando que explicaba mejor la arquitectura.
Ese fue el patrón a lo largo de todo el debate. A cada explicación entusiasta le seguía alguien corriendo detrás con un extintor al grito de "¡NO! ¡Así no es como funciona!". Es lo que pasa cuando una función es nueva, inusual y cuenta con escasa documentación.
Casos de uso prácticos: dónde brillan realmente los contenedores OCI
Más allá de la discusión, surgieron varios casos de uso reales.
1. Sustituir LXC ligeros pensados para una sola aplicación
Mucha gente ejecuta aplicaciones en LXC aunque esas herramientas se crearon originalmente pensando en contenedores. Piensa en AdGuard, Unifi, pequeñas utilidades de red o gestores de servicios. Los LXC siguen exigiendo parches, gestión de paquetes y mantenimiento del sistema operativo.
Una persona lo resumió con acierto: "No quiero jugar a ser un administrador de sistemas del año 2000 lidiando con dependencias en cada actualización". Con los contenedores OCI puedes ejecutar una aplicación a partir de su imagen de Docker sin utilizar Docker, y te ahorras la carga de mantener el sistema operativo.
2. Hardware con recursos ajustados
Quienes ejecutan Proxmox en equipos NUC, mini PC o pequeños servidores domésticos a veces no pueden permitirse el consumo de memoria RAM de una máquina virtual solo para sostener un demonio de Docker. Los contenedores OCI les aportan un consumo mínimo con aislamiento específico por servicio.
3. Casos de uso de red en clúster
Un usuario explicó que cuenta con una red SDN dedicada y aislada de su LAN principal, y ejecuta una máquina virtual exclusivamente para alojar un proxy inverso, lo que resulta desmesurado. Intentó meter Docker dentro de un LXC pero no consiguió que funcionara limpiamente. Un contenedor OCI creado a partir de la imagen de Traefik resuelve ese problema exacto con una sobrecarga mínima. Es un caso de uso particular, desde luego, pero en el mundo del homelab cada caso de uso es particular.
Los puntos críticos: dónde falla en la actualidad
Incluso los más optimistas reconocieron varios inconvenientes importantes.
1. La operativa de Docker simplemente no existe
Si supervisas las actualizaciones a través del socket de Docker, olvídalo, el socket no existe. Los proyectos que esperan un entorno Docker no lo van a encontrar, y las herramientas que dependen de los eventos de Docker no tienen nada a lo que escuchar.
2. Muchas imágenes de contenedores sencillamente no arrancan
Cuanto más dependa una imagen de las características del entorno de ejecución de Docker en vez de limitarse al contenido del sistema de archivos, más probabilidades tiene de fallar.
3. Los LXC con estado se comportan de forma distinta a los contenedores efímeros de Docker
Alguien preguntó: "Espera, ¿el sistema de archivos se reinicia como en Docker?". No, no lo hace. Cualquier cosa que escriba en el sistema de archivos raíz permanece allí a menos que reconstruyas o limpies manualmente. No es necesariamente malo, pero es un comportamiento muy diferente.
4. Los flujos de trabajo con varios contenedores quedan descartados
Las aplicaciones basadas en Compose como Immich, Home Assistant con complementos o bases de datos vinculadas con paneles frontales no van a ser fáciles de gestionar de forma limpia.
El bando de LXC: "llevamos años haciendo esto"
Algunos lectores se lo tomaron casi con humor. Hay quien lleva mucho tiempo ejecutando Docker dentro de LXC, y funciona razonablemente bien, sobre todo para entornos de homelab no críticos. Unos pocos mencionaron pequeños ajustes necesarios tras ciertas actualizaciones, pero en general el montaje ha sido estable.
Para ellos, los contenedores OCI de Proxmox parecen una variante paralela de lo que ya hacen, interesante pero lejos de ser una revolución. Lo que buscan es Docker o Podman integrados de verdad a nivel del host, y esta función no es eso. Si todavía estás comparando LXC puro frente a Docker en LXC frente a una máquina virtual completa, nuestra guía de decisión entre LXC, VM y Docker repasa los pros y contras de cada opción.
En qué punto se encuentra realmente esta función
En conjunto, la conversación describe una novedad reciente, curiosa, potente y mal comprendida. No está lista para producción y desde luego no es "Docker en Proxmox", al menos no todavía.
Lo que Proxmox ha desarrollado es una vía para tomar imágenes OCI, uno de los formatos de empaquetado más extendidos del sector, y arrancarlas como contenedores ligeros de sistema sin instalar un entorno de ejecución de contenedores. Es ingenioso, resulta útil y va a evolucionar. Por ahora se sitúa en un término medio peculiar: demasiado potente para ignorarlo, demasiado incompleto para depender de él y demasiado confuso para explicarlo sin abrir un debate.
El futuro: cuándo podría Proxmox sustituir de verdad a los hosts Docker
¿Llegará esta función a convertirse con el tiempo en un sustituto real de Docker para usuarios de homelab? Quizá. Según lo debatido, necesita:
- Flujos reales de actualización
- Mejores capas de compatibilidad para imágenes
- Orquestación de múltiples contenedores
- Opciones de red más limpias
- Comportamiento más estable del sistema de archivos
- Mejor documentación
- Menos confusión en general
Si Proxmox consigue resolver eso, se convertiría en una solución integral para virtualización, alojamiento de aplicaciones ligeras y cargas de contenedores, algo que incluso TrueNAS sigue intentando definir. Por ahora es experimental y prometedor, y sinceramente resulta muy entretenido seguir su evolución.
Conclusión
Proxmox 9.1 no dejó obsoleto a Docker. No permitió prescindir de los archivos compose ni concentrar toda la infraestructura doméstica en una sola función del hipervisor.
Lo que sí hizo fue abrir la puerta a un futuro donde Proxmox pueda ejecutar aplicaciones en contenedores sin entornos de ejecución pesados ni apaños frágiles, donde quienes tienen un homelab puedan desplegar pequeños servicios rápidamente, olvidarse del mantenimiento del sistema operativo y evitar las máquinas virtuales para servicios de una sola aplicación. Es una propuesta temprana, imperfecta y poco comprendida, pero aporta algo nuevo, y en un panorama donde todo el mundo tiene una opinión sobre cómo deben funcionar los contenedores, Proxmox acaba de volver el debate mucho más interesante.