So far, we’ve learned how to create and run containers very easily. But there’s an important pitfall when you’re just starting out withDocker: a container’s data isn’t meant to be persistent.
And this behavior isn’t a flaw.
It’s a deliberate design choice in Docker.
To understand why, we need to go back to a fundamental principle:
A container is ephemeral.
A container is a temporary instance of an image
In the previous sections, we saw that an imageDockeris a ready-to-use, read-only template.
WhenDocker launches a container from this image, it simply adds a temporary write layer on top of the image. All changes made within the container are saved to this layer.
Simplified diagram:
IMAGE (lecture seule)
│
▼
CONTENEUR
(couche d'écriture temporaire)This means that if a file is created, modified, or deleted in the container, the change is stored in this temporary layer.
What happens if the container disappears?
When you delete a container with the command:
docker rm mon-conteneur
Docker it also deletes the associated write layer.
In practice, everything that was created or modified in that container disappears along with it: generated files, logs, uploads… and even databases if they are stored inside the container.
A quick example
Let’s imagine we launch an Ubuntu container to run some tests:
docker run -it ubuntu bash
Inside the container, we create a file:
touch fichier-important.txt
The file is indeed present:
ls
fichier-important.txt
But if we exit the container and then delete it, all of that data disappears. If we launch a new container based on the same Ubuntu image, that file will no longer exist.
This isn’t a bug: it’s simply because the previous container no longer exists.
WhyDockerdoes it work this way?
This behavior may seem surprising at first, but it offers several significant advantages.
First, containers become disposable. You can stop, delete, and recreate them very quickly. This greatly simplifies the management of applications and environments.
Second, it makes deployments predictable and reproducible. Instead of modifying a server over time, you simply rebuild the containers from their image.
Finally, this approach is part of what’s known as immutable infrastructure: you don’t modify an existing container; you replace it with a new one.
The Problem for Applications
In reality, some applications need to retain data.
A MariaDB database must keep its tables, a WordPress site must retain images uploaded by users, and a tool like Grafana must store its dashboards.
If this data remains inside the container, it will disappear when the container is deleted or recreated.
It’s easy to see that this would be disastrous for an application in production.
The solution: move the data out of the container
To solve this problem,Docker allows you to store data outside the container, in a persistent space called a volume.
The principle is simple: the container continues to run normally, but important data is written to an external location.
CONTENEUR
│
▼
VOLUME DOCKER
(stockage persistant)
Thus, even if the container is deleted and then recreated, the data remains intact.
This is exactly what we do, for example, with MariaDB. The database files are stored in a volume, which ensures they won’t disappear during a container update or restart.
🧠 Key Takeaway
A containerDockeris temporary by nature. All changes it contains are saved in a write-through layer that disappears when the container is deleted.
DockerFor applications that need to retain data, it is therefore essential to use persistent storage, typically in the form of volumes.
This mechanism allows you to update or recreate containers without ever losing application data.
In the next section, we’ll explore the two main persistence methods inDocker Kubernetes: Bind Mounts and Named Volumes, as well as the scenarios where each is best suited.
DockerAnd this is often where we begin to truly understand how to properly structure a project.