Development vs production Dockerfiles - Visual Side-by-Side Comparison

Process Flow - Development vs production Dockerfiles

Start: Write Dockerfile

↓

Choose environment

↓

Development

↓

Add dev tools

↓

Build dev image

↓

Run with debug

↓

Test & Debug

Shows the flow of creating Dockerfiles for development and production environments, highlighting different steps and goals.

Execution Sample

Docker

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

A simple Dockerfile that copies app code, installs dependencies, and runs the app.

Process Table

Step	Dockerfile Type	Action	Effect	Resulting Image Size
1	Development	Use full python:3.12 image	Includes dev tools and debugging	Large (~1GB)
2	Development	Copy all source code	Full app code available	No size change
3	Development	Install all dependencies	Ready to run with debug	Medium increase
4	Development	Set CMD to run app with debug	Container runs with debug mode	No size change
5	Production	Use python:3.12-slim image	Smaller base image	Small (~200MB)
6	Production	Copy only necessary files	Exclude tests and docs	Smaller size
7	Production	Install only runtime dependencies	No dev tools installed	Smaller increase
8	Production	Set CMD to run app normally	Runs app without debug	No size change
9	Exit	Build complete	Images ready for respective environments	-

💡 Both Dockerfiles built; development image is larger with debug tools, production image is smaller and optimized.

Status Tracker

Variable	Start	After Step 2	After Step 3	After Step 5	After Step 7	Final
Image Size	Base size	Base + source code	Base + source + deps	Slim base size	Slim base + runtime deps	Final image size
Debug Tools	None	Included in dev image	Included	None	None	Only in dev image
Source Code	None	Full copy	Full copy	Partial copy	Partial copy	Full in dev, partial in prod

Key Moments - 3 Insights

Why is the development image much larger than the production image?

Because the development Dockerfile includes full Python with dev tools and copies all source code, as shown in execution_table rows 1-4, increasing size.

Why do we copy fewer files in the production Dockerfile?

To keep the image small and secure by excluding tests and docs, as shown in execution_table row 6.

Why do we install fewer dependencies in production?

Production installs only runtime dependencies to reduce size and surface area, as shown in execution_table row 7.

Visual Quiz - 3 Questions

Look at the execution table, what is the image size after step 5 in the production Dockerfile?

A Large (~1GB)

B Small (~200MB)

C Medium increase

D No size change

💡 Hint

Check the 'Resulting Image Size' column at step 5 for production Dockerfile.

At which step does the development Dockerfile set the command to run the app with debug?

A Step 4

B Step 3

C Step 2

D Step 6

💡 Hint

Look at the 'Action' column for development Dockerfile steps in the execution table.

If we copied all files in production like in development, how would the image size change?

A It would stay the same

B It would become smaller

C It would become larger

D It would become zero

💡 Hint

Refer to variable_tracker row 'Image Size' comparing after step 2 and step 6.

Concept Snapshot

Development Dockerfile:
- Uses full image with dev tools
- Copies all source code
- Installs all dependencies
- Runs app with debug

Production Dockerfile:
- Uses slim image
- Copies only needed files
- Installs runtime dependencies only
- Runs app normally

Goal: Dev for debugging, Prod for small, fast, secure image.

Full Transcript

This visual execution compares development and production Dockerfiles. Development Dockerfiles use a full Python image with debugging tools, copy all source code, and install all dependencies, resulting in a larger image. Production Dockerfiles use a slim base image, copy only necessary files, and install only runtime dependencies, making the image smaller and optimized. The execution table shows step-by-step actions and their effects on image size and content. Variable tracking highlights how image size and included tools change. Key moments clarify why development images are larger and why production images exclude extra files and dependencies. The quiz tests understanding of image sizes, commands, and file copying differences. The snapshot summarizes the main differences and goals for each Dockerfile type.

Practice

1. Why do we use separate Dockerfiles for development and production environments?

easy

A. Because development needs debugging tools and production needs optimized images

B. Because production requires more debugging tools than development

C. Because development images must be smaller than production images

D. Because production Dockerfiles always include all source code

Solution

1. Step 1: Understand development Dockerfile purpose

   Development Dockerfiles include debugging tools and full dependencies to help developers test and debug easily.

2. Step 2: Understand production Dockerfile purpose

   Production Dockerfiles are optimized for smaller size, speed, and security, removing unnecessary tools.

3. Final Answer:

   Because development needs debugging tools and production needs optimized images -> Option A

4. Quick Check:

   Separate Dockerfiles fit different environment needs [OK]

