Merge pull request #11491 from thaJeztah/compose_swarm

Remove old "Using Compose with Swarm" page

_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/

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).

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).