►
From YouTube: ArgoCon '21: Argo CD and Stateful Applications - Tips and Tricks! (Christian Hernandez)
Description
Argo CD is widely used as a tool in GitOps workflows. Part of the appeal of GitOps is the recovery after a disaster can be expedited. Reinstall the cluster and reapply the manifest is the high level instructions, but is that all? In this talk I will go over what to keep in mind when planning your recovery of your stateful applications.
A
We
are
now
joined
by
christian
christian,
currently
works
on
the
customer
and
field
engagement
team
in
the
hybrid
platforms,
business
unit
within
red
hat
he's
a
technologist
with
experience
in
infrastructure,
engineering
systems,
administration,
enterprise
architecture,
tech
support
and
management.
Christian
is
passionate
about
open
source
and
containerizing
the
world
one
application.
At
a
time.
Lately
he's
been
focusing
on
kubernetes,
microservices
cloud
native
architecture
and
get
ops
practices
christian.
What
do
you
have
in
store
for
us
today?.
B
B
Staple
applications
is
something
that
is
always
a
challenge
and
I'm
here
to
share
some
of
the
tips
and
tricks
that
I've
learned
along
the
way
working
with
staple
applications
and
argo
cd
anytime.
I
do
a
talk.
I
always
like
to
start
off
with
a
good
quote,
and
so
I
found
a
great
quote
from
christian
posta,
who
is
currently
the
field
cto
at
solo.
B
One
of
the
many
benefits
of
get
ops
is
that
it
reduces
the
time
to
recovery
right,
that's
one
of
the
things
that
that
you
get
by
doing
get
ups
practices
and
the
idea
is
being
you
just
reapply
the
manifests
and
you're
back
in
business
right.
You
have
an
outage.
You
spin
up
a
cluster,
you
reply,
your
manifests
and
you're
back
up
right.
B
That's
that
kind
of
the
whole
idea
and,
as
we
all
know
and
hope,
hopefully
none
of
you
have
been
into
any
serious
problems,
but
it's
a
little
bit
more
complex
than
that
right
and
you
know
you
always
think
about
what
about
your
staple
applications.
What
about
what
was
the
data
lost?
Were
you
hosting
a
database?
B
Do
do
we
need
to
recover
data
from
a
backup?
What
was
the
application
storage
pointing
to
exactly
right?
Where
was
it?
What
was
it
consuming?
Storage
so,
depending
on
what
happened,
you
may
need
to
take
a
different
approach
on
restoring
those.
So
so
just
a
point
of
reference
in
this
talk,
I'm
going
to
be
focusing
on
recovering
from
an
outage,
specifically
right
so
failing
over
to
another
site
in
general.
Disaster
recovery
is
kind
of
out
of
scope
for
this.
B
For
this
talk,
but
you
know
I
just
won't
have
time
right,
it's
a
big
topic,
but
hopefully
this
can
give
you
ideas
in
preparing
for
those
kind
of
scenarios.
So
the
challenge
of
stateful
application
isn't
something
new,
as
I
said
before,
but
it
is,
you
know,
a
general
problem,
and
hopefully
you
can
start
formulating
some
disaster
recovery
processes
around
what
you
learned
today.
So
first
I
like
to
talk
about
storage
with
kubernetes
from
a
high
level.
Just
in
from
a
generic
standpoint.
B
Storage
has
always
been
a
challenge
in
kubernetes
it's
from
day
one
right.
So,
ideally,
all
of
our
applications
will
be
stateless,
but
that's
honestly,
not
the
world.
We
live
in
in
the
world
of
I.t,
whether
you're
doing
cloud
native
state
slash
data
is
always
at
the
center
of
everything.
It's
no
different
with
kubernetes
right.
So
you
know
traditional
cl
application,
development
and
application
development
on
kubernetes
there's
a
lot
of
differences,
but
really
what
they
have
in
common
is
the
data,
because
that's
really
the
center
of
the
world.
B
You
know
even
with
cloud
native
applications,
you
need
to
sort
states
somewhere.
So
this
is
where
the
persistent
volume
percent
volume
claim
paradigm
came
to
play.
Pv
and
pvc
right.
Persistent
volume
versus
volume
claim
allowed
a
way
to
abstract
the
storage
and
from
it
abstracted
the
storage
from
the
application
to
where
the
idea
was
that
the
application
just
says
hey.
B
I
need
some
storage
and
everything
else
kind
of
automatically
happens
on
the
back
end,
and
so
some
of
the
things
that
came
along
with
that
is
storage
classes
right
so
like
after
that
came
about
storage
classes.
Were
there
to
help
to
tier
the
storage.
You
know
the
way
you
have
you
know
I
need
ultra
fast
storage.
I
need
you
know,
you
know
I
don't
care
as
long
as
the
data
is
available,
gold,
platinum.
You
know
that
kind
of
kind
of
kind
of
idea,
with
with
storage
classes
right.
B
That
was
all
very
manual
but
but
then
the
the
advent
of
you
know
the
the
idea
of
dynamic
volume,
provisioning
came
came
to
place
race
where
no
longer
administrators
need
to
specifically
create
persistent
volumes.
There
is
a
controller
that
created
those
volumes
for
you
right,
so
it
connected
to
the
back-end
storage
and
it
created
those
storage
on
the
flyer.
So
you
never.
It
removed
the
need
for
administrators
to
create
those
persistent
volumes
at
scale
right
and
now
with
csi.
B
This
is
making
is
making
things
easier
right,
the
container
storage
interface.
So
now
you
have
a
bunch
of
choices
when
choosing
for
for
storage
right
so
now
before
it
was
traditionally,
you
just
had
block
and
nfs
kubernetes.
Now
you
have
all
kinds
of
choice,
choices
that
are
provided
for
you,
so
so
get
up.
Some
storage
right,
the
dynamic
storage
provisioning
introduced
a
very
interesting
problem
right,
so
it
was
a
savior,
but
then
it
introduced
a
problem
with
get
ops
right.
B
So
with
get
ops,
a
representation
of
your
application
is
stored
in
git.
So
this
allows
you
to
quickly
restore
you
know
an
event
of
a
failure
like
like
a
like
I
mentioned
before,
so
is
it
you
know
all
unicorns
and
rainbows
there?
Well,
not
really!
So,
if
you
think
about
it,
the
default
reclaim
policy
for
dynamic
storage
is
delete,
meaning
that
when
the
persistent
volume
claim
is
deleted,
the
back
end
storage
is
also
deleted
right.
So
this
you
know
forget
losing
a
cluster.
B
So
there
are
some
providers
that
have
full
integration
with
kubernetes
right
for
like
snapshotting
resizing,
but
but
that
that
that's
still
something
new
and
that
that's
still
something
that
not
a
lot
of
administrators
still
do
right.
So
a
lot
of
a
lot,
if
not
most,
if
not
all
the
storage
management
still
happens
outside
of
kubernetes
right
so
they're.
So
there's
kind
of
like
a
disjointed
thought
behind,
or
you
know,
restoring
your
your
application.
B
So
there's
other
things
to
consider
too,
when
you're
restoring
from
a
from
from
a
catastrophe
right,
you
need
to
do
things
like
file
permissions
right.
You
need
to
make
sure
those
are
those
are
set.
You
know
you
need
to
think
about
whether
you're
going
to
restore
from
backup
or,
if
you're
running
a
database.
B
So
that's
kind
of
another
decision
you
need
to
make,
and
so
you
know
that's
kind
of
some
other
other
things
to
consider
of
you
know:
where
does
the
storage
live
and
how
is
that
management
done
and
what
you
know
how
you're
gonna
do
that?
So
with
that,
I
kind
of
like
to
bring
up
some
of
the
tips
and
tricks
that
I've
used,
so
don't
use
dynamic
storage.
So
yeah,
sorry
right,
I
know
it's
kind
of
no
fun,
but
in
get
ups
world
this
is.
B
I
think
this
is
actually
an
anti-pattern
using.
You
know
my
my
opinion
using
dynamic
storage
right,
so
you
actually
want
to
specify
the
storage
you
are
using
for
a
specific
application.
If
git
ops
in
a
git
ups
world
you're,
using
something
as
a
source
of
truth
using
dynamic
storage,
you
know
that
that
can
change
on
the
back
end
right.
So
no
you
you!
You
really
want
to
have
a
one-to-one
relationship
from
your
storage
to
your
application.
B
B
B
This
application
is
a
you
know,
front-end
web.
You
know,
three-tiered
application,
front-end
web
a
back-end
and
a
db
having
a
simple
crud
application
right.
So
I
do
have
some
data
that
is,
that
is
stored
on
the
application
here.
If
I
look
at
the
configuration
for
this
calling
this
out
really
quick
is
the
the
the
persistent
volume
here
and
a
few
things
I
want
to
call
out
is
that
one,
I'm
labeling,
this
remember:
label
selectors
is
very
important.
B
I
am
setting
the
persistent
volume
claim
policy
to
retain
and
I'm
stating
the
claim
reference
to
claim
reference
to
say
specifically
satisfy
this
specific
claim
so
kind
of
mapping
those
one
to
one
there.
I
have
a
a
volume
I
created
on
aws,
specifically
right,
so
I,
as
you
see
here,
I
have
a
little
cheat
sheet
here
that
that
I
use
this,
creates
the
volume
and
I
use
this
volume
id
specifically.
B
B
I
also
want
to
call
out
that
I'm
using
security
context
constraint
right,
I'm
adding
a
supplemental
group
so
that
way
the
permissions
always
stay.
You
know
this.
This
application
runs
always
as
this
specific
group
id.
So
that
way
the
permissions
don't
get
messed
up
so
here.
So
if
I
go
down
here
and
if
I
do
a
get
a
persistent
volume
you'll
see
that
I
have
that
persistent
volume
and
it's
bound
to
that
claim.
B
B
So,
as
you
see
here,
argo
city
automatically
says
hey,
this
is
out
of
sync:
things
are
being
deleted,
so
the
application
is
actually
gone.
So
if
I
go
over
here
and
I
reload
this
here,
applications
is
gone.
The
pv
is
still
there.
So
if
I
do
a
get
persistent
volume,
it's
still
there,
the
status
is
now
released,
but
an
actual
failure.
Let's
delete
the
pv,
the
pv
will
be
gone
right,
there's
an
actual
failure.
B
The
persistent
volume
will
be
gone
and
so
the
you
know
this
is
kind
of
like
hey.
Either
the
project
got
deleted,
the
the
percent
volume
got
deleted
or
the
cluster
got
deleted
and
we're
just
kind
of
simulating
me
reinstalling
a
cluster
right.
So
this
is
completely
gone.
The
application's
done,
so
all
I
have
to
do
right
is
kind
of
just
sync.
B
This
back
up,
and
so
the
idea
being,
is
that
since
I
specified
the
storage
specifically
in
get
as
you
see
as
you
see
in
in
the
in
the
yaml,
and
that
was
already
created
on
aws,
and
that
volume
was
already
there
reapplying,
the
manifests
shows
it
works
right,
and
so
here,
as
you
see,
everything
is
starting
to
sync
up.
The
very
last
thing
to
sync
up
here
is
the
openshift
route,
which
looks
like
I'm
back
on
business,
everything's
green.