Named volumes for data sharing in Docker - Step-by-Step Execution

Process Flow - Named volumes for data sharing

Create Named Volume

↓

Start Container A

↓

Container A writes data

↓

Start Container B

↓

Container B reads data

↓

Data shared via Named Volume

This flow shows how a named volume is created and used by two containers to share data persistently.

Execution Sample

Docker

docker volume create shared_data

docker run -d --name containerA -v shared_data:/data busybox sh -c "echo hello > /data/greeting.txt && sleep 3600"

docker run --rm -v shared_data:/data busybox cat /data/greeting.txt

Create a named volume, write data in one container, then read it from another container.

Process Table

Step	Action	Command	Result/Output
1	Create named volume	docker volume create shared_data	Volume 'shared_data' created
2	Start containerA with volume	docker run -d --name containerA -v shared_data:/data busybox sh -c "echo hello > /data/greeting.txt && sleep 3600"	Container 'containerA' running, file /data/greeting.txt created with 'hello'
3	Start containerB to read data	docker run --rm -v shared_data:/data busybox cat /data/greeting.txt	Output: hello
4	Stop containerA	docker stop containerA	Container 'containerA' stopped
5	Remove containerA	docker rm containerA	Container 'containerA' removed

💡 Data persists in named volume 'shared_data' even after containerA is removed

Status Tracker

Variable	Initial	After Step 1	After Step 2	After Step 3	Final
shared_data volume	none	created	contains greeting.txt with 'hello'	accessible with 'hello' content	persists with data intact

Key Moments - 2 Insights

Why does containerB see the file created by containerA?

Because both containers use the same named volume 'shared_data' mounted at /data, so data written by containerA is accessible to containerB as shown in execution_table step 3.

What happens to the data if containerA is removed?

The data remains in the named volume 'shared_data' even after containerA is removed, as shown in execution_table step 5 and variable_tracker final state.

Visual Quiz - 3 Questions

Look at the execution table, what is the output when containerB reads the file?

A empty output

B hello

C error: file not found

D containerB fails to start

💡 Hint

Check execution_table row 3 under Result/Output

At which step is the named volume created?

A Step 3

B Step 2

C Step 1

D Step 4

💡 Hint

Look at execution_table row 1 Action and Command

If containerA did not write the file, what would containerB see when reading?

A error: file not found

B hello

C empty output

D containerB crashes

💡 Hint

Think about what happens if the file /data/greeting.txt does not exist in the volume

Concept Snapshot

Named volumes in Docker allow data sharing between containers.
Create a volume with 'docker volume create NAME'.
Mount it with '-v NAME:/path' in containers.
Data persists beyond container life.
Containers share files via the volume path.

Full Transcript

This visual execution shows how Docker named volumes enable data sharing between containers. First, a named volume 'shared_data' is created. Then containerA starts with this volume mounted at /data and writes a file greeting.txt with content 'hello'. Next, containerB starts with the same volume mounted and reads the file, outputting 'hello'. Even after containerA stops and is removed, the data remains in the named volume. This demonstrates persistent and shared storage using Docker named volumes.

Practice

1. What is the main purpose of using named volumes in Docker?

easy

A. To isolate network traffic between containers

B. To speed up container startup time

C. To share and persist data between containers safely

D. To limit CPU usage of containers

Solution

1. Step 1: Understand what named volumes do

   Named volumes store data outside the container's writable layer, allowing data to persist beyond container life.

2. Step 2: Identify the main benefit

   This persistence and sharing of data between containers is the key purpose of named volumes.

3. Final Answer:

   To share and persist data between containers safely -> Option C

4. Quick Check:

   Named volumes = data sharing and persistence [OK]

Hint: Named volumes keep data safe and share it [OK]

Common Mistakes:

• Confusing volumes with network settings
• Thinking volumes improve CPU or speed
• Assuming volumes delete data with containers

2. Which of the following is the correct command to create a named volume called mydata?

easy

A. docker volume create mydata

B. docker create volume mydata

C. docker volume new mydata

D. docker volume make mydata

