Aunque hay muchos buenos blogs y tutoriales sobre Podman y Buildah, los usuarios de Docker claramente carecen de explicaciones claras y concisas sobre cómo cambiar a Podman, por qué se necesita Buildah en otros temas de este tipo.
Intentaremos responder estas preguntas y decirle cómo migrar sin problemas de Docker a Podman.
Cómo funciona Docker
Comencemos aclarando cómo funciona Docker para entender por qué surgieron Podman y Buildah. Como sabes, los comandos de Docker solo funcionan cuando el proceso del demonio Docker se está ejecutando. Parece que la idea con el demonio era reunir en un lugar todas las cosas geniales que hace Docker y, al mismo tiempo, organizar API útiles para trabajar con él en el futuro. Como se muestra en la figura a continuación, el demonio Docker contiene toda la funcionalidad necesaria para realizar las siguientes tareas:
- Operaciones de extracción y empuje cuando se trabaja con el registro de imágenes;
- Crear copias de imágenes en el almacenamiento del contenedor local y agregar capas a estos contenedores;
- Confirmar cambios en contenedores y eliminar imágenes de contenedores del repositorio local en el host;
- Solicite al kernel del sistema operativo que inicie el contenedor en el espacio de nombres correspondiente, cgroup, etc.
En esencia, el demonio Docker se encarga de todo el trabajo con registros, imágenes, contenedores y el núcleo. Y usted simplemente le dice qué hacer a través de la interfaz de línea de comando (CLI).
Aquí no evaluaremos los pros y los contras de este enfoque, cuando todo se reúne en un proceso demoníaco. Se pueden hacer muchos argumentos a su favor, y en el momento de la aparición de Docker, tenía mucho sentido. Sin embargo, con el uso activo de Docker, comenzaron a surgir preguntas para él, por ejemplo:
- Un solo proceso significa un único punto de falla;
- El proceso daemon posee todos los procesos secundarios (contenedores en ejecución);
- Cuando el demonio se va, los procesos infantiles permanecen huérfanos;
- El ensamblaje del contenedor tiene agujeros de seguridad;
- Para realizar cualquier operación de Docker, los usuarios necesitan privilegios de root completos.
Hubo otras quejas. Uno puede no estar de acuerdo con esto o decir que estas deficiencias ya se han eliminado, pero no vamos a discutir. Los desarrolladores de Podman creen que han logrado resolver muchos de estos problemas, y si quieres aprovechar Podman, entonces este artículo es para ti.
La esencia de Podman es interactuar con el registro de imágenes, con contenedores y almacenamiento de imágenes, así como con el kernel de Linux, no a través de un demonio, sino directamente a través del proceso runC, que es responsable del lanzamiento de los contenedores.
Ahora que hemos descubierto parcialmente los motivos de los desarrolladores de Podman, es hora de discutir qué significa la transición a Podman para el usuario. Y aquí debemos entender y aclarar (lo haremos a continuación) lo siguiente:
- Podman reemplaza a Docker. Al mismo tiempo, ya no es necesario iniciar algún tipo de proceso de demonio, como el demonio Docker;
- Los comandos Docker familiares funcionan de la misma manera en Podman;
- Podman no almacena contenedores e imágenes en el mismo lugar que Docker;
- Las imágenes de Podman y Docker son compatibles;
- En entornos Kubernetes, Podman es capaz de más que Docker;
- Y también analizaremos qué es Buildah y por qué es necesario.
Instalación de podman
Si usa Docker, puede eliminarlo cuando decida hacer un cambio. Sin embargo, puede abandonar Docker mientras prueba Podman. Hay algunas
lecciones útiles y excelentes
demostraciones que pueden ser útiles para leer y ver para empezar para que pueda comprender mejor el proceso de transición. Un ejemplo en la demostración requiere que Docker muestre compatibilidad.
Para instalar Podman en
Red Hat Enterprise Linux 7.6 o posterior, use lo siguiente; si está usando Fedora, reemplace yum con dnf:
# yum -y install podman
Podman usa los mismos comandos que Docker
Podman fue diseñado para que sea fácil cambiar de Docker. Por lo tanto, todos los equipos que conoce de Docker funcionan de la misma manera en Podman. Además, se argumenta que los scripts de llamada de Docker deberían funcionar bien si crea el alias apropiado, como este: alias docker = podman - solo inténtelo. Por supuesto, antes de eso debe detener Docker (systemctl stop docker). Además, puede instalar el paquete podman-docker, que realizará todas las conversiones necesarias por usted. Simplemente coloca un script en / usr / bin / docker que ejecuta Podman con los mismos argumentos que utiliza Docker.
Los comandos habituales de Docker, como pull, push, build, run, commit, tag, etc., están todos en Podman. Consulte el manual de Podman para obtener más información. Una diferencia importante es que en Podman algunos equipos han agregado banderas de conveniencia, por ejemplo, las banderas --todos (-a) para los comandos podman rm y podman rmi, que muchos encontrarán muy útiles.
Además, Podman se puede ejecutar como usuario normal, sin privilegios de root. Es cierto, hasta ahora esto solo funciona en Fedora y con Podman 1.0, y en RHEL debería aparecer a partir de las versiones 7.7 y 8.1. Esto ha sido posible gracias a las mejoras en la protección del espacio del usuario. Ejecutar como un usuario normal significa que, de manera predeterminada, Podman almacena imágenes y contenedores en el directorio de inicio del usuario, discutiremos esto con más detalle en la siguiente sección. Para obtener más información sobre cómo ejecutar Podman sin privilegios de root, consulte el artículo de Dan Walsh
¿Cómo funciona Podman sin root? .
Imágenes de podman y contenedor
Cuando ingrese por primera vez el comando de imágenes de podman, lo más probable es que se desanime, ya que no verá ninguna imagen de Docker que ya se haya descargado en su computadora. El hecho es que el repositorio local de Podman se encuentra en la carpeta / var / lib / container, y no en el directorio / var / lib / docker. Esto se hizo no solo así, sino como parte de una nueva estructura de almacenamiento que cumple con los estándares OCI (Open Containers Initiative).
En 2015, Docker, Red Hat, CoreOS, SUSE, Google y otros creadores de tendencias de contenedores de Linux crearon Open Container Initiative, un organismo independiente para gestionar las especificaciones de estándares para el formato de las imágenes de contenedores y su tiempo de ejecución. Como parte de la OCI, se crearon contenedores / imagen y proyectos de contenedores / almacenamiento en GitHub.
Como Podman puede ejecutarse sin privilegios de root, necesita un lugar separado para grabar imágenes. Por lo tanto, el repositorio de Podman se encuentra en el directorio de inicio de usuario ~ / .local / share / container. Esto ayuda a evitar una situación en la que puedan escribir todo en / var / lib / container, y en relación con otras prácticas que son peligrosas desde el punto de vista de la seguridad. Además, ahora cada usuario tiene su propio conjunto separado de contenedores, de modo que varios usuarios pueden trabajar simultáneamente en el host a la vez. Una vez finalizado el trabajo, los usuarios pueden enviar mediante envío al registro general para que sus imágenes estén disponibles para otros.
Al cambiar de Docker a Podman, conocer las nuevas rutas de ubicación del contenedor será útil al depurar, así como cuando desee borrar el repositorio local con el comando rm -rf / var / lib / container para comenzar de nuevo. Sin embargo, al cambiar a Podman, lo más probable es que comience a usar la nueva opción -todos para los comandos podman rm y podman rmi en lugar de este comando.
Compatibilidad de contenedores entre Podman y otros tiempos de ejecución
A pesar de las diferentes ubicaciones de los repositorios locales, tanto Docker como Podman crean imágenes de contenedor que son compatibles con el estándar OCI. Podman puede usar registros de contenedores populares, como Quay.io o Docker Hub, así como registros privados en ambas direcciones (push y pull). Por ejemplo, con Podman, puede descargar y ejecutar la última imagen de Fedora desde Docker Hub. Si no especifica un registro, Podman buscará de forma predeterminada los registros enumerados en el archivo registries.conf., Siguiendo el orden especificado en este archivo. Inicialmente, el primero en este archivo es el registro de Docker Hub.
$ podman pull fedora:latest $ podman run -it fedora bash
Las imágenes que se han subido al registro con Docker se pueden descargar y ejecutar con Podman. Por ejemplo, si creamos una imagen de myfedora usando Docker y la subimos a nuestro repositorio Quay.io (ipbabble), puede descargarla usando Podman, así es como:
$ podman pull quay.io/ipbabble/myfedora:latest $ podman run -it myfedora bash
Podman le permite mover imágenes de manera fácil y elegante entre los directorios / var / lib / docker y / var / lib / container utilizando los comandos push y pull, por ejemplo:
$ podman push myfedora docker-daemon:myfedora:latest
Está claro que si omite docker-daemon en este ejemplo, el envío de envío irá al Docker Hub. Si especifica quay.io/myquayid/myfedora, la imagen se cargará en el registro Quay.io (aquí myquayid es el nombre de nuestra cuenta en Quay.io):
$ podman push myfedora quay.io/myquayid/myfedora:latest
Si decide que está listo para abandonar Docker, para desinstalarlo, simplemente cierre el demonio y luego elimine el paquete Docker usando el administrador de paquetes. Pero antes de eso, asegúrese de descargar todas las imágenes que necesita usando Docker en el registro externo (no local) para poder descargarlas desde allí más tarde. O puede usar Podman para descargarlos desde el repositorio local de Docker al repositorio local de OCI de Podman. Por ejemplo, en RHEL, la transferencia de una imagen fedora se realiza así:
# systemctl stop docker # podman pull docker-daemon:fedora:latest # yum -y remove docker # optional
Podman facilita el cambio a Kubernetes
Podman ofrece una serie de características adicionales, en comparación con Docker, que son útiles para los desarrolladores y operadores de TI cuando trabajan con Kubernetes, en particular, comandos útiles que Docker simplemente no tiene. Si está familiarizado con Docker y considera mudarse a Kubernetes / OpenShift como plataforma de contenedores, Podman será útil.
Podman puede generar un archivo YAML de Kubernetes basado en un contenedor en ejecución utilizando el comando podman generate kube. Y al depurar pods en ejecución, además de los comandos estándar para trabajar con contenedores, también puede usar el comando podman pod. Para obtener más información sobre cómo Podman ayuda a cambiar a Kubernetes, consulte el artículo de Brent Baude Podman ahora puede facilitar la transición a Kubernetes y CRI-O.
Buildah: qué es y por qué
Buildah apareció antes que Podman. Y esto a veces desalienta a los usuarios de Docker: “¿Por qué los apologistas de Podman hablan repentinamente de Buildah? ¿Podman no sabe cómo construir? "
Nos apresuramos a tranquilizar, Podman puede, y lo hace igual que Docker. Es decir, el ensamblaje se puede realizar utilizando el Dockerfile y el comando de construcción podman, o puede iniciar el contenedor, realizar los cambios necesarios y luego confirmarlos (ejecutar commit), creando una nueva etiqueta en la imagen del contenedor. En nuestra interpretación, Buildah es un conjunto extendido de comandos para crear y administrar imágenes de contenedor y, por lo tanto, proporciona un control mucho más preciso cuando se trabaja con imágenes. El comando de compilación Podman contiene parcialmente la funcionalidad de Buildah y utiliza el mismo código de programa para la compilación que el propio Buildah.
La forma más eficiente de usar Buildah es escribir scripts de Bash para crear imágenes, de forma muy similar a como escribes para un Dockerfile.
En cuanto a la cronología de la aparición de Buildah y Podman, los eventos ocurrieron aproximadamente de la siguiente manera. Cuando Kubernetes aprendió a trabajar con CRI-O basado en el estándar OCI para tiempos de ejecución de contenedores, el demonio Docker ya no era necesario. Es decir, ya no era necesario instalar Docker en todos los nodos del clúster de Kubernetes para ejecutar pods y contenedores en él. Kubernetes ahora puede llamar a CRI-O, y ese puede ejecutar RunC directamente, lo que, a su vez, inicia procesos de contenedor. Sin embargo, si al mismo tiempo queremos usar el mismo clúster de Kubernetes no solo para el lanzamiento, sino también para construir contenedores (como, por ejemplo, en OpenShift), necesitaremos una nueva herramienta de compilación que no dependa del demonio Docker y , como resultado, no requeriría la instalación de Docker. Además, dicha herramienta, creada sobre la base de los proyectos de contenedores / almacenamiento y contenedores / imagen, eliminaría los riesgos de seguridad asociados con el socket abierto del demonio Docker durante el ensamblaje, y muchos usuarios de Docker están preocupados por estos riesgos.
Y Buildah se ha convertido en una herramienta tan nueva (el nombre se lee como "construir" e imita el acento de Boston del gerente del proyecto Dan Walsh al pronunciar la palabra "constructor"). Puede encontrar más información sobre Buildah en buildah.io, así como blogs y guías de enlaces al final de este artículo.
Hay un par de detalles más para aprender si desea usar Buildah:
- Proporciona un control más preciso al crear capas de imágenes. En particular, le permite hacer lo que muchos usuarios de contenedores siempre han querido hacer: confirmar muchos cambios a la vez con solo una capa.
- La carrera de Buildah y la carrera de Podman son dos cosas diferentes. Debido a que Buildah está diseñado para construir imágenes, su comando de ejecución es esencialmente el mismo que el comando EJECUTAR en el Dockerfile. William Henry, uno de los desarrolladores de Buildah, recuerda cómo surgió esta solución: “De alguna manera me quejaba de que algún puerto o montaje no funcionaba como esperaba. Dan Walsh (@rhatdan) sopesó todo y dijo que Buildah no debería trabajar con contenedores de esta manera. Todo, no más asignaciones de puertos ni volúmenes de montaje. Eliminamos estos indicadores y usamos buildah run en su lugar para ejecutar los comandos que se necesitan al crear imágenes de contenedor, por ejemplo, buildah run dnf -y install nginx ".
- Buildah puede crear imágenes desde cero (imágenes desde cero). Es decir, imágenes en las que no hay nada, literalmente. De hecho, si observa el almacenamiento del contenedor creado como resultado del comando buildah from scratch, habrá un directorio vacío. Esto es muy útil desde el punto de vista de la creación de imágenes súper livianas que contienen solo aquellos paquetes que son necesarios para ejecutar la aplicación.
¿Por qué construir desde cero? Comparemos la imagen de desarrollo de una aplicación Java con su imagen para un entorno de producción o para un entorno de ensayo. En la etapa de desarrollo, la imagen puede contener el compilador de Java, Maven y otras herramientas que el desarrollador necesita. Pero cuando se traduce a producción, solo el tiempo de ejecución de Java y sus paquetes deben permanecer en la imagen. Y, por cierto, para eliminar lo superfluo, no necesita un administrador de paquetes en absoluto, como DNF / YUM, y ni siquiera necesita Bash: puede hacer todo a través de la interfaz Buildah CLI, como se muestra en la figura a continuación, donde el contenedor multicapa tradicional está a la izquierda y un contenedor de una sola capa está a la derecha rascar la imagen. Consulte
Creación de una imagen de contenedor Buildah para Kubernetes y
demostración de introducción de Buildah para obtener más detalles .
Volviendo a la cronología. Entonces, Kubernetes aprendió a trabajar con CRI-O y runC, y para la compilación apilamos Buildah: ¿todo, desde Docker en el host Kubernetes, puede rechazar? No, la depuración aún permanece. ¿Cómo resolver problemas con contenedores si el host no tiene las herramientas adecuadas? No pongas a Docker en él, de lo contrario volveremos al demonio y todos los esfuerzos fueron en vano. Y luego Podman entra en escena.
Es decir, Podman resuelve dos problemas a la vez. Primero, permite a los operadores de TI inspeccionar contenedores e imágenes utilizando comandos familiares. Y en segundo lugar, les da estas mismas herramientas a los desarrolladores. Como resultado, todos los usuarios de Docker, tanto desarrolladores como operadores, pueden cambiar a Podman y realizar con calma las tareas para las que utilizaron anteriormente Docker, así como resolver una serie de tareas nuevas.
Recursos necesarios:
- Sitio web para los proyectos Podman.io y Buildah.io.
- Proyectos en github.com/containers (conéctese, estudie la fuente y vea lo que se está desarrollando:
- libpod (Podman);
- buildah;
- imagen (código para trabajar con imágenes OCI de contenedor);
- almacenamiento (código para el almacenamiento local de imágenes de contenedor).
Enlaces utiles: