WindowsユーザーのためのDockerコンテナー入門【Azure活用編】(4)

WindowsユーザーのためのDockerコンテナー入門【Azure活用編】(4)

Azure Container Service+Docker Swarmで、複数Dockerホストから成るクラスターの構築
――Dockerコンテナー実践活用(後編)――

2016年12月7日

Azure Container ServiceでDocker Swarmを使い、複数のDockerホスト上にCassandraコンテナーをロードする手順を説明する。

アバナード 旭 哲男
  • このエントリーをはてなブックマークに追加

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

Azure Container Service(ACS)によるDocker Swarm環境の構築

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

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

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

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

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

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

1. ACSの配置

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

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

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

図13 「Azure Container Service」テンプレート

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

図14 Azure Container Serviceの作成(1): 基本情報の入力
項目 意味 説明
User Name Docker管理ホストの管理アカウント名 Docker Swarmを使ってDockerコンテナクラスターを構築するときの管理ホストを制御するための管理者アカウント。本稿の例では「builder」を指定している
SSH public key SSH認証のための公開鍵の文字列 Docker管理ホストに接続するための認証公開キー。puttygen(PuTTY Key Generator)を使って公開鍵と秘密鍵を作成し、公開鍵の文字列をここに貼り付ける。詳細については、第1回記事を参照のこと
サブスクリプション Azureの契約種類 Azureの契約を複数持っている場合には課金対象の契約を選択できる
リソース グループ ACSを配置する先のリソースグループ ACSテンプレートに記載されている各種リソースを配置する先の名前。新規リソース名(本稿の例では「dcrclstr」)を指定する
場所 リソース配置先の地域 どの地域のクラウドリソースを使用するか指定。本稿の例では「東日本」(Japan East)を指定した
表6 ACS配置のための基本情報の設定項目

【コラム】「Azure Container Service」テンプレートとAzure Resource Manager(ARM)モード

 今回のACSの配置では、仮想マシンやストレージの他に、可用性セット、仮想マシンのスケールセット、ロードバランサー、仮想ネットワークといったAzureで提供されている各種リソースが同時に配置される。Azureでは、複数のリソースを一括して配置・管理できるようにAzure Resource Managerを経由してサービスが提供される。配置のオペレーションを実施すると、Azure Resource Managerは、配置テンプレートを参照し、使用するリソース定義に従って環境が生成される。詳細については「公式サイト:Azure リソース マネージャーの概要」を参照のこと。

 ちなみに、今までDockerホストの作成をAzure-CLIで行ったときに、ASM(Azureサービス管理)モードに変更してから操作を行っていたが、実際にはARM(Azure Resource Manager)モードでもDockerホストとして必要なリソースを配置テンプレートとして定義することで配置は可能である(ただし配置テンプレートをゼロから記述するのは困難であり、既存の配置テンプレートを修正して使うのが一般的である)。

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

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

図15 Azure Container Serviceの作成(2): オーケストレーション機構の選択

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

図16 Azure Container Serviceの作成(3): マスターノードとエージェントノード数の指定
項目 意味 説明
Agent count 配置されるエージェントノードの数 Dockerコンテナーを処理するエージェントの仮想マシンの台数を指定する。今回は「2」を入力する
Agent virtual machine size エージェントノードのサイズ エージェントノードの仮想マシンのサイズ(=スペック)を指定する。今回の例では「Standard A1」を選択。この設定の理由については*1を参照されたい
Master count 配置されるマスターノードの数 Dockerコンテナーを操作するマスターの仮想マシンの台数を指定する。今回は「1」を入力する
DNS prefix for container service Swarmコンテナーを使用するときの、接続先プレフィックス名 DockerクライアントからDockerマスターに接続するための、接続プレフィックス名を指定する。本稿の例では「dcrclstr」とした(たまたまリソース名と一致しているが、一致させる必要はない)。後述の<DNSプレフィックス>にはこれを指定する
VM Diagnostics 仮想マシンの診断情報 診断情報の出力を有効にするか(Enabled)、無効にするか(Disabled)を指定する。今回は「Disabled」でよい
表7 マスターノードとエージェントノード数の設定項目

*1 ACSの配置テンプレートの初期値では、エージェントノードは、「Standard D2」が指定されており、複数のコンテナーをロードしても余裕のある構成となっている。今回は複数のホストで、複数のコンテナーに分散してロードされる様子を確認するため、「Standard A1」にサイズダウンしていることに注意(指定したいサイズが表示されていない場合は、[サイズの選択]ブレードの右上の[すべて表示]リンクボタンをクリックすればよい)。

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

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

図17 Azure Container Serviceの作成(4): 構成内容の確認で
  • *2 配置後のエージェントノードのサイズや台数の変更は、Azure Resource Managerを直接操作する必要がある。なお、エージェントノードのサイズ・台数の変更方法については、次回以降の記事で解説予定だ。

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

