Development container patterns in Docker - Cheat Sheet & Quick Revision

Recall & Review

beginner

What is a development container?

A development container is a lightweight, isolated environment that contains all the tools and dependencies needed to build and test software. It helps keep your workspace clean and consistent.

beginner

Why use a development container pattern?

Using a development container pattern ensures that all developers work in the same environment, avoiding "it works on my machine" problems and speeding up setup time.

intermediate

What is the 'bind mount' pattern in development containers?

The bind mount pattern links your local source code folder to the container, so changes you make on your computer immediately appear inside the container for testing or running.

intermediate

Explain the 'multi-stage build' pattern in Docker development containers.

Multi-stage builds let you use one container to build your app and another smaller container to run it. This keeps the final container small and fast by removing build tools.

intermediate

What is the benefit of using a 'base development image' pattern?

A base development image contains common tools and libraries shared across projects. It saves time by not reinstalling the same tools for every project and keeps environments consistent.

What does a bind mount do in a development container?

A Removes unused files from the container

B Creates a copy of the container image

C Links local files to the container for live updates

D Builds the container in multiple steps

A bind mount connects your local source code folder to the container, so changes are reflected immediately.

Why use multi-stage builds in Docker?

A To share files between containers

B To keep the final container small by separating build and runtime

C To run multiple containers at once

D To speed up network connections

Multi-stage builds separate building and running steps, reducing the final container size.

What problem does a development container pattern mainly solve?

A Inconsistent development environments

B Slow internet speed

C Lack of storage space

D Hardware failures

Development containers ensure all developers use the same environment, avoiding inconsistencies.

What is a base development image?

A A backup of your local machine

B A container that runs only databases

C A temporary container for testing

D An image with common tools shared across projects

A base development image includes common tools and libraries to reuse across projects.

Which pattern allows live code changes without rebuilding the container?

A Bind mount

B Multi-stage build

C Base image

D Container snapshot

Bind mounts let you edit code locally and see changes immediately inside the container.

Describe the main benefits of using development container patterns in a team project.

Think about how containers help teams work smoothly together.

Explain how the bind mount and multi-stage build patterns work together in a development container workflow.

Consider how code changes and container size are managed.

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