Podman. la nueva estrella en ascenso en un nuevo panorama de contenedores

Ya hace un tiempo que tomamos el tema de los Contenedores. ¿Qué contenedores? Esos métodos centrados en las aplicaciones para ofrecer aplicaciones escalables de alto rendimiento, en cualquier infraestructura que se elija. Son los más adecuados para ofrecer microservicios, al proporcionar entornos virtuales portátiles y aislados para que las aplicaciones se ejecuten sin interferencia de otras aplicaciones en ejecución.

¿Microservicios? Nos referimos a las aplicaciones ligeras escritas utilizando varios lenguajes de programación modernos, con sus propias dependencias, bibliotecas y requisitos ambientales específicos. Para garantizar que una aplicación tenga todo lo que necesita para ejecutarse correctamente, se empaqueta junto con sus Dependencias.

Por mucho tiempo Doker se consolidó como una plataforma de contenedorización de código abierto. Ha permitido a los desarrolladores empaquetar aplicaciones en contenedores. Digamos pues que Doker era la plataforma "de facto" para quien quisiera ejecutar contenedores.

Algo que caracteriza al Código Abierto, así como a todas y cada una de las comunidades y tecnologías que se basan en ésta, es el hecho de que nada ni nadie tiene la exclusiva sobre cualquiera de las mencionadas. Es por eso que ahora tenemos una alternativa más para ejecutar Contenedores. ¿Su nombre? Podman.

Podman (Pod Manager) es definido como -"...un motor de contenedores sin daemons (daemonless) para administrar y ejecutar contenedores apegado a la Open Container Initiative (OCI) en su sistema Linux. Los contenedores se pueden ejecutar como raíz o en modo sin raíz. En pocas palabras: alias docker=podman.

Es una estrella en ascenso en un nuevo panorama de contenedores que de repente tiene muchos más jugadores. Aprenda qué es Podman y cómo se compara con Docker para la compatibilidad con Kubernetes y más.

Podman es un proyecto de Red Hat que es de código abierto y de descarga gratuita. Es un recién llegado a la escena de la contenerización, con la versión 1.0 lanzada en 2019. Desde entonces, Podman ha hecho grandes avances, y su ascenso se ha visto agravado por el declive gradual de Docker, el proyecto que en muchos sentidos creó el mundo de los contenedores como lo sabemos hoy.

Podman y Kubernetes

Si está un poco familiarizado con el desarrollo basado en contenedores, conocerá el nombre Kubernetes. A medida que las aplicaciones en contenedores se volvieron más complejas, los desarrolladores necesitaron herramientas que pudieran coordinar los contenedores que interactuaban entre sí mientras se ejecutaban en diferentes máquinas virtuales, o incluso en diferentes máquinas físicas. Esta herramienta se denomina plataforma de orquestación de contenedores y Kubernetes es, con diferencia, el ejemplo más destacado. Kubernetes puede funcionar con cualquier contenedor que cumpla con la especificación de imagen de Open Container Initiative (OCI), lo que hacen los contenedores de Podman.

Una de las características importantes de Kubernetes es el concepto de pod, una agrupación efímera de uno o más contenedores que es la unidad informática más pequeña que puede administrar Kubernetes. Podman también se centra en la idea de una cápsula, como su nombre lo indica. Un pod de Podman también incluye uno o más contenedores, que se agrupan en un solo espacio de nombres, red y contexto de seguridad. Esta similitud hace que Podman y Kubernetes encajen de forma natural y, desde el principio, uno de los objetivos de Red Hat era que los usuarios de Podman organizaran contenedores con Kubernetes.

Podman contra Docker

El otro gran nombre del mundo de los contenedores que seguramente habrá escuchado es Docker. Docker no fue el primer motor de contenedores, pero en muchos sentidos ha llegado a definir la creación de contenedores. Gran parte del funcionamiento de Docker es el estándar de facto para el desarrollo basado en contenedores, lo suficiente como para que muchas personas utilicen "Docker" como abreviatura de contenedores.

Si bien Docker y Podman ocupan un espacio similar en el ecosistema de contenedores, no son lo mismo y tienen diferentes filosofías y enfoques sobre cómo funcionan. Por ejemplo, Docker es una plataforma todo en uno con herramientas para tareas específicas, mientras que Podman colabora con otros proyectos para ciertos fines; por ejemplo, se basa en Buildah para crear imágenes de contenedores.

