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

第4回 Consulのサービス検出と様々なインターフェース

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

Consulの活用例:DNSインターフェースを通した汎用メンバー管理

Consulが独特なのはDNSのインターフェースを兼ね備えていることです。たとえば,インターネットに出ていないローカル空間における名前解決は,通常内部にDNSサーバを立てたり,あるいは台数が少なければ/etc/hostsを管理します。ところが,クラウド環境やコンテナ・仮想化環境においては,頻繁にホストやコンテナの追加・削除が繰り返されます。

そのような場合,都度DNSサーバの設定を書き換えたり,各サーバのhostsを書き換えたりするのはかなりの手間になります。これをSerfを使って/etc/hostsの書き換えやDNSサーバのゾーンファイルを書き換える方法もありますが,Consulを使えば,Consulのメンバー情報だけでなく,その中のアプリケーションに関する名前解決もできるようになります。

たとえば,単純にホスト名の追加・削除だけであれば,Consulエージェントの追加・削除だけで自動的に名前解決できます。便利なのは,特定のアプリケーションの稼働状況,たとえばポート80番の応答があればWebサーバが稼働しているとみなし,その稼働しているWebサーバの情報で名前解決ができます。

Consulは監視ツールなのでしょうか?

Consulにはクライアントを通して,サーバ内で何のプロセスが稼働しているかや,コマンドラインの実行結果を基に正常か異常かを判断する仕組みがあります。これは以前からある監視ツールとは何が違うのでしょうか?

死活監視を行いますが,これまでの監視ツールとは違ったものと言えます。たとえば,Consulは,Zabbixのようにサーバ内のプロセス稼働状況監視や,コマンドを実行した結果の正常性を評価することはできます。決定的に違うのは,監視の主導権がエージェントにある点です。Zabbixでは通常,監視の主導権はサーバ側にあり,サーバが,クライアントに対して状態を訊ね,その結果をサーバに返します。つまり,サーバが障害で停止したり,経路上のネットワークに問題があると,一次対応コマンドの実行をトリガとするだけでなく,監視そのものが停止してしまいます。

一方のConsulの場合,あくまで監視の主体はクライアント側にあります。何をどのように,どのくらいの時間間隔で監視するかは全てクライアントが決めることです。サーバはあくまでクライアントからの情報を保存しておくための役割と,その結果を返すためのインターフェースを持っているにすぎません。そして,その変化があれば何かアクションを起こし,元の状態に戻そうとします(これは,Consulの中ではアンチエントロピーと呼ばれている機能です)⁠

そしてConsulの大きな特徴の1つであるイベントハンドラは,このクライアントの状況変化をトリガとするだけでなく,KVS上のデータの変化に応じて様々なアクションを起こすような応用に使えます。

まとめ

Consulの概要とSerfの違いは,単純にクライアント・サーバ型の違いだけでなく,機能面でも監視するためのレイヤーが違うことを見てきました。次回はConsulを使ってクラスタを構成し,設定方法や様々なインターフェースの扱い方を見て行きます。

参考資料

著者プロフィール

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

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

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

Twitter:@zembutsu