NGINX reverse proxy to docker applications

Question

I am currently learning to set up nginx but I am already having an issue. There are gitlab and nextcloud running on my vps and both are accessible with the right port. Therefore I created a nginx config with a simple proxy_pass command but I always reveice 502 Bad Gateway . Nextcloud, Gitlab and NGINX are docker container and NGINX has port 80 opened. The remaining two containers are having port 3000 and 3100 opened.

/etc/nginx/conf.d/gitlab.domain.com.conf

upstream gitlab {
    server x.x.x.x:3000;
}
server {
    listen 80;
    server_name gitlab.domain.com;
    location / {
      proxy_set_header X-Real-IP $remote_addr;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header Host $host;
      proxy_set_header X-NginX-Proxy true;
      proxy_pass http://gitlab/;
     }
}

/var/logs/error.log

2018/04/12 08:10:41 [error] 7#7: *1 connect() failed (113: Host is unreachable) while connecting to upstream, client: xx.201.226.19, server: gitlab.domain.com, request: "GET / HTTP/1.1", upstream: "http://xxx.249.7.15:3000/", host: "gitlab.domain.com"
2018/04/12 08:10:42 [error] 7#7: *1 connect() failed (113: Host is unreachable) while connecting to upstream, client: xx.201.226.19, server: gitlab.domain.com, request: "GET /favicon.ico HTTP/1.1", upstream: "http://xxx.249.7.15:3000/favicon.ico", host: "gitlab.domain.com", referrer: "http://gitlab.domain.com/

What is wrong with my configuration?

Answer 1

I think you could get away with a config way simpler than that.

Maybe something like this:

http {
 ...
server {
listen 80;
charset utf-8;
...

location / {
  proxy_pass http://gitlab:3000;
}
}
}

I assume you are using docker's internal DNS for accessing the containers for example gitlab points to the gitlab containers internal IP. If that is the case then you can open up a container and try ping the gitlab container from the other container. For example you can ping the gitlab container from the nginx container like this:

 $ docker ps (use this to get the container id)

Now do:

$ docker exec -it <container_id_for_nginx_container> bash
# apt-get update -y
# apt-get install iputils-ping -y
# ping -c 2 gitlab

If you can't ping it then it means the containers have trouble communicating with each other. Are you using docker-compose? If you are then I would suggest look at the "links" keyword which is used to link containers that should be able to communicate with each other. So for example you would probably link the gitlab container to postgresql.

Let me know if this helps.

Answer 2

Another option that uses the advantage that your Docker containers are just processes in an isolated own control group is to bind each process (container) to a port on the host network (instead of an isolated network group). This bypasses Docker routing, so beware of the caveat that ports may not overlap on the host machine (no different than any normal process sharing the same host network.

You mentioned running Nginx and Nextcloud (I assume you are using the nextcloud fpm image because of FastCGI support). In this case, I had to do the following on my Arch Linux machine:

1. /usr/share/webapps/nextcloud is bounded (bind mounted) to the container at /var/www/html .
2. The UID of both host and container process must be the same (in my case, user host http and container www-data are UID=33)
3. The 443 server block in nginx.conf must set root to the host's nextcloud path, root /usr/share/webapps/nextcloud; .
4. The FastCGI script path for each server block that calls php-fpm over FastCGI must be adjusted to refer to the Docker container's Nextcloud base path, fastcgi_param SCRIPT_FILENAME /var/www/html$fastcgi_script_name; . In other words, you cannot use $document_root as you normally would, because this points to the host's nextcloud root path.
5. Optional: Adjust paths to database and Redis in the config.php file to not use localhost , rather the hostname of the host machine. localhost seems to reference the container's host despite having been bound to the host machine's main network.