Bind mounts for development in Docker - Step-by-Step Execution

Process Flow - Bind mounts for development

Start Docker Container

↓

Specify Bind Mount

↓

Host Folder Linked to Container

↓

Code Changes on Host

↓

Changes Reflected in Container

↓

Develop and Test Live

↓

Stop Container

This flow shows how a host folder is linked to a container using a bind mount, allowing live code changes on the host to appear instantly inside the container.

Execution Sample

Docker

docker run -it -v /host/app:/app myimage
# Start container with bind mount
# Edit files in /host/app on host
# Changes appear in /app inside container

This command runs a container with a bind mount linking the host's /host/app folder to the container's /app folder for live development.

Process Table

Step	Action	Host Folder State	Container Folder State	Result
1	Start container with bind mount	/host/app contains code v1	/app linked to /host/app	Container sees code v1
2	Edit file on host: change main.py	/host/app main.py updated to v2	/app main.py updated to v2	Container sees updated main.py
3	Run app inside container	No change	/app runs updated code v2	Live testing with latest code
4	Add new file on host: utils.py	/host/app utils.py added	/app utils.py appears	Container sees new file immediately
5	Stop container	Host folder unchanged	Container stops	Development session ends

💡 Container stops, bind mount ends but host files remain unchanged

Status Tracker

Variable	Start	After Step 2	After Step 4	Final
/host/app/main.py	version 1	version 2	version 2	version 2
/host/app/utils.py	does not exist	does not exist	added	added
/app/main.py (container)	version 1	version 2	version 2	version 2
/app/utils.py (container)	does not exist	does not exist	added	added

Key Moments - 3 Insights

Why do changes on the host folder immediately appear inside the container?

Because the bind mount links the host folder directly to the container folder, so both share the same files in real time, as shown in execution_table steps 2 and 4.

Does stopping the container delete the files on the host?

No, stopping the container only ends the container process. The host files remain unchanged, as shown in execution_table step 5.

What happens if you add a new file on the host after the container started?

The new file appears immediately inside the container folder because the bind mount reflects all host folder changes live, as shown in execution_table step 4.

Visual Quiz - 3 Questions

Look at the execution table, what is the state of /app/main.py inside the container after step 2?

A File deleted

B Version 1 (original file)

C Version 2 (updated file)

D File does not exist

💡 Hint

Check the 'Container Folder State' column at step 2 in the execution_table.

At which step does the container first see the new file utils.py?

A Step 4

B Step 2

C Step 3

D Step 5

💡 Hint

Look for when utils.py appears in the 'Container Folder State' column in the execution_table.

If the bind mount was not used, what would happen to changes made on the host folder?

A They would appear live inside the container

B They would not appear inside the container

C The container would crash

D The host files would be deleted

💡 Hint

Recall that bind mounts link host and container folders live; without it, container files stay static.

Concept Snapshot

Bind mounts link a host folder to a container folder live.
Syntax: docker run -v /host/path:/container/path image
Changes on host appear instantly inside container.
Useful for live development and testing.
Stopping container does not affect host files.

Full Transcript

Bind mounts in Docker let you connect a folder on your computer (host) to a folder inside a running container. When you start a container with a bind mount, any changes you make to files on your computer show up immediately inside the container. This is great for development because you can edit code on your computer and test it live inside the container without rebuilding the image. The flow starts by running the container with the bind mount option. Then, when you edit or add files on your host, those changes appear inside the container folder. When you stop the container, the files on your computer stay safe and unchanged. This method helps developers work faster by seeing their changes live inside the container environment.

Practice

1. What is the main purpose of using bind mounts in Docker during development?

easy

A. To automatically update Docker itself

B. To link files or folders from the host machine directly into the container for live editing

C. To isolate the container completely from the host file system

D. To create a new Docker image from a container

Solution

1. Step 1: Understand bind mounts concept

   Bind mounts connect a folder or file on your computer (host) directly into the container, so changes on the host reflect immediately inside the container.

2. Step 2: Identify the purpose in development

   This allows developers to edit code on their computer and see the changes live inside the container without rebuilding the image.

3. Final Answer:

   To link files or folders from the host machine directly into the container for live editing -> Option B

4. Quick Check:

   Bind mounts = live code sync [OK]

Hint: Bind mounts sync host files live inside containers [OK]

Common Mistakes:

• Confusing bind mounts with Docker image creation
• Thinking bind mounts isolate container from host
• Assuming bind mounts update Docker software

2. Which of the following is the correct syntax to create a bind mount in Docker CLI?

easy

