Dockerfile for microservices - Practice Problems & Coding Challenges

Challenge - 5 Problems

💻 Command Output

intermediate

What is the output of this Docker build command?

Given the following Dockerfile for a Node.js microservice, what will be the output when running docker build -t myservice .?

Microservices

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

A Successfully built image with tag 'myservice' and no errors

B Error: 'package.json' not found during COPY step

C Error: npm install failed due to missing package.json

D Build hangs indefinitely at RUN npm install

💡 Hint

Check if the Dockerfile copies package.json before running npm install.

The Dockerfile copies package.json before running npm install, so dependencies install correctly. The build completes successfully with the image tagged 'myservice'.

❓ Configuration

intermediate

Which Dockerfile snippet correctly sets environment variables for a microservice?

Choose the Dockerfile snippet that correctly sets environment variables PORT to 8080 and NODE_ENV to production.

A ENV PORT 8080 NODE_ENV production

B ENV PORT:8080 NODE_ENV:production

C ENV PORT=8080 NODE_ENV=production

D ENV PORT=8080; NODE_ENV=production

💡 Hint

Look for the correct syntax to set multiple environment variables in one ENV instruction.

The correct syntax uses ENV VAR=value pairs separated by spaces. Option C correctly sets both variables.

❓ Troubleshoot

advanced

Why does this Dockerfile cause a large image size?

Consider this Dockerfile for a Python microservice:

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

Why might this Docker image be larger than necessary?

A It does not specify a user, causing permission issues

B It uses an outdated Python base image

C It runs pip install without caching dependencies

D It copies all files including unnecessary ones like tests and docs

💡 Hint

Think about what files get included in the image when using COPY . ..

Copying the entire context includes unnecessary files like tests and documentation, increasing image size. Using a .dockerignore file can exclude these.

🔀 Workflow

advanced

What is the correct order of Dockerfile instructions for efficient caching?

Arrange these Dockerfile instructions in the best order to optimize Docker layer caching for a Node.js microservice:

A 1,2,3,4

B 2,1,3,4

C 3,1,2,4

D 1,3,2,4

💡 Hint

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

Copying package.json and running npm install first allows Docker to cache dependencies. Copying the rest of the code later avoids reinstalling packages unnecessarily.

✅ Best Practice

expert

Which Dockerfile practice improves security for microservices?

Which option shows the best Dockerfile practice to improve security by avoiding running the container as root?

A USER node

B RUN adduser appuser && USER appuser

C USER 1000

D RUN chmod 777 /app && USER root

💡 Hint

Consider creating a non-root user and switching to it.

Option B creates a new user and switches to it, reducing security risks. Option B uses an existing user but may not exist in all images. Option B uses a numeric ID without context. Option B keeps root user with insecure permissions.

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