Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie Consulを頑張って理解する
Ähnlich wie Consulを頑張って理解する (20)
Consulを頑張って理解する
- 1. 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
- 2. Q：Consul て何ですか？ A：HashiCorp社が開発しているサービス管理ツール的なもの 公式サイトは https://www.consul.io/ です。 公式サイトトップページいわく >Service discovery and configuration made easy. >Distributed, highly available, and datacenter-aware. サービス検出や設定を簡単に出来るようにするものです。 分散、高可用性、そしてデータセンターを意識して作られています。 とりあえずは基本情報から...
- 4. 操作とかは... ○参照、操作の為のAPIインターフェースとしては *cli (コマンドラインインターフェース) *DNS (DNS API) *HTTP API 等が用意されている。
- 6. インストールとかは... *サーバは3台、または5台が必要となる(それ以上はそんなに効率出ないらしい) *サーバ、クライアント共に共通の consul というバイナリ一つで動作する (go言語製) つまりインストール自体は簡単! 少なくとも大量のモジュールやインストーラを 気にしないで済む分楽に感じる!(多分) サーバが3台いる部分はネックとなる場合もありますが、 そもそも冗長化が必要となる部分で用いるものなので、 きっとなんとかなる...はず。 ※デバッグ目的等の場合は-devオプション使用で1台でも試せます (ver0.6.3以降)(オンメモリ/データ出力無しモード)
- 9. 大雑把な構成イメージ ※色々省略してます 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アプリがサービスとして登 録された事をイベント的に検知 して何かを行う等
- 12. 大雑把な構成イメージ ※色々省略してます 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等
- 13. 構成を踏まえつつインストール ※サーバ/クライアント共通 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
- 15. サーバノードで 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 と 最後の & にてバックグラウンド動作をさせています。
- 16. クライアントノードで 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 と 最後の & にてバックグラウンド動作をさせています。
- 18. 通信関係捕捉 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で使用
- 20. ちなみにもう少しだけ実践的な起動時の引数では... ○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アドレスで後は全台同じ記述
- 21. その他今回は説明の為に割愛している注意事項 詳細説明は別の機会にしようかと思っておりますが、今の段階でも書いておかないと原因不 明で動作しない等あるかもしれないので... consulサーバ3台の場合1台のdownまでは問題無いのですが、2台以上のdownの場合は、 データ保全やスプリットブレイン防止の為等の理由で制限状態（実質停止）になります。 前述の理由等により2台以上停止した場合は同じように起動しようとしても、 そのままでは 起動出来無い場合があります。その場合は-data-dirで指定したディレクトリを全台削除す ればデータは全て消えますが取り敢えず起動可能な状態になります。復旧の仕方等は別の機 会に... consulはフロントエンド起動しますのでデーモン的に動作させる場合は起動スクリプトを 書いたり、supervisordを使用する等の方法が必要になるかと思います。dockerコンテナと して使用する方法もオススメです。(本スライドの付録として最後のページに付いていたりし ます) consulプロセスの停止はデフォルト設定ではSIGINTで停止される事を想定しています。今回 の説明にあった nohup と & を使った起動の場合等に注意がいります。お試し目的で nohup と & を使用しないでそのまま起動した場合等はCtrl+C等で停止しましょう。
- 22. 今大体こんな感じ(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等
- 24. クライアントノードの状態おさらい 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への操作や問い 合わせを行う事になるのですが...
- 25. またこの図ですが ※色々省略してます 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への操作 や問い合わせになります。
- 26. またこの図ですが ※色々省略してます 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を使う場合の基本となります。 ※必須ではありませんが
- 28. では使いましょう (consulの操作) *cli 主にクラスタやノードとしての状態を見たりするのに使います *DNS (DNS API) 主にサービスの状態を問い合わせるのに使います。 アプリケーション次第では柱ともなる機能です。 *HTTP API サービスの状態の問い合わせの他、サービスの登録やKVS機能の 使用の他、殆ど全ての役割を担う主たる機能となります。
- 30. 現在のクラスタ状態の確認 ○とりあえずは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となっていれば問題ありません。
- 36. 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アドレス。
- 37. 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サーバ)は三つ存在する為三つ返って来ている。
- 38. 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というデータセンタに所属する)
- 39. DNSについて (service srv機能 ※少し重要な機能) さて、DNSの三つの機能の説明を書きましたが、srvレコードの問い 合わせ機能は少し重要なので捕捉があります。 前述の問い合わせ結果により、srvレコードを使えば「サービス名」 だけで「consulサービスを利用する為にはどのサーバのどのポート を使用すれば良いかが分かる」という事になります。また、この三 つの回答はDNSらしくラウンドロビンされた結果となっている為、問い 合わせする度に違う順番で結果が返って来ます。つまり、複数のレプ リカを持つような冗長化サービスでは適度にバランシングされた接 続先を使用する事が可能という事になります。 また、このSRVレコードですが、consulのヘルスチェック機能を有効 にしていた場合、ヘルスチェックで問題があるサービスは結果から 除外されて返って来ます。冗長化構成にぴったりの機能ですね。
- 42. 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
- 43. 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}}}
- 44. 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}]
- 45. 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" } }
- 46. 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}]
- 48. WebUIを使ってみる
- 49. WebUIの使用 consulには簡易なWebUIもあったりします。 WebUIはconsulのバイナリとは独立して配布されており、別途インス トールして有効にする必要があったのですが、consulのver0.6.3よ り、起動時のオプションとして-uiを付ける事により、内蔵のWebUIが 有効になるようになっています。（配布されているものをインストー ルした場合とほぼ同じ見た目と動作） なお、WebUIではKVSの操作まで出来てしまいますので、本番環境等で は何らかの対策が必要となるかもしれませんが、開発中やデバッグ中 は結構便利です。 ○起動時に-uiを付ける (なお、接続時はブラウザに http://接続ノード:8500/ui 等でアクセス) #consul agent [その他のオプション] -ui
- 50. WebUIのスクリーンショット
- 51. まとめ的なもの
- 53. consul の良い所02 (かゆいところに手が届く所) ○例えば現在の自身の属するサーバ群の死活状態を知りたい場合 アプリケーション的には「どこか」にその情報を持っていなければ なりません。そしてその「どこか」を設定ファイルに設定等をしてお く必要があります。「どこか」のサーバが何かしらの都合で変更にな る場合は全サーバの設定ファイルを修正しなければなりません。 →consul の場合、設計思想的には「どこか」ではなく 「自身のホスト(localhost,127.0.0.1のconsul)」に 問い合わせるようになっています。 アプリケーション的には「どにあるか」はどうでも良く、何か知らな くても全サーバ共通の情報が簡単に手に入ればそれがベストです。
- 57. 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) への値登録 ※あくまで概念図です。実際の通信はもっと相互に入り組んでいるようです。データ中心の概念図
- 58. おまけ