Curious to understand nginx config in docker?

Want to understand how does nginx config works because the config adds server_name as “frontend” but when I run the container with “localhost:8080” it responds? Ideally nginx config should not work for it since the server_name in the config does not match.

The config is generated from this template

It replaces the env variables in the template with the ones set in container and generates the nginx config


Hey @Revant, thanks for the reply. But I got that part I tell you where my confusion is arising from. So in the nginx template we name server_name as FRAPPE_SITE_NAME_HEADER.

listen 8080;
root /home/frappe/frappe-bench/sites;

Now we are passing frontend in the env variable and a default site has been created with the same name. But when I call the reverse-proxy container with http://localhost:8080, where does the translation from localhost → frontend host happens for the site to actually be served?

I am referring the pwd.yml only for the docker containerisation step.

Well, if you read the yaml at:

it’s precisely configured to serve at port 8080
(the mapping is in the section ports of frontend).

But you could change that, couldn’t you?

How the yaml is interpreted by docker is in the docker documentation, an essential read if you want to understand, change, adapt, improve your server creatures.

@Peer, Yeah agreed I understand that part. The place where I am confused a bit is that after you send the request to the container from the browser with http://localhost:8080, the nginx config is identified to route request for port 8080 and server_name: FRAPPE_SITE_NAME_HEADER (which according to the docker-compose.yaml) is set as frontend which is the site name as well. So how does the hostname localhost is able to use this because it does not match the server_name in config.

The name of the site you configure with bench add-site is routed by the framework (or the proxy aka frontend).
Technically it travels in the http request header sent with any request coming from a browser. It arrives at the frontend machine inside of the container via pure IP routing.

The other names are internal to the docker container setup which creates several “machines” inside the container which also need to have names to refer to.
Still another setup would be with kubernetes (helm) which also needs a mechanism to refer the “machines” to each other.

Remember that The Thing is not just built with docker, but with docker-compose.

Docker compose builds an orchestra of more than one container and does some routing between them.

My terminology might not be exactly correct, but I guess it transports the basics of the mechanism you try to understand more or less correctly.