►
From YouTube: GitOps Patterns for managing cloud native applications by Roberto Carratalá & Germán M Yébenes
Description
In this session, we will present some of the best practices for deploying GitOps application workloads in multi-application use cases. Using Syncwave, Hooks and ArgoCD Image Updater, we will present the advanced deployment patterns in GitOps / ArgoCD and discuss the promotion strategy between clusters in dev, test, stage and prod environments. Furthermore, we will demonstrate how to deploy GitOps Applications to multiple Kubernetes clusters simultaneously, by the means of grouping applications in Application Sets, using various strategies such as GitOps generators.
A
So
your
favorite
Italian
again
good
morning,
we
are
going
to
have
a
special
presentation
today,
it's
more
of
a
boxing
match
between
redette
and
Souza
than
that.
A
presentation
well
I'm,
very
I'm,
very
happy
to
have
Hermann
and
and
and
Roberto
here
with
us.
It's
a
it's
a
beautiful
example
of
community
work,
Reddit
and
Susie
our
competitors.
A
They
work,
they
go
on
same
clients
on
same
behind
same
Technologies
and
all
these
things,
but
still
they're,
working
together
to
improve
our
open
source
community
and
that's
extremely
and
if
that's
not
an
example
of
community
work,
I,
don't
know
what
it
is,
so
please
give
it
up
for
Airman
and
Roberto.
Thank
you.
A
B
So
today
we
will
explain
the
different
patterns
for
the
different
gitops
deployments
and
to
manage
Cloud
native
applications.
So
imagine
that
you
are
working
in
a
platform
engineer
or
a
devops
team
that
needs
to
manage
hundreds
of
different
microservices
and
you
recently
adopt
the
different
github's
methodology.
But
you
wanted
to
know
also
how
to
implement
these
different
patterns
that
you
have.
B
C
So,
in
terms
of
the
tools
and
projects
we're
going
to
review
first,
some
of
the
some
of
the
projects
that
we're
going
to
see
please,
okay,
so
the
first
things
we
are
not
going
to
invest
so
much
time
in
this
because
we
are
assuming
that
we
are
all
familiar
with
the
githubs
with
so
some
of
the
principles
the
system
is
described,
declaratively,
it's
it's
a
new
good
Paradigm
that
we
are
going
to
see
for
deploying
the
applications.
It's
even
deploying
or
changing
the
infrastructure.
C
The
decided
state
is
version,
you
don't
get
the
different
states.
The
current
states
is
what
we
get
from
the
Clusters
and
the
decided
state
is
what
we
want
to
get
all
the
appropriate
changes
can
be
applied
automatically.
There's
two
models,
two
major
models:
there
are
pool
and
push
models,
and
both
of
them
will
be
applied
directly.
As
long
as
we
have
the
changes
in
in
the
indicator.
Repository
and
also
a
controller
exists
in
case
of
any
drift
is
detected
between
the
current
state
under
the
side
of
the
state.
C
What
is
the
clouded
into
the
repository
and
what
is
the?
What
is
reported
from
the
cluster
itself?
So
the
one
of
the
major
tools
that
we
are
going
to
use
is
the
Argo
CD.
We
are
all
familiar
with
Argo
CD
I
hope,
so
it
is
a
cluster
and
application
configuration
version
it
and
and
Git
it
automatically
syncs
configuration
from
git
to
the
Clusters
in
case
of
any
drift
detections
you
can
visualize
and
correcting,
depending
of
how
you
configure
that
it
provides
granular
control
over
sink
order
for
complexual
routes.
C
It
can
roll
back
on
Raw
follower
for
to
any
kid
coming.
So
so
the
gate
will
be
will
be
a
milestone,
a
point
on
time
about
what
our
infrastructure,
what's
at
certain
point
of
time
and
the
manifold
is
tempting
support
which
is
going
to
be
the
major
point
of
this
talk.
This
is
going
to
be
a
lot
talking
about
the
templating,
so
this
is
focuses
on
the
customize,
but
when
we
cover
and
also
you
can
also
provide
some
visual
insights
about
the
the
situation
we
have
into
the
infrastructure.
C
B
Let's
start
with
the
some
fun
with
guitar
patterns
with
argosity,
you
have
also
this
QR
and
also
this
URL,
and
if
you
just
scan
it,
you
can
go
to
One,
open
source
repo,
and
you
can
reproduce
every
single
demo
that
you
have
in
here.
So
we
like
risks
and
for
that
reason
we
are
doing
live
demos
with
a
hotspot,
so
yeah
it
will
be
fun
and
we
have
also
our
argosity
instant
in
here
and
in
this
different
QR.
B
C
C
Some
of
the
principles
we
have
with
the
customize
customizes
consist
in
a
base
file,
some
of
the
base
files
with
the
customization
dot
yaml
file
itself,
which
is
declining
what
what
is
going
to
be
the
files
that
will
be
changed
or
some
of
the
some
of
the
specifications
that
we're
going
to
add,
depending
of
which
environments
we
want
to
create,
based
based
on
the
paste
where
we
will
be
able
to
create
some
overlays
in
this
case.
For
this
example,
we
have
two
the
development
one
and
the
production
one.
C
Each
of
them
has
different
CPU
accounts,
replica
counts
and
other
customization
that
we
want
to
add.
The
major
point
of
that
is
we
don't
want
to
duplicate
the
files
depending
of
the
environments,
because
this
is
okay
for
one
application.
Let's
try
to
imagine
this
with
thousands
and
thousands
of
applications,
it's
almost
impossible,
so
these
are
really
good
for
templating
things,
because
if
you
are
templating
with
customize,
you
don't
need
you
remove
that
need
of
duplicating
things.
C
If
we
go
to
the
dashboard
we'll
be
able
to
see
the
application
is
it's
deployed
and
we
can
see
the
different
objects
available.
If
you
go
to
the
details,
you
can
see
the
repo
URL,
so
it's
pointing
to
the
git
repository
where
you
have
all
the
the
customization
files
and
within
a
specific
path.
If
you
go
there,
you
will
be
able
to
see
the
customization
file
itself,
which
is
pointing
if
you
go
into
the
customization.
C
Thank
you
buddy.
It's
now
targeting
using
some
of
the
resources
available
and
the
patch
strategy
that
we
want
to
change.
In
this
case,
for
example,
we
want
to
Target
in
this
specific
deployment.
This
deployment
we
have
here
with
the
name
of
bgdk
will
be
changing.
These
values
here
so
we
want
to
change
the
first
item
into
the
first
array
and
we
want
to
change
that
value
to
Yellow.
Customize
will
read
that
and
we'll
apply
the
changes
to
the
application
deploys
in
in
our
gocd.
C
So
if
you
go
back
here
and
see
the
applications
details
go
down
into
the
Manifest,
I
hope
the
everyone
can
see
that
you
see
the
first
item
in
the
value.
It's
the
name
of
color,
thank
you
and
the
value
of
yellow.
So
in
this
way
you
can
change
that.
So
imagine
this
is
development
environment.
You
can
push
that
to
production
and
you
can
change
that
to
the
desired
value
that
you
want
to
all.
B
Right
then,
first
demo
life.
So
what
if
you
wanted
to
control
The
Ordering
of
the
different
githubs,
because
githubs
it's
thinking,
every
single
kubernet
is
manifest.
But
what,
if
you
need
to
First
deploy
your
database
insert
some
data
into
the
database
and
therefore
deploy
your
front
end?
How
you
can
control
the
order
within
dictator's
deployment,
introducing
sync
waves
and
hooks
a
single
if
it's
a
way
to
order?
How
obviously
applies
to
the
different
manifest?
Storing
it
and
all
of
the
manifests?
All
of
the
kubernetes
manifests?
B
Have
this
annotation
with
this
scene
wave
and
also
one
number
that
defines
the
grouping
of
the
different
applications?
So
you
can
group,
and
you
can
Define
first-
is
the
database
and
then
you
can
apply
different
things
like
the
front-end,
implying
also
and
defining
all
the
things
and
are
very
handy
also
to
its
hooks
that
could
be
and
can
run
before
during
and
after
a
sync
operation.
So
in
this
specific
demo
we
will
insert
some
information,
usually
in
the
API,
when
everything
is
ready,
but
you
can
send
messages
in
slack.
B
Send
if
everything,
for
example,
works.
Well,
you
can
send
one
slack
message:
if
everything
was
wrong,
you
can
send
arpeggio
Duty,
for
example,
you
can
control
the
different
stages
or
not
so
in
this
demo
we
will
control
the
order
and
we
will
first
deploy
the
database.
We
insert
data,
we
will
deploy
the
front
end
and
we'll
make
an
HTTP
call
just
with
a
single
Cube
CTR.
Hopefully,
let's
see
so.
If
we
go
to
the
second
pattern
in
this
second
pattern,
we
have
DTD
application.
B
We
copy
paste
that
we
go
to
departing
to
the
platin
T
and
we
deploy
it.
Just
we
go
to
these
show
ads
because
it's
pretty
quickly
and
as
you
can
see,
this
is
not
a
big
bang.
It's
having
order.
It's
first
deploying
the
application
of
the
postures
and
applying
also
different
things
like
the
front
and
as
well,
and
it's
doing
everything
with
the
different
order.
So
it's
not
applying
every
single
object
that
detects
it's
maintaining
the
proper
order,
defining,
for
example,
this
how
you
can
control
it.
B
Remember
that
we
applied
seam
waves
and
we
have
a
single
wave
with
zero
that
it's
applying
the
first
time
and
afterwards,
when
it's
ready
when
it's
deployed
and
sync
it
properly.
We
have
also
the
thing
with
two
defining
different
things:
that
we
can
control
and
controlling
the
order
within
the
different
githubs
deployments.
So
you
can
have
the
power
of
controlling
and
orchestrating
your
different
kubernetes
manifests.
C
So
what
a
good
way
to
orchestrate
things
right,
so,
let's
gonna
see
the
third
pattern
here.
The
github's
orders
awakened.
We
already
see
what
happens
when
we
have
to
define
a
single
application
request.
We
go
to
Diego
CD,
we
Define
what
we
wanted
to
get
repository,
but
what
happened
when
we
need
to
scale
that
this
up
to
thousand
different
related
applications.
We're
gonna
have
a
single
definition
for
each
of
them,
because
managing
that
or
sending
them
to
the
operations
teams
will
make
them
mad.
It's
possible.
C
It's
going
to
reduce
or
increase
retention
policy
of
the
employees.
So
the
question
here
actually
writes
what
about
deploying
multiple
related
applications
at
once,
so
we
don't
want
to
end
the
day
at
like
this
guy.
We
just
handling
the
different
files
onto
just
trying
to
okay,
where,
when
I
put
the
configuration
for
that
article
CD
file,
this
is
intended
for
a
specific
cluster
this
for
another
one.
This
is
almost
impossible.
No
one
wants
to
do
to
deal
with
that.
C
C
It
allows
us
to
define
a
root,
Argo
CD
application
that
will
itself
Define
others,
article
CD
application
belonging
to
the
same
one,
the
road
apps,
the
argosity
root
application
points
to
a
folder
in
Gate
it
where
you
have
other
files
where
you
have
other
files
where
you
are
defined
in
the
article
CDA
plans
or
the
components
that
belongs
to
each
application.
That
doesn't
mean
you
don't
need
to
define
the
rest
of
the
application,
but
Argo
CD
when
it
comes
to
deploy.
You
apply
the
root
application
and
it
will
be
orchestrating
the
rest
of
the
components.
C
C
We
go
back
to
the
dashboard
and
we
filter
in
with
just
to
remove
the
rest
of
the
application
that
does
not
belong
to
this
app.
So,
as
you
can
see
here,
we
have
a
bunch
of
different
alcohol
CD
applications,
but
we
just
default.
We
just
deployed
the
root
Argo
CD
application
is
the
one
that
you
see
into
the
top
left
corner.
C
So
if
we
go
to
the
root
application,
we
can
see
that
is
the
root
application,
the
root
article
CD
application
and
the
application
you
see
on
the
right.
The
alcohol
City
applications
you
see
on
the
right
belongs
to
the
same
rule
one.
So
if
you
see
on
the
details,
you
can
see
the
path
and
the
path
is
pointing
to
the
different
components.
C
If
you
go
there,
it
is
pointing
the
to
the
repository
where
you
can
see
the
rest
of
the
definitions,
the
yaml
definition
of
the
rest
of
the
application
belonging
to
the
same
one,
but
you
don't
deploy
these
apps.
You
deploy
the
root,
argosity
applications
so
you're
back
there,
and
you
see
some
of
the
details
that
you
can
see
on
the
application.
C
Let's
trust
on
the
Wi-Fi
thanks
God,
so
you
can
see
here
the
Argo,
the
Argo
CD
application.
This
is
one
of
the
child
applications
belonging
to
the
same
the
the
same
route
or
parent
application.
As
you
can
see,
it's
an
application,
as
always
where
you
can
see
some
of
the
Ripple
URL.
So
you
can
see
the
details
and
everything
is
working
I
suspected,
but
you
just
deployed
the
route.
They
are
going
to
say
the
application,
that
is
the
app
of
apps.
B
Apps
all
right,
then
so
I
have
a
question:
do
I
need
to
Define
each
argosity
application
in
this
pattern?
Is
there
any
way
better
to
manage
our
application
at
scale,
because
we
saw
just
a
bunch
of
application?
But
what?
If
you
need
to
manage
hundreds
of
different
microservices
and
you
need
to
deploy
it,
and
you
need
to
also
orchestrate,
for
example,
development,
staging
or
production
applications,
so
we
introduce
August
the
application
sets
with
these
application.
Sets
that
isn't
specific
for
Arc
CD.
B
You
can
Target
multiple
kubernetes
clusters
and
also
you
can,
with
a
single,
manifest
kubernetes,
manifest
that
we
saw
you
can
deploy
multiple
applications
from
one
to
multiple
kit.
The
broad
processor
is
improving
this
support
of
the
mono
repo,
so
we
can
have
just
one
repo
one
git
repo
and
within
you
can
Define.
B
For
example,
one
folder
structuring
your
different
development
staging
and
production
objects
and
kubernetes
manifests
as
well
and
within
this
multi-tenant
clustering,
you
can
improve
the
ability
of
individual
cluster
tenants
to
deploy
different
applications
controlling
your
different
environments
that
you
wanted
to
Target
as
well,
using
that
we
are
using
the
generators.
So
we
have
four
type
of
generators
and
we
will
focus
in
this
demo
in
t.
That
is
the
key
generator
that
will
point
to
one
specific
git
repository
with
this
folder
and
also
you
can
use
other
generators
in
this
email.
B
So
we
will
demonstrate
managing
this
GitHub
application.scale.
We
prepared
default
demo
and
so
far
so
good,
trusting
the
hotspot
and
living
in
the
edge
and
we
will
deploy
Dev
staging
and
production
environment
with
a
single
argosity
obligation
set.
So
if
we
go
again
to
the
applications,
we
remove
the
filter,
we
saw
a
lot
of
different
things
and
we
just
go
to
the
pattern.
B
For
in
this
pattern,
four,
we
will
apply
this
argosity
application
sets
and
with
this
application
set,
we
see
that
if
we
filter
with
different
projects
that
we
have,
we
have
the
different
staging
projects.
So
these
staging
projects
are
the
different
argosity
application
sets
that
we
Define
it.
These
application
sets
are
pointing
out
to
one
specific
generator
and
we
use
sticky
generator.
So
you
can
Define
the
different
directories
and
you
can
put
whatever
you
want
inside
that
will
recognize
automatically
defining
inside
of
this.
B
If
you
put,
for
example,
more
applications
will
pop
up
here
and
will
appear
without
the
need
of
defining
every
single
object.
Every
single
kubernetes
manifest
just
popping
up
right
now
and
if
we
add,
for
example,
another
folder
will
sync
and
will
have
so
we
are
structuring.
We
are
defining
everything
that
is
here,
so
we
have
this
also
for
prod
and
everything
it's
right.
So
so
far
so
good
and
we
have
another
type
of
generation,
we
focus
just
in
one
cluster.
But
what,
if
you
want
to
deploy
it
in
multiple
cluster?
B
Obviously
they
can
also
Define
with
using
the
cluster
generator
that
automatically
generates
these
cluster
parameters.
If
you
have
to
your
credentials,
you
can
Target
with
one
signal
argosity
instance
multiple
different
kubernetes
cluster,
and
you
can
have,
for
example,
inside
of
your
argosity
different
kubernetes
clusters,
manners
that
could
be
within
or
distributed
across
different
environments,
and
therefore
you
can
have
also
this
generator
with
these
clusters,
and
you
can
use
this
in
order
to
deploy
your
different
environments.
B
Your
different
development
environments,
staging
that
are
you
defining
in
one
single
repo
and
using
these
generators,
pointing
and
deploying
with
one
click
your
entire
infrastructure,
your
entire
environment,
across
all
of
these
kubernetes
clusters.
So
you
have
a
lot
of
file
for
using
that
generating
as
well.
C
C
We
have
different
branches,
different
branches,
pointing
to
a
different
environments,
the
production
environment,
the
staging
and
the
QA,
and
when
we
want
to
move
some
changes,
we
just
promoting
the
the
the
changes
just
merging
one
branch
to
another
or
using
any
gate
strategy
base.
This
is
not
what
we
want
to
do
during
this
this
demo,
so
we
need
to
move
out
because
it
will
require
to
have
multiple
branches,
multiple
files
and
it's
going
to
be
complex
to
handle
when
it
comes
to
Edge
architectures.
C
So
if
you
see
at
the
at
the
files
here,
okay,
we
have
the
button
says
we
have
a
bunch
of
different
base
files
and
then
we
have
the
ends
and
the
variants,
and
we
have
some
specific
extra
settings
that
we
are
adding
for
each
of
the
environments.
If
we
go
to
the
customize,
we
are
going
to
see
the
base
file.
C
Some
of
the
resource
are
only
pointing
to
the
base
files
with
the
different
components
which
is
belonging
to
the
variance
in
this
case
for
the
Europe
and
the
patches
strategic
match
that
we
are
going
to
use
for
both
file
deployments
and
the
version,
because
these
two
are
relevant
to
promoting
the
content
from
one
to
another.
So
please,
thank
you.
C
C
We
are
applying
the
different,
the
different
extra
settings
that
we
are
going
to
add
in
depending
of
the
of
the
stage
we
have
so
two
different
scenarios.
How
are
we
going
to
promote
application
version
from
Dev
to
a
staging
environment
in
the
US?
So
we
are
not
going
to
move
that
from
the
variance
just
copying
the
files
into
the
repository.
We
are
copying
the
files,
the
files
version.yaml
from
the
dev
GPU
into
the
Italian
Us.
C
C
Once
we
have
copied
that
we
have
seen,
we
can
see
the
the
version
on
the
production
is
still
the
one,
because
the
changes
that
we
are
validated
into
the
previous
environment
will
be
push
it
into
the
next
one
into
the
next
environment,
to
the
it
will
be
promoted
into
the
into
the
other
environment.
So
everything
that
is
validated
in
the
previous
environment
will
be
pushed
to
the
production
or
to
other
environments.
So
you
will
lose
the
control,
even
if
you
are,
if
you
are
using
this
scenario
so
time
for
the
Q
a
so.
B
B
B
For
that
reason,
we
want
to
avoid
it
because
we
suffered
that
in
the
past,
and
for
that
specifically,
we
wanted
to
just
go
in
with
a
better
way
in
order
to
just
copy
one
single
file
pointing
out,
and
you
can
just
go
and
roll
back.
It's
going
to
one
specific,
commit
avoiding
pain
more
in
production
and
this
calls
into
a.m
in
the
morning.
So
a
series
yeah.
B
E
B
That's
a
very
interesting
question
because
you
need
to,
for
example,
Define
the
promotions,
and
you
can
also
use
this
p-request
in
order
to
at
least
pull
requests.
So
we
did
just
copying
it,
but
you
can
also
demonstrate
it
and
you
can
put
pull
requests
and
several
reviewers
in
order
to
not
mess
up
with
different
things.
So
is
it
just
a
demo?
Don't
do
it
in
production,
so
just
put
a
pull
request.
Some
reviewers
some
linking
and
you
go
to
all,
and
you
have
also
the
rollback.
C
Just
remember
that
rolling
back,
it's
also
a
feature
available
in
Argo
CD.
So
if
you
want
to
roll
back,
a
commit
is
just
a
point
on
time
for
my
application.
So
if
you
want
to
roll
back,
you
can
always
go
back
on
the
commit
on
the
git
or
you
can
using
or
fixing
something
into
the
article
CD,
just
to
make
sure
that
you
have
the
right
of
the
right
version
of
the
application
running
into
the
previous
stage.
F
Questions
hi
hello
in
the
pattern:
three,
it
explained
about
the
apps
of
apps,
okay,
so
let's
say
that
you're
allowed
a
new
version
of
your
app
and
you
have
tested
that
in
QA
environment
and
depth.
It
works.
But
for
some
reason,
when
you
ship
to
production,
you
have
a
bug
so
either
way
that
I
can
detect
that
before
going
to
prod
I'm,
not
doing
rollback
but
just
testing
it
before
just
switching
the
traffic
or
just.
G
So,
usually
in
in
an
environment,
we
try
to
create
artifacts
through
pipelines.
Okay,
the
artifacts
are
usually
stored
in
a
repository,
so
I'm
curious.
How
do
you
make
the
connection
between
a
new
artifact
and
your
automated
deployment?
So
if
you
have
version
one
and
you
create
a
new
artifact
version
too?
Okay,
how
do
you
want
this
process
to
be
automated
all
the
way
into
your
github's
repository
without
automating,
the
autocommit
yeah.
B
It's
who
controls
the
automation?
Isn't
it
yeah?
It's
a
chicken
and
egg.
So
it's
not
easy.
We
try
to
simplify
that
and
we
try
to
do
it
at
least
not
doing
the
big
bang.
So
if
you
see
here-
and
it's
messing
with
me-
the
Wi-Fi
okay,
the
different
Dev
environments,
you
can
Define
as
well
the
different
directories
that
you
can,
but
you
can
narrow
as
well.
You
can
deploy
just
a
single
specific
application
and
test
it,
and
therefore
you
can
increase
this
automation.
It's
not
a
big
bang.
B
It's
just
trying
to
make
the
things
that
works
first
get
a
bit
simple
first
and
then
you
can
automate
a
little
bit
more.
This
is
like
patterns
that
we
show
we
suffered.
So
if
we
are
starting,
this
application
set.
Can
save
you
a
lot
of
time,
but
you
need
to
take
care
with
the
automation
as
well.
All
right,
then,
this
one
because
we
don't
want
to
eat
I
mean
we're
on
time,
we're
from
Spain.
C
D
B
And
that's
exactly
that
you
can
do
with
this
much
of
generators.
You
have
different
generators
that
you
can
deploy.
So
you
have
these
generators
that
you
can
apply
that
specific
pattern
and
you
can
Define
these
specific
application
that
you
want.
Instead
of
doing
this
big
band
narrowing
and
doing
that,
that's
the
best
thing
around
generator
that
you
have
this
flexibility
in
order
to
scale,
and
you
have,
for
example,
this
cluster
generator
and
you
can
apply
both.
So
you
have
this
mix
and
match
using
the
Matrix
generation
that
combines
the
different
generated.
C
The
generators
will
actually
allows
mostly
or
most
of
them,
definitions
to
be
flexible
because
it,
depending
of
how
you
want
to
deploy
your
application
or
what
is
the
strategy
that
you
want
to
apply
to
the
environment?
You
will
be
able
to
see
how
many
generators
that
you
need
to
use.
Maybe
you
have
just
a
single
repository.
Maybe
you
have
more
than
one
cluster
that
you
want
to
add,
and
maybe
that's
not
applicable
for
for
most
of
the
Clusters,
so
you
can
add
that
kind
of
flexibility
specifically
for
Edge
all
right,
then.
H
B
B
You
can
use
still
secrets
and
you
can
Define
it
also
inside
with
Lua,
and
try
to
think,
because
this
is
like
changing
and
you
need
to
be
and
tell
argosity
that
you
are
using
these
seal
secrets
that
you
can
Define
in
Lua
as
well.
So
there
are
some
bunch
of
different
strategies,
but
this
could
be
like
another
talk
and
could
be
fun
so
so
far,
so
good
thanks
for
listening
and
yeah
live
demos,
so
we
are
living
in
the
edge
thanks
for
attending.
Thank
you.
So
much.