FrançaisGet started

Making a container's data persist

The ephemeral writable layer and the three mounts (named volume, bind mount, tmpfs); the -v and --mount options; the docker volume commands; what survives stop, rm and a new image.

  • 24 cards
  • 5 topics
  • Free
Study this deck

The outline, topic by topic

Each topic is weighted the way the exam weighs it.

  1. Concepts
  2. Questions
  3. Sort and link
  4. Scenarios
  5. Understand

A few cards from the deck

  • Writable layer: what is it?

    Show the answer

    A space belonging to one container where all the files it writes outside a mount go; it is destroyed along with it.

    It survives docker stop then docker start, but not docker rm. Writing into it is also slower than writing to a volume.

  • You write a.txt in /data (named volume), b.txt in /tmp and c.txt in /src (bind mount). You run docker rm then docker run with the same mounts. Which files are still there?

    • a.txt et c.txt
    • a.txt seulement
    • a.txt, b.txt et c.txt
    • b.txt et c.txt
    Show the answer

    a.txt et c.txt

    /tmp is in the writable layer, deleted with the container. The named volume lives outside the container, and the bind mount is a host folder: neither is touched by docker rm.

  • In -v pgdata:/var/lib/postgresql/data, pgdata is the name of the … and /var/lib/postgresql/data the path where it appears ….

    Show the answer

    In -v pgdata:/var/lib/postgresql/data, pgdata is the name of the volume and /var/lib/postgresql/data the path where it appears inside the container.

    When the left part is a name, it is a named volume; when it starts with / or ./, it is a bind mount to the host.

  • Named volume: what is it?

    Show the answer

    A storage space created and managed by Docker, designated by a name, which lives independently of any container.

    Docker keeps it in its own folder (/var/lib/docker/volumes/...): no host path needs to be chosen. It is the standard choice for a database's data.

  • A postgres:16 container is started with no -v option. After each update of the image, the database is empty. What is the probable cause, and the fix?

    • The new image overwrites the tables at start-up; pin the image tag to latest
    • The Docker daemon deletes databases after an update; turn off automatic updates
    • The data stays attached to the old container; mount a named volume on the data folder
    • The database port is not published; add the -p 5432:5432 option
    Show the answer

    The data stays attached to the old container; mount a named volume on the data folder

    Updating the image forces the container to be re-created. Without -v, the postgres:16 image keeps its data in an anonymous volume tied to the old container, which the new one does not pick up: it starts from an empty database. A named volume on /var/lib/postgresql/data is attached to each new container.

Study this deck