Consulサーバクラスタ構成手順の歴史 #consul
この記事は1年以上前に投稿されました。情報が古い可能性がありますので、ご注意ください。
Consulとは
Consul とは、米 HashiCorp 社が開発する、サービスの検出と設定を行うための仕組みです。クライアント・サーバ型の構成で動作し、キーバリューストア(KVS) に保持したデータを DNS や HTTP インターフェイスで取得できます。クライアントとサーバはそれぞれがクラスタを構成し、インターネット越しに別々のデータセンターをまたいで接続することもできます。
詳しくは公式サイトのイントロダクションやドキュメントを参照してください。
Consul サーバクラスタ
Consul サーバはクラスタとして動作します。1台でも動作しますが、冗長性・耐障害性を高めるために 3台あるいは 5台での運用が推奨されています(参考: Deployment Table)。
ここでは 3台の Consul サーバによるクラスタを構築することとします。事前に 3台のマシンそれぞれに Consul バイナリをインストールしておきます。Consul バイナリは起動オプションによって、クライアントにもサーバにもなります。
手動ブートストラップ (バージョン 0.4 以上では非推奨)
注意: Consul 0.4 以上では非推奨の手順です。比較のための参考としてください。Manually Bootstrapping を参照して構築していきます。
まず、Consul-1 マシンにて、次のようにして Consul サーバを起動します。consul agent は Consul をエージェントとして、-server オプションによりサーバで、-bootstrap オプションにより「ブートストラップ」モードにて起動します。ブートストラップとは、Consul を最初にデプロイする際に必要な準備を行う動作です。後述しますが、クラスタが構成された後はブートストラップモードで起動する必要はありません。
consul agent -server -bootstrap
ブートストラップモードで起動した Consul サーバは自分自身をクラスタリーダーとして選出します。つまり、他の Consul サーバが存在していなくてもこの 1台だけで Consul サーバクラスタとして動作します。ただし前述の通り、1台では冗長性がないため、ここでは 3台で構成することとします。
次に、Consul-2 マシンにて、次のようにし Consul サーバを起動します。
consul agent -server
これは Consul サーバとして起動しています。しかし、クラスタに参加していないため Consul としてのサービスを行っていません。まず、ブートストラップモードではないため、クラスタリーダーではありません。そして、他の Consul サーバについて知らないため、クラスタを構成することもクラスタに参加することもできません。
そこで、この Consul サーバを動作させたまま、別ターミナルなどから join サブコマンドを実行します。
consul join XXX.XXX.XXX.111
XXX.XXX.XXX.111 は Consul クラスタに所属している Consul-1 の IP アドレスです。このように、クラスタに所属していない Consul サーバに対してクラスタメンバの IP アドレスを教えてやることで、クラスタに所属させて Consul のサービスを行わせることができます。
引き続き、Consul-3 マシンでも Consul サーバを起動します。-join オプションを使えば、後から join サブコマンドを実行する手間が省けます。
consul agent -server -join XXX.XXX.XXX.111
こうして 3台のマシンによる Consul サーバクラスタを構成し、Consul サービスを開始できました。すべての Consul サーバはお互いを監視し、クラスタリーダーである Consul-1 サーバが保持するデータが Consul-2 と Consul-3 に複製されるようになっています。
最後に、Consul-1 の -bootstrap オプションはもう必要ないので、起動オプションから取り除いて再起動します。Consul-1 は -join オプションか join サブコマンドでクラスタメンバーである Consul-2 か Consul-3 を指定し、クラスタに復帰させます。
自動ブートストラップ (バージョン 0.4 以上で推奨)
注意: Consul 0.4 以上で推奨の手順です。Bootstrapping を参照して構築していきます。
まず、Consul-1 マシンにて、次のようにして Consul サーバを起動します。-bootstrap-expect N オプションとは、N 台の Consul サーバによってクラスタを構成するという指定です。ここでは 3台でクラスタを構成するので、-bootstrap-expect 3 と指定します。
consul agent -server -bootstrap-expect 3
まだクラスタには 1台の Consul サーバしか参加していないので、Consul サーバはブートストラップを行いません。クラスタに 3台のサーバが参加した時点で Consul サーバはブートストラップを行い、クラスタリーダーを選出します。手動ブートストラップと比較しての利点は、最初に起動した Consul サーバがブートストラップ済でなくてもよい、ということです。
次に、Consul-2 マシンにて、同様に -bootstrap-expect 3 で起動します。
consul agent -server -bootstrap-expect 3
そして、Consul-2 マシンにて、join サブコマンドで Consul-1 を指定してクラスタに参加します。
consul join XXX.XXX.XXX.111
これでクラスタメンバは 2台となりました。指定の 3台になっていないので、このクラスタはまだブートストラップを行っておらず、Consul サービスも提供していません。
最後に、Consul-3 マシンにて、やはり -bootstrap-expect 3 で起動し、join サブコマンドで Consul-1 を指定してクラスタに参加します。Consul-2 を指定してもかまいません。
consul agent -server -bootstrap-expect 3
consul join XXX.XXX.XXX.111
これでクラスタメンバは指定の 3台となったので、ブートストラップを開始し、クラスタリーダーを選出します。以降、このクラスタは Consul サービスを開始します。
Atlas を利用した自動クラスタ構成 (バージョン 0.5 以上が必要)
さて、ここまで見てきた手動ブートストラップと自動ブートストラップでは、結局のところ参加するクラスタメンバの IP アドレスを知っていなければいけませんでした。これを解決するために、Consul 0.5 から Auto-Join という機能が追加されました。これは HashiCorp 社が提供するさまざまなツールを統合したインフラ管理サービスである Atlas の機能を利用しています。Consul サーバは API を通じて Atlas のサービスに問い合わせを行い、参加すべきクラスタを知ることができます。
Auto-Join を利用するには、Atlas のアカウントと API トークンが必要になります。2015年 6月現在、この機能は無料で利用できます。以下、手順を簡単に紹介します。Atlas のアカウントの作成は Atlas のトップページにある「Sign Up & Tutorial」から行えます。アカウントが取得できたら、Atlas にログインし、アカウントの「Setting」から「Tokens」に行き、適当なトークンの名前をつけて「Generate Token」ボタンで API トークンを生成します。生成した API トークンは二度と再表示されないので、大切に保管してください。
Atlas の API トークンが入手できたら、Consul クラスタの構成に取りかかります。先の自動ブートストラップ用のオプション -bootstrap-expect N に加えて、Atlas の Auto-Join を有効にするための -atlas-join オプションを付与、-atlas=X オプションにて適当な Atlas インフラの名前を指定、-atlas-token=Y オプションにて Atlas の API トークンを指定します。-atlas-token オプションでコマンドライン指定する代わりに環境変数 ATLAS_TOKEN で API トークンを渡すこともできます。Consul サーバはすべて次のように起動します。
consul agent -server -bootstrap-expect 3 -atlas-join -atlas=consul/test -atlas-token=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
まず Consul-1 で Consul サーバを起動します。
クラスタメンバは 1台だけなので、まだブートストラップを行いません。
次に Consul-2 で Consul サーバを起動します。
Consul-2 は Atlas に問い合わせ、クラスタメンバである Consul-1 を教えてもらい、ピアリングします。まだクラスタメンバが 2台なので、ブートストラップは行いません。
最後に Consul-3 で Consul サーバを起動します。
Consul-3 は Atlas に問い合わせ、クラスタメンバである Consul-1 または Consul-2 を教えてもらい、ピアリングします。これでクラスタメンバが指定の 3台となったので、ブートストラップを開始し、クラスタリーダーを選出します。以降、このクラスタは Consul サービスを開始します。
まとめ
Consul 0.4 以前、0.4 以後、0.5 以後と、Consul サーバクラスタの構成手順の変遷を見てきました。Consul はサーバクラスタをどのように構成しているのか、サーバクラスタを構成する際のコマンドラインオプションはどのような意味か、簡単ながら理解の一助となったと思います。少なくとも手動ブートストラップ手順は今後は使わず、自動ブートストラップで IP アドレス指定を行うか Atlas との連携を行うかは環境次第となるでしょう。
参考文献
Author
Chef・Docker・Mirantis製品などの技術要素に加えて、会議の進め方・文章の書き方などの業務改善にも取り組んでいます。「Chef活用ガイド」共著のほか、Debian Official Developerもやっています。
