2016-11-05 13 views
1

I 3(APP-クライアント、APP-A、APP-B)アプリケーションは、桟橋サーバと1つのnginxのロードバランサ(APP-LB)で実行されてきました。すべての(内部または外部の)リクエストはロードバランサを通じてアプリケーションに送られます。 Webコンテキスト(/ app-a /または/ app-b /)の名前に基づいて、LBは要求を正しいアプリケーションに転送します。私はLBで(location/app-a /とlocation/app-bとlocation/app-client)を設定しました。 app-aはapp-bを呼び出し、app-bはapp-aを呼び出し、app-clientは外部から呼び出され、app-clientはapp-aまたはapp-bを呼び出します。ドッカーjwilder/nginxのプロキシ位置設定

私は自分のアプリケーションのためにドッカー・作曲を書かれています。循環依存を避けるために、私はDockerネットを使用しました。それは良い仕事です。私は自分のアプリケーションをスケールアップした場合

。 LBはこの新しいアプリケーションコンテナについて知らない。

チュートリアルはほとんどありませんが、NGINXの代わりにjwilder/nginx-proxyを使用しようとしました。私はそれが設定file.Butの上流更新されVIRTUAL_HOST =アプリ名の変数を使用して、私のアプリケーションは、各container.ifの場所のマッピングに基づいて実行されていることを使用している場合、私は、コンテナを修正するためにリクエストが行くだろうか、指定しないでください。

この設定がコンテナによって動的に更新されたため、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 

答えて

1

仮想パスをサポートするために、nginxのプロキシ画像のためのプル要求(e.g. #599)があります。これを実装するには、元の画像を使用し、独自のnginx.tmplファイルをコンテナに(ボリュームマウントとして、たとえば-v $(pwd)/nginx.tmpl:/app/nginx.tmpl:ro)渡します。次に、コンテナはVIRTUAL_PATHVIRTUAL_HOSTのように定義する必要があります。

私はまた、nginxのプロキシコンテナにDEFAULT_HOSTを設定することはお勧め、あなたがホスト名ベースのルーティングをしたくない場合はそれにすべての人のポイントを持っていると思います。

注意が#599で、私はに走ったnginx.tmplにバグがあります、あなたは{{ range $container := .Containers }}(範囲は.Networksを再定義.を再定義する)前にあることを{{ $networks := .Networks }} 2までのラインを移動する必要があります。そうしないと、すべてのネットワークが到達可能であるとみなされ、nginx-proxyが到達できない他のネットワークにもコンテナが接続されているとタイムアウトになります。

+0

私はdockercloud-haproxy使用することを計画しています。それは仮想パスとホストを持っています。この上に私を提案してください – Gnana

+0

上記の質問は私がここで答えたjwilderのnginxプロキシのためのものでした。私はdockercloud-haproxyのアドバイスはありません。これは別の質問です。 – BMitch

関連する問題