Development container patterns in Docker - Commands & Configuration

Introduction

Development container patterns help you create isolated environments for coding. They solve the problem of different tools or libraries conflicting on your computer by packaging everything your app needs inside a container.

When you want to ensure your app runs the same way on any computer without setup issues

When you need to share your development environment with teammates easily

When you want to test your app with different versions of tools without changing your main system

When you want to keep your computer clean from many installed dependencies

When you want to quickly start coding without spending time installing software

Config File - Dockerfile

Dockerfile

FROM python:3.11-slim

WORKDIR /app

COPY requirements.txt ./
RUN pip install --no-cache-dir -r requirements.txt

COPY . ./

CMD ["python", "app.py"]

This Dockerfile creates a development container for a Python app.

FROM python:3.11-slim sets the base image with Python 3.11.

WORKDIR /app sets the working directory inside the container.

COPY requirements.txt ./ copies the dependencies list.

RUN pip install installs the dependencies.

COPY . ./ copies your app code.

CMD runs the app when the container starts.

Commands

This command builds the Docker image named 'my-python-dev' using the Dockerfile in the current folder. It packages your app and its dependencies.

Terminal

docker build -t my-python-dev .

Expected Output

Sending build context to Docker daemon  4.096kB

Step 1/6 : FROM python:3.11-slim

 ---> 123abc456def

Step 2/6 : WORKDIR /app

 ---> Using cache

 ---> 789ghi012jkl

Step 3/6 : COPY requirements.txt ./

 ---> Using cache

 ---> mno345pqr678

Step 4/6 : RUN pip install --no-cache-dir -r requirements.txt

 ---> Running in abc123def456

Collecting flask

  Downloading Flask-2.3.2-py3-none-any.whl (96 kB)

Installing collected packages: flask

Successfully installed flask-2.3.2

Removing intermediate container abc123def456

 ---> stu901vwx234

Step 5/6 : COPY . ./

 ---> 567yzab890cd

Step 6/6 : CMD ["python", "app.py"]

 ---> Running in efg567hij890

Removing intermediate container efg567hij890

 ---> klm123nop456

Successfully built klm123nop456

Successfully tagged my-python-dev:latest

→

-t - Names and tags the image for easy reference

This command runs the container interactively, removes it after exit, mounts your current folder inside the container for live code changes, and maps port 5000 so you can access the app from your browser.

Terminal

docker run -it --rm -v $(pwd):/app -p 5000:5000 my-python-dev

Expected Output

 * Serving Flask app 'app'

 * Debug mode: off

WARNING: This is a development server. Do not use it in a production deployment.

 * Running on http://0.0.0.0:5000/ (Press CTRL+C to quit)

→

-it - Runs container interactively with a terminal

→

--rm - Removes container after it stops to keep system clean

→

-v - Mounts current directory inside container for live code editing

→

-p - Maps container port to host port for access

This command lists running containers so you can check if your development container is active.

Terminal

docker ps

Expected Output

CONTAINER ID   IMAGE           COMMAND                  CREATED          STATUS          PORTS                    NAMES

klm123nop456   my-python-dev   "python app.py"          10 seconds ago   Up 9 seconds    0.0.0.0:5000->5000/tcp   loving_borg

This command stops the running container named 'loving_borg' to end your development session cleanly.

Terminal

docker stop loving_borg

Expected Output

loving_borg

Key Concept

If you remember nothing else from this pattern, remember: mounting your code folder into the container lets you edit code live without rebuilding the image.

Common Mistakes

Not mounting the code folder with -v, so code changes inside the container are lost after rebuild

Without mounting, the container uses the code copied at build time, so live edits on your computer don't affect the running app

Always use -v $(pwd):/app to mount your current folder inside the container for live development

Not exposing or mapping the app port with -p, so you cannot access the app from your browser

The container runs the app internally, but without port mapping, your computer cannot reach it

Use -p 5000:5000 (or your app port) to map container port to your host

Running the container without --rm, leaving stopped containers cluttering your system

Stopped containers take disk space and make management harder

Use --rm to automatically remove the container after you stop it

Summary

Build a Docker image with your app and dependencies using 'docker build'.

Run the container with code folder mounted and ports mapped for live development.

Use 'docker ps' to check running containers and 'docker stop' to end sessions cleanly.

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