Consul.ioパート2

最初の部分では、分散アプリケーションアーキテクチャが私たちにもたらす問題とタスクを詳細に調べました。 これらの問題を解決するために使用できるツールを決定し、プロジェクトの初期段階での発見の重要性に注目しました。 また、検出サービスの実装を検討する上で、Consulをメインアプリケーションとして選択しました。







最後の部分では、ConsulがDNSプロトコルとどのように機能するかを調べ、HTTP APIの基本的なリクエストを分析し、使用できるヘルスチェックの種類を確認し、もちろん、K / Vストレージの用途を確認します。 そして最も重要なことは、実際の機能のいくつかを詳しく見ていくことです。

DNSインターフェイス

Consulは、DNSプロトコルを使用してクエリに応答でき、任意のDNSクライアントをクエリに使用できます。 DNSインターフェイスは、ポート8600のローカルホスト上のコンポーネントで使用できます。Consulへの直接要求に加えて、それをリゾルバとしてシステムに登録し、名前解決に透過的に使用し、すべての外部要求を上流の「本格的な」DNSサーバーにプロキシし、要求を解決することができますプライベートゾーン.consulのみ。

ディレクトリ内に同じ名前で異なるIPアドレスを持つ複数のサービスがある場合にプリミティブDNSバランシングを実装するために、Consulは応答内のIPアドレスをランダムに混合します。

クラスター内でのドメイン名解決の直接要求に加えて、ルックアップもできます。 検索は、サービス（サービス検索）とクラスターのノード（ノード検索）の両方に対して実行できます。

consulクラスター内のDNSクエリ中のドメイン名の形式は厳密に定義されており、変更できません。

クラスターノード

これは、名前でクラスターノードのIPアドレスを返す通常のDNSクエリです（ノード名は、エージェントが-nodeパラメーターを使用して起動するときに設定されます）。 DNSクエリのホスト名形式を検討してください。

[node].node[.datacenter].[domain]

• [ノード]-必須の部分、ノード名。
• .node-ノード検索を行っているという事実へのポインター。
• [.datacenter]-オプションの部分であるデータセンターの名前（「すぐに使用できる」consulは同じクラスター内の複数のデータセンターを検出できます。デフォルトでは、dc1という名前が使用されます。データセンターの名前が指定されない場合、現在のデータセンターが使用されます。リクエストが実行されているエージェントが起動される）。
• 。[ドメイン]-必須の部分、第1レベルのConsulプライベートドメイン。 デフォルトでは.consul
  
  
  
  値を.consul
  
  
  
  ます。

したがって、nodeserviceなどの名前を持つノードのドメイン名は次のようになります。

nodeservice.node.consul.





ご覧のとおり、データセンターの名前はありませんが、名前は次のように構成することもできます。

nodeservice.node.dc1.consul.





同じDC内で同じ名前を持つ複数のノードは許可されません。

サービス

名前でサービスを検索する要求は、クラスターのすべてのノードで実行されます。 ホスト名を解決するリクエストとは異なり、サービスを検索するリクエストにはより多くのオプションがあります。 さらに、実際には、サービスのIPアドレス（つまり、Aレコード）を使用して、SRVレコードの要求を実行し、サービスが実行されているポートを見つけることができます。

これは、 rls



という名前のサービスを実行しているすべてのノードを検索する典型的なクエリのようrls



：

 root@511cdc9dd19b:~# dig @127.0.0.1 -p 8600 rls.service.consul. ; <<>> DiG 9.9.5-3ubuntu0.7-Ubuntu <<>> @127.0.0.1 -p 8600 rls.service.consul. ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26143 ;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;rls.service.consul. IN A ;; ANSWER SECTION: rls.service.consul. 0 IN A 172.17.0.2 rls.service.consul. 0 IN A 172.17.0.3 ;; Query time: 4 msec ;; SERVER: 127.0.0.1#8600(127.0.0.1) ;; WHEN: Thu Feb 18 07:23:00 UTC 2016 ;; MSG SIZE rcvd: 104
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この回答から、クラスター内にrls



という名前のサービスが実行されている2つのノードがあり、Consul DNSインターフェイスがすべてのノードのIPアドレスを返したことがrls



ます。 リクエストを数回繰り返すと、レコードが定期的に場所を変更することがわかります。つまり、最初に見つかったサービスには最初の場所が割り当てられていません。 これは、上で説明した単純なDNSバランシングの例です。

SRVレコードをリクエストする場合、答えは次のようになります。

 root@511cdc9dd19b:/# dig @127.0.0.1 -p 8600 rls.service.consul. SRV ; <<>> DiG 9.9.5-3ubuntu0.7-Ubuntu <<>> @127.0.0.1 -p 8600 rls.service.consul. SRV ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8371 ;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;rls.service.consul. IN SRV ;; ANSWER SECTION: rls.service.consul. 0 IN SRV 1 1 80 agent-two.node.dc1.consul. rls.service.consul. 0 IN SRV 1 1 80 agent-one.node.dc1.consul. ;; ADDITIONAL SECTION: agent-two.node.dc1.consul. 0 IN A 172.17.0.3 agent-one.node.dc1.consul. 0 IN A 172.17.0.2 ;; Query time: 5 msec ;; SERVER: 127.0.0.1#8600(127.0.0.1) ;; WHEN: Thu Feb 18 07:39:22 UTC 2016 ;; MSG SIZE rcvd: 244
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ANSWER SECTION



