►
Description
Cloud Native CD Pipelines with Tekton - Andrea Frittoli, IBM
Tekton is an open-source project for building cloud-native CI/CD pipelines and systems. It provides reusable and lightweight building blocks, such as tasks, that embody best practices. Tekton, hosted by the CD Foundation, aspires to be the common denominator in CI/CD.
Tekton gives developers full flexibility in how to set up their workflows.
In this talk, we will present how to get started authoring cloud-native delivery pipelines; we will dig into the Tekton resources used to implement the CD pipelines that build, release, and deploy Tekton itself.
Intro: (0:00)
What is Tekton: (0:25)
Plumbing: (5:38)
CD Pipelines: (8:00)
Demo: (14:13)
Lesson Learnt: (21:06)
Join us + References: (24:43)
Q&A: (25:15)
A
A
A
A
A
Techtune
comes
with
a
rich
set
of
tooling
as
well
like
a
web
ui
or
a
dashboard
for
browsing
through
your
pipeline
runs,
look
at
the
logs
and
so
forth
what
we
call
dkn,
so
the
cli
for
interacting
with
tecton
and
controlling
everything
about
tecton
and
finally,
an
operator
to
manage
installation
deployment.
Upgrades
of
techno.
A
We
also
have
a
catalog
in
the
hub,
which
is
about
providing
existing
building
blocks
for
creating
your
pipelines
and
discovering
them
through
the
app
and
consuming
them
in
your
pipeline
as
well
in
the
near
future,
and
also
we
run
a
number
of
experiments
like
dsls
on
top
of
tecton
and
providing
permanent
storage
and
ability
to
query
the
execution
history
of
your
pipelines
and
so
forth.
We
also
looking
at
the
supply
chain,
security
and
etc.
A
Then,
the
next
one,
which
is
an
extension
of
kubernetes
api
or
also
custom
resource
definition.
Crd,
is
a
task
and
the
task
is
a
sequence
of
steps
executed
within
the
same
pod,
so
they're
running
on
the
same
node
and
finally
pipeline
is
a
set
of
tasks
that
could
be
executed
in
sequence
or
could
be
executed
in
parallel
or
a
combination.
So
it's
a
graph
in
general.
A
So
tasks
and
pipelines
they
can
use
workspaces
for
storage
and
sharing
storage
between
tasks
within
the
same
pipeline.
They
come
with
input,
parameters
and
results
which
are
kind
of
the
output
parameters
of
tasks
and
pipelines.
So
all
this
is
about
the
static
definition
of
your
pipelines
and
then
to
actually
run
a
pipeline
or
a
task.
A
A
So
now
that
we
get
an
idea
of
what
tekton
is
about,
let's
look
into
plumbing,
why
do
we
call
it
plumbing?
First
of
all?
So
well,
if
you
look
at
the
dictionary,
plumbing
is
the
set
of
systems
and
pipes
and
so
forth,
basically
bring
tap
water
in
your
house
and
heating
and
other
services
like
that.
So
in
terms
of
tecton
infrastructure
with
plumbing
we
mean
the
set
of
services
and
software
and
configuration
that
are
used
to
provide
releases
and
building
and
testing
tecton
itself.
A
So
we
started
looking
into
what
we
call
dog
fooding,
using
tecton
for
building
releasing
releasing
and
testing
tecton
and
specifically
on
the
cd
side
of
things.
We
incrementally
build
and
added
functionality
for
having
nightly
and
full
releases
for
building
container
images,
both
on
demand
and
nightly.
A
A
So,
let's
dive
a
bit
deeper
into
the
city
pipelines
I
just
talked
about.
So
what
did?
What
do
they
look
like
so
the
setup
as
described
in
this
busy
diagram?
If
you
will,
but
let's
just
deconstruct
it
and
understand
what
what's
going
on
here.
So
in
the
middle,
you
got
the
the
city
pipelines
themselves,
so
the
top
one,
for
instance,
is
about
generating
90
nightly
releases.
So
this
is
a
pipeline
and
it
will
run
unit
tests
and
build
tests.
A
So
all
the
events
that
trigger
those
pipelines
are
generated
by
kubernetes
cron
jobs,
which
are
created
out
of
templates
using
customize
and
those
kubernetes
chrome
jobs.
They
send
a
json
payload
to
an
event
listener.
Here.
The
blue
box
that
receives
the
events
uses
a
filter
to
understand
which
cd
pipeline
we
want
to
trigger
it,
uses
bindings
to
extract
information
and
pass
it
into
the
templates
and
then
finally
run
the
pipeline.
A
So
tekton
can
generate
cloud
events,
events
and
cloud
events
for
everything
that
happens
about
task
runs
and
pipeline
runs.
So,
for
instance,
when
we
start
a
nightly
release,
while
we
are
completing
it,
whether
it's
successful
or
failed
cloud
events
are
going
to
be
generated
and
we
have
the
system
configured
so
that
all
the
events
are
going
to
one
single
sync,
which
is
a
yet
another
event
listener.
Here.
The
blue
box,
on
the
right
hand,
side
and
this
event
listener
what
it
does.
A
So,
with
this
setup
we
have
cloud
native
pipelines
that
are
schedulable
reusable,
because
we
can
have
multiple
configurations
for
each
of
them,
they're
kind
of
observable.
So
we
have
monitoring
in
place.
We
have
metrics
that
are
generated,
but
we
are
working
towards
making
them
more
properly
observable.
A
Are
they
interoperable
well?
This
is
the
the
aim
really
and
we're
working
with
the
sig
interpretability
sig
from
the
cd
foundation
to
define
a
shared
vocabulary
for
events
so
right
now
the
events
are
technical,
specific,
but
hopefully,
in
future
will
be
a
common
one,
so
they
will
use
a
common
dictionary,
and
this
should
allow
to
have
integration
between
tecton
and
other
solutions
in
the
cicd
space
from
the
cd
foundation
or
even
outside.
A
That
can
be
then
trigger
pipelines
across
different
platforms.
Are
they
testable?
Well,
let's
dive
into
that.
So
we
started
building
several
cd
pipelines
and
initially
the
process
was
create.
The
pipeline
maybe
bring
up
your
kind.
Cluster
locally
run
the
pipeline
there
and
see.
If
everything
went
well
or
in
some
cases
we
get
confidence.
So
we
try
to
change,
we
put
it
in
a
pr.
Oh,
it
looks
okay,
so
let's
deploy
it
and
then
maybe
it
works.
Maybe
it
doesn't
so.
A
So
in
the
middle
here,
in
this
case
we
have
our
ci
pipelines.
This
setup
is
similar,
just
in
this
case.
The
events
come
from
github,
so
developer
created
a
pr,
and
maybe
this
pr
includes
a
change
to
one
of
the
cd
pipelines.
So
there
is
a
number
of
filters
that
we
need
to
execute
to
validate
that
the
event
is
a
one
that
we
care
about,
and
it's
a
valid
one
and
it's
coming
from
a
user
that
we
trust,
for
instance,
because
we
don't
want
to
run
random
code
from
the
internet
someone's
submitting
a
pr.
A
A
If
it
recognizes
that
the
pr
is
about
trying
to
change
one
of
the
cd
pipelines,
what
it
does,
it
creates
a
new
name
space
in
the
cluster
and
it
deploys
a
copy
of
the
entire
cd
system
in
that
namespace,
and
this
copy
is
actually
out
is
created
out
of
the
definition
of
the
prss
of
the
cd
system
in
the
pr.
So
it
includes
the
cd
pipelines
as
defined
there.
A
So
this
is
a
step
two
and
then
we
have
another
task
that
waits
for
the
first
one
to
complete,
and
then
it
sends
a
trigger
using
a
cloud
event
into
the
event
listener,
so
the
entries
event
listener
in
the
new
namespace.
So
in
this
case
the
trigger
normally
is
sent
by
a
kubernetes
chrome
job.
But
here
we
can.
A
A
I've
got
my
kubernetes
cluster
here
on
ibm
cloud.
I've
got
a
full
replica
of
the
upstream
cicd
system
so
including
the
various
cd
pipelines,
and
I
can
look
at
those
pipelines
through
the
crown
jobs
that
trigger
them
and
for
this
demo
we're
going
to
use
the
conflict
map
cd
trigger
label,
sync
that
deploys
a
conflict
map
with
the
definition
of
the
labels
that
we
use
for
github.
A
Trigger
this,
with
a
trick,
just
using
cdl
create
job
from
the
chrome
job,
and
this
triggers
my
pipeline
on
demand,
which
is
really
handy
and
also
I
can
look
at
the
logs
of
recent
task
runs
and
you
can
see
one
was
started
just
nine
seconds
ago.
This
is
the
one
we
just
triggered
and
here
is
entire
log.
So
we
cloned
a
git
repo
and
set
up
a
cube
config
for
interacting
with
the
cluster,
and
then
we
made
a
diff
of
the
config,
but
it
doesn't
tell
us
much
more.
A
So
in
the
demo
I
showed
that
we
can
update
this
cd
pipeline,
make
it
a
bit
more
verbose,
useful
and
run
that
as
part
of
ci
without
merging
the
code.
So
we
can
see
the
pipeline
running.
We
can
check
at
base
the
way
we
want
to
want
to
and
then
after
the
code
is
reviewed
and
approved,
it
will
merge
and
it
will
actually
be
deployed
into
production.
A
So,
let's
have
a
look.
I've
got
the
branch
ready
for
that.
So
this
is
the
cd
pipeline
for
the
conflict,
map
deployment
and
yeah.
I'm
adding
a
step
to
greet
everyone
before
we
start
doing
anything
which
is
just
nice
and
then
adding
verbosity,
so
adding
the
positive
to
the
fetch
config
and
also
to
the
deploy
step
and
telling
whether
we
are
deploying
something
or
we
are
not,
and
I
got
a
second
branch
up
where
I'm
sorry,
the
same
branch
second
commit
where
I'm
adding
a
label,
so
we
can
see
something
being
deployed.
A
And
you
can
see
that
as
soon
as
this
is
pushed
there
are
pipeline
runs
that
are
started
in
this
tecton
ci
namespace,
which
is
where
ci
jobs
are
running,
and
we
have
tekton
yemenlink,
which
checks
for
validity
of
yaml,
and
then
we
have
a
few
jobs.
Dkn
build
hub,
cube,
cdl,
build
those
are
building
container
images,
those
are
started,
but
they
are
not
actually
going
to
be
reporting
anything
because
we
didn't
change
any
of
these
images,
so
you
can
see
they're
going
to
succeeded
completed.
A
So
that
means
that
this,
the
tasks
in
the
pipeline
are
actually
skipped,
and
then
we
have
two
pipelines
here
and
the
plumbing
test.
Tecton
cde
one
is
responsible
for
creating
a
new
namespace
and
deploying
the
entire
cd
system
into
this
namespace
from
the
pr,
as
things
are
defined
in
the
pr
and
then
the
second,
so
the
first
one,
cd
config
map
label
triggers
is
waiting
for
that
to
be
finished
and
then
triggering
the
city
pipeline
and
waiting
for
the
pipeline
to
finish
and
reporting
the
result.
A
A
And
so
we
can
switch
back
to
the
list
of
pipelines
and
you
can
see
again.
Yaml
lint
has
been
triggered
and
cube,
cdl
build
and
have
built
tk
and
build
have
been
triggered,
but
the
pipelines,
the
ci
pipelines
to
test
city
pipelines
have
not
been
triggered
because
the
user
is
not
authorized
and
we
can
go
and
check
what
happened
also
via
the
gita.
A
A
Instead,
it's
running
two
checks,
so
the
yaml
length
and
this
that
tested
the
cd
pipeline
was
successful.
Let's
have
a
look
at
it,
so
you
can
see
the
deploy,
conflict,
maps
tab
and
this
is
sending
the
trigger
to
the
newly
created
cd
system
and
extracting
the
event
id
and
then
it's
waiting
for
it
to
complete
and
it
gives
us
is
giving
us
a
link
as
well
to
the
where
we
can
follow.
A
The
cd
pipeline
has
been
executed
and
you
can
see
that
it
is
running
in
a
dedicated
namespace,
not
in
tekken
ci,
but
in
pr26,
which
matches
the
number
of
the
pr
that
was
created
here
and
yeah.
So
here
is
our
step,
our
gridding
step,
hello,
everyone
and
then
the
fetch
config
and
in
the
deploy
config.
You
can
see
now
it's
showing
the
diff
between
the
original
config
map
and
the
new
one
in
this
pr
and
yeah
config
detected
and
updating
it,
so
it
was
replaced.
A
A
What
did
we
learn
from
this
exercise?
Setting
up
the
cd
pipelines
well,
tectu
gave
us
really
full
flexibility
in
setting
things
up
the
way
we
want
it
and
it
allowed
for
incremental
implementation.
So
we
started
from
brow
and
manual
city
and
we
incrementally
added
functionality
and
moved
things
from
away
from
the
ci
side
from
proud
to
tactile,
but
still
the
two
coexist.
A
A
When
things
everything
that
we
manual
eventually
failed
and
then
we
started
automating
and
things
failed
as
well,
because
when
you
automate
and
then
there
is
churn,
you
change
things,
and
so
they
don't
behave
as
you
expected
to,
and
sometimes
this
is
down
to
documentation,
because
there
is
a
different
expectation
when
reading
the
code
of
the
behavior.
That
should
be
happening,
but
it's
also
very
important
to
plan
for
testing
and
monitoring
your
pipelines
so
that
you
can
see
the
changes
before
they
are
merged.
A
Also
running
ci
cd
and
cd
pipelines,
especially
using
tecton,
leads
to
so
many
resources
in
your
cluster.
All
the
runs
for
instance.
So
it's
very
good
idea
to
use
labels
and
some
of
them
are
set
up
by
tekton
natively
and
you
can
use
labels
to
filter
your
resources
to
search
for
them
and
you
can
create
deep
links
with
a
dashboard.
A
It's
also
a
good
idea
to
archive
logs
and
yamls,
and
this
is
the
we
have
an
experimental
project
for
that
and
to
clean
up
the
cluster
regularly
to
keep
it
clean
with
fewer
resources
in
place
and
also
we
realize,
when
building
cd
pipelines.
We
don't
have
everything
that
we
need,
so
we
need
more
functionality
from
tecton's
side
or
more
pipes
to
be
able
to
do
everything
that
we
want
to
do.
A
A
A
Hopefully
you
can
see
and
hear
me
so
thanks
for
joining
the
session
today.
So
there's
one
question
from
the
chat:
let's
start
with
that,
so
the
question
is
mainly
js
tool.
Calculator,
parallelism
based
on
info
on
the
proxy
view
info
I've,
just
any
thoughts
on
the
techno
project,
how
to
set
resources
to
tasks
and
pipelines.
A
A
We
have
the
ability
to
configure
resources
to
request
resources
they
can
be
set
for
the
steps,
but
in
general,
when
scheduling
a
task
on
a
node
or
task
run,
I
should
say
where
it
has
the
maximum
that
is
requested
by
any
of
the
steps,
because
steps
are
executed
sequentially.
So
we
just
want
to
take
the
largest
step
and
request
for
that,
and
so
that
is
the
amount
of
resources
that
you
can
configure
for
your
task.
A
A
A
I
mean
really
from
like
things
like
use
cases
if
you're
working
on
ci
cd
and
you
want
to
share
use
cases
of
features
that
you'd
like
to
have
or
yeah
so
infrastructure
like
the
dog,
fooling
that
I
talked
about
and
yeah
from
the
main
project.
So
if
you're
like
developing
a
goal
line
or
javascript
for
the
dashboard,
so
yeah
any
type
of
contributions
really
is
welcome,
so
feel
free
to
to
join
us.
Like
don't
be
shy
and
we
look
forward,
we
get
to
see
you
there.