Welcome back. I'm Travis of Linux Academy.

In the previous section, we talked about

networking. We covered the theories behind it and how to create networks as well as
networking our containers. Now we're going to look into how we can store data in
Docker. Non-persistent data is going to be ephemeral. If this data gets deleted,
we're not going lose any sleep over it. An good example would be application code
because it is going to be tied to the life cycle of our container. By using a
Docker image as a build artifact, we bake our code into the image. And anytime we
go and release a new version of code, we're generating a new version of the image
and therefore deploying out a new container. And that's the reason why application
data can be ephemeral. Every container has non-persistent storage, and this storage
gets created with the container, which is the read-write layer. Non-persistent data
is tied to the life cycle of the container. This means that when the container is
deleted, so is the non-persistent data. Persistent data is data that is not
ephemeral, we want it to stick around, and this is achieved by using volumes.
Volume data lives outside of the life cycle to container. Going back to the example
of our application being ephemeral, if our application talks to a database, we want
to make sure that data is persistent and therefore lives in a volume. This allows
us to go and upgrade our database container without losing any database ties to the
application. Non-persistent storage is commonly referred to as local storage. It's
also been referred to as graphdriver storage, as well as snapshotter storage. On
Linux systems storage ccn be found under /var/lib/docker/ and then the name of the
storage driver. For example, let's say we're using the overlay to storage driver.
The location would be var/lib/docker/overlay2. For Windows systems, storage is
located on the c:\ drive under \programdata\docker\windowsfilter\. The version of
the operating system is going to determine what storage driver is going to be used
by default. RHEL-based systems use overlay2. With Ubunto you can use overlay2 or
aufs. SUSE uses btrfs, Windows is its own special case, it has its own driver that
is configured by default. There are two ways we can handle persistent data in
Docker: we can use a bind mount or volume. We'll be covering bind mounts in a
future lesson. For now, we're going to focus on volumes. We start by creating the
volume first, followed by the container, and then the volume is mounted inside of
it. And this is done by mounting the volume to a directory. Any changes that are
made from within that directory are going to be made on that volume. For example,
if we go and create a file, it's written to the volume. If we make a change to that
file. likewise it will be written to it as well. And if we delete the file from the
directory, it's removed from the volume. Volumes live outside of the life cycle of
containers. This allows us to go and safely delete a container without worrying
about our data being impacted. Volumes are first class citizens in Docker. This
means that they are their own object, they have their own APIs as well as their own
subcommand. The local driver is used by default. This means that when we create a
volume, it's created locally on the Docker server. However, if we're using Docker
Swarm, this is going to present an issue. We'll talk about this in more detail once
we get to Docker Swarm. Just like with networking, volumes also support third party
drivers. There are three types of drivers: block storage, file storage, and object
storage. Block storage is good for high performance or small block random access
workloads. This includes storage like Amazon EBS as well as openstack cinder. File
storage uses protocols such as NFS or SMB, and like block storage, it's also good
for high performance workloads. Some examples include Netapp FAS, Azure file
storage, and Amazon EFS. The last type of storage driver we have is object storage.
Object storage is large data blobs that don't change all that often. Some examples
are Amazon S3, Ceph, MinIO, and OpenStack Swift. When the volume is created on
Linux, it's going to be located in /var/lib/docker/volumes/, and for Windows, it's
found on the c: drive under \programdata\docker\volumes. Here's an example of how a
volume is mounted into a container. Let's say we have a directory called code under
/var. The docker volume will be mounted to /var/code, and any changes we make in
the code directory are going to be written to the volume. Now that we have learned
the fundamentals of how volumes work, let's go and get our hands dirty. In the next
lesson, we're going to start working with the volume commands. Go ahead and mark
this lesson complete.