Proxmox vs Docker: cuándo usar cada uno y cuándo combinarlos

Si queremos montar un servidor en casa, tarde o temprano aparecen dos recomendaciones: instalar Proxmox o utilizar Docker. Parece que debemos elegir entre ellos para guardar fotos, reproducir películas o levantar alguna aplicación. Sin embargo, podemos usar los dos en el mismo ordenador, y muchas veces esa combinación tiene más sentido que enfrentarlos.

La diferencia está en qué queremos administrar. Proxmox VE organiza máquinas virtuales, contenedores y los recursos del servidor. Docker organiza la ejecución de aplicaciones en contenedores. Antes de decidir, conviene separar esas dos necesidades. Para servir una aplicación no siempre necesitamos una plataforma de virtualización completa, y para tener varios sistemas operativos Docker no sustituye a una máquina virtual.

Qué hace Proxmox y qué hace Docker

Proxmox Virtual Environment es una plataforma de virtualización basada en Debian. Desde su panel podemos crear máquinas virtuales KVM y contenedores LXC, asignarles recursos y gestionar almacenamiento y redes. Es software libre, con código publicado bajo AGPLv3.

Una máquina virtual tiene su propio sistema operativo y su propio kernel. Podemos crear una con Debian para nuestras aplicaciones y otra con Windows para una tarea distinta. Lo que instalamos dentro de una no se convierte en un paquete del sistema operativo de la otra.

Docker, por su parte, permite ejecutar aplicaciones desde imágenes que incluyen su entorno de ejecución. En un anfitrión Linux, sus contenedores comparten el kernel del anfitrión. No arrancamos un ordenador virtual completo por cada proceso.

Así, instalar una aplicación web y su base de datos en Docker responde a una pregunta. Disponer de un panel para administrar varios sistemas, sus discos virtuales y sus copias responde a otra. Que ambas herramientas permitan ejecutar servicios no significa que sean equivalentes.

Un ejemplo sin montar un centro de datos

Supongamos que tenemos un miniordenador para un servidor multimedia, una aplicación de notas y una web de pruebas. Tenemos dos recorridos razonables.

El primero consiste en instalar una distribución Linux soportada y ejecutar allí Docker. Podemos describir cada aplicación con Docker Compose, mantener sus datos fuera de la capa desechable del contenedor y preparar sus copias. Es un servidor con una sola base de sistema que administrar.

El segundo consiste en instalar Proxmox y crear una máquina virtual con Linux para Docker. Dentro de esa máquina dejamos las mismas aplicaciones. Si más adelante necesitamos otro sistema independiente, podemos crear otra máquina sin convertir la primera en un cajón donde instalamos todo.

La segunda opción tiene una capa más. Necesitaremos actualizar Proxmox, el Linux de la máquina virtual y las aplicaciones. No es un defecto, pero sí trabajo que conviene justificar. Si la única necesidad es levantar dos servicios, el primer recorrido puede ser suficiente.

Cuándo elegir Docker directamente en Linux

Docker encaja cuando la tarea principal es ejecutar aplicaciones que ya tienen una instalación documentada con contenedores. Nos interesa poder describir sus servicios, redes y almacenamiento de forma reproducible, sin mantener un sistema operativo distinto por cada aplicación.

Docker Compose permite guardar esa descripción en un archivo YAML. Por ejemplo, un servidor web de pruebas podría tener este contenido:

services:
  web:
    image: nginx:stable-alpine
    ports:
      - "127.0.0.1:8080:80"
    volumes:
      - ./web:/usr/share/nginx/html:ro
    restart: unless-stopped

Es un ejemplo de configuración, no una instalación de todas nuestras aplicaciones. La carpeta web contendría los archivos del sitio. El puerto se publica sólo en la dirección de bucle local del anfitrión Docker, así que sirve para una prueba local y no deja la web accesible automáticamente desde toda la red.

Si ese anfitrión es una máquina virtual sin escritorio, abrir localhost:8080 en el navegador de nuestro portátil no llegará a ella. Cada máquina tiene su propio localhost. Para acceso remoto tendríamos que preparar una conexión apropiada o una publicación de red deliberada, con sus reglas y permisos.

Tampoco debemos tratar la etiqueta stable-alpine como una versión fija. Cuando queramos despliegues repetibles, elegimos una versión concreta o un digest y planificamos las actualizaciones. El archivo Compose ayuda a reconstruir los servicios, pero no contiene por arte de magia todos sus datos.

Si todavía no hemos trabajado con contenedores, podemos empezar por la introducción a Docker para usuarios Linux. Para probar programas de otra distribución dentro del escritorio, Distrobox cubre un uso diferente al de un servidor de aplicaciones.

Cuándo compensa Proxmox

Proxmox empieza a tener más sentido cuando necesitamos separar sistemas completos. Por ejemplo, un Linux para servicios habituales y otra máquina para probar cambios que no queremos mezclar con ese entorno. También cuando queremos administrar desde un mismo panel el almacenamiento, las máquinas y sus tareas de copia.

La facilidad de crear máquinas no elimina los límites del ordenador. Cada sistema necesita recursos y disco, aunque las aplicaciones de su interior estén paradas. Antes de repartir memoria entre varias máquinas, reservamos margen para el anfitrión y comprobamos los requisitos de Proxmox VE.

No hay un número de gigabytes que garantice que cualquier conjunto de servicios irá bien. Un servidor multimedia que transcodifica vídeo exige cosas distintas a una web pequeña. También importa dónde estarán los datos, qué capacidad de crecimiento tenemos y cómo los recuperaríamos si falla el almacenamiento.

