Para servir una página con Nginx hace falta muy poco. Pero si lo despliego con Docker dentro de un contenedor Debian, también mantengo ese Debian, el motor de Docker y sus dependencias. La página pesa lo mismo. Lo que cambia es todo lo que la acompaña.
Por eso me interesaba probar el despliegue directo de imágenes OCI en Proxmox. Quería comprobar si podía quitar esa capa intermedia, conservar los datos y administrar la aplicación desde el propio PVE. Y, sobre todo, cuánto se notaba en la RAM.
Probé Nginx y Uptime Kuma en un Proxmox de pruebas. Ambos funcionaron, conservaron sus datos tras los reinicios y, en la comparación de Nginx, el despliegue directo necesitó mucha menos RAM. Me parece un acierto que Proxmox permita hacerlo: para servicios sencillos, es una manera útil de aprovechar mejor la máquina. Eso sí, hay un par de detalles con los datos que conviene entender antes de mover nada.
La misma imagen, con menos cosas alrededor#
OCI es el formato de la imagen de aplicación. Proxmox la importa y la convierte en un contenedor LXC que ejecuta esa aplicación, sin instalar un motor Docker dentro. El arranque, la parada y los límites de recursos pasan a gestionarse como los de otro contenedor de PVE.
Esto permite aprovechar imágenes como las que ya utilizamos con Docker. Hablar de «OCI contra Docker» puede confundir, porque Docker también trabaja con imágenes OCI. Aquí comparé dos formas de desplegar el mismo Nginx: Docker dentro de un LXC con Debian y la imagen OCI ejecutada directamente como LXC por Proxmox.
En ambas rutas comprobé que el contenido servido y la configuración de Nginx coincidían. También concedí los mismos recursos a los contenedores: un núcleo, 512 MiB de RAM y sin swap. La diferencia estaba en la pila necesaria para poner la aplicación en marcha.
En el despliegue directo, Proxmox recuperó de la imagen la entrada de arranque y las variables. Configuré la red y los directorios persistentes por línea de comandos. La ventaja práctica es administrar ese servicio desde PVE sin mantener además el motor Docker.
La memoria es donde más se nota#
Estos fueron los resultados con Nginx 1.28.1 sirviendo una página estática:
| Medida | Docker dentro de Debian LXC | OCI directo en Proxmox |
|---|---|---|
| Memoria anónima en reposo | 54,99 MiB | 2,05 MiB |
| Memoria total en reposo, incluida caché | 328,01 MiB | 12,03 MiB |
| Memoria anónima bajo carga | 57,75 MiB | 2,07 MiB |
| Arranque hasta servir la página | 6,986 s | 3,647 s |
La medición incluye el contenedor completo. En la columna de Docker entran Debian y el motor, además de Nginx. Precisamente esa es la sobrecarga que quería comparar.
La primera fila me parece la más útil: de unos 55 MiB de memoria anónima a poco más de 2 MiB en reposo. Para este servicio, quitar la pila intermedia dejó más memoria disponible para otras aplicaciones. Bajo carga se mantuvo una diferencia similar.
La cifra total es más llamativa, pero incluye caché de archivos, que Linux puede recuperar cuando necesita memoria. Esos 328 MiB no son RAM ocupada para siempre, así que me quedo con la primera fila para no inflar el ahorro.
Con una sola aplicación, unas decenas de MiB no cambian nada. Pero en una máquina donde vas sumando servicios pequeños, esa sobrecarga se multiplica.
También arrancó antes. Los tiempos de la tabla son las medianas de cinco arranques, con las imágenes ya disponibles, hasta recibir la página esperada. El despliegue directo tardó unos 3,65 segundos frente a casi 7 segundos.
Más peticiones por segundo, con un matiz que cambia la lectura#
En la primera comparación, el despliegue directo parecía tener una ventaja enorme. Al revisar el registro de accesos apareció una diferencia relevante: Docker recogía la salida mediante su controlador json-file. Una configuración idéntica de Nginx no implicaba el mismo trabajo alrededor de los registros.
Desactivé access_log en ambas rutas y repetí la carga. Las medianas quedaron en 14.579 peticiones por segundo con Docker y 16.804 con OCI directo. Los rangos se solaparon y una de las tres parejas de pruebas dio el orden contrario.
El despliegue directo rindió bien, pero no elegiría esta opción por una promesa de multiplicar la velocidad. El tratamiento de los registros cambió mucho el resultado. Para mí, el argumento más claro sigue siendo la menor sobrecarga de memoria y poder gestionar la aplicación desde PVE.
Arrancar sirve de poco si los datos no vuelven#
Además de servir la página, comprobé que Nginx conservaba su contenido al parar y arrancar el contenedor. Uptime Kuma mantuvo el monitor y su historial. También volvieron después de reiniciar Proxmox.
La actualización de Nginx dejó el aviso más útil de toda la prueba. Al crear un contenedor con la nueva imagen y el directorio de datos ya conectado, el archivo de la página quedó sobrescrito antes del primer arranque. Desapareció el contenido de prueba y apareció el índice incluido en la imagen.
Recuperé la copia externa y cambié el orden: creé el contenedor sin ese directorio, lo conecté después y arranqué. Así conservó el archivo y funcionó con la nueva versión. Si vas a recrear una aplicación con datos existentes, guarda una copia antes y comprueba qué ha ocurrido antes de ponerla en servicio.
Aquí entra la segunda precaución. Un bind mount conecta un directorio de Proxmox con el contenedor, pero el backup del contenedor con vzdump no incluye los archivos de ese directorio. Recuperar la referencia al montaje no recupera su contenido. El manual de Proxmox lo explica y apareció también en los registros del backup.
Comprobé la restauración de las dos rutas de Nginx usando ambas piezas: la copia del contenedor y una copia independiente de los datos. Las dos volvieron a servir el contenido esperado. Ese directorio necesita su propia estrategia de copia, tanto si eliges Docker como si despliegas OCI directamente.
Dónde le veo sentido en mi homelab#
Para un servicio sencillo que quiero administrar desde Proxmox, esta opción me convence. Nginx funcionó con menos memoria, Uptime Kuma conservó su estado y pude comprobar reinicios y recuperación de datos.
La función sigue clasificada como tecnología preview en el manual oficial. Además, aquí la ejecución es LXC: los contenedores comparten el kernel de Proxmox. Si necesito un kernel independiente, seguiré recurriendo a una VM.
Tampoco trasladaría automáticamente un conjunto de servicios que ya administro con Compose. Para eso, mantener Docker puede seguir siendo la decisión más cómoda para un despliegue que depende de sus herramientas.
Pero para esas aplicaciones pequeñas que solo necesitan ejecutarse y conservar un directorio, Proxmox ha añadido una posibilidad que me parece muy acertada. Permite aprovechar las imágenes disponibles y quitar componentes que también consumen recursos y requieren mantenimiento.
Mi Nginx siguió sirviendo la misma página. La diferencia es que ahora podía hacerlo con bastante menos memoria alrededor. Y eso, cuando lo que quiero es exprimir las máquinas del homelab, sí me parece una mejora útil.