►
From YouTube: GitLab Operator Demo - MVP
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
A
We
want
to
be
able
to
deploy,
configure
reconfigure
as
well
as
make
sure
that
all
of
the
components
work.
I
will
call
out,
as
documented
that
we
do
currently
have
it.
Defaultively
deploying
with
a
self-signed
certificate,
we're
working
through
a
couple
of
issues
with
cert
manager
inside
of
openshift-
that's
not
directly
under
our
control,
so
bear
with
us.
In
that
regard,
I
will
say
we
have,
though,
proven
out
that
you
can
indeed
deploy
with
your
own
certs,
and
everything
will
work
perfectly
fine
with
a
publicly
trusted
certificate.
B
Now
this
is
our
gitlab
operator
project,
and
so
what
I'm
going
to
do
is
open
up
the
doc
folder
here
in
a
new
tab.
This
is
our
documentation.
If
you
want
to
look
at
this
after
the
demo,
everything
from
standing
up
in
openshift
cluster
to
deploying
the
gitlab
operator
will
be
here
a
quick
note
right
now,
a
lot
of
our
project
code
and
documentation,
references
openshift,
but
the
ultimate
goal
is
to
be
able
to
support
deploying
this
gitlab
operator
on
openshift
as
well.
B
As
you
know,
just
raw
kubernetes
as
well
and
so
we'll
be
working
towards
that
as
time
goes
on,
so
I'm
going
to
start
is
installation.
The
first
process
technically
is
to
do
the
openshift
cluster
setup,
which
is
documented
here
effectively.
This
uses
some
open
shift
tooling
and
job
scripting
to
create
a
project
in
gcp
that
will
stand
up
some
instances
to
act
as
a
kubernetes
cluster
and
install
openshift
on
top
of
it.
B
That
will
give
you
a
running
cluster
as
well
as
a
domain
name
that
you
can
use
for
accessing
your
services,
so
we'll
skip
right
to
installation
as
I've
already
done
the
cluster
setup,
since
it
takes
about
45
minutes
or
so
so,
we'll
see.
The
next
portion
of
the
requirements
here
is
to
ins
clone
our
repository
and
a
quick
note.
This
process
is,
is
kind
of
just
for
our
mvp
early
days.
Installation
of
the
operator.
B
B
So
the
next
step
here
is
to
run
make
install
required
operators.
This
confirms
that
nginx
ingress
operator
insert
manager
installed
right
now.
Nginx
ingress
operator
is
not
leveraged
in
openshift
openshift
defaults
to
aj
proxy
and
automatically
converts
any
ingresses
we
create
to
routes,
and
so
those
routes
will
talk
directly
to
the
services
bypassing
engine
x
entirely.
B
B
B
B
So
we'll
see
here,
as
that
container
starts
to
run
we'll
check
the
logs.
What
it'll
do
is
start
up
and
elect
itself
a
leader,
so
it
can
be
the
one
to
manage
the
resources
in
this
namespace
and
it'll
just
start
up
and
wait
for
us
to
send
it
a
resource
like
a
gitlab
and
so
right.
Now
it's
just
sitting
waiting
the
last
step
here
is
that
we'll
actually
go
ahead
and
deploy
an
instance
of
gitlab.
B
B
So
before
I
do
that,
I
want
to
show
you
what
that
file
actually
looks
like
so,
if
you're
familiar
with
working
with
deployments
and
services,
this
manifest
will
look
very
similar.
You
can
see
the
kind
is
gitlab
and
then
under
the
spec
here,
we've
got
our
own
specifications
for
what
defines
a
gitlab
and
how
to
work
with
it
in
our
operator.
B
So
the
top
level
key
here
is
chart.
The
our
git
lab
helm
chart
kind
of
serves
as
the
the
heart
for
the
operator.
We
run
a
template
of
the
helm
chart
within
our
operator
and
then
can
deploy
and
upgrade
and
change
certain
resources
based
on
logic
that
we
can
program
into
the
operator
itself,
so
this
chart
version
will
determine
what
version
of
the
chart
to
use
in
the
template.
By
default,
we
ship
the
last
three
minor
patches,
patch
versions
of
the
gitlab
helm
chart
right
now.
B
The
latest
version
in
there
is
4.10.3
will
be
the
default.
An
important
one
is
global
host
domain.
This
is
also
important
when
deploying
the
the
raw
helm
chart.
This
tells
the
the
ingress
resources
which
hosts
to
specify
for
accessing
those
services
and
then
here's
some
others
that
we
use
in
ci
but
are
also
common
uses
in
case
you
want
to
use
a
custom
tls
certificate,
that's
available
as
well,
and
this
is
at
the
bottom-
is
just
a
temporary
fix
that
we're
making
in
the
upstream
helm
chart.
B
B
So
now
in
the
logs
you'll
see
that
the
operator
has
noticed
that
we
have
deployed
that
new
gitlab
resource,
so
it
says
that
it's
reconciling
gitlab
rendering
a
new
template
based
on
the
values
we
just
passed
it
you
can
see
here
it
takes
a
hash.
This
is
based
on
the
version
of
the
helm
chart
and
the
values
that
we
passed
to
it.
So
we
can
cache
it
templating.
The
home
chart
takes
a
little
bit
of
time.
So
if
the
values
in
the
version
haven't
changed,
we
just
keep
a
cache
for
that
template.
A
B
B
B
B
B
So
the
next
step
that
I
want
to
demo
is
that
the
operator
can
support
changes
to
the
resources.
So
I'm
going
to
do
is
come
back
to
the
example
of
the
gitlab
resources
that
we
were
looking
at
and,
as
you
can
see,
you
have
the
option
here
to
pass
in
passing
host
suffix,
just
like
the
helm
charts.
So
I'm
going
to
do
that.
The
host
suffix
is
a
good
demo
here,
because
it
touches
a
lot
of
resources
related
to
the
gitlab
release.
B
Alrighty,
so
all
of
the
pods
have
been
replaced
with
new
configuration.
We'll
do
is
go
back
to
the
ingresses
screen
and
see
that
our
url
has
changed
with
our
host
suffix,
which
is
great
so
we'll
copy
that
and
open
that
in
a
browser,
same
certificate
error,
so
go
ahead
and
tell
the
browser
is
okay
for
now
log.
In
again,.
B
And
we're
back
in
so
we
can
see
that
everything
has
updated
as
expected
was
we
changed
the
host
suffix,
and
this
will
go
for
any
changes
that
you
make
to
the
custom
resource.
Any
of
those
values
that
are
configurable
in
the
helm
chart
will
be
supported
in
that
gitlab
cr,
and
that
will
be
how
you
manage
the
gitlab
instance.
B
So
as
a
quick
recap,
what
we've
done
here
as
part
of
the
operator
project
is
create
a
golan
code
base
that
will
be
able
to
watch
for
custom
resources
and
use
the
configuration
defined
in
those
resources
to
ensure
a
certain
state.
What's
great
about
the
operator
specifically
compared
to
the
helm
chart
is
that
we
can
go
beyond
because
we're
using
a
full-fledged
programming
language
such
as
golang
in
this
case,
so
we'll
be
able
to
handle
more
of
the
life
cycle
of
a
running
gitlab
instance.
B
So
in
the
future
we'll
be
able
to
handle
upgrades
and
backups
etc
and
really
take
a
lot
of
those
admin
tasks
and
bake
them
into
the
logic
of
the
operator
to
help
make
running
gitlab
a
more
seamless
and
dependable
process
so
really
excited
to
be
working
on
this
and
sharing
this
with
the
world.
And
so,
if
you
get
your
hands
on
it
and
get
a
chance
to
test
it,
we're
always
welcoming
feedback.