Docker Swarmは死んだ。Docker Swarm万歳。

Docker社は、先週のDockerConで中核製品であるDocker Engineのバージョン1.12をリリースした。最大の新機能は、Docker Swarmがもはや別個のツールではないことである。Docker Swarmは、Docker Engineに組み込まれるようになり、スケールと信頼性を向上するために複数のDockerホストを単一の論理単位にまとめるのが、より簡単になった。Docker CaptainであるAdrian Mouat氏は、新しいswarmモードによって、Dockerが「オーケストレーション領域での手ごわい競合」になると信じている。

Docker Engineに統合されたDocker Swarmは大きな利点だが、これは追加機能であり、使いたい場合にのみ使うものである。以前のバージョンと全く同じ方法でDocker 1.12をインストール、実行、アップグレードでき、Docker 1.12は既存のコンテナ イメージやツールと後方互換性を持っている。

単一ホストでのDockerの実行と、Docker Composeによるコンテナのオーケストレーションは、従来通り動作する。Docker Engine 1.12を既存のDocker Swarmとともに使うことすらできる。新しいDocker Engineを使って明示的にSwarmを作成しない限り、ランタイムの挙動は以前のリリースと同じである。

当初のDocker Swarmはキット形態で提供されており、一連の中核機能が組み込まれていなかった。Docker Swarmランタイム自体は各ノード上でコンテナとして動作し、検出のためのConsulやetcd、負荷分散のためのnginxといった複数の追加テクノロジが必要だった。Swarmでは、自分のアプリコンテナと一緒に混在するインフラコンテナを実行することになる。

「古い」Swarmの設定も簡単ではなかった。なぜなら、Swarmの作成前に検出コンポーネントが動作していなければならないが、Swarmの一部として検出コンポーネントを動作させたいので、他の何かをする前に解決すべき卵が先か鶏が先かという問題があったからである (Jacob Blain Christen氏の記事「Consulによる本番環境向けのDocker Swarmクラスターに向けて」が、これを詳しく説明している)。

swarmモードでは、"init"コマンドでSwarmを作成し、"join"コマンドでクラスタにワーカーを追加する。Swarmを作成して参加するコマンドは、文字通り1、2秒で完了する。Mouat氏は、「KubernetesやMesosのクラスタを実行するのに比べて、Docker Swarmは簡単だ」と述べた。

Swarmのノード間の通信は、全てTransport Layer Security (TLS) で保護されている。Docker 1.12は、単純な設定として、Swarmの作成時に、使用する自己署名証明書を生成する。あるいは、自分の認証局 (CA) からの証明書を提供することもできる。この証明書は、ノードによって内部使用されるだけである。パブリックに公開するサービスは、従来通り自分の証明書を使う。

DockerConで、Nigel Poulton氏は、以前のバージョン、および、1.12でのSwarmのセキュリティの次のような比較を共有した。

Docker社は全てのSwarmノードを同じL3サブネット内で動作させることを推奨しているが、環境によっては、パブリック向けのコンテナを実行するノードが内部ノードから隔離されるように、ノードを分割できる。

この隔離は、Microsoftのクラウドについてのポスト「Azureでの本番環境のDocker Swarm」で私が書いた、スタンドアロンのSwarm製品で採るのと同じアプローチである。

Swarmの自己認識能力は、最大かつ最も重要な変更点である。Swarm上の各ノードは他の各ノードと通信でき、トラフィックを向ける必要がある場所にトラフィックをルーティングできる。もはや、nginxやInterlockといったツールを使って、独自のロードバランサを実行し、ロードバランサを動的検出エージェントと統合する必要はない。

あるノードがリクエストを受信し、そのノードがそのリクエストを処理できるコンテナのインスタンスを実行していないために、そのリクエストに対応できない場合、そのノードは、そのリクエストを処理できるノードにそのリクエストをルーティングするようになった。これはコンシューマにとって透過的であり、コンシューマが見るのは自分のリクエストに対するレスポンスだけである。コンシューマは、Swarm内部で発生したリダイレクトについては分からない。

Dockerがルーティングメッシュと呼んでいるこの機能は、外部負荷分散をサポートしている。Swarmの前面にパブリック向けのロードバランサを配置し、そのロードバランサを全サービスの単一のエントリポイントとして構成する。パブリックのロードバランサは、入力トラフィックをSwarmノード間にやみくもに分散し、リクエストを受信したノードは、そのノードが処理できないトラフィックをインテリジェントに再分散する。Dockerコアエンジニアリングチームは、ルーティングメッシュはLinuxの中核機能、つまり「15年以上Linuxカーネルで使われているロードバランサ」を使っていると説明している。

ルーティングメッシュとスケジューラの組み合わせによって、障害が発生したノードによってサービス障害が引き起こされないことが保証される。あるノードがダウンした場合、ロードバランサはそのノードにトラフィックを送信しなくなる。ノードの喪失によってあるサービスのレプリカ数がが必要数より少なくなった場合、スケジューラが他のノードで新しいレプリカを起動する。

Docker Swarmは依然としてネイティブDockerクラスタの名前だが、バージョン1.12のswarmモードは、スタンドアロン製品ではなくDocker Engineの不可欠な要素である。検出機能が提供され、信頼性のための複数のマネージャと必要なだけ多くのワーカーで、Swarmをスケールできる。

この最初のリリースでは、Docker Engineは他のDocker製品の先を行っている。Docker Machineで新しいスタイルのSwarmを作成できず、Docker Composeを使ってサービスをデプロイできない。しかし、Dockerコミュニティは早く作業しているので、こういった統合が近いうちに提供されることが期待されている。