Podman vs. Docker: ¿dónde se encuentra el futuro del mundo de los contenedores?

Dado que en Red Hat Enerprise Linux 8 (RHEL 8) se ha interrumpido el soporte oficial para la popular herramienta de gestión de contenedores conocida como Docker, los administradores deben estar al tanto de una nueva opción. Podman, que también es de Red Hat, se considera el sucesor directo de Docker y, como prescinde de un daemon central y de la necesidad de privilegios root, es capaz de disipar las preocupaciones de seguridad que generaba su predecesor. Por los demás aspectos, ambas herramientas son similares, aunque Podman sigue teniendo algunos errores con los que lidiar.

Docker es una de las soluciones de contenedores más populares, pero ya no recibe soporte oficial Red Hat Enerprise Linux 8 y, por tanto, ha pasado a ser historia. Red Hat, sin embargo, proporciona la solución al problema de forma directa con Podman. Red Hat anuncia el entorno CRI-O  como una solución equivalente 1:1, así que los aficionados a Docker no tienen por qué preocuparse. Otra cuestión completamente diferente es si Podman verdaderamente puede sustituir a Docker sin implementar restricciones. Para poder responder a esta pregunta, conviene primero examinar de cerca ambas tecnologías de contenedores.

Desde que Docker surgió como software de código abierto en 2013, esta tecnología ha gozado de gran popularidad. Docker permite a los usuarios un enfoque más abierto; es una solución sencilla y al mismo tiempo práctica y segura para el desarrollo de aplicaciones. La imagen de un contenedor facilita el transporte e instalación de paquetes de datos. Una sola imagen Docker puede crear un número ilimitado de contenedores para, por ejemplo, crear OpenStack clouds. Docker está completamente aislado, a excepción de algunas interfaces con el sistema operativo o el hardware. Los contenedores solo contienen la información realmente necesaria, por lo que son relativamente ligeros.

Docker va a ser sustituido por Podman, al menos esa es la intención de Red Hat Linux. Podman está pensado como un gestor de pods para la creación y posterior procesamiento de contenedores y es compatible con las especificaciones de contenedores OCI. A diferencia de Docker, Podman no necesita derechos root, por lo que es supuestamente más seguro en comparación con Docker. Podman está basado en Docker y fue originalmente concebido como una herramienta de debugging que terminó convirtiéndose en una alternativa o sucesor a las antiguas herramientas de gestión. Para facilitar la transición de uno a otro, Podman reconoce y permite utilizar los comandos de Docker. Pero esto por sí solo no convierte a Podman en un sucesor equivalente.

Esa es precisamente la cuestión decisiva. Dado que Docker va a dejar de recibir mantenimiento, los usuarios tienen que adaptarse y encontrar una alternativa similar. Mientras que Red Hat Linux ve a Podman como esa alternativa, muchos desarrolladores no terminan de decidirse o incluso la descartan. Para evaluar adecuadamente las diferencias entre Docker y Podman, merece la pena echar un vistazo a los puntos fuertes y débiles del aspirante.

La mayor ventaja que ofrece Podman frente a Docker es que prescinde de un daemon centralizado y de los derechos root. Esto no solo permite un inicio más rápido, sino que aumenta el nivel de seguridad. El sistema host está protegido y los procesos con derechos root ya no pueden acceder al kernel. La compatibilidad que tiene Podman con Docker es también una gran ventaja. Migrar entre los dos sistemas es bastante sencillo y los pasos individuales también son muy intuitivos para los administradores que están acostumbrados a gestionar sistemas con Docker.

Además, con Podman es posible utilizar registros de contenedores populares como Docker Hub o Quay.io. También se pueden crear archivos YAML para Kubernetes. Podman es considerado extremadamente rápido y, en comparación con Docker, requiere en general menos espacio de almacenamiento y es más eficiente. Por lo tanto, Podman es la solución por defecto para muchas distribuciones de Linux como Fedora CoreOS.

Por mucho que Red Hat se haya decidido por Podman, el motor de contenedores no está exento de errores. En particular, sus defectos de crecimiento y bugs hacen que muchos administradores aún no estén plenamente satisfechos con Podman y prefieran otras alternativas a los contenedores de Docker o soluciones híbridas como Kata Containers.

Cuando se trata de contenedores, los errores son frecuentes. Crear y gestionar contenedores a través de un host remoto sin un daemon en la red es difícil. Aunque Podman ofrece soluciones provisionales, estos problemas no se han resuelto completamente. Esto también se aplica a la supuesta compatibilidad entre Podman y Docker. La herramienta más reciente, Podman, aún no entiende todas las solicitudes.

