►
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
Deep Dive: Cloud Native Buildpacks - Terence Lee, Heroku & Stephen Levine, Pivotal
Learn why you need a buildpack and how to create one. We'll write a simple Python buildpack we can use to build an image from a Django app. We'll take advantage of caching and Docker layers to speed up rebuilds and deploys. Unlike Dockerfiles, buildpacks are composable. We'll create a build pipeline with our Python buildpack and the Node.js buildpack, which we'll use to prepare asset bundles. Finally, you'll learn how to rebase your application layers on a new image. This allow operators to efficiently handle the delivery of OS-level dependency upgrades.
https://sched.co/MPj2
A
Good
afternoon,
this
is
the
talk
on
the
deep
dive
for
platinum,
bull
pecs.
My
name
is
Terrence
Lee
I
go
by
on
0-2
on
Twitter
I
work
at
platform
as
a
service
company
called
Heroku,
and
if
you
missed
or
remember
the
talk
from
yesterday,
this
was
the
bill
pack
API,
where
so
as
a
Bill
pack
author,
you
need
to
implement
these
two
executables
detect
and
build,
and
then
the
platform
provides
basic
analysis
and
exports,
and
so
with
detect.
A
This
is
the
part
where
the
bill
pack
will
just
write
code
that
will
decide
if
it
should
run
kind
of,
creates
a
build
plan
that
codifies
the
bull
facts
that
need
to
be
run
and
in
the
bill
phase.
This
is
kind
of
the
meat
of
the
bill
pack
that
actually
goes
ahead
and
creates
the
different
OCI
layers
that
will
be
in
your
resulting
image
at
the
end,
as
well
as
a
bunch
of
metadata
that
gets
associated
with
it
and
so
with
export.
A
This
is
where
the
platform
actually
goes
and
constructs
the
image
that
you
can
use
at
the
end
and
then
basically,
on
a
subsequent
build
like
a
non
first
run.
The
analysis
will
go
ahead
and
pull
down
the
different
OCI
layers
that
may
be
needed
on
that
build
and
so
just
a
quick
overview
of
the
various
components.
If
you
go
to
our
build
pack,
github
org
you'll
see
a
bunch
of
different
repos,
and
these
are
kind
of
the
most
important
ones.
A
I
think
if
you're
going
to
be
looking
into
this
project,
so
pack
is
the
one
I
think
we
direct
most
people
to
first
to
kind
of
get
started.
It's
basically
the
local
experience
that
you
can
download
as
a
CLI
and
kind
of
go
ahead
and
take
a
nap
and
actually
build
an
image
out
of
that
with
the
various
images.
And
it's
really
just
like
the
best
starting
point.
A
A
There
is
a
lifecycle
repo
that
basically
is
the
main
thing
that
you'll
you
as
a
platform
like
implement
that
implements
the
bill
pack
API
via
through
spec,
we'll
mention
this
further
on
talked
first
things
would
bill
pack
is
kind
of
the
main
goal:
anguish
bonding
that
we
provide.
So
a
lot
of
the
bill
packs
that
we
have
implemented
as
climate
bill
packs.
Actually
a
written
go
and
they
just
used
the
liberal
Pat
to
kind
of
make
that
easier.
A
We
have
a
spec
which
is
just
the
formal
specification
of
the
bill
pack
API
and
then
the
RFC's
as
a
basic
place,
where
you
can
propose
substantial
changes
to
the
project,
and
so
with
that
we're
going
to
dive
into
kind
of
the
main
part
of
the
presentation,
so
I'm
gonna
go
and
talk
about
basically
how
we've
implemented
the
Heroku
bill,
packed
set
of
things
and
then
Stephens
going
to
talk
about
cloud
foundry.
So
to
kick.
A
This
off
I
was
talking
about
pack,
so
here's
an
example
of
running
a
pack
builds
and
then
we're
passing
in
basically
the
local
builder
images
or
the
program
builder
image,
and
it
contains
all
the
bill
packs
that
we
used
to
run
it
and
in
this
thing
that
we're
running
it's
building
against
a
spring
boot
application.
And
so
one
of
the
things
is
that
this
application
doesn't
specify
any
like
double
pack
specific
configuration.
A
So
I
was
mentioning
this
builder
image
that
we
use
AC
as
part
of
pack,
and
so
the
Builder
images
are
a
way
that
we
use
to
kind
of.
They
are
a
assignment
that
bassy
contains
the
build
packs
that
you're
going
that
are
gonna,
be
made
available
when
you
run
pack
build
or
really
anything
as
kind
of
a
containable
format.
A
They're
includes
the
lifecycle
that
actually
goes
ahead
and
does
the
build,
and
the
life
cycles
also
use
to
basically
launch
the
application
when
you
actually
run
it
with
like
a
docker
run
and
so
to
construct
a
builder
image.
There
is
a
build.
A
lot
on
that
basically
describes
the
kind
of
things
that
go
into
it,
so
you're
gonna
list
kind
of
the
build
packs
there
and
then,
as
well
as
as
a
stack
and
when
we
talk
about
a
stack,
it's
broken
up
into
two
parts.
A
There's
a
build
image,
that's
used
as
the
context
for
actually
building
images,
and
then
the
run
image
that,
when
you
actually
do
that
docker
run
my
kind
of
the
base
image,
that's
being
used
where
the
application
sits
on
top
of
so
kind
of
stepping,
through
that
with
the
building
on
Tom.
All
you
just
have
to
name
your
stack.
So,
in
the
Hoecker
case,
we
have
a
stack
called
for
creatine
and
then
here
we're
basically
as
strings
pointing
to
two
different
docker
images
that
we've
built
and
we'll
go
into
like
how
these
images
were
built.
A
But
so
we
at
broeckel
provide
basically
two
docker
images
that
anyone
can
kind
of
go
and
fetch
and
use
as
part
of
the
product
unrelated
to
kind
of
the
planetvale
PACs
project.
And
basically,
in
our
build
image.
We
have
development
headers
that
basically
we
don't
make
it
available
in
a
run
image
because
they
aren't
really
needed,
but
you
might
need
them
for
poly
native
extensions
and
other
things
like
that.
So
to
go
ahead
and
construct
those
images
that
I
referenced
in
the
Builder
tunnel.
We
basically
inherit
from
the
that
Viroqua
build
image.
A
We
need
to
provide
basically
create
a
user
that
will
be
used
to
kind
of
do
all
that
stuff,
as
well
as
basically
set
some
stack
information
and
kind
of
the
label.
So
the
build
pack
knows
what
stack
it's
actually
running
with
and
then
the
run
image
is
going
to
look
really
similar,
and
the
only
difference
here
is
that
the
run
image
uses
the
run
image
down
here
from
on
the
for
creatine
stack
side
and
not
the
build
image,
and
so
with
that.
If
you
dr.
A
bill
both
of
those
doctor
files,
we
have
two
images
that
the
builder
Tom
will
can
reference
now,
and
so
the
kind
of
the
next
section
is
going
to
be
all
the
build
packs
that
you
want
to
have
available
that
when
we
do
the
when
we
create
that
builder,
that
will
actually
be
available
in
that
OCI
image.
So
in
this
case,
there's
a
bunch
of
bill
packs
in
here,
I
haven't
written
in
code,
but
there's
example.
A
What
that
looks
like
you
need
to
basically
specify
the
idea
of
the
bill
pack
as
well
as
well
as
where
you
can
actually
get
that
bill
pack.
So
in
this
case,
I
have
a
Ruby
in
a
proc
file
one
and
then
once
you've
lists
all
the
bill
packs.
You
can
then,
basically
build
groups
of
bill,
packs
being
run
together
as
a
single
kind
of
change,
so
we
have
a
Ruby
bill
pack
and
then,
after
reveal,
packets
run
the
proc
cloudbuilt
pack
will
get
wrong
and
one
things
that
you
can
do
is
you
can
set
bill.
A
Packs
is
optional.
So
if
the
detect
fails
on
proc
file,
the
bill
will
still
succeed,
and
so
we'll
have
the
resulting
image.
But
if
the
rubyville
pack,
for
instance,
failed
since
its
required,
it
will
actually
kind
of
fail
to
build
and
proceed
to
the
next
group,
and
so
with
all
that
stuff.
We
have
a
complete
builder
dot
tunnel
that
we
can
use
to
use
pack
and
run
the
create
builder
command,
and
it
goes
ahead
and,
like
I
was
saying,
adds
all
the
bill
packs.
It's
gonna
inject.
A
The
lifecycle
binary
that
we
use
for
the
building
and
launching
it's
gonna
validate
that
we
actually
have
that
user,
so
I
won't
want
you
to
kind
of
create
a
builder
image
without
that
stuff
validates
the
GOPAC
on
the
stack
creates
all
the
directors
you
need
and
basically
kind
of
sets
everything
up.
So
you
don't
have
to
do
that
inside
of
your
own
stack
images
that
you're
linked
that
you're
linked
to
in
your
builder
tunnel,
and
so
once
we
have
that.
A
So
these
are
kind
of
the
docker
images
that
we've
created
as
part
of
our
Builder
image.
So
this
is
builder
image
for
okay,
build
packs.
18
is
the
one
that
you're
gonna
pass
to
the
builder
flag
when
you
run
pack
build,
and
then
it's
gonna
reference,
these
two
other
ones
that
we've
walked
through
and
with
that
we
have
here
all
the
build
packs
that
we
actually
have
as
part
of
the
Pirozhki
builder
image.
A
So
we've
written
to
cloud
native
go
pack
specific
ones
to
the
Ruby
and
Java
ones,
and
then,
as
part
of
kind
of
the
platform,
we
really
have
a
bunch
of
other
existing
bill
packs
and
we've
written.
Basically,
a
shim
that
allows
us
to
run
those
v2a,
build
packs
inside
of
the
v3
launcher
and
kind
of
have
them
all
run
together.
So
that's
node,
Python,
PHP
go
and
so
I'm
gonna
walk
through
kind
of
the
Ruby
one.
A
We
don't
have
to
apply
them
across
like
two
different
repos,
so
you'll
see
kind
of
the
different
design
decisions
we've
made
to
kind
of
hit
some
of
those
goals,
so
the
proko
bill
pack
has
par
detect.
Basically,
all
it
does
is
it's
gonna
check
that
a
gem
file
exists
because
that's
kind
of
the
main
defensive
management
system
in
Ruby
and
if
it
does
it
passes,
it
doesn't
actually
write
like
a
build
plan
or
anything,
and
you
don't
need
to
do
stuff
that
you
don't
want
to
do
as
part
of
that.
A
So
you
can
do
pretty
simple
stuff
and
so,
as
part
detect,
we
actually
just
have
code
there
to
basically
check
a
form
v2
mode
or
v3
mode.
So
we
do
kind
of
a
bunch
of
this
stuff
to
just
make
it.
So
we
can
run
the
v2
and
v3
next
to
each
other
with
the
same
code
base
and
then
as
part
of
build
we're
gonna
go
through
and
create
a
bunch
of
different
layers.
A
In
the
Ruby
case,
we're
gonna
create
a
ruby
layer,
and
so
this
goes
in
a
specific
directory
under
the
layers
folder
specific
to
our
bill
pack,
that's
made
available
to
us
we're
gonna,
set
environment
variable
the
path
thing
so
basically
can
execute,
and
so
basically,
at
runtime,
when
we
launch
any
Ruby
process,
it
knows
where
the
binary
is
as
well
as
if
there
is
a
Bill
pack
that
depends
on
Ruby
kind
of
down
the
line.
It
also
has
access
to
the
read
binary.
A
A
If
we
on
a
new
stack,
you
obviously
want
to
replace
the
binary
with
a
Ruby
minor,
that's
actually
built
for
that
stack
kind
of
the
next
major
layer
is
kind
of
the
dependencies
which
are
rubygems
so
again,
similar
we're
gonna
put
that
in
a
different
layer
which
is
in
a
different
directory
and
then
we're
just
going
to
set
time
the
environment
variable.
So
when
we
boot
the
Ruby
app,
it
knows
where
to
actually
find
that
stuff
and
then
again
metadata
stuff.
A
So
we
know
when
to
actually
basically
build
this
layer
if
we
need
to
and
seems
gonna
kind
of
go
how
all
that
stuff
gets
constructor
an
image.
So
we
don't
go
through
this
twice
gonna
kind
of
move
along,
and
so
this
kind
of
builds
kind
of
the
first
part,
the
Ruby
part,
and
so
we're
going
to
talk
about
this
proc
file
build
pack
as
this
optional
pack
that
we're
building,
and
so
the
Heroku
clan
native
go
pack
profile.
A
Build
pack
is
really
just
a
compatibility
bill
pack,
so
this
is
kind
of
an
example
of
like
how
you
can
build
really
small
functionality
to
kind
of
extend
things
that
you
want,
even
though,
like
a
route
build
packs,
a
pretty
massive
bill
pack,
this
prompt
about
one
is
under
100
lines
of
mostly
bash,
and
so,
if
you're
not
familiar
profiles
away
on
karoku
to
basically
specify
the
process
type
that
you
want
to
launch
and
kind
of
have
that
be
able
to
be
launched.
And
so
it's
pretty
simple.
A
A
All
that
has
different
things
you
can
specify
in
it,
but
one
of
them
is
a
group
of
processes,
and
so
all
this
proc
file
build
pack
is
going
to
do
it's
going
to
parse
that
proc
file
and
it's
just
going
to
write
out
I
launched
Omelas
par
that
build
process.
So
when
launcher
boots
up,
it
knows
of
the
different
processes
that
you
can
actually
launch,
and
so
with
that
previous
proc
file,
all
does
is
basically
replaces
strings
and
kind
of
does
validation
around
that
and
that's
kind
of
again.
B
Hey
yeah,
so
I'm
Steven
I
work
at
pivotal
on
things
related
to
cloud
foundry
and
kate's,
and
today
I'm
gonna
talk
about
sort
of
the
primary
goal
we
had
for
rewriting
the
Cloud
Foundry
build
packs.
On
top
of
this,
new
API
is
really
modularity
and
transparency
that
we
wanted
to
break
down
the
build
packs
into
kind
of
composable
pieces
that
each
did
know
one
thing
and
that
kind
of
cloud
native,
build
packs.
V3
API
provides
some
nice
functionality
for
letting
you
break
down
build
packs
into
smaller
parts
than
the
previous
build
pack
and
invitations
did.
B
You
can
kind
of
contrast
this.
You
know
on
the
Heroku
side,
I
think
the
initial
approach
was
more
of
you
know,
build
one
build
pack,
that's
responsible
for
a
lot
of
things
and
that's
a
fine
way
to
build
a
build
pack
too.
On
our
side,
we
wanted
to
break
it
down
more
and
use
some
of
the
sort
of
progressive
complexity
that
you
can
use
within
the
API.
So
if
you
look
at
our
you
know
previous
nodejs
build
pack
for
v2,
it's
kind
of
one
big
monolithic
thing.
B
The
new
nodejs
build
pack
for
v3
is
kind
of
three
build
max.
It's
a
node
engine
build
pack,
a
yarn,
build
pack
and
an
NPM
build
back,
and
so
during
the
detection
phase,
you
can
kind
of
express
this
as
two
groups.
The
engine
build
pack,
you
know
with
the
module
installed
the
process
by
yarn
or
the
engine
build
pack
and
the
modules
installed
in
the
process
by
NPM,
and
so
it
was
a
kind
of
a
reminder.
Build
pack.
B
The
detection
process
is
actually
that
that
whole
initial
part
is
also
responsible
for
coming
up
with
a
plan
for
what's
going
to
happen
during
the
build
called
the
build
plan
and
so
to
kind
of
run
through
what
this
looks
like
with
Cloud
Foundry,
we
have
the
nodejs,
build
pack
engine
build
pack
running
first
and
it
says:
hey,
you
know,
I
just
do
one
thing:
I,
don't
understand
package.json,
because
that's
an
NPM,
you
know
configuration
file
or
your
own
configuration
file,
and
so
my
job
is
just
I'm.
Gonna
provide
the
nodejs
engine
itself.
B
If
another
build
pack
asks
for
it
and
I'm
gonna
pass
because
who
knows
might
if
nobody
else
asked
for
it,
then
that's
great
I'm
not
gonna.
Do
anything.
The
yarn
build
pack
runs
and
fails
immediately
because
there's
no
yarn
lock
here
so
move
on
to
the
next
week.
So
that
group
doesn't
happen.
We
move
on
to
the
next
group.
B
So
they
note
engine
build
pack,
runs
again
same
thing:
okay,
we're
good
and
then
the
npm
build
pack
runs
and
it
reads
package.json
because
that's
npm
configuration-
and
it
says
oh
I-
found
this
node
engine
version.
So
I
know
we
need
to
install
node,
j,
s10,
31
and
I'm
going
to
add
that
build
plan
for
the
node
JS
build
pack,
and
so
that
group
is
selected.
B
We
have
a
build
plan
and
we
proceed
to
the
build
phase,
and
so
at
this
point
and
just
as
a
reminder,
the
build
phase
is
kind
of
a
it's
an
unprivileged.
So
it
runs
an
unprivileged
containers
and
produces
reproducible
images,
and
it
constructs
these
image
in
these
images
incrementally
just
by
generating
new
layers
that
don't
need
to
change
from
the
previous
build.
It
doesn't
even
need
to
download
old
layers
kind
of
it's
very
different
from
the
docker
file
model
sort
of
designed
to
be
as
efficient
as
possible.
B
Given
that
we
can,
you
know,
kind
of
put
code
upfront
on
the
build
back
side
and
so
to
kind
of
run
through
that
build
process.
The
build
plan
is
fed
into
the
node.js
engine,
build
pack
which
kind
of
claims
that
entry,
and
it
creates
these,
you
know,
creates
a
node.js
layer
that
has
you
know,
nodejs
in
it
and
sets
up
the
environment
a
little
bit
for
things
to
be
able
to
use
it.
It
if
you
look
at
these
layer
paths
here,
it's
kind
of
interesting.
B
You
know
the
reason
we
can
kind
of
incremental
e
update
layers,
regardless
of
what
order
they're
in
is
because
there's
sort
of
a
tight
contract
for
where
they
live
and
at
the
same
time
it
writes
that
layer.
It
writes
a
metadata
about
what
what's
in
the
layers
so
that
later
it
can
look
back
at
that
and
say:
oh,
you
know
the
remote
image
and
the
registry.
B
It
already
has
this
layer
I
don't
need
to
rebuild
it
if
it
needs
to,
and
then
the
NPM
build
pec
runs
and
it
doesn't
get
the
build
plan
because
the
entry
was
claimed
by
the
node.js
build
pack.
If
you
had
many
more
build
packs,
you
have
it's
sort
of
more
entries
passed
along
and
when
the
npm
bobba
hug
runs
and
generates
node
modules,
layer,
kind
of
wood,
you
know
path
set
up
sort
of
so
that
you
have
modules
and
a
node
path
exported
separately,
and
then
it
writes
metadata.
B
That,
in
this
case,
is
the
shoc
256
some
of
the
package
JSON
locks
so
that
it
can
tell
hey
your
package
block,
didn't
change,
I'm
not
going
to
regenerate
the
modules
time,
and
so
then,
all
these
components
that
were
generated
are
kind
of
combined
together
to
create
no
CI
image.
So
you
have
the
layers
and
the
application
layer.
B
You
know
being
stored
as
filesystem
layers
in
the
image,
and
then
you
have
the
metadata
and
the
build
plans
stored
in
the
image
metadata,
and
that's
that's
the
final
OCI
image
that
gets
generated
it's
more
than
two
layers.
It's
just
kind
of
grouping
everything
together
there
and
then
on
a
rebuild.
You
know
say
the
build
happens
again.
You
might
not
need
to
regenerate
that
nodejs
layer.
You
may
just
need
to
rebuild
the
node
modules.
B
So
doesn't
you
know
a
question
we
get
and
kind
of,
as
we
were
building
it
style
we
realize
might
be
a
problem
is
I'm
decomposing,
build
packs
into
smaller
groups,
makes
distributing
them
and
kind
of
interacting
with
them
a
challenge.
So
if
you
have
all
these
groups
like
for
our
Python,
build
pack
where
it's
even
more
complicated,
you
know
we
support
all
these
different
kinds
of
package
managers.
How
would
you
say
I
want
to
put
an
APM
agent.
B
You
know
before
every
single
one
of
those
that
seems
like
a
lot
of
extra
configuration
might
be
good
too.
We
had
an
abstraction
to
represent
these
groups
of
build
packs,
and
so
that
abstraction
is
the
distribution
specification
which
there's
an
RFC
out
for
right
now
that
should
come
up
in
the
next
version
for
kind
of
defining
these
build
modules
as
groups
of
build
packs,
so
kind
of
coming
from
that
Python
configuration
we
kind
of
simplify
it
into
runtime
build
pack.
B
A
package
managers
met
a
build
pack
that
references,
those
other
build
packs
and
a
condor
build
pack
is
kind
of
kind
of
doesn't
something
and
altogether
that
can
be
represented
by
a
Python
ecosystem
build
pack,
and
so,
if
you
want
to,
you
know,
have
your
APM
agent
or
security
scan
or
build
pack,
or
whatever
run
around
that
you
just
say
yep.
This
runs
before
that
you're
done,
and
so
you
know
same
with
node
for
the
configuration
you
saw
before
you
know:
J
s,
engine
package
managers
or
just
the
node
J
s
ecosystem,
build
pack.
B
You
don't
have
to
read
this
tamil
here,
but
to
kind
of
give
you
a
sense
of
what
that
looks
like
underneath,
each
kind
of
modular
build
pack
can
have
its
own
little
piece
of
configuration.
That
says
this
is
my
version.
Here's
some
metadata
about
my
build
pack
and
then
you
can
define
these
sort
of
meta,
build
packs
on
the
right-hand
side
of
the
diagram
or
Tamil
that
kind
of
define
you
know,
build
packs
that
are
composed
of
other
bill
packs.
B
The
highlighted
one
at
the
bottom
is
the
ecosystem
bill
back
and
so
I
think
the
the
next
sort
of
really
significant
part
of
this
new
distribution
specification
is
kind
of
the
ability
to
dynamically
construct
builders
automatically
and
this
kind
of
starts
with
a
file
format.
That's
just
you
know.
Each
build
pack
represented
as
an
individual
layer
with
the
constituent
build
taxes
symboliks
inside
of
that
layer.
B
It's
kind
of
a
non
runnable
OCI
image
or
it
can
be
exported
to
a
dot,
C
and
B
file,
but
it's
just
an
exported
OCI
and
there's
that
you
can
kind
of
you
know,
transfer
places.
If
you
don't
have
a
registry
available
and
then
you
can
take
this
and
then
put
it
on
top
of
a
stack
that
all
the
build
packs
support
to
get
a
builder
image,
and
you
can
do
that.
You
can
actually
do
this
whole
process
dynamically.
B
On
a
registry
where
you
just
update
the
registry
meditate
create
a
new
manifest
dynamically
on
the
registry
that
points
to
the
existing
layers.
So
it's
just
like
it's
very
easy
to
dynamically
generate
a
builder
on
the
registry
that
supports
the
build
packs
you
want
to
support,
and
this
is
a
way
you
can
support
a
large
platform
with
many
many
build
packs,
so
users
could
build
kind
of
whatever
stack
they
want,
whatever,
whatever
build
packs,
they
want,
but
also
have
predefined
configurations
that
an
operator
can
set
up
that
an
operator
could
also
easily
generate
to.
B
A
So
Steven
talked
about
the
destruction
RFC,
which
is
kind
of
the
next
big
thing
that
we've
been
talking
a
bunch
about
since
our
summit
two
months
ago
and
as
he
alluded
as
well
with
the
OPAC
registry,
we
have
not
built
that
yet,
but
the
hope
is
to
have
a
central
place
where
people
can
register
build
packs,
as
well
as
I.
Think.
The
kind
of
very
attractive
thing
is
the
dynamic
generation
of
basic
builder
images,
since
those
all
that
information
will
be
there
and
a
lot
of
it
will
just
be
quickly
just
writing
that
metadata
file.
A
So
we
don't
have
to
basically
rebuild
all
these
images.
In
addition
to
that,
we're
looking
to
basically
remove
dependencies
on
things
that
it
takes
to
run,
build
packs.
We
can
support
Basie
scratch
or
smaller
images
for
cases
where
people
care
about
that.
We
want
to
add
support
in
our
specification
for
Windows
containers
as
well
kind.
The
next
big
thing
that
kind
of
adds
a
lot
of
more
functionality
is
mixin
support,
and
so
what
we
mean
by
this
is
kind
of
a
contract
for
how
to
extend
stack
images
to
support
additional
packages.
A
So,
right
now,
with
bill
packs,
you
kinda
have
to
specify
what
stacks
you
support
so
with
mix-ins.
This
will
allow
you
to
basically
add
additional
packages,
but
still
have
those
bill
packs
be
able
to
run
on
kind
of
different
configurations
of
that
stacked
image
and
finally,
like
in-line
bill
packs.
This
is
the
concept
of
being
able
to
like
inside
of
your
project
or
application.
That
is
not
a
bill
pack
repo
but
like
this
is
what
using
to
the
source,
while
you're
running
your
bill,
packs
against
to
actually
be
able
to
specify
inline
bill
packs.
A
We
have
a
bunch
of
other
stuff
in
the
roadmap,
but
these
are
kind
of
the
high
level
things
I
thought
was
worth
talking
about,
and
so
in
dishes
that
we've
been
working
with
various
projects
and
providers
for
basically
integrating
bill
packs
with
their
systems.
Obviously,
Steve
and
I
have
worked
at
cloud
for
having
Heroku,
so
working
on
platform
integrations
there.
We
have
the
template
that
we
talked
about
4k
native
Tecton.
A
Riff
is
a
functions
as
a
service
on
top
of
K
native,
and
they
basically
are
built
on
top
of
bill
packs
for
kind
of
constructing
images,
and
so
they
use
the
C
and
B
v3
like
the
bill
pack.
V3
Cloud
Foundry
bill
packs,
as
well
as
they
have
their
own
set
of
basically
function
bill
packs
that
allows
them
to
not
have
to
duplicate
that
functionality.
A
Build
pack
model
draft
was
also
represented
at
the
summit
that
we
had
and
potentially
talking
about
bill
paxton
how
they
think
stand.
The
current
template
support
that
they're
doing
with
docker
files,
and
maybe
some
of
you
in
the
room
are
also
involved
with
various
open
source
projects
or
things
in
your
company,
whether
that's
a
public
product
or
an
internal
thing,
but
we'd
be
happy
to
talk
to
you
about
how
you
can
integrate
bill
packs
with
your
platform.
A
So
either
come
talk
to
us
after
the
talk,
or
we
have
a
slack
that
you
can
join
where
that's
where
we
actually
coordinate
and
talk
about
things
across
our
various
companies.
And
then
we
also
have
a
mailing
lists.
That's
provided
by
this
CNC
F,
and
so,
if
you
haven't
checked
it
out,
definitely
the
easiest
way
like
I've
said
before
is
to
use
the
pax
Eli,
which,
if
you
go
to
github.com,
slash,
gill-pack,
slash
pack
under
releases,
you
just
go
download
it
or,
if
you're,
on
a
Mac
and
I
think
brew
install
it.
A
If
you
had
support
for
that,
so
you'll
have
access
to
the
Builder
images
and
pill
packs
that
we've
talked
about
through
this
talk
to
actually
kind
of
bootstrap
and
see
what
that
looks
like
so
you're,
not
starting
from
nothing
and
then
all
that
stuff
is
based
on
top
of
ionic
today.
So
with
that,
I
will
open
it
up
for
questions.
B
B
Yeah,
sorry
to
repeat
the
question
you
know:
how
do
we
construct
layers
with,
for
instance,
like
how
do
we
construct
the
layer
that
has
the
Ruby
runtime
and
in
it,
and
you
know
to
build
that
with
CI
image
and
so
part
of
the
you
know.
Kind
of
an
really
interesting
part
of
a
project
is
that
we
are
kind
of
creating
OCI
images
using
kind
of
our
own
tooling
and
a
Google
library
called
go
container
registry.
So
we
can
generate
OCI
images
directly
on
a
registry
without
a
doctor
daemon.
B
Without
you
know
any
capabilities
or
privileges
needed
without
anything
like
builder
or
Conoco,
just
by
constructing
layers
manually-
and
you
know,
as
you
know,
TG
sees,
which
are
distressed
with
layers
are
and
exporting
them
out
to
the
registry
or
to
the
local
doctor
daemon.
If
you
want
to
kind
of
use
a
docker
Damon
with
it,
and
so
so
the
Ruby
build
pack
would
generate
that
layer
in
a
directory
kind
of
like
in
an
easy
way
without
the
full
pads,
and
then
it
would
the
kind
of
build
pack.
B
B
Yeah,
so
the
Cloud
Foundry
bill
PACs
support
fully
offline
builds
by
including,
like
we
have
kind
of
two
versions
of
each
bill
pack.
One
that's
packaged
to
include
all
of
its
like
to
the
last
patch
versions
of
all
the
supported
lines
of
every
dependency
they're
like
a
gigabyte
each.
Maybe
so
you
can
build
completely
offline
and
unprivileged
containers
and
all
that
stuff
in
a
you
know,
isolated
environment
with
all
the
security
stuff.
You
want.
B
A
I
mean
we
have
the
only
thing
we
really
have
been
they're
like
the
binaries,
like
the
actual
Ruby
runtimes.
We
build
as
well
as
like
both
bundler
and
other
things
that
are
kind
of
dependent
on
it,
when
you're
actually
doing
bundle
install
the
fetch
libraries
we
hit
literally
what
the
gem
file
tells
us
to
hit
so
most
of
times.
That's
gonna
be
Ruby
gems,
but
I
mean
if
you
had
a
private
server
that
you
had
like
in
our
private
spaces
product.
B
Pet
could
also
build
everything
from
source
during
the
build
process
if
I
really
wanted
to,
but
because
of
that
sort
of
approved
stack
model
we
have
you
don't
have
to,
and
your
builds
can
be
much
faster.
You
don't
have
to
worry
about
building
everything
you
know
during
the
build
process
for
each
a
cool,
awesome
question.
C
B
The
question
is:
how
easy
is
it
to
swap
out
the
operating
system,
layers
I?
Think
they're.
It's
like
do
you
mean
like
swap
out
go
into
with
Santos
or
like
swap
atubu
into
with
a
new
ABI,
compatible
security
patch
version
of
good.
You
got
it
so
the
the
specification
and
the
tooling
doesn't
have
a
preference
of
one
two
or
Sun
toss
or
whatever,
but
the
build
packs
individually
support
operating
system
layers
because
the
binaries
are
built
on
top
of
those
operating
system
layers.
B
A
And
then,
and
then,
when
we're
talking
about
support
for
scratch
images,
it's
mostly
there's
some
stuff
that
is
dependent
on
like
with
the
profile,
D
and
other
things,
as
part
of
the
specification
that
kind
of
requires
a
POSIX
tile
environment,
but
yeah
I
mean
there's
nothing
hard-coded.
That
forces
you
to
use
a
particular
flavor
of
Linux
or
anything
that
is
really
entirely
up
to
the
fill
packs
that
are
written
against
them
right.
So,
like
the
for
global
packs,
we
just
build
them
in
the
context
that
we
assume
that
stuff
is
on
the
stack
image.
A
B
Yeah,
so
mix-ins
are
a
contract
for
defining
kind
of
base,
images
that
have
more
stuff
than
the
build
pack
kind
of
intends
to
know
about,
so
that
you
can
say
like
I.
Have
my
you
know,
CF
official
Bionic
stack
that
has
a
few
dependencies
on
it,
but
for
my
application,
I'm
gonna
create
a
version
that
has
these
extra
image,
processing
related
packages
and
it'll
still
work
with
the
CF
build
packs
and
that's
kind
of
the
first
step,
eventually
we'd
like
to
do
sort
of
more
automated
support.
B
For
you
know,
my
app
means
these
OS
packages
just
make
sure
they're
there.
But
you
know
it's
because
we're
trying
to
preserve
this
sort
of
ABI
compatibility
contract
between
the
application
layers
and
the
operating
system
layers,
so
you
can
swap
the
operating
system
out
without
rebuilding
it.
The
you
know
that
makes
it
adds
challenges
to
adding
those
operating
system
packages
because
they
have
to
come
in
with
those
stack
layers.
Initially,
there's.
No,
you
know
good
contract
for
installing
them.
B
It's
a
great
question:
we
don't
think
because
operating
system
packages
can
run
arbitrary
code
when
they
get
installed.
In
many
cases
you
know
we've
been
through
a
lot
of
iterations
of.
Is
it
possible
to
layer
eyes
all
the
packages
you
know
be
able
to
install
them,
but
we
don't
think
you
can
do
it
safely.