También hay diferencias arquitectónicas: Docker no tiene un concepto nativo de pods, por ejemplo. Otra diferencia importante es que Docker se basa en un programa daemon en segundo plano que se ejecuta continuamente para crear imágenes y ejecutar contenedores, mientras que Podman lanza contenedores y pods como procesos secundarios independientes. Este aspecto del diseño de Docker tiene implicaciones importantes para la seguridad, que analizaremos en breve.

Comandos de Docker en Podman

Por diseño y necesidad, Podman y Docker son compatibles en general. Parte de esa compatibilidad se puede atribuir a la adhesión a estándares abiertos. Debido a que ambos motores funcionan con contenedores que cumplen con el estándar OCI, puede crear un contenedor con Docker y modificarlo en Podman, o viceversa, y luego implementar cualquiera de los contenedores en Kubernetes.

Cuando se lanzó Podman en 2019, Docker era tan dominante que su interfaz de línea de comandos se había convertido en parte de las rutinas de programación y la memoria muscular de muchos desarrolladores. Para hacer que un cambio potencial a Podman sea más fluido, los creadores de Podman se aseguraron de que sus comandos y sintaxis reflejaran la de Docker tanto como fuera posible. Fueron tan lejos como para hacer posible establecer un alias que redirigir los comandos de Docker a Podman.

Mejor seguridad con contenedores "sin raíz" (rootless)

Con Podman y Docker trabajando de manera tan similar en tantas formas, ¿por qué elegiría uno sobre el otro? Bueno, una razón importante es la seguridad. ¿Recuerda cómo Docker se basa en un daemon para realizar gran parte de su trabajo continuo? Ese demonio se ejecuta como root, lo que lo convierte en un punto de entrada potencial para los atacantes. Este no es un obstáculo insuperable para la informática segura, pero sí significa que debe pensar un poco en navegar por los problemas de seguridad de Docker.

En algunas situaciones, querrá ejecutar un contenedor con privilegios de root en su máquina host, y Podman le permite hacerlo. Pero si prefiere mantener sus contenedores restringidos de forma segura al espacio del usuario, también puede hacerlo ejecutando lo que se denomina un contenedor sin raíz. Un contenedor sin raíz no tiene más privilegios que el usuario que lo lanzó; dentro del contenedor, ese usuario tiene privilegios de root. También puede usar marcas de línea de comandos para agregar privilegios a sus contenedores de forma granular.

¿Qué hay con el rendimiento?

Un área en la que Docker tiene una ventaja sobre Podman es el rendimiento, al menos según algunos. Si bien hay poca información concreta sobre este tema, no es difícil encontrar desarrolladores frustrados en Hacker News, Stack Overflow y Reddit quejándose del rendimiento de Podman, especialmente cuando se ejecuta sin root. Algunos estudiantes universitarios suecos ejecutaron una suite de referencia en varias plataformas de contenedores diferentes y encontraron que Podman carecía, aunque es cierto que se trataba de una versión anterior a 1.0 de Podman. Si bien no hay mucha información técnica sobre este tema, anecdóticamente, Podman se ve criticado por su desempeño.

¿Podman reemplazará a Docker?

De la discusión hasta ahora, puede que no parezca que se está trabajando en un gran cambio de ambiente para reemplazar Docker con Podman. Pero se avecina un cambio importante que desplazará a Docker de uno de sus nichos de toda la vida: el mismo Kubernetes.

Kubernetes y Docker han sido durante años los gigantes gemelos del mundo de los contenedores. Pero su convivencia siempre fue algo incómoda. El auge de Kubernetes se produjo después de que Docker estuviera bien establecido en su nicho; de hecho, se podría decir que Kubernetes se hizo popular en parte porque Docker no estaba a la altura de la tarea de administrar todos los contenedores que debían coordinarse en una gran aplicación distribuida. .

Docker (la compañía) desarrolló su propia plataforma de orquestación de contenedores en 2015, denominada Swarm, que fue diseñada para aprovechar las fortalezas de Docker. Swarm se lanzó con gran fanfarria, pero nunca alcanzó a Kubernetes. Si bien Swarm todavía tiene devotos, Kubernetes se ha convertido en el estándar de facto para la orquestación de contenedores, al igual que Docker se convirtió en el estándar de facto para otros aspectos del ecosistema de contenedores.