は、Consulが必要とする形式でノードのドメイン名をリストします（ノードではなく、サービスではないことに注意してください！）そして、要求されたサービスが実行されているポート。 ノード（および、それに応じてサービス）のIPアドレスADDITIONAL SECTION



応答のADDITIONAL SECTION



リストされます。



DNSクエリのサービス名の形式は次のようになります。

[tag.][service].service[.datacenter].[domain]

• [タグ]はオプションの部分です。 タグでサービスをフィルタリングするために使用されます。 同じ名前で異なるタグのサービスがある場合、タグ名を追加すると結果を除外できます。
• [サービス]-必須の部分、サービス名。
• .service-サービス検索を行っているという事実へのポインタ。
• [.datacenter]-オプションの部分、データセンターの名前。
• 。[ドメイン]-必須の部分、第1レベルのConsulプライベートドメイン。

したがって、nginxという名前でwebという名前のタグを持つサービスは、ドメインで表すことができます。

web.nginx.service.consul

RFC-2782に従ってサービスを検索するSRV要求

ドメイン名の「通常の」構成に加えて、SRVレコードの要求を満たすために、より厳格なRFC-2782ルールに従ってドメイン名を構築できます。 名前の形式は次のようになります。

_service._tag.service[.datacenter].[domain]





サービス名とタグには、プレフィックスとしてアンダースコア（_）があります。 （タグの代わりに元のRFCでは、プロトコルの名前を使用する必要があります。これは、要求中の衝突を防ぐために行われます）。

RFC-2782形式の名前を使用する場合、nginxという名前のサービスとwebという名前のタグを持つサービスは次のようになります。

_web._nginx.service.consul







答えは、「単純な」リクエストの場合とまったく同じです。

 root@511cdc9dd19b:/# dig @127.0.0.1 -p 8600 _rls._rails.service.consul. SRV ; <<>> DiG 9.9.5-3ubuntu0.7-Ubuntu <<>> @127.0.0.1 -p 8600 _rls._rails.service.consul. SRV ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26932 ;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;_rls._rails.service.consul. IN SRV ;; ANSWER SECTION: _rls._rails.service.consul. 0 IN SRV 1 1 80 agent-one.node.dc1.consul. _rls._rails.service.consul. 0 IN SRV 1 1 80 agent-two.node.dc1.consul. ;; ADDITIONAL SECTION: agent-one.node.dc1.consul. 0 IN A 172.17.0.2 agent-two.node.dc1.consul. 0 IN A 172.17.0.3 ;; Query time: 6 msec ;; SERVER: 127.0.0.1#8600(127.0.0.1) ;; WHEN: Thu Feb 18 07:52:59 UTC 2016 ;; MSG SIZE rcvd: 268
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

デフォルトでは、Consul内のすべてのドメイン名はTTL = 0になります。つまり、キャッシュされません。 これを覚えておく必要があります。

HTTP API

HTTP REST APIは主要なConsulクラスター管理ツールであり、非常に幅広い機能を提供します。 APIのフレームワーク内では、10個のエンドポイントが実装され、それぞれがConsulの特定の機能面の構成へのアクセスを提供します。 すべてのエドポイントの詳細な説明はConsulのドキュメントにあります。APIの機能を表すために、各エドポイントについて簡単に説明します。

• acl-アクセス制御。
• agent-エージェント管理領事;
• カタログ-クラスターノードとサービスの管理。
• 座標-ネットワーク座標。
• イベント-ユーザーイベント。
• 健康-可用性チェック;
• kv-キー/値ストレージ。
• クエリ-準備されたクエリ。
• セッション-セッション;
• status-システムのステータス。

acl

名前が示すように、aclはConsulサービスのアクセス制御を制御します。 サービス、ノード、ユーザーイベントに関するデータを受信および変更するためのアクセスを制御し、k / v-storageへのアクセスを制御できます。



代理人

ローカルエージェント管理領事。 このエンドポイントで利用可能なすべての操作は、ローカルエージェントデータに影響します。 エージェントの現在の状態、クラスター内での役割に関する情報を取得したり、ローカルサービスの管理にアクセスしたりできます。 ローカルサービスに加えられた変更は、クラスター内のすべてのノードと同期されます。



カタログ

グローバルレジストリ管理領事。 ノードとサービスの操作はここに集中しています。 このエンドポイント内で、サービスを登録および無効化できます。サービスを使用する場合は、 agent



を使用するよりもこのセクションを使用する方が望ましいです。 catalog



作業catalog



より簡単で明確で、 反エントロピーに貢献します。



コーディネートする