図18 ダッシュボード画面に表示されたリソース群

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

図19 [リソース グループ]ブレードに表示されたリソース群
図20 ACSテンプレートで作成したリソースグループの内容を確認

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

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

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

設定項目 設定値 説明
接続先ホスト <DNSプレフィックス>mgmt.<地域>.cloudapp.azure.com <……>で示されている箇所は、オーケストレーションの選択で入力した[DNS prefix for container service]と、リソース配置先の地域を指定する。本稿の例では「dcrclstrmgmt.japaneast.cloudapp.azure.com」となる
ポート 2200 SSHで接続するポート番号。「2200」固定
秘密鍵のパス マスターノードに接続するための秘密鍵 リソース配置先の[SSH public key]で指定した公開鍵に対応する、秘密鍵のファイルパスを指定
ソースポート 2375 Dockerコマンドを受け付けるポート番号。「2375」固定
接続先 localhost SSHトンネリングの接続先ホスト名。「localhost」固定
表8 Puttyで設定する必要がある項目

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

図21 PuttyによるSSHトンネリングの設定(1): 秘密鍵のパス

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

図22 PuttyによるSSHトンネリングの設定(1): SSHトンネリングの接続先ホストとポート番号

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

図23 PuttyによるSSHトンネリングの設定(3): 接続先ホストとポート

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

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

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

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

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

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

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

CMD
# 秘密鍵をコピーする
CMD> cp "<秘密鍵のファイルパス>" "%USERPROFILE%\.docker\key.pem"

# 環境変数 DOCKER_HOSTの設定
CMD> set DOCKER_HOST=:2375

# Docker環境情報の確認(SSHトンネリングによるコマンド送信)
CMD> docker info
リスト13 SSHトンネリングによるコマンド送信と、その前準備

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

図25 エージェントノードの確認

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

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

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

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

CMD
# Dockerネットワークの作成
CMD> docker network create --driver overlay --subnet=192.168.0.0/24 overlay-net

# Dockerネットワークの確認
CMD> docker network ls
リスト14 Dockerネットワークの作成と確認

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

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

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

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

cassandra-clstr.yml
version: '2'
services:
  cassandra-1:
    image: cassandra
    container_name: cassandra-1
    environment:
      CASSANDRA_BROADCAST_ADDRESS: "cassandra-1"
    ports:
    - 7000
    restart: always
  cassandra-2:
    image: cassandra
    container_name: cassandra-2
    environment:
      CASSANDRA_BROADCAST_ADDRESS: "cassandra-2"
      CASSANDRA_SEEDS: "cassandra-1"
    ports:
    - 7000
    depends_on:
      - cassandra-1
    restart: always
networks:
  default:
    external:
       name: overlay-net
リスト15 サービス(services)とネットワーク(networks)を定義したYAML形式のComposeファイル

設定内容の詳細は、公式ドキュメントの「Compose ファイル・リファレンス」を参照されたい。

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

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

PowerShell
# docker-composeコマンドのインストール
PS> choco install docker-compose
リスト16 docker-composeコマンドのインストール

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

CMD
# cassandra-clstr.ymlファイルが保存されたディレクトリに移動
CMD> cd C:\work

# docker-composeを使ってCassandraコンテナーをロードし、Cassandraクラスターを構成する
CMD> docker-compose -f cassandra-clstr.yml up -d

# Cassandraクラスターが起動したことを確認する
CMD> docker ps
リスト17 Cassandraコンテナーの起動

docker-composeコマンドのオプションやコマンドについては公式サイトのコマンド概要を参照してほしい。ここで使われているものは、以下の意味がある。
-fオプション: Composeファイルを指定する
upコマンド: コンテナーを作成して起動する。続けて「デタッチモード(Detached mode:デタッチした状態、つまりバックグランドで起動するモード)」を意味する-dオプションが指定されている(詳細は公式サイトのupコマンドの説明を参照)

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

図26 Cassandraコンテナーを起動した結果

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

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

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

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

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

CMD
# Cassandraクラスターに接続する
CMD> docker run -it --link cassandra-1:cassandra --network overlay-net cassandra cqlsh cassandra
リスト18 Cassandraコンテナクラスターにcqlshで接続

各オプションの意味については、第2回の記事のリスト3などの説明を参照してほしい。ここで新たに登場したdocker run--networkオプションは表9の通り。
このコマンド例では、cqlshクライアントで接続しており、第2回で説明したCQLが使えるようになる。今回はCQLを使ったテーブル作成などは行わないので、ここでexitコマンドを入力してcqlshを終了してよい。

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