Solution

1. Step 1: Recall Docker volume creation syntax

   The correct command to create a volume is docker volume create [name].

2. Step 2: Match the command with options

   Only docker volume create mydata uses the correct syntax: docker volume create mydata.

3. Final Answer:

   docker volume create mydata -> Option A

4. Quick Check:

   Volume create command = docker volume create [OK]

Hint: Use 'docker volume create' to make named volumes [OK]

Common Mistakes:

• Swapping order of words in the command
• Using 'new' or 'make' instead of 'create'
• Omitting the 'volume' keyword

3. Given the command:

docker run -d --name app1 -v myvol:/app/data busybox sleep 1000

What happens to the data inside /app/data if the container app1 is removed?

medium

A. Data inside /app/data is saved in the named volume 'myvol'

B. Data inside /app/data is lost unless backed up manually

C. Data inside /app/data is copied to the host's /var/lib/docker folder automatically

D. Data inside /app/data is deleted with the container

Solution

1. Step 1: Understand volume mounting in the command

   The -v myvol:/app/data option mounts the named volume 'myvol' to the container path '/app/data'.

2. Step 2: Know volume persistence behavior

   Named volumes keep data even if the container is removed, so data inside '/app/data' is saved in 'myvol'.

3. Final Answer:

   Data inside /app/data is saved in the named volume 'myvol' -> Option A

4. Quick Check:

   Named volume keeps data after container removal [OK]

Hint: Named volumes keep data safe after container removal [OK]

Common Mistakes:

• Thinking data deletes with container
• Confusing named volumes with anonymous volumes
• Assuming data copies to host automatically

4. You run this command to share data between two containers:

docker run -d --name c1 -v sharedvol:/data busybox sleep 1000
docker run -d --name c2 -v sharedvol:/data busybox sleep 1000

But container c2 cannot see files created by c1 inside /data. What is the likely problem?

medium

A. The volume mount syntax is incorrect

B. Containers must be on the same network to share volumes

C. The volume 'sharedvol' was not created before running containers

D. Files created by c1 are not saved because the container is stopped

Solution

1. Step 1: Check volume creation requirement

   Named volumes must exist or be created automatically. If 'sharedvol' was never created, Docker creates an empty volume.

2. Step 2: Understand volume persistence and sharing

   If 'sharedvol' was not created or data was not saved properly, c2 won't see c1's files. Network does not affect volume sharing.

3. Final Answer:

   Files created by c1 are not saved because the container is stopped -> Option D

4. Quick Check:

   Stopped container does not save files to volume [OK]

Hint: Files must be saved and container running to share data [OK]

Common Mistakes:

• Thinking network affects volume sharing
• Assuming mount syntax is wrong
• Believing stopped containers save files automatically

5. You want to share a folder /var/log/app on your host with multiple containers using a named volume. Which sequence of commands correctly creates and uses the named volume to achieve this?

hard

A. docker volume create app_logs

docker run -d -v /var/log/app:/app/log busybox sleep 1000

B. docker volume create --opt type=none --opt device=/var/log/app --opt o=bind app_logs

docker run -d -v app_logs:/app/log busybox sleep 1000

C. docker volume create app_logs

docker run -d -v app_logs:/var/log/app busybox sleep 1000

D. docker run -d -v app_logs:/app/log busybox sleep 1000

Solution

1. Step 1: Create a named volume that binds to host folder

   Use docker volume create with options type=none, device=/var/log/app, and o=bind to bind the host folder to the volume.

2. Step 2: Run container mounting the named volume

   Mount the named volume app_logs to the container path /app/log with -v app_logs:/app/log.

3. Final Answer:

   docker volume create --opt type=none --opt device=/var/log/app --opt o=bind app_logs docker run -d -v app_logs:/app/log busybox sleep 1000 -> Option B

4. Quick Check:

   Bind host folder with volume create options [OK]

Hint: Use volume create with bind options for host folder sharing [OK]

Common Mistakes:

• Mounting host folder directly without volume create
• Mounting volume to wrong container path
• Skipping volume creation step