Docker containerization in Django - Step-by-Step Execution

Concept Flow - Docker containerization

Write Dockerfile

↓

Build Docker Image

↓

Run Docker Container

↓

Container runs Django app

↓

Access app via browser or API

↓

Stop or remove container

This flow shows how you write a Dockerfile, build an image, run a container, and then access your Django app inside the container.

Execution Sample

Django

FROM python:3.12-slim
WORKDIR /app
COPY requirements.txt ./
RUN pip install -r requirements.txt
COPY . ./
CMD ["python", "manage.py", "runserver", "0.0.0.0:8000"]

This Dockerfile sets up a Python environment, installs dependencies, copies the Django app, and runs the development server.

Execution Table

Step	Action	Details	Result
1	Read Dockerfile	FROM python:3.12-slim	Base image set to Python 3.12 slim
2	Set working directory	WORKDIR /app	Working directory inside container is /app
3	Copy requirements	COPY requirements.txt ./	requirements.txt copied to /app
4	Install dependencies	RUN pip install -r requirements.txt	Python packages installed
5	Copy app files	COPY . ./	All app files copied to /app
6	Set command	CMD ["python", "manage.py", "runserver", "0.0.0.0:8000"]	Container will run Django server on port 8000
7	Build image	docker build -t django-app .	Docker image 'django-app' created
8	Run container	docker run -p 8000:8000 django-app	Container runs, Django app accessible at localhost:8000
9	Access app	Open browser at http://localhost:8000	Django app homepage loads
10	Stop container	Ctrl+C or docker stop	Container stops running

💡 Container stops when user stops it or system shuts down

Variable Tracker

Variable	Start	After Step 3	After Step 4	After Step 5	Final
Docker Image	None	Base python:3.12-slim	With dependencies installed	With app files copied	Ready to run Django server
Container State	Not running	Not running	Not running	Not running	Running Django server on port 8000

Key Moments - 3 Insights

Why do we copy requirements.txt and run pip install separately before copying the whole app?

This allows Docker to cache the installed dependencies layer. If requirements.txt doesn't change, Docker skips reinstalling packages, speeding up builds (see execution_table steps 3 and 4).

Why do we use 0.0.0.0:8000 instead of localhost:8000 in the CMD?

0.0.0.0 makes the Django server listen on all network interfaces inside the container, allowing access from outside the container (see execution_table step 6).

What happens if we don't map port 8000 when running the container?

The Django app runs inside the container but is not accessible from the host machine's browser (see execution_table step 8).

Visual Quiz - 3 Questions

Look at the execution_table at step 4, what happens during this step?

A The container starts running the Django server

B The Django app files are copied into the container

C Python packages are installed inside the container

D The working directory is set inside the container

💡 Hint

Check the 'Action' and 'Details' columns at step 4 in the execution_table

At which step does the container become accessible from the host machine's browser?

A Step 8: Run container with port mapping

B Step 6: Set command

C Step 7: Build image

D Step 9: Access app

💡 Hint

Look for when the container is run with port mapping in the execution_table

If you change requirements.txt, which step will Docker NOT cache and must rerun?

A Step 3: Copy requirements.txt

B Step 4: Install dependencies

C Step 5: Copy app files

D Step 6: Set command

💡 Hint

Changing requirements.txt affects the pip install step in the execution_table

Concept Snapshot

Docker containerization for Django:
- Write Dockerfile with base image, copy files, install dependencies
- Build image with 'docker build'
- Run container with 'docker run -p hostPort:containerPort'
- Use 0.0.0.0 in runserver to allow external access
- Access app via localhost:port in browser
- Stop container when done

Full Transcript

Docker containerization for Django involves writing a Dockerfile that starts from a Python base image, sets a working directory, copies the requirements.txt file, installs dependencies, copies the Django app files, and sets the command to run the Django development server on all interfaces at port 8000. The Docker image is built using 'docker build', then run with 'docker run' mapping port 8000 to the host. This allows accessing the Django app in a browser at localhost:8000. The container runs until stopped by the user. Key points include caching dependencies by copying requirements.txt first, using 0.0.0.0 to listen on all interfaces, and port mapping to expose the app outside the container.

Practice

1. What is the main purpose of using Docker with a Django application?

easy

A. To write Django code faster

B. To automatically generate Django templates

C. To replace the Django ORM with a container

D. To package the app and its environment for easy sharing and deployment

Solution

1. Step 1: Understand Docker's role

   Docker packages an app with all its dependencies so it runs the same everywhere.

