前書き
Consulは、分散型の高可用性、データセンター対応のサービス検出および構成システムです。 これを使用して、クライアントが所属するインフラストラクチャの最新のビューを常に保持できる、柔軟で強力なインターフェイスでサービスとノードを提示できます。
Consulは、インフラストラクチャに関する一貫した利用可能な情報を提供するために使用されるさまざまな機能を提供します。 これには、サービスとノードの検出メカニズム、タグ付けシステム、ヘルスチェック、コンセンサスベースの選択ルーチン、システム全体のキー/値ストレージなどが含まれます。 組織内で領事を活用することにより、アプリケーションやサービスに対する高度な認識を簡単に構築できます。
このガイドでは、consulの使用の基本をいくつか紹介します。 サーバーでconsulを実行してテストするために必要な一般的な手順について説明します。 次のガイドでは、実稼働環境での領事のセットアップに焦点を当てます。
前提条件と目標
このガイドでは、consulを使用してインフラストラクチャのサービス検出と構成のシステムを構築する方法について詳しく説明します。
このデモでは、3つのサーバーと1つのクライアントを構成します。 サーバーは、クエリを処理し、システムの一貫したビューを維持するために使用されます。 クライアントはシステムのメンバーでもあり、サーバーに接続してインフラストラクチャに関する情報を取得できます。 クライアントには、領事によって監視されるサービスも含まれる場合があります。
このガイドおよびこのシリーズ全体の目的のために、4台のコンピューターを構成します。 上記のように、最初の3つはconsul serversになります。 最後のものは、クライアントとして機能し、システムに関する情報を照会するために使用できるconsul agentになります。
後でセキュリティメカニズムの一部を実装するには、単一のドメイン内のすべてのマシンに名前を付ける必要があります。 これは、将来ワイルドカードSSL証明書を活用できるようにするためです。
私たちのマシンの詳細はこちらです:
ホスト名 | IPアドレス | Role |
---|---|---|
server1.example.com |
192.0.2.1 |
ブートストラップ領事サーバー |
server2.example.com |
192.0.2.2 |
領事サーバー |
server3.example.com |
192.0.2.3 |
領事サーバー |
agent1.example.com |
192.0.2.50 |
領事クライアント |
このデモでは64ビットUbuntu 14.04サーバーを使用しますが、最新のLinuxサーバーでも同様に機能するはずです。
Consulのダウンロードとインストール
最初に行う必要があるステップは、各マシンにconsulソフトウェアをダウンロードしてインストールすることです。 上記のマシンのeachに対して、次の手順を実行する必要があります。 ルートとしてログインする必要があります。
領事アプリケーションを調べる前に、実行可能ファイルを抽出するためにunzip
を取得する必要があります。 また、screen
アプリケーションを使用して、単一のターミナルウィンドウで複数のセッションを簡単に実行できるようにします。 通常、consulはサービスとして実行されていないときに画面全体を占有するため、これは導入に役立ちます。
ローカルシステムのパッケージキャッシュを更新してから、apt
を使用してパッケージをインストールします。
apt-get update
apt-get install unzip screen
そのため、後で行うことを忘れないで、今すぐスクリーンセッションを開始してください。
screen
著作権に関するメッセージが表示されたらEnterキーを押します。 ターミナルウィンドウに戻りますが、スクリーンセッション内にいます。
これで、領事プログラムを入手できます。 consul project’s pageは、Windows、OS X、およびLinux用のバイナリパッケージへのダウンロードリンクを提供します。
上記のページに移動し、サーバーを表すオペレーティングシステムとアーキテクチャを右クリックします。 このガイドでは、64ビットサーバーを使用しているため、「linux」の下の「amd64」リンクを使用します。 「リンクの場所をコピー」またはブラウザが提供する同様のオプションを選択します。
ターミナルで、実行可能ファイルを保持する/usr/local/bin
ディレクトリに移動します。 wget
とスペースを入力し、サイトからコピーしたURLを貼り付けます。
cd /usr/local/bin
wget https://dl.bintray.com/mitchellh/consul/0.3.0_linux_amd64.zip
これで、前にインストールしたunzip
コマンドを使用してバイナリパッケージを抽出できます。 その後、圧縮されたファイルを削除できます。
unzip *.zip
rm *.zip
これで、すべてのサーバーでconsul
コマンドを使用できるようになります。
ブートストラップサーバーの起動
consulでの作業を開始するには、consulサーバーを稼働させる必要があります。 推奨されるマルチサーバー環境でこれを構成する場合、このステップは段階的に実行する必要があります。
最初に行う必要があるのは、サーバーの1つで領事プログラムをserver
およびbootstrap
モードで起動することです。 サーバーモードとは、consulがクライアントではなくサーバーインスタンスとして起動することを意味します。 ブートストラップオプションは、最初のサーバーに使用されます。 これにより、選択なしでクラスタの「リーダー」として自分自身を指定することができます(利用可能な唯一のサーバーになるため)。
ホストを指定するテーブルで、server1
をブートストラップサーバーとして指定しました。 server1で、次のように入力してブートストラップインスタンスを開始します。
consul agent -server -bootstrap -data-dir /tmp/consul
サーバーは現在のターミナルで起動し、イベントが発生するとログデータが出力されます。 ログデータの終わりに向かって、次の行が表示されます。
. . .
2014/07/07 14:32:15 [ERR] agent: failed to sync remote state: No cluster leader
2014/07/07 14:32:17 [WARN] raft: Heartbeat timeout reached, starting election
2014/07/07 14:32:17 [INFO] raft: Node at 192.0.2.1:8300 [Candidate] entering Candidate state
2014/07/07 14:32:17 [INFO] raft: Election won. Tally: 1
2014/07/07 14:32:17 [INFO] raft: Node at 192.0.2.1:8300 [Leader] entering Leader state
2014/07/07 14:32:17 [INFO] consul: cluster leadership acquired
2014/07/07 14:32:17 [INFO] consul: New leader elected: server1.example.com
2014/07/07 14:32:17 [INFO] consul: member 'server1.example.com' joined, marking health alive
ご覧のとおり、これは初期ノードであるため、クラスターリーダーは見つかりませんでした。 ただし、ブートストラップオプションを有効にしたため、このサーバーは単一のホストでクラスターを開始するために、単独でリーダー状態に入ることができました。
他のサーバーの起動
server2
とserver3
で、次のように入力して、領事サービスwithoutのブートストラップオプションを開始できます。
consul agent -server -data-dir /tmp/consul
これらのサーバーについては、ログエントリも表示されます。 最後に向かって、次のようなメッセージが表示されます。
. . .
2014/07/07 14:37:25 [ERR] agent: failed to sync remote state: No cluster leader
2014/07/07 14:37:27 [WARN] raft: EnableSingleNode disabled, and no known peers. Aborting election.
2014/07/07 14:37:53 [ERR] agent: failed to sync remote state: No cluster leader
これは、クラスターリーダーが見つからず、リーダー自体になることができないために発生します。 この状態は、2番目と3番目のサーバーが有効になっているが、サーバーがまだ相互に接続されていないために発生します。
相互に接続するには、これらのサーバーを相互に結合する必要があります。 これはどの方向でも実行できますが、最も簡単なのはserver1
マシンからです。
現在のターミナルウィンドウのserver1
で領事サーバーを実行しているため、追加の作業を行うには、screen
で別のターミナルを作成する必要があります。 次のように入力して、server1
の既存の画面セッション内に新しいターミナルウィンドウを作成します。
CTRL-A C
これにより、以前のセッションを実行したまま、新しいターミナルインスタンスが開きます。 次のように入力して、既存の各ターミナルセッションをステップスルーできます。
CTRL-A N
新しいターミナルに戻り、次のようにIPアドレスを参照して他の2つのインスタンスに参加します。
consul join 192.0.2.2 192.0.2.3
これにより、3つすべてのサーバーが即座に同じクラスターに参加します。 次のように入力して、これを再確認できます。
consul members
Node Address Status Type Build Protocol
server1.example.com 192.0.2.1:8301 alive server 0.3.0 2
server2.example.com 192.0.2.2:8301 alive server 0.3.0 2
server3.example.com 192.0.2.3:8301 alive server 0.3.0 2
上記のように画面に新しいターミナルセッションを作成し、同じコマンドを発行することで、他のサーバーからもこの情報を取得できます。
ブートストラップサーバーの削除と通常のサーバーとしての再参加
3つのサーバーすべてをクラスターに参加させましたが、まだ完了していません。
現在、server1
はブートストラップモードで開始されているため、他のサーバーに問い合わせることなく決定を下すことができます。 彼らは平等に動作し、定足数によって決定することになっているので、クラスターがブートストラップされた後にこの特権を削除したいと思います。
これを行うには、server1
で領事サービスを停止する必要があります。 これにより、残りのマシンが新しいリーダーを選択できます。 その後、ブートストラップオプションなしでserver1
でconsulサービスを再起動し、クラスターに再参加できます。
server1で、consulを実行しているターミナルに切り替えます。
CTRL-A N
次のように入力してサービスを停止します。
CTRL-C
次に、ブートストラップオプションなしでサービスを再起動します。
consul agent -server -data-dir /tmp/consul
開いているターミナルに戻り、クラスター内の2つのサーバーのいずれかと接続してクラスターに再参加します。
CTRL-A N
consul join 192.0.2.2
これで、3台のサーバーを同等の状態で使用できるようになります。 それらは互いに情報を複製し、単一のサーバーが利用できなくなった状況を処理します。 ブートストラップなしでサーバーを起動してクラスターに参加するだけで、追加のサーバーもクラスターに参加できるようになりました。
クライアントとしてクラスターに参加し、Web UIを提供する
サーバークラスターが利用可能になったので、クライアントマシンを使用して接続できます。
クライアントコンピューターにconsul Web UIを配置して、クラスターとやり取りし、その状態を監視できるようにします。 これを行うには、visit the download page for the web UI。 ダウンロードボタンを右クリックして、「リンクの場所をコピー」または利用可能な同様のオプションを選択します。
クライアントマシンで、ホームディレクトリに移動します。 wget
とスペースを入力し、ページからコピーしたURLを貼り付けます。
cd ~
wget https://dl.bintray.com/mitchellh/consul/0.3.0_web_ui.zip
ダウンロードが完了したら、アーカイブを解凍して削除します。
unzip *.zip
rm *.zip
領事のWebUIをレンダリングするために必要なすべてのファイルを含むdist
というディレクトリがあります。 クラスターに接続するときにこのディレクトリを指定するだけです。
クラスターに接続するには、サーバーに使用したconsulエージェントへの同様の呼び出しを使用します。 ただし、異なるフラグを使用します。
クライアントモードで操作するため、server
フラグは使用しません。 デフォルトでは、各ノードのクライアントインターフェースはローカルループバックインターフェースを使用してアクセスできます。 ウェブUIにリモートでアクセスするため、代わりにクライアントのパブリックIPアドレスを指定する必要があります。
そのコンテンツを提供するには、Web UIが格納されているディレクトリを領事に示す必要があります。 さらに、クラスター内のいずれかのサーバーのIPアドレスを渡すことにより、クラスターにすぐに参加します。 これにより、後で参加する必要がなくなります。 サーバーの例でもこれを以前に行うことができました。
最終的に、接続コマンドは非常に長くなります。 これは次のようになります。
consul agent -data-dir /tmp/consul -client 192.0.2.50 -ui-dir /home/your_user/dir -join 192.0.2.1
これにより、クライアントマシンが通常の非サーバーエージェントとしてクラスターに接続されます。 このエージェントは、通常の127.0.0.1
インターフェースではなく、パブリックIPアドレスで要求に応答します。 このため、rpc-addr
を指定する領事コマンドにフラグを追加する必要があります。
たとえば、クライアントからメンバーのリストを照会する場合は、選択した別のインターフェースとポートを渡すことでそうする必要があります。
consul members -rpc-addr=192.0.2.50:8400
Node Address Status Type Build Protocol
agent1 192.0.2.50:8301 alive client 0.3.0 2
server2 192.0.2.2:8301 alive server 0.3.0 2
server1 192.0.2.1:8301 alive server 0.3.0 2
server3 192.0.2.3:8301 alive server 0.3.0 2
これは面倒に思えるかもしれませんが、領事のウェブインターフェースにアクセスする機会を提供します。 クライアントのIPアドレスにアクセスし、続いてWebブラウザで:8500/ui
にアクセスすると、Webインターフェイスにアクセスできます。
http://192.0.2.50:8500/ui
メインインターフェイスは次のようになります。
さまざまなメニューをクリックして、インターフェイスを確認できます。 これにより、クラスターとマシンおよびサービスの状態を視覚化するための優れた方法が提供されます。
サービスとチェックの追加
次に、consulにサービスを追加します。これは、これを設定するための主要なユースケースです。 さまざまな方法でサービスを追加できますが、最も簡単なのは、構成ディレクトリを作成してサービス定義を保存することです。
サービスは、サービス定義を含むノードに関連付けられます。 したがって、Webサーバーがある場合は、そのサーバーにconsulエージェントをインストールし、そこにサービス定義ファイルを作成する必要があります。
この目的のために、クライアントにNginxをインストールしてこれを実証します。 次のように入力して、現在のクライアントセッションを強制終了します。
CTRL-C
次のように入力して、クライアントにNginxをインストールします。
apt-get install nginx
これで、サービス定義を保存する構成ディレクトリを作成できます。
mkdir ~/services
このディレクトリ内に、Webサービスを記述するJSONファイルを作成します。 これをweb.json
と呼びます。
nano ~/services/web.json
このファイル内に、サービス定義の構造を含める必要があります。 この構造内で、サービスが正常に実行されているかどうかを確実に判断できるように、サービスのヘルスチェック用の下位構造を定義します。
基本的なアウトラインは次のようになります。
{
"service": {
. . .
"check": {
. . .
}
}
}
サービスの場合、サービスの名前を定義し、チェックするポートをconsulに伝える必要があります。 さらに、独自のソート目的でサービスを任意に分類するために使用できるタグのリストを提供できます。
この例では、これは次のようになります。
{
"service": {
"name": "web server",
"port": 80,
"tags": ["nginx", "demonstration"],
"check": {
. . .
}
}
}
サービス自体を定義するために必要なのはこれだけです。 ただし、consulがサービスの正常性を検証できる方法も定義したいと思います。 これは通常非常に簡単で、通常のシステム管理者の手動チェックを再現します。
私たちのサービスでは、領事プロジェクトがits own documentationにリストされているように、curl
を使用して単純なWebリクエストを実装します。 実際にcurlが取得できるものを知る必要はありません。コマンドがエラーなしで実行できたかどうかのみを考慮します。 このため、出力を破棄できます。
また、チェックを実行する間隔を設定する必要があります。 これは常に、パフォーマンスと最新情報の間の妥協点です。 何かが間違っているかどうかを比較的すぐに知りたいため、10秒を使用します。
{
"service": {
"name": "web server",
"port": 80,
"tags": ["nginx", "demonstration"],
"check": {
"script": "curl localhost:80 > /dev/null 2>&1",
"interval": "10s"
}
}
}
完了したら、ファイルを保存して閉じます。
これで、クライアントのconsulセッションを単純に再起動し、このディレクトリをサービス定義としてポイントできます。
consul agent -data-dir /tmp/consul -client 192.0.2.50 -ui-dir /home/your_user/dist -join 192.0.2.1 -config-dir /home/your_user/services
これにより、ノードが再起動され、クラスターに接続されます。 Webインターフェイスに戻ると、サービスが表示されているはずです。
クライアントに戻って、新しいターミナルを作成し、Webサーバーを一時的に停止できます。
CTRL-A C
service nginx stop
Web UIを更新すると、予想どおりWebサービスのチェックが失敗していることがわかります。
これは、ヘルスチェックが期待どおりに機能していることを示しています。
結論
これで、consulがどのように機能するかについての基本的な考え方が得られました。 このガイドで提供しているデモンストレーションは、実稼働環境で執政官を処理する最良の方法ではありませんが、ソフトウェアの便利な機能をすばやく確認するために使用されました。
next guideでは、本番環境で領事を使用する方法について説明します。 簡単に参照できるように構成の詳細をすべてファイルに入れ、起動時にサービスを開始するための起動スクリプトを作成します。