run - Cuándo usar Docker-Compose y cuándo usar Docker-Swarm

docker-compose start

Question

Estoy tratando de entender las diferencias o similitudes entre D-Compose y D-Swarm .

Al leer la documentación, he entendido que docker-compose proporciona un mecanismo para unir diferentes contenedores y trabajar en colaboración, como un solo servicio (supongo que está utilizando la misma funcionalidad que el comando --link utilizado para vincular dos contenedores)

Además, entiendo que docker-swarm es que le permite administrar un grupo de diferentes docker-hosts , cada uno de los cuales ejecuta varias instancias de contenedor de algunas imágenes de docker. Podríamos definir conexiones como redes superpuestas entre diferentes contenedores en el enjambre (incluso si están en dos docker-hosts en el enjambre) para conectarlos como una unidad.

Lo que estoy tratando de entender es si Docker-Swarm ha tenido éxito con Docker-Comose y las redes superpuestas es la nueva forma (recomendada) de conectar contenedores.

¿O es que Docker-compose sigue siendo una parte integral de toda la familia de acopladores y se espera y es aconsejable usarlo para conectar contenedores para trabajar en colaboración? Si es así, ¿Docker-compose funciona con contenedores a través de diferentes nodos en el enjambre?

¿O es que las redes superpuestas son para conectar contenedores a través de diferentes hosts en el enjambre y docker-compose es para crear enlaces internos?

Además, también veo que se menciona en la documentación de la ventana acoplable que los enlaces ya no se recomiendan y que pronto serán obsoletos.

¿¿¿Estoy un poco confundido???

¡Muchas gracias!

Answer 1

componer o enjambre o redes de superposición enjambre

Encontrará que necesita usar todo lo anterior si está haciendo algo más que una demostración en su computadora portátil, etc.

Deliberadamente separé las redes de superposición de enjambre y enjambre, porque no es necesario utilizar ambas, pero no puede obtener una red de superposición sin tener un enjambre debajo.

Componer es para traer varios contenedores juntos. Ahora tiene sentido que estén relacionados entre sí, aunque pueden no estarlo. Pero supongamos un caso típico cuando los contenedores son para servicios que están relacionados entre sí, entonces querrás que se comuniquen entre sí de alguna manera, pero que controlen cómo se comunican entre sí mediante redes. Por ejemplo, tome una aplicación de 3 niveles que tenga un servidor web, un servidor de aplicaciones y una base de datos. Digamos que los tres componentes están acoplados y está usando componer para reunirlos en lugar de ejecutar la ejecución de docker run.. tres veces con diferentes parámetros, etc. Los tres aparecerían, pero querrá controlar cómo se conectan entre sí. Desea que el servidor web pueda hablar con el servidor de aplicaciones, pero no directamente con el db. Y desearía que el servidor de aplicaciones hable (haga ping) al contenedor del servidor db y también haga ping al servidor web. Todas las conexiones son bidireccionales, pero están restringidas solo a aquellos servicios que desea poder comunicarse entre sí. Para tal arreglo, normalmente configuraría 2 redes, por ejemplo, frontend y backend . Los contenedores web y de aplicaciones están conectados a la red frontend. La aplicación y los contenedores db están conectados a la red de fondo. Debido a que no hay una red común entre los contenedores web y db, no pueden tocarse (hacer ping) entre sí, lo cual es su intención.

Ahora, si desea que estos 3 servicios puedan ejecutarse en su clúster de cientos de máquinas, y también desea escalarlos, necesitaría una red que abarque múltiples hosts. Ahí es donde entra en juego la red de superposición (en enjambre). La superposición de redes no es más que la creación de redes de múltiples hosts sobre la tecnología VxLAN. No tiene que saber sobre VxLAN, excepto que es una topología de red estándar que es compatible con casi toda la infraestructura de red moderna.

Espero que eso aclare.

Editar: ¡No vi que ya tienes una respuesta!

Answer 2

Creo que tiene la mayor parte de la comprensión correcta en cuanto a lo que cada uno es, pero se requieren algunos ajustes.

Lo correcto, docker-compose es abrir aplicaciones de contenedores múltiples. Anteriormente solía hacer docker run .. para iniciar cada contenedor. Por lo general, las aplicaciones modernas que abarcan el paradigma de los microservicios pueden estar formadas por docenas de servicios y el uso de docker run .. volverá muy cansado muy pronto. Por lo tanto, docker-compose le permite expresar todos los contenedores y sus propiedades y cómo se conectan entre sí como un archivo yaml o json para que pueda administrarlo de una manera más fácil.

Por lo tanto, docker-compose es la parte de orquestación de contenedores en el ecosistema de docker.

Los enlaces son diferentes, son solo una parte de los comandos docker-compose o docker run y están en desuso en favor de software defined networks cuyas overlay networks son solo una de ellas.

