►
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
Brigade is an in-cluster runtime that interprets scripts and executes generic pipelines of work in Kubernetes. Using JavaScript, developers can chain containers together in a script to create an event-driven workflow in Kubernetes. Scripts can define a series of jobs that run in parallel or serially, and take advantage of having full programming language support for error handling and async functionality, as well as benefit from the rich JavaScript ecosystem of libraries.
Brigade is a CNCF Sandbox project, it integrates with other cloud-native projects (Helm, Prometheus, CloudEvents, Virtual Kubelet), and has varied use cases (from a foundation for opinionated CI/CD platforms, to building training pipelines for predictive modeling, or asynchronous processing for orders).
In this webinar we will explore how to start building distributed workflows in Kubernetes using a few lines of code, how Brigade works, and how it integrates with the cloud native ecosystem.
A
I'd
like
to
thank
everybody
who
is
joining
us
today,
welcome
to
today's
CN
CF
webinar
Brigade
scripting
container
workflows
on
kubernetes
you're
in
for
a
real
treat
today
my
name
is
lucky:
lucky
Evensen,
I'm,
a
principal
program
manager
at
Microsoft
and
cloud
native
ambassador
I'll
be
moderating
today's
webinar,
and
we
would
like
to
welcome
our
presenter
today
rather
mud
day.
He's
a
software
engineer
at
Microsoft
and
maintainer
of
the
Brigade
project.
A
Brigade
is
actually
in
the
CNC
F
sandbox
a
few
housekeeping
items
before
we
get
into
it
during
the
webinar
you're
not
able
to
talk
as
an
antenna
D
there
is
a
Q&A
box
at
the
bottom
of
your
screen
feel
free
to
click
that
and
drop
your
questions
in
there
and
then
we'll
get
to
the
questions
as
we
see
fit.
So
again,
please
don't
ask
questions
in
the
chat,
specifically
go
down
to
the
Q&A
box
and
we
will
see
them
and
we
will
get
them
answered
throughout
the
webinar.
Thank
you
very
much.
A
This
is
an
official
webinar
of
the
CNC
F
and,
as
such,
is
subjected
to
the
CNC
F
code
of
conduct.
Please
do
not
add
anything
to
the
chat
or
any
questions
that
would
be
in
violation
of
that
code
of
conduct.
Basically,
please
be
respectful
to
all
your
fellow
participants
and
presenters
and
with
that
I
will
hand
it
over
to
rudder
to
kick
off
today's
presentation.
Take
it
away
rudder.
B
Hello
everyone
good
morning
evening
afternoon,
hopefully
the
daylight
savings
time
in
Europe
didn't
mess
up
too
many
schedules
this
week
today
we're
going
to
talk
about
brigades
and
skipping
container
workflows
on
kubernetes.
My
name
is
abu,
I'm
on
open-source
maintainer
for
brigade
and
cloud
native
application.
Bundles
project.
We
can
hear
me
talk
about
fallarbor
tools,
OCI
security
protocols
really
really
into
music
and
bicycles
and
I'm.
A
software
engineer
at
Microsoft
today
in
this
webinar
we're
gonna
talk
about
Brigade
and
you
could
go
ahead
and
check
out
the
documentation.
B
Throughout
this
presentation
there
will
build
links
to
multiple
pages
in
the
documentation.
You
can
also
check
the
github
project
and
how
about
samba
gate
core
before
talking
about
Brigade.
Let's
take
a
step
back
and
think
about
what
an
operating
system
is,
what
its
job
is,
and
essentially
the
program
that,
after
initially
being
loaded,
it
manages
all
of
the
other
programs
right
and
if
we
think
about
it,
an
operating
system
manages
processes
on
a
single
machine
and
kubernetes
manages
containers
in
a
cluster.
B
B
If
we
continue
the
analogy,
then
how
would
we
think
about
cluster
shell
scripting?
Oh
I
would
like
to
have
something
that
controls
the
flow
of
executing
containers,
but
it's
not
opinionated
about,
but
the
containers
do
or
how
they
run.
So
I
would
like
to
be
able
to
do
something
very
similar
to
how
I
would
do
bash,
but
instead
of
starting
processes
on
a
single
machine,
I'd
like
to
be
able
to
start
containers
in
a
kubernetes
cluster.
So
how
are
we
doing
this
right
now?
B
Well,
first
of
all,
we're
using
good
old
batch
scripts
and,
to
some
extent,
abusing
yamo
and
we're
gonna,
see
in
a
minute
about
that.
We
have.
We
think
that
we
have
a
solution
for
this
problem
with
Brigade
we
get
either
a
cloud
native
app
is
a
CNCs
sandbox
project
and
essentially
the
framework
is
an
encruster
runtime
for
event-driven
scripting
on
kubernetes.
B
Data
between
them
attach
kubernetes
volumes,
wait
for
them
to
finish,
start
them
in
groups
and
all
that
stuff
which
so
far,
we've
been
doing
with
either
batch
scripts,
really
really
complicated
and
unmaintainable
or
untestable
bath
scripts,
or
some
sort
of
trying
to
use
Yambol
to
do
that.
For
us
and
thinking
about
a
shell
scripting.
Well,
there
were
a
bunch
of
questions
that
brigade
has
answered.
First
of
all
is
what
programming
language
should
we
use?
B
How
do
we
share
data
between
multiple
containers,
multiple
jobs,
and
when
are
we
supposed
to
execute
scripts,
and
let's
take
each
of
those
and
talk
about
them?
First,
one
is
we
decided
to
choose
a
language
and
not
write
one
and
in
if
in
2017,
18,
19
or
20
20
we're
thinking
about
using
the
programming
language
to
reach
as
many
people
as
we
can
well
honestly,
there's
only
one
language
that
fits
that
and
that's
JavaScript,
regardless
of
what
we
think
about
it.
It's
been
the
number
one
programming
language
over
last
couple
of
years.
B
You
know
Metrix,
oh
well,
we
chose
to
go
with
JavaScript,
mainly
because
it's
extremely
popular
has
a
very
rich
ecosystem
of
tools,
and
it's
extremely
flexible.
More
than
that,
it
has
more
than
1
billion
weekly
NPM
package
pools.
Some
of
those
are
CI,
but
some
of
those
are
actual
real
humans
using
JavaScript.
B
Second
question
was:
how
do
we
share
data
between
containers?
Think
about
it?
This
way,
I
want
to
start
a
job,
wait
for
it
to
finish
and
get
the
result
or
an
output
or
something
from
that
job
and
pass.
It
add
input
to
the
next
job.
If
we,
if
you're
thinking
about
how
to
do
right
now,
uber
natives,
really
thinking
about
to
control,
exact
or
keep
control,
run
basically
output
in
the
console
grab
through
it.
Take
some
info
and
then
pass
it
forward.
B
Jake
you
and
Jason
and
yaw
will
help
with
that
a
bit,
but
it
feels
really
really
painful
and
we're
interested
in
how
the
best
information
to
containers
and
how
to
get
information
from
containers
that
have
executed
and,
more
importantly,
because
we
chose
JavaScript,
we
wanted
to
be
JavaScript
native
to
feel
like
you're,
actually
writing,
JavaScript
and
as
important.
We
wanted
to
preserve
existing
paradigms
for
passing
data
to
and
from
containers
in
a
kubernetes
world
and
at
the
end
of
the
day,
it's
just
JavaScript.
B
The
third
question
was:
when
do
we
execute
scripts
and
the
most
obvious
was
reacting
to
triggers
or
events
right
and
if
an
handlers
become
the
entry
point
for
Brigade
scripts?
We
live
in
a
world
where
every
system
is
able
to
trigger
some
sort
of
events
beat
by
web
hooks
or
by
a
message,
queue
or
something
like
that,
and
essentially
it
made
sense
for
us
to
execute
to
outside
events.
B
Where
do
these
events
come
from?
Well,
they
could
be
any
HTTP
web
hook
either
internals
from
your
systems.
It
can
be
a
third
party
like
github
container
registries
or
kubernetes
itself,
yet
I'm
mentioning
kubernetes
in
the
end,
any
vent
source
can
be
configured
for
a
brigade
in
a
component
that
we're
gonna
take
a
look
at
in
a
minute
for
gateway,
and
this
is
a
complete
script
for
brigade.
B
If
you,
if
you
add
this
to
abrogate
project,
essentially
you're
able
to
execute
it
every
time,
there's
a
an
event
called
some
event,
and
essentially
what
we're
doing
is
we're
importing
the
brigade
package
in
JavaScript
and
then
we
react
to
an
event
called
some
event
with
this
function.
You
start
a
job,
we
add
some
tasks
to
the
executors,
and
then
we
run
it.
This
is
the
most
simple
task
that
we
can
aggregate
aggregate.
We
think
we're
gonna
see
in
a
couple
of
minutes.
More
complicated
tasks
and
actual
control
flow.
B
So
what
do
people
use
brigade
for
now?
We've
seen
it
being
used
for
as
a
foundation
for
opinionated
ci
City
systems,
we'll
take
a
look
at
those
in
a
minute
overnight:
application,
security,
scannings,
aggregating
and
analyzing
data
from
multiple
systems,
building
reports,
creating
preview
environments
on
top
of
kubernetes
all
pull
requests.
So
if
you
have
a
project,
that's
in
get
big
buckets
your
lab
github.
Whenever
there's
a
pull
request.
B
So
essentially,
we
are
using
brigades
with
the
existing
checks,
API
and
in
the
end,
any
potential
container
workflow,
or
that
you
want
to
run
on
top
of
kubernetes.
That
would
actually
benefit
from
language
features.
So
if
you're
only
use
case
is
just
starting
three
jobs,
one
after
the
other
or
at
the
same
time
and
you're
not
interested
in
actual
control
flow
or
thing.
Gonna
wait
for
some
of
those
jobs
passing
easily
passing
data
back
and
forth,
and
you
could
probably
achieve
that
with
either
kubernetes
primitives
or
some
other
declarative
system.
B
But
if
you
find
yourself
restrained
by
llamó,
then
having
a
full
programming,
language
and
environment
could
be
of
use.
So
how
do
you
get
started
with
brigades
well,
brigade?
We
can
configure
it
with
helm,
helm,
install
and
then
break
check.
I
really
encourage
you
to
go
check
the
docs
Brigade
our
sh
website.
You
can
find
all
of
the
all
the
getting
started
right
on
on
the
website.
Now
there
is
a
question
of
whether
we
can
replace
docker
files
or
manifest
with
Java
Script.
B
Essentially,
you
can
configure
brigades
to
work
with
a
github
repo
and
if
you
put
that,
if
you
go
to
manifest
in
your
github
repo
you
could
you
could
also
choose
to
build
container
images
before
using
them,
but
you
would
need
a
docker
runtime
in
your.
You
know
cluster.
To
do
that.
We
have
an
example
examples
of
how
to
do
it
on
on
the
documentation.
So
how
do
we
actually
get
started
with
Brigade.
A
B
Was
telling
you
that
Brigade
is
fairly
lightweight
essentially,
but
the
default
installation
of
brigade
is
three
parts.
We
have
a
completed
pod,
that's
just
a
cron
job.
That's
running!
That's
not
running
right
now,
so
there
are
three
main
components
for
brigades:
there's
a
kubernetes
controller
which
is
looking
for.
We
gate
events
and
then
there's
an
api
which
we
can
use
it
to
in.
It's
actually
easy
to
interact
with
with
brigade,
and
then
we
have
a
web
dashboard,
that's
obviously
optional.
B
So
after
we
do
a
helm
install,
we
can
do
a
brig
check
to
make
sure
that
everything
is
running
healthy
in
our
brigade,
installation.
And
if
everything
is
running
okay,
then
we
can
start
the
web
dashboard
to
see.
If
that's
running
and
that's
gonna
start
your
default
browser
I'm
gonna
create
a
tunnel
to
kubernetes
and
access
to
the
brigade
dashboard
and
right
now
we
don't
have
any
projects.
We
haven't
computed.
Anything
I
just
deployed
Brigade
a
little
bit
earlier,
so
that
I
don't
rely
on
pulling
some
charts
on
the
internet
right
during
this
call.
B
We
have
couple
of
scripts
that
we're
going
to
use
you
can
find
them
I'll
place
the
github
repo
for
this
most
of
this
thing,
you're
going
to
be
able
to
find
in
Docstoc
bouquet
data
stage,
the
entire
demo
that
I'm
going
to
show
you
right
now
is
from
the
documentation.
So
please
be
sure
to
check
that
out.
B
This
is
the
first
script
that
you're
going
to
using
gonna
pass
it
as
the
default
script
to
be
used
in
case.
We
don't
use
anything
else,
you
and
we
don't
want
any
Advanced
Options.
So
at
this
point
we
have
our
brigade
project
called
hello,
and
if
we
do
a
brig
run,
essentially
I
was
telling
you
that
Brigade
reacts
to
triggers
and
external
events
right
now
we're
using
the
brake
CLI
to
create
a
an
event
for
us
and
I
want
to
execute
a
new
event
and
I
want
to
pass.
B
We
also
have
a
second
terminal
dashboard
for
a
brigade.
It's
a
seal
I
want
in
case
you
don't
have
access
to
a
web
interface.
It's
called
break
turn
brigade
turn
someone
from
the
community
contributed
this
we're
super
happy
with
the
community
and
the
things
that
they've
been
contributing.
So
far.
Essentially,
let's
walk
through
what
happened
so
brick
created
an
event.
It
was
a
simple
run:
execve
en't.
This
was
caught
by
the
brigade
controller,
which
scheduled
a
brigade
worker
and
essentially
our
job
was
called.
B
Do
nothing
based
on
an
alpine
container
and
the
only
thing
that
was
supposed
to
execute
were
echo
hello
and
then
echo
world
and
then
run
and
exit.
So,
let's
see
how
that
looks
like
we
have.
The
brig
run
creates
an
event
called
exec
that
we're
handling
two
that
are
responding
to
and
then,
if
we
go
any
further,
we
can
see
that
the
job
was
called.
B
Do
nothing
and
we
can
see
the
two
tasks
that
were
supposed
to
be
executed,
echo,
hello
and
then
echo
world
and
then
an
exit,
so
kubernetes
get
pods
and
right
now
we
all
to
see
the
brigade
worker.
That
was
that
his
job
was
to
execute
this
javascript
file
and
then
our
do-nothing
job,
which
was
a
kubernetes
pod,
with
a
single
container,
called
based
on
Alpine.
So
this
is
the
simplest
Brigade
script
that
your
that
you
could
execute.
There
was
a
question
of
people
not
being
familiar
with
JavaScript
and
how
hard
was
it
to
learn?
B
Essentially,
this
is
the
simplest
way
you
can
start
with
Brigade
it.
We
try
to
have
the
syntax
as
simple
as
possible,
first
of
all,
for
people
who
are
not
familiar
with
JavaScript,
but
at
the
same
time,
if
you
are
familiar
with
JavaScript
and
if
you
have
written
JavaScript
before
we're
trying
to
make
use
of
as
many
useful
JavaScript
patterns
as
we
can
so
we're
gonna,
see
throughout
today's
demo,
useful
JavaScript
features
and
things
that
are
obvious
to
people
who've
used
JavaScript,
but
as
well
as
easy
enough
to
get
started
for
other
people.
B
So
let's
have
a
look
at
a
second
a
second
script.
Essentially,
this
one
starts
two
jobs,
so
it's
going
to
start
them
at
the
same
time,
one
called
hello
which
will
do
echo
hello
and
echo
world
and
then
one
goodbye
both
of
them
based
on
alpine.
So
we're
going
to
do
the
same
things,
break,
run
or
really
exact.
That's
the
same
command.
B
B
Essentially,
the
brigade
worker
is
using
the
kubernetes
javascript
api
to
interpret
this
and
start
jobs,
and
then,
if
we
go
back
to
our
CLI
dashboard,
we
can
see
that
we
have
two
jobs,
one
hello,
one
goodbye
now
we
can
see
that
they
were
both
started.
At
the
same
time,
it
doesn't
really
matter
the
order
that
you
pass
right
here
and
then
here
we
can
see
that
they
were
start
at
the
same
time.
They
both
last
is
pretty
much
the
same
time
and
then
we
can
go
into
the
logs
of
each
job
and
then
see
them.
B
We
started
them.
Essentially,
we
first
tried
to
start
hello
and
then
try
to
start
goodbye,
but
we
don't
see
the
order
here.
We
first
see
goodbye
and
then
hello.
How
are
we
supposed
to
actually
control
the
order?
The
execution
and
things
like
that?
So
we
have
something
called
groups,
first
of
all,
essentially
think
of
them
as
collection
of
useful
methods
in
Brigade
that
allow
us
to
control
the
execution,
so
we
can
run
each
which
will
first
start
hello
and
then
start
goodbye,
sequentially
or
run
all
which
was
started
in
parallel.
B
So
let's
see
how
this
is
gonna
execute
for
doing
the
same
thing
passing
this
file
and
what
we're
expecting
to
see
is
Brigade
first
starting
the
hello
job
and
then
starting
the
goodbye
job
and
be
essentially
here
you
started,
we
saw
them
getting
started
at
the
same
time,
we
expect
them
to
to
be
started
separately.
So
we
first
see
hello
which
started
the
execution
and
then
finished,
and
then,
after
hello
finished,
we
see
the
second
job
being
start.
So
we
see
hello
and
then
goodbye.
B
B
We
see
the
project
called
hello,
and
then
we
see
a
bunch
of
events
that
were
executed
five
minutes
ago
two
minutes
ago
and
a
few
seconds
ago,
which
were
the
which
correspond
to
our
break
run
commands,
and
this
is
how
it
looks
for
a
single
event.
You
see
the
two
jobs
and
then
the
the
the
food
job
right.
These
are
the
logs
from
the
briquette
worker,
the
same
ones
that
we
see
right
here
when
we
aggregate
and
then
we
can
go
further
into
the
logs
of
each
individual
job.
B
So
this
is
very
useful
when
you
don't
have
access
to
the
brick
CLI.
Essentially
the
brick
CLI
that
we've
been
using
so
far
requires
access
to
a
config.
It
uses
config
to
essentially
talk
to
the
brigade,
API
and
kubernetes
api.
For
that.
What
I
didn't
mention
so
far
is
that
everything
in
brigade
is
kubernetes
native,
so
it
doesn't
have
any
external
dependencies.
Everything
is
done
as
kubernetes
native
objects
and
then
the
web
dashboard
essentially
is
a
read-only
version
that
uses
the
api
e.
It
cannot
be
used
to
modify
the
state
of
the
cluster
or
appliquéd.
B
A
B
Example,
these
are
the
logs
from
brigade
itself
and
we
can
see
that
the
left
build
actually
failed.
So
this
is
interesting
now,
if
you're
interested
in
this,
you
can
deep
dive
into
what's
happening
there,
but
essentially
because
it's
a
read-only
version
of
what
happens
in
brigade.
You
cannot
affect
this
state.
You
can
only
see
you
can
only
see
the
the
logs
there's
a
question
in
chat,
whether
we're
running
kubernetes
jobs,
almost
running
kubernetes
parts,
not
exactly
jobs.
Jobs
in
kubernetes
are
an
opinion
over
pods
we're.
B
We
can
enter
it,
go
into
the
details
of
why
we
chose
paws
over
jobs.
I,
don't
think
it's
worth
going
to
discussion
right
now,
I'll
be
happy
to
chat
about
that
if
you're
interested,
so
we've
seen
how
to
use
the
group's
abstraction
in
Brigade
to
start
jobs
one
at
a
time
now,
let's
see
how
we
could
use
more
advanced
JavaScript
features
to
get
the
same
results.
B
So
essentially,
what
we're
doing
is
we're
starting
to
jobs
just
like
before,
but
this
time
we're
using
the
single
weight
function,
allottee
from
javascript
to
essentially
wait
for
a
job
one
to
finish
and
then
start
job
two
and
then
do
something
else
right.
Imagine
you
imagine
job
one
configuring
something
in
your
cluster
and
then
job
to
using
that
right.
So,
let's
see
how
that.
B
B
Yes,
the
job
function
supports
promises,
that's
how
we're
using
the
async
await
functionality.
There
was
a
question
of
whether
the
job
supports
promises.
There's
another
question
of
how
is
this
similar
or
different,
detect
on
CD
to
create
pipeline
jobs
or
BOTS?
The
way
we're
thinking
about
it
is
essentially,
first
of
all
we're
not
using
any
declarative
features
we're
not
using
Yammer
to
configure
our
jobs.
So
that's
one
difference.
The
second
one
is
essentially
stacked
on
the
CD
is
particularly
suited
for
CI
CD
purposes.
B
We've
seen
Brigade
being
used
for
a
bunch
of
other
other
use
cases
as
well.
We
we
are
using
Brigade
for
CDs
for
CIN
CD,
and
there
are
a
bunch
of
opinionated
framework
on
top
of
brigades
that
have
declared
a
features
for
CD,
but
if
you're
only
gonna
use
ICD,
you
could
have
a
look
at
that
done.
For
example,
other
things
on
top
of
kubernetes.
B
B
B
We
have
a
job
one
which
is
going
to
write
into
a
file.
We
have
job
to
which
you're
going
to
write
into
the
same
file
and
then
job
three
is
gonna,
echo
whatever
were
was
in
that
file,
so
thing
you
think
about
think
about
it.
In
this
way,
you
are
trying
to
share
the
same
persistent
volume
in
kubernetes
across
three
different
thoughts.
B
You
could
potentially
achieve
that
using
your
very
complicated
bash
script,
create
the
persistent
volume
attach
it
to
the
to
the
configure
of
the
first
pod,
as
a
person
in
volume
claim
claim
then
wait
for
the
first
part
to
finish
and
then
attach
the
persistent
volume
claim
to
the
second
pod
and
then
attach
it
to
the
third.
Essentially,
this
is
what
Brigade
does
for
you
automatically
by
just
doing
storage
enabled
equals
true.
So
if
you
do
that,
it's
gonna
attach
the
persistence
volume
to
your
path.
The
brigade
storage
is
a
persistent
volume.
B
B
Just
reiterate
one
more
time
on
this
I'm,
starting
with
executing
events
annually
and
passing
Brigade
J's
files.
You
don't
have
to
do
that.
You
can
use
git
provider
for
that
story
or
big
Aegis
files
and
have
an
inversion
control.
This
is
the
easiest
way
to
to
test
your
script
without
pushing
the
source
control
right.
You
can
also
store
them
in
kubernetes,
config
Maps.
If
you
don't
have
a
github
repo
and
we've
actually
seen
more
and
more
people
using
brigades
without
you'd
have
repos,
so
it
doesn't
have
to
be
a
git
enabled
scenario.
B
We
see
personal
volume
claim
being
created
and
yeah.
This
is
essentially
what's
happening
right
now
we
created
the
worker
pot
and
then
we
created
the
persistent
volume
that
we're
attaching
to
that
and
then
we're
waiting
for
that
to
finish
and
then
we're
going
to
start
each
individual
kubernetes
pod,
attach
it
use
the
persistent
volume
and
then
and
then
detach
the
PVC
from
the
bottom.
Then
add
it
to
the
other.
There's
a
question
in
chat:
whether
it
is
better
to
use
a
weight
versus
the
run,
each
construct,
essentially
the
run
each
just
uses
away.
B
B
B
B
B
In
JavaScript,
the
only
or
preferred
language
for
event-driven
scripting
for
kubernetes
brigade
by
default
uses
JavaScript
to
do
the
to
do
this.
That
being
said,
we
have
we
have
seen
at
these
three
implementations
of
a
declarative
approach
on
top
of
on
top
of
brigades,
so
you're
not
solely
only
restricted
to
two
Java
sleep.
We
can
have
a
llamó
file
that
in
figures
we
get
for
your
needs,
but
specifically
by
default
Brigade
only
uses
JavaScript.
B
Then
the
second
question
was:
could
you
pass
configuration
or
parameters
to
pod
deployment
like
having
a
template
and
deploy
to
kubernetes?
Yes,
we
actually
see
that
doing.
I
would
think
that
done
pretty
regularly,
essentially
you're
keeping
a
bunch
of
kubernetes
config
files
or
helm
charts
into
a
into
a
repo
and
then
as
part
of
a
aggregating
or
of
a
trigger
you're
able
to
take
that
in
fig
file
and
then
essentially
deploy
to
kubernetes
or
even
better
start
kubernetes
cluster
inside
of
brigade
using
kind
kubernetes
and
docker.
B
Does
brigade
in
clusters
interact
with
others
know?
If
you
have
a
config
file
for
a
different
cluster
stored
as
a
secret,
you
can
pass
it
to
the
brigade.
It
doesn't
have
to
run
by
default
in
the
easiest
way
would
beat
for
Brigade
to
essentially
because
the
gate
runs
in
your
kubernetes
cluster.
It's
able
to
start
pods
in
the
same
namespace
as
its
configured
into
but
yeah.
You
can
point
to
a
different
cube
config
as
well.
B
Alright,
in
a
working
scenario,
essentially,
this
would
would
create
a
persistent
volume
and
share
it
across
all
the
jobs
there
are
in
the
current
build
right
in
the
current
event.
This
is
for
is
one
person
in
the
volume
created
for
each
event
and
then
attached
to
each
individual
job.
The
second
type
of
storage
that
we
are
able
to
use
in
brigade
is
called
a
cache,
and
essentially,
if
it
has
the
same
job
name
and
you
have
the
cache
enabled
this
will
attach
us
the
same
persistence
volume
to
your
to
your
job
across
multiple
event.
B
A
B
This
is
really
interesting.
I
know,
I,
really,
don't
know
why
the
demo
gods
are
not
with
us
for
the
job
storage.
Well,
we'll
get
back
to
that.
Another
thing
that
we
able
to
easily
do
in
Brigade
is
essentially
fast
information,
not
using
persistence
volumes,
but
just
return
values
from
our
containers,
so
I
think
about
it.
This
way
we
have
teacher
and
the
first
one
just
print
something
on
the
console.
It
can
be
formatted,
JSON
or
plain
text
and
then
we're
starting
job
one
and
then
we're
taking
the
output.
B
So
we
see
job
one
that
outputs
world
and
then
essentially,
what
we're
hoping
to
see
is
job
two
using
the
output
of
world
and
then
just
using
it
in
some
way.
So
we
can
see
output
in
hello
world
right
so
think
about
it
in
a
more
in
a
more
complex
way.
Think
about
it,
job,
one
executing
something:
passing
girl,
an
ID
of
a
job
or
an
idea
of
something
in
your
database
and
then
the
second
job,
picking
it
up
and
using
it.
B
If
you're,
only
passing
very
simple
information
like
something
that
would
be
able
to
be
pushed
to
standard
output
feel
free
to
use
the
job
return
values.
If
your
I
have
something
more
complex,
more
bigger
object
that
you're
trying
to
pass
between
jobs,
you're,
probably
going
to
want
to
use
storage
or
caches
or
the
other
other
storage
in
UNIX.
B
And
then,
finally,
let's
have
a
look
at
how
we
would
use
more
complex,
JavaScript
features
like
syncing
a
weight
and
then
try
catch,
I.
Think
about
it
and
you're
trying
to
execute
a
job
and
then
you're
preparing
that
something
could
fail
in
the
job
right
in
in
a
normal,
kubernetes
inari.
Oh,
if
a
pod
fails,
you
can
either
choose
to
restart
it
or
you
can
choose
to
back
off
and
stop
restarting
it
right.
B
A
B
About
it
and
if
you
ever
need
to
stop
some
service
from
running
or
we
start
something
or
simply
we
try,
you
can
do
it
right
here,
so
we've
caught
the
exception
right
and
then
we're
able
to
traditional
things
right.
The
card
exception
error
is
coming
from
your
actual
code.
So
if
you
go
back
here,
we
can
see
that
in
this
case
the
job
the
defending
self
succeeded.
But
there
is
one
job
that
failed.
The
event
Excel
succeeded
because
we
chose
not
to
fail.
It's
explicitly
here.
B
B
There
is
one
question
if
any
feature
use
case
overlap
with
kubernetes
operator
patterns
and
brigade.
This
is
a
really
interesting
question,
which
is
because
we've
been
discussing
that
in
the
last
couple
of
weeks
and
I
can
point
you
to
a
project
that
does
just
that,
which
is
the
brigade
universal
kubernetes
control,
simple
buck,
elevator
building,
for
that,
can
you
synchronize
in
a
completion
of
a
group
you
can?
Essentially
you
can
you
can
wait?
B
Yes,
groups
can
be
used
if
you
put
multiple
jobs
in
a
single
group,
you
can
wait
for
the
entire
group
to
finish
before
starting
new
jobs
or
before
doing
something
else.
Here's
the
cash
only
runtime
or
does
it
persist
across
Gate
restarts.
The
cache
is
a
kubernetes
persistent
volume.
So,
if
you
don't
delete
your
persistence
volume,
then
it's
gonna,
it's
gonna
remain,
and
by
default
we
don't
we
don't
delete
the
persistent
volume
you
have
to
do
that
manually.
B
I
told
you
there
are
a
bunch
of
components
in
brigate,
there's
a
controller,
a
kubernetes
controller
they're
worker
pods,
which
execute
the
scripts
and
schedule
the
jobs,
and
then
there
is
the
optional
API
that
used
to
interact
with
Brigade
from
web
or
CLI,
and
then
gateways
essentially
be
Maps.
Events
from
outside
the
cluster
or
outside
of
brigade
inside
brigade
out-of-the-box
brigade
comes
pre-configured
with
a
cloud
events
gateway
or
one
that
supports
arbitrary
json
gateways
for
container
registry
is
github.
They
can
be
web
hooks
or
a
simple
batch
script.
That
creates
a
kubernetes
secrets.
B
B
So
this
is
the
brigade
repo
itself
and
then
for
each
pull
request
in
the
checks
tab.
We
have
jobs
that
are
running
inside
of
our
brigade,
cluster,
beginning
installation
and
then
logs
pushed
back
to
get
out.
So
this
is
github.
This
is
just
a
github
app
and
then
these
are
two
jobs
in
our
Brigade
Jas
script
that
we
used
to
test
the
actual
gauge
people,
so
we
can
see
them
and
interact
with
them.
If
you
have
access
to
the
repo,
you
can
rerun
them
essentially
interactive.
B
Patients
with
premedia
and
virtual
cubelets
essentially
scale
in
with
any
provider
a
virtual
cubelet
supports,
and
if
you
want
to
see
a
tutorial
on
how
to
do
that
on
a
dirt
container
instances
I've
written
a
couple
of
months
ago,
a
blog
post
on
the
Microsoft
blog,
essentially
about
how
to
schedule
how
to
burst
out
to
Brigade
jobs
to
virtual
cubelet.
So
if
you
don't
have
enough
capacity
or
don't
want
to
schedule
on
your
usual
nodes,
essentially
you
can
set
your
post
to
be
visual
virtual
cubelet,
and
that's
it.
It's
gonna.
B
And
then
for
a
full
ecosystem,
you
can
see
the
github
page
for
for
that
we
really
really
like
contributors.
If
you
want
to
get
started,
there's
a
good
person
to
label
it
happen,
I
think
most
of
our
projects,
you're
more
than
welcome
to
to
start
contributing
we're
happy
to
help
you
get
started.
That's
not
what
I
was
supposed
to
do.
B
B
The
too
long
didn't
read
for
brigade
is
a
bigger
reason
in
in
cluster
scripting
environment.
That
allows
you
to
change
multiple
containers.
It
is
really
lightweight
and
works
on
any
kubernetes
cluster
you're
right,
scripting
basic
JavaScript,
and
then
it's
a
essentially
the
kubernetes
application.
It's
made
of
a
couple
of
pods.
B
You
can
manage
it
and
monitor
it
in
the
same
way
as
you
would
any
other
kubernetes
application
at
the
CNCs
sandbox
project,
stable
version,
1.2
we're
getting
prepared
to
release
of
1.3,
and
if
you
want
to
learn
more
about
advanced
language
features,
sync
with
more
examples
on
try-catch
we
have
a
advanced
scripting
guide
on
our
documentation.
I
can
learn
more
about
gateways
if
you
want
to
learn
about
how
to
secure
brigades.
So
I
really
encourage
you
to
check
the
the
security
topic.
B
B
If
not,
I
can
show
you
a
couple
of
other
examples
such
as
I
was
telling
you
about
a
couple
of
opinionated
CI
CD
frameworks
built
on
top
of
the
gate.
Here's
one
called
Anya,
which
is
also
integrates
with
the
github
checks
API,
and
allows
you
to
have
trigger
gates
for
different
pull
requests.
So
essentially
you
check
out
the
checks,
the
checks
tab
and
then
it
gives
you
a
button
on
whether
to
promote
the
specific
pull
requests
to
production
or
reject
it
and
perform
deployments,
and
things
like
that.
B
So
this
is
built
on
top
of
the
gate,
for
example,
and
there
are
a
bunch
of
other
projects
built
on
top
of
the
gate
as
well.
Another
one
that
I'm
really
really
excited
about
is
we've
seen
if
you've
kept
seeing
Brigade
being
used
for
end-to-end
testing.
So
essentially
you
have
you
have
your
application
and
then
you
want
to
deploy
it
on
Cooper,
Nate
you're,
using
Cooper
names.
B
There
are
two
options
you
can
create:
a
preview
environment
or
a
different
namespace,
or
you
can
start
a
kubernetes
cluster
inside
of
kubernetes
itself,
using
kind
which
is
kubernetes
in
docker,
which
is
a
kubernetes
6
project.
Essentially,
it
uses
docker
containers
to
start
kubernetes
notes.
I,
really
encourage
you
for
a
local
for
a
local
environment.
It's
really
really
easy
to
get
started
with
kubernetes,
but
here
we
are
configuring,
a
kind
cluster
inside
of
kubernetes
using
Brigade,
and
essentially
this
is
all
we
have
to
do.
We
have
a
kind
job.
B
You
know
you
know
library
and
then
basically
we're
adding
our
tasks
and
executing
it
and
what's
gonna
happen,
and
when
that
as
bouquets
queue
is
going
to
get
executed,
we
see
the
cluster
getting
started
and
we
can
interact
it
the
same
way
as
you
would
interact
with
any
other
cluster
without
and
without
interfering
with
our
production
workloads
right.
So
this
is
an
interesting,
real
big
shout
out
to
the
kind
steam
for
this
project.
B
I
really
encourage
you
to
get
started
with
it,
and
if
you
want
to
use
javascript
dependencies
other
than
what
we
gate
comes
with.
Essentially,
you
can
either
have
dependencies
in
your
github
repo,
you
know
in
a
local
file
and
then
import
them,
or
you
can
put
them
in
abrogate
JSON
file
very
similar
to
a
package
JSON
where
you
could
just
list
your
dependencies
and
use
them
from
there.
So
you
would
just
require
it.
Just
like
you
would
in
a
in
a
normal
JavaScript
project,.