Development container patterns in Docker - Step-by-Step Execution

Process Flow - Development container patterns

Start: Define base image

↓

Add dependencies & tools

↓

Set working directory

↓

Copy source code

↓

Expose ports & volumes

↓

Define entrypoint or command

↓

Build container image

↓

Run container for development

↓

Code changes reflected via mounted volume

↓

Debug & test inside container

↓

Stop container when done

This flow shows how a development container is built step-by-step, from base image to running with live code changes.

Execution Sample

Docker

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

This Dockerfile sets up a Python development container with dependencies installed and runs the app.

Process Table

Step	Dockerfile Instruction	Action	Resulting Image State	Notes
1	FROM python:3.12-slim	Set base image	Image starts from python 3.12 slim	Base OS and Python ready
2	WORKDIR /app	Set working directory	Working directory set to /app	Commands run inside /app
3	COPY requirements.txt ./	Copy requirements file	requirements.txt available in /app	Needed for dependency install
4	RUN pip install -r requirements.txt	Install dependencies	Python packages installed	App dependencies ready
5	COPY . ./	Copy source code	All app files copied to /app	App code ready to run
6	CMD ["python", "app.py"]	Set default command	Container runs python app.py on start	Defines container behavior
7	docker build -t dev-container .	Build image	Image named dev-container created	Ready to run container
8	docker run -v $(pwd):/app -p 5000:5000 dev-container	Run container with volume and port	Container runs with live code sync	Code changes reflect immediately
9	Modify code on host	Edit source files	Changes appear inside container	Live development enabled
10	Stop container	End session	Container stops running	Development session ends

💡 Container stops when developer finishes coding or testing

Status Tracker

Variable	Start	After Step 3	After Step 5	After Step 8	Final
Image Layers	Empty	Base python:3.12-slim	Added requirements.txt and source code	Built image with all files and dependencies	Image ready for development
Container State	Not running	Not running	Not running	Running with volume mounted	Stopped after development

Key Moments - 3 Insights

Why do we mount the source code as a volume instead of copying it only once?

Mounting the source code as a volume (see step 8) allows live code changes on the host to immediately appear inside the container without rebuilding the image (step 5 only copies once). This enables fast development feedback.

What happens if we don't set the working directory with WORKDIR?

Without WORKDIR (step 2), commands like COPY and RUN might place files or run in unexpected locations, making the container harder to manage. Setting WORKDIR ensures all actions happen inside /app.

Why do we separate installing dependencies from copying source code?

Separating RUN pip install (step 4) from copying source code (step 5) helps Docker cache dependencies. If source code changes but requirements.txt doesn't, Docker reuses the cached layer, speeding up builds.

Visual Quiz - 3 Questions

Look at the execution table at step 8. What is the main benefit of running the container with the volume option?

A The container image size is reduced

B Code changes on the host immediately reflect inside the container

C The container runs faster without dependencies

D The container automatically restarts on failure

💡 Hint

Check the 'Resulting Image State' and 'Notes' columns at step 8 in the execution table

At which step does the container image get created and ready to run?

A Step 7

B Step 5

C Step 3

D Step 9

💡 Hint

Look for the 'docker build' command in the execution table

If we remove the WORKDIR instruction, what would likely happen?

A The container would run faster

B Dependencies would not install

C Files might be copied to unexpected locations

D The container would not start

💡 Hint

Refer to the key moment about WORKDIR and step 2 in the execution table

Concept Snapshot

Development container patterns:
- Use a base image (e.g., python:3.12-slim)
- Set WORKDIR for consistent paths
- Copy dependencies file and install them
- Copy source code separately
- Use volumes to sync live code changes
- Define CMD or ENTRYPOINT to run app
- Build and run container with port and volume mappings
- Enables fast, isolated development environment

Full Transcript

Development container patterns involve creating a container image starting from a base image like python:3.12-slim. We set a working directory to keep commands organized. We copy the dependencies file and install packages before copying the full source code. This separation helps caching and speeds up rebuilds. When running the container, we mount the source code as a volume so that changes on the host immediately reflect inside the container, enabling live development. The container runs the app using a defined command. This pattern creates an isolated, reproducible environment for coding, testing, and debugging without affecting the host system.

Practice

1. What is the main purpose of using a development container in Docker?

easy

A. To create a consistent coding environment isolated from your main computer

B. To speed up your internet connection

C. To permanently delete files from your computer

D. To run games inside Docker

Solution

