• ← 前回
• 連載 INDEX

　前回は、単一のDockerホストに複数のコンテナーをロードする方法を見てきたが、ここからは複数のホストに、複数のコンテナーをロードする方法を解説する。

Azure Container Service（ACS）によるDocker Swarm環境の構築

　通常、Dockerを使ったシステムを開発する際には、「コンテナーをスタック」して開発することが一般的である。例えばWebのシステムを開発するとしたら、DB＋APPサーバー＋Webサーバーという形態になるだろう、それぞれの要素はDockerコンテナーとして提供され、DBコンテナーの上に、APPサーバーのコンテナーがスタックされ、さらにその上にWebサーバーがスタックされているものと見なすことができる。

　また、スタックを構成するときに、DB-APP-WEBのコンテナーを1つずつ構成するだけではなく、システムが成長してユーザー数や扱うデータ量が増大したときに、コンテナーを追加して負荷分散を図ったり、その逆に、システムの負荷が下がったら、課金対象となるリソースを削減する目的で、コンテナーを削除する必要があるかもしれない。

　Dockerコンテナーをスタックするだけであれば、単一のDockerホストだけでも実現することは可能だが、Dockerホストの仮想マシンのサイズ（＝スペック）変更を図るだけでは、遅かれ早かれ限界が来てしまう。システムの高可用性を実現するためには、複数のDockerホストにまたがって、複数のコンテナーがお互いに協調して利用（＝Dockerコンテナーのクラスタリング）できることが必要となる。

　Azure Container Service（以下、ACSと略す）では、Dockerコンテナーのクラスタリングの機構として、DC/OS、Swarm、Kubernetesの中から選択・利用することができる。本記事では、前回までのDockerコマンドを使ってコンテナーのクラスターを操作できるSwarmを使い、コンテナーのクラスタリング方法について解説する。

　Dockerコンテナクラスターを構築するための、大まかな手順は以下の通り。

1. ACSの配置
2. ACS操作のためのSSHトンネリング設定
3. ACSでのコンテナクラスターの構築

1. ACSの配置

　ACSの配置に当たっては、AzureポータルサイトからACSのテンプレートを選択してサービスをデプロイする方法を採る。以下に手順を説明する。

ACSテンプレートの選択と、基本情報の設定

　Azureポータルサイトに接続し、左側のハブメニューから［＋新規］を選択して［Marketplace］の検索欄に「Azure Container Service」と入力してEnterキーを押す。これにより、検索結果の一番上に今回使用するACSテンプレートが表示される（図13）。

　「Azure Container Service」テンプレートを選択すると、テンプレートの説明（英語）が表示される。その下にある［作成］ボタンを押下すると、ACS配置のための基本情報を入力するブレード（図14）が現れるので、各項目をそれぞれ入力する。各項目の意味は表6の通り。

オーケストレーション機構の指定と、ノードの構成

　ACS配置のための基本情報を入力するブレード（図14）で［OK］ボタンを押下すると、Dockerコンテナクラスター実現のためのオーケストレーション機構を選択するブレード（図15）に切り替わる。先にも述べたように、本稿ではDockerコマンドを使って制御できる“Swarm”を採用するので、［Orchestrator configuration］欄で「Swarm」を選択して［OK］ボタンを押下する。

　次に、Dockerコンテナクラスターを構成するための、マスターノードとエージェントノードの数を指定する（図16）。マスターノードは、クライアントからDockerコマンドを受け付けて、エージェントノードにDockerコンテナーを起動・停止させる役割を持つ。今回は、ACSの検証のためにマスターノードを1台、エージェントノードを2台の構成とする。それぞれの項目の意味は表7の通り。

ACSの配置と、作成されたリソース群の確認

　図16の［OK］ボタンを押下すると、図17のように、ここまでに指定してきた構成の内容を確認できる。エージェントノードのサイズや台数は、配置後にAzureポータルサイトのGUIからは操作できないため*2、ここで間違いないか確認することをお勧めする。

　構成を確認したら、［OK］ボタンを押下すると［購入］ボタンが表示される。これを押下すると、ACSの配置が始まる。約30分程度で配置が完了する。ACSの配置が完了すると、Azureポータルサイトのダッシュボード画面に、新しく作成したリソース（今回の場合は、大文字化されて「DCRCLSTR」。図18の赤枠部分）が追加される。

　各リソースの中身を確認するには、図18のようにダッシュボード画面でリソースを選択する他にも、左側のハブメニューから［リソース グループ］を選択してから（図19）、「dcrclstr」を選択することでも確認できる（図20）。

2. ACS操作のためのSSHトンネリング設定

PuttyによるSSH接続とトンネリングの設定

