►
From YouTube: GitOps for multicloud applications
Description
GitOps for multicloud applications
This is a presentation by @theWilliamChia and @cesar_saavedr about how GitLab supports GitOps for multicloud applications. It first covers the concepts and then follows with demos for push-based and pull-based CI/CD modalities for GitOps. No matter what your approach is for GitOps, we have you covered!
Get in touch with Sales: http://bit.ly/2IygR7z
A
A
So
as
you
look
at
this,
we
all
know
the
landscape
of
software.
Development
is
changing.
When
we
look
back
on
on
how
software
development
has
evolved,
we
can
remember
the
days
of
of
waterfall
development.
Maybe
some
of
us
in
large
enterprises
are
even
still
doing
some
of
this,
where
we're
delivering
software
like
it's
hardware,
but
it
causes
a
lot
of
challenges.
A
Innovations
like
agile
and
devops
have
allowed
us
to
move
a
lot
faster,
while
also
being
a
lot
safer,
deploying
with
less
risk
more
frequently
being
able
to
easily
roll
back
changes,
and
the
latest
evolution
in
cloud-native
applications
is
about
dynamic
environments,
those
that
scale
up
and
down
automatically
based
on
load
where
things
can
shift
and
change.
Different
users
logged
into
the
same
application
can
have
a
completely
different
experience
based
on
the
region
or
what
they've
interacted
with
and
in
order
to
manage
all
this
complexity.
A
We
need
an
infrastructure,
automation,
practice,
that's
able
to
keep
up
with
all
of
it
and
that's
where
get
ops
comes
in
in
this
talk
today,
we're
going
to
tell
you
what
git
ops
is.
Why
get
ops
is
important
and
we'll
give
you
a
hands-on
demo,
so
you
can
see
step-by-step
how
you
can
do
get
ops
yourself
to
kick
it
off.
A
What
is
devops
well,
what
is
gitops
so
gitops
is
an
operational
framework
that
takes
devops
best
practices,
things
we've
used
for
application
development
for
years,
like
version
control,
collaboration,
compliance
and
ci
cd,
and
it
applies
them
to
infrastructure.
Automation
in
a
sense,
get
ops
is
going
to
have
three
major
components.
A
This
is
going
to
be
infrastructurist
code.
Merge
requests
are
what
we
call
mrs
and
some
types
of
git
platforms.
They
call
them
a
pr
pull
request
at
gitlab.
We
call
it
a
merge
request
and
the
mr
that's
going
to
be
our
agent
of
change
and
automation,
we're
going
to
use
ci
cd,
but
essentially
we
want
to
automate
our
changes.
When
you
combine
these
together,
you
get
the
practice
of
get
ops.
A
A
Of
course,
as
I
mentioned,
this
is
stored
in
git
version
control,
and
so
all
of
the
get
tooling
standard
practice
that
engineers
and
developers
are
familiar
with
using
git
and
all
of
your
get
tooling.
You
get
to
leverage
that
with
your
operations
when
you're
doing
infrastructure
as
code,
but
just
having
your
infrastructure
stored
in
a
git
repo,
that's
not
enough
really
to
get
the
power
of
get
ops
as
a
as
a
collaboration.
A
You
need
to
be
using
the
merge
request
as
your
agent
of
change
and
the
way
this
works
is
the
merge
request
of
the
pull
request
serves
as
a
gate
for
any
changes
that
go
out,
so
you
would
have
a
main
branch
that
is
tied
to
let's
say
an
environment.
This
could
be
a.
We
could
call
the
production
branch,
the
main
branch,
the
master
branch,
the
trunk
branch
or
it
could
be
related
to
let's
say,
staging
environment
or
any
other
type
of
development
or
testing.
A
Whatever
environment
you
have,
but
that
branch
represents
the
state
of
that
environment
and
whenever
you
want
to
make
changes
to
it,
you
create
a
new
feature
branch.
The
same
way,
an
app
dev
team
would
for
a
software
development
feature,
but
in
this
case
it's
a
proposal
for
application
changes,
and
that
way
you
can
collaborate
on
that
branch
and
when
it
gets
merged
back
in
to
that
main
or
that
trunk
branch
that
enacts
the
change
in
that
environment.
A
What
this
allows
you
to
do
is
through
that
merge
request.
You
can
do
code
review
collaboration
approvals,
manage
all
of
your
compliance,
so
a
lot
of
powerful
elements,
these
collaboration
capabilities
to
be
able
to
do
code,
review
collaborate
between
developers,
security,
practitioners,
operations,
engineers,
that's
what's
really
powerful
about
get
ops
and
certainly
important.
Is
this
automated
reconciliation
or
cicd
we're
going
to
use
cicd
as
a
type
of
reconciliation
loop?
A
You
can
imagine
that
anytime,
the
state
of
the
environment
is
out
of
sync,
with
what
we've
defined
as
our
declarative
state
and
our
git
repository.
We
want
that
to
be
matched
up,
so
the
cid
cd
can
run.
It
can
run
every
time.
Let's
say
you,
you
merge
to
master,
you
can
run
on
a
timer,
and
what
this
allows
you
to
do
is
allows
you
to
tackle
things
like
configuration
drift.
A
You
know,
unfortunately,
when
sometimes
you
configure
an
environment
and
then
all
of
a
sudden
for
whatever
purpose,
whether
it's
manual
or
there's
errors,
and
it
drifts
away
from
your
configuration
the
next
time
that
ci
cd
runs
next
time
that
automation
loop
runs.
It
goes
and
it
gets
the
latest
state
the
source
of
truth
from
your
git
repo
and
it
updates.
A
So
the
main
core
component
here
is
that
changes
are
implemented
automatically
and
we
we
are
no
longer
making
manual
changes
for
infrastructure,
but
all
of
the
state
of
the
infrastructure
stored
in
git
and
all
those
changes
are
applied
by
our
automation
tool
by
our
ci
cd,
so
that
flow
for
a
git
ops
flow.
It
ends
up
looking
very
similar
to
a
software
development
flow.
You
would
create
an
issue.
A
We
need
to
expand
the
number
of
nodes
in
our
node
pool
or
we
need
to
lessen
resources
for
a
particular
service
because
it
doesn't
get
as
much
traffic
and
we
want
to
save
on
cost
or
we
need
to
investigate
because
something
went
down
based
on
that
issue
and
defined
problem
that
we
want
to
go
tackle.
You
create
a
merge
request
with
a
branch
you
run
that
automation
and
then,
when
it's
merged
back
into
master,
you
have
your
running
running
production
environment.
A
So
some
folks
might
ask
well.
This
sounds
just
a
lot
like
infrastructure
as
code.
What's
the
difference?
Well,
with
infrastructure,
as
code
code
may
or
may
not
be
version
controlled
right,
you
can
take
a
yaml
file
or
you
can
have
a
text-based
definition
in
linux.
We've
been
using
dot
com
files
for
a
long
time
and
that
dot
com
file
or
that
configuration
file
that
can
live
in.
A
You
could
call
that
infrastructure
as
code,
but
that's
not
git
ops,
you're,
not
you're,
not
storing
that
code
and
get
repository
you're,
not
using
all
the
power
of
get
version
control
to
do
things
like
roll
back
right
to
roll
forward.
This
is
particularly
powerful.
Let's
say
something
goes
wrong
and
in
the
middle
of
a
firefight
you
just
need
to
get
that
infrastructure
up
and
going
as
soon
as
possible,
but
then
later
on,
you
want
to
do
some
introspection
and
you
want
to
do
some
forensics
and
figure
out
what
was
it
that
went
wrong?
A
Well,
if
you
just
have
the
the
code
stored
in
a
text
file
somewhere,
it's
been
updated
and
the
state
in
the
history
has
been
lost,
but
if
you're
doing
git
ops
and
stored
in
git,
you
can
actually
see
what
the
state
of
that
infrastructure
was
before
you
made
the
changes,
you
could
spin
up
another
environment
and
do
your
forensics
and
introspection
there
same
thing
with
infrastructure's
code.
Those
changes
may
or
may
not
go
through
any
type
of
code
review
or
approval
process,
but
with
git
ops.
We
use
that
merge
request
as
the
change
agent.
A
This
is
so
much
faster
and
so
much
more
automated
than
having
your
change
management
meeting
right
rather
than
having
to
sit
around
and
discuss
what
goes
in
and
what
goes
on.
What's
on
the
calendar,
everything
is
just
automated.
You
have
your
automated
tests
a
lot
of
times.
The
security
approvals
can
be
automated,
so
you
can
still
have
compliance,
but
it's
super
lightweight
and
it's
automated
when
you're
doing
git,
ops
and
finally,
as
as
I've
kind
of
already
said,
you
know,
changes
could
be
applied
in
many
ways.
A
If
you're
just
doing
infrastructures
code,
you
get
ssh
to
the
server
they
may
or
may
not
be
automated,
but
with
when
we're
doing
git
ops,
we're
absolutely
automating
the
infrastructure.
So
in
a
nutshell,
you
could
say
that
git
ops
is
infrastructure.
Is
code
done
right
if
you're
doing
it
with
the
best
practices,
we're
going
to
call
that
git
ops?
A
So
why
is
get
ops
important?
Well,
you
get
a
lot
of
benefits,
self-documenting
environments.
The
code
is
there.
You
can
now
share
knowledge
amongst
your
teams
when
somebody's
clicking
in
a
gui.
How
do
they
tell
other
people
what
they
did
or
how
they
did
it?
And,
as
I
mentioned,
you
want
to
duplicate
that
environment,
let's
say
to
spin
up
another
thing
or
to
do
forensics
after
a
firefight,
as
I
mentioned
before,
you
get
these
version
control
benefits
the
ability
to
roll
back
and
roll
forward.
A
A
So
now
that,
with
the
new
version
of
the
application,
we
can
have
a
more
lightweight
infrastructure
running
that
same
surface,
it
doesn't
require
as
many
resources
but
all
of
a
sudden,
we
found
out
that
there
was
a
bug
in
that
new
version
of
the
code,
so
we
actually
had
to
roll
back
the
application
of
the
previous
version
that
you
know
didn't
have
this
really
terrible
customer
facing
bug,
but
it
didn't
have
the
memory
leak.
It
wasn't
as
efficient.
A
Well,
if
you
don't
have
the
ability
to
roll
back
your
infrastructure
at
the
same
time
and
you
deploy
that
new
application,
where
there's
not
enough
resources,
now
you've
taken
down
you're
gonna
crash
the
whole
environment.
So
this
ability
to
version
your
infrastructure
alongside
of
your
application
and
have
those
walk
along
depending
on
the
needs
of
each.
It's
really
powerful
helps
with
misconfigured
misconfiguration
of
the
infrastructure,
and
this
can
really
really
help
your
mean
time
to
recovery
when
things
go
down
to
having
it
in
the
version
control.
A
Sometimes
it
just
being
able
to
quickly
roll
back
to
the
last
known,
good,
config
last
known,
good
config,
and
we
can
roll
back
and
get
up
and
going
quickly,
and
then
we
can
go
back
and
try
to
figure
out.
What's
going
on,
we
have
these
automation
benefits.
We
can
deploy
faster,
more
often
with
less
risk.
I've
already
talked
a
little
bit
about
configuration,
drift,
a
key
benefit
of
get
ops
and
these
security
and
compliance
benefits,
especially
with
a
lot
of
enterprises
or
a
lot
of
businesses
and
organizations
that
are
in
regulated
industries.
A
You
need
to
have
a
set
of
compliance
policies
that
you
follow,
and
this
can
mean
permissions
to
your
particular
environment.
This
is
compliance
and
collaboration,
so
you
get
you
you
can
have
both.
Sometimes
you
have
only
compliance
where
you
can
lock
everything
down,
and
only
a
few
people
have
access
to
the
infrastructure
tools
and
can
update
or
make
infrastructure
changes
and
you're
constrained
by
your
compliance,
but
with
get
ops,
you're
unleashed
and
you're
compliant.
Anybody
can
make
a
change
propose
a
change
via
an
mr,
because
it's
just
code
right.
Anybody
in
the
org
any
developer.
A
You
can
use
all
of
the
permissioning
of
git.
You
get
that
for
free.
In
effect,
you
have
you've
changed
process
compliance
as
well,
because
you
have
an
audit
log
of
all
your
changes
in
your
git
repo,
really
really
powerful.
So
with
that,
we've
talked
about
what
git
ops
is
at
a
high
level.
Why
git
apps
is
important
at
this
point.
I
hope
you
are
excited
to
see
a
hands-on
demo
and
I
would
like
to
pass
it
on
to
my
colleague
cesar.
Thank
you
thank.
B
You,
william,
my
name,
is
cecilia
savedra
and
I'm
a
technical
marketing
manager
at
gitlab.
Here
you
can
see
my
social
handles.
Please
feel
free
to
reach
out
to
me
via
any
of
them,
so
I'm
going
to
be
covering
first,
a
push-based
github's
demo
for
this
csd
component,
which
we've
been
calling
agentless
and
then
later
on,
we'll
do
the
pull-based.
B
B
B
There
is
a
set
of
projects
under
the
infrastructure
group
and
another
set
of
projects
under
the
application
application
directory-
and
this
is
a
separation
of
duties
and
concerns
within
this
project.
Then
it
optimizes
the
work
and
collaboration
among
the
stakeholders.
There
will
be
working
towards
a
solution
within
the
mr,
so
let's
go
to
sasha's
issue.
I
pre-created
already
one.
It's
about
the
her
needing
the
to
have
a
database
provision
that
sasha
created
it.
He
she
assigned
it
actually
to
sydney.
B
The
database
administrator
and
here
are
the
details
of
the
requirements
of
this
request
or
the
details
of
the
request
and
notice
also
that
this
is
already
in
sydney's
work,
list
or
board
of
to-do
items.
So
let's
go
here
to
sydney
and
if
she,
when
she
opens
her
boards,
you'll
see
that
the
item
is
already
in
her
to-do
board.
B
So
let's
go
in
to
the
issue
itself
and
then
what
sydney
is
going
to
do
here
is
she's
going
to
read
over
the
problem
and
she's
going
to
start
she's
going
to
start
a
merch
request.
Other
competing
solutions.
Call
this
pr
and
the
merch
request
is
where
all
the
collaboration
is
gonna
happen
among
the
stakeholders
here,
she's
gonna,
loop,
devin
he's
the
devops
engineer
just
to
make
sure
that
everything
is
going
to
be
okay
with
the
infrastructure.
B
So
now,
let's
switch
to
sasha's
console
and
she's,
going
to
refresh
her
page
and
notice
that
there's
been
some
activity
in
the
mr,
so
she's
going
to
go
into
it.
She's
going
to
notice
that
there
is
a
terraform
plan
that
has
been
run
as
part
of
the
review
step,
so
she's
going
to
go
ahead
and
expand
that
artifact
and
she's
going
to
click
on
the
view.
The
full
log-
and
here
she
checks
the
terraform
plan
output
and
ensures
that
everything
is
good
for
the
creation
of
the
database,
which
is
right.
B
B
B
And
now
she's
going
to
go
into
the
changes
now.
This
shows
all
the
changes
that
have
happened
to
the
infrastructures
code.
In
this
case
it's
a
terraform,
but
it
could
be.
You
know,
cloud
formation
or
any
other
type
of
technology
to
do
this,
and
here
she's
going
to
add
a
comment,
an
inline
suggestion
actually
for
increasing
the
allocated
storage
from
five
gigabytes
to
10.
B
Again
this
is
this
is
showing
how
easy
it
is
to
collaborate
within
an
mr
all
right.
So,
let's
switch
to
devin.
This
is
devon's
console
he's
the
devil's
devops
engineer
that
oversees
the
kubernetes
clusters,
among
other
things,
and
he's
going
to
navigate
to
the
aws
project,
he's
been
looped
into
the
mr
remember,
but
sydney
she's
going
to
go
into
the
mr.
B
B
B
B
Sydney's,
going
back
to
the
mr
now
she's
going
to
start
reviewing
all
the
result,
threats
that
have
been
applied
to
the
mr
from
other
stakeholders,
so
she's
going
to
go
ahead
and
apply
the
inline
suggestion
from
devin
and
that's
with
a
click
up
a
click
of
a
button.
She
does
that
same
thing
with
the
allocated
storage,
inline
suggestion
from
sasha
she's,
going
to
click
on,
apply
the
suggestion
and
that
resolves
the
thread
automatically.
B
Review
devin's
a
comment
about
the
username
parameterizing,
the
username
and
making
a
mass
variable
out
of
the
password
so
before
she
can
resolve
those
two
comments.
She's
gonna
go
ahead
and
go
to
the
actual
code
and
open
it
in
the
web,
ide
and
she's
going
to
go
ahead
and
make
the
changes
that
fulfill
or
resolve
the
comments
from
devon
about
the
username
and
password.
What
she's
gonna
do
is
she's
going
to
parametrize
both
of
them
and
then
she's
gonna
go
ahead
and
commit
the
changes
to
the.
B
B
So
now,
since
sydney
is
part
of
the
code
owner's
file,
she
needs
to
approve
dmr,
which
she
does
now
and
code
owners
outlines
the
exact
users
and
groups
that
own
certain
files
and
paths
in
their
repo
and
it
streams
lines.
The
merge
request
approval
process
now
we're
going
back
to
sasha's,
console
and
dmr
requires
two
approvers,
so
sash
is
going
to
approve
dmr
as
well.
B
And
with
this
now
she
can
mark
the
mr
as
ready
before
she
can
merge
it
now
notice.
There
are
so
many
result
threads
and
if
you
would
like
the
merge
to
be
dependent
on
all
the
threads
being
resolved,
you
can
set
that
up
also
in
gitlab,
but
in
this
case
I
don't
have
to
set
that
I
don't
have
that
set
up,
so
I
can
merge
with
our
result
threads.
B
B
With
stages
that
will
take
that
basically
will
apply
all
the
infrastructure
changes
in
this
case
the
creation
of
a
database,
a
mysql
database
out
to
production.
You
can
see
the
pipeline
there
has
been
launched
and
this
pipeline
has.
You
know
many
stages
that
will
take.
You
know:
it'll,
validate
the
configuration
file
plan
and
then
apply
to
production.
B
B
B
It's
going
to
fire
off
another
pipeline
here.
You've
seen
that
before
it's
going
to
do
the
validate
plan,
the
plan
and
the
apply,
and
once
it
completes,
you
should
see
a
second
instance
that
have
been
deployed
to
the
cluster
and
there
you
go
now.
We
have
two
nodes
in
the
cluster
up
and
running
on
aws.
B
B
B
B
B
B
Now,
let's
go
to
the
applications
group
and
we
have
a
python
application.
There
microservice-
and
let
me
show
you,
you
know
how
it's
running
on
gke.
This
is
a
second
cloud,
so
we
go
to
environments
dashboard.
We
can
see
that
they,
there
are
two
environments
running
for
that
microservice
tas
default,
which
is
the
dynamic
security
application
testing
environment.
B
B
Although
you
can
use
push-based
ci
cd
with
git
ups,
you
also
have
the
pool
based
approach
to
ci
cd,
and
why
is
this
needed
so
many
organizations?
You
know
they
cannot
open
their
clusters
to
the
internet,
so
this
approach
of
pool
based
is
good.
For
them.
Here
is
a
high-level
architecture
of
our
solution.
B
The
this
is
a
high-level
relationship,
diagram
of
the
agent
on
the
server
side
process-
and
this
is
a
workflow
of
you-
know
the
whole
process
of
the
agent
checking
every
so
many
seconds
with
the
server
to
see.
If
there
are
any
updates
to
the
configuration
of
the
project.
We
use
the
github's
engine
open
source
project
for
this
implementation
and
the
you
know
the
argo
cd
folks
and
the
argoflex
folks
came
together
and
they
are
now
collaborating
in
this
new
github's
engine
project.
B
And
we're
going
to
create
two
new
projects,
one
of
them
the
first
one
is
going
to
be
what
we
call
the
getups
project,
and
this
is
the
project
that
is
going
to
be
observed
by
the
kubernetes
agent
server
running
on
gitlab,
and
it's
going
to
be
observed
for
changes
in
configurations
of
input
of
the
infrastructure
in
this
github
project.
We're
going
to
create
a
file
called
manifest
dot,
yaml
and
we're
gonna.
B
We
also
need
to
create
a
directory
called
under
dot,
gitlab,
slash
agents
and
the
third
directory.
There's
is
the
name
of
the
actual
agent
that
is
going
to
be
running
in
the
in
the
grenades
cluster
called
in
this
case.
It's
called
agent1
and
in
here
we're
going
to
give
it
a
config,
the
yaml,
with
the
configuration
of
that
agent,
which
we
can
copy
from
the
documentation,
and
this
config
configuration
yamo
actually
is
telling
the
agent.
B
B
B
B
B
B
B
It's
going
to
be
deployed
under
under
the
same
namespace
of
gitlab
agent
and
that's
nginx
right
there
and
there
are
two
replicas.
So
once
we
save
this
and
it's
committed
to
the
main
line,
the
agent
will
detect
that
update
and
then
it'll
communicate
this
to
the
the
server.
That's
gonna
communicate
this
to
the
agent.
B
The
different
events
that
took
place
versus
listening
on
five
port
5005
members,
websockets
that
that
the
server
agent
and
the
agent
itself
are
talking
on,
and
here
it's
detecting
the
agent's
kubernetes
agent
server
is
actually
detecting
modifications
to
the
getups
project.
That
is
the
one
being
modified.
B
And
this
is
the
agent
log
that
is
talking
to
the
cass,
which
is
running
on
the
server
side,
and
this
is
this:
is
the
agent
running
on
the
kubernetes
itself
cluster
itself?
This
is
in
the
case.
You
know
where
organizations
cannot
make
their
clusters
available
on
the
internet.
This
agent
is
the
one
running
on
that
cluster.
B
Talking
to
this
to
the
cast
to
the
kubernetes
agent
server
running
on
gitlab,
the
cast
is
authenticating
it
and
then
informing
the
agent
of
any
updates
that
have
taken
place
on
the
on
the
gitlab
side,
and
then
the
agent
is
getting
those
updates
and
applying
them
to
to
the
cluster
on
which
it's
running
and
here's
the
log.
The
different
log
events
for
the
agent
itself,
that
is
running
on
the
kubernetes
cluster.
B
So
again,
you
know
this
is
a
demo
of
the
pool
based
ci
cd
used
in
githubs,
and
you
know
you
can
use
push
based
and
pull
base.
These
two
are
not,
you
know,
they're,
not
exclusive
of
each
other,
they're
actually
complementary.
So
you
can
use
them.
You
can
use
a
push-based
approach
with
pull-based
approach
together
in
combination.