►
Description
Interested to hear how you can provide a native Docker experience for end users while maintaining a vSphere experience for IT?
vSphere Integrated Containers Engine is an open source project designed to tightly integrate container workflows, life cycles, and provisioning with the VMware software-defined data center (SDDC). In vSphere Integrated Containers, a container is a hardware-virtualized first-class citizen on the hypervisor provisioned into a Virtual Container Host (VCH) and able to directly integrate with vSphere infrastructure capabilities, such as networking and storage features.
In this open source webinar Patrick Daigle will walk you through how vSphere Integrated Containers works and how it provides an ideal way to host containers on vSphere. See a live demo on how vSphere Integrated Containers leverages vSphere for isolation and scheduling. You will also hear some of the learnings from real-world use cases.
A
One
number
one
and
welcome
to
today's
webinar
we're
super
super
excited
to
have
you
all
here.
This
is
a
webinar
series
where
we're
introducing
and
explaining
some
of
the
interesting
open-source
projects.
That's
done
from
VMware
and
the
topic
of
today
is
a
project
called
vSphere
integrated
containers
with
a
focus
on
the
vSphere
integrated
container
engine.
If
you
have
any
questions
throughout
the
webinar,
please
add
them
to
the
Q&A
at
the
bottom
of
your
resume
client
and
we
will
answer
them
there
throughout
the
presentation
our
speaker
today
is
Patrick.
A
Bagel
Patrick
has
been
with
VMware
for
11
years,
which
is
a
long
time
so
he's
a
veteran
at
VMware.
It's
been
focused
on
cloud
native
applications
for
over
4
years
and
working
on
Vic
the
vSphere,
integrate
containers
and
related
open
source
project
for
the
past
two
years.
With
that
I'm
gonna
hand
it
over
to
Patrick
who
will
start
this
presentation
all.
B
B
Then
we're
going
to
get
right
into
these
four
integrated
containers,
I'm
going
to
give
you
a
bit
of
a
technical,
deep
dive
into
some
of
the
components
that
make
up
the
engine
and
then
we'll
spend
I'm
hoping
more
than
half
of
this
session
on
a
demo
in
my
live
environment,
as
Jonas
said,
if
you
have
any
questions
during
the
Q&A,
please
put
them
in
the
Q&A
window.
I
will
be
monitoring
it
and
pausing
throughout.
So
we
can
answer
your
questions
as
they
as
they
appear
all
right.
B
So
we're
hoping
to
get
even
more
contributions
for
from
the
open
source
community
on
that
one
and
then
a
number
of
others
like
hatchway
that
aims
to
bring
transparent
access
to
vSphere
storage
for
container
workloads
Amaral.
That's
also
part
of
these
contributed
containers
and
it
it
provides
a
lightweight
management
portal
for
your
containers
and
your
container
hosts,
as
well
as
a.
A
B
Of
others
that
that
you
can
see
when
you
visit
the
VMware
github
page
today,
we're
going
to
focus
on
these
four
integrated
containers.
There's
three
main
components
of
these
four
integrated
containers.
There's
the
engine
component
that
we're
going
to
focus
on
today,
then
there's
the
container
registry.
Again.
This
is
based
on
project
Harbor.
It's
an
open
source
project
at
VMware.
It
provides
a
docker,
compatible
container
registry
that
provides
a
lot
of
the
controls.
B
You
need
to
run
a
container
registry
in
an
enterprise,
so
things
like
things
like
authentication
against
the
company
directory
built-in
vulnerability
scanning
built-in
image
signing
a
lot
of
those
controls
that
you
need
to
run
a
container
registry
and
integrated
in
an
enterprise.
That's
been
operationalized
for
production.
The
last
piece
of
the
visa
through
gritted
container
is
the
management
portal
and
again
that's
a
lightweight
management
portal
that
we
have.
B
Managing
your
vSphere
infrastructure,
if
you're
interested
here
are
some
of
the
links
to
the
actual
github
repos
for
these
projects.
So
Admiral
again
is
the
portal.
Harbor
is
the
registry
and
then
Vic
itself
is
made
up
of
three
repositories.
The
main
one
is
Vic,
that's
where
all
of
the
engine
things
that
we're
going
to
talk
about
today
is
built.
B
Then
we
also
have
Vic
UI,
that's
the
repo
that
we
have
for
the
vSphere,
client,
html5
integration
and
then
Vic
product
is
where
we
keep
all
of
the
tools
and
the
scripts
that
we
use
to
build
the
OVA.
The
OVA
is
used
as
a
distribution
mechanism
for
the
officially
supported
versions
of
vSphere
integrated
containers,
because,
while
this
is
an
open-source
project,
it's
available
to
all
for
free
vSphere
customers
have
access
to
these
official
releases
that
they
can
deploy
and
get
full
support
from
vmware,
that's
included
in
their
vSphere
Enterprise
Plus
and
Robo
advanced
support.
B
B
We
typically
start
with
a
standard
linux
host,
that's
running
a
standard
linux
kernel
and
then,
on
top
of
it,
we
need
to
install
a
number
of
management
and
tools
to
make
that
machine
useful-
and
this
is
what's
often
referred
to
as
a
distribution,
so
that
Linux
distribution
gives
you
a
number
of
basic
libraries
and
tools
to
get
up
and
running,
and
then
once
we
have
that
distribution
on
top
of
it,
we
can
install
the
the
mid-tier,
so
the
application
middleware
that
we
need
to
actually
run
the
application.
So
that
can
be
Apache.
B
You
know
you're,
probably
today
using
things
like
virtual
machine
templates,
or
maybe
your
are
already
using
some
configuration
management
tool
to
help
with
deploying
this
in
a
timely
manner
and
in
a
consistent
manner.
But
all
of
this
is
has
its
own
challenges
as
you're
aware
over
time.
You
know
maintaining
these
images
in
a
consistent
state
making
sure
that
they
haven't
drifted
from
the
original
configuration
that
we
put
in
there.
These
tend
to
be
long-lived,
there's
some
configuration
management
headaches
as
well.
B
If
my
app
process
here,
for
example,
process,
one
requires
a
certain
version
of
a
library
but
my
app
process
2
requires
a
different
version
of
that
library.
It
can
create
some
nightmares
in
terms
of
keeping
that
that
hosts,
up-to-date
and
patched
and
current
so
with
containers
containers
really
provide
a
way
to
reliably
package
an
application
with
all
of
its
dependencies.
So
we
start
with
a
similar
linux
host
that
we
had
in
the
past.
B
But
in
this
case
we
start
with
the
same
an
external
standard,
Linux
kernel,
but
what
we
deploy
on
top
of
this
machine
is
a
container
engine,
so
we're
using
docker
as
an
example
here.
But
there
are
a
few
others
that
are
emerging
as
well,
so
you
start
with
a
Linux
kernel,
a
lightweight
linux
distribution
that
gives
you
a
container
engine,
and
then
you
can
start
deploying
containers
on
top
of
that
linux
host.
So
what's
in
a
dr
container
container
is
built
from
a
container
image.
B
B
That's
going
to
run
inside
of
my
container,
so
here
I'm
running
Apache,
with
my
user
data
and
running
that
inside
the
container.
So
what
this
means
is
that
I'm,
actually
starting
from
this
Ubuntu
distribution,
I'm,
installing
all
the
tools
that
I
need
inside
of
the
container
to
run
my
application
and
then
finally,
I
can
run
the
actual
process
and
run
my
application.
So
that
means
that
I
can
very
reliably
and
predictably
package
my
application
now
with
all
of
its
dependencies.
B
The
other
important
aspect
here
is
that
docker
has
created
a
very
rich
set
of
lifecycle
management
tools
that
allow
you
to
create
those
containers
update
them
run
them.
So
you
know
that
whole
workflow
of
lifecycle
management
tools
is
a
very
important
aspect
and
something
I
think
that
helped
really
drive
the
adoption
of
containers.
B
Another
interesting
side
effect
is
that
it
may
not
be
a
best
practice
to
do
this,
but
it
allows
you
as
well
to
start
from
different
distributions
of
Linux
as
your
sort
of
baseline
in
your
containers
to
start
building
your
containers
and
meet
your
applications
requirements.
So
it's
not
necessarily
a
best
practice.
The
mix
Linux
distribution,
although
these
things
are.
B
Isolated,
you
know
they
use
os-level
isolation
with
this.
With
these
Linux
containers,
it's
not
necessarily
a
best
practice,
but
it
is
a
possibility
and
it
just
goes
to
show
that
it's
a
way
more
flexible
model
for
packaging
applications
and
making
sure
that
all
the
dependencies
are
met
and
match
that
application
over
time.
So
you
can
understand
why
developers
like
containers,
they're,
very
portable,
so
a
container
that
I
build
on
my
Mac
laptop
today.
B
I
can
take
this
exact
same
container
drop
it
into
my
my
maybe
my
internal
private
cloud
where
I
have
a
container
engine,
maybe
I
drop
it
into
Amazon
ec2,
where
they're
providing
a
container
runtime
anywhere.
You
have
a
container
runtime.
You
can
take
this
image
and
move
it,
so
it
enables
some
very
interesting
things
like
moving
from
dev
to
test
the
prod
moving
across
different
different
infrastructure,
be
it
on
Prem
and
off.
B
Prem
containers
are
often
seen
as
a
sort
of
a
stepping
stone
to
cloud,
and
that's
one
of
the
reasons
why
containers
are
typically
very
fast
to
start
because
they're
sitting
on
top
of
an
OS,
that's
already
running
and
they're,
basically
only
bringing
up
the
application
itself
and
it's
dependencies,
they're
very
fast
to
start
and
they're
they're,
very
lightweight
so
again,
I'm,
not
packaging,
anything
that
I
don't
need
I'm,
just
packaging.
The
the
things
I
need
to
run
my
application
and
lightweight.
B
If
we
look
at
what
Ops
needs,
though
you
know,
their
needs
are
very
different
and
there's
some
problems
with
not
problems,
but
you
know
some
things.
We
containers
that
we
need
to
address
and
that
we
need
to
look
at
before.
We
can
think
about
moving
them
to
production
that
are
very
important,
are
around
networking
and
security.
B
You
know,
container
hosts
have
their
own
internal
networking.
They
have.
This
thing
called
a
bridge
network
that
that
allows
containers
to
talk
to
one
another
and
to
talk
to
the
host.
That's
kind
of
this
obfuscated
things
that
lives
inside
of
the
host,
where
it's
very
hard
to
get
visibility
from
a
security
standpoint
like
I,
can
put
a
big
bubble
around
my
my
container
host,
but
it's
pretty
hard,
although
there's
tools
emerging
now
that
allow
you
to
do
it
it's
harder
to
get
into
the
the
abstraction
level
of
the
container
and
have
introspection
at
that
level.
B
Another
problem
that
is
common
is
data,
persistence,
so
containers
as
I
showed
you
they're
immutable.
They're
there
they're
non
persistent,
so
you're,
not
you
never
patch,
a
running
container.
You
basically
create
a
new
version
of
the
container
image,
kill
the
old
running
container
and
instantiate
the
new
one.
So
that
means
that
if
you
want
to
persist
data,
if
you
have
data
that
needs
to
survive
the
lifecycle
of
the
container,
it
has
to
live
outside
of
the
container
itself.
B
So,
if
we
look
at
this
from
the
standpoint
of
the
provider
versus
the
consumer,
vSphere
integrated
container
sits
right
on
top
of
your
virtual
infrastructure.
You
don't
need
to
change
anything
in
your
virtual
infrastructure
to
run
it
you
just
basically,
if
you're,
using
the
open-source
version.
You're
running
a
command
line
called
Vic
machine
to
create
your
virtual
container
host
and
you're
ready
to
go
and
and
really
from
the
provider
standpoint.
The
provider
is
using
all
the
tools
that
they
have
that
they
know
today
for
maintaining
and
using
their
virtual
infrastructure.
B
So
Vic
installs
on
top
of
vSphere,
you
see
NSX
and
V
San
here
they're,
not
dependencies.
If
they're
there,
we
have
some
integrations
that
allow
us
to
bring
additional
benefits,
but
it's
not
a
requirement.
We
can
deploy
this
on
a
single
ESXi
server
and
it
should
work.
And
then
we
have
this
concept
of
the
virtual
container
house
that
I'm
going
to
dive
into
as
well
as
these
components
that
you
see
here
these
three
components
that
have
a
Linux
kernel
and
a
container
application
running
on
top
of
them,
they're.
B
What
we
call
container
VMs
and
we're
going
to
talk
about
those
and
see
how
those
are
deployed
and
some
of
the
benefits
that
they
bring
so
diving
into
the
engine
so
again
to
understand
how
we
do
things
differently
with
Vic
engine.
It
helps
to
look
at
the
way
that
things
are
done
normally.
So,
if
you're
running
containers
today
chances
are
you're
deploying
a
Linux
VM
on
top
of
which
you're
installing
a
container
engine
so
again
we're
using
docker
engine.
B
So
you
can
put
a
big
firewall
around
this
docker
host,
but
it's
very
hard
to
understand
and
see
and
put
controls
around
how
these
containers
are
talking
to
one
another
out
there
talking
to
the
hosts
and
things
like
that.
So
what
we
did
with
peacefully
containers
engine
is
that
we
took
the
engine
out
of
the
of
the
host.
So
we
have
our
Vic
engine
that's
running
inside
of
its
own
VM,
and
we
put
this
inside
this
VM
inside
of
a
resource
pool.
So
we
use
the
resource
pool
as
well
use
it
for
two
things.
B
We
use
it
as
a
resource
management
construct,
so
it
gives
us
a
very
flexible
way
of
managing
the
resources
that
are
available
to
this
virtual
container
host
and
two.
It
allows
us
to
group,
together
all
of
the
container
VMs
that
we
spin
up
that
belong
to
this
container
engine,
so
using
the
same
building
blocks
that
docker
uses.
So
we
use
the
same
docker
image
same
same
format.
You
can
use.
You
can
pull
docker
images
from
from
docker
hub
and
they'll
work
here,
but
using
the
same
building
blocks.
B
What
we
do
is,
instead
of
using
that
docker
image
and
building
a
Linux
container
using
a
namespace
using
a
c
group.
We
use
those
same
building
blocks,
but
instead
we
build
a
VM.
So
this
is
a
very
lightweight
VM
that
we
call
a
container
VM
terms
of
its
management
lifecycle.
It
sits
under
the
control
of
the
Vic
engine.
So
it's
a
container
VM,
it's
a
full
fledge
VM.
It
shows
up
in
your
V
Center
inventory
as
a
first-class
citizen.
B
It
we
use
a
lightweight
linux
kernel,
that's
based
on
photon
OS,
to
bootstrap
the
VM
and
then
once
the
VM
is
up
and
bootstrapped.
We
use
the
different
layers
of
the
docker
image
to
build
a
VMDK.
We
mount
that
VMDK
in
the
container
vm
and
then
we
Schrute-
and
we
run
that
entry
point
that
I
showed
you
before.
So
this
is
a
very
lightweight
VM.
That's
running
just
the
application.
That's
defined
inside
of
your
inside
of
your
container
image,
so
the
container
engine
is
running
separately.
B
B
B
Vick
engine
really
quickly,
it
allows
you
to
run
docker
images
as
VMs
in
vSphere.
So
what
that
means
is
that
we
use
the
same
building
block
docker
client,
dr.
API,
this
the
same
docker
image
format,
but
we
instantiate
everything
as
a
VM
so
that
their
first
class
citizen
in
your
environment,
you
get
full
visibility.
You
can
apply
security
policies
the
same
way.
You
apply
them
to
your
VMs.
Today,
it's
a
fully
open
source
project.
It's
available
on
github.
As
we
see
here,
I
talked
about
the
the
Enterprise
Plus
and
mobile
advanced.
B
It
says
need
here
it
you
need
it
if
you
want
to
be
to
have
support
from
VMware,
but
you're
you're.
More
than
welcome
to
download
this
and
run
it
if
you,
if
you
want
directly
from
the
open
source,
if
you
are
a
vSphere
customer
I,
would
encourage
you
to
download
the
official
releases,
because
then
you
can
call
it
via
more
support
to
get
help
and
it's
a
feature
of
vSphere
takes
advantage
of
all
the
other
constructs
that
are
in
here
container
VMS.
We
talked
about
a
little
bit.
B
B
They
they're
lightweight
VMs
that
are
under
the
control
of
our
Vic
engine,
the
amount,
the
images
as
read-only.
So
again,
all
these
all
these
characteristics
of
containers,
where
they're,
immutable
and
I
can
bring
them
back
to
a
known,
good
state,
very
easily
they're,
all
they're
all
present.
Here
they
have
an
ephemeral
storage
layer
on
top
of
it,
we
can
also
attach
them
to
persistent
volumes.
B
So
we're
gonna
talk
a
little
bit
more
about
how
that
works
and
I'm
going
to
show
it
to
you
in
the
demo
as
well,
but
we
use
a
tether
processed
with
a
lot
of
container
VMs
to
be
controlled
by
by
ESX
and
vCenter,
and
you
know
this
container
VM
again,
it's
a
first-class
citizen.
So
it's
connected
to
a
port
group.
It's
not
connected
to
a
sort
of
a
virtual
network
that
lives
on
the
inside
of
the
container
host,
as
in
the
native
docker
model.
This
is
connected
to
a
real
port
group.
B
So
if
you
have
any
type
of
network
flow
monitoring
tool,
it'll
pick
up
all
the
traffic
coming
in
and
out
of
this
container
VM
the
virtual
container
host.
That's
a
combination
of
the
resource
pool
that
we
use
to
again
group
the
container
VMs
and
provide
resource
management
as
well
as
one
VM
that
we
provision
in
there.
That
gives
you
that
docker
compatible
endpoint
and
that's
the
virtual
container
host
VM,
so
at
stalker
CLI
compatible
the
containers
don't
share
the
kernel,
the
control
plane,
so
the
docker
engine
itself.
B
The
container
engine
itself
is
running
separate
from
the
visa
from
the
from
the
confirm
the
containers.
So
you
know,
if
you
look
at
a
lot
of
the
security
problems
around
containers
that
you
need
to
solve.
A
lot
of
them
have
to
do
with
isolating
containers
from
one
another
isolating
containers
from
the
hosts
hardening
that
host-
and
none
of
these
apply
here
because
every
container
is
inside
of
its
own
VM
and
the
engine
is
running
inside
of
its
own
VM
and
then
the
engine
itself
is
booting
off
of
an
ayah.
So
that's
immutable.
B
B
That
virtual,
like
the
virtual
container
hosts
like
I,
said
the
resource
pool
contains
a
VM.
That's
the
API
endpoint.
So
that's
the
thing
that
speaks
docker,
so
the
darker
personality
that
you
see
here
at
the
top
actually
speaks
docker
and
then
the
port
layer
services,
that's
a
layer
that
we
have
as
part
of
the
vic
architecture
that
actually
translates
these
docker
commands
and
translates
them
into
vSphere.
So
that's
what
allows
us
to
take.
You
know
your
docker
run
command
and
then
tell
vSphere
create
the
VM
connected
to
this
network.
B
It
also
needs
a
persistent
volumes
so
connected
to
this
go,
create
a
VM
DK
on
this
datastore
connected
to
it
so
on
and
so
forth.
So
at
a
high
level,
this
is
the
the
architecture.
The
port
layer
provides
that
abstraction
between
the
vSphere
layer
and
the
container
runtime,
and
then
the
darker
personality
is
the
thing
that
that
allows
you
to
talk
docker
and
and
provide
that
docker
native
experience
to
your
end-users.
B
The
packaging
there's
the
Vik
machine
CLI
that
allows
you
to
control
to
create
the
virtual
container
hosts,
there's
the
appliance.
That
is,
oh,
that's,
basically,
the
ISO
that
we
use
to
boot,
the
virtual
container
host
and
then
the
bootstrap
ayah.
So
that's
the
very
lightweight
is
so
that
we
use
to
to
boot
the
container
VMs
and
that
provides
that
just
enough
Colonel
I
think
it's
it's
at
about
sixty
five
Meg's.
Currently
the
kernel
image
that
that
we
use
to
bootstrap
the
actual
container
image
yeah
all
right.
So
let
me
switch
over
to
the
live
demo.
B
And
switch
over
to
my
demo
environment
so
here
I
have
a
vSphere,
6.5
environment.
It's
made
up
of
a
cluster
of
three
ESX
hosts
I've,
already
created
the
virtual
container
host.
So
you
can
see
here
the
virtual
container
host
resource
pool.
So
this
is
where
I
can
go
in
and
edit
the
resources
that
I
want
to
make
available
to
this
container
host.
So
by
default
it's
created
as
expandable
and
unlimited.
But
if
you
get
a
consumer,
that's
using
a
lot
of
resources
and
you
want
to
avoid
problems
with
you
know
noisy
neighbor
type
of
problems.
B
Then
you
can
go
in
here
and
and
put
a
limit
to
how
many
resources
are
available
and
then
inside
of
this
virtual
container
host.
We
also
have
like
I
said:
one
VM
is
the
virtual
container
host
API
endpoint.
So
this
is
the
thing
that
speaks
docker
when
I
configure
my
doctor-client.
In
a
few
minutes,
I'm
gonna
tell
dr.
client
to
point
to
this
API
endpoint
instead
of
running
on
the
on
the
local
docker
engine.
So
as
part
of
the
integration
we
provide
you
with
the
docker
API
endpoint
environment
variables.
B
This
is
basically
the
thing
you
would
need
to
provide
to
your
end
user
in
order
to
configure
their
their
doctor
client
to
speak
to
this
endpoint
there's
also
a
lightweight
admin
portal
that
we
have
here.
That
gives
you
some
basic
information
about
the
health
of
the
container
host
as
well
as
access
to
the
logs.
So
that's
the
engine
I
mean
that's
what
that's
what
this
is
the
processes?
You
would
download
download
a
build
off
of
the
open
source
page
and
then
you
get
a
directory
called
dick,
and
in
here
you
have
the
Vic
machine
command.
B
Vic
machine
command
is
available
for
Linux,
for
Mac
and
for
Windows.
So
whatever,
whatever
flavor
you're
running,
you
can
run
the
Vic
machine
command
and
this
Vic
machine
command
would
allow
you
to
create
your
container
hosts.
Now,
if
you're
running
the
the
version
that
we
have
not
the
open
source
engine,
but
the
full
Vic
version
that
we
have
that
we
package
for
our
vSphere
customers,
then
you
would
have
a
few
more
options.
B
B
Container
hosts
running
containers-
and
it
also
has
integration
into
also
has
integration
into
the
harbor
registry.
So
this
is
the
harbour
registry
here,
so
you
can
see.
I
have
three
images,
then
I
put
my
private
registry
and
you
can
see
the
built
in
vulnerability
scanning,
as
well
as
the
image
signing.
That's
provided
and
I
can
set
security
policies,
but
I'm
not
going
to
speak
I'm
not
going
to
touch
on
that
too
much
I
see
a
question
in
the
Q&A.
How
easy
is
it
to
run
and
test
the
cloaca
Li
on
the
desktop?
B
A
B
You
can
run
this
against
a
single
ESXi.
You
know
it's,
it's
really
configuration
for
testing
and
you
know
again
you're
testing
only
the
engine
at
that
point,
but
it's
absolutely
a
configuration.
It's
it's
an
our
documentation
and
it's
something
you
can
do.
It's
not
the
configuration
we
recommend
to
work,
run
workloads
in
production
necessarily,
but
if
you
want
to
just
have
something
up
and
running
to
test,
that's
a
good
way
to
do.
It.
B
B
B
We
can
see
that
it's
connected
to
some
data
store
as
well.
So
all
these
things
are
configured
by
the
vSphere
admin,
so
you
maintain
a
lot
of
control
as
the
vSphere
admin
on
what
resources
will
be
available
to
consume
via
the
docker
API.
So
again,
if
I
look
here,
I
can
see
that
I
have
this
bar
API
endpoint.
So
again,
this
is
the
only
thing
I
need.
So
if
I
switch
over
to
more
of
a
developer
of
you
here,
I
have
a
Linux,
workstation,
I'm
running
a
standard.
B
Doctor
client
I
think
this
is
version
1706,
so
this
is
darker
Community
Edition
client
that
I'm
running
and
then
I
already
set
my
rocker
host
to
talk
to
this
remote
endpoint
that
I
have.
So,
if
you
don't
specify
this
docker
host,
it's
gonna
happen
as
Dockers
gonna.
Try
to
talk
to
the
local
docker
engine
in
this
case,
I
want
to
talk
to
this
remote
docker
engine.
That's
sitting
in
my
data
center.
My
vSphere
data
center,
so
from
here
I
can
run
standard
commands
like
docker
info.
For
example.
Docker
info
gives
me
information
about
the
engine.
B
That's
listening
on
the
other
end,
so
I
can
see
that
this
answers,
just
like
I,
expect
the
docker
engine
to
answer.
But
if
I
look
closely
I'm
gonna
start
to
see
some
vic
specific
things,
so
you
can
see
that
I'm
running
the
Vic
1
for
3
back-end
engine.
You
can
see
that
my
storage
driver
is
the
victor
iver
and
a
number
of
other
things
right.
You
can
see
this
VCH
CPU
limit
VCH
memory
limit.
These
are
tied
to
the
resource
pool
numbers
that
I
shown
you
before.
B
So
what
we're
going
to
do
to
show
you
how
this
works
is
that
I'm
actually
going
to
run
a
little
script,
that
I
created
I'm
just
going
to
kick
it
off,
because
it
takes
a
few
seconds
to
complete
in
this
environment,
because
this
is
running
nested
ESX
somewhere
in
a
in
a
lab
in
California,
so
I'm
just
going
to
kick
off
the
script
and
then
I'm
going
to
quickly
show
you
what
the
script
does
and
then
we're
going
to
go.
See
how
this
translates
into
my
eye.
B
My
vSphere
environment,
so
this
is
a
simple
script
I
created,
and
it's
just
to
show
that
you
know
you
can
easily
build
some
simple
orchestration
around
your
containers.
So
what
I'm
doing
here
is
I'm
actually
pulling
an
HTTP
D
image
from
public
docker
hub
so
again,
here
I'm,
demonstrating
that
you
can
run
regular
docker
images
against
this
I'm
just
pulling
httpd
from
docker
hub
I'm,
telling
the
script
run.
Three
instances
of
httpd
exposed
port
80,
so
I
want
port.
B
You
know
I'm
just
setting
some
prefixed
names
for
my
containers
as
they
come
up
a
prefix
name
for
my
little
balance,
sir
and
I'm
also
telling
it
what
external
network
I
want
to
use
in
this
case,
I'm
using
something
that
you
can
only
do
in
these
four
integrated
containers,
I'm
going
to
talk
a
little
bit
more
about
it
once
this
is
up
so
very
simple.
You
know
I'm
just
creating
a
basic
load.
B
Balancer
configuration
from
the
parameters
that
the
user
provided
I'm
pulling
my
httpd
image
from
docker
hub
I'm,
pulling
the
H
a
proxy,
which
is
an
open
source
proxy.
You
can
get
from
docker
hub
as
well
I'm,
creating
the
regular
dr.
Network.
So,
as
you
can
see,
I'm
running
normal
docker
commands
here
so
I'm
just
creating
a
a
what's
called
a
user-defined
bridge
Network
and
this
user-defined
bridge
network.
The
cool
thing
about
it
is
that
it
has
built-in
name
resolution
so
remember.
B
I'm
copying
it
in
look
at
the
lobe
answer
container
and
finally
I'm
starting
that
container
and
then
once
the
script
has
finished,
executing
it's
going
to
give
me
what
I
P
my
service
is
available
at
so
again.
You
know
a
very
simple
example
of
how
you
can
build
orchestration
on
top
of
on
top
of
a
deployment
like
this,
and
it
kind
of
illustrates
as
well.
B
Why
this
is
so
powerful
and
why
developers
might
want
to
use
it
as
a
side
now
this
script,
as
well
as
a
few
others,
are
available
in
the
Vic
product
github
page
there's
a
folder
in
there
called
tutorials
that
has
this
script
as
well
as
a
few
others.
So,
let's
go
back
to
here
see
if
it's
completed
yeah,
so
the
script
completed
you
can
see.
Service
is
available
at
192,
168,
101
33.
So
let's
just
make
sure
that
it
worked.
So
that's
been
doing
here.
B
B
Even
though
this
is,
you
know,
technically
an
internal
docker
Network
here
the
way
we
provision,
everything
is
a
first-class
citizen
in
your
vSphere
environment,
every
container
is
a
VM
and
then
every
container
is
connected
to
a
real
vSphere
network.
So
you
can
get
full
visibility
here
for
those
who
are
quite
a
keen
eye,
you'll
see
that
I'm
using
an
nsx
logical,
switch
to
back
this
bridge
network.
Again.
This
is
something
that's
supported,
but
not
a
requirement.
You
can
do
this
with
a
regular
distributed
port
group
on
the
cluster.
B
We
can
see
that
this
also
is
connected
to
a
data
store.
I
can
monitor
this
the
same
way
that
I
monitor
any
VM,
so
I
can
see
what's
going
on
from
a
performance
standpoint
in
each
of
these
individual
web
containers,
so
you
can
see
a
little
spike
here
as
it
came
up
and
the
other
thing
I
wanted
to
show.
You
is
that
we
also
have
some
basic
information
in
the
portlet
here.
You
can
see
the
name
of
the
container
that's
running
and
also
the
the
image
that's
running
inside
of
it.
B
So
this
is
an
HTTP
d
image.
The
other
thing
I
want
to
draw
attention
to.
Is
this
ID
here
this
weird
EXA
decimal
number
here,
that's
the
unique
docker
ID,
that's
provided
by
docker.
So
this
is
the
thing
that
allows
you
to
do
easy
correlation
from
the
view
you
get
here
in
in
vSphere.
So
you
see
this
docker
ID
3
III.
If
I
go
here
and
I,
do
a
docker
PS
to
see
my
running
containers
I'm
gonna
be
able
to
find
this
3d
3
very
easily
here.
B
So
I
can
easily
correlate
the
view
I
get
from
vSphere,
with
the
view
that
my
end
user
gets
using
docker
so
again
doc.
Her
native
experience
for
your
end
users.
They
don't
need
to
know
that
this
is
running
on
vSphere
they're,
running
regular
docker
commands
and
they're
getting
regular
docker
instances
getting
run,
but
from
the
vSphere
standpoint
that
gives
this
gives
you
a
lot
more
flexibility,
so
I'm
not
changing
the
workflow.
B
We
talked
about
a
little
bit
that
workflow
and
and
how
the
life
cycle
workflow
is
is
really
is
one
of
the
reasons
why
docker
has
gained
so
much
adoption.
So
we're
not
touching
that
we're
leaving
that
as
is,
but
we're
enabling
it
in
a
way
that
for
the
vSphere
administrators
you're
getting
a
lot
more
security,
because
every
one
of
these
containers
now
is
isolated,
leveraging
that
VM
as
a
security
boundary
and
from
a
resource
management
standpoint.
You
can
see
that
this
web
one
is
on
ESX
3.
This
web
2
is
on
yes
x1.
B
This
web
3
is
on
yes,
x2,
so
on
and
so
forth,
so
we're
using
DRS
to
make
an
intelligent
placement
decision
when
these
container
VMs
come
up-
and
you
know,
depending
on
the
level
of
automation,
that
the
RS
is
configured
with,
these
will
get
rebalanced
over
time
as
well.
So
all
the
container
VMs
that
I
created
using
this
container
host
get
grouped
under
this
resource
pool
and
we're
going
to
go.
Look
at
this
load
balancer,
because
this
one's
a
little
bit
different.
B
This
one
should
be
connected
to
two
networks,
so
you
can
see
that
I
have
this
connected
to
the
bridge
network
and
one
of
the
side-effects
of
running
containers
as
VMs
and
connecting
them
directly
to
port
groups
is
that
I
can
now
connect
the
container
directly
to
a
routable
port
group.
So
that's
what
I'm
doing
here,
I'm
using
this
vm
port
group
that
I
use
for
all
of
my
VMS.
This
is
a
port
group.
That's
running
DHCP!
It's
on
routable
network!
That's
my
192!
168
Network!
B
You
see
the
IP
that
it
got
here.
It
also
received
an
IP.
Remember
this
the
end
user
defined
bridge
network
that
I
told
you
about
well.
This
is
this
172
dot
17
network.
All
these
other
ones
are
connected
on
only
to
the
172
17
network
right,
so
they're,
all
connected
to
this
back-end
network.
That's
mimicking
the
docker
bridge
and
then
this
little
balancer
is
the
only
one:
that's
dual
homed
and
exposing
the
service
to
the
outside
world,
so
I'm
using
this
external
IP
to
expose
the
service
to
the
outside
world.
B
So
this
is
an
interesting
side
effect
because
now
I
can
run
container
with
you
know,
enabling
things
like
unique,
IP
per
container
without
having
to
resort
to
an
overlay
or
anything
like
that,
because
I
can
connect
these
containers
directly
to
a
routable
port
group,
so
that's
kind
of
an
interesting
side
effect
of
running
running
containers
as
VMs.
The
other
thing
we
have
in
here
is
the
the
integration
with
the
client.
This
is
again
something
that
you
get
with
the
OVA
installer
the
official
deployment
install.
B
But
this
is
another
view
you
get
where
you
can
manage
your
container
hosts
directly
from
the
from
the
vSphere
UI.
You
can
create
a
new
container
host
as
well
I
told
you.
You
have
the
the
option
of
using
that
Vic
machine
command
line.
That
I
showed
you
briefly,
but
a
much
easier
way
to
get
started
is
to
use
this
wizard.
That's
gonna
walk
you
through
every
step
of
how
to
create
your
container
host
and
provide
you
with
hints
along
the
way,
for
you
know
what
we
expect
at
each
step
of
this.
B
You
know
how
to
map
your
vSphere
resources,
and
then
we
pull
the
resources
directly
from
your
inventory.
So
you
can
easily
point-and-click
giving
you
that
same
type
of
experience
that
you
have
when
you're
creating
VMs
inside
of
here.
So
again,
if
you're
getting
started,
probably
recommend
that
you
start
with
this,
because
this
kind
of
explains
what
each
of
these
parameters
mean
and
you
can
make
the
right
decisions
as
you're,
creating
your
container
host,
because
the
process
of
creating
the
container
host
is
where
you're
mapping
your
vSphere
resources
for
consumption
through
the
docker
API.
B
So
you
need
to
make
the
right
decisions
to
a
need,
your
operational
requirements
and
be
meet
the
application
requirements
as
well.
The
other
view
I
have
from
here
is
I
have
a
view
of
all
the
containers.
Vms
that
are
running
you
know.
I
can
filter
them
by
image
type
and
then
from
here
I
can
look
and
be
taken
directly
to
that.
B
A
B
B
Not
not
on
VM
see
today,
and
the
reason
is
that
VM
C
is
a
managed
service.
So,
as
a
VM
C
customer,
you
only
get
you
don't
get
admin
access
to
recenter
right
and
when
you're
creating
your
container
hosts.
Here
you
need
to
have
admin
access
to
be
Center,
to
create
the
container
start
to
run
them,
but
to
create
them.
B
You
could
probably
manage
to
do
it
by
not
not
even
now,
I,
don't
think
you
can
do
it
on
VM
see
today
it's
something
we
do
have
on
the
roadmap,
though
you
know
we
tested
this
on
on
vCloud
air.
You
know
before
it
moved
to
OVH,
but
this
should
work
on
every
on
any
regular
cloud
provider
where
they
give
you
sort
of
full
access
to
the
V
Center.
It
should
work
no
problem,
but
for
the
vm
c
model.
B
There's
things
on
the
engineering
side
that
we
need
to
figure
out
in
terms
of
giving
the
Vic
machine
create
process
just
the
right
level
of
permissions
to
allow
it
to
run
it
against
or
to
allow
the
end
user
to
run
it
against
a
vm
c
managed
v
center.
So
that's
a
limitation.
We
have
today,
but
it's
something
that
we're
considering
on
the
world
map.
A
B
B
B
The
quran
is
supported,
but
on
docker
build
and
not
got
pushed.
For
example.
This
plays
really
well
in
CI
automation,
because
no
longer
do
you
need
to
maintain
these
long
running
virtual
cat
that
these
long
running
container
hosts
just
for
the
purposes
of
building
the
image.
Now,
because
this
is
provisioned
as
a
container,
it's
ephemeral
like
a
container,
so
I
can
bring
it
out
just
as
part
of
my
own
pipeline
for
the
time
of
building
the
image
and
destroying
it.
B
After
so,
it
promotes
two
things:
it
promotes
a
effective
or
efficient
resource
utilization
in
your
vSphere
clusters
and
B.
It
provides
it
avoids
the
snowflakes.
A
lot
of
the
Linux
container
hose
that
we're
seeing
within
our
accounts
are
becoming
quickly
snowflakes,
because
you
know
admins
typically
have
to
give
shell
access
the
developers
to
the
Container
host,
and
then
you
know,
configuring
careered
configuration
drips
happens
and
they
just
every
container
host,
is
basically
a
snowflake
in
this
model
we
can
provision
in
it
ephemerally.
B
B
It
turned
out
that,
because
we're
doing
containers
as
VMs
doing
container
in
Vic
docker
in
Vic
was
a
lot
simpler,
so
we
included
it
as
part
of
the
product
to
to
address
that
use
case
where
customers
need
to
build
the
container
images
themselves
and
again.
This
is
something
that's
well
documented
in
our
in
our
github.
A
B
Alright,
so
we
touched
on
a
lot
of
these
and
the
fact
that
we
provision
containers
as
VMs
allows
us
to
get
all
the
benefits
of
the
underlying
vSphere
infrastructure
in
terms
of
resource
management,
security,
visibility,
monitoring,
you
can
leverage
the
all
of
your
existing
tools
yeah.
So,
if
you're
interested
to
learn
more,
we
have
the
official
VMware
page.
We
also
have
a
hands-on
lab.
If
you
don't
know
the
hands-on
labs
there,
they're
completely
free
to
use,
you
just
need
to
sign
up
and
they're
real
live
environments.
B
Actually
it
should
be
nineteen,
thirty
and
not
eighteen
thirty,
because
we
refreshed
it
just
for
a
vmworld
a
few
weeks
back
and
then
again
the
links
to
all
of
the
various
github
pages
where
you
can
visit
us.
If
you
want
to
contribute,
you
know
we're
always
looking
for
contributions
in
terms
of
you
know,
improving
the
documentation
anything
like
that
is
welcome.
So
with
that
I
think
that's
all
I
had
and
we're
right
on
time.
Yeah.
A
A
If
you
haven't
already
registered
there
head
over
to
code,
VMware,
comm
and
I
put
that
in
the
chat
head
over
there
register
and
then
you
will
get
a
link,
so
you
can
get
added
into
the
VMware
code
slack
and
we
have
a
channel
they're
called
Vic
engine.
So
please
join
us
there
and
for
more
conversations
and
Patrick.
If
I
wanted
to
reach
out
to
you
on
Twitter
or
somewhere
else.
Where
could
I
find
you.
B
So
on
Twitter
I'm,
PD,
AIG
le,
so
that's
my
my
first
letter
of
my
first
name
and
my
last
name
and
then
I'm
also
I
also
monitor
the
EMR
code
slack,
as
can
be
seen
here.
It's
part
of
the
multiple
slack
that
I
that
I
monitor,
but
I
am
on
this
VMware
code
slack
as
well
as
some
of
the
victim
Alpers
are
on
here
as
well.
Some
of
the
GSS
folks,
that's
our
support.
People
at
vmware
are
on
here,
so
it's
a
great
first
place
to
get
help
and
interact
with
other
users.
B
A
Well,
I
want
to
thank
you
Patrick
so
much
and
for
this
presentation,
I
hope
everyone
here
has
had
a
a
lot
of
fun.
Listening
to
Patrick,
explained
Vic
in
the
Vic
engine
and
how
it
works.
I
want
to
thank
everyone.
That's
been
on
the
call
today
on
the
webinar
here,
so
thank
you
so
much
and
we
do
have
more
webinars
coming
up
next
week.
A
We
do
have
a
CNC
F
webinar
for
harbor,
so
please
head
over
to
to
CS
at
I/o
and
register
for
that,
and
we
do
have
another
webinar
coming
up
next
week
as
well,
for
these
fair
CPI,
the
cloud
provider
interface.
So
please
join
us
there.
The
recording
of
this
will
be
available
most
likely
later
this
afternoon
or
early
tomorrow
morning,
up
on
the
VMware
cloud
native
apps
YouTube
channel.
So
please
yeah
take
a
look
over
there
with
that.
Thank
you
so
much
and
we
hope
you
have
a
great
rest
of
your
week.
Bye
thanks.