Development container patterns in Docker - Practice Problems & Coding Challenges

Challenge - 5 Problems

💻 Command Output

intermediate

Output of multi-stage Docker build

Consider this Dockerfile using multi-stage build pattern:

FROM node:18 AS builder
WORKDIR /app
COPY package.json .
RUN npm install
COPY . .
RUN npm run build

FROM nginx:alpine
COPY --from=builder /app/build /usr/share/nginx/html

What will be the output when running docker images after building this Dockerfile with docker build -t myapp .?

A Only the 'builder' image remains, tagged as 'myapp', containing all build layers

B Two images: one intermediate 'builder' image and one final 'myapp' image with nginx and app files

C No images are created because multi-stage builds do not produce images

D An image named 'myapp' with a single layer containing only the nginx base and the built app files

💡 Hint

Multi-stage builds keep only the final stage as the image unless you tag intermediate stages.

Multi-stage builds produce a single final image named as specified. Intermediate stages are not saved as separate images unless explicitly tagged.

❓ Configuration

intermediate

Correct Dockerfile pattern for caching dependencies

You want to optimize your Dockerfile to cache dependencies and avoid reinstalling them on every build. Which Dockerfile snippet correctly implements this pattern?

A

COPY . ./
RUN npm install

B

COPY package.json ./
RUN npm install
COPY . ./

C

RUN npm install
COPY package.json ./
COPY . ./

D

COPY . ./
RUN npm install
COPY package.json ./

💡 Hint

Think about which files change less often and how Docker caches layers.

Copying package.json first and running npm install before copying the rest allows Docker to cache the dependencies layer if package.json hasn't changed.

❓ Troubleshoot

advanced

Why does my container fail to start with permission denied?

You have this Dockerfile snippet:

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

When running the container, you get a permission denied error on app.py. What is the most likely cause?

A app.py does not have execute permissions inside the container

B The WORKDIR /app does not exist in the container

C pip install failed and dependencies are missing

D The CMD syntax is incorrect and causes failure

💡 Hint

Check file permissions inside the container for scripts.

COPY preserves file permissions from the host. If app.py lacks execute permission, the container cannot run it, causing permission denied.

🔀 Workflow

advanced

Order of steps in a development container workflow

Arrange these steps in the correct order for a typical development container workflow:
1. Run the container interactively
2. Write or edit code on the host
3. Build the Docker image
4. Mount source code into the container

A 4,1,2,3

B 1,4,2,3

C 1,2,4,3

D 1,2,3,4

💡 Hint

Think about when you build, mount, and edit code during development.

First build the image, then mount the source code, then edit code on the host, finally run the container interactively to see changes live.

✅ Best Practice

expert

Choosing the best base image for a development container

You want a development container for a Node.js app that is fast to build, small in size, and supports debugging tools. Which base image is the best choice?

A node:18-slim

B node:18-alpine

C node:18-buster

D node:18

💡 Hint

Consider trade-offs between image size, build speed, and tool availability.

node:18-slim balances small size and compatibility with debugging tools better than alpine (too minimal) or full images (larger).

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