Deploy Docker Compose Services to Swarm

Docker Swarm vs Docker Compose? Now they work together! Docker 1.13 introduced a new version of Docker Compose. The main feature of this release is that it allow services defined using Docker Compose files to be directly deployed to Docker Engine enabled with Swarm mode. Docker Swarm with Docker Compose enables simplified deployment of multi-container application on multi-host.

This blog demonstrates how a simple Docker Swarm and Docker Compose file show how services are created and deployed in Docker 1.13.

Here is a Docker Compose v2 definition for starting a Couchbase database node:

This definition can be started on a Docker Engine without Swarm mode as:

This will start a single replica of the service define in the Compose file. This service can be scaled as:

This would work fine on a single host. If swarm mode is enabled on on Docker Engine, then it shows the message:

Docker Compose gives us multi-container applications but the applications are still restricted to a single host. And that is a single point of failure. Docker Compose in Swarm mode allows to create a cluster of Docker Engines. With 1.13, docker stack deploy command can be used to deploy a Docker Compose file to Docker Swarm mode. Here is an example of Docker Compose v3 definition:

As you can see, the only change is the value of version attribute. There are other changes in Docker Compose v3. Also, read about different Docker Compose versions and how to upgrade from v2 to v3. Enable Docker Compose with swarm mode:

Other nodes can join this swarm cluster and this would easily allow to deploy the multi-container application to a multi-host as well. Use Docker to deploy the services in Swarm defined in Compose file as:

A default value of Compose file here would make the command a bit shorter. #30352 should take care of that. List of services running can be verified using docker service ls command:

The list of containers running within the service can be seen using docker service ps command:

In this case, a single container is running as part of the service. The node is listed as moby which is the default name of Docker Engine running using Docker for Mac. The service can now be scaled as:

The list of container can then be seen again as:

Note that the containers are given the name using the format _n. Both the containers are running on the same host. Also note, the two containers are independent Couchbase nodes and are not configured in a cluster yet. This has already been explained at Couchbase Cluster using Docker and a refresh of the steps is coming soon. A service will typically have multiple containers running spread across multiple hosts. Docker 1.13 introduces a new command docker service logs to stream the log of service across all the containers on all hosts to your console. In our case, this can be seen using the command docker service logs couchbase_db and looks like:

The preamble of the log statement uses the format .@. And then actual log message from your container shows up. At first instance, attaching container id may seem redundant. But Docker services are self-healing. This means that if a container dies then the Docker Engine will start another container to ensure the specified number of replicas at a given time. This new container will have a new id. And thus it allows  to attach the log message from the right container. So a quick comparison of commands:

Want to get started with Couchbase? Look at Couchbase Starter Kits. Want to learn more about running Couchbase in containers?

• Couchbase on Containers
• Couchbase Forums
• Couchbase Developer Portal
• @couchhasedev and @couchbase