WORKDIR instruction for directory in Docker - Step-by-Step Execution

Process Flow - WORKDIR instruction for directory

Start Dockerfile

↓

Read WORKDIR instruction

↓

Check if directory exists

Yes No↓

Set as current

↓

Use directory for next commands

↓

Continue build

Docker reads the WORKDIR line, checks if the directory exists, creates it if needed, then sets it as the working directory for following commands.

Execution Sample

Docker

FROM alpine
WORKDIR /app
RUN touch file.txt

Sets /app as working directory, creates it if missing, then runs command inside /app.

Process Table

Step	Instruction	Action	Directory State	Current Working Directory
1	FROM alpine	Start from alpine base image	/	/
2	WORKDIR /app	Check /app exists? No, create /app	/app created	/app
3	RUN touch file.txt	Run command inside /app	/app exists with file.txt	/app
4	End	Build continues with /app as working dir	/app exists with file.txt	/app

💡 WORKDIR sets /app as current directory; created if missing; subsequent commands run there.

Status Tracker

Variable	Start	After Step 2	After Step 3	Final
Current Directory	/	/app	/app	/app
Directory /app Exists	No	Yes	Yes	Yes
Files in /app	None	None	file.txt	file.txt

Key Moments - 2 Insights

Why does Docker create the directory if it does not exist when using WORKDIR?

Docker ensures the directory exists so commands run inside it without errors, as shown in execution_table step 2 where /app is created.

Does WORKDIR change the directory for the whole build or just the next command?

WORKDIR sets the directory for all following commands, not just the next one, as seen in steps 3 and 4 where current directory remains /app.

Visual Quiz - 3 Questions

Look at the execution table, what is the current working directory after the WORKDIR instruction?

A /app

B /

C /root

D /home

💡 Hint

Check the 'Current Working Directory' column at step 2 in the execution_table.

At which step does Docker create the /app directory?

A Step 1

B Step 2

C Step 3

D Step 4

💡 Hint

Look at the 'Directory State' column in execution_table for when /app is created.

If the WORKDIR was set to an existing directory, what would change in the execution table?

A Docker would create a new directory anyway

B Docker would delete the directory first

C Docker would skip creating the directory

D Docker would fail the build

💡 Hint

Refer to the decision in concept_flow where directory existence affects creation.

Concept Snapshot

WORKDIR /path
- Sets working directory for following commands
- Creates directory if missing
- Affects all subsequent RUN, CMD, ENTRYPOINT
- Simplifies file paths in Dockerfile
- Helps organize container filesystem

Full Transcript

The WORKDIR instruction in Dockerfile sets the working directory for all following commands. When Docker reads WORKDIR, it checks if the directory exists inside the image. If it does not exist, Docker creates it automatically. Then Docker uses this directory as the current working directory for subsequent commands like RUN or CMD. This means commands run inside that directory without needing full paths. For example, WORKDIR /app creates /app if missing and sets it as current directory. Then RUN touch file.txt creates file.txt inside /app. This behavior helps organize files and commands inside containers cleanly.

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