No más demonios gordos (#nobigfatdaemons)

Es una referencia al servicio (daemon en inglés) de Docker. Como sabemos, Docker es una herramienta maravillosa, con infinidad de ventajas y opciones. Es capaz de manejar todo lo referente a nuestros contenedores: red, almacenamiento, ejecución, motorización, etc., y todo esto lo gestiona el mismo servicio de Docker, lo cual puede traer algunas desventajas, ya que mientras más contenedores usemos, más grande y complejo se hace el servicio de Docker.

Es por esto que RedHat ha decidido desarrollar su herramienta sin depender de un servicio, y esta es la principal diferencia entre Docker y Podman.

Podman no necesita un gran servicio (daemon) para funcionar; han descentralizado todos los componentes necesarios para la gestión de contenedores y los han individualizado en componentes más pequeños que se utilizarán solo cuando sean necesarios. Esta descentralización nos ofrece un gran número de ventajas que veremos más adelante.

Podman: ¿Pods o Contenedores?

Podman tiene un nombre muy descriptivo, y sí, cuando hablamos de Pods nos referimos a esas mismas unidades que usamos en el mundo de Kubernetes.

Podman es capaz de ejecutar contenedores exactamente de la misma forma en que lo hace Docker, pero también es capaz de ejecutar Pods.

Para los que no estén familiarizados con el mundo de Kubernetes pronto tendremos un artículo hablando de ello en más profundidad, pero antes podemos aclarar que un Pod es la unidad de medida mínima en Kubernetes. La diferencia fundamental es que un Pod puede contener más de un contenedor. Sobre todo se hace uso de un contenedor principal acompañado de uno o más “side cars containers” corriendo en el mismo Pod que el contenedor principal, para “ayudarlo” con la tarea principal para la que fue diseñado.

Si os suena a magia negra, por ahora quedaos con que un Pod es una unidad en la que puede haber uno o más contenedores; ya profundizaremos más en estos conceptos.

Imaginaos que cada una de las focas del logo de Podman es un contenedor; entonces lo que tenemos es un Pod.

Gestión de imágenes

Podman usa una herramienta basada en scopio para la inspección y gestión de imágenes de tipo OCI.

Con Podman podemos inspeccionar imágenes OCI sin necesidad de descargarlas, y aún mejor, podemos tomar elementos de un repositorio y moverlo a otro directamente sin que esta imagen pase por nuestro dispositivo; no tendríamos que descargar la imagen para poder inspeccionar o usar sus componentes.

Aunque Podman es capaz de construir imágenes de forma muy similar a Docker con el comando Podman build, el equipo de Redhat también nos ofrece otra herramienta llamada buildah.

Buildah es una herramienta para gestión de imágenes que está muy ligada al uso de Podman. Entre sus características nos permite manipular una imagen o un contenedor corriendo para crear nuevas imágenes, montar el directorio raíz de un contenedor para su manipulación o crear nuevas imágenes en formato tradicional o OCI. Si quieres saber un poco más sobre Buildah aquí os dejamos el enlace a su repositorio oficial.

Podman es rootless (seguridad en Podman)

Gracias a la arquitectura modular de Podman, no es necesario correr nuestros contenedores como root. Esto es una gran ventaja, ya que podemos ejecutar nuestros contenedores con diferentes usuarios que tengan diferentes privilegios y sin riesgo de que alguien tenga acceso al servicio de contenedores y pueda ejecutar contenedores como usuario root, y haga estragos en nuestros servidores.

Lo que Podman hace cuando se ejecuta como un usuario non-root es crear un directorio en el directorio home del usuario y almacenar allí toda la información de las imágenes y contenedores que tiene este usuario. Por lo que, si por ejemplo hacemos un podman images con nuestro usuario non-root, mostrará solo las imágenes que este usuario ha creado o descargado.

Otra ventaja de Podman es que es capaz de usar separación de UIDs utilizando namespaces, lo cual nos da una capa extra de aislamiento a la hora de correr nuestros contenedores.

En cuanto a seguridad, la infiltración en el servicio de Docker es incluso más peligrosa que obtener privilegios root (sudo).

Cuando obtenemos permisos de administración (sudo) y hacemos algo en el sistema, siempre se registra en el log de auditoría del sistema, siempre deja rastros que seguir. Pero si accedemos al servicio de Docker y lo hacemos desde un contenedor que obtenga privilegios y nos deshacemos de este contenedor, es prácticamente imposible saber lo que hemos hecho; no se guarda en ningún log ni queda ningún registro de nuestros actos. Lo cual presenta a Podman como una herramienta más segura.

Integración con Systemd

Podman nos permite correr contenedores que tengan habilitado Systemd por defecto, sin ninguna modificación.

Soporta activación de socket, por lo que podemos utilizar systemd para configurar un socket y tener acceso a una API remota a través de la cual comunicarnos con Podman. Se han desarrollado una serie de librerías Python para poder implementar integraciones y comunicarnos con la API remota de Podman.

De hecho, ya hay una aplicación llamada Pypodman desarrollada en Python, que es capaz de ejecutar todo lo que ejecuta Podman localmente, pero de forma remota, comunicándose con la API remota, lo cual abre un mundo de posibilidades.

Conclusiones

No hay una conclusión clara sobre si Podman es un reemplazo a Docker o si conseguirá destronar al rey de los contenedores.

Docker tiene ventajas contra Podman; en primer lugar la distribución y aceptación que tiene, o herramientas como Docker swarm, docker-compose, etc. Ahora mismo, si queremos orquestar contenedores en Podman, nuestra alternativa es usar Kubernetes o, como preferiría RedHat, usar Openshift usando cri-o que es el runtime que utiliza Podman.

Lo que sí sabemos es que RedHat está apostando con fuerza en el mundo de los contenedores, desde la adquisición de CoreOS para su uso en la plataforma Openshift, hasta el desarrollo de Podman, que actualmente es el motor de contenedores por defecto en RedHat 8 y CentOS 8.

sudo zipper install podman

Iniciar servicio podman

sudo systemctl start podman.socket

Verificar si funciona:

$ sudo curl -H "Content-Type: application/json" --unix-socket /var/run/docker.sock http://localhost/_ping

 Tienes ejemplos de contenedores con docker-compose en:

• https://github.com/docker/awesome-compose

git clone https://github.com/docker/awesome-compose/tree/master/wordpress-mysql

¿Cómo funciona la gestión de imágenes de contenedor con Podman?

En lo que respecta a las características y la sintaxis, Podman se basa en Docker. Por eso, al configurar el contenedor deseado puedes acceder a la gran biblioteca de imágenes de Docker listas para su uso, que también se conoce como Docker Hub. Con la ayuda del comando pull podrás descargar las imágenes de las aplicaciones que desees como, por ejemplo, la última versión de Ubuntu:

podman pull hub.docker.com/_/ubuntu:latest

La ruta oficial de almacenamiento de cada una de las imágenes es la ruta de acceso local /.local/share/containers/, en la que cada usuario tiene su propio espacio de nombre. Así, la configuración del contenedor propio, por ejemplo, está separada de la configuración root. Con el siguiente comando conseguirás una vista general de las imágenes guardadas en el disco duro local:

podman images

Si lo que deseas es una lista de las imágenes root, deberás escribir el típico comando de Linux sudo:

sudo podman images 

Podman y Máquinas Virtuales (VM) + Contenedores

Fuentes:
https://pandorafms.com/blog/es/que-es-podman/