Swarm モードの重要な概念

目次

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

Swarm とは何でしょうか？

クラスタ管理とオーケストレーション機能は、 SwarmKit を使って Docker Engine に組み込まれた（内蔵された）ものです。Swarmkit は Docker のオーケストレーション層を実装する独立したプロジェクトであり、Docker 内で直接使われます。

swarm モード で動作する複数の Docker ホストにより、 swarm （訳者注：ノードによって構成されるクラスタを意味する「群れ」の表現）を構成し、manager （メンバーと委任の管理）の役割と worker （ swarm サービス を実行する）の役割があります。Docker ホストには、manager か、 worker か、あるいは両方の役割を与えられます。サービスを作成するとき、最適の状態（optimal state）を定義します（レプリカ数、サービスが利用できるネットワークとストレージのリソース、世界に公開するサービス用ポート、など）。Docker はこの desired state（期待状態）を維持するよう動作します。たとえば、worker ノードが利用不可能になれば、Docker はノードのタスクを他のノード上にスケジュールします。タスク（ task ）とは swarm サービスの一部として実行中のコンテナであり、スタンドアロン・コンテナとは異なり swarm manager によって管理されます。

スタンドアロン・コンテナと比べた swarm サービスの重要な強みの1つは、サービスの設定を変更可能な点です。サービスだけでなく、サービスに接続するネットワークとボリュームも含みます。そして、手動でサービスを再起動する必要はありません。Docker は設定を更新すると、期待する設定に一致するように、無効となったサービス・タスクを停止し、新しいサービス・タスクを作成します。

Docker を swarm モードで動かすと、swarm （クラスタの意味）に参加している Docker ホスト上では、swarm サービス同様に、スタンドアロン・コンテナも実行できます。スタンドアロン・コンテナと swarm サービスとの重要な違いとは、swarm manager だけが swarm を管理可能であり、スタンドアロン・コンテナはデーモンだけが起動できます。Docker デーモンは swarm に対して manager か worker か、あるいは両方の役割で参加できます。

Docker Compose を使ってコンテナの定義と実行ができるのと同じ方法で、 Swarm service スタックの定義・実行が行えます。

Docker swarm サービスに関連する概念の詳細に含まれるノード、サービス、タスク、負荷分散についての詳細は、このまま読み進めてください。

ノード（nodes）

ノード（node） とは、swarm （クラスタ）に参加している Docker Engine のことです。これを Docker ノードと考えることもできます。1つまたは複数のノードを1つの物理コンピュータ上、あるいは、クラウドサーバ上で実行できます。とはいえ、プロダクションで展開する swarm に典型的に含む Docker ノードは、複数の物理またはクラウドマシン上にわたります。

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

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

worker ノード（worker nodes） は、 manager ノードから送られてきたタスクの受信と実行をします。デフォルトでは、 manager ノードは worker ノードも兼ねますが、manager 機能のみを持つノード（manager-only node）としても設定できます。各 worker ノード上で動作するエージェントは、ノードに割り当てられたタスクを manager ノードに通知します。 worker ノードは、自身に割り当てられているタスクに対する、現在の状態を manager ノードに対して通知しますので、manager が各 worker に対する期待状態を維持できます。

サービスとタスク

サービス（service） とは、 manager ノードや worker ノード上で実行するタスクについての定義です。これは swarm システムにおける中心となる構造であり、ユーザが swarm と相互にやりとりする主要なものです。

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

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

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

タスク（task） は Docker コンテナを運ぶもので、そのコンテナ内でコマンドを実行します。これは Swarm における最小スケジューリング単位です。manager ノードは worker ノードに対して、サービスのスケール（訳者注：service scale サブコマンドなどで指定）を設定したレプリカ数に応じて、タスクを割り当てます。タスクがノードに割り当てられれば、他のノードに移動できません。タスクが移動できるのは、ノードへの割り当て時か障害発生時のみです。

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

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

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

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