►
From YouTube: vSphere Integrated Containers: Storage
Description
In this video, learn about how VMware based storage technology and architecture can easily be leveraged to deliver storage services for docker containers using vSphere Integrated Containers.
Patrick Daigle is a Sr. Technical Architect with the Cloud Native Applications group at VMware.
A
Hi,
my
name
is
Patrick
Pegg
and
today
we're
going
to
talk
about
vsphere,
integrated
containers,
storage
and,
specifically
we're
going
to
look
at
Vic
helps
you
address
the
data
persistence
problem
with
with
running
containers,
so
containers
by
definition
are
ephemeral
and
stateless,
which
means
that
when
a
container
goes
away,
all
the
data
that
was
written
to
its
internal
filesystem
also
goes
away.
So
we
want
containers
to
be
immutable.
We
want
those
images
to
be
immutable.
It
makes
deployment
more
consistent.
A
It
makes
deployment
more
predictable,
but
there
are
some
use
cases
where
containers
require
a
level
of
data
persistence.
So
we're
going
to
look
at
how
these
four
integrated
containers
tries
to
address
that
challenge.
So
with
Vic,
we
start
with
this
construct
of
a
virtual
container
host,
that's
backed
by
a
resource
pool.
So
we
use
a
resource
pool
here
to
provide
us
with
a
flexible
resource
management
construct
and
then
inside
this
resource
pool.
We
create
one
virtual
machine
and
this
virtual
machine
is
our
docker
API
endpoint.
A
So
if
we
look
at
the
storage
that
we
can
provide
with
these
two
integrated
containers,
there's
three
types
of
storage
that
we
can
provide
with
these
four
integrated
containers,
the
first
one
is
the
image
store,
so
the
image
store
I'm
going
to
put
an
asterisk
next
to
it,
because
that's
the
only
storage,
that's
mandatory
as
part
of
creating
this
virtual
container
host.
This
is
the
only
storage
that's
mandatory,
so
what
this
is
used
for?
It's
used
for
two
things.
A
So
the
first
thing
we
use
this
for
is
we
use
it
as
the
working
directory
for
this
virtual
machine,
so
the
vmx
file,
the
VM
D
a
file
and
the
logs
all
the
files
that
make
up
that
VM
live
under
this
directory.
The
second
thing
we
use
this
for
is
for
our
image.
Cache
now
docker
uses
this
concept
of
a
registry
that
is
used
to
store
the
images
now,
when
you
request
an
image
to
be
instantiated
from
docker
it'll.
A
First,
look
at
the
image
cache
if
it
doesn't
have
it
locally,
it's
going
to
go
out
to
the
registry,
pull
it
down
and
then
copy
it
to
the
cache.
So
that's!
The
second
thing
we
use
this
for
is
as
the
image
cache.
So
this
image
store
needs
to
be
a
vSphere
data
store.
It
does
not
have
to
be
dedicated,
but
it
does
need
to
be
vSphere.
Data
store
that
we
associate
to
this
function.
A
The
next
storage
we're
going
to
look
at
is
these
volume
stores
and
there's
two
types
of
volume
stores
that
we
have
in
the
vSphere
integrated
containers,
and
this
is
where
we're
gonna
start:
creating
persistence
for
the
actual
data
in
the
form
of
creating
docker
volumes.
So
the
first
type
is
the
vSphere
data
store.
So
again,
here
I'm
specifying
a
vSphere
data
store
to
be
used
as
my
volume
store.
A
So
since
this
is
a
vSphere
data
store,
it
means
I'm,
creating
VM
decays,
so
every
volume
that
I
create
the
docker
will
get
created
as
a
VMDK
on
this
data
store
and
we're
gonna
see
in
more
detail
how
that
works
in
a
few
minutes.
But
for
now
you
have
to
remember
that
when
you
create
this
virtual
container
host,
what
you're
doing
is
you're
mapping
your
vSphere
resources
into
this
docker
consumption
model,
so
as
a
vSphere
admin
you're,
taking
the
decision
of
how
to
map
these
vSphere
resources
to
the
darker
consumption
model.
A
A
So
that's
just
a
label.
That's
going
to
be
used
again
to
reference.
This
data
store
now
there's
a
special
case
for
a
label.
You
can
specify
the
default
label.
Now
the
default
label
is
going
to
enable
the
use
of
anonymous
volumes.
I'm
not
gonna,
get
into
the
details
of
anonymous
volumes.
They
can
be
very
useful
in
development,
but
I
would
be
very,
very
careful
about
using
them
for
any
type
of
production
use.
A
Now
the
one
thing
about
these
vSphere
data
store
and
the
volumes
we
create
on
them
is
that
they
create
a
one-to-one
mapping
with
the
container.
So
it's
one
running
container
for
one
volume,
so
they're
good
to
use,
for
you
know,
maybe
data
that
needs
to
be
private
to
a
specific
container,
but
they
cannot
be
shared
among
multiple
running
containers.
If
you
want
to
share
data
among
multiple
running
containers,
you
need
to
look
at
our
second
type
of
data
store,
and
this
is
the
NFS
mount
point.
A
Now
it's
important
here
to
point
out
the
key
difference.
So
this
here
is
a
vSphere
data
store.
It
can
be
visan,
it
can
be
ice
cozy,
it
can
be
NFS,
but
if
you're
using
NFS
in
this
concept
in
this
context,
you're
using
NFS
to
back
a
vSphere
data
store,
which
means
that
VM
decays
are
getting
created
when
you're
using
NFS-
and
this
constant
is
this
context-
you're
using
NFS
as
a
mount
point
you're
presenting
an
actual
filesystem
and
files
to
your
containers.
So
it's
two
very
different
contexts,
even
though
we're
using
NFS
to
back
them.
A
So
the
center
fest
mount
point
again.
It
can
be
shared
among
multiple
running
containers
and
the
way
we
specify
that
when
we
create
the
container
host
is
we
need
to
specify
using
NFS
colon,
slash,
slash
that
we
want
to
use
an
NFS
mount
point
for
this
volume
store.
Then
we
need
to
specify
the
IP
information,
so
network
information
on
how
to
contact
the
Sena,
fest
mal
point.
And
finally,
you
can
also
specify
the
UID
and
GID
to
use,
because
that
can
be
the
tricky
part
right,
specifying
the
right
UID
GID.
A
For
that
data
to
be
accessed
from
within
the
container
and
lastly
again,
we
need
to
specify
a
label
in
this
case
for
the
purposes
of
this
example.
Let's
just
call
it
NFS
store
as
the
label
here
so
now,
I've
specified
my
image
store,
I've
created
two
volume
stores
to
be
used.
So
now
let's
switch
gears
and
we're
gonna.
You
know
switch
to
the
persona.
That's
gonna
be
consuming
this,
so
that's
your
darker
end
user
or
your
developer.
You
know
now
I'm
the
person
that's
going
to
be
consuming
this
using
that
docker
API.
A
A
Volume
on
this
vSphere
data
store
and
let's
call
it
that
at
all
so
data
volume.
So
what's
going
to
happen
here
so
under
Vic
volumes,
I'll
get
a
new
folder
called
data
vol
and
under
this
folder
I'll
find
my
VMDK.
So
that's
the
virtual
disk
or
the
virtual
block
device.
That's
going
to
be
used
for
this
volume,
as
well
as
some
metadata
that
we
use
in
the
backend.
A
Volume
store
this
time,
I'm
going
to
specify
the
NFS
store
and
let's
call
this
volume
shared
wall
because,
like
I
said,
since
it's
we're
using
an
NFS
mount
point,
this
can
actually
be
shared.
So,
what's
going
to
happen
here
is
I'm
gonna
get
a
new
sub
directory
under
volumes
called
shared
vault,
it's
gonna
get
created
empty
and
then,
as
I
start
writing
files
to
it
from
the
containers.
This
will
get
populated
all
right,
so
we
now
have
two
volumes
that
can
be
used
with
containers.
A
Now
one
thing
to
observe
here:
the
volumes
are
created,
but
there's
no
containers
yet
so
it's
that
independence,
that's
gonna,
allow
you
to
persist
and
have
these
volumes
survive.
The
lifecycle
of
your
container,
all
right,
let's
run
a
container
and
attach
the
volumes
to
see
what's
happening
so
we're
going
to
do
a
simple
docker
run
command.
A
A
So
let's
look
at
what's
going
to
on
going
on
here,
so
I
run
the
command
against
this
API
endpoint.
So
first
it's
going
to
look
at
this.
My
image.
It
does
not
have
my
image
in
the
image
cache,
so
it's
going
to
go
out
to
the
registry,
pull
down
the
layers
that
make
up
that
image.
It's
going
to
cache
it
here,
version
1.0!
Once
we
have
it
in
the
local
cache,
we
can
actually
instantiate
our
container.
So
it's
instantiate
our
container
here.
A
This
is
vSphere
integrated
containers,
so
every
container
image
gets
instantiated
as
its
own
container
VM.
So
this
is
a
container
VM
running
my
image
version
1.0
and
then,
because
I
specified
these
two
volumes.
These
will
get
mounted
in
my
container
so
/data.
This
volume
here
will
get
mounted
in
slash
data
and
then
slash
shared.
A
This
volume
here
will
get
mounted
in
slash
shared
so
now,
I
have
my
container.
This
piece
here
is
ephemeral,
so
anything
that
gets
written
inside
of
here
will
get
deleted
when
I
get
rid
of
the
container.
But
these
pieces
point
through
external
volumes,
everything
I
share,
I,
write
in
slash
data
or
in
slash
shared,
will
get
written
to
these
volumes,
so
it
will
survive
the
lifecycle
of
this
container.
So
next,
let's
look
at
an
example
of
where
this
is
useful.
A
So
let's
imagine
for
a
second
that
my
development
team
has
released
a
new
version
of
this
image
version
1.1
to
address
the
vulnerability
so
now
I
need
to
update
this
container
to
version
1.1
to
make
sure
that
its
current
and
secure
so
in
the
container
world.
We
don't
really
patch
running
containers.
We
will
patch
an
update
the
image
and
then
we'll
tear
this
one
down
and
will
bring
a
new
container
up
with
the
new
version,
so
you
can
see
we're
having
volumes
that
exist
outside
of
this
container
become
useful
in
terms
of
providing
that
persistence.
A
So
let's
look
at
what
happens
so
first
I'm
going
to
run
docker,
stop
to
stop
this
container
and
then
I'm
going
to
ruin
docker
RM
to
remove
this
container.
So
this
container
will
stop.
It
will
get
deleted.
So
this
is
gone.
This
link
is
gone.
This
link
is
gone
also,
but
these
volumes
are
still
around.
So
if
I
take
this
command
again,
I
run
this
exact
same
command.
The
only
thing
I
change
is
I,
replace
this
1.0
label
with
one
dot
one
label,
so
my
docker
engine
would
look
at
the
sketch.
A
It
does
not
have
the
one
that
one
label
so
go
to
the
registry.
It'll
pull
down
the
necessary
layers
to
update
this
21.1.
So
now
it
has
the
1.1
version
of
the
image.
So
it's
able
to
instantiate
a
new
container
as
a
VM,
so
I
get
another
container
VM,
that's
running
my
image,
now
version
1.1
right
and
then
I'm
reattaching,
the
same
volume,
so
/data
gets
attached
here
and
then
slash
shared,
gets
attached
here
and
now
all
the
data
that
was
written
there
by
the
previous
container
is
accessible
to
this
new
instance.
A
So
to
recap,
we
talked
about
the
different
types
of
storage.
The
image
store
is
mandatory.
It
can
be
any
data
store
in
your
vSphere
environment
existing
or
new
and
dedicated
whatever
you
want
to
do,
and
we
use
it
for
the
VM
running
directory,
as
well
as
the
image
cache,
and
then
we
have
two
types
of
volume
stores.
A
The
vSphere
dot
of
a
data
store
type
of
volume
store
is
great
for
having
this
private
data
that
needs
to
be
just
internal
to
the
container,
and
then
this
NFS
mount
point
is
great
if
you
need
to
share
the
data
between
multiple
running
containers.
So
with
that,
thank
you
for
your
time
and
have
a
great
day.