Herramientas de usuario

Herramientas del sitio


contenedores:debates-internos

Debates internos en la comunidad de desarrolladores

La comunidad de infraestructura: The Moby Project

El proyecto Docker es producto comercial basada en un motor open source. Para separar ambos planos se renombró como “proyecto Moby” la parte de motor que podrían usar tanto Docker como otras herramientas de usuario para manejar la tecnología de contenedores (cgroups y namespaces).

Con la compra de Docker (empresa) por parte de Mirantis los desarrolladores de Moby han decidido renombrer su proyecto de Moby a Docker.

https://github.com/moby/moby/

Fuente de la imagen: https://collabnix.com/demystifying-the-relationship-between-moby-docker/

La lista de proyectos del ecosistema Docker de fuentes abiertas puede encontrarse en https://www.docker.com/community/open-source

BuildKit: A set of tooling for building and packaging software using containers
Compose: Define and run multi-container applications with Docker
containerd: The industry-standard core container runtime, donated to the CNCF (Cloud-native Computing Foundation) with an emphasis on simplicity, robustness and portability
DataKit: A tool to orchestrate applications using a 9P dataflow
Docker CLI: The cli used in the Docker CE and Docker EE products.
Docker Distribution: The Docker toolset to pack, ship, store, and deliver content.
HyperKit: A toolkit for embedding hypervisor capabilities in your application
InfraKit: A toolkit for creating and managing declarative, self-healing infrastructure
Libnetwork: A native Go implementation for connecting containers
Moby Project: An open framework to assemble specialized container systems without reinventing the wheel.
Linuxkit: a toolkit for building custom minimal, immutable Linux distributions
Notary: A tool for running and interacting with trusted content collection - donated to the CNCF
Runc: The reference implementation for the Open Container Initiative (OCI)
Swarmkit: A toolkit for orchestrating distributed systems at any scale

Su relación con Docker

Los componentes y herramientas en el Proyecto Moby son inicialmente los componentes de código abierto que Docker y la comunidad han construido para el Proyecto Docker. Se pueden agregar nuevos proyectos si se ajustan a los objetivos de la comunidad. Docker se compromete a utilizar Moby como el proveedor del producto Docker. Sin embargo, también se alienta a otros proyectos a utilizar Moby como un flujo ascendente y a reutilizar los componentes de diversas maneras, y todos estos usos serán tratados de la misma manera. Los encargados y colaboradores externos son bienvenidos.

El proyecto Moby no pretende ser una ubicación para soporte o solicitudes de características para productos Docker, sino un lugar para que los contribuyentes trabajen en código fuente abierto, corrijan errores y hagan que el código sea más útil. Las versiones son respaldadas por los mantenedores, la comunidad y los usuarios, solo en base a los mejores esfuerzos, y no están destinados a clientes que desean soporte comercial o empresarial; Docker EE es el producto apropiado para estos casos de uso.

Comentarios de los desarrolladores de Moby

En el issue Rename moby to docker #40222 ha habido varios comentarios iluminadores de los desarrolladores.

Solomon Hykes

Solomon Hykes es el creador del software Docker, proyecto de código abierto.

En este comentario del repositorio moby/moby de GitHub, Hykes dice

NOTA: No hablo en nombre de Docker. A continuación se muestra mi opinión personal y recuerdo de los hechos. No es un comentario oficial autorizado.

El objetivo de la división Moby/Docker era bastante simple: separar el código de infraestructura de las herramientas de desarrollo, para que podamos separar a la gente de “Docker es infraestructura” de la gente de “Docker es una herramienta de desarrollo”.

Esta separación de personas en comunidades separadas fue muy importante, ¡porque esas personas NO se llevaban bien! Las personas de infraestructura y de devtool tienen diferentes objetivos y prioridades, y no era sostenible para un proyecto tratar de hacer felices a ambos grupos. Creó demasiado conflicto, demasiados malentendidos y, en última instancia, quemó a la gente (incluido yo mismo). Gran parte del drama “Docker no está realmente abierto, lo que significa que la gente de Docker no fusionó mi RP” en realidad se deriva de este malentendido fundamental entre la infraestructura y las personas devtools.