Enjambre es el componente de programación en Docker. Qué es la programación: no es más que averiguar dónde "colocar" sus contenedores en su clúster de hosts acoplables. Puede tener un clúster de cientos de servidores, y puede tener cientos de contenedores, cada uno de los cuales encapsula un servicio para una docena de aplicaciones diferentes. Ahora, ¿cómo deberían distribuirse estos contenedores en su clúster de cientos de servidores? ¿Deberían colocarse algunos contenedores solo en ciertos hosts porque satisfacen un criterio particular o tal vez deberían estar más cerca (o no) de otros contenedores que de alguna manera están relacionados? Todos estos son parte del componente de programación que realiza Docker Swarm.

Le sugiero que lea la documentación de inicio en docker.com aquí: https://docs.docker.com/engine/getstarted-voting-app/

Answer 3

Probablemente sea útil comenzar con algunas definiciones:

• docker-compose : comando utilizado para configurar y administrar un grupo de contenedores relacionados. Es una interfaz para la misma API utilizada por el Docker Cli, por lo que puede reproducir su comportamiento con comandos como docker run .
• docker-compose.yml : archivo de definición para un grupo de contenedores, utilizado por docker-compose y ahora también en modo enjambre.
• Modo de enjambre : se utiliza para administrar un grupo de motores acoplables como una sola entidad y proporcionar orquestación (constantemente tratando de corregir las diferencias entre el estado actual y el estado objetivo).
• servicio : uno o más contenedores para la misma imagen y configuración dentro del enjambre, múltiples contenedores proporcionan escalabilidad.
• stack : uno o más servicios dentro de un enjambre, estos pueden definirse utilizando un DAB o un archivo docker-compose.yml.
• Puente de red : Red gestionada por un único motor de acoplamiento donde múltiples contenedores pueden comunicarse entre sí. Puede tener varias redes administradas por un motor, y los contenedores se pueden conectar a cero o más redes.
• red superpuesta : similar a una red puente pero que abarca múltiples motores acoplables. Estos requieren un almacén de clave / valor para mantener su estado. El modo enjambre proporciona esto, pero si el modo enjambre está desactivado, también puede usar etcd, consul o zookeeper.
• enlaces : un método para conectar contenedores entre sí que es anterior a la red puenteada. Su uso ya no se recomienda.
• enjambre clásico : un predecesor del modo de enjambre integrado que se ejecuta como contenedor, permite que varios motores aparezcan como uno solo, pero no proporciona orquestación ni incluye su propia tienda k / v.

Para responder las preguntas:

¿Docker-swarm ha tenido éxito con Docker-compose y redes superpuestas? ¿Es la nueva forma (recomendada) de conectar contenedores?

¿O es que Docker-compose sigue siendo una parte integral de toda la familia de acopladores y se espera y es aconsejable usarlo para conectar contenedores para trabajar en colaboración? Si es así, ¿Docker-compose funciona con contenedores a través de diferentes nodos en el enjambre?

Proporcionan una funcionalidad diferente y continuarán cumpliendo ambos un propósito. docker-compose no puede iniciar contenedores dentro del modo enjambre, pero se puede usar una versión más nueva del archivo docker-compose.yml (versión 3) para definir una pila directamente en modo enjambre sin usar docker-compose. docker-compose es necesario para administrar contenedores fuera del modo enjambre, en un solo motor acoplable o con enjambre clásico.

¿O es que las redes superpuestas son para conectar contenedores a través de diferentes hosts en el enjambre y docker-compose es para crear enlaces internos?

Además, también veo que se menciona en la documentación de la ventana acoplable que los enlaces ya no se recomiendan y que pronto serán obsoletos.

docker-compose que comienza con la versión 2 del archivo yml conecta varios contenedores de manera predeterminada con una nueva red puenteada por proyecto (el proyecto se predetermina al nombre del directorio). Con el enjambre clásico, eso sería una red superpuesta que usa una tienda externa de k / v. Y con una pila de modo enjambre, esta sería una red superpuesta.

El uso de redes de acopladores es la forma preferida para que los contenedores se comuniquen entre sí. Desea una red por grupo de contenedores que desea aislar del resto de su entorno de acoplador. docker-compose automatiza esta creación de red, pero también puede hacerlo desde la línea de comandos con docker networks create .

La vinculación ha sido reemplazada en gran medida por redes de acopladores con descubrimiento de DNS incorporado. Cuando elimine enlaces de su docker-compose.yml, es posible que deba reemplazarlos con una sección depends_on para imponer el orden de inicio del contenedor. De lo contrario, hay muy pocos escenarios en los que la vinculación tiene sentido y todo el uso que he visto proviene de alguien que sigue la documentación obsoleta.