Consulによる運用自律化体験ハンズオンとConsul活用事例紹介

Copyright © 2015 TIS Inc. All rights reserved.
Consulによる運用自律化体験ハンズオン
とConsul活用事例紹介
2015年7月26日
TIS株式会社
戦略技術センター
高橋和也
July Tech Festa 2015

目次
 Consulとは
 Consulハンズオン: 基本操作編
 Consulハンズオン: 応用編
 Consulの活用事例
▶ クラウドオーケストレーションツール「CloudConductor」
2

Consulとは？
3

Consulとは
 Hashicorp社が提供するオーケストレーションツール
▶ インフラ運用の自動化・自律化に有用な多数の機能を提供
 ノードやサービスの死活管理
 障害や環境構成の変化に応じた処理の自動実行
 その他KVSやDNSなど
▶ 既存のサーバ上で追加のサービスとして稼動させることで、
サーバ間の情報共有や運用作業の自動化の助けに
▶ Go言語で開発されており、OSを問わずどの環境でもバイナリを
一つ置くだけで実行可能なため、導入が簡単
 2014年4月に提供開始
4

Consulの特徴
 公式サイトでは以下の4つの要素が挙げられています
▶ Service Discovery
 各Nodeで動いているServiceをConsulに登録することで、他のNodeからその状
態を確認したり、DNS機能を通じてServiceを提供するIP一覧を取得できます
▶ Health Checking
 クラスタ内のNodeの障害やConsulに登録されたServiceの障害を検知し、自動
的にその状況に応じた処理を呼び出すことができます
▶ Key/Value Store
 Consulのクラスタ内でデータが同期されるため、特別な設定無しで各サーバが
簡単に高い可用性を持つKVSとしても利用可能になります
▶ Multi Datacenter
 一つのデータセンター内でクラスタを自由にスケールさせられるだけでなく、
複数のデータセンターのクラスタを結合して管理することができます
5

どういう用途に使えるのか
 環境の変化に合わせた自律的な設定変更
▶ 従来の運用では、システム構成の変更や障害時の対応は人が対応
▶ クラウドの普及により、システム構成変更の頻度は増加
 必要になったらサーバ数を増やし、必要なくなれば減らすことが当たり前に
 この増減の度に人が設定を変更すると品質が一定にならず、ボトルネックに
▶ ある程度の定型作業であれば、自動的に環境の変化を検出して
自律的に設定内容を変更して欲しい
 監視サーバの監視対象を追加したり、ロードバランサーに登録したり
▶ Consulを使うと
 Service Discoveryにより、各サーバで稼動しているServiceを把握
 Health Checkingにより、各サーバの状態やServiceの死活状況を検出し、
自動的に設定更新用のスクリプトなどを実行可能
6

どういう用途に使えるのか
 システム内の各サーバ間での情報共有
▶ 従来の運用では、他のサーバの情報は静的に与えられる
 APがDBに接続するためには、DBがどこにいるか設定しなければならない
 設定した内容に変化があると、その都度設定を更新しなければならない
 更新できなければ障害となる
▶ Consulを使うと
 DNS機能を利用すれば、目的のServiceを提供しているサーバのIPを動的に取得
できる
 ConsulのHealth Checkに失敗したサーバは自動的に除外可能
 Tagを活用すれば、DBのMasterだけを取得するといったことも可能
 KVS機能を利用すれば、複数のサーバ間で任意の情報の共有が可能
 現在設定されているパラメータの情報など
7

