2017-04-17 17 views
1

私は、Tomcatサーバーへのシリーズを指すロードバランサ/プロキシサーバーとしてnginxを使用しようとしています。これは私の現在のnginx設定です。それは何の違いになりますが、プロビジョニングはドキュメントが正常に動作している間、正しく解決するために失敗した場合、これはdockerizedさNginxをWebサーブレットのプロキシとして使用する

server { 

    listen 80; 
    server_name _; 
    rewrite^https://$http_host$request_uri? permanent; 
} 

server { 
    listen 443; 

    resolver 127.0.0.11 valid=5s; 

    ssl on; 
    ssl_certificate /etc/nginx/certs/default.crt;  # path to your cacert.pem 
    ssl_certificate_key /etc/nginx/certs/default.key; # path to your privkey.pem 
    ssl_verify_client off; 
    server_name localhost; 
    fastcgi_param HTTPS    on; 
    fastcgi_param HTTP_SCHEME   https; 

    charset utf-8; 
    client_max_body_size 200M; 

    set $app https://app:8443; 
    set $auth https://auth:8443/authentication/; 
    set $discovery https://discovery:8443/discovery/; 

    location/{ 
     proxy_pass $app; 
    } 
    location /authentication { 
     proxy_pass $auth; 
    } 
    location /discovery { 
     proxy_pass $discovery; 
     proxy_set_header Host $http_host; 
     proxy_set_header X_FORWARDED_PROTO https; 
    } 

} 

。ドキュメントとプロビジョニングの唯一の違いは、 'docs'がtomcat経由で純粋なhtmlファイルを提供していることです。 (tomcat7標準/ docs /)、プロビジョニングは実際にはJavaサーブレット(JaxRS/springなど)です。

イメージを直接ヒットした場合、期待どおりに動作しますが、nginx経由で同じエンドポイントにヒットしようとすると解決しません。

参照用に私のドッカーの構成を構成します。

version: '2' 
services: 
    db: 
    image: db:nodata 
    expose: 
    - 5433 
    zk: 
    image: zookeeper 
    ports: 
    - 2181:2181 
    discovery: 
    image: services_discovery:latest 
    env_file: docker_environment 
    expose: 
    - 8443 
    ports: 
    - 8443:8443 
    links: 
    - db 
    - zk 
    app: 
    image: tomcat-jsse-ssl:7-jdk8 
    volumes: 
    - ./app/www/:/usr/local/tomcat7/webapps/ROOT/ 
    expose: 
    - 8443 
    ports: 
    - 8444:8443 
    auth: 
    image: tomcat-jsse-ssl:7-jdk8 
    volumes: 
    - ./authentication/www/authentication/:/usr/local/tomcat7/webapps/authentication/ 
    expose: 
    - 8443 
    proxy: 
    build: ./proxy/ 
    depends_on: 
    - 'auth' 
    - 'app' 
    - 'discovery' 
    ports: 
    - 443:443 
    restart: always 

イメージを実行すると、次のURLを正しく解決できます。

  • https://localhost:8444/
  • すなわちhttps://localhost:8443/discovery/ready

    • 。両方のコンテナがうまく動作しています:

      サーバーログ:

      proxy_1  | 172.20.0.1 - - [24/Apr/2017:00:04:28 +0000] "GET /discovery/ready HTTP/1.1" 404 400 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.133 Safari/537.36" 
      proxy_1  | 172.20.0.1 - - [24/Apr/2017:00:04:43 +0000] "GET /discovery/api/swagger.json HTTP/1.1" 404 400 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.133 Safari/537.36" 
      proxy_1  | 172.20.0.1 - - [24/Apr/2017:00:04:57 +0000] "GET /discovery/ready HTTP/1.1" 404 400 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.133 Safari/537.36" 
      

      ディスカバリーTomcatのアクセスログ(直接アクセス)

      172.20.0.1 - - [23/Apr/2017:00:02:38 +0000] "GET /discovery/ready HTTP/1.1" 200 70 
      172.20.0.2 - - [24/Apr/2017:00:04:28 +0000] "GET /discovery/ HTTP/1.0" 404 949 
      172.20.0.2 - - [24/Apr/2017:00:04:43 +0000] "GET /discovery/ HTTP/1.0" 404 949 
      172.20.0.2 - - [24/Apr/2017:00:04:57 +0000] "GET /discovery/ HTTP/1.0" 404 949 
      

      私がヒットしたときに最初のエントリがありますサーバは直接https://localhost:8443/discovery/ready経由で他のすべて はnginxが要求をサーバーに送信します。何らかの理由で、要求を正しく翻訳していません。

      ご意見/ご感想はありますか?

      注:私はこの質問のために私のexample/configを簡略化しました。そして、 "provisioning"への参照は "discovery"になりました。

      更新:私は「サーブレット」を破壊する理由を知りました。実際には絶え間なく壊れています。ベースを除くすべてのURLを削除しています。

      などです。

      https://localhost/authentication?q=dummy

      172.20.0.3になり - - [24/4月/ 2017:03:22:06 +0000] "GET /認証/ HTTP/1.0" 200 28

      ノートクエリことパラメータが取り除かれます。

    +0

    同じドッカーネットワークにあるコンテナはありますか? – BMitch

    +0

    ええ、同じネットワーク。私はnginxのコンテナに入る場合、私はすべての様々なコンテナを参照してください、私は言ったように、データが静的なHTML/CSSは、それは大丈夫と思われる限りpingすることができます。 – csgeek

    +0

    プロビジョニングコンテナのログにエラーが表示されますか。どのコンテナに404が生成されたのかわかりますか? – BMitch

    答えて

    1

    nginxのドキュメントは、URLを再構築するために責任があると述べている:

    http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_pass

    だから、あなたは正規表現を使用してURIの残りの部分をキャプチャし、proxy_pass部にそれを送信しようとすることができます。

    location ~* ^/discovery/(.*) { 
        proxy_pass $discovery$1$is_args$args; 
        .... other configs.... 
    } 
    
    +0

    これは私のために素晴らしい仕事!ちょっとしたフォローアップの質問。私は(。*)が$ 1にマッピングされると仮定します。私は$ vars定義をhttp://nginx.org/en/docs/http/ngx_http_core_module.htmlから入手しました。何の目的は~~ – csgeek

    +0

    ああ、それを持っています。 〜*は正規表現パターンとしてマークします。ありがとう! – csgeek

    関連する問題