私は、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:8443/discovery/ready
- 。両方のコンテナがうまく動作しています:
- https://localhost/は、nginxで動作します。
- https://localhost/authentication/がnginx経由でロードされます。
- https://localhost/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
ノートクエリことパラメータが取り除かれます。
同じドッカーネットワークにあるコンテナはありますか? – BMitch
ええ、同じネットワーク。私はnginxのコンテナに入る場合、私はすべての様々なコンテナを参照してください、私は言ったように、データが静的なHTML/CSSは、それは大丈夫と思われる限りpingすることができます。 – csgeek
プロビジョニングコンテナのログにエラーが表示されますか。どのコンテナに404が生成されたのかわかりますか? – BMitch