Consulエントリー04-Consulクラスタ
4217 ワード
私たちはすでに最初のエージェントを起動し、このエージェントにサービスを登録し、クエリーしました.これらは、Consulの使用がどんなに容易であるかを示していますが、Consulの拡張性と製品レベルのサービス発見に使用できるインフラストラクチャが示されていません.このウィザードでは、最初のマルチメンバーの実際のクラスタを構築します.
Consulエージェントが起動すると、他のノードについて何も知りません.個別の分離クラスタです.他のクラスタメンバーを感知するために、エージェントは既存のクラスタに参加する必要があります.既存のクラスタに参加するには、単一の既存のメンバーを知る必要があります.参加すると、エージェントはメンバーをブロードキャストし、クラスタ内の他のメンバーを迅速に発見します.1つのConsulエージェントは、サービスモードで実行されているエージェントだけでなく、他のエージェントに参加することができます.
エージェントの起動
比較的リアルなクラスタをシミュレートするために,Vagrantを介して2つのノードのクラスタを起動する.次に使用するVagrantfileはConsul倉庫demoで見つけることができます.
まず2つのノードを起動します.
システムが利用可能になると、sshでシステムにログインし、クラスタの構成を開始できます.最初のノードにログインし始めました.
以前の例では、*-devフラグを使用して開発サーバを迅速に設定しました.いずれにしても、クラスタの環境では使用できません.-dev*フラグを削除し、指定したクラスタ用フラグに置き換えます.次に、このフラグについて説明します.
各クラスタノードには一意の名前が必要です.デフォルトではConsulはコンピュータのホスト名を使用しますが、-nodeコマンドラインオプションを使用して手動で上書きできます.
バインドアドレスを指定することもできます.Consulはアドレスでリスニングされ、変更アドレスはクラスタ内の他のすべてのノードにアクセスできます.バインドされたアドレスは厳密に必要ではありませんが(Consulはシステム内の最初のプライベートIPをデフォルトでリスニングします)、1つを提供することが望ましいです.1つの本番環境のサービスには通常、複数のネットワークインタフェースがあるので、バインドアドレスを指定すると、Consulを誤ったネットワークインタフェースにバインドしないことが保証されます.
最初のノードは、クラスタ内の唯一のサーバとして使用され、serverモードで実行されることを指定します.
-bootstrap-expectフラグは、Consulサーバに他のサービスノードが参加することを示しています.このフラグの目的は、レプリケーション・ログのブートを、予想されるサービス・ノードが正常に加入するまで遅延させることです.ガイドチュートリアルでは、より多くの情報を参照できます.
最後にconfig-dirを追加し、サービスがどこで見つかるかを指定し、定義をチェックします.
すべてのフラグを指定した後、これらの設定をconsul agengコマンドラインに追加します.
別の端末では、2番目のノードに接続します.
今回,バインディングアドレスは2番目のノードのIPアドレスとする.このノードはConsulのサーバではないので、サーバモードとして起動するように指定しません.
すべてのフラグを指定した後、これらの設定をconsul agengコマンドラインに追加します.
このとき、すでに2つのConsulエージェントが実行されています.1つのサーバと1つのクライアントです.この2つのConsulエージェントは、2つの単一ノードのクラスタである相互に何の感知もありません.consul membersを実行して検証できます.各クラスタには1つのメンバーしか含まれていません.
クラスタへの参加
次に、最初のエージェントに2番目のエージェントを追加し、新しい端末で次のコマンドを実行するように伝えます.
それぞれのエージェントログにログの出力が表示されるはずです.よく見ると、ノードが加わったログ情報が表示されます.consul membersを再実行すると、2つのエージェントが別のノードの存在を感知していることがわかります.
クラスタに参加するには、Consulエージェントが既存のメンバーを知る必要があることを覚えておいてください.指定したクラスタに参加すると、各エージェントは互いに完全なメンバー情報を伝播します.
起動時にクラスタを自動的に追加
理想的には、いつ新しいノードがデータセンターに追加されても、手動で操作することなく、Consulクラスタに自動的に追加する必要があります.この目的を達成するために、Atlas by HashiCorpを使用して-atlas-joinフラグを指定できます.次の構成例を示します.
これにはAtlasのユーザー名とtokenが必要です.ここでアカウントを作成し、Consul構成で認証情報を使用してそれぞれの値を置き換えます.これで、Consulエージェントによって起動されたノードがいつ加入しても、構成情報をハードコーディングすることなく、Consulクラスタに自動的に追加されます.
もう1つ選択できるのは、起動時に-joinフラグまたはstart_を使用することです.joinは、クラスタに参加するために既知のConsulエージェントのアドレスを指定します.
クエリーノード
クエリー・サービスのように、ConsulにはAPIユーザーがノード情報をクエリーします.DNSまたはHTTP APIで問い合わせることができます.
DNS APIの場合、名称構造はNAMEである.node.consulまたはNAME.node.DATACENTER.consul. データセンターが削除されると、Consulはローカルデータセンターのみをクエリーします.
たとえば、「agent-one」から、ノード「agent-two」のアドレスを問い合わせることができます.
このノードを検索する能力は、システム管理タスクに非常に役立ちます.例えば、ノードのアドレスが分かった場合、sshを使用してノードにログインすることができ、ノードをConsulクラスタの一部として容易にクエリーすることができる.
クラスタから離れる
指定されたクラスタから離れるために、エージェントを優雅に終了するか(Ctrl-Cを使用する)、エージェントプロセスを強制的に殺すことができます.優雅に離れることで、ノードを離れる状態に変換することができる.他の場合、他のノードはこのノードを検出するのに失敗します.その違いはここで詳しく説明されています.
次のステップ
マルチノードのConsulクラスタが起動し、実行されています.「健康診断」()を通じて、私たちのサービスにより強いロバスト性を持たせましょう.
ここから
Consulエージェントが起動すると、他のノードについて何も知りません.個別の分離クラスタです.他のクラスタメンバーを感知するために、エージェントは既存のクラスタに参加する必要があります.既存のクラスタに参加するには、単一の既存のメンバーを知る必要があります.参加すると、エージェントはメンバーをブロードキャストし、クラスタ内の他のメンバーを迅速に発見します.1つのConsulエージェントは、サービスモードで実行されているエージェントだけでなく、他のエージェントに参加することができます.
エージェントの起動
比較的リアルなクラスタをシミュレートするために,Vagrantを介して2つのノードのクラスタを起動する.次に使用するVagrantfileはConsul倉庫demoで見つけることができます.
まず2つのノードを起動します.
$ vagrant upシステムが利用可能になると、sshでシステムにログインし、クラスタの構成を開始できます.最初のノードにログインし始めました.
$ vagrant ssh n1以前の例では、*-devフラグを使用して開発サーバを迅速に設定しました.いずれにしても、クラスタの環境では使用できません.-dev*フラグを削除し、指定したクラスタ用フラグに置き換えます.次に、このフラグについて説明します.
各クラスタノードには一意の名前が必要です.デフォルトではConsulはコンピュータのホスト名を使用しますが、-nodeコマンドラインオプションを使用して手動で上書きできます.
バインドアドレスを指定することもできます.Consulはアドレスでリスニングされ、変更アドレスはクラスタ内の他のすべてのノードにアクセスできます.バインドされたアドレスは厳密に必要ではありませんが(Consulはシステム内の最初のプライベートIPをデフォルトでリスニングします)、1つを提供することが望ましいです.1つの本番環境のサービスには通常、複数のネットワークインタフェースがあるので、バインドアドレスを指定すると、Consulを誤ったネットワークインタフェースにバインドしないことが保証されます.
最初のノードは、クラスタ内の唯一のサーバとして使用され、serverモードで実行されることを指定します.
-bootstrap-expectフラグは、Consulサーバに他のサービスノードが参加することを示しています.このフラグの目的は、レプリケーション・ログのブートを、予想されるサービス・ノードが正常に加入するまで遅延させることです.ガイドチュートリアルでは、より多くの情報を参照できます.
最後にconfig-dirを追加し、サービスがどこで見つかるかを指定し、定義をチェックします.
すべてのフラグを指定した後、これらの設定をconsul agengコマンドラインに追加します.
vagrant@n1:~$ consul agent -server -bootstrap-expect 1 \
-data-dir /tmp/consul -node=agent-one -bind=172.20.20.10 \
-config-dir /etc/consul.d
...別の端末では、2番目のノードに接続します.
$ vagrant ssh n2今回,バインディングアドレスは2番目のノードのIPアドレスとする.このノードはConsulのサーバではないので、サーバモードとして起動するように指定しません.
すべてのフラグを指定した後、これらの設定をconsul agengコマンドラインに追加します.
vagrant@n2:~$ consul agent -data-dir /tmp/consul -node=agent-two \
-bind=172.20.20.11 -config-dir /etc/consul.d
...このとき、すでに2つのConsulエージェントが実行されています.1つのサーバと1つのクライアントです.この2つのConsulエージェントは、2つの単一ノードのクラスタである相互に何の感知もありません.consul membersを実行して検証できます.各クラスタには1つのメンバーしか含まれていません.
クラスタへの参加
次に、最初のエージェントに2番目のエージェントを追加し、新しい端末で次のコマンドを実行するように伝えます.
$ vagrant ssh n1
...
vagrant@n1:~$ consul join 172.20.20.11
Successfully joined cluster by contacting 1 nodes.それぞれのエージェントログにログの出力が表示されるはずです.よく見ると、ノードが加わったログ情報が表示されます.consul membersを再実行すると、2つのエージェントが別のノードの存在を感知していることがわかります.
vagrant@n2:~$ consul members
Node Address Status Type Build Protocol
agent-two 172.20.20.11:8301 alive client 0.5.0 2
agent-one 172.20.20.10:8301 alive server 0.5.0 2クラスタに参加するには、Consulエージェントが既存のメンバーを知る必要があることを覚えておいてください.指定したクラスタに参加すると、各エージェントは互いに完全なメンバー情報を伝播します.
起動時にクラスタを自動的に追加
理想的には、いつ新しいノードがデータセンターに追加されても、手動で操作することなく、Consulクラスタに自動的に追加する必要があります.この目的を達成するために、Atlas by HashiCorpを使用して-atlas-joinフラグを指定できます.次の構成例を示します.
$ consul agent -atlas-join \
-atlas=ATLAS_USERNAME/infrastructure \
-atlas-token="YOUR_ATLAS_TOKEN"これにはAtlasのユーザー名とtokenが必要です.ここでアカウントを作成し、Consul構成で認証情報を使用してそれぞれの値を置き換えます.これで、Consulエージェントによって起動されたノードがいつ加入しても、構成情報をハードコーディングすることなく、Consulクラスタに自動的に追加されます.
もう1つ選択できるのは、起動時に-joinフラグまたはstart_を使用することです.joinは、クラスタに参加するために既知のConsulエージェントのアドレスを指定します.
クエリーノード
クエリー・サービスのように、ConsulにはAPIユーザーがノード情報をクエリーします.DNSまたはHTTP APIで問い合わせることができます.
DNS APIの場合、名称構造はNAMEである.node.consulまたはNAME.node.DATACENTER.consul. データセンターが削除されると、Consulはローカルデータセンターのみをクエリーします.
たとえば、「agent-one」から、ノード「agent-two」のアドレスを問い合わせることができます.
vagrant@n1:~$ dig @127.0.0.1 -p 8600 agent-two.node.consul
...
;; QUESTION SECTION:
;agent-two.node.consul. IN A
;; ANSWER SECTION:
agent-two.node.consul. 0 IN A 172.20.20.11このノードを検索する能力は、システム管理タスクに非常に役立ちます.例えば、ノードのアドレスが分かった場合、sshを使用してノードにログインすることができ、ノードをConsulクラスタの一部として容易にクエリーすることができる.
クラスタから離れる
指定されたクラスタから離れるために、エージェントを優雅に終了するか(Ctrl-Cを使用する)、エージェントプロセスを強制的に殺すことができます.優雅に離れることで、ノードを離れる状態に変換することができる.他の場合、他のノードはこのノードを検出するのに失敗します.その違いはここで詳しく説明されています.
次のステップ
マルチノードのConsulクラスタが起動し、実行されています.「健康診断」()を通じて、私たちのサービスにより強いロバスト性を持たせましょう.
ここから