Serf/Consulで管理を自動化! ~実践的な手法を紹介~

第8回(最終回) 定型作業を自動化するConsul Template

この記事を読むのに必要な時間:およそ 4 分

Consul Template

これまでの連載の応用として,最後にConsul Templateをご紹介します。SerfやConsulを使えば,複数台のサーバやLinuxコンテナ上で,様々な処理を同時に行うことができます(イベントハンドラ機能)。実行は任意のタイミングで行えるだけでなく,ノードの増減やサービスの増減に応じて自動的に実行できることが特徴です。

自動実行は,増減のタイミングでコマンドを実行するだけでなく,管理用のファイルやロードバランサ等の設定ファイルを書き換えにも利用できます。通常は,設定を書き換えるためのスクリプトやプログラムを準備する必要がありました。

この設定ファイルの自動書き換えに特化したプログラムがConsul Templateです。その名前の通り,Consulクラスタと連携します。あらかじめテンプレート元になるファイルを用意しておくことで,Consul上でのノード名やIPアドレス等の情報を,自動的に設定ファイルに反映します。それだけでなく,オプションとしてコマンドの実行によるデーモンの再起動を行うことができます。

Consul Templateを活用する事で,たとえば/etc/hostsやAnsibleのインベントリなど,ホスト管理用のファイル書き換えができます。あるいは,NginxやApacheのプロキシ設定を動的に書き換えた後,デーモンの自動再起動も行います。

これは運用担当者にとっては非常に有用な機能です。クラウドのように,動的にIPアドレスが変化する環境でも,設定の追加や削除を正確かつ迅速に行えるようになります。また,開発担当者にとっても,検証環境などで設定変更をしたいとき,その都度自分で作業したり,運用担当とやりとりしたりする手間を軽減できます。

動作原理

Consul Templateはデーモンとしてサーバに常駐し,Consulサーバ上のKVSの情報をローカルまたはリモートから監視します(図1)。Consulノードの状態やサービスの正常性に変化が発生すると,KVSの情報が書き換わります。

Consul TemplateはConsulの持つHTTPインターフェースを経由して,KVSの情報を常時監視しています。Consul TemplateがKVS値の変化を検出すると,テンプレート用ファイルを元に,新しいファイルを自動的に作成します。なお,ノード名やサービス名が変数として定義されている場合,それらもファイルに反映します。

このとき,ファイルを新しく作成だけでなくだけでなく,オプションで任意のコマンド実行もできます。たとえば,設定を反映するためのコマンドや,パーミッションの変更,デーモンの再起動などのコマンドを自動実行させることができます。

図1 Consul TemplateとConsulクラスタの関係

図1 Consul TemplateとConsulクラスタの関係

Consul Templateの利点

Consul Templateの利点の一つは,実行時にバイナリを1つしか必要としないため,起動や各種設定が非常にシンプルに行える点です。Consul TemplateはConsulサーバがローカルでもリモートでも動作するため,Consulエージェントが動いていないサーバ上でも使えます。

また,設定時の確認や動作検証を楽にするため,反映状況を画面に出すだけのドライモードを備えています。その他,デバッグの為の豊富なメッセージ情報の表示や,syslogにログを出力する機能も備えています。

セットアップ方法

consul-templateデーモン

Consul Templateはバイナリやパッケージが提供されていません。そのため,ソースコードを取得して,自分で環境を作ります。以下はLinux(CentOS)上で,Go言語の開発環境を整え,GitHubからソースコードを取得し,バイナリを作成します。

$ sudo yum -y install git golang
$ export GOPATH=/usr/local/src/go
$ git clone https://github.com/hashicorp/consul-template.git
$ cd consul-templae
$ make
$ sudo cp ./bin/consul-template /usr/bin/consul-template
$ consul-template --version
consul-template v0.7.1.dev

Consul環境のセットアップ

Consul Templateを動かす前提として,Consulが動いている必要があります。最低限,1台のConsulサーバ上でノードまたはサービスを認識します。動作にあたって,Consulが動作する環境をお持ちの場合は,そちらを利用することもできます。

ここでは例として,1台のConsulサーバと,2台のConsulクライアントでクラスタを構成します(図2)。ノードは必要に応じて,増減して頂いて構いません。

図2 consul-templateをサーバ上に設定する構成

図2 consul-templateをサーバ上に設定する構成

Consulサーバでは,エージェントをサーバモードとして起動します。

$ consul agent -server -bootstrap-expect=1 -data-dir=/opt/consul/data -bind=192.168.39.3

Consulノードも同様に起動します。このとき-nodeで何らかのノード名称を指定しておきます。

$ consul agent -node=web1 -bind=192.168.39.11 -data-dir=/opt/consul/data -join=192.168.39.3

著者プロフィール

前佛雅人(ぜんぶつまさひと)

クリエーションライン株式会社 Technology Evangelist

ホスティングサービスで運用保守サポートに携わった後,現職へ。サポート業務や新技術検証・開発業務を行う。趣味で監視や自動化に関するOSS検証や翻訳を行うのが好き。辛口の日本酒が大好き。

Twitter:@zembutsu

コメント

コメントの記入