Skip to content

Update Dockerfile #96

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Update Dockerfile #96

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 4 additions & 3 deletions Dockerfile
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3,18 +3,19 @@ FROM python:3.9
WORKDIR /app/backend

COPY requirements.txt /app/backend

RUN apt-get update \
&& apt-get upgrade -y \
&& apt-get install -y gcc default-libmysqlclient-dev pkg-config \
&& rm -rf /var/lib/apt/lists/*


# Install app dependencies
RUN pip install mysqlclient
RUN pip install --no-cache-dir -r requirements.txt

COPY . /app/backend

EXPOSE 8000
#RUN python manage.py migrate
#RUN python manage.py makemigrations

# Run migrations then start the server on 0.0.0.0:8000
CMD python manage.py migrate && python manage.py runserver 0.0.0.0:8000
Comment on lines +19 to +21
Copy link

@coderabbitai coderabbitai bot Jul 28, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🛠️ Refactor suggestion

⚠️ Potential issue

runserver in CMD is unsuitable for production & loses signal handling

The added CMD runs Django’s dev server after applying migrations.
Issues:

  1. python manage.py runserver is single-threaded, slow, and not meant for production; use gunicorn/uvicorn instead.
  2. Shell form (CMD ... && ...) launches a shell as PID 1 so signals (SIGTERM, SIGINT) may not reach the Django process → containers may hang on shutdown.
  3. Running migrations on every container start can race when multiple replicas launch concurrently. Prefer a separate init/entrypoint step (or CI/CD migration job) and keep the app container focused on serving traffic.

Suggested fix (example):

-# Run migrations then start the server on 0.0.0.0:8000
-CMD python manage.py migrate && python manage.py runserver 0.0.0.0:8000
+# Apply migrations once, then hand off to Gunicorn with proper signal handling
+ENTRYPOINT ["sh", "-c", "python manage.py migrate --noinput && \
+  exec gunicorn project.wsgi:application --bind 0.0.0.0:8000"]

(Replace project.wsgi with your actual WSGI module.)

This switches to exec-form, forwards signals correctly, and uses a production-grade server.
Consider moving migrations to a one-off job if concurrent starts are expected.

🤖 Prompt for AI Agents 
In Dockerfile lines 19 to 21, replace the CMD that runs migrations and starts
Django's development server with an exec-form CMD that launches a
production-grade server like gunicorn or uvicorn to handle signals properly and
improve performance. Remove running migrations from the CMD to avoid race
conditions on container start; instead, run migrations as a separate
initialization or CI/CD job. Update the CMD to directly exec the production
server with the correct WSGI or ASGI module for your project.