Consulの基本的な構成
公式サイトより引用 (https://www.consul.io/docs/internals/architecture.html)
 各Node上でagentが稼動
▶ ServerとClientの2種類
▶ Serverの中からLeaderを1台選出
 agent同士はGossipプロトコルを
用いてクラスタを形成
▶ agent同士の通信網を確立し、
情報を共有
 ユーザは最寄のagentを窓口とし
て各種機能を利用
▶ どのagentに聞いても良い
 単一障害点となるエンドポイントが無い
▶ agentがClientモードの場合、裏で
最寄のServerに取り次がれる
 WANをまたぐ別のクラスタとも
接続可能
▶ 今回のハンズオンでは対象外
8

Consulハンズオン
基本操作編
9

本日のハンズオンの範囲
 本日のハンズオンでは以下の機能について紹介します
▶ 前半: 基本操作編
 インストール、起動
 複数Nodeでのクラスタ形成
 Serviceの管理とヘルスチェック
 KVS(Key Value Store)機能
 DNS機能
▶ 後半: 応用編
 Consul Watch & Event
 Consul exec
 他にもロック機構やACLによるアクセス制御など、細かい機能
が色々とあります
▶ 公式サイトのドキュメントは非常に丁寧に書かれているので、
是非目を通してみて下さい
 https://www.consul.io/
10

本日のハンズオン環境について
 操作端末
▶ 各席に備え付けのMacを利用していただけます
▶ SSHとブラウザが利用可能であれば、お持ちのPCを利用して頂い
ても構いません
 構築対象となる環境
▶ AWS EC2の仮想マシンを一人一台ずつ用意しています
 OSはCentOS 7.1です
▶ SSHの接続先情報は各席のメモをご覧下さい
 ハンズオン手順
▶ 手順は以下の記事でも公開しています
 http://qiita.com/kz-takahashi/items/c413df2973accbdcb680
それでは実際に動かしてみましょう
11

基本操作編: 事前準備
 会場備え付けの端末(Mac)からTerminalを起動し、
各席の用紙に記載の接続先情報に従ってSSH接続してください
 もし接続できない方がおられれば、お近くのスタッフまで
お声掛け下さい
$ ssh jtf_handson@(SSH接続先)
12

基本操作編: インストール
 Consulのインストールは非常に簡単です
▶ 必要なファイルは consul という実行ファイル一つだけです
 環境にあったファイルを一つダウンロードして解凍するだけで動きます
▶ 今回は合わせてデータを置くディレクトリやConfigファイルを置
くディレクトリも作成しておきます
$ wget https://dl.bintray.com/mitchellh/consul/0.5.2_linux_amd64.zip
$ sudo unzip 0.5.2_linux_amd64.zip -d /usr/local/bin
$ sudo mkdir /opt/consul
$ sudo chown $(whoami) /opt/consul
$ sudo mkdir /etc/consul.d
13

基本操作編: 起動
 consul agentコマンドを実行することでサービスが起動します
▶ 起動時に指定するオプションは色々とありますが、
まずは1台だけのクラスタを作ってみましょう
 -server: Serverモードで起動
 -bootstrap-expect 1: クラスタ内のノードが1台以上の時Leaderに立候補
 -data-dir: データの格納先ディレクトリを指定
▶ 起動したら、Consulに対してクラスタ内にいるメンバーを問い合
わせてみましょう
$ consul agent -server -bootstrap-expect 1 -data-dir /opt/consul/data >> /tmp/consul.log &
$ consul members
Node Address Status Type Build Protocol DC
ip-10-0-1-191 10.0.1.191:8301 alive server 0.5.2 2 dc1
14

基本操作編: 他のノードへのJoin
 次はもっと大きなクラスタを作ってみましょう
▶ クラスタ内には以下の3種類のノードが存在します
 Leader: クラスタ内のServerから選出された、データの原本を保持する代表
 Server: Leaderのデータを複製して保持し、データに対するリクエストに応答
またLeader不在時にServerの中から新Leaderが選出される
 Client: 自身はデータを保持せず、データに対するリクエストをクラスタ内の
Serverへと仲介
 今稼動しているConsulを一度停止し、ハンズオン参加者全員で
一つのクラスタを形成します
▶ -joinオプションでこちらが用意したLeaderを指定します
▶ 以前のクラスタのデータが残っている場合、新しいクラスタに参
加すると様々なエラーが出るため注意が必要です
$ consul leave (現在のクラスタから離脱)
$ rm -rf /opt/consul/data (異なるクラスタに参加する前に以前のクラスタのデータを削除)
$ consul agent -data-dir /opt/consul/data -join leader.jtf.cloudconductor.jp >>
/tmp/consul.log &
15

基本操作編: Configファイルの利用
 起動時のオプションが増えると、都度指定するのは面倒です
 もちろんConsulもConfigファイルから設定を読み込んで起動す
ることができます
$ consul leave
$ sudo vi /etc/consul.d/client.json
{
"data_dir": "/opt/consul/data",
"start_join": ["leader.jtf.cloudconductor.jp"]
}
$ consul agent -config-dir /etc/consul.d >> /tmp/consul.log &
16

基本操作編: Web-UIの利用
 ConsulにはWeb-UIも用意されています
 Web-UIに必要なファイルは同梱されていないので、
利用する場合は別途ダウンロードが必要です
▶ Web-UIを外部に公開するノードにだけ導入されていれば
クラスタ内の全ノードの情報が確認できます
▶ 標準設定の場合 http://(SSHホスト名):8500/ui でアクセス可能
です
 このポート番号は後で説明するREST APIと共用されています$ wget https://dl.bintray.com/mitchellh/consul/0.5.2_web_ui.zip
$ unzip 0.5.2_web_ui.zip -d /opt/consul
$ sudo vi /etc/consul.d/web_ui.json
{
"ui_dir": "/opt/consul/dist",
"addresses": { "http": "0.0.0.0" }
}
$ consul leave
17

基本操作編: Serviceの管理とヘルスチェック
 Serviceの登録
▶ Configファイルにサービスの情報とヘルスチェックの条件を記載
することで、起動時にサービスの登録が行えます
▶ もしくはHTTP API経由で動的に登録することも可能です
 スクリプト等から動的に制御する場合に有用です
$ cat <<EOF | sudo tee /etc/consul.d/services.json > /dev/null
{
"services": [{
"id": "sshd-$(hostname)",
"name": "sshd",
"tags" : [],
"checks": [{
"script": "pgrep sshd",
"interval": "10s"
}]
}]
}
EOF
$ consul reload
18

基本操作編: Serviceの管理とヘルスチェック
 Serviceの情報の確認
▶ 現在の状態はWeb-UIから確認できます
▶ もしくはHTTP API経由でも確認できます
$ curl -s http://localhost:8500/v1/catalog/services | jq .
$ curl -s http://localhost:8500/v1/catalog/service/sshd | jq .
19

基本操作編: Key Value Store (KVS)
 KVSとは
▶ Keyとそれに対応するValueを管理するシンプルなデータストア
 RDBのようなテーブル構造やRelationは持たない
 一般的にスケールアウトが容易
 Consulが提供するKVS
▶ Leaderがデータの原本を持ち、全てのServer Nodeに同期
 Leader Nodeに障害が発生しても、過半数のServer Nodeが残っていれば
自動的に新たなLeaderをServerから選出
 クラスタ内のLeaderが不在の場合は利用不可
▶ consul agentが提供するHTTP API経由で読み書き可能
 特定のNodeがEndpointになるわけではなく、全てのAgentがEndpointになれ
るため、障害時も接続先を切り替える必要が無い
20

 KVSに対する操作
▶ 人が参照・更新する場合は、Web-UIから操作するのが簡単です
このタブを選択
21

 KVSに対する操作
▶ プログラムから制御する場合は、HTTP API経由で操作します
 またはコミュニティで作成されている各言語用のSDKを利用します
 https://www.consul.io/downloads_tools.html
▶ 手動でHTTP APIを試す場合は、以下の操作で確認可能です
# $(hostname)/test というKeyに"test_data" というValueを登録
$ curl -X PUT http://localhost:8500/v1/kv/$(hostname)/test -d "test_data"
# $(hostname)/test というKeyの情報を取得し、Valueの所だけ切り出してbase64デコード
$ curl -s http://localhost:8500/v1/kv/$(hostname)/test | jq .[].Value | tr -d '"' | base64 -d
22

基本操作編: DNS
 Consulは分散型の内部DNSとしても利用可能です
▶ クラスタ内の特定Nodeや、特定Serviceを提供するNode群の
IPアドレスをDNSで取得できます
 例: <node_name>.node.dc1.consul
 例: <service_name>.service.dc1.consul
▶ Serviceの場合、HealthCheckに成功したノードのIPアドレスだけ
取得
 障害が発生したノードを自動的にアクセス対象から外せる
▶ KVSと同様に、単一障害点がなく冗長化が可能
 configで再帰問い合わせ先を指定すれば、外部のドメイン名も
名前解決できます
▶ ちょっとした環境なら単体でDNSサーバとしても利用可能
▶ 本番環境では別途dnsmasq等と併用することが推奨されている
23

基本操作編: DNS
 設定
▶ 標準設定の状態で、TCP 8600でサービスが稼動
▶ 外部への再帰問い合わせを行う場合は、問い合わせ先を追加設定
 確認
▶ 一時的に試す場合は、digコマンド等で 127.0.0.1:8600を指定
▶ 実際に利用する際には、dnsmasq等で.consulの問い合わせ先が
Consulになるように設定します
$ sudo vi /etc/consul.d/dns.json
{
"recursors": ["8.8.8.8", "8.8.4.4"]
}
$ consul leave
$ dig @127.0.0.1 -p 8600 $(hostname).node.dc1.consul
$ dig @127.0.0.1 -p 8600 sshd.service.dc1.consul
24

基本操作編
 以上でConsulの基本操作編を終わります
▶ 16:15まで質疑応答タイムとします
▶ 残りの時間で色々な操作を試してみて、わからない所があれば
スタッフに質問してみてください
▶ 一通り触ってみた方は休憩していただいて構いません
▶ 16:15から後半の応用編を開始します
25

Consulハンズオン
応用編
26

応用編: Consul watchを用いた自律的な運用
 Consul Watchはクラスタ内の変化を検出し、自動的に何らか
の処理を行わせることができる機能です
▶ 自律的な運用を行うためには、現在の環境の状態を把握して
適切な処理を自動的に実行する仕組みが必要です
▶ consul watchを用いることで、クラスタ内の様々な変化を検出し
てそれに応じたアクションを自動的に呼び出せます
 例: 新しいノードがクラスタに参加した時に、監視サーバが自動的に新しい
ノードを監視対象に追加
27

 シンプルな例として、sshdのServiceが稼動しているNodeの
情報を/etc/hostsに同期してみましょう
▶ sshdが稼動しているNodeの増減に応じて自動的に更新させます
 ConsulのDNS機能を使えば/etc/hostsを使う必要は無いですが、例として
 こうした処理を簡単に実現するconsul-templateという公式のツールもあります
$ sudo vi /etc/consul.d/watch_nodes.json
{
"watches": [{
"type": "service",
"service": "sshd",
"handler": "/bin/bash -e /opt/consul/update_hosts.sh"
}]
}
$ sudo chmod a+w /etc/hosts
$ sudo cp -a /etc/hosts /etc/hosts.org
$ sudo vi /opt/consul/update_hosts.sh
#!/bin/sh
cp /etc/hosts.org /etc/hosts
curl -s localhost:8500/v1/catalog/service/sshd | jq .[] | jq '.Address + " " + .Node' | tr -d '"' >> /etc/hosts
$ consul reload
28

 登録したWatchの動作確認
▶ 誰かのNodeが参加・離脱すると/etc/hostsも更新されます
▶ 試しに皆で参加･離脱してみてください
29
$ consul leave

応用編: Consul eventを用いたイベント発行
 運用には自律的な対応が望ましいものだけではなく、
ユーザが判断するタイミングで実行したいものも多数あります
▶ backup, restore, restart, etc.
 consul eventを使うと、事前にwatchに登録したスクリプトを
任意のタイミングで実行させることができます
▶ watchのtypeとしてeventを指定
30

 例として、restartイベント受信時にcrondをrestartする
watchを登録してみましょう
▶ 登録方法は先ほどのwatchの場合と同様です
 watchを登録したら実際にイベントを送ってみましょう
▶ cronのログに再起動に関連するログが出ていると思います
$ sudo vi /etc/consul.d/watch_restart.json
{
"watches": [{
"type": "event",
"name": "restart",
"handler": "sudo systemctl restart crond"
}]
}
$ consul reload
$ consul event -name restart -node $(hostname)
$ less /var/log/cron
31

 特定のevent名に対応する処理は同一でなくとも構いません
▶ 例: APサーバがrestartを受け取った場合はtomcatを再起動
▶ 例: DBサーバがrestartを受け取った場合はpostgresqlを再起動
 consul eventは対象のノードを限定することも可能です
▶ -node: 指定した名前のノードのみで実行
▶ -service: 指定した名前のサービスが稼動するノードでのみ実行
▶ -tag: -serviceと併用し、サービスが稼動するノードの内、指定し
たタグを持つノードでのみ実行
32

応用編: Consul execによる任意のコマンド実行
 管理対象のNodeが増えると、一つ一つのNodeにSSH接続して
管理を行うのは大変です
 consul execを使うと、クラスタ内のNodeに対して任意のコマ
ンドを実行し、その出力を得ることができます
▶ 例えば各NodeのOpenSSLのバージョンを確認する場合には
▶ また更新が必要な場合も、全ノードに一度に行えます
$ consul exec openssl version
node1: OpenSSL 1.0.1e-fips 11 Feb 2013
node1:
==> node1: finished with exit code 0
1 / 1 node(s) completed / acknowledged
$ consul exec sudo yum -y update openssl
node1: Updated:
node1: openssl.x86_64 1:1.0.1e-42.el7.9
(略)
==> node1: finished with exit code 0
1 / 1 node(s) completed / acknowledged
33

応用編: Consul execによる任意のコマンド実行
 一方で、任意のコマンドを遠隔から実行できるのは
セキュリティ上問題になる場合もあります。
▶ Configで、consul execの実行を無効にすることもできます
▶ またACLの機能を使って実行を制限することもできます
 今回はACLの詳細については省略します
$ sudo vi /etc/consul.d/disable_exec.json
{
"disable_remote_exec": true
}
34

Consul活用事例紹介
クラウドオーケストレーションツール
CloudConductor
35

活用事例: CloudConductorとは
 アジャイルなシステム構築をサポートするツール
▶ システム構築のノウハウを込めたパターンから、いつでも誰でも
その時点で最適な非機能要件を持ったシステムを簡単に構築
詳しくは公式サイトをご覧下さい: http://cloudconductor.org/
GitHubでソースコードも公開しています: https://github.com/cloudconductor/
36

活用事例: CloudConductorとは
 どんなツール？
▶ 一言で言えば、マルチクラウド対応のAWS OpsWorks
 CloudConductorの特徴
▶ 一定の形式に従って記述された「パターン」をもとに、システム
構築を自動化
 パターンの中にはシステム構成を表すCloudFormationのようなTemplateや、
各種ミドルウェアの導入・設定を自動化するChefなどのスクリプトを内包
 構成管理ツールはChefに限定されず、任意のツールを利用可能
▶ 複数の「パターン」を組み合わせて一つのシステムを構築可能
 Javaアプリケーション用のTomcat Patternと、監視用のZabbix Patternを組み
合わせると、連動して自動的にサーバの監視を開始
▶ 複数のクラウドに対応
 とはいえ現在はまだAWSとOpenStackの2種類。今後さらに拡充予定
▶ Consulを用いてイベントに応じた処理の自動実行を実現
 AWS Opsworksと同様に、setup, configure, deploy等のイベントに対して処
理を行える機構をConsulを用いて実現
37

活用事例: Consulを用いたオーケストレーションの概要
38
Users
指示
Pattern
Consul
Consul
Pattern
Consul
Consul
Pattern Pattern
KVSに
パラメータを登録し
指示に対応する
Eventを発行
Consul Cluster
自身のRoleとEventに
対応した処理を呼出
Consul
Pattern
サーバ増加時には
Watchが検知
サーバのRoleと
Eventに応じた
処理を行う
スクリプトを内包
Eventを伝播
 Consulの持つ以下の機能を用いて情報共有、イベント通知を実施
○ 分散KVSによる情報の共有 → パラメータ共有に利用
○ クラスタ内へのイベントの伝播 → 外部非公開のサーバへの通知に利用
○ イベントに対応したスクリプトの実行 → パターン内の処理呼出に利用
○ 稼動するサービスの管理とヘルスチェック → 稼動させるサービスの管理に利用
○ サービス管理と連動した内部DNS

活用事例: 使用しているConsulの機能
 Consul Watch & Eventを用いた処理の呼び出し
▶ CloudConductorが構築したシステムに対してイベントを発行し、
各Nodeが自身に合った適切な処理を呼び出し
 初期構築時のsetupイベント, configureイベント
 アプリケーションデプロイ時のdeployイベント
 その他ユーザから指示されたイベントの伝達 (backup, restore等)
 KVSによるシステム内の設定情報の共有
▶ ユーザから受け取ったパラメータや、各Nodeの役割などを格納
▶ Eventに応じて呼び出されるスクリプトがKVSの値を参照
 システム内で稼動するServiceの管理
▶ Serviceの状態をConsul経由で確認可能に
▶ Consulから監視情報を取得してZabbixに格納するパターンも
現在作成中
39

活用事例: Consulを活用することで得られたメリット (1/2)
 特定のノードに依存しない自律的な運用の実現
▶ 従来の運用では
 監視サーバが障害を検出して特定のアクションを起こすことはできたが、どの
ノードで何を実行するかの設定が監視サーバに集中
 各サーバの状態が共有されていないため、それぞれのノードが他のサーバの状
態を考慮してアクションを行うことが困難
▶ Consulを使うことで
 特定の変化(Nodeの追加)などが起こった場合に、各ノードが自分が行うべき処
理を判断して自律的に動けるように
 監視サーバであれば、新ノードを監視対象に追加
 ロードバランサーであれば、新ノードをロードバランスの対象に追加
 他のノードの状態を把握した上で適切なアクションが可能に
 現在どのDBサーバがMasterを判別してReplicationを実行
40

活用事例: Consulを活用することで得られたメリット (2/2)
 単一障害点の無いシステム内の情報共有基盤としての活用
▶ Consulを活用することで、情報を集約するサーバを持たずに
システム内で情報共有が可能に
 Consulの管理するNodeやServiceの情報の活用
 KVSにその他のパラメータ等を格納して活用
 クラスタ内でのイベント伝播による外部公開ポートの限定
▶ SSHを経由して各サーバを管理するツールの場合、外部に公開し
ていないサーバを外から運用しようとすると設定が複雑に
 多段SSHを行うことで管理できないことは無いが、細かい設定が必要
▶ Consulの場合、外部に公開されているクラスタ内の1つのサーバ
にイベントを送れば、全てのノードにイベントを伝達可能
 外部に公開されているサーバが複数あれば簡単に冗長化も可能
41

まとめ
 Consulは運用に役立つ多様な機能を持っています
▶ クラスタ内のNodeやServiceの死活監視
▶ 分散KVSによる情報共有
▶ 分散DNSによるクラスタ内のNodeやServiceの名前解決
▶ Watch/Eventを用いた運用作業の自動化、自律化
▶ consul execによるちょっとした運用作業の効率化
▶ その他様々な機能
 OSを問わず簡単に導入できます
▶ バイナリ一つで動きます
 まずは手元の検証環境などに導入してみてはいかがでしょうか
42

宣伝: 技術勉強会 TechCircle
 TechCircleという誰でも参加可能な勉強会を開催しています
▶ 色々な技術の勉強会やハンズオンを不定期に実施しています
▶ 過去のテーマ例
 OpenStack, Vagrant+Docker, SDS, Consul, 機械学習, Ansible, Pepper
 Connpassで情報公開と参加者の募集を行っています
▶ http://techcircle.connpass.com/
▶ 過去の勉強会の資料なども公開していますので是非ご覧下さい
43

Consulによる運用自律化体験ハンズオンとConsul活用事例紹介

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Consulによる運用自律化体験ハンズオンとConsul活用事例紹介

Similar to Consulによる運用自律化体験ハンズオンとConsul活用事例紹介 (20)

More from cloudconductor

More from cloudconductor (15)

Consulによる運用自律化体験ハンズオンとConsul活用事例紹介