Docker-Composeを使用する場合とDocker-Swarmを使用する場合
D-ComposeとD-Swarmの違いまたは類似点を理解しようとしています。
ドキュメントを読むことで、docker-composeは異なるコンテナを一緒にバインドし、単一のサービスとしてコラボレーションで動作するメカニズムを提供することを理解しました（と同じ機能を使用していると推測しています--link 2つのコンテナをリンクするために使用されるコマンド）
また、docker-swarmについての私の理解では、異なるdocker-hostsのクラスターを管理でき、それぞれがいくつかのdocker-imagesの複数のコンテナーインスタンスを実行しています。スウォーム内の異なるコンテナ間の接続をoverlay-networksとして定義し（スウォーム内の2つのドッカーホストにまたがっていても）、ユニットとして接続できます。
私が理解しようとしているのは、docker-swarmがdocker-composeに成功し、オーバーレイネットワークがコンテナを接続する新しい（推奨）方法であるということですか？
または、docker-composeは、まだdockerファミリ全体の不可欠な部分であり、コンテナを接続してコラボレーションで動作させるために使用することが期待され、推奨されています。その場合、docker-composeはswarmの異なるノードのコンテナで動作しますか？
それとも、オーバーレイネットワークはswarm内の異なるホスト間でコンテナを接続するためのものであり、docker-composeは内部リンクを作成するためのものですか？
また、ドッカーのドキュメントで-linksは推奨されておらず、まもなく廃止されることが記載されていることもわかります。
私は少し混乱しています???
どうもありがとう！
いくつかの定義から始めるとおそらく役立つでしょう：
- docker-compose：関連するコンテナのグループを設定および管理するために使用されるコマンド。これは、Docker CLIで使用されるのと同じAPIのフロントエンドです。したがって、
docker runなどのコマンドを使用して、その動作を再現できます。 - docker-compose.yml：コンテナのグループの定義ファイル。docker-composeで使用され、現在ではswarmモードでも使用されます。
- swarmモード：Dockerエンジンのグループを単一のエンティティとして管理し、オーケストレーションを提供するために使用されます（現在の状態とターゲット状態の違いを常に修正しようとしています）。
- service：swarm内の同じイメージと設定用の1つ以上のコンテナ、複数のコンテナはスケーラビリティを提供します。
- stack：swarm内の1つ以上のサービス。これらはDABまたはdocker-compose.ymlファイルを使用して定義できます。
- ブリッジネットワーク：複数のコンテナが互いに通信できる単一のドッカーエンジンによって管理されるネットワーク。エンジンによって管理される複数のネットワークがあり、コンテナはゼロ個以上のネットワークに接続できます。
- オーバーレイネットワーク：ブリッジネットワークに似ていますが、複数のドッカーエンジンにまたがっています。これらの状態を維持するには、キー/値ストアが必要です。 Swarmモードはこれを提供しますが、swarmモードが無効になっている場合は、etcd、consul、またはzookeeperも使用できます。
- links：ブリッジネットワークより前のコンテナを接続する方法。その使用は推奨されなくなりました。
- classic swarm：コンテナとして実行される統合スウォームモードの前身で、複数のエンジンを1つとして表示できますが、オーケストレーションを提供したり、独自のk/vストアを含めたりしません。
質問に答えるには：
docker-swarmはdocker-composeに成功し、オーバーレイネットワークはコンテナを接続する新しい（推奨）方法ですか？
または、docker-composeは、まだdockerファミリ全体の不可欠な部分であり、コンテナを接続してコラボレーションで動作させるために使用することが期待され、推奨されています。その場合、docker-composeはswarmの異なるノードのコンテナで動作しますか？
それらは異なる機能を提供し、両方とも目的を果たし続けます。 docker-composeはswarmモード内でコンテナを起動できませんが、docker-compose自体を使用せずに、新しいバージョンのdocker-compose.ymlファイル（バージョン3）を使用して直接swarmモードでスタックを定義できます。 docker-composeは、単一のdockerエンジン上で、または従来のswarmを使用して、swarmモード以外のコンテナーを管理するために必要です。
それとも、オーバーレイネットワークはswarm内の異なるホスト間でコンテナを接続するためのものであり、docker-composeは内部リンクを作成するためのものですか？
それに加えて、ドッカーのドキュメントで--linksはもう推奨されておらず、まもなく廃止されることが記載されていることもわかります。
ymlファイルのバージョン2以降のdocker-composeは、デフォルトでプロジェクトごとに新しいブリッジネットワークで複数のコンテナを接続します（プロジェクトはデフォルトでディレクトリ名になります）。従来のswarmでは、デフォルトで外部k/vストアを使用するオーバーレイネットワークになります。そして、スウォームモードスタックでは、これはオーバーレイネットワークになります。
コンテナを相互に通信させるには、Dockerネットワークを使用することをお勧めします。コンテナのグループごとにネットワークを作成し、他のドッカー環境から隔離します。 docker-composeはこのネットワーク作成を自動化しますが、docker networks createを使用してコマンドラインから作成することもできます。
リンクの大部分は、組み込みのDNSディスカバリーを備えたdockerネットワークに置き換えられました。 docker-compose.ymlからリンクを削除する場合、コンテナの起動順序を強制するために、それらをdepends_onセクションに置き換える必要がある場合があります。それ以外の場合、リンクが意味をなすシナリオはほとんどなく、私が見たすべての使用法は、古くなったドキュメントをフォローしている人からのものです。
オーバーレイネットワークを作成、スウォーム、またはスウォームします
ラップトップなどでデモ以外を行う場合は、上記のすべてを使用する必要があることがわかります。
SwarmとSwarm Overlay Networkを意図的に分離しました。両方を使用する必要はありませんが、その下にSwarmがなければオーバーレイネットワークを取得することはできません。
Composeは、複数のコンテナをまとめて表示するためのものです。今では、それらは相互に関連していることが理にかなっていますが、そうではないかもしれません。しかし、コンテナが相互に関連するサービス用である典型的なケースを想定してみましょう。コンテナは何らかの方法で相互に通信したいが、ネットワークを使用して相互に通信する方法を制御します。たとえば、webserver、appserver、dbのある3層アプリを取り上げます。 3つのコンポーネントすべてがドッキングされており、異なるパラメーターなどでdocker run..を3回実行する代わりに、composeを使用してそれらをまとめて表示するとします。 。 Webサーバーがappserverと通信できるようにしたいが、dbとは直接通信できないようにします。また、appserverがdbサーバーコンテナーと通信（ping）し、Webサーバーもpingする必要があります。すべての接続は双方向ですが、相互に通信できるようにしたいサービスのみに制限されます。このような配置の場合、通常、2つのネットワーク（たとえば、frontendとbackend）をセットアップします。 Webおよびアプリコンテナーは、フロントエンドネットワークに接続されます。アプリとdbコンテナはバックエンドネットワークに接続されます。 dbコンテナとWebコンテナの間には共通のネットワークがないため、お互いに接触（ping）することはできません。これが目的です。
ここで、これらの3つのサービスを数百台のマシンのクラスターで実行できるようにしたい場合、およびそれらをまたがってスケールしたい場合は、複数のホストにまたがるネットワークが必要になります。これが、オーバーレイネットワーキング（スウォーム内）の出番です。オーバーレイネットワーキングは、VxLANテクノロジー上に構築されたマルチホストネットワーキングに他なりません。 VxLANについて知る必要はありません。ただし、VxLANは、ほとんどすべての最新のネットワークインフラストラクチャでサポートされている標準のネットワークトポロジです。
それが明らかになることを願っています。
編集：あなたはすでに答えを得たことを見ませんでした！
私はあなたがそれぞれが何であるかについて正しい理解の大部分を持っていると思いますが、いくらかの微調整が必要です。
正しいdocker-composeは、マルチコンテナアプリケーションを起動することです。以前は、docker run ..を使用してすべてのコンテナを開始していました。通常、マイクロサービスパラダイムを採用する最新のアプリケーションは、多数のサービスで構成され、docker run ..を使用することはすぐに面倒になります。したがって、docker-composeを使用すると、すべてのコンテナとそのプロパティ、およびそれらの接続方法をyamlまたはjsonファイルとして表現できるため、より簡単に管理できます。
したがって、docker-composeは、Dockerエコシステムのコンテナオーケストレーションパーツです。
リンクは異なります。リンクはdocker-composeまたはdocker runコマンドの一部であり、software defined networksの代わりに廃止され、overlay networksはそのうちの1つにすぎません。
Swarmは、Dockerのスケジューリングコンポーネントです。スケジューリングとは-コンテナをdockerホストのクラスター内のどこに「配置」するかを把握することです。数百のサーバーのクラスターを持つことができ、数百のコンテナーがあり、それぞれが数十の異なるアプリケーションのサービスをカプセル化します。これらのコンテナを何百ものサーバーのクラスタにどのように分散させるべきか、特定の基準を満たすために特定のホストにのみいくつかのコンテナを配置するか、何らかの形で関連する他のコンテナに近づける（または近づけない）必要があります...これらはすべて、Docker Swarmによって実行されるスケジューリングコンポーネントの一部です。
ここでdocker.comの入門ドキュメントをご覧になることをお勧めします。 https://docs.docker.com/engine/getstarted-voting-app/