Consulは、 ネットワークトモグラフィーを使用してネットワーク座標を計算します。 これらの座標は、クラスター内の効果的なルートと、たとえば、特定のサービスで最も近いノードを見つける、事故の場合に最も近いデータセンターに切り替えるなど、多くの便利な機能を構築するために使用されます。 このセクションのAPI関数は、ネットワーク座標の現在の状態に関する情報を取得するためにのみ使用されます。



出来事

カスタムイベントの処理。 カスタムイベントは、クラスター内で任意のアクションを実行するために使用されます。たとえば、オーケストレーションプロセスの一部として、サービスの自動展開、再起動、特定のスクリプトまたはその他のアクションの実行などです。



健康

ノードおよびサービスの現在のステータスを確認します。 このエンドポイントは読み取り専用であり、ノードとサービスの現在の状態、および実行されたチェックのリストを返します。



kv

このエンドポイントにはメソッドが1つしかなく、Consulが提供する分散キー/値ストレージのデータを管理するために使用されます。 このエンドポイントの唯一のメソッドは次のようになります。

/v1/kv/[key]





処理の違いはリクエストメソッドです。 GETはキーで値を返し、PUTは新しい値を保存するか古い値を上書きし、DELETEはレコードを削除します。



問い合わせ

クエリ管理の準備。 このような要求により、Consulの構成に対して複雑な操作を実行でき、保存して後で実行できます。 保存されたクエリには一意のIDが割り当てられます。 その助けを借りて、何度も準備をすることなく、いつでも要求を満たすことができます。



セッション

Consulセッションエンジンは、分散ロックを構築するために使用されます。 セッションは、チェック対象のノードとk / vストア間の接続層です。 各セッションには名前があり、リポジトリに保存できます。 この名前は、競合モードのノードおよびサービスを使用した順次アクションの一部としてロックを実装するために使用されます。 セッションのメカニズムは、 Consulのドキュメントで説明されています 。



状態

このエンドポイントは、クラスターのステータス情報を取得するために使用されます。 ここでは、現在のリーダーを見つけて、すべてのクラスターメンバーに関する情報を取得できます。

ヘルスチェック

前に、DNSを使用した均一な負荷分散について説明しました。次に、ノードとサービスの状態をチェックするメカニズムを検討します。 ヘルスチェックは定期的に実行される操作であり、その結果により、チェック対象のシステムのステータスを判断できます。 実際、これはクラスターの状態を健全な状態に維持し、アイドル状態のノードとサービスをクリーンアップし、健全性回復の事実に基づいて機能するように戻す自動監視です。 Consulは、いくつかのタイプのチェックをサポートしています。

• スクリプトチェック-指定した頻度で特定のノードで特定のスクリプトを実行します。 終了コードに応じて（ゼロ以外のコードはチェックに合格しなかったことを意味します）、ノードまたはサービスをオンまたはオフにします。
• HTTPチェック-指定されたURLをロードしようとし、応答コードに応じて、チェックされたオブジェクトをオンまたはオフにするチェック（任意の2xx-すべてが正常で、Too Many Requestsコード429が警告を生成し、他のコードはエラーを示します）。
• TCPチェック-指定されたアドレスとポートへの指定された間隔でTCP接続を確立しようとするチェック。 接続の確立の失敗は、テストが失敗したことを意味します。
• TTLチェックは、HTTP APIを介して定期的に更新する必要があるチェックです。 その本質は、特定のサービスが特定の間隔内でこのチェックを更新しなかった場合、アイドルとしてマークされることです。 これはパッシブチェックです。つまり、サービス自体が動作していることを定期的に報告する必要があります。 指定された間隔でレポートが受信されなかった場合、チェックは不合格と見なされます。
• Docker Check-Dockerコンテナで実行されているサービスを確認します。 Consulは、Docker Exec APIを使用して、コンテナ内でスクリプトを実行できます。 チェックの結果は終了コードに依存し、ゼロ以外は失敗します。

K / vストレージ

Consulが提供するストレージは、分散キーと値のデータベースであり、クラスターの任意のメンバーが使用可能なデータを保存するために使用できます（もちろんACLルールに従って）。 サービスは、このストレージに他のクラスターメンバーに必要なデータを保存できます。 これらは、構成オプションの値、いくつかの計算の結果、または上記で示したように、k / vストレージを使用して、セッションメカニズムを使用して分散ロックを実装できます。 k / vストレージを使用すると、クラスターの効率が向上し、手動による介入の割合を減らすことができます。 サービスは、クラスターが保証するストレージ内の情報に応じて、状態を調整できます。 このストレージには、サービスのビジネスロジックに関連するデータを保存しないでください。 Consulが提供するストレージは、クラスターメンバーが処理するデータではなく、クラスターメンバーのステータスに関するメタ情報を保存および配布するために使用されます。

おわりに

大規模なプロジェクトで分散アーキテクチャを構築するプロセスでの発見サービスの役割を過大評価することは困難です。 領事はこの役割に最適です。 この製品は開発されたままであり、多くの有用な機能が実装されています。これは、多数のコンポーネントを備えたシステムの簡単なメンテナンスに必要です。 さらに、ConsulはGoで記述され、単一の実行可能ファイルとして配布されるため、更新とサポートのプロセスが非常に便利になります。