►
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
Intro to Cloud Native Buildpacks - Terence Lee, Heroku & Emily Casey, Pivotal
You're great at running containers but you shouldn't have to be great at building them. In this talk, you'll learn about Cloud Native Buildpacks, a higher-level abstraction for building apps compared to Dockerfiles. Buildpacks are a standardized tool for creating images in a secure, reproducible, and efficient manner. As an app developer, you don't need to know best practices around ordering commands for layer reuse. As an operator, you don't need to worry about exposing developers to the responsibilities that come with Dockerfile. Come learn how buildpacks meet developers at their source code, automate the delivery of both OS-level and application-level dependency upgrades, and help you efficiently handle day-2 app operations
https://sched.co/UaiE
A
Welcome
to
the
cloud
native
build
packs
inter
talks
today,
we're
gonna
be
talking
about
the
cloud
natives
build
pack
project
which
is
currently
in
the
CNC
F
sandbox.
We're
gonna
talk
them
about
the
tooling
this
project
provides
and
how
it
can
help.
You
turn
your
application
into
a
container
image:
I'm
Emily,
Casey
I'm,
an
engineer
at
pivotal
and
I
work
on
the
cloud
native,
build
packs,
contributor
team
at
pivotal,
I'm,
also,
a
maintainer
of
the
platform
and
implementation
sub
teams
of
the
project.
A
B
I'm
Terrence
Lee
I
work
at
Heroku
as
an
engineer,
helped
create
the
original
bill.
Packs
API
and
one
of
the
founding
members
of
the
cloud
named
bill
packs
project
on
some
of
these
other
fine
folks
in
the
front
of
the
room
and
so
with
kubernetes.
We
have
a
great
way
to
orchestrate
and
run
images,
but
you
actually
need
images
to
start
with
to
actually
run
it
in
a
coop
cluster.
B
And
finally,
the
built
PACs
provide
a
great
way
to
take
your
application
and
turn
it
into
a
docker
image
that
you
can
run
in
your
cluster
and
it
Maps
layers
logically
to
the
layers
that
make
sense
in
your
application
itself,
with
relatively
zero
configuration
of
white
cloud
native,
build
pack
specific
configuration
that
you
have
to
do
to
actually
make
that
application
work,
and
it's
actually
built
on
top
of
this
kind
of
older
Bill
packs
thing
that
was
invented
in
2011
by
Heroku.
And
so
we've
been
running
kind
of
the
ideas.
B
That
kind
of
made
cloud
native
bill
packs
that
it
is
today
which
started
in
2018
from
concepts
that
we've
been
doing
in
production
between
both
from
pivotal
over
the
last
seven
or
eight
years,
and
we
wanted
to
kind
of
bring
all
those
great
ideologies
to
this
container
ecosystem
and
bring
kind
of
some
of
those
methodologies
there.
And
so
at
the
end,
when
you
actually
build
an
image,
you
get
this
image
that
allows
you
to
have.
B
These
reproducible
builds
that
allow
you
to
kind
of
inspect
these
images
without
and
unpacking
the
image
itself
and
create
images
that
have
like
these
logical
layer,
mappings
and
so
as
a
project.
There's
kind
of
a
few
important
parts
of
the
cloud
native
Belle
PACs
project,
there's
at
its
core
the
specification
itself
and
we
like
to
call
lifecycle
kind
of
the
implementation
of
the
spec
and
so
there's
kind
of
two
different
contracts
that
are
there.
B
There's
the
bill
pack
API,
which
is
the
part
where
lifecycle
will
actually
go
ahead
and
run
the
bill,
packs
and
execute
them
to
actually
produce
that
image,
as
well
as
the
platform
API.
So
a
platform
can
BC,
take
the
lifecycle
and
run
the
resulting
images
and
kind
of
launch
the
resulting
processes
and
stuff
and
set
the
environments,
and
things
like
that,
and
so
the
platform
that
we
provide
out
of
the
project.
A
All
right,
so,
let's
dive
right
in
I
have
a
sample
node
application
here
and
I
have
a
pack
CLI
installed
I'm
gonna
run
PAC
build
I'm
gonna,
provide
it
with
a
tag
in
a
registry
where
I
can
export
this
app
I
can
provide
the
publish
flag,
which
tells
PAC
to
export
the
image
directly
into
the
registry,
which
is
the
most
performant
way
to
run
pack.
So
let's
give
this
a
go.
A
So
what
PAC
is
doing
here
is
taking
the
lifecycle
and
running
it
in
a
series
of
docker
containers
in
my
local
docker
demon
in
a
minute
we're
gonna
dive
into
the
details
of
what
is
specifically
happening
in
each
of
these
lifecycle
steps.
You
can
see
the
headings
for
the
different
lifecycle
phases,
but
zooming
out
at
a
really
high
level.
What
we've
done
here
is
selected
a
group
of
bill
paxton
during
this
lifecycle
phase
called
detection.
So
here
we
have
the
node
engine
bill
pack
and
the
yarn
pack
and
their
virgins.
A
You
might
notice
that
this
version
is
called
old,
which
is
something
we're
going
to
come
back
to
you
and
update
later.
If
you're
clever,
you
might
have
guessed
that
now
in
the
building
phase.
Each
of
these
build
packs
execute
and
it
contributes
dependencies
that
end
up
at
the
final
image.
So
the
node
engine
build
pack
is
contributing
nodejs.
A
The
yarn
build
pack
is
contributing
modules.
They
are
writing
these
dependencies
to
specific
locations
in
the
file
system
and,
at
the
end
here,
the
exporter
is
wrapping
all
of
this
up
to
create
an
image.
So
now
that
I've
built
this
image,
I
can
use
pack
to
learn
a
little
bit
more
about
my
image.
So
let's
use
this
pack
inspect
image
command
and
we
can
see
some
info
here.
So
we
see
what
build
packs
were
used
to
create
the
image.
A
The
dependency
and
a
players
are
added
on
top
of
what
we
call
a
run
image
which
provides
the
operating
system
in
those
dependencies,
and
you
can
see
information
about
the
tag
where
we
found
the
run
image
and
the
specific
run
image
we
use
at
build
time.
Finally,
if
we
provide
the
build
materials
flag
to
you,
this
command,
we
can
see
more
details
about
the
specific
dependencies
that
were
installed
into
this
image.
So,
for
example,
we
can
see
that
we
installed
node
10
16
3.
A
That
starts
with
a
run
image
which
it
comes
from
our
stack
layer
which
represents
the
operating
system
in
this
pack,
which
is
with
semantically
meaningful
layers,
one
for
each
dependency
and
the
application
layer
and
the
modifications
the
bill
pack
might
have
made
to
your
application.
On
top
so
diving
a
little
bit
into
what
happens
in
each
lifecycle
step
during
the
detect
phase,
the
lifecycle
executes
the
detect
binary
in
each
build
pack
and
what
happens
during
the
detect
phase?
A
Is
the
build
pack
looks
at
the
application
source
and
determines
whether
and
how
it
should
run
so,
for
example,
if
I
have
a
package
tree
son
and
a
yarn
lock
file,
the
node
build
pack
is
going
to
say
yes,
I
can
build
this
app
and
the
yarn
build
pack
will
and
together
they'll
make
a
build
pack
group
that
will
execute
at
Build
time.
In
a
case
where,
for
example,
we
didn't
have
a
yarn
lock
file,
we
might
get
the
node
and
NPM
build
packs,
collaborating
to
build
the
application.
A
So
detection
happens
in
parallel
in
order
to
be
performant,
but
we
still
want
to
allow
the
bill
packs
to
collaborate
with
each
other,
because
one
build
pack
might
need
a
dependency
from
an
upstream
build
pack
in
order
to
execute
its
piece
of
the
build.
So
this
is
facilitated
with
a
concept
called
the
build
plan.
So,
as
the
bill
packs
detects,
they
can
write
into
the
build
plan
dependencies
that
they
either
provide
or
require.
A
So
after
detection
has
run
on
all
the
bill,
paxton
looks
at
the
output
to
find
a
build
plan
where
all
the
provides
match
requires,
and
that's
the
first
group
where
that
is
true.
As
the
group
that's
selected
and
those
build
packs
will
run
on
this
first
build
we're
going
to
skip
over
restoring
analyze
because
they
become
important
for
efficiency
on
the
rebuild
step.
So
we're
gonna
move
ahead
to
the
build
phase
of
the
lifecycle.
A
When
the
lifecycle
executes
build,
the
lifecycle
builder
will
call
the
build
binary
and
each
build
pack,
and
this
is
really
like
the
meat
of
the
build
and
what
most
people
think
about
when
they
think
about
build
packs.
So
the
build
packs
will
run
they'll,
look
at
the
source
code
and
they
will
provide
dependencies
like
nodejs
or
yarn
or
node
modules
in
layers
right
now,
they're
directories
on
the
file
system.
B
You
can
run
your
coop
cluster
and
what-have-you
and
finally,
there's
the
caching
phase,
and
so
this
is
what
we're
this
is
done
to
basically
take
anything
that
a
Bill
pack
author,
my
team,
that
can
be
used
to
basically
save
steps
or
processing
time
in
a
future
build
or
a
subsequent
build.
So
an
example.
This
might
be
like
the
node
modules
once
we
have
that
you
don't
have
to
fresh,
install
it
every
time,
so
kind
of
taking
a
different
view
and
slice
of
what
this
looks
like.
B
If
we
look
at
what
the
docker
image
layers
could
look
like
here
on
the
right-hand
side,
so
in
the
export
phase
we're
going
to
in
the
Bill
pack
that
Emily
showed
off,
we
have
that
no
models
directory
of
all
that
kind
of
be
node
library,
dependencies
that
are
included
in
there.
There's
no
engine
which
represents
the
runtime
itself,
like
the
version
of
node
you're,
going
to
run
on
that
was
like
10
16
3
in
that
example,
the
application
specific
code.
B
So
this
lives
in
the
workspace
directory,
but
basically
the
source
code
and
any
mutations
that
they'll
pack
needs
to
do
on
that
directory
to
make
the
app
runnable,
as
well
as
the
stack
image
and
then
any
of
the
layered
and
build
configuration,
sits
in
a
layer
and
those
make
up
kind
of
the
OCI
image
that
gets
run.
And
then,
in
addition
to
that,
we
have
these
cache
layers
which
can
be
used
and
kept
separate
from
the
actual
export
image.
B
So,
as
Bill
pact
author,
you
can
have
say,
like
the
NPM
cache
live
in
this
cache
layer
because
you
don't
actually
need
it
to
boot
or
run
your
application.
So
we
have
the
separate
set
of
things
that
we
want
to
cache
that
we
may
or
may
not
want
in
the
final
exported
image,
and
so
with
that
we'll
look
at
our
rebuild
on
this.
Exactly
not
as
I
made
changes
so.
A
Let's
come
back
to
our
app
and
we
pointed
out
that
we
installed
node
10,
16
3.
So
let's
say
I
want
to
update
the
minor
version
of
node
when
I
first
ran
this
pack
build
I
didn't
supply
builder,
because
I
have
a
default
builder
set
on
the
system.
But
let's
take
a
look
at
the
default
builder
that
we're
using.
A
So
we
can
use
to
pack
inspect
builder
command
to
look
at
all
the
bill
packs
on
this
builder
and
the
order
they
protect
in.
We
can
see
this
old
version
of
the
node
engine
build
pack,
so
I
have
an
updated
builder
here
that
we
can
look
at
and
it's
almost
exactly
the
same,
but
it
has
the
new
version
of
the
build
pack.
So
let's
say
I
want
to
rebuild
with
this
new
builder.
I
can
add
the
Builder
flag
here
and
supply
the
name
of
this
builder
image.
A
Now,
generally,
you
wouldn't
necessarily
update
your
builders
by
pointing,
at
a
different
time,
you'd
be
pointing
at
one
builder
tag
that
a
group
like
cloud,
foundry
or
Heroku
would
constantly
be
publishing
bill
pack
updates
too,
but
we're
gonna.
Do
it
like
this
for
the
sake
of
the
demo,
and
we
can
see
on
rebuild
that
our
new
known
engine
bill
pack
as
detected
we're
restoring
cache
layers
and
metadata.
A
We're
gonna
describe
a
little
bit
more
about
what's
going
on
there
in
a
second
and
during
the
build
phase,
the
node
engine
build
pack
sees
that
the
layer
is
out
of
date
compared
to
what
it
wants.
The
version
of
this
dependency
to
be
so
we'll
install
the
newer
version
of
known
the
yarn
built
back
can
actually
go
ahead
and
just
reuse
the
cache
layer,
because
this
version
I've
noticed
a
bi
compatible
with
the
previous
version.
A
So,
let's
dive
into
a
little
bit
of
detail
what
was
happening
in
each
of
those
lifecycle.
Containers
detect
same
as
last
time
during
restore
layers
that
we
put
into
the
cache
were
returned
to
the
filesystem
in
order
to
help
build
packs
build
more
quickly
either
because
they
need
those
dependencies
at
Build
time
or
because
it's
easier
to
make
a
small
change
to
the
cache
layer
than
to
regenerate
it
from
scratch.
A
During
analyze,
the
analyzer
looks
at
the
actual
OCI
image
that
was
generated
last
time
and
writes
metadata
about
the
layers
to
the
filesystem.
So
an
example
of
this
might
be
like
a
nude
tamil
file
describing
the
version
of
node
that
was
in
the
previous
image,
and
it
will
include
metadata
like
the
version
that
was
in
that
layer.
The
reason
we
do
this
is
so
that
build
packs
can
use
this
information
to
decide
whether
they
want
to
bother
regenerating
a
layer
or
not.
A
A
B
And
so
in
this
case
we
only
need
to
update
the
note
engine
cache
layer,
because
that's
the
only
one
that's
actually
updated.
We
didn't
even
actually
run
yarn
install
to
actually
update
those
dependencies.
Could
we're
just
reusing
that
layer
so
going
through
kind
of
the
layer
breakdown
example
again
as
we
go
through
it,
so
Emily
I
was
talking
about
restore,
so
we're
actually
go
ahead
and
restore
those
images.
B
We
can
export-
and
in
this
case,
for
example,
we've
run
through
we're
just
updating
the
configuration
and
the
node
engine,
because
in
the
yarn
build
path,
we're
not
actually
running
yard
and
solver,
just
reusing
that
layer
and
then
with
caching,
there's
a
similar
optimisation
where,
since
we're
not
actually
changing
any
other
cache
layers,
we're
only
going
to
be
updating
the
node
engine
one
for
the
cache.
So
it
can
be
used.
C
B
You're
going
to
do
would
be
like
patching
this
nodejs
application
in
case
there's
an
operating
system
well
with
cv
that
you
have
to
handle,
and
so
snick
released
an
article
this
year
about.
You
know
like
the
top
30
docker
images
has
all
these
vulnerabilities
in
them,
and
actually
you
can
actually
just
swap
out
kind
of
the
underlying
base
image
that
we've
been
talking
about
to
actually
mitigate
a
good
chunk
of
those
CDs.
A
A
One
of
these
run
images
tags
to
find
a
run
image
to
build
on
top
of
the
tool,
we'll
select
the
run
image,
that's
on
the
registry
you're
exporting
to
for
maximum
efficiency,
and
then
this
base
image
includes
the
specific
image
that
we
built
on
top
of
that
running
time,
like
the
image
digest,
so
I
actually
have
an
updated
version
of
this
run.
Image
here
and
I'm
gonna
push
it
up
to
my
registry,
and
now
we
can
rebase
this
application
and
it
should
replace
the
base
layers
on
this
image.
A
With
the
new
base
layers,
we
pushed
to
the
registry
I'm
going
to
do
with
the
publish
like.
Oh
my
gosh,
okay,
you
can
see
it's
much
faster
when
you're
operating
directly
against
the
registry.
So
now
the
weave
rebase,
this
image,
we
can
take
a
look
and
I,
don't
know
if
remember
the
SHA
from
last
time,
you
probably
don't,
but
the
base
layers
have
changed
and
I'm
realizing.
We
forgot
to
show
this
image
actually
runs
last
time,
so
that
we've
made
a
couple
changes
to
it.
Let's
actually
pull
it
down
to
run
it
not
that
one.
A
A
So,
let's
talk
about
what
is
happening
during
rebase
image,
normally
have
OS
layers
and
language
runtime
layers
and
application
layers.
On
top
of
that,
so
we
maintain
a
logical
separation
between
the
application
layers
and
the
operating
system
layers
and
operating
system
packages.
So
imagine
there's
a
CBE
in
the
operating
system.
We
can
upload
to
the
registry
a
new
image
that
contains
a
patched
operating
system,
and
these
two
images
have
a
guaranteed
between
them
called
ABI
compatibility,
so
application
binary
interface
compatibility
and
what
that
means
is
all
of
these
layers.
A
These
application
layers
that
we've
built
can
run
exactly
as
they
are
on
top
of
the
new
you
base
layers
and
this
because
we're
building
on
top
of
a
boon
to
Bionic.
This
is
a
guarantee
provided
to
us
by
canonical.
So
what
we
can
do
is
create
a
new
image
directly
against
the
registry,
not
by
rebuilding
or
re
uploading,
anything
other
than
a
config
file
that
describes
an
image
that
combines
these
base
layers
for
the
application
layers
and
a
manifest
file
for
that
image.
So.
B
You're,
probably
gonna,
be
doing
at
scale
with
the
cluster
of
applications
out
there,
and
so
potentially,
if
you
run
to
a
thing
where
there
is
a
CV
that
you
have
to
apply,
you
have
to
actually
deal
with
that
for
every
single
application
in
your
fleet,
and
that
means
that
you
have
to
figure
out
some
mitigation
strategy
for
writing
this
with
docker
to
figure
out
like
how
that
actually
works
right.
So,
if
you're
doing
this,
what
docker
file.
Traditionally
that
means
for
every
different
base
image.
B
You
have
to
actually
figure
out
a
strategy
for
actually
mitigating
that
for
each
different
base,
image
you're
doing
and
then
in
the
best
case
scenario
where
it's
all
the
same.
You
still
have
to
do
a
rebuild
across
the
entire
fleet
for
every
type
of
application,
you're
running
which,
if
you
have
a
small
fleet
that
maybe
that's
a
few
hours
to
a
few
days
to
just
even
do
the
rebuild
before
you
actually
roll
it
out
in
the
worst
case.
B
A
We
talked
about
how,
by
implementing
the
platform
API
any
platform,
to
take
advantage
of
the
core
functionality
of
the
lifecycle
and
the
cloud
native
build
packs
building
technology.
So
we
talked
about
one
platform
which
was
pack
and
pack
provides.
The
UX
has
optimized
for
a
developer
workstation,
it's
a
local
CLI.
It
has
an
imperative
flow.
A
Now
we're
gonna
talk
about
key
pack,
which
is
a
pivotal
open
source
project
that
uses
a
set
of
custom,
kubernetes
resources
and
controllers
to
manage
many
images,
and
it
provides
a
declarative
API
and
it's
well-suited
to
rebuilding
many
images
with
Clannad
build
packs
SQL.
So
it's
the
same
core
building
technology
but
wrapped
in
a
UX.
It's
optimized
for
a
different
use
case.
A
A
We
want
to
see
you
living
at
a
particular
tag
in
the
container
registry,
so
you
can
say
I
want
source
from
this
branch
from
my
git
repo
and
I
want
it
to
be
built
with
a
specific
builder
and
then
every
time
that
the
reality
falls
out
of
date
with
the
desired
configuration
either
because
gopac
gets
updated
or
the
source
changes.
Ki
pack
will
schedule
a
bill,
so
an
image
is
a
mutable
config
and
every
time
that
the
system
reconciles
and
makes
an
immutable
build.
A
B
A
I'm,
gonna
repeat
the
question
for
the
recording.
The
question
is:
what
goes
to
the
right
of
this
page,
so
this
system,
and
it
is
generating,
builds
and
that's
great
and
all
but
like
what
is
responsible
for
knowing
what
to
do
with
certain
builds
and
also
like
do
I
want
to
do
something
different,
because
it
was
built
for
a
different
reason
like
a
rebase.
A
We
sort
of
think
of
that
as
outside
of
the
scope
of
the
cloud
and
build
packs
project.
But
there
definitely
are
people
building
tools
that
use
things
like
this
as
a
building
block
in
the
process
of
creating
a
higher
level.
Abstraction,
like
the
Rif
team,
for
example,
like
uses
kpac
as
a
component
in
their
function
service.
So
they
plug
this
set
of
ceará
DS
in
and
you
generate
a
bunch
of
images
and
then
a
larger
set
of
ceará
DS
that
describe
higher-level
concepts
like
a
function
or
an
application,
take
care
of
deploying
those.
D
A
I
think
the
bill
PACs
take
responsibility
for
providing
all
the
information
that
a
platform
we
need
in
order
to
make
those
determinations
right
so
like
either
creating
a
derivative
image.
Config.
So
I
want
to
rebase
this
one
particular
image
that
I
have
to
put
the
prod,
not
just
what's
on
master
stuff.
D
A
Problem
you're
making
us
jumping
in
here
we're
gonna
get
to
other
platforms
later
all
right.
Sorry,
let's
rebase,
multiple
images,
so
I
have
kpac
installed
here.
I
have
taken
the
liberty
of
installing
a
builder
image
here,
so
I
created
that
configuration
that
points
at
a
tang
and
kpac
has
populated
it
with
the
bill.
A
Pacs
it
found
on
this
image
and
that
builder
image
has
a
reference
tool,
run
image
tag
and
we
can
also
see
the
particular
digest
reference
of
the
run
image
at
that
Tang
also
created
a
couple
images
here:
demo
apps,
1,
3,
3,
they're,
simple,
Java,
apps
and
we're
gonna
see
what
it
would
look
like
to
rebase
all
of
your
images
right
now.
It's
only
3,
but
this
could
easily,
on
a
large
cluster
scale,
to
many
images
being
managed
this
way.
A
A
We
can
look
at
the
original
build
that
was
used
to
create
the
first
version
of
this
image,
and
this
should
look
very
familiar,
because
this
is
almost
exactly
the
output
you're
getting
from
the
packs.
E1Ke
pack
ran
the
same
lifecycle
in
a
series
of
containers
in
a
pot
and
kubernetes,
but
the
like
core
technology
here
being
used
is
the
same.
This
is
a
Java
app,
not
like
the
known
app
that
we
built
originally
so
now
that
we
have
this
app
because
it's
being
built
with
the
same
life
cycle
as
annotated
with
the
same
metadata.
C
A
It
should
see
that
this
run
image
the
digest
that
this
tag
has
changed
and
it
will
update
the
builder
for
us.
It's
gonna
take
a
couple
seconds,
so
we're
just
gonna
watch
it
goes
there.
It
goes
alright,
so
now
that
this
run
images
change,
Capek
knows
that
all
these
images
need
to
be
rebase
in
order
to
match
their
desired
config.
So
if
we
get
the
builds
before
we
ran
this,
we
only
had
one
build
for
each
app,
but
now
we
have
extra
builds.
These
are
real
aces.
A
A
All
right,
so
you
can
see
the
reason
for
this
build
was
types
back,
meaning
that
it's
a
rebus
and
if
we
inspect
the
image,
we
can
see
that
we
have
updated
the
run
image
and
simply
by
pushing
this
one
run
image.
It's
able
to
get
a
rebase
of
all
the
appropriate
images
on
my
cluster,
and
we
for
this
example
for
a
stack.
But
this
would
work
with
a
built,
a
cup
date
as
well.
B
Thanks
Emily,
so
I
guess
I'm
kind
of
just
recapping
a
little
bit.
We
we
were
talking
about
the
contacts
before
I,
guess
the
demo
/x
questions,
and
you
know
like
we're
talking
about
like
how
long
it
would
actually
take
to
mitigate
this
at
scale.
If
you're,
using
like
docker
files
in
production
and
Emily,
you
kind
of
showcase
like
doing
that.
Rebase
like
it
for
her
the
only
took
a
few
minutes,
but
you
can
imagine,
maybe
it
takes
a
little
bit
longer.
B
If
you
have
a
bunch
of
different
builds,
you
have
to
do
across
entire
fleet,
and
so
this
is
the
thing
that
scale
is
relatively
well
and
actually
can
be
done
relatively
quickly,
especially
in
comparison
to
what
you
have
to
do
with
a
rebuild
per
app.
So
this
is
rebasing
with
kpac.
So
just
you
know
another
platform
that
is
leveraging
cloud
and
build
packs
with
a
totally
different
UX
like
we're
talking
about,
and
so
really
at
the
end
of
the
day.
Climb
and
Bill
packs
are
kind
of
wound
to
some
of
dr.
next.
B
Questions
like
building
blocks
where
different
platforms
or
services
that
want
to
take
a
management
can
have
different
UX
and
parameters
of
what
they
want
to
do,
but
it's
just
providing
the
primitives
to
actually
do
image
building
for
things
like
applications,
and
so
both
plat
finding
Roku
are
actually
working
on
various
climate
bill
packs
to
kind
of
take
advantage
of
some
of
this
stuff.
With
the
Google
cloud
run
project,
they
have
a
thing
where
you
can
click
a
button
with
Google
cloud
run
and
it
will
actually
build
an
app
using
Bill
packs
or
docker
files.
B
Project
RIF
is
a
I
just
like
function
functions
as
a
service
that
basically
uses
cloud
native
bill
packs
as
building
blocks
to
kind
of
provide
this
like
high-level
abstraction
for
building
functions.
So
at
the
end,
you
still
do
get
this
OCI
image
that
you
can
run,
but
it's
using
their
own
set
of
CMBS
underneath
to
actually
make
that
happen.
B
So
build
packs
are
being
used
kind
of
as
a
foundational
piece
to
actually
provide
this
kind
of
image,
building
service
across
a
bunch
of
different
platforms,
and
hopefully
through
the
demos
in
this
presentation,
you're
able
to
see
that
bill
packs
have
a
lot
of
pretty
great
properties
surrounding
them.
So
when
we
talk
about
reusable
one
things
that
was
nice
and
the
kpac
demo,
is
that,
like
there
was
this
same
unified,
build
pipeline
of
the
lifecycle
and
using
like
a
very
small
subset
of
bill
packs?
B
Whereas
if
you
ever
deployed
a
file
in
production
and
your
company,
you
probably
have
this
kind
of
sprawling
snowflakes
of
docker
files
per
apps,
your
checking
in
a
docker
file
per
repo
and
and
all
the
demo,
apps
and
apps
that
people
are
using
bill
packs
on
you're,
not
checking
in
the
actual
build
pack
into
your
app
like.
It
is
a
kind
of
separate
thing
that
can
be
reused
across
multiple
applications
through
the
use
of
of
basically
the
build
configuration,
the
caching
we
can
base.
B
B
So
it
means
that
if
you
need
to
replace
a
certain
component
like
maybe
you
want
to
I
like
a
few
years
ago,
when
iOS
was
thing
and
potentially
the
platform
you're
working
on,
doesn't
support
it,
you
could
write
your
own,
like
I
OGS
engine
bill,
packed
us
up
that
in
or
I
guess
more
realize,
realistic
examples
like
if
you're
working
with
Java
you
need
to
replace
the
runtime.
You
can
replace
like
the
JDK
or
Jerry
like
Bill
pack.
That's
installing
that
and
say
you're
on.
B
You
want
to
use
the
kind
of
Amazon's
proprietary
jdk
in
that
case
right,
and
so
you
could
just
write
a
bill
pack
that
leverages
the
rest
of
those
components,
but
just
replaces
that
one
piece
and
then
finally
they're
kind
of
secured
out
of
the
gate.
With
these
authors,
who
are
actually
maintaining
and
patching
this
stuff
with
the
metadata,
that's
provided
you
don't
actually
have
to
unpack
the
docker
image
itself,
to
kind
of
look
at
it
for
compliance
or
other
reasons
there
and
with
features
like
rebase.
B
B
B
If
you
want
to
get
involved
or
have
questions
fairly
active
on
there
there's
a
mailing
list
and
then
we
also
have
a
deep
dive,
talk
being
done
by
Steven
and
Joe
tomorrow
at
5:20,
where
they're
gonna
kind
of
dig
into
production,
build
packs
and
kind
of
how
they
work,
and
you
can
get
a
better
feel
of
like
what
it
takes.
Actually
kind
of
write
this
stuff
in
brush
them.
Thanks.
B
E
This
is
relatively
quick
one.
Some
of
this
seems
to
overlap
at
least
conceptually
with
the
cloud
native
application
bundle.
Spec,
do
you
know
if
anybody's
working
on
combining
this
with
that
or
do
they
conflict
with
each
other,
or
do
they
complement
each
other
or
like?
Are
they
totally
unaware
of
each
other
right
now,
we're.
B
Aware
of
the
cloud
Nate
C,
NAB
project
I,
don't
think
we're
doing
anything
that
conflicts
with
it.
We're
not
really
doing
anything.
That
also
makes
us
like
make
a
scene
ab
out
of
it.
So,
like
you
can't
do
it.
Pac
building
get
us
C,
not
out
of
that
project,
but
I.
Think
C
NAB
has
a
significant,
bigger
scope,
as
far
as
like
packaging
concerns
right,
because
it
talks
about
both
like
what
you're
installing
locally
on
your
machine
and
how
it
like
it's
a
pretty
generic.
B
F
A
G
A
The
Tecton
catalog
Tecton
is
like
an
example,
CI
CD
tool,
and
it
will
just
execute
the
lifecycle
directly
in
a
series
of
containers.
So
the
Tecton
tool
itself
is
doing
the
orchestration
and
that's
nice
because
you
don't
have
the
problem
of
like
running
docker
in
docker,
like
you
would.
If
you
used
a
pack
C
like
so
directly,
integrating
a
lifecycle
is
better
where
it's
possible.
Yeah.
B
H
It
seems
like
the
process
would
be
if
I'm
a
developer,
that
I'm
still
coding
locally
on
everything,
then
using
Packer
kpac
to
deploy
it
out
to
my
cluster.
Have
you
all
looked
at
integrating
with
some
of
the
other
tools,
not
integrating
but
taking
the
same
approach
as
well
for
like
local
development,
so
things
like
octet,
oh
and
telepresence,
things
that
can
sync
changes
over
to
a
running
container?
Is
that
completely
out
of
scope
of
what
you're
trying
to
do
with
packs?
Does
that
make
sense
what
I'm
asking
so.
H
D
B
We
and
so
we've
talked
about
like
in
the
spec,
there's
actually
been
developing,
that
we've
talked
about
it's
not
implemented
yet,
and
there's
probably
still
much
more
work
to
be
done
on
it.
So
I
don't
think
we
have
anything
that
does
exactly
what
you're
talking
about,
but
it's
definitely
something
that
is
not
out
of
scope.
B
I
I
C
A
If
you
have
what
I'm
going
to
build
our
image-
and
you
have
this
image
on
a
registry-
all
the
tools
we've
demoed
today-
will
always
try
to
pull
the
newest
version
from
the
registry
before
running.
So
it
does
that
by
default,
you
can
also
distribute
build
packs
in
what
we
call
build
package.
Is
our
new
specification
for
distributing
them
and
that
all
works
by
the
same
mechanism.
It's
like
packaging,
build
packs
in
an
OCI
image
and
we
try
to
always
pull
when
something
as
a
village.
C
B
Mean
yeah
so
we're
we're
getting
to
a
point
where
stuff
is,
for
the
most
part,
not
backwards.
Breaking
I
think
we
just
made
a
significant
backwards
breaking
thing
relatively
recently,
but
for
the
most
part,
a
lot
of
the
stuff
going
forward
were
not
doing
a
lot
of
breaking
changes
and
for
the
most
part,
any
kind
of
breaking
changes
would
fall
on
the
kind
of
bill.
They've
tend
to
fall
in
like
the
bill,
packed
API
side.
So,
like
I
guess
for
a
production
level
usage
it.
B
It
kind
depends
on
like,
like
if
you're
using
the
local
Cloud
Foundry
build
packs.
You
know,
like
they've,
been
used
for
a
while,
depending
on
what
bill
packs
are
using
and
but,
if
you're,
like
writing
your
own
I
think
it's
much
more
dependent
on
like
whether
the
build
packs
you're
writing
you
feel
are
also
production-ready.
In
that
sense,
as
far
as
lifecycle
and
other
things
like,
we
definitely
have
these
chases,
where
people
are
using
it
in
production
and
people
are
leveraging
it.
A
Also,
if
you're
using
a
maintained
platform
that
can
encapsulate
you
from
the
breaking
changes,
so
we
might
make
a
break
one
of
those
api's
right
now
at
this
stage
in
beta,
but
the
platform
is
capable
of
knowing
which
API
it's
running
against
and
doing
the
right
thing.
So
for
most
use
cases,
you
wouldn't
even
feel
many
of
the
braking
changes.
It
mostly
falls
on
my
platform,
authors
and.
C
B
Those
changes,
if
there's
there's
I,
think
only
been
one
time
where
we
haven't
done
that,
because
it
was
really
like
hard
to
actually
maintain
both
of
those
things
at
one
time
but
oftentimes
a
little
like
if
we
defecate
an
n/bar
for
like
a
new
one
like
the
Lib
Bill
pack,
we'll
just
account
to
do
both
of
those
things.
So
you
don't
really
have
to
kind
of
make
those
changes.
B
Think,
that's
that's
definitely
something
that
is
taken
account
by
who's,
providing
the
kind
of
container
image
so
like
when
you're,
providing
the
stack
or
kind
of
base
or
run
images
like
like
the
bill.
Packs
of
cells
are
not
out
of
the
box
and
provide
like
a
app
security
thing.
How
the
gate
is
part
of
the
project,
but
yeah
like
the
container
image,
should
have
I
guess,
like
those
rules
and
stuff
in
place.