►
Description
Cloud-native buildpacks provide organizations with a way to build consistent, more secure, and more efficient docker images. The session will be a deep dive into Cloud-native buildpacks, and how they work when compared to traditional Dockerfiles. The session will also explore the benefits and tradeoffs when transitioning to build packs and how they solve some of the industries most challenging problems.
-- Buildpacks - The future of containers?
-- Eamon Scullion
Broadcast at the Northern Ireland Developer Conference 2020
-- Day 1 / Track 2 / Talk 4
A
Hi,
my
name
is
eamon
scullion
and
I'm
a
software
engineer
at
undersquare.
This
talk
today
is
about
build
packs,
an
alternative
to
docker
files
and
cover
a
lot
of
different
topics
such
as
why
people
use
docker
files
and
docker
in
general,
and
then
some
of
the
benefits
they
might
get
from
some
other
options
out
there.
So,
first
of
all,
let's
talk
a
bit
about
the
prehistoric
days,
also
known
as
before,
2013..
A
It
might
just
be
differences
in
environments
in
2013,
docker
came
along
and
that
kind
of
changed
the
way
developers
work.
So
it
kind
of
changed
all
the
responsibilities
so
developers
now
more
prior
to
say,
here's,
the
environments.
I
want
my
apps
to
run
in
and
it
can
be
consistent
across
environments
before
we
get
to
that,
though
a
little
intro
into
what
docker
is
and
why
people
use
it.
So
the
first
thing
is:
what
is
a
docker
container?
A
A
One
important
difference
between
a
container
and
a
fertile
machine
is
a
container
shares
the
actual
underlying
operating
system,
whereas
in
a
virtual
machine
it
has
a
separate
operating
system
for
each
virtual
machine
and
other
concepts
to
be
aware
of
is
a
docker
image,
which
is
what
we
actually
run
in
order
to
get
a
docker
container.
It
kind
of
outlines
all
the
setup
for
your
app
and
dependencies
and
all
that
is
defined
by
dockerfiles.
A
So
some
of
the
benefits
we
get
from
dockerfiles
and
docker
in
general
is
we
have
consistent
environments
between
a
developer's
machine
right
through
to
all
their
different
production.
Environments
will
no
longer
have
the
it
works
online
machine
problem
and
it's
portable
and
can
run
anywhere
where
you
can
install
docker,
so
all
common
platforms,
and
yet
it's
perfect
for
isolating
apps
from
each
other.
So
it's
ideal
for
microservices
architecture.
A
Some
of
the
problems
it
introduces
that
we
briefly
touched
on
is
developers
now
have
the
ability
to
outline
their
entire
stack,
so
not
only
their
application
code
but
the
runtime
and
also
the
underlying
operating
system.
But
when
you
speak
to
developers,
we
we
don't
really
look
too
much
in
detail
into
the
actual
underlying
things
that
are
happening.
So
if
you
ask
someone
what
operating
system
is
actually
used
for
your
docker
container,
they
might
not
be
able
to
answer
so
touching
on
dockerfiles.
A
So
it's
a
way
to
outline
how
your
docker
image
is
constructed,
and
here
you
see
an
example-
that's
written
in
node.
So
overall
it
looks
fine,
it's
perfectly
filed.
It
does
what
it's
meant
to,
but
if
we
dive
a
little
deeper
into
it,
we
can
see
that
maybe
there's
some
questions
that
need
answered,
such
as
we
are
using
the
node-based
docker
image,
but
has
anyone
actually
checked
to
see
what
operating
system
that
runs
on?
A
One
downside
of
this
is
it
kind
of
increases
the
attack
surface,
so
there's
more
areas
for
attackers
to
attack
your
app
and,
lastly,
we
can
see
there's
no
user
defined,
so
this
container
will
run
with
root
by
default
and
depending
on
your
system.
This
may
mean
that
if
an
attacker
gets
into
your
container,
they
can
access
your
docker
host
and
maybe
spin
up
some
extra
containers
and
install
malicious
software.
A
Unfortunately,
container
security
is
more
of
an
afterthought
for
developers
and
I
don't
think
it
can
be
expected
for
all
developers
to
know
all
the
best
practices
and
in
the
night
of
docker,
as
you
can
see
here,
here's
like
a
summary
of
the
top
10
docker
security
practices.
That's
provided
by
snick.
You
can
see
the
link
for
yourself,
I'm
not
going
to
cover
all
these,
but
we
have
covered
some
of
them
in
the
previous
examples
and
I'll
show
how
build
packs
can
solve
all
these
problems
out
of
the
box.
A
Also,
some
haunting
statistics
also
provided
by
the
state
of
open
source
security
by
snik.
So,
as
you
can
see,
there's
a
list
of
the
most
popular
and
official
docker
images
and
there's
kind
of
some
scary
statistics
about
how
many
vulnerabilities
each
of
them
have
if
we
actually
look
into
where
these
vulnerabilities
come
from.
A
A
There's
also
an
important
concept,
which
is
bill
of
materials
which
is
actually
knowing
everything
your
app
pulls
in
and
it's
it
is
kind
of
difficult
to
keep
track
of
that
if
you're
not
using
some
open
source
tools
or
you're
not
actively
looking
for
it.
So
why?
Why
does
any
of
this
matter?
So
if
you
do
discover
a
security
vulnerability,
how
do
you
go
about
fixing
it?
A
They
also
have
probably
differing
ways
of
doing
things
for
every
team,
so
you'll
have
to
get
used
to
seeing
many
different
types
of
docker
files
and
because
of
the
way
docker
caching
works
once
you
make
a
change,
a
high
level
change
such
as
changing
the
operating
system
that
your
container
is
using.
It's
going
to
have
to
rebuild
the
entire
image.
So
this
could
be
quite
a
timely
and
lengthy
process
and
it's
really
more
of
a
chore,
whereas
you
could
be
doing
more
important
things
for
your
business.
A
So
is
there
another
way
and
another
way
is
using
build
packs.
So
what
is
buildpack
as
part
of
the
cloud
native
computing
foundation?
They
released
build
packs
in
2018.
It
was
mostly
started
by
heroku
and
pivotal
who've
been
using
it
on
their
platforms
for
many
years.
I
think
2011
is
when
hiroki
started
using
it
and
the
the
general
idea
is
that
it
takes
in
some
source
code.
It
detects
what
kind
of
app
it
is.
It
decides
how
to
build
it
and
it
gives
you
a
docker
image
and
the
key
difference
between
the
resulting
image.
A
The
main
advantages
of
this
is
we
have
reusability,
so
you
can
have
one
build
pack
for
all
your
apps.
So
if
you
have
20
java
micro
services,
you
just
need
one
build
pack
to
maintain
and
you
can
use
that
for
all
of
your
builds
as
well
as
that
you
have
fast
builds
because
you're
only
building
the
layers
that
you
actually
need.
So
it
accomplishes
this
by
rebasing,
which
we'll
cover
later
on.
We
can
also
do
modular
things.
A
So
if
you
have
a
an
app,
maybe
it's
a
react
front
end
and
java
back
in
you
can
now
have
a
build
pack
made
of
different
build
packs.
So
you
have
one
way
to
build
your
entire
stack
and
also
it's
safe.
So
if
you're
using
all
the
community
support
at
once,
they'll
have
all
the
latest
security
requirements
built
into
them,
and
also
you
have
the
option
to
build
your
own.
A
A
Now
it's
a
lot
more
simpler
because
we
were
saying
before
that
you
had
to
rebuild
entire
images
just
to
make
one
change,
but
with
build
packs
you
can
just
swap
out
individual
layers,
it
uses
rebasing.
So
it
allows
you
to
like
mentioned
just
do
one
layer
at
a
time
swap
it
out,
and
that
means,
rather
than
spending
weeks,
updating
all
of
your
apps.
You
can
now
do
it
in
minutes.
A
In
the
this
example,
we're
going
to
update
the
heroku
version
from
16
to
18,
and
we
can
just
do
that
by
replacing
a
single
layer
just
popping
it
out,
and
it's
done
in
one
place
and
now
it's
replicated
for
all
of
your
apps
and,
like
we
mentioned
with
dockerfiles,
we
would
have
to
do
this
for
absolutely
every
file.
So
every
code,
repo,
there's
a
list
of
more
advanced
features
that
I
never
I
haven't
covered
yet.
But
the
important
ones
to
call
out
is
bill
of
materials.
A
If
you
do
have
your
own
requirements,
you
can
build
your
own
I've
attached
a
link
here
as
well
with
extensive
documentation
if
you
do
want
to
get
started
as
well.
First
of
all,
you
just
set
your
default
builder
in
this
case
cloud
foundry,
and
then
you
can
just
run
packed,
build
to
build
your
app,
and
this
will
work
with
all
main
languages,
so
java.net
javascript
go
etc.
A
How
I
actually
got
into
looking
into
build
packs,
was
spring
boot.
2.3
brought
in
build
packs
and
played
around
with
it.
So
with
out
of
the
box.
It
just
provides
you
with
a
new
command
that
you
can
run
with
gradle.
It's
a
build
boot
image
and
I'm
moving
its
spring
boot
build
image
and
it
makes
use
of
piquito
build
hacks
and
allows
you
to
out
of
the
box
with
very
little
configuration
make
use
of
build
packs.
A
The
main
thing
I
noticed
about
this
was
actually
the
performance,
so
I
was
used
to
building
and
pushing
hundreds
of
megabytes
worth
of
images,
but
with
this
simple
change
it
got
down
to
kilobytes,
so
my
usual
build
would
take
minutes.
But
now
it's
just
taking
seconds
and
like
mentioned
before
for
other
frameworks,
I
highly
recommend
using
the
pacman
command
line
tool
and,
if
you're,
using
a
specific
platform,
whether
it's
roku
cloud,
foundry
or
google
cloud
platform,
they
provide
you
with
first
class
tools
and
build
packs
for
their
specific
platform.