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.