►
From YouTube: Bogor Meetup #1: Container with Cloud Native Buildpacks & Container Image Operation with Skopeo
Description
========================================================
Talk #1: Code to a Production-Ready Container with Cloud Native Buildpacks (CNB)
Speaker: Srinivasa Vasu (Field Solution Engineer at VMware)
Srinivasa Vasu is an Open source enthusiast and contributor interested in all stuff java, spring, travel, photography, and Kubernetes.
Building a secure production-grade container is complicated, operationally intensive, and time-consuming. As developers, a lot of their productive time and effort are spent on learning about the nuances of creating a production-grade container image using Dockerfile. Cloud Native Buildpacks is an open-source and CNCF incubated project & specification that addresses these challenges and simplifies the creation of standard OCI conformant images from source code. Developers can go from committed code to a runnable artifact in no time and operators are relieved of the burden of maintaining the provenance of various layers of the stack. Like any other spec, there are a few reference implementations. One such implementation is paketo-buildpacks which is a community-driven CF project. We shall explore CNB, paketo-buildpacks, and a Kubernetes native kpack in this talk.
Talk #2: Simplify Remote Container Image Operation with Skopeo
Speaker: Muhammad Aushafy Setyawan (Solutions Engineer at PT Infracom Technology)
Aushafy talk will be about how Skopeo can simplify the remote container image operation.
========================================================
Hosted By
Kubernetes & Cloud Native Indonesia, Community Leaders
https://t.me/kubernetesindonesia
A
B
C
C
C
C
A
A
D
E
E
Right
good
evening,
everyone,
I
hope
everyone
is
staying,
safe
and
healthy.
First
of
all
really
appreciate
the
passion
and
the
energy
that
the
community
members
and
the
organizers
carry
in
successfully
running
this
event.
Every
month
you
guys
are
doing
a
tremendous
job,
keep
up
the
good
work
kudos
to
the
entire
team,
happy
to
be
back
for
the
second
time
again,
I
did
a
talk
on
cluster
apis
a
couple
of
months
ago,
good
to
be
back
again.
E
My
name
is
pinima
savasu,
I'm
a
solution
engineer
with
vmware,
and
today's
talk
is
on
cloud
native
buildbacks.
So
before
we
get
started,
please
keep
your
questions
coming
in
the
chat
window,
I've
got
30
to
35
minutes
if
time
permits
I'll
try
to
go
through
your
questions
online.
If
not
I'll
answer
as
much
as
I
can,
via
the
chat
chat
channel
right
again,
congratulations
to
cloud
cnb
cloud
native
buildbacks
contributors
on
the
community
team.
E
It's
a
cncf
incubated
project
now
so
it
graduated
from
sandbox
to
incubation
that
got
announced
in
the
recently
concluded
cloud
native
and
kubecon
event.
So,
let's
dive
into
the
session.
What's
what's
cloud
native
buildbacks?
It
transforms
your
application
source
code
into
a
runnable
artifacts
right,
so
the
craft
of
producing
a
runnable
artifact
from
a
source
code
isn't
nothing
new
right.
So
buildback
as
a
technology
has
been
existence
for
quite
a
number
of
years.
E
Now,
heroku
invented
it
way
back
in
2011
and
then
cloud
foundry
community
adapted
it,
and
then
they
took
it
to
a
lot
of
enterprises
right
so
back,
then
there
was
no
peer
specification
around
this
buildback.
What
happened
was
eroku
ended
up
having
their
own
implementation
of
buildback,
and
so
is
cloud
foundry
as
well.
The
build
the
the
buildback
as
a
technology
was
tightly
coupled
to
the
underlying
platform.
E
It
was
impossible
because
it
was
tightly
designed
for
the
underlying
platform
fast
forward
to
2018,
with
the
emergence
and
the
maturity
of
container
technology
space
and
and
associated
to
tool
sets
have
been
enabled
folks
from
heroku
and
pivotal
to
come
together
to
bring
the
best
of
both
worlds
to
a
new
unified
convergence
spec.
If
I,
if
I
had
to
put
it
that
way,
the
version
three
specification
of
build
packs
called
cloud
native
packs
right.
So
what
does
it
do?
Let's
dissect,
I
mean,
as
we
move
on.
E
Let's
try
to
understand
what
is
this
initiative
all
about?
What
does
it
do
and
how
it's
helping
developers
and
operations
of
the
of
the
industry
right?
What
problem
does
cnb
solve
today?
We
understand
that
the
application
architectures
are
changing.
We
are
moving
away
from
monolithic
based
architecture,
to
a
microservices-based
architecture,
mainly
to
solve
the
people
and
team
scalability
problem
more
than
a
technology
problem.
E
So
what
we
have
started
started
to
see
is
more
about
the
destiny
of
these
services
is
controlled
by
the
team
that
builds
it.
So
it's
it
goes
with
the
notion
of
you
build
it
and
you
own
it
right.
What
used
to
be
a
single
monolithic
based
application?
It's
been
broken
down
into
multiple
services,
and
since
each
these
teams
are
owning
these
services,
they
have
the
luxuriant
flexibility
in
terms
of
picking
the
right
language
on
time.
E
Picking
the
right
set
of
frameworks
that
address
the
given
set
of
business
requirements
right
so
so
a
single
service
has
been
broken
down
into
multiple
different
services
being
built
using
different
languages
and
different
frameworks.
Now
the
next
obvious
question
is:
how
can
we
package
and
distribute
these
apps
right
packaging?
A
single
application
itself
is
not
an
easy
thing.
We
have
to
look
after
so
many
things
now.
E
The
same
thing
is
being
kind
of
extrapolated
into
multiple
folds
in
terms
of
the
number
of
languages
and
frameworks
that
you
deal
with
and
containers
have
become
the
de
facto
standard
packaging
format.
So
the
obvious
choice
is
to
go
with.
Containers
start
writing
your
own
docker
file
right.
So
this
is
something
that
we've
got.
Every
developer
would
have
seen
it
in
the
past,
or
every
developer
would
have
tried
it
themselves
at
some
point
of
time.
Writing
their
own
version
of
docker
files,
so
docker
files
are
great.
It
gives
you
a
lot
of
flexibility.
E
It's
it's
it's
a
kind
of
double-edged
sword
right,
so
you
would
be
able
to
do
a
lot
of
things
with
docker
files,
but
at
the
same
time
as
developers
running
a
production
grid
secured
and
docker
files
are
not
really
easy
right.
So
it's
very,
very
complex.
It's
complicated
time
consuming
and
it's
operationally
very
intensive
as
well,
and
then,
as
you
know,
I
mean
so.
E
As
you
know,
docker
files
are
really
composed
of
multiple
layers
right
so
connected
image
layers
that
contribute
your
application
image
right.
So
you'll
have
a
user
lan
or
the
user
space
the
base
file
system
to
start
with
any
application
that
you
take.
At
least
it
will
have
three
different
kinds
of
docker
files
that
you
have
to
create
in
order
to
produce
that
runnable
form
of
your
application
right.
E
So
one
is
the
base
file
system
file
wherein
you
package
all
your
user
space
related
stuff
and
then
one
docker
file,
which
comprises
of
all
the
language
related
dependencies,
runtimes
and
so
on
and
so
forth,
and
one
file
to
create
your
application
specific
bits.
These
three
files
put
together
becomes
your
runnable
application
image
and,
depending
on
the
complexity
of
the
application,
you
end
up
having
multiple
images
as
well
right
and
the
challenge
with
this
approach
is
like,
since
it's
a
layered
file
right.
E
E
It's
it's
not
an
easy
thing
to
do.
That's
where
cloud
native
build
packs
come
right,
so
it
simplifies
and
eases
the
job
of
both
developers
and
operations.
People
right.
What
does
it
do?
As
I
told
you
before,
cnb
cloud
native
buildbacks
is
a
cncf
incubator
project.
It's
an
open
standard
specification
that
defines
how
to
produce
a
runnable
artifact
from
it
right
from
your
application
source
in
order
to
understand
cnb.
In
order
to
understand
this
specification,
we
need
to
know
about
three
important
things.
Let's
try
to
understand
what
are
those
three
important
things?
E
A
build
pack
is
software
that
either
fully
or
partially
transforms
your
application
source
code
into
a
runnable
artifact.
For
example,
if
you
have
an
application,
that's
built
based
on
java,
a
buildback
is
a
layer
that
would
contribute
the
necessary
runtimes.
In
order
to
run
your
java
based
application,
a
bill
pack
does
not
need
to
be.
E
E
Life
cycle
is
is
again
a
piece
of
software
that
orchestrates
these
build
packs
together.
The
role
of
the
right
life
cycle
is
to
make
sure
that
it
brings
in
all
the
necessary
buildbacks,
and
then
it
transformed
that
resulting
artifact
into
an
oca
conformant
image
so
that
you
can
take
that
image
and
then
run
it
on
a
platform
that
understands
or
run
it
on
a
platform
with
a
container
local
runtime
in
it.
And
the
third
important
thing
is
the
platform.
E
The
platform
is
the
one
that
connects
this
technology
with
the
end
users
right,
so
it
takes
this
whole
cnb
implementation
to
the
users
right
basically
to
the
developers
and
and
the
operations
people
and
on
a
high
level.
It's
it's
been
defined
around
these
three
different
things:
platform,
life
cycle
and
buildback.
As
I
mentioned
you
before,
buildpack
is
the
one
that
transforms
your
source
code
into
a
runnable.
E
Artifact
lifecycle
is
the
one
that
orchestrates
it
and
platform
takes
it
to
the
end
users,
and
in
order
to
fully
understand
this,
we
need
to
know
two
more
things
about
cnb.
As
cnb
is
a
specification
right.
It
doesn't
really
do
anything
right,
so
it
defines
the
roles
and
responsibility
of
these
different
participating
layers,
but
end
of
the
day,
you
need
to
have
a
reference.
Implementation
of
it.
So
builder
is
more
like
a
reference
implementation
of
cnb
it
it's
again
an
oca
confirmed
image.
It
packs
all
these
things
together.
E
It
packs
all
these
different,
build
packs
being
developed
and
written
for
different
language
runtimes,
and
the
life
cycle
is
the
reference
implementation
of
it.
It
orchestrates
all
these
build
packs
based
on
the
language
that
you
deal
with,
and
then
the
builder
is
the
one
that
does
the
heavy
lifting
of
taking
your
source
code
and
then
convert
it
into
a
runable
artifact
and,
along
with
that
builder
stack,
is
the
one
that
that
that
forms
the
base
of
it
right.
E
E
Another
one
is
the
run:
image
stack,
so
build
image
stack
would
be
kind
of
bloated,
because
during
build
time
you
would
need
to
have
a
lot
of
libraries
and
dependencies
that
are
necessary
to
produce
the
compiled
version
of
your
source
code,
but
the
runtime
image
can
be
as
thin
as
possible
as
tiny
as
possible.
Right,
it's
just
enough
layer
to
run
your
application
email.
You
don't
need
to
package
unnecessary
libraries
and
packages
to
be
part
of
that
run
image.
E
That's
the
difference
between
build
and
run
image,
so
build
image
would
be
used
during
the
build
time
to
produce
that
oca
image
and
the
final
oc
image
would
be
based
based
on
the
transmission
and
the
workflow
would
be
something
like
that
on
a
high
level.
So
you
have
the
source
code.
You
give
that
source
code
to
the
builder
and
the
from
the
source
code.
The
builder
the
first
step
first
job
that
it
does
is
to
detect.
E
Okay,
so
we
have
seen
about
the
specification
and
then
we
have
seen
the
reference
implementation
of
it
as
well.
So
it's
time
to
see
it
in
action
right,
so,
let's
get
into
the
demo
yeah
yeah,
so
we
also
in
the
earlier
slide.
I
have
also
mentioned
about
kpac
and
pacquiao
buildbacks
other
than
cloud
native
buildback.
So
let's
try
to
understand
what
are
those
things
right
if
you
look
at
the
ecosystem
of
cnb
right?
So,
as
I
mentioned
you
before,
cnb
is
a
specification.
You
need
to
have
a
reference
implementation
of
it.
E
The
builder
is
the
one
that
that
provides
a
reference
implementation.
The
builder
is
the
one
that
provides
that
reference
implementation
right,
so
pacato
build
packs
is
a
again
cloud.
Foundry
backed
project.
That's
an
open
source
community
backed
reference
implementation
of
cnb
in
a
similar
way.
Heroku
has
their
own
implementation,
so
as
google
as
well
and
platform
is
the
one,
as
I
told
you
before,
that
takes
this
whole
technology.
The
implementation
reference
implementation
to
the
end
users,
so
pac
is
a
cli
based
tool
that
that
leverages
builder
to
produce
that
oc
image.
E
E
E
Okay,
so
what
you'll
see
here
is
I've
split,
my
terminal
window
into
two
pins,
just
to
show
you
how
to
use
cloud
native
buildback
to
produce
this
oc?
A
confirmed
image
for
different
language
context
on
the
left
is
sorry
on
the
left
is
a
language
that's
built
using
node.js
and
on
the
right
is
a
cloud
native
source.
That's
built
using
google
right
now.
E
What
we
are
going
to
do
is,
as
I
told
you
before,
pax
is
a
cli
tool
that
helps
you
to
take
that
reference
implementation
to
the
end
user
right
so
back
to
something
that
you
can
deploy
it
in
your
workstation
and
from
your
workstation.
You
can
make
use
of
this
different
reference
implementations
to
produce
that
oc
confirming
image
from
the
system.
So,
let's
try
to
understand
what
all
the
builders
that
are
available
when
you
do
pack
inspect
builders.
B
C
E
Okay,
what
I'm
doing
here
is
I've
used
packs
such
as
builders,
so
this
is
going
to
pull
all
the
trusted
reference
implementations
of
cnb
cloud
native
buildbacks,
so
give
it
a
couple
of
seconds.
This
would
bring
in
all
the
available
reference
implementations.
As
we
see
here,
there
are
different.
This
is
same
as
what
what
I
mentioned
in
the
slide
right
so
pacquiao
built
backs
is
one
such
reference.
E
So
we
will
do
that
in
a
while
before
that,
let's
kick
start
the
build
process.
So
what
I'm
going
to
do
now
is
I'm
going
to
build
both
this
node.js
based
application
and
the
go
based
application
using
pack
so
bank
bill.
So
what
I'm
doing
here
is
pack
build,
build
as
a
command
to
build
this
from
this
local
part,
which
is
where
my
source
code
resides
and
then
pull
policy
is
never
no
need
to
pull
these
images
from
docker,
because
these
images
are
already
cached
locally
and
I've
given
a
tag
to
this.
E
E
So
while
this
happens,
let's
try
to
understand
what
is
happening
in
the
console.
If
you
look
at
the
console
here,
basically,
the
buildback
does
two
things.
So
one
is
like.
There
are
two
phases
in
the
build
pack.
The
first
phase
is
the
detect
phase.
Detect
phase
is
where
the
actual
magic
happens,
right
so
from
the
source
code
based
on
the
predefined
rules
it
identifies
what's
the
underlying
language.
Runtime
is
so
in
this
case,
while
doing
pack
build.
We
did
not
mention
that
this
is
a
nodejs
based
application.
E
That's
been
detected
automatically
by
the
build
pack
itself
once
it
detects
the
underlying
languages
node.js,
and
then
it
has
started
contributing
these
layers.
So
these
are
all
the
different
layers,
or
these
are
the
different
runtimes
dependencies
that
we
need.
We
need
those
things
to
be
part
of
your
final
image
in
order
to
run
this
node.js
based
application,
that's
been,
these
are
all
the
metadata
information
that
would
be
added
to
your
build
phase
as
part
of
the
detectors
and
analyze
is
something
that's
been
provided
by
the
platform
since
I'm
running
it
using
pax
cli.
E
What
pax
cli
does
is.
It
goes
and
verifies
the
cache
layer.
Whether
have
you
built
this
image
before,
if
you
have
built
this
image
before
then
these
runtimes
are
going
to
be
part
of
your
local
cache.
If
that's
been
the
case,
then
you
don't
need
to
pull
this
layers
again.
What
it
does
is
if
these
layers
are
already
available
in
the
cache
it
just
reuses
the
metadata
information,
it
doesn't
use
the
data
per
se.
It
just
uses
the
metadata
information,
it
uses
the
cache
metadata
and
cache
layers
metadata
information
for
for
for
the
build.
E
That's
it's
trying
to
do
now
and
it's
re
restoring
the
metadata
information
from
the
local
cache
and
then
the
next
phase
is
about
building
it
right.
So
this
is
where
the
compilation
happens,
and
then
it
produces
your
oc
image
and
finally,
it
gets
exported
so
that
when
you
run
the
same
build
process
again,
it
reuses
it
from
the
cache.
E
So
if
I
run
the
same
build
again
this
time,
it
will
be
much
faster
because
since
I
have
run
it
big
once
all
these
layers
are
already
cached
in
the
local
file
system,
so
that
it
reuses
everything
from
the
cache
layer
itself
see
it's
restoring
the
node
engine,
npm
install
and
other
things
from
the
cache
layer,
and
then
the
image
is
built
much
faster
this
time
and
the
same
case
for
go
based
application
as
well.
So
as
part
of
the
detect
phase
it
has
identified.
E
Okay,
this
is
a
go
based
application,
because
there
is
a
go.mod
file.
Is
that
so
from
that?
It
knows
that
okay!
This
is
this
is
an
application,
that's
written
on,
go,
and
these
are
all
the
different
dependencies
and
runtime
layers
that
need
to
be
part
of
the
final
image.
So
that's
why
it
adds
all
those
metadata
information
as
part
of
the
detectors
and
build
is
where
everything
gets
laid
right.
So
all
these
connected
images
are
being
put
together
and
finally
produces
that
oc
confirmed
image.
So
this
is
the
image
that's
been
produced
right.
E
So
if
you
want
to
run
this
image,
just
take
this
image
and
then,
if
you
do,
a
docker
run
occur.
A
nice
8080
to
this
you'll
be
able
to
run
this
image.
So
this
is
again
oca
conformant.
Wherever
you
want
to
run
this
image,
you
would
be
able
to
run
this
image.
So
if
I
do
localhost
8080p,
it's
just
a
sample
hello,
world
application,
so
you'll
be
able
to
see
the
output
here
and
the
same
image.
E
This
is
this
is
the
image
that
you
can
take
and
run
it
on
a
platform
like
kubernetes
as
well,
that
I
mean
so
the
reason
because
since
we
have
chosen
a
builder
since
we
have
chosen
a
packet
of
buildback
buildback
builder,
that's
the
one
that's
going
to
be
used
wherever
you
use
this
cnb
reference
implementation
right.
So
in
this
case
pack
is
the
tool
that's
pulling
this
builder,
and
while
this
build
happens,
it
creates
a
container
locally
and
all
the
all.
This
detect
analyze
restore
build
phase.
E
Everything
would
be
executed
as
part
of
the
container
and
that's
how
the
final
image
gets
produced.
So
when
you
run
the
same
thing
on
a
full-blown
platform
like
k-pack,
it
also
does
the
same
thing
end
of
the
day.
It
leverages
these
builders
to
produce
that
oca
image.
So
that's
a
that's
how
it
the
cnb,
the
cloud
native
build
pack
ensures
that,
whatever
the
image
that
you
produce,
it's
a
consistent
same,
reusable
image,
you
just
build
it
once
and
then
you
can
run
it
wherever
you
have
a
compatible
container
on
time
in
place
right.
E
So
this
is
one
way
of
leveraging
cloud
native
build
packs
to
build
that
application.
The
other
way
is
springboard
is
also
used
as
a
platform,
so
spring
boot
provides
out-of-the-box
support
with
cloud-native
build
packs.
It's
integrated
as
part
of
your
build
tool
itself.
So
based
on
whichever
the
build
tool
that
you
use,
if
you
use
maven
or
gradle,
then
you
can
define
the
task
as
part
of
your
build
tool
so
that,
while
you
compile
your
application,
you'll
be
able
to
produce
or
build
that
final
oc,
confirmment
image
as
well.
E
So
what
you
see
here
is
the
next
demo
is
more
about
how
we
can
use
spring
boot.
This
is
more
for
the
java
side
of
things.
So
if
you
are
building
applications
on
on
on
jre,
so
and
and
if
those
are
using
spring
boot
frameworks,
then
you
can
produce
this
cnb
compatible
oca
image
as
part
of
the
build
the
build
phase
itself,
using
your
build
tools
like
gradle
or
so
what
I've
done
is
I've
defined
a
simple
build
task
here.
E
Boot
build
image,
don't
worry
about
whatever
the
arguments
that
you
have
present
to
it
so
same
as
pull
policies,
if
not
present,
so
don't
pull
it
from
the
docker
app.
If
the
image
is
already.
The
builder
is
already
in
the
local
mission,
try
to
use
the
image
in
the
local
machine,
and
I
have
given
a
custom
name
to
this
image.
This
is
like
this
is
the
registry
to
use
this
is
the
image
name,
repo
name?
E
This
is
the
image
name
and
the
tag,
and
I'm
just
passing
some
enb
related
information
into
the
build
so
use
java
version,
jrd
version
11-
and
this
is
the
builder
that
needs
to
be
used.
So
here
I'm
passing
a
custom,
purpose-built
packet
of
tiny
java
builder,
so
that
the
runtime
image
would
be
more
like
a
distro
list
right,
so
just
enough
base
to
run
your
application
image.
So
if
I
run
this
here,
the
way
to
run
this
is
so.
This
is
a
gradle
based
thing.
E
So,
if
I
do
gradle
boot
build
image,
that's
the
task
that
I
have
defined,
I'm
just
calling
the
task
as
part
of
my
build
phase.
So
what
it
does
is
that
gradle
as
usual,
it
compiles
java
source
code
and
then
it
produced
that
fat
jar
and
after
that,
since
the
boot
build
image,
task
is
being
given
as
part
of
the
build
phase.
It
will
go
and
run
that
again,
so
out
of
the
box,
spring
board
is
integrated
with
pacquiao,
build
packs
and
then,
as
part
of
the
build
instruction
as
part
of
the
task
instruction.
E
We
have
given
that
use
this
builder
to
build
this
application
image.
So
what
it
does
is
that
it
does
the
same
thing.
So
in
this
case
from
the
source
code
again,
it
has
identified
okay,
it's
a
java
based
application.
These
are
the
contributing
layers,
so
there
are
18
build
packs
that
are
applicable
for
a
java
based
application
out
of
18,
based
on
the
information
that
you
pass,
certain
build
packs
would
participate
certain
build
packs,
wouldn't
right,
based
on
your
env,
related
information
and
other
build
related
meta
information.
E
These
layers
would
participate
in
the
build
phase,
so
out
of
18
build
packs.
Five
build
packs
have
participated
in
this
one
so
bill.
Soft
library
car
is
the
one
that
contributes
the
jre
runtime.
An
executable
jar
is
the
one
that
produces
your
fat
jar
and
then,
since
it's
built
based
on
springboard
spring
boot
would
contribute
its
necessary
dependencies
to
build
your
application
and
like
like
how
the
pack
buildback
worked,
detect
analyze.
So
it's
it
goes
and
looks
for
all
these
cache
layers.
E
If
these
cache
layers
exist
and
the
sha
information
remains
the
same,
it
reuses
those
cache
layers
as
part
of
this
bit.
So
it's
restoring
all
those
things,
because
all
these
things
are
previously
built.
That's
the
reason
it
has
pull
in
all
those
cache
layers,
the
metadata
information
of
these
cache
layers
and
then,
finally,
it's
contributing
rest
of
the
things.
E
So
in
this
case,
since
we
have
given,
since
we
have
passed,
the
env
parameter
to
use
jre11,
so
it's
using
jre
11.0.9
right
so
reusing
the
cache
layer,
and
since
I
have
run
this
build
before
so
it
has
picked
up
the
cache
layered
metadata
information.
The
same
information
is
used
as
part
of
this
build
and
then
spring
boot
is
contributing
all
its
relevant
dependencies.
E
E
E
So
it's
hitting
that
boot
build
image
task
and
it's
restoring
all
these
things.
But
if
you
look
at
this
face
since
I'm
using
a
different
builder
and
as
part
of
that
builder
definition,
I've
used
a
different
buildback
and
the
the
runtime
being
contributed
by
the
buildback
is
11.0.7.
So
that's
how
the
whole
build
pack
is
completely.
You
know,
you'll
be
able
to
it's
it's
very
much
extensible.
E
So
as
a
buildback
author,
all
you
have
to
do
is
that
you
have
to
stick
to
that:
slash
bin,
detect
and
bin
build
phase
and
then
you'll
be
able
to
contribute
your
own
layers
as
well.
So
in
this
case
by
using
a
different
buildback
layer,
I
have
contributed
a
different
version
of
jre
lantern
right
and
in
a
similar
way.
Let's
say
if
you
don't
want
to
use
build
soft
liberica.
E
Rather,
if
you
want
to
use
oracle
runtime
or
if
you
want
to
use
sap
java
mission
runtime,
then
all
you
have
to
do
is
as
part
of
your
builder
definition.
You
would
be
able
to
define
all
those
build
packs.
So
if
you
want
to
use
a
different
version
of
buildsoft,
then
you
can
specify
the
version
here
or
altogether.
E
If
you
want
to
change
bitsoft
with
oracle
runtime,
then
you
can
specify
the
oracle
image
here
and
then
you
can
create
your
own
builder
and,
as
part
of
this
as
part
of
this
boot
build
image
task,
then
you
can
specify
your
own
builder
and
when
this
oc
image
gets
built,
it's
going
to
get
built
based
on
the
builder
that
you
have
asked
the
boot
build
image
task
to
use,
and
accordingly,
all
those
after
update,
build
packs
would
participate.
Based
on
the
information
you
pass
and
that's
how
the
oc
image
gets
built.
E
So
if
you
really
want
to
look
into
what
what
is
part
of
this
image
right
so
to
understand
what
we
have
done
here
is
we
have
used
a
cradle
to
produce
this
oc
confirmed
image?
I
should
be
able
to
run
this
image
in
my
local
machine,
but
everything
happened
from
my
source
code
right.
So
if
you
really
want
to
look
into
what
all
the
different
layers
that
are
part
of
this
image,
the
best
way
to
do
is
dive
with
an
excellent
tool.
E
E
E
So
the
cnb,
the
reference
implementation,
contributes
all
these
layers
below
right,
so
life
cycle
launcher
is
the
one
that
holds
information
about
how
to
run
your
application
and
then
so
the
build
sap,
the
bills
of
liberia
participated
in
the
bill
and
this
layer
has
been
contributed
by
bill
saw
and
in
a
similar
way.
So
this
is
the
jre
layer
being
contributed
by
bills
off
in
a
similar
way.
E
All
those
build
packs
that
participated
in
the
build
phase
would
con
would
contribute
the
appropriate
layers,
and
this
is
where
the
application
related
layers
would
come
in.
So
what
you
see
here
is
it's
a
java
based
application
right,
so
this
layer
is
where
all
of
your
application
specific
dependencies
are
there
all
the
dependent
jars
are
part
of
this
layer.
E
Unlike
a
fat
jar.
In
this
case,
the
jar
is
being
sliced
into
four
different
layers,
so
the
topmost
layer
is
where
your
all
your
dependencies
would
be
part
of
it,
and
the
next
layer
is
where
all
the
spring
boot
loader
related
files
compile
classes
would
be
part
of
it,
and
this
layer
is
empty.
If
you
have
defined
any
snapshot
dependencies,
then
all
those
snapshot
dependencies
will
be
part
of
this
layer
and
the
final
layer
is
where
your
application
compile
bits
would
get
it
right.
E
So
this
this
gives
you
a
lot
of
value
it
right.
So
if
it's
a
fad
jar,
if
you
change
a
single
line
in
your
fat
jar-
and
if
you
rebuild
your
application
again
and
if
let's
say
the
size
of
the
fat
jar
is
somewhere
around
100
and
150
mb,
then
you
have
to
move
the
entire
fat
jar
to
your
register
right.
So
that's
a
lot
of
data
being
exchanged
from
your
local
mission
or
from
your
build
system
to
the
registry
by
slicing
your
application.
E
This
way,
what
happens
is
that
the
dependency
layer
is
something
that
you
don't
change.
Very
often
you
change
these
dependencies
once
in
six
months
or
once
in
three
months
right.
If
you
don't
change
this
dependencies,
then,
while
building
your
image
again,
so
this
layer
would
already
be
cache,
would
be
part
of
your
registry.
You
don't
need
to
move
this
layer
to
your
registry,
and
so
is
the
case
with
bootloader.
The
only
layer
that
changes
in
your
image
is
just
this
application
layer,
and
the
size
of
this
is
only
6kb
right.
E
E
So
that's
how
we
leverage
buildback
as
part
of
our
favorite
build
tools
right
and
the
third
step
is
so.
What
we
have
seen
so
far
is
how
we
can
make
use
of
pack
to
produce
this
oc
confirmed
image
from
the
source
code
by
make
by
running
back
in
our
laptops
and
workstation,
and
the
second
demo
was
focused
more
on
the
java
world
of
things.
E
How
we
can
use
maven
and
gradle
as
the
platform
to
leverage
cnb
to
produce
that
oc,
confirmed
image,
and
the
third
demo
is
more
on
how
we
can
use
a
full-blown
build
service
that
runs
natively
on
kubernetes
and
and
then
leverage
the
same
thing
to
produce
this
oc
image,
typically
in
the
the
expectation
from
the
developers,
would
often
be
like.
Once
I
commit
my
changes
to
a
version
control
system,
I
want
the
build
process
to
kick
in
right.
E
So
once
the
changes
get
into
the
version
control
system,
we
expect
the
build
service
to
notify
all
those
up
to
detect
all
those
events
and
then
start
building
start
checking
out
the
changes
and
then
produce
that
oca
image
from
the
change
right.
So
kpac
is
more
of
a
full-blown
platform
that
runs
natively
on
kubernetes
any
oc,
any
cncf
confirmed
kubernetes.
So
in
this
case
I'm
already
running
kpac
on
a
kubernetes
cluster
of
four
nodes,
yeah
five
nodes.
So
what
I'm
going
to
do
now
is
I've
already.
E
I've
already
run
this
build
before.
So,
let's
do
kpack
pack
list
bills,
so
k
pack
from
this
name
space
list
the
bills
that
are
available
right,
so
so
this
is
going
to
list
the
bills
that
are
available.
So
since
I
have
run
this
before
twice
it's
listing
that
you
have
run
this
before
and
both
both
runs
are
successful.
E
Let's
say
that
I
want
to
simulate
one
more
build,
so
the
usual
flow
would
be
like
you
make
changes
to
your
application
source
code
in
your
local
machine
and
once
you're
done
with
your
changes,
you
commit
your
changes
to
a
version
control
system.
So
what
I'm
going
to
do
is:
let's
assume
that
let's
pretend
that
we
have
done
some
changes
to
our
application,
I'm
just
going
to
do
a
dummy
mp
comment
to
the
version
control
system,
so
git
comment
empty
and
then
trigger
build
broker
event
right.
So.
E
E
Give
it
a
couple
of
seconds
while
that
happens,
let's
look
at
the
available
images,
so
these
are
the
images
that
I
have
created
before.
So
the
cloud
native
is
the
one
that
I've
created
before
so
it's
listing
that
build
okay,
it
has
started.
It
has
picked
up
our
changes,
so
we
we
made
some
changes
in
our
local.
E
We
pretended
that
we
pretended
as
if
we
made
some
changes
to
our
local
mission,
and
then
we
committed
that
change
to
the
github
repo
right
and
that's
been
picked
up
automatically
by
the
kpac
platform,
that's
running
on
kubernetes
and
then
it
has
started.
It
has
started
the
build
process
now.
So
if
I
do
kpi
fun
from
this
namespace
do
a
build
logs
of
this
cloud
native.
E
E
This
is
an
application
that's
built
on
java,
so
it
has
got
32
appropriate,
build
packs
out
of
its
six
build
packs,
are
participating
in
this
build
build
phase,
and
since
I
have
built
this
image
before
it's
restoring
that
metadata
information
again
from
the
cache
layer
and
then
it's
the
build.
Software
is
contributing,
jrd
related
stuff
and
then
executable
jar
spring
boot
related
stuff.
And
finally,
it's
building
everything
from
the
source
code.
E
The
gradle
daemon
kicks
in,
and
then
it
compiles
the
source
code
and
produces
the
jar
and
the
jar
would
get
sliced
up
again,
as
we
have
seen
by
our
type.
It
gets
sliced
sliced
up
into
four
different
layers
like
dependencies
spring
boot,
loaded,
layer,
snapshot,
dependencies
and
application
bits
and
finally,
the
oci
image
gets
built
and
it
gets
pushed
it
gets
pushed
to
the
repository
as
well.
E
So,
finally,
if
you
go
to
your
repository,
so
this
is
the
output
right.
So
when
you
create
a
kp
image
that
the
instruction
will
be
like
this,
so
image
create
would
be
like
kp
in
this
namespace
create
an
image
with
this
name,
and
it
needs
to
be
tagged
this
way.
So
this
this
has
to
be
the
output
of
this
build
process.
So
what
I
expect
out
of
this
build
process
is
more
about
once
the
image
gets
built.
E
E
Harvard
our
image
name
is
cyst.humormind.com.
Knee
is
the
repo
name
and
spring
cloud.
Kubernetes
version
2..
If
I
go
to
knee
repo
and
if
I
get
into
spring
cloud
kubernetes
and
you
get
to
see
the
version
2
image
that
just
got
pushed
to
this
registry
right,
so
that's
how
a
full-blown
kp
kind
of
a
platform
on
a
kubernetes-based
runtime
would
work
with
native
buildbacks.
E
So
again
with
kp,
you
can
find
out
all
these
different
builders
as
well,
and
so,
when
you
do
cluster
builder
list,
it
would
list
all
the
builders
that
are
available
in
this
platform.
So
in
this
case
it
has
got
four
different
builders
base
default,
full
and
tiny
builders,
and
then
you
can
look
into
these
builders
as
well,
and
I
told
you
before
so,
if
you,
for
example,
if
you
take
this
built
image.
E
This
this
command
from
pac
would
give
you
the
information
about
this
image,
how
this
image
has
been
built?
What
are
the
participating,
build
back
layers
and
what
are
the
different
processes
that
are
part
of
this?
How
it's
going
to
get
executed
and
all
those
things
would
be
part
of
this
image?
If
you
need
more
information
about
what
are
the
different
dependencies
and
layers
that
are
part
of
this
image,
so
you
can
get
the
complete
build
of
materials
as
well,
so
give
it
a
couple
of
seconds.
E
This
would
give
you
a
nicely
formatted
json,
with
all
the
layers,
with
short
information
that
are
part
of
this
image.
So
if
I
go
all
the
way
up
to
this
image
here,
you
can
see
some
metadata
information
is
there
they
have
pulled
in
the
license
information
as
well.
So
this
is
the
jre
license
information.
So
if
you
have
any
compliance
or
regulatory
requirements
where
you
have
to
produce
this
information,
you'll
be
able
to
produce
this
information
as
well.
So
this
is
the
bills
of
liberica
jre
layer.
That's
been
part
of
this
image.
E
This
is
the
shah
reference
in
case.
If
this
gets
changed,
if
you
use
a
different
builder,
the
shah
reference
would
it's
it's
going
to
be
different.
So
that's
when,
when
you
do
a
bill,
it
wouldn't
be
able
to
restore
it
from
the
cash,
so
that
needs
to
be
contributed
fresh
again,
and
this
is
where
the
jr8
is
being
downloaded
from
and
in
a
similar
way.
You
get
to
see
other
other
layers
as
well,
and
if
you
go
further
down
you'll
get
to
see
all
your
application
specific
dependencies
as
well.
E
So
all
your
jackson
related
dependencies
spring
boot
related
dependencies.
All
those
things
would
be
part
of
the
pill
of
material
information
right.
So
if
you
go
further
down,
you
get
to
see
everything
at
the
different
layer,
different
dependencies
that
are
part
of
it,
the
sha
information
and
all
those
things.
So
that's
how
it
does
the
comparison
when
you
redo
the
build
of
the
same
image
again
if
it's
already
been
built,
if
the
cha
information
remains
intact.
If
it's
not
changed,
then
reuses,
all
this
metadata
information
from
the
previously
built
layer.
E
So
this
is
how
typically
a
build
service
would
look
like
enterprise,
commercial
distribution
of
build
service
would
look
like
so
the
build
service
is
is
at
the
center
of
this
whole
ecosystem,
and
then
it
points
to
your
source
code,
repo
and
then
you'll
have
a
private
registry.
That's
where
you
keep
all
your
buildback
oc
images,
plus
the
stack,
related
images
and
build
service
is
going
to
continuously
watch
these
two
sources
for
any
updates.
E
E
Another
important
thing
is:
I
I'm
not
sure
whether
I
have
the
time
to
show
you
that
part
as
well,
so
the
rebasing
part
is
very
simple:
with
build
service,
so
in
a
docker
file
based
build
mechanism,
whenever
you
have
to
patch
your
base
os
file
system,
you
have
to
pull
that
updated,
patched
image,
and
then
you
have
to
rebuild
all
your
application
images
that
were
built
based
on
that
base
image
right,
whereas
with
cloud
native
buildbacks,
you
don't
need
to
rebuild
your
application
layer
again.
All
you
have
to
do.
E
Is
it
it?
It
follows
the
same
principle
of
the
build
pack
technology
that's
been
used
in
in
in
the
cloud
in
in
cloud
foundry
platform,
so
that
there
is
a
clear
demarcation
between
what
are
the
layers
being
contributed
by
your
application
and
the
layer,
the
file
system
layer.
That's
been
coming
coming
from
the
infrastructure
layer
itself,
so
whenever
you
need
to
patch
your
base
os
file
system,
what
it
does
is
that
once
you
have
that
updated
stack
base
your
runtime
stack
base.
E
Basically,
it
has
to
go
and
update
that
metadata
information
of
the
stack
based
in
your
application
image.
So
through
this
application
binary
interface
contract,
it
ensures
that
changing
the
stack
image
will
not
break
any
of
the
contracts,
that's
being
established
between
your
application
layer
and
the
underlying
stack
layer
and
underlying
infrastructure
layer,
so
rebasing
or
rebuilding
the
patching.
Your
base
layer
os,
is
not
a
big
deal
with
build
service,
and
it
happens
in
a
matter
of
few
seconds
in
the
world
of
docker
file.
E
If
you
have
hundreds
of
thousands
of
containers
rebuilding,
it
would
take
a
longer
time,
whereas
with
cloud
native
build
packs,
it's
just
about
updating
some
metadata
information
and
if
the
the
size
of
that
update
would
be
in
a
few
kilobytes.
That
is
that
information
that
needs
to
be
pushed
back
to
your
registry.
E
A
B
E
Okay,
I
I
run
this
command
before
as
well
right.
So
when
you
do
pack
for
this
builders,
this
this
is
going
to
pull
you
all.
The
open
proof,
implementation
of
pnp
and
arrow
to
build
pack
is
again
a
reference
implementation.
The
open
source
version
is
available
and
you
would
go
to
see
the
same
thing
on
this
one,
so
they
probably
would
have
added
some
enterprise
flavor
to
it,
similar
to
what
we
have
done
with.
E
Implementation,
that's
based
on
pacquiao
buildbacks,
so
pacquiao,
potato
buildback
is
again
an
open
source
reference
implementation
with
apac.
We
have
added
some
of
the
flavors
like
listening
to
your
source
code
repository
and
then,
whenever
the
builder
or
any
of
the
factory,
it
gets
updated
and
pulls
all
those
updates,
whereas
the
potato
contract.
E
A
E
More
like
a
distance,
so
it
is
just
enough
container
based
to
run
your
application
image,
so
it
does
not
include
any
of
the
unnecessary
libraries
and
dependencies
and
that's
how
it
ensures
that
the
runtime
layer
is
as
tiny
as
possible
and
then
other
than
that.
You
love
different
layers
that
would
participate
in
the
country
right
so
based
on
whatever
you
have
included
as
part
of
your
very.
E
A
multi-stage
impact
as
part
of
during
the
build
phase.
We
include
a
bloated
base
image
with
a
lot
of
libraries
that
that
typically,
we
would
need
in
order
to
build
that
image,
whereas
the
runtime
is
the
final
image
that
we
should
use
in
a
multi-stage
file.
The
runtime
image
that
we
have
finally
so
cloud
native
buildback
does
the.
E
It
takes
longer
once
the
build
happens,
the
metadata
and
the
actual
data
itself
give
cache.
So
when
you
re-run
the
building
without
changing
anything,
everything
is
going
to
be
reused
from
the
cache.
Let's
say
that
if
you
have
changed
one
year,
application
layer,
so
all
but
application
layers
would
be
reused
from
your
cache
layer.
So
since
we
have
particular.
A
E
Not
really
so
the
best
way
to
get
started
is
to
go
with
patch
cli
or
if
you
are,
if
you
are
building
for.
If
you
are
building
a
java
based
application,
then
you
can
quickly
get
started
with
springbook
yeah.
So
project.com
is
something
that
you
can
define
as
well,
but
in
order
to
get
started
with
community,
that's
not
a
mandatory
thing.
All
you
need
is
the
backseat
by
default,
your
local
mission
and
then
get
started.
A
E
E
E
And
in
a
similar
way,
you
can
maintain
multiple
builders,
so
that
becomes
your
golden
cost.
The
developers
don't
need
to
worry
about
any
of
them.
It's
a
one-time
setup
would
do
it
once
depending
on
what
policy
is
all
about.
If
you
decide
to
support
multiple
different
times
for
a
language,
then
you'll
have
two
different
builders
to
support
right.
So
this
is
pretty
much
extensible.
E
You
can
take
one
of
the
available
particular
open
source
file
packs
and
then
you
can
contribute
your
own
impact
layer,
so
you'll
be
able
to
override
the
default
as
well
when
you
do
find
well
during
that
time,
you
can
specify
your
own
golden
images.
So
that's
how
cnb
works.
It's
the
same
thing.
Whatever
we
used
to
do
with
docker
files,
the
same
thing
is
being
done
by
cnb
in
a
much
better
way,
so
as
developers
or
we
don't
need
to.