Sharing volumes between containers in Docker - Practice Problems & Coding Challenges

Challenge - 5 Problems

💻 Command Output

intermediate

Output of volume sharing with named volume

What is the output of the following commands when sharing a named volume between two containers?

Docker

docker volume create shared_data

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

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

A

Error: volume shared_data not found

B

cat: /data/greeting.txt: No such file or directory

C hello (without newline)

D

hello

💡 Hint

Think about how named volumes persist data and are shared between containers.

The named volume 'shared_data' is created and mounted in both containers. The first container writes 'hello' with a newline to /data/greeting.txt. The second container reads the file and outputs 'hello' with a newline.

❓ Configuration

intermediate

Correct docker-compose volume sharing syntax

Which docker-compose.yml snippet correctly shares a volume named 'shared_data' between two services 'app1' and 'app2'?

A

version: '3'
services:
  app1:
    image: busybox
    volumes:
      - ./shared_data:/data
  app2:
    image: busybox
    volumes:
      - ./shared_data:/data

B

version: '3'
services:
  app1:
    image: busybox
    volumes:
      - /data/shared_data:/data
  app2:
    image: busybox
    volumes:
      - /data/shared_data:/data

C

version: '3'
services:
  app1:
    image: busybox
    volumes:
      - shared_data:/data
  app2:
    image: busybox
    volumes:
      - shared_data:/data
volumes:
  shared_data: {}

D

version: '3'
services:
  app1:
    image: busybox
    volumes:
      - shared_data
  app2:
    image: busybox
    volumes:
      - shared_data
volumes:
  shared_data: {}

💡 Hint

Named volumes are declared under 'volumes' and referenced with 'volume_name:container_path'.

Option C correctly declares a named volume 'shared_data' and mounts it at /data in both services. Option C uses a host path which is not a named volume. Option C misses the container path. Option C uses a relative host path, not a named volume.

❓ Troubleshoot

advanced

Why data is missing when sharing host directory volume

You mounted a host directory as a volume in two containers to share data. Container A writes a file, but Container B cannot see it. What is the most likely cause?

A The host directory was mounted as read-only in Container B

B The containers are on different Docker networks

C The volume was declared as a named volume instead of a bind mount

D Container A did not have write permissions on the host directory

💡 Hint

Check the mount options for the volume in Container B.

If Container B mounts the host directory as read-only, it cannot see new files written by Container A if they are not synced properly or permissions prevent visibility. Network differences do not affect volume sharing. Named volumes and bind mounts behave differently but here a host directory is used. Write permissions on Container A affect writing but not visibility in Container B if files exist.

🔀 Workflow

advanced

Steps to share data between containers using volumes

What is the correct order of steps to share data between two running containers using a named volume?

A 2,1,3,4

B 1,2,3,4

C 1,3,2,4

D 2,3,1,4

💡 Hint

Think about creating the volume before using it in containers.

You must first create the named volume, then start the first container mounting it, write data inside, and finally start the second container mounting the same volume to access the data.

✅ Best Practice

expert

Best practice for sharing sensitive data between containers

Which is the best practice for securely sharing sensitive configuration files between multiple containers?

A Use Docker secrets or a dedicated secrets management tool

B Use a Docker named volume with encrypted filesystem on the host

C Use environment variables to pass sensitive data to each container

D Mount a host directory with sensitive files as a bind mount in all containers

💡 Hint

Consider security and access control for sensitive data.

Docker secrets or dedicated secrets management tools provide secure storage and controlled access to sensitive data. Named volumes or bind mounts do not encrypt or restrict access by default. Environment variables can leak sensitive data in logs or process lists.

Practice

1. What is the main purpose of sharing volumes between Docker containers?

easy

A. To automatically update container images

B. To increase the CPU performance of containers

C. To allow containers to access and modify the same files

D. To isolate containers completely from each other

Solution

1. Step 1: Understand volume sharing concept

   Sharing volumes means multiple containers can read and write the same files stored in a volume.

2. Step 2: Identify the purpose of sharing volumes

   This allows containers to share data easily, like sharing notes or files in a folder between friends.

3. Final Answer:

   To allow containers to access and modify the same files -> Option C

4. Quick Check:

   Sharing volumes = shared files access [OK]

Hint: Sharing volumes means sharing files between containers [OK]

