►
From YouTube: Intro: Brigade - Radu Matei, Microsoft
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
Intro: Brigade - Radu Matei, Microsoft
Brigade is a lightweight, Kubernetes-native framework which allows the creation of event-driven workflows. Using JavaScript, Brigade chains together containers and controls their execution in an in-cluster scripting environment that enables easy error handling and data sharing. In this session, you will learn how to get started with Brigade, how to use the existing GitHub, CloudEvents and generic event support and integrate them in your workflow, and how different companies are using Brigade to automate their internal workflows (from code quality assessment and security scanning, to automatically generating preview environments for each pull request), and ultimately allow teams to build massively distributed workflows using a few lines of JavaScript.
https://sched.co/N7PI
A
A
So
one
analogy
that
really
helped
me
when
I
was
getting
started
with
kubernetes
when
I
tried
to
understand
how
it
operates
was
that
of
a
cloud
operating
system?
Yeah,
don't
take
it
way
too
far,
the
analogy,
but
for
for
a
simple
reason
in
it
holes
write
an
operating
system
manages
the
application,
the
processes
on
a
single
machine,
while
kubernetes
manages
containers
on
a
cluster
of
machines
right.
A
So
taking
the
analogy
of
a
step
further
then
think
about
operating
system,
shell
scripting
think
about
bash
powershell
or
any
other
scripting
environment
that
you
use
on
an
operating
system.
What
that
does?
It's
simply
flow
control
that
wraps
the
execution
of
some
processes,
but
doesn't
have
an
opinion
on
what
the
process
is
actually
running
right
or
what
it's
supposed
to
do,
or
how
it's
supposed
to
run
so
think
about
this
simple
example,
because
we
have
a
real
programming
language
bash.
A
In
the
six
scenario,
we're
able
to
start
processes
like
LS
echo,
start
processes,
listen
for
them
loop
over
the
results,
wait
for
it
to
finish,
get
the
result
of
the
first
process,
which
is
list
and
pass
it
as
argument
for
the
next
process
right
and
using
bash
were
able
to
actually
put
together
some
really
interesting,
the
flow
of
programs
right
so
taking
the
analogy
to
the
two
kubernetes
as
an
operating
system.
What
would
a
cluster
of
shell
scripting?
Look
like
right,
so
we
take
the
same
definition
and
we
try
to
substitute
processes
with
containers.
A
So
I
would
like
to
do
something
like
this
right
for
each
result,
in
the
execution
of
one
part
of
a
container
I
want
to
get
that
result.
I
want
to
loop
over
it
if
the
exit
code,
for
that
is
success
or
is
failure,
I
want
to
do
something
else.
I
want
to
do
something
else.
Right
I
want
to
pass
some
storage,
a
persistent
volume
from
one
and
also
use
it
in
a
different
scenario.
A
So
I
want
to
do
things
that
I,
wouldn't
normally
do
in
a
scripting
environment,
but
in
kubernetes
and
the
main
question
is:
how
do
people
do
that
today
and
what
I've
seen
at
least
is
one
is
executing
shell
scripts
in
busybox
or
executing
shell
scripts
when
they,
where
they
do
queue,
control
exact.
They
wait
for
that
to
finish
they
do
some
grep
and
then
search
for
some
strings
that
they
want
to
pass
over.
That
is
not
maintainable.
That
is
not
testable
and
we
want
something
else
right,
and
this
is
where
Brigade
comes
in.
A
So
what
is
Brigade?
First
of
all,
it's
a
CNC
F
project,
we're
really
happy
to
be
a
CNC
F
cloud
native
computing
foundation,
sandbox
project
and
essentially
it's
a
framework
for
event-driven
scripting
on
kubernetes
and
over
this
talk
we'll
try
to
get
to
each
part
of
that
of
that
definition,
it's
extremely
lightweight
and
it's
built
on
kubernetes.
It's
actually
a
kubernetes
application,
it's
made
of
deployments
and
services
right.
A
So
think
again
about
this
scenario
and,
let's
think
about,
let's
imagine
how
a
cluster
shell
stripping
environment
would
look
like.
The
first
question
is:
will
we
the
programming
language
right,
because
if
anyone
I
said
it
before,
if
anyone
tried
to
write
a
for
loop
in
llamo,
that's
not
ideal
right.
You
want
to
actually
have
a
real
programming
language
where
you
can
loop
and
for
and
actually
reason
about
the
thing
that
you're
executing
second:
how
do
we
share
data
between
the
containers
that
we're
starting
right?
A
We
are
on
kubernetes,
so
we
kind
of
have
an
idea
about
how
we
should
do
that
and
we
I
think
we
want
to
maintain
that
expectation
and,
ultimately,
when
are
we
supposed
to
actually
start
the
scripts?
What
should
trigger
them?
So,
first
of
all
choose
a
language
don't
write.
One
people
in
our
team
would
be
absolutely
delighted
if
we
got
to
actually
write
our
own
programming
language
right,
not
always
ideal
right,
it's
better
to
choose
an
existing
language.
That's
first
of
all
popular
has
adoption
and,
most
importantly,
has
a
low
barrier
of
entry.
A
A
It's
it's
the
programming
language,
that's
arguably
the
easiest
to
get
started
with,
and
it's
really
one
of
the
most
popular
programming
languages
out
there.
Second
of
all,
it
has
a
rich,
very
rich
ecosystem
and
by
ecosystem
I
mean
lenders
unit
framework
unit
testing
frameworks.
It
has
type
checking
with
typescript
and
has
a
lot
of
NPM
packages
and,
at
the
end,
it's
extremely
flexible.
A
We
want
to
make
it
easy
for
new
users
to
get
started
right,
but
at
the
same
time
we
want
to
be
able
to
configure
our
workflow
our
pipelines
as
much
as
possible
right
for
experienced
kubernetes
users.
We
want
to
have
the
same
flexibility
in
setting
everything
that
we
want
in
a
kubernetes
manifest
in
a
pipeline
like
this,
and
if
you
don't
believe
me
when
I
say
it's
really
popular,
there
are
a
billion
weekly
NPM
downloads
for
JavaScript
packages.
A
Now
yeah,
some
of
them
are
Cir
automated
systems,
but
there
are
a
few
at
least
5
million
actual
humans
doing
npm
install
every
week,
so
we
could
possibly
reach
a
portion
of
those
with
kubernetes
and
brigade.
The
second
one
is:
how
do
we?
How
do
we
share
data
between
containers
right?
We
want
to
pass
information
to
containers
and
want
to
read
data
from
that,
and
since
we
chose
JavaScript
first
of
all,
we
want
to
be
to
feel
like
it's
like
we're.
A
Actually
writing
JavaScript
and,
more
importantly,
we
want
to
preserve
the
existing
if
you're
used
to
passing
data
in
some
way
in
kubernetes,
if
it's
secrets
or
environment
variables,
persistent
volume
claims
or
temporary
file
systems.
We
want
you
to
be
able
to
keep
doing
that
and
at
the
end
of
the
day,
it's
just
JavaScript
right.
This
is
how
you
would
start
a
job
called
one
using
a
container
using
the
image
Alpine.
You
can
substitute
Alpine
there
with
any
existing
container
image
out
there,
that
you
have
access
to
pull.
A
You
write
a
list
of
tasks
that
you
want
to
execute
inside
that
pod.
That
container
you
have
environment,
storage,
caches
that
you
can
attach
and
configure,
and
ultimately
you
run
it.
We
want
it
to
be
as
easy
as
possible
for
new
users
right
and
that's
ultimately
what
it
takes,
and
the
final
question
is:
when
do
we
actually
get
to
executors
scripts
that
we're
writing
that
we're
defining
and
what
we've
seen
over
the
last
decade,
one
with
event-driven
development
and
two
with
the
serverless
movement
is
that
people,
like
events
write
week.
A
So
where
do
these
events
come
from
right?
They
can
be
any
sort
of
HTTP
web
hook.
They
be
from
an
internal
system.
They
can
be
from
any
third-party
system
that
might
want
to
give
information
back
to
you.
They
could
be
get
events,
they
can
be
container
registry
events.
They
could
be
even
kubernetes
events,
events
that
kubernetes
internally
generate
you
can
react
to
those
as
well
and
eventually,
any
event
source
that
can
be
configured.
A
You
can
do
it
with
brigade,
it's
a
component
called
gateway
and
it's
fairly
easy
to
get
any
event
and
create
kubernetes
jobs.
With
that
event,
you
can
write
tough
cop
gateways.
You
can
write
Redis,
pub
sub
gateways
and
essentially
any
messaging
system
that
you
use
right
now.
Potentially,
you
can
convert
those
events
to
Brigade,
and
this
is
a
complete
brigade
script
right.
A
The
only
thing
on
top
of
defining
and
running
the
job
is
we
say
that
whenever
some
events
happen,
some
event
triggers
I
want
to
execute
this
and
I
simply
pass
some
the
data
that
the
event
gives
me
back.
This
is
the
the
library
that
we
use.
You
can
simply
import
it
and
that's
that's
a
complete
brigade
script
and
you
can
skip
that
as
well
right.
So
it's
five
four
or
five
lines
of
of
code.
A
What
do
people
use
Brigade
for
the
first
one
and
the
thing
that
comes
to
people's
mind?
The
first
is
the
ICD
and
we
actually
use
yikes
if
we
use
Brigade
to
build
test
and
release
brigade
itself,
but
besides,
actually
using
brigade
directly
to
a
four
CI
which
again,
we
have
github
integrations
that
I'm
gonna
show
you
in
a
minute.
A
People
actually
use
it
as
a
foundation
for
their
own
opinionated
CI
systems
right
you
want
and
I'm
gonna
give
you
an
example
for
that
in
a
minute
actually
have
someone
in
the
room
because
building
one
of
those
one
really
interesting,
one
that
we
haven't
thought
of
when
building
brigade
is
application
security
scannings
every
night.
They
they
take
all
the
applications
in
a
certain
namespace.
They
do
vulnerability
checking's
for
those
applications.
If
they
discover
vulnerabilities,
they
stop
the
traffic
to
that.
A
If
not,
if
they
still
there,
they
potentially
can
create
I,
don't
know,
send
emails
and
slag
notification,
something
to
someone
who
happens
to
react
and
essentially
because
you
have
a
full
programming
language,
you
can
use
any
API
inside
any
container
that
you
want
another
one
is
aggregating
and
analyzing
data
from
multiple
different
sources.
You
have
one
storage
account
in
cloud:
a
you've
got
a
storage
bucket
in
cloud
B
and
you
have
an
on-prem,
my
sequel.
A
What's
a
sane
way
of
getting
data
consistently
and
programmatically
from
all
those
and
putting
it
in
a
report
right,
you
need
to
have
access
to
all
of
those,
and
this
is
a
very
interesting
way
you
can
use
Brigade
for
and
one
really
interesting
that
it's
coming
to
the
brigade
documentation.
Someone
from
the
community
actually
is
writing
that
right
now,
it's
spinning
up
preview
environments
for
every
pool
requester
on
demand.
So
imagine
you
have
a
repo
whenever
you
want
to
prepare
or
there's
a
pull
request
that
you
want
to
merge.
There's
a
namespace
that
gets
created.
A
Everything
gets
deployed
there,
you
kind
of
get
a
cannery
of
10%
of
traffic.
Let's
say
that
goes
there.
If
everything
goes
well,
you
can
increase
it
right
and
you
can
do
that
from
Brigade
without
put
potentially
integrating
with
a
service
mesh
if
you
want,
but
you
can
just
test
the
namespace.
If
it's
everything,
okay,
you
can
multiple
requests
and
that's
it
so
think
about
Brigade,
not
only
as
a
step
for
CCD
but
potentially
a
way
to
automate
any
processes
that
you
might
have
running
in
your
kubernetes
cluster
right.
A
You
can
install
brigate
using
helm,
there's
one
command,
I'll
install
and
then
you
can
use
the
brigade
CLI
called
Brig
I
didn't
get
from
the
release
pages
from
github
and
actually
interact
with
with
the
entire
system.
So
the
only
thing
that
I
did
before
this
talk,
because
I
really
do
not
trust
the
Wi-Fi
here
to
actually
pull
images
and
install
things
in
my
cluster
is
I.
Did
the
helm,
install
and
I
created
the
project?
A
And
if
your,
if
you
use
the
S
code-
and
you
haven't
seen
the
vs
code,
kubernetes
extension
I
recommend
you
have
a
look
at
it,
it's
a
it's
a
thing
that
allows
you
to
see
the
state
of
your
cluster
and
interact
with
it.
Exact
into
containers.
Get
the
logs
follow
the
logs.
There
was
a
talk
that
I
recommend
you
watch
online
from
ivan
from
our
team
who's
building.
This
yeah
check
it
out.
So
essentially,
in
this
namespace
I
deployed
Brigade
and
I
said
it's
lightweight.
A
It's
actually
three
containers,
there's
three
pods
that
are
running
and
only
one
of
those
is
actually
mandatory.
The
other
two
are
an
API
and
a
web
dashboard
that
are
nice
to
have
there's
a
brigade
controller,
which
is
simply
a
kubernetes
controller
that
is
listening
for
events
and
scheduling
things
to
start.
So
this
is
the
controller,
the
API
and
and
the
and
the
web
dashboard.
So
I
hope
I've
been
telling
you
that
you
simply
write
JavaScript,
and
then
you
run
it.
Let's
actually
do
that.
So
this
is.
A
This
is
a
simple,
a
simple
script
that
only
does
echo
hello
and
then
echo
Barcelona.
It's
it's
intended
to
show
you
how
easy
things
can
be.
So
how
can
we
run
that
I've
told
you
that
there,
whenever
there's
an
event,
triggered
there's
a
job
that
gets
started
right
now,
we're
simulating
events
with
brick
right
there's.
This
script
is
listening
for
an
event
called
exact
whenever
anyone
creates
a
that's
authenticated,
creates
an
event
called
exact.
This
was
gonna.
This
is
gonna,
get
started
and
with
brick
I'm
doing
exactly
that.
A
Brig
exact,
the
name
of
the
project
is
hello,
cube,
Khan
and
I'm.
Just
passing
the
the
file
that
I
want
to
execute
now
what's
happening
here.
The
controller
sees
there's
a
new
event
and
we'll
start
scheduling.
The
digital
job.
Brigade
also
comes
with
a
web
dashboard.
So
if
you
don't
really
like
to
look
at
CL
eyes,
there's
a
command
called
brick
dashboard
that
opens
up
a
web
dashboard
for
you,
where
you
can
see
all
of
your
projects
and
all
of
the
events
that
got
generated.
A
So
we
can
see
that
we
created
an
event
through
the
brigade
CLI
and
if
you
go
further,
we
can
see
the
event
and
then
we
can
see
the
actual
logs.
So
the
script
itself
was
called.
Do
nothing.
It
was
based
on
an
Alpine
image
because
of
the
smallest
things
that
that
I
trust
to
run
on
this
thing,
and
then
it's
gonna
do
echo
hello
and
echo
Barcelona.
So
at
this
point,
I
can
see
in
the
dashboard
things
that
have
happened,
but
let's
take
steps
a
bit.
Fer
I
can
do
that
with
a
declarative
thing
right.
A
They
could
just
say
what
I
want
to
happen.
Let's
have
a
look
at
running
things,
either
sequentially
or
wait
for
one
another.
To
finish-
and
this
is
where
having
a
real
programming
language
is
really
important.
I
can
use
the
away
to
sync
functionality
in
JavaScript
to
do
that.
You
do
just
that
because
of
the
way
we
build,
the
library
you're
able
to
asynch
await
jobs
to
finish
before,
starting
things
or
you
can
group
them.
A
A
And
this
is
the
point
where
I
show
you
another
tool
that
someone
from
the
community
built,
it's
called
Brigade
turn
and
it's
again
it's
a
dashboard
for
Brigade,
but
it's
for
your
CLI.
If
you're,
not
the
web
kind
of
person
and
you
live
in
a
terminal.
There's
this
there's
a
web
terminal
that
you
can
see
all
the
things
that
are
running
in
your
Brigade.
All
the
events.
You
can
see
all
the
jobs
that
were
created
and,
more
importantly,
the
things
that
I'd
really
like
about
this.
You
can
see
the
pipeline
how
the
things
started.
A
You
can
see
that
there
first
jae-won
got
created
it's
finished
and
then
j2
started,
and
this
is
simply
because
we
did
an
await
for
those
things
so
and
then
you
can
dive
in
into
each
of
the
jobs
and
can
see
what
happened
there.
Now,
let's
take
it
a
step.
Further
I've
been
telling
you
that
it's
easy
with
Brigade
to
actually
share
storage
across
jobs
and
across
multiple
invocations
of
events.
So
first
one
that
I
want
to
show.
You
is
sharing
a
persistent
volume,
a
temporary
persistent
volume
between
all
the
jobs
of
a
single
event.
A
So
what
this
is
gonna
do
is
gonna
create
three
jobs.
The
first
one
is
gonna
write
hello
in
the
file.
The
second
one
is
gonna
write
world
in
the
same
file,
the
shared
file,
and
then
the
third
one
is
gonna,
actually
print
the
thing
that
that's
in
that
file
and
the
only
thing
that
I'm
doing
by
default.
You
don't
have
that
because,
if
you're,
a
new
user,
you
don't
want
to
know
what
the
storage
is.
A
If
you,
if
you've
used
to
burn
a
DS
and
know
what
a
persistent
volume
is
just
do,
a
storage
enabled
and
you're
gonna
have
you
can
configure
where
you
want
to
have
your
shared
storage
and
by
default
it's
in
Mount,
Brigade
share
and
everything
you
create
there.
It's
gonna
get
persisted
across
all
the
jobs
in
your
in
your
in
your
event,
invitation
when
the
event
is
over.
That
job
is
that
that
persistent
volume
is
deleted.
You
can
choose
to
persist
it
somewhere
else
if
you
want,
but
this
is
what
you
get
by
default.
A
And
we
go
back
to
Brigade
term,
we
see
there's
an
event
happening.
We
see,
there's
job
gold,
one
what's
happening
right
now
the
persistent
volume
gets
created
and
it's
gonna
get
attached
to
each
of
the
jobs,
while
they're
starting
jobs
are
simply
kubernetes
pots.
So
we're
able
to
attach
things
exactly
like
you
would
do
in
in
any
kubernetes
pod.
So
one
didn't
do
anything.
It
wrote
hello
in
the
file
to
wrote
world
in
the
file
and
three
printed.
Whatever
was
on
that
file.
A
There
are
three
separate
parts
that
are
running
in
the
same
namespace
and
they're,
using
the
same
the
same
file
depending
on
the
storage
class
that
you
have
in
your
cluster.
You
can
have
readwrite
ones
with
like
many.
It's
only
a
matter
of
how
proper
how
how
things
the
things
that
you
can
do
with
your
persistent
volume
and
with
your
storage
class
and
one
other
thing
that
I
want
to
show
you
before
moving
over
is
the
first
storage
that
I
showed
you
was
across
jobs
of
the
same
event.
A
The
second
one
called
the
cache,
its
persistent
across
the
same
type
of
jobs
across
multiple
events.
Right
so
you
execute,
for
example,
a
go
build
every
time
if
you
have
the
same
name
for
your
job
in
this
for
the
same
project
in
the
same
name
space.
If
you
attach
the
cache,
then
by
default,
Brigade
will
attach
to
that
persistent
volume
for
you
and
it
will
make
it
available
in
mount
brigade.
You
can
configure
where
that
is
available
as
well.
A
A
Right,
you
can
see
that,
as
as
we
execute
the
same
event,
over
and
over
again,
the
same
storage
gets
attached
the
same
job.
So
you
can
imagine
the
things
that
you
can
do,
having
storage
shared
across
jobs
and
across
the
same
job
on
multiple
events
and
just
to
show
you
a
bit
of
a
tease
for
the
deep
dive
session.
A
When
it
comes
to
integration,
we
actually
have
a
first-class
support
for
cloud
events,
which
is
a
CNC
F
specification
which
its
goal
is
to
standardize
the
way
events
are
shared
across
multiple
systems.
So,
if
you
have
a
system,
all
storage
cloud
storage
providers
use
this
this
thing.
So
if
you
have
an
event
that
generates
cloud
events,
you
can
get
it
by
default.
Whenever
you
install
it
brigade
and
handle
those
events,
we
having
first-class
integration
with
github
checks,
API
and
I'm
gonna
show
you
in
a
minute.
A
It's
exactly
that
how
we
can
go
to
the
checks,
API
tab
in
github
and
see
logs
from
brigades.
Jobs
are
running
on
your
cluster.
You
can
see
them
in
the
brigade
CLI.
We
have
integrations
with
Prometheus
for
metrics
and
virtual
cubelets
to
scale
in
the
cloud.
If
you
don't
have
enough
capacity
locally,
we
have
also
support
for
arbitrary
event
data
with
a
generic
gateway.
A
So
if
your
system
doesn't
support
cloud
events
and
support
some
random
JSON
schema,
we
can
handle
that
as
long
as
you
know
what
you
have
in
your
javascript
file,
you
can
consume
that
as
well
and
ultimately,
what
we
want
to.
What
we're
trying
to
build
is
a
rich
ecosystem
for
Brigade
I've
shown
you
caste
and
Brigade
term,
which
are
dashboards
to
see
the
state
of
Brigade.
But
there
are
a
number
of
gateways
that
are
coming
directly
from
the
community.
We
have
support
for
big
bucket
events,
gitlab
kubernetes
as
your
event
with
Trello.
A
When
you
move
a
board
in
Trello
that
generates
a
webhook
you
can
handle
that
and
a
number
of
systems
that
generate
defense
and
because
we're
developers
and
we
actually
love
working
with
developers-
Brigade
also
loves
developers.
If
you
want
to
get
started
with
this
Doc's
dot
brigade,
the
FSH
and
I
want
to
give
a
shout
out
to
Ronan
who's,
not
here,
because
building
all
of
our
awesome
documentation
and
landing
websites-
and
you
can
have
you-
can
see
how
to
get
started.
A
You
get
an
overview,
get
an
advanced,
scripting
guide
and
essentially
how
to
get
started
with
with
Brigade.
If
you
want
to
contribute
with
absolutely
love
that
we
a
label
on
github
the
good
first
issue,
I
would
all
of
us
in
the
community
would
love
to
help.
You
get
started
contributing
to
Brigade
and
get
involved.
We
have
a
brigade
channel
in
the
kubernetes
slack.
We
have
a
biweekly
community
meeting
every
Tuesday
at
6
p.m.
Central
European
Time.
What
was
last
night
you've
gone
and
you
can
find
most
of
the
projects
in
github,
comm
brigade,
core
organization.
A
I
want
to
tell
you
about
the
deep
dive
tomorrow.
We're
gonna
have
a
look
at
more
of
a
try-catch
object-oriented
approach
of
writing
jobs.
Brigade
internals,
there's
a
kubernetes
controller
in
there
somewhere,
there's
secrets
their
storage.
We're
gonna
see
how
that
actually
works.
We're
gonna
see
how
to
build
a
custom
gateway
for
your
own
events.
Right.
You
have
some
event:
data
in
your
in
your
company,
that's
generating
some
never-seen-before
schema.
That's
not
HTTP
does
not
JSON
events.
We're
gonna
see
how
to
get
started
with
it
and
we're
also
gonna
have
a
look
at.
A
A
That's
usually
one
of
the
first
questions
that
we
get
asked
this.
How
do
you
stack
against
usually
there's
a
CI
system
somewhere
tectonic,
for
example,
we
gain,
isn't,
doesn't
intend
to
be
a
CI
system
only
right
we,
its
goal,
is
to
be
a
shell,
scripting
environment
where
you
can,
if
you
want
to
process
a
CI
system
or
CI
process.
Yes
sure
you
can
do
it,
but
there
are
a
lot
of
other
processes
out
there
that
you
can
start
using
if
you're.
A
If
you
only
have
a
declarative
need,
if
you
only
want
to
execute
something,
there's
an
event
you
want
to
execute
this,
then
you
could
probably
get
started
with
function.
There's
a
service,
probably
right.
If
you
need
something
a
bit
more
complex.
If
you
want
to
handle
logic,
if
you
want
to
schedule
multiple
jobs
and
get
results
and
share
things
between
them,
having
the
complexity
of
a
real
programming,
language
is
really
helpful.