Consulを頑張って理解する
2016年02月14日(日) ver 1.0.1.0
http://www.atelier.jp/
渡邉 雅和
〜どんぶり勘定シリーズ〜
2016年02月14日(日) ver 1.0.1.0
2016年02月11日(木) ver 1.0.0.0
Q:Consul て何ですか?
A:HashiCorp社が開発しているサービス管理ツール的なもの
公式サイトは https://www.consul.io/ です。
公式サイトトップページいわく
>Service discovery and configuration made easy.
>Distributed, highly available, and datacenter-aware.
サービス検出や設定を簡単に出来るようにするものです。
分散、高可用性、そしてデータセンターを意識して作られています。
とりあえずは基本情報から...
もう少し細かく言うと...
○機能的には
*サービスの公開機能
*サービスのヘルスチェック機能
*KVS機能
*イベント機能 (及び状態変化のイベント通知機能)
*リモートコマンド実行機能
その他色々な機能が用意されている。
操作とかは...
○参照、操作の為のAPIインターフェースとしては
*cli (コマンドラインインターフェース)
*DNS (DNS API)
*HTTP API
等が用意されている。
角度を変えて説明すると...
*KeepAlived
*NagiosやZabbix
*KVS (グローバルなデータストア、早くはない)
*DNS
*これらの状態監視とトリガ実行
以上のような既存のソフトウェアを
足して割った上にクラスタリング対応させたもの。
といった所でしょうか(多分)
インストールとかは...
*サーバは3台、または5台が必要となる(それ以上はそんなに効率出ないらしい)
*サーバ、クライアント共に共通の
consul というバイナリ一つで動作する (go言語製)
つまりインストール自体は簡単!
少なくとも大量のモジュールやインストーラを
気にしないで済む分楽に感じる!(多分)
サーバが3台いる部分はネックとなる場合もありますが、
そもそも冗長化が必要となる部分で用いるものなので、
きっとなんとかなる...はず。
※デバッグ目的等の場合は-devオプション使用で1台でも試せます (ver0.6.3以降)(オンメモリ/データ出力無しモード)
んで、結局どんな場面で使う
ものなのか?
例えばこんな場面?...
*Webサーバは冗長化の為に複数台用意する必要がある
*Webサーバは死活監視をしなければならない
*Webサーバは追加の際にロードバランサに登録をしなければならない
*DBサーバは冗長化の為に複数台用意する必要がある
*DBサーバは追加の際に冗長化proxyに登録をしなければならない
*DBサーバが追加された場合はWebサーバは追加されたDBを使用
しなければならない
*現在のサーバ群の状態を含めた情報の一覧が欲しい
青字の部分に
困っていたら
consulが補助を
してくれるかも
大雑把な構成イメージ ※色々省略してます
node01.example.jp
IP:192.168.20.21
consul server 01
node04.example.jp
IP:192.168.20.41
consul client 01
apach01
node02.example.jp
IP:192.168.20.22
consul server 02
node03.example.jp
IP:192.168.20.23
consul server 03
node05.example.jp
IP:192.168.20.42
consul client 02
apach02
consul操作script等
consul操作script等
consulクライアントで自身のノー
ドにあるApacheの状態を監視
Apacheで実行されているWeb
アプリをサービスとして
consulに登録
Webアプリがサービスとして登
録された事をイベント的に検知
して何かを行う等
※ちなみに一見ではnagios/zabbixサーバと
agentを入れたクライアントとの構成に似て見えますが、
nagios/zabbix等とは似て非なる物だと思った方が
良いかと思います
では実際に使ってみるの巻
== インストール編 ==
大雑把な構成イメージ ※色々省略してます
node01.example.jp
IP:192.168.20.21
consul server 01
node04.example.jp
IP:192.168.20.41
consul client 01
apach01
node02.example.jp
IP:192.168.20.22
consul server 02
node03.example.jp
IP:192.168.20.23
consul server 03
node05.example.jp
IP:192.168.20.42
consul client 02
apach02
consul操作script等
consul操作script等
構成を踏まえつつインストール ※サーバ/クライアント共通
1:公式サイトからconsulをダウンロードする
https://www.consul.io/downloads.html
※バイナリなのでOSと64bit/32bitを選択してダウンロード
Linux-64bitなら (ver 0.6.3)
#wget https://releases.hashicorp.com/consul/0.6.3/consul_0.6.3_linux_amd64.zip
2:解凍
#unzip ./consul_0.6.0_linux_amd64.zip
3:各ノードでインストール
#mv ./consul /usr/local/bin
#chmod +x /usr/local/bin/consul
インストール完了
※少しウソ、大体本当
サーバノードで consul server を起動
1:各サーバノードで順番に実行
○node01.example.jp
#nohup consul agent -server -bootstrap-expect=3 
-data-dir=/var/lib/consul -advertise=192.168.20.21 &
○node02.example.jp
#nohup consul agent -server -bootstrap-expect=3 
-data-dir=/var/lib/consul -advertise=192.168.20.22 
-join=node01.example.jp &
○node03.example.jp
#nohup consul agent -server -bootstrap-expect=3 
-data-dir=/var/lib/consul -advertise=192.168.20.23 
-join=node01.example.jp &
※consulをそのまま実行するとフロントエンドで動作する為、先頭の nohup と 最後の & にてバックグラウンド動作をさせています。
クライアントノードで consul client を起動
1:各クライアントノードで実行
○node04.example.jp
#nohup consul agent -data-dir=/var/lib/consul -advertise=192.168.20.41 
-join node01.example.jp &
○node05.example.jp
#nohup consul agent -data-dir=/var/lib/consul -advertise=192.168.20.42 
-join node01.example.jp &
※consulをそのまま実行するとフロントエンドで動作する為、先頭の nohup と 最後の & にてバックグラウンド動作をさせています。
クラスタリング環境構築完了
※少しウソ、大体本当
通信関係捕捉
consulは結構色々な通信ポートをいるようです。以下のポートにて正
しく通信が行える状態になっている必要があります。
TCP:8300 ServerRPCで使用
TCP:8301/UDP:8301 SerfプロトコルのLAN用通信で使用
TCP:8302/UDP:8302 SerfプロトコルのWAN用通信で使用
TCP:8400 RPCのエンドポイント
TCP:8500 HTTP-APIで使用
TCP:8600/UDP:8600 DNSで使用
引数捕捉 ※実際はもっと沢山ありますので公式ドキュメントを参照下さい
*agent
agentを起動(serverやclientを起動)
*-server
サーバモードで起動
*-bootstrap-expect=3
指定台数が揃ってからサーバの起動を始める。
split-brainの防止等の為。
*-data-dir=/var/lib/consul
データディレクトリの指定.指定必須。(場所はどこでも良い)
*-advertise=192.168.20.21
広告IPアドレスの指定。IPアドレスを複数持っている場合等に指定必須。(ver0.6)
*-join=node01.example.jp
接続先クラスタの指定 (複数指定出来る、今回は最初の例なので取り敢えずnode01指定)
起動して後からjoinでも問題ありません。
ちなみにもう少しだけ実践的な起動時の引数では...
○node01.example.jp、node02.example.jp、node03.example.jp (サーバ)
#consul agent -server -bootstrap-expect=3 
-data-dir=/var/lib/consul -bind 0.0.0.0 -advertise=192.168.20.21 
-retry-join=node01.example.jp 
-retry-join=node02.example.jp 
-retry-join=node03.example.jp
※赤字部分は各ホスト自身のIPアドレスで後は全台同じ記述
○node04.example.jp、node05.example.jp (クライアント)
#consul agent 
-data-dir=/root/consul/data -bind 0.0.0.0 -advertise=192.168.20.41 
-retry-join=node01.example.jp 
-retry-join=node02.example.jp 
-retry-join=node03.example.jp
※赤字部分は各ホスト自身のIPアドレスで後は全台同じ記述
その他今回は説明の為に割愛している注意事項
詳細説明は別の機会にしようかと思っておりますが、今の段階でも書いておかないと原因不
明で動作しない等あるかもしれないので...
consulサーバ3台の場合1台のdownまでは問題無いのですが、2台以上のdownの場合は、
データ保全やスプリットブレイン防止の為等の理由で制限状態(実質停止)になります。
前述の理由等により2台以上停止した場合は同じように起動しようとしても、 そのままでは
起動出来無い場合があります。その場合は-data-dirで指定したディレクトリを全台削除す
ればデータは全て消えますが取り敢えず起動可能な状態になります。復旧の仕方等は別の機
会に...
consulはフロントエンド起動しますのでデーモン的に動作させる場合は起動スクリプトを
書いたり、supervisordを使用する等の方法が必要になるかと思います。dockerコンテナと
して使用する方法もオススメです。(本スライドの付録として最後のページに付いていたりし
ます)
consulプロセスの停止はデフォルト設定ではSIGINTで停止される事を想定しています。今回
の説明にあった nohup と & を使った起動の場合等に注意がいります。お試し目的で nohup
と & を使用しないでそのまま起動した場合等はCtrl+C等で停止しましょう。
今大体こんな感じ(apache除く)(この図3回目ですが一応) ※色々省略してます
node01.example.jp
IP:192.168.20.21
consul server 01
node04.example.jp
IP:192.168.20.41
consul client 01
apach01
node02.example.jp
IP:192.168.20.22
consul server 02
node03.example.jp
IP:192.168.20.23
consul server 03
node05.example.jp
IP:192.168.20.42
consul client 02
apach02
consul操作script等
consul操作script等
では実際に使ってみるの巻
== 使ってみよう編 ==
クライアントノードの状態おさらい
1:先程のクライアントノードの起動
○node04.example.jp
#consul agent -data-dir=/root/consul/data -advertise=192.168.20.41 
-join node01.example.jp
○node05.example.jp
#consul agent -data-dir=/root/consul/data -advertise=192.168.20.42 
-join node01.example.jp
これで各ノードはconsulクライアントによってconsulサーバにリンクされた状態になる事に
なります。
さて、この状態で既consulを使用する準備は出来ているので、実際にconsulへの操作や問い
合わせを行う事になるのですが...
またこの図ですが ※色々省略してます
node01.example.jp
IP:192.168.20.21
consul server 01
node04.example.jp
IP:192.168.20.41
consul client 01
apach01
node02.example.jp
IP:192.168.20.22
consul server 02
node03.example.jp
IP:192.168.20.23
consul server 03
node05.example.jp
IP:192.168.20.42
consul client 02
apach02
consul操作script等
consul操作script等
普通この手のクライアントサーバな構
成のものの場合、何かをしたい場合は
サーバに問い合わせるイメージです
が、consulの場合、自身のホストにあ
るconsulクライアントを使用するの
が基本形です。
つまりこの線の部分がconsulへの操作
や問い合わせになります。
またこの図ですが ※色々省略してます
node01.example.jp
IP:192.168.20.21
consul server 01
node04.example.jp
IP:192.168.20.41
consul client 01
apach01
node02.example.jp
IP:192.168.20.22
consul server 02
node03.example.jp
IP:192.168.20.23
consul server 03
node05.example.jp
IP:192.168.20.42
consul client 02
apach02
consul操作script等
consul操作script等
consulクライアントは自身のconsul
クラスタとしてのjoinや通信により、
consulサーバとリンクしている状態
にあります。
つまり、consulクライアントへの操作や問い合わ
せはconsulサーバへ操作や問い合わせをしている
のと同等に近い動作をするようになっています。
この辺りがconsulを使う場合の基本となります。
※必須ではありませんが
つまり俺様専用consul
というやつです。多分。
では使いましょう (consulの操作)
*cli
主にクラスタやノードとしての状態を見たりするのに使います
*DNS (DNS API)
主にサービスの状態を問い合わせるのに使います。
アプリケーション次第では柱ともなる機能です。
*HTTP API
サービスの状態の問い合わせの他、サービスの登録やKVS機能の
使用の他、殆ど全ての役割を担う主たる機能となります。
CLI機能を使ってみる
※一部機能のみ、詳細は公式サイトをご覧ください
現在のクラスタ状態の確認
○とりあえずはcliで現在のクラスタ状態の確認
まずはconsulクライアント/サーバの入っている環境で以下のコマン
ドを入力
#consul members
Node Address Status Type Build Protocol DC
node01.example.jp 192.168.20.21:8301 alive server 0.6.3 2 dc1
node02.example.jp 192.168.20.22:8301 alive server 0.6.3 2 dc1
node03.example.jp 192.168.20.23:8301 alive server 0.6.3 2 dc1
node04.example.jp 192.168.20.41:8301 alive client 0.6.3 2 dc1
node05.example.jp 192.168.20.42:8301 alive client 0.6.3 2 dc1
特に問題なく構築されている場合は以上のような出力となります。先
程までで構築したサーバやクライアントが全て列挙され、ステータス
がaliveとなっていれば問題ありません。
続いてDNSやWebAPIの説明
...の前に
「サービス」の概念
consulは「Service discovery」ソフトウェアですので「サービ
ス」という概念を掴んでおかないと分かり辛いかもしれません。
ちなみにこの間他の人に「サービス」を説明しようとした時、
「サービスという概念をどのように説明したら良いかと言うと"サービ
ス"が最も適切な言葉のような気がするのですよね!」とか口から出て
いました。フィーリングとかで掴んでください的な○投げですね!
一応頑張って説明しますと...
例えばwordpressを用意したとしまして、このwordpressは抽象概念化
しますと「web」という名のサービスと言えるかと思います。これを
もう少し抽象概念化しますと「wordpress」という名のサービスと呼
ぶのがさらに適切な言い方かと考えられます。多分。
「サービス」の概念とconsul
consulではwebやDB等をサービスという概念で登録したり参照したり
します。例えばwordpress等であればフロントエンドであるApacheと
バックエンドであるDBとの組み合わせとなる訳ですが、この場合は
「wordpress」とか「web」とかいう名前でポート80番のサービスとし
て登録/参照を行い、DBは「db」とか「datastor」とかそのような名前
で登録/参照を行ったりする事になります。
これらのサービスがいったいどのような場所で起動しているのかと
か、正常な状態で起動しているのかとか、そのような事を取り扱うの
が、consulの主となる機能の一つという事になります。
なお、consulでクラスタを構築した場合、「consul」という名前の
サービスとしてconsulサーバが自動で登録されていますので、今回
の説明では主にconsulサービスを用いて説明してみます。
DNS機能を使ってみる
※一部機能のみ、詳細は公式サイトをご覧ください
DNSについて
それではDNSを使用してみます。consulにはDNS機能が内蔵されてお
り、主にサービスやノードの情報を参照する為に使用する事ができる
ようになっています。
デフォルト設定ではconsulに登録されている情報は「.consul」とい
うドメインの配下に存在するかのような振舞いをします。また、デ
フォルト設定ではDNS機能はポート8600番で待ち受けていますのでご注
意ください。
DNSについて (node機能)
digコマンドを実行 (クライアントノードで実行)(サーバノードでも可能ですが)
node情報を取得する場合 (ノード名.node.consul)
#dig @localhost -p 8600 node01.example.jp.node.consul
;; ANSWER SECTION:
node01.example.jp.node.consul 0 IN A 192.168.20.21
*@localhost
自分に問い合わせ。
*-p 8600
ポート8600番。
*192.168.20.21
ノードのIPアドレス。
DNSについて (service機能)
digコマンドを実行 (クライアントノードで実行)(サーバノードでも可能ですが)
サービス情報を取得する場合 (サービス名.service.consul)
#dig @localhost -p 8600 consul.service.consul
;; ANSWER SECTION:
consul.service.consul. 0 IN A 192.168.20.21
consul.service.consul. 0 IN A 192.168.20.22
consul.service.consul. 0 IN A 192.168.20.23
*192.168.20.21..192.168.20.23
consulサービス(consulサーバ)は三つ存在する為三つ返って来ている。
DNSについて (service srv機能 ※少し重要な機能)
digコマンドを実行 (クライアントノードで実行)(サーバノードでも可能ですが)
サービス情報(srv)を取得する場合 (サービス名.service.consul)
#dig @localhost -p 8600 consul.service.consul srv
;; ANSWER SECTION:
consul.service.consul. 0 IN SRV 1 1 8300 node01.example.jp.node.dc1.consul.
consul.service.consul. 0 IN SRV 1 1 8300 node02.example.jp.node.dc1.consul.
consul.service.consul. 0 IN SRV 1 1 8300 node03.example.jp.node.dc1.consul.
*srv
digコマンドでDNSのsrvレコードを問い合わせる場合に付加する。
*8300
このサービスが待ち受けているポート番号、consulサーバは8300で利用可能という意味。
*node01.example.jp.node.dc1.consul
このサービスを行っているノード。(デフォルト設定ではdc1というデータセンタに所属する)
DNSについて (service srv機能 ※少し重要な機能)
さて、DNSの三つの機能の説明を書きましたが、srvレコードの問い
合わせ機能は少し重要なので捕捉があります。
前述の問い合わせ結果により、srvレコードを使えば「サービス名」
だけで「consulサービスを利用する為にはどのサーバのどのポート
を使用すれば良いかが分かる」という事になります。また、この三
つの回答はDNSらしくラウンドロビンされた結果となっている為、問い
合わせする度に違う順番で結果が返って来ます。つまり、複数のレプ
リカを持つような冗長化サービスでは適度にバランシングされた接
続先を使用する事が可能という事になります。
また、このSRVレコードですが、consulのヘルスチェック機能を有効
にしていた場合、ヘルスチェックで問題があるサービスは結果から
除外されて返って来ます。冗長化構成にぴったりの機能ですね。
HTTP-API機能を使ってみる
※一部機能のみ、詳細は公式サイトをご覧ください
HTTP-APIについて
それではHTTP-APIを使用してみます。consulにはHTTP-API機能が内蔵
されており、サービスやノードの情報の参照の他、それらの登録、後
述のKVS機能最小や登録の際にもHTTP-APIを使用します。
また、consul公式配布のプログラミング用ライブラリ(go言語)でも内
部的にはHTTP-APIを使用しておりますので、基本的にconsulを外部か
ら操作する場合はHTTP-APIで行うと思って問題ないかと思います。
なお、デフォルト設定ではHTTP-API機能はポート8500番で待ち受けて
いますのでご注意ください。
HTTP-APIで出来る事
HTTP-APIでは基本的各機能毎にURL的なエンドポイントが分かれてお
り、それらは以下のように区分されて用意されているようです。
*acl - Access Control Lists
*agent - Consul Agent
*catalog - Nodes and services
*coordinate - Network coordinates
*event - User Events
*health - Health checks
*kv - Key/Value store
*query - Prepared Queries
*session - Sessions
*status - Consul system status
HTTP-API (catalog ※後述のagentとの役割の違いに注意がいります)
*ノードの一覧を表示する
#curl http://localhost:8500/v1/catalog/nodes
[{"Node":"node01.example.jp","Address":"192.168.20.21","CreateIndex":3,"ModifyIndex":8},
{"Node":"node02.example.jp","Address":"192.168.20.22","CreateIndex":4,"ModifyIndex":9},
{"Node":"node03.example.jp","Address":"192.168.20.23","CreateIndex":5,"ModifyIndex":10},
{"Node":"node04.example.jp","Address":"192.168.20.41","CreateIndex":6,"ModifyIndex":11},
{"Node":"node05.example.jp","Address":"192.168.20.42","CreateIndex":7,"ModifyIndex":12}]
*ノード個別の情報を表示する
#curl http://localhost:8500/v1/catalog/node/node01.example.jp
{"Node":
{"Node":"node01.example.jp","Address":"192.168.20.21","CreateIndex":3,"ModifyIndex":8},"
Services":{"consul":{"ID":"consul","Service":"consul","Tags":
[],"Address":"","Port":8300,EnableTagOverride":false,"CreateIndex":3,"ModifyIndex":8}}}
HTTP-API (catalog ※後述のagentとの役割の違いに注意がいります)
*サービスの一覧を表示する
#curl http://localhost:8500/v1/catalog/services
{"consul":[]}
*サービス個別の情報を表示する
#curl http://localhost:8500/v1/catalog/service/consul
[{"Node":"node01.example.jp","Address":"192.168.20.21","ServiceID":"consul","ServiceName
":"consul","ServiceTags":
[],"ServiceAddress":"","ServicePort":8300,"ServiceEnableTagOverride":false,"CreateIndex"
:3,"ModifyIndex":6},
{"Node":"node02.example.jp","Address":"192.168.20.22","ServiceID":"consul","ServiceName"
:"consul","ServiceTags":
[],"ServiceAddress":"","ServicePort":8300,"ServiceEnableTagOverride":false,"CreateIndex"
:4,"ModifyIndex":7},
{"Node":"node03.example.jp","Address":"192.168.20.23","ServiceID":"consul","ServiceName"
:"consul","ServiceTags":
[],"ServiceAddress":"","ServicePort":8300,"ServiceEnableTagOverride":false,"CreateIndex"
:5,"ModifyIndex":8}]
HTTP-API (agent ※前述のcatalogとの役割の違いに注意がいります)
*サービスを登録する
HTTPの PUTで http://localhost:8500/v1/agent/service/register に
以下のようなJSONを送信する (下記内容は公式のexampleからのコピペです)
{
"ID": "redis1",
"Name": "redis",
"Tags": [
"master",
"v1"
],
"Address": "127.0.0.1",
"Port": 8000,
"Check": {
"Script": "/usr/local/bin/check_redis.py",
"HTTP": "http://localhost:5000/health",
"Interval": "10s",
"TTL": "15s"
}
}
HTTP-API (kv)
*key value を登録する
#curl -X PUT -d 'value01' http://localhost:8500/v1/kv/key01
true
*key value を取得する
#curl http://localhost:8500/v1/kv/key01
[{"LockIndex":0,"Key":"key01","Flags":0,"Value":"dmFsdWUwMQ==","CreateIndex":1324,"M
odifyIndex":1324}]
HTTP-API機能の10%も
説明出来ていませんがこの位で!
※公式サイトのHTTP-APIの項目はconsulで「出来ること」の一覧とも言えますので是非ご覧に
なってください
WebUIを使ってみる
WebUIの使用
consulには簡易なWebUIもあったりします。
WebUIはconsulのバイナリとは独立して配布されており、別途インス
トールして有効にする必要があったのですが、consulのver0.6.3よ
り、起動時のオプションとして-uiを付ける事により、内蔵のWebUIが
有効になるようになっています。(配布されているものをインストー
ルした場合とほぼ同じ見た目と動作)
なお、WebUIではKVSの操作まで出来てしまいますので、本番環境等で
は何らかの対策が必要となるかもしれませんが、開発中やデバッグ中
は結構便利です。
○起動時に-uiを付ける (なお、接続時はブラウザに http://接続ノード:8500/ui 等でアクセス)
#consul agent [その他のオプション] -ui
WebUIのスクリーンショット
まとめ的なもの
consul の良い所01
既存の物でも出来る事ばかりに見えますが、実際に使ってみると世
代が新しい後発ソフトらしく、従来ではかゆくて手が届かなかった
ような場所に手が届くようになっている気がします。
また、この手のものは設計思想的に運用視点で作成されているのが
普通なのですが、consulの場合はアプリケーション開発の視点的に
欲しいと思うような機能が取り入れられているのもミソかなと思いま
す。
consulを各ノードに入れるによっていわばconsulチャネルで全ノード
をリンクさせているような状態ともなりますので、アプリケーション
的な連携部分にも一役買ってくれます。
クラスタリング対応の部分とconslバイナリ一つにまとまっている
部分もとても良い部分ですね。
consul の良い所02 (かゆいところに手が届く所)
○例えば現在の自身の属するサーバ群の死活状態を知りたい場合
アプリケーション的には「どこか」にその情報を持っていなければ
なりません。そしてその「どこか」を設定ファイルに設定等をしてお
く必要があります。「どこか」のサーバが何かしらの都合で変更にな
る場合は全サーバの設定ファイルを修正しなければなりません。
→consul の場合、設計思想的には「どこか」ではなく
「自身のホスト(localhost,127.0.0.1のconsul)」に
問い合わせるようになっています。
アプリケーション的には「どにあるか」はどうでも良く、何か知らな
くても全サーバ共通の情報が簡単に手に入ればそれがベストです。
consul の良い所03 (かゆいところに手が届く所)
○例えばちょっと複数ノードで情報を共有したい場合
KVS等に保存する?そのKVSも冗長化しなけばなりません。思ったよ
り面倒です。クラスタリングKVSってあまり選択肢がありません。あっ
たとしてもそれなりの規模で運用しなければならないものが多いで
す。アプリケーション的にはjson数個を共有出来れば良いだけなの
に...
→consulが構築してあれば一緒にKVSが付いているので問題無い
アプリケーション的にはクラスタリング済みで冗長化が
担保されているKVSが存在するのは大変素晴らしい事です。
喉から手が出るほど欲しかった人もいるはず。
(速度とか信頼性はほどほどですゆえ過度な期待は禁物ですが)
consul の良い所04 (かゆいところに手が届く所)
○クラスタリングメンバーを追加する(再構築する)
*設定ファイルが/etc/aaa.confで、内部的なデータファイルは
/var/lib/aaa/aaa.dbにあってetc...複雑!
→consulでも本質的には変わらないのですが、
初期状態でバイナリ一つと言うのは思っている以上に
心理的負担が減ります。
例えばクラスタリングノードの一つがダメになったので再構築して再
追加しなければとなった時。consulなら「-data-dir全部消し再起動
してしまえばまあ初期化は何とかなるかなと思えて来ます。
困った時は「リブートしてしまえばanything OK!!」ですね!
次回予告※次回気が向いたらやるかもしれない詳細説明
server node 01 node 01
consul-agent (client)
agent
service 01 (web)
check 01
(chrck http)
apache 01
catalog
node情報
service情報
health
consul-agent (server)
agent
catalog
node情報
service情報
health
kvskvs
consul(service) へのservice登録
consul(kvs) への値登録
※あくまで概念図です。実際の通信はもっと相互に入り組んでいるようです。データ中心の概念図
おまけ
Consul Docker Container
現在consulはdockerの流行と共に発展して行くという戦略にあるよう
に感じます。
実際、最近のconsulの更新ではdocker向け/docker専用の機能が追加
されて来ており、dockerコンテナ内部で動作させる事も考慮された機
能の追加もされて来ています。
しかし、何故かDockerHub上にはHashiCorp社の公式のdockerコンテナ
が存在しないという状態にあるようです。
Consul Docker Container
という訳でコンテナを作成して公開してみました。
https://hub.docker.com/r/masakazuwatanabe/consul/
https://hub.docker.com/r/masakazuwatanabe/consul-client/
https://hub.docker.com/r/masakazuwatanabe/consul-server/
基本的には特別なにかをしているという訳ではなく、起動時の引数を
環境変数経由で与える事が出来るようにしただけの簡潔なものとなっ
ておりますので、お気軽にお試しください。
(HashiCorp社が公式コンテナを出したらいらないんですけどね別に...)

Consulを頑張って理解する