Docker swarmでcomposeを使用します.

上記では、単独のDocker環境でのcomposeの使い方を紹介します.ここではswarmクラスタでcomposeを使う方法を紹介します.
制限
イメージ構築
swarmでイメージを構築するには、単機版と同じ命令を使用します.しかし、構築されたイメージは現在のホストのみに存在し、ミラー像を実行する複数の例がクラスタ内の異なるノードに分布している場合、構築されたミラー像を配信する必要があり、ノードは他のノードで構築されたミラー像を共有しない.解決策は、まずあるノードでイメージを構築し、イメージをイメージ倉庫にアップロードし、composeの定義ファイルでこのイメージを倉庫から引用する.救命は以下の通りです

$ 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

多依存
いくつかのアプリケーションが複数のサービスから構成されている場合、以下のような例があります.

version: "2"
services:
  foo:
    image: foo
    volumes_from: ["bar"]
    network_mode: "service:baz"
  bar:
    image: bar
  baz:
    image: baz

上記の例では、fooのvolumeはbarに依存しており、fooのネットワークはbazと共有しています.この例の3つのサービスは同じノードに展開しなければなりません.つまり、fooはbarとbazに明確に依存しています.配置時の実際のスケジュールにおいて、まずfooを配置すると、システムはbarとbazに依存していることが分かり、その後、システムは同じノードにbarとbazを配置し、その後fooを配置する.しかし、実際には、swarmはこのようにスケジュールされていません.barとbazを同時に配置する可能性があります.この二つのサービスは誰に依存しているかを指摘していません.したがって、クラスタ内の任意のノードに配置され、異なるノードに配置される可能性があります.解決策の一つは、手動で配置に制約を加えることである.

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"

以上の強制は、すべての3つのサービスをノードnode-1に配置する必要があります.この方式は実際にはあまり柔軟ではないです.強制的にノード名を指定しました.一つの方法は、ラベルを通してターゲットノードにラベルを付けてから、ラベル名を指定することです.これはセレクタが必要です.k 8 sはこのようにしています.composeにもこのような機能があるかもしれません.
ホストポートとコンテナの再構築 (Host ports and recreating containers)
この部分は本当に意味がよく分かりません.後でvolumeがportします.何が原因で衝突したのか分かりません.原文は以下の通りです
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 einther in in in it)without an explicit mapping,and so in order to preserve its data,Compashas dicted Swarm the condule.
下の二つの方法は見て分かります.一つは名前をvolumeといいます.コードは以下の通りです.

version: "2"

services:
  web:
    build: .
    ports:
      - "80:8000"
    volumes:
      - web-logs:/var/log/web

volumes:
  web-logs:
    driver: custom-volume-driver

上記の例では、volumeは名前を持っています.また、あるストレージシステムが単独で提供しています.シンクホストに依存しないで、コンテナインスタンスがそこに配置されています.疑問の一つは、複数のインスタンスの多volumeの問題です.もし5つのインスタンスを実行し、その後10つのインスタンスに調整したら、このvolumeはどのように結合されますか?
第二の方法は前回の運行によって発生したレガシーを徹底的に除去し、衝突を避けることです.

$ docker-compose stop web
$ docker-compose rm -f web
$ docker-compose up web

 オートスケジュールは上の例ですでに発生しています.composeでのサービスの配置はスケジュールに影響する可能性があります.

network_mode: "service:..." and  network_mode: "container:..." (and net: "container:..." in the version 1 file format).

volumes_from

links

手動スケジューリング

# 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"

具体的には配置時の制約、親和性、親和性などです.