Swarm モードの重要な概念¶

このトピックでは、Docker Engine 1.12 の独特の概念であるクラスタ管理とオーケストレーション機能を紹介します。

Swarm ¶

クラスタ管理とオーケストレーション機能は、 SwarmKit を使って Docker Engine に組み込まれた（内蔵された）ものです。Engine がクラスタに参加するには、 swarm モード（swarm mode） で動作します。swarm の初期化だけでなく、既存の swarm に追加する時も、Engine を swarm モードにします。

Swarm は Docker Engine のクラスタであり、サービス群をデプロイする場所です。Docker Engine CLI には、ノードの追加や削除などの swarm 管理コマンドを含みます。また、 CLI にはサービスを swarm にデプロイするために必要なコマンドや、サービス・オーケストレーションの管理のためのコマンドも含みます。

Docker Engine を swarm モード以外で実行時は、コンテナに対するコマンドを処理します。Engine を swarm モードで実行時は、サービスをオーケストレートします。

ノード ¶

ノード（node） とは、Swarm 内に参加する Docker Engine インスタンスです。

アプリケーションを swarm にデプロイするには、 マネージャ・ノード（manager node） にサービス定義を送信します。マネージャ・ノードはワーカー・ノードへタスクと呼ばれる単位を送ります（ディスパッチします）。

また、マネージャ・ノードは swarm の期待状態（desired state）を維持するために、オーケストレーションと管理機能を処理します。マネージャ・ノードはオーケストレーション・タスクを処理するため、単一のリーダーを選出（elect）します。

ワーカ・ノード（worker nodes） はマネージャ・ノードから送られてきたタスクの受信と処理をします。デフォルトでは、マネージャ・ノードはワーカー・ノードも兼ねますが、マネージャのみのノード（manager-only node）としてもマネージャを設定可能です。エージェントは割り当てられたタスクの現在の状況をマネージャ・ノードに伝えるため、マネージャは期待状態を維持できます。

サービスとタスク ¶

サービス（service） とは、アプリケーションを作り上げるための様々なタスクを、どのように実行するかという定義です。たとえば、Swarm 内で Redis イメージをデプロイするサービスを作成します。

サービスの作成時に指定するのは、どのコンテナ・イメージを使い、コンテナ内でどのようなコマンドを実行するかです。

複製サービス（replicated services） モデルとは、期待状態の指定に基づき、swarm マネージャがノード間に複製タスク（replica task）を指定した数だけ分散します。

グローバル・サービス（global services） とは、特定のタスクをクラスタ内の全ノード上で利用可能になるように swarm が実行します。

タスク（task） とは Docker コンテナを運び、コンテナ内でコマンドを実行します。これは Swarm における最小スケジューリング単位です。マネージャ・ノードはワーカ・ノードに対してタスクを割り当てます。割り当てる数はサービスのスケールで設定されたレプリカ数に応じます。タスクがノードに割り当てられれば、他のノードに移動できません。移動できるのはノードに割り当て時か落ちた時だけです。

ロード・バランシング（負荷分散）¶

Swarm の外部で使いたいサービスを公開するため、swarm マネージャは イングレス・ロード・バランシング（ingress load balancing） （訳者注：入ってくるトラフィックに対する負荷分散機構）を使います。Swarm はサービスに対して自動的に PublishedPort （公開用ポート） を割り当てられます。あるいは、自分でサービス用の PublishedPort を 30000 ～ 32767 の範囲で設定可能です。

クラウドのロードバランサのような外部コンポーネントは、クラスタ上のあらゆるノード上の PublishedPort にアクセスできます。たとえ、対象のノード上でサービス用のタスクが（その時点で）動作していなくてもです。swarm クラスタ上にある全てのノードが、タスクを実行しているインスタンスに接続する経路なのです。

Swarm には内部 DNS コンポーネントがあります。これは各サービスを自動的に Swarm DNS エントリに割り当てます。swarm マネージャは 内部ロード・バランシング（internal load balancing） を使い、クラスタ内におけるサービスの DNS 名に基づき、サービス間でリクエストを分散します。