762 - ¿Por qué estoy abandonando Docker? Adiós al Demonio
Descubre por qué migrar de Docker a Podman mejora la seguridad y eficiencia de tu servidor Linux. Analizamos arquitectura, logs y pods
Una de las tareas que comenté quería abordar en esta temporada es la migración de Docker a Podman. En este episodio, el primero de una serie dedicada a esta transición, me centraré en la arquitectura de Podman y por qué es una mejora significativa respecto a Docker. Hace ya unos años estuve utilizando Podman, pero, no recuerdo exactamente cual fue la razón por la que terminé abandonándolo. Las ganas de retormarlo, junto con algunos de vuestros comentarios, me han llevado a darle otra vuelta
¿Por qué estoy abandonando Docker? Adiós al Demonio
El problema del Gran Hermano
Lo que no me gustaba de Docker, y que Podman soluciona elegantemente, es su arquitectura basada en un demonio persistente. Docker utiliza un proceso llamado dockerd, que corre siempre como root en segundo plano. Este demonio es responsable de gestionar todos los contenedores, imágenes y redes. Es importante entender que si este proceso falla o es comprometido, todos los contenedores que dependen de él también se ven afectados. Esto crea un punto único de fallo y de ataque, lo cual no es ideal desde una perspectiva de seguridad y fiabilidad.
Procesos independientes
Como te decía, esto lo soluciona Podman con una arquitectura completamente diferente. En el caso de Podman, no existe un demonio persistente. En su lugar, cada comando que ejecutas con Podman lanza un proceso independiente que gestiona el contenedor solicitado. Esto significa que si un contenedor falla, no afecta a los demás, ya que no dependen de un proceso centralizado. Podman se encarga de lanzar el proceso, se asegura que esté en marcha y luego desaparece.
Como Podman utiliza el modelo estándar de Linux, el contenedor es un proceso hijo directo de quien lo lanza (o de Systemd si se integra de esa manera). Esto permite que los contenedores se integren orgánicamente en el sistema operativo, en lugar de ser una «isla» gestionada por un demonio.
Pero sobre todo, y lo que mas me gusta, es que no dependen de un demonio con privilegios de administrador. Esto reduce drásticamente la superficie de ataque del servidor, ya que no hay un proceso siempre activo que pueda ser comprometido para obtener acceso a todos los contenedores.
En los últimos tiempos cada vez ando mas preocupado con el tema de tener procesos en contenedores corriendo como root. Por eso mis imágenes ya salen con un usuario normal, sin privilegios.
La transición es indolora
Llegados a este punto, y ahora que ya están convencido de que Podman es una mejor solución desde el punto de vista de arquitectura, estarás pensando en la migración, y que probablemente sea eso lo que te eche para atrás. Pues bien, la buena noticia es que la transición es indolora. De hecho, puedes simplemente crear un alias en tu shell para que docker apunte a podman. La mayoría de los comandos y flags son idénticos, lo que significa que puedes aprovechar todo lo que ya has aprendido sobre Docker, sin hacer ningún es fuerzo adicional. El 99% de los comandos y flags son idénticos.
Pero no solo esto, sino que además Podman cumple estrictamente con los estándares de la Open Container Initiative (OCI). Esto significa que las imágenes que ya tienes funcionan perfectamente; no hay que re-migrar nada. Simplemente instala Podman, crea el alias, y listo.
Imágenes y Registries
Tengo que confesarte que iniciamente pensaba que solo había un registry, el de Docker Hub. Ahora ya se que estaba equivocado. Tan equivocado que actualmente tengo mi propio registry, y estoy implementando una interfaz web para gestionarlo.
Podman permite configurar múltiples registros de imágenes (Docker Hub, Quay.io, GitHub) de forma explícita en /etc/containers/registries.conf. Esto facilita la gestión de imágenes desde diferentes fuentes y mejora la flexibilidad en la obtención de contenedores.
Los logs
Precisamente hace un par de episodios, en concreto en el 759, te contaba que había liberado 600 GB de espacio en disco en Docker, y que una de las razones era el sistema de logs. Docker almacena los logs de los contenedores en archivos JSON que pueden crecer sin control, ocupando un espacio considerable en disco.
Si bien con Docker también es posible redirigir los logs a journald, no es la configuración por defecto, y requiere una configuración adicional. Pero no solo esto, y es que el proceso que genera los logs es el propio Docker, si el demonio tiene problemas, los logs pueden perderse o corromperse.
Por contra, en el caso de Podman, la gestión de logs es mucho más sencilla y eficiente. Podman puede integrarse directamente con journald, el sistema de logs nativo de Linux. Esto significa que los logs de los contenedores se gestionan de la misma manera que los logs del sistema, lo que facilita su monitorización y análisis. Pero además dado que puedes integrar Podman con Systemd
Los Pods… La herramienta que nos faltaba
Si bien esto lo exploraré con detalle en el episodio 766, no quiero dejar de mencionarlo aquí. Podman introduce el concepto de Pods, que es una agrupación de contenedores que comparten recursos como la red y el almacenamiento. Este concepto es similar al de Kubernetes, lo que facilita la transición a orquestadores más complejos en el futuro. En el caso de Docker, lo mas similar es el uso de Docker Compose, pero no es lo mismo. Los pods tienen algunas ventajas, que son necesarias explotar al máximo. Así por ejemplo,
- Los contenedores dentro de un Pod pueden comunicarse entre sí utilizando
localhost, lo que simplifica la configuración de red. - Como Podman se integra de forma nativa con Systemd, es posible gestionar Pods como unidades de Systemd, lo que facilita su arranque automático y gestión de recursos.
- El patrón sidecar. Se trata de una solución para añadir funcionalidades adicionales a una aplicación principal sin modificarla. Por ejemplo, puedes tener un contenedor principal que ejecute tu aplicación y un contenedor sidecar que gestione el registro o la monitorización.
Conclusión
Como has podido ver, la arquitectura de Podman ofrece varias ventajas significativas sobre Docker, especialmente en términos de seguridad, fiabilidad y eficiencia. La ausencia de un demonio persistente reduce la superficie de ataque y mejora la estabilidad del sistema. Además, la compatibilidad con las imágenes OCI y la facilidad de migración hacen que cambiar a Podman sea una opción atractiva para cualquier usuario de contenedores.