1. Step 1: Understand what a development container does

   Development containers provide a consistent environment for coding by isolating tools and dependencies.

2. Step 2: Match the purpose to the options

   Only To create a consistent coding environment isolated from your main computer describes creating a consistent, isolated coding environment.

3. Final Answer:

   To create a consistent coding environment isolated from your main computer -> Option A

4. Quick Check:

   Development container purpose = consistent isolated environment [OK]

Hint: Think: 'Is this about coding environment isolation?' [OK]

Common Mistakes:

• Confusing containers with internet speed tools
• Thinking containers delete files permanently
• Assuming containers run unrelated apps like games

2. Which Dockerfile instruction is used to specify the base image for a development container?

easy

A. RUN

B. CMD

C. FROM

D. COPY

Solution

1. Step 1: Identify Dockerfile instructions

   Dockerfile uses specific instructions like FROM, RUN, COPY, CMD for different purposes.

2. Step 2: Match instruction to base image

   FROM sets the base image; RUN executes commands; COPY copies files; CMD sets default command.

3. Final Answer:

   FROM -> Option C

4. Quick Check:

   Base image instruction = FROM [OK]

Hint: Base image always starts with FROM in Dockerfile [OK]

Common Mistakes:

• Using RUN to set base image
• Confusing COPY with base image
• Thinking CMD sets base image

3. Given this Dockerfile snippet for a development container:

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

What happens when you run this container?

medium

A. The container fails because WORKDIR is missing

B. The container runs but does not install dependencies

C. The container runs but does not start app.py

D. The container runs Python 3.12, installs dependencies, and starts app.py

Solution

1. Step 1: Analyze Dockerfile commands

   FROM sets Python 3.12 base, WORKDIR sets /app, COPY copies files, RUN installs dependencies, CMD runs app.py.

2. Step 2: Predict container behavior

   All steps are correct and complete, so container installs dependencies and runs app.py.

3. Final Answer:

   The container runs Python 3.12, installs dependencies, and starts app.py -> Option D

4. Quick Check:

   Dockerfile commands = install and run app [OK]

Hint: Check each Dockerfile line for its role [OK]

Common Mistakes:

• Ignoring RUN command effect
• Assuming WORKDIR is missing
• Thinking CMD does not start app

4. You wrote this Dockerfile for a development container:

FROM node:18
WORKDIR /app
COPY package.json .
RUN npm install
COPY . .
CMD ["node", "server.js"]

But when you build and run, the app crashes with missing modules error. What is the likely problem?

medium

A. You did not copy package-lock.json before npm install

B. The COPY . . after RUN npm install overwrites node_modules with host files if node_modules not in .dockerignore

C. You copied package.json before npm install but did not copy other files before npm install

D. You copied package.json after npm install

Solution

1. Step 1: Review Dockerfile copy and install order

   package.json copied first for npm install (good for caching), then full COPY . . after.

2. Step 2: Identify the overwrite issue

   RUN npm install builds linux-compatible node_modules, but COPY . . copies host files including node_modules/ (wrong platform), overwriting it and causing missing modules or binary errors. Fix: node_modules in .dockerignore.

3. Final Answer:

   The COPY . . after RUN npm install overwrites node_modules with host files if node_modules not in .dockerignore -> Option B

4. Quick Check:

   Node Dockerfile pattern = COPY pkg, install, COPY src, .dockerignore node_modules [OK]

Hint: Copy package.json -> npm install -> COPY . . but .dockerignore node_modules/ [OK]

Common Mistakes:

• Copying package.json after npm install
• Confusing package-lock.json necessity
• Assuming source files must be copied before npm install

5. You want to create a development container that automatically reloads your Node.js app when you change source files on your host machine. Which pattern should you use?

hard

A. Use a volume mount to sync source files and run nodemon inside the container

B. Copy source files once during build and restart container manually on changes

C. Build a new image every time source files change

D. Run the app outside Docker and only use Docker for dependencies

Solution

1. Step 1: Understand live reload needs

   Live reload requires syncing source files between host and container and a watcher like nodemon inside container.

2. Step 2: Match pattern to options

   Volume mount syncs files live; nodemon watches and reloads app automatically.

3. Final Answer:

   Use a volume mount to sync source files and run nodemon inside the container -> Option A

4. Quick Check:

   Live reload = volume mount + nodemon [OK]

Hint: Volume mount + nodemon = auto reload dev container [OK]

Common Mistakes:

• Copying files only once without sync
• Rebuilding image on every change
• Running app outside Docker defeats container purpose