What is the role of nginx when dockerizing an app? - docker

Question

I am new to docker and I've been working on dockerizing and deploying my app to an internal server at work.
The structure is that I have a Dockerfile for my react + nginx server and a flask backend.
Then I use docker-compose to merge these Dockerfiles.
I've been following the format that other people at my work have written previously, so I am not fully grasping all aspects.
I am especially confused about the role of nginx.
The Dockerfile that contains both react and nginx looks like this:
FROM node:latest as building
RUN npm config set proxy <proxy for my company>
RUN npm config set https-proxy <proxy for my company>
WORKDIR /app
ENV PATH /node_modules/.bin:$PATH
COPY package.json /app/
COPY ./ /app/
RUN npm install
RUN npm install react-scripts#3.0.1 -g
RUN npm run build
FROM nginx
RUN rm -rf /etc/nginx/conf.d
COPY deployment/nginx.conf /etc/nginx/nginx.conf
COPY --from=building /app/build /usr/share/nginx/html
EXPOSE 80
CMD ["nginx", "-g", "daemon off;"]
and my customized nginx.conf looks like
user root;
worker_processes auto;
error_log /var/log/nginx/error.log warn;
pid /var/run/nginx.pid;
events {
worker_connections 1024;
}
http {
server {
server_name <internal_server_box>
;
listen [::]:80;
listen 80;
root /usr/share/nginx/html;
location / {
root /usr/share/nginx/html;
index index.html index.htm;
try_files $uri $uri/ /index.html =404;
}
location /v1 {
proxy_pass <backend_container>:5000;
}
}
client_max_body_size 2M;
include /etc/nginx/mime.types;
default_type application/octet-stream;
log_format main '$remote_addr [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
access_log /var/log/nginx/access.log main;
sendfile on;
keepalive_timeout 65;
include /etc/nginx/conf.d/*.conf;
}
I am not sure what nginx does here because I can still make this app accessible from the outside just by putting up the react app without the nginx. I read somewhere that it could function as some kind of a gateway, but it wasn't clear for me.
It would be great if anyone can explain why we need nginx to make the server up while we can just put it up (make it accessible outside the internal server box) without it.

Answer 1

In the general case, there is no need or requirement to install nginx if you want to dockerize something.
If what you are dockerizing is a web app of some sort (in the broadest sense, i.e. something which people will use their browsers or an HTTP API to communicate with) and it can only handle a single client connection at a time, the benefit of a web server in between is to provide support for multiple concurrent clients.
Many web frameworks allow you to serve a single user or a small number of users without a web server, but this does not scale to production use with as many concurrent clients as the hardware can handle. When you deploy, you add a web server in between to take care of spawning as many instances of your server-side client handling code as necessary to keep up, as well as handle normal web server tasks like resource limits, access permissions, redirection, logging, SSL negotiation for HTTPS, etc.

Answer 2

The nginx has two important roles here. (Neither is specific to Docker.) As you say it's not strictly required, but this seems like a sound setup to me.
The standard Javascript build tooling (Webpack, for instance) ultimately compiles to a set of static files that get sent across to the browser. If you have a "frontend" container, it never actually runs your React code, it just serves it up. While most frameworks have a built-in development server, they also tend to come with a big "not for production use" disclaimer. You can see this in your Dockerfile: the first-stage build compiles the application, and in the second stage, it just copies in the built artifacts.
There are some practical issues that are solved if the browser can see the Javascript code and the underlying API on the same service. (The browser code can just include links to /v1/... without needing to know a hostname; you don't have to do tricks to work around CORS restrictions.) That's what the proxy_pass line in the nginx configuration does.
I consider the overall pattern of this Dockerfile to be a very standard Docker setup. First it COPYs some code in; it compiles or packages it; and then it sets up a minimal runtime package that contains only what's needed to run or serve the application. Your build tools and local HTTP proxy settings don't appear in the final image. You can run the resulting image without any sort of attached volumes. This matches the sort of Docker setups I've built for other languages.