Despliegue de servicios Docker Compose en Swarm

¿Docker Swarm frente a Docker Compose? ¡Ahora trabajan juntos! Docker 1.13 presentó una nueva versión de Docker Compose. La principal característica de esta versión es que permite que los servicios definidos mediante archivos Docker Compose se desplieguen directamente en Docker Engine habilitado con el modo Swarm. Docker Swarm con Docker Compose permite el despliegue simplificado de aplicaciones multicontenedor en múltiples hosts.

Este blog muestra cómo un simple archivo Docker Swarm y Docker Compose muestran cómo se crean y despliegan los servicios en Docker 1.13.

Aquí hay una definición de Docker Compose v2 para iniciar un nodo de base de datos Couchbase:

Esta definición se puede iniciar en un motor Docker sin modo Swarm como:

Esto iniciará una única réplica del servicio definido en el archivo Compose. Este servicio se puede escalar como:

Esto funcionaría bien en un solo host. Si el modo enjambre está habilitado en el motor Docker, entonces muestra el mensaje:

Docker Compose nos ofrece aplicaciones multicontenedor, pero las aplicaciones siguen estando restringidas a un único host. Y eso es un único punto de fallo. Docker Compose en modo Swarm permite crear un cluster de Docker Engines. Con 1.13, docker stack deploy se puede utilizar para desplegar un archivo Docker Compose en modo Docker Swarm. Este es un ejemplo de definición de Docker Compose v3:

Como puede ver, el único cambio es el valor de versión atributo. Existen otros cambios en Docker Compose v3. Lea también diferentes versiones de Docker Compose y cómo actualización de v2 a v3. Habilitar Docker Compose con modo enjambre:

Otros nodos pueden unirse a este cluster swarm y esto permitiría fácilmente desplegar la aplicación multi-contenedor a un multi-host también. Utilice Docker para desplegar los servicios en Swarm definidos en el archivo Compose como:

Un valor por defecto de Componer archivo aquí haría el comando un poco más corto. #30352 debería encargarse de ello. La lista de servicios en ejecución puede verificarse mediante docker service ls mando:

La lista de contenedores que se ejecutan dentro del servicio puede verse utilizando docker service ps mando:

En este caso, un único contenedor se está ejecutando como parte del servicio. El nodo aparece como moby que es el nombre por defecto del motor Docker que se ejecuta utilizando Docker para Mac. El servicio ahora se puede escalar como:

La lista de contenedores puede verse entonces de nuevo como:

Tenga en cuenta que los contenedores reciben el nombre utilizando el formato _n. Ambos contenedores se ejecutan en el mismo host. También hay que tener en cuenta que los dos contenedores son nodos Couchbase independientes y no están configurados en un cluster todavía. Esto ya se ha explicado en Cluster Couchbase usando Docker y pronto se actualizarán los pasos. Un servicio suele tener varios contenedores ejecutándose en varios hosts. Docker 1.13 introduce un nuevo comando registros del servicio docker para transmitir el registro de servicio a través de todos los contenedores en todos los hosts a su consola. En nuestro caso, esto se puede ver usando el comando docker service logs couchbase_db y parece:

El preámbulo de la sentencia log utiliza el formato .@. Y luego aparece el mensaje de registro real de su contenedor. A primera vista, adjuntar el id del contenedor puede parecer redundante. Pero Servicios Docker son auto-reparables. Esto significa que si un contenedor muere, el motor Docker iniciará otro contenedor para garantizar el número especificado de réplicas en un momento dado. Este nuevo contenedor tendrá un nuevo id. Y por lo tanto permite adjuntar el mensaje de registro del contenedor correcto. Así que una rápida comparación de comandos:

¿Quieres empezar a usar Couchbase? Mira en Kits de inicio de Couchbase. ¿Quieres saber más sobre cómo ejecutar Couchbase en contenedores?

• Couchbase en contenedores
• Foros de Couchbase
• Portal para desarrolladores de Couchbase
• @couchhasedev y @couchbase