►
From YouTube: What is a Container?
Description
In this lightboard talk, Ben Corrie explains what a container is for beginners.
For more information, please visit the VMware’s Cloud-Native Apps website:
https://cloud.vmware.com/cloud-native-apps
A
Hi,
my
name
is
ben
corey
and
I'm
here
to
talk
to
you
about
what
is
a
container
now.
That
may
sound
like
a
very
basic
question
to
be
asking
in
2017,
but
I
can
tell
you
every
time
we
go
to
vmworld.
Every
year
we
talk
about
vsphere,
integrated
containers
and
and
container
technologies,
all
the
kinds
of
stuff
that
we're
working
on
here
at
vmware
oftentimes.
We
get
a
kind
of
a
sheepish
look
and
like
actually
what
is
a
container
like
you
know.
Maybe
you've
heard
a
few
things
about
it.
A
A
So
I
think
the
word
container
to
some
extent
is
used
to
cover
a
multitude
of
things.
That's
one
of
the
things
that
I
think
is
a
little
bit
confusing
about
it.
So,
let's
start
the
very
most
simple,
the
very
simplest
form
of
what
a
container
is.
So
here
we
have
an
operating
system.
Okay,
an
operating
system-
this
could
be
in
a
vm,
it
could
be
bare
metal,
doesn't
matter,
but
it's
an
operating
system
and
for
argument's
sake.
Let's
say
that
it's
linux
I
mean
these
days.
A
Most
containers
are
in
linux
and
inside
of
that
operating
system,
you
can
run
processes.
Okay.
Now,
in
the
normal
scheme
of
things,
you
can
run
any
number
of
processes
inside
this
operating
system
and
these
processes
share
an
address
space.
They
share
a
process
namespace,
they
share
pretty
much
everything.
Now,
that's
useful!
Absolutely!
You
know
in
many
cases,
you're
going
to
be
running
all
sorts
of
things
inside
of
one
of
these
operating
systems.
It's
designed
to
do
that.
It's
designed
to
schedule
these
things
and
that's
all
well
and
good.
A
However,
what
if
you
actually
want
to
isolate
one
of
these
processes
from
one
of
the
other
processes?
What
if
you
want
some
kind
of
sandbox
for
that
process
to
run
in
okay,
that,
at
its
most
basic,
is
the
notion
and
the
concept
of
a
container
right,
at
least
as
it
was
originally
envisaged,
it's
basically
a
sandbox
for
a
process.
A
Now
what
I
mean
by
sandbox?
Well,
what
I
mean
by
sandbox
is
that
the
process
for
start
has
its
own
process
namespace.
Okay.
So
when
you,
if
I
were
to
get
a
shell
into
this
container,
I
would
see
just
the
processes
running
inside
of
that
container.
It
has
its
own
process
namespace,
so
we've
got
a
process
namespace.
A
We
also
have
c
groups
which
allows
us
to
also
restrict
what
this
process
is
able
to
do
right.
There
are
certain
capabilities:
there
are
certain
resource
limits
that
we
can
apply
to
this
container
and
that
allows
us
for
a
certain
degree
of
isolation
when
it's
combined
with
the
process
namespace,
that's
the
most
fundamental
notion
of
the
runtime
definition
of
a
container,
it's
basically
an
isolated
process,
a
process
running
in
a
sandbox
that
typically
only
sees
other
processes
or
other
things
that
are
started
in
the
same
container.
A
So
when
you
start
the
container,
it
starts
the
container
process
when
the
container
process
exits,
the
container
ends
right,
so
the
container
process
and
and
the
container
life
cycle
are
completely
tightly
coupled
now
within
the
container.
You
may
have
other
processes
running
right.
There
may
be
threads
that
are
kicked
off.
There
may
be
a
demon
process
that
started.
A
A
So
then,
let's
think
about
you
know,
I
said
earlier
on
this
whole
notion
of
a
container
is
somewhat
overloaded.
Let's
think
about
what
other
things
the
word
container
can
mean.
Well,
there's
such
a
thing
as
a
container
image,
and
quite
often,
when
we
talk
about
containers,
we
actually
conflate
the
word
container.
With
with
an
image,
we
actually
mean
an
image
and
what
is
a
container
image?
Well,
an
image
is
very
simply
a
binary
representation.
A
A
The
interesting
thing,
though,
about
a
container
image,
at
least
in
the
way
that
we
think
about
containers
today,
is
that
there's
also
a
notion
of
apparent
child
relationship
and
image
layering.
Let
me
explain
what
I
mean.
So
if
we
start
at
the
at
the
root
of
this
parent
child
tree,
we
have
an
image
called
scratch
and
the
scratch
image,
basically
is
just
a
completely
empty
think
of
it
as
an
empty
formatted
file
system.
Right,
it's
basically
nothing
now,
on
top
of
scratch,
we
might
have
the
basics
of
an
operating
system.
A
A
A
A
The
whole
point,
though,
is
that
the
images
are
arranged
in
this
image
hierarchy
and
it's
think
of
it.
It's
very
much
like
the
notion
of
snapshots
right,
like
disk
snapshots.
You
know
you've
got
this
binary
state
here
and
you
add
something,
and
that
creates
a
snapshot.
You
add
something
else
to
it
and
that
creates
a
snapshot.
A
One
of
the
good
things
about
this
is
that
it
allows
you
to
share
images
right
because
you
end
up
with
this
tree
effectively
and
anytime,
that
you
want
to
run
an
application.
Well,
you'll
pull
a
branch
of
this
tree,
but
the
other
nodes
may
well
be
shared
by
other
things
that
you're
running,
so
it
actually
allows
for
quite
a
lot
of
consolidation
of
binary
state,
which
is
a
good
thing
right,
you're
not
having
to
shift
around
entire
application
stacks
in
single
files,
which
is
which
can
be
kind
of
painful.
A
Another
big
advantage
of
this
is
it
allows
you
to
concentrate
specific
things
in
specific
places
right
and
know
where
they
are
so,
for
example,
this
busy
box
here
it
could
be
ubuntu,
it
could
be,
it
could
be
anything
it
could
be
centos,
but
let's
say
that
I
discover
a
particular
vulnerability
in
the
user,
libraries
in
centos
right
or
in
busybox,
and
I'm
like
oh
wow.
Okay,
I
need
to
replace
this
well
now.
I
need
to
understand
all
of
the
other
applications
that
I'm
running,
that
is
going
to
be
impacted
by
that
vulnerability.
A
Well
now,
because
of
this
tree
structure,
that's
actually
pretty
easy
to
figure
out,
because
every
single
child
node
every
descendant
of
this
busy
box
node,
is
going
to
be
impacted
by
that
vulnerability,
because
I
know
that
it's
here-
and
I
know
that
all
these
things
inherit
from
that
node.
So
by
rebuilding
this
and
then
rebuilding
everything
else
and
redeploying
everything
else.
I
have
a
high
degree
of
certainty
that
the
thing
that
I
patched
here
is
now
inherited
by
everything
else.
So
that's
also
a
good
thing.
A
So
this
whole
question
of
of
of
images
is
tied
in
with
this.
This
whole
question
of
the
runtime
notion
of
a
container,
and
it's
a
little
bit
like
the
whole
class
object
concept
right.
An
image
is
like
a
class
right,
it's
a
template
for
something
and
then
you
can
create
any
number
of
instances
of
that
template
and
it
has
this
runtime
representation.
A
A
So,
let's
talk
specifically
about
the
docker
use
case,
because
it's
it's
helpful
to
do
that.
Docker
has
added
a
ton
of
really
useful
abstractions
to
the
whole
container
abstraction
there's
this
basic
container
abstraction
that
makes
life
way
easier
and,
and
it
adds
huge
value
to
this
whole
experience.
So,
let's
talk
about
the
docker
file.
Okay,
you
may
have
heard
of
a
dockerfile.
A
What
is
a
dockerfile?
A
dockerfile
is
basically
an
environment
in
a
file
in
a
text
file
and
you
may
not
know,
but
the
start
of
a
dockerfile
is
just
from
right
from
what.
What
does
that
mean?
Well
from
is
the
parent
image
that
this
dockerfile
is
inheriting
from
so
here
we'll
say
from
and
we'll
say
from
busybox
for
example,
and
then
within
here
we
can
basically
run
any
number
of
things
that
we
want
to
configure
the
image
that
this
docker
file
is
going
to
create.
A
There
are
cache
layers,
that's
a
little
bit
more
advanced,
but
suffice
to
say
that
a
dockerfile
is
typically
a
starting
point
for
an
image,
because
it
makes
that
really
really
easy.
Then
how
do
we
make
containers?
Well,
containers
come
from
images,
so
we
go
from
dockerfile
to
image
to
container,
but
we
can
also
create
an
image
from
a
container.
We
can
actually
go
from
here
back
to
here
again
and
the
way
that
we
can
do
that
is.
We
can
say:
okay,
I'm
going
to
run
a
container
and
I'm
going
to
log
into
it.
A
I'm
going
to
get
a
shell
into
it
and
I'm
going
to
run,
install
this
and
modify
that
and
add
this
configuration
file
and
do
whatever
modifications
I
want
to
make,
and
then
I
can
commit
that
as
an
image
and
then
from
that
image
create
more
containers.
So
I
don't
have
to
start
from
the
docker
file.
I
can
move
between
these
two
things
here,
but
hopefully
that's
a
good
and
helpful
illustration
of
the
relationship
between
these
things.
A
Now.
Another
thing
that's
worth
worth
calling
out
here
is
that
you'll
notice
that
a
container
is
packaged
with
all
of
its
dependencies,
which
again
is
distinct
to
some
extent
from
from
most
applications.
Most
applications
you'll
install
into
your
operating
system
and
your
operating
system
will
already
have
quite
a
few
dependencies
in
it.
It
will
certainly
have
the
user
libraries.
It
may
well
have
some
basics
like
shd
perl.
A
Well
with
with
containers,
it's
expected
that
all
of
the
dependencies
pretty
much
above
the
kernel
are
packaged
inside
of
the
container.
So
when
you
run
the
container
in
an
operating
system,
you
actually
don't
install
anything
right.
Nothing
is
actually
installed
into
this
thing.
It
just
it
sits
above
the
operating
system
in
its
own
in
its
own
world
and
its
own
stack,
and
that
again
is
a
really
powerful
thing,
and
it's
partly
why
we
use
this
word
container,
because
the
whole
notion
of
a
container
is
it
contains
right.
A
It
contains
everything
that
you
need
to
run
an
application.
So
one
of
the
things
people
have
found
about
containers,
it's
actually
really
nice
is.
You
can
run
any
number
of
different
versions
of
applications
that
require
different
versions
of
libraries
and
you
can
run
them
all
on
top
of
a
single
operating
system
and
because
none
of
these
dependencies
are
installed.
A
If
you
delete
these
images,
it's
all
gone
right,
you
just
the
the
whole
thing
is
back
to
a
completely
clean
state
and
so
in
the
in
the
in
the
world
of
things
like
jenkins
slaves.
This
is
a.
This
is
a
huge
boon
because
we
can
actually
run
stuff
on
them
without
polluting
them
right.
So,
okay,
we've
looked
at
images.
We've
looked
at
the
runtime
notion
of
containers
and
we've
looked
at
a
dockerfile,
so
let's
tie
all
of
this
together.
A
So
how
do
we
tile
these
things
together?
Well
out
there
in
the
world
somewhere
there
will
be
a
thing
called
a
registry.
Now
the
registry
is
a
thing
that
contains
these
images
right.
These
snapshots
that
I
mentioned
and
you
can
pull
and
push
from
the
registry
at
will.
Okay,
now
remember
when
you're
pulling
and
pushing
you're,
typically
only
pulling
and
pushing
the
bits
that
you
need,
because
inside
of
this
host
there
is
an
image
cache.
A
So
if
I
want
to
run,
let's
say
my
application
and
I
do
docker
pull
what
it's
going
to
do.
Is
it's
going
to
say,
okay,
how
many
of
these
parent
nodes
do?
I
already
have
in
this
image
cache
and
it
will
pull
the
ones
that
it
needs
and
if
I
then
create
choose
to
create
a
derivative
of
this
a
a
child
of
this.
I
can
push
that
to
the
registry,
but
I'm
only
pushing
the
diff,
because
that's
all
I
need
to
push
because
everything
else
isn't
in
the
registry.
A
A
We've
been
through
some
of
these
things
already,
but
these
are
some
of
the
basic
things
the
client,
so
the
client
manages
the
life
cycle
of
containers
inside
of
this
docker
host,
but
it
actually
does
more
than
that.
It
not
only
manages
the
lifecycle
of
the
containers,
but
it's
also
designed
to
be
able
to
configure
the
infrastructure
inside
of
this
docker
host
as
well.
So
it's
not
only
container
lifecycle
management,
but
it's
also
able
to
do
network
configuration
and
storage
configuration.
A
So
what
I
mean
by
network
and
storage
configuration
well
inside
of
this
docker
host
docker
will
set
up
certain
kinds
of
networking
right
now.
We're
not
going
to
go
into
detail
on
that,
because
that
that
would
be
a
topic
for
another
day
but
using
the
client.
It's
a
it's
a
kind
of
network
virtualization
that
happens
in
here
using
the
client.
I
can
basically
choose
to
do
port
forwarding.
I
can
choose
to
do
all
sorts
of.
A
I
mean,
there's
all
sorts
of
plugins
as
well,
that
give
me
much
more
complex
overlay,
networking
and
other
capabilities,
but
from
the
client.
I
can
control
all
of
that
networking
and
I
can
say:
okay,
I
want
to
create
a
network
for
containers
to
talk
to
each
other
on.
I
want
to
you
know,
assign
this
container
to
this
network.
I
want
to
create
links
so
that
containers
can
refer
to
each
other
by
certain
types
of
host
name,
there's
all
sorts
of
network
configuration.
I
can
do
from
this
docker
client
in
terms
of
storage
configuration
typically.
A
The
main
thing
I
want
to
do
with
storage
is
to
create
volumes.
So
there
is
a
thing
in
docker
called
a
volume,
and
a
volume
is
very
simply:
a
persistent
area
of
storage,
so
container
will
have
or
may
have
a
volume
if
it
wants
to
persist
any
data
beyond
the
life
cycle
of
the
container.
Remember
early
on,
we
talked
about
how
the
process
is
completely
tied
to
the
life
cycle
of
the
container.
Well,
the
container's
state
is
also
ephemeral
and
completely
tied
to
its
life
cycle.
A
The
moment
you
delete
a
container,
you
delete
all
of
the
state
that
it
wrote.
So
if
you
actually
want
to
persist,
any
state
you've
really
got
two
options.
You
either
create
a
volume
and
you
mount
it
to
a
container
or
you'll
push
it
out
on
a
network
socket
to
somewhere
right.
Those
are
the
two
things
that
you
typically
do.
A
So
the
client
manages
storage.
The
client
manages,
let's
just
put
a
network
in
here
right.
The
client
manages
networking
and
it
manages
the
container
life
cycle.
So
let's
say
we
start
a
container.
Let's
say
we
start
my
app
well,
we
go
client
docker
run
my
app
okay.
Well,
let's
say
it's
pulled
all
of
the
images
it
needs
from
the
registry
and
the
images
are
in
the
image
cache
or
what
it's
then
able
to
do.
A
So,
to
summarize,
when
we
talk
about
a
container,
we're
talking
about
a
whole
bunch
of
things,
we're
talking
about
the
container
image
and
its
relationship
to
other
images,
we're
talking
about
the
runtime
represent
representation
of
a
container
we're
talking
about
the
way
in
which
we
create
and
build
and
define
what
a
container
is,
and
then,
when
we
tile
that,
together
with
something
like
a
registry
and
a
client,
we
have
this
ecosystem
this
world,
in
which
we
can
then
spin
up
containers,
control
infrastructure
and
tie
all
these
things
together.
I
hope
that
was
informative.