►
From YouTube: Helm for Anybody – Combining ChatOps and Declarative Configurations Jonathan Striebel, Software En
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
Helm for Anybody – Combining ChatOps and Declarative Configurations Jonathan Striebel, Software Engineer, Scalable Minds GmbH
A
A
A
A
I
will
just
still
use
the
names
that
we
are
using
in
our
company
still
and
but
you
can
replace
all
the
tools
with
something
else,
of
course,
so
lot
chat.
Ups
chat.
Ups
basically
means
you
can
command
your
operations
from
the
chat.
So
we
have
two
use
cases
for
that
in
our
company.
The
first
is
to
upgrade
web
browsers
for
our
clients.
We
have
different
helm
releases
and
we
want
to
upgrade
them
usually
multiple
times
a
day
and
do
that
often-
and
everybody
wants
to
do
that
in
our
company.
A
A
So
we
had
a
look
into
cherubs.
So
imagine
you
have
a
chat
bot,
let's
call
it
Scotty
and
you
want
to
upgrade
web
gnosis.
Then
you
say:
hey
great
me
up
Scotty.
So
how
does
it
actually
look
like?
Okay,
we
have
a
company
Church
in
our
case
slack,
and
we
have
an
upgrade
command
and
we
say
upgrade
web
notice,
a
which
is
just
the
release
of
the
web
gnosis
charge,
and
we
want
to
upgrade
it
to
another
version.
A
So
then
Scotty
which
has
access
to
our
cluster.
It's
saying:
okay,
I'm,
going
to
upgrade
this
and
hey
after
some
time,
I'm
done
upgrading.
So
why
do
we
actually
want
to
do
that
and
don't
just
use
the
helm
seal
I?
Well,
the
first
thing
is:
anybody
can
can
now
go
into
our
chat
and
copy
that
command
and
just
put
in
a
new
version
if
I
do
that
privately
on
my
shell,
nobody
else
can
see
in
my
shell
history
and
have
a
look.
What
I
did
before
so
it's
easily
copy
copyable
in
the
whole
company.
A
Also
anybody
can
see
this
within
this
channel
that
we
are
using
and
can
ask
question.
For
example,
hey
did
we
include
this
cool
new
feature?
Well,
not
yet,
but
you
see,
we
gain
visibility
to
the
steps
that
we
are
doing
and
everybody
can
communicate
on
that.
We
are
all
in
this
chat
anyways
and
we
have
faster
interactions
than
usually
in
pull
requests
or
just
with
commits
or
anything.
A
So
let's
have
a
look.
Are
we
actually
using
this?
Well,
yes,
for
upgrading
our
releases
regularly
we're
doing.
We
did
that
in
the
last
year,
550
times
roughly
and
mentioning
our
def
releases
760
times,
and
we
had
a
bunch
of
like
15
people,
so
that's
quite
a
number
for
us
at
least,
and
that
helps
everybody
to
engage
more
with
our
infrastructure
tools
that
we
have
so
in
total.
A
A
Now,
let's
get
to
the
second
topic,
declarative
configuration
so
declarative
configuration
it's
been
in
other
talks
as
well.
It's
just
that
you
don't
state
imperatively
what
to
do,
but
you
state
what
you
want
to
have
you
define
a
specific
state
and
you
want
some
mechanism
that
applies
this
stage
through
your
system,
in
our
case
the
helm.
A
So
you
know
this
already.
I
mean
you've,
probably
written
kubernetes
resources
and
there
it's
quite
typical
to
use
queue,
control,
apply
and
just
have
some
declarative
gamal.
Instead
of
doing
cube
control
edit
all
the
time
and
managing
everything
in
place
and
probably
you've
written
some
hell,
charts
and
they're
your
templates,
our
declarative
as
well,
but
just
one
last
step-
is
missing
with
a
home
stack
that
is
currently
there
and
that's
how
releases.
A
A
So
for
the
first
step,
we
create
overwrite
yeah
mods,
where
we
have
the
values
that
we
have
normally
in
our
charts
and
just
the
values
that
we
overwrite,
usually
maybe
with
set,
which
just
put
it
in
a
file.
That's
it
so,
for
our
web
notice
a
release,
we
just
specify
the
tag
that
we
want
and
some
other
values.
A
At
the
moment
we
put
this
into
version
control
system.
We
gain
a
lot
of
benefits
and
at
that
moment
we
can
also
call
it
get-ups
and
if
we
use
gate,
of
course,
we
gain
reproducibility,
because
we
can
just
take
any
file
here
and
install
it
again
upgrade
to
this
exact
version
and
we
get
exactly
the
same
system
running
again.
A
So
we
want
this.
Basically
for
our
home
helm
releases,
there
are
multiple
solutions.
What
we'd
use
is
helm
file.
There
is
parallel.
Another
talk
about
the
flux,
I
think
this
works
as
well.
There
are
other
solutions
as
well
I'll
just
pick
Hound
file
here
and
what
it
looks
like
there
is
that
you
specify,
for
example,
a
helm
file
Yama,
and
you
specify
the
releases
you
want
to
with
a
name
with
a
namespace,
for
example
the
charge
and
your
values
file.
A
There
are
other
options
how
to
specify
this,
but
this
in
the
end
is
a
declarative
configuration
for
your
whole
stage
of
the
application.
You
can
have
it
for
one
release
or
multiple.
It
doesn't
measure
in
the
end
and
what
health
I
can
do
is
now
have
health
I'll
apply
and
upgrade
your
stage
in
helm
to
exactly
what
you
stated
here
so
helm
file
gives
you
the
mechanism
to
synchronize
your
declarative
configuration
with
helm.
A
So
to
wrap
this
up,
we
have
chat
ops,
and
this
gives
us
nicer
interactions.
It's
accessible
usable,
you
have
visibility
throughout
your
company
and
you
have
fast
interaction
rates
you
can
discuss
with
other
people
and
on
the
other
hand,
you
have
declarative
configurations
in
this
case
helm
file,
and
this
allows
you
to
F
reproducible
releases
to
have
the
typical
interactions.
You
know
from
your
code,
anyways
with
poor
requests,
with
reasoning
in
discussions
there
and
to
have
reversions
whatever
you
like.
A
A
So
what
we
instead
want
to
do
is
apply
changes
from
our
chat
to
this
declarative
configuration
and
that
let
this
then
be
reflected
into
helm
by
a
hand
file.
So
what
we
do
here
is
we
say:
ok
upgrade
recognize
us
to
some
specific
version.
Then
this
probably
has
a
check
out
of
this
repository
changes.
This
repository
and
updates.
There's
some
configurations
pushes
this
into
our
ground
truth
in
some
repository
upstream
and
have
this
applied
into
helm.
A
Now
this
is
nice
and
we
can
reason
about
things
that
come
from
our
chat
and
discuss
upon
that,
but
we
can
also
still
have
changes
right
here
in
this
version
control
system.
So
here
we
also
want
to
get
notified
in
the
chat.
If
somebody
is
changing
just
anything
here
which
is
still
a
valid
operation,
I
mean
we
can
just
change
the
configurations
here
as
usual,
through
pull
requests
whatever,
and
that's
why
we
also
have
a
route
where
we
look
at
the
diff
in
help
file
and
just
post
this
back
to
the
chat.
A
So
technically
for
us,
we
have
a
slack
command
here
that
then
just
triggers
some
operations
in
the
repository
we
have
git
commit
this
gets
pushed
to
get
up.
In
our
case
there
we
have
a
github
webhook
and
that
then
triggers
something
that
we
have
running
in
our
cluster.
So
this
is
just
a
small
service
that
is
running
in
our
cluster
listening
for
this
Web
book
and
then
applying
the
changes
to
the
whole
cluster
and
also
posting
the
diff
back
to
the
chat.
A
A
So
we
have
basically
two
main
interaction
modes
and
that's
the
important
case
here.
Why
we
combine
this?
Actually
we
have
the
one
where
we
have
regular
updates.
That's
what
we
do
on
a
daily
basis,
what
everybody
in
the
team
does-
and
this
is
pretty
easy
through
the
chat
as
you've.
Seen
on
the
other
side,
we
have
the
usual
administration,
where
you
change
your
kubernetes
resources.
Where
you
change
your
charge,
the
templates
have
different
sub
charts.
Whatever
complex
operations
you
have,
you
can
still
do
them
in
your
repository
and
have
both
system
combines.
A
So
this
is
just
to
commit
to
your
system
that
you
might
have
anyways
if
you're,
using
git
ops
already
so
the
numbers
again,
we
had
1300
interactions
through
the
chat
the
last
year
versus
versus
our
manual
direct
interactions
in
this
repository
that
were
like
240.
So
those
are
typical
of
the
more
complex
operations
by
actually
moving
the
big
parts,
and
that
doesn't
happen
so
often
it's
much
more
important
to
ease
the
burden
on
those
things
that
are
happening
on
daily
basis
and
that
actually
makes
this
system
rough
I
for
us.
A
Besides
that,
we
are
also
having
around
800
interactions
from
the
CI
system,
we're
having
nightly
builds
that
are
also
updating
some
configuration
here.
That's
actually
using
the
same
component
as
the
chat.
The
chat
actually
is
just
triggering
another
service
that
is
running
in
the
cluster,
which
then
changes
the
config,
and
this
middle
service
here
is
also
triggered
from
the
continuous
integration
to
then
have
some
specific
updates
on
our
configuration
state.
A
So
to
wrap
them
up
once
again,
we
have
now
chat,
amps,
plus
some
declarative
configuration,
and
this
gives
us
reproducibility,
which
you
might
know
from
key
drops
as
well
as
version
control
system.
Of
course,
plus
you
have
combined
it
with
high
visibility,
so
you
can
discuss
about
those
changes
that
you
do
through
your
chat.
C
A
Yep
you're
asking
about
security
actually
for
us.
Let
me
go
back
to
that,
so
here
we
use
slack
for
that
and
we
have
some
channels
and
only
in
those
channels
the
bot
is
listening
to
those
specific
commands
that
we
are
using.
You
could
have
also
more
fine-grained
security
with
access
control,
but
then
probably
that
wouldn't
be
in
the
chat
itself,
but
in
the
service
that
is
listening
behind
the
chat,
we
don't
need
that
at
all,
as
just
all
developers
are
in
this
channel
and
that
works
for
us.
A
So
if
we
go
here,
that's
actually
what
we
set
up,
usually
in
our
repository,
so
we
have
different
configurations
for
those
different
releases
that
you're
saying
and
one
of
those
facilities
is
which
version
we
are
running.
This
is
what
we
upgrade
through
the
chat,
but
everything
else
we
usually
set
once
or
upgraded
at
some
point
in
time,
but
not
that
often-
and
that
happens
just
in
the
repository,
and
so
we
have
those
overwrite
values
there.
Shorty
and
those
are
different
from
release
to
release.