►
Description
Want to view more sessions and keep the conversations going? Join us for KubeCon + CloudNativeCon North America in Seattle, December 11–13, 2018 (http://bit.ly/KCCNCNA18) or in Shanghai, November 14–15 (http://bit.ly/kccncchina18).
Source2Image Intro – Ben Parees, Red Hat & Matt Moore, Google (Any Skill Level)
Over the years Kubernetes has had a number of different approaches to building images on or for Kubernetes. Now is a good time to take stock of Kubernetes' image building support from the perspective of different types of users. In this session, we'll look at a little history of building images for use with Kubernetes. We will review and demo some specific examples with working in this space dating back to the very beginning of Kubernetes and containerized applications, then lead a conversation around some of the challenges and techniques when either building images on or for Kubernetes. Challenges that need to be considered when building images on kubernetes include dependencies on a local docker daemon, security/privilege requirements, and caching+reuse of build artifacts.
About Ben
Ben Parees is a Principal Engineer on OpenShift. He serves as the lead for the Developer Experience team which focuses on workflows that take developers from source code to PaaS deployed Docker image based applications, including continuous integration and delivery flows.
About Matt
Matthew co-founded and was the original Tech Lead for the Google Container Registry product, and has been involved with Docker at Google since the beginning. These days, Matthew is focused on Uber TLing container development and firmly believes that we can do better than Dockerfiles. He is the principal author of github.com/google/containerregistry and github.com/bazelbuild/rules_docker which enable the construction and manipulation of Docker images without a Docker daemon or root. As a part of building better container images, Matthew believes we should kick the Distro out of our containers. Come see why at his talk!
Want to view more sessions and keep the conversations going? Join us for KubeCon + CloudNativeCon North America in Seattle, December 11 - 13, 2018 (http://bit.ly/KCCNCNA18) or in Shanghai, November 14-15 (http://bit.ly/kccncchina18).
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 21! 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.
A
Well,
thank
you
all
for
coming
to
this
wonderful
session
with
about
25
other
competing
sessions.
So
I
really
appreciate
you
showing
up
and
coming.
This
is
the
intro
to
from
source
to
image.
It
was
written
up
as
source
to
image
and
I'm,
obviously
with
OpenShift
and
I
have
a
bias
towards
our
tool
source
to
image.
A
But
we
all
know
that
there's
many
many
tools
out
there
and
tool
chains
for
building
images
and
what
we'd
really
like
today,
too,
is
to
go
into
some
of
the
key
concepts
around
that
today
and
tomorrow
we
have
a
deeper
dive
at
3:40
and
we
are
not
really
going
to
be
source
to
image.
Centric
like
that
tool.
B
All
right
welcome,
so
yeah
I
am
Ben
priest
I,
lead
the
developer
experience
team
for
OpenShift
and
that
one
of
the
main
core
missions
for
us
is
enabling
developers
to
take
their
application
source
code
and
turn
it
into
an
image
on
the
OpenShift
platform
and
then
get
that
image
running.
So
one
of
the
tools
we
maintain
is
what
I'll
refer
to
as
s2i,
which
is
specifically
the
command
line
tool
for
doing
source
damage,
as
opposed
to
the
general
concept
of
going
from
source
to
image,
which
is
what
we're
gonna
talk
about
today.
B
C
B
Alright,
so,
first
off
we're
just
going
to
lay
out
the
framework
of
so
what
do
we
mean?
We've
now
confused
you
about
s2i
versus
source
to
image,
so
we'll
try
and
explain
that
get
through.
Why
you
should
care
about
that?
You
probably
already
have
some
idea
since
you
came
to
this
session
and
then
we're
gonna
go
through
some
of
the
different
approaches
that
are
starting
to
evolve
in
the
ecosystem
around
how
you
do
this
and
then
that
should
be
a
relatively
short
part
of
the
session,
because
we
want
to
open
the
floor
to
discussion.
B
B
So
what
do
we
mean
when
we
talk
about
source
to
image
in
general?
We're
talking
about
just
a
way
to
go
from
I've
got
my
source
code
in
a
repository
somewhere
and
I
need
to
turn
it
into
a
runnable
application
image.
Probably
cuz
I
want
to
run
on
kubernetes,
so
I've
got
a
bunch
of
source
code.
How
do
I
make
that
into
an
artifact
that
I
can
run
on
my
cluster
and
then
more?
Ideally,
we
want
to
do
that
by
hiding
the
details
that
are
going
on
when
you're
constructing
the
image.
B
So
when
you
write
a
docker
file,
you're
exposed
to
some
pretty
ugly
details
of
what
it
means
to
construct
an
image
and
application
developers
shouldn't
have
to
care
about
those
things,
and
it's
actually
dangerous
in
some
cases
to
let
them
do
it,
they
might
produce
less
secure
images.
They
might
produce
less
efficient
images,
they're
not
going
to
follow
up
best
practices.
B
So
by
limiting
the
things
they
have
to
worry
about,
you
can
guide
them
down
those
best
practices
and
then
you're
also
just
keeping
them
from
having
to
learn
about
things
that
they
don't
need
to
know
about.
They
know
their
source
code,
they
know
how
to
build
source
code,
they
don't
necessarily
know
docker
files,
they're,
certainly
not
experts
in
the
right
way
to
construct
docker
files.
B
All
right,
so
why
do
you
want
to
go
from
source
to
image?
Well,
kubernetes
runs
images,
so
you
need
to
figure
how
to
get
your
application
source
code
into
an
image.
You
therefore
need
to
be
able
to
build
images,
and
this
is
kind
of
leading
to
what
we're
gonna
talk
about
more
tomorrow
in
the
deep
dive.
But
if
you're
gonna
have
to
build
images,
why
not
do
it
on
the
cluster
you
already
have
to
run
anyway?
Don't
have
a
separate
set
of
infrastructure.
B
Certainly
you
don't
want
developers
just
building
their
images
locally
and
shipping
them
interpret
so
you've
got
a
cluster.
Let's
build
our
images
on
the
scalable
cluster
of
resources
that
we
already
have
and
important
note.
We
have
to
do
that
securely
because
we
don't
want
to
produce
a
exploit
in
our
cluster
when
we
start
building
images
on
the
cluster.
So
just
an
advertisement
for
our
deep-dive
session
tomorrow
today
will
be
less
cluster
focused
and
more
specific
tool
focused.
B
Alright,
so
going
through
some
of
the
approaches
so
we're
starting
with
the
basic
one
that
I
would
imagine
everyone
in
this
room
has
used.
You
are
just
gonna
use.
Traditional
docker
build
you've
got
a
docker
daemon
available.
You
invoke
docker
build
from
a
directory,
that's
got
your
source
code
and
a
docker
file.
The
docker
file
knows
how
to
assemble
your
source
code,
and
then
you
docker
push
that
image
to
somewhere
that
you're,
ultimately
going
to
deploy
on
to
your
cluster.
B
What's
good
about
it,
everybody
who's
doing
stuff
on
kubernetes
probably
knows
how
to
do
this
today,
so
kind
of
a
low
barrier
to
entry.
The
downside
is
to
do
it,
you
need
to
hand
out
docker,
sockets
and
so
either.
That
means
the
developer,
doing
it
on
their
own
machine,
where
they
have
a
docker
socket
or
you
start
handing
out
access
to
the
docker
socket
on
a
shared
cluster,
which
is
a
really
bad
idea.
There's
lots
of
ways
that
people
can
essentially
root
your
host
system
if
you've,
given
them
access
to
the
docker
socket.
B
All
right
so
with
that
table
stakes
out
of
the
way
we
move
on
to
some
of
the
more
sophisticated
techniques
which
we'll
refer
to
as
daemon
list
a
cravat
builds.
So
your
input
artifact
still
a
docker
file,
but
you're,
not
using
the
docker
daemon
to
build
that
image,
you're
going
to
use
a
different
tool
that
will
not
require
a
talker
daemon.
B
B
Didn't
get
a
lot
of
time
to
practice
this
together,
so
yeah,
but
the
other
learner
is
just
constructing
the
image
layers
directly,
which
we'll
get
into
so
what's
good
about
this.
Well,
it's
similar
to
your
docker
build
experience.
So
if
you're
used
to
writing
docker
files,
you're
still
writing
docker
files
still
works.
It
gives
you
a
little
bit
more
control
over
what
image
layers
are
produced,
or
at
least
the
tool
itself
has
more
control.
That
tool
may
expose
that
control
to
you.
B
Right
and
could
could
go
both
ways
on
that,
but
gives
you
gives
you
a
little
more
control
over
that
and
it
also
again.
The
aim
here
is
greater
security
because
you're
not
requiring
the
docker
Daymond,
so
you're
able
to
let
people
do.
These
docker
builds
in
a
more
secure
way.
The
downsides
to
these
approaches
in
general
and
again
we'll
get
into
more
specific
tools,
but
docker
file.
C
That
said,
I
think
the
state
of
things
today
is
significantly
better
than
a
number
of
years
ago
of
trying
to
do
this
since
I
think
a
lot
of
the
sort
of
handling
in
the
daemon
for
how
those
are
parsed
and
whatnot
has
actually
been
factored
in
to
a
more
reasonable
library
than
it
once
was.
So
you
can
actually
leverage
a
lot
of
the
same
facilities
for
parsing
that
and
interpreting
the
file.
Then
you
used
to
be
able
to
do
which
was
pretty
much
rolling
around.
B
And
then
the
other
thing
to
consider
with
this
is
the
also
perk
of
the
different
approaches
to
image
layer,
construction
that
may
be
a
negative
or
some
of
the
tools
that
don't
give
you
control.
They
might
give
you
only
one
fat
layer
and
you
don't
want
only
one
fat
layer
because
you're
not
getting
cash
reuse.
B
So
there's
a
couple
of
tools
that
we
wanted
to
go
through
that
implement
this
daemon
'less
approach.
So
bilder
is
one
that,
based
on
the
run,
C
container,
runtime,
and
so
it
rather
than
using
the
docker
Damon
to
spawn
a
container,
is
able
to
actually
launch
a
container
itself
directly
and
then,
as
I
mentioned
earlier,
it
runs
through
the
docker
file
commands
within
that
container
that
it
launched
to
add
your
source
code,
run
your
run,
commands
and
then
again,
when
it's
done
executing
all
those
commands.
B
C
C
Conoco
is
a
relatively
well
an
even
more
recent
dockerfile
centric,
build
which
it's
I
would
say,
optimized
for
being
run
invoked
by
a
container
orchestration
system
which
sort
of
speaks
to
the
talk
tomorrow,
but
it
expects
to
sort
of
be
executed
in
an
empty
container,
and
then
it
does
an
evaluation
of
the
dockerfile
constructs
and
does
its
own
snapshotting.
Without
you
know,
speaking
to
you,
know,
file
system,
driver
and
publishes
the
image
directly
to
the
registry,
so
it's
effectively
making
0
privileged
syscalls.
C
Aside
from
what
you
may
have
in
your
run
commands,
but
it
expects
to
have
been
bootstrapped
by
a
container
orchestration
system
in
advance.
One
of
the
things
worth
calling
out
here
is
when
this
came
out.
G
Weiser
wasn't
announced
yet,
but
they
are
very
complementary.
So
if
you
haven't
seen
that
or
read
through
that,
yet
I
would
highly
recommend
it.
It's
pretty
cool.
B
B
Who
only
cares
about
source,
but
I've
got
to
produce
this
image,
because
my
boss
told
me
that
we're
deploying
everything
on
kubernetes
and
I
don't
know
what
that
is
either,
but
I'm
gonna
write
my
source
code
and
I
need
to
somehow
get
that
source
code
onto
a
cluster,
so
the
user
is
just
specifying
their
intent
and
their
source
code.
I've
got
a
bunch
of
Java
code
and
I
want
to
run
it
on
a
wild
fly.
Server
I've
got
some
node.js
code.
I
want
a
no
js'
server.
B
Some
of
the
tools
can
also
even
incorporate
detection
into
it.
Italy
scaffold
is
one
that
will
do
some
of
that
as
well
just
detecting
what
sort
of
language
you're
using
and
matching
it
to
the
right
image
to
apply
that
source
code
to
so
you
manages
to
these
dockerfile
approaches.
Are
less
configuration
for
the
developer
again,
they're
really
only
concerned
with
their
source
code
and
maybe
what
framework
they
need
to
be
using
to
build
that
source
code
and
the
tools
can
actually
do
some
of
that
decision-making
about
what
should
be
a
layer
in
the
final
image.
B
So
the
tool
can
say
I'm
going
to
produce
a
layer,
that's
the
application
framework
and
then
maybe
another
layer
for
the
dependencies
for
the
application,
because
I'm
not
expecting
those
to
change
too
often,
and
then
the
top
layer
will
be
the
application
code
that
changes
most
frequently.
And
so
you
get
really
good
reuse
as
you're
iterating.
On
building
that
application.
B
C
Thing
I'll
just
add,
write
like
and,
from
my
perspective,
write
like
this
is
the
goal
right.
I
containers
have
been
really
hyped
over
the
last
few
years
right,
but
ultimately,
they're
I,
I
see
them
as
sort
of
an
infrastructural
implementation
detail,
and
you
shouldn't
have
to
worry
about.
You
know
understanding
how
to
hold
every
single
aspect
of
it
right
in
order
to
use
them
really
well.
C
B
So
another
advantage
to
this
is
because
the
developer
isn't
responsible
for
writing
the
docker
file
and
they're
not
responsible
for
the
base
image
that
their
application
is
going
to
end
up
running
on.
It
means
that
the
organization
can
produce
a
base
image
for
your
java
workloads
or
your
nodejs
workloads
that
codifies
the
best
practices
for
that
image.
So
again,
what
libraries
you
want
in
it?
What
ports
should
the
image
expose?
What
layers
should
it
have?
How
many
layers
should
it
have?
B
C
It
is
actually
a
more
approachable
problem
right.
You
can
actually
decoupling
service
the
the
base,
runtime
independent
of
rebuilding
the
whole
thing,
because
the
build
itself
may
actually
be
expensive
and
you
may
just
want
to
be
able
to
swap
it
in
a
new
version
of
your
base.
Runtime
image,
whatever
that
is
to
pick
up
a
julep,
see
update
or
something
right.
B
So
the
downsides
to
this
are,
it
is
gonna,
be
significantly
less
flexible
again,
depending
on
the
tool
that
you're
picking
to
implement
this
approach.
But
just
as
an
example,
the
s2i
command-line
tool
is
by
design
less
flexible
because
we
were
trying
to
to
some
extent
take
power
away
from
developers,
power
that
we
didn't
want
them
to
have
to
shoot
themselves
in
the
foot,
so
the
at
least
with
default
configurations.
B
B
So
the
ones
that
we
were
going
to
cover
today
in
brief
are
s2i,
which
has
been
around
for
a
number
of
years.
At
this
point,
it
was
sort
of
the
first
thing
that
we
had
Red
Hat
came
up
with
to
try
and
approach
the
problem
of
how
to
enable
developers
to
do
secure,
builds
on
a
multi-tenant
platform
that
we
saw
that
we
were
gonna,
be
building
on
top
of
kubernetes
so
with
source
to
image
the
it's
sort
of
what
I
described
earlier.
B
The
user
provides
their
source
code
that
source
code
gets
built
and
layered
into
an
application
image
based
on
top
of
what
we
refer
to
as
a
builder
image.
So
it's
dependent
on
this
ecosystem
of
builder
images
and
we
supply
a
number
of
them,
but
the
hope
is
for
other
people
to
contribute
their
own
or
within
an
enterprise.
They
may
just
build
their
own
internally,
which
we
see
sometimes
based
on
their
own
language
or
because
they
have
a
specific
version
of
a
framework
that
they
want,
or
they
want
to
bake
specific
dependencies
in.
C
Where
you
know
you,
you
do
a
build
to
produce
an
application
slug
and
then
these
are
then
bound
to
a
base
image
in
order
to
actually
create
a
runnable
container
image,
and
these
are
one
of
the
contexts
in
which,
having
that
contract
for
rebasing
is
actually
kind
of
nice,
and
it's
enabled
by
the
fact
that
they
have
control
over
how
it's
built
and
ultimately
composed
FTL
is
sort
of
a
technique.
That's
used
for
a
number
of
purpose-built
source
to
image
builders
that
are
used.
C
Oh
yeah
FTL
stands
for
faster
than
light,
which
was
sort
of
a
tongue-in-cheek
name
for
the
technique.
Ultimately,
it's
the
the
insight
is
taking
sort
of
looking
at
sort
of
application
dependencies.
In
the
same
way,
build
systems
do
and
projecting
sort
of
the
incrementality
that
gives
build
systems
into
the
layering
of
the
application
image
so
that
you
get
very
incremental,
pushes
and
pulls
of
images.
C
Ultimately,
to
give
you
faster
cycle
times
want,
one
of
the
instances
of
FTL
is
jib
with
some
of
the
folks
for
involved
in
that
are
here
in
the
audience
and
let's
see
the
the
fourth
is
Basel,
which
actually
has
a
lot
of
configuration,
but
a
lot
of
the
ideas
that
went
into
FTL,
which
is
not
Basel,
based
stem
from
work
done
in
Basel
long
ago
to
bring
to
give
Google
the
capacity
to
build,
produce.
Docker
meters
from
our
internal
infrastructure.
C
We're
sort
of
the
the
fundamental
constraint
was
Googlers,
don't
have
privilege
on
our
internal
distributed
build.
So
how
are
we
going
to
produce
docker
images,
since
we
can't
run
a
daemon
so
that
that
was
sort
of
the
origin
of
some
of
that
work
and
that
inspired
a
lot
of
the
sort
of
direct
image
assembly
stuff
that
went
into
stuff
like
FTL.
C
C
B
C
A
A
C
B
B
B
C
And
I
think
that's
I,
think
there's
a
use
for
both
and
I
think
that
we
need
a
better
solution
for
both
I
think
that
ultimately,
I
think
I
see
it
sort
of
partitioning
a
little
bit.
I
think
that,
ultimately
having
the
capacity
to
containerize
applications
is
really
useful,
but
a
lot
of
the
times.
Those
applications
have
sort
of
system
dependencies
that
may
not
be
in
a
base
image
like
I
I
want
to
shell
out
to
get
or
something
so
I
need.
C
You
know
a
package
manager
to
install
something
right
and
so
I
think
you
could
I
think
an
interesting
knob
I've
seen
in
terms
of
sort
of
source
to
image
stuff
is
okay.
Well,
curate
curate
a
base
image
using
a
docker
file
approach,
but
you
can
still
then
could
potentially
consume
that
base
image
with
sort
of
source
to
image,
style
techniques
and
so
I
think
in
practice
having
that
knob,
as
has
felt
like
a
an
interesting.
B
Just
to
follow
up
on
that
because
Matt
sort
of
reminded
me-
and
we
see
this
a
lot
with
s2i,
which
is
we
produce
this
curated
set
of
sty
builder
images,
but
they
don't
necessarily
include
every
library
that
you
might
want
to
use
with
that
framework,
and
you
can't
necessarily
add
those
libraries
with
the
assemble
script
if
they
have
to
go
into
the
system
directory
or
something
like
that
and
yeah.
Our
message
around
that
is
great.
B
It's
a
docker
image
right,
a
docker
file
that
extends
it
and
adds
whatever
else
you
want
one
time
and
then
tell
your
organization
here
is
our
s2i
builder
image
for
this
framework
that
includes
our
internal
libraries
or
these
other
dependencies.
We
even
have
s2i
builder
images
for
databases
where
the
source
you're
injecting
is
your
configuration.
But
again,
if
you
need
to
add
additional
drivers
or
plugins,
then
maybe
you
extend
that
image
with
a
docker
file,
but
you
don't
let
everybody
do
those
docker
file
builds.
B
C
B
C
D
I
was
wondering
if
these
framix
does
have
an
idea
of
limiting
docker
files
or
linking
the
best
practice
that
we
are
using
in
company.
It
means
what
should
be
like:
it's
not
like
OpenScape,
that
you're
using
like
a
wall
or
something
it's
the
idea
to
have
a
linking
of
how
it
should
looks.
Like
I
mean
there
are
source
image,
you
have
source
image,
but
we
have
custom
builders
and
we
have
other
stuff
but
I'm
interesting.
If
we
can
force
it
to
somehow
linked
it.
How
should
be
a
docker
file?
Look
like.
D
C
So
if
you
look
at
what
fkl
style
builders
like
jib
or
the
ones
we
have
for
Python
and
noter,
doing
we're
basically
producing
a
dynamic
set
of
layers
based
on
the
transitive
dependencies
of
an
app,
and
you
can
sort
of
reading
that
and
spitting
out
a
docker
file.
It
would
be
very
challenging
for
you
to
write
sort
of
a
static
docker
file
that
could
produce
that
layering
and
one
of
the
things
that
I
think
I'd
like
to
see
from
some
of
the
demon.
C
Less
docker
file
builders
is,
in
addition
to
supporting
things
like
squashing
layers,
which
can
eliminate
redundant
downloads.
For
you
know,
copied
or
overwritten
files
is
starting
to
embrace
techniques
around
partitioning
that
mega
layer
into
a
set
of
things
that
can
be
uploaded
and
downloaded
in
parallel
and
potentially
give
you
like.
If
you
know
it's
var,
food
doesn't
change
right,
then
the
layer
with
that
won't
need
to
be
reapplied.
It
won't
need
to
be
redownload
it,
and
so
you
can
partition
the
change
in
your
application
and
get
much
faster
cycle
times.
E
D
Wondering
how
we
can
can
we
approach
the
multi
stage
environment?
That
means
we
normally
creating
somewhere
something
there's
JDK
and
in
the
production
area
we
just
run
GRE
or
and
how?
How
is
the
way
it
is
tooling
helped
me
to
have
multi
stage
stuff
I
mean
today,
I
can
do
in
docker.
File
can
do
a
builder
stage
and
and
add
stage
from
the
output.
Can
this
stuff
here
also
be
done.
B
C
C
So,
to
echo
that
rate,
we
have
a
slightly
different
approach
in
google
container
builder,
where
you
basically
have
multiple
steps
in
a
build.
Where
there's
a
shared
workspace,
you
can
use
to
copy
things
between
things,
but
it
both
predate
multistage
docker
files
to
your
point,
though,
right
I
think
this
touches
on
the
you
know,
these
these
source
to
image
builders,
sort
of
enforcing
best
practices,
I,
think
one
of
the
best
practices
is
jdk
czar
for
building
and
JRE
czar
for
running
right.
The
the
most
extreme
example
of
this
is
from
go
lang.
C
Add
my
source
go,
build
and
then
set
the
entry
point
of
the
binary
write
like.
That
is
a
huge
image
that
that's
invoking.
You
know
a
statically
linked.
You
know
couple
mega
executable
and
so
you're
downloading
huge
amounts
of
data.
That's
just
pointless
right,
so
yeah
I
think
that
that's
absolutely
a
best
practice
that,
hopefully
users
don't
have
to
you-
can
use
one
of
these
tools
instead
of
having
to
curate
their
own
multi-stage
docker
file
and
worry
about
how
they
copy
things
in
between
it.
But
but
yeah,
then
they'd
have
to
live
with
the
constraints.