►
From YouTube: GitHub Satellite India 2021 - Resilience testing with GitHub Actions using LitmusChaos
Description
Presented by Uma Mukkara, Maintainer @ LitmusChaos / CEO @ ChaosNative
Since Kubernetes has achieved mainstream adoption, achieving safe upgrades and resilience in production has become a challenge when the delivery of changes are happening at a much faster pace than before. Fortunately, new Chaos Engineering tools have emerged to meet the needs of resilience engineering of Kubernetes. In this session, Uma will talk about the importance of building application resilience testing into CI pipeline stages using GitHub Actions. Uma will do a couple of LitmusChaos experiments and demonstrate the functioning and usage of the Actions. Then, he'll touch upon best practices for running GitHub Actions on Azure and on native Kubernetes. There will also be a 5- to 10-minute Q&A after the demo.
As always, feel free to leave us a comment below and don't forget to subscribe: http://bit.ly/subgithub
Thanks!
Connect with us.
Facebook: http://fb.com/github
Twitter: http://twitter.com/github
LinkedIn: http://linkedin.com/company/github
About GitHub
GitHub is the best place to share code with friends, co-workers, classmates, and complete strangers. Millions of people use GitHub to build amazing things together. For more info, go to http://github.com
A
A
Of
course,
you
can
do
it
in
many
other
ways,
but
today
we're
going
to
talk
about
github
actions
and
in
that
process
we'll
touch
a
little
bit
about
what
is
chaos
engineering?
What
is
cloud
native
chaos,
engineering?
What
is
litmus
and
I'll
probably
show
how
we've
been
using
a
github
actions
for
our
own
project,
which
is
litmus
and
how
you
can
use
litmus
and
github
actions
together
to
do
some
kiosk
engineering
and
improve
the
resilience
of
your
own
application
or
platform.
A
So
let's
talk
a
little
bit
about
cloud
native
developers
right
so
we're
all
now
already
in
the
cloud
native
space
and
it's
all
about
micro
services
right.
So
what
why?
The
developer
mindset
has
to
be
a
little
bit
different
about
the
cloud
native
ecosystem,
the
development
of
application
in
such
a
system
right,
the
first
primary
difference
is
as
a
developer.
You
are
expected
to
ship
things
faster
right
and
that's
the
whole
hype
about
microservices.
A
The
reason
why
kubernetes
and
containers
are
so
famous
now
right
and
they
are
also
coming
much
faster
to
you.
Your
development
environment
is
also
changing
right
and
the
pipelines
are
large,
complex
and
they're
expected
to
do
a
lot
more
job
than
what
they
used
to
do
earlier.
Right
and
as
developers.
Your
ecosystem
is
changing
a
lot
underneath
in
which
you're
developing,
which
you're
testing,
and
that
is
expected
to
be
very
sturdy.
Otherwise,
you
are
you're,
really
slowing
down
your
ecosystem,
all
right.
A
So
I
want
to
be
able
to
depend
on
my
tasks
and
I
want
to
be
able
to
depend
on
the
underlying
stack
as
well
right.
So
what
is
chaos?
Engineering
for
developers
right
so
just
to
summarize,
you've
been
developing
your
application
with
your
cdi
pipelines
and
you
used
to
test
them,
but
now
you
also
have
a
continuous
verification
of
your
underlying
infrastructure,
as
well
as
your
underlying
micro
services
that
you
run
your
pipeline
on.
So
that's
really.
Chaos
engineering
for
developers
really
mean
it's
adding
chaos
engineering
to
your
safe
pipelines
right.
So
what
is
chaos?
A
Engineering?
We
all
know
that
it's
all
about
reducing
down
times,
because
they're
very
expensive.
You
move
your
testing
on
to
the
right
side
of
your
devops
loop.
Don't
wait
test!
Keep
testing
right
and
usually
it's
been
an
after
thought
process.
You
burn
something.
You
know
an
expensive
outcome
will
come
and
as
a
result,
you
are
expected
to,
you
know,
fix
it
and
the
rca
is
the
practice.
Chaos
engineering
right.
So
it's
been
a
mostly
traditional
one.
A
Not
many
tools
have
been
there
in
a
way
that
you
can
automate
them
at
high
scale
and
generally
it's
a
reactive
stuff.
You've
not
been
seeing
chaos
engineering
as
part
of
ci
cd
so
far
that
aggressively,
except
that
you
know
last
a
year
or
so
with
so
much
of
stuff
happening
around
cacd,
faster
stuff
happening
in
in
in
the
left,
shift
mode
of
operations,
you're
seeing
chaos
engineering
as
a
way
to
do
it,
and
this
is
really
propelled
by
the
adoption
of
kubernetes.
A
As
you
see,
kubernetes
is
moving
mainstream
and
you
are
seeing
more
dynamism
and
the
chaos
engineering
has
begun
to
catch
up.
You
know
the
people's
mindset
and
we
believe
that
you
know
it's
already
on
the
path
to
mainstream
adoption,
as
you
would
have
seen
many
people
talking
about
how
chaos
engineering
is
going
to
play
our
main
role
in
this
year
and
probably
next
year
and
years
to
come
in
that,
so
there
is
going
to
be
more
of
more
chaos,
engineering
in
cloud
native
space
and
that's
why
cloud
native
chaos?
Engineering
is
a
topic.
A
You
know
we
define
certain
principles
right,
so
it's
got
to
be
open
source.
You
need
to
have
this
chaos,
experiments
pretty
well
organized
well
tested.
It
has
to
have
operators
with
open
api
and
lifecycle
management.
It
has
to
scale
well
and
probably
get
ops.
Is
the
right
answer
to
manage
chaos,
engineering
and
then,
when
you
introduce
certain
issues
or
bugs
you
find
them
using
fault
injection,
you
need
to
debug
them.
So
observability
is
a
very
key
factor.
A
So
when
you
do
chaos
engineering
in
this
way,
you
can
call
that
as
cloud
native
chaos
engineering.
These
are
the
principles
that
we
defined
couple
of
years
ago
before
we
started
the
journey
of
chaos
engineering
in
late
months.
The
project
which
is
now
a
cncf
project
is
really
based
on
these
principles
right,
so
it
is
open
source
and
it
is
having
a
chaos
hub
and
a
lot
of
operator.
A
Work
has
gone
in,
and
githubs
and
open
observability
are
just
around
the
corner,
with
the
titans
all
right
as
a
project,
it's
pretty
famous,
I
would
say
we
have
about
close
to
50
000
installations,
all
over
the
place
that
we
know
of
there
may
be
more.
What
I'm
really
excited
about
is
this
project.
Apart
from
the
maintenance
kiosk
native,
there
are
other
people
who
are
contributing
very
very
actively,
including
some
of
the
larger
companies.
Recently,
red
hat
also
became
one
of
the
main
adapters,
and
the
contributions
have
been
very,
very
helpful
right.
A
So
where
do
we
use
litmus
right?
Obviously,
you
know.
I
just
talked
about
the
ci
pipelines
use
case,
we'll
talk
more
about
it
in
shortly,
and
the
other
two
areas
are
as
an
extension
of
ci
chaos.
Engineering
is
used
as
a
trigger
to
do
cd
and
then
post
cd
as
well
right.
So
I
just
deployed
it
is
my
application
working
as
behaving
behaving
as
expected,
and,
of
course
chaos.
Engineering
has
been
having
the
use
case
of
randomized
testing
in
production,
not
reproduction
right.
So
overall
litmus
is
a
cross-cloud
multi-tenant
platform.
A
You
will
be
able
to
see
these
three
use
cases
used
properly
so
a
little
bit
about
what
is
litmus.
As
a
brief,
you
know
it's
a
helm
chart
with
a
lot
of
experiments
already
available
and
you
can
take
them
as
is
or
you
can
pull
them
into
your
private
git
repository
and
then
create
your
own
private
chaos
hub
and
collaborate
with
your
own
team
members
right.
So
that's
private
key
also.
So
when
you
install
a
litmus
through
a
helm,
chart
you
get
a
nice
portal.
A
That's
where
your
centralized
cross
cloud
are
multi-cloud
control,
plane
for
your
chaos,
engineering
and
then,
once
you
set
that
up,
you
can
run
kiosk,
workflows
anywhere
any
kubernetes
or
non-kubernetes.
You
can
run
them
on
cloud
platforms,
vms,
bare
metals,
and
you
can
store
all
this
configuration
and
and
get
centralized
so
that
you
can
automate
them.
You
can
put
some
you
know
or
back
rules
around
it
manage
the
versioning
of
them,
and
this
works
very
well
with
any
other
git
ops
platforms
such
as
argo,
cd
or
plug
cd.
A
You
know
all
versions
are
supported,
so
workflow
is
is
really
the
next
step
in
chaos.
Engineering,
where
you
can
create
scenarios
on
the
flow,
a
set
of
experiments,
pull
together
either
in
sequence
or
in
parallel,
consolidate
the
result
and
then
push
the
metrics
back
to
a
centralized
monitoring
place.
So
we've
integrated
this
with
the
argo
workflows.
A
It
works
very
well
right
now,
litmus
has
got
a
lot
of
experiments,
that's
already
there
and
a
lot
more
are
coming
as
it
is
open
source
community
continuously.
You
know
and
adds
this
list
right
and
then
it
works
on
non-kubernetes
targets
also,
for
example,
all
platforms
or
vmware
openstack,
all
such
stuff.
So
coming
back
to
how
you
can
use
the
main
use
case
that
we
are
talking
about
today,
how
can
you
use
chaos
in
ci
pipelines
and.
B
A
More,
interestingly,
how
you
can
use
it
in
github
actions
right,
so
what
we
have
done
is
we
have
developed
a
ci
library
on
top
of
litmus
which
you
can
actually
use
as
a
chaos
stage.
All
you
just
need
to
do
is
you
know
you
implement
a
chaos,
action
that
calls
this
library
function
and
then
the
entire
litmus
experiment
just
gets
executed
automatically.
A
So
it's
as
simple
as
just
calling
this
api
and
then
you're,
you're
good,
so
very
the
same
infrastructure
can
be
used
or
is
being
used
with
other
pipelines
too
spinnaker
or
captain
or
gitlab.
So
let's
go
ahead
and
actually
show
chaos,
actions
in
in
reality
right
so
how
we've
been
using.
So
when
chaos,
when
github
actions
was
introduced,
we
ourselves
litmus
project,
moved
our
ci
from
something
else
to
github
actions.
So
we
are
using
it
of
actions
and
we're
using
chaos
to
test
our
own
chaos.
A
Engineering
code
I'll
show
how
we
have
been
using
it,
but
primarily
with.
If
you
want
to
introduce
github
actions,
you
just
introduce
a
new
workflow
or
a
stage
right,
and
you
call
that
as
chaos
stage
and
then
you
keep
calling
chaos,
experiments
or
chaos
actions
within
it
right.
It
generally
includes
you
call
certain
functions
that
installs
litmus
and
at
the
end
of
the
chaos
stage
of
the
workflow
you
clean
up
bitmus
and
in
the
middle,
you
can
call
as
many
chaos
experiments
as
your
as
your
platform
or
application
deserve.
A
A
A
So
you'll
see
kubernetes
chaos
here
and
what
we
have
done
is.
We
have
actually
created
one
single
action
and
call
any
experiment
that
you
wish
to
execute
as
an
environment
variable.
So
it's
it's
pretty
easy.
You
don't
have
to
learn
a
lot
of
actions.
It's
just
one
action
right
now
we're
trying
to
implement
more,
probably
workflows,
so
you
can
just
use
this
one
single
action
and
then
it
really
includes
three
steps.
As
I
said
first,
you
include
a
script
to
deploy,
bitmas
and
then
later
to
clean
it
in
the
middle.
A
You
call
this
actions
and
then
call
what
is
the
experiment
or
where
the
target
is
the
application
through
all
environmental
variables
right,
and
these
are
the
environmental
variables
as
as
you
keep
tuning
it,
you
are
in
control
of
what
experiment
should
be
executed
against
which
target
right,
and
I
have
a
sample
project
that
I'm
going
to
show
right
now.
It's
a
simple
project
where
we're
going
to
have
a
chaos
action.
So
let
me
go
here
and
explain
how
this
workflow
is
written.
A
So
this
is
a
demo,
chaos
action
and
it
uses
chaos.
I
mean
the
github
actions.
All
we're
going
to
do
is
set
up
a
kubernetes
cluster
kind
cluster.
On
the
fly
and
install
nginx,
that's
one
stage,
so
then
I'm
going
to
introduce
the
chaos
stage
right.
So
it's
all
about
setup
litmus,
it's
as
simple
as
that
and
then
run
a
couple
of
experiments.
A
I'm
just
calling
this
actions,
chaos,
actions
with
this
environment
variables.
You
can
see
chaos,
experiment
is
modulate
and
the
same
action.
I
call
again
with
a
different
experiment
right
and
you're
all
set.
Then
of
course,
I'm
going
to
delete
litmus
uninstall
it
most
at
the
end
of
it.
So
you
go
and
see
this
in
action.
Let
me
just
go
run
it
just
for
the
sake
of
it
and
while
it
gets
launched
it
might
take
a
minute.
I
can
go
and
see.
Show
you
how
this
was
done
earlier
right.
A
So
it's
really
about
setting
up
litmus
and
running
a
couple
of
experiments
and
uninstalling
it
rest
of
it.
Is
your
own
action
pipeline
right.
So
if
you
go
and
see
this
modulate
experiment,
all
you
called
is
just
one
line,
but
we
do
the
heavy
lifting
underneath
and
the
developer
should
not
be
worried
about.
You
know
what
goes
on
underneath,
but
you
can
generally
go
and
see
you
know
what
goes
on
and
you
know
what
the
results.
A
Of
course
you
can
integrate
this
with
a
lot
of
monitoring
tools
which
I'm
not
talking
about
it.
But
what
it
really
is
is
a
simple
way
to
execute
chaos
into
your
pipelines
right-
and
this
is
our
repository
where
we've
been
using
github
actions
as
a
way
of
testing
our
own
merged
code
and
as
you
can
see
that
we
got
build
and
we
got
your
e2e
pipelines
and
that's
where
we
are
running
our
own
chaos
actions
right.
A
So
let's
go
and
see
one
run
pipeline,
so
you
will
see
some
a
lot
of
generic
tests.
This
generic
test-
or
you
know,
set
up
lateness
and
for
every
code,
much
that
we
do.
We
go
on
test
if
our
own
experiments
are
working
or
not.
So
if
you
are
looking
at
how
to
execute
a
particular
experiment,
you
can
go
to
our
own
pipelines
and
see
how
we
are
using
chaos,
actions
and
github,
kios
experiments
and
github
actions.
You
can
just
take
that
as
an
example
and
then
do
them.
A
A
It's
been
for
operations
traditionally,
but
that's
we
are
in
the
new
world
where
cloud
native
ecosystem
is
changing
the
way
we
do
id
right.
So
chaos
engineering,
in
my
opinion,
is
going
to
be
a
common
place
in
developer's
tool
set
right.
So
that's
what
we
are
set
out
to
do
and
we
are
at
the
beginning
of
that
cycle
right.
A
So,
first
of
all,
you
need
to
create
a
good
tool
set
an
open
source
tool
set,
that's
easy
to
use
and
it
makes
a
lot
of
sense
by
using
it
and
if
it
produces
results,
developers
will
take.
Take
it
and,
as
I
discussed
in
this
session,
we
expect
developers
to
start
looking
at
the
test,
not
only
negative
tests,
but
there
are
chaos
tests
outside
your
own
code
that
your
code
should
really
depend
on.
B
A
Right
the
scales
actions,
a
lot
of
them
are
there.
I
mean
chaos
experiments.
There
is
only
one
chaos
action
that
we
have
written
right
now,
using
which
you
can
introduce
whatever
the
chaos
experiment
that
you
want,
using
the
environmental
variable
right
and
usually
either
developers
or
whoever
is
trying
to
do
chaos
and
studying
in
the
beginning.
They
would
want
to
take
the
most
simple
chaos.
Experiments
right,
so
port
eviction
and
port
delayed
is
is
a
very
common
thing.
Right.
A
Kubernetes
can
kick
any
part
out
based
on
the
resource
constraints,
so
you
it's
safe
to
do
a
port
delay
right,
because
kubernetes
is
mainstream
right
now,
so
you
go
and
actually
use
such
chaos
experiments
to
learn
the
benefits
of
chaos
and
how
to
use
chaos,
and
you
generally
people
use
port
delay
to
cpu
hog
memory
hog,
because
you
know
these
are
less
intrusive
and
you
learn.
But
generally
what
we
also
see
is
people
go
all
the
way
to
the
extent
of
breaking
some
infrastructure.
A
For
example,
a
disk
fail
right
or
disk
delete
or
network
loss
network
delay.
All
this
kind
of
thing,
one
of
the
other
common
things
that
we
have
seen,
is
what
happens
if
my
kubernetes
itself
gets
stuck
right.
So
how
do
I
simulate
the
scenario
of
something
wrong
going
in
the
kubernetes
itself
and
you
take
a
cue
blade
out
right,
so
we
have
a
cubelet
kill
experiment.
A
C
A
I
know
large
deployments
and
all
so
as
part
of
that
we
created
chaos,
workflows
right,
which
are
nothing
but
a
set
of
experiments
you
can
put
together.
You
can
stitch
together
to
create
a
chaos
scenario
right,
usually
the
problems
happen,
not
because
a
small
fault
has
happened,
but
because
you
know
something,
you
know
a
dual
failure,
or
triple
failure
happened
in
an
unexpected
way.
You
wanted
to
simulate
all
this
stuff
and
that's
what
a
chaos
workflow
can
do
and
you
can
automate
that
also
so,
can
I
introduce
chaos
workflows
through
github
actions?
A
Right
of
course,
it's
going
to
be
a
little
bit
more
difficult
than
or
cumbersome
than
a
simple
chaos
action
of
an
experiment,
but
that's
what
we
are
trying
to
look
at
developing
bring
in
chaos
workflows
as
a
way
to
test
complex
scenarios
in
your
pipelines
using
github
actions.
So
we
might
write
one
more
chaos,
action
called
chaos,
workflow,
and
then
we
are
also
looking
forward
to
integrate
some
analytics.
You
know
if
github
is
providing
some
analytics
or
in
general.
A
B
A
I
know
a
lot
of
people
would
like
to
say
you
know
the
latest
feature.
I'm
pretty
excited,
of
course,
github
actions
we
like
them,
but
you
know
as
an
open
source
maintainer.
I
want
my
community
to
be
working
very
well
on
github
right,
so
the
age
old
feature
github
issues
right,
we've
been
using.
Everybody
uses
github
issues
as
a
way
to
ask
questions
as
a
way
to
go
and
find
answers
right.
You
ask
a
question,
you
answer
and
then
a
year
down
the
line,
somebody
faces
the
same
question.