►
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
Open Source Weave Ignite - The GitOps VM - Mark Emeis, Weaveworks
Weave Ignite is a new open source tool that combines Firecracker microVMs with OCI images, containerd and CNI to unify containers and VMs. It integrates with Kubernetes and GitOps operators so it can be managed declaratively like Kubernetes itself and Terraform. Ignite is fast and secure because of Firecracker, AWS’ oss KVM implementation that is optimised for speed, low resource consumption, high security, and isolation. With Ignite, users can: *Launch and manage entire “app ready” stacks from Git *Run legacy or special apps in lightweight VMs (eg for multi-tenancy) *Run a cloud of VMs ‘anywhere’ using Kubernetes for orchestration, Ignite for virtualization, GitOps for management, and supporting cloud native tools and APIs. Ignite contributor Mark Emeis will share why Kubernetes SIG Lead and Weaveworks DX Engineer, Lucas Käldström, created Ignite, how it works, and how to get started.
https://sched.co/Uabk
A
Afternoon
everybody
so
we're
here
to
talk
about
we
big
night,
and
this
will
be
kind
of
a
general
introduction
to
what
we've
ignite
is
kind
of
the
motivations
behind.
Why
we
built
it,
how
we
use
it
and
give
you
guys
a
few
demos
of
us
using
it
so
hopefully
to
ignite
your
interest
in
ignite.
If
you
will
that's
a
pun,
I
I,
just
thought
of
that
anyways,
so
I'm
marki
mice,
just
a
little
bit
about
me
so
happily
married
I
tend
not
to
want
to
jump
right
in
on
all
technology
stuff.
A
So
I'll
give
you
a
little
background
on
me,
but
you
just
you
know
happily
married
for
29
years.
I
got
two
fantastic
children,
neither
of
which
became
software
engineers.
That's
surprise
beef,
but
I'm
gonna.
Have
it
runner,
biker
horror,
movie
viewer
I'm,
a
member
of
the
sig
cluster
lifecycle,
mostly
participating
in
meetings
around
cluster
API
I'm.
The
development
manager
at
weave
works
for
a
product
called
wkp,
which
is
the
weave
kubernetes
platform
previous
to
weave
works.
I
actually
was
the
founder
of
a
company
called
the
API.
Oh
and
GPIO.
A
B
A
A
We've
created
several
open
source
projects
that
you
guys
have
either
heard
of,
or
probably
used
or,
if
you're
new,
to
like
get
ops,
you're
learning
about
it
this
week,
but
we
kind
of
break
it
down
into
the
kubernetes
space
if
you're,
installing
kubernetes
and
you're,
using
ku-band
ADM
right.
That
is
something
that
we've
works
created
early
on
in
order
to
be
one
of
the
installers,
if
you're,
using
eks,
cuddle
or
eks
you're,
probably
using
eks
cuddle,
that's
another
we've
works
donation
or
our
open
source
project
that
we
have
way
back.
A
In
the
beginning
time
of
kubernetes
and
and
docker
containers,
there
was
something
called
weave
net,
which
was
the
original
software-defined,
networking
and
firewall
that
was
by
containers
and
then
we're
talking
about
we've
ignite
in
this
space
as
well
on
the
observability
front.
So
we
have
a
product
called
we've
cloud.
We
ingest
tons
of
metrics
that
are
Prometheus
metrics
and
we
needed
a
scalable
way
on
that.
So
we
created
we've
cortex,
which
is
a
has
scalable
injectors
and
really
a
scalable
version
of
Prometheus.
That's
in
the
CNC
F.
A
We
have
we've
scoped,
that's
used
for
monitoring
of
kubernetes
one
of
the
top
products
and
we
have
almost
20,000
users
of
that
I
get
into
CD
and
the
get
ops
tooling.
So
it
you've
probably
heard
some
about
flux.
You
may
have
heard
a
little
bit
about
Argo
and
the
combination
of
the
two,
but
there's
a
CNC
F
project
flux
that
actually
came
from
weave
works
as
well,
and
that's
one
of
the
premier
get
ops
technologies
that
you
can
use
with
your
weave
with
your
kubernetes
clusters.
A
In
addition
to
that,
we
have
something
called
flagger,
so
hopefully
you've
heard
about
that.
That's
kind
of
a
progressive
deployment
tool
in
the
git
ops
space
there
and
as
we're
building
these
tools
and
working
on
the
weave
communities
platform
we
work
out.
You
know
how
to
do
configs
correctly
and
things
like
that.
So
we
created
another
project
called
JK
that
allows
you
to
keep
some
of
your
definitions
dry,
so
I'm,
just
kind
of
giving
a
high-level
review.
We
have
coop
de.
If
we
have
cubes,
we
have
something
for
Griffin.
A
I
live
in
order
to
capture
your
dashboards
and
a
mechanism
that
you
can
create
as
code
and
therefore
you
can,
you
know,
version
them
and
do
all
the
things
you
want
to
do
with
those
definitions
and
all
of
that
stuff
is
used
in
in
our
wkp
product.
That
I'm
not
here
to
talk
about
kind
of
some
recent
stats
that
I
pulled
around
the
weave
workspace.
A
So
we
have
almost
25,000
stars
across
our
projects.
We
have
90
200
poles,
we've
had
over
400
releases
and
almost
600
different
contributors
to
all
of
the
different
open
source
projects
we
have.
So
if
you
have
time-
and
you
want
to
investigate
kind
of
what
we've
works
has
to
offer-
which
is
a
ton
of
things
in
the
open-source
community,
I
encourage
you
to
do
so,
but
we're
here
to
talk
about
weaving
night.
A
So
so
what
is
weave
ignite
so
I
searched
on
ignite
and
there's
a
whole
bunch
of
things
out
there,
and
none
of
them
are
related
to
exactly
what
we've
acknowledged
is
an
open
source
virtual
machine
manager
leveraging
the
UX
of
docker
container
building
blocks
has
a
built-in
get
ops
engine
and
it
was
created
by
a
VM
agnostic
company.
So
that's
a
mouthful
right,
but
but
it
we
wanted
to
get
across
all
of
the
different
features
that
we've
ignite
provides.
A
You
and
I
want
and
I'll
be
going
through
examples
today
and
showing
some
demos
of
how
that
benefits.
You
you'll
notice
the
fire
cracker
logo,
that's
at
the
bottom
of
the
screen
here.
So
fire
cracker
is
a
micro,
VM
technology
that
Amazon
released
and
it
has
reduced
the
number
of
devices
and
they
guest
facing
functionality
in
order
to
reduce,
reduce
the
footprint
and
provide
more
packable
VMS
that
are
quick
to
start
up
because
it's
used
in
Fargate
and
the
lambda
functionality
that
amazon
uses.
A
So
when
they
open
source
that
stuff,
we
had
the
Lucas
shell
storm,
who
was
in
the
finished
military
along
with
his
buddy
Dennis,
and
they
needed
a
kubernetes
installation
and
they
needed
virtual
machines.
They
were
very
limited
and
strapped
on
cash,
so
they
looked
around,
they
found
firecracker
and
they
thought
this
would
be
a
great
technology
to
build
on
top
of
and
use
for
the
kubernetes
deployment.
So
if
interesting
fact,
I
was
just
talking
to
Lucas
that
first
version
that
they
developed
is
a
500
line.
A
Bash
script,
so
you
know
fairly,
it
may
be
fairly
fragile,
but
anyways
when
they
got
out
of
their
finished
military
duty.
They
actually
came
to
weave
works
and
they
reimplemented
it
and
that's
what
we're
going
to
talk
about
today.
That
is
weave
ignite,
so
when
I
think
about
running
workloads
historically
and
over
the
years
in
my
mind,
I
kind
of
think
of
five
axes
of
those
workloads
and
the
benefits
we
get
from
the
different
layers
that
we
could
use
to
run
those
on.
A
So
if
we
start
with
hardware
and
operating
system,
just
a
base
hardware
and
installing
an
operating
system
on
there,
the
five
kind
of
axes
that
I
think
about
our
simplicity,
security,
performance,
flexibility
and
utilization.
So
when
we
had
hardware
and
operating
systems,
we
had
pretty
simple,
because
that
was
all
you
had
right.
You
could
take
advantage
of
that
performance.
You
had
the
entire
machine
for
you
to
use,
so
you
had
as
much
performance
and
security
was
yep.
I'm
gonna
run
the
workload
on
this
one
machine
and
operating
system.
A
A
This
started
to
break
down
in
my
mind,
when
some
of
you
will
remember
Moore's
law,
although
I
think
it's
not
as
relevant
now,
but
there
was
a
time
when
the
number
of
transistors
in
a
CPU
were
doubling
every
two
years
right,
and
so
what
was
happening
is
we
were
creating
this
hardware
that
had
massive
capacity
and
we
couldn't
take
advantage
of
nearly
as
much
of
it
as
we
wanted
to
you.
The
other
thing
that
was
kind
of
an
issue
on
hardware-
and
this
is
more
on
the
Microsoft
side.
A
Some
of
you
may
remember
something
that
was
affectionately
referred
to
as
DLL
hell,
and
that
was
where
you
tried
to
run
Microsoft
process
that
used
dynamic,
link,
libraries
and
see
some
nods
in
the
audience
that
use
dynamic,
link,
libraries
and
yeah.
You
could
run
one
and
then
you
did
stall,
the
other
one
and
the
first
one
wouldn't
work
and
the
second
one
would
you
saw
a
third.
Neither
of
them
would
work
because
you
would
have
all
these
conflicts
on
the
DLL
stuff,
so
things
like
OSGi
were
invented.
A
Actually
it
was
yeah
that
was
more
for
Java
side
of
the
house,
but
different
things
were
invented
to
try
and
address
that
that
shared
nature
of
wanting
to
take
advantage
of
this
bigger
beefier
hardware,
and
we
couldn't
do
it
so,
inter
virtual
machines.
So
when
those
got
added
into
the
equation
right,
your
utilization
went
up
because
our
processors
rupees
are
did
in
there
and
I
can
run
multiple
versions
of
an
operating
system
on
there
with
workloads
that
would
had
some.
You
know
good
security
and
isolation
in
it.
A
The
flexibility
was
there
so
now,
some
of
my
windows,
laptop
I,
can
run
different
versions.
Linux
I
can
run
on
the
Linux
box.
Different
versions
of
Linux
and
I
could
do
more
flexible
things
that
I
couldn't
do
previous
when
I
had
hardware
and
operating
systems
enter
containers.
The
container
space
that
I'm
talking
about
here
is
when
we
had
namespaces
and
see
groups.
So
just
the
bare
building
blocks
are
there
so
now
utilization
even
doubled,
because
well
we're
sharing
the
processor
over
sorry
we're
sharing
the
operating
system.
It's
because
we're
running
just
as
processes.
A
We
have
great
flexibility
in
that
we
have
really
good
performance,
but
we
kind
of
lost
the
simplicity
and
the
security
layer
enter
docker,
docker
added
in
the
simplicity
layer
and
really
once
docker
came
in
the
simplicity,
skyrocketed
and
that's
when
we
really
got
to
see
the
the
utilization
of
the
container
technology
over
time,
but
we
still
have
that
security
axes
that
is
missing
so
enter
ignite.
So
again,
this
is
how
I
think
about
things.
So
I
got
the
five
axes.
A
If
you
will
so,
then
we
saw
John
wick
sitting
out
in
New
York
City
somewhere,
and
he
was
wondering
if
thinking
if
only
I
could
manage
my
VMs
as
easily
as
I
could
containers
right-
and
this
is
sad,
Keanu
Reeves
thinking
that
so
what
Lucas
and
Denis
put
together
is
they
thought
sure
we
should
be
able
to
do
that
right.
So
this
is
the
CLI
command
for
ignite,
and
if
you
take
a
look
here,
you'll
see
that
a
lot
of
these
commands
they,
they
should
seem
familiar
to
you
for
those
reviews
and
Dockers.
A
So
things
like
attach
start/stop
exact,
write,
inspect
those
are
kind
of
things.
So
so
we
wanted
to
take
a
UX
that
was
well
known
and
transition
that
to
be
able
to
utilize
on
virtual
machines
as
well.
So
so
we
took
that
and
we
thought
that
was
a
good
addition
right,
no
need
to
reinvent
the
wheel
here,
especially
when
we
want
to
leverage
that
UX
that
we
had
on
docker
right.
So
as
I
go
through
the
presentation
here.
A
Not
only
did
we
do
that
on
that
level,
but
we
want
to
deleverage
even
more
of
the
docker
and
the
container
aspects
for
virtual
machines,
and
so
you
can
actually
take
a
docker
container
if
it
has
an
innate
process
in
it,
and
you
know
system
D
in
it.
You
can
run
that
on
at
night,
just
like
you
can
as
a
docker
container,
and
so
that's
really
where
the
power
is
going
to
start
to
come
in
and
I'll
show
more
about
that
shortly.
A
So
when
I
started,
writing
the
presentation
and
thinking
about
you
know
what
was
our
motivation,
what
were
some
of
the
things
that
we
looked
for
in
an
environment?
Why
did
we
look
for
these
sorts
of
things,
and
so
these
are
kind
of
the
ones
that
I
landed
on.
So
we
wanted
to
have
an
open-source
virtual
machine
and
a
VM
M
solution
that
we
could
use.
A
A
So
the
declarative
control
is
what's
important
there
and,
of
course,
all
of
us
using
kubernetes
we're
already
used
to
that
to
where
we
do
a
coop
control
apply,
and
then
it
just
makes
it
it's
kind
of
a
we
used
to
call
it
goal
seeking
before
there
was
kubernetes,
but
it's
kind
of
that
process
that
says
that's
what
they
want.
I'm
gonna
do
what
I
need
to
to
arrive
at
that
that
situation
that
was
defined
there.
So
sometimes
you
have
limited
access
to
cloud
resources.
A
This
could
be
money,
so
you
can't
spin
up
50
machines
out
in
the
cloud
because
you
can't
afford
it-
or
maybe
you
have
limited
networking
bandwidth,
and
so
that
would
be
another
motivation
here.
One
of
the
key
ones
for
us
is:
we
wanted
to
have
faster
tests
around
time
we
tried
docker
and
docker
with
something
called
footloose.
Another
open
source
project
from
weave
works
that
you
can
take
a
look
at,
but
it
basically
put
VMs
inside
of
containers.
So
you
would
start
up.
A
Finally,
in
this
area,
the
around
non-functional
requirements
testing
so
years
ago,
I
worked
out
a
project
called
Skynet,
usually
when
I
tell
people
that
they
have
also
worked,
as
anybody
else
here
worked
on
a
project
called
Skynet,
just
curious,
nope,
okay
yeah
for
those
those
older
Terminator
fans
like
me,
but
anyways.
So
we
had
this
project
called
Skynet
and
what
it
would
allow
you
to
do
is
you
would
take
a
rack
of
hardware?
You
would
neck
Network
it
together
when
it
requested
an
IP
address.
We
would
image
that
box.
A
We
would
put
that
image
that
image
machine
into
a
cluster
and
build
up
these
large
clusters
from
all
of
this
rack
hardware.
So
this
was
prior
to
kubernetes
and
one
of
the
things
we
wanted
to
test
is
well.
How
does
it
work
if
we
have
a
large
number
of
machines
and
then,
more
importantly,
what
happens
if
we
have
a
catastrophic
outage,
so
we
started
looking
around
very
difficult
to
test
something
like
that,
because
at
the
time
it
was
all
testing
with
real
hardware.
A
We
were
able
to
create
a
Zen
based
solution
and
and
test
it
that
way,
and
so
the
things
we
learned
from
that
I
learned
from
that
was
being
able
to
simulate
a
catastrophic
failure
can
be
until
the
do
chaos,
monkey
testing
and
stuff,
like
that
in
a
quick
enough
fashion
to
where
you
know
that
your
software's
doing
the
right
thing
with
quick
turnaround
time.
So
that
was
a
huge
motivation
around
ignite
as
well.
Here
I
mentioned
a
little
bit
before
about
embracing
container
management.
We
want
that
disposable
in
infrastructure.
A
We
want
a
mutable
infrastructure
for
your
virtual
machines.
All
of
us
are
still
I
think
hugging
on
a
little
too
much
on
virtual
machines.
I
know
I
am
because
I'm
gonna
use
one
in
my
demo
here
shortly,
but
yeah
we
want
to
get
away
from
that.
So
if
they're
easy
to
create
easy
to
reproduce,
you
can
create
them
as
more
disposable
resources.
A
That's
all
better.
We
want
to
leverage
container,
runtime,
CNI
benefits
and
again
I
said
the
the
VM
and
pet
mentality,
so
we're
gonna
hop
to
a
demo
real,
quick
here
and
I
just
wanted
to
put
out
a
few
of
the
requirements
that
you
have
to
have
in
your
host
operating
system.
This
is
up
on
the
website,
but
you
need
a
14
for
414
kernel,
ipv4
wording.
The
key
ones
here
are
would
be
the
CPU
virtualization,
because
we're
gonna
leverage
KBM
and
the
CPU
virtualization
that's
in
there
in
order
to
run
the
firecracker
VMs
in
there.
A
There
is
no
arm
support
yet,
but
it's
in
process
and
Lucas
who
I
mentioned
earlier,
who
created
most
of
this
technology?
He
is
actually
working
on
raspberry
PI's
to
be
able
to
run
firecracker
VMs
and
using
ignite
to
do
that
and
I
think
he
got
that
submitted
it
just
recently.
So
we
do
have
arm
now.
So
Lee
is
one
of
the
maintainer
zuv
a
big
night.
By
the
way
in
the
frontier
no
support.
A
Okay,
then
you're
gonna
need
a
container
run
time.
So,
if
you're
using
the
latest
version,
its
container
D
or
its
docker,
you
need
see
and
I
get
OpenSSH
client
device,
mapper
KBM
again
it's
all
listed
out
there
I
just
wanted
to
cover
it.
Before
we
jump
to
a
demo,
so
you
need
to
KVM
and
you're
gonna
need
ignite
and
ignite
D,
depending
on
how
you
want
to
use
it.
So
with
that
I'm
gonna
jump
to
a
demo
here,
real
quick,
so
hopefully
I
knew
that
was
going
to
happen
so
sitting
on
a
machine
here.
A
I've
split
my
screen
here
at
the
top
is
basically
just
querying
to
say
what
ignite
machines
do.
I
have
nothing's
nothing's
listed
there
and
in
the
bottom,
I'm
going
to
do
some
ignite
work
here.
So
we'll
just
go
ahead
and
do
the
ignite
before,
because
the
the
help
actually
gives
you
a
nice
listing
of
what
it
would
take
to
run
an
ignite
machine.
So
there's
the
command-line.
A
If
you
wanted
to
just
spin
up
a
machine,
ignite,
run
weave
works,
slash
ignite
booth,
so
that
is
a
docker
image
out
on
docker
hub
I'm,
saying
I
want
to
give
it
two
CPUs
two
gigabytes
of
RAM
turn
on
SSH
and
and
name
that
VM
my
PM.
So
so
we're
gonna
go
ahead.
I
didn't
want
to
do
that
because
that's
just
running
one
VM,
so
I
wanted
to
show
a
little
bit
different
way
to
do
it.
So
I
just
went
ahead
and
wrote
this
little
for
loop.
That's
gonna!
A
Do
five
VMs
all
with
different
operating
systems,
we're
just
going
to
start
those
up
so
again
to
reiterate:
I'm
on
a
Mac
here,
I'm
running
VMware
fusion,
so
performance
is
going
to
be
quite
a
bit
different
than
if
you're
running
natively
on
Linux.
But
you
can
see
before
I
finish.
Talking.
I
got
all
five
of
my
VMs
up
and
running,
and
you
can
see
that
I
have
in
a
boom.
2
VM
I
have
an
Amazon
Linux
VM
I
have
a
busy
box,
VM
an
Alpine
VM
and
a
CentOS
VM.
A
A
So
you
can
see
that
the
CentOS
and
Linux
was
fully
available
up
and
up
and
ready
in
2.8
seconds
on
here
and
the
actual
hardware
for
the
VM
before
we
started
putting
CentOS
on
it
was
second
and
a
half,
so
that's
VMware
fusion
running
on
a
Mac
with
nested
virtualization
turned
on
so
that
it
simulates
all
of
the
hardware
there.
If
you
read
the
firecracker
website,
they
talk
about
running
4000
machines
and
all
of
them
I
think
our
sub-second
start
time,
Lisa
right,
yeah,
so
sub-second
response
start
time.
A
So
now,
okay,
my
VMs,
are
coming
up
fast
enough
right
to
where
they're
marrying
what
I
could
do
with
docker
containers,
only
it's
a
full
vm.
So
as
I
mentioned
before
I
attached
to
this
machine
here,
so
we
can
go
ahead
and
log
in
right,
and
so
now
we
can.
You
know
cat
Brock,
CPU,
info
and
yeah.
So
this
is
the
virtual
machine
that
I
just
started
up.
A
You
can
see
in
there
I
said
it
only
needs
one
CPU
if
we
wanted
a
cat,
mmmph
Oh
again
so
I
said:
half
a
gig
of
ram,
there's
half
a
gig
of
ram
there,
and
if
I
do
it,
you
name
Shay,
you
can
see
it's
a
419
kernel
if
I
log
back
out
and
I
do
a
you
name
a
on
my
Linux
box
that
were
my
Linux
VM,
it's
a
five
kernel.
So
I
was
able
to
start
all
those
virtual
machines
with
one
command
a
for
loop,
which
looked
just
like
a
docker
command.
A
It
downloaded
the
episode.
It
was
fast,
I
download
the
images
previously
right,
so
we're
using
a
container
run
time.
So
that
is
caching
the
images
for
me
and
that's
why
performance
look
like
that
if
I
had
to
download
the
images
across
the
Wi-Fi
here
might
not
have
been
quite
as
fast
and
then
to
to
show
you,
you
know
how
easily
it
is
to
then
clean
up.
A
I'll
just
go
ahead
and
hit
the
remove
of
the
VMS,
and
that's
it
third
on
right,
so
so
simple
commands
in
and
out
starting
stopping,
but
getting
a
whole
virtual
machine
in
that
short
amount
of
time
is
when
I
just
ran
through
there
quickly,
so
that
was
first
demo
of
just
creating
a
handful
of
VMs.
You
can
see
how,
if
I
could
create
that
many
on
a
virtual
machine
running
on
my
Mac.
A
If
I
had
a
regular
machine,
I
could
do
quite
a
bit
more
with
it,
especially
like
when
I
want
to
do
chaos,
monkey
testing
or
that
sort
of
thing.
So
what
happened?
It
looked
easy,
but
there's
a
lot
of
stuff
happening
under
the
covers
here,
so
this
is
trying
to
put
together
this
sequence
diagram
to
kind
of
understand
exactly
what
really
transpired
right
that
we
just
did
so.
I
did
ignite
run.
What
happened
when
I
did
that
it
talked
to
the
container
runtime.
A
In
this
instance,
it
was
container
D
that
that
interacted
with
the
image
registry
in
order
to
pull
down
the
image
cache
it
down.
We
then
turned
that
image
into
something
they
could
be
used
by
the
device
mapper
to
use
as
a
root
filesystem
for
a
virtual
machine.
So
then
we
set
up
a
network
using
CNI
networking.
Then
we
interacted
with
the
container
runtime
again
in
this
case
it's
just
container
D
and
we
said,
run
this
process
or
run
this
container.
That
has
two
processes
in
it.
It's
an
ignite
spawn
process
and
a
firecracker
process.
A
So
this
would
be
the
firecracker
thing
that
started
the
VMS
in
KVM,
so
ignite
spawn
interacted
with
firecracker
who
interacted
with
KVM,
who
generated
a
virtual
machine
again,
that's
that
stripped-down
virtual
machine
on
KBM
that
in
turn
used
the
root
filesystem
that
we
set
up
with
the
device
mapper
it
DHCP.
The
ignite
spawn
process
took
its
IP
address
that
it
got
from
CNI
and
gave
it
to
the
VM.
A
So
now
that
VM
is,
is
routable
and
available,
and
you
saw
the
IP
addresses
listed
on
the
machine
there
so
kind
of
a
high-level
review
that
there's
a
lot
of
stuff
going
on
underneath
the
covers
to
do
that.
But
the
key
point
was
trying
to
simplify
it
all
down
to
where
looks
like
you're
just
running
containers
right
and
so
we're
gonna
continue
on
that
theme
as
we
as
we
go
along.
A
So
this
is
just
another
picture
of
the
architecture
and
the
kind
of
the
breakup
what
happened
there
so
there
we
started
out
saying
we
needed
to
get
the
OCI
images.
So
if
you
were
to
do
these
steps,
so
encapsulate
all
of
these
steps,
but
you
can
do
these
individually,
so
you
could
like
cache
images
and
things
at
on
your
own.
So
I
did
an
ignite
image
import
or
we
did
underneath
the
covers
that
generated
these
write-only
snapshots
using
the
device
mapper.
A
We
started
this
OCI
container
that
you
can
see
listed
here
where
the
first
process
is
that
ignite
spawned
that
created
the
Firecracker
and
then
that
created
our
KVM.
We
have
signed
the
IP
address
and
poof
we
have
some
VMS
there.
So
OCI
is
a
great
standard
and
we
thought
why
not
reuse
that
for
here,
so
we're
using
that
for
content,
distribution,
some
monitoring
of
processes
and
process
isolation.
So
this
one
seems
weird
to
me
when
I
look
at
that,
because
I
think,
okay,
we
have
KVM
and
we
have
virtual
machines
running
in
in
KBM.
A
A
A
But
now
you
have
to
break
out
of
the
container
that
docker
gave
us
or
your
container
runtime
in
order
to
do
any
kind
of
damage
to
any
of
the
other
containers,
not
to
mention
we
use
the
networking
and
things
that
we
get
from
docker
in
order
to
facilitate
a
lot
of
the
networking
stuff
and
simplify
it
down.
So
that's
why
we
have
the
containers
there
for
that.
In
addition,
we
use
the
resource
limit.
A
So
if
you
were
to
specify
different
resource
limits,
we
put
those
on
the
container
because
it
already
has
that
mechanism
to
do
that.
Work
for
us,
so
we're
using
device.
Mapper
and
DCP
bridges,
like
you
mentioned,
and
that's
kind
of
the
high
level
architecture
of
what
happened
when
I
hit
a
kite
run.
So
let's
talk
briefly
about
get
ops,
hopefully
everybody's
heard
of
get
ops
and
knows
a
little
bit
of
something
about
it,
but
that,
but
if
you
don't
that's
okay,
too
so
get
ops
is
really
separating
the.
What
from
the
how
right.
A
So
you
want
to
capture
your
facts.
Put
them
in
your
repository,
get
in
in
this
instance.
It
doesn't
have
to
be
get,
but
you
know
that's
kind
of
where
we
started
so
we're
saying
get
ops
in
that,
but
really
it's
yeah.
You
know
capturing
your
facts
and
using
it
there
so
and
that's
you're
a
single
source
of
record,
and
then
you
have
a
separate
process
that
is
working
to
achieve
those
goals
right
to
achieve
that
set
up.
A
So
we
have
this
loop
in
here
that
says:
okay,
you
get
your
state
and
get
you
release
that
it
goes
into
your
runtime
system.
You
observe
what
the
system
is
doing,
based
on
that
you
diff,
based
on
desired
state
versus
the
actual
state
trying
to
figure
out
do
these
match
if
they
don't
I
need
to
take
corrective
action,
so
should
all
seem
familiar.
Kubernetes
is
like
that
in
a
declarative,
declarative
manager
manner,
and
then
this
just
loop
just
kind
of
goes
around.
So
the
key
is
really
that
reconciliation
loop.
A
You
could
do
a
lot
of
this
with
imperative
work,
but
what
are
you
gonna
build?
You're
gonna
have
to
build
a
reentrant
and
an
idempotent
shell
script
that
you
can
run
on
cron
every
X
amount
of
time,
and
you
can
absolutely
do
that.
We've
we've
all
probably
done
that
as
we're
adopting
these
kind
of
things,
but
it's
that
it
makes
it
really
difficult
to
know
a
where
it
failed.
Why
it
failed.
A
What's
the
difference
here
so
when
you
can
diff
the
facts
in
the
in
the
repository
versus
what
the
observable
state
is
that
make
things
easier
there?
So
then
I
mentioned
here
about
the
common
tooling,
so
a
lot
of
people,
you
know
we
say,
get
ops
and
they
think
ok,
well,
everybody's
just
gonna
use
git,
and
it's
really
with
the
invent
of
ignite
and
how
we've
put
it
together.
A
So
this
is
just
a
get
ops,
inspector,
sorry
and
Knight
inspect,
and
you
can
see
here
it
really
breaks
down
into
four
different
blocks
and
again,
hopefully,
you're
getting
a
theme
here
again.
This
should
look
familiar
right
because
we're
leveraging
the
kubernetes
api
machinery
in
order
to
deal
with
manifests
right.
So
here
we
have
a
kind.
So
what
is
this?
It's
a
virtual
machine.
How
do
I
identify
it?
What's
my
metadata?
A
What's
the
image
I'm
gonna
run,
so
my
root
filesystem
in
this
instance
is
a
date
night
boom
to
latest
and
so
the
way
on
that
and
then
finally,
we
need
to
have
the
status
so
basically
tell
us
when
you
observe
the
the
state
between
what
it
is
and
what
it
when
you
observe
the
state
of
what
it
is
we'd
like
that
recorded
here.
So
that's
in
the
status
area,
so
all
of
this
should
seem
very
very
familiar
for
those
of
you.
Everybody
that's
working
with
kubernetes,
because
we
leveraged
a
lot
of
that
same
infrastructure
here.
A
So
we
capture
the
definition
of
what
we
want.
We
just
need
the
how
we
make
that
happen,
so
I'm
gonna
do
an
a
demo
now
of
the
get
ops
processing
that
Ignite
provides
for
itself,
but
really
ignite
can
be
leveraged
for
other,
get
ops
processes
that
you
need
to
isolate
and
do
repeatable
processes
in
your
environments,
where
you
need
a
virtual
machine
and
maybe
multiple
different
alessa's
in
your
environments.
But
this
is
the
get-ups
specific
attributes
that
Ignite
provides
here
so
back
to
our
same
machine
here.
A
So
what
what
I
have
created
is
I
have
a
git
repo
out
here
in
my
account,
and
it
has
four
machines
defined
in
it
so,
and
these
should
look
very
familiar
because
that's
what
we
just
had
up
there.
But
the
key
point
here
is
I've
said
all
these
two
running
is
false.
So
basically,
what
I
want
is
when
I
start
the
Ignite
process.
I
want
you
to
prepare
to
run
these
and
then
at
a
later
date,
we'll
go
ahead
and
turn
them
on
or
off
depending
on
it.
A
So
if
you
were
doing
testing,
maybe
you're
doing
a
boomtube
testing
and
you
need
to
spin
up
five
a
boon
to
machines
and
you
want
to
leave
the
CentOS
machines
ready
to
go
right,
even
though
it's
it's
fast
enough
to
start
them
up,
it's
even
faster.
If
you
can
cash
some
of
the
images
and
be
ready
to
actually
start
them
up
and
run
so
I'm
just
going
to
start
the
back-end
process,
which
is
ignite
D,
get
ops
here.
A
So
if
I
take
a
look,
I'm
running
ignite,
D
get
ops.
I
have
my
repo
here
that
I've
set
up
key
so
that
I
can
pull
from
it.
I
have
log
levels
set
to
debug.
Maybe
I
won't
need
to
talk
about
that,
but
I
have
it
set
for
that
now.
So
what
this
is
going
to
do
it's
going
to
start
up
some
reconciliation
loops,
and
it's
going
to
query
my
repository
to
see
if
there's
any
work
that
it
needs
to
be
needs
to
be
done.
So
this
takes
just
a
little
bit
here.
A
So
it's
initialized,
it's
pulled
in
a
repository
and
let's
see
what
it
does
here,
so
it
noticed
that
I
had
four
machines
defined
in
there.
It
created
all
four
machines
and
there
there
I
have
that
a
flag
on
my
ignite
command
line
for
PS,
which
says
show
me
everything
and
you'll
notice.
All
of
these
are
listed
as
stopped
right
now,
so
they
don't
have
IP
addresses
they're,
not
taking
any
resources
right
now
when
you
carry
through
with
get
ops-
or
you
know-
we
it's
also
sometimes
referred
to.
A
As
you
know,
at
pull
request
mechanism
and
that's
how
I
like
to
do
it
so
I've
created
a
pull
request
out
here.
That
says,
turn
the
machines
on.
So
we
went
through
all
the
testing
and
everything
and
if
we
take
a
look
at
the
change
request,
all
I
did
was
change
it
from
false
to
true
so
I'm
gonna
hit
merge
this
pull
request
and
now
what's
gonna
happen
is
ignites
gonna
see
that
change
and
it's
gonna
turn
on
all
these
machines.
A
So
and
now
you
can
see
why
I
have
debug
turned
on
because
I
turned
all
the
machines
on,
but
for
some
reason
it
didn't
turn
on
the
last
machine,
booted
everything,
but
the
last
one
trying
to
thought
was
talking
to
Lee
earlier
about
this.
So
this
is
all
still
in
active
development.
It's
a
live
demo
and
unfortunately
this
has
worked
for
two
weeks
until
last
night
when
it
stopped
working
on
my
machine,
but
so
so
what
did
I
do?
There?
A
I
didn't
touch
anything
other
than
make
a
pull
request
and
have
ignite
go
off
and
do
that
so
by
capturing
all
of
the
definition
of
your
environment,
testing
and
everything
you
can
give
it
to
multiple
developers.
They
can
work
on
that.
They
can
spin
up
these
virtual
machines
on
their
desktop
to
run
whatever
testing
they
need
to
do
in
in
their
area.
So
that's
it
for
the
Ignite
DevOps
processing
there.
So
I'll
hop
back
here.
A
Don't
worry,
I
know
I'm
standing
between
your
party
tonight
and
and
and
an
enjoyment.
So
I
talked
about
Ville
the
fact
that
we're
leveraging
you
know
as
much
as
we
can
as
far
as
the
docker
aspect.
So
when
you
guys
build
virtual
machines
today,
do
you
you
know
you
go
to,
depending
on
which
machine
you're
using
you're,
probably
building
a
VMDK
and
you're
provisioning
in
a
certain
amount
of
disk
space
and
you're
running
an
installer
and
doing
X.
You
know
etc.
Work
in
there
to
get
that
VM
to
cater
ready
to
go
three
minutes.
A
Okay,
I
could
speak
faster
anyways.
So
what
you
see
here
these
should
be
look
familiar
to
again
that
common
theme,
but
we're
building
VMs
the
new
way
by
building
docker
containers.
So
these
are
docker
build
files.
The
one
on
the
left
that
you
see
is
a
kernel
and
the
one
on
the
right
is
the
abouttwo
machine
that
we
ran
in
the
demos
here.
So
these
now
I
have
code
there,
docker
files,
I
do
docker,
builds
check
those
into
a
docker
registry
and
then
run
them
with
ignite.
A
So
last
last,
quick
demo
that
I
have,
and
that
is
that
that
ignite
produces
Prometheus
data.
So,
since
we're
using
containers,
we
can
take
advantage
of
all
of
that
infrastructure
as
well,
so
I'm
gonna
switch
back
over
here
and,
unfortunately
we're
gonna
go
ahead
and
kill
this
one.
So
we
open
a
socket
for
each
virtual
machine.
That's
there.
It
gets
a
socket.
That
is
the
Prometheus
data
and
also
the
ignite
D
process
has
a
socket
that
will
tell
us
details
of
what
it's
doing.
A
So,
if
we
take
a
look
here,
I
just
queried
the
Ignite
demon
to
see
and
I'm
repping
out
what
VM
operations
it
did,
and
you
can
see
that
it
said
I
created
three
machines
and
I
went
ahead
and
started
three
machines
and
if
I
had
queried
that
in
between
the
start
or
setting
that
definition
from
running
to
from
running
false
to
running
true,
you
would
have
seen
that
it
only
created
three
and
then
it
created
it
started.
The
other
three.
A
The
bug
I'm
trying
to
find
is
why
didn't
do
four,
but
it's
a
demo,
so
I
kind
of
expected
something
to
not
work
and,
like
I
said
we
can
also
query
each
of
the
machines
themselves.
So
if
I
can
spell
so
if
we
take
a
look
at
one
of
the
IPS
there
or
one
of
the
IDs
of
this
machine-
and
we
can
query
that
soccer
and
we
can't
connect
to
that
one
either.
So
that's
probably
the
one
that
did
not
start
up.
So
it's
a
demo
I
apologize
for
that.
A
A
Please
go
in
there
and
get
involved
and
if
you
happy
Oh,
pricey
myself
orally
here
approving
pull
requests
and
whatnot
on
and
if
you
want
to
learn
more
about
get
offs,
we
have
a
hands-on
demo
that
you
can
do
and
get
one
of
these
nice
shirts
that
Lee
is
actually
wearing.
So
with
that
I'll.
Take
any
questions.
Am
I
over
time?
Okay,.
C
B
B
C
A
B
Yeah
so
basically
the
the
way
that
firecracker
boots
machines-
it
specifically
boots
Linux.
So
it
cannot.
Firecracker
cannot
boot
windows,
some
folks
from
solo,
5
and
the
likes,
and
you
know
kernel
type
projects
looked
at
booting
firecracker
with
Yuna
kernels,
so
that
would
work,
but
as
far
as
booting
Windows,
that's
not
something
that
firecracker
supports.
I'm.
C
C
C
C
A
It
is,
but
what
we
really
need
is
more
community
involvement
to
help
us
drive.
What
are
the
most
important
things
to
focus
on,
so
we
don't
have
an
overarching
goal
to
say
we
want
to
mimic
everything
we
do
in
docker
in
ignite.
If
does
that
they
never
involvement
from
the
community
to
help
us
decide.
What's
the
most
to
build
so.
A
C
Then
one
final
question,
because
this
is
Q
Khan
there
are
tools
like
telepresence
and
such
that
are
used
scaffolding.
All
these
tools,
sto
take
tella
persons,
for
example,
will
that
work
with
ignite
and
firecracker
running
on
a
kubernetes
cluster?
And
if
not,
what
will
that
take?
Because
I
know
you
mentioned,
there's
a
container
wrapper
around
it.
Mm-Hmm.
B
A
B
Running
ignite
VMs
on
a
kubernetes
cluster
is
something
that
is
technically
feasible
and
that
one
of
our
primary
maintainer
x'
is
very
interested
in
writing.
A
virtual
couplet,
plugin
or
implementation
to
support,
and
then
when
that
is
happening,
a
one
thing
that
is
very
important.
That
did
we
touch
on
the
fact
that
networking
is
provided
by
CNI
yeah
right
so
yeah
like
you,
can
put
a
bunch
of
ignite
VMS
on
a
weave
net
or
a
calico
or
and
it'll
work
with
things
like
linker
D.
B
If
you
want
to
use
something
right
like
let's,
let's
go
make
it
work,
so
this
project
is
like,
let's
totally
do
cool
stuff
together,
not
like.
Oh,
this
is
important
for
production
on
5,000
servers.
There's
a
question
back
there.
If
we
could
get
yeah
krandall
comes
from
a
docker
image
and
it's
built
and
you
can
provide
your
own
yeah
read.
If
s
is
expanded.
D
A
B
D
Okay,
sorry,
really
cool
technology,
I
love
what
you
guys
are
done,
I'm
thinking,
though,
in
terms
of
who
your
target
audience
is
from
a
business
value
perspective
like
as
a
you
know.
This
guy's
point
like
as
a
Mac
user
docker
desktop,
is,
is
way
more
convenient
because
you
know
I
want
to
develop
the
docker
and
it
just
works
on
a
Mac
out
of
the
box
right.
D
B
A
So,
as
I
was
talking
to
motivation
earlier
for
me,
is
it's
really
about
treating
virtual
machines
as
as
docker
containers
and
simplifying
the
creation
start-stop
for
performance
of
that
and
using
those
in
place
of
other
places
where
you
may
actually
use
real
hardware
or
cloud
resources
or
whatnot?
So
for
me,
that's
the
motivation
around
when
I'm
working
on
the
wkp
product
right
I'm,
trying
to
build
larger
kubernetes
clusters
in
order
to
get
my
hands
on
all
those
either
virtual
machines
or
using
cloud
resources
is
going
to
be
expensive.
It's
going
to
be
time-consuming.
A
So
for
me
it's
a
lot
around
the
testing
aspect,
testing
turnaround
time
and
be
able
to
do
like
I,
said
kind
of
that
catastrophic
failures
and
say:
okay.
Well,
how
long
would
it
take
wkp
to
build
100,
node
communities
cluster
right
and
by
the
fact
that
I
can
spin
up
those
virtual
machines
like
that,
and
then
I
can
use
Kubb
ATM
on
it
too?
You
build,
you
know,
install
whatever
I
need
and
then
join
the
cluster.
A
Okay,
now
I
have
something
that's
a
repeatable
process
and
by
the
way
it's
all
in
get
ups
and
I
can
run
it
all
directly
from
that
as
well.
So
that's
my
motivation.
You
know
it's
not
it's
not
to
replace
the
doctor
desktop
in
those
aspects.
It's
more
around.
Let's
get
VMs
to
be
more
immutable
and
easier
to
interact
and
use.
That's
that
would
be
my
answer
and
it's
a
good
answer.
Okay,
yeah.