Score:0

Same server_name with different applications plugged as separate location blocks in nginx

bq flag
s.k

Is it possible to "plug" different web services (exposed from different docker containers) in a same nginx server?

Here's a simple example to get the general idea:

server {
    listen 80;
    listen [::]:80;

    client_max_body_size 10M;
    charset utf-8;

    server_name my.server.org;

    access_log /var/log/nginx/reverse-access.log;
    error_log /var/log/nginx/reverse-error.log;

    location / {
        include proxy_params;
        proxy_pass http://127.0.0.1:8081/;
    }
    location /static/ {
        include proxy_params;
        include /etc/nginx/mime.types;
        alias /var/www/app/static/;
    }
    location ^~ /app2/ {
        include proxy_params;
        proxy_pass http://127.0.0.1:8082;
    }
    location ^~ /app3/ {
        include proxy_params;
        proxy_redirect off;
        proxy_set_header Host $http_host;
        proxy_pass http://127.0.0.1:8083;
    }
}

where location / is the root of a first application along with its static files in the next location block.
This first application is running at http://my.server.org/.

I would like to access two other applications at http://my.server.org/app2/ and http://my.server.org/app3/ while keeping the same server name my.server.org.
These applications are related to the main one, but they are totally independent, i.e. they are served from other docker compositions, with their ports exposed respectively at 8082 and 8083.

Is it possible to achieve such simple task within a unique server block?

For the moment I got 404 when reaching those two other URLs.

I basically want to map those working URLs+ports and all their children elements to named locations:

http://my.server.org:8081/... -> http://my.server.org/...
http://my.server.org:8082/... -> http://my.server.org/app2/...
http://my.server.org:8083/... -> http://my.server.org/app3/...

EDIT:
either this:

    location /app3/ {
        if ($http_referer ~ "^$scheme://$http_host/app3/") {
            rewrite ^/app3/(.*) $scheme://$http_host/app3/$1 redirect;
        }
        include proxy_params;
        proxy_redirect off;
        proxy_set_header Host $http_host;
        proxy_pass http://127.0.0.1:8083;
    }

or this:

    location ~*/app3/(.*)$ {
        include proxy_params;
        proxy_redirect off;
        proxy_set_header Host $http_host;
        proxy_pass http://127.0.0.1:8083/$1;
    }

are "working" the same, but yet not perfectly because there are two issues left:

  1. only raw HTML is served (e.g. no styling: "502 bad gateway" on css files for example)
  2. links within the pages point to, e.g. http://my.server.org/subfeature/subitem instead of http://my.server.org/app3/subfeature/subitem. Hence, they are "missing" the /app3 prefix and I don't know how to actually add it if it's not present where it should actually be.
Score:0
za flag

This is a typical task but you forgot two things:

  • googling your question.
  • adding rewrite clauses into each of the location {} blocks.
s.k avatar
bq flag
s.k
The problem is that statics files are automatically served at the root level, without the `/app3` prefix, therefore, because they are not "aware" of that location from inside the docker container they originate from, they will never ever enter that `/app3` location block and their search path will default to the one of nginx. I don't know if the task is typical, but it doesn't seem solvable within nginx. :/
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.