　ACS環境に接続してDockerコンテナーを操作する前に、（クライアントから）Dockerマスターノードに接続するためのSSHトンネリングの設定を行う必要がある。puttyコマンドでPuttyを起動し、以下の設定を実施する。それぞれの設定手順は後述する。

　まずは秘密鍵のパスを指定する。Puttyを起動したら、左側の［Category］ツリーから［Connection］－［SSH］－［Auth］を選択し、右側の設定領域の一番下にある［Private key file for authentication］欄に、puttygenで生成した秘密キーのファイルパスを指定する（図21）。

　次にSSHトンネリングに関する指定。先ほどの［Connection］－［SSH］配下の［Tunnels］を選択し、［Source port］欄に「2375」を、［Destination］欄に「localhost：2375」を指定して［Add］ボタンを押下する。

　最後に接続先ホストとポート番号を指定する。［Category］ツリーから［Session］を選択し、［Host Name］欄に「dcrclstrmgmt.japaneast.cloudapp.azure.com」を、［Port］欄に「2200」を指定する。全ての指定が終わったら、［Saved Sessions］欄に接続のラベル（以下の例では「docker swarm」）を付けて［Save］ボタンを押下する。

PuttyによるSSH接続と、Docker Swarmの起動の確認

　上記の設定を実施したら、［Open］ボタンを押下してマスターノードに接続する。なお、接続時のログインユーザー（＝login as:の後に入力する名前）には、ACS配置先設定で指定した［User Name］（本稿の例では「builder」）を、パスワードには秘密鍵ファイル作成時に指定したパスワードを指定する。

　マスターノードに接続したら、docker psコマンドを実行する。これにより、Docker Swarmが起動していることを確認できる（図24の赤枠部分）。

SSHトンネリングによるコマンド送信と、エージェントノードの確認

　次に、クライアントPC側でdocker infoコマンドを実行してDocker環境情報を取得する。これにより、Dockerマスターノードに接続するためのSSHトンネリングの設定が正しく行われたかと、2台のエージェントノードが正しく割り当てられているかを確認する。が、その実行の前に、秘密鍵ファイルをDocker指定の場所にコピーし、環境変数としてDOCKER_HOST=:2375を設定しておく必要がある。

　よって、実行するコマンドはリスト13のようになる（※CMD、つまりコマンドプロンプトで実行することに注意）。なお、Dockerコマンドを実行すると、「クライアント」と「Swarmマスター」の間でのSSHトンネリングによりコマンドが送信されるため、以下の操作はPuttyでマスターノードに接続したままで行うこと。

　実際に実行したのが図25だ。Dockerエージェントノードとして2台の仮想マシンが割り当てられていることが確認できる（図25の赤枠部分）。

3. ACSでのコンテナクラスターの構築

　ACSの配置ができたので、DockerコンテナーとしてCassandraコンテナーを2つロードする。

前準備：Dockerネットワークの作成と確認

　今回は、エージェントノード間で通信が必要なため、コンテナーのロードに先立ちDockerネットワークをあらかじめ作成しておく（リスト14）。

　Dockerネットワークとしてoverlay-netという名前の仮想ネットワーク（Overlay Network）が作成されていればOKだ。

複数のCassandraコンテナーのロード

　次に、Cassandraコンテナーをロードするが、Cassandraコンテナーが相互に接続できないと正しくクラスターを構成できない。Cassandraコンテナーを個別にロードする形でもよいのだが、ここではDocker Compose（＝docker-composeコマンド）の仕掛けを使い、一度に複数のコンテナーを構成しつつロードする方法を採用する。

　以下の内容をcassandra-clstr.ymlという名称で任意のローカルディレクトリ（本稿ではC:\work）に保存する。

　ファイルを保存したら、以下の手順に従い、Cassandraコンテナーを起動する。

　まずは、docker-composeコマンドをインストールする（リスト16）。

　インストールが終わったらdocker-composeコマンドを実行する。その-fオプションには、先ほど保存したC:\workディレクトリのcassandra-clstr.ymlファイルを指定した。

　実行すると、Cassandraクラスターが起動し、それぞれのコンテナーが別のエージェントノードで起動される。図26はリスト17の実行結果で、docker psコマンドによる出力の［NAMES］列が、「swarm-agent-xxxxxx00001/cassandra-1」のように表記されていることが分かる。これは、ACS配置時に生成された、Swarmエージェントのホスト名である。

システム構成図：複数のSwarmエージェントで構成されたCassandraコンテナクラスター

　以上で、複数のDockerホスト（＝Swarmエージェント）へのCassandraコンテナーのロードは完了だ。そのシステムの構成は以下の通り。

Cassandraコンテナクラスターへのcqlsh接続

　それでは、Cassandraコンテナクラスターに接続してみよう。これには、リスト18のdocker runコマンドを実行する。