Common Mistakes:

• Thinking volumes improve CPU or performance
• Confusing volume sharing with container isolation
• Assuming volumes update container images automatically

2. Which Docker command syntax correctly shares a volume named shared_data between two containers app1 and app2?

easy

A. docker run --volumes shared_data:/data --name app1 busybox

B. docker run -v shared_data:/data --name app1 busybox

C. docker run -v /shared_data:/data --name app1 busybox

D. docker run -v shared_data --name app1 --link app2 busybox

Solution

1. Step 1: Check volume syntax for sharing

   The correct syntax to share a named volume is -v volume_name:container_path. docker run -v shared_data:/data --name app1 busybox uses -v shared_data:/data which is correct.

2. Step 2: Verify other options

   docker run --volumes shared_data:/data --name app1 busybox uses invalid --volumes flag (should be --volume or -v). docker run -v /shared_data:/data --name app1 busybox uses a host path, not a named volume. docker run -v shared_data --name app1 --link app2 busybox uses incomplete volume syntax (missing :/data) and --link which is unrelated to volume sharing.

3. Final Answer:

   docker run -v shared_data:/data --name app1 busybox -> Option B

4. Quick Check:

   Use -v volume_name:path to share volumes [OK]

Hint: Use -v volume_name:container_path to share volumes [OK]

Common Mistakes:

• Using host paths instead of named volumes
• Confusing --link with volume sharing
• Using incorrect volume syntax

3. Given these commands, what will be the output of docker exec app2 cat /data/message.txt?

docker volume create shared_vol
docker run -d -v shared_vol:/data --name app1 busybox sh -c "echo Hello > /data/message.txt"
docker run -d -v shared_vol:/data --name app2 busybox sleep 1000

medium

A. Empty output

B. Error: file not found

C. Container app2 does not exist

D. Hello

Solution

1. Step 1: Understand volume sharing effect

   Both containers use the same volume shared_vol mounted at /data. Writing in app1 creates the file in the shared volume.

2. Step 2: Check file access from app2

   Since app2 mounts the same volume, it can read the file /data/message.txt created by app1. So the command outputs "Hello".

3. Final Answer:

   Hello -> Option D

4. Quick Check:

   Shared volume files visible in all containers [OK]

Hint: Shared volumes show same files in all containers [OK]

Common Mistakes:

• Assuming files are isolated per container
• Expecting file not found error
• Confusing container names or existence

4. You tried to share a volume between two containers but the second container cannot see the files created by the first. Which of these is the most likely cause?

medium

A. The volume was not named the same in both containers

B. The containers are running different images

C. The containers are on different networks

D. The first container did not expose ports

Solution

1. Step 1: Check volume naming consistency

   For containers to share data, they must use the exact same volume name. Different names create separate volumes.

2. Step 2: Evaluate other options

   Different images or networks do not affect volume sharing. Port exposure is unrelated to file sharing.

3. Final Answer:

   The volume was not named the same in both containers -> Option A

4. Quick Check:

   Same volume name needed to share data [OK]

Hint: Use identical volume names to share data [OK]

Common Mistakes:

• Thinking network or image affects volume sharing
• Confusing port exposure with volumes
• Using different volume names by mistake

5. You want two containers to share a volume but keep their own separate data initially, then merge changes later. Which Docker feature or approach helps achieve this?

hard

A. Use named volumes with different initial content and copy files manually

B. Use a bind mount to a host directory shared by both containers

C. Use Docker networks to share data between containers

D. Run containers with --rm to remove volumes after exit

Solution

1. Step 1: Understand volume sharing with initial separate data

   Named volumes start empty by default. To have separate initial data, create volumes separately and copy files manually.

2. Step 2: Consider merging changes later

   After initial separate data, you can copy or sync files between volumes or containers to merge changes.

3. Step 3: Evaluate other options

   Bind mounts share host directories but do not isolate initial data. Networks do not share files. --rm removes containers and volumes, not helpful here.

4. Final Answer:

   Use named volumes with different initial content and copy files manually -> Option A

5. Quick Check:

   Named volumes + manual copy = separate then merge [OK]

Hint: Start with separate volumes, copy files to merge later [OK]

Common Mistakes:

• Assuming networks share files
• Using --rm which deletes volumes
• Thinking bind mounts isolate initial data