La división Moby/Docker tenía como objetivo resolver este conflicto diciendo “Docker es una herramienta de desarrollo; Moby es infraestructura. Si está interesado en las herramientas de desarrollo, mire Docker. Si está interesado en la infraestructura, vea Moby”. Como era de esperar, esto creó confusión y, a veces, enojo para las personas de infraestructura, porque los obligó a cambiar su definición de Docker. Por otro lado, las personas que ya pensaban en Docker como una herramienta de desarrollo no estaban confundidas, porque no estaban obligadas a cambiar su definición.

Finalmente, la separación de las comunidades tuvo lugar, y ayudó a aumentar la productividad y disminuir el drama. Pero en retrospectiva, el factor más importante no fue la división de Moby, sino la división de containerd.

NOTA: Ver What is containerd en el blog de Docker y Docker, Containerd & Standalone Runtimes — Here’s What You Should Know para comprender el ecosistema de servicios de Docker: Containerd is one of the recent projects in the Docker ecosystem and its purpose is breaking up more modularity to Docker architecture and more neutrality visà-vis the other industry actors (Cloud providers and other orchestration services). According to Solomon Hykes, containerd is already deployed on millions of machines since April 2016 when it was included in Docker 1.11. The announced roadmap to extend containerd get its input from the cloud providers and actors like Alibaba Cloud, AWS, Google, IBM, Microsoft, and other active members of the container ecosystem. More Docker engine functionality will be added to containerd so that containerd 1.0 will provide all the core primitives you need to manage containers with parity on Linux and Windows hosts.

Una vez que CRI permitió que los usuarios de Kubernetes elijan su tiempo de ejecución favorito en lugar de quedarse atrapados en dockerd, muchas de las personas enfadadas de Kubernetes se fueron, ya sea al repositorio de contenedores, a CRI-O, o cualquier otra cosa que las personas ejecuten ahora.

NOTA: Ver la página about de CRI-O: “CRI-O es un tiempo de ejecución de contenedor ligero y optimizado para Kubernetes. Es compatible con OCI (Open Container Initiative) y una alternativa a Docker o Moby. CRI-O admite imágenes de contenedor OCI y puede extraer desde cualquier registro de contenedor.”

No sé si revertir la división de Moby es una buena idea (mi instinto me dice que no vale la pena, pero no lo sé). Sin embargo, por favor, mantengan una separación clara entre infraestructura y herramientas de desarrollo. ¡Y no hagan de Docker un proyecto de infraestructura! No lo es, y nunca debería haberlo sido. A menos que alguien haya sido un desarrollador/mantenedor a tiempo completo en Docker antes de la separación entre infraestructura y desarrollo no tienes ni idea de lo doloroso que es combinar desarrollo de herramientas y desarrollo de infraestructura en el mismo proyecto de código abierto, a gran escala. No lo desearía para mi peor enemigo.

Decidas lo que decidas, te deseo la mejor de las suertes. Y mientras lo hago: gracias por preocuparse lo suficiente como para mencionar este importante tema :)

Asim Aslam

Aslam es fundador de Micro indica en este comentario

Gracias por compartir tus pensamientos Solomon. Muchos de nosotros no tenemos estas ideas o el punto de vista interno y no creo que esto se haya reflejado claramente en el momento del cambio de nombre. Puedo entender que probablemente fue una decisión increíblemente difícil en ese momento y resolvió muchos problemas. Desafortunadamente, desde el punto de vista del desarrollador, siento que lo que era “docker” se perdió en algún lugar en medio de eso junto con los apodos de CE/EE (Community Edition / Enterprise Edition)

Incluso si este proyecto específico no se renombra a moby (que personalmente considero que es lo que debería de hacerse considerando su valor y centro de gravedad), https://github.com/docker/docker debería ser una cosa, debería existir en alguna forma. Porque ese es francamente el lugar donde las personas van a ir, y si aterrizan en github.com/docker no lo ven. Si no se proporciona esa visión unificada es un poco difícil entender para un desarrollador dónde comienzar a contribuir o cómo moverse a través del ecosistema. Esto solo son mis pensamientos.

