nginx configuration file : server, server_name and upstream understanding-CodePudding

I have this nginx.conf configuration file inherited from a github project and i'd like some people to explain me what is doing what:

upstream hello_django {
    server web:8000;
}

server {
    listen 80;
    server_name react-wagtail-api.accordbox.com;
    location / {
        proxy_pass http://hello_django;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $host;
        proxy_redirect off;
        client_max_body_size 20M;
    }
    location /static/ {
        alias /app/static/;
    }
    location /media/ {
        alias /app/media/;
    }
}

server {
    listen 80;
    server_name react-wagtail.accordbox.com;
    location / {
      root   /usr/share/nginx/html/build;
      index  index.html index.htm;
      try_files $uri $uri/ /index.html;
    }
}

with

upstream hello_django {
        server web:8000;
    }

is web a service (elswhere there is a docker-compose container name which is web... is it a ref to that? ) ? What does upstream define exactly?

with

server_name react-wagtail-api.accordbox.com;

what happens if i dont define a server_name for example in case i dont have yet a domain? is server_name the domain typed in the adress bar of the browser? can i define it as the local ip and let my domain name provider do the redirect? can i define it as the internet ip of the server and let my domain name provider do the redirect?

As there are two servers on the same port, can i define for example server_name my_internet_ip/app1 and server_name my_internet_ip/app2 to serve two servers on port 80?

CodePudding user response：

Is web a service (elsewhere there is a docker-compose container name which is web... is it a ref to that?)

Generally, web here is an upstream domain name (can be also specified via IP address or UNIX socket path). However, when this is executed within the docker-compose context, at the nginx startup time it will be resolved to the web container internal IP using docker internal domain name resolving system.

What does upstream define exactly?

For this particular configuration, there will be no difference using either

upstream hello_django {
    server web:8000;
}
server {
    ...
    proxy_pass http://hello_django;

or specifying an upstream address directly in the proxy_pass directive:

server {
    ...
    proxy_pass http://web:8000;

Really useful upstream use cases include failover (example) or load balancing (example). Read the ngx_http_upstream_module documentation to find out all the available features.

What happens if i don't define a server_name for example in case i don't have yet a domain?

To understand this part make sure you read the following two chapters from the official documentation:

You can omit the server_name directive from the server block at all. For any HTTP request arriving at the TCP port where nginx is listening, one of the defined server blocks (usually the very first one appearing in the configuration, unless being specified explicitly using default_server parameter of listen directive) will act as the default server if more appropriate server block won't be found. The Host HTTP header value is used here, and it will be exactly what you typed at the browser address bar (assuming IP address/domain name being typed will actually point to the nginx server).

As there are two servers on the same port, can i define for example server_name my_internet_ip/app1 and server_name my_internet_ip/app2 to serve two servers on port 80?

No. Looks like you don't understand the internals of HTTP protocol. At the low level HTTP request will be something like

GET /app1 HTTP/1.1
Host: my_internet_ip
...

As you can see the host name and the request URL path are two completely different things. Usually this kind of tasks being solved using several location blocks:

server {
    server_name example.com;
    location /app1/ {
        ...
    }
    location /app2/ {
        ...
    }
}

However it will require support from the underlying web apps. Two available options are

Referring assets using relative URIs, e.g.

<link rel="stylesheet" type="text/css" href="style.css">

<link rel="stylesheet" type="text/css" href="./style.css">

but not the using absolute URIs like

<link rel="stylesheet" type="text/css" href="/style.css">

Using the same URI prefix as specified in the location directive, e.g.
```
<link rel="stylesheet" type="text/css" href="/app1/style.css">
```

The reason should be obvious - every request for any first or second app assets should start with the /app1/ or /app2/ prefix for being handled with the proper location block.

CodePudding user response：

web service in your case resolves to some IP, same with server_name. You can read more about upstreams here, same for server_name directive.