Score:0

Nginx cannot find backend service which is running

je flag

I am setting up an nginx webserver for an application with web frontend and a flask backend, each running in a docker container. The following is my nginx configuration:

events{}
http{
client_max_body_size 50M;
   server {
    listen 80;

    location /api {
        proxy_pass http://0.0.0.0:5000;
    }

    location / {
        root /var/www/;
        try_files $uri /index.html;
    }
  }
}

I can access my front end at localhost fine. However, my backend is not accessible.

For example, I can access the backend directly by using the correct port: localhost:5000/api/alive gives me the expected response, but localhost/api/alive gives me

502 Bad Gateway
nginx/1.23.4

And the following error

172.27.0.1 - - [07/Apr/2023:21:22:12 +0000] "GET /api/alive HTTP/1.1" 502 559 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/111.0.0.0 Safari/537.36"

2023/04/07 21:22:12 [error] 108#108: *35 connect() failed (111: Connection refused) while connecting to upstream, client: 172.27.0.1, server: , request: "GET /api/alive HTTP/1.1", upstream: "http://0.0.0.0:5000/api/alive", host: "0.0.0.0"

How can I get my request to be routed correctly? I am new to nginx and do not understand the error message.

Score:0
in flag

0.0.0.0 is not a valid IP address. It is a notation to bind to all addresses, which is used in configuring the service that should listen.

Change your configuration to the IP address of the loopback interface.

location /api {
    proxy_pass http://127.0.0.1:5000;
}

Regarging the docker containers: You can't reach a port on another container via localhost by default. Every container has it's own network namespace, which is separated by the hosts. To reach one container from another you have three possibilities:

  • host networking
  • container links (legacy, will probably removed in the future)
  • custom networks

Since custom networks are the most viable option I'll focus on this.

You need to create a network and reference it when you create containers.

docker network create my-network
docker run --network my-network --name db mariadb:latest
docker run --network my-network --name app -p 80:8080 myimage

now you can reference the container db by its name from inside the app container. You don't need to publish the ports in the db container, since they share the same network.

with docker-compose you don't need to do anything special when all containers that are involved are defined in the same yaml file, it creates a network for the containers by default.

If you have multiple yaml files and want to share a container, for example, a single database instance, you can reference it's network as an external network in the docker-compose.yml.

BoringPanda avatar
je flag
I still get similar message: 172.27.0.1 - - [08/Apr/2023:12:07:51 +0000] "GET /api/alive HTTP/1.1" 502 559 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/111.0.0.0 Safari/537.36" 2023/04/08 12:07:51 [error] 141#141: *69 connect() failed (111: Connection refused) while connecting to upstream, client: 172.27.0.1, server: , request: "GET /api/alive HTTP/1.1", upstream: "http://127.0.0.1:5000/api/alive", host: "localhost"
in flag
`connection refused` means nothing is listening on that port. Are VMs or container involved?
BoringPanda avatar
je flag
Yes, the backend (port 5000) is on a separate docker container. It is exposed, and I can access it through browser.
in flag
Then read up on docker networking. It doesn't work that way. I'll update my answer when I'm on a computer again, that's to much to write on the phone. Hint: you need to create a link to the other container.
BoringPanda avatar
je flag
That worked! I had to use the name I had used in the docker compose file. Lets say the service name was `mycustomapp` in my docker-compose, so had to set `proxy_pass http://mycustomapp:5000` in nginx config. Please update the answer and I'll accept it.
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.