Docker Swarmモード実践ガイド：CentOSクラスタへのFedoraワーカーノード追加手順

数週間前、CentOS 7.2をベースに、Docker 1.12に組み込まれたネイティブなクラスタリングおよびオーケストレーション機能(Swarmモード)の初期化と起動方法をご紹介しました。しかし当時はマネージャノードのみで、ワーカーノードはまだ存在していませんでした。今回はその続きとして、クラスタをさらに拡張していきます。

本記事では、異種混在(非対称)ノードをSwarmに参加させる方法を解説します。具体的には、既存のCentOSマシンに加えてFedora 24をワーカーとして追加し、両者が同じクラスタに参加して、ロードバランシングをはじめとする各種機能を活用できるようにします。もちろん一筋縄ではいかず、いくつかの落とし穴にも遭遇するため、非常に興味深い内容になるはずです。それでは始めましょう。

前提条件

新しいノードをSwarmに正常に参加させる前に、いくつか準備しておくべき事項があります。まず、すべてのノードで同じバージョンのDockerを実行しているのが理想的です。ネイティブオーケストレーションを利用するには、少なくともバージョン1.12以上が必要です。CentOSと同様、Fedoraも標準リポジトリには最新版が用意されていないため、手動またはDocker公式リポジトリを追加して適切なバージョンをインストールし、依存関係の競合を解消する必要があります。CentOSでの手順は以前ご紹介した通りで、Fedoraでも作業内容は基本的に同じです。

さらに、すべてのノードが相互に通信できる必要があります。マネージャとワーカーが互いにやり取りできるよう、ルーティングとファイアウォールのルールを適切に設定しておかなければなりません。さもないと、ノードをSwarmに参加させることができません。問題を切り分ける最も手軽な方法は、一時的にファイアウォールのルールをクリアすること(iptables -F)ですが、これはセキュリティを損なう可能性があります。自分が何をしているのかを十分に理解した上で、ノードとポートに応じた正しいルールを作成するようにしてください。

Error response from daemon: Timeout was reached before node was joined. The attempt to join the swarm will continue in the background. Use the "docker info" command to see the current swarm status of your node.

また、ホスト間で同じDockerイメージが利用可能であることも重要です。前回のチュートリアルではApacheイメージを作成しましたが、ワーカーノード側でも同じイメージを作成するか、作成済みのイメージを配布する必要があります。これを怠るとエラーが発生します。Dockerのセットアップについてサポートが必要な場合は、入門ガイドやネットワーキングのチュートリアルを参照してください。

7vwdxioopmmfp3amlm0ulimcu \_ websky.11 my-apache2:latest
localhost.localdomain Shutdown Rejected 7 minutes ago
"No such image: my-apache2:lat&"

それでは始めよう

CentOSマシンはすでに稼働しており、コンテナを正常に起動できています。ホストのポート経由でサービスに接続でき、すべてが順調に見えることでしょう。ただし現時点では、Swarmにはマネージャノードしか存在していません。

ワーカーノードの参加

新しいノードを追加するには、joinコマンドを使用します。ただしその前に、ワーカーノードがSwarmマネージャに対して正しく認証できるよう、必要なトークン・IPアドレス・ポートの情報を確認しておく必要があります。まずマネージャ側で以下のコマンドを実行し、表示されたコマンドをFedora側で実行します。

[root@localhost ~]# docker swarm join-token worker
To add a worker to this swarm, run the following command:

docker swarm join \
--token SWMTKN-1-0xvojvlza90nrbihu6gfu3qm34ari7lwnza ... \
192.168.2.100:2377

ファイアウォールやルーティングの設定を修正していないと、タイムアウトエラーが発生します。また、すでにSwarmに参加済みのノードでjoinコマンドを再実行すると、次のようなメッセージが表示されます。

Error response from daemon: This node is already part of a swarm. Use "docker swarm leave" to leave this swarm and join another one.

迷ったときは、いったんSwarmから離脱してから再試行しましょう。

[root@localhost ~]# docker swarm leave
Node left the swarm.

docker swarm join --token SWMTKN-1-0xvojvlza90nrbihu6gfu3qnza4 ... 192.168.2.100:2377
This node joined a swarm as a worker.

ワーカーノード側では、docker infoコマンドでステータスを確認できます。

Swarm: active
NodeID: 2i27v3ce9qs2aq33nofaon20k
Is Manager: false
Node Address: 192.168.2.103

同様に、マネージャ側では次のような情報が表示されます。

Swarm: active
NodeID: cneayene32jsb0t2inwfg5t5q
Is Manager: true
ClusterID: 8degfhtsi7xxucvi6dxvlx1n4
Managers: 1
Nodes: 3
Orchestration:
Task History Retention Limit: 5
Raft:
Snapshot Interval: 10000
Heartbeat Tick: 1
Election Tick: 3
Dispatcher:
Heartbeat Period: 5 seconds
CA Configuration:
Expiry Duration: 3 months
Node Address: 192.168.2.100

サービスの作成とスケーリング

次に、Dockerがコンテナを各ノードへどのように分散させるのかを確認してみましょう。筆者のテストでは、軽負荷の状態ではかなり単純なバランシングアルゴリズムが使われる傾向があることがわかりました。一度か二度、実行中のサービスを新しいワーカーへ再分散せず、scaleやupdateを試しても変化がないケースがありました。逆に、あるときは新しいサービスが完全にワーカーノード上だけで作成されることもありました。おそらくそれが最善の判断だったのでしょう。

新しいサービスがワーカーノード上に作成された様子

しばらくすると、既存サービスのコンテナが2つのノード間で再分散されましたが、ある程度時間がかかりました。新規サービスについては特に問題なく動作しました。これはあくまで初期段階での観察結果なので、現時点で断言できることは多くありません。とはいえ、Swarmの挙動を探索し、チューニングを始めるには良い出発点と言えるでしょう。

しばらくするとロードバランシングが機能し始める

まとめ

Dockerは優れたツールであり、今後さらに大規模に、複雑に、強力に、そして当然ながらより洗練されていくでしょう。大企業に買収されるのも時間の問題かもしれません。ネイティブオーケストレーションであるSwarmモードはかなり良好に動作しますが、そのアルゴリズムとスケーラビリティの真価を引き出すには、少数のコンテナだけでは不十分です。

本チュートリアルでは、CentOSが稼働するクラスタにFedoraノードを追加する方法を紹介しました。異なるディストリビューション同士でも問題なく共存できることを確認できました。ロードバランシングについてはまだ検証の余地が残されているため、今後の記事で詳しく掘り下げていく予定です。全体として、Swarm構築時に遭遇しがちな前提条件や一般的な問題への対処法を学び、複数のコンテナを起動し、サービスのスケーリングと分散についても触れることができました。そして忘れないでください。これはほんの始まりにすぎません。

それでは、また次回。