正式文書のConsulの表示と整理

正式なドキュメントの表示と整理に使用するConsul

1.開始

ダウンロードコンサルティング

問い合わせ.exeのインストール先

へ

conda activate msa(仮想環境駆動)

対応するコマンドで実行

2.サービスの定義

mkdir ./consul.dconfigurationㄴ게

.dは、ディレクトリが一連のconfigファイル

を有することを示す.

サービスを定義するプロファイル

を作成します.

ポート80が「web」というサービス

を返すと仮定する.

consul.dサイトにアクセスします.jsonという名前のファイル

を作成
-->このファイルに名前、ポート、およびオプションが含まれているタグは、サービスを定義するファイルに挿入され、後でサービスを検索するときに使用されます.

echo '{
  "service": {
    "name": "web",
    "tags": [
      "rails"
    ],
    "port": 80
  }
}' > ./consul.d/web.json

作成後にエージェントを再実行

構成ディレクトリを指定し、スクリプトチェックを有効にするには、プロキシがコマンドラインタグを使用する必要があります.

スクリプトチェックは、メルソフトウェアなどのセキュリティ上の問題を引き起こす可能性があるため、-enable-local-script-checksを使用することを強くお勧めします.

.... 頭が回らないので,いつも変なことをしている.

$ consul agent -dev -enable-script-checks -config-dir=./consul.d
==> Starting Consul agent...
           Version: 'v1.5.2'
           Node ID: '82f64bfa-22c2-5727-0f5d-0bae376f6584'
         Node name: 'Judiths-MBP.lan'
        Datacenter: 'dc1' (Segment: '<all>')
            Server: true (Bootstrap: false)
       Client Addr: [127.0.0.1] (HTTP: 8500, HTTPS: -1, gRPC: 8502, DNS: 8600)
      Cluster Addr: 127.0.0.1 (LAN: 8301, WAN: 8302)
           Encrypt: Gossip: false, TLS-Outgoing: false, TLS-Incoming: false, Auto-Encrypt-TLS: false

==> Log data will now stream in as it occurs:

...

2019/07/16 14:09:25 [INFO] agent: Synced service "web"
2019/07/16 14:09:25 [DEBUG] agent: Node info in sync
2019/07/16 14:09:25 [DEBUG] agent: Service "web" in sync
2019/07/16 14:09:25 [DEBUG] agent: Node info in sync

agent: Synced service "web"を見てみましょう.
領事がネットサービスを洗浄したことがわかる.

は、エージェントがプロファイルを介してサービス定義をロードしたことを示し、サービスディレクトリも

に正常に登録する.

ご注意ください

この例では、Webサービスを開始したことがありません.コンサルタントは、まだ開始されていないサービスを登録できます.これは、このサービスのポートに基づいて、登録とともに起動されたサービスに関連付けられています.

の複数のコンサルティングデータセンターにおいて、各サービスはローカルコンサルティングクライアントを登録し、クライアントはサービスディレクトリを含む登録(登録)をコンサルティングサーバに渡す.

クエリー・サービス

エージェントは、マッピングされたサービスディレクトリにサービスを追加すると、DNSインタフェースまたはHTTP APIを使用してサービスを問い合わせることができる.

は、まずConsulのDNSインタフェースを使用してWebサービスを問い合わせる.Consulに登録されているサービスのDNS名はNAME.service.consulです.ここで、NAMEは、登録サービスの名称(本例ではweb)である.デフォルトでは、DNS名はすべてconsulネーミングスペースにありますが、

を構成できます.

Webサービスの標準ドメイン名はweb.service.consulです.登録されたサービスのDNSインタフェースを問い合せます(デフォルトではポート8600で実行されます).

dig @127.0.0.1 -p 8600 web.service.consul

ウィンドウから@および-pを減算し、各ウィンドウ

このように動作する
(今は面倒くさいから全部掘り出して回るつもり)

出力に示すように、返されるAレコードは、登録サービスのIPアドレスを含む.

レコードにはIPアドレスしか格納できません.

チップ

Aレコードは、領事を最小限の構成で起動するため、ローカルホスト(127.0.0.1)に戻ります.

データセンター内の他のノードに意味のあるIPアドレスを提供するには、Commer Agentパラメータ- advertiseまたはaddressフィールドをサービス定義に設定します.

ユーザはまた、DNSインターフェースを使用してSRVレコードを使用してアドレス／ポートペア全体を検索することもできる.

dig @127.0.0.1 -p 8600 web.service.consul SRV

dig 127.0.0.1 8600 web.service.consul SRV

SRVレコードは、80番ポートのJudiths-MBP.lan.node.dc1.consulというノードの上に表示されます.

追加の部分は、DNSおよびAレコードによって返され、このノードのために使用される
最後に、DNSインタフェースを使用して、ユーザはタグフィルタリングサービスを通過することができる.
ラベル・ライブラリのサービス・クエリー・フォーマットはTAG.NAME.service.consulです.

次の例では、すべてのWebサービスの「rails」タブを検索します.

ユーザーがラベル付きWebサービスを登録した場合、成功した応答が得られます.

SRVレコード

SRVレコードは、サービスロケータリソースレコード

である.

単一DNSクエリ操作により、TCP/IPサービスのようなサーバ

を複数台検索する.

レコードを使用して、既知のサーバポートとトランスポートプロトコルタイプのサーバリストをDNSドメイン名の優先順位でソートし、

の管理性を実現

HTTP APIとDNSインタフェースを使用してサービスを問い合わせることができます.