►
From YouTube: Building Docker Images Without Docker - Matt Rickard, Google (Intermediate Skill Level)
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)
Building Docker Images without Docker - Matt Rickard, Google (Intermediate Skill Level)
Why would you want to build docker images without docker? You might want reproducible, minimal, or unprivileged builds. This talk will cover the alternative tools that exist to build docker images without docker. It will cover building images with tools like BuildKit, distroless, and buildah. It will compare the benefits and trade-offs of each tool as well as general patterns and anti-patterns to follow when building your images. Additionally, it will cover tools to manipulate and inspect those images.
About Matt
Matt Rickard is a Software Engineer at Google. He works on Kubernetes developer experience and container tooling products at Google, with a focus on local development and CI/CD tooling. He is a maintainer of many open source repositories, including kubernetes/minikube, GoogleCloudPlatform/container-diff, and GoogleCloudPlatform/distroless.
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
A
What
did
we
try
to
do?
There
have
been
I
mean
this
talk
became
a
lot
easier
in
the
last
few
months
because
there
have
been
a
lot
of
products
that
have
come
out
addressing
this
this.
This
problem
and
a
lot
of
them
have
kind
of
similar
approaches,
but
I'm
going
to
break
it
down
into
kind
of
three
three
major
approaches
that
I
saw.
A
What
problems
did
we
run
into?
Basically,
what
worked,
what
didn't
and
then
kind
of
what
we
can
do
about
that
and
and
what
we
should
be
thinking
about
for
the
feature
cool.
So
just
a
little
background
on
me,
I'm,
a
software
engineer
at
Google,
San,
Francisco
and
I
work
pretty
exclusively
on
open
source
software,
so
anything
container
related.
You
know
more
recently,
the
communities
developer
experience
so
I'm,
a
maintainer
of
mini
cube
and
a
lot
of
the
tools
and
the
Google
container
tools,
organization,
which
is
which
is
fairly
new.
A
So
that's
scaffold,
distro
list
which
I'll
be
talking
about
today,
can
echo
which
also
be
talking
about
today
and
container
diff,
among
others,
shameless
plug,
we're
hiring.
So
if
you're
interested
just
email
me
or
talk
to
me
after
so
why
do
we
care
the
biggest
one
is
kind
of
the
the
separation
of
concerns.
So
the
idea
is
that
we
started
with
docker.
We
had
this
huge
monolith.
We
had
the
daemon
we
had
docker
run.
We
had
docker
build,
which
was
great.
A
Is
that
matures
security
I
won't
talk
too
much
about
security
in
this
talk,
because
that's
it's
kind
of
a
runtime
issue,
but
you
can
see
that
you
know
the
the
division
is
not
exactly
clear,
but
it's
worth
mentioning
reusing
and
kind
of
consolidating
infrastructure.
So
it's
a
bit
civility
that
we
have
some
infrastructure
to
build
the
artifacts,
and
then
we
have
different
infrastructure
to
run
the
artifacts,
and
the
idea
is
that
we
should
really
be
able
to
reuse
the
clusters
that
we
run
things
to
build
things
reproducibility.
So
this
is
kind
of
from
two
angles.
A
It's
you
know
the
reproducibility,
that's
not
in
your
docker
file
because
of
the
run
command,
but
also
reproducibility
in
terms
of
the
actual
image
metadata,
so
timestamps
and
and
configs,
and
all
that
sort
of
stuff,
minimal
images.
The
idea
behind
this
is
that
you
really
want
kind
of
your
runtime
dependencies
in
your
application
and
have
that
be
the
only
thing
in
your
application
and
your
in
your
docker
image.
Unfortunately,
it's
hard
to
produce
those
images,
and
once
you
have
them,
there's
not
really
the
right
tools
to
kind
of
debug
and
figure
out.
A
What's
what's
going
wrong
and
then
this
this
last
part
is
it's
kind
of
related
to
minimal
images,
but
control
over
your
images,
basically
constructing
your
layers
in
a
smart
way,
and
you
know
the
contents
inside
of
it
so
separation
of
concerns.
So
this
is
just
kind
of
a
you
know.
Very
basic
Venn
diagram
actually
had
a
lot
of
trouble,
making
a
Venn
diagram
in
PowerPoint
I.
You
know
it's
very
confusing,
but
so
there's
build,
there's
push,
pull
and
there's
run.
Docker
is
obviously
kind
of
at
the
intersection
of
all
these
things.
A
It
does
everything
it's
a
demon.
That's
always
running
so
always
doing
all
this
stuff,
we've
seen
kind
of
cryo,
be
the
intersection
of
run
and
pull
pull
kind
of
being
the
idea
that
it
needs
to
pull
the
base
image
and
kind
of
the
build
context
before
it
runs
it,
and
what
I'll
be
talking
about
mainly
in
this
talk
is
the
the
intersection
between
build
and
push
and
pull,
and
a
lot
of
these
tools.
Kind
of
explicitly
call
this.
A
This
division
out,
which
I
think
is
great
I,
think
that's
what
we
should
be
aiming
for
and
I
think
that's
a
that's
a
great
division
in
an
ideal
world.
You
know,
maybe
we
could
even
split
out
the
push
pull
from
the
build
and
have
your
build,
not
responsible
for
kind
of
setting
up
the
build
context
pulling
the
build
are
pulling
the
the
kind
of
the
context
for
the
build
and
then
also
not
responsible
for
pushing
that
artifact
so
that
you
build,
doesn't
really
know
anything
about
authentication.
But
that's
that's
an
ideal
way.
A
So
another
thing
I'd
like
to
talk
about
in
this
talk
and
I'll
kind
of
call
it
out
and
some
of
the
tools
is
that
there's
kind
of
an
implicit
dependency
between
build
and
run,
even
though
I've
divided
them
here.
When
you
have
the
run
instruction,
it's
actually
pretty
much
the
same.
As
you
know
a
docker
run.
So
the
idea
is
that
we
should
we
should
think
hard
about.
Do
we
need
this?
A
Coupling
we've
had
a
lot
of
the
kind
of
flexibility
of
docker
run,
so
we
were
a
little
bit
spoiled
in
that
sense,
but
actually
you
know
making
that
that
a
clear
division
between
build
and
run
I
think
will
be
really
important
and
we'll
actually
see
that
more.
So
as
we
try
to
run,
these
builds
in
a
run
times
such
as
like
kubernetes,
or
something
like
that.
A
So
the
the
first
kind
of
category
I
want
you
to
think
about
when
I
talk
about
these
tools
is,
is
docker
file
list,
so
does
a
tool
support
building
from
a
docker
file
or
doesn't
it?
You
know
in
images
worth
a
thousand
words
in
this
case.
Most
of
them
are
apt-get
update
and
apt-get
install.
Why
no
install
recommends
you
know
this
is
just
from
the
Postgres
image
docker
hub.
A
You
know
this
is
boilerplate
that
probably
all
of
us
in
this
room
have
written
and
kind
of
moving
away
from
that
model,
but
at
the
same
time
we
already
have
all
these
docker
files.
We
need
ways
to
kind
of
continue
building
those
images,
so
the
other
kind
of
dimension
that
we
should
be
thinking
about
as
I
kind
of
go
over.
These
tools
is,
does
it
have
a
demon
or
does
it
not
have
a
demon,
I?
Think
kind
of
the
I
think
everyone
would
agree
that
not
having
a
demon
for
build
is
a
good
thing.
A
You
know
its
performance,
it's
easier
to
run
and
kind
of
see,
ICD
pipelines,
it's
easier
to
run
in
kind
of
containerized
environments,
it's
a
great
step
towards
kind
of
decoupling
and
the
ones
that
I'll
talk
about
our
build
image
and
in
Kanak,
oh
so
this
is.
This
is
kind
of
an
overview
of
bilder
if
you
haven't
heard
of
it.
It's
basically
this
this
tool
to
kind
of
build
docker
images
with
no
docker
daemon,
so
it
was
kind
of
like
that.
A
One
of
the
first
tools
that
that
really
took
this
paradigm
of
no
daemon
and
really
pushed
it.
It
can
build
from
a
docker
file.
It
can
also
build
through
kind
of
a
series
of
these
imperative
commands,
which
the
CLI
actually
looks
a
lot
like
the
docker
file,
instructions,
which
is
quite
interesting,
so
you
have
build
that
add,
build
a
copy.
Those
are
from
builder
run
and
then
some
other
ones.
A
The
interesting
thing
here
is
that
they've
taken
kind
of
an
imperative
approach
versus
kind
of
the
you
know,
declarative
configuration
paradigm
of
kubernetes
and
and
all
those
other
tools
well
I-
think
it's
probably
a
lot
better
than
the
docker
file.
I
think
they
kind
of
envisioned
this
to
be
used,
as
is
some
sort
of
foundation
for
other
tool
to
both
to
be
built
on
top
of
it
to
support
kind
of
alternative
front
ends.
But
it's
interesting
that
it's
imperative,
especially
in
this
world.
A
Another
tool,
that's
kind
of
demon
list
is
which
is
a
really
interesting
tool.
I
actually
took
the
first
two
bullet
points
from
the
readme
because
it
was
so
spot-on.
The
first
thing
that
commands
you
X
are
the
same
as
docker
build
push,
pull
and
login,
and
so,
if
you
think
about
that
kind
of
Venn
diagram,
this
is
exactly
kind
of
where
we
want
to
target
and
I.
A
A
So
the
the
idea
behind
this
is
that
it
doesn't
actually
have
any
runtime.
It's
not
calling
run
C.
It's
not
calling
any
of
that
sort
of
stuff.
It's
kind
of
deferring
to
whatever
environment
you're
running
in
it
in
and
the
idea
behind.
This
is
that
you
know
they're
more
portable,
there's
no
dependency
and
actual
runtime
dependencies.
So
historically
that's
been.
You
know:
Linux
namespaces
and
C
groups.
A
Of
course
not
every
runtime
actually
uses
those,
but
it's
it's
interesting
that
your
build
tool
shouldn't
really
need
your
runtime
dependencies
and
so
that
you
can
run
your
builds
cross-platform
or
in
a
lots
of
different
infrastructure.
Of
course,
there's
less
complexity.
You
know,
there's
no
kind
of
nested
containers,
there's
no
nested
overlay
FS.
We
know
how
that
goes
and
it's
it's
a
lot
easier
to
nest.
Inside
of
existing
containerized
environments,
the
analogy
and
maybe
looking
for
is
kind
of.
You
know
nested
VMs
right
you
can.
A
You
can
do
them
under
the
kind
of
the
right
constraints,
but
they're
slower
and
they're
much
more
complex.
So
the
first
one
I'm
going
to
talk
about
in
this
kind
of
run.
Timeless
category
is
distro
s.
So
a
full
disclaimer
I
worked
on
this
a
little
bit
so
I'll
try
to
be
unbiased.
It's
it's
a
little
different
in
that
there's,
there's
no
docker
file.
It
can
interpret
a
docker
file.
It's
built
on
these
kind
of
rules,
docker,
which
are
Basel
rules
to
build
a
docker
loadable
compatible
tarball.
A
It's
really
great,
for
you,
know,
constructing
your
images
and
kind
of
reproducible,
ways,
there's
a
lot
that
kind
of
comes
from
this:
it's
rebei
scible.
So
the
idea
is
that
if
you,
if
you
patch
a
security
vulnerability
or
something
like
that,
you
can
do
that
and
rebuild
the
image
without
actually
rebuilding
your
application
and
you're,
not
kind
of
stuck
with
that
weird.
You
know
layering
in
the
docker
file,
where
you
can
only
cache
the
things
before
the
instruction
that
changes
and
it
creates
these
kind
of
minimal
images.
A
The
idea
behind
the
name
distro
s
was
that
there
were
images
that
weren't
based
off
of
Ubuntu
or
Debian,
or
anything
like
that,
and
you
know
it
I
mean
you
really
think
about
it.
When
you
know,
should
you
really
be
deploying
you
know
thousands
of
Ubuntu
Ubuntu
based
images?
Do
you
really
need
that
kind
of
full
operating
system?
Is
that
your
applications
runtime
dependencies?
The
answer,
usually
99%
of
the
time,
is
No.
A
So
really
the
the
benefit
of
this
is
that
you
have
nothing
but
your
your
application
in
your
runtime
dependencies
in
your
image.
The
the
downside
to
that
is.
You
have
nothing
but
your
application
and
your
runtime
dependencies
in
your
image.
You
know
you,
you
don't
really
realize
that
that
means
no
shell.
That
means
no
package
manager.
None
of
the
nice
things
that
kind
of
help
you
debug.
A
So
this
is
just
just
a
snapshot
of
what
what
this
looks.
Like
you
know.
These
are.
These
are
Basel
rules.
We
have
a
way
of
kind
of
injecting
packages
because
it
turns
out
that
you
really
do
need
to
inject
packages
into
your
application.
You
don't
need
the
package
manager,
but
you
do
need
the
packages.
So
it's
it's
kind
of
an
interesting
problem,
but
the
kind
of
takeaway
from
this
was
that
you
don't
necessarily
need
the
runtime
another
tool
that
our
team
kind
of
recently
opened
source
is
Kanak.
A
A
It
interprets
docker
files,
so
we've
kind
of
reimplemented.
All
of
the
docker
file
instructions
run
em
from
all
that
sort
of
stuff
and
it
runs
kind
of
completely
in
user
space.
So
the
kind
of
two
main
things
that
need
to
run
in
user
space
are
the
actual
snapshotting,
so
we
actually
create
the
layers
after
things
I
ran,
so
it
works
kind
of
naively.
A
There
is
no
runtime
and
there's
no
nested
containers.
So
there's
no
complexity
there.
On
the
flip
side,
you
don't
get
any
of
the
security
of
nested
containers.
So
if
you're
running
something
like
image-
and
you
don't
trust
your
kind
of
parent
runtime-
you
can
get
around
that
by
running
run
C
and
route
list
mode.
The
the
idea
behind
this
is
I,
don't
know
if
you
guys
get
a
chance
to
see.
We
just
put
out
a
blog
post
about
G
visor,
which
is
our
kind
of
sandbox
container
runtime.
A
So
we
actually
do
treat
that
as
a
security,
boundary
runtime,
so
using
something
like
that
in
your
kubernetes
cluster
plus
canna
co+
kubernetes
equals
kind
of
secure
on
cluster
builds
so
that
you
can
do
builds
on
cluster
in
a
multi-tenant
way,
which
is
really
interesting,
so
I
think
in
the
future.
We'll
will
see
a
lot
of
what
we'll
see
more
kind
of
trusted,
runtimes
and
and
not
a
lot
of
this.
This
nested
complexity
for
the
builders,
the
the
last
kind
of
category
I
want
to
talk
about.
A
So,
basically,
all
these
tools
use
one
of
three
libraries
there's
two
that
we
published:
Google
container
registry
and
Google
go
container
registry
container
registries,
written
Python
and
it's
the
basis
of
the
kind
of
dish,
Gois
tool
that
I
talked
about
ago
container
registries
fairly
new.
But
it's
basically
the
go
port
of
that
library
and
then,
of
course,
there's
containers
image
which
build
a
and
image
and
some
of
those
other
tools
use
and
the
idea
behind
this
is
that
we
can
construct
and
kind
of
manipulate
images
programmatically.
A
So
that
becomes
really
important.
You
know
just
kind
of
four
basic
registry
interactions,
so
you
need
to
do
something
like
retag
an
image.
You
need
to
do
something
like
mutating
image.
It's
really
useful
for
that
and
kind
of.
More
importantly,
it
can
serve
as
the
basis
for
kind
of
alternative
front
ends
as
we
start
to
explore.
You
know,
what's
next,
after
the
dockerfile,
so
just
an
overview
of
this
go
container
registry.
A
We
use
it
in
kind
of
all
of
our
google
container
tools,
so
container
diff
scaffold
we
just
switched
mini
cube
to
use
it
can't
go
and
distress,
and
you
can
see
these
are
just
kind
of
the
diffs
of
when
we
removed
all
the
boilerplate
and
replace
it
with
this
library.
So
it's
a
pretty
significant.
You
know
cognitive
load
taken
off
by
switching
to
this
library.
It
can
build
images
from
scratch
and
it
can
mutate
images.
So
a
lot
of
a
lot
of
activities
that
seemed
kind
of
impossible
before
become
really
easy.
A
So
I
guess
that
was
just
like
a
quick
overview
of
I
mean
there's
like
so
many
tools
that
I
didn't
cover,
mostly
because
either
I'm
not
familiar
with
them
or
you
know
we
wouldn't
have
had
time
but
kind
of.
What's
what's
next
in
this
space,
and
and
you
know
what
I'm
thinking
about
and
and
what
I
hope,
some
of
you
will
think
about
reproducibility.
A
So
it's
possible.
It's
not
so
possible
with
you
know
arbitrary
docker
files,
so
we
might
need
to
think
of
something
there,
but
at
least
we
can
kind
of
make
the
the
metadata
reproducible
decoupling
bills
from
push-pull.
You
know
this
is
a
in
a
very
ideal
world
I
think
we
can
start
to
build
our
tools.
With
this
in
mind.
A
A
If
we're
sticking
with
this
these
kind
of
paradigms,
we
really
need
to
start
thinking
about
what
optimizations
we
can
make
for
languages
and
frameworks,
because
we
can
make
some
pretty
significant
optimizations
new
front
ends,
so
things
other
than
the
dockerfile
build
kit
by
docker
has
really
been
thinking
about
this
and
kind
of
abstracts
away
a
lot
of
the
dag
and
the
caching
complexity.
So
tools
like
image
use,
build
kit
kind
of
under
the
hood
to
not
have
to
re-implement
all
of
that,
but
they're
kind
of
actively
thinking
about.
A
What's
next,
after
the
docker
file,
flexible
builds
without
a
runtime.
You
know
again,
we've
been
spoiled
with
the
run
command.
How
do
we
get
away
from
that
and
into
more
declarative
and
reproducible
builds
while
still
having
the
kind
of
flexibility
of
being
able
to
install
things
from
commands?
And
then
the
last
point,
I
think
is
actually
kind
of
interesting.
We've
already
carved
out
what
the
interface
for
the
runtime
looks
like
so
cry
is
to
run,
as
you
know,
is
there
an
equivalent
for
build?
A
Is
there
you
know
some
sort
of
build
interface,
though
that
we
can
build
and
work
with
the
kind
of
abstract
away
the
API
for
these
tools?
And
you
know,
I
I,
don't
know
what
the
answer
is.
There's
been
some
work
done
to
kind
of
carve
out
what
this
looks
like,
but
there's
a
lot
to
be
done
so
I
guess
what
would
what
would
some
dockerfile
alternatives?
Look
like
so
a
container
native
package
manager
right,
you
know
the
the
beauty
of
you
know.
The
docker
file
and
containers
is
that
we
can
reuse
the
Linux
package
managers.
A
We
didn't
need
to
kind
of
remake
that
part.
On
the
flip
side.
Those
package
managers
aren't
reproducible
when
you
do
an
app
get
upgrade
and
an
app
get
install
you're
kind
of
at
the
mercy
of
when
you
running
that,
because
those
packages
are,
you
know,
guaranteed
to
change
over
time
so
figuring
out.
You
know,
there's
been
some
work
done
in
kind
of
the
Nix
OS
space
and
the
Nix
package
manager
for
kind
of
reproducible
and
declarative
package
configuration,
but
I
think
you
know
some
people
have
tried
to
pour
some
of
those
ideas
to
containers.
A
A
You
know,
we've
we've
been
able
to
craft
our
images
in
such
kind
of
a
flexible
way
in
an
expressive
way
that
it's
hard
to
kind
of
pull
back
from
that
and
convert
some
of
our
builds
to
more
declarative
and
more
reproducible,
but
I
think
we
we
do
need
to
do
that
and
then
kind
of
the
last
one
is
just
smarter
construction
of
layers
and
base
images.
You
know
layers
are
what
we're
given
you
know
it's
in
the
spec
you
know.
Could
we
have
gone
more
granular
than
that?
Possibly,
but
that's
what
we're
given!
A
A
I,
don't
think
when,
when
we're
writing
a
docker
file,
you
know
maybe
we're
thinking
of
you
know
instruction
is
a
layer
but
I,
don't
think
we're
going
the
extra
mile
to
actually
make
sure
that
we're
we're
doing
this
in
kind
of
a
composable
way
and
minimizing
the
amount
of
base
images
that
were
maintaining
or
the
layers
that
were
maintaining
so
I
just
want
to
talk
a
little
bit
about
some
ideas
of
language,
specific
workflows
that
exist
out
there
and
what
what
has
worked
really
well.
So
the
idea
is
that
we
can.
A
We
can
really
optimize
for
frameworks
and
languages
without
getting
rid
of
the
dockerfile
without
getting
rid
of
any
of
this
this
stuff,
and
we
can
do
it
kind
of
today.
You
know
there's
some
ideas
behind
build
packs
of
we
have.
These
kind
of
you
know
language,
specific
containers
that
we
can
just
kind
of
take
your
source
code
and
pop
it
in
there,
and
then
we
can
run
that
you
know.
That's
that's
something
kind
of
like
the
Heroku
past
model,
I.
Think
there's,
there's.
A
Definitely
a
lot
of
analogies
with
containers
they're,
one
tool
that
we've
open-sourced
is
jib,
so
jib
is
kind
of
it's
a
job,
a
specific
tool
and
it
really
fits
into
your
job.
A
workflow
can
kind
of
be
called
from
your
your
your
Java
native
tooling
maven
in
Gradle,
and
it
does
like
really
smart
layering
of
your
image
so
that
you
can
just
take
your
jar
files,
put
them
in
the
container
and
then
deploy
them.
A
So
you
get
those
really
fast
kind
of
building
deploy
loops
and
by
default
that
use
the
the
distro
as
images,
but
there's
ways
to
kind
of
configure
that
another
tool
that
are
kind
of
paradigm
that
that
we've
been
working
on
is
faster
than
light
bulbs.
So
this
work
lives
in
the
the
runtimes
common
github
repository
by
the
way.
A
All
this
stuff
is
is
on
github
I,
just
left
out
the
github
portion,
but
you
should
be
able
to
find
all
of
them
and
in
the
right
paths,
and
the
idea
behind
this
is
that
it
treats
language
level
packages
as
layers,
so
that
becomes
really
important
when
you're
doing
caching,
it
really
speeds
up
your
builds
at
speeds
up
to
your
deploys,
and
so
we
can
do
that
for
languages
like
PHP.
We
can
do
it
for
languages
like
nodejs
and
there's
there's
some
other
languages
that
we
can
make
optimizations
by
kind
of
introspecting.