Why WORKDIR instruction for directory in Docker? - Purpose & Use Cases

The Big Idea

What if you could stop repeating long folder paths and avoid silly mistakes in your Docker builds?

The Scenario

Imagine you are building a Docker image and need to run several commands inside a specific folder. Without setting a working directory, you must type the full path every time you want to access files or run commands there.

The Problem

This manual way is slow and error-prone because you have to repeat long paths in every command. It's easy to make typos or forget to change directories, causing build failures or unexpected results.

The Solution

The WORKDIR instruction sets a default directory inside the container. After setting it once, all following commands run inside that folder automatically, making your Dockerfile cleaner and less error-prone.

Before vs After

✗ Before

RUN mkdir -p /app && cd /app && touch file.txt
RUN cd /app && ls

✓ After

WORKDIR /app
RUN touch file.txt
RUN ls

What It Enables

It enables simpler, clearer Dockerfiles where commands naturally run in the right folder without repeating paths.

Real Life Example

When building a web app image, you can set WORKDIR to the app folder so all build steps like installing dependencies and copying files happen inside that folder automatically.

Key Takeaways

Manually changing directories in Dockerfiles is repetitive and error-prone.

WORKDIR sets a default folder for all following commands.

This makes Dockerfiles easier to read and maintain.

Practice

1. What does the WORKDIR instruction do in a Dockerfile?

easy

A. Runs a command when the container starts

B. Deletes files in the container

C. Sets the working directory for commands inside the container

D. Specifies the base image for the container

Solution

1. Step 1: Understand the purpose of WORKDIR

   The WORKDIR instruction sets the folder where subsequent commands run inside the container.

2. Step 2: Compare with other options

   Options A, B, and C describe other Dockerfile instructions or actions, not WORKDIR.

3. Final Answer:

   Sets the working directory for commands inside the container -> Option C

4. Quick Check:

   WORKDIR sets folder for commands [OK]

Hint: WORKDIR sets folder for commands inside container [OK]

Common Mistakes:

• Confusing WORKDIR with CMD or ENTRYPOINT
• Thinking WORKDIR deletes files
• Assuming WORKDIR sets base image

2. Which of the following is the correct syntax to set the working directory to /app in a Dockerfile?

easy

A. WORKDIR /app

B. WORKDIR: /app

C. WORKDIR = /app

D. WORKDIR(/app)

Solution

1. Step 1: Recall Dockerfile syntax for WORKDIR

   The correct syntax is WORKDIR /path without any symbols like colon, equals, or parentheses.

2. Step 2: Check each option

   Options A, B, and D use invalid syntax for Dockerfile instructions.

3. Final Answer:

   WORKDIR /app -> Option A

4. Quick Check:

   WORKDIR uses space, no symbols [OK]

Hint: WORKDIR uses space before path, no symbols [OK]

Common Mistakes:

• Adding colon or equals sign after WORKDIR
• Using parentheses around path
• Forgetting the space between WORKDIR and path

3. Given this Dockerfile snippet:

FROM alpine
WORKDIR /app
RUN touch file.txt
WORKDIR /app/data
RUN echo "hello" > message.txt

Where will the file message.txt be created inside the container?

medium

A. /app/data/file.txt

B. /app/message.txt

C. /message.txt

D. /app/data/message.txt

Solution

1. Step 1: Follow WORKDIR changes

   The first WORKDIR sets directory to /app. The second WORKDIR changes it to /app/data.

2. Step 2: Locate where message.txt is created

   The command RUN echo "hello" > message.txt runs in /app/data, so the file is created there.

3. Final Answer:

   /app/data/message.txt -> Option D

4. Quick Check:

   Last WORKDIR sets folder for commands [OK]

Hint: Last WORKDIR sets current folder for commands [OK]

Common Mistakes:

• Assuming files created in first WORKDIR folder
• Confusing file paths with root directory
• Ignoring multiple WORKDIR instructions

4. You wrote this Dockerfile snippet:

WORKDIR /app
RUN ls
WORKDIR app/data
RUN ls

Why does the second WORKDIR cause an unexpected result?

medium

A. Because WORKDIR cannot be used twice

B. Because relative path 'app/data' resolves to /app/app/data instead of /app/data

C. Because RUN ls is invalid syntax

D. Because /app directory is not created automatically

Solution

1. Step 1: Understand relative paths in WORKDIR

   The second WORKDIR uses a relative path app/data, which is relative to the current directory /app. So it tries to set /app/app/data.

2. Step 2: Understand relative path resolution

   Docker creates /app/app/data automatically if needed, but this nested path is usually unintended if /app/data was desired.

3. Step 3: Identify actual issue

   Relative path app/data is a mistake; use data or absolute /app/data instead.

4. Final Answer:

   Because relative path 'app/data' resolves to /app/app/data instead of /app/data -> Option B

5. Quick Check:

   Relative WORKDIR paths resolve from current dir [OK]

Hint: Relative WORKDIR paths are inside current folder [OK]

Common Mistakes:

• Thinking WORKDIR cannot be used multiple times
• Assuming RUN ls is invalid
• Believing /app is not auto-created

5. You want to create a Dockerfile that:
- Sets working directory to /app
- Creates a subfolder logs
- Changes working directory to logs
- Creates a file app.log

Which Dockerfile snippet correctly does this?

hard

A. WORKDIR /app
RUN mkdir logs
WORKDIR logs
RUN touch app.log

B. WORKDIR /app/logs
RUN mkdir logs
WORKDIR /app
RUN touch app.log

C. RUN mkdir /app/logs
WORKDIR /app/logs
RUN touch app.log

D. WORKDIR /app
RUN touch app.log
WORKDIR logs
RUN mkdir logs

Solution

1. Step 1: Set working directory to /app and create logs folder

   WORKDIR /app RUN mkdir logs WORKDIR logs RUN touch app.log sets WORKDIR to /app and runs mkdir logs to create the subfolder.

2. Step 2: Change WORKDIR to logs and create app.log

   Then it changes WORKDIR to logs (relative to /app) and creates app.log inside it.

3. Step 3: Verify other options

   WORKDIR /app/logs RUN mkdir logs WORKDIR /app RUN touch app.log sets WORKDIR incorrectly and creates logs folder in wrong place. RUN mkdir /app/logs WORKDIR /app/logs RUN touch app.log creates logs folder but misses initial WORKDIR. WORKDIR /app RUN touch app.log WORKDIR logs RUN mkdir logs creates app.log before logs folder and changes WORKDIR before folder exists.

4. Final Answer:

   WORKDIR /app RUN mkdir logs WORKDIR logs RUN touch app.log -> Option A

5. Quick Check:

   Create folder before changing WORKDIR [OK]

Hint: Create folder before changing WORKDIR into it [OK]

Common Mistakes:

• Changing WORKDIR before folder exists
• Creating files in wrong directory
• Using absolute path incorrectly