Está claro que en la actualidad las pasiones en torno a Red Hat tienen un
enfoque completamente diferente y muy global, pero todavía estamos hablando de las nuestras, locales y aplicadas desde el mundo de los contenedores. Desde principios de este año, Red Hat ha estado trabajando activamente en un reemplazo para Docker llamado
Podman (o
libpod ). Por alguna razón, todavía no escribieron sobre este proyecto en el centro, pero ahora es un momento muy adecuado para conocerlo, conocer sus orígenes y pensar en las perspectivas. Vamos!
CRI-O como historia de fondo
Si observa el mundo moderno de los contenedores de Linux, es fácil ver que el tema del artículo de hoy es solo una de las etapas de la estrategia a largo plazo de Red Hat. Una vívida confirmación de esto es
el proyecto CRI-O , sobre el que
escribimos hace un año. En resumen, CRI-O es una implementación de Kubernetes CRI (Interfaz de tiempo de ejecución de contenedor) para lanzar tiempos de ejecución de contenedor compatibles con el estándar OCI (Open Container Initiative). Aún más corto, este es un reemplazo para Docker como un tiempo de ejecución para Kubernetes.
(Una iniciativa técnicamente similar para K8 de Docker Inc es cri-containerd , sobre la cual también escribimos ; en el mismo artículo, hay una comparación del rendimiento de estas dos soluciones).La historia de CRI-O es tal que mientras OCI estaba preparando estándares para contenedores (
especificación de tiempo de ejecución y
especificación de imagen )
[que, sin embargo, también sucedió con la participación de Red Hat] , se creó un nuevo proyecto llamado OCID y se colocó en la incubadora Kubernetes en HR ( Open Container Initiative Daemon), que más tarde [solicitado por OCI] pasó a llamarse CRI-O. Su propósito era "la implementación de una interfaz estándar para el entorno de tiempo de ejecución para contenedores en Kubernetes", y la promoción en las "masas técnicas" se llevó a cabo como parte de un proyecto más grande de Red Hat para crear un sistema operativo para contenedores: el
Proyecto Atómico .
Gorras con el logotipo CRI-O en KubeCon + CloudNativeCon North America 2017En el pasado, CRI-O ha madurado hasta la
versión 1.0 ,
recibió soporte en Minikube, y su último logro puede considerarse la
adopción de la interfaz de contenedor predeterminada en
el proyecto Kubic , que, más notablemente, es desarrollado por la comunidad competitiva (para Red Hat) Distribución de Linux - openSUSE.
Volviendo al tema del artículo: Podman fue originalmente parte de CRI-O.
La apariencia y esencia de Podman
El anuncio oficial del proyecto Podman (el nombre es la abreviatura de "pod manager")
tuvo lugar en febrero de este año:
“Podman (anteriormente conocido como kpod) existe desde el verano pasado. Inicialmente, era parte del proyecto CRI-O . Asignamos podman a un proyecto separado: libpod . Queríamos que tanto Podman como CRI-O crecieran a su propio ritmo. Ambos funcionan muy bien tanto individualmente (como utilidades independientes) como juntos ".
Por esta razón, el anuncio en sí se tituló como "
reintroducción" . Y el primer lanzamiento público de Podman -
v0.2 - tuvo lugar 2 semanas antes de este anuncio. Entonces, ¿cuál es la esencia de Podman?
El objetivo de Podman es proporcionar una interfaz de consola para lanzar contenedores fuera del sistema de orquestación. Es de destacar que los contenedores lanzados se pueden combinar en grupos especiales con espacios de nombres comunes, es decir. pods: este concepto ya se ha hecho conocido gracias a Kubernetes. El proyecto sigue la ideología de los comandos de UNIX, donde cada utilidad solo hace una cosa, pero es buena. Otro detalle importante, que los desarrolladores enfatizan incansablemente, ya se citó anteriormente en el anuncio: Podman se puede usar tanto con CRI-O como de forma independiente.
En general, la idea principal de Podman es proporcionar a los usuarios de Kubernetes que eligen CRI-O como tiempo de ejecución del contenedor un análogo de la interfaz de la consola Docker CLI (para interactuar con contenedores e imágenes que se ejecutan en grupos):
“Podman implementa 38 de los 40 comandos de Docker CLI definidos en Docker 1.13 (en el momento del anuncio en febrero - aprox. Transl. ), Pero algunos de ellos no los repetimos específicamente. Por ejemplo, en relación con Docker Swarm, en su lugar, para las vainas / contenedores que necesitan ser orquestados, sugerimos usar Kubernetes. Además, algunos comandos para Docker Plugins, como los complementos de volumen y para la red, no se implementaron. Puede encontrar una lista completa de los comandos de Podman y sus equivalentes en Docker en la página de transferencia de uso de Podman ".
Un fragmento de la tabla de comparación para los comandos Docker y Podman: la mayoría de ellos son iguales, pero también hay diferenciasSin embargo, detrás de esta identidad visible en la interfaz se encuentra una diferencia fundamental en la arquitectura: si la CLI de Docker se comunica con el demonio Docker para ejecutar comandos, entonces Podman es una utilidad independiente que no requiere ningún demonio para su trabajo.
Al menos debido a esta diferencia arquitectónica, sería más correcto comparar Podman no con Docker como tal, sino con crictl, una utilidad de consola de
cri-tools (se usa, en particular, para la
integración de contenedores con Kubernetes). Y existen diferencias funcionales: Podman puede reiniciar contenedores detenidos y también proporciona administración de imágenes de contenedores. (Para una comparación más detallada, vea el
blog OpenShift ).
Con el
lanzamiento de Fedora 28 Atomic Host (este mes de mayo), Podman se ha convertido en la herramienta de administración de contenedores predeterminada para esta distribución de Linux. Y solo recientemente, en septiembre, en la conferencia Linux All Systems Go! En Berlín, Dan Walsh, jefe del equipo de ingeniería de contenedores de Red Hat, presentó a Podman a un público aún más amplio:
aquí se puede ver una grabación de la actuación (pero solo la presentación
aquí ).
Presentación de Podman en All Systems Go! 2018Notas técnicas
La última versión de Podman es la
v0.10.1.3 (fechada el 18 de octubre), y la última con nuevas características es la
v0.10.1 (12 de octubre), que ha incorporado varios equipos nuevos y banderas adicionales.
El código de Podman está escrito en Go y se distribuye bajo la licencia gratuita Apache 2.0. Los paquetes listos para instalar están disponibles para Fedora versión 27 y posteriores (también hay
una guía de instalación para Ubuntu). Entre los componentes dependientes para que Podman funcione se encuentran utilidades para contenedores Linux como
runc y
conmon , así como
complementos de red CNI .
Tanto iniciar el contenedor con Podman como luego trabajar con él es similar al escenario habitual de uso de la
docker :
$ sudo podman run -dt -e HTTPD_VAR_RUN=/var/run/httpd -e HTTPD_MAIN_CONF_D_PATH=/etc/httpd/conf.d \ -e HTTPD_MAIN_CONF_PATH=/etc/httpd/conf \ -e HTTPD_CONTAINER_SCRIPTS_PATH=/usr/share/container-scripts/httpd/ \ registry.fedoraproject.org/f27/httpd /usr/bin/run-httpd $ sudo podman ps ... $ sudo podman inspect -l ... $ sudo podman logs --latest 10.88.0.1 - - [07/Feb/2018:15:22:11 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.55.1" "-" 10.88.0.1 - - [07/Feb/2018:15:22:30 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.55.1" "-" 10.88.0.1 - - [07/Feb/2018:15:22:30 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.55.1" "-" 10.88.0.1 - - [07/Feb/2018:15:22:31 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.55.1" "-" 10.88.0.1 - - [07/Feb/2018:15:22:31 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.55.1" "-" $ sudo podman top <container_id> UID PID PPID C STIME TTY TIME CMD 0 31873 31863 0 09:21 ? 00:00:00 nginx: master process nginx -g daemon off; 101 31889 31873 0 09:21 ? 00:00:00 nginx: worker process
Para una introducción práctica a Podman, también puede usar el script en línea apropiado de Katacoda: "
Contenedores sin Docker: lanzamiento de contenedores con Podman y Libpod ".
Finalmente, el proyecto
pypodman , que se encuentra en desarrollo activo y ofrece una interfaz escrita en Python para la ejecución remota de comandos de Podman, merece una mención especial.
No solo Podman: libpod y el ecosistema
Junto con Podman, el artículo ha mencionado repetidamente el proyecto libpod. Cual es la diferencia
Si hablamos del proyecto "completo" de Red Hat, en realidad se llama libpod y
está alojado en GitHub con ese nombre. Hoy, libpod se posiciona como "una biblioteca para aplicaciones que necesitan trabajar con el concepto de hogares de contenedores, popularizado por Kubernetes". Y el propio Podman es una utilidad que forma parte de la biblioteca libpod.
Si volvemos a una visión más amplia de los contenedores, entonces Red Hat tiene su propia visión, que cobra vida con un conjunto completo de utilidades para todas las ocasiones. La mayoría de ellos se concentran en repositorios con el nombre de habla
github.com/containers , y esto solo ya muestra las ambiciones obvias de la compañía
(por cierto, algunos de estos proyectos solían estar ubicados en github.com/projectatomic ) .
Las opiniones de Red Hat sobre la estandarización y el desarrollo del ecosistema contenedor se expresan directamente en el archivo README del proyecto libpod:
Ya escribimos sobre casi todos estos proyectos (runc, contenedores / imagen, contenedores / almacenamiento, CNI, conmon) en
la revisión CRI-O , sin embargo, una adición importante desde entonces fue una utilidad para construir imágenes de contenedores llamada
buildah . Además, Red Hat ya tiene respuestas listas para otras necesidades del mundo moderno de contenedores, como
udica para generar perfiles de seguridad SELinux y
skopeo para trabajar con registros de imágenes remotas.
Resumiendo
Al igual que Red Hat no solo está detrás de su plataforma empresarial para contenedores OpenShift, sino que también participa activamente en la vida del proyecto subyacente de código abierto Kubernetes, la compañía estadounidense se está dando cuenta de su visión sobre la infraestructura moderna de TI a un nivel más fundamental: los contenedores en sí, los ingenieros de DevOps y SRE están muy interesados en su orquestación. Podman y libpod son componentes importantes de todo el ecosistema que Red Hat está construyendo en el mundo de contenedores de estándares abiertos. Si observa lo que está sucediendo, el acuerdo con IBM mencionado al principio del artículo, que se
presenta como una iniciativa para formar un proveedor líder de soluciones en el campo de las nubes híbridas, parece aún más interesante en toda la industria ...
Finalmente, propongo una pequeña encuesta sobre el conocimiento de los lectores del Habra sobre el proyecto Podman antes de la aparición de este artículo. ¡Gracias por participar!
PS
Lea también en nuestro blog: