Docker-Composeを使用する場合とDocker-Swarmを使用する場合

Docker-ComposeとDocker-Swarmの違いや類似点を理解しようとしています。

ドキュメントを読むことで、docker-composeは、異なるコンテナーをバインドし、単一のサービスとして共同で動作するメカニズムを提供することを理解しました（2つのコンテナーをリンクするために使用される--linkコマンドと同じ機能を使用していると思います）

また、docker-swarmについての私の理解は、それぞれがいくつかのdocker-imagesの複数のコンテナーインスタンスを実行している異なるdocker-hostsのクラスターを管理できることです。接続を、スウォーム内の異なるコンテナー間のオーバーレイネットワークとして定義し（スウォーム内の2つのDockerホストにまたがる場合でも）、それらを1つのユニットとして接続できます。

私が理解しようとしているのは、docker-swarmがdocker-composeに成功し、オーバーレイネットワークがコンテナーを接続するための新しい（推奨される）方法であるということです。

それとも、docker-composeはまだdockerファミリー全体の不可欠な部分であり、それを使用してコンテナーを接続して共同作業を行うことが期待され、推奨されています。もしそうなら、docker-composeは群れの異なるノードにまたがるコンテナで動作しますか？

それとも、オーバーレイネットワークは群れの異なるホスト間でコンテナを接続するためのものであり、docker-composeは内部リンクを作成するためのものですか？

さらに、dockerのドキュメントに、-linksは推奨されなくなり、まもなく廃止されることが記載されていることもわかりました。

私は少し混乱していますか？

どうもありがとう！

おそらく、いくつかの定義から始めると役立つでしょう。

• docker-compose：関連するコンテナーのグループを構成および管理するために使用されるコマンド。これは、docker cliで使用されるのと同じAPIのフロントエンドであるため、のようなコマンドを使用してその動作を再現できますdocker run。
• docker-compose.yml：コンテナのグループの定義ファイル。docker-composeで使用され、現在はswarmモードでも使用されています。
• スウォームモード：Dockerエンジンのグループを単一のエンティティとして管理し、オーケストレーションを提供するために使用されます（現在の状態とターゲットの状態の違いを常に修正しようとします）。
• サービス：スウォーム内の同じイメージと構成の1つ以上のコンテナー、複数のコンテナーがスケーラビリティーを提供します。
• スタック：スウォーム内の1つ以上のサービス。これらは、DABまたはdocker-compose.ymlファイルを使用して定義できます。
• ブリッジネットワーク：複数のコンテナが相互に通信できる単一のDockerエンジンによって管理されるネットワーク。エンジンによって複数のネットワークが管理されている場合があり、コンテナは0個以上のネットワークに接続できます。
• オーバーレイネットワーク：ブリッジネットワークに似ていますが、複数のDockerエンジンにまたがっています。これらは、状態を維持するためにキー/値ストアを必要とします。スウォームモードはこれを提供しますが、スウォームモードが無効になっている場合は、etcd、consul、またはzookeeperを使用することもできます。
• リンク：ブリッジネットワークよりも前のコンテナを接続する方法。その使用は推奨されなくなりました。
• クラシックスウォーム：コンテナとして実行される統合スウォームモードの前身であり、複数のエンジンを1つとして表示できますが、オーケストレーションを提供したり、独自のk / vストアを含めたりすることはありません。

質問に答えるには：

docker-swarmはdocker-composeとoverlayネットワークに成功しましたか？コンテナを接続するための新しい（推奨される）方法ですか？

それとも、docker-composeはまだdockerファミリー全体の不可欠な部分であり、それを使用してコンテナーを接続して共同作業を行うことが期待され、推奨されています。もしそうなら、docker-composeは群れの異なるノードにまたがるコンテナで動作しますか？

それらは異なる機能を提供し、両方とも目的を果たし続けます。docker-composeはswarmモード内でコンテナーを開始できませんが、docker-compose.ymlファイルの新しいバージョン（バージョン3）を使用して、docker-compose自体を使用せずにswarmモードで直接スタックを定義できます。docker-composeは、単一のdockerエンジンで、または従来のswarmを使用して、swarmモード以外のコンテナーを管理するために必要です。

それとも、オーバーレイネットワークは群れの異なるホスト間でコンテナを接続するためのものであり、docker-composeは内部リンクを作成するためのものですか？

さらに、dockerのドキュメントに、-linksは推奨されなくなり、まもなく廃止されることが記載されていることもわかりました。

docker-composeはバージョン2以降のymlファイルで、デフォルトで複数のコンテナーをプロジェクトごとに新しいブリッジネットワークに接続します（プロジェクトのデフォルトはディレクトリ名です）。従来の群れでは、デフォルトで外部k / vストアを使用するオーバーレイネットワークになります。そして、スウォームモードスタックでは、これはオーバーレイネットワークになります。

