Docker ?

Hubo un momento en que la ventana acoplable era la única opción, cuando pensaba en hacer microservicios e intentar romper lo monolítico y finalmente tener una arquitectura escalable y orientada a servicios. sin embargo, el mundo está cambiando y tenemos que estar al día con las tendencias y, si es posible, anticiparnos a las próximas oleadas de innovación, mi idea en este artículo es precisamente evaluar alternativas a la ventana acoplable.

¿Dónde no usar Docker?

Si ha sido un usuario de Docker durante mucho tiempo, creo que le llevará un tiempo considerar cambiar a diferentes herramientas. Entonces, aquí va:

Primero, Docker es una herramienta monolítica. Es una herramienta que intenta hacerlo todo, lo que generalmente no es el mejor enfoque. La mayoría de las veces, es mejor elegir una herramienta especializada que haga solo una cosa, pero que lo haga muy bien.

Si tiene miedo de cambiar a un conjunto diferente de herramientas, porque tendría que aprender a trabajar con una CLI diferente, una API diferente o, en general, conceptos diferentes, entonces esto no será un problema. La elección de cualquiera de las herramientas que se muestran en este artículo puede ser completamente perfecta, ya que todas (incluido Docker) se adhieren a la misma especificación bajo OCI, que es la abreviatura de Open Container Initiative. Esta iniciativa contiene especificaciones para el tiempo de ejecución del contenedor, la distribución del contenedor y las imágenes del contenedor, que cubre todos los recursos necesarios para trabajar con contenedores.

Puede elegir el conjunto de herramientas que mejor se adapte a sus necesidades y, al mismo tiempo, puede seguir utilizando las mismas API y comandos CLI que Docker.

Entonces, si está abierto a experimentar con nuevas herramientas, comparemos las ventajas, desventajas y características de Docker y sus competidores para ver si realmente tiene sentido considerar siquiera abandonar lasDocker.

alternativas motores de contenedores

Al comparar Docker con cualquier otra herramienta, necesitamos para dividirlo por sus componentes y lo primero de lo que deberíamos hablar es de los motores de contenedores. El motor de contenedores es una herramienta que proporciona una interfaz de usuario para trabajar con imágenes y contenedores para que no tenga que meterse con cosas como las reglas SECCOMP o las políticas de SELinux. Su trabajo también es extraer imágenes de repositorios remotos y expandirlas a su disco. Aparentemente, también ejecuta los contenedores, pero en realidad su trabajo es crear el manifiesto del contenedor y el directorio con capas de imágenes. Luego, los pasa al tiempo de ejecución del contenedor, como runc o crun.

Hay muchos mecanismos de contenedor disponibles, pero el competidor más destacado de Docker es Podman, desarrollado por Red Hat. A diferencia de Docker, Podman no necesita un demonio para ejecutarse y tampoco necesita privilegios de root, lo cual es una antigua preocupación de Docker. Según el nombre, Podman no solo puede ejecutar contenedores, sino también pods. Si no está familiarizado con el concepto de pods, pod es la unidad informática más pequeña de Kubernetes. Consiste en uno o más contenedores, el principal y los llamados sidecar, que realizan tareas de apoyo. Esto facilita que los usuarios de Podman migren posteriormente sus cargas de trabajo a Kubernetes.

Finalmente, Podman proporciona exactamente los mismos comandos de CLI que Docker, por lo que simplemente puede usar el alias docker = podman y pretender que nada ha cambiado (nada como estar mal, correcto).

Existen otros motores de contenedores además de Docker y Podman, pero los consideraría todos como tecnología sin salida o no como una opción adecuada para el desarrollo y uso local. Pero para tener una vista completa, al menos mencionemos lo que hay:

• CRI-O: cuando busca en Google qué es para crearlo, puede encontrarlo descrito como un mecanismo contenedor. Sin embargo, en realidad es el tiempo de ejecución del contenedor. Además del hecho de que no es realmente un motor, tampoco es adecuado para un uso “normal”. Y con eso quiero decir que fue creado específicamente para ser utilizado como tiempo de ejecución para Kubernetes (CRI) y no para el usuario final.
• rkt — rkt (“cohete”) es un motor de contenedores desarrollado por CoreOS. En realidad, este proyecto se cita aquí solo para que esté completo, porque el proyecto ha finalizado y su desarrollo se ha detenido y, por lo tanto, no debe utilizarse.
• LXD — LXD es el administrador de contenedores (demonio) para LXC (contenedores de Linux). Esta herramienta ofrece la capacidad de ejecutar contenedores del sistema que proporcionan un entorno de contenedor más similar a las máquinas virtuales. Se encuentra en un espacio muy estrecho y no tiene muchos usuarios, por lo que, a menos que tenga un caso de uso muy específico, es mejor usar Docker o Podman.