　先ほど起動したCassandraコンテナーのクラスターは、overlay-netという名前で仮想ネットワークを構築しているので、--networkオプションを追加して起動している。

　なお、この時点では、Cassandraコンテナーにストレージをマップしていないため、中身は空の状態である（※各Cassandraコンテナーにストレージをマップする方法は後述する）。

SwarmマスターおよびSwarmエージェントの停止

　次の操作に入る前に、ACSで起動したSwarmマスターとSwarmエージェントの停止方法を説明する。

AzureポータルサイトでSwarmマスターを停止する方法

　Swarmマスターを停止するには、Azureポータルサイトで今回作成したリソースグループ（本記事では「dcrclstr」）を選択し、「swarm-master-……」という名前の仮想マシンを選択してから、［仮想マシン］ブレードの上部にある［停止］ボタンを押下する（図28のように確認メッセージが表示されるが、［はい］ボタンを押下する）。

AzureポータルサイトでSwarmエージェントを停止する方法

　Swarmエージェントを停止するには、同様にリソースグループを選択してから、「swarm-agent-……」という名前の仮想マシンのスケールセットを選択してから、［仮想マシンのスケール セット］ブレードの［割り当てを解除する］（Deallocate）ボタンを押下する（図29のように確認メッセージが表示されるが、［はい］ボタンを押下する）。複数の仮想マシン（VM）のインスタンスがあっても、全て一括で停止することが可能である。

AzureポータルサイトでSwarmマスター／エージェントを開始し直す方法

　停止させたSwarmマスター／エージェントのノードは、［仮想マシン］／［仮想マシンのスケール セット］ブレードの上部にある［開始］（Start）ボタンを押下することで起動できる。

Azure-CLIでSwarmマスター／エージェントを停止する方法

　ちなみに上記と同じ操作を、Azure-CLIでも実現できる。具体的にはリスト19のように、Azure-CLIをARMモードに変更し、Azure Resource Manager（ARM）に対して命令を発行することで各リソースを操作可能である。リスト19で＜……＞で示されている環境ごとに異なる部分は、本稿の今回の環境であればリスト20のようになる。

　上記のAzureポータルサイト／Azure-CLIのどちらを使ってもよいが、SwarmマスターとSwarmエージェントは全て停止したままにして、次節に進んでほしい。

Swarmエージェントノードにストレージをマップする

　先ほど起動した、Cassandraクラスターの各ノードにストレージをマップして、Azure Fileストレージにデータを保存できるように構成を変更する*3。

　手順は以下の通り。

• 仮想マシンスケールセットの各ノードにSSH接続できるようにする
• 仮想マシンスケールセットの各ノードにドライバーをインストールする
• Cassandraコンテナー起動時にAzure Fileストレージをマップするように構成ファイルを修正する

　以下、各手順を説明する。

仮想マシンスケールセットの各ノードにSSH接続できるようにする

　仮想マシンスケールセット（以下、VMSS）の各ノードにSSHで接続するために、VMSSのノードと外部のインターネットを接続するためのポートを各ノードに用意する必要がある。

　VMSSの各ノードにはPublic IPアドレスが用意されていないため、インターネット側からノードに直接接続することはできないのだが、ノードとインターネットの間にロードバランサーが配置されているため、ロードバランサーにSSHポートの負荷分散規則を追加することでインターネットからVMSSのノードに接続可能になる。具体的には以下の設定を実施する。

　Azureポータルサイトにアクセスし、リソースグループ「dcrclstr」を選択。表示されるブレードのリソース一覧の中に「swarm-agent-lb-xxxxxx」という名前のロードバランサーがあるので、これをを選択。次に表示される［ロード バランサー］ブレード内のメニューから［設定］の［プローブ］を選択し、上部の［追加］ボタンを押下する。最後に［プローブの追加］ブレードの各項目に表10の値を入力してから、下にある［OK］ボタンを押下する。ちなみにプローブ（probes）とは、「探針」という意味であり、ロードバランサーが管理するVMSSノード（＝VMインスタンス）の正常性を監視・追跡するための機能である。

　続けて、［ロード バランサー］ブレード内のメニューから［設定］の［負荷分散規則］を選択し、上部の［追加］ボタンを押下する。［負荷分散規則の追加］ブレードの各項目に表11の値を入力してから、下にある［OK］ボタンを押下する。図30は実際にこの手順で設定しているところ。

　これでVMSSのロードバランサーを経由してVMSSのノードに接続できるようになった。

仮想マシンスケールセットの各ノードにドライバーをインストールする

　次に、各エージェントノードにSSHで接続し、「第3回：『Azure Storage』をDockerコンテナーにマップする」で行った手順を実施する。

