►
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
Managing Helm Deployments with Gitops at CERN - Ricardo Rocha, CERN
Kubernetes has taken a key role at CERN both for physics analysis and core IT services, simplifying and accelerating deployments and allowing a much higher rate of updates and upgrades. This session will describe how helm is used for managing the description and configuration of the services. How CERN uses chartmuseum to maintain its private chart repositories, and how a custom plugin is used to manage secrets in the configuration, safely pushing encrypted payloads into git repositories. How a well defined structure of umbrella charts (sometimes referred to as meta charts) is used to define high level applications with complex dependencies, and how the notion of service variants and environments is exposed. A demo will show the full gitops lifecycle for both production and canary deployments, relying on weave flux to quickly propagate changes to clusters.
https://sched.co/UabD
A
Everyone,
so
my
name
is
Ricardo
I
work
at
CERN
in
Geneva
I'm,
a
computer
engineer
there
and
CERN
is
the
European
Organization
for
Nuclear
Research
for
those
that
are
not
aware
today,
I'll
try
to
describe
a
bit
how
we've
been
adopting
containers
but
specially
on
the
area
of
how
we
use
home
to
track
the
application.
Configuration
and
I
have
a
live
demo
at
the
end.
This
will
be
the
light.
Last
live
demo
I
do
this
year,
I've
done
quite
a
few
Alworth.
A
This
one
I
had
to
switch
the
laptop
at
the
last
minute,
which
is
not
my
laptop,
but
let's
see
maybe
this
will
still
work
otherwise,
I
hope
it
still
has
enough
content.
So
a
bit
about
CERN.
We
are
a
big
physics
laboratory
that
spans
the
border
between
France
and
Switzerland
close
to
Geneva.
We
build
large
scientific
experiments
to
explore
to
do
fundamental
physics,
research
and
explore
the
universe
and
the
origin
of
the
universe.
Try
to
answer
questions
like
what
is
matter
made
of
what
is
dark
energy
dark
matter.
A
Why
don't
we
see
antimatter,
and
for
this
we
build
very
large
machines.
This
is
the
largest
scientific
experiment
ever
built
largest
hadron
collider.
It's
a
ring
of
27
kilometers,
where
we
accelerate
protons
in
the
two
beams
of
protons
in
different
directions,
and
we
make
them
collide
at
specific
points
where
we
build
these
large
detectors
I
to
have
an
idea
of
the
size.
You
can
see
the
Geneva
Airport
there
on
the
down
right,
so
the
it's
it's
a
tunnel
and
a
hundred
meters
underground.
A
It's
quite
large-
and
we
have
this
four
main
experiment:
CMS
a
little
HTTP,
an
Atlas
where
we
built
these
detectors.
It
looks
like
this,
so
this
is
100
meters
underground
the
tunnel.
This
is
the
Large
Hadron
Collider,
it's
a
superconductor,
it's
made
of
superconducting
magnets,
and
to
achieve
this
we
put
them
at
the
parallel
low
temperature,
very
close
to
the
absolute
zero
1.7
Kelvin,
and
then
at
this
point,
where
we
make
the
protons
collide,
we
build
these
gigantic
machines.
So
this
is
the
compact
muon
solenoid
CMS.
It's
not
very
compact.
A
Compact
is
14
tons
and
it's
40
minutes,
but
40
meters
by
40
meters.
It
fills
up
the
cavern.
It's
also
a
100
meters
underground.
This
acts
like
a
gigantic
camera,
where
we
try
to
understand
what
happened
during
these
collisions
between
the
protons
and
we
try
to
prove
theories
about
the
nature
of
physics
of
the
universe
and
basically,
we
are
taking
40
million
pixel
pictures
a
second,
it's
not
really
pictures,
but
you
can
think
of
it
like
pictures,
and
this
is
basically
a
lot
of
data,
so
it
generates
something
like
1
petabyte
a
second.
A
We
have
to
trim
this
down
so
that
we
can
compute.
We
still
generates
everything
like
10
to
15
gigabytes,
a
second.
When
the
beam
is
on
to
produce
to
process
all
this
data,
we
have
a
large
private
clouds.
It
has
close
to
300
thousand
colors
these
days.
For
this
talk,
you
can
see
all
the
numbers
there,
but
for
this
talk
the
interesting
part
is
the
number
of
clusters
that
we
contain
or
clusters
that
we
have.
A
We
started
by
offering
multiple
container
orchestration
options
kubernetes
by
far
the
most
popular
swarm
has
one
use
case,
which
is
4-bit
lab
CI,
where
people
have
quite
a
few
clusters
there,
but
it
still
it
will.
A
lot
of
people
are
also
migrating
to
kubernetes
and
then
missiles
and
DCOs.
We
eventually
deprecated
support
because
we
had
very
few
users
now.
This
is
the
current
state.
A
A
Eventually,
we
moved
to
a
more
like
modern
data
center,
and
this
is
how
it
looks
today.
The
building
is
still
quite
old,
have
been
too
high
difficult
to
cool,
but
we
have
more
traditional
things
now.
In
addition
to
all
this
computing
that
we
use
for
a
large
scale
processing,
we
also
have
people
doing
funny
things
in
their
offices.
A
So
this
is
the
next
computer
that
Tim
berners-lee
used
to
when
he
created
the
world
wide
web
and
was
the
first
world
wide
web
server,
and
you
can
see
that
this
was
really
an
imported
server
because
it
has
a
sticker
and
in
this
sticker
it
said
this
machine
is
a
server,
do
not
power
down,
and
this
was
basically
the
message
that,
if,
when
cleaning,
if
someone
unplugs
to
plug
the
vacuum
cleaner,
the
web
is
down.
So
that's
not
good,
and
he
was
very
clear
about
now.
A
With
the
move
to
commodity
hardware
in
large
scale,
a
large
number
of
nodes
we
had
to
improve
a
lot
of
the
automation
and
efficiency
of
our
systems
and
I
will
try
to
describe
here
a
bit
some
of
the
parameters
that
have
changed
a
bit.
The
way
we
do
so
when
we
had
purely
physical
infrastructure,
provisioning
nodes
could
take
days
weeks,
maybe
months.
If
we
didn't
have
the
word
the
hardware
and
you
had
to
order
it,
we
had
to
the
ticket
way
to
explain
your
request.
Things
like
this
maintenance
was
highly
intrusive.
A
We
frequently
have
two
updates
of
the
operating
system
and
we
had
to
coordinate
with
the
users
going
to
do
this
deployments
and
updates.
We
started
using
configuration
management
pretty
early,
but
still
in
some
cases,
complex
applications
can
take
minutes
or
even
hours
to
update,
and
it
is
a
civilization
is
very
poor
because
it's
dedicated
to
a
single
application.
Even
if
it's
not
that
big,
then
introduction
of
quality
is
and
especially
virtualization.
A
This
allowed
us
to
have
a
very
quick
way
to
do
provisioning
of
resources
and
to
kind
of
separate
the
hardware
procurement
from
the
rest,
the
maintenance
in
if
the
application
was
designed,
so
that
it
could
be
easily
live
migration
migrates
it.
We
could
do
this
without
being
intrusive
deployment
and
update
was
pretty
much
the
same
because
we're
already
relying
on
configuration,
management
utilization
became
much
better
because
we
can
overcome
it
resources
and
make
sure
that
the
loads
are
the
nodes,
are
balanced
and
then
containers.
A
A
You
can
drain
notes
and
expect
that
it
will
deal
with
moving
the
application
around
as
appropriate
and
then
deployment
and
update
became
faster,
and
this
is
what
we
will
cover
in
the
rest
of
the
talk
and
the
utilization
became
better,
mostly
because
we
don't
have
to
external
layer
from
the
virtualization.
So
we
can
make
much
better
use,
especially
of
memory
and
then
some
experiences
so
during
this
transition,
it's
quite
interesting
to
see
how
our
users
deal
with
this.
A
So
when
we
moved
from
physical
machines
to
like
virtual
machines
and
cloud
API,
we
had
this
question
constantly.
Where
is
my
machine
now?
I
want
to
know
where
my
machine
is
hosted.
Things
like
this,
so
people
really
treated
them
as
pets
and
they
were
very
doubtful
of
the
cloud.
So
they
would
doubt
that
the
problems
they
are
seeing
they
would
blame
us
like
as
first
thing,
sometimes
it's
stupid.
Sometimes
it's
not,
but
still
the
transition
was
pretty
easy
because
the
provisioning
was
much
better
once
they
were
confident
with
it.
A
They
were
happy
to
take
it,
but
then
the
all
the
the
rest
you
still
SSH
to
your
node.
You
can
use
system
D,
you
can
use
whatever
configuration
management,
C's
log.
Everything
feels
pretty
much
the
same,
so
the
the
the
learning
curve
is
not
very
high
to
start
using
this
kind
of
infrastructure
now
two
containers.
This
is
much
more
different
and
we
have
a
large
number
of
users
and
we
get
a
bunch
of
questions
because
you
express
things
in
a
very
different
way.
A
You
need
to
know
how
to
use
kubernetes
all
the
notions
on
kubernetes
and
it's
not
kubernetes
only
its
ingress,
its
helm.
It's
the
CSI
drivers,
all
these
things,
persistent
volumes.
So
we
get
a
lot
of
questions
and
there's
a
steep
learning
curve.
Also,
people
are
still
used
to
going
to
the
nodes,
so
they
want
to
access
the
node
and
then,
in
our
case
we
use
the
remote
distribution,
so
they
won't
be
able
to
install
a
package
or
anything
and
they
start
asking.
A
Why
can't
I
do
it
and
we
have
to
explain
how
to
do
this
to
try
it.
So
this
our
disk
is
some
of
these
cases
we
have
one
of
the
most
interesting
ones
is
the
trigger
fans.
This
is
the
these
firms
that
filter
the
data
coming
in
to
reduce
the
amount
of
data
we
have
to
process-
and
this
is
a
very
interesting
use
case
because
they
have
to
change
the
application
running
in
the
cluster
very
fast.
A
If
there's
beam,
they
want
to
use
the
to
have
the
filter
running
when
the
beam
is
down,
they
want
to
read
to
redeploy
simulation
applications
so
that
they
make
the
best
use
of
this.
These
resources
all
the
time.
So
we
had
a
lot
of
iterations
with
them.
We
also
offer
spark
as
a
service
where
people
can
have
a
spark
service
in
their
own
kubernetes
cluster
coop
flow,
and
this
we
did
machine
learning
batch
on
kubernetes,
HT,
condor
and
other
internal
services
now
to
try
to
make
this
transition
easier.
A
We
organized
some
trainings
internally,
we
organized
workshops
from
time
to
time
and
office
hours.
We
took
this
idea
from
the
kubernetes
community
and
this
is
quite
popular.
We
have
end-users
talking
to
us,
but
also
between
each
other.
This
is
really
nice.
Now
one
thing
is
quite
similar.
Most
of
our
service
managers
are
used
already
to
use
git
to
maintain
their
configuration.
A
We
so
now
it's
called
get
ops,
but
storing
and
maintaining
the
versioning
of
the
configuration
of
your
applications
in
git
is
something
that
we
are
already
used
to
doing,
and
this
is
kind
of
a
nice
opportunity
to
ease
the
transition
to
pronounce
is
still
having
to
learn
everything
about
kubernetes.
They
can
learn
how
to
maintain
an
application
that
is
running
on
two
grenadiers,
just
by
accessing
the
configuration
in
gate
and
with
time
they
get
more
used
and
more
confident
with
the
internals
of
coronaries
itself
as
well.
A
So
if
you
look
in
our
case
we're
using
puppet
for
all
the
configuration,
the
transition
to
helm,
you
have
manifests
in
puppet.
You
have
going
going
templates
in
helm,
yeah
the
configuration
itself
we
have
here
in
in
puppet,
and
we
have
the
values
files
for
for
for
a
home,
and
these
are
both
llamo,
so,
like
everyone,
hates
yam,
yam
abides
everywhere,
and
it's
something
that
everyone
knows.
So
it's
it's
quite
nice.
A
It
also
has
it's
very
easy
to
show
the
benefits
when
you
are
using
puppet
to
transition
to
something
like
home
because
of
the
speed
of
deployment
and
iteration
on
the
features,
so
I'll
focus
the
rest
of
the
talk
on
helm
and
some
of
the
tooling
that
we
have
around
to
manage
all
of
this.
So
the
first
thing
I
would
like
to
mention
is
that
we
maintain
our
own
charts
repository,
actually
the
repositories.
So
initially
we
were
just
packaging
charts
from
upstream
and
putting
them
into
the
local
history.
A
The
reason
for
this
is
that
we
want
to
have
full
control
over
them.
Then
we
move
to
chart
museum,
it's
still
using
an
s3
back-end,
but
actually
having
an
API
makes
things
much
easier,
also
because
they
provide
a
nice
plugin
with
home
push,
and
then
we
have
also.
We
have
two
types
of
reporters.
What
is
what
we
call
certain
repository?
We
have
all
the
apps
to
internal
charts.
This
is
like
to
deploy
and
maintain
the
clients
for
our
storage
systems
and
similar,
and
also
we
have
mirror
charts.
A
These
are
just
sync
triples
between
the
upstream
charts
and
our
local
ones.
Again,
because
we
want
to
keep
some
control
and
then
we
we
have
did
the
gitlab
CI,
triggering
all
the
maintenance
of
the
repositories.
If,
if
an
app
streamed
repository
or
chart
gets
updated,
its
synced
with
our
local
repos,
and
then
we
can,
we
maintain
a
branch
which
is
our
release
branch
where
we
can
trigger
a
tag
and
the
tag
will
run
lint
tests
and
then
eventually
package
and
push
them
to
the
chart
museum.
A
So,
if
you
take
the
my
simple
chart,
we
will
never
deploy
them
icicle
chart
directly.
What
we
do
is
we
have
this
meta,
charts
or
umbrella
charts
that
have
all
the
dependencies
of
the
actual
deployment
you
want
to
do
so
say
you
have
an
internet
server
with
a
my
simple
back-end.
What
you
want
to
deploy
is
the
two
together,
so
we
have
this
notion
of
meta
charts
that
are
kept
in
a
separate
git
repo,
where
you
define
the
deployment
units
or
releases,
as
we
will
call
them
later.
A
We
started
by
doing
this
pretty
much
like
by
our
own
with
our
own
structure.
The
main
points
here
is
the
requirements,
so
this
is
I
put
an
example
here.
In
this
case,
the
application
only
has
one
requirement
which
binder
hub
actually
binder
hub,
has
many
other
requirements,
and
then
you
have
the
values
file,
which
is
the
default
configuration,
and
then
you
have
templates,
and
in
these
templates
we
can
add
stuff
to
the
charts
so
say
for
example,
in
this
case
we
want
binder
hobbies.
A
This
is
Jupiter
notebook
style
deployment
say
we
want
to
support
GPUs
in
the
cluster.
The
the
upstream
chart
does
not
handle
this,
so
we
have
a
specific
template
to
configure
the
GPU
setup
and
then
a
pod
security
policy
and
anything
else
we
might
have
want
here
and
now.
The
other
interesting
part
is
how
to
manage
secrets.
So
there
are
basically
two
options
that
we
consider
one
is
to
build
on
kubernetes
secrets
themselves
or
similar
CRD.
A
So
there
is
no
easy
way
or
obvious
way
to
plug
in
a
external
secret
providers
in
the
coronaries
there's
things
like
vietnamese
sealed
secrets
that
are
good,
but
there
are
custom
resources
which
means
that
if
you
use
them
it
kind
of
breaks
most
of
the
obstruent
home,
charts
and
vault
is
a
fully
managed
solution,
but
we
don't
have
a
vault
service
in-house
now.
The
second
option
is
to
not
treat
handle
the
coronary
secrets
directly,
but
just
to
treat
secrets
as
configuration.
A
What
this
means
is
that
all
the
secret
configuration
is
just
in
the
values
file
and
you
encrypt
that
part.
So
whatever
is
is
not
you
cannot
just
expose
the
configuration,
then
you
encrypt
it
and
there's
a
tool
called
hum-hum
secrets
from
future
simple
that
does
this
with
also
supporting
subs
internally,
we
do
have
a
secret
storage
service,
a
secret
service
as
if
you
wish-
and
we
built
a
plugin
for
a
home
that
is
very
similar.
What
it
does.
It
builds
on
our
only
identity
scheme,
so
this
part
is
solved.
We
just
rely
on
it.
A
The
tool
is
called
Barbican
and
from
OpenStack,
and
we
can
just
rely
on
the
on
this
identity
to
manage
all
the
secrets.
The
comments
look
like
this
you
put
hum,
and
then
you
name
the
released
the
name
of
the
release
plus
the
project.
Your
your
configured
in
will
define
where
the
name
of
the
encryption
key
that
will
be
fetched
to
manage
the
secrets.
Then
you
can
view
just
exposing
the
contents
you
can
edit,
where
the
crips
in
memory
and
encrypts
for
for
storage.
A
A
Now.
The
most
interesting
part,
I
think,
is
when
you
start
doing
the
wool
flow.
So
all
of
this
was
kind
of
manual.
A
lot
of
people
would
trigger
things
in
their
little
app
see.
Is
that
with
the
push
into
the
cluster,
but
this
means
that
you
have
to
put
the
cluster
credentials
somewhere
in
your
gate
system
or
in
some
system
that
interacts
with
git,
but
this
was
always
our
end
goal,
as
I
mentioned,
to
try
to
simplify
the
life
of
our
users,
and
then
you
have
here
on
the
top
right.
A
The
comment
that
you
usually
use,
which
is
how
many
install
flux
where
we
use
flux
CD,
to
maintain
this
there's
other
options.
I
will
mention
also
at
the
end.
But
flux
worked
quite
well
for
us,
we
pass
a
bunch
of
default
configuration
and
you
can
see
what
it
does.
It
basically
defines
the
interval
that
it
sinks
back
to
the
and
additional
repositories
we
need,
and
if
you
look
to
the
options
there,
we
see
a
get
poly
interval,
which
is
the
polling
interval.
A
The
URL
URL
is
just
the
URL
of
the
git
repo
holding
the
meta
chart
on
umbrella
chart
that
it
should
be
deployed
locally
and
then
flux
what
it
does.
It
runs
in
your
cluster
and
it
contacts
the
the
the
git
repo
checking
for
updates
when
it
when
it
sees
an
update.
It
updates
a
local
home
release
which
is
a
custom
resource,
and
then
it
has
a
home
operator
that
is
listening
to
this.
That
is
implementing
this
custom
resource,
and
then
it
applies
it
in
the
cluster.
A
So
all
the
flow
is
there
now
flux
also
does
something
in
addition,
which
is
when
you,
you
could
define
a
policy
on
the
image
versions
where,
if
you
update
the
image
via
some
other
mean
in
the
in
a
docker
registry,
it
would
actually
write,
update
the
charts
directly
and
get
itself
making
like
the
full
cycle.
We
are
not
doing
this
yet
and
we
are
not
sure
we
want
to
do
this.
So
what
we
do
now.
A
We
have
a
completely
separate
CI
to
maintain
in
the
applications
with
their
their
tests
and
then,
when
there's
a
new
release,
the
service
manager
has
to
go
to
the
meta
chart
and
update
the
version
of
the
image
directly
and
the
configuration
files.
And
then
a
home
release
looks
like
this.
You
define
again
the
the
git
repo
that
you
want
to
pick
up.
The
home
chart
from
the
location
of
the
home
chart
and
I'll
try
to
show
it
in
a
bit
and
then
the
branch
that
you
want
to
use.
A
So
by
allowing
to
specify
the
branch
you
can
play
with
a
lot
of
things
like
having
test
environments
in
the
grid,
lab
CI
and
then
on
the
bottom.
You
just
specify
the
values
for
for
the
application.
The
structure
of
meta
chart
looks
like
what
is
on
the
right,
so
you
have
the
meta
chart
on
charts.
In
this
case
it's
called
hub
and
inside
you
have
this
requirements,
file
the
values
file
and
the
cust
manifests
that
indicates
before
was
the
GPU,
and
then
you
have
the
releases
while
the
namespaces,
and
then
you
have
the
releases.
A
So
in
this
case
we
maintain
two
different
releases
of
this
application:
one
for
production,
one
for
staging.
This
allows
us
to
override
the
default
values
for
each
of
the
environment,
and
then
the
only
specific
thing
we
have
is
because
we
have
this
specific
secrets:
plugin
for
home,
we
kind
of
put
the
secrets
outside
of
flux.
This
is
not
ideal,
but
it
allows
us
to
track
this
secret.
A
The
configuration
part
that
is
encrypted
together
with
the
rest
of
the
configuration,
while
still
benefiting
from
flux,
so
this
means
that
whenever
you
update
the
secrets,
you
actually
have
to
update
the
cluster
manual,
but
this
is
not
that
often
as
the
rest
of
the
configuration.
Ideally,
this
should
be
inside
flux
as
well,
and
once
it
supports
something
like
soaps,
we
will
be
able
to
do
this
so
now,
I'll
switch
to
the
demo,
which
I
hope
it
works,
so
I've
never
used
this
laptop.
A
A
Yes,
cool,
sorry
Mac,
is
it
good
cool?
Okay,
so
what
I
will
do
is
I
will
start
by
doing
I'll
run
this
command?
Ok.
So
what
this
will
do
is
like
a
pre
setup
of
the
cluster.
This
sets
up
things
like
the
namespace
that
we
saw
there
that
has
to
be
created
before
and
as
I
mentioned,
we
have
to
manage
the
secrets
independently.
So
this
is
what
it
does
and
then
so,
if
I
look
into.
A
Okay,
so
this
is
the
comment
that
we
saw
before
how
install
and
then
you
pass
the
default
values
for
flux
with
all
the
default
configuration,
and
then
we
say
that
we
want
to
pull
interval
of
one
minute
here:
yeah
and
then
the
URL
of
the
the
repo
using
the
meta
chart,
and
then
we
say
also
that
we
want
to
use
a
specific
branch
that
is
called
demo.
So
what
I
will
do
is
Outrigger.
This.
A
Okay,
so
this
just
deployed
flux.
Okay,
this
is
this
is
I'm
actually
on
the
CERN
system.
Right
now
so
I'm
doing
this
life,
lots
of
things
can
go
wrong,
so
we
see
already
that
hum
has
one
release.
That
is
called
flux.
While
this
is
going,
what
I
will
do
is
I
will
show
you
a
bit
more
in
detail
what
what
I
was
talking
about
before
so
the
first
area
we
saw
is
this
charts
hub?
A
This
is
the
meta
chart
and
if
I
look
into
the
requirements,
I
see
that
I
have
one
requirement
in
this
case,
which
is
binder
hub.
This
is
actually
quite
complex
application
where
it
well,
while
it
is
deploying
it
actually
defines
the
storage
for
for
my
sequel
database,
its
deploying
ingress,
and
so
it's
not
it's
not
that
simple,
and
then
we
have
also
the
hub
templates
GPU,
where
we
deploy
the
nvidia
driver
on
the
cluster.
This
is
tied
to
the
kernel,
of
course.
A
So
if
you
are
handling
GPUs,
you
will
know
how
much
fun
this
is,
and
so
it's
basically
deploying
this
is
also
for
the
cluster
to
be
able
to
handle
GPUs.
And
then
the
releases
have
all
this
that
we
saw
the
prod
the
staging,
and
then
we
have
this
and
inside
the
demo
one.
We
have
a
home
release
where
we
define
things.
We
said
that
the
demo
branch
is
using
this
external
configuration
to
fetch
the
secret
data
and
then
a
bunch
of
stuff
for
for
the
configuration
of
the
application.
A
So
if
I
look
now
there
we
go
so
now
we
have.
While
we
were
talking
flux
detected
now,
I
have
a
new
I
saw
a
hum
release
in
the
git
repo
I
will
deploy
it
and
then
the
helm
operator
saw
the
new
hum
release
and
applied
it
to
the
to
the
cluster.
So
we
have
two
releases
here.
If
we
see
quickly
here,
it's
still
creating,
so
it's
deploy
its
finalizing
the
requirement
there
we
go
so
now
it's
validating
so
that
we
are
almost
there
and
what
I
will
do
is
I
will
try
to
access
it.
A
So
you
can
see
that's
404
not
found
because
I
opened
it
because
before
deploying
earlier
now,
if
all
go,
we'll
go,
I'll
have
to
login.
Also
so
you'll
see
the
new
cern
login
page,
this
works
yeah.
So
this
also
takes
care
of
things
like
single
sign-on
registration
and
things
like
this.
So
it's
quite
complete,
even
if
it
took
only
a
couple
of
seconds
and
now
logged
in
and
there
we
go.
So
we
have
a
full
Jupiter
notebook
application
running
with
the
my
simple
database
and
all
the
fancy
whistles.
A
If
I
would
I
could
create
it
here.
My
server
and
what
I
will
do?
I,
don't
know,
choose
some
machine
learning
thing
and
I
will
go
for
GPUs
and
I
could
just
go
and
deploy
my
notebook
there's
another
application
that
I
deployed
here.
I
will
do
a
slide.
Cheat
here.
I
assume,
which
is
the
the
second
chart,
actually
has
one
bug
that
was
introduced
recently.
So
I
have
to
do
a
quick
patch
for
this
to
work,
but
it's
a
coupe
city
or
patch.
It's
also
quite
fast
and
useful
for
demos.
So
this
should
hopefully
work.
A
A
And
in
theory
now,
if
we
wait
up
to
a
minute
how
flux
will
detect
this
and
apply
that
we
can
also
trigger
it
immediately
by
doing
this,
so
this
is
actually
triggering,
and
it's
so
that
there's
a
new
commit
and
you
can
see
the
commit
ID
here,
matching
the
one
we
just
did
here.
This
is
all
looking
good,
we'll
take
a
second.
A
A
And
that's
it
for
a
live
demo,
so
that
was
the
last
one
of
the
year
and
I'm
happy.
It
also
worked,
although
there's
always
something:
okay,
so
okay,
so
this
was
just
a.
This
is
actually
how
we
deployed
this
application
I'm
using
a
repository
that
is
actually
the
stuff
we
use
for
production.
So
it's
just
a
branch
on
it.
A
Also-
and
this
is
a
quite
messy
mix
of
batch
script-
sound
charts
and
things
like
this,
so
we
want
to
move
it
completely
to
a
hunger
release
that
will
be
managed
by
flux
and
maintain
two
or
a
couple
of
environments,
production
staging,
maybe
others
so
that
people
can
choose
when
they
register
there
when
they
create
a
cluster.
They
want
to
use
the
staging
branch
or
the
production
branch
and
then
we'll
centrally
manage
all
the
add-ons
which
will
simplify
a
lot.
A
The
upgrades
and
here
I
put
some
some
example,
so
the
dependencies
we
would
manage
these
things,
like
font,
II
and
the
configuration
to
push
the
logs
to
our
elastic
search
parameters
and
pushing
the
metrics
to
our
central
metric
service
traffic
for
ingress.
Things
like
this,
so
I
come
to
the
conclusion.
We
are
relying
a
lot
on
home
as
you
could
see,
and
we
are
now
relying
on
things
like
flux
or
art
or
flux,
as
a
familiar
tool
set
to
handle
can
tell
containerized
applications.
If
you
think
about
it,
it's
basically
doing
the
same.
A
We
were
doing
for
for
note
management,
but
for
containers,
which
has
like
all
the
benefits
of
using
containers
instead
of
individual
nodes.
We
want
to
remain
as
we'd
get
as
the
source
of
truth,
so
this
allows
us
to
define
all
the
permissions
on
the
git
repositories
and
separate
by
groups
there.
We
are
ready
doing
it,
so
this
is
one
of
the
main
reasons
why
we
want
to
keep
doing
it
and
now
for
future
steps.
We
want
as
everyone
to
use
HMMWV
3.
A
So
this
was
a
demo
with
v2,
but
we
all
right
started
using
v33
to
get
rid
of
chiller
mostly,
but
there
are
also
other
nice
features.
There's
the
home
hub
or
it's
unclear
to
us
how
we
will
manage
this,
but
the
idea
would
be
to
have
a
local
replica
of
this,
or
at
least
the
charts.
We
are
interested
as
we
want
to
keep
some
control
and
we
want
to
start
signing
charts.
So
this
is
something
that
we
are
working
on
right
now
now
automating.
The
container
image
deployment
is
something
that
we
might
reconsider.
A
We
will
see
how
this
goes
and
then
the
main
thing
we
are
working
on
now
is
to
have
clusters
not
being
pets.
The
same
way,
we
were
not
so
happy
that
people
treat
notice
as
pets.
One
of
the
main
frustrations
is
I
know.
A
lot
of
things
can
go
wrong
with
the
cluster.
We
do
the
tools
to
recover
it,
but
it
also
causes
frustration.
A
So
we're
trying
to
convince
people
to
have
this
kind
of
easy
way
of
deploying
their
application
to
new
clusters
so
that
they
can
have
they
can
spread
the
load
and
maybe
lose
some
capacity
when
one
goes
down,
but
at
least
keep
the
application
always
up
and
then
using
cannery
and
surface
finished
for
cannery
deployments.
We
are
still
not
very
experienced
with
the
service
mesh,
but
we
started
looking
at
it.
So
I,
don't
know
if
you
follow
this
area.