Además, Docker nunca jugó bien con Kubernetes en términos de tiempo de ejecución de contenedores, el componente de bajo nivel del motor de contenedores que, entre otras tareas, funciona con el kernel del Sistema Operativo (SO) subyacente y monta imágenes de contenedores individuales. Tanto Docker como Kubernetes se ajustan a la especificación de imagen OCI, que Kubernetes usa para coordinar imágenes creadas en contenedores. Pero Kubernetes también se basa en tiempos de ejecución de contenedores compatibles con una API de complemento estandarizada llamada Interfaz de tiempo de ejecución de contenedores (Container Runtime Interface o CRI), que Docker nunca ha llegado a implementar.

Durante mucho tiempo, la popularidad de Docker obligó a Kubernetes a usar Dockershim, una capa compatible con CRI que era un intermediario entre Kubernetes y el demonio de Docker. Sin embargo, esto siempre fue una especie de truco y, a principios de este año, Kubernetes desechó el soporte para Dockershim. (Podman, por el contrario, utiliza el tiempo de ejecución CRI-O compatible de Cloud Native Computing Foundation).

Esto es parte de una historia más amplia sobre Docker que intenta y no logra convertirse en una empresa empresarial. En resumen, Docker nunca pudo separarse por completo de Kubernetes. Mientras tanto, Kubernetes ya no necesita Docker en la medida en que lo hacía antes.

No está claro si Podman reemplazará a Docker, pero definitivamente será uno de los contendientes. Ayuda que Podman no sea un producto insignia que busca ser monetizado, sino más bien una única oferta de tecnología de código abierto de una empresa mucho más grande. Podemos esperar que Podman y Kubernetes permanezcan entrelazados durante algún tiempo.

¿Qué motor de contenedor debería usar?

Con suerte, esta discusión le dará una idea de los factores que lo ayudarán a elegir entre estos dos motores de contenedores. Podman se basa en una arquitectura más segura, mientras que Docker tiene una historia más profunda. Podman es nativo de Kubernetes, mientras que Docker también funciona con Docker Swarm. Docker incluye toda la funcionalidad que necesita para muchas tareas relacionadas con contenedores. Podman es modular y te permite experimentar con diferentes herramientas para diferentes propósitos.

Dicho esto, la pregunta "Podman vs. Docker" es, en cierto modo, una elección falsa. Ambas plataformas crean imágenes que se ajustan a las especificaciones de OCI, y ambas funcionan con muchos de los mismos comandos, por lo que puede moverse sin problemas entre las dos. Por ejemplo, puede querer usar Docker para el desarrollo local y luego usar Podman para implementar los contenedores que creó dentro de Kubernetes.

Una característica que distingue a Docker es que viene con soporte pago. Pero incluso esto tiene un lado negativo: mientras Docker (la empresa) intenta monetizar su oferta principal, ha comenzado a cobrar por el entorno de desarrollo de Docker Desktop. Red Hat, por otro lado, parece contento con dejar libre a Podman (como en la cerveza) por ahora.

Al final, la ventaja principal que vemos a priori es que existen ya dos grandes alternativas para los ambientes de ejecución de nuestros contenedores. Esto al final genera competencia y esta es el mejor catalizador para que cualquiera de estas alternativas mejore cada vez más.

¿Cuál es para Usted la mejor altenetiva?

Tecnología de contenedores: moviéndose en un flujo continuo

Las presiones comerciales y los Ciclos Ágiles están aumentando la frecuencia de lanzamiento requerida para la entrega de programas, aplicaciones y funciones. Se están inspirando y gestando nuevos enfoques para lograr un flujo continuo en DevOps, allanando el camino para entregar software de calidad. Estos desarrollos están empujando a las organizaciones a explorar formas más efectivas de diseñar sus lanzamientos. Uno que está ganando un atractivo significativo para muchas organizaciones de desarrollo es la Tecnología de Contenedores.

Contenedores es una tecnología que está "en llamas" en este momento, ya que las empresas necesitan cada vez más ofrecer soluciones seguras y confiables, sin sacrificar la velocidad de liberación y al mismo tiempo controlar los costos. Este impulso que trae el Contenedor es evidente en prácticamente todos los informes de analistas sobre DevOps.

El estado de los Contenedores

