問題タブ [nomad]

nomadを使用して、 gRPCエンドポイントを提供するアプリケーションをタスクとしてデプロイします。その後、タスクはnomad の service stanzaを使用してConsulに登録されます。

アプリケーションのルーティングは、envoy proxyを使用して実現されます。IP で負荷分散された中央の envoy インスタンスを実行しています10.1.2.2。

host現在、ルーティング先のエンドポイント/タスクの決定はヘッダーに基づいており、すべてのタスクは の下にサービスとして登録されています<$JOB>.our.cloud。これは 2 つの問題につながります。

1. サービスにアクセスするときは、ロードバランサー IP の DNS 名を登録する必要があります。これにより、次の/etc/hostsようなエントリが生成されます。

   この問題は を使用することで部分的に軽減されますdnsmasqが、新しいサービスを追加するときはまだ少し面倒です

2. 同じ gRPC サービスを提供する複数のサービスを同時に実行することはできません。たとえば、サービスの新しい実装をテストすることにした場合job、同じ名前で同じサービスを実行する必要があり、gRPC サービス ファイルで定義されているすべてのサービスを実装する必要があります。

私たちが議論してきた可能な解決策はtags、serviceスタンザの を使用して、提供された gRPC サービスを定義するタグを追加することです。

しかし、これはConsulによって推奨されていません:

今、私たちは、のようなタグでそれを行うことを考えていましたgrpc-my-company-firstpackage__ServiceA...これは本当に嫌に見えますが:-(

だから私の質問は：

• 誰かがそのようなことをしたことがありますか？
• その場合、Consul で自動検出される gRPC サービスにルーティングする方法に関する推奨事項は何ですか?
• 誰かがこれについて他のアイデアや洞察を持っていますか?
• これは、たとえばistioでどのように達成されますか?

ハードウェア デバイスでのマイクロサービス オーケストレーションと、そのために存在するより優れたツールセットに関する彼の経験を誰かが共有してくれると助かります。論理的には、クラウドには明確に定義されたアプローチがあり、これらの目的で kubernetes を利用できますが、ハードウェア デバイスへの展開にはいくつかの仕様があります。

そのため、通常のアプリケーションではなく、ハードウェア デバイスの Docker コンテナーを保持する必要があります。また、顧客ごとにハードウェア デバイスの数が異なる可能性があるという問題点が 1 つあります (展開内の 1 人の顧客が 2 台のデバイスを持ち、別の顧客が 3 台、4 台、さらには 5 台のデバイスを所有している可能性があります)。

各ハードウェア デバイスには、複数のコンテナー (5、6) を展開できます。アイデアは、そのような環境でコンテナー オーケストレーションに適したプラットフォームを選択することです。

2 VM の環境では、どのオーケストレーション ツールが優れていますか?

最初に頭に浮かぶプラットフォームは kubernetes ですが、特に 2 つのデバイスへの展開について話している場合は重すぎる可能性があります。

他のオプションは docker swarm ですが、定足数を確保するには、大部分のノードを使用できるようにする必要があります。また、ハードウェア デバイスが 2 つの場合、1 つのデバイスに障害が発生すると、クォーラムのDocker swarm フォールト トレランスがなくなります。

3 番目のオプションは、id nomad + consul であり、別々のアベイラビリティ ゾーンのようにデバイスを構成しますが、誰かがそのような経験をしており、そのようなユース ケースに対してすでに設計上の決定を下しているかどうかに興味があります。

任意の提案をいただければ幸いです。