►
Description
Don’t miss out! Join us at our upcoming events: EnvoyCon Virtual on October 15 and KubeCon + CloudNativeCon North America 2020 Virtual from November 17-20. Learn more at https://kubecon.io. The conferences feature presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Why We Are Choosing Cloud Native Buildpacks at GitLab - Abubakar Siddiq, GitLab
GitLab provides a zero configuration build/test/deploy pipeline called "Auto DevOps" which relies on Herokuish for detecting how to build/test your source code into a runnable docker image. Currently, GitLab uses Herokuish to match projects with known languages and build them. The new tooling from CNB is capable of building smaller resultant images by separating the build layers from the runtime layers. In order to increase the speed and efficiency of GitLab's products, the Product team investigated the Cloud Native Buildpacks, which provide a cloud-native means of standardizing code detection and producing a standards-based container runtime. In this talk, learn about GitLab’s goals, plan, and how they made the decision to move forward based on the greatest benefit to GitLab from CNAB - the larger community fixing CNAB issues.
https://sched.co/ZetC
A
First,
what
is
buildbox
buildpacks
are
basically
used
to
convert
code
to
a
compiled
code
or
any
generated
asset
that
can
be
used
to
automatically
detect
what
the
code
is
in,
which
language
is
written
and
get
the
necessary
dependencies
on
binary
is
required
to
compile
it
to
the
compiled
code,
and
this
was
first
initiated
by
heroku.
This
is
an
example
of
a
flow
of
how
it's
done
once
a
developer
pushes
their
code
to
probably
a
code
hosting
platform
or
anywhere,
and
the
ci
picks
it
up.
A
It
checks
first
using
a
build
pack
to
see
okay.
What
language
is
this
reason?
If
it's
ruby
or
it
sees
a
gem
file,
it
automatically
builds
the
application
using
the
specified,
binaries
and
images
that
have
been
compiled
and
used
to
run
the
application.
Then
it
deploys
it
to
the
right
place
for
it
to
run.
Then
here's
an
example
here
what
I
just
described
it
first
checks
is
the
ign
file.
Okay,
then
it's
definitely
a
ruby.
Then
every
dependency
needed
based
on
the
gem
file
is
used
to
compile
the
application.
A
Now
and
the
basic
logic
it
uses
based
on
the
heroku,
build
pack
for
ruby,
is
it
checks?
Basically,
if,
as
you
can
see
here,
based
on
the
detective
file
that
is
included
in
the
heroku's,
build
pack
for
ruby,
does
this?
Can
it
find
a
gem
file?
If,
yes,
then
it's
definitely
ruby?
If
not
it's
not.
Basically,
almost
every
ruby
application
has
a
check
file.
A
Now,
as
buildpack
has
evolved,
everyone
saw
the
benefit
in
being
able
to
ease
the
work
of
the
developer
in
detecting
the
language
they've
used
to
build
their
applications
and
using
the
necessary
dependency
to
build
them
in
ci
and
deploy
pivotal
created
their
own
cloud.
Foundry,
build
packs
and
eric
to
have
this,
and
this
led
to
because
there
is
most
of
it
is
proprietary.
You
can
only
use
it
on
your
platform.
A
The
rest
of
us
are
basically
left
with
hero.
Krish
heroquish
is
an
open
source
version,
which
largely
depends
on
heroku
build
packs.
So,
basically,
what
happens
is
it's
used?
It
has
already
taken
all
the
necessary
runtime
and
of
heroku
emulates
them
and
uses
hero,
supported,
build
packs
to
now
build
the
application
and
run
it
comes
in
a
binary
file
or
you
can
deploy
it
using
docker.
A
Now
then
came
in
clarity,
build
packs,
pivotal
and
heroku
desire
to
bring
all
the
all
the
power
and
experience
they've
gathered
together
from
the
running
club
cloud.
Foundry
builder,
build
packs
and
also
running
heroic
boosted
fox
for
quite
a
long
time
bringing
all
the
learnings
and
the
failings
then
decided
to
create
an
open
source
cognitive,
build
packs
which
will
make
it
much
more
easier
for
almost
everyone
who
wants
to
use
fuel
packs
and
gladly
it's
under
the
cncf.
A
A
Security
is
when
images
are
created.
There
are
possibilities
of
privilege
exclamations
due
to
the
possibility
of
having
privileged
containers
now
and
also
we
have
faster,
builds
and
image
layer
rebasing.
What
this
means
is
when
the
the
build
box
has
majorly
two
things
that
it
uses
to
build.
The
images
first
is
the
builder
which
contains
all
the
necessary
runtimes
and
routines
that
is
necessary
to
build
the
application.
Then
we
have
the
pax
cli,
which
is
used
to
pack
the
applications.
A
A
Now,
clarity,
build
packs,
has
a
life
cycle
first
thing
when
a
code
is
deployed
to
probably
by
the
ci
platform
or
any
of
any
way
the
platform
is
being
used.
The
first
step
for
a
builder
is
to
detect
what
type
of
application
is
this
based
on
the
example
of
heroku
that
we
saw
earlier
it
checks
if
there's
a
gem
file.
If
there
is
this,
is
definitely
a
ruby
application,
then
it
analyzes
the
code
to
determine
what
are
the
necessary
dependencies
that
this
application
needs.
A
A
Now
the
in
at
gitlab.
One
of
the
major
features
that
we
have
is
our
auto
devops,
which
allows
you
to
just
push
your
code
without
necessarily
declaring
a
ci
file
or
setting
up
the
configuration
of
how
your
cih
will
run
and
gitlab
will
automatically
detect.
Okay,
what's
the
programming
language,
this
is
in
what
are
the
dependencies?
A
It
requires.
What
are
the
tests
that
has
been
written
for
is
to
run
then
it
runs
off
of
them
drugs.
All
of
the
testing
deploys
to
staging
for
you
if
you
have
staging
already
configured,
deploys
to
production
and
even
do
all
the
necessary
performance
tests
and
runnings
that
you
want
to
do
so.
For
example,
in
the
image
we
have
here,
we
can
see
that
it
has
a
build
job.
It
has
test
jobs,
checkbook
quality,
do
sas
security,
analysis,
testing
and
so
on
and
so
forth,
and
moves
to
staging
production
and
performance.
A
A
A
A
The
main
reason
is
because
one
we
need
when
using
auto
devops
and
because
most
of
this
happens
over
the
internet,
the
amount
of
data
that
is
consumed
in
building,
rebuilding,
pulling
images
and
so
on
is
enormous
and
image
sizes
tend
to
grow
as
along
the
line
in
the
ci
pipeline.
So
one
of
the
reasons
that
we
want
that
we
are
switching
to
quantitative
view,
parts
is
to
make
the
image
sizes
lesser,
with
image
repeats.
Like
I
mentioned
earlier,
then
faster
builds
once
the
rebase
can
be
done.
A
A
Ordinarily,
in
the
auto
devops
example,
I
shared
earlier
by
default
simply
just
uses
herokush,
and
it
builds
everything
without
you
having
to
specify
your
gitlab
that
ci
yaml
file.
That
is
the
file
you
use
to
specify
how
ci
should
run
and
how
the
deployment
should
be
done,
but
to
enable
it
at
the
moment
it's
obtaining
clarity,
build
packs.
It's
we
are
still
improving
it
and
building
it
more.
A
But
at
the
moment,
if
anyone
wants
to
use
it,
they
will
have
to
opt-in
by
creating
a
costume,
gitlab
cr
file
and
specifying
that
they
are
still
using
the
autodevops
templates
that
we
use
for
them
automatically,
but
with
just
some
modifications,
and
those
modifications
is
by
specifying
that,
okay,
so
for
the
build
stage
of
the
ci
pipeline,
you
want
to
use
declarative,
build
packs.
So
an
environment
variable
has
to
be
declared
by
saying
autodevops
build
image,
cnb
enabled
specifying
it
as
one
and
also
specifying
the
image
it
will
use.
A
As
shown
in
the
in
my
slide
here
now,
once
you
specify
that
during
the
build
stage,
the
ci
job
will
not
use
heroku,
it
will
use
the
clarity,
build
packs
to
build
everything
and
move
it
along
this
stage
now,
but
there's
just
one
drawback,
which
is
one
of
the
advantages
of
using
herokuchi
that
it
has
built
back
tests
which
we
use
extensively
in
our
auto
test.
Job
and
clarity,
build
packs
only
currently
comes
with
builds
and
reviews
commands.
A
So
because
this
is
important-
and
we
feel
other
members
of
the
community
also
need
this,
and
they
will
be
benefit
from
this
as
as
the
project
grows
now.
This
is
basically
how
we
currently
use
build
packs
for
our
auto
devops
jobs,
so
I'll
be
showing
you
a
demo
of
an
example
of
how
one
can
opt
in
and
use
cloud
native,
build
packs.
A
Now,
first,
I've
already
prepared
the
demo
to
save
time
and
I'll
be
showing
you
screenshots
of
some
of
the
results
from
the
demo
in
the
image
here
you
can
see
that
I
have
a
sample
project
sample
ruby
project
that
has
a
rig
file
and
a
gem
file,
so
yeah,
it's
just
included.
The
gitlab
ci
file
was
included
subsequently
after
enabling
cmv,
but
by
default
it
doesn't
come
with
a
class
ci
file.
A
A
Autodevops
then
sees
the
project
sees
a
gem
file,
uses
herokush
to
detect
the
programming
language
to
be
ruby
and
it
starts
to
build
job,
creates
jobs
for
the
test
stage
production
at
the
performance
stage.
Now,
on
the
second
slide,
I'll
be
showing
you
in
the
ci
log.
As
you
can
see
here
in
the
first
red
box,
it
clones
the
glider
labs,
heroic
image,
and
it
uses
that
in
the
second
box
to
now
run
herokuchi
buildback
build.
This
is
by
default,
those
when
not
using
cloud
native,
build
packs.
A
Now
the
next
thing
here
is
in
the
gitlab
ci
file.
We
created
the
custom
gitlab
ci
and
specified
that
okay,
we
are
still
using
the
autodevops
template,
but
we
want
to
enable
cloud
native,
build
packs
by
specifying
the
environment
variable
setting
it
to
one
and
also
specifying
the
image
to
be
used
once
this
is
done
in
the
build
stage
instead
of
using
heroquish
this
time
it
switches
to
building
with
the
cognitive
build
packs.
A
Now
it
pulls
the
image
once
it
does
that,
then
it
uses
the
the
heroku
open
source,
build
packs
for
cognitive,
build
packs.
As
you
can
see
online
251
here,
then
it
uses
that
and
downloads
the
the
open
source
version
of
the
heroku
pack
also
to
detect
the
language
that
the
project
is
used
in,
which
is
here.
You
can
see
here,
it's
ruby.
It
takes
a
profile,
then
it
analyzes
the
code
with
for
all
the
necessary
dependencies
and
information
that
it
needs
and
it
proceeds
to
combine
it.
A
So
basically,
git
lab
as
a
company
uses,
auto
devops
or
has
auto
devops
as
a
feature
for
our
customers
and
for
our
users
to
be
able
to
build
straight
from
idea,
move
from
straight
from
idea
to
production
without
little
to
no
intervention,
giving
developers
more
productivity.
But
we
can
only
achieve
this
with
buildbacks
and
with
hero
and
from
the
beginning.
A
Hi
everyone.
Thank
you
very
much
for
joining
this
session
and
yeah.
I
will
be
answering
a
few
questions
that
have
been
coming
in.
I
think
one
of
the
major
ones
that
have
been
asked
is
how
does
cognitive
build
packs
relates
to
cloud
native
application,
build
packs
yeah.
They
are
two
different
projects
and
of
the
top
of
my
head.
I've
not
really
used
quantitative
application,
build
packs
much,
but
based
on
the
things
I've
read
previously.
A
Also
christian
was
asked
at
the
time.
How
do
these
build
packs
relates
to
private
platform,
rebuild
packs?
Like
I
said
in
the
presentation
there
was
here
computers
packed
separately.
Then
there
was
the
private
view,
packs
separately,
most
of
which
were
proprietary
at
cognitive.
Build
packs
was
an
effort
that
came
after
both
companies
decided
to
standardize
an
open
source
build
packs.
A
Also,
there
is
how
does
cnb
compare
with
red
hat's
source
to
image
used
in
point
shift.
I've
not
really
used
source
to
image,
so
I
won't
be
able
to
give
the
honest
comparison
of
of
it
with
the
quality,
buildblocks
yeah.
Okay,
I
think
that's
most
of
the
questions
that
have
been
posted.
Okay,
I
have
more
here:
is
it
possible
to
disable
over
a
specific
job
in
the
build
pack
using
gitlabs,
yeah
yeah?
I
just
I
just
want
to
add
more
information
about
our
twitter
develop.
It
is
highly
customizable.
A
You
can
even
go
as
fast
because
we
are
the
auto
devops.
Ci
first
are
more
or
less
templates
that
we've
created
to
be
language,
agnostic
and
work
with
almost
any
language,
so
you
can
customize
it
as
much
as
you
want
change
the
images
that
are
being
used.
You
can
decide
to
package
your
own
images.
You
can
decide
to
even
decide
to
not
use
them.
Just
pick
a
couple
of
things
in
them
and
use
your
own
park
cli
directly
in
your
ci
job.
A
How
does
an
upstream
should
use
build
packs
to
patch
this
os
image?
So
I
think
I
don't
have
much
information
about
this,
but
I
can
definitely
share
more
in
the
slack
channel,
but
I
think
majorly
as
at
now
the
two
major
functionality
that
build
pack
has
it
allows
you
to
build
and
it
allows
you
to
rebate.
So
I
think
probably
your
basin
might
be,
maybe
guess
a
little
bit
of
the
top
of
my
head.
A
You
basically
might
be
an
answer
to
this,
but
I'll
look
this
up
and
provide
more
answers
to
it
in
the
slack
channel
yeah
the
snack
channel,
for
this
is
case
studies,
yeah,
cube
current
case
studies,
but
you
can
also
drop
into
ask
more
questions
about
two
devops
and
most
of
our
engineers
are
on
the
gitlab
channel.
So
you
can
ask
more
christian
step
so
any
more
questions
from
anyone
keep
while
christians
come
in.
I
think
I
still
have
some
time
yeah.
A
Basically,
since
the
recording
of
the
call
I
we've
added
more
new
features
to
the
way
we
use.
If
you
noticed
in
this
slide
earlier,
you
have
to
specify
the
image
to
use
for
build
packs,
but
now
it
has
been
baked
into
the
onto
a
devops
templates.
You
don't
need
to
specifically
specify
an
image
to
use
when
you
want
to
use
clarity,
build
packs,
and
previously,
after
the
recording
with
discussions
among
some
people
in
the
industry,
must
have
asked
okay.
A
Why
do
you
still
want
to
stick
to
herokuish
and
so
on
when
there
are
probably
other
ways,
tests
can
be
achieved
with
quantitative
impacts
and
the
major
reason
why
we
are
still
sticking
with
heroku
for
now
is
because
we
want,
we
don't
want
anything
to
be
consumed
in
the
templates
that
we
provide
as
a
company.
We
want
it
to
be
language
agnostic.
You
can
just
we
want
simply
when
you
are
using
autodevops
to
just
push
your
code
and
it
detects
and
it
builds
without
any
customization.
A
Okay,
a
question
just
came
in.
Is
there
a
possibility
to
create
own
buildback
and
share
with
the
community?
Of
course
you
can
create
as
much
as
you
want
the
builders
and
share
and
within
your
application
you
can
always
specify
a
builder
to
use
in
my
you
can
check
my
slide.
Subsequently,
you
will
notice
in
this.
A
So
I
still
have
like
two
minutes,
but
if
we
are
unable
to
answer
all
the
questions
here,
just
like
I
said
earlier,
you
can
ask
more
questions
in
the
case
to
this
track
channel
and
also
you
can
ask
more
questions
about
other
things.
We
do
around
autodevops,
especially
with
other
stage,
because
this
is
focused
more
on
the
build
and
test
stage
of
employment.