2. Step 2: Connect to Django app deployment

   This packaging makes sharing and deploying Django apps consistent and easy.

3. Final Answer:

   To package the app and its environment for easy sharing and deployment -> Option D

4. Quick Check:

   Docker packages app + environment = B [OK]

Hint: Docker bundles app + environment for consistent deployment [OK]

Common Mistakes:

• Thinking Docker speeds up coding
• Confusing Docker with Django features
• Believing Docker replaces Django components

2. Which of the following is the correct way to start a Django app inside a Dockerfile?

easy

A. EXPOSE python manage.py runserver

B. RUN python manage.py runserver

C. CMD python manage.py runserver 0.0.0.0:8000

D. COPY python manage.py runserver

Solution

1. Step 1: Identify Dockerfile commands

   CMD sets the command to run when the container starts.

2. Step 2: Match command to Django app start

   Running 'python manage.py runserver 0.0.0.0:8000' starts the Django server accessible outside the container.

3. Final Answer:

   CMD python manage.py runserver 0.0.0.0:8000 -> Option C

4. Quick Check:

   CMD runs app on container start = A [OK]

Hint: Use CMD to run Django server with 0.0.0.0 binding [OK]

Common Mistakes:

• Using RUN instead of CMD to start server
• Misusing EXPOSE as a command
• Confusing COPY with execution commands

3. Given this Dockerfile snippet for a Django app:

FROM python:3.12-slim
WORKDIR /app
COPY requirements.txt ./
RUN pip install -r requirements.txt
COPY . .
CMD ["python", "manage.py", "runserver", "0.0.0.0:8000"]

What happens when you build and run this container?

medium

A. The container fails because requirements.txt is missing

B. The Django app runs and listens on port 8000 inside the container

C. The app runs but listens only on localhost inside the container

D. The container runs but does not start the Django server

Solution

1. Step 1: Analyze Dockerfile commands

   The Dockerfile installs dependencies, copies code, and runs the Django server on 0.0.0.0:8000.

2. Step 2: Understand container networking

   Binding to 0.0.0.0 means the app listens on all interfaces inside the container, ready for port mapping.

3. Final Answer:

   The Django app runs and listens on port 8000 inside the container -> Option B

4. Quick Check:

   CMD runs server on 0.0.0.0:8000 = A [OK]

Hint: 0.0.0.0 means app listens inside container for external access [OK]

Common Mistakes:

• Assuming app is accessible without port mapping
• Confusing 0.0.0.0 with localhost
• Thinking COPY runs code

4. You wrote this Dockerfile for your Django app:

FROM python:3.12
COPY . /app
WORKDIR /app
RUN pip install -r requirements.txt
CMD python manage.py runserver

When you build and run the container, the server does not start. What is the likely problem?

medium

A. The CMD command is missing the IP and port to bind to

B. The WORKDIR command is in the wrong place

C. The requirements.txt file is not copied before pip install

D. The base image python:3.12 does not support Django

Solution

1. Step 1: Check CMD command correctness

   Running 'python manage.py runserver' defaults to binding on 127.0.0.1, which is inside the container only.

2. Step 2: Understand container network binding

   Without binding to 0.0.0.0, the server is not accessible outside the container, so it seems like it does not start.

3. Final Answer:

   The CMD command is missing the IP and port to bind to -> Option A

4. Quick Check:

   Missing 0.0.0.0 binding causes server invisibility = D [OK]

Hint: Always bind Django server to 0.0.0.0 in Docker CMD [OK]

Common Mistakes:

• Assuming default runserver binds externally
• Thinking WORKDIR order breaks container
• Believing base image lacks Django support

5. You want to optimize your Django Docker container to reduce image size and speed up builds. Which approach is best?

hard

A. Use a multi-stage Dockerfile to install dependencies separately and copy only needed files

B. Install all Python packages globally on the host machine

C. Copy the entire project folder after installing dependencies

D. Use the latest full Python image without slimming

Solution

1. Step 1: Understand multi-stage builds

   Multi-stage Dockerfiles let you build dependencies in one stage and copy only necessary files to the final image, reducing size.

2. Step 2: Compare other options

   Installing packages on host or copying everything increases image size and reduces portability.

3. Final Answer:

   Use a multi-stage Dockerfile to install dependencies separately and copy only needed files -> Option A

4. Quick Check:

   Multi-stage builds optimize image size and build speed = C [OK]

Hint: Multi-stage Dockerfiles keep images small and builds fast [OK]

Common Mistakes:

• Installing packages outside container
• Copying unnecessary files increases size
• Using large base images without slimming