Cuando hablamos de ejecutar contenedores (al menos en entornos de desarrollo) podemos afirmar sin temor a equivocarnos que Docker es el producto más usado. Es gracias a Docker que los contenedores se han popularizado y para mucha gente "Docker" y "Contenedor" son sinónimos.
Pero la realidad es que, Docker no es el único sistema existente para gestionar contenedores. Hay otros. Y uno que está creciendo mucho en los últimos tiempos es Podman.
En este artículo vamos a responder a preguntas cómo:
- ¿Qué es Podman?
- ¿Qué problemas tiene Docker?
- ¿Por qué Podman está ganando popularidad?
- ¿En qué se diferencian Docker y Podman?
- ¿Cuál te conviene usar: Docker o Podman?
Veámoslo...
Docker y Docker Desktop: una distinción importante
Cuando hablamos de Docker debemos diferenciar entre dos productos distintos: Docker Engine y Docker Desktop. Cada uno de estos productos tiene capacidades distintas y, lo más importante, están sujetos a licencias distintas.
Por eso, antes de explicar qué es Podman y por qué no es interesa, es muy importante conocer estos dos productos de Docker, y sus diferencias.
Docker Engine
Este producto está disponible solamente en Linux y podríamos decir que es el "Docker original".
Contiene los elementos mínimos para poder gestionar, crear y ejecutar contenedores. Es una herramienta basada en una CLI (interfaz de línea de comandos), sin ninguna interfaz gráfica.
Este producto es totalmente funcional y su licencia es Open Source. En concreto lleva una licencia Apache 2.0, que es muy permisiva.
Por ello, el producto es gratuito y sin restricciones de uso.
Docker Desktop
Este producto tiene sus raíces en Windows y en macOS, sistemas que no permiten la ejecución nativa de contenedores.
Nota: en la actualidad Windows sí soporta la ejecución nativa de contenedores, pero con ciertos detalles técnicos que sería necesario aclarar. Para no irme demasiado por las ramas, no voy a tratar contenedores Windows en este artículo.
Puede parecer que en sistemas operativos que no soportan contenedores, un producto como Docker no tiene mucho sentido. Pero la gente de Docker no opinaba igual. Así nació Docker Desktop: un producto cuyo sentido era permitir la ejecución de contenedores en macOS y Windows.
Y para ello, claro, tiraron de virtualización. Así Docker Desktop se encarga de crear y mantener una Máquina Virtual Linux en la que se ejecutan los contenedores. Esto se realiza de forma transparente para nosotros como usuarios, por lo que crea la ilusión de que los contenedores se ejecutan de manera nativa también en estos sistemas.
Además, integra también la CLI de Docker (es decir, los binarios para poder gestionar los contenedores desde la terminal nativa de Windows y macOS), pero configurados para que se comuniquen en realidad con la máquina virtual.
Y por supuesto se encarga de tareas adicionales (pero necesarias), como por ejemplo la de convertir rutas entre sistemas de ficheros y así poder montar en los contenedores volúmenes ubicados en carpetas Windows/macOS.
Con el tiempo el producto ha ido evolucionando para usar tecnologías de virtualización cada vez más integradas (por ejemplo, en Windows actualmente se usa el subsistema de Linux, WSL2) y hacer que la experiencia de trabajar con contenedores desde Windows/Mac sea lo más parecida posible a hacerlo en Linux y Docker Engine.
Docker Desktop añade características adicionales como una interfaz gráfica para gestionar las imágenes y los contenedores, así como herramientas extra (como por ejemplo un Kubernetes para desarrollo) que no se encuentran en Docker Engine.
Estas características no son opcionales en el sentido de que no hay una versión básica de Docker Desktop sin ellas y otra completa con todo, sino que existe una única versión de Docker Desktop, independientemente de que habilites o utilices esos extras.
Inicialmente Docker Desktop era exclusivo de Windows y Mac, ya que en Linux la existencia de Docker Engine lo hacía innecesario. Pero con el tiempo, los extras de Docker Desktop empezaron a aportar valor también en el sistema del pingüino y, actualmente, existe también Docker Desktop para Linux.
La licencia de Docker Desktop
A diferencia de Docker Engine, Docker Desktop está sujeto a licencia, lo que significa que su uso no es gratuito en todos los casos.
En la página de precios de Docker se detallan los distintos planes, pero lo más importante es que el plan gratuito no está permitido a determinadas empresas: actualmente aquellas con más de 250 trabajadores (OJO: trabajadores en general, no solo desarrolladores que vayan a usar Docker Desktop) o más de 10 millones de dólares de ingresos.
Si una empresa no tiene permitido usar Docker Desktop de forma gratuita, tiene la opción de usar Docker Engine o bien un plan de pago de Docker Desktop.
Pero recuerda: Docker Engine no está disponible en Windows o MacOS por lo que en estos casos la única opción es un plan de pago si trabajas en una empresa que cumpla los requisitos que acabamos de ver.
Podman
Docker es el sistema de gestión de contenedores más popular, pero no el único.
En la actualidad, el mundo de los contenedores está estandarizado a través de un estándar llamado OCI (Open Container Initiative), lo que asegura la compatibilidad entre los distintos sistemas de contenedores. La aparición de OCI marcó un punto de inflexión, ya que permitió la aparición de nuevos y distintos sistemas de gestión de contenedores sin miedo a que cada uno de ellos se convirtiera en un silo, incapaz de interoperar entre ellos. De esos nuevos sistemas de contenedores uno de los más usados en la actualidad es Podman.
Podman nació de la mano de la conocida empresa Red Hat. Se trata de un producto Open Source (también con licencia Apache 2.0) y completamente gratuito para gestionar contenedores en Linux.
Inicialmente Podman competía directamente contra Docker Engine, ya que sólo estaba disponible en Linux. Era posible ejecutarlo en Windows o MacOS usando una máquina virtual, claro, pero sin ninguna de las ventajas de ofrece Docker Desktop (integración de sistemas de ficheros, enrutamiento desde localhost, etc...). por lo que no era una opción atractiva para los usuarios de estos sistemas.
Con el tiempo, Podman se ha ido adaptando a Windows y macOS ofreciendo un sistema parecido al de Docker Desktop (uso de la CLI desde Windows/MacOS y contenedores ejecutándose en una máquina virtual Linux pero de forma integrada y transparente).
Posteriormente apareció Podman Desktop, una herramienta que ofrece más o menos los mismos extras que Docker Desktop: una interfaz gráfica y gestionar Kubernetes de desarrollo. Y al igual que Podman, esa nueva herramienta es Open Source y sin costes de licenciamiento.
Además, Podman se creó desde el principio con la clara idea de ser capaz de sustituir a Docker. Y para ello la CLI funciona casi exactamente igual en ambos productos: es posible reemplazar docker por podman en todos tus scripts y la inmensa mayoría de ellos seguirán funcionando. Podman acepta los mismos comandos, con las mismas opciones que Docker. Eso facilita mucho la transición de un sistema a otro ya que no es necesario aprender una nueva sintaxis.
O sea, al final lo importante es que Podman carece de costes para cualquier tipo de empresa, y además te garantiza la compatibilidad a la hora de migrar desde Docker. Aunque, por supuesto, tiene sus particularidades que se deben conocer.
Gestión de varios contenedores con Docker y Podman
Una característica muy importante de Docker es la gestión de varios contenedores a través de su herramienta compose. Docker compose es el estándard de facto para gestionar varios contenedores en desarrollo.
La forma más habitual de trabajo a la hora de desarrollar es usar ficheros compose para levantar y configurar todos los contenedores en desarrollo.
Nota: es cierto que el tema le salió un poco "rana" a Docker cuando pretendió que lo usásemos también en producción a través de su orquestador Swarm, ya que Kubernetes arrasó con todo. Pero en desarrollo compose es el rey.
Si Podman quería tener alguna posibilidad real de ser utilizado masivamente en entornos de desarrollo debía ofrecer una alta compatibilidad con compose. Y la realidad es que la ofrece.
El comando podman compose permite ejecutar ficheros compose del mismo modo que su homólogo docker compose. El comando podman compose delega su funcionalidad en una herramienta externa (que debe ser instalada adicionalmente) llamada podman-compose. Esa herramienta es la que ofrece el soporte para ficheros compose.
El hecho de que el comando podman compose delegue la ejecución en una herramienta externa permite escenarios curiosos como que se pueda delegar le ejecución en... ¡Docker compose! 😆
Podman puede coexistir con Docker si ambos están instalados. En ese caso, el comando podman compose ejecuta realmente docker compose (para garantizar la máxima compatibilidad):
Por supuesto, es posible configurar Podman para que use podman-compose, su propia implementación de la especificación compose, usando Podman como gestor y así olvidarnos completamente de Docker.
Pero es que Podman tiene otro as en la manga: además del soporte de compose, Podman tiene su propio sistema para gestión de varios contenedores: el soporte de manifiestos de Kubernetes.
Podman soporta, nativamente, el concepto de pod de Kubernetes (de hecho, de ahí viene su nombre) y un pod permite ejecutar varios contenedores de una forma similar a compose. En este caso sí que se trata de un sistema nuevo, con una sintaxis y conceptos distintos a los de compose, pero para equipos con cierta experiencia en Kubernetes les puede resultar cómodo y es posible trasladar entornos entre desarrollo y producción con más facilidad al usar la misma definición.
Eso sí, aunque puedas usar pods con Podman, la relación entre pod y contenedor seguramente no sea la misma en desarrollo que en producción, así que la realidad es que raramente vas a poder pasar los mismos ficheros, tal cual, de desarrollo a producción. Pero eso tampoco es ningún inconveniente ya que con compose ocurre lo mismo: utilizamos compose en desarrollo, pero luego debemos traducirlo al sistema de producción, que casi con total seguridad será Kubernetes.
Diferencias arquitectónicas
Podman y Docker parten de una arquitectura radicalmente distinta.
Arquitectura de Docker
Docker es un ejemplo clásico de arquitectura "cliente-servidor": la CLI es el cliente que habla con un servidor (al que conocemos generalmente como dockerd o docker daemon), y es este servidor el que gestiona los contenedores. Esto permite conectar con facilidad una CLI de Docker con un servidor que está ubicado en otra máquina, y gestionar los contenedores de esa otra máquina de forma transparente.
Nota: existía un proyecto (ya abandonado) de Docker llamado "Docker Machine" que permitía aprovisionar máquinas virtuales en distintos proveedores (incluyendo cloud) para ejecutar contenedores en remoto, y configuraba la CLI para acceder a dichas máquinas. Docker discontinuó el proyecto y lo sustituyó por el concepto de "contextos". Usando contextos es posible seguir conectándonos de forma sencilla a motores de Docker externos, pero toda la parte de aprovisionamiento queda en nuestras manos.
La crítica principal a Docker es que el servidor suele ejecutarse con permisos de súperusuario. Eso es peligroso porque permite explotar vulnerabilidades en los contenedores, incluso de forma remota. Hay que prestar especial atención a aquellos contenedores cuyo proceso se ejecuta como root en el contenedor. Si existe alguna vulnerabilidad en esos contenedores y se puede saltar al HOST, este salto se realizaría con permisos de root en el HOST, ya que el servidor de Docker es a su vez root.
Afortunadamente cada vez hay menos contenedores que ejecuten su proceso como root. Pero, de todas maneras, que el propio servidor lo sea es un aspecto de seguridad importante a tener en cuenta.
Es cierto que es posible ejecutar el servidor de Docker sin permisos de súperusuario, pero no es un procedimiento sencillo y tiene sus propias limitaciones.
Arquitectura de Podman
Podman no utiliza un modelo cliente-servidor, sino que es un proceso monolítico: el mismo cliente que ejecutamos para la CLI es quien gestiona los contenedores.
Al ser un proceso que lanzamos nosotros, con nuestro usuario, se ejecuta con los permisos que nosotros tengamos, que por lo general serán permisos de usuario. Eso significa que si se aprovecha alguna vulnerabilidad de algún contenedor, incluso aunque sea un contenedor que ejecute su proceso como root, los efectos están limitados a lo que permita realizar en el HOST los permisos de nuestro usuario.
Podman está preparado desde su diseño para gestionar contenedores sin necesidad de tener permisos de súperusuario, por lo que no hay limitaciones destacables, salvo aquellas que vengan por el propio sistema operativo (por ejemplo, no se puede enlazar un puerto menor de 1024).
Por supuesto, es posible ejecutar Podman con permisos de administrador usando simplemente sudo como realizaríamos con cualquier otro programa.
Una pregunta que queda en el aire es... ¿si Podman no tiene el modelo cliente-servidor, como hacen en Windows y macOS para que la CLI de Podman se comunique con la máquina virtual Linux subyacente?
Pues para ese caso tuvieron que agregar soporte explícito para ello. Podman permite gestionar contenedores de máquinas remotas de un modo similar a Docker. Para ello es necesario que la máquina remota tenga instalado un servicio. Pero este servicio no gestiona contenedores sino que simplemente recoje las peticiones del cliente del Podman externo y las redirecciona al Podman local, de la propia máquina. De este modo la comunicación va de la primera máquina al servicio intermedio de la segunda y de este servicio al Podman de la segunda máquina.
Este servicio se puede configurar para que ejecute Podman con o sin sudo. Lo recomendable es usar siempre el modo sin permisos de súperusuario y añadirle permisos de root solo cuando sea necesario. En Windows y MacOS podemos pasar de un modo a otro reconfigurando el servicio con el comando podman machine.
Esta es una gran diferencia con Docker porque, incluso en el caso de comunicación remota, el acceso a los contenedores se hará de manera habitual sin permisos excesivos y, por lo tanto, más peligrosos y propensos a las vulnerabilidades.
Construcción de imágenes con Docker y con Podman
Una cosa es la gestión de los contenedores y otra, anterior y diferente, es la construcción de imágenes.
Es importante destacar que, aunque el formato final de las imágenes está también estandarizado por OCI y todas deben seguirlo, el formato del fichero que se usa para definirlas (y construirlas a partir de este) no tiene una especificación estándar. Pero el formato del Dockerfile definido por Docker es el estándar de facto a seguir.
Eso no quita que existan sistemas de construcción de imágenes que usan otros formatos distintos al Dockerfile, para casos concretos. Mientras al final se termine generando una imagen OCI no hay ningún problema.
Evidentemente Docker soporta el formato Dockerfile. Es su formato y poco más hay que añadir. BuildKit (el sistema que usa Docker para generar las imágenes y que se invoca con docker build) utiliza este formato para terminar generando las imágenes OCI resultantes.
Podman, por su parte, usa el término Containerfile_ en lugar de Dockerfile, pero a día de hoy ambos ficheros son lo mismo. Puedes usar los mismos Dockerfiles de Docker para Podman sin ningún problema.
Para construir las imágenes Podman usa un proyecto Open Source llamado buildah.
¿Cuál usar: Docker o Podman?
Sinceramente, no hay una respuesta clara a esa pregunta. Ambos sistemas son capaces de gestionar contenedores a la perfección y, para el día a día de desarrollo, ambos cumplen con las mejores expectativas.
En cuanto a su popularidad, por supuesto, Docker sigue siendo el número uno, pero Podman está creciendo muchísimo. Ambos sistemas tienen una gran comunidad y se usan en entornos complejos.
Uno de los puntos más importantes es el de la licencia: si trabajas en una empresa mediana o grande que use Windows (o MacOS) es probable que esté sujeta a licencia de pago para Docker Desktop. En este caso Podman sirve como sustituto de plenas garantías sin coste alguno. Es un punto importante a tener en cuenta. Pero también hay que evaluar si los servicios adicionales que ofrece el pago de Docker Desktop (registros privados de contenedores, más operaciones de pull/push por hora, etc) valen la pena o no. En algunos casos es posible que no interesen esos servicios adicionales (la empresa los puede tener contratados en otros proveedores, especialmente si trabaja con algún cloud) y en otros casos sí.
En la práctica ambos te van a permitir a ti y a tu empresa hacer el trabajo de manera eficiente y prácticamente idéntica (con sus particularidades en ciertos casos).
Al final, recuerda que tanto Docker como Podman son meras herramientas y que lo importante es comprender los conceptos subyacentes. Y estos son los mismos en ambos casos. Al final como desarrollador, conocer la herramienta es necesario, pero conocer "lo que hay debajo" te va ayudar mucho más, ya que con esos conceptos claros, el usar una herramienta u otra es algo secundario.
Tanto si en tu organización vais a usar Docker o Podman para el desarrollo, como Kubernetes (seguro) para el despliegue, aprenderás todo lo que necesitas con nuestro completísimo curso online "Docker, Podman y Kubernetes: desarrollo, despliegue y orquestación de aplicaciones basadas en contenedores". En serio, sin recetas, comprendiendo a fondo lo que haces y por qué lo haces. Además, si eres una empresa española puede saliros sin coste gracias a la bonificación.
Respuestas a Preguntas Fecuentes sobre Docker y Podman
¿Qué es Podman?
Podman es un sistema de gestión de contenedores Open Source y gratuito, creado por Red Hat como alternativa a Docker. Es compatible con el estándar OCI (Open Container Initiative) y ofrece funcionalidades casi idénticas a las de Docker, pero con una arquitectura diferente y sin costes de licencia para empresas.
¿Cuál es la principal diferencia entre Docker y Podman?
La arquitectura es la diferencia más notable: Docker usa un modelo cliente-servidor con un demonio que se ejecuta como root, mientras que Podman es un proceso monolítico que se ejecuta con los permisos del usuario. Esto hace que Podman sea potencialmente más seguro, especialmente en entornos compartidos o multiusuario.
¿Es Podman compatible con los comandos de Docker?
Sí, Podman fue diseñado para ser altamente compatible con Docker. Acepta los mismos comandos y opciones que Docker, lo que facilita enormemente la transición entre ambos sistemas. En la mayoría de los casos, puedes simplemente reemplazar docker por podman en tus scripts y seguirán funcionando.
¿Podman funciona en Windows y macOS?
Sí, aunque originalmente era solo para Linux, hoy en día Podman ofrece soporte para Windows y macOS. Utiliza una máquina virtual Linux de forma similar a Docker Desktop, permitiendo una experiencia integrada y transparente para los usuarios de estos sistemas operativos.
¿Qué es Docker Desktop y en qué se diferencia de Docker Engine?
Docker Desktop es una versión de Docker para Windows y macOS que incluye una interfaz gráfica, herramientas adicionales y una máquina virtual Linux integrada. Docker Engine, por otro lado, es la versión básica para Linux, basada en línea de comandos y sin interfaz gráfica. Docker Desktop está sujeto a licencias de pago para ciertas empresas, mientras que Docker Engine es gratuito.
¿Podman tiene alguna ventaja en términos de seguridad frente a Docker?
Sí, Podman está diseñado para ejecutarse sin permisos de súperusuario por defecto, lo que reduce el riesgo de vulnerabilidades. Esto significa que si un contenedor se ve comprometido, el daño potencial al sistema host está limitado por los permisos del usuario que ejecuta Podman, a diferencia de Docker que generalmente se ejecuta como root.
¿Qué es Docker Compose y cómo lo maneja Podman?
Docker Compose es una herramienta para definir y gestionar aplicaciones multicontenedor en desarrollo. Podman ofrece compatibilidad con Docker Compose a través de podman-compose, permitiendo usar los mismos archivos compose.yaml. Además, Podman tiene soporte nativo para pods de Kubernetes, ofreciendo una alternativa para gestionar múltiples contenedores.
¿Puedo usar mis Dockerfiles con Podman?
Sí, Podman es totalmente compatible con los Dockerfiles de Docker, aunque los llama Containerfiles. Puedes usar los mismos archivos de definición de imagen que usas con Docker sin necesidad de modificarlos, lo que facilita la migración o el uso simultáneo de ambas herramientas en entornos de desarrollo.