Dónde va Docker en Proxmox: la decisión de colocación y la trampa de compose

Proxmox está instalado y quieres ejecutar contenedores. La pregunta no es "cómo lo instalo", es dónde lo pongo. Y eso no es cuestión de gusto, es cuestión de cuántas cosas se rompen cuando se rompe una.

Tres colocaciones

Directamente sobre el anfitrión. Lo más fácil, y justo lo que no hay que hacer. El anfitrión es la capa sobre la que descansa todo lo demás. Cualquier cosa que instales ahí queda dentro del radio de daño de cada máquina virtual: un choque de dependencias, un disco lleno o una mala actualización no se lleva solo tus contenedores, se lo lleva todo de golpe.

Dentro de un contenedor de sistema. Ligero y rápido de montar. A cambio estás ejecutando contenedores dentro de un contenedor, y ese montaje tiene sus propias aristas: el modelo de permisos, las capas de sistema de archivos, el núcleo compartido. Elegido a propósito es razonable; elegido porque "era más fácil" produce sorpresas.

Dentro de una máquina virtual. Lo más pesado sobre el papel y lo más limpio en la práctica. Cuando el montaje de contenedores se cae, lo que se cae es una máquina virtual, no tu servidor. Y cuando quieras rehacerlo, rehaces una máquina.

La única pregunta que decide

"Si esto se rompe, ¿qué pasa con todo lo demás?" En el anfitrión la respuesta es "todo", dentro de una máquina virtual la respuesta es "una sola". El consumo de recursos, la facilidad de instalación, todo eso queda en segundo plano junto a esa respuesta.

La segunda mitad: compose es un programa

Un archivo compose parece configuración. No lo es. Ejecutarlo es ejecutar código, y corre con tus permisos. Dos líneas dentro pueden entregarle al contenedor la máquina entera.

Cuando la gente copia un archivo compose de internet no siente la incomodidad que siente al copiar una orden. La diferencia no está en el peligro, está en la apariencia: una orden parece una orden, mientras que compose parece un archivo de ajustes. Parecerlo no lo hace seguro.

Cuatro líneas que mirar antes de ejecutarlo

¿Monta dentro el sistema de archivos del anfitrión? ¿Pide modo privilegiado? ¿Pasa dentro el socket propio de la gestión de contenedores? ¿Usa directamente la red del anfitrión?

Esas cuatro son las líneas que perforan la frontera del contenedor: si hay una, ese contenedor ya no es un contenedor, es el anfitrión mismo. Leerlas cuesta diez segundos, y esos diez segundos valen más que todo lo demás de esta entrada.

Qué hace Atlas

Atlas analiza los archivos compose y los scripts de instalación antes de instalar, y ese análisis está en el servidor y no en la interfaz. Así que mande lo que mande la interfaz, la comprobación no se puede saltar.

Los hallazgos llegan en dos niveles. Rojo significa algo que saca al contenedor fuera de la frontera del contenedor, es decir, privilegios equivalentes a los del anfitrión; en ese caso se pide una aprobación explícita. Amarillo significa algo que puede hacerse a propósito pero de lo que hay que informarte. En el lado del catálogo de aplicaciones, el rojo no se acepta en absoluto.

Hay un detalle más y cuenta: el analizador no opina, informa del hecho. No dice "esto es peligroso", dice "esta línea hace aquello". Decide quien lee, porque la misma línea puede ser aceptable en una instalación e inaceptable en otra.