►
From YouTube: Six Minute Video Explanation of The Two Major Definitions of GitOps and How Gitlab Does Both
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
You
can
see
the
ones
that
are
currently
scheduled
and
for
more
information,
a
syllabus
as
well
as
to
register
you
can
go
to
the
URL
on
the
screen
as
time
goes
on,
we'll
add
more
workshops
to
the
docket,
and
you
can
continue
to
visit
this
URL
to
keep
up
to
date
with,
what's
going
on.
I
hope
you
enjoy
this
explanation
all
right.
Let's
talk
about
how
gitlab
does
get
Ops
before
we
get
right
into
the
details
of
how
gitlab
does
it?
A
We
need
to
talk
about
the
fact
that
there's
been
two
major
definitions
of
what
git
Ops
is
that
have
evolved
in
the
industry
over
time.
So
we'll
talk
about
the
first
one
is
basically
the
idea
that
it's
a
kubernetes
thing,
so
we
have
a
new
concept
of
pull
CD
where
we
install
an
agent
inside
of
kubernetes
and
that
pulls
the
software
updates
on
onto
the
cluster.
A
Now
this
has
really
been
the
Forte
of
things
like
chef
and
puppet
in
the
past,
completely
separate
products,
but
now
with
the
git
Ops
approach,
we
integrate
that
right
into
the
standard
deployment
agent
and
then
finally,
the
main
focus
is
kubernetes
targets,
so
we
presume
that
this
is
all
running
on
kubernetes.
So
in
this
case
we
start
out
with
our
application
code.
A
In
a
repository,
we
use
a
continuous
integration
to
then
build
that
into
a
container,
so
we
have
got
that
container
set
up,
then
we
are
able
to
reference
it
in
a
manifest
which
is
also
stored
in
git.
Now
this
manifest
is
going
to
be
a
completely
rendered
manifest,
which
means
that
there
aren't
any
variables
in
it.
It
is
ready
to
read
plain
and
simple,
exactly
everything
that's
going
to
happen.
It
also
means
that
we
can
scan
it
and
check
it
out
and
make
sure
that
it
is
in
good
shape.
A
Then
we
have
an
agent
that
we
install
into
the
cluster,
and
this
agent
does
two
things.
First
of
all,
it
it
pulls
onto
the
cluster.
Now
we
can
also
insert
approvals
in
this
poll
operation.
If
we
wish
to
for
major
deployments,
then
the
second
mode
that
it
has
is
that
continuous
drift
management
and,
of
course,
in
this
mode,
it
just
directly
pulls
the
Manifest
and
reinforces
it.
This
way,
if
there's
any
tinkering
that
goes
on
in
production
or
other
environments,
it
is
brought
back
into
compliance
with
the
standard
configuration
relatively
quickly.
A
So
that's
an
example
of
what
get
Ops
defined
as
a
kind
of
a
kubernetes
thing.
Another
definition
of
it
is
that
our
source
code
management
system
would
be
the
same
system
that
builds
our
software
will
now
deploy
our
software.
It
easily
allows
for
push
CD.
It
also
uses
git,
merge
controls
in
order
to
control
deployment
approvals
and
then,
finally,
we
don't
really
have
any
restrictions
in
terms
of
what
targets
that
we
allow
for
this
situation.
A
So
we
start
again
with
our
code
repository
and
that
is
built
by
CI
and
then
within
CI.
We
have
some
sort
of
approval
process
for
doing
push
deployments.
The
push
deployments
can
then
go
to
basically
any
kind
of
infrastructure.
You
want
using
a
variety
of
techniques
within
that
push
CD
mechanism,
so
these
are
the
two
major
definitions
that
have
evolved
over
time.
Now,
how
does
git
lab
approach
this?
What
does
git
lab
do
in
order
to
Service
one
or
the
other
of
these
models?
A
So
let's
talk
a
little
bit
about
how
gitlab
is
doing
that
now
that
we
have
the
gitlab
agent
and
how
that
kind
of
changes.
The
mix
here
a
bit
first
of
all,
we
do
indeed
need
the
gitlab
runner
for
CI
notice
that
no
matter
what
you
use
for
git
Ops
deployment,
you
still
need
CI
get
Ops,
really
solves
the
CD
portion
of
the
problem.
The
really
nice
thing
about
having
added
the
agent
is
now
in
the
single
platform.
A
You
are
able
to
manage
both
your
CI
as
well
as
your
pulse
CD,
so
we
use
a
runner
4ci,
and
then
we
have
the
new
gitlab
agent,
which
runs
inside
the
cluster
that
gitlab
agent
is
able
to
accomplish
both
pull
CD
as
well
as
drift
management.
So
it's
able
to
give
us
all
those
services
and
provide
us
a
very
comparable
solution
for
the
kubernetes
definition
now
over
here
on
the
deploy
from
git
definition,
we
of
course
have
gitlab
CI
again
for
building
our
application,
and
then
we
have
a
gitlab
runner
for
CD
push.
A
Now,
we've
been
using
gitlab
runner
for
a
very
long
time
for
CD
push
in
the
past.
The
certificate
connection
method
has
required
that
your
kubernetes
cluster
have
its
API
control
plane
available
to
the
runner,
so
the
runner
could
reach
out
and
reach
into
the
cluster
through
that
not
a
big
deal,
if
you're
all
on
private
networking,
but
if
you're
trying
to
use
gitlab.com
well,
then
you'd
have
to
have
that
API
control
endpoint
on
the
internet,
so
that
gitlab
Runners,
if
you're
using
SAS
Runners,
could
service
it.
A
You
could
also
do
self-managed
runners
and
solve
this
problem
by
putting
your
runners
in
with
your
kubernetes
cluster,
but
in
any
case
customers
spoke
and
wanted.
This
part
also
to
be
more
secure.
So
when
we
add
the
gitlab
agent,
we
change
how
this
works.
Your
kubernetes,
API
control,
endpoint
no
longer
needs
to
be
of
available
to
the
runner.
Once
you
install
the
gitlab
agent,
it
is
able
to
establish
a
secure
connection
now,
technically,
it
doesn't
go
back
directly
to
the
runner.
A
So
one
of
the
really
cool
things
you
should
be
able
to
discern
from
this
is
even
though
we
are
retiring,
the
certificate
connection,
you
can
use
the
gitlab
agent
for
CD
push.
So
if
you're
not
really
at
a
point
where
you're
worrying
about
get
Ops
as
far
as
a
pull
technology,
it
doesn't
matter
to
you
or
it
doesn't
work
very
well
for
your
scenario.