Nuevamente, gracias por compartir y todo lo que has hecho para traer a Docker a este mundo. Vivirá durante muchos años en aquellos que buscan encontrar la infraestructura de este nuestro mundo y en los corazones y las mentes de todos los desarrolladores.

A esto le contesta Solomon Hykes de esta forma

Señala bien @asim que no hay un lugar obvio para que los usuarios de Docker comiencen a participar en la comunidad de código abierto. Visitando el sitio web en este momento, hay https://www.docker.com/community/open-source, que hace un buen trabajo al presentar los diversos proyectos. Creo que es un buen comienzo que podría mejorarse aún más. La holgura de la comunidad también es un gran lugar.

Personalmente, creo que el mejor lugar para dar sus primeros pasos como contribuyentes podrían ser las herramientas Docker. ¿Quizás la CLI de Docker podría tener un complemento que lo ayude a informar errores, proponer características e incluso hacer contribuciones? Podría proporcionar una experiencia más personalizada e interactiva, y también dejaría a los encargados de la libertad de decidir su estructura de repositorio y cambiar de opinión con el tiempo.

Para mí, tiene sentido que obtener soporte para un producto y sugerir cambios se considere parte de la experiencia del producto en sí.

Un ejemplo de las diferentes mentalidades: ¿docker run es infraestructura o herramienta de desarrolladores?

Por qué “docker run” es un tema de discusión lo recume bien SvenDowideit en su comentario:

Trabajo con investigadores que usan computadoras y código para crear resultados científicos, por lo que su enfoque principal es su ciencia … les encanta usar Docker para reducir la carga cognitiva, pero en mi opinión, el enfoque de Docker como herramientas de desarrollo (y mezclado en infra) les causa dolor.

Hacer un CLI (Intérprete de Línea de Comandos) por separado para ellos no parece ser la respuesta correcta, con razón buscan información en Google para solucionar sus dudas, que no son la parte de “build” (construir) ni la de “ship” (desplegar). Es solo “docker run” lo que es una peste pare ellos.

El punto de vista de la mentalidad de infraestructura lo plantea bien AkihiroSuda en este comentario:

¿Quizás los complementos CLI (introducidos en Docker 19.03) pueden cambiar la situación?

Las partes “infra” de la CLI, incluida la ejecución de la ventana acoplable, se pueden mover a moby / moby repo para facilitar la apertura de nuevos PR de funciones de infraestructura.

Los comandos con opiniones de Docker como la pila de docker aún podrían permanecer en docker / cli repo pero como complementos de CLI.

A lo cual Solomon Hayks contesta esto:

@AkihiroSuda, en realidad, creo que Docker Run debería considerarse una característica de devtool, no una infraestructura.

Por un lado, el consenso en la comunidad de infraestructura parece ser: evitar hacer wrapping de “docker run” para infraestructura de tiempo de ejecución; en su lugar considerar el uso de containerd u otro proyecto de infraestructura de la competencia, como systemd, lxd, cri-o, etc.

Por otro lado, si eres un desarrollador o si eres responsable de la productividad del desarrollador, confías en Docker Run y, en general, estás contento con eso. Yo diría que, si Docker Run estuviera libre de la carga de ser tanto una infraestructura como una herramienta de desarrollo al mismo tiempo, podría ser una herramienta de desarrollo aún mejor. Por ejemplo, ¿tal vez podría soportar más backends? ¿Qué pasaría si pudiera apuntar Docker Run en cualquier clúster Kubernetes, Swarm o ECS, y obtener un contenedor en ejecución utilizando la misma interfaz familiar y consistente? Este es solo un ejemplo, aunque no sé cuánto se necesita esa característica en particular.

El punto es: la comunidad de infraestructura no quiere usar Docker Run. La comunidad de desarrolladores lo hace. Por lo tanto, recomiendo centrarse en aquellos usuarios que realmente disfrutan de la herramienta y desean usarla más.

Drew Erny

En este comentario del repositorio moby/moby de GitHub, Drew Erny dice

NOTA: No hablo en nombre de Docker, y mi memoria es un poco basura, por lo que esta publicación incluye mucho “como recuerdo” y “en mi entendimiento”, pero como he estado bastante amargado por estos temas durante bastante tiempo pues aquí estoy contándolo.