Instalar Proxmox en el ordenador que usamos a diario merece una decisión aparte. No lo tratamos como si fuera una aplicación que añadimos al escritorio de Mint. Si vamos a dedicarle una máquina, preparamos una copia de lo que ya contiene y revisamos bien los discos antes de instalar.

LXC no es una máquina virtual pequeña

En un contenedor LXC podemos tener un entorno Linux separado, pero comparte el kernel con el anfitrión. En una máquina virtual KVM tenemos un kernel independiente. Esto afecta tanto a la compatibilidad como a los límites de aislamiento.

LXC puede encajar para un servicio Linux que sepamos mantener con sus paquetes y configuración. Docker suele facilitar el uso de aplicaciones distribuidas como imágenes, junto con sus archivos Compose. Ninguna de esas frases significa que LXC sólo sirva para un sistema completo o que cualquier imagen Docker vaya a funcionar sin condiciones fuera de Docker.

De hecho, desde Proxmox VE 9.1 se pueden crear contenedores LXC a partir de imágenes OCI. Lo explica el anuncio oficial de esa versión. Por eso ya no sería correcto decir que Proxmox no puede utilizar esas imágenes.

Pero importar una imagen OCI tampoco equivale a interpretar un archivo Compose con todos sus servicios, redes, volúmenes y opciones. Son operaciones diferentes. Si un proyecto documenta su instalación con Docker Compose, comprobamos los requisitos de ese despliegue antes de traducirlo a otra forma de ejecución.

Combinar Proxmox con Docker dentro de una máquina virtual

Para un servidor doméstico que necesite ambos, una distribución Linux dentro de una VM y Docker dentro de ella es una separación fácil de entender. Proxmox administra esa máquina. Docker administra las aplicaciones de su interior.

Podemos imaginar una organización pequeña, con las aplicaciones habituales en una máquina virtual y otro entorno para pruebas:

Esquema de una organización posible. El destino de copias está fuera del ordenador que aloja los servicios.

No es obligatorio crear una VM por contenedor Docker. Podemos agrupar las aplicaciones que tengan requisitos y necesidades de mantenimiento parecidos. Separar una aplicación que estamos probando de las que usamos todos los días puede ser útil, pero crear diez máquinas para diez servicios pequeños añade trabajo que quizá no necesitamos.

Ejecutar Docker dentro de LXC también es una posibilidad técnica en ciertos entornos. Tiene más condicionantes de permisos, kernel y configuración. No lo elegiría como recorrido inicial sólo por ahorrar algo de memoria sin conocer qué va a necesitar cada aplicación. Para este planteamiento, la VM evita tener que empezar resolviendo contenedores dentro de contenedores.

Tampoco instalamos Docker directamente en el anfitrión Proxmox por comodidad. La propuesta anterior deja el nodo dedicado a administrar la virtualización y coloca los paquetes y cambios de las aplicaciones dentro de su Linux invitado.

Dónde están los datos y qué debemos copiar

Este es el punto que merece más atención que el panel. En Docker, los volúmenes conservan datos aparte de la capa escribible del contenedor. Si usamos carpetas enlazadas o bind mounts, la ruta pertenece al anfitrión Docker. En la organización anterior ese anfitrión es la VM, no el nodo Proxmox ni nuestro portátil.

Si guardamos la biblioteca multimedia en un almacenamiento externo, necesitamos saber qué copia la protege. Lo mismo ocurre con fotos, documentos y bases de datos. Guardar el Compose sin sus datos sólo permite reconstruir una parte de la instalación.

Una instantánea en el mismo almacenamiento puede ayudarnos a volver atrás, pero no sustituye una copia independiente frente a la pérdida de ese almacenamiento. Y copiar archivos de una base de datos que está trabajando no siempre produce una copia consistente. Seguimos el procedimiento de exportación o copia recomendado por la aplicación y probamos la recuperación.

Antes de dar el servidor por terminado, escogemos un archivo y una aplicación pequeños para restaurarlos en otro destino. Para distinguir copias de archivos e instantáneas del sistema, la guía de copias de seguridad en Linux Mint también explica esa diferencia.

Los contenedores no evitan administrar la seguridad

Una imagen preparada por otra persona sigue siendo software que vamos a ejecutar. Revisamos su procedencia, actualizaciones, permisos y carpetas que le entregamos. Si un contenedor tiene acceso de escritura a nuestros documentos, el hecho de estar dentro de Docker no vuelve inocuo cualquier proceso de su interior.

La documentación de seguridad de Docker explica además las consecuencias del acceso al demonio y de los permisos elevados. No añadimos privilegios ni acceso al socket Docker para solucionar cualquier fallo de una aplicación sin entender por qué los pide.

Con Proxmox, el panel de administración tampoco debería quedar publicado a Internet sin una necesidad y una protección bien definidas. Separar sistemas nos da opciones, no una garantía de seguridad. Las cuentas, las copias, las actualizaciones y los servicios accesibles siguen siendo responsabilidad nuestra.

Qué elegir para empezar

Si tenemos un equipo con Linux y queremos ejecutar unas aplicaciones con Compose, empezaría por Docker sin añadir más capas. Si necesitamos varios sistemas independientes o un laboratorio de máquinas virtuales, Proxmox responde mejor a esa parte. Y si necesitamos ambas cosas, podemos combinar Proxmox con una VM para Docker.

La decisión útil no es cuál tiene más funciones, sino qué podremos mantener y recuperar. Un servidor con pocas piezas, una copia comprobada y actualizaciones que entendemos suele servirnos mejor que una instalación enorme que no sabemos reconstruir. Si ya tenemos claro qué aplicaciones queremos alojar, ése es un buen punto de partida para elegir la estructura.