►
Description
Docker images are the deployment artifacts in modern platforms (Kubernetes, Cloud Run, etc). There are a number of ways to create those images from source: 'docker build', the Jib Maven & Gradle plugin, or Cloud Native Buildpacks. This session provides an overview of the different methods and compares them to help you understand which you should use.
Speaker: James Ward
Watch more:
Google Cloud Next ’20: OnAir → https://goo.gle/next2020
Subscribe to the GCP Channel → https://goo.gle/GCP
#GoogleCloudNext
DEV109
product: Cloud Run, Kubernetes Engine; fullname: James Ward;
event: Google Cloud Next 2020; re_ty: Publish; product: Cloud - Serverless Computing - Cloud Run; fullname: James Ward;
A
A
A
So
I'm
going
to
use
port
8080
until
to
map
the
port
in
the
container
8080
to
my
localhost
8080
and
then
we'll
give
it
the
container
to
run,
and
this
is
going
to
be
either
a
docker
hub
container
or
a
url
to
a
container,
I'm
going
to
give
it
the
url
to
gcr.io,
slash
hello,
so
that
is
a
url
that
it'll
pull
the
container
down
from.
So
let's
run
this
and
see
what
happens
now.
I
already
had
the
container
on
my
local
machine,
so
it
didn't
have
to
download
anything.
A
But
you
can
see
it's
actually
started
up
the
container
now,
so
it
uses
virtualization
on
my
machine
to
take
the
contents
of
the
container
and
run
them
and
that's
how
we
get
containers
to
have
a
consistent
running
across
different
platforms
and
operating
systems,
and
all
that,
let's
go
take
a
quick
look
at
this
application
in
my
browser,
so
I
can
just
go
to
localhost
8080
and
there
we
go.
We've
got
now
our
application
up
and
running
okay.
So
we're
able
to
run
that
container
locally
and
that's
great.
A
A
So
I'm
going
to
go
into
cloud
run
on
google
cloud
and
we're
going
to
go,
create
a
new
service
and
we'll
say
we
want
to
run
it
in
the
iowa
region.
We
need
to
give
it
a
name.
So
we'll
just
call
this
one,
hello
containers,
I'm
going
to
allow
unauthentic
unauthenticated
invocations,
and
then
I
need
to
give
it
a
container
image
url.
A
So
you
can
think
of
a
container
as
kind
of
like
a
zip
file
with
some
metadata
about
what
other
layers
it
depends
on,
and
so
we
can
build
up
a
stack
of
layers
to
have
everything
that
we
need
in
our
container
so
that
it
can
run
so
we
can
see
different
layers
here.
You
can
see
those
up
in
the
top
left
and
we
can
see
the
first
layer
was
only
5.6
megabytes,
so
nice
and
small
for
that
one,
and
then
we
can
go
and
browse
the
files
that
are
in
there.
A
A
Then
there's
another
layer
which
looks
like
it's
adding
some
some
server
pieces
to
it
and
we
and
then
there's
an
index.html
that
gets
added
in
a
layer
and
then
some
svgs
some
assets
so
that
the
whole
image
size
the
whole
container
image
size
is
only
17
megabytes
for
this
particular
one.
So
that's
nice
and
small
everything
that's
needed
to
have
a
portable
container
that
can
run
anywhere.
That
runs
containers,
okay,
so
that's
our
basic
intro
to
containers.
A
So
what
we're
going
to
do
is
go
over
to
github.
I
have
a
repo
under
my
github
james
warden,
comparing
docker
methods
and
there's
some
different
branches
that
we're
going
to
be
walking
through
the
first
branch.
We're
going
to
walk
through
is
the
dockerfile
method
and
we'll
open
this
up
in
intellij,
so
that
we
can
explore
it
a
little
better.
I'm
going
to
be
using
a
java,
maven
project
for
our
explorations
here,
but
of
course,
really
anything
can
be
turned
into
a
container
these
days.
A
Okay,
so
for
our
first
method
of
turning
something
into
into
a
container
we're
going
to
use
a
docker
file-
and
this
is
kind
of
the
traditional
standard
for
how
you
take
something
and
turn
it
into
a
container.
Let
me
first
walk
you
through
this
project,
so
you
can
get
an
idea
for
the
layout.
So
this
is
a
maven
project.
A
So
let's
take
a
look
at
how
this
works
for
the
dockerfile
method.
I
have
a
docker
file
and
the
first
part
of
the
docker
file
is
talking
about
how
this
thing
is
going
to
be
built
from
source
code
into
something
that
can
run.
So.
What
I
do
is
I
start
from
another
container
and
I
give
it
a
indicator
as
builder
which
is
going
to
say
this
is
this
is
just
the
builder
part
of
the
package
and
won't
go
into
my
final
container.
A
A
So
I've
got
that
now
in
the
as
builder
part,
but
I
need
to
now
take
that
and
put
it
into
my
final
container.
So
I
do
another
from
and
this
time
I
give
it
the
base
image
that
I'm
going
to
use
for
this.
For
my
my
production
container
image,
and
so
I'm
using
the
open,
jdk
jre
and
then
I'm
copying
from
the
builder
that
jar
file
that
was
created
from
maven,
compile
in
jar
jar
and
then
putting
that
on
server.jar,
and
then
I
tell
it
a
command
to
use
to
when
the
container
starts.
A
A
A
And
then
I'm
going
to
say
colon,
where
I
get
a
chance
to
specify
like
a
version
or
something
like
that
and
in
my
case
I'm
going
to
say
this
is
docker
file
and
then
I
need
to
tell
docker
what
to
actually
build,
and
so
I'm
going
to
say
dot,
and
so
it's
going
to
find
the
docker
file
there.
And
now
what
docker
will
do
is
it'll
go
download
if
it
needs
to
the
different
layers,
the
docker
container
layers,
so
that
it
can
build
this
you'll
see
it's
downloading.
A
Those
from
in
this
case,
docker
hub,
is
where
it's
getting
that
adopt
open,
jdk,
open,
jdk,
11
from
and
now
it's
walking
through
all
the
steps
in
the
docker
file
running
the
maven
build.
So
now,
because
this
is
running
outside
of
my
local
file
system,
it
doesn't
have
access
to
the
maven
local
cache,
so
it's
downloading
all
the
maven
stuff
that
it
needs
and
and
it
it
has
the
jdk
already,
but
it
alright
and
it
needed
to
download
maven
and
then
maven's
dependencies.
A
A
Okay,
so
it's
created
the
jar
file
and
you'll
see
it
says
it's
removing
those
intermediate
containers
because
it
didn't
need
those
any
longer
for
the
final
image
and
then
it's
assembling
the
final
image,
starting
with
the
open,
jdk
11
jre
as
the
base
image
and
then
copying
that
server
jar
file
in
and
then
setting
up
that
command.
Okay,
so
now
we
can,
we
can
actually
run
this
thing.
A
So
what
I
can
do
is
say:
let's
docker
run,
I
do
need
to
map
the
port
like
I
did
before,
let's
map
it
to
your
8080
and
then
I'm
going
to
tell
it
that
container
image
to
run
so,
let's
run
that
thing
and
see
how
it
works
locally.
Let's
go
to
our
localhost
8080
and
great.
Our
hello
world
works
okay,
so
we've
got
this
working
locally
and
and
we've
got
the
container
image.
A
But
now
let's
go
use
that
dive
tool
and
take
a
look
at
what's
actually
in
this
container
and
how
it's
structured
so
diving
in
we'll
see
that
dive
opens
it
up.
We
can
see
the
layers,
we
see
a
base
image
that
is
our
operating
system,
and
then
it's
got
a
few
other
pieces
here
that
are
tweaking
some
things
in
the
operating
system.
A
Now
it's
nice
that
we
have
this
layering
of
our
of
docker
containers,
because
that
makes
the
cache
and
validation
really
great,
because
if
I
create
a
new
version
of
this
container
that
only
changes
that
final
layer
with
a
new
jar
file,
then
it
doesn't
have
to
recreate
and
in
a
lot
of
cases,
doesn't
have
to
pull
down
those
those
layers
that
it
already
has.
So
there's
these
shaw
shot
digests
that
that
make
it
so
that
caching
works
really
well
for
each
layer
that
our
container
is
assembled
from.
A
Okay,
so
really
great
question:
caching
support
with
the
layers
in
docker
okay,
so
that
was
the
first
method
for
creating
a
docker
container
with
a
docker
file.
All
right
now
for
the
second
method
of
building
containers,
we're
going
to
use
something
called
jib.
So
I'm
going
to
go
and
switch
my
branch
and
this
repo
over
to
the
jib
branch
and
we'll
check
that
out
and
now,
let's
go
pull
up
the
palm
file
and
we'll
learn
a
little
bit
about
jib.
A
So
jib
is
a
jvm
based
library
that
can
plug
into
maven
and
gradle
and
creates
container
images.
So
all
we
have
to
do
in
the
case
of
maven
is
add
that
plugin
and
now
we
can
use
jib
so
to
build
our
container.
So
the
source
code
didn't
change.
Nothing
else
changed
you'll,
see
that
I
don't
have
a
docker
file
anymore,
because
we
don't
need
one
because
we're
going
to
use
jib,
and
we
could
do
this
from
maven
or
gradle
and
I
think
there's
other
other
jvm
based
build
plugins
as
well.
A
Okay,
so
to
do
this,
we're
going
to
call
maven
with
a
target
of
jib
docker
build.
So
let's
go
do
that
here,
run
that
so
we're
going
to
first
run
the
compile
then
jib
docker
build
and
we're
going
to
tell
it
the
image
name
that
we
want
to
store,
which
is
comparing
docker
methods:
colon
jib,
okay,
now
jib
is
assembling
our
container
and
it
did
that
super
fast,
because
jib
doesn't
actually
use
the
typical
docker
method
to
create
these
containers.
It
has
its
own
implementation
and
it's
super
fast
and
has
great
caching
support
as
well.
A
A
So
jib
did
a
great
job,
creating
this
this
nice
little
container
for
us
now,
let's,
let's
run
this
thing
and
make
sure
that
everything
works.
I
can
just
go
say:
let's
run
the
jib
one
of
those
and
let's
go
refresh,
make
sure
that
our
container
works
yeah.
It
does
okay.
So
that's
our
container
created
with
jib
one
of
the
nice
things
that
jib
does,
though,
is
you
may
have
seen
it
there?
A
It
adds
a
layer
for
the
dependencies
in
our
application,
so
in
this
case
my
application
doesn't
have
any
dependencies,
it's
just
a
basic
java
application,
but
let's
switch
over
to
the
jib
spring
boot
branch
and
then
we'll
have
some
dependencies.
So
in
the
case
of
spring
boot,
I
have
some
dependencies
in
this
case
just
the
spring
boot
starter
webflux.
A
So
that
is
my
dependency
with
a
whole
bunch
of
other
dependencies
underneath
it
that
I'm
going
to
use
in
here,
and
so,
if
we
go
back
and
run
that
maven
docker
build
again
and
we'll
give
this
a
different
name,
we'll
call
it
spring
jib
dash
spring
boot,
then
it's
going
to
take
the
dependencies
and
copy
those
dependencies
into
a
layer
as
well
and
you'll.
Remember
that
the
caching
in
docker
makes
it
so
that
the
caching
validation
is
really
nice.
So
let's
use
dive
and
go
check
this
thing
out.
A
Okay,
so
looking
at
this,
we'll
see
that
now
there's
this
layer
added
by
jib,
which
is
18,
megs
and
you'll,
see
over
on
the
right
that
this
is
all
the
dependencies
that
come
in
from
my
dependency
on
spring
boot.
So
18
megs
of
dependencies
that
got
pulled
in
for
that
spring
boot,
web
flex,
dependency
and
then
all
the
way
down
to
my
particular
code
that
was
added
on
another
layer.
A
So
if
we
don't
change
our
dependencies,
then
that
layer
doesn't
change
which
is
super
nice
only
when
we
change
the
dependencies
with
that
layer
change
and
only
when
we
change
our
application
code.
Would
this
top
layer
change
so
total
now
216
megs
with
those
dependencies
with
most
of
that
being
the
jvm
okay?
So
that's
the
jib
method
and
that
works
on
any
jvm
based
build.
But
let's
take
a
look
at
yet
another
method,
so
I'm
gonna
go
switch
over
to
the
build
packs
branch.
A
A
So,
let's
give
this
a
try.
I've
already
installed
this
tool
called
pack.
You
can
just
download
it
from
the
build
pack
website,
but
then
you
give
it
the
builder
image
to
use,
which
is
also
a
docker
container,
and
so
this
is
the
build
pack.
So
the
java
build
pack
the
go
build
pack
from
google
cloud,
build
packs,
and
then
we
give
it
the
the
tag
that
we're
going
to
use.
A
So,
let's
run
pack
build
on
this
thing
and
turn
that
source
code
into
a
container
image
and
then
we'll
take
a
look
at
the
container
in
dive.
There's
also
nice.
Caching
in
build
packs.
They
do
a
good
job
of
preserving
stuff
across
builds
and
you'll,
see
that
it
did
this
restoring
phase
so
first,
it
actually
did
a
detecting
phase
and
it
detected
that
hey.
This
is
a
java
application
and
it
knows
how
to
build
java
applications.
So
then
it
restored
from
cache
our
m2
cache,
so
it
didn't
have
to
redownload
stuff.
A
It
did
the
maven
clean
package
and
then
it
exported
the
layers.
Okay.
So
now
we've
got
our.
Let's
see
that
was
build
pack,
let's
go
now
dive
into
that
one.
So
let's
run
this
on
the
build
pack
one
and
let's
try
build
packs.
I
think
that's
what
it
was:
plural,
okay.
So
now
this
is
pulling
that
into
dive,
and
now
we
can
see
the
layers
that
were
created
from
build
packs
for
this
application.
A
We
can
see
a
base
image
which
looks
like
the
operating
system
and
then
some
other
things
on
top
of
that,
and
then
we
get
down
into
this
large
layer,
which
is
probably
the
jvm
layer,
and
then
we
have,
I
think,
a
layer
for
dependencies
and
a
layer
for
our
application,
something
along
those
lines.
So
similarly,
layering
to
what
we
saw
with
the
jvm,
but
you'll
see
that
in
this
case
the
the
base
images
that
it
chose
were
larger
than
the
ones
that
were
chosen
by
jib.
A
You
can
customize
that
if
you
want,
but
the
total
image
size
for
this
one
is
436
megabytes,
but
really
nice
that
we
didn't
have
to
have
anything
in
our
project
that
telled
it
how
to
create
a
container
image
from
our
source
code.
Okay,
and
just
for
the
sake
of
validation.
Let's
go
run.
Our
docker
run,
give
it
the
port
8080
to
8080
and
run
this
thing
and
make
sure
that
our
application
built
with
build
packs,
works
hello,
world
great.
A
Now,
let's
check
out
another
option
which
is
going
to
use
the
dockerfile
option
we
saw
before,
but
in
the
case
of
jvm
projects
can
result
in
really
small
binaries.
So
for
this
one
I'm
going
to
switch
over
to
a
branch
called
grawl
vm
and
for
girl
vm,
the
graph
vm
one.
What
we're
doing
is
we're
using
the
docker
file
because
we're
doing
some
stuff
that
we
can't
do
with
jib
or
with
build
packs.
A
And
then
I'm
going
to
do
my
maven
compile,
create
my
jar
and
now
I'm
going
to
run
the
native
image
tool
and
I'm
going
to
tell
it
some
parameters
here
for
when
it
creates
the
native
image.
I'm
telling
you
to
use
that
mucil
c
bundle
that
I
downloaded
earlier
and
a
few
other
things
static
is
what
does
the
static
binding
of
the
to
the
native
libraries?
A
Okay?
Now,
here's
the
cool
part,
is
that
for
my
final
image,
I'm
saying
from
scratch,
which
gives
me
a
plain
nothing
in
it:
docker
image
and
now
I'm
copying
the
output
of
native
image,
which
is
this
binary
executable
called
web
app
copying
that
into
the
container
and
then
telling
it
to
run
that
web
app
okay.
So
this
is
a
jvm
based
application
that
we're
turning
into
a
native
application
with
no
bindings
to
or
built-in
bindings
to
the
native
native
code.
That's
needed!
A
A
So
all
this
takes
a
little
bit
of
time
and
just
a
recommendation,
no
matter
what
method
you're
using,
I
only
create
my
container
images,
usually
as
part
of
my
cicd
process
when
I'm
developing
locally
for
jvm
applications,
I'm
just
using
the
the
standard
java
run
tooling,
with
a
jvm
installed
locally.
So
I
get
a
really
quick
feedback
cycle
and
I'm
not
not
creating
container
images
as
part
of
my
local
development.
A
Okay,
so
native
image
is
now
running
on
our
jar
files
and
has
has
ahead
of
time
compiled
that
jvm
application
into
a
native
binary,
and
then
it
has
stored
that
into
the
docker
container,
and
now
we
can
run
this
container
and,
let's
make
sure
it
works,
so
let's
say
run
and
then
let's
map
our
port,
okay
run
that
thing.
So
one
of
the
things
that's
really
nice
about
grav,
vm
native
images,
is
that
they
start
up
really
fast
and
usually
use
a
lot
less
memory.
A
So
they
work
great
in
serverless
environments
that
are
benefit
from
that.
Okay
looks
like
everything's
working,
that's
awesome!
Now,
let's
use
our
dive
tool
and
let's
go
explore
our
native
image
that
was
created
here
so
now,
you'll
see,
because
I
did
that
from
scratch.
I
only
have
one
layer
in
my
docker
container
and
that
one
layer
only
contains
that
one
file
web
app
and
it's
11
minutes.
A
A
Okay,
so
that
was
exploring
different
ways
of
creating
docker
containers
and
the
some
of
the
impacts
that
you
have
with
doing
so
now.
Let's
learn
a
little
bit
about
docker
registries.
Docker
registries
are
places
that
we
can
store
these
containers
so
that
they
can
be
easily
accessed
from
different
machines.
A
So
there's
a
number
of
docker
registries
out
there,
one
of
them
the
most
typical
one
that
people
use
is
just
docker
hub,
so
docker
hub
is
hub.docker.com
and
you
can
sign
up
for
an
account
and
store
your
containers
up
on
docker
hub
and
a
lot
of
the
containers
that
we're
using
as
space
images.
That's
where
they
come
from
now
for
your
projects
on
google
cloud,
there's
two
other
places
where
you
can
store
your
docker
containers.
A
So
let's
go
over
into
the
cloud
console
and
check
those
out
so
there's
the
container
registry
is
the
traditional
place
to
store
containers.
So
you
can
see
I've
got
a
bunch
of
containers
stored
up
on
the
google
container
registry
and
you'll
you'll.
Remember
from
when
we
did
like
the
build
pack
sample
that
the
build
packs
are
stored
up
there
as
well.
The
cloud
run
hello
world
is
stored
up
there
on
the
google
container
registry,
there's
another
place
on
google
cloud,
which
is
newer,
and
this
is
called
the
artifact
registry.
A
The
artifact
registry
is
cool
because
it
supports
not
just
docker
containers,
but
you
can
also
store
maven
artifacts
npm
artifacts,
that
kind
of
stuff
up
there
as
well,
so
not
just
docker
containers.
So
you
can
check
that
out
currently
in
beta
okay.
So
let's
go
back
to
the
container
registry
and
let's
go
store,
create
a
container
that
will
store
up
on
the
google
container
registry.
So
I'm
going
to
switch
over
to
the
let's
go
to
the
jib
branch.
A
Here
and
use
that
one
okay,
let's
go
now
back
to
our
command,
where
we're
gonna,
create
our
container
image
all
right.
So
let's
copy
that
command
that
we
used
before
and
paste
it
in
here
and
then,
instead
of
saying,
jib
docker
build
I'm
going
to
say,
jib
build
and
then
I'm
going
to
give
it
the
coordinates
to
the
google
container
registry.
A
So
I'm
going
to
say,
gcr.io
and
then
my
project
id
on
google
cloud,
so
it's
jw
demo
and
then
my
artifact
name,
okay,
let's
try
to
run
this
and
what
it
should
do
is
create
that
container
image
and
store
it
up
on
the
google
container
registry
so
looks
like
it's
pushing
those
layers
up
to
the
google
container
registry
and
in
this
case
it
didn't
need
the
local
docker
daemon,
because
it
didn't
actually
store
that
on
the
local
docker
daemon.
Okay.
A
A
Let's
go
and
and
walk
through
one
other
quick
step
for
this,
which
is
deploying
this
on
cloud
run
which
you've
seen
already.
But
I
want
to
show
you
what
it
looks
like
if
we
were
to
do
it
from
that
menu.
So,
just
like
we
saw
before
we
can
create
a
service,
we
can
give
it
the
service
name.
We
can
tell
it
yes,
an
authentic
unauthenticated
request,
the
container
image
url
and
then
let's
hit
create
okay.
A
So
now
it's
creating
that
service
from
that
source
code
and
deploying
the
new
revision,
and
that
will
be
up
and
running
in
just
a
second
okay
great.
So
it's
up
and
running
and
there
it
is
hello
world
running
up
on
the
cloud.
So
there's,
if
you
do
want
to
play
around
with
this
stuff,
there's
a
really
easy
way
to
do
that,
which
is,
if
you
go
to
my
comparing
docker
methods,
repo
and
then
you
can
pick
any
of
these
different
different
methods
via
different
branches.
A
So
it's
cloned
that
git
repo
and
checked
out
the
branch
that
we
were
on
and
then
it's
asking
me
which
project
I
want
to
use.
I'm
saying
jw
demo:
where
do
I
want
to
deploy
us
central
one
is
the
region
and
now
what
it'll
do
is
run
that
maven
jib
task
on
this
repo?
So
that's
now
running
and
creating
our
container
image
using
jib.
Storing
that
container
image
up
on
the
google
container
registry,
so
there
you
go,
you
see
that
it's
doing
that
maven
package,
you
build
giving
it
the
image
parameter.
A
So
just
like
we
did
from
the
command
line,
but
this
is
doing
it
all
for
you.
So
you
don't
have
to
remember
all
the
steps,
just
click
that
button
and
you
can
do
it
on
any
of
those
branches
within
that
repo
and
that'll
help
you
get
started
so
now.
It's
doing
the
g-cloud
run
deployed
deploying
that
container
image
up
on
the
cloud,
and
then
we
should
see
this
thing
deployed
and
up
and
running
here
in
just
a
second.
A
A
We
can
open
it
up
and
see
once
again
our
lovely
hello
world,
okay,
so
that
is
that
is
the
comparing
docker
methods
with
files
jib
and
build
packs,
and
then
also
some
graw
vm
thrown
in
there
for
native
images
with
the
jvm
all
right.
That
was
comparing
docker
methods,
and
I
hope
that
was
useful
for
you.
I
really
appreciate
you
watching
hope
you
got
a
lot
of
it.