resolving simple containerized nginx : bad gateway-CodePudding

I have a nginx container supposed to serve a flask gunicorn container but i get a "502 bad gateway" error even if the flask gunicorn container is working properly.

Could you help me understand why this is happening ? (I have tried to remove the mynet network but it's the same)

This is my nginx.conf:

server {
    listen 80;
    server_name localhost; 
    
    location / {
        proxy_pass http://app:4000;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        client_max_body_size 20M;
      } 
    }

This is my docker-compose.yml :

---
version: '3.7'
services:
  nginx:
    build:
      context: .
      dockerfile: ./nginx/Dockerfile
    restart: always
    ports:
      - 80:80
    depends_on:
      - app
    networks:
      - mynet
  app:
    container_name: app
    build:
      context: .
      dockerfile: ./app/Dockerfile
    volumes:
      - app:/app
    ports:
      - 4000:5000
    networks:
      - mynet


volumes:
  app:
    name: app
networks:
  mynet:

And the app dockerfile

FROM python:3.8-slim-buster
RUN apt-get update \
  # dependencies for building Python packages
  && apt-get install -y build-essential netcat\
  # cleaning up unused files
  && apt-get purge -y --auto-remove -o APT::AutoRemove::RecommendsImportant=false \
  && rm -rf /var/lib/apt/lists/*
RUN adduser --home /app --system --group kr1p
WORKDIR /app
COPY --chown=kr1p:kr1p app .
RUN pip install -r requirements.txt 
USER kr1p
ENV PYTHONUNBUFFERED=1
CMD gunicorn

And the nginx Dockerfile:

FROM nginx:1.21.6-alpine
RUN rm /etc/nginx/conf.d/default.conf
COPY ./nginx/nginx.conf /etc/nginx/conf.d
CMD ["nginx", "-g", "daemon off;"]

CodePudding user response：

You do not need to publish the port of the app. (Unless you access it from outside the docker network.) Since both containers share the network they can be reached on that network without publishing ports. This also means that you should access it on the port the process is running on.

Since you have

ports:
      - 4000:5000

for the app it would mean your process is running on port 5000. Is that correct? If so, try connecting to it there in nginx:

proxy_pass http://app:5000;