►
From YouTube: Enabling Cloud Native Buildpacks for Windows Containers
Description
"Cloud Native Buildpacks (buildpacks.io), a CNCF sandbox project headed for incubation, is quickly becoming a standard for building secure, runnable OCI images from source code. Unfortunately, support for Windows-based containerization was not part of the CNB project’s original, Linux-focused charter. This leaves a large void for those looking for a path to modernize their existing Windows-based .NET applications.
We’ve been hard at work to change this! In this talk, we’ll begin with a brief overview of the CNB project and its benefits. We’ll then recap some of the challenges and successes we encountered in our journey to enable first-class support for Windows in the CNB ecosystem. Finally, we’ll give a live demo of building and running a Windows-based container image to show just how simple it can be."
Daniella Corricelli, Product Manager at VMware; Malini Valliath, Member of Technical Staff at VMware; Micah Young, Software Engineer at VMware; Andrew Meyer, Software Engineer at VMware
Slides: https://www.slideshare.net/Pivotal/enabling-cloud-native-buildpacks-for-windows-containers
A
So
next
up
we
have
andrew
meyer
daniela,
coracelli,
molini,
valiath
and
micah
young,
all
from
vmware.
There's
often
a
lot
of
talk
about
containers
in
the
realm
of
linux,
but
there's
not
as
much
about
windows.
So
in
this
talk,
they'll
be
covering
cloud
native,
build
packs
and
enabling
that
with
windows
containers
so
I'll,
let
them
take
it
off.
B
B
Great
so,
let's
get
started
over
the
next
45
minutes.
We
are
going
to
be
talking
about
what
options
you
have
to
containerize
your
windows.
Apps
today
introduce
you
to
a
project.
You
might
not
be
familiar
with
yet
cloud
native,
build
packs,
we're
going
to
give
you
a
full
overview
and
a
little
bit
of
a
look
under
the
hood,
as
well
as
the
future
of
cloud
native,
build
packs,
plus
windows
and
then
later
on,
andrew's
going
to
give
us
a
live
demo
with
a.net
framework
app.
B
B
B
All
in
all,
you
might
have
already
realized
it
can
take
a
lot
of
effort
to
write
good
docker
files,
especially
for
net
framework.
Apps,
writing
and
maintaining
one
docker
file
is
costly,
but
maintaining
hundreds
or
even
thousands
of
docker
apps
is
going
to
accumulate
a
mountain
of
technical
debt.
You
probably
don't
want
to
deal
with.
B
B
B
It's
a
pluggable
modular
tool
that
can
translate
your
source
code
into
an
oci
image
and
at
a
high
level.
Cloud-Native
bill
packs
are
resolving
your
app's
dependencies
based
on
its
source
code
and
configures.
Your
app
to
run
to
give
a
quick
history.
Cloud-Native
build
packs
were
first
conceived
by
heroku
in
2011,
and
the
cloud-native
buildpacks
project
was
jointly
initiated
by
pivotal
now
vmware
and
heroku
in
2018..
B
That's
when
the
project
joined
the
cloud
native
sandbox,
and
it's
now
currently
headed
for
incubation.
So
why
should
you
use
cloud-native,
build
packs
for
your.net
framework?
Apps
well
they're
easy
to
configure,
so
you
won't
be
frankensteining
docker
files
anymore
and
they
cover
all
common
language
ecosystems
and
offer
these
four
benefits.
B
They're
reusable.
You
can
use
the
same,
build
pack
on
many
apps
they're
fast.
They
only
rebuild
and
upload
layers
when
necessary,
they're
modular.
You
can
combine
build
packs
to
create
composite
images
and
they're
safe.
You
can
meet
security
requirements
without
developer
intervention
and
keep
a
clean
separation
between
the
base
between
the
app
and
the
base
os.
C
C
So,
for
example,
you
might
have
a
java
build
pack
and
it
might
look
for
the
existence
of
java
files
or
a
jar.
Similarly,
an
npm
build
pack
might
look
for
a
package
json,
and
if
you
had
a
net
related
build
pack,
it
might
look
for
something
like
a
cs.
Proj
file,
and
then
you
have
build
so
build
is
the
second
primary
component
of
a
build
pack,
and
it
too
is
a
binary.
C
C
So
the
orchestrator
of
all
this
is
the
life
cycle,
and
so
the
life
cycle
is
composed
of
two
primary
parts.
There
are
a
lot
more
details
in
here,
but
I'm
going
to
go
over
the
two
main
phases
of
the
life
cycle
and
they
correspond
very
neatly
to
the
two
components
within
an
individual
build
pack.
The
first
of
these
is
called
detect,
and
so
the
one
after
that
is
build
so
we'll
focus
in
on
detect.
First
and
I'll.
C
C
So
let's
visualize
this
a
little
bit
the
first
one
that
passes
will
be
the
one
that
we
select
for
the
rest
of
the
build.
So
in
this
example,
here
we've
got
one
group
with
the
node
and
yarn
build
packs,
for
instance,
as
daniella
mentioned,
build
packs
are
quite
modular.
So
here's
an
example
of
that,
where
you
can
take
a
node
build
pack
that
might
provide
the
node
engine
and
you
could
kind
of
couple
that
with
a
build
pack
depending
on
which
flavor
of
packager
you
want
it.
C
So
we've
got
node
plus
yarn
as
one
group
and
then
as
a
second
group
second
option.
Really
we
have
the
node
plus
the
npm
pack
and
which
group
gets
selected
is
going
to
be
dependent
entirely
upon
the
source
code,
and
so
let's
pretend
that
the
yarn
cnb
might
look
for
the
presence
of
the
yarn
lock
file
to
determine
whether
it
should
be
applied.
C
If
we
had
similar
source
code,
it
didn't
have
the
yarn
lock
file
and
you
expected
the
npm
build
pack
to
run.
You
would
want
that
group
to
be
second
so
that
the
yarn
build
pack
would
essentially
look
for
the
yarn
lock
file
first.
But
if
it's
not
there,
it'll
kind
of
pass
on
to
the
next
group
that
can
run,
and
so
in
this
case,
there's
no
yarn
lock
file.
So
this
group
is
going
to
fail.
C
Detection
and
it'll
allow
the
next
group
to
be
tested,
and
then
lo
and
behold,
let's
say
the
npm
build
pack,
maybe
just
needs
to
look
for
a
package
json
so
that
one's
going
to
be
selected.
So
operators
have
this
flexibility
in
determining
the
not
only
the
groups
of
build
packs
that
can
be.
You
know
connected
together,
but
also
the
order
of
the
groups
so
that
they
can
ensure
that
their
developer
source
code
is
being
built
correctly,
with
the
right
build
packs,
and
now
we
get
to
build
so
build.
C
Is
the
you
know
the
meat
and
potatoes
of
cloud
native
build
packs?
So
let's
pretend
that
the
node
c
and
b
and
the
yarn
c
and
b
were
the
ones
that
were
selected
during
the
detection
phase.
So
I
like
to
envision
the
build
phase
of
the
life
cycle,
as
you
know,
feeding
the
source
code
through
this
machine
of
these
build
packs
and
then
on
the
other
side.
These
build
packs
are
cranking
out
layers.
C
So
more
specifically,
it's
going
to
be
like.
I
said
that
group
that
was
selected
during
detect
each
build
pack
within
the
group
is
going
to
be
run
in
order,
and
then
each
build
pack
is
going
to
you
know
through
their
build
binary
that
I
talked
about
earlier,
is
going
to
gather
all
the
dependencies
for
your
application.
C
It's
going
to
do
any
compilation
that
it
needs
to
do
it's
going
to
configure
any
sort
of
launch
commands
that
it
needs
to
do,
and
then
basically,
the
artifact
of
each
of
those
steps
is
going
to
be
image
layers
that
get
cranked
out.
So
that's
kind
of
the
form
that
these
contributions
take
and
then,
at
the
end
of
this
you
have
this
handy
stack
of
images
or
of
layers
that
are
basically
going
to
comprise
your
image.
At
the
end,.
C
So,
in
order
to
work
up
to
this
big
picture
that
I'll
show
you
there's
one
more
piece
of
the
puzzle
that
we
want
to
have
you
understand
and
it's
about
stacks
and
builders.
So
you
might
have
heard
the
word
stack
related
to
tons
of
application
service
or
or
pc
or
any
any
of
the
like
pivotal
equivalents
in
the
past,
and
so
it's
a
similar
concept
for
cloud
native
build
packs.
But
it
is
a
little
bit
different.
So
in
cnbs
a
a
stack
is
actually
comprised
of
two
images
and
not
one
piece.
C
So
we
have.
What
we
have
here
is
a
build
image
and
we
have
a
run
image
and
so
that
build
image
provides
the
build
time,
os
or
environment
that
the
build
packs
are
going
to
run
inside
of,
and
then
you
also
have
the
runtime
environment
that
the
actual
app
image
is
going
to
be
sitting
on
top
of,
and
that
kind
of
allows
you
to
separate
the
dependencies
that
you
need
only
for
build
time
versus
the
dependencies
and
things
that
you
need
in
your
stack
at
runtime.
C
C
C
C
C
It's
a
cli.
That
is
a
platform.
It's
a
local
platform.
If
you
will,
you
can
also
have
a
platform
that
exists,
maybe
in
a
kubernetes
cluster
or
something
like
that.
So
we'll
be
talking
about
build
service
later
and
some
kubernetes
related
tools
that
you
can
that
you
can
use
spill
packs
with
so
the
platform's
job
is
really
to
execute
the
life
cycle
that
I
told
you
about.
So
let's
see
how
everything
kind
of
fits
together.
C
We
have
our
source
code.
We
have
a
builder
we're
going
to
combine
those
together
and
feed
them
into
the
platform.
The
platform
is
then,
going
to
start
a
container
from
that
builder
image.
It's
going
to
mount
the
source
code
into
that
container
and
then
it's
going
to
kick
off
the
life
cycle
and
the
life
cycle
will
then
go
on
to
kick
off
the
binaries
inside
the
build
packs
and
out
pops.
This
wonderful,
app
image
that
was
built
based
on
all
these
things
that
the
build
packs
provided
for
you.
C
So
we
also
talked
about
the
stack,
so
here's
kind
of
how
the
stack
fits
into
the
big
picture
as
well.
So
we
can
see
the
build
image
affects
this
builder
and
is
kind
of
becomes
the
context
that
the
build
packs
run
inside
of
and
then
here's
how
the
run
image
kind
of
gets
used
to
become
the
base
set
of
base
layers.
For
your
final
app
image.
C
How
long
is
that
going
to
take
so
we
can
perform,
what's
called
an
app
image
rebase,
and
what
that
is.
Is
it's
very,
very
much
like
a
get
rebase
where
you're
essentially
saying
I
want
these
pieces
and
I
want
to
take
them
and
throw
them
on
top
of
a
new
run
image,
a
new
base
and,
what's
really
really
cool
about
the
way
this
is
implemented?
Is
that
through
this
idea,
called
remote
registry
layer
manipulation?
C
We
can
actually
just
do
all
this
without
actually
having
to
download
the
app
image
and
re-upload
it.
We
can
just
download
kilobytes
of
metadata,
manipulate
that
metadata
and
then
send
it
back
up
and
it
takes
less
than
a
second
and
then
your
app
image
is
ready
to
be
redeployed
anywhere.
You
want
so
pretend
you've
got.
You
know
your
old
image,
which
you
now
have
discovered
some
sort
of
cve
in
or
for
whatever
reason
you
want
to
update
it.
C
So
you
push
and
update
to
the
registry
where
your
images
reside
and
when
we
perform
a
rebase.
This
is
all
that
happens.
We
just
it's
essentially
updating
a
pointer
to
point
to
a
new
base
and
that's
why
it's
so
very
fast-
and
this
is
all
possible
because
we
have
this
thing
called
an
abi
guarantee
between
the
run
images.
C
And
I'll
be
demoing
rebasing
as
well
too
toward
the
end,
so
everything
that
I
just
described
is
really
about
the
cnb
project
in
general.
The
cloud
native
build
packs
project
and
we,
our
team
at
vmware,
is
not.
We
are
not
on
that
team
per
se.
We're
on
a
net
focus
team,
so
you
might
be
wondering
you
know
this
is
all
really
cool
stuff.
What
does
it
have
to
do
with
windows
or
how
does
it
work
with
windows?
C
C
So
what
that
means,
if
we
you
know
step
back
to
this
big
picture
image,
is
that
this
right
here
needs
to
be
able
to
support
windows
images,
windows
based
container
images,
and
so
you
can
imagine
the
far-reaching
effect
that
this
is
going
to
have,
because
if
we,
you
know,
support
it
here,
we're
going
to
need
it.
You
know
this
thing
has
its
hands
in
the
builder
image,
which
affects
how
the
build
packs
run
and
how
it
interacts
with
your
source
code.
C
C
So,
as
I
mentioned,
it's
very
widespread
right.
The
changes
we
had
to
make
so
I
mentioned
the
pax
cli
it's
going
to
require
changes
to
the
pax
cli
or
it
did
we've
already
done
this
work.
The
pax
cli
is
used
for
creating
those
builder
images
that
I
mentioned
again.
Those
are
the
images
that
have
the
build
time.
Environment
they've
got
the
life
cycle
and
the
build
packs,
so
creating
those
builder
images
is
primarily
done
through
the
pax
cli,
so
we
had
to
make
changes
significant
changes
to
the
pax
cli
to
support
that.
C
C
C
You
know
this
work
on
this
team
to
make
this
all
work
for
windows
build
packs
execution
is,
are
you
know
affected
by
this
change,
because
now
the
things
that
they
are
assuming
about
the
operating
system
needs
to
be
a
little
bit
more
flexible
and
setting
up
the
launch
command
for
the
app
itself.
You
know
it
was
first
written
with
you
know,
bash
in
mind
and
all
that,
and
so
now
we
need
to
support
environments
that
you
can't
maybe
guarantee
that
bash
is
going
to
be
there.
C
So
at
its
core,
you
could
think
of
an
image
as
really
a
collection
of
tar
files
where
each
layer
is
tar,
and
we
found
that
in
order
to
write
a
a
windows
image
again
we're
not
using
docker
files
right.
So
we
are
stepping
in
to
that
place
that
docker
normally
takes
and
we're
actually
executing
all
the
commands
to
to
create
these
layers
directly,
and
so
these
layers
we
found
required
really
specially
formatted
tars.
C
C
C
Certain
things
might
be
slower
or
we
ran
into
some
permissions
issues
around
volumes
and
things
like
that
and
overall,
the
ecosystem
is
really
just
a
bit
smaller
for
windows,
container
images
than
linux,
and
that
you
know
it
makes
a
lot
of
sense.
Because
windows
is
newer.
To
this.
You
know
docker
image
ecosystem,
but
the
images
that
are
there.
C
C
So
that's
a
really
broad
overview
of
a
little
bit
about
how
build
packs
work,
what
we
had
to
do
to
kind
of
make
all
that
work
for
windows
and
some
of
the
challenges
we
faced.
In
light
of
that,
I'm
going
to
turn
it
over
to
melanie.
Now
to
tell
you
a
little
bit
about
the
future
of
build
packs
and
windows.
A
D
D
C
Thanks
melanie
all
right
yeah,
so
let's
get
started
with
actually
seeing
these
things
work.
So
I'm
gonna
slide
over
here
to
my
windows,
vm,
and
so
I'm
going
to
be
using
the
pax
cli
that
I
talked
about
earlier,
and
what
we're
going
to
do
is
we're
first,
going
to
run
a
build
and
we're
going
to
use
a
sample
builder
that
we
already
have
published
on
docker
hub
that
you
can
use
today.
C
C
C
C
C
C
C
C
C
So,
let's
head
back
over
here,
I
want
to
show
you
one
more
actually
a
couple
more
features,
we'll
let
this
app
kind
of
shut
down
and
I'm
going
to
show
you
a
build
where
we
can
actually
build
directly
against
a
registry.
So
we're
going
to
run
this
same
command
here,
but
I'm
going
to
supply
the
publish
command
and
what
this
is
going
to
do.
Is
it's
going
to
skip
building
it
locally?
C
If
the
image
was
not
there
on
your
local
docker
daemon,
it
still
wouldn't
be
there
after
this,
but
it
would
exist
in
the
registry
that
you
pointed
it
to.
In
this
case,
I've
pointed
it
to
a
local
registry
just
sitting
at
port
5000
on
my
machine
and
we'll
go
take
a
peek
at
that
registry.
After
this
build
is
finished
to
make
sure
that
it's
there
build
should
be
just
a
tad
quicker
this
time,
because
it's
reusing
what
it
can.
C
And
at
this
point
it's
kind
of
exporting
it
up
to
the
registry
so,
depending
on
your
connection,
that
might
take
a
little
bit
of
time.
The
first
time
build
packs
do
optimize,
though,
and
that
the
life
cycle
will
only
update
layers
that
need
to
so.
If
this
app
image
is
up
there
on
the
registry,
already
it's
only
going
to
be
uploading,
those
layers
that
it
knows
have
changed
it's
a
pretty
cool
optimization.
C
C
Demo
rebase
for
you
in
a
bit,
we
have
our
app
image
that
just
popped
up
so
that
again,
built
directly
to
the
registry
didn't
actually
hit
our
local
docker,
daemon
cool.
So
you've
got
this
app
image
right.
You've
built
again
what
about
those
those
things
that
happen
after
your
app
is
already
out
there
in
the
wild.
You
realize
there's
a
cve
in
your
stack
in
your
os
and
you
need
to
make
some
updates
to
some
of
the
things
that
are
in
your
os.
C
But
what,
if
you
have
you
know
hundreds
or
even
thousands,
of
app
images,
kind
of
like
daniella
mentioned
in
her
first
part?
You've
got
you
know,
doctor
files
that
you
might
need
to
rebuild
a
hundred
times
over
or
you
might
need
to
update
a
whole
bunch
of
images
at
once
that
share
this
common
stack
so
because
cloud
native,
build
packs.
Has
this
really
really
well
defined
seam
between
the
app
and
the
stack?
C
These
rebases
can
be
really
really
quick.
So
I'm
going
to
show
you
an
example
of
this.
So,
let's
pretend
that
there
is
a
cve
in
our
run
image
and
I'm
just
going
to
present
the
vulnerability
of
the
cve,
or
rather
when
the
cve
is
fixed,
we'll
know
by
the
existence
of
a
file
that
I'm
going
to
have
exist
on
the
run
image.
So
I'm
just
going
to
do
a
docker.
C
C
C
All
right,
so
it
can't
find
the
file
which
is
expected
at
this
point,
because
our
app
is
still
vulnerable.
So
now,
let's
pretend
that
now
a
new
run
image
has
been
pushed
up
to
the
registry
that
has
the
fix
applied
and
we
want
to
perform
a
rebase
against
it.
So
what
I'm
going
to
do?
Just
as
an
aside,
is
I'm
going
to
build
that
run,
image
and
push
it
up.
C
C
I'm
going
to
push
that
up
and
see
most
of
those
layers
exist
because
that
image
I
had
already
pushed
to
the
registry
before
this
demo.
That's
why
we
saw
that
run
image
sitting
up
there,
but
this
is
a
new
one
that
we
just
created
so
that
new
run
image
is
up
there.
Now
we
are
all
set
to
try
and
do
a
rebase
against
it
and
see
that
we
patched
our
application
in
an
instant.
C
C
C
C
C
You
can
patch
them
all
in
a
matter
of
seconds
or
minutes
and
not
hours
or
months
that
it
might
take
with
a
traditional
docker
file
based
workflow,
and
then
you
kind
of
pair
that
with
tons
of
build
service
which
automates
most
of
this
for
you
or
all
of
this
rebase
for
you,
so
that
when
it
does
see
a
new
run
image
published
to
a
registry,
it
can
go
ahead
and
kick
off
this
rebase
for
you.
So
it's
pretty
cool
stuff.
C
So
that's
our
demo.
I
want
to
just
point
you
to
a
few
more
resources.
If
you
want
to
tinker
with
this
stuff
on
your
own
first
and
foremost
since
we're
all
digital
here,
if
you
hold
up
your
phone,
you
should
be
able
to
scan
this
qr
code
and
it
should
take
you
right
to
buildpacks.io,
which
is
really
the
entry
point
for
everything
related
to
buildpacks.
C
It's
going
to
give
you
access
to
a
windows,
build
guide.
If
you
want
to
try
out
the
same
demo
that
I
did
for
you
today,
you
can
follow
the
tutorial
there
and
do
this
yourself,
we'd
love
for
you
to
engage
in
conversation
with
us
on
our
slack
channel.
So
you
can
reach
that
at
buildpax.slack.com
and
if
there
are
any
questions
that
we
can't
answer
for
you
today,
I
would
really
encourage
you
to
come,
join
that
slack
channel
and
you
can
ask
them
there
and
they
can
get
answered
by
the
wider
cloud
native,
build
packs
community.
C
Please
also
check
out
our
github.
I
mentioned
we
have
samples
right.
These
were
the
samples
that
I
used
for
this
demo.
The
sample
app
the
sample
builder
that
contained
the
sample
build
pack.
So
that's
all
going
to
be
at
this
github
repo.
So
please
do
check
that
out
and
we'd
love
stars
on
any
of
these
repos.
C
If
you
would
be
so
kind
pax
cli,
you
can
hit
up
the
github
repo
for
that,
as
well
as
well
as
the
life
cycle
and
then
the
open
source
core
of
build
service
you
can
tinker
with
if
you
want
to
try
and
deploy
it
locally
to
a
kubernetes
cluster,
or
something
like
that,
you
can
tinker
with
some
of
the
capabilities
of
tons
of
build
service
in
a
local
sense
and
that's
pretty
much
it
so
we
you
know,
love
that
you
joined
us
today.
Thank
you.