GCE上でDocker Swarm使ってクラスタ構築した Part2 (マルチマネージャノード)

• GCE上でDocker Swarm使ってクラスタ構築した Part1 (Getting Startedレベル)

未だに公式の方にはDocker Swarmのドキュメントも残ってて、こっちはswarm modeとか書いててイマイチどっちで呼称するべきなのかがよくわかりません。(2016年8月16日現在)
Part2は複数のマネージャノードの話。

ノード関連

マネージャノード

軽くおさらい。Part1で書いてないことまで書いてますが。

• クラスターを管理するためのノード
• サービスのスケジューリングをするノード
• デフォルトだとこいつもワーカーノードになる得る
• AvailabilityをDrainに変更すれば管理だけするノードになる
  • Docker的にはマネージャノードは管理に集中させた方がいいからDrainにしといた方がいいっぽい。そりゃそうだな。
• Raftアルゴリズム実装して使ってる

マネージャノードが落ちたらどうするん？

Part1では、シングルマネージャノードで動かしてました。
公式のHow nodes workでも書いてるとおり、シングルの場合はそのマネージャノードが落ちた場合サービス自体は動き続けるけど、クラスタを作り直す必要があります。
LBを外側に置いてれば、アプリケーションとしては動き続けられます。

インスタンス再起動なら、復帰時に勝手にクラスタの再構成はしてくれます。
ここのfailedはもっとマネージャがクラスタから強制的に抜けるとかのぶっ壊しをしたらってことでしょう。

というわけで、Swarmの恩恵を預かるには、クラスタノードの数に合わせて以下のようにマネージャの数を決めるのがオススメだそうです。

• 3マネージャなら、1マネージャが落ちることまでは許容できる
• 5マネージャなら、2マネージャまでなら許容できる
• Nマネージャなら、(N-1)/2マネージャまでなら許容できる
• Dockerは7マネージャをオススメする
• これ以上増やしてもスケーラビリティ・パフォーマンスには繋がらない

ワーカーノード

• コンテナ実行のためのノード
• スケジュールの決定には関わらない
• 言われたことだけやる人
• 自分からクラスタに参加する
• Drainのノードにはタスクは割り当てられない

ワーカーノードをマネージャノードに昇格

これでワーカーノードを格上げできます。

$ docker node promote <NODE_NAME>
$ docker node ls 
ID                           HOSTNAME              STATUS  AVAILABILITY  MANAGER STATUS
54dnxv70465ysj0nkf34oe2cy    my-swarm-worker-zujm  Ready   Active        Reachable
8x1ev7mve4znsgs9f4n7rqa5x *  my-swarm-manager      Ready   Drain         Leader
eniapt9t58gpi78vry2opgbp5    my-swarm-worker-k4r1  Ready   Active

MANAGER_STATUSがReachableになってます。
マネージャノードを複数用意しといてかつ必要な数のマネージャを用意しておけば、

マネージャノードをワーカーノードに降格

$ docker node demote my-swarm-worker-zujm 
Manager my-swarm-worker-zujm demoted in the swarm.
$ docker node ls 
ID                           HOSTNAME              STATUS  AVAILABILITY  MANAGER STATUS
54dnxv70465ysj0nkf34oe2cy    my-swarm-worker-zujm  Ready   Active        
8x1ev7mve4znsgs9f4n7rqa5x *  my-swarm-manager      Ready   Drain         Leader
eniapt9t58gpi78vry2opgbp5    my-swarm-worker-k4r1  Ready   Active

クラスタに参加

マネージャとして参加する方法と、ワーカーとして参加する方法があります。
docker swarm initした時に参加時のコマンドを参照できますが、あとからでも確認できます。
以下のコマンドをマネージャノードで実行して下さい。

$ docker swarm join-token [worker|manager]

それぞれ参加するコマンドは同じですが、マネージャとワーカーでトークンの値が違います。

$ docker swarm join --token <TOKEN> <MANAGER_IP>:2377

ちなみに、このノードに参加する場合、マネージャノードが複数ある場合はどのマネージャノードを指定してもOKですが、
Joinコマンド自体のマネージャノードが固定されちゃってるとそのマネージャノードが落ちてたら困りますね。
なんか方法を考える必要がありますね。

ノードの削除

ワーカーノード自ら離脱する場合と、マネージャノードが削除する場合の2パターンがあります。

自分で離脱する場合
ちなみに、マネージャノードは--forceオプションを付けると離脱できますが、あんまりオススメはしません。
あと、マネージャノードが

$ docker swarm leave

マネージャが削除する場合

$ docker node rm <NODE_NAME>

サービス関連

サービスはアプリケーションが動くための定義です。
公式のHow services workにサービスの図解がのってるので参考にするとよりイメージしやすいかと思います。

超わかりやすいサービスとタスクとコンテナの関係(公式より)

2つのデプロイ方法

• Replicated Service
• Global Service

バックアップ

ディザスタリカバリのためにマネージャノードの以下のディレクトリをバックアップしとくといいようです。

/var/lib/docker/swarm/raft

環境がぶっ壊れたら（ディザスタリカバリ）

クラスタ作り直しましょう。
アプリケーションもコンテナで動いているなら、仮にぶっ壊れてたとしてもアプリケーションそのものは復旧簡単ですよね。

$ docker swarm init --force-new-cluster --listen-addr <MANAGER_IP>:2377

GCPで作るなら…

雑ですがこんな感じかな？

• マネージャノード
  • 最初にswarm init
  • トークンをメタデータに保存
  • リーダーが自分のIPをメタデータに保存
  • って、ここまで書いて気付いたけどマネージャノードの最初はインスタンスグループ外で一個作った方がいいですね。
  • Part1のDeploymentManagerでマネージャノード作ってるのでまずはこれでクラスタ作成して、
    以降のマネージャノードの増減はインスタンスグループ追加すればいいかな。
• ワーカーノード
  • メタデータからトークンとか必要な情報を持ってくる
  • SwarmにJoin

管理するのめんどくさいですねｗ

とりあえず今回はここまで。
Swarm modeについては大体書けることは書いた感があります。・