跪拜 Guibai
← Back to the summary

Docker Nginx Reverse Proxy to Node, Step by Step

Docker in Practice: Using Nginx as a Container Entry Proxy for a Node Service


theme: github

The previous article introduced Docker's core idea:

Docker = Application + Runtime Environment

It solves the problem of:

"It runs on my machine, why doesn't it run on yours?"

In actual development, a project usually depends on many environments:

Node
Redis
MySQL
React
Next
Nginx

Each of these services has its own version requirements.

Docker can package them into independent runtime environments.

For example:

Project
│
├── Node Container
│
├── Redis Container
│
├── MySQL Container
│
└── Nginx Container

Each service runs independently, yet they can communicate with each other.

This article uses a simple web service to understand how Docker runs Nginx and proxies a backend Node service through Nginx.


1. A Simple Web Service

Assume there is a Node backend service.

Code:

const express = require("express")

const app = express()

app.get("/", (req, res) => {
    res.send("Hello Docker")
})


app.listen(1314, () => {
    console.log("server running at 1314")
})

Start it:

node app.js

The service runs on:

localhost:1314

Access:

http://localhost:1314

The browser gets:

Hello Docker

The current request flow:

Browser
↓
Node Service
↓
Return Data

2. Why Do We Need Nginx?

If it's only for local development:

Browser
↓
localhost:1314
↓
Node

There is absolutely no problem.

But in a production environment, users usually do not access it directly via:

xxx.com:1314

Reasons:

For example:

A user visits:

www.example.com

This defaults to accessing:

Port 80

But our Node service is on:

Port 1314

So an intermediate layer is needed:

User
↓
Nginx :80
↓
Node :1314

This process is called:

Reverse Proxy


3. What Does Nginx Do?

Nginx is server software.

Here, it is mainly responsible for:

For example:

A user visits:

localhost:80

Based on the configuration:

location / {

    proxy_pass http://localhost:1314;

}

Nginx forwards:

localhost:80
↓
localhost:1314

The user only knows:

localhost:80

And does not know:

Node is running on port 1314

4. Running Nginx with Docker

Docker's biggest feature:

No need to manually install environments.

We directly use the official Nginx image.

Pull the image:

docker pull nginx

We get:

nginx Image

An Image can be understood as:

A pre-prepared runtime environment template.

Run it:

docker run nginx

Docker creates a container based on the Image:

nginx Container

The Container is the truly running Nginx service.


5. Parsing docker run Parameters

Actual execution:

docker run \
--name my-nginx-demo \
-p 80:80 \
-v /Users/shunwuyu/Desktop/ai_doubao_ysw/backend/docker/demo/nginx.conf:/etc/nginx/nginx.conf \
-d nginx

This command contains several important concepts.


5.1 --name: Naming the Container

--name my-nginx-demo

Names the created container:

Container

name:

my-nginx-demo

Afterwards, it can be managed by name:

docker stop my-nginx-demo

5.2 -p: Port Mapping

-p 80:80

Format:

Host Port : Container Port

This means:

Computer's port 80

maps to

Nginx Container's port 80

Therefore:

When the browser visits:

localhost:80

The request enters:

Nginx Container:80

Flow:

Browser
↓
Computer Port 80
↓
Docker Port Mapping
↓
Container Port 80

5.3 -v: Mounting Configuration Files

-v HostFile:/ContainerFile

For example:

-v nginx.conf:/etc/nginx/nginx.conf

Function:

Maps the file on the computer:

nginx.conf

to:

Inside the Container:

/etc/nginx/nginx.conf

Why is this needed?

Because Nginx's forwarding rules need to be configured.

We modify the local:

nginx.conf

And the Nginx inside the Container reads the new configuration.


5.4 -d: Running in the Background

-d

Stands for:

detach

Lets the Container run in the background.

Otherwise:

docker run nginx

The terminal will continuously display Nginx logs.


6. Configuring Reverse Proxy in nginx.conf

For example:

server {

    listen 80;


    location / {

        proxy_pass http://host.docker.internal:1314;

    }

}

Meaning:

Listens on:

Port 80

If a request is received:

Forwards it to:

The Node service on port 1314

7. Complete Request Flow

Now the entire system:

                 Browser
                    |
                    ↓
              localhost:80
                    |
                    ↓
         Docker Port Mapping (-p)
                    |
                    ↓
          Nginx Container
                    |
                    ↓
         nginx.conf Configuration
                    |
                    ↓
              proxy_pass
                    |
                    ↓
          Node Service :1314
                    |
                    ↓
                Return Data

Specific process:

Step 1

The user visits:

localhost:80

Step 2

The request enters Docker:

-p 80:80

Maps the computer's port 80 to:

Nginx Container:80

Step 3

Nginx receives the request.

Reads:

nginx.conf

Finds:

proxy_pass http://host.docker.internal:1314;

Step 4

Nginx forwards the request to:

Node Service :1314

Step 5

Node returns the result:

Node
↓
Nginx
↓
Browser

8. Docker's Role in This Flow

There are two roles here:

Nginx Container

Responsible for:

Receiving Requests
↓
Forwarding Requests

Node Service

Responsible for:

Business Logic
↓
Returning Data

Final structure:

Docker
├── Nginx Container
│       ↓
│   Reverse Proxy
│
└── Node Service
        ↓
    Processing Business

9. Common Docker Commands for Operations

View running Containers:

docker ps

Stop all Containers:

docker stop $(docker ps -q)

Delete all Containers:

docker rm $(docker ps -aq)

Delete an image:

docker rmi nginx

Pull MySQL:

docker pull mysql:8.0

Summary

Docker solves:

The problem of consistent application runtime environments.

Nginx solves:

The problem of request entry points and service forwarding.

In this example:

User
↓
localhost:80
↓
Nginx Container
↓
Node Service :1314

Docker is responsible for running Nginx and Node.

Nginx is responsible for forwarding user requests to the service that actually handles the business logic.

This is a most basic Docker web deployment process.