►
From YouTube: Microservices, Service Mesh, and CI/CD Pipelines: Making It All Work Together [I] - Brian Redmond
Description
Microservices, Service Mesh, and CI/CD Pipelines: Making It All Work Together [I] - Brian Redmond, Microsoft
Microservices come with many advantages for massively scaling applications. With that comes many challenges around service communication and application updates. It is pretty simple to do blue/green deployment and canary releases with a basic web site. But what about thousands of microservices? How can we have blue/green deployments at the service level while still allowing for efficient communication? This is one of the areas where service mesh technology is a huge benefit in Kubernetes.
In this session, I will show how to use common CI/CD tooling such as Spinnaker or Jenkins to drive microservices deployments with Kubernetes. I will show how service mesh technologies such as istio and linkerd ease the ability to efficiently deliver and test microservices in Kubernetes. All without substantial changes for the microservice developer. Additionally, I will provide comparisons of the wide variety of tools available in this area.
The overall goal of this demo heavy session is to show the value of these technologies working together to ease the delivery of cloud native applications.
About Brian Redmond
Brian Redmond is an Azure Architect on the Global Black Belt team. Brian focuses on containers, microservices, DevOps, and cloud native applications in the Azure cloud platform. Brian has been working in technology for over 20 years and has a mixed background across application development to infrastructure. Brian is based in Pittsburgh, PA and enjoys running, biking, and tinkering with new technology.
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 21! Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy and all of the other CNCF-hosted projects.
A
All
right,
hello,
everybody
thanks
for
thanks
for
coming
to
this
session,
I
appreciate
you
guys
picking
this
session.
I
know
you
have
really
an
amazing
agenda
of
possible
things
to
see
at
this
time.
I
mean
this.
This
this
conference
has
just
so
many
great
sessions
to
attend.
I
appreciate
you
coming
to
see
to
see
my
talk
here,
so
this
is
about
micro
services
and
service,
mesh
technology
and
CI
CD
and
kind
of
bringing
it
all
together.
Just
a
first
off
Who
am
I.
My
name
is
Brian
Redmond
I
work
for
Microsoft.
A
My
last
name
is
Redmond.
That's
been
my
name
ever
since
birth
I
didn't
change,
my
name
I
didn't
do
any
of
those
things.
To
be
honest.
I've
been
at
Microsoft
for
about
17
years,
so
feel
free.
After
the
talk
kind
of
bring
on
all
the
traditional
Microsoft
jokes,
we
can
make
our
Clippy
jokes.
We
can
make
our
blue
screen
of
death.
Jokes
I'm
used
to
all
that
and
quite
comfortable
with
it.
A
These
days,
I'm
a
part
of
the
Azure
global
Black,
Belt
team
and
I
help
customers
deploy
cloud
native
applications
on
Azure
and
use
our
Azure
cloud
platform.
I've
been
working
at
Microsoft,
as
I
said
for
17
years,
doing
all
kinds
of
different
things,
but
really
working
with
Azure
since
its
inception
and
I'm
a
big
fan
of
our
Azure
cloud
platform.
A
So
you
can
find
me
on
Twitter
when
I'm
not
at
work,
I
like
to
run
so
I
do
a
lot
of
marathon
running,
so
various
marathons
start
line
selfies
and
things
like
that
you'll
see,
but
I
do
like
to
spend
my
time
running
when
I,
when
I
can
so
when
I,
when
I
submitted.
The
idea
for
this
talk
to
be
honest,
I
did
not
think
it
would
get
accepted.
I
thought
I'll
throw
out
this
idea.
I
know
about
these
various
technologies.
A
Maybe
I'll
try
to
piece
them
together
and
put
something
interesting
and
it'll
never
get
picked.
In
fact,
I
also
submitted
a
safe
topic
that
did
not
get
selected,
but
but
when
I
got
the
email
back
much
to
my
surprise
and
my
shock,
it
was
kind
of
oh
I
actually
have
to
do
this,
and
so
you
know,
based
on
the
amount
of
response
here,
I
think
it
is
something
that
that
people
want
to
see
and
if
anything,
I'm
really
good
at
writing
those
CFPs
and
coming
up
with
with
interesting
sort
of
tag
lines
to
them.
A
What
am
I
going
to
talk
about?
Well,
we
I
think
we
all
know
what
CI
CD
is
we're
not
going
to
spend
time
here,
defining
that
we
do
want
to
make
sure
we
understand
kind
of
the
difference
between
CI
and
CD.
For
this
talk,
we're
going
to
spend
a
little
bit
more
time,
talking
about
that
continuous
deployment
and
and
automating
things
that
are,
that
are
a
part
of
our
deployment
process
and
we'll
talk
about
different
ways
that
we
can
do
that.
A
A
It's
really
important
if
you
have
this
pipeline
to
have
that
be
declared
in
a
code
library,
so
we
can
treat
it
with
the
same
rigor
that
we
treat
our
actual
application
source
code
and
so
forth
and,
of
course,
I'll
also
talk
about
service
mesh.
There's
a
lot
of
excitement
around
service
mesh,
there's
a
lot
a
lot
of
different
opportunities
and
different
kinds
of
service
mesh
technology.
A
You
can
use
in
particular
with
kubernetes
all
right,
sound
good,
so
when
I
think
of
CI
CD
I
like
to
think
of
it
as
a
an
assembly
line,
you
know
I've
got
these
various
robots
in
this
case
manufacturing
something
for
us.
This
is
robots
before
the
robot
apocalypse
before
Skynet
and
before
they
actually
take
over
they
do
they
do
automation,
they
do
it
consistently
and
they
do
it
very
well
and
our
CID,
our
CI
CD
pipeline
is
the
same
kind
of
concept.
A
We
write
this
pipeline
it'll
automatically
repeat
that
process
over
and
over
again
the
same
way,
every
time
we're
feeding
in
a
new
version
of
our
application.
The
problem
with
that
could
be
that
the
application
could
actually
have
a
problem
in
it
and
what
we
don't
want
to
end
up
with
is
this
automation
actually
deliver
bad
code
into
the
environment.
We
do
a
bunch
of
testing.
We
shouldn't
lis
hope
that
we
did
all
the
testing
we
could.
We
did
integration
testing,
we
did
load
testing.
A
We
hope
our
test
environment
really
is
like
production,
but
in
the
end,
sometimes
eventually
we're
just
crossing
our
fingers
and
what
we
don't
want
is
to
learn
about
bugs
and
issues
from
the
customer.
We
don't
want
to
find
out.
There
was
an
issue
by
hearing
about
it
directly
from
the
customer
or
even
worse,
hearing
about
it
on
Twitter
and
hearing
about
all
the
ugliness
and
so
forth,
like
that,
so
we
need
better
ways
to
solve
that
solve
that
problem
for
us
and
I
would
argue.
A
Obviously,
canary
testing
is
something
we
can
do
to
help
us
with
this
problem,
and
this
is
a
pretty
common
technique.
I
think
most
people
here
at
least,
if
they're
not
already
doing
it,
are
underst
what
it
is
I
have
this
application
I,
maybe
go
through
some
kind
of
proxy
I
put
out
the
second
new
version
of
the
application,
alongside
the
the
the
existing
production
one
and
I
route,
some
of
the
traffic
over
to
it.
A
This
comes
from
the
concept
of
canary
in
a
coalmine
I'm
afraid
to
go
into
the
coal
mine,
so
I
I
submit
a
poor
bird
to
go
through
into
the
cave
and
hope
that
it's
safe,
and
so
this
can
help
us
understand.
What's
actually
going
on,
does
the
application
actually
work
while
I'm
getting
real
production
traffic?
But
if
it's
gone
wrong,
it's
easy
for
me
to
switch
back.
The
impact
is
much
smaller.
This
is
a
great
technique
and
something
I'm
sure
everybody
here
is
familiar
with
and
already
doing.
A
But
what
about
when
I
have
a
microservices
application?
Now
I've
got
lots
of
services-
it's
not
quite
so
simple
to
take
those
same
techniques
that
I
would
apply
at
the
front
end
across
a
mesh
of
services
that
basically
all
of
the
services,
are
talking
to
everything.
So
this
problem
becomes
a
bit
harder.
I
need
a
way
to
do
canary
testing
anywhere
in
this
environment
anywhere
without
or
across
my
application
of
micro
services.
A
So,
what's
missing
from
this
and
I
would
argue,
there's
a
lot
of
different
sort
of
implementations
of
CI
CD
out
there
in
general.
We
need.
We
need
a
few
things
to
make
this
better.
The
one
thing
that
we
need
is
advanced
routing.
We
need
something
that
can
route
traffic
to
particular
versions
of
particular
services
by
rule
and
help
us
be
able
to
understand,
what's
actually
happening
and
do
that
canary
testing
at
any
layer
of
my
microservices
application.
I
also
need
something
that
gives
me
observability,
so
I
do
need
to
know
what's
happening.
A
I
need
detailed
metrics
coming
out
of
this
I
need
to
understand
that
when
traffic
does
hit
that
canary
test
is
it
taking
longer,
is
it
worse
or
better
than
average?
How
is
how
is
my
application
performing
overall
and
how
is
that
particular
API
performing
and
maybe
even
down
to
source
and
destination?
What?
What
is
the
actual
impact
of
this
so
I
need
meaningful?
Detailed
kind
of
observability
and
I
may
also
need
chaos
testing.
So
like
this,
we
all
know
applications
things
go
wrong
in
general.
Everything
that
could
go
wrong
will
go
wrong.
A
So
as
an
example
when
I
won't
spend
as
much
time
talking
about
sort
of
dev
and
test.
Certainly
we're
gonna
have
some
kind
of
a
developer
development
environment
and
we're
gonna
do
unit
and
integration
testing.
We
need
to
make
sure
the
code
actually
works
so
make
sure
it
does
what
we
expect
it
to
do.
A
We
may
even
do
have
a
test
environment
where
we
throw
that
code
out
there
with
all
the
other
micro
services,
and
this
would
be
a
great
place
to
inject
that
sort
of
chaos,
testing
and,
in
fact,
there's
a
lot
of
different
ways
to
do.
Chaos,
testing
that
you'll
hear
about
from
from
different
technologies
here
at
this
conference,
but
that's
outside
of
production
in
the
in
the
production
model.
A
Let's
just
go
ahead
and
automatically
merge
it.
Let's
try
to
automate
this
as
much
as
possible.
However,
if
it's
below
that
you
know,
maybe
we
need
some
kind
of
human
workflow
to
actually
take
a
look
at
the
individual
statistics
and
decide
that
it's
okay
and
maybe,
if
it's
below
a
certain
amount,
we
don't
do
anything
at
all.
We
remove
it
and
then
we
go
ahead
and
update
production
accordingly,
if
it's
passing
those
kind
of
tests
so
generically,
we
might
want
some
kind
of
pipeline
like
this.
A
Well
to
me,
this
is
where
STO
comes
in.
So
SDO
is
a
service
mission
technology,
as
it
said,
it's
an
open
platform
to
connect,
manage
and
secure
micro
services
and
there's
a
lot
of
different
service
mesh
technologies
out
there.
I
didn't
pick
this
one,
because
I
thought
it
was
the
best
frankly
I'd
like
to
learn
about
new
technology.
So
that's
one
that
I
picked
just
because
it
was
new
and
interesting
and
certainly
being
well
adopted
in
the
kubernetes
kind
of
community.
A
What
this
helps
me
do
is
it
does
help
me
with
the
things
like
service
discovery
and
routing.
It
provides
this
sidecar
model
to
be
able
to
control
where
traffic
is
going.
I
get
some
of
these
other
interesting
things
like
health
checking
and
policy
enforcement
helps
me
with
security.
It
helps
me
with
a
lot
of
different
things,
and
how
do
we
do
that
from
an
architecture
standpoint,
each
of
my
services
and
this
in
this
picture
right
out
of
the
sto
docks
I,
have
service
a
and
service
B
service.
A
A
in
its
pod
has
the
Envoy
proxy
as
a
sidecar.
All
the
traffic
from
service,
a
going
anywhere
else
outside
of
that
pod
has
to
go
through
that
proxy
various
route
rules
will
be
applied,
any
kind
of
other
other
kind
of
delays
that
I
want
to
inject
any
kind
of
telemetry
that
I
want
to
gather,
will
all
be
handled
by
that
sidecar
and
that
sidecar
is
actually
the
Envoy
proxy
that
came
out
of
the
lyft
organization
and
is
one
of
the
CN
CF
projects
here.
So
this
is
super
handy.
A
This
means
that
at
the
control
plane
layer
there
are
sto
components
that
allow
me
to
manage
how
those
proxies
behave
and
in
the
kubernetes
case
we
can
actually
do
this
with
custom
resources,
so
we
can
create
an
actual
resource,
call
it
our
route
rule
and
tell
our
side
cars
how
to
behave
and
what
to
do
so
when
I
think
about
some
of
the
things
that
I
wanted
earlier
and
I
want
to
gather
statistics
and
I
want
to
control,
routing
and
so
forth.
Sdo
is
a
great,
a
great
model
for
me
to
do
this
now.
A
How
does
that
envoy
proxy
get
into
that
pod?
Well,
there's
a
few
different
ways
that
you
can
do
that
Waianae
can
manually
inject
it
using
a
command
line
tool
from
from
the
SDO
platform.
I
can
also
automatically
inject
it
by
name
space,
so
I
can
say:
I
can
use
it
take
advantage
of
initializers,
which
is
part
of
a
part
of
the
latest
releases
of
kubernetes,
and
allow
that
that
gets
automatically
injected
in
pods.
A
So
I
don't
actually
have
to
change
our
deployment
process
to
make
sure
that
that
sidecar
is
there
for
me
and
there's
other
ways
to
actually
make
sure
that
that's
there
across
cluster
or
by
namespace
or,
however,
you
might
want
to
do
it,
but
so
what
can
I
do
with
this?
Do
just
to
kind
of
summarize
around
that
well,
I
needed
advanced
routing
I
can
do
I
can
do
that
with
route
rules
and
traffic
shaping
and
I
can
I
can
apply.
A
Whatever
advanced
routing,
I
need
to
do
this
kind
of
micro
service
level,
canary
testing,
very
simple.
To
get
that
observability
I'm,
going
right
out
of
the
box
and
in
the
in
the
the
docks
you
can,
you
can
see
how
easy
it
is
to
write
all
these
interesting,
metrics
out
something
such
as
prometheus,
so
that
I
can
pull
up
a
dashboard
and
see
what's
actually
happening
with
the
traffic
and
see
how
long
this
new
version
is
taking
or
any
kind
of
metrics
around
it.
A
And,
of
course,
I
can
also
do
things
like
chaos,
testing,
so
I
can
inject
a
delay
or
even
a
complete
HTTP
fault
and
see
how
how
my
application
behaves.
Does
it
handle
that?
Does
it
do
do
we
have
the
proper
retry
logic
to
handle
that
scenario?
Now
this
isn't
everything
that
sto
does
you
can
do
mutual
authentication
and
in
an
automated
fashion,
I
can
implement
circuit
breakers.
I
can
do
all
kinds
of
other
things
with
this.
A
Do
these
are
the
things
that
I'm
focused
on
here
that
are
gonna
help
me
with
this
kind
of
see
ICD
process,
but
certainly
a
lot
more
that
you
can
do
with
this.
Do
so
what
about
a
C
ICD
tool?
Well,
the
one
thing
I
would
argue
in
this
case
is
you
shouldn't,
need
a
new
C
ICD
tool
to
do
this,
so
hopefully,
your
C
ICD
tool
can
really
automate
some
of
these
same
processes
that
I'm
going
to
show
you
here,
and
that
would
certainly
be
the
goal.
A
A
couple
months
ago,
at
the
OSS
summits,
that
was
in
Prague
and
basically
Brigade
is
an
event-driven
scripting
engine
that
runs
in
kubernetes
and
we're
gonna
take
a
look
at
it
and
get
it
and
get
a
good
look
at
how
it
works.
But
essentially
what
it
allows
me
to
do
is
the
various
steps
of
my
workflow
can
be
encapsulated
as
functions
inside
of
containers
in
mike-mike,
kubernetes
cluster.
So
I
can
then
run
these
these
particular
jobs
that
make
up
my
CI
CD
process
by
taking
advantage
of
kubernetes
and
my
cluster
and
containers.
A
A
The
other
nice
thing
is.
We
talked
about
secrets
that
might
be
needed
by
my
pipeline
like
how
to
connect
to
my
container
registry,
how
to
talk
a
secret
on
how
to
talk
to
github
or
anything
such
as
that.
Brigade
actually
helps
me
with
that
as
well.
It
creates
the
concept
of
a
project
and
injects
all
of
those
meaningful
configuration
items
as
secrets
in
the
cluster
and
easily
takes
care
of
pulling
those
out
for
me
and
using
them
in
my
pipeline,
and
so
it's
well-suited
for
CI
CD
pipelines.
It
isn't
only
a
CI
CD
tool.
A
So
if
you're
thinking
to
yourself
wow
I
could
use
this
for
something
different
than
that
great
I.
Think
that
would
be
a
great
use
of
brigade,
so
brigades
in
its
early
stages,
I,
want
to
say
we're
in
like
a
point
for
a
version.
Release
like
I
could
be
forgetting,
but
I
think
we're
seeing
a
lot
of
interest
already
and
how?
What
could
I
use
this
for
and
certainly
see,
ICD
pipelines
is
an
easy
place
to
start.
We
also
had
another
another
open
source
project
that
was
announced
by
the
same
team.
A
That
was
actually
announced
only
a
couple
hours
ago.
That's
called
cosh,
T
and
cos.
T
is
a
is
a
web
dashboard.
That's
really
made
to
sit
in
front
of
Brigade
and
show
me
what's
actually
happening
in
the
C
sed
pipeline,
and
really
this
is
a
beautiful
web-based
UI.
That
shows
me
a
bunch
of
information
that
would
have
otherwise
been
distributed.
All
kind
of
throughout
my
kubernetes
cluster
I
had
a
particular
pod
that
ran.
It
did
a
job
for
me,
I
needed
to
find
the
logs
I
need
to
find
what
triggered
it.
A
How
do
they
all
fit
together?
Gosh?
He
pulls
that
all
together.
For
me,
what
event
triggered
this?
How
long
did
it
run?
What
are
the
different
steps?
It
shows
me
in
kind
of
a
waterfall
diagram
and
we'll
get
a
good
look
at
it
here
in
a
moment
in
the
demo
now,
but
it
gives
me
a
chance
to
actually
see
the
the
results
of
my
CI
CD
pipeline,
as
well
as
the
configuration
and
all
the
details
around
it.
So
cosh
T
was
just
announced
as
I
said
earlier
today.
A
These
are
I,
encourage
you
to
go,
take
a
look
at
these
and
try
them
out
and
give
us
sort
of
feedback
on
them
to
that
to
the
team
so
time
for
a
demo.
I,
don't
know
timing
wise,
where
I'm
at
I
think
I'm
right
on
schedule.
So
my
demo
is
called
micro
smack
I'm
not
going
to
explain
the
backstory
to
micro
smack
if
you
catch
me
after
I'll,
explain
where
that
comes
from,
but
the
the
actual
application
itself
I
like
to
do
live.
Demos
I
will
tell
you.
A
The
application
itself
is
unimportant:
we're
trying
to
see
what
automation
actually
happens
here.
So
I
have
a
really
rudimentary
bad
web
UI
I'm,
not
a
I'm,
not
a
UI
guy.
So
the
important
thing
is
you
actually
see
the
front
end
and
you
see
it
call
the
API
and
we're
gonna
affect
that
behavior
using
SDO
and
we're
gonna
drive
all
of
that
with
Brigade.
Now
before
I
jump
over
the
demo
and
I'll
walk
you
through
what
the
what
the
demo
will
actually
look
like.
So
what
we
have
is
we
have
a
web
UI.
A
We
have
just
a
simple
go
application,
that's
displaying
that
it
makes
25
calls
back
to
the
api's
that
are
running
in
a
separate
in
separate
pots.
These
api
is
return
a
color
and
they
return
some
build
details,
but
that
color
actually
drives
how
the
HTML
table
is
painted
and
we
call
it
25
times
not
because
that's
efficient,
because
it
obviously
isn't.
We
want
to
generate
some
traffic
and
we
want
to
see
if
we
are
getting
some
kind
of
canary
deployment
in
this.
A
We're
gonna
get
details
of
the
build
over
in
our
slack
Channel
and
we
have
Brigade
in
our
code
and
github.
So
when
we
make
an
update
to
the
code
and
github
will
see,
a
web
hook
occur,
webhook
will
talk
to
brigade
brigade.
Will
fire
up
the
steps
of
my
pipeline
and
that
actually
is
going
to
spin
up
pods
in
my
kubernetes
cluster?
That's
going
to
do
the
various
steps
of
this
of
this
workflow,
so
we're
gonna
go
and
create
a
go.
A
So
I
do
all
of
that
with
helm
as
well,
and
we
have
one
to
update
slack
so
when
we
actually
kickoff
that
that
PR,
it's
actually
going
to
do
a
deployment
of
that
PR
put
it
alongside
the
existing
one
and
route
some
of
the
traffic
over
to
it.
Now
you
might
be
saying:
ok,
90%
of
the
traffic
that
that
doesn't
sound
like
a
canary
build.
It
actually
sounds
like
the
reverse
of
a
canary,
build
and
yeah.
You
have
to
kind
of
use
your
imagination,
we're
up
here
doing
a
demo
on
stage.
A
We
want
to
see
some
kind
of
interesting
activity,
that's
kind
of
like
watching
an
action
movie
and
wondering
how
Bruce
Willis
doesn't
get
shot
running
through
a
you
know,
a
bunch
of
machine
guns,
so
we're
showing
90%
just
so
we
can
see
a
little
bit
more
activity,
but
it
really
would
be
10%
if
we
were
doing
a
canary,
build
or
obviously
some
small
amount
of
percent
we'll
be
able
to
see
what's
actually
happening
in
our
define
a
dashboard.
That's
talking
to
Prometheus.
A
If
we
like
what
we
see,
we
will
merge
that
PR
and
it'll
kick
off
another
workflow
and
it's
actually
a
slightly
different
workflow,
but
it
is
the
same
Brigade
pipeline.
That's
actually
running,
but
it's
it's
responding
to
a
different
event
and
in
this
case
it's
actually
taking
away
that
that
that
other
version
routing
all
the
traffic
and
updating
the
production
release
with
the
new
one.
Alright
and
again,
we'll
see
everything
in
the
dashboard
and
so
forth.
A
So
this
is
the
application
again,
you
can
hold
your
applause
for
my
UI
design
skills.
The
important
thing
to
note
is
it:
this
table
is
painted.
It
is
25
separate
calls
to
the
API
on
the
backend
and
that
color
that
that
we're
seeing
there,
which
is
officially
steel
blue,
comes
from
the
API
on
the
backend.
A
It
may
have
hit
one
of
the
different
pods
that's
running,
but
it's
not
important,
which
one
that
it
hit
they're
all
the
same
version
and
we
do
get
some
detail
back
on
the
build
ID
and
some
stuff
around
how
it
was
actually
built
through
our
CI
CD
system.
So
that's
what
that's!
What
the
home
page
looks
like
in
the
background.
I
am
actually
curling
that
page
here,
I'm
looping
through
it
just
seeing
so
we're
creating
some
traffic.
A
So
if
we
take
a
look
over
in
core
fauna,
we
can
actually
see
my
dashboard
of
the
activity
here.
So
this
is
again
Griffin
of
front-ends
Prometheus.
The
data
got
into
Prometheus
because
we
had
sto
as
a
sidecar
and
I'll
show
you
where
that
sidecar
is
running
on
the
top.
Here
we
have
the
activity
around
the
API
and
on
the
bottom,
you
have
the
activity
on
the
on
the
web
application,
and
you
can
see
that
we're
seeing
this
red
line
here,
which
is
essentially
all
of
the
traffic,
is
going
to
the
production
release.
A
A
But
just
so
you
can
see
the
pods
that
are
a
part
of
my
micro,
SMAC,
namespace
they're
running
in
a
separate
namespace
here,
so
that
we
can
automatically
inject
the
sto
or
the
Envoy
sidecar,
and
you
can
see
for
each
of
those
pods.
We
do
have
two
containers
running
in
them,
so
one
of
them
is
the
application
itself
and
the
other
one
is
that
SDO
sidecar.
That's
taking
care
of
the
the
routing
that
we
need
for
this.
A
Alright.
So
from
a
standpoint
of
Brigade
I
mentioned
that
we
had
various
Brigade
projects,
so
a
project
ends
up
being
described
as
a
helm
chard
in
and
of
itself,
so
we
installed
Brigade
using
helm,
and
then
we
install
a
series
of
Brigade
projects
for
for
each
really
each
application
that
we
want
Brigade
to
do
a
pipeline
for
us
and
really
that
project
ends
up
being
a
series
of
secrets
or
configuration
details.
A
So
what
we
want
to
do
is
actually
go
and
make
a
change.
So
I'm
gonna
go
into
the
dev
branch
and
make
sure
I
have
the
latest
I'm
gonna
open
up
vs
code
and
we'll
take
a
look
at
some
interesting
parts
of
this
application,
but
just
from
a
standpoint
of
the
color
here,
we're
actually
gonna
change
the
color
from
that
steel,
blue
to
red,
I'm,
gonna,
get
this
kicked
off
and
then
we'll
take
a
look
at
actually.
What's
happening.
A
Then
I'll
explain
what's
actually
happening
here
so
because
I
kicked
off
that
PR
down
on
the
bottom.
Here
you
can
see
some
activity
actually
happening
in
the
cluster.
Based
on
that
github
update,
we
kicked
off
a
web
hook
that
actually
called
in
to
Brigade,
and
has
you
have
this
worker
that's
running?
A
You
could
see
some
other
pods
start
up
that
are
cut
that
are
prefixed
with
job
Runner
and
so
those
those
are
the
the
pods
that
are
actually
running
my
pipeline
and
why
I'll
show
you
how
those
are
defined,
but
just
real,
quick
when
I
look
at
the
logs
on
this
particular
Brigade
worker,
you
could
see
some
things
that
are
happening.
It's
created
a
doctor
pod
for
me.
A
It's
now
running
that
particular
doctor
pod
and
I
could
go
in
and
look
at
the
logs
and
see
this
sort
of
process
that's
running,
but
if
we
actually
go
back
over
into
our
code
here,
let
me
show
you
what
that
Brigade
javascript
looks
like
so
you
can
see.
I
have
have
some
events
that
I
handle
so
I
have
various
event.
Handlers
in
this
case
there's
a
push
event
handler
and
there's
a
pull
request,
one
so
we're
actually
running
this
request
run
right
now.
I've
set
up
some
basic
configurable
x'
here.
A
This
is
where
I've
actually
pulled
in
my
my
asher
container
registry
credentials
into
my
my
code
very
easy
to
pull
those
out
of
just
the
project
object
here
and
in
brigades
so
that
I
don't
have
to
manage
or
think
about
getting
those
out
of
some
kubernetes
secret
and
so
forth,
and
then
I
set
up
my
Brigade
jobs.
So
I
define
these
these
for
containers
by
creating
Brigade
jobs
and
I'm,
actually
using
some
JavaScript
functions
here
to
configure
how
those
jobs
act
that
way.
I
can
use
these
over
and
over
again.
A
A
Let's
see
what
the
application
looks
like
now
that
it's
red
now
you
may
notice
when
I
refreshed
it,
it
took
it
a
few
seconds
there
to
build
notice
that
we're
now
seeing
the
PR,
and
we
actually
should
see
more
of
that
90%
of
the
traffic
appear
here.
If
I
keep
refreshing
it,
I
should
actually
still
see
some
of
the
traffic
going
to
that
other
version,
and
so
we've
actually
have
deployed
this
sort
of
canary
build,
but
it
doesn't
seem
like
it's
actually
working
very
well.
A
In
fact,
if
we
go
over
to
graph
on
o,
we
can
see
what's
actually
happening,
so
the
API
chart
on
the
left
up
there
at
the
top
left.
We
can
see
that
the
traffic
shaping
occurred.
So
again,
we
used
helm
to
actually
make
sure
that
those
sto
rules
were
changed.
We
do
see
that
some
of
the
traffic
is
now
hitting
this
new
release,
which
is
the
yellow
line
in
the
graph.
But
man,
the
the
performance
of
this,
has
gone
to
hell.
A
really
slow
massive
amount
of
increase
in
what's
actually
happening.
A
So
maybe
red
wasn't
the
right,
color
choice,
and
maybe
we
need
to
actually
make
a
change.
Now
again.
We
we
may
have
some
sort
of
automated
process
to
this
again.
We're
doing
this
in
a
demo
fashion
to
actually
see
everything,
but
we
know
that
we
do
have
a
problem
here.
So
we're
going
to
go
back
over
to
our
code
and
our
API
handler
here,
I'm
gonna
change
to
my
favorite
HTML
color,
you
I
guy
on
our
team.
That
again
was
at
Deus.
Matt
butcher
told
me
about
a
real
HTML
color
called
Chuck
Norris.
A
A
Now
again
over
in
our
cluster,
we're
gonna
see
Brigade
kick-off.
Again,
we
could
see
the
workers
have
kicked
off
and
they're
gonna
update
our
PR
with
this
and
we're
gonna
see
if
that
does
any
better
now
in
the
meantime,
but
by
doing
that,
update
I
want
to
show
you
what
Kosti
looks
like
so
I
mentioned
at
the
beginning.
A
You
saw
in
this
cluster
all
the
things
that
we're
doing
with
containers
and
all
the
detail
that
we're
seeing
by
a
command
line,
but
that's
all
that
would
be
a
hard
way
to
troubleshoot,
builds
and
see
what's
actually
happening,
and
that's
really
where
cosh
T
comes
in
cosh
T
is
this
web
UI
here?
That
shows
me
all
of
my
Brigade
projects.
A
He
saw
I
had
three
projects
earlier,
so
that
corresponds
exactly
to
what
I
see
here
and
you
can
see
that
the
cube
con
1
is
the
only
one
that
actually
has
activity
in
it,
and
you
can
see
the
various
events
that
have
occurred.
They
have
all
have
separate,
build
IDs.
You
can
see,
you
know
how
long
they
ran
when
they
ran.
You
can
even
see
a
fun
bug
there
for
the
one.
A
That's
currently
running
that
one
started
2000
17
years
ago
funny
the
the
cause
of
that
is
the
the
different
way
that
different
languages
handles
sort
of
date.
Zero,
if
you
want
to,
if
you
want
to
understand
the
background
to
that
again,
just
release
today
fun
to
have
the
bug
and
see
it
actually
in
action.
So
if
we
want
to
see
the
actual
history
of
a
build
that
happened
earlier,
we
have
this
build
history.
You
can
see
when
it
started.
We
can
see
when
it
finished.
In
this
case
it
passed.
A
You
can
see
that
it
came
from
a
pull
request.
You
can
see,
there's
a
commit
ID
to
it.
If
I
want
to
see
individual
results,
you
can
see
how
easy
it
is
to
see
these
various
steps.
These
are
the
same
same
jobs
that
are
defined
in
that
brigade,
JavaScript
that
we
looked
at
earlier
and,
for
example,
in
the
helm
in
the
helm,
job
runner.
You
can
see
the
actual
logs
all
encapsulated
right
here
in
this
screen
very
easy
for
me
to
see.
A
What's
actually
happen
in
that
Brigade
process
on
the
back
end,
and
you
can
see
when
I
go
back
to
my
main
screen
here,
that
that
Chuck
Norris
pull
request
is
actually
done.
That's
the
one
that
finished
a
few
seconds
ago,
so
we
can
actually
jump
back
over
and
see,
see
how
that
went
and
when
I
click
refresh
here
it
certainly
refreshed
faster.
So
it's
more
than
likely
working
correctly,
but
we
still
are
in
this
sort
of
canary
build.
If
you
will
so
we're
gonna
go
back
over
to
our
dashboard
and
take
a
look.
A
You
can
see
we're
still
in
that
we're
still
seeing
the
traffic
going
going
to
two
different
releases
of
the
API,
but
we
certainly
are
seeing
performance
back
to
normal,
so
Chuck
Norris
did,
in
this
case
save
the
day
and
certainly
a
much
better
scenario
for
our
application.
So
it's
at
this
point
when
we
should
go
ahead
and
merge
this
pull
request,
and
so
we
will
and
say
Chuck
Norris
saved
the
day.
A
A
To
that
to
that
that
really
that's
staging
or
Deb
slot,
that
was
for
the
canary
build,
and
if
you
see
my
my
pipeline,
you
can
see
it
looks
very
similar
to
the
last
one
except
we
actually
are
only
executing
the
code
if
it's
on
the
master
branch-
and
you
may
have
noticed-
actually
this
thing
kicked
off.
If
you
were
really
paying
attention
when
I
push
something
to
the
dev
branch,
this
thing
did
run.
It
just
didn't,
do
anything
and
you
might
have
caught
that
that
happened.
A
A
You
can
see
that
the
various
components
are
in
the
sto
namespace.
We
do
have
have
the
sto
control
plane,
the
mixer,
the
pilot.
There
is
also
the
initializer,
that's
the
one
that
I've
added.
That
knows
how
to
automatically
inject
this
I
configured
it
and
told
it
only
inject
into
the
micro
space
or
the
micro
smack
namespace.
So
all
of
these
brigade
pods
are
starting
up
they're,
not
actually
using
this.
Do
they
don't
need
sto
for
what
their
work
is
done
here.
A
We
do
also
have
the
Griffin
out
prometheus
components
as
well
running
in
this
namespace
they're
not
required,
but
they're
certainly
useful.
In
this
case.
The
other
thing
that
you
should
see
is
the
route
rule.
So
let
me
just
make
sure
I
get
my
route
rule
name
right,
so
I
have
a
route
rule
that
was
driving
some
of
this
traffic
and
we've
been
modifying
it
using
helm.
A
And
you
can
see
again,
this
is
a
standard.
Kubernetes
object,
it's
a
custom
resource,
that's
been
added
to
my
cluster
and
you
can
see.
We
know
that
it's
already
done,
because
we've
removed
that
sort
of
canary
deployment
and
merged
that
build
into
master.
So
we
actually
see
now
that
a
hundred
hundred
percent
of
the
traffic's
already
hitting
this
updated
release,
so
odds
are.
When
we
go
back
and
check
our
application,
we
should
actually
see
this
no
longer
being
the
PR.
A
We
should
see
it
be
that
master
build,
and
if
we
go
back
over
to
our
graph
on
a
dashboard,
we
can
see
now
that
over
on
the
top
left
there,
the
API
is
now
shifted
all
the
traffic
back
over
to
that
sort
of
master
primary
release.
We
did
that
at
that
micro
service
level,
all
right
so
from
a
demo
standpoint.
That's
what
I
wanted
you
to
see.
Now
again,
we
just
have
one
API.
In
this
case
you
could
expand
that
to
many
of
different
api's
and
be
able
to
control
them
in
this
fashion.
A
We
take
advantage
of
Sto
to
do
all
the
route
and
route
rules
and
traffic
shaping,
and
we
have
brigade
to
help
us
actually
do
our
C
ICD
process
and
again
cosh
T.
Is
this
beautiful
sort
of
UI?
That
gets
me
a
good
look
at
what
actually
happened
and
I
can
go
back
and
see
the
history
of
these
results
and
see
what's
actually
happening
with
it
all
right.
A
So
before
I
before
I,
wrap
up
I
do
to
say
that
just
before
I
came
up
here,
I
did
publish
a
blog
so
that
you
can
go
try
this
out
yourself
perhaps
expand
upon
it.
Do
something
more
with
it,
maybe
make
a
better
UI
or
a
better
front
end
to
the
to
the
application,
but
it
is
out
on
on
my
blog,
which
is
on
medium
I'll,
probably
tweet
about
it
later,
but
I
did
I
did
post
that
live.
A
I,
haven't
really
tried
it
enough
times
to
know
that
it
absolutely
works
that
from
the
instructions
I
know,
I
can
get
it
to
work,
but
did
I
build
the
right
instructions
for
you
to
get
it
to
work,
but
please
try
it
out
and
let
me
know
what
you
think
about
it
and
certainly
like
I
said
I'll
say
more
about
it
on
Twitter
and
so
forth
later.
But
with
that
I
have
time
for
questions
I,
don't
remember
how
long
I
had
I
have
one
one
minute.
So
if
you
have
a
question,
please
go
to
the
mic.
A
If
I
wanted
to
run
like
if
I
wanted
to
run
a
particular
test
against
it,
I
could
run
that
in
in
another
job
in
my
pipeline,
so
I
I
had
complete
control
over
defining
those
different
jobs.
That
might
be
a
great
place
for
me
to
do
that.
I
mentioned
earlier.
That
I
probably
want
something
to
do
almost
like
a
score
related
to
that.
I
might
want
a
job,
but
actually
gathers,
maybe
the
last
hour
of
data
from
Prometheus
and
does
like
an
index
around
that
and
and
make
some
decisions
around.