El cambio de nombre a moby/moby fue una decisión intensamente política, según recuerdo, en lugar de una decisión de ingeniería. Fue poco después del lanzamiento del Swarm Mode, que fue recibido, como estoy seguro que muchos recuerdan, con bastante hostilidad (especialmente en el sitio web de The Orange).

NOTA: Ver

La acusación de los detractores, tal como lo entendí, era que Docker-la-compañía ejercía demasiado control sobre Docker-el-proyecto-open-source, que Docker la compañía no respetaba a la comunidad, etc. La separación de moby/moby era un intento de apaciguar a los detractores, cortar una gran parte de “Docker” y decir: “Mira, esta parte es para la gente enfadada. Trabajaremos para quitar del código todos los trozos que no te gusten”. Se hizo la promesa de que la tecnología que impulsa a Docker fuera más modular, de modo que “los otros chicos” (kubernetes principalmente, si la memoria sirve) podría tomar las partes que quisieran, y Docker podría continuar en la dirección que quisiera.

Esto obviamente no funcionó. El Gran-Cambio-de-Nombre es probablemente uno de los peores ejemplos de poner el carro delante del caballo. El trabajo de marketing fue primero, dramáticamente, con Solomon et al presionando el interruptor y renombrando el proyecto en el escenario allí mismo en DockerCon, antes de que se materializara cualquier trabajo de ingeniería real para “hacer Docker más modular”. La intención era que el cambio de nombre se tradujera en acciones de ingeniería concretas, pero esa acción de ingeniería concreta fue vaga y mal definida desde el principio. Irónicamente, moby/moby parece haber evolucionado poco hacia un conjunto modular de componentes y más hacia ser el lugar en el que se agregan varios componentes modulares.

El problema para mí siempre ha sido la sensación de que los detractores que instigaban esto rara vez operaban de buena fe. La acusación de que Docker-La-Compañía tenía demasiada influencia era menos sobre su preocupación por la salud de la comunidad y tenía más que ver con el hecho de que todos estos otros jugadores querían tener un pedazo del pastel Docker. Cuando hicimos algo como el Swarm Mode, fue un insulto para ellos, Docker-La-Compañía se sobrepasó respecto a su papel como los mantenedores de este software gratuito en el que se construyó su negocio y privilegiando sus propios intereses. Ciertamente, el hecho de que Swarm haya surgido, completamente formado y vestido con una armadura como la de Atenea en la frente de Zeus, no contribuyó a refutar esa idea. Pero, por otro lado, parecía que esos mismos detractores que siempre velaban por sus propios intereses, tenían poca razón en acusar a Docker-La-Compañía por defender también sus propios intereses.

En última instancia, el cambio a moby/moby ha sido poco más que El-Gran-Cambio-De-Nombre. El gran trabajo de ingeniería que le siguió no fue causado de ninguna manera por El-Gran-Cambio-De-Nombre, sino por sus propios méritos. Y además, la ruta de importación canónica para todas estas cosas nunca ha sido otra que github.com/docker/docker. Francamente, es un poco sorprendente que “moby/moby” haya aguantado tanto tiempo.

Además, hizo que el proceso de compilación de Docker fuera un grano gigantesco en el culo (tal como dijeron que sería algunas personas a las que elijo no nombrar).

Finalmente, a propósito de esta publicación, aunque separándome un poco del tema original, creo que la impresión de que la comunidad “se mudó” a Kubernetes es menos el resultado de la obsolescencia tecnológica de Docker, o incluso la mala administración de la comunidad por parte de Docker-La Compañía, y fue más el resultado de que Kubernetes es para la mayoría de esos detractores lo que querían que fuera Docker: un espacio vacío en el que pueden verter su propia salsa especial. Un software servil que nunca compite. Un chasis rodante, un marco o sustrato, casi inutilizable por sí solo, sobre el que puede proyectar sus propios sueños y aspiraciones y construir una empresa.

Kubernetes no es “baterías incluidas y además extraíbles”, como es Swarm. Kubernetes es Las Baterías, Todas Las Baterías y Nada Más Que Las Baterías.

contenedores/debates-internos.txt · Última modificación: 2019/12/18 10:47 por jherrero