📖 Scenario: You are learning how Docker containers handle files inside their filesystem. Containers have a temporary filesystem that resets when the container stops. This means any files created inside the container at runtime will be lost after it stops unless you use special methods like volumes.
🎯 Goal: Build a simple Docker container, create a file inside its filesystem at runtime, then observe that the file disappears after the container stops, demonstrating the ephemeral nature of container filesystems.
📋 What You'll Learn
Create a Dockerfile that uses the alpine image
Add a CMD to keep the container running
Build and run the container detached, create tempfile.txt at runtime using docker exec, and check that the file exists
Stop and remove the container, then verify that the file is gone when starting a new container from the same image
💡 Why This Matters
🌍 Real World
Containers are widely used to run applications in isolated environments. Understanding ephemeral filesystems prevents data loss in deployments.
💼 Career
DevOps engineers must manage persistent storage with volumes for stateful apps like databases.
Progress0 / 4 steps
1
Create a Dockerfile with Alpine base image
Create a file named Dockerfile with a single line that sets the base image to alpine.
Docker
Hint
The first line in a Dockerfile usually starts with FROM followed by the image name.
2
Add CMD to keep the container running
Add a CMD instruction in the Dockerfile to run sleep 3600. This keeps the container alive so we can execute commands inside it later.
Docker
Hint
Use CMD sleep 3600 (shell form) to make the container run indefinitely for this demo.
3
Build, run detached container, create and check the file
Build the Docker image with tag ephemeral-test. Run a detached container named ephemeral-container. Use docker exec to create /tempfile.txt with content Hello from container, then cat it to verify.
Docker
Hint
Build with docker build -t ephemeral-test ., run detached with -d --name, create file with docker exec ... sh -c 'echo ...'.
4
Stop container and demonstrate ephemeral filesystem
Confirm file exists with ls, then stop and remove the container. Run a new container from the same image and check ls /tempfile.txt fails, proving the file was ephemeral.
Docker
Hint
Run docker exec ... ls /tempfile.txt (outputs /tempfile.txt), stop/rm, then new docker run --rm ... ls /tempfile.txt (outputs error).
Practice
(1/5)
1. What happens to files created inside a Docker container when the container is stopped and restarted?
easy
A. The files are deleted because the container filesystem is ephemeral.
B. The files are saved permanently inside the container.
C. The files are automatically copied to the host machine.
D. The files are backed up to Docker Hub.
Solution
Step 1: Understand container filesystem behavior
Docker containers have an ephemeral filesystem, meaning changes inside the container do not persist after restart.
Step 2: Apply this to file creation
Files created inside the container are lost when the container stops or restarts unless saved externally.
Final Answer:
The files are deleted because the container filesystem is ephemeral. -> Option A
Quick Check:
Container filesystem ephemeral = files lost on restart [OK]
Confusing container filesystem with host filesystem
2. Which Docker command correctly mounts a host directory /data to a container directory /app/data to persist data?
easy
A. docker run --env /data:/app/data myimage
B. docker run -p /data:/app/data myimage
C. docker run --link /data:/app/data myimage
D. docker run -v /data:/app/data myimage
Solution
Step 1: Identify volume mount syntax
The correct syntax to mount a host directory is using -v host_path:container_path.
Step 2: Match the correct option
docker run -v /data:/app/data myimage uses -v /data:/app/data, which is the correct way to mount the host directory.
Final Answer:
docker run -v /data:/app/data myimage -> Option D
Quick Check:
Volume mount uses -v host:container [OK]
Hint: Use -v host_path:container_path to mount volumes [OK]
Common Mistakes:
Using -p instead of -v for volumes
Confusing --link or --env with volume mounts
Forgetting to specify both host and container paths
3. Consider this Dockerfile snippet:
FROM alpine
RUN echo "Hello" > /greeting.txt
CMD cat /greeting.txt
If you run this container, then modify /greeting.txt inside the running container to "Hi", then restart the container, what will cat /greeting.txt output?
medium
A. Hi
B. Hello
C. File not found error
D. Empty output
Solution
Step 1: Understand Dockerfile build vs container runtime
The file /greeting.txt is created during image build with content "Hello".
Step 2: Recognize ephemeral container filesystem
Changes made inside a running container (changing to "Hi") are lost after restart because the container filesystem resets.
Final Answer:
Hello -> Option B
Quick Check:
Container restart resets filesystem, original file restored [OK]
Hint: Changes inside container lost on restart; image files stay [OK]
Common Mistakes:
Assuming changes inside container persist after restart
Confusing image build files with runtime changes
Expecting file to be missing after restart
4. You ran a container and created a file inside it. After restarting, the file disappeared. You want to keep the file persistent. Which of these fixes the problem?
medium
A. Restart the container with --restart=always flag.
B. Increase container memory limit.
C. Use a Docker volume to store the file outside the container.
D. Run the container with --rm option.
Solution
Step 1: Identify cause of file loss
Files inside container are lost on restart because filesystem is ephemeral.
Step 2: Choose method to persist data
Using a Docker volume stores data outside container, preserving files across restarts.
Final Answer:
Use a Docker volume to store the file outside the container. -> Option C
Quick Check:
Volumes keep data persistent beyond container life [OK]
Hint: Persist files with volumes, not restart flags or memory [OK]
Common Mistakes:
Thinking restart flags keep files
Confusing memory limits with filesystem persistence
Using --rm removes container on exit, losing files
5. You want to run a container that writes logs to /var/log/app.log inside the container. You want these logs to persist even if the container is removed or recreated. Which Docker run command achieves this?
hard
A. docker run -v /host/logs/app.log:/var/log/app.log myapp
B. docker run --rm myapp
C. docker run -v /host/logs:/var/log/app.log myapp
D. docker run -v /host/logs/app.log:/var/log myapp
Solution
Step 1: Understand volume mount for specific file
To persist a single log file, mount the host file to the container file path.
Step 2: Analyze options
docker run -v /host/logs/app.log:/var/log/app.log myapp mounts /host/logs/app.log to /var/log/app.log inside container, persisting logs exactly.
Step 3: Why other options fail
docker run -v /host/logs/app.log:/var/log myapp tries to mount file to directory path (invalid). docker run -v /host/logs:/var/log/app.log myapp tries to mount directory to file path (invalid). docker run --rm myapp removes container on exit, losing logs.
Final Answer:
docker run -v /host/logs/app.log:/var/log/app.log myapp -> Option A
Quick Check:
Mount host file to container file for persistent logs [OK]
Hint: Mount host file to container file path to persist logs [OK]
Common Mistakes:
Mounting directory to file path (invalid)
Using --rm which deletes container and files
Mounting directory when only file persistence needed
Recommended
Ready to prove it?
Pass the test and this pattern moves unknownstrongwhile earning +1 Grip toward your certificate.