►
From YouTube: So what's new in Brigade 2?
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
If
you've
followed
our
project
at
all,
you
may
have
seen
content
similar
to
this
before
and,
if
that's
the
case,
I'd
recommend
sticking
around
regardless.
It's
an
exciting
time
for
brigade
right
now.
As
of
this
recording,
it
was
just
days
ago
that
we
cut
the
first
release
candidate
of
brigade2,
most
likely
by
the
time
you
view
this
brigade2
has
already
become
generally
available.
A
What
eventually
became
brigade
v1
was
born
at
a
deus
offsite
in
2016.,
the
entire
team
was
assembled
in
denver
and
one
exercise
we
all
went
through
that
day
was
a
shark
tank
style
game,
wherein
teams
pitched
ideas
to
the
senior
leadership
and
the
best
idea
would
get
resources
assigned
to
it.
Well,
brigade
was
the
big
winner
that
day,
but
interestingly,
helm,
which
we
regard
as
our
sister
project
was
born
from
a
similar
exercise
at
the
previous
years
off-site
helmet
brigade
both
were
products
of
an
interesting
thought.
Experiment
that
I'm
going
to
share
with
you.
A
A
A
A
A
That's
where
brigade
comes
in
brigade
offers
asynchronous
event
driven
scripting.
It
can
be
used
to
chain
together
containers
to
create
complex
workflows
and
it
uses
kubernetes
as
a
workload.
Execution
substrate,
that
is
to
say
kubernetes,
is
an
implementation.
Detail
and
users
do
not
have
to
interact
with
kubernetes
directly.
A
A
A
A
So
here
are
some
example
gateways
that
we
have
already
created.
There
are
several
others.
Besides
these
and
they're
generally
pretty
easy
to
build,
so
you
can
expect
us
to
be
creating
more
and
you
can
pretty
easily
create
your
own.
If
you'd
like
to
trigger
your
scripts
with
events
from
an
external
system,
we
don't
already
integrate
with
even
a
proprietary
one.
A
A
A
Every
event
has
a
type
gateways
may
emit
many
different
types
of
events,
and
generally
they
would
map
pretty
directly
onto
events
sent
by
the
external
system
and
received
by
that
gateway.
This
event
indicates
that
someone
starred
a
repository
in
github
gateways
should
always
document
the
events
they
emit.
A
An
event
may
optionally
have
qualifiers
if
you're
familiar
with
labels
and
kubernetes
qualifiers
are
similar,
but
a
little
bit
different.
They
specifically
provide
more
context
about
the
event,
so
here
someone
starred
a
repository
but
which
repository
in
all
likelihood,
no
one
subscribed
to
this
event
is
interested
in
knowing
when
any
repository
was
starred.
It's
more
likely.
One
may
want
to
know
when
some
specific
repository
was
starred.
A
A
A
A
The
embedded
script
responds
simply
by
writing
some
logs
to
the
console.
When
you
embed
a
chunk
of
script
in
yaml,
however,
you
lose
a
lot
of
the
niceties
that
we
usually
take
for
granted
like
syntax,
highlighting,
especially
so
for
more
complex
scripts.
It
makes
more
sense
to
reference
a
script
that
is
stored
elsewhere.
A
A
A
A
So
finally,
it's
demo
time,
one
thing
I
am
not
going
to
show
you
in
this
demo
is
the
installation
process,
because,
frankly,
it's
uninteresting
like
most
other
things
that
are
built
on
top
of
kubernetes
brigade,
is
installed
using
helm
and
our
default
configuration
is
well
tuned
for
a
local
non-production
installation.
So
you
can
be
up
and
running
and
kicking
the
tires
in
just
minutes.
A
A
A
Having
everything
brigade
related
in
a
separate
directory
allows
you
to
have
separate
package.json
files
for
your
main
project
and
for
your
brigade
script
again,
we'll
come
back
to
this
later
in
the
demo
in
the
list
of
things
that
brig
init
did.
You
can
also
see
that
it
created
a
project
definition,
some
notes,
a
file
for
secrets
and
because
we
didn't
already
have
a
dot
git
ignore
file.
It
created
one
for
us
and
added
a
couple
entries
to
it
specifically.
A
If
we
should
check
this
project
into
source
control
in
the
future,
there
are
certain
things
we
wouldn't
want
tracked.
One
of
those
things
is
whatever
npm
modules
our
brigadescript
uses,
because
it's
simply
not
convention
to
track
those
for
any
javascript
or
typescript
project.
That's
in
no
way
brigade
specific.
A
Also,
we
see
that
our
secrets
aren't
being
tracked,
and
that
also
makes
sense,
because
one
typically
does
not
check
sensitive
information
into
source
control.
You
can
also
see
some
notes
were
created.
Those
notes
spell
out
your
next
steps:
we're
not
going
to
bother
looking
at
them
right
now,
because
well,
you've
got
me
instead.
A
A
A
Now,
we'll
look
at
the
main
body
of
the
project.
Definition
recall
that
a
project
fundamentally
pairs
event
subscriptions
with
worker
configuration
that
describes
how
to
handle
those
events.
We
can
see
that
at
work
here
in
this
file,
we're
subscribing
to
events
of
type
exec
that
come
from
a
source
called
brigade.sh
cli
we're
going
to
come
back
to
that
in
a
minute
or
two.
A
We
can
also
see
a
worker
template
section
that
describes
our
worker.
Under
there
we
see
default
config
files
when
your
worker
launches
the
full
contents
of
whatever
you
put
in
this
section
will
be
mounted
into
the
worker
container.
The
worker
always
looks
for
a
script
named
either
brigade.js
or
brigade.ts.
A
So
by
putting
a
brigade.ts
file
here
in
our
project
definition,
we've
effectively
embedded
our
script
in
the
project
definition.
You
can
put
other
files
here
as
well,
but
we
want
to
keep
things
simple
for
right
now.
Now
the
mere
existence
of
this
project
definition
file
doesn't
accomplish
anything
unless
we
upload
it
to
brigade.
A
You
can
also
see
these
projects
all
correspond
to
our
most
active
repositories
and
you
might
surmise
that
we're
mostly
using
brigade
for
ci
and
cd.
I
really
want
to
emphasize
that
brigade
is
generally
useful
for
anything.
You
want
to
automate
ci
and
cd
just
happen
to
be
specialized
cases
of
automation
and
their
needs.
We
had
that
we
were
able
to
quite
easily
fill
using
our
own
product.
A
A
A
A
Inevitably,
however,
people
who
are
kubernetes
experts
are
going
to
want
to
push
brigade
a
little
harder
and
do
some
things
like
automate
maintenance
operations
on
the
cluster
itself
for
this
sort
of
person,
supposing
they
have
direct
access
to
the
underlying
cluster,
telling
them
the
namespace.
That
brigade
created
for
this
project
permits
the
user
to
seek
out
the
kubernetes
service
accounts
in
that
namespace
that
are
used
by
workers
and
jobs
and
amend
their
permissions
so
that
they
can
do
things
within
the
kubernetes
cluster
that
a
worker
or
job
cannot
usually
do.
A
A
A
A
If
you
look
back
at
the
project
definition
you'll
see,
we
subscribe
to
events
of
type
exec
that
come
from
a
source
called
brigade.sh
cli,
well,
primarily
for
testing
and
demo
purposes.
This
type
of
event
is
trivial
to
create
manually
from
the
cli,
so,
instead
of
setting
up
a
gateway,
that's
what
we're
going
to
do.
A
Adding
the
follow
flag
is
a
bit
of
a
convenience
that
we'll
wait
until
the
worker
starts
and
then
begin
streaming
its
logs
to
our
console,
because
we
had
debug
logging
enabled
we
see
quite
a
bit
of
information
about
what
exactly
the
worker
is
doing.
The
most
important
thing
is
that
it
launched
a
hello
job
that
also
ran
to
completion.
A
A
A
This
may
not
seem
like
a
big
deal.
We
already
saw
these
logs
earlier
as
the
event
was
being
handled,
but
the
kubernetes
pod
that
ran
the
worker
is
long
gone
by
this
point,
and
yet
the
logs
have
been
preserved.
This
is
because
we
run
fluent
d
on
every
node
to
collect
logs
from
all
workers
and
jobs
and
forward
them
to
our
database.
A
A
Let's
say
that
over
time
our
needs
change
and
we
need
to
start
doing
something
a
little
more
involved
with
this
script.
It
probably
won't
be
long
before
we're
sick
of
working
with
typescript,
that's
embedded
in
a
gamel
document
and
offers
us
no
syntax
highlighting
or
context
help.
This
is
actually
pretty
easy
to
deal
with.
So
the
first
thing
I'm
going
to
do
is
copy
the
embedded
script
from
our
project
definition.
A
Immediately,
I've
got
all
my
syntax
highlighting
and
such,
but
you
can
see
that
a
brigade
specific
import
that
I'm
using
the
brigadier
library
does
not
resolve.
So
I
cannot
get
context
help
for
that
module.
This
is
pretty
easy
to
fix,
using
conventional
techniques
that
should
be
familiar
to
anyone.
Who's
done
much
with
javascript
or
typescript.
A
A
This
can
be
a
convenient
thing
to
do
for
testing
purposes,
and
it's
important
to
note
that
this
won't
actually
integrate
with
the
brigade
api
server.
In
any
way
you
see,
the
brigadier
library
is
actually
just
interfaces
and
some
stub
implementations
of
those
interfaces
at
runtime.
Our
worker
substitutes
an
alternative
implementation
of
those
interfaces
to
enable
communication
with
the
brigade
api
server.
A
A
There
are
ways
to
control
the
source
and
type
of
the
dummy
event
and
even
the
payload
using
environment
variables,
but
they're
documented
and
so
we're
going
to
move
on.
We've
successfully
separated
our
script
from
the
project
definition.
Let's
revisit
that
definition
briefly
and
remove
the
embedded
script
and
tell
it
to
go
looking
elsewhere
to
find
it.
A
A
Note
that
the
debug
output
from
the
worker
is
a
little
different
this
time
around.
It
tells
you
exactly
what
it's
doing,
which
includes
using
the
package.json
and
yarn.lock
we
provided
to
resolve
dependencies.
You
even
see
where
it
substitutes
an
alternative
implementation
of
the
brigadier
interfaces.
A
A
A
A
A
A
Now
note
that
what
I've
done
here
is
for
demonstration
purposes
only
it's
a
really
bad
idea
to
allow
secrets
to
bleed
into
your
logs
as
I've
done
here
now.
There
have
been
no
changes
to
our
project
definition.
So
there's
no
need
to
update
that,
but
we
have
made
changes
to
our
script,
so
we
should
probably
push
those
up
to
github.
A
A
Really
up
to
this
point,
we've
discussed
just
the
basics.
Brigade
has
a
lot
of
other
tricks
up
its
sleeve
here
are
some
important
features
we
haven't
touched
on.
We
have
get
integration,
so
it's
easy
to
build
and
test
source
code.
We
have
shared
volumes,
so
it's
easy
to
pass
artifacts
from
one
job
to
the
next.
A
We
have
configurable
limits,
so
you
can
configure
the
maximum
number
of
workers
that
may
execute
concurrently
or
the
maximum
number
of
jobs
that
may
execute
concurrently.
This
is
important
because
even
the
largest
kubernetes
cluster
cannot
possibly
execute
an
infinite
amount
of
work.
Concurrently,
we
have
fair
scheduling,
this
is
to
say
each
project
has
its
own
work
queue
and
we
pseudo-randomly
select
events
from
the
head
of
each
one.
A
We
also
have
several
user
authentication
options
that
include
any
open
id
connect,
identity,
provider
and
github.
I
especially
want
to
zero
in
on
that
recall
that
brigade
is
built
to
be
useful
for
teams
where
not
everyone
is
a
kubernetes
expert
and
some
may
not
even
have
credentials
for
directly
accessing
a
kubernetes
cluster.
A
This
introduces
a
requirement
to
authenticate
to
brigade's
apis
in
some
other
way.
We
didn't
want
to
build
user
management
from
scratch,
so
we
opted
to
build
integration
with
third
third-party
identity
providers.
Instead,
our
favorite
is
github.
It's
actually
very
easy
to
configure
a
brigade
installation
to
delegate
authentication
to
github
and
to
limit
authentication
to
users
belonging
to
github
orgs
of
your
choice.
A
A
A
We
have
an
offering
for
chaos,
engineering,
something
called
the
brigade
noisy
neighbor.
That
can
apply
a
lot
of
load
to
your
brigade
installation
and
we
also
offer
a
couple
official
sdks
with
a
third
and
possibly
a
fourth
in
the
works,
because
it's
a
question
we're
asked
frequently.
I
want
to
briefly
touch
on
how
brigade
differs
from
argo,
and
let
me
say
off
the
bat
that
we
love
argo.
We
don't
think
we're
better
than
them.
We
think
we're
different
than
them.
A
A
A
So
the
bottom
line
is
there's
a
lot
of
overlap
between
brigade
and
argo,
but
they
take
very
different
approaches
to
similar
problems.
So
when
would
you
choose
one
over
the
other?
To
a
large
extent,
it
may
be
a
matter
of
personal
preference,
but
other
factors
are
likely
to
enter
the
equation
as
well.
What
exactly
are
you
building?
Argo
is,
in
my
opinion,
in
many
ways,
lower
level
than
brigade.
A
It's
probably
a
good
starting
point
if
you're
building
your
own
product
that
has
a
need
to
build
and
submit
workflows
for
execution
brigade
is
a
little
more
oriented
around
end
users
and
in
particular
end
users,
who
are
not
necessarily
kubernetes
experts.
So
if
your
team,
that's
looking
to
automate
a
lot
of
your
own
tasks
quickly
and
the
team
doesn't
have
a
lot
of
kubernetes
experience
on
the
bench,
brigade
may
be
what
you're
looking
for.
A
A
Second,
I
hope
this
will
be
a
useful
primer
for
anyone
who
might
be
interested
in
making
contributions
to
the
project
toward
the
top
of
this
diagram.
We
see
external
systems.
These
could
be
things
like
github
or
slack.
They
send
events
to
gateways
which
convert
the
events
to
brigade
events
and
utilize.
The
brigade
api
to
enqueue
events
on
a
message,
bus
and
the
cli
permits
end
users
to
interact
with
the
api
as
well.
A
A
A
This
diagram
is
the
same
as
the
previous
one,
but
superimposes
the
specific
technologies
and
protocols
that
brigade
utilizes
our
api
is
a
restful
one
served
over
https,
our
database
is
mongodb
and
our
message
bus
is
artemis,
which
is
the
next
generation
of
apache
mq.
The
api
server
and
scheduler.
Both
talk
to
the
message,
bus
using
the
amqp
1.0
protocol
we
use
fluentd
to
collect
and
forward
logs
and
last,
but
certainly
not
least,
kubernetes
is
our
workload.
Execution
substrate.
A
So
here's
our
website
some
getting
started
documentation
our
main
repo
on
github,
our
twitter
handle
and
our
slack
channel,
which
is
part
of
the
kubernetes
slack,
especially
want
to
highlight
the
quick
start
as
being
your
next
step.
If
you
want
to
try
this
out
for
yourself-
and
I
also
want
to
emphasize
that
you
should
totally
come
talk
to
us
on
slack-
we
love
our
community.
We're
really
interested
in
hearing
from
you
thanks
again
for
viewing
this
webinar
have
a
wonderful
day.