Dockerfile for microservices - System Design Exercise

Design: Microservices Containerization with Docker

Design Dockerfiles for individual microservices including base image selection, layering, environment configuration, and security best practices. Out of scope: orchestration, service discovery, or CI/CD pipeline setup.

Functional Requirements

FR1: Each microservice must be containerized using Docker.

FR2: Containers should be lightweight and start quickly.

FR3: Dockerfiles must support easy updates and debugging.

FR4: Images should be secure and follow best practices.

FR5: Support environment variable configuration for different environments.

Non-Functional Requirements

NFR1: Image size should be minimized to reduce deployment time.

NFR2: Build time should be optimized for CI/CD pipelines.

NFR3: Containers must run consistently across development, testing, and production.

NFR4: Use official base images where possible for security and support.

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

Key Components

Base Docker image selection (e.g., official language images, Alpine variants)

Multi-stage builds to reduce image size

Environment variable injection

Health checks and debugging tools

Security best practices (non-root user, minimal permissions)

Design Patterns

Multi-stage Docker builds

Immutable infrastructure pattern

12-factor app principles for configuration

Layer caching optimization

Security hardening in Dockerfiles

Reference Architecture

Microservice Dockerfile Design

+-------------------+
| Base Image        |
+-------------------+
          |
          v
+-------------------+
| Install Dependencies|
+-------------------+
          |
          v
+-------------------+
| Copy Source Code   |
+-------------------+
          |
          v
+-------------------+
| Build Application  |
+-------------------+
          |
          v
+-------------------+
| Set Environment    |
+-------------------+
          |
          v
+-------------------+
| Define Entrypoint  |
+-------------------+

Components

Base Image

Official language runtime images (e.g., python:3.12-slim, node:18-alpine)

Provides the minimal OS and language runtime environment for the microservice.

Dependency Installation

Package managers (pip, npm, apt) inside Dockerfile

Installs required libraries and dependencies for the microservice.

Source Code Copy

Docker COPY command

Copies microservice source code into the container.

Build Stage

Multi-stage Docker build

Compiles or prepares the application, reducing final image size.

Environment Configuration

Docker ENV and ARG instructions

Sets environment variables for configuration and secrets injection.

Entrypoint

Docker ENTRYPOINT or CMD

Defines the command to run the microservice when the container starts.

Request Flow

1. Developer writes microservice code and Dockerfile.

2. Dockerfile uses a base image matching the microservice language.

3. Dependencies are installed inside the container image.

4. Source code is copied into the image.

5. Multi-stage build compiles or prepares the app, discarding build-only layers.

6. Environment variables are set for runtime configuration.

7. Entrypoint is defined to start the microservice process.

8. Docker image is built and pushed to a registry.

9. Container runs consistently across environments using the built image.

Database Schema

Not applicable for Dockerfile design.

Scaling Discussion

Bottlenecks

Large image sizes causing slow deployment and startup.

Slow build times impacting CI/CD pipeline speed.

Security vulnerabilities from outdated base images or unnecessary packages.

Difficulty managing environment-specific configurations securely.

Solutions

Use multi-stage builds to keep final images small.

Choose minimal base images like Alpine variants.

Cache dependencies and layers effectively during builds.

Regularly update base images and dependencies for security patches.

Use Docker secrets or environment injection tools for secure config management.

Interview Tips

Time: Spend 10 minutes understanding microservice language and requirements, 15 minutes designing Dockerfile layers and explaining choices, 10 minutes discussing scaling and security considerations, 10 minutes answering questions.

Explain base image choice and why minimal images matter.

Describe multi-stage builds and how they reduce image size.

Discuss environment variable usage for configuration.

Highlight security best practices like running as non-root user.

Mention caching strategies to speed up builds.

Address how Dockerfiles support consistent deployments across environments.

Practice

1. What is the main purpose of a Dockerfile in a microservices project?

easy

A. To monitor the performance of the microservice

B. To write the microservice's business logic code

C. To define how to build a container image for the microservice

D. To deploy the microservice to the cloud

Solution

1. Step 1: Understand the role of Dockerfile

   A Dockerfile contains instructions to build a container image, including base image, dependencies, and commands.

