2

3 つの ( app-client,app-a, app-b ) アプリケーションが jetty サーバーと 1 つの NGINX ロード バランサー ( app-lb ) で実行されています。すべての (内部または外部の) 要求は、ロード バランサーを介してアプリケーションに送信されます。Web コンテキスト ( /app-a/ または /app-b/) 名に基づいて、LB は要求を正しいアプリケーションに転送します。LB で (場所 /app-a/ と場所 /app-b と場所 /app-client) を構成しました。app-a は app-b を呼び出し、 app-b は app-a を呼び出し、 app-client は外部から呼び出され、 app-client は app-a または app-b を呼び出します。

アプリケーション用に Docker-composer を作成しました。循環依存を避けるために、Docker net を使用しました。それはうまくいっています。

アプリケーションをスケールアップした場合。LB は、この新しいアプリケーション コンテナーについて知りません。

私はいくつかのチュートリアルを行って、 NGINX の代わりにjwilder/nginx-proxyを使用しようとしました。VIRTUAL_HOST=app-name 変数を使用してそれを使用すると、構成ファイルのアップストリームが更新されます。ただし、アプリケーションは各コンテナーのロケーション マッピングに基づいて実行されます。指定しない場合、要求が正しいコンテナーにどのように送られるか。

この構成はコンテナーによって動的に更新されるため、以下のように LB の default.conf ファイルでロケーション マッピングを指定する方法、または内部呼び出し URL を作成する方法。

   location /app-a {
            proxy_pass http://app-a;
    }
   location /app-client {
            proxy_pass http://app-client;
    }


   location /app-b {
            proxy_pass http://app-b;
    }
Request from outside: http://IP:9090/app-client/
Internal call : http://app-lb:80/app-a/
                http://app-lb:80/app-b

   LB exposed port no is 9090
4

1 に答える 1