オプション 意味 説明
--network ネットワーク名 コンテナーをネットワークに接続させる リスト18の例では、「cassandra」コンテナーを「overlay-net」ネットワークに接続させるように指定している
表9 Dockerコンテナー起動(docker run)コマンドのオプション(仮想ネットワークへの接続で使用分)

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

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

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

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

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

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

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

図29 Swarmエージェントを停止する方法
AzureポータルサイトでSwarmマスター/エージェントを開始し直す方法

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

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

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

CMD
# ARMモードに変更
CMD> azure config mode arm

CMD> azure login

# Swarmマスター(VM:仮想マシン)の停止
CMD> azure vm stop <リソースグループ> <仮想マシン名>

# Swarmエージェント(VMSS:仮想マシンスケールセット)の停止
CMD> azure vmss deallocate <リソースグループ> <仮想マシンスケールセット名> <スケールセット内のインスタンスID>
リスト19 Azure-CLIでSwarmマスター/エージェントを停止する方法

<仮想マシン名>/<仮想マシンスケールセット名>/<スケールセット内のインスタンスID>は自動生成されているので、Azureポータルサイトで確認する必要がある。<スケールセット内のインスタンスID>には、個別インスタンスの場合は01のような数値を、全インスタンス一括の場合は*を指定する。
停止したSwarmマスター/エージェントをAzure-CLIで起動し直すには、上記のstopdeallocatestartに置き換えればよい。

CMD
CMD> azure config mode arm
CMD> azure login
CMD> azure vm stop dcrclstr swarm-master-5DDAC7BE-0
CMD> azure vmss deallocate dcrclstr swarm-agent-5DDAC7BE-vmss_*
リスト20 本稿の今回の環境でのリスト19の実行例

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

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

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

  • *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インスタンス)の正常性を監視・追跡するための機能である。

項目 説明
名前 tcpSSH VMSSノードを監視するためのポート名称。「tcp<ポート名>」のような名称を付ける
プロトコル TCP 今回はSSHを負荷分散させたいため、「TCP」を選択する
ポート 22 監視させるポート番号。SSHのポート番号である「22」を指定する
間隔 30 VMSSノードに対して監視間隔を指定する
異常しきい値 2 監視時にポートからの応答がない場合はエラーとしてカウントされる。ここで指定した回数回エラーが発生したらノードは「非活性」と判断される
表10 プローブとして追加する「SSHポート」の内容

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

項目 説明
名前 LBRuleSSH 負荷分散のルール名。「LBRule<ポート名>」のような名称を付ける
フロントエンド IP アドレス swarm-agent-lbFrontEnd-xxxxxx ロードバランサーに割り当てられているIPアドレスのリソース名。デフォルトのままでよい
プロトコル TCP 負荷分散対象のプロトコル種別を指定する。「TCP」のままでよい
ポート 22 負荷分散対象のポートを指定する。今回はSSHのデフォルトポートである「22」を指定する
バックエンド ポート 22 ロードバランサーのバックエンドにあるVMSSのノード側のポートを指定する。今回はSSHのデフォルトポートである「22」を指定する
バックエンド プール swarm-agent-pool-xxxxxx ロードバランサーのバックエンドにあるVMSSのプール(=プライベートIPアドレスを持つ複数ノードをまとめたグループ)を指定する。デフォルトのままでよい
プローブ tcpSSH (TCP:22) 先ほど登録したプローブを選択する
セッション永続化 なし 毎回、異なるノードに接続できるよう、「なし」のままとする
アイドル タイムアウト 4 接続の維持間隔。デフォルトのままでよい
表11 ロードバランサーに追加する「SSHポートの負荷分散規則」の内容

[フローティング IP (Direct Server Return)]という入力項目はデフォルトの「無効」のままでよい。これは現時点でSQL AlwaysOn可用性グループリスナーを構成する場合にのみ使用されており、本稿の内容とは無関係なので説明を割愛する。

図30 SSHポートの負荷分散規則を設定しているところ

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

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

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

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

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

図31 セットアップ対象の1つのノード(=VMインスタンス)を起動

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

  • *4 設定内容は、表8で示した「SSHトンネリング設定」とほぼ同じ。接続先ホストが<DNSプレフィックス>mgmt.<地域>.cloudapp.azure.comから<DNSプレフィックス>agents.<地域>.cloudapp.azure.comに変わったことに注意。
