- [Instructor] According to the Docker Certified
Associate Study Guide, you should be able
to configure the Device Mapper storage driver.
Now, Device Mapper is an alternative to,
for example, the Overlay storage driver
that we have configured by default in Ubuntu with Docker.
The Device Mapper storage driver has a number
of different capabilities over storage drivers
such as Overlay and Overlay Two.
For example, Device Mapper uses block-based storage.
In other words, it can access block devices
that are dedicated to Docker.
So, Device Mapper works at the block level
rather than the file level like most of the
other storage drivers.
And, this way, Docker can access and manage
physical storage that's directly connected
to your Docker host.
Now, to use your Device Mapper storage driver,
there are a few things that you should know.
If we scroll down here and take a look at the
prerequisites inside the Docker documentation,
it tells us that the Device Mapper storage driver
is only supported for Docker EE
on Red Hat Enterprise Linux, CentOS,
and Oracle Linux.
It's also supported on Docker's CE edition,
or the community edition, on CentOS, Fedora,
Ubuntu, and Debian.
So, if you wanna use Device Mapper and use
block-based storage with Docker Enterprise edition,
you need to make sure that you're using
one of these Linux distributions listed here
in the prerequisites.
It's also important to know that any time you
change a storage driver in Docker,
you will lose accessibility, in other words,
you'll lose access to all of the containers
that are stored on the local system.
To preserve those containers, you would want to
make sure that you do a Docker save to save those
containers off, for example, to the Docker hub,
or to a private repository,
so that you don't lose your application data
that may be stored inside those containers.
To configure the Device Mapper storage driver,
let's scroll on down here and take a look at the steps.
First it says that you should stop Docker
with sudo systemctl stop docker.
From there you edit the etc docker daemon dot json file.
And you make this entry right here
with the squiggly brackets,
storage driver colon devicemapper.
From there, scroll on down and you will re-start Docker.
And then, finally, you should be able to see
inside Docker info that you're now using
the storage driver for Device Mapper.
If you scroll on down,
while it's not specifically listed in the
Docker DCA Study Guide,
it's important to note that if you scroll on down here,
once you have configured Device Mapper
as your storage driver,
there are many things to know about a very complex
configuration related to the direct LVM mode
that would be used in produc--
to actually configure and manage these block devices
that are directly attached to the Docker host.
So, it would be similar to doing the old F disc
in DOS or Windows, if you will.
Or, for example, in Linux, using the
Logical Volume Manager, LVM.
Or any other physical disc partitioning tool
that you may have used in the past.
So, that's what you need to know about Direct LVM.
In the latest versions of Docker,
Direct LVM will be automatically configured
with just a base set of configurations
listed here in the documentation.
However, in older versions of Docker,
or optionally, if you would like to,
you can configure direct LVM mode manually,
which, if I scroll down here, as you can see
is a very lengthy procedure.
But once Device Mapper and Direct LVM is configured,
then you can perform things such as
thin provisioning, and you can access these discs,
these physical discs, at the block level.
Which will give you much higher performance
than at the file level.
At the end of this documentation,
Docker provides some performance best practices
related to using Device Mapper.
It tells us that the loop LVM
should never be used in production.
Loop LVM is the default if you don't configure direct LVM.
They recommend using fast storage, solid-state disc drives,
of course, to get the best performance.
Naturally, you would get the best performance
from flash storage.
It tells us that Device Mapper uses more memory
than some other storage drivers.
So take that into consideration.
And then, finally, it tells us that volumes
provide the best and most predictable performance
for write-heavy workloads.
And that's because they bypass the storage driver
and don't incur any potential overhead
introduced by thin provisioning and copy on write.
In other words, if you have write-heavy workloads,
you should use volumes.
If we scroll back up here,
there is some detailed information.
If you'd like to dive into the details here
on how exactly Device Mapper works,
with thin provisioning, with snapshotting,
how the data is read inside Device Mapper,
specifically reading files with Device Mapper,
and how data is written inside Device Mapper.
With that overview of Device Mapper in mind,
we're actually going to go to one of our Docker hosts
and we're going to configure Device Mapper
as our new storage driver.
So let's jump over into the lab.