web-dev-qa-db-ja.com

外部Docker Swarmクライアントにサービスディスカバリを実装する方法

当社製品の特定のケースについて質問があります。

2つのサービスがあるとしましょう。 Service AおよびService B。 （サービスの数はインストールごとに異なります）。それらはDockerSwarmにデプロイされます。これらはポートを公開しません。つまり、Swarmクラスターの外部からはアクセスできません。そして、Swarmの外部にポートを公開し、リバースプロキシとして使用するNginxコンテナがあります。

Service AとService Bは非常によく似た動作をしますが、どちらが呼び出されるかはクライアントの好み次第です。クライアントが同じエンドポイント（たとえばHTTP POST /some-event）を使用してこれらのサービスにアクセスするだけでなく、リクエストコンテキストに何か特別なものを提供することでサービス（Service AまたはService B）を選択することを望んでいます。

たとえば、Service AとService Bにアクセスできるさらに別のサーバーを実装し、両方のサービスのアクセスキーを作成してデータベースに書き込み、クライアントにアクセスキーを提供することを考えました。この新しいサーバーはHTTP POST /some-eventの唯一の受信者であり、リクエストコンテキスト（ヘッダーなど）で提供されるアクセスキーに応じて、リクエストをService AまたはService Bにルーティングします。車輪を再発明するようなものでした。

Netflix Zuulも調べていますが、このソリューションでは、製品を展開するたびにZuul構成を作成する必要があります（インストールごとに展開するサービスの数によって異なります）。

したがって、問題は次のとおりです。同じリソース/サービスに対して行われたリクエストに対してヘッダーを使用して動的ルーティングを実現する別の方法は何でしょうか？ありがとう！

designarchitecturemicroservicesdocker
4
Hasan Can Saral

私はあなたが私のデザインで説明しているのと同じようなことをします。ドメイン名でルーティングすることで解決しましたが。 Imo、さまざまなサービスをさまざまなドメイン/サブドメインに分散させる必要があります。

ただし、ルーティングにヘッダーを使用するように設定されている場合は、次のようにすることができます。

upstream service1 { server 127.0.1.1:65535; }
upstream service2 { server 127.0.1.2:65535; }

map $http_x_access_key $access_key 
{
  123 "service1";
  456 "service2";
}

server 
{
  listen 80;
  server_name example.com;
  location / 
  {
     proxy_pass http://$access_key;
     # proxy settings
     # ...
  }
}

http://nginx.org/en/docs/http/ngx_http_map_module.html

リクエストを解決するためにdbレイヤーにアクセスする必要がある場合は、これを解決するために独自のリバースプロキシを作成することをお勧めします。ほんの数行でそれを行うことができるはずであり、必要に応じて機能をさらに下流に拡張することができます。

2
superhero