Imágenes construidas

Primero, permítanme presentarles a Buildah. Buildah es otra herramienta desarrollada por Red Hat y funciona muy bien con Podman. Si ya instaló Podman, es posible que haya notado el subcomando de compilación de podman, que en realidad es solo Buildah disfrazado, ya que su binario está incluido en Podman.

En cuanto a sus recursos, sigue la misma ruta que Podman: no tiene demonio ni raíz 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 creadas con Docker. También es capaz de construir imágenes a partir del Dockerfile o (nombre más apropiado) Containerfile, que es lo mismo con diferentes nombres. Además, Buildah también proporciona un control más preciso sobre las capas de la imagen, lo que le permite realizar muchos cambios en una sola capa. Una diferencia inesperada, pero (en mi opinión) agradable, de Docker es que las imágenes creadas por Buildah son específicas del usuario, por lo que solo puede enumerar las imágenes que ha creado.

El siguiente es Kaniko de Google. Kaniko también crea imágenes de contenedor a partir del Dockerfile y, de forma similar a Buildah, tampoco necesita un demonio. La principal diferencia de Buildah es que Kaniko se centra más en crear imágenes en Kubernetes.

Kaniko debe ejecutarse como una imagen, usando gcr.io/kaniko-project/executor, que tiene sentido para Kubernetes, pero no es muy conveniente para compilaciones locales y anula el propósito, ya que necesitaría usar Docker para ejecutar Kaniko imagen para construir tus imágenes. Dicho esto, si está buscando una herramienta para crear imágenes en su clúster de Kubernetes (por ejemplo, en la canalización de CI / CD), Kaniko puede ser una buena opción, considerando que no tiene demonio y (quizás) más

El tercer contendiente aquí es el kit de compilación, que también se puede llamar la compilación de la ventana acoplable de próxima generación. Es parte del proyecto Moby (al igual que Docker) y se puede habilitar con Docker como una función experimental usando DOCKER_BUILDKIT = 1 docker build … Bueno, pero ¿qué te traerá esto exactamente? Introduce muchas mejoras y características interesantes, que incluyen pasos de construcción paralelos, omisión de fases no utilizadas, mejores construcciones incrementales y construcciones desarraigadas. Por otro lado, sin embargo, todavía requiere un demonio para ejecutarse (buildkitd). Por lo tanto, si no desea deshacerse de Docker, pero desea algunas características nuevas y mejoras interesantes, usar el kit de compilación puede ser el camino a seguir.

Como en el apartado anterior, aquí también tenemos algunas “menciones honoríficas” que cumplen algunos casos de uso muy específicos y no serían una de mis principales opciones:

También hay algunas alternativas para casos muy concretos.

• Jib es otra herramienta de Google, específicamente para crear imágenes Java. Incluye complementos de Maven y Gradle, que pueden facilitar la creación de imágenes sin interferir con Dockerfiles.
• Source-To-Image (S2I) es un conjunto de herramientas para crear imágenes directamente desde el código fuente sin Dockerfile. Esta herramienta funciona bien para escenarios y flujos de trabajo simples y esperados, pero rápidamente se vuelve molesto e incómodo si necesita mucha personalización o si su proyecto no tiene el diseño esperado. Puede considerar el uso de S2I si aún no se siente muy seguro con Docker o si crea sus imágenes en el clúster de OpenShift, ya que las compilaciones de S2I son una característica integrada.
• Esto no es solo para crear imágenes de contenedores, sino para un sistema de construcción completo. Si solo desea construir una imagen, sumergirse en Bazel puede ser un poco exagerado, pero definitivamente es una buena experiencia de aprendizaje, por lo que si lo desea, la sección rules_docker es un buen punto de partida para usted.

Conclusión

la idea del artículo no es decir que hay que abandonar lo docker y migrar todo ahora, sino más bien mostrar que ya tenemos algunas alternativas en el horizonte y que a veces en escenarios específicos podemos tener mejores herramientas que las docker. Espero mostrarte algunas herramientas que no conocías y hagamos un laboratorio para probar las alternativas, ¡cierto!