Para 2023, el 70% de las organizaciones ejecutarán tres o más aplicaciones en Contenedores en producción, según una investigación reciente de Gartner. Con la innovación de TI empresarial, DevOps y la Transformación Digital moviéndose a la velocidad de la luz, los Contenedores son clave para ayudar a las organizaciones a aumentar su competitividad y agilidad operativa.

Como se indica en la figura anterior, el atractivo de los Contenedores es innegable. Su diseño significa que la eficiencia y la velocidad superan con creces las instalaciones a "metal desnudo" (bare metal), e incluso a los entornos virtuales. A pesar del atractivo y la promesa de la tecnología de Contenedores, presenta un nuevo ecosistema de tecnologías, que agrega complejidad.

Dentro del ecosistema de software, los Contenedores afectan positivamente a todo, incluido el tiempo de ejecución, la administración, la estructura y las operaciones. Aunado a lo anterior, su capacidad para acelerar los ciclos de entrega de software al tiempo que garantiza la fiabilidad del proceso los hace invaluables para muchas organizaciones.

Potencial casi ilimitado de los Contenedores

Los Contenedores pueden mejorar dramáticamente la velocidad de entrega del software, la independencia de la plataforma, la utilización de los recursos y la confiabilidad del proceso. Son un gran camino para las organizaciones en el mundo acelerado y delgado de hoy.

Independencia de su evidente ventaja que les confiere el poder aprovechar la plataforma y el ambiente de ejecución en cualquier lugar, gracias a que se "conteneriza" el paquete que contiene el código, las configuraciones, las bibliotecas y dependencias que necesitan para ejecutarse de manera consistente en cualquier entorno. Esta portabilidad permite a las organizaciones construir una vez e implementar muchas veces, ya sea localmente o utilizando cualquiera de los proveedores de la Nube Púublica, sin necesidad alguna de reconstruir la aplicación o rearmar el Contenedor.

Sólo por enumerar algunas de las más importantes ventajas que ofrecen los Contenedores, podemos mencionar:

• Utilización de recursos mejorada: los Contenedores proporcionan aislamiento del proceso, lo que permite un control detallado sobre el Procesador y la Memoria para un mejor uso de los recursos. Mientras que una Máquina Virtual a menudo "pesa" varios gigabytes, un Contenedor puede llegar a pesar megabytes, permitiendo que se ejecuten más Contenedores en un solo servidor de lo que es posible con las Máquinas Virtuales. Como resultado de una menor necesidad de recursos, las organizaciones disfrutan de una reducción significativa de costos al pasar de Máquinas Virtuales a un ecosistema de Contenedores.
  
• Arranque rápido: cada Contenedor se ejecuta como un proceso separado que comparte los recursos del sistema operativo subyacente. Las máquinas virtuales pueden tardar varios minutos en arrancar sus sistemas operativos y comenzar a ejecutar las aplicaciones que alojan, mientras que las aplicaciones en Contenedores se pueden iniciar en segundos.
  
• Mayor modularidad y seguridad: en lugar de ejecutar una sola aplicación compleja dentro de un solo Contenedor, la aplicación se puede dividir en módulos (Microservicios). Las aplicaciones creadas de esta manera son más fáciles de administrar, ya que cada módulo es relativamente simple y se pueden realizar cambios en los módulos sin tener que volver a compilar toda la aplicación.
  
• El aislamiento de Contenedores también disminuye los riesgos de seguridad: si una aplicación fuera "pirateada" o violada por malware, cualquier problema resultante no afectaría a otros Contenedores que ejecuten la misma aplicación. Incluso si el software malicioso afecta a un solo microservicio, todos los demás microservicios quedarían a salvo.
  
• Canalización de desarrollo optimizado: la utilización de un ecosistema basado en Contenedores elimina las inconsistencias de los ambientes de ejecución, lo que permite a los desarrolladores garantizar que las aplicaciones funcionen según lo diseñado. Los desarrolladores pasan menos tiempo probando y depurando versiones y configuraciones para ambientes particulares, ya que los Contenedores se pueden replicar para los entornos de desarrollo, prueba, control de calidad y producción de una organización.
  
• Implementación de producción simplificada: actualizar una aplicación en producción se vuelve más fácil usando Contenedores. Se puede realizar utilizando varios métodos de implementación, por lo que una vez que se implementan los cambios, si se encuentran fallas en la producción se pueden revertir inmediatamente a la versión anterior. Esto reduce el impacto de las fallas de implementación en los clientes de una organización.