Hay que realizar una comparación directa entre ambos sistemas si queremos poder determinar si triunfa el cuasi-estándar que ha sido popular durante años o el contendiente del duelo Podman vs. Docker. ¿Cuáles son las diferencias entre los dos sistemas de gestión?

A diferencia de Docker, Podman prescinde de un daemon central para el desarrollo, gestión y ejecución de contenedores OCI. En cambio, Podman está basado en el concepto de pods de Kubernetes donde varios contenedores se unen dentro de un espacio de nombres común de Linux. Esto crea opciones de configuración y combinación flexibles. Docker no ofrece esta posibilidad sin tener que entrar a configurar la herramienta Docker Compose.

Esta es también una de las mayores críticas dirigidas a Docker. Su daemon requiere tener derechos root, lo cual crea un riesgo potencial para la seguridad. Es por ello por lo que los contenedores de Docker tienen la posibilidad de liberarse y actuar sobre el host. Esto puede provocar daños importantes en el kernel en determinadas circunstancias, como cuando un contenedor mal configurado accede al host. Podman soluciona este problema permitiendo que los contenedores se inicien sin derechos root. Sin embargo, lo que es positivo desde el punto de vista de la seguridad, también implica necesariamente que los administradores no puedan ejecutar comandos en el host que requieran derechos root.

En el duelo Kubernetes vs. Docker son muchas las diferencias entre los dos pesos pesados, pero cuando se trata de la organización de contenedores, ambas herramientas funcionan bien juntas. Esto cambiará con Kubernetes 1.24, ya que Kubernetes abandona el soporte de Docker. Con Podman el trabajo conjunto no es un problema. El propio nombre del nuevo sistema ya indica que (a diferencia de Docker) también es compatible con los Pods desarrollados por Kubernetes.

A diferencia de Docker, Podman realiza acciones según el modelo fork-exec y registra los cambios en el sistema auditd. Esto no ocurre con Docker, ya que no existe ningún tipo de registro.

Sin duda, esta diferencia se irá reduciendo con el tiempo. Sin embargo, actualmente la documentación de Docker sigue siendo muy superior a la de Podman. Desde 2013, el “oldie” se ha convertido más o menos en el estándar y, por ello, cuenta con una enorme comunidad que proporciona a los administradores ayuda y consejos para todo problema que les pueda surgir. Su sucesor, cinco años más joven, aún no consigue mantener el ritmo. Sin embargo, es probable que en el futuro, las dos herramientas probablemente coincidan en este aspecto.

Aunque el diseño de Docker y Podman es muy diferente, esto tiene poco impacto en el trabajo diario. Aquellos que están familiarizados con Docker probablemente sepan encontrar la forma de hacerlo con Podman, sobre todo porque muchos comandos son similares y uno se puede adaptar a ellos fácilmente.

Veamos qué es exactamente lo que hace que el cambio de Docker a Podman sea relativamente fácil. No solo los comandos como “pull”, “push”, “build”, “run”, “commit”, etc. son en gran medida idénticos, sino que las imágenes Docker también son compatibles con Podman. Esto fue el objetivo principal de los desarrolladores cuando crearon Podman. Antes de cambiar a Podman deberías asegurarte de que Docker de verdad haya perdido su soporte. Una vez lo tengas claro, instala Podman o recurre al software preinstalado de algunas versiones de Linux. A continuación, debes cambiar el nombre de “Dockerfile” y docker-compose.yml por “Containerfile” y container-compose.yml. Además, es importante saber que Podman almacena sus contenedores e imágenes en un lugar diferente al de su prominente predecesor.

Podman vs. Docker es una batalla injusta, ya que la herramienta más antigua tiene una cierta ventaja, aunque sin el soporte de Red Hat parece estar condenada a desaparecer. Hay buenas razones para ello, especialmente en cuanto a la seguridad; mientras Docker lleva mucho tiempo intentando ponerse al día en este aspecto, estas deficiencias se han subsanado desde el principio con Podman. La ausencia de un daemon centralizado y la mejor protección resultante de ello podrían convencer tarde o temprano incluso a los administradores más escépticos. Sin embargo, ni siquiera Podman se libra de tener errores; todavía necesita resolver algunos problemas. Si se resuelven estos pequeños problemas con éxito, Podman ganará a Docker por un margen estrecho.

Muchos defensores de Docker tendrán que cambiar tarde o temprano, ya que van a dejar de tener soporte. No obstante, pueden optar por una alternativa a Kubernetes con la que se pueda seguir usando Docker. Con todo, debido a la gran similitud de las dos soluciones de contenedores y a los esfuerzos de Red Hat Linux por establecer a Podman como su sucesor, es muy probable que este cambio salga adelante.