設定項目 設定値 説明
接続先ホスト <DNSプレフィックス>agents.<地域>.cloudapp.azure.com オーケストレーションの選択で入力した[DNS prefix for container service]と、リソース配置先の地域を指定する。本稿の例では「dcrclstragents.japaneast.cloudapp.azure.com」となる
ポート 22 SSHで接続するポート番号。SSHのデフォルトポートである「22」を指定する
秘密鍵のパス マスターノードに接続するための秘密鍵 リソース配置先の[SSH public key]で指定した公開鍵に対応する、秘密鍵のファイルパスを指定
ソースポート 2375 Dockerコマンドを受け付けるポート番号。「2375」固定
接続先 localhost SSHトンネリングの接続先ホスト名。「localhost」固定。Puttyの[Destination]欄には「localhost:2375」と指定する必要があるので注意
表12 Puttyで設定する必要がある項目

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

図32 Puttyを設定しているところ

 接続時に必要なユーザー名(本稿の例では「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のノードを停止する。

図33 ドライバーインストール済みのVMSSのノードを停止し、次のノードを起動する

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

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

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

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

cassandra-clstr.yml
version: '2'
services:
  cassandra-1:
    image: cassandra
    container_name: cassandra-1
    environment:
      CASSANDRA_BROADCAST_ADDRESS: "cassandra-1"
    ports:
    - 7000
    volumes:
      - "cassandra-vol1:/var/lib/cassandra"
    restart: always
  cassandra-2:
    image: cassandra
    container_name: cassandra-2
    environment:
      CASSANDRA_BROADCAST_ADDRESS: "cassandra-2"
      CASSANDRA_SEEDS: "cassandra-1"
    ports:
    - 7000
    depends_on:
      - cassandra-1
    volumes:
      - "cassandra-vol2:/var/lib/cassandra"
    restart: always
volumes:
  cassandra-vol1:
    driver: azurefile
    driver_opts:
      share: myshare
  cassandra-vol2:
    driver: azurefile
    driver_opts:
      share: myshare2
networks:
  default:
    external:
       name: overlay-net
リスト21 サービス(services)とボリューム(volumes)とネットワーク(networks)を定義したYAML形式のComposeファイル

 リスト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

CMD
# Cassandraクラスターの停止と削除
CMD> docker stop cassandra-1 cassandra-2
CMD> docker rm cassandra-1 cassandra-2
リスト23 Cassandraクラスターの停止と削除
  • *5 念のため、Cassandraコンテナーを停止&削除しておく。上記の説明では全ノードを起動するようにしているので発生しないはずだが、すでに停止しているコンテナーを停止しようとした場合には「No Such container: cassandra-1」といったエラーが発生する。このエラーは、無視しても問題ない。

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

CMD
# Cassandraクラスターの起動
CMD> docker-compose -f cassandra-clstr.yml up -d

# Cassandraボリュームの一覧
CMD> docker volume ls
リスト24 Cassandraコンテナーを起動し直す
図34 Cassandraコンテナーを起動し直した結果

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

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

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

図35 複数のSwarmエージェントで構成されたCassandraコンテナクラスター
Cassandraコンテナクラスターを停止・削除する方法

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

CMD
# Cassandraクラスターの停止(コンテナー削除まではしない)
CMD> docker-compose -f cassandra-clstr.yml stop

# Cassandraクラスターの停止と削除
CMD> docker-compose -f cassandra-clstr.yml down
リスト25 Cassandraコンテナクラスターを停止・削除する方法

最後に

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

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

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

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

1. Dockerとは? Dockerホストの作成から、Dockerコンテナーのロードまで

Dockerの概要やそれが必要な理由、仮想マシンとの違いを解説。初めてDockerを使うWindowsユーザーに向けて、AzureにDockerホストを作成してSSH接続し、Dockerコンテナーを起動・停止する方法を説明する。

2. Dockerコンテナーの起動・停止と、Cassandraのコンテナーへのcqlsh接続&CQL実行

Dockerコンテナーの基本的な使い方(起動・停止)を一通り説明。また、Cassandraのコンテナーにcqlshで接続してCQL文によりテーブル作成やレコード追加を行う手順を解説する。

3. Dockerコンテナーへのストレージのマッピングと、複数コンテナーのロード(単一ホスト)

実運用で必要となる「ストレージのマッピング」(Dockerホストのストレージを利用/Azure File Storageを利用)を解説。さらに、単一のホストに複数のCassandra DockerコンテナーをロードしてCassandraクラスターを構築する方法を説明する。

4. 【現在、表示中】≫ Azure Container Service+Docker Swarmで、複数Dockerホストから成るクラスターの構築

Azure Container ServiceでDocker Swarmを使い、複数のDockerホスト上にCassandraコンテナーをロードする手順を説明する。

イベント情報(メディアスポンサーです)

Azure Central の記事内容の紹介

GrapeCity Garage 記事内容の紹介

Twitterでつぶやこう!


Build Insider賛同企業・団体

Build Insiderは、以下の企業・団体の支援を受けて活動しています(募集概要)。

ゴールドレベル

  • 日本マイクロソフト株式会社
  • グレープシティ株式会社