　VMSSの各ノードを起動する必要があるが、ここではセットアップ対象の1つのノード（＝VMインスタンス）を起動し、セットアップが完了したらノードを停止し、次のノードを起動する、ということを繰り返す。

　まずはSwarmエージェントの個別インスタンスを1つだけ起動しよう。これには、Azureポータルサイトにアクセスし、リソースグループ「dcrclstr」を選択。リソース一覧から「swarm-agent-xxxxxx-vmss」（仮想マシンのスケールセット）を選択。［仮想マシンのスケール セット］ブレード内メニューから［設定］の［インスタンス］（Instances）を選択し、仮想マシンの一覧から任意の1つを選んでチェックを入れてから［Start］ボタンを押下する（図31）。

　1つのインスタンスが起動したら、Puttyを新たに起動し、表12の設定内容*4で、そのVMインスタンスに接続する。

　設定が終わったら、図32のように［Saved Sessions］欄に任意の名前（この例では「docker agents」）を入力し、［Save］ボタンを押下して設定内容（Session）を保存する。最後に、下部にある［Open］ボタンを押下して実際に接続する。

　接続時に必要なユーザー名（本稿の例では「builder」）とパスワードは、先に実施したSSHトンネリングの指定と同じである。接続すると、SSHのプロンプトにマシン名がbuilder@swarm-agent-XXXXXXXX000001:~$のように表示されるので、どのVMインスタンスに接続したかも確認できるだろう。

　あとは、「第3回：『Azure Storage』をDockerコンテナーにマップする」と同じ手順でazurefile-dockervolumedriverをインストールする（※第3回の「リスト8　ボリュームドライバー『azurefile-dockervolumedriver』の起動」までを実行する。「Dockerボリュームの作成」以降は実施しなくてよい）。

　インストールが終わったら、Puttyを終了し、Azureポータルサイトで先ほど起動したVMSSのノードを選択してから、［割り当てを解除する］（Deallocate）ボタンを押下し（図33）、今操作しているVMSSのノードを停止する。

　停止したことを確認したら、先ほどと同じ手順で次のVMSSノードを起動し、ドライバーをインストールする。

Cassandraコンテナー起動時にAzure File Storageをマップするように構成ファイルを修正する

　VMSSの各ノードにドライバーがインストールされたので、CassandraコンテナーにAzure File Storage（azurefileストレージ）をマップするように、Dockerの構成を変更する。

　先に保存したC:\workディレクトリのcassandra-clstr.ymlファイルを以下のように修正する。

　リスト21の構成では、cassandra-1のコンテナーにcassandra-vol1という名前のボリューム（ファイル共有名：myshare）をマップし、cassandra-2のコンテナーにcassandra-vol2という名前のボリューム（ファイル共有名： myshare2）をマップしている。また、この構成によって、各ボリュームはコンテナーが起動する前に、azurefileストレージにDockerボリュームがあるかどうかを確認し、もし存在しなければDockerボリュームを作成してからストレージをマップ、もし存在すればそのボリュームをマップして、コンテナーがロードされるようになる。

　それでは、動作を確認するため、今まで停止していたSwarmマスターのノードと、停止している残りのSwarmエージェントの全ノードを起動してほしい。それぞれののノード（＝VMインスタンス）を起動する方法は、先述の「AzureポータルサイトでSwarmマスター／エージェントを開始し直す方法」という項や、図31を参考にしてほしい。

　全ノードが起動したら、SSHトンネリングを開くため、Puttyを起動しSwarmマスターにSSHで接続する。

　次に、リスト23のコマンドをコマンドプロンプトで実行して、Cassandraクラスターを停止し、いったん削除することで初期化する*5。

　Cassandraコンテナーを停止＆削除した後、Cassandraコンテナーを再度起動してみる（リスト24、図34）。

　図34の赤枠内を見ると、コンテナーの起動と合わせて、ボリュームが作成されていることが分かる。今回の例では、エージェントノードが2つあるため、2つずつボリュームが生成されていることが分かる。

システム構成図：複数のSwarmエージェントで構成されたCassandraコンテナクラスター

　以上で、構成は以下のようになる。

Cassandraコンテナクラスターを停止・削除する方法

　ここまでに構築してきたCassandraクラスターは、停止したり、停止して削除したりできる。これには、以下のdocker-composeコマンドを使用可能である。

最後に

　今回は、Cassandraコンテナーを使い、複数のホストでCassandraクラスターを構築する方法を解説した。

　AzureクラウドでDocker実行環境を整備をする方法については、いったんここで一区切りとしたい。次回は、

• Dockerコンテナーを自分で構築する
• バージョン管理をする
• 開発環境から検証環境にデプロイする

といった構成管理の面から見たDocker利用の方法を説明する予定である。

• ← 前回
• ▼ この記事の連載 INDEX ▼ 連載 RSS