mirror of https://github.com/docker/docs.git
Merge pull request #11491 from thaJeztah/compose_swarm
Remove old "Using Compose with Swarm" page
This commit is contained in:
Usha Mandya
GitHub
commit
3cdfb582e7
|
|
@ -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/
|
||||
|
|
|
|||
|
|
@ -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).
|
||||
|
|
|
|||
174
compose/swarm.md
174
compose/swarm.md
|
|
@ -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 <name of swarm master machine>)"
|
||||
$ 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).
|
||||
Loading…
Reference in New Issue