DOCKER - 5 4 Exercise Volume name

Now that you understand volumes and bind mounts, let's tackle a realistic scenario: database patch upgrades. Imagine you run a specific version of Postgres in production. A security patch comes out and you need to apply it. On a regular host you'd run apt-get update && apt-get upgrade. In containers we follow a different best practice: don't upgrade software inside a container, replace the container with a new image version. The question is — how do we keep the database data across that swap?

The exercise

Use Docker Hub to find what you need. Start a Postgres container pinned to 9.6.1 (an older patch) and attach a named volume. Look at the Postgres official Dockerfile on Docker Hub to find the right path inside the container — the right-hand side of the volume:path syntax — and pick any name you like on the left.

docker container run -d --name postgres1 \
  -v psql:/var/lib/postgresql/data postgres:9.6.1

Watch the logs (docker container logs postgres1) until startup finishes — the first boot does a lot: it creates the admin user, the default database, etc. When the log stream stops, Postgres is ready. Confirm the volume exists with docker volume ls, then stop the container (only one container can write to the data files at a time).

  • Start a second container with a newer patch version (e.g. postgres:9.6.2)
  • Re-use the same named volume on the same path
  • Make sure postgres1 is stopped before launching postgres2
docker container stop postgres1
docker container run -d --name postgres2 \
  -v psql:/var/lib/postgresql/data postgres:9.6.2
docker container logs postgres2

The second container's logs should be much shorter — only a handful of startup lines — because the database already exists on the shared volume; it doesn't need to bootstrap anything. That's exactly what you'd do in production to apply a patch release. Note that major version upgrades (9 to 10, 10 to 11) generally require a dedicated upgrade tool for the database engine — what we just did only covers patch-level upgrades that share the same on-disk format. If you get stuck, check the next lesson for a live walkthrough.

Pour récapituler rapidement, nous avons expliqué dans ce cours que les conteneurs ne pouvaient pas, ou ne devraient pas, compter sur les adresses IP pour se parler, car ils ne pouvaient tout simplement pas si fier. Et que le DNS est vraiment la norme en ce qui concerne la manière dont nous effectuons l'intercommunication entre des conteneurs sur le même hôte et entre des hôtes. Il est donc recommandé de toujours créer des réseaux personnalisés, car c'est plus simple que de faire un --link tout le temps.
C’est tout pour cette vidéo, mais je vous dis à bientôt pour la prochaine.

Summary

This practical Docker exercise demonstrates how to work with named volumes by updating a PostgreSQL database container. You'll create an initial PostgreSQL 9.6.1 container with a named volume, then upgrade to a newer PostgreSQL version while reusing the same named volume to persist data across container restarts. The exercise illustrates how named volumes enable safe database version upgrades without data loss—a critical real-world scenario for maintaining production databases.

Key points

  • Named volumes provide persistent storage independent of container lifecycle, allowing data to survive container restarts and replacements
  • Database version upgrades must reuse the same named volume to access existing data from the previous container instance
  • Monitor container logs during startup to verify successful initialization; subsequent starts with existing volume data complete much faster
  • The official Docker Hub Dockerfile specifies the correct internal container path for volume mounting (the right side of the colon in the volume syntax)
  • Best practice: replace containers entirely rather than updating software inside them—volumes ensure data integrity across versions
  • Only one container can access a named volume at a time; stop the first container before starting a second one sharing the same volume

FAQ

How do I verify that my named volume is correctly created and attached?

Run `docker volume ls` to list all named volumes and confirm your volume appears with the name you specified. Check the container logs with `docker logs <container_id>` to verify the database initialized without errors.

Why does the second container start much faster than the first when using the same named volume?

The first container performs extensive initialization work—creating database users, default databases, and system tables. The second container with the same volume skips most initialization since data already exists, resulting in only 4-5 log entries instead of dozens.

What happens if I try to run two containers simultaneously with the same named volume?

You cannot safely do this. Databases cannot handle concurrent access from multiple instances. You must stop the first container before starting the second one, ensuring exclusive access to the named volume's data.