diff --git a/_data/toc.yaml b/_data/toc.yaml index d7a0b0e64f..a4a380c19f 100644 --- a/_data/toc.yaml +++ b/_data/toc.yaml @@ -1124,8 +1124,6 @@ manuals: title: Release notes - path: /compose/gettingstarted/ title: Getting started - - path: /compose/swarm/ - title: Using Compose with Swarm - path: /compose/environment-variables/ title: Environment variables in Compose - path: /compose/env-file/ diff --git a/compose/index.md b/compose/index.md index d36e4231e9..30e967c028 100644 --- a/compose/index.md +++ b/compose/index.md @@ -4,6 +4,7 @@ keywords: documentation, docs, docker, compose, orchestration, containers title: Overview of Docker Compose redirect_from: - /compose/overview/ + - /compose/swarm/ --- >**Looking for Compose file reference?** [Find the latest version here](compose-file/index.md). diff --git a/compose/swarm.md b/compose/swarm.md deleted file mode 100644 index 56ecd3d0ec..0000000000 --- a/compose/swarm.md +++ /dev/null @@ -1,174 +0,0 @@ ---- -advisory: swarm-standalone -hide_from_sitemap: true -description: How to use Compose and Swarm together to deploy apps to multi-host clusters -keywords: documentation, docs, docker, compose, orchestration, containers, swarm -title: Use Compose with Swarm ---- - -Docker Compose and [Docker Swarm](../swarm/overview.md) aim to have full integration, meaning -you can point a Compose app at a Swarm cluster and have it all just work as if -you were using a single Docker host. - -The actual extent of integration depends on which version of the -[Compose file format](compose-file/compose-versioning.md) you are using: - -1. If you're using version 1 along with `links`, your app works, but Swarm - schedules all containers on one host, because links between containers - do not work across hosts with the old networking system. - -2. If you're using version 2, your app should work with no changes: - - - subject to the [limitations](swarm.md#limitations) described below, - - - as long as the Swarm cluster is configured to use the [overlay driver](../network/overlay.md), - or a custom driver which supports multi-host networking. - -Read [Get started with multi-host networking](../network/network-tutorial-overlay.md) to see how to -set up a Swarm cluster with [Docker Machine](../machine/overview.md) and the overlay driver. Once you've got it running, deploying your app to it should be as simple as: - - $ eval "$(docker-machine env --swarm )" - $ docker-compose up - -## Limitations - -### Building images - -Swarm can build an image from a Dockerfile just like a single-host Docker -instance can, but the resulting image only lives on a single node and won't -be distributed to other nodes. - -If you want to use Compose to scale the service in question to multiple nodes, -build the image, push it to a registry such as Docker Hub, and reference it -from `docker-compose.yml`: - - $ docker build -t myusername/web . - $ docker push myusername/web - - $ cat docker-compose.yml - web: - image: myusername/web - - $ docker-compose up -d - $ docker-compose scale web=3 - -### Multiple dependencies - -If a service has multiple dependencies of the type which force co-scheduling -(see [Automatic scheduling](#automatic-scheduling) below), it's possible that -Swarm schedules the dependencies on different nodes, making the dependent -service impossible to schedule. For example, here `foo` needs to be co-scheduled -with `bar` and `baz`: - - version: "2" - services: - foo: - image: foo - volumes_from: ["bar"] - network_mode: "service:baz" - bar: - image: bar - baz: - image: baz - -The problem is that Swarm might first schedule `bar` and `baz` on different -nodes (since they're not dependent on one another), making it impossible to -pick an appropriate node for `foo`. - -To work around this, use [manual scheduling](#manual-scheduling) to ensure that -all three services end up on the same node: - - version: "2" - services: - foo: - image: foo - volumes_from: ["bar"] - network_mode: "service:baz" - environment: - - "constraint:node==node-1" - bar: - image: bar - environment: - - "constraint:node==node-1" - baz: - image: baz - environment: - - "constraint:node==node-1" - -### Host ports and recreating containers - -If a service maps a port from the host, such as `80:8000`, then you may get an -error like this when running `docker-compose up` on it after the first time: - - docker: Error response from daemon: unable to find a node that satisfies - container==6ab2dfe36615ae786ef3fc35d641a260e3ea9663d6e69c5b70ce0ca6cb373c02. - -The usual cause of this error is that the container has a volume (defined either -in its image or in the Compose file) without an explicit mapping, and so in -order to preserve its data, Compose has directed Swarm to schedule the new -container on the same node as the old container. This results in a port clash. - -There are two viable workarounds for this problem: - -- Specify a named volume, and use a volume driver which is capable of mounting - the volume into the container regardless of what node it's scheduled on. - - Compose does not give Swarm any specific scheduling instructions if a - service uses only named volumes. - - version: "2" - - services: - web: - build: . - ports: - - "80:8000" - volumes: - - web-logs:/var/log/web - - volumes: - web-logs: - driver: custom-volume-driver - -- Remove the old container before creating the new one. You lose any data - in the volume. - - $ docker-compose stop web - $ docker-compose rm -f web - $ docker-compose up web - -## Scheduling containers - -### Automatic scheduling - -Some configuration options result in containers being automatically -scheduled on the same Swarm node to ensure that they work correctly. These are: - -- `network_mode: "service:..."` and `network_mode: "container:..."` (and - `net: "container:..."` in the version 1 file format). - -- `volumes_from` - -- `links` - -### Manual scheduling - -Swarm offers a rich set of scheduling and affinity hints, enabling you to -control where containers are located. They are specified via container -environment variables, so you can use Compose's `environment` option to set -them. - - # Schedule containers on a specific node - environment: - - "constraint:node==node-1" - - # Schedule containers on a node that has the 'storage' label set to 'ssd' - environment: - - "constraint:storage==ssd" - - # Schedule containers where the 'redis' image is already pulled - environment: - - "affinity:image==redis" - -For the full set of available filters and expressions, see the -[Swarm documentation](../swarm/scheduler/filter.md).