5

I'm quite new to Docker. I'm trying to run Django on Docker. Following is my docker-compose file.

version: '2' services: django: build: context: . dockerfile: ./deploy/dev/Dockerfile tty: true command: python manage.py runserver 0.0.0.0:8000 ports: - "8000:8000" volumes: - ./app:/src/app depends_on: - "workflow_db" - "rabbitmq" env_file: - ./deploy/dev/envvar.env workflow_db: image: postgres:9.6 volumes: - postgres_data:/var/lib/postgresql/data/ environment: - POSTGRES_USER=hello_django - POSTGRES_PASSWORD=hello_django - POSTGRES_DB=hello_django rabbitmq: image: "rabbitmq:3-management" hostname: "rabbitmq" environment: RABBITMQ_ERLANG_COOKIE: "SWQOKODSQALRPCLNMEQG" RABBITMQ_DEFAULT_USER: "rabbitmq" RABBITMQ_DEFAULT_PASS: "rabbitmq" RABBITMQ_DEFAULT_VHOST: "/" ports: - "15672:15672" - "5672:5672" volumes: postgres_data:

DockerFile

FROM python:3.7-alpine RUN apk update && apk add --no-cache gcc libffi-dev g++ python-dev build-base linux-headers postgresql-dev postgresql postgresql-contrib pcre-dev bash alpine-sdk \ && pip install wheel #Copy over application files COPY ./app /src/app #Copy over, and grant executable permission to the startup script COPY ./deploy/dev/entrypoint.sh / RUN chmod +x /entrypoint.sh WORKDIR /src/app #Install requirements pre-startup to reduce entrypoint time RUN pip install -r requirements.txt ENTRYPOINT [ "/entrypoint.sh" ]

And finally my entrypoint.sh

#! /bin/bash cd /src/app || exit echo "PIP INSTALLATION" && pip install -r requirements.txt echo "UPGRADE" && python manage.py migrate # echo "uwsgi" && uwsgi "uwsgi.ini"

I do django-compose build, it builds the image. But when I do docker-compose up django_1 exited with code 0.

However, if I uncomment the last line of entrypoint.sh, it runs perfectly well.

Can someone help me understand the reason behind it?

Improve this question
2
  • better to remove volume if you copying files in docker image. remove this ` volumes: - ./app:/src/app` , as it will overide every thing inside image. or may be in compose the path inside container will become some thing /src/app/app/... . as the application exiting with code 0 so mean no erro, one thing that help you to debug by adding django: command: tail -f /dev/null then verify files and folder inside django container. seems like something wrong with path Commented Oct 17, 2019 at 8:56
  • Is there any other message or just django_1 exited with code 0? And could you include your uwsgi.ini into the question? Commented Oct 17, 2019 at 9:15

3 Answers 3

Reset to default
11

When you have both a command and an entrypoint, Docker runs only the entrypoint, and passes the command to it as arguments. See Understand how CMD and ENTRYPOINT interact in the Dockerfile docs. As soon as the entrypoint exits, the container is over; it can do whatever it likes with the command part, including completely ignoring it.

Typical practice is to end the entrypoint script with

exec "$@"

which causes it to just take its command-line arguments and run them as a command, replacing the entrypoint script as the main container process.

Without this, you get to the end of the entrypoint script, and the container has done everything it's told to do, so it exits successfully (status code 0).

Improve this answer
Sign up to request clarification or add additional context in comments.

1 Comment

Yes. With a lot of playing around, I figured out the maths myself. However, your answer acted as an explanation. Thankyou so much.
0

If you want to container to keep running, you need either to:

  1. run a foreground process
  2. connect to it's terminal by --ti

you need to connect with terminal to see if the python command is failing when the uwsgi is not executed, hence stopping the container

Improve this answer

Comments

0

AFAIU, when you uncomment the last line in entrypoint, the container doesn't have a foreground process anymore which can keep it up & running, hence it exits with status 0. Entrypoint must have a foreground process to keep container up & running. Also, you are doing "pip install" multiple times. This step should just be in Dockerfile.

Try moving python manage.py runserver 0.0.0.0:8000 in entrypoint.sh itself.

Update -

In case of port conflict, the container will not exit with status 0 & the port conflict error with come in STDOUT. Also, when he uncomments, there is no chance of port conflict. So, it seems like the foreground process is not getting executed at all.

Improve this answer

5 Comments

I think it do have a foreground process, python manage.py runserver 0.0.0.0:8000 on the compose file.
Got it. But I doubt if that is getting executed. Can you try putting that command in the entrypoint?
I don't know, let questioner put it :D. Do you think that's because uwsgi running on the same port 8000 so that when docker compose execute python manage.py runserver 0.0.0.0:8000 then it will stop the foreground process. maybe?
Yes, makes sense and probably may well be the cause. I have never tried like this yet. Ideally it should all be just in entrypoint or entrypoint should support args passed by CMD.
A correction, in case of port conflict, the container will not exit with status 0 & the port conflict error with come in STDOUT. Also, when he uncomments, there is no chance of port conflict. So, it seems like the foreground process is not getting executed at all.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.