Dockerネットワークを使用することは、コンテナーを相互に通信させるための推奨される方法です。Docker環境の残りの部分から分離したいコンテナーのグループごとにネットワークが必要です。docker-composeはこのネットワークの作成を自動化しますが、コマンドラインからdocker networks create。を使用して行うこともできます。

リンクは、DNS検出機能が組み込まれたDockerネットワークに大幅に置き換えられました。docker-compose.ymlからリンクを削除する場合、depends_onコンテナーの起動順序を強制するために、リンクをセクションに置き換える必要がある場合があります。そうでなければ、リンクが理にかなっているシナリオはほとんどなく、私が見たすべての使用法は、古いドキュメントをフォローしている誰かからのものです。

オーバーレイネットワークを構成または群がるまたは群がる

ラップトップなどでデモ以外のことをしている場合は、上記のすべてを使用する必要があることがわかります。

両方を使用する必要がないため、意図的にスウォームとスウォームオーバーレイネットワークを分離しましたが、その下にスウォームがないとオーバーレイネットワークを取得できません。

作成は、複数のコンテナをまとめるためのものです。今では、そうではないかもしれませんが、それらが互いに関連していることは理にかなっています。ただし、コンテナが相互に関連するサービス用である場合の典型的なケースを想定してみましょう。コンテナが何らかの方法で相互に通信するようにし、ネットワークを使用して相互に通信する方法を制御する必要があります。たとえば、ウェブサーバー、アプリサーバー、データベースを備えた3層アプリを考えてみましょう。3つのコンポーネントすべてがドッキングされており、実行する代わりに、composeを使用してそれらをまとめて起動しているとします。docker run..異なるパラメータなどで3回。3つすべてが表示されますが、相互の接続方法を制御する必要があります。Webサーバーがappserverと通信できるようにしますが、dbとは直接通信できないようにします。また、appserverがdbサーバーコンテナーと通信（ping）し、Webサーバーにもpingを実行するようにします。すべての接続は双方向ですが、相互に通信できるようにしたいサービスのみに制限されています。このような配置の場合、通常は2つのネットワーク（sayfrontendとbackend。）をセットアップします。Webコンテナとアプリコンテナはフロントエンドネットワークに接続されています。アプリとデータベースのコンテナはバックエンドネットワークに接続されています。dbコンテナとwebコンテナの間に共通のネットワークがないため、それらは互いに接触（ping）できません。これがあなたの意図です。

ここで、これら3つのサービスを数百台のマシンのクラスターで実行できるようにし、それら全体に拡張する場合は、複数のホストにまたがるネットワークが必要になります。そこで、（群れの）オーバーレイネットワークが登場します。オーバーレイネットワークは、VxLANテクノロジー上に構築されたマルチホストネットワークに他なりません。VxLANについて知る必要はありませんが、VxLANは、ほとんどすべての最新のネットワークインフラストラクチャでサポートされている標準のネットワークトポロジです。

それが明らかになることを願っています。

編集：私はあなたがすでに答えを得ているのを見ませんでした！

それぞれが何であるかについてはほとんどの理解が正しいと思いますが、多少の調整が必要です。

あなたは正しいdocker-composeは、マルチコンテナアプリケーションを起動することです。以前はdocker run ..、すべてのコンテナを起動するために行っていました。通常、マイクロサービスパラダイムを採用している最新のアプリケーションは、数十のサービスで構成されている可能性があり、使用docker run ..はすぐに非常に面倒になります。したがって、docker-composeを使用すると、すべてのコンテナーとそのプロパティ、およびそれらが相互に接続する方法をyamlまたはjsonファイルとして表現できるため、より簡単に管理できます。

つまり、docker-composeは、dockerエコシステムのコンテナーオーケストレーション部分です。

リンクは、彼らがドッキングウィンドウ・コンかのほんの一部である、異なるdocker runコマンドとの賛成で廃止されsoftware defined networksたのoverlay networksちょうどそれらの一つです。

Swarmは、dockerのスケジューリングコンポーネントです。スケジューリングとは-Dockerホストのクラスター内のどこにコンテナーを「配置」するかを理解することに他なりません。数百のサーバーのクラスターを作成することも、数百のコンテナーを作成して、それぞれが12の異なるアプリケーションのサービスをカプセル化することもできます。ここで、これらのコンテナーを数百台のサーバーのクラスター全体にどのように分散させる必要がありますか、特定の基準を満たすために特定のホストにのみ配置する必要があるか、何らかの形で関連する他のコンテナーに近い（またはしない）必要があります...これらはすべて、dockerSwarmによって実行されるスケジューリングコンポーネントの一部です。

ここでdocker.comの入門ドキュメントを確認することをお勧めします：https：//docs.docker.com/engine/getstarted-voting-app/