cloudpack の 自称 Sensu芸人 の かっぱこと 川原 洋平（@inokara）です。
はじめに
Consul という Vagrant や Serf で有名な Hashicorp 社が作ったツールをちょっと使ってみたのでメモです。
尚、記事を作成するにあたって以下の記事、スライドを参考にさせて頂きました。
有難うございます。詳しいことは上記の記事やスライドをご覧になることをお薦め致します。
わっといず Consul
ざっくり Consul
Consul とは以下のような機能を持っているとのことです。
- サービスやそのサービスの障害検知
- HTTP や DNS で操作出来る
- マルチデータセンター
- キー・バリューストア
サービスの検出や障害検知に関してはなんとなくイメージが掴めますが、マルチデータセンターやキー・バリューストアの機能については使いどころについては個人的にちゃんと確認したいなと考えています。
また、Consul はサーバーとクライアント（ノード）の構成で稼働するとのことで以下のような役割があります。
| サーバー / クライアント（ノード） |
役割 |
|---|---|
| サーバー | 情報をキー・バリューストアに保存してクライアントからのリクエストに応える |
| クライアント（ノード） | サービスの監視を行いサーバーに情報を伝える |
Consul イメージ
イメージとしては以下のような感じでしょうか…
図にしてみるとなんとなくイメージが掴めてきたような気がします。また、詳しい実装等についてはこちらも合わせて確認しましょう。
Consul 用語
こちらをちょっと和訳してみました。今回もご協力は Powered by Google 翻訳です。
| 用語 | ざっくり意味 |
|---|---|
| Agent | Agent は全てのクラスタメンバーで起動するデーモンでクライアント or サーバーモードで実行、すべてのエージェントは DNSや HTTP インタフェースを利用してチェックを実行し同期してサービスを維持する |
| Client | Client はサーバーと RPC でステートレスな通信をする Agent で最小限のネットワークオーバーヘッドにてバックグラウンドで稼働する（クライアントは LAN Gossip プールを利用している） |
| Server | Server は Server モードで稼働するエージェントで Raft quorum にてクラスタ状態を維持してリーダーノードやリモート DC へのクエリ、他の DC への WAN Gossip や RPC の応答、転送等の役割を有する |
| Datacenter | Datacenter は EC2 による複数 AZ と同じようなもの（だと思う）で低レイテンシーで高帯域なプライベートネットワークで通信できる環境を定義する（インターネット越し通信は除く） |
| Consensus | リーダーを決めたりトランザクションの順序についての取り決め |
| Gossip | Consul は Gossip プロトコルを提供する Serf を利用して構築されており、Serf はメンバーシップ、障害検出、イベントのブロードキャストメカニズムを提供する |
| LAN Gossip | LAN Gossip は全て同一のローカルエリアネットワークまたはデータセンターにゴシップ·プールが存在する場合に利用される |
| WAN Gossip | WAN Gossip は異なるデータセンター間でゴシッププールを利用する際に利用される |
| RPC – RPC | 読んで時のごとく Remote Procedure Call （リモート・プロシージャ・コール）の略で Client と Server 間で利用される |
これで私も和洋折衷の Consulタントだと思ったら @zembutsu さんが以下にちゃんとした和訳を書かれておりました…。
有難うございます！
Consul ポート
Consul で使うポートは下記のようなポートがあります。
| ポート | 用途 |
|---|---|
| 8400 | RPC で利用 |
| 8500 | HTTP API で利用 |
| 8600 | DNS インターフェースで利用 |
インストールと起動
インストール
インストールはとても簡単です。Consul は Go 言語で書かれておりバイナリで配布されていますので以下のようにダウンロードして zip を解凍するだけです。
wget https://dl.bintray.com/mitchellh/consul/0.3.0_linux_amd64.zip
unzip 0.3.0_linux_amd64.zip
起動
ここから少し注意が必要です。サーバーとクライアントで起動方法が異なります。
Consul サーバー
./consul agent -server -bootstrap -client=xxx.xxx.xxx.1 -dc=local
-node=consul1 -data-dir=/tmp/consul -bind=xxx.xxx.xxx.1 &
Consul クライアント（ノード）
./consul agent -dc=local -node=consul2 -data-dir=/tmp/consul2
-bind=xxx.xxx.xxx.2 -join=xxx.xxx.xxx.1 &
それぞれを起動した直後の Consul サーバーのスクリーンショットです。
よく見ると serf が稼働していて Consul サーバー（consul1）へのメンバージョインを検出していることが判ります。
Hello Consul
現状、三台の Consul ノードで 1 台が Consul サーバー、2 台が Consul クライアントな状態でクラスタが組まれている状態かと思います。
コマンドラインツールによるクラスタノードの確認
コマンドラインツールを利用してクラスタノードのメンバーを確認してみます。
consul members
以下のように出力されます。
HTTP API や DNS によるサービスの検出
Consul の一つの機能として HTTP API や DNS によるサービスの検出という機能があり、HTTP リクエストや dig コマンドでクラスタ内のノードメンバーや稼働しているサービスを確認することが出来ます。
HTTP API
どこかのノードで以下のようなリクエストを curl で投げてみます。（みんな大好き jq はあらかじめインストールしておきましょう…）HTTP の問い合わせは 8500 ポートに対して行います。
curl -s http://${Consul サーバーの IP}:8500/v1/catalog/nodes | jq .
以下のような結果が返ってきます。
これはクラスタ内の Consul メンバーの一覧を確認出来ます。
尚、HTTP API の問い合わせエンドポイントについてはこちらにて詳しく解説してされておりますので参考にさせて頂きます。
例えば、あるノード（consul3）の状態を確認する為には以下のようなリクエストを投げます。
curl -s http://${Consul サーバーの IP}:8500/v1/health/node/consul3 | jq .
以下のような結果が返ってきます。
では、consul3 で Consul agent がお亡くなりなった状態で問い合わせをすると…
何も返ってきませんがな。つまり、他のノードからは consul3 がお亡くなりなったことを検知することが出来そうです。
DNS による問い合わせ
dig コマンドを使って問い合わせてもみます。DNS による問い合わせは 8600 ポートに対しておこないます。
dig @${Consul サーバーの IP} -p 8600 consul1.node.consul any
以下のような結果が返ってきます。
最小インストールな CentOS では dig コマンドすらインストールされていないことも（telnet 先生とかも同様に…）あるので以下のようにインストールしておきましょう。
yum -y install bind-utils
DNS による問い合わせは個人的には馴染みが浅いですが、HTTP API を使って各ノードで稼働しているサービスのヘルスチェックが出来るというのは素晴らしいですね。
引き続き
今回やったこと
- consul をインストールしてみました
- 三台のノードを使ってクラスタを構成してコマンドラインツール、HTTP API と DNS を使ってクラスタノードを確認しました
次回は…
- ノードで稼働しているサービスの監視、障害検知
- Consule についても少し詳しく見ていきたいと思います
元記事は、こちら