►
From YouTube: Shipwright - What Happened in our First Year as a CDF Project - Sascha Schwarze & Enrique Encalada
Description
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
Shipwright - What Happened in our First Year as a CDF Project - Sascha Schwarze & Enrique Encalada, IBM
JW Grand Ballroom 4
Speakers: Enrique Encalada, Sascha Schwarze
Shipwright (https://shipwright.io) is a framework for declaring and executing container image builds in a Kubernetes cluster. It provides a pluggable architecture where common tools such as BuildKit, Buildah, or Buildpacks can be used in build strategies; and users define their build configurations based on them. In this talk we will give a quick introduction into the project. We'll describe how easy the installation has become with Shipwright being installable through OperatorHub. We'll see live how our new command-line interface makes it more convenient to get the first build going, and how it enables you to build from code that is on your local machine. Finally, we'll take a tour through a variety of new features in the backend that empower you to build more and secure images. Finally, we'll give an outlook on what's coming next.
A
A
A
A
All
right,
that's
cool,
because
today
we're
going
to
tell
you
for
the
ones
that
doesn't
know
too
much
about
shipwright,
I'm
going
to
give
you
a
little
bit
of
context
on
what
is
shipwright.
How
can
you
use
it
and
then
we
will
also
deep
dive
on
what
are
the
next
things
that
are
coming
for
the
project.
B
A
All
right
so
shipwright!
Well
sorry,
I
will
just
do
a
quick
recap
on
what
is
shipwright.
The
first
thing
is
that
shipwright
does
one
thing
well
and
that
is
actually
building
container
images.
I
I
typed
this
beautiful
high
code
today
for
you-
and
it
goes
like
this.
Shipwright
is
a
simple
approach:
code,
build
tools
and
instructions
to
build
your
image,
so
in
shipwright,
or
one
of
the
aims
of
shipwright,
is
really
to
simplify
the
experience
when
building
container
images
in
kubernetes
cluster
shipwright
achieved
this
in
an
efficient
and
secure
way.
A
If
you
would
like
to
use
shipwright,
you
probably
want
to
ask
yourself
three
questions.
What
do
you
want
to
build?
How
you
want
to
build?
Where
do
you
want
to
actually
push
your
image?
So
the
what
is
really
about
the
code?
Where
do
you
have
your
code?
Is
that
in
git?
Is
that
local
local
source
code
then
the
how
for
the
how
usually
in
shipwright
or
in
shipwrecked
idiomatics,
we
have
custom
resources
as
we
run
on
kubernetes,
we
have
something
that
is
called
the
build
strategy.
A
The
build
strategy
is
basically
a
resource
that
have
a
set
of
steps
that
will
tell
you
how
to
build
a
particular
container
image
under
the
hood.
Build
strategies
have
different,
build
tools
such
as
kaniko
builda,
ko
pakito
right.
So
as
a
user
to
answer
the
question,
how
you
can
easily
just
choose
one
of
these
build
strategies
that
we
make
available
for
you
in
the
cluster.
A
On
top
of
that,
you
can
define
different
instructions.
You
are
able
to
define
the
behavior
at
build
time.
Let's
put
an
example.
You
require
a
build
time
to
have
an
environment
variable,
so
you
can
define
that
through
the
different
shipwright
resources,
definitions
that
we
have
at
the
end
of
the
day,
a
shipwred
is
going
to
build
your
image,
as
I
have
in
the
last
sentence
of
the
haiku,
but
also
is
going
to
build
and
push
an
image
to
a
container
registry.
A
Keep
in
mind
that
shipwright
is
built
on
top
of
tecton.
So
if
you
will
do
a
deep
dive
in
the
mechanics
of
shipwright,
you
will
eventually
find
out
that
we
generate
tecton
resources
such
as
a
test
run
today.
Shipwright
is
on
an
alpha
state
and
we,
the
shipwreck
community,
have
been
discussing
on
moving
to
vita
in
the
next
months.
A
She
writes
she
practices,
not
only
the
technology,
so
she
practice
also
the
community,
and
that
will
be
my
main
focus
on
the
next
slides
sheep
right
community
is
a
community
of
doers
and,
as
fatigue
mentioned
yesterday,
shibra
graduated
to
the
city
foundation
as
an
incubation
project
back
in
august
2021,
I
can
give
you
a
little
bit
of
the
reasons
why
we
did
that.
One
of
the
reasons
was
we
were
looking
for
ownership
neutrality,
so
the
foundation
was
really
like
the
the
best
place
to
where
we
can
put
the
the
project.
A
In
addition,
being
part
of
the
foundation
also
have
benefits
for
us,
as
in
terms
of
visibility,
we
can
get
more
contributors
and
eventually
get
more
feedback
on
the
state
of
shipwrite
right.
So
let
me
just
tell
you
a
little
bit
about
the
shipwright
community
and
then
sasha
will
go
into
more
technical
details
or
what
is
coming
next
for
us,
the
shipwreck
community,
in
my
opinion,
is
unique.
The
shipwright
community
is
an
open
source
software
community
that
is
focused
on
trying
to
improve
the
experience
when
building
container
images
in
kubernetes
clusters.
A
There
are
three
key
things
of
this
community.
One
is
continuous
improvement.
That
basically
means
as
we
move
forward
as
a
community.
We
have
a
lot
of
github
repositories.
There
is
a
lot
of
things
that
we
need
to
work
on
there
so
that
we
can
improve
the
state
of
the
community
as
a
as
good
engineers.
One
of
the
key
things
is
automation.
A
We
try
to
avoid
doing
a
lot
of
the
manual
steps
and
we
favor
automation.
We
have
times
where
we
have
a
lot
of
issues
across
multiple
repositories,
pull
requests
and
technical
proposals,
and
that's
where
we
try
to
shorten
the
feedback
loop.
The
second
thing
is
that
shipwreck
is
really
a
sustainable
community
and
if
you're
interested
in
achieving
that
state,
you
probably
need
to
have
a
specific
set
of
things.
A
For
example,
contribution
guidelines,
code
of
conduct:
we
invest
a
lot
of
time
in
documentation,
so,
for
example,
if
you
go
today
to
the
shipwright
build
a
repository
at
first
glance,
you
will
understand
what
is
shipwright
and
you
will
also
be
able
to
use
it
in
an
easy
way.
If
you
are
more
interested
on
shipwright,
very
specific
details,
you
can
just
go
to
the
extensive
documentation
we
already
have
for
users.
The
last
thing
is
about
culture.
A
A
A
A
We
have
what
is
called
the
shipwright
improvement
proposals
that
are.
You
can
see
this
as
cool
ideas
that
the
community
are
working
on
in
order
to
enhance
the
the
shipwrecked
state.
So
we
we
increase
their
with
more
than
70,
and
also
all
of
these
proposals
are
already
implemented
as
part
of
the
shipwright
api.
B
B
B
B
The
second
thing
that
I
would
like
to
highlight
here
is
our
cli,
I
mean
so
back
a
year
ago.
It
had
always
been
a
pain
to
set
up
a
build
and
get
your
build
ones
going,
because
you
had
to
work
with
kubernetes
manifests
and
our
cli
is
greatly
simplifying
that
experience
and
I'm
going
to
quickly
show
that
in
a
video
I
have
to
say
something
upfront,
the
vendor
of
that
software
was
so
kind
to
introduce
kind
of
a
bug.
You'll
see
it
in
a
moment,
but
we'll
get
through
it.
B
So
so
we
are
here
in
our
cli
and
I'm
running
one
command,
which
is
the
shp,
build,
create
command,
and
when
you
see
the
things
that
go
in
there
as
arguments,
then
that's
exactly
what
enrique
mentioned.
So
you
see
which
source
is
being
built.
What
is
the
strategy
being
taken
build
kit
in
this
case
and
what
is
the
output
image,
meaning?
Where
do
we
want
to
push
the
image
to
and
that's
debug.
B
So
the
second
command
that
comes
here
is
shp
build
run.
Actually
one
of
my
favorite
commands,
especially
with
the
minus
minus,
follow
flag.
So
what
happens
here
is
that
the
cli
is
creating
a
build
one.
It
looks
for
the
part
that
is
being
created
and
subsequently
right
away
starts
tailing
the
locks
that
are
happening
there.
So
it's
just
like,
as
if
you
would
run
your
build
locally,
you
see
life
the
progress
and,
if
it
would
fail,
then
you
would
right
away
see
where
it
where
it
actually
hangs
and
that's
yeah
really
cool.
B
B
So,
to
give
you
a
few
examples,
we
have
one
build
strategy
which
is
based
on
ko,
so
that's
a
tool
to
build
a
container
image
for
for
your
go
code
and
there
you
need
to
specify
what
your
main
package
is.
One
use
case
for
which
we
introduce
parameters.
Another
example
is,
if
you
have
a
docker
file
and
you
have
arcs
in
there,
then
for
the
builds.
When
you
run
it,
you
need
to
specify
the
values
for
those
build
arcs
and
that's
the
story
behind
our
parameter.
Support
that
we
added
so
build
strategy.
B
Authors
can
now
nowadays
define
a
certain
set
of
parameters,
can
be
single,
values
can
be
arrays
and
build.
Users
can
then
specify
the
corresponding
values
for
them.
A
nice
feature
that
we
have
there
is
that
those
values
can
either
be
directly
specified
or
they
can
reference
a
config
map
or
secret,
so
that
you
can
also
reference
credentials
from
there,
depending
on
the
scenario.
B
Another
feature
that
we
shipped
just
last
week
with
our
order,
10
releases
volumes
and
that's
actually
a
great
enhancement.
I
really
like
it
so
I
mean
we
all
know
it
when
we
build
something
it
takes
time.
If
we
rebuild
something
and
we
do
it
locally,
it
typically
gets
fastest
because
compilers
reuse,
some
of
the
things
that
it
compiled
previously.
B
If
code
wasn't
changed
there
in
certain
packages
etc,
or
if
you
think
about
a
dockerfile
based
strategy,
then
layers
if
things
were
not
changed
and
the
sources
can
be,
can
be
cached
and
do
not
need
to
be
rebuilt,
and
for
that
we
now
introduce
volume,
support
so
build
strategy.
Authors
can
define
certain
volumes
and
they
can
define
them
as
overrideable,
and
then
the
build
user
can
plug
in
a
persistent
volume
to
make
use
of
it
and
then
potentially,
depending
on
the
strategy.
The
bids
get
faster.
B
We
actually
so
far
for
last
week's
release
only
enabled
the
ko
build
strategy.
But
it's
just
amazing
to
see
that
if
we
build
with
ko
our
own
shipwright
build
controller,
then
the
first
bit
takes
one
minute
40
just
for
the
compilation
step
and
the
rebuild
is
then
done
in
two
seconds.
I
mean
that's
how
gocash
actually
works,
and
it's
nice
that
we
can
now
exploit
this
also
in
shipwright
builds.
B
The
second
feature
that
I'm
having
here-
and
we
can
mention
it
already
briefly-
is
local
source
support.
So
traditionally
we
were
able
to
load
the
source
code
for
the
images
that
you
want
to
build
just
from
from
a
git
repository,
but
we
recognize
that
as
a
developer,
you
do
not
always
want
to
push
every
single
change
when
you
are
iteratively
trying
something
out
to
a
git
repository
just
to
run
than
the
build.
B
So
what
we
enabled
is
local
source
support
and
that's
a
really
cool
feature
that
I'm
going
to
show
in
a
moment
after
I'm
saying,
obviously,
there's
way
more
features
that
we
added
in
the
past
year,
I'm
just
mentioning
two
of
them,
so
we
enhanced
our
the
status
of
our
build
one
resource
you
can
find
now
there,
the
sha
of
the
commit
of
the
source
that
was
built.
You
find
the
digest
of
the
image
that
was
built
in
case
of
arrows.
B
B
But
let
me
just
continue
so
the
build
one
at
some
point
comes
to
the
source
tab
where
it
doesn't
clone
the
source
anymore.
Instead,
it
is
going
to
wait,
and
now
the
cli
is
going
to
stream
the
sources
into
the
pod.
What
it
technically
does
another
cover
it
uses
what
you
know
from
cube:
ctrl,
cp
or
cube
ctl
exact.
B
There's
one
downside
in
that
approach,
and
that
is
that
you
require
the
permission
to
do
a
cube.
Ctl
exec
certain
administrators
might
not
want
to
give
you
that,
because
I
mean
in
production
systems,
it
would
enable
you
to
make
modifications
to
also
application
processor,
which
you
might
not
want
to
allow.
B
B
The
cli
is
going
to
package
the
source
code
into
what
we
call
a
source
bundle
and
it's
going
to
push
that
into
a
container
registry
and
then
the
build
one
is
going
to
pull
it
from
there.
The
image
is
not
runnable.
It
just
contains
the
source
code,
so
the
running
build
one
pulls
it
from
there
extracts
it.
Optionally
deletes
the
source,
bundle
container
image
from
the
registry
and
continues
obviously
has
another
carriage.
You
shouldn't
be
doing
that
with
a
public
docker
repository,
because
your
source
code
would
then
land
there.
B
B
So
let's
have
a
look
at
the
road
map,
so
one
cool
feature
that
we
are
working
on
at
the
moment
is
what
I
call
image
post
processing.
So
when
I
describe
build
strategies
and
and
because
that
quite
similar
things
then
I
usually
say
a
build
strategy-
defines
the
steps
to
turn
source
code
into
a
container
image.
B
The
downside
of
that
is
that
shipwright
didn't
have
any
handle
on
the
image,
and
now
we
are
going
to
change
this,
so
we
are
doing
some
slide
api
extensions
and
then
build
strategy.
Authors
can
basically
just
build
the
image
and
store
it
in
the
file
system
and
then
shipwright
is
going
to
take
over
and
push
that
image.
B
This
alone
doesn't
have
too
much
value,
add
to
the
users,
but
in
it
enables
the
scenarios
that
I'm
going
that
I'm
listing
here.
So
we
will
be
able
to
do
a
vulnerability
scan
of
the
image
that
you
just
built
even
before
it
gets
pushed
so
really
the
earliest
time
we
are
looking
at
creating
software
bill
of
materials
for
the
image,
with
all
the
content
that
is
in
there,
and
we're
also
going
to
look
at
signing
the
image,
and
I
mean
security
and
compliance
wise.
B
That's
all
really
interesting
topics
enrique
also
mentioned
the
triggers
project,
which
is
quite
brand
new.
So
as
of
today,
when
you
want
to
get
a
build
one
going,
you
need
to
create
a
build
one
by
yourself.
Either
cube
cgl
apply
with
a
with
a
manifest
or
using
the
magic
cli
commands
that
I
had
shown,
but
as
of
today,
there
is
no
automatic
way
to
get
a
build
one
started,
but
we
see
many
scenarios
and
we
are
going
to
tackle
that.
B
B
Think
of
that
you
build
your
base
image,
you
have
one
build
which
builds
your
base
image,
and
then
you
have
several
micro
services
where
you
build
your
application
images
that
depend
on
that
base
image.
So,
when
your
base
image
build
finishes,
you
actually
want
your
application.
Image
builds
to
be
restarted
so
that
they
pick
up
the
new
base,
image
and
leverage.
It
that's
the
scenario.
B
Finally,
and
we
can
mention
that
we
are
based
on
tacton
and
we
are
also
looking
at
better
integrating
with
tacton.
So
in
tecton
there
is
a
concept
which
is
called
custom
tasks
which
you
can
have
in
a
tecton
pipeline,
which
means
that
one
task
in
there
is
implemented
externally
the
corresponding
concept.
There
is
also
called
a
rundom
at
runtime
and
we
are
going
to
provide
custom
task
support
so
that,
basically,
a
build
becomes
part
of
a
tecton
pipeline,
a
really
nice
integration
to
basically
make
the
picture
a
little
bit
more
complete.
B
Another
sub
project
that
we
started
is
the
image
sub
project
and
that
actually
extends
the
scope
of
shipwright.
So
far,
we
always
end
when
the
image
got
pushed
to
the
container
registry
with
the
image
subproject.
We
are
going
to
take
care
of
the
container
image
even
further,
so
with
that
the
image
will
become
a
first
class
resource
that
you
can
create
in
your
kubernetes
cluster.
B
B
That's
not
enough
operating
system,
libraries
become
vulnerable
code
dependencies
become
vulnerable,
so
we
actually
need
continuous
scanning
for
vulnerabilities
and
with
the
image
subproject
that
could
become
possible
so
that
we
continuously
rescan
the
image
to
see
if,
in
the
meantime,
there's
a
vulnerability
in
it,
and
maybe
we
eventually
don't
just
trigger
a
new
build
one
to
get
it
mitigated
if
it's
in
in
some
of
the
base
layers
and
yeah,
there's
also
a
scenario.
So
one
of
those
images
could
also
be
one
that
you
didn't
build
with
shipwright.
A
A
B
A
A
One
of
the
most
relevant
things
is
tomorrow
we're
going
to
be
running
our
first
official
shipwright
community
summit.
So
I
encourage
you
to
scan
the
qr
code,
so
there
you
will
find
more
information
on
our
website,
but
it's
going
to
be
between
2
to
5
p.m,
local
time,
cdt
and
it
will
be
on
in
room
209
for
the
folks
attending
virtually
on
the
website.
You,
you
will
find
a
link
to
the
to
the
zoom
session
for
tomorrow
right.
A
B
B
Okay,
so
the
question
was,
which
kind
of
triggers
we
are
going
to
support
and
if
there
is
a
relationship
to
the
already
existing
tact
on
triggers
project.
So
we
had
long
discussions
in
the
community
also
a
long
time
ago,
whether
we
should
reuse
tacton
triggers,
but
we
concluded
that
we
wouldn't
do
that.
So
we
are
establishing
our
own
triggers
project
with
inbound
webhook
to
receive,
for
example,
events
from
github
and
with
a
controller
that
takes
care
of
other
scenarios
and
yeah.
B
B
So
what
we
think
makes
sense
is
that
you
that
we
react
when
a
commit
is
pushed
to
the
branch
that
the
build
is
configured
for.
We
think
it
makes
sense
if
there's
a
pull
request
open
for
that
branch
to
react.
Obviously,
you
will
be
able
to
define
what
what
you
actually
want
as
a
trigger
in
in
your
build
definition,
but
we
won't
react
on
creation
of
an
issue,
for
example,
so
I
mean
it
will
be.
It
will
be
those
events
that
we
think
makes
sense.
B
B
What
was
the
third
one
I
had
on
the
list?
You
don't
remember
perfect.
Okay,
he
didn't
listen.
The
triggers
project
will
also
take
care
of
that
custom
task
implementation,
so
we
can
become
part
of
a
pipeline
and
yeah.
The
thing
which
I
mentioned
under
image.
Also,
that
is
not
really
defined
at
all,
because
both
projects
are
new,
so
that's
just
existing
as
an
idea.
So,
basically,
if
an
image
that
is
managed
by
the
image
project
gets
an
update
that
the
build
one
can
be
triggered.
B
Yeah,
so
it
actually
depends
on
the
tool
that
you're
using
meaning,
which
builds
for
the
g
use.
As
of
today,
in
our
sample
build
strategies,
we
are
having
two
build
strategies
which
are
supporting
cross
platform
builds
already.
Those
are
build
kit
and
ko
among
other
strategies.
It
always
depends
on
the
tool.
Like
I
mean,
if
you're
using
kaneko,
you
won't
ever
build
an
arm
image
when
you're
running
on
amd64,
but
obviously,
if
shipwright
your
kubernetes
cluster
is
running
on
arm64,
then
kaneko
will
also
build
an
arm64
image.
B
A
support
that
we
don't
have
is
I
mean
you
could
theoretically
have
a
kubernetes
cluster
with
a
mixture
of
nodes
that
are
on
different
platforms,
so
we
don't
provide
any
selection.
As
of
now
that
you
could
specify
hey
run
this
build
one
on
a
node
which
is
arm
64
and
another
one
on
on
amd64.
So
that's
something
we
we
don't
have
at
the
moment.