2. Step 2: Differentiate from other tasks

   Writing code, monitoring, and deployment are separate tasks outside the Dockerfile's scope.

3. Final Answer:

   To define how to build a container image for the microservice -> Option C

4. Quick Check:

   Dockerfile = build container image [OK]

Hint: Dockerfile builds images, not code or deployment [OK]

Common Mistakes:

• Confusing Dockerfile with source code files
• Thinking Dockerfile handles deployment
• Assuming Dockerfile monitors services

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

easy

A. BASE python:3.12-slim

B. START python:3.12-slim

C. IMAGE python:3.12-slim

D. FROM python:3.12-slim

Solution

1. Step 1: Recall Dockerfile base image syntax

   The Dockerfile uses the FROM keyword to specify the base image.

2. Step 2: Verify other options

   BASE, IMAGE, and START are not valid Dockerfile instructions.

3. Final Answer:

   FROM python:3.12-slim -> Option D

4. Quick Check:

   Base image starts with FROM [OK]

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

Common Mistakes:

• Using incorrect keywords like BASE or IMAGE
• Forgetting the colon between image name and tag
• Writing lowercase FROM

3. Given this Dockerfile snippet:

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

What happens when you build and run this container?

medium

A. The container fails because WORKDIR is missing

B. The container runs the server.js file using Node.js

C. The container installs Python dependencies

D. The container runs npm start automatically

Solution

1. Step 1: Analyze Dockerfile commands

   The base image is Node.js 18 Alpine. It sets working directory to /app, copies package.json, runs npm install, copies all files, then runs node server.js.

2. Step 2: Understand container behavior

   On running, the container executes node server.js, starting the Node.js app. No Python involved. WORKDIR is present, so no failure.

3. Final Answer:

   The container runs the server.js file using Node.js -> Option B

4. Quick Check:

   CMD runs node server.js [OK]

Hint: CMD runs the specified command when container starts [OK]

Common Mistakes:

• Assuming Python dependencies install
• Thinking WORKDIR is missing
• Confusing CMD with npm start

4. Identify the error in this Dockerfile snippet for a Python microservice:

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

medium

A. The WORKDIR should be set before copying requirements.txt

B. The pip install command is missing the --user flag

C. The CMD syntax is incorrect

D. The base image version is invalid

Solution

1. Step 1: Check file paths and working directory order

   The requirements.txt is copied to /app/, but WORKDIR is set after. So pip install runs in root, not /app, causing file not found error.

2. Step 2: Correct order for Dockerfile commands

   Set WORKDIR /app before copying files and running commands to ensure correct paths.

3. Final Answer:

   The WORKDIR should be set before copying requirements.txt -> Option A

4. Quick Check:

   Set WORKDIR before file operations [OK]

Hint: Set WORKDIR before copying files and running commands [OK]

Common Mistakes:

• Running pip install before setting WORKDIR
• Misunderstanding CMD JSON syntax
• Assuming base image version is wrong

5. You want to optimize a Dockerfile for a Java microservice to reduce build time and image size. Which change is best to achieve this?

FROM openjdk:17
COPY . /app
WORKDIR /app
RUN ./gradlew build
CMD ["java", "-jar", "build/libs/app.jar"]

hard

A. Copy only build.gradle and settings.gradle first, run gradlew build, then copy the rest

B. Remove the WORKDIR instruction

C. Use CMD java -jar build/libs/app.jar without JSON array

D. Change base image to openjdk:8

Solution

1. Step 1: Understand Docker layer caching

   Docker caches layers. Copying only build files first and running build caches dependencies, so changes in source code don't rebuild dependencies.

2. Step 2: Apply multi-step copy for optimization

   Copy build.gradle and settings.gradle first, run gradlew build, then copy source files. This reduces rebuild time and image size.

3. Final Answer:

   Copy only build.gradle and settings.gradle first, run gradlew build, then copy the rest -> Option A

4. Quick Check:

   Optimize Dockerfile with layered caching [OK]

Hint: Copy build files first to leverage Docker cache [OK]

Common Mistakes:

• Removing WORKDIR breaks path context
• Using shell form CMD can cause signal issues
• Downgrading base image unnecessarily