Lesson 11: Introduction to Container Storage and Statelessness

By default, containers are designed to be stateless and ephemeral (short-lived). This means any data written inside the container's writable layer is lost when the container is stopped and removed.

The Need for Persistence

Most applications need to store data persistently:

• Databases (PostgreSQL, MongoDB) need to keep their data files.
• Web applications need to store user uploads, log files, or session data.

If we didn't use persistent storage, restarting a database container would result in a complete loss of all user data.

Docker's Solutions for Persistence

Docker offers two primary mechanisms for persistent storage that allow data to survive container restarts and removal, and also allows data sharing between containers or with the host system:

1. Volumes: The preferred and most robust method. Docker manages the storage location on the host machine.
2. Bind Mounts: Maps a specific file or directory on the host machine directly into the container. Great for development.

The Concept of Storage Drivers

Docker uses a storage driver (e.g., OverlayFS, ZFS) to manage how files are stored and retrieved, especially concerning the image layers and the thin writable layer of the container.

Key Takeaway: Never rely on the container's writable layer for critical data. If the container crashes or is deleted, the data is gone.