nomadを使用して、 gRPCエンドポイントを提供するアプリケーションをタスクとしてデプロイします。その後、タスクはnomad の service stanzaを使用してConsulに登録されます。
アプリケーションのルーティングは、envoy proxyを使用して実現されます。IP で負荷分散された中央の envoy インスタンスを実行しています10.1.2.2
。
host
現在、ルーティング先のエンドポイント/タスクの決定はヘッダーに基づいており、すべてのタスクは の下にサービスとして登録されています<$JOB>.our.cloud
。これは 2 つの問題につながります。
サービスにアクセスするときは、ロードバランサー IP の DNS 名を登録する必要があります。これにより、次の
/etc/hosts
ようなエントリが生成されます。10.1.2.2 serviceA.our.cloud serviceB.our.cloud serviceC.our.cloud
この問題は を使用することで部分的に軽減されます
dnsmasq
が、新しいサービスを追加するときはまだ少し面倒です同じ gRPC サービスを提供する複数のサービスを同時に実行することはできません。たとえば、サービスの新しい実装をテストすることにした場合
job
、同じ名前で同じサービスを実行する必要があり、gRPC サービス ファイルで定義されているすべてのサービスを実装する必要があります。
私たちが議論してきた可能な解決策はtags
、service
スタンザの を使用して、提供された gRPC サービスを定義するタグを追加することです。
service {
tags = ["grpc-my.company.firstpackage/ServiceA", "grpc-my.company.secondpackage/ServiceB"]
}
しかし、これはConsulによって推奨されていません:
Dots are not supported because Consul internally uses them to delimit service tags.
今、私たちは、のようなタグでそれを行うことを考えていましたgrpc-my-company-firstpackage__ServiceA
...これは本当に嫌に見えますが:-(
だから私の質問は:
- 誰かがそのようなことをしたことがありますか?
- その場合、Consul で自動検出される gRPC サービスにルーティングする方法に関する推奨事項は何ですか?
- 誰かがこれについて他のアイデアや洞察を持っていますか?
- これは、たとえばistioでどのように達成されますか?