►
From YouTube: Distribution Team Demo 2021-06-10 SSH with Operator
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
Alrighty,
hello,
everybody
welcome
to
the
distribution
team
demo
on
june
10
2021.
this
week.
I'm
going
to
be
talking
about
ssh
support
for
the
gitlab
operator,
so
I'm
going
to
do
a
quick
demo
of
what
that
looks
like
and
then
lead
into
a
discussion
about
the
alternatives
in
the
approach
that
we
have
for
the
solution
so
share
my
screen.
A
Alrighty
everybody
see
my
screen
cool
all
right,
so
this
is
the
issue
number
58.
If
you're
curious,
I
have
it
linked
in
the
distribution
team.
Demo
notes.
There's
good
discussion
on
here
where
this
has
led
is
mr
163
and
the
approach
in
this
one
I'm
going
to
be
taking
is
to
deploy
the
forked
nginx
objects
that
we've
built
into
our
gitlab
helm
chart,
and
so
the
idea
behind
this
being
with
the
operator
that
we
currently
deploy
with
the
gitlab
operator,
it
approaches
ssh
support
in
a
slightly
different
way.
A
So
my
fear
with
that
is
that
the
process
for
an
end
user,
who
wants
ssh
support,
which
currently
comes
out
of
the
box
with
the
helm
charts,
would
require
some
manual
intervention
with
several
steps
for
a
user
if
they
wanted
to
do
the
same
thing
in
the
operator
and
ideally,
I
would
like
to
avoid
the
operator
becoming
a
more
involved
process
than
our
home
charts,
and
so
the
approach
in
this
mr
kind
works
around
that,
because
we've
taken
that
logic
that
connects
all
the
ssh
traffic
for
gitlab
and
built
it
into
our
fork
at
the
nginx
chart
and
so
effectively.
A
A
So
the
interesting
part
is
down
here
under
spec
we've
got
global
host
domain
pointed
to
my
domain.
I
only
picked
an
external
ip
just
so
I
didn't
have
to
keep
mapping
them
every
time
my
service
got
a
new
ip
and
then
I
disabled,
configure
cert
manager,
because
just
no
need
for
the
specific
mr
to
hit
let's
encrypt
too
often,
and
then
I
went
nginx
ingress
enabled
true,
I'm
working
around
a
small
issue,
but
this
should
be
the
default.
Of
course
that's
up
for
discussion.
A
If
we
want
this
to
be
the
default
or
if
we
want
the
nginx
ingress
operator
to
be
the
default,
but
that's
really
all
a
user
would
need
to
do,
and
then
you
can
see
here.
If
I
list
the
pods,
we've
got
the
nginx
ingress
controller
and
the
default
backend.
This
looks
exactly
like
what
we
have
from
the
home
charts
because
it
is
and
so
and
then
the
last
thing
to
check
here
is
the
services.
A
A
Give
it
a
message
and
push
it
up,
so
no
errors.
If
I
refresh
there's
my
message
so
exactly
how
you
would
expect
it
to
work
in
another
installation
of
the
gitlab
helm
charts.
Now
what
I
left
some
notes
here
regarding
in
the
demo
notes,
is
kind
of
what
I
started
leading
into
earlier
now.
The
downsides
of
this
approach
that
I've
deployed
here
is
that
at
the
moment,
there's
no
red
hat
certified
images
for
the
flavor
of
ingress
engine
x
that
we're
deploying.
A
That
was
one
of
the
points
I
didn't
mention
at
the
beginning
of
the
call
with
the
helm
charts
we
actually
deploy
the
kubernetes
flavor
of
ingress
engine
x,
the
kubernetes
managed
distribution
of
it,
whereas
the
gitlab
operator
currently
before
the
semr
deploys
nginx
inc's
flavor
of
it,
and
so
those
actually
behave
differently,
and
so
there's
different
configuration
for
those
objects
and,
like
I
was
starting
to
mention.
There
are
no
red
hat
certified
images
specifically
for
the
kubernetes
ingress
engine
x.
A
Docker
image
hussein
brought
up
a
point
as
well
that
end
users
might
not
like
that.
We
bundle
other
services
into
our
operator.
So
it's
something
to
consider.
We
do
currently
do
this
with
services
like
redis
and
postgres,
but
just
like
with
the
home
charts,
we
plan
to
support
external
instances
of
those
and
just
disabling
our
internal
ones,
and
we
can
do
the
same
thing
for
nginx
here.
A
And
so
the
ultimate
question
is
here:
do
we
deploy
this?
These
bundled
and
forked
nginx
objects
by
default
for
users
or
maybe
not
by
default,
but
allow
them
to
only
if
they
want
ssh
or
do
we
want
to
keep
in
with
the
operator
paradigm
and
point
users
to
installing
the
gitlab
engine
x
operator,
so
yeah?
That's
where
I
wanted
to
lead
everyone,
so
any
thoughts
or
questions
or
anything
else.
You
wanted
me
to
demo.
B
A
Sure
yeah
those
are
custom
resources
specific
to
that
operator
and
those
custom
resources
are
marked
in
their
documentation
as
a
feature
preview
not
recommended
for
production
and
sort
of
tangentially
related
that
configuring,
those
doesn't
automatically
expose
the
desired
port
on
the
nginx
service.
You
have
to
go
manually
do
that
even
the
nginx
ingress
controller
custom
resource
doesn't
have
a
field
for
exposing
any
custom
ports.
B
A
Yep
and
like
many
operators,
it's
young
just
like
ours,
is
but
they're
much
earlier
in
the
development
cycle
than
the
related
helm
chart.
Obviously,.
A
Yeah,
that's
ultimately
the
question
hussein
has
started
to
take
a
look,
and
so
is
jason
so
because
we're
getting
near
the
end
of
the
release
cycle,
I
just
wanted
to
open
up
the
mr
and
make
sure
that
this
is
an
approach
that
we
were
all
comfortable
with
and
made
sense
and
there's
lots
of
ways
to
skin
this
cat
and
so
gotcha
yeah.
I
think
this
kind
of
leads
more
into
software
philosophy
and
what
we
want
our
defaults
to
be
and
what
we
want
to
support.
Not
necessarily
is
it
technically
feasible.
A
I
think
we
could
go
either
way
and
it
would
still
work
it's
just
if
we,
if
we
do
go
the
path
of
the
nginx
ingress
operator,
the
we're
just
kind
of
going
down
a
different
track
in
terms
of
software.
We
support
and
the
process
for
the
end
user
would
be
a
little
tougher.
B
A
Yeah,
it's
a
fair
question.
I
noticed
that
I'm
just
scrolling
through
here.
I
remember
seeing
that
there
was
one
of
these
images
is
effectively
not
made
by
the
nginx
team,
but
it
was
made
by
someone
who
I
guess
was
blessed
to
to
produce
their
image
I'll
grab
a
link
to
it
when
I
can
find
it.
B
A
B
So
I'm
specifically
looking
for
one:
that's,
not
the
nginx
inc
one.
What
I'm
saying
is
a.
C
B
C
A
B
B
How
do
I
phrase
this?
There
are
implementation
differences
on
how
they've
chosen
to
do
something
versus
how
the
community
has
chosen
to
do
something.
The
community
has
chosen
that
you
should
be
able
to
to
supply
and
configure
your
own
default
backend
that
allows
you
to
bring
your
own
error
handler,
slash,
secondary
router
or
literally
just
set.
Look
if,
if
you
go
to
something
on
the
ingress
that
doesn't
actually
end
up
at
my
application,
just
send
it
to
my
application.
A
A
C
A
Awesome
alrighty.
Well,
thank
you,
everybody.
The
notes
are
here
in
the
google
doc.
So
with
the
qriket
sounding,
I
will
leave
you
all
to
enjoy
the
rest
of
your
week.
Thank
you.
Everybody
yeah
great
work
mitch
see
you.
Thank
you.
Good
job
mitch
appreciate.