El papel de los Contenedores en el logro del flujo continuo

Adoptado del mundo de la fabricación, el flujo esbelto y continuo se ha convertido en un ideal que muchas organizaciones de DevOps se esfuerzan por lograr pero luchan por implementar. Para aplicar prácticas esbeltas a los modelos de entrega de software de manera significativa, el flujo del proceso debe soportar el movimiento de los cambios de código a la producción de manera rápida, confiable y continua.

Los Contenedores pueden ayudarlo a acercarse al flujo continuo. Aplicar el mismo pensamiento continuo a los Contenedores puede ayudarlo a trazar un camino hacia adelante, pero hay muchos aspectos a considerar.

Un enfoque continuo de Contenedores ayuda a despejar la niebla a medida que las organizaciones intentan satisfacer las demandas modernas de ciclos más rápidos y avanzar hacia una base de Contenedores. Hay nueve aspectos clave que debe abordar a medida que se traslada a los Contenedores que permiten ejecutar la velocidad y la agilidad durante todo el ciclo de vida de una manera integrada y automatizada. Esto afecta a las personas, los procesos, la tecnología y los cambios culturales.

Para tener aún más claro todo el concepto de los Contenedores, dentro del ámbito de las Tecnologías de la información, vale la pena echar una mirada a los

Nueve aspectos clave

• Contenedorización: la clave para lograr Contenedores continuos es contener las aplicaciones existentes y nuevas.
• Automatización de Contenedores: con ciclos más rápidos y la confianza de calidad requerida, la automatización de Contenedores es crítica.
• Operaciones de Contenedores: operar en un ecosistema de Contenedores significa cambiar los enfoques de operaciones tradicionales. Requiere comprender la nueva cadena de herramientas y el ciclo de vida general.
• Conectividad de Contenedores: los contenedores necesitan nuevas formas de conexión y comunicación. Comprender cómo encajan y se relacionan es fundamental.
• DevOps: Madurar las capacidades de DevOps, lo que significa conectar los silos tradicionales, reexaminar los procesos y racionalizar el ciclo de vida y el flujo.
• Integración del flujo: un componente fundamental de los Contenedores continuos es comprender e integrar la cadena de herramientas y el ciclo de vida general.
• Arquitectura de Contenedores: la conducción a Contenedores debe incluir una arquitectura bien pensada diseñada para satisfacer sus necesidades.
• Cambiar la cultura: los Contenedores continuos implican cambiar la forma en que las personas piensan en todos los niveles de la organización, la forma en que las personas están conectadas y la forma en que trabajan.
• Alineación de personas y organización: los Contenedores continuos exigen un cambio en las responsabilidades, lo que permite que muchos equipos e individuos contribuyan a lo largo del ciclo de vida y el flujo.

Realidades de los Contenedores

Las empresas pueden realizar mejoras sustanciales con los Contenedores. Sin embargo, los Contenedores por si mismos no son una solución "lista para usar". Aprovecharlos correctamente, garantizar que sean seguros y en ocasiones el desplegarlos con éxito involucra ciertas operaciones complejas. Estos son los puntos críticos a considerar:

• Adoptar, implementar y administrar contenedores se logra más fácilmente con un plan integral y una estrategia a largo plazo.
  
• Los comportamientos arraigados y el territorialismo entre los equipos de trabajo pueden ser serios impedimentos para la adopción.
  
• A pesar de su apodo atractivo, los Contenedores no son una solución autónoma. Las actividades asociadas y las herramientas del ecosistema deben acompañar el despliegue.
  
• Para un éxito duradero, las organizaciones preferiblemente ya tendrán una práctica de DevOps madura.

Incluso con estas advertencias, los beneficios para las empresas que adoptan contenedores en términos de velocidad, agilidad y eficiencia del proceso de software son innegables.

¿Conclusión? Los Contenedores no son una palabra rara, una moda, una tendencia efímera o algo que la gente está mencionando para aparentar cierta sofisticación. Son una excelente y muy seria alternativa a los Microservicios, así como un aliado valiosísimo para DevOps. Las empresas que se dedican por completo al Desarrollo de aplicaciones, así como las áreas de Desarrollo de las empresas que dejen fuera a los Contenedores, están seriamente condenadas al fracaso y la extinción.