►
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2021 Virtual from May 4–7, 2021. Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Image-Builder Deep Dive - Moshe Immerman, Flanksource & Tushar Aggarwal, VMware
Image-builder is a subproject of SIG Cluster Lifecycle that was created with idea to host a number of different utilities for creating virtual machine images. It has the following goals: 1) To build images for Kubernetes-conformant clusters in a consistent way across infrastructures, providers, and business needs. 2) To provide assurances in the binaries and configuration in images for purposes of security auditing and operational stability 3) To ensure that the creation of images is performed via well defined phases. Where users could choose specific phases that they needed.
https://sched.co/ekGy
A
Hi
everyone
and
welcome
to
the
image
builder
deep
dive,
I'm
moshe
imaman
and
I'm
joined
here
with
tushar.
So
the
image
builder
deep
dive
project
is
a
sponsored
project
by
the
sig
cluster
life
cycle
group.
And
if
we
go
into
the
the
history
of
the
project,
there
was
a
really
a
lack
of
consensus
on
on
approaches.
So
there
are
quite
a
lot
of
approaches
to
building
images
and
we
are
talking
about
machine
images.
A
So
these
are
the
images
that
that
provide
kubernetes
hosts
not
contain
images,
because
there's
quite
a
bit
of
confusion
there
and
there
was
a
document
that
was
put
out
at
the
beginning
of
the
project
which
was
over
a
year
ago,
and
there
was
a
lot
of
comment
on
that
document
and
some
people
prefer
building
in
the
cloud.
Some
people
prefer
building
locally.
Some
people
prefer
using
bits
directly
and
there
really
was
a
lack
of
consensus
on
this,
and
it
was
kind
of
agreed
upon
that.
A
A
There
are
a
lot
of
issues
that
that
can
come
up
with
incompatible,
docker
versions,
container
d
versions,
so
we
really
do
want
to
have
some
type
of
conformance
test
for
an
image
to
say
this
image
can
run
kubernetes
successfully
and
while
not
a
primary
goal,
so
releasing
images
across
different
operating
systems
and
cloud
providers
was
kind
of
a
stretch
goal.
At
the
moment.
This
is
handled
separately
by
individual
sub-projects.
So
each
of
the
the
infrastructure
providers
for
cluster
api
is
releasing
their
own
images.
A
So
looking
at
at
what
we
have
today,
so
there
are
three
tools
that
were
kind
of
consolidated
into
the
repository,
the
first
one
being
an
ansible
packer
configuration,
and
this
is
where,
where
historically
a
lot
of
the
work
by
heptio,
was
done
on
their
projects
and
and
where,
today,
microsoft
and
vmware
and
many
other
infrastructure
providers
for
cluster
api
are
spending
time.
Building
conformant
images
for
cluster
api.
So
there
are
providers
for
vmware,
microsoft,
google,
cloud,
digitalocean,
openstack
or
qmu,
and
for
a
variety
of
operating
systems.
A
Windows
is
in
the
work,
so
it's
flat
com.
The
second
tool
in
the
repository
would
be
cube.
Deploy,
and
this
comes
from
the
k,
ops
project
and
at
the
moment
there
is
a
very
limited
support
on
on
the
tool
and
more
than
likely
it
will
be
the
first
one
to
merge
into
one
of
the
other
tools
and
then
the
final
tool
is
a
a
golang
based
cli
that
that
is
really
designed
to
take
a
lot
of
the
configuration
effort
out
of
ansible
and
packer
and
and
provide
a
better
user
experience.
A
B
Thanks
mosh:
let's
start
with
our
packer
and
simple
system.
For
those
who
don't
know,
packer
is
a
free
and
open
source
tool
for
creating
golden
or
base
images
for
multiple
platforms
from
a
single
configuration
and
packet
builds
and
provisions,
and
also
does
some
post
processing
to
output.
The
final
cluster
api
conformant
images,
the
next
major
tool
that
we
use
is
ansible.
B
B
So
basically,
this
screen
shows
the
high
level
diagram
of
what
the
packer
and
ansible
make
file
based
system
looks
like
the
pipeline
here
describes
the
process
of
image,
building
the
configs
feed
into
make
system
which
invokes
packer
binary
with
requisite
packer
variables
and
execution
files,
and,
as
you
can
see
here,
packer
is
a
three
stage
process
where
it
first
builds
an
os
image
from
an
iso
or
a
base.
Ami
or
an
azure
offer
once
base
vm
is
ready.
Packer
passes
on
the
execution
to
provisioning
stage.
B
You
can
also
like
download
the
ov
and
customize
the
ovf
in
case
of
oviabreader,
so
yeah
and
at
the
end
of
the
whole
process.
Finally,
we
get
an
image
which
is
a
cappy
conformant,
so
a
bit
more
about
packer
configs
that
feed
into
the
system.
So
these
packer
configs
are
used
to
define
kubernetes
versions,
kubernetes
sources,
container
diversion
kickstart
and
pc
files.
Some
of
these
arguments
are
passed
down
by
packer
to
the
ncbl
provisional,
for
installing
correct
components
and
stuff.
B
You
can
also
modify
this
configs
to
build
custom
images
coming
on
to
the
ansible.
We
have
basically
structured
all
the
ansible
tasks
in
four
roles,
as
this
slide
displays
actually
five
roles
and
one
like
x,
number
of
custom
roles.
So
so
you
can
see
like
there
are
four
predefined
rules
which
set
up
the
base
components.
B
Customizable
roles
actually
enable
you
to
completely
undo
the
past
four
rules
that
we
saw
and
redo
them
in
your
own
way.
And
then
so.
So
it's
it's
a
pretty
powerful
feature
which
will
allow
you
to
like
customize
the
image
as
as
as
you
want,
and
then
we
run
the
sysprep
roll
in
the
end,
which
will
clean
up
the
things
for
you
so
yeah.
So
this
is
about
customizing
the
image
and
we'll
see
a
demo
later,
how
we
customize
the
image.
B
Demo,
so
here
we
can
see
that
first,
I'm
doing
the
make
help
command,
which
will
list
all
the
targets
related
to
photon
3,
which
I'm
going
to
use
for
my
demo.
We
can
see
that
there
are
various
builders
here
and
we
are
going
to
use
a
local
builder
local
hypervisor,
vmware
fusion,
based
hypervisor
and
a
photon
3
os.
B
So,
to
start
with,
let's
look
at
the
packer
config,
so
here
we
can
see
that
this
is
a
packer
config
for
kubernetes.json
and
you
can
see
that
various
variables
are
defined
for
the
type
of
kubernetes
version
we
want
to
install
like.
We
can
see
1
17
11
here
with
all
of
these
things
can
be
over
in.
We
can
also
see
http
sources,
debian,
debian
and
rpm,
requisitory
and
sources.
B
B
So
all
of
these
settings
again
feed
into
packer
system,
which
it
passes
to
principle
for
installing
the
right
container
d
coming
on
to
the
packer
main
packer
json
or
configuration
file,
we'll
see
that
on
the
top
we
have
defined
all
the
variables
that
are
being
consumed
and
then
we'll
have
various
type
of
builders.
It
can
be
local
builder,
vsphere
base
builder
esx
based
builder,
and
then
we'll
see
the
builder.
We
are
going
to
use
this
vmware
iso,
which
helps
us
produce
local
ovf.
B
There
are
various
configurations
that
we
do
here:
boot
command
and
ssh
username
cpu
memory.
You
can
look
into
more
detail
on
our
upstream
repo
and
next
looking
at
the
provisional,
we
can
see
that
there
is
an
ansible
provisioner
here.
We
can
also
add
some
extra
arguments
for
increasing
the
verbosity
and
debugging
purposes,
and
then
we
can
see
that
we
pass
the
playbook
file
and
the
and
the
ansible
ssh
arcs
to
be
done.
B
Next
important
provisioner
that
we
use
is
gauss.
It's
basically,
as
I
mentioned
before,
is
for
server
validation
and
a
server
spec
side
tools
tool.
So
we
are
passing
a
various
configurations
to
it
and
then
the
last
section
is
our
post
processor,
where
we
have
a
post
processor
of
type
manifest,
which
generates
a
just
like
a
json
kind
of
manifest
which
details
what
all
things
got
installed.
As
you
can
see
from
line
378
390.
All
this
information
is
captured
in
the
manifest,
along
with
the.
B
Ovf
next
we
are
going
to
look
at
the
customizable
role
that
I
have
created
to
customize
the
image
apart
from
the
upstream
image
building
that
will
take
place
on
it.
So
I
am
installing
this
tool
called
havist,
as
you
can
see
here,
to
increase
the
entropy
and
then
I'm
setting
some
extra
kernel,
params.
B
B
B
B
Let's
kick
off
this
build,
as
you
can
see
on
the
top
of
the
screen
that
there
are
few
hack
insurance,
even
short,
packer
got
run.
We
just
make
sure
the
right,
tooling
is
present
on
the
machine
and
then
right
now
it's
building
the
vm,
it's
waiting
for
it
to
boot
and
it's
it's.
Then
it
will
wait
for
getting
an
ip
and
once
the
system
is
on
it
will
it
should
start
provisioning
it.
B
As
you
can
see
here,
it's
installing
all
the
uncivil
rules
kubernetes
right
now
and
then
this
is
this
prep
roll
cleaning
of
the
ssh
keys,
and
here
I
can
see
that
we
are
running
gauss
and
you
can
see
that
48
has
passed
and
zero
failed.
So
basically
cos
was
able
to
verify
that
all
the
components
that
were
required
are
there
and
running.
For
instance,
we
can
see
that
service
container
d
is
running
and
matches
expectation.
True.
B
B
B
We
can
see
all
these
image
processes
are
also
running,
some
of
which
are
exited
because
it's
in
a
state
of
reconciliation
where
slowly
everything
will
be
powered
on
and
now
next
you
can
see
that
we
installed
this
tool
called
harrist
which
is
installed
and
present
on
the
system
yeah.
So
this
is
our
demo
of
the
complete
thing.
A
Thank
you
to
cheryl
that
was
very
informative,
so
the
image
builder
is
definitely
far
from
complete.
It
is
being
used
in
production
for
a
number
of
use
cases
and
for
the
future
type
of
plans.
We
are
looking
at
releasing
a
cli
that
will
replace
much
of
the
make
file
functionality
and
make
it
a
little
bit
more
discoverable
and
user
friendly,
as
well
as
as
make
some
of
the
configuration
auto
generated
and
merged.
A
A
The
same
way
that
the
containers
are
promoted
today
for
many
of
the
sub
projects,
so
in
terms
of
the
cli,
so
the
cli
is
not
a
a
replacement.
It's
it's
in
an
addition
to
the
existing
tool
set
that
that
encapsulates
much
of
the
the
makefile
based
functionality,
as
well
as
adding
a
few
other
non-packer
based
approaches
for
building
images
and
and
that
should
be
released
for
consumption,
also
in
the
next
month
or
two
and
unlikely
by
the
time
this
video
is
or
this
presentation
is,
is
running.
A
It
should
be
out
as
well
in
terms
of
how
you
can
contribute.
Probably
the
biggest
way
is
use
the
tool,
consume
the
images
and
and
and
tell
us
what
what
could
be
better
attend
the
office
hours.
If
you
want
and
and
really
report
new
issues
bugs
and
and
suggestions,
anything
is
welcome
and
where
you
can
find
us,
so
we
have
a
bi-weekly
office
hours,
we're
on
the
main
suit
cluster
life
cycle.