A. docker run --mount /host/path:/container/path image_name

B. docker run -mount bind:/host/path:/container/path image_name

C. docker run -bind /host/path:/container/path image_name

D. docker run -v /host/path:/container/path image_name

Solution

1. Step 1: Recall Docker bind mount syntax

   The correct way to specify a bind mount is using the -v or --volume flag with the format host_path:container_path.

2. Step 2: Check each option

   docker run -v /host/path:/container/path image_name uses -v /host/path:/container/path which is correct. Options A, C, and D use incorrect flags or syntax.

3. Final Answer:

   docker run -v /host/path:/container/path image_name -> Option D

4. Quick Check:

   Bind mount syntax = -v host:container [OK]

Hint: Use -v host_path:container_path for bind mounts [OK]

Common Mistakes:

• Using --mount without correct syntax
• Using non-existent flags like -bind
• Mixing mount types incorrectly

3. Given the command:
docker run -it -v /home/user/app:/app ubuntu bash
What will happen if you edit a file inside /home/user/app on the host while the container is running?

medium

A. The changes will appear immediately inside the container's /app directory

B. The container will crash due to file conflicts

C. The changes will not reflect inside the container until it is restarted

D. The container will create a copy of the file and ignore host changes

Solution

1. Step 1: Understand bind mount behavior

   The -v /home/user/app:/app option mounts the host folder directly into the container, so files are shared live.

2. Step 2: Effect of editing host files

   Editing files on the host folder /home/user/app will immediately reflect inside the container at /app because of the live bind mount.

3. Final Answer:

   The changes will appear immediately inside the container's /app directory -> Option A

4. Quick Check:

   Host edits = instant container updates [OK]

Hint: Host file edits show instantly inside container [OK]

Common Mistakes:

• Thinking container needs restart to see changes
• Assuming container crashes on file edits
• Believing container copies files instead of sharing

4. You run this command but changes on your host folder are NOT visible inside the container:
docker run -v app:/app ubuntu
What is the most likely problem?

medium

A. You used a named volume instead of a bind mount with an absolute host path

B. The container image ubuntu does not support volumes

C. You forgot to add the -it flags

D. The container is missing the /app directory

Solution

1. Step 1: Analyze the volume syntax

   The command uses -v app:/app which creates a named volume called 'app', not a bind mount from the host.

2. Step 2: Understand bind mount requirement

   Bind mounts require an absolute host path like /home/user/app. Using just 'app' creates a Docker-managed volume, so host folder changes won't reflect.

3. Final Answer:

   You used a named volume instead of a bind mount with an absolute host path -> Option A

4. Quick Check:

   Bind mounts need absolute host paths [OK]

Hint: Use absolute host path for bind mounts, not volume names [OK]

Common Mistakes:

• Confusing named volumes with bind mounts
• Forgetting absolute path on host
• Assuming all volumes sync host files

5. You want to develop a Node.js app inside Docker using bind mounts. Your host code is in /home/dev/myapp. Which command correctly sets up the container so that:
- The host code is live inside /usr/src/app in the container
- The container runs npm start
- You can edit code on host and see changes immediately

Choose the best command:

hard

A. docker run -v /home/dev/myapp:/usr/src/app node npm start

B. docker run -v /home/dev/myapp node npm start

C. docker run -v /home/dev/myapp:/usr/src/app -w /usr/src/app node npm start

D. docker run -v /usr/src/app:/home/dev/myapp node npm start

Solution

1. Step 1: Check bind mount and working directory

   docker run -v /home/dev/myapp:/usr/src/app -w /usr/src/app node npm start uses -v /home/dev/myapp:/usr/src/app to bind mount the host folder to the container path, and -w /usr/src/app to set the working directory inside the container.

2. Step 2: Confirm command and live editing

   Running npm start inside the container's working directory ensures the app runs with live code from the host. docker run -v /home/dev/myapp:/usr/src/app node npm start misses the working directory, docker run -v /home/dev/myapp node npm start has incorrect volume syntax (missing container path), and docker run -v /usr/src/app:/home/dev/myapp node npm start reverses paths incorrectly.

3. Final Answer:

   docker run -v /home/dev/myapp:/usr/src/app -w /usr/src/app node npm start -> Option C

4. Quick Check:

   Bind mount + correct workdir + command = docker run -v /home/dev/myapp:/usr/src/app -w /usr/src/app node npm start [OK]

Hint: Set -v host:container and -w container for live dev [OK]

Common Mistakes:

• Omitting working directory (-w) for commands
• Reversing host and container paths
• Not specifying full host path for bind mount