エージェントの領事クラスターを見つける

Question

3ノードの領事クラスターを構築しました。今はIPアドレスでしか表現されていません。ドキュメンテーションを読む際に、どのように自分の位置をクエリしたい他の人に公開するかは、私には不明です。

現在のリーダーのIPアドレスを他のエージェントにハードコードすることはできますが、それはベストプラクティスのようには思えません。私は各ノードにDNS名を割り当てることができましたが、ネットワーク上の問題のためにリーダーが変わるとどうなりますか？問題ありますか？どのノードにクエリ/書き込みを行うかは重要ですか？

私はクラスタ設定のこの部分を説明していないと思います。領事クラスターを照会する必要のある新しいシステムを立ち上げると、自動的に領事クラスターの所在を知ることができます。

Answer 1

クライアントはその逆のマスターを接続しないようにする必要があるという事実からの脱出はありません。

あなたは、クラスタ全体のブートプロセスを自動化したい場合は、いくつかのオプションがあります。

1. あなたは、ハードマスターのアドレスをコーディングすることができます - 静的アドレスを使用する必要があります（クライアントは、動的IPを持つことができますアドレス）。これは、前提条件またはクラウド環境でも実行できます。たとえば、AWS VPCドキュメントを探します。これが最も簡単なアプローチです。

2. 最初にマスターを起動することができます。クライアントが起動するたびに、マスターのIPアドレスを提供することができます。クラウドでは、これは、例えばユーザデータを使用して自動化することができる。これは、たとえば、IT自動化ツールで自動化することもできます。 ブート時にクライアントの設定を編集する必要があるため、ブートプロセスを少し変更する必要がありますが、ハードコードアドレスに制限されることはありません。この方法を使用すると、一連の作業がすぐに実行できるため、クラスタの起動時間が遅くなる可能性があります。しかし、十分に努力すれば、これを避けることができます（すべてのクラスタを起動し、マスターIPアドレスを実行時にクライアントに渡してクライアントの領事プロセスを開始する方法を見つける）。

もっともエレガントなのは＃1だと思いますが、これは必要に応じて決まります。

いずれにしても、クラスタの開始後にマスターのIPアドレスが変更されないようにしてください。再起動してもこれは悪い習慣です。

また、高可用性のために3つのIPアドレスをすべてクライアントに渡すことをお勧めします（3つのマスター構成を選択した場合）。

Answer 2

documentationによると -

「クラスタに参加するには、領事エージェントはたったの約1既存のメンバーを学ぶ必要があるクラスタに参加した後、エージェントはフルメンバーシップ情報を伝播するために互いにゴシップ。。」

だから、あなたの場合には、単にクライアントの設定にstart_joinリストにあなたのマスターのIPアドレスをハードコード：

{ 
    "server": false, 
    "data_dir": "/var/consul", 
    ... 
    "start_join": ["192.0.x.y1", "192.0.x.y2", "192.0.x.y3"] 
}