(bright music)
Hi, my name is Michael Mattsson.
I'm a tech marketing engineer
with Hewlett Packard Enterprise.
Today, I'm going to demystify
stateless, state full, and persistent containers.
So, initially containers were designed
to be ephemeral and transient.
It abstracted the operating system
to allow processes to run in that very confined space.
It uses Linux namespaces and cgroups
to accomplish these tasks, right.
So, when you start up a container, all the data
that's being processed in the container dies, right?
So, let's see that you start up a container,
and you're storing your data on /data
inside the container.
And you run this application
for a certain amount of time,
and if you restored it or you upgraded,
all that data is essentially lost, right?
So that means that the whole thing here,
the entire container including its data
is ephemeral and transient.
So as time progressed,
we wanted to do more things with containers.
We wanted to be able to run databases inside them.
We wanted to be able to run file services
or other applications that require you
to basically store the data across restores.
So, one concept was that we basically created
empty containers and stored the data inside that.
Another concept is that you create
something called a bind mount,
and that essentially the mount point
that you create inside your container,
you would replace that with a bind mount
from the host itself.
And that allows the container
to be restarted on the same host again,
which is pretty practical.
And you will also be able
to connect that mount point to an external volume.
And this could reside on an external store system
or a remote file server or anything else.
But, the key thing here is that the data that you stored
outside your container will then persist
across restores, upgrades, and rollbacks
and whatever you do.
But this state here, everything about the container--
its name, its state that is stored
outside of that particular mount point--is lost.
And that's why we need to kind of have a concept
and a construct to be able to persist
not only the external data, we also need to persist
the actual application and the run-time, right?
So, the application would
essentially rely on data that is stored
outside of that particular mount point.
So, say you have the root file system
in the application.
You want to be able to persist that
across restores and upgrades and rollbacks and so forth.
And you might also special treat your data
and still store that externally, right?
And what this construct essentially means
is that not only do you store the stateful data
for the persistent app outside of the container,
you'll also persist the run-time information
and that could be the node identity
that the container needs,
like a fixed IP address or whatnot,
because regardless if this is a silent monolith
or it's a distributed application,
it needs to store the entire state, right?
And, that means that the entire application--
container and data--will be able
to survive across reboots.
If you find this topic interesting,
please visit hpe.com/storage/containers.
You can follow me on Twitter @datamattson.
You can also visit my personal blog at datamattson.io.
Until next time, bye.
(bright music)