Hint: Dev needs tools; prod needs speed and security [OK]

Common Mistakes:

• Thinking production needs more debugging tools
• Assuming development images must be smaller
• Believing production always includes all source code

2. Which of the following is a correct way to specify a base image in a production Dockerfile?

easy

A. BASE node:alpine

B. FROM node:latest

C. FROM alpine:node

D. FROM node:alpine

Solution

1. Step 1: Identify correct Dockerfile syntax for base image

   The correct keyword to specify a base image is 'FROM', followed by the image name and tag.

2. Step 2: Choose a lightweight base image for production

   For production, 'node:alpine' is a lightweight image suitable for smaller, optimized containers.

3. Final Answer:

   FROM node:alpine -> Option D

4. Quick Check:

   Use 'FROM' and lightweight image for production [OK]

Hint: Use 'FROM' and lightweight tags like alpine for production [OK]

Common Mistakes:

• Using 'BASE' instead of 'FROM'
• Incorrect image name order like 'alpine:node'
• Using 'latest' tag for production images

3. Given this production Dockerfile snippet:

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

What is the main effect of the npm install --production command?

medium

A. Installs all dependencies including devDependencies

B. Installs no dependencies at all

C. Installs only production dependencies, skipping devDependencies

D. Installs only devDependencies

Solution

1. Step 1: Understand npm install --production flag

   The '--production' flag tells npm to install only dependencies needed for running the app, skipping devDependencies used for development.

2. Step 2: Relate to production Dockerfile purpose

   Skipping devDependencies reduces image size and improves security for production environments.

3. Final Answer:

   Installs only production dependencies, skipping devDependencies -> Option C

4. Quick Check:

   npm install --production = only production deps [OK]

Hint: npm install --production skips devDependencies [OK]

Common Mistakes:

• Assuming it installs all dependencies
• Thinking it installs no dependencies
• Confusing devDependencies with production dependencies

4. You have a development Dockerfile that installs extra debugging tools but your production image is unexpectedly large. What is a likely cause?

medium

A. You used the development Dockerfile to build the production image

B. You forgot to copy source code in production Dockerfile

C. You used a smaller base image in production

D. You ran npm install without --production flag in development

Solution

1. Step 1: Identify cause of large production image

   If the production image is large, it may include unnecessary development tools and dependencies.

2. Step 2: Check which Dockerfile was used for production build

   Using the development Dockerfile for production will include extra tools, increasing image size.

3. Final Answer:

   You used the development Dockerfile to build the production image -> Option A

4. Quick Check:

   Wrong Dockerfile causes large production image [OK]

Hint: Use correct Dockerfile for each environment [OK]

Common Mistakes:

• Assuming missing source code causes large image
• Thinking smaller base image increases size
• Confusing npm install flags in development

5. You want to create a multi-stage Dockerfile that uses a full Node.js image for development and a lightweight Alpine image for production. Which snippet correctly achieves this?

hard

A. FROM node:alpine AS build
WORKDIR /app
COPY . .
RUN npm install
FROM node:alpine
COPY --from=build /app .
CMD ["node", "server.js"]

B. FROM node:latest AS build
WORKDIR /app
COPY . .
RUN npm install
FROM node:alpine
COPY --from=build /app .
CMD ["node", "server.js"]

C. FROM node:alpine AS build
WORKDIR /app
COPY . .
RUN npm install --production
FROM node:latest
COPY --from=build /app .
CMD ["node", "server.js"]

D. FROM node:latest
WORKDIR /app
COPY . .
RUN npm install
CMD ["node", "server.js"]

Solution

1. Step 1: Identify multi-stage build structure

   The first stage uses a full Node.js image (node:latest) for building with all tools, suitable for development.

2. Step 2: Use lightweight Alpine image for final production stage

   The second stage uses node:alpine to copy only necessary files from build stage, creating a smaller production image.

3. Step 3: Verify correct order and commands

   FROM node:latest AS build WORKDIR /app COPY . . RUN npm install FROM node:alpine COPY --from=build /app . CMD ["node", "server.js"] correctly uses 'AS build' for first stage and copies from it to the lightweight image.

4. Final Answer:

   FROM node:latest AS build WORKDIR /app COPY . . RUN npm install FROM node:alpine COPY --from=build /app . CMD ["node", "server.js"] -> Option B

5. Quick Check:

   Multi-stage: full image build + alpine production [OK]

Hint: Use full image first, then alpine with COPY --from=build [OK]

Common Mistakes:

• Using alpine for build stage losing dev tools
• Using latest image for final production stage
• Not using multi-stage COPY syntax