►
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
Extending containerd - Samuel Karp & Maksym Pavlenko, Amazon
containerd, a graduated CNCF project, is a widely used container runtime that provides core functionality for Docker. containerd was designed to be small and simple, but also very modular and extensible. This talk covers the architecture of containerd, explains the responsibilities of each component, and dives deep into containerd’s facility for extension. We’ll cover the individual gRPC services that make up containerd and show how they can be extended with proxy plugins, Go plugins, process interfaces (OCI runtimes and process-based logging), thick client implementations, and build-your-own containerd for compiled-in extension. These extension mechanisms can be shown with simple examples and real-world use in the firecracker-containerd project.
https://sched.co/UaYP
A
A
Sam
and
Max.
Both
work
on
containers
at
AWS,
helping
build
core
components
behind
AWS,
Fargate,
Amazon,
eks
and
Amazon
ECS
Sam
has
been
a
docker
and
mobi
contributor
since
2015,
and
a
container
D
contributor,
since
2017
max
is
a
container
D
maintainer
and
both
max
and
Sam
currently
help
build
fire
cracker
container
D
to
rent
containers
with
hypervisor
provided
isolation.
So
without
further
ado,
Sam
and
Max
with
extending
container
D.
B
Cool,
so
thanks
for
that
introduction,
I
guess
I
don't
have
to
really
introduce
myself
anymore,
but
we're
really
happy
to
be
here
today
to
talk
about
extending
container
D.
So
we
can
start
with
just
a
brief
overview
of
what
we're
going
to
talk
about
today.
First
thing:
I'm
gonna,
just
a
brief
introduction
of
what
container
D
is
talk
a
little
bit
about
its
architecture
and
the
modularity
of
that
architecture.
We'll
move
on
to
some
of
the
extension
techniques
and
then
we'll
have
some
examples.
B
So,
first
we're
gonna
talk
about
container
D.
I
hope
that
if
you're
at
this
talk
you're
at
least
somewhat
familiar
with
containers
and
maybe
you've
heard
of
container
D
or
maybe
you've
used
it
or
some
of
the
people
here,
work
on
container
D,
which
is
also
really
cool.
So
just
for
anyone
who's
not
super
familiar.
It's
a
really
small
and
focused
container
runtime.
It
has
a
really
limited
scope.
B
So
it's
a
container
runtime
that
was
built
by
many
of
the
same
folks.
Who've
worked
on
docker
with
a
lot
of
the
lessons
learned
from
things
that
worked
really
well
in
docker
and
things
that
were
a
little
bit
more
challenging
in
docker.
So
it
has
a
bit
of
a
different
focus.
It's
really
just
focused
on
running
containers
and
not
any
of
the
higher-level
things
that
docker
does
things
like
overlay,
networking
or
built
in
logging
features
or
clustered
storage
or
all
out
of
scope
for
container
D.
B
So
it's
really
just
focused
on
the
core
problem
of
running
and
managing
containers,
and
it's
built
out
of
these
modular
composable
pieces
that
can
be
extended
and
that's
the
the
main
thing
that
we
really
want
to
talk
about
today.
So
I
can
give
you
a
little
bit
of
an
overview
of
what
the
architecture
looks
like
it's
a
bunch
of
independent
pieces
that
are
meant
to
work
well
together.
The
primary
way
that
you
interact
with
container
D
is
through
the
G
RPC
API,
or
an
adapter
like
a
thick
client
library,
that's
provided
by
container
D.
B
Typically,
the
users
of
container
D
are
not
someone
interacting
on
the
command
line,
but
are
rather
a
higher-level
application
like
a
container
Orchestrator.
That's
meant
to
integrate
with
container
D,
so
this
diagram
shows
some
of
the
components
and
we're
going
to
take
a
look
at
a
couple
of
them.
The
first
donut
that
I
want
to
highlight
is
container
DS
contents
store.
This
is
used
for
storing
the
raw
content
of
images.
B
So
what
I
want
to
talk
a
little
bit
about
just
what
are
layers,
because
this
is
a
little
bit
interesting
and
relevant
in
container
images,
you
usually
have
some
sort
of
concept
of
a
union
filesystem
that
composes
different
layers
together.
I've
got
a
diagram
here
that
tries
to
show
this
a
little
bit,
so
you
can
see
that
there's
three
layers
in
the
bottom,
the
one
that's
labeled
the
base
layer-
is
a
read-only
layer
and
has
a
few
files
in
it.
B
The
way
that
layered
file
systems
work
is
that
the
files
stay
in
the
layer
that
they're
originally
written
in
so
something
that
was
in
that
base
layer
doesn't
have
to
be
duplicated
in
the
other
ones.
This
lets
you
enable
things
like
sharing
layers
between
different
images
and
lets.
You
have
a
really
fast,
cheap,
startup
time,
because
you
put
an
empty
writable
layer
on
the
without
having
to
copy
all
of
the
content.
So
why
am
I
talking
about
this?
B
The
contents
store
that
we
talked
about
stores
layers
in
a
compressed
format
and
doesn't
actually
implement
this
copy-on-write
or
the
union
of
the
file
system.
So
that's
implemented
by
the
next
part
of
the
container
D
stack,
which
is
the
snapshot
or
layers
from
the
content,
store
unpacked
into
a
some
sort
of
file
system
in
the
snapshot.
Er
and
the
snapshot
is
typically
implementing
copy-on-write
functionality,
so
you
don't
have
to
duplicate
all
of
the
contents.
B
If
you
used
docker
before
you've
seen
this
in
Dockers
storage
or
graph
drivers,
the
snapshot
is
in
container
d
are
similar,
but
they
have
a
little
bit
of
different
implementation
choices.
Just
like
docker.
There
can
be
multiple
different
implementations
of
snapchatters
and
the
different
implementations
can
do
whatever
they
want,
as
long
as
they
produce
at
the
end
of
the
day,
something
that
looks
like
a
union
of
the
file
system
together
and
you
have
different
implementations
that
can
offer
different
trade-offs
and
things
like
speed
or
efficiency.
B
The
next
thing
I
want
to
look
at
is
when
you
want
to
actually
run
containers.
You
use
a
runtime
container
d
will
dispatch
to
some
lower
level,
runtime
implementation
that
goes
and
implements
the
the
parts
of
containers
that
we're
all
familiar
with
things
in
Linux,
like
C
groups
and
namespaces
seccomp
capabilities
in
container
D.
By
default
there,
it
uses
the
reference
implementation
of
the
OCI
standard,
which
is
called
run
C,
and
that
does
normal
Linux
containers
through
all
of
those
Linux
technologies.
B
But
you
could
plug
in
something
different
and
maybe
something
that
wasn't
even
containers
you
could
have.
It
run
anything
that
fits
either.
The
OCI
standard
that
container
D,
supports
or
container
D
also
has
a
version
to
a
slightly
different
way
of
interacting
with
runtimes.
But
it's
built
to
let
you
run
something
different
than
run
C.
If
you
want
the
GRP
C
API
is
the
central
interaction
point
for
container
D.
It
mediates
interaction
with
each
of
the
parts
of
container
D.
B
So
what
is
container
DS
overall
architecture?
It's
a
modular
core
built
of
small,
separate
services
that
are
designed
for
extensibility
and
to
make
it
functional.
You
can
use
those
services
together.
You
have
interactions
that
are
modeled
as
interfaces
through
the
ERP
C
API
and
plug-in
mechanisms
that
make
it
easy
to
replace
different
implementations.
B
When
you
want
something
different
and
there's
a
client
library
that
hides
that
complexity
from
you
and
ties
it
all
together,
so
now
that
we
know
a
little
bit
about
how
container
D
works,
we
can
move
on
to
some
of
the
extension
points
where
you
can
customize
it.
There's
five
basic
extension
points
for
container
D.
B
The
first
one
is
the
thick
client
library
that
I
talked
about
a
little
bit
before
in
go
that
models
interactions
as
in
ergo
interfaces,
and
so
it
has
the
ability
to
let
you
swap
some
of
the
implementations
of
those
interfaces
for
different
things.
When
you
want
to
change
the
way
that
the
client
is
working,
the
next
is
what
I
call
CLI
or
executable
plugins,
which
are
programs
that
container
DX
Acutes
for
you
and
you
can
tell
it
to
run
a
different
program
instead
of
the
one
that
it's
going
to
run
by
default.
B
The
third
is
g
RPC
proxy
plugins,
where
you
can
implement
the
entire
interface
of
one
of
the
container
DS
services
in
a
separate
program
and
have
container
D
call
into
that
program.
For
you,
the
next
one
is
dynamically
linked
go
plugins.
These
are
dynamically
linked.
Libraries
shared
object
files
that
you
can
compile
with
go
and
load
into
container
D
and
have
it
do
different
things
and
the
last
one.
If
you
need
something
that
is
the
most
powerful,
you
can
run
built-in
plugins,
where
you've
compiled
your
own,
build
of
container
D
and
changed
its
functionality.
B
That
way,
so,
let's
go
a
little
bit
into
depth
for
these
techniques
and
the
first
one
that
we're
gonna
talk
about
is
the
client
library,
so
container.
D
is
built
for
programmatic
interactions
and
models.
A
lot
of
its
functionality
in
this
thick
client
library
written
in
go
the
client
library
orchestrates
calls
across
container
DS
GRP
C
API,
but
also
implements
portions
of
common
workflows
like
pulling
images.
These
common
workflows
are
modeled
with
interfaces,
and
you
can
use
your
own
implementation
when
you
want
behavior
that
is
different
from
the
standard
behavior.
B
That
container
D
has
some
of
the
downsides
of
this,
or
that
you
do
actually
need
to
control
the
calling
code
for
it.
So,
if
you're
writing
your
own
integration
with
container
D,
it's
really
easy
to
extend
the
client
library
and
do
something
different.
But
if
you're
using
a
an
integration
that
someone
else
is
already
written,
you're
not
going
to
be
able
to
customize
it
that
way.
B
So,
let's
dig
into
the
pull
workflow
in
community,
the
actual
network
transfer
of
images
happens
inside
the
client
library,
not
in
the
container
D
daemon
itself.
This
is
really
unlike
docker,
so
in
docker
there's
a
single
API
call
for
pull
and
it
handles
all
of
the
networking
in
container
D.
It's
decomposed
into
a
bunch
of
different
steps
and
the
client
library
handles
orchestrating
those
steps
for
you.
So
there's
a
default
implementation
that
can
handle
talking
to
a
docker
registry,
but
it's
really
easy
to
customize.
B
If
you
need
something,
that's
different,
for
example,
if
you
want
to
use
docker
style
image
names,
but
reference
a
different
network
endpoint
or
if
you
want
to
customize
encryption
settings
or
timeouts,
it's
really
easy
to
do
that
from
the
client
library
or
if
you
want
something
completely
different
like
a
different
transfer
protocol,
say
something
like
BitTorrent.
You
could
do
that
as
well.
B
We
ended
up
writing
an
implementation
for
Amazon
ECR,
the
container
registry
that
AWS
offers
that
uses
the
the
ECR
api
directly
instead
of
docker
api
and
I'll,
show
you
a
little
bit
about
how
how
we
were
able
to
do
that.
So
this
is
the
default
interaction
to
pulling
in
to
pull
an
image
using
the
client
library,
and
this
uses
the
default
resolver,
which
is
the
thing
that
knows
how
to
talk
to
the
docker
registry.
B
You
can
see
here
that
there's
it's
fairly
simple:
it's
just
calling
a
pull
function
and
passing
the
image
and
a
couple
of
options
that
go
along
with
it
so
use
a
different
resolver
like
the
one
that
we
wrote
for
ECR.
Your
call
looks
very
similar.
The
only
differences
here
are
that
you
construct
the
resolver
object
that
you
want
to
use,
and
then
you
pass
that
resolver
object
to
the
pull
function
and
the
poll
function
will
know
how
to
use
the
capabilities
that
the
resolver
provides.
B
Some
resolvers
are
going
to
require
maybe
a
different
image,
name
format,
and
so
you
may
to
change
that
as
well.
So
what
does
it
look
like
to
go
and
build
a
resolver?
This
is
the
resolver
interface,
which
is
a
the
basic
thing
that
needs
to
be
implemented,
and
it
has
three
methods,
so
the
first
one
is
called
resolve
and
that
returns
two
things
that
are
useful
and
interesting.
The
first
is
a
canonicalized
identifier
for
the
image
and
that's
in
the
docker
implementation.
B
The
thing
that
will
turn
a
name
of
an
image
that
includes
a
tag
into
something
that
is
identified
by
a
digest.
It
also
returns
a
descriptor
object
that
community
uses
in
subsequent
calls,
there's
two
more
functions
here
and
they
look
really
similar
to
each
other.
There's
a
fetcher
and
a
pusher,
and
these
both
return
objects
that
know
how
to
get
content
or
how
to
push
object
to
a
remote.
If
you
only
really
care
about
retrieving
things,
you
can
implement
a
resolver
with
just
the
fetcher.
B
You
don't
have
to
implement
the
pusher,
but
if
you
want
to
put
push
and
pull
images,
you
need
to
implement
all
of
these
parts.
So
let's
look
a
little
bit
at
the
fetcher
interface.
This
has
one
method
that
takes
a
descriptor
and
returns
a
reader
for
stream
of
data,
and
the
client
can
call
this
and
then
have
access
to
whatever
it's
trying
to
retrieve.
So
the
descriptor
is
what
specifies
the
actual
object.
B
That's
trying
to
be
retrieved
and
images
consist
of
a
bunch
of
different
objects,
things
like
an
index
and
a
manifests,
some
config
and
all
of
the
actual
layer
contents,
and
this
fetch
method
will
get
called
once
for
each
of
those
objects
that
needs
to
be
retrieved.
Some
of
the
calls
are
going
to
involve
so
the,
for
example.
B
If
you're
calling
fetch
for
the
index,
the
next
call
you're
going
to
use
the
day
that
you
retrieved
from
the
index
to
call
and
get
the
manifest,
and
then
the
next
call
is
going
to
use
the
data
that
you
saved
from
the
manifest
to
go
and
actually
get
the
layers.
This
means
that
the
same
fetch
method
is
used
for
all
of
the
different
objects
that
make
up
an
image.
The
reader.
That's
returned
actually
hides
the
implementation
of
the
network
activity
from
the
client.
B
So
it's
a
responsibility
of
the
fetcher
to
do
whatever
it
wants
to
do.
In
the
ECR
resolver
that
we
wrote,
we
have
a
fetcher
that
can
make
multiple
parallel
requests
for
different
content
ranges
in
the
same
layer.
That
gets
us
a
lot
faster
downloads
than
the
default.
If
you
wanted
your
custom
implementation
to
be
able
to
push
push
images,
you
also
need
to
implement
the
pusher,
and
this
is
looks
a
lot
like
the
fetcher.
They
mean
differ.
B
Here's
that
it
returns
a
writer
where
you
write
content
instead
of
a
reader
where
you're
reading
content-
and
you
don't
always
have
to
use
the
same
writer
or
return.
The
same
writer
object
out
of
this
in
the
ECR
implementation,
for
example,
we
return
different
writers
for
different
kinds
of
content,
so
we
have
a
separate
writer
for
manifest
as
opposed
to
the
layer
contents.
C
Hey
everyone,
so
Sam
talked
about
client-side
extensibility.
Let's
discuss
server-side
continued
dick,
has
notion
of
executable
plugins
and
uses
them
in
a
lot
of
places
to
extend
its
functionality.
Essentially,
it's
a
separate
binary
invoked
by
continuity
at
some
point
that
conforms
to
certain
conventions
and
depending
on
plug-in
type
conventions,
might
be
different.
Let's
see
how
it
works.
C
First
example
of
such
plugin
is
runtime
continually
delegate
the
control
of
containers
to
an
external
binaries
and
communicates
with
them
through
a
DC
channel
runtime
candles
all
implementation
details
how
to
run
your
containers
in
continued
either
is
run
GB
to
run
time
that
is
used
by
default
and
it
uses
Linux
kernel,
primitive
store
on
containers
like
namespaces
in
C
groups
and
others,
but
it
can
be
literally
anything,
for
instance,
in
a
gradual
continuity
project.
We
have
built
our
custom
runtime
and
it
managed
by
a
cracker
micro
VM
instance
SC.
C
C
C
It
is
expected
that
you're
on
time
start
the
service
in
background
and
returns.
It's
addressing
STD
out
back
to
continuity,
it's
up
to
run
time,
whether
it
runs
a
new
background
service
for
each
container
or
it
just
really
uses
existing
instance.
Similarly,
to
start
continuity,
we'll
call
a
binary
with
deleted
argument
so
run
time.
Implementations
have
a
chance
to
clean
up
resources,
so
every
run
time
must
implement
a
service
interface
over
the
domain
socket.
This
is
how
continued
he
controls
container
instances.
C
Here's
how
the
service
interface
looks
like
there
are
lot
of
green
one
here,
but
most
of
this
correspond
to
a
process.
Lifecycle
so,
for
instance,
create
creates
a
new
process
and
the
container
there
is
a
fire
root.
The
first
fire
container
how
to
handle
STD
out
a
bunch
of
other
options.
Similarly
start
actually
starts
a
process
way
to
a
way
to
wait
for
the
one
to
finish
and
so
on.
C
C
C
C
Another
extensibility
point
is
proxy
plugins.
They
are
similar
to
runtime
plugins.
It's
a
separate
process
that
implements
one
of
proxy
interfaces.
The
only
difference
is
that
now
you
are
responsible
for
a
process
lifecycle.
That
means
that
continuity
doesn't
invoke
binary
for
you
and
there
are
no
started
delete
arguments.
Instead,
you
have
to
configure
continuity
in
advance
and
tell
what
kind
of
proxy
plugin
are
you
going
to
run
and
how
to
communicate
with
it?
C
C
There
are
two
types
of
proxies
plugins
supported
today.
It's
a
sneak,
shorter
and
content
store.
This
talk
will
focus
on
controllers,
so
sneak
furthers
our
mechanism
for
providing
file
system
to
containers
the
implement
layer
unions,
as
I
mentioned
previously,
so
difference
in
each
other's
implement
different
strategies
how
to
deal
with
layers
so
for
instant.
There
is
no
overlaid
controller
that
witch
cookies
entire
file
on
each
right
and
there
is
a
bit
of
a
that
does
more
lightweight
block
level
cookies.
There
are
also
offerings
of
block
device
based
or
others
like
device,
mapper
and
LBM.
C
C
Let's
have
a
brief
look
how
it
would
fight
these
are
used
to
control
filesystem
layers
to
be
used
by
container.
There
are
two
major
function
that
worth
to
highlight
so,
for
instance,
when
continually
pulling
an
image
continued
equals
prepare
to
create
a
new
layer,
prepare
return,
small
structures
that
can
be
used
to
mount
snapshot
for
capturing
changes.
After
that
container
G
will
unpack
their
data
from
content
store
into
the
snapshot
and
then
continue
Tico's
commit
to
seal
the
snapshot.
C
C
Another
extensibility
point
is
go
plugins
in
Faragher
contenido
project.
We
have
built
a
Jerry
PC
API
extension
for
contain
a
team
that
would
allow
clients
to
manage
micro,
VM
instances,
and
our
original
intention
was
to
implement
it
as
go
plugin.
But
it
turns
out
that
there
are
a
lot
of
compatibility
change
challenges
with
go
plugins
today.
So,
for
instance,
our
compiler
version
that
is
used
to
build
continuity
and
your
plugin
should
strictly
match,
including
major
minor
and
page
numbers
dependencies
outside
like
standard
libraries
that
are
used
by
both
continuity
and
extension
should
also
strictly
major.
C
So
instead
we
ended
up
with
routine
approach
for
our
extension,
the
majority
of
contenido
modules
are
built
in
plugins,
around
30,
embedded
plugins
in
1.3
release
of
contain
a
deer.
This
includes
default
implementation
of
runtime
law
like
currency,
be
to
bunch
of
intruders
and
various
components
for
orchestrating
runtimes.
New
coders
and
training
containers
every
component
can
be
extended
to
replace
or
deleted,
but
the
downside
is
that
this
cannot
be
changed
at
runtime
and
you
have
to
rebuild
a
continuity
binary.
C
You
don't
have
to
for
continue
to
build
your
built-in
extension.
Essentially,
you
build
your
own
program.
Import
existing
pieces
from
continuity.
Add
your
extension
and
just
have
your
compost
needed
functionality
so
how
to
build
your
own
continuity
distribution.
Essentially,
you
have
to
write
your
own
main
function
and
register
needed
plugins.
C
Here's.
How
main
would
look
like
you
define
minimal
and
she
went
to
spin
a
plug-in
engine
and
run
several
listeners
of
continuity.
Next,
within
same
main
that
go
file.
Your
register
plugins
by
important
CMS
go
packages
not
likely.
You
would
want
to
reuse
existing
functionality
of
continuity,
so
you
import
go
packages
provided
by
contingency
first,
and
this
can
be
pretty
long
list
and
after
that,
you
import
your
ears
one
in
order
to
make
it
work
like
that,
plug-in
must
register
yourself
in
a
neat
package
function
and
provide
all
details
about
your
plugin.
C
Here's
how
a
typical
registration
code
would
look
like
you
must
specify
the
type
of
your
plugin
and
identify
our
so
other
plugins
know
how
to
refer
to
it.
Optionally.
You
can
specify
a
list
of
dependencies.
It
needs
to
be
available
to
your
plugin
and
at
runtime
continue
to
build
in
it
a
fan
function
to
initialize
your
plugin
code
and
that's
basically
it
so.
B
That
are
already
hearing
yeah,
okay.
Hopefully
everyone
can
see
on
the
screen.
So
what
I
have
here
is
a
your
metal
ec2
instance.
That's
set
up
to
run
a
bunch
of
stuff
with
the
various
integration
points
that
we've
written
with
container
D.
So
this
is
some
programs
that
we've
written
that
do
all
the
stuff
that
we've
talked
about
so
first
thing
that
we're
gonna
do
I'm
just
going
to
show
you
a
little
bit
about
what's
installed
here.
B
So
we've
got
a
few
things
that
are
on
there.
I,
don't
think
it's
a
little
hard
to
read,
but
there's
first
thing
that
I
want
to
draw
your
attention
to.
Is
the
thing
called
firecracker
container
D?
This
is
our
own
custom,
build
of
container
D
with
a
plugin,
that's
built
into
it,
so
it
was
doing
the
process
that
max
was
just
talking
about
next
thing
that
we
can
look
at
is
there's
a
program
here
called
firecracker.
This
is
actually
the
Firecracker
virtual
machine
monitor
that
ABS
uses
to
run
virtual
machines.
B
B
B
So
let's
go
ahead
and
look
at
what
images
are
present
on
this
instance
that
I
have
set
up
and
we're
just
gonna
go
ahead
and
list
them
and
there's
nothing
there.
So
we
can
go
ahead
and
pull
something
first
and
we're
gonna
use
that
ECR
pull
program
that
we
wrote.
That's
gonna
pull
the
Amazon
Linux
image
from
ECR
and
it
can
go
ahead
and
pull
that
and
it
unpacked
it
into
the
device
mapper
snapshot
or
that
we're
using.
B
So
we
can
go
ahead
and
see
that
that
pulled
properly.
You
can
see
that
it's
there.
So,
even
though
we
didn't
use
the
CTR
command
line
to
pull
the
image,
we
were
able
to
pull
it
through
the
container
dapi
s
and
using
the
different
resolver
that
we
wrote.
So,
let's
see
what
it
looks
like
to
go
ahead
and
run.
Something
first
thing
is
it?
Can
you
hear?
Okay
first
thing:
we
can
look
at
what
this
instances
is
running
right
now.
So
this
is
a
well.
B
It
looks
like
it's
a
Debian
kernel
and
it's
got
a
host
name.
That
looks
like
an
ec2
instance
and
we
can
go
ahead
and
look
at
the
OS
release
file
and
this
just
is
a
normal
Debian
thing.
So
what
we'll
do
is
we'll
go
ahead
and
run
a
container
and
we'll
go.
Look
at
the
same
stuff
inside
the
container
that
we
were
looking
at
outside
and
we'll
see
what
looks
different
and
we're
just
gonna
call
this
container
demo.
B
That's
what
that's
on
there
for
so
we've
got
a
container
running
and
we
can
do
the
same
thing
that
we
were
doing
before.
We
can
look
at
the
kernel,
that's
running
and
you
can
see
it's
actually
a
different
kernel.
So
this
is
the
an
Amazon
Linux
kernel,
that's
running
inside
a
virtual
machine.
It's
got
a
host
name
that
was
set
to
just
a
micro
VM.
We
can
look
at
the
same.
Oh
s,
release
so.
B
And
you
can
see
that
this
is
an
amazon
linux
image.
This
is
actually
the
same
amazon
linux
image
that
you'd
be
able
to
run
with
docker,
and
so
that
this
OS
release
file
is
the
same
file
that
you
would
see
if
you're
running
things
with
normal
Linux
containers.
But
you
could
see
that
we're
actually
running
a
different
kernel
which
will
distinguish
it
from
running
just
a
regular
Linux
container.
B
Okay,
so
that
was
I
think
a
little
bit
interesting.
But
what
we
can
also
look
at
is
what
happens
on
the
host
when
you're
running
something
like
this.
So
we
can
go
ahead
and
run
another
container
and
we're
just
gonna.
Let
it
sleep
in
the
background
for
a
little
bit
and
we
can
examine
what
is
going
on
with
the
way
that
the
processes
are
set
up
on
the
host.
B
So
we've
got
a
container
and
we're
running
it,
and
what
we
can
look
at
is
what's
going
on
with
the
processes
that
are
involved,
so
we'll
look
at
the
firecracker
container
D
process
and
we're
just
gonna
look
at
the
processes
that
are
run
here
and
you
can
actually
see
a
little
bit.
That's
different
here
from
a
normal
container
is
instead
of
you
being
able
to
see
the
container
processes
that
are
running
like
you
can't
see
anything
here.
That's
called
sleep.
B
You
actually
just
see
this
firecracker
process
and
that's
the
virtual
machine
monitor
that's
running
and
all
of
the
things
that
are
happening
inside
the
VM
are
encapsulated
by
that,
and
so
that's
pretty
much
the
end
of
the
demo
that
I
have
here.
So
we
what
we
just
to
go
over,
what
we
saw
we
were
able
to
pull
an
image
from
EC
are
using
a
custom
resolver
that
we
wrote.
B
Then
we
were
launching
that
container
inside
a
VM
using
the
custom
firecracker
container
D
binary
with
this
control
plug-in
built-in
and
using
the
community
shim
nativist
firecracker
to
go
ahead
and
control
the
container
to
control
the
firecracker
process.
We
use
the
device
mapper
snapshot
or
that
we
wrote
and
we
were
able
to
contribute
upstream,
and
so
that
was
running
with
the
upstream
installed
version
of
the
device
mapper
driver
and
then
inside
the
VM.
It
uses
the
normal
container
D
shim
to
go
ahead
and
run
a
container
with
run
C.
B
B
D
D
B
B
So
in
the
way
that
we
think
about
this
is
it's
aimed
at
things
like
multi-tenancy
and
at
isolating
workloads
from
each
other
that
are
operating
in
different
security
contexts
you
can
see
so
firecracker
was
something
that
was
built
for
a
Tobias
lambda,
basically
and
for
use
cases
that
are
the
same
times
use
cases
for
Fargate.
So
this
is
software
that
we're
writing
to
help
make
that
available
for
other
people
that
want
to
run
that
as
well.
I.
E
B
B
Firecracker
container
T
does
not
work
with
kubernetes
today.
The
way
that
it
will
hopefully
work
eventually
is
through
the
CRI.
So
container
T
has
a
built-in
plug-in
called
CRI
container
T
that
implements
things
with
kubernetes.
There's
a
few
design
challenges
that
we're
still
facing
in
order
to
get
something
working
with
kubernetes
today,
but
if
you're
not
using
kubernetes
and
you're.
If
you're
entertaining
directly
with
container
d
you're
able
to
use
this
today,.
B
B
D
B
Like
so
for
me,
the
things
that
I
really
like
about
container
D
are
the
fact
that
it
is
a
bunch
of
separate
things
that
are
composable
and
interchangeable,
and
so
I
can
work
out
different
things
and
build
different
things
than
were
initially
envisioned
by
the
people
that
wrote
container
D,
and
so
it
led
us
build
this
whole
thing
with
firecracker
it.
Let
us
build
the
thing
where
we're
able
to
pull
things
from
ECR
versus
something
like
Dockers
a
little
bit
more
of
a
monolith.
B
B
All
the
firecracker
container
you
stuff
is
on
github.
If
you
go
to
github.com,
slash,
firecracker
micro,
VM,
all
of
the
firecracker
code
is
under
there,
so
the
main
firecracker
project
is
there
as
well
as
firecracker
container
deep
yeah.
Everything
that
was
shown
on
the
demo
is
open
source
and
that's
all
on
github.
The
ECR
thing
is
under
the
80s
labs
github
instead
of
the
firecracker
one,
because
it's
not
really
related
to
firecracker,
but
everything
that
we
showed
today
was
open
source.
B
So
I
think
that's
I,
think
we're
out
of
time.
At
this
point,
one
last
thing
before
we
finish
I
would
really
appreciate
it.
If
you
all
would
fill
out
the
survey,
that's
on
the
sched
website
or
the
Sketchup,
we
really
appreciate
feedback.
Hopefully
they're
gonna
actually
send
it
to
us.
Something
to
keep
in
mind
is
that
if,
as
you're
filling
these
out
that
everyone
who's
presenting
here
is
a
human
just
like
you,
so
hopefully
don't
be
like
to
mean
to
everyone.
B
If
you
didn't
get
a
chance
to
ask
a
question
here,
we're
the
hallway
tracks
open
we're
gonna
be
around
the
whole
week.
You
can
come
up
to
us
at
the
end
of
this
session
if
you
find
us
in
the
hallway
feel
free
to
come,
say
hi.
If
you
didn't
get
a
chance
to
actually
talk
to
us
in
person.
Our
email
address
and
Twitter
handles
are
up
there,
and
so
thank
you.