I am trying to setup a basic mockup (for training) with 2 docker containers :
One with nginx
One with jenkins
nginx is used as a reverse container (the next step wil be https frontend).
jenkins is supposed to be publicly accessible as www.devportal.org:90/ci
I have partially succeeds. I mean that I can access it with the given address. But ...
When I try to connect with the admin user, I get the login page. But when filling the user / password, I am redirected to http://www.devportal.org/ci/.
If I add the port to this address, I obtain the instance home page, connected as the admin user.
When I select the manage page, I see a warning message saying that my reverse proxy configuration is broken.
Besides, when going to configure system, the page is displayed but it never finishes loading.
I tried various configuration for nginx, but none of them gave me the correct result.
The Jenkins Location URL is set to the instance address known by nginx.
As far as both are within containers linked to a dedicated docker network where jenkins is known as jenkins_ci, the address is http://jenkins_ci:8080/ci/.
And if I run :
docker exec nginx_revproxy wget http://jenkins_ci:8080/ci/
I actually get the home page.
Here is my nginx configuration (in : /etc/nginx/conf.d/reverse_proxy.conf)
# Reverse proxy configuration for one jenkins server
# Nginx listen public traffic on port 90 and forward to jenkins container address on port 8080
server {
listen 90;
access_log /var/log/nginx/reverse-access.log;
error_log /var/log/nginx/reverse-error.log;
location ^~ /ci/ {
proxy_set_header Host $host:$server_port;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_pass http://jenkins_ci:8080/ci/;
# Fix the "It appears that your reverse proxy set up is broken" error.
proxy_set_header X-Forwarded-Host $host;
proxy_read_timeout 90;
proxy_redirect http://jenkins_ci:8080/ http://www.devportal.org:90/;
# Required for new HTTP-based CLI
proxy_http_version 1.1;
proxy_request_buffering off;
}
}
When getting an error page at connexion I see this on nginx container log
172.17.0.1 - - [19/Jul/2019:12:32:04 +0000] "GET /ci/ HTTP/1.1" 404 153 "http://www.devportal.org:90/ci/login?from=/ci/" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0" "-"
2019/07/19 12:32:04 [error] 7#7: *40 "/usr/share/nginx/html/ci/index.html" is not found (2: No such file or directory), client: 172.17.0.1, server: localhost, request: "GET /ci/ HTTP/1.1", host: "www.devportal.org", referrer: "http://www.devportal.org:90/ci/login?from=/ci/"
On the jenkins container log I also have :
Jul 19, 2019 2:18:25 PM hudson.diagnosis.ReverseProxySetupMonitor getTestForReverseProxySetup
WARNING: http://www.devportal.org/ci/manage vs. http:
Additional information
With nginx conf:
server {
listen 90;
server_name www.devportal.org;
access_log /var/log/nginx/reverse-access.log;
error_log /var/log/nginx/reverse-error.log;
location ~ "^/static/[0-9a-fA-F]{8}\/(.*)$" {
#rewrite all static files into requests to the root
#E.g /static/12345678/css/something.css will become /css/something.css
rewrite "^/static/[0-9a-fA-F]{8}\/(.*)" /$1 last;
}
location /ci/ {
proxy_pass http://jenkins_ci:8080;
proxy_set_header Host $host:$server_port;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
# Fix the "It appears that your reverse proxy set up is broken" error.
proxy_set_header X-Forwarded-Host $host;
proxy_read_timeout 90;
proxy_redirect http://jenkins_ci:8080/ http://www.devportal.org:90/;
# Required for new HTTP-based CLI
proxy_http_version 1.1;
proxy_request_buffering off;
proxy_set_header Connection ""; # Clear for keepalive
}
}
and
<jenkins.model.JenkinsLocationConfiguration>
<adminAddress>[my mail address]</adminAddress>
<jenkinsUrl>http://www.devportal.org:90/ci</jenkinsUrl>
</jenkins.model.JenkinsLocationConfiguration>
in
jenkins.model.JenkinsLocationConfiguration.xml
I make some progress regarding the error message in jenkins log :
Jul 22, 2019 11:59:35 AM hudson.diagnosis.ReverseProxySetupMonitor getTestForReverseProxySetup
WARNING: http://www.devportal.org/ci/manage vs. http://www.devportal.org:90/ci/manage
Now, I only loose the port number (I lost the whole domain name before).
Note that it is the same with or without proxy_redirect.
So Jenkins URL should be set to what your user see as standing in description:
Optionally specify the HTTP address of the Jenkins installation, such as
http://yourhost.yourdomain/jenkins/. This value is used to let Jenkins know how
to refer to itself, ie. to display images or to create links in emails. This is
necessary because Jenkins cannot reliably detect such a URL from within itself
so in your case: http://www.devportal.org:90/
That line should be probably removed as I think it's not needed:
proxy_redirect http://jenkins_ci:8080/ http://www.devportal.org:90/;
And you should remove '/ci' from proxy pass like this
proxy_pass http://jenkins_ci:8080;
Related
I have setup two nginx instances as follows:
nginx (https) → docker:[nginx (http) → uwsgi]
The front facing nginx process exposes the https service, which passes down all requests via proxy_pass to the docker nginx process. It also redirects all requests to http → https.
The problem is that the docker nginx process has the following line in a location block in its default server instance:
server {
...
location = / {
return 301 $scheme://$http_host${request_uri}login/;
}
}
With the intention of redirecting / to the login page. This works fine except that the redirection always points to an http://... url. E.g. A request to http://myserver.com/, gets redirected to https://myserver.com/, then it gets passed down to the docker nginx which returns a 301 with the following url: http://myserver.com/login/. I want it to be https://myserver.com/login/ or whatever schema the front-facing server may offer.
This is how I setup the front-facing nginx process:
server {
listen 443 ssl http2 default_server;
...
location / {
proxy_pass http://localhost:81;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_cache_bypass $http_upgrade;
proxy_redirect https:// http://;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Host $server_name;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Scheme $scheme;
}
}
server {
listen 80 default_server;
...
location = / {
return 301 https://$http_host${request_uri};
}
}
Is this kind of redirection even possible?
Also, in case you wonder, I also tried all possible combinations of X-Forwarded-Proto, X-Scheme and proxy_redirect as other answers suggest, namely:
Nginx does redirect, not proxy
how to handle nginx reverse proxy https to http scheme redirect
One trick that I've found is that you can disable absolute redirects (e.g. instead of redirecting to http://localhost/your_url_with_trailing_slash_now it will redirect to /your_url_with_trailing_slash_now).
add the following to any point within the server block (of the nginx instance that does this 301 redirect, in your case the nginx-docker instance):
server {
absolute_redirect off;
...
More info can be found here: https://serverfault.com/questions/227742/prevent-port-change-on-redirect-in-nginx
I am running Nexus3 in a docker container on a server that also uses nginx reverse-proxy. The problem is that when try to access to nexus repository from a browser, I am getting a broken page that has many console errors. Here's what I see:
After looking at the network tab, I noticed that my server is not setting the proper content-type for my requests. This is an example of a request to a js file:
Does anyone know what this could be? This is what my nginx.conf looks like:
server {
listen 443 ssl http2;
ssl_certificate /etc/ssl/confidential.com/fullchain.cer;
ssl_certificate_key /etc/ssl/confidential.com/*.confidential.com.key;
server_name confidential.com;
location /test {
proxy_pass http://nexus:8081/;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto "https";
}
}
You have:
location /test {
proxy_pass http://nexus:8081/;
The context path of Nexus needs to match the context path served through the reverse proxy. Edit $workdir/etc/nexus.properties and set "nexus-context-path=/test". And change the proxy_pass to be "proxy_pass http://nexus:8081/test".
We're running grafana and nginx in docker swarm, and proxying the url /foobar/ to the swarm instance of grafana. Using this guide, this works with the following config:
# nginx config
server {
resolver 127.0.0.11 valid=30s;
...
location /foobar/ {
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
proxy_redirect off;
proxy_pass http://grafana:3000/;
proxy_next_upstream error timeout http_502;
}
}
# docker-compose
grafana:
image: ${REGISTRY}foo/grafana:${IMAGE_VERSION}
networks:
- foo
volumes:
- grafana:/var/lib/grafana
environment:
- GF_SERVER_ROOT_URL=%(protocol)s://%(domain)s:%(http_port)s/foobar/
However, this causes nginx to die on startup if the grafana service is not available. So to resolve this, we use a variable for the proxy_pass directive and change it to this:
server {
resolver 127.0.0.11 valid=30s;
...
location /foobar/ {
set $grafana http://grafana:3000;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
proxy_redirect off;
proxy_pass $grafana/;
# proxy_pass http://grafana:3000/;
proxy_next_upstream error timeout http_502;
}
}
However, this causes grafana to reject the request somehow. I can verify that grafana is actually receiving the request (using GF_SERVER_ROUTER_LOGGING=true), and it claims the status is 200 ok, however the only thing I see on the page is
If you're seeing this Grafana has failed to load its application files
1. This could be caused by your reverse proxy settings.
2. If you host grafana under subpath make sure your grafana.ini root_path setting includes subpath
3. If you have a local dev build make sure you build frontend using: npm run dev, npm run watch, or npm run build
4. Sometimes restarting grafana-server can help
Why does grafana behave like this, and how can I set up the proxy pass such that nginx can start up without trying to resolve the grafana URL if it happens to be down?
When using variables complete URL is your responsibility in a proxy pass
location /foobar/ {
set $grafana http://grafana:3000;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
proxy_redirect off;
proxy_pass $grafana$request_uri;
# proxy_pass http://grafana:3000/;
proxy_next_upstream error timeout http_502;
}
In case the base path is different then you will need to use regular expression to send part of the path
location ~ /foobar/(.*) {
set $grafana http://grafana:3000;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
proxy_redirect off;
proxy_pass $grafana/$1;
proxy_next_upstream error timeout http_502;
}
I have an Nginx reverse proxy inside a docker container, which listens to port 3000 and is exposed to 3002: docker run -p "3002:3000" ....
The idea is that this reverse proxy will proxy /my-app to the instance running in my laptop on port 8080; and /my-app/api to the cloud instance, in https://my-domain.
Here's the configuration:
upstream my-laptop {
server host.docker.internal:8080; # this is a magic hostname for the laptop's IP address.
keepalive 64;
}
upstream cloud {
server my-domain.com:443;
keepalive 64;
}
server {
listen 3000;
include ssl/ssl-certs.conf;
include ssl/ssl-params.conf;
location /my-app {
proxy_pass http://my-laptop;
proxy_set_header Host $http_host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
location /my-app/api {
proxy_pass https://cloud;
proxy_set_header Host $http_host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
...
}
The issues are:
when I hit https://localhost:3002/my-app I get a 301 response to /my-app/ (trailing slash). I don't know why is that. The local app instance is shown in the browser, so I guess I can let it slide for the moment?
when I hit https://localhost:3002/my-app/api/students, I get a 301 response to https://cloud/my-app/api/students. This causes CORS issues, of course, and the endpoint doesn't return data.
Now, I have configured reverse proxies a couple of times, so I am completely shocked that I'm not seeing what's wrong, this is not my first time.
I have tried tweaking with the upstreams, the proxy_set_headers, compared with another reverse proxy that I have for a different app; I'm out of ideas.
What am I doing wrong?
Although the questioner's config doesn't have this particular issue, a redirect instead of proxying can also be caused by trailing slash issues, as described in the docs:
If a location is defined by a prefix string that ends with the slash character, and requests are processed by one of proxy_pass, fastcgi_pass, uwsgi_pass, scgi_pass, memcached_pass, or grpc_pass, then the special processing is performed. In response to a request with URI equal to this string, but without the trailing slash, a permanent redirect with the code 301 will be returned to the requested URI with the slash appended. If this is not desired, an exact match of the URI and location could be defined like this:
location /user/ {
proxy_pass http://user.example.com;
}
location = /user {
proxy_pass http://login.example.com;
}
The problem was my Host header in the cloud upstream, I had
proxy_set_header Host $http_host;
But it needed to be
proxy_set_header Host my-domain.com;
here is an example config for nginx as a reverse proxy which works for me,
I simplified it and removed unnecessary parts.
I hope it helps.
upstream OAUTH {
server remote_oauth;
}
server {
listen 80;
server_name example.com;
client_header_timeout 300;
location = /servies/oauth {
return 301 /services/oauth/;
}
location /services/oauth/ {
proxy_pass_request_headers on;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_pass http://OAUTH/;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-ROOT-URI /services/oauth;
proxy_set_header Accept-Encoding "gzip";
proxy_buffering off;
proxy_request_buffering off;
proxy_http_version 1.1;
proxy_intercept_errors on;
proxy_redirect default;
client_max_body_size 4M;
}
}
I think you missed this part :
proxy_pass_request_headers on
I'm trying to set up a nginx loadbalancer/proxy for two servers, with OAuth authenticated apps running on both of them.
Everything's running fine when nginx is running on port 80, but when I put it on any other port OAuth authentication fails with an "invalid signature" error message.
Here is my server config in nginx.conf:
server {
listen 80;
server_name localhost;
location / {
proxy_pass http://webservice;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Port $server_port;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-FORWARDED-PROTO https;
}
Has anyone run into a similar problem?
PS: I've noticed that the port 80 is omitted from the OAuth realm property, but other ports are added normally.
That's probably not in any way related to nginx. OAuth (1, not 2) requires a signing URL, which would be http://webservice:81 if you moved it to port 81. Make sure that your OAuth code knows the website is actually on port 80 and not 81.
Either update your client to say it's port 81 or tell the server it's on 80.
Replace 81 with your favorite port