Si hablamos de contenerización de aplicaciones, imágenes y virtualización, es muy probable que se os venga a la cabeza Docker. De hecho ha sido durante muchos años el maximo exponente en cuanto a uso de contenedores se refiere. Sin embargo, con el paso de los años han aparecido alternativas, que añaden funcionalidades ausentes o bien vienen a resolver algunos problemas. Y por todo ello, hoy me gustaría presentaros Podman como alternativa a Docker.

¿Qué es Podman?

Podman es un motor de contenedores sin daemon para el desarrollo, gestión y ejecución de contenedores de imágenes para Linux. Además permite la ejecución de contenedores que cumplen la Open Container Initiative (OCI). Por tanto, las imágenes creadas con Podman pueden ser ejecutadas en cualquier sistema que cumpla OCI y vicebersa.

Docker funciona siguiendo una arquitectura cliente-servidor, por ello, necesita un daemon para gestionar los contenedores y la comunicación entre cliente y servidor. Por otro lado, Podman usa un modelo fork-exec, esto es, cada contenedor que se ejecuta es un proceso hijo del proceso principal Podman. De esta forma, Podman consigue reducir el consumo de recursos y mejorar la seguridad.

Los creadores de Podman saben lo extendido que está Docker en el mercado, por lo que han hecho que Podman sea capaz de ejecutar imágenes Docker asi como Dockerfiles. Además, Podman provee un socket que soporta Docker API, por lo que permite a los usuarios el uso de docker-py y docker-compose. Es tal la compatibilidad con Docker que nos aseguran que es tan facil hacer la migración a Podman como ejecutar: «alias docker=podman«

¿Por que usar Podman?

Hemos visto algunas características y diferencias entre estos motores de contenedores, pero ¿Que funcionalidades hacen a Podman ser una alternativa viable a Docker?

Pods

De forma similar al concepto de Pod de Kubernetes, los contenedores en Podman pueden formar pods de forma que pueden operar de forma atómica. Por ejemplo, si tienes una aplicación que consiste en un API rest, un fronted y una base de datos, puedes crear un pod que contenga estos tres contenedores y gestionarla como una entidad única:

podman pod create --name libreria
podman run --pod libreria --name api libreria-api:1.0
podman run --pod libreria --name frontend libreria-ui:1.0
podman run --pod libreria --name database mariadb:latest

El concepto de pod es muy útil en el desarrollo de aplicaciones Cloud Native y sobre todo, si estamos desarrollando para Kubernetes, ya que seguimos usando la misma filosofía. De hecho, es posible generar los descriptores necesarios para desplegar el mismo pod que estamos desarrollando en local en Kubernetes. Para ello ejecutamos el siguiente comando:

podman generate kube

Privilegios Root

Podman es capaz de ejecutar contenedores rootless, es decir, contenedores los cuales no tienen privilegios de administración o root. Esto es debido a que Podman no usa daemon para gestionar su actividad. Esto supone una mejora sustancial en cuanto a seguridad. El uso de contenedores con usuarios root puede suponer que un atacante que inyecte un contenedor infectado pueda acceder a la totalidad del cluster.

Aunque es posible ejecutar contenedores en Podman con privilegios root, su uso debe quedar relegado a procesos de debuging y pruebas. Los contenedores en Podman no tienen acceso root por defecto, lo que añade una barrera natural entre los distintos niveles de privilegios, mejorando la seguridad dentro del contenedor.

Por supuesto, siempre estamos expuestos a atacantes, y aun es posible que se inyecte un contenedor malicioso dentro del cluster. Pero si esto ocurriera, al usar contenedores rootless el atacante solo tendria acceso a los recursos del usuario en uso en el contenedor.

Integración con Systemd

Systemd es un conjunto de daemons de administración de sistemas y herramientas diseñados como una plataforma de administración y configuración central para interactuar con el núcleo del Linux. Es la herramienta que usa Podman para crear unidades de control que gestionan los servicios y soportan los contenedores corriendo en segundo plano.

De esta forma, es mucho más fácil ejecutar contenedores cuyos paquetes requieren systemd para la gestión de servicios y dependencias. Igualmente, Podman puede ejecutarse como parte de los servicios de systemd. La arquitectura fork-exec tradicional de Linux implementada por Podman se integra bien con los sistemas Linux y permite que Podman se comunique con systemd de manera eficiente.

Enfoque modular

Al contrario que Docker, Podman presenta un enfoque modular, esto significa que está especializado en una única función: ejecutar imágenes de contenedores. Aunque podemos realizar construcciones de imágenes ejecutando: podman build, no es Podman el encargado de crear la imágen si no Buildah. Al igual que si ejecutamos podman push para subir una imágen, quien realizara la acción es Skopeo.

Este modelo lleva a una especialización de cada una de las herramientas que usamos para trabajar con contenedores e imágenes. Tres proyectos (Podman, Buildah y Skopeo) con sus respectivos equipos y desarrollo independiente, lo que se traduce en mayor capacidad en la implementación de funcionalidades, mejor rendimiento en la gestión de bugs y posiblidad de utilizar las herramientas de forma aislada. Esto nos hace ver a Docker como un sistema monolítico, que por supuesto, no tiene porque ser algo malo.

Desventajas de Podman

Hemos visto algunas razonas para considerar a Podman como alternativa a Docker, pero como todo existe una serie de desventajas a tener en cuenta:

• No soporta Docker Swarm: Aunque hay alternativas, si se requiere el uso de Docker Swarm el uso de Podman queda totalmente descartado (por ahora).
• Podman no es una herramienta all-in-on: Una de sus mejores caracteristicas puede jugar en su contra, para aquellos que desean una herramienta para realizar todas las tareas.
• El soporte online de Podman es menor: Al ser una herramienta relativamente nueva, la comunidad y soporte es mucho menor si la comparamos con la comunidad detras de Docker.

Conclusión

Como hemos visto, Podman se presenta como una gran alternativa a Docker, con una serie de funcionalidades que mejoran tanto la eficiencia como la seguridad. Si despues de leer el artículo os preguntais si es hora de cambiar a Podman, mi respuesta sería que depende de las circunstancias de vuestro dia a dia en el trabajo. Por mi parte, hace unos meses que estoy usandolo y no echo en falta en ningun momento Docker. De hecho, y salvo en un par de ocasiones, no ha cambiado mi forma de trabajar con contenedores.

Si queréis alguna referencia más de uso de Podman, RedHat cambió el engine de OpenShift de Docker a CRI-O, que es el runtime que utiliza Podman. Igualmente, RedHat 8 y CentOS 8 usan Podman como motor de contenedores por defecto.

Si teneis alguna duda al respecto, quereis conocer más o simplemente decir que os ha parecido Podman, no dudeis en dejar vuestras opiniones en la caja de comentarios. Si os ha gustado el artículo, os animo a que echeis un vistazo a más articulos en Techdoit!