Docker o Podman: rootless no decide por sí solo el rendimiento

Docker y Podman pueden ejecutar contenedores sin privilegios de administrador, pero rootless no determina cuál rinde más. El modo rootless de Docker incluye tanto al daemon como a los contenedores; Podman también permite trabajar como usuario corriente. Para elegir entre ambos hay que mirar qué operación importa: compilar imágenes, iniciar procesos, mantener servicios activos, transferir datos o acceder al disco.

La seguridad y la velocidad plantean preguntas distintas. Reducir los privilegios del motor limita su capacidad de actuar sobre el host, mientras que el tiempo de una compilación o el caudal de red dependen además del constructor, la caché y la configuración. Una comparación útil mantiene constantes el sistema operativo y la carga, e identifica si cada motor funciona en modo rootless.

Qué cambia al ejecutar cada motor sin privilegios

Docker Engine gestiona los contenedores mediante un daemon persistente. Ejecutar como usuario no privilegiado un proceso dentro de un contenedor no cambia necesariamente los privilegios de ese servicio; en modo rootless, el daemon y los contenedores se ejecutan dentro de un espacio de nombres de usuario. La configuración requiere herramientas de mapeo de identidades y rangos subordinados de UID y GID. Así, la comparación de seguridad debe partir de los privilegios efectivos de la instalación, no solo del nombre del motor.

El manual de Podman describe un motor sin daemon central persistente que crea automáticamente un espacio de nombres de usuario al ejecutarse en modo rootless. También fija límites para el almacenamiento: OverlayFS no está soportado en ese modo con núcleos anteriores a 5.12.9, y NFS y otros sistemas de archivos distribuidos no pueden alojar directamente su almacenamiento rootless. En un host con directorio personal sobre NFS, la documentación permite situar ese almacenamiento en una ruta local; esa ubicación pasa a ser una condición relevante para cualquier prueba de E/S.

El beneficio de reducir privilegios es acotar lo que puede hacer en el host un proceso comprometido. Eso no elimina la necesidad de revisar los directorios montados, los permisos concedidos al contenedor y el acceso a las interfaces de administración. Podman puede ejecutarse sin privilegios, y Docker puede configurarse para ello; la diferencia arquitectónica entre ambos no sustituye esa revisión.

Qué miden las cifras publicadas

En las mediciones de Leaper, realizadas con Docker Engine 27.x y Podman 5.4 sobre un equipo con Fedora 41, cgroups v2 y overlayfs, la compilación de una aplicación Node.js en varias etapas tardó 38,2 segundos con Docker y 40,7 con Podman; el arranque en frío de Alpine, 0,31 y 0,28 segundos; la memoria adicional de un contenedor inactivo, 11,4 y 8,2 MB; la red entre contenedor y host medida con iperf3, 42,1 y 38,7 Gbps; y la E/S secuencial medida con fio, 1,82 y 1,79 GB/s, respectivamente. El autor indica que repitió las pruebas y publicó la mediana.

La ventaja cambia con la operación: Docker obtuvo mejores cifras de compilación y red en esa prueba; Podman registró un arranque más breve y menor memoria adicional. La cercanía de los valores de E/S secuencial hace especialmente arriesgado trasladar ese resultado a otro disco o controlador. Además, la publicación no especifica el modo de privilegios de cada ejecución ni ofrece suficiente detalle de configuración para aislar el efecto de rootless. Sus cifras describen una combinación de motor y entorno, no el coste de eliminar privilegios.

También importa la escala temporal de la carga. En un trabajo que inicia contenedores breves de forma repetida, el arranque puede influir en el tiempo total; en un servicio que permanece activo, pesan más el consumo sostenido, la red y el acceso a datos. Una medición de tráfico entre contenedor y host tampoco representa por sí sola las conexiones entre servicios o hacia sistemas externos.

Por qué la compilación requiere una comparación propia

El tiempo de construir una imagen depende del constructor además del motor. La documentación de BuildKit explica que puede omitir etapas no utilizadas, ejecutar etapas independientes en paralelo y transferir solo los archivos modificados del contexto. Por ello, la ventaja de Docker en la compilación publicada corresponde a la combinación probada: no permite atribuir toda la diferencia a la presencia de un daemon.

Para un equipo que compila a diario, una construcción inicial y una reconstrucción con caché responden a preguntas distintas. Si apenas cambian las dependencias, la reutilización de capas puede dominar el resultado; si cada trabajo empieza sin caché, cobran más peso la descarga de imágenes, la ejecución de etapas y el almacenamiento. El mismo Dockerfile y el mismo estado de caché permiten comparar tiempos relevantes para ese flujo, mientras que los segundos obtenidos con otra aplicación sirven solo como referencia.

Red y almacenamiento: las condiciones que pueden alterar el resultado

La prueba de red citada mide transferencia entre un contenedor y su host. Una aplicación que habla con otros contenedores, una base de datos externa o clientes remotos recorre rutas distintas; por eso, el caudal de aquella prueba no predice necesariamente su latencia. Para comparar motores en esa aplicación, deben coincidir el destino, el tamaño de las transferencias y la configuración de red, además del modo de privilegios.

En almacenamiento, rootless puede cambiar qué controlador está disponible y dónde residen las capas de las imágenes. La distinción entre OverlayFS del núcleo y fuse-overlayfs, así como el uso de un disco local para el almacenamiento de Podman, afecta especialmente a cargas que crean o modifican muchos archivos. Conviene registrar también el controlador y la ruta de datos de Docker antes de interpretar una diferencia de E/S como propiedad del motor. Una prueba secuencial con fio describe ese patrón de acceso; una base de datos o una compilación pueden exigir otros patrones.

Compatibilidad cotidiana y elección por carga

Podman ofrece comandos familiares para gestionar imágenes y contenedores, pero un flujo de trabajo puede depender de Compose, volúmenes, redes y herramientas conectadas a un socket. La referencia de podman compose aclara que el comando delega la ejecución en un proveedor externo y prepara su conexión con el socket local de Podman. Compartir comandos básicos, por tanto, no garantiza que un proyecto con integraciones concretas se comporte igual.

Docker encaja cuando el equipo depende de su constructor y de integraciones ya establecidas, siempre que su configuración cumpla los requisitos de seguridad. Podman encaja cuando interesa operar como usuario corriente sin un daemon central persistente y sus condiciones de almacenamiento y compatibilidad se ajustan al entorno. Si rootless es un requisito, la comparación pertinente usa ambos motores en ese modo y separa las mediciones de compilación, arranque, memoria, red y E/S. La elección resulta de la carga y de las herramientas que la acompañan, no de una sola cifra.

Lee también:

• Demandan a cuatro laboratorios por frenar la IA: la seguridad choca con la competencia
• Descartes paga 100 millones por Tai: los datos de carga son la pieza clave
• La IA no puede ser autora: el trabajo humano decide qué se protege