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

Copyright © 2015 TIS Inc. All rights reserved. 6

どういう用途に使えるのか

環境の変化に合わせた自律的な設定変更▶ 従来の運用では、システム構成の変更や障害時の対応は人が対応▶ クラウドの普及により、システム構成変更の頻度は増加

必要になったらサーバ数を増やし、必要なくなれば減らすことが当たり前にこの増減の度に人が設定を変更すると品質が一定にならず、ボトルネックに

▶ ある程度の定型作業であれば、自動的に環境の変化を検出して自律的に設定内容を変更して欲しい監視サーバの監視対象を追加したり、ロードバランサーに登録したり

▶ Consul を使うと Service Discovery により、各サーバで稼動している Service を把握 Health Checking により、各サーバの状態や Service の死活状況を検出し、

自動的に設定更新用のスクリプトなどを実行可能


どういう用途に使えるのか

システム内の各サーバ間での情報共有▶ 従来の運用では、他のサーバの情報は静的に与えられる

AP が DB に接続するためには、 DB がどこにいるか設定しなければならない設定した内容に変化があると、その都度設定を更新しなければならない

更新できなければ障害となる

▶ Consul を使うと DNS 機能を利用すれば、目的の Service を提供しているサーバの IP を動的に

取得できる Consul の Health Check に失敗したサーバは自動的に除外可能 Tag を活用すれば、 DB の Master だけを取得するといったことも可能

KVS 機能を利用すれば、複数のサーバ間で任意の情報の共有が可能現在設定されているパラメータの情報など


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

https://www.consul.io/

https://www.consul.io/


本日のハンズオン環境について

操作端末▶ 各席に備え付けの 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

https://dl.bintray.com/mitchellh/consul/0.5.2_web_ui.zip


基本操作編 : 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

http://localhost:8500/v1/catalog/services

http://localhost:8500/v1/catalog/service/sshd


基本操作編 : 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

https://www.consul.io/downloads_tools.html


基本操作編 : 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 も更新されます▶ 試しに皆で参加離脱してみてください･

$ 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 / acknowledged33


応用編 : 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

http://cloudconductor.org/

https://github.com/cloudconductor/


活用事例 : 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 を用いたオーケストレーションの概要

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

http://techcircle.connpass.com/

http://techcircle.connpass.com/

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

Engineering