Developers might find topics related to DevOps quite annoying, but once you master this skill, and you can be invincible. Just like we cannot skip Docker, let’s challenge Nginx heads on.
Setting up Nginx as a reserve proxy might not be that troublesome as you expect. Check below the nginx.conf file:
It’s quite easy to understand above code. The server listens on port 8080 and proxies requests to various upstream servers based on the URL path.
What is an upstream server?
In the context of a reverse proxy server, an upstream server is a server that the reverse proxy forwards requests to. The upstream server can be any server that can handle the request, such as a web server, application server, or microservice.
In the Nginx configuration file, the “upstream” section defines the upstream servers that the reverse proxy will forward requests to. Each upstream server is defined with a “server” directive that specifies the server’s hostname and port number. For example, the “upstream docker-baskets” directive defines an upstream server named “docker-baskets” that listens on port 8080.
When a request comes in to the reverse proxy server, the server determines which upstream server to forward the request to based on the URL path. This is typically done using the “location” directive in the Nginx configuration file. For example, the “location /api/baskets” directive proxies requests with the “/api/baskets” URL path prefix to the “docker-baskets” upstream server.
This means that when a client sends a request to the reverse proxy server with a URL path that starts with “/api/baskets”, the reverse proxy server will forward the request to the “docker-baskets” upstream server. The upstream server will then handle the request and send the response back to the reverse proxy server, which will forward the response back to the client.
Check how the API is handled:
I used Swagger UI to make api calls.
What the Nginx file means?
The “upstream” section defines the upstream servers that the reverse proxy will forward requests to. Each upstream server is defined with a “server” directive that specifies the server’s hostname and port number.
The “server” section defines the reverse proxy server itself. It listens on port 8080 and has multiple “location” directives that define how to proxy requests based on the URL path. Each “location” directive specifies a URL path prefix and the upstream server to forward requests to using the “proxy_pass” directive.
For example, the “location /api/baskets” directive proxies requests with the “/api/baskets” URL path prefix to the “docker-baskets” upstream server. Similarly, the “location /baskets-spec/” directive proxies requests with the “/baskets-spec/” URL path prefix to the “docker-baskets” upstream server.
The “location /” directive is a catch-all that proxies all other requests to the “docker-baskets” upstream server.
Overall, this configuration file allows the reverse proxy server to route requests to different microservices based on the URL path, making it easier to manage and scale a microservices-based application.
How to use the Nginx Reverse Proxy?
Below is my docker-compose.yml file that specified nginx:
Docker Compose file that defines a service named “reverse-proxy” which uses the “nginxproxy/nginx-proxy:alpine” image to create a container named “proxy”. The container is configured to listen on port 8080 and map it to the host’s port 8080.
The “volumes” section is used to mount files or directories from the host machine to the container. In this case, it mounts the “nginx.conf” file from the host machine to the container’s “/etc/nginx/nginx.conf” directory. This allows the container to use the custom Nginx configuration file instead of the default one.
The second volume “- /var/run/docker.sock:/tmp/docker.sock:ro” is used to mount the Docker socket file from the host machine to the container’s “/tmp/docker.sock” directory. This allows the container to communicate with the Docker daemon running on the host machine. The “:ro” at the end of the volume definition specifies that the Docker socket file is mounted in read-only mode.
The “profiles” section is used to assign the “microservices” profile to the “reverse-proxy” service. Profiles are used to group services together and apply common configuration to them. In this case, the “microservices” profile may contain additional configuration that applies to all services in the group.
That’s it, Nginx is no big deal. Don’t be bothered by this config file, that’s all we need to know about how to use it!