Continuando con esta entrada (que en realidad escribí para intentarme aclarar en esta maraña de tecnologías y nomenclatura:

https://unpocodejava.com/2021/06/14/algunos-trminos-importantes-en-2021-en-esto-de-los-contenedores/

hoy vamos a hablar sobre algunas tecnologías alternativas a Docker a tener en cuenta en este año en el que Docker ha decidido cambiar los términos de su servicio:

Podman

Podman es un motor de contenedores sin demonio (Daemon-less), de código abierto y nativo de Linux, desarrollado por RedHat, que se utiliza para construir, ejecutar y gestionar contenedores OCI de Linux e imágenes de contenedores.

Aunque Podman proporciona una interfaz de línea de comandos similar a la de Docker, su funcionamiento es diferente, una diferencia significativa entre Docker y Podman es que Docker ejecuta un runtime persistente y autosuficiente (Daemon) llamado dockerd. En cambio, Podman no depende de un demonio para funcionar y en su lugar inicia los contenedores como procesos hijos. También interactúa directamente con el registro y con el Kernel de Linux utilizando un proceso de ejecución.

La ausencia de un demonio mejora la flexibilidad de Podman como motor de contenedores porque elimina la dependencia de un único proceso que podría actuar como un punto de fallo que se propaga a los procesos hijos haciendo que fallen o queden huérfanos.

Podman proporciona exactamente los mismos comandos CLI que Docker, ya que están implementados utilizando el mismo estándar definido por la Open Container Initiatives (OCI).

Podman también se diferencia significativamente de Docker en que no requiere acceso de root lo que proporciona una barrera de seguridad adicional que restringe los procesos potencialmente peligrosos que pueden manipular configuraciones cruciales del sistema y hacer que el contenedor y la aplicación contenida sean vulnerables.

Además, Podman puede ejecutar pods (colecciones que contienen uno o más contenedores gestionados como una sola entidad y que utilizan un conjunto de recursos compartidos). Gracias a esta capacidad los usuarios de Podman pueden trasladar sus cargas de trabajo a Kubernetes de forma sencilla.

Buildah

Buildah es una herramienta de construcción de imágenes OCI para sistemas de contenedores. desarrollada por Red Hat. Es una herramienta que proporciona una funcionalidad similar a la de ejecutar `docker build` en Docker.

Es una herramienta complementaria que a menudo se utiliza junto con Podman. De hecho, Podman utiliza un subconjunto de la funcionalidad de Buildah internamente para implementar su proceso de construcción y se invoca cuando se ejecuta podman build.

Buildah no tiene demonio ni necesarita acceso root y produce imágenes compatibles con OCI, por lo que se garantiza que sus imágenes se ejecutarán de la misma manera que las construidas con Docker.

Con Buildah se pueden construir imágenes desde un Dockerfile o Containerfile y produce imágenes que operan de la misma manera que las creadas con Docker, ya que las imágenes son compatibles OCI.

Además, ofrece un control de grano fino sobre las capas de la imagen que permite realizar múltiples cambios en una sola capa.

También proporciona la capacidad de construir imágenes desde cero, es decir, imágenes que no contienen nada, lo que da a los usuarios la libertad de añadir sólo los paquetes necesarios para ejecutar la aplicación.

Containerd

Containerd es un runtime de contenedores estándar con el objetivo de ser portable, sencillo y robusto (que ejecuta runc por debajo) para proporcionar una interfaz entre el SO y los motores de contenedores. Runc es un demonio compatible con Windows y Linux que abstrae la funcionalidad específica del sistema operativo y facilita la ejecución y supervisión de los contenedores y la gestión de la transferencia y el almacenamiento de imágenes.

Este nivel de abstracción proporcionado por Containerd elimina la complejidad que supone realizar varias llamadas al sistema de bajo nivel, esto permite la portabilidad de los contenedores, ya que estas llamadas al sistema pueden ser diferentes para distintos sistemas operativos.

A diferencia de Docker, Containerd no maneja la construcción de imágenes o la creación de volúmenes. Containerd es el runtime por defecto de Docker (aunque es una herramienta independiente al igual que runc).

Containerd es un proyecto de la CNCF (Cloud Native Computing Foundation) como Kubernetes, Prometheus, Envoy y CoreDNS.

Skopeo

Skopeo está desarrollado también por Red Hat y es una herramienta que acompaña a Buildah y Podman.

Skopeo no requiere que el usuario se ejecute como root para realizar la mayoría de sus operaciones ni ejecutar un dominio y puede trabajar con imágenes OCI así como con las imágenes originales de Docker v2.

Skopeo trabaja con los registros de imágenes de contenedores de la API V2, como los registros de docker.io y quay.io, registros privados, directorios locales y los directorios locales de OCI-layout.

Skopeo puede realizar operaciones que consisten en:

• Copiar una imagen desde y hacia varios mecanismos de almacenamiento. Por ejemplo, puede copiar imágenes de un registro a otro, sin requerir privilegios.
• Inspeccionar una imagen remota mostrando sus propiedades incluyendo sus capas, sin requerir que se lleve la imagen al host.
• Borrar una imagen de un repositorio de imágenes.
• Sincronización de un repositorio de imágenes externo con un registro interno para las implantaciones en el aire.
• Cuando es requerido por el repositorio, skopeo puede pasar las credenciales y certificados apropiados para la autenticación.

Kaniko

Kaniko es una herramienta desarrollada y liberada por Google para construir imágenes de contenedores a partir de un Dockerfile, dentro de un contenedor o clúster Kubernetes.

kaniko no depende de un demonio Docker y ejecuta cada comando dentro de un Dockerfile completamente en el espacio de usuario. Esto permite construir imágenes de contenedores en entornos que no pueden ejecutar fácilmente o con seguridad un demonio Docker, como un clúster Kubernetes estándar.

Kaniko puede no ser conveniente para las instancias de desarrollo local, ya que normalmente se ejecuta como una imagen con un orquestador de contenedores como Kubernetes, pero si para procesos de integración continua.