►
From YouTube: Deep Dive: 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
Deep Dive: Brigade - Radu Matei, Microsoft
In this session, we will explore the Brigade architecture, and how it is built to chain together containers and share data between them. We will deep dive on how external events are routed and transformed into jobs, and how Brigade uses JavaScript for more complex scripting and error handling, and differentiate itself to enable scenarios that are extremely difficult to achieve in a purely declarative framework. In the end, we will take a look at how to build custom event gateways, and have a look at the future roadmap.
https://sched.co/N7N9
A
My
name
is
Radha,
and
today
we're
gonna
have
a
deep
dive
into
Brigades
I'm,
a
software
engineer
at
Microsoft
I'm,
a
on
open-source
maintainer
on
a
bunch
of
projects.
Brigade
is
one
of
them:
the
cloud
native
application,
bundles
and
some
others
I'm
a
piano
enthusiast.
My
neighbors
don't
like
me
very
much
because
I'm
learning
so
today
we're
gonna
have
a
look
at
Brigade
and
specifically
we're
gonna.
Take
a
look
at
a
bit
of
an
advanced
scripting
guide
right.
A
How
to
do
things
that
you
wouldn't
necessarily
be
able
to
do
with
llamó,
for
example,
how
Brigade
works.
We
look
at
building
custom
gateways,
take
a
look
at
securing
Brigade
and
then
a
bit
of
dependencies
and
strategies
for
testing
Brigade,
but
before
I
get
started.
If
you
haven't
seen
the
introduction
to
Brigade
or
if
you're
not
familiar
to
Brigade
I,
advise
you
to
have
a
look
when
you
go
back
home
to
the
yesterday
session,
the
introduction
to
Brigade.
A
But
if
you
are
not
familiar,
we
think
about
an
operating
system
as
the
thing
that
manages
processes
on
a
machine
right
well.
In
the
same
way,
we
can
think
at
kubernetes
as
a
thing
that
manages
containers
on
a
cluster
right,
and
if
you
go
with
the
analogy
a
bit
further,
then
if
you
ever
done
operating
system,
shell
scripting
like
bash
or
PowerShell.
A
Well,
that
gives
me
a
flow
control
that
I
can
wrap
the
execution
of
various
processes,
but
I'm,
not
a
good,
but
it's
not
opinionated
on
what
that
process
does,
and
essentially
it
allows
me
to
do
something
like
this.
I
can
start
a
process
LS
take
it
result
in
the
output
of
it
do
something
with
it
then
use
it
as
input
for
the
next
process.
How
would
something
like
this
look
on
kubernetes?
Well,
I
want
to
do
the
same
thing
right.
A
I
want
the
float,
control
that
wraps
the
execution
of
containers,
but
it's
not
opinionated
about
what
that
container
does
right.
So,
ultimately,
I'd
like
to
be
able
to
do
something
like
this
to
have
a
scripting
programming
language
and
have
a
scripting
environment
that
allows
me
to
do
that
for
each
result
of
the
executing
container,
use
the
output
and
start
another
container
and
use
the
output
with
it.
How
do
people
do
that?
A
Dejan,
kubernetes,
well,
I've,
seen
batch
scripts
in
busybox
I've
seen
local
batch
scripts
that
do
keep
control
exact
then
wait
for
that
then
we'll
grep
and
then
do
a
keep
control.
Exec
again,
that's
not
very
maintainable,
and
it's
not
very
testable
and
I've
seen
people
do
things
with
the
ammo
that
no
one
should
be
able
to
do
with
the
ammo.
A
We
think
that
Brigade
might
be
a
fit
if
you
have
that
trouble.
If
you're
struggling
with
things
like
that,
so
Brigade
is
a
cloud
native
computing
foundation,
sandbox
project
and
essentially
it's
a
framework
for
event-driven
scripting
on
top
of
kubernetes.
It
is
really
really
lightweight
and
it's
built
with
kubernetes
native
objects.
Its
purpose
in
the
end
is
to
allow
you
to
chain
together
multiple
containers
and
respond
to
certain
events
that
are
happening
and
create
workflows.
A
A
Is
that
large
enough?
Okay,
so
this
is
the
simplest
Brigades
cube
that
you
can
write
and
essentially
what
it
does
is
it
defines
a
new
job
called
do-nothing.
It's
gonna
pull
a
container
using
the
image
Alpine.
Imagine
you
can
use
any
container
that
you
have
access
to
pull
either
from
a
Public
Registry
or
from
a
private
internal
one.
A
It
defines
the
tasks
that
I
want
to
run
inside
that
container
and
I
just
run
it
for
someone
who's
never
seen
kubernetes
before
starting
job
and
scheduling
things
to
run
on
top
of
kubernetes
is
as
easy
as
writing
a
couple
of
lines
of
JavaScript
and
the
goal
is
to
make
it
as
easy
as
possible
for
newcomers.
But
at
the
same
time,
if
you
know
how
to
do
things
in
kubernetes
well,
we
have
real
language
features.
A
So,
for
example,
if
you
want
to
wait
for
a
container
to
finish
for
par
and
kubernetes
to
finish
before
starting
a
new
one.
Well,
there's
async
await
in
JavaScript
that
you
can
use
right.
On
top
of
that,
we
also
have
an
API
called
the
groups
API,
which
essentially,
you
can
just
define
jobs
and
say
I-
want
to
run
each
of
those
in
order.
So
if
we
run
this
thing.
A
So
I'm
using
the
Brig
Brigade
CLI
called
brig,
which
essentially
allows
me
to
start
the
execution
flows
manually,
we'll
see
in
a
minute
how
it's
supposed
to
work
and
how
you're
supposed
to
react
to
actual
real
events,
but
essentially
I
am
executive,
starting
up
the
scheduling
of
that
script,
and
at
this
point
what
we
can
do
is
we
can
use
the
web
dashboard
of
Brigade
and
see
that
up
a
build
is
started
and
essentially
I.
Go
to
that
and
I
can
see
the
two
jobs
that
started
if
you're,
not
that
interested
in
web
dashboards.
A
A
If
you
ever
try
to
attach
a
persistent
volume
to
multiple
containers
in
a
coherent
flow
and
that's
a
bit
difficult
right
in
Brigade,
you
can
define
that
storage
enabled
equals
true
and
Brigade
will
automatically
create
a
persistent
volume
and
attach
it
to
all
jobs
in
a
certain
script
right,
then
we
do
that
for
you.
So
what
this
does?
The
first
job
will
write
in
a
shared
file.
The
second
one
would
write
as
well,
and
then
the
third
one
will
display
whatever,
however,
happened
after
the
execution
of
those
two,
so
I
can
do
something
like
this.
A
A
A
Because
Brigade
is
built
on
kubernetes
and
understands
kubernetes
objects,
attaching
a
secret,
something
that's
prevalent,
usually
in
any
non-trivial
example:
I'm
going
to
need
to
talk
to
a
database
or
talk
to
a
storage,
account
I'm,
going
to
need
credentials
and
secrets
right,
it's
as
simple
as
referencing
a
secret
in
in
the
environment
right.
You
should
not
do
that.
Probably
echo
secrets
right,
but
Brigade
allows
you
to
do
if
you're
a
if
you're
an
administrator
of
a
brigade
installation
you
can
prevent
that
from
happening
right.
A
You
can
set
that
for
all
of
the
jobs
that
are
running.
No
one
can
mount
secrets
rather
in
Brigade
gives
you
that
ability,
because
it's
a
programming
language
you
can
have
something
like
try
catch
retry
policies.
You
can
catch
exceptions
and
recover
from
failures.
What
this
job
is
going
to
do
is
going
to
start
the
first
one
and
it's
gonna
exit
successfully,
but
the
second
one
is
going
to
exit
with
an
exit
code.
A
A
I
kicked
off
the
script
and,
if
I
go
back
to
the
CLI
dashboard,
I
can
see
the
first
one,
which
was
successful
and
I
can
see
the
second
one
failed
right.
Let's
go
back
to
the
web
dashboard
and
see
that
we
actually
recovered
from
that
failure.
We
can
see
that
the
pod
fails
right.
The
second
job
failed,
but
I
caught
the
exception,
and
at
this
point
I
can
do
anything.
I
want
I
can
do
a
cleanup
process.
I
can
retry
if
I
wanted
to.
A
Another
thing
that
you
can
do
is
define
based
jobs.
If
someone
in
your
company
is
responsible
for
building
this,
they
have
to
understand
how
they're
supposed
to
build
it,
and
then
other
people
can
just
use
it
can
instantiate
it
with
new
job
and
that's
it.
It's
gonna
run
whatever
it
was
declared
to
do.
A
But
how
does
Brigade
actually
work
right?
I
said
in
the
beginning
that
it's
an
event-driven
scripting
environment
for
kubernetes
right,
the
events
have
to
come
from
somewhere
right.
Whenever
there's
an
event
triggered
outside
of
a
brigade,
they
can
be
webhooks,
they
can
be
any
event
source
that
you
might
want
to
respond
to
and
we'll
see
in
a
minute.
What
is
that
there's
an
event?
A
There's
a
component
in
Brigade
called
the
Gateway
which
will
map
the
external
events
to
a
brigade
event,
and
then
your
JavaScript
file
will
get
executed
and
kubernetes
pods
will
get
started
specifically
the
gateways.
There
is
a
component
that
translate
the
events
after
the
event
arrived
and
it
was
transformed
by
a
gateway
there's
a
kubernetes
controller
that
listens
for
those
events,
and
then
it
will
start
a
pod
to
exit
with
your
javascript
file.
A
At
that
point,
executing
the
javascript
file
will
create
kubernetes
pods
that
the
java
sea
follow
manages
and
schedules,
and
on
top
of
that,
there's
an
api
that
you
saw
with
the
web
dashboard
in
the
CLI.
So
essentially,
this
is
how
it
runs
where
the
events
come
from.
Well,
out-of-the-box
brigade
comes
with
a
couple
of
gateways,
things
that
understand
the
outside
world:
there's
a
generic
gateway
that
understand
any
arbitrary
payload,
Jason
payload
that
you
might
have.
If
you
have
a
system
that
generates
Jason,
you
have
an
out-of-the-box
thing
that
can
map
to
brigade
events.
A
The
same
gateway
also
supports
cloud
events,
which
is
a
CNCs
specification
for
standardizing
JSON
schema
payloads.
All
cloud
support
cloud
providers
support
it.
We
support
it
as
well.
So
if
you
have
up,
for
example,
a
storage
bucket
that
generates
an
event,
you
can
catch
it
with
brigade
out
of
the
box.
A
These
events
they
can
come
from
web
hooks
from
HTTP
triggers,
but
ultimately
any
application
that
can
create
a
kubernetes
secrets
can
create
brigade
events.
Ultimately,
brigade
events
are
just
kubernetes
secrets
with
a
special
label
and
a
type
right.
We
do
that
for
a
number
of
reasons.
I'm
gonna
get
into
it,
but
you
have
examples.
All
of
our
production
gateways
are
built
with
go.
We
have
examples
on
how
to
do
it
with
no
js'.
You
can
do
it
in
bash
by
creating
a
secret
right,
and
we
have
examples
for
Python
as
well.
A
If,
for
example,
you
want
to
respond
to
I,
don't
know
a
Kafka
event,
well,
there's
a
Python
gateway
that
does
that,
for
you,
all
you
have
to
do
is
be
close
to
the
source
of
the
event,
catch
that
event
from
the
outside
and
be
able
to
create
a
kubernetes
secrets,
and
that's
it.
So,
let's
see
how
a
custom
gateway
actually
looks.
Like
so
I
told
you
that
you
can
write
anything,
you
want
even
a
bash
script.
That
creates
a
an
event.
A
Ultimately,
it's
just
the
secret
right
with
a
couple
of
labels
and
tie
and
types
right.
If
you
can
create
a
kubernetes
secret
with
that,
then
Brigade
is
gonna.
Understand
that
the
controller
will
pick
it
up
and
will
will
start
executing
your
script.
But
let's
have
something
a
bit
more
testable
that
we
can
reason
about
right.
A
We
have
a
getting
started
for
gateways
written
in
nodejs
and
essentially
what
this
does
is
it
waits
for
a
post
requests
and
whatever
one
comes
with
a
project
name,
it
will
create
a
brigade
event
and
very
similar
to
what
you
see
in
the
batch
script.
The
brigade,
the
creation
of
the
brigade
event
itself.
A
It's
just
the
kubernetes
create
a
namespace
secrets
right.
It's
the
same
thing.
If
you
can
even
manage
to
create
this
in
any
language,
then
you
have
a
gateway.
You
saw
me
earlier
using
Brig
the
CLI
for
Brigade
brig
acts
like
a
gateway.
I
just
simulate
events
on
my
command
line.
Brigade
catches,
those
and
starts
whatever
a
script,
I
I
defined.
A
A
And
I
can
see
that
two
seconds
ago
an
event
was
created
with
the
name
node
gateway.
That
was
the
source
of
the
event,
so,
whatever
application
you
have
that
connects
to
outside
events
like
external
things,
if
you
can
create
a
kubernetes
secret
to
map
it
inside
plus,
the
cluster
brigade
will
pick
it
up.
A
Now,
let's
talk
a
bit
about
how
to
secure
a
brigade
environment
right,
ultimately,
brigade
is
built
on
top
of
kubernetes.
It's
a
kubernetes
application.
It's
built
with
a
controller
which
is
a
component
there's
an
API,
and
there
are
a
worker
pods
that
get
created
right
to
schedule
your
jobs,
the
things
that
you
want
to
execute.
Well,
because
it's
a
kubernetes
application.
You
treat
it
just
like
any
other
kubernetes
application
right.
Our
recommendation
is
to
isolate
brigade
in
a
single
namespace.
We
can
talk
about
the
reasons
if
you
want
to.
A
Ideally,
you
want
to
use
our
back
roles,
ways
access
control,
it's
enabled
by
default,
and
you
should
probably
use
it.
If
you
have
external
gateways
that
accept
events
from
the
outside
always
use
HTTPS,
we
have
a
documentation
with
a
tutorial
on
how
to
use
certain
manager,
nginx
ingress
controller
and
how
to
configure
DNS
using
clouds
there.
So
you
can
swap
any
of
those
components
out
with
your
own
and
you
can
still
you
can
still
do
it.
A
really
important
point:
Brigade
allows
you
to
start
container
jobs
right.
A
They
allow
you
to
pull
a
container
image
from
your
container
registry
or
from
the
outside
and
started
in
your
cluster,
always
use
images
that
you
trust.
They
will
start
in
your
cluster
right.
You
don't
want
to
use
things
that
might
have
vulnerabilities
in
them
that
can
exploit
things
in
your
cluster
and
another
really
really
important
point,
always
validate
user
input
and
always
authenticate
events.
A
Here's
the
scenario
right:
you
have
an
external
gateway
that
creates
Brigade
events.
The
brigade
event
gets
picked
up
by
the
controller
and
then
starts
the
things
that
you
want
to
execute
starts
multiple
workloads
on
kubernetes.
If
someone
finds
out
your
endpoint,
they
might
be
able
to
start
a
lot
of
things
in
your
cluster
right,
always
authenticate
that
the
source
of
the
event,
the
sort
of
the
event
that
saw
the
web
hook
or
whatever
type
of
system
you
have
for
the
event,
is
authenticated
to
do
that.
Use
a
secret
user
authentication
tokens.
A
We
have
examples
of
how
to
do
that
as
well.
Now,
because
we
grade
is
actually
running
in
a
JavaScript
environment,
you've
control
the
flow
using
javascript
and
because
you're
able
to
show
you
how
to
tree
a
specific
class
of
job
that
is
already
defined
by
someone
you
can
just
start
it.
Well,
you
can
use
dependencies
in
your
Brigade
JS
file.
You
can
import
JavaScript
modules,
either
locally,
that
someone
that,
from
the
same
repo
that
are
defined
or
you
can
pull
packages
from
NPM
or
any
any
registry,
actually
right.
A
If
the
thing
to
note
here
is
that
those
are
pulled
every
time
you
have
an
execution.
If,
though,
if
the
thing
takes
a
long
time-
or
you
know
that
you're
gonna
use
the
event
a
lot,
you
might
want
to
consider
building
and
building
that
package
directly
into
the
image.
So
they
don't
pull
it
every
time.
Important
here
is,
you
should
avoid
putting
too
much
logic
in
bridge
ajs.
A
A
If
a
number
is
13,
it's
a
really
useful
package
and
then
I
also
require
something:
that's
local,
it's
dot
local
depth
circle
and
if
I
go
there,
I
can
see,
there's
a
very
simple
node.js
module
which
exports
two
simple
files
right:
that
do
something
that
calculate
the
area
where
did
I
define
is
13.
Well,
there's
a
brigade
adjacent
file
which
has
a
field
for
dependencies.
A
If
this
is
present
in
your
project,
whenever
there's
a
build
scheduled,
Brigade
will
read
the
script
and
will
install
the
package
that
you
define
here
right,
there's
also
strategies
if
you
want
to
connect
to
private
registries
and
there's
an
open
issue
for
that
with
detail,
steps
on
how
to
do
it.
So
let's
actually
run
this
and
see
what's
happening.
A
A
You
can
actually
unit
test
the
scripts
that
you
that
you
provide
there's
a
project
called
grig
test.
Its
purpose
is
to
check
that
big
ajs,
first
of
all,
is
well
built
that
it
doesn't
have
syntax
errors,
that
it
uses
the
actual
things
that
are
defined
in
in
your
environment
and
also
automatic
eyes.
It
gives
the
unit
tests
for
you.
It
does
not
run
the
things
that
you
define
to
schedule
on
the
cluster.
You
can
mock
them
and
it
does
not
need
kubernetes
for
that.
A
There's
also
a
tool
called
Brigade
integration
test
that
someone
from
the
community
builds.
Essentially,
it
uses
mini
cube
it
automatically
configures
brigade,
it
creates
the
project,
it
creates
events
and
checks
that
the
output
of
the
event
is
actually
what
you
intended.
It's
using
I
think
bats
the
bash
testing
framework,
and
essentially
it
allows
you
to
functionally
test
everything
that's
happening
in
your
pipeline.
A
We
have
built-in
support
for
the
CN
CF
cloud
event
specification
to
define
events.
We
have
integration
with
the
github
API.
We
actually
use
Brigade
quite
extensively
for
our
own
development
purposes.
This
is
this
is
running
in
github
right.
This
is
the
brigade
repo
for
every
pull
request
there
are
builds.
The
pull
request
is
an
event
for
us
right.
We
kick
off
a
build,
that's
happening
in
our
cluster
in
our
subscription
that
we
manage
it's
not
in
a
public
class
or
it
can
be.
Public
cloud
can
be
in
a
private
cloud
in
your
own
local
environment.
A
A
We
also
have
integrations
with
Prometheus
and
virtual
cubelet.
Both
of
them
are
CNC
F
projects
and
the
fear
system
generates
arbitrary
payload
of
JSON.
You
can
catch
that
as
well.
There
are
a
lot
of
tools
that
I've
shown
you
actually
the
web
dashboard.
The
CLI
dashboard
I've
shown
you
a
few
gateways.
Most
of
them
are
built
by
the
community
with
us.
A
If
you
want
to
contribute
your
own
we're
happy
to
help
you
get
started,
we
can
find
the
docs
on
Docs
that
we
gave
out
SH,
and
this
is
the
moment
where
I
get
a
shout
out
to
Ronan
from
our
team
who
builds
awesome,
documentation
websites.
If
you
want
to
contribute,
we
have
a
couple
of
layers.
Labeled
good
first
issue,
we'll
be
more
than
happy
to
help.
You
get
started
with
the
development
environment
and
after
you
contribute
things,
and
we
actually
want
you
to
get
involved
right.
We
have
a
brigade
channel
in
this
kubernetes
Lac.
A
A
Within
the
cluster
specifically
Brigade
has
technically
it
has
only
one
component
that
needs
to
run
all
the
time,
which
is
the
controller
that
listens
for
events,
and
that's
the
only
thing
that
needs
to
be
running.
You
probably
also
need
another
part
to
actually
generate
the
events
but
other
than
there
are
two
parts
right
the
moment
the
events
is
generated.
The
controller
creates
the
worker
pod,
which
executes
your
JavaScript
scripts
and
that
generates
another
kubernetes
parts
other
community
spots.
A
A
A
The
quote
is:
unlike
the
comparison
with
Kay
native
there's,
also
comparison
with
Argo
that
usually
comes
up
essentially
the
minute
you
want
to
actually
execute
things
and
the
minute
you're
not
only
declarative.
The
minute
you'd
have
to
execute
something
check.
The
status
pass
information
between
multiple
pods
recovery,
retry
policies,
try
catch.
You
need
a
real
programming
language
right.
If
you
need
that,
then
probably
Brigade
is
the
right
thing.
I've
seen
people
do
things
with
llamo.
There
are
insane
if
you
want
something,
that's
testable
and
maintainable,
maybe
have
a
look
at
brigade.
D
D
Can
you
speak
a
little
bit
more
about
this
choice
between
declarative
and
imperative
figures?
So
it's
true
that
you
can
add
like
error,
handling
and
retry
some
suffered.
Some
part
of
this
declarative
approach
has
been
at
the
controller
or
handle
set,
and
not
the
user.
So
now
the
user
needs
to
add
this
logic
to
what
the
retry
should
be,
and
it's
not.
D
A
A
To
speak
a
little
bit
more
about
the
declarative
approach,
there's
actually
I
guess
three
projects
now
which
I'll
their
goal
is
to
provide
a
declarative
API
on
top
of
brigades.
So
essentially
you
can
write
your
own
Brigade
worker.
That's
the
thing
that
knows
what
to
execute.
There
are
people
who
are
reading
llamo
in
the
brigade
worker
and
they
have
their
custom
definition.
I
have
their
if
there's
a
project
that
does
a
CR
D
for
Brigade
events
and
they
define
the
job
as
a
CR
D.
It's
up
to
you.
Ultimately,
just
one.
D
E
So
you
say
just
you
have
some
kind
of
complicated
relationship
with
site
cars
so,
to
you
supports
BOTS
or
chops
with
side
cars
that
would
like.
You
have
a
have
a
vault
manager,
sidecar
I'll,
post
credentials
for
a
job,
and
then
there
is
a
long-running
cycle
actually
but
needs
to
terminate
with
the
main
job.
Something
like
that.
So.
A
The
short
answer
for
that
is
no
the
long
answer
is
we
have
an
init
container
for
jobs
that
you
can
create,
that
can
define
ok
and
we
do
not
have
a
sidecar
exactly
because
which
you
in
kubernetes,
if
you
have
a
sidecar,
you
have
two
containers
in
a
pod.
You
cannot
define
which
one
gives
the
life
cycle
of
the
pods
right.
It's
that's
our.
A
Were
thinking
about
it,
but
ultimately
it
would
give
us
the
option
to
probably
specify
that
this
container
is
the
main
one
it
if
the
user
doesn't
automatically
kill
the
other,
then
you
have
a
thing.
That's
running
forever
right.
We
try
to
avoid
allowing
users
to
shoot
themselves
in
the
foot
feel
free
to
comment
on
the
issue.
It
we've
have
a
lot
of
discussion
specifically
for
this
we'd
love
to
have
examples
in
use
cases
specifically
for
it.
Thank.
E
E
B
So
I'm
just
wondering
about
the
availability
of
the
basically
being
able
to
accesses
to
create
a
storage
drive,
so
I'm
missing
the
name
of
the
kubernetes
api,
which
you
basically
call
for
that,
but
basically
being
able
to
instantiate
different
objects
of
the
cloud
provider.
Be
the
hard
drive
for
anything
yeah.
Would
that
be
possible
with
brigade
to.
A
In
a
in
a
brigade
job,
you
can
execute
any
container
right
if
you
have
the
it
doesn't
use
directly.
The
well
that's
an
interesting
question
because
you
could
do
that
as
well.
So
no
js'
has
a
kubernetes
client.
So
technically
in
the
brigade
JS
file,
you
can
use
the
kubernetes
api
to
do
anything
you
you
need
to.
So
you
can
access
any
API
in
the
brigade
javascript
file.
A
F
A
Probably
the
first
one
that
when
people
hear
Oh
pipeline
and
scripting
the
first
one
is
CI
CD
right,
that's
the
first
one
that
comes
into
mind
and
we
actually
use
it
extensively
for
CI
CD.
It's
also
a
poke.
It's
also
a
foundation
for
other
CI
CD
platforms.
I
know
personally
about
least
three
platforms
that
are
building
CIS
on
top
of
rig
8.
Another
one
is:
there
are
security,
jobs,
security
scanning
jobs
running
every
night
inside
clusters,
they
scan
every
application
with
every
container
image
and
they
do
that
they
do
retry
policies.
A
If
there's
security
is
there
critical
security
vulnerabilities,
they
send
an
email
to
someone
right.
You
have
the
ability
to
do
that.
Other
one.
It
which
is
really
interesting
is
aggregating
data
from
multiple
sources,
so
they
have
scheduled
jobs
that
connect
to
a
storage,
accounting,
Cloud
a
to
a
storage
bucket
in
cloud
B
and
to
a
local,
my
sequel,
running
somewhere.
They
aggregate
the
data
and
generate
reports.
Another
one
which
is
really
interesting
is
as
part
of
the
CI
process,
the
spin
preview
environments.
A
So,
essentially,
you
build
the
application,
create
a
separate
namespace
for
it,
deploy
everything,
maybe
use
a
service
mesh
to
start
directing
traffic
as
a
canary.
Maybe
not,
if
you
don't
have
one,
have
someone
actually
validate
that
the
namespace
and
application
is
running
correctly
and
then
simply
delete
it
in
the
end,
those
are
some
that
we
see
recurrently.
There
are
other
really
interesting
ones.
There's
someone
who's
running
eight-hour
jobs
on
top
of
brigades,
they're
running
nightly.
There
are
various
use
cases.
A
C
A
Specifically,
there's
an
integration
with
Prometheus
to
export
metrics
and
everything
that
Prometheus
offers
and
right
now
we're
looking
into
essentially,
if
you,
if
there's
a
way
that
you
observe
your
applications
on
kubernetes
right
now,
because
everything
in
Brigade
is
a
kubernetes
pod
deployment
or
PVC
or
storage,
or
anything
else
that
experien
it
is
native.
You
can
keep
using
that
right.
A
If
you,
if
you
have
you,
add
some
annotations
that
you
put
on
resources
so
that
they're
observed-
and
you
can
continue
to
do
that-
we're
actively
looking
into
adding
documentation
for
things
like
linker,
deep
meshing
right
for
Brigade
job.
So
you
can
see
when
they
started.
You
can
observe
them
the
same
way
as
other
applications.