►
From YouTube: Distribution Team Demo Oct 1st 2020
Description
Distribution Team Demo of potential mult-role webservice idea in the helm chart.
A
A
A
A
So
one
of
the
nice
handy
parts
of
helm
is,
you
can
actually
say
helm
get,
but
one
of
the
things
you
can
say
there
is
get
manifest
and
it
will
actually
return
all
of
the
kubernetes
objects
as
it
understands
them
so
per
issue
2334
effectively.
What
we
want
to
do
is
we
want
to
have
one
ingress
and
then
a
set
of
items
for
the
rest
of
the
deployment.
So
we
need
a
deployment.
We
need
a
service,
we
need
a
pdb
that
matches
to
the
label
selectors
because
otherwise,
you've
got
pdb.
A
Such
things
they
shouldn't,
we
want
the
same
thing
for
an
hpa.
We
want
it
pointed
at
the
deployment
by
name.
So
we
have
a
couple
of
resources.
We
need
to
effectively
duplicate
from
web
service.
In
this
example,
what
I'm
doing
is
creating
over
here
a
base
which
will
be
effectively
web
or
default
api
and
get.
A
This,
what
I've
done
is
I've,
pulled
the
full
manifest
down.
Obviously
I
don't
need
every
single
thing
that's
in
here,
but
for
the
giggles
of
line
count
almost
5
000
lines,
and
I
don't
even
have
everything
turned
on
what
I've
done?
Is
I've
gone
through
and
pulled
out
all
the
engine,
the
web
service
bits
that
were
generated
from
that
chart
and
placed
them
into
two
copies
of
that
and
then
made
the
necessary
changes
that
being
the
name
of
the
objects,
so
it's
gitlab
web
service
dash
api
and
gitlab
web.
A
This
is
a
valuable
item,
but
I
just
did
this
for
consistency
and
visibility
and
then
over
in
the
ingress.
This
needs
some
small
changes
made
to
it.
I've
added
additional
paths,
one
for
anything
under
api
and
one
for
anything
under
the
regex
that
we
have
in
place
from
recent
changes
to
this
regex
within
the
omnibus.
Basically,
the
easiest
way
for
me
to
get
most
of
it
right
was
to
take
what
we
already
had
and
hope
it
works
out
of
the
box.
So
that's
the
attempt
there.
A
All
I've
done
in
that
regard
is
then
turned
around
and
actually
just
to
control
apply
and
I
applied
each
of
the
deployments.
The
objects
are
still
in
the
same
order.
So
it's
doing
things
in
such
a
direction
that
you're
not
going
to
like
have
a
rejection
from
the
api,
because
the
objects
don't
exist
and
once
I've
got
those
down,
then
I
turned
around
and
updated
the
ingress
with
this
additional
chain
set.
A
A
A
Looks
correct,
as
you
can
see,
the
interpolation
of
our
literal
dollar
sign
actually
changed
out
a
little
bit.
So
that's
a
fun
one
to
see,
but
it
works
the
same
way
go
ahead
and
pop
out
of
that
one.
But
I
will
go
ahead
and
jump
into
the
logs
there
so
just
to
see.
If
I
can't
turn
off
a
little
bit
of
detail
here,
no
not
a
whole
lot,
so
I
will
do
full
screen
and
make
that
a
little
easier
for
us
to
follow
along
and
back
to
the
demo
here
and
just
so
everybody
can
see.
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
B
One
thing
to
verify
might
be
just
the
service
level
that
we
haven't
accidentally
matched
like
that.
Maybe
nginx
isn't
going
to
the
right
service,
but
maybe
the
services
are
matching.
A
A
A
A
A
C
C
A
A
A
A
A
A
A
A
A
B
Yeah,
so
this
this
regex
isn't
just
for
get
traffic.
It's
I
think
it's
just
for
attracting
like
in
omnibus
it's
just
for
traffic.
We
want
to
turn
off
request
buffering,
for
I
think,
but
that.
C
B
That
does
inc
like
that's
why
the
job
artifacts
are
on
there
as
well,
but
it
does
include
like
in
the
middle
there.
The
receive
pack
forget
okay,
so
I
would
have
expected
that
to
still
be
matched
is
this.
A
A
A
A
Well,
you're
correct.
C
A
A
B
Yeah,
I
think
the
regex
we
have
now
is
actually
just
for
push.
A
B
Yeah,
in
the
end,
we're
going
to
need
a
completely
different
regex
for
this,
just
because
what
we're
trying
to
do
here
isn't
exactly
the
same
as
what
the
omnius
is
trying
to
do.
A
A
A
A
A
A
A
A
A
B
B
Yeah,
which
is
fine
for
this
case,
though
actually
you
can
actually
draw
like
because
we're
just
trying
to
grab
all
the
topics,
so
you
could
just
do
the
info
reps
and
drop
the
parameter
yeah.
I
think
that
was
the
problem
with
the
old
regex
that
we've
changed
recently
is.
I
just
don't
think
that
having
service
in
there
works
for
the
location
line?
A
B
A
A
A
Now
that
we've
taken
50
minutes,
does
anybody
have
questions
comments,
concerns
regarding
the
issue
as
they
might
have
reviewed
it.
C
A
It
should
be
a
lot
like
sidekick,
but
not
quite
one
of
the
things
that
we
want
to
point
out
is
that
we
don't
want
it
quite
as
complete
as
sidekick
we
want
to.
We
want
to
make
sure
it
has
all
the
necessary
configuration
properties
and
that
those
are
observed,
but
we
need
to
make
sure
that
this
path
is
simpler
than
redefining
a
default
cue
set
in
sidekick.
Most
people
never
need
to
touch
sidekick,
or
they
really
need
to
touch
sight
kick
with
web
service.
A
We
don't
want
to
have
to
be
warning
people
that
all
the
settings
have
moved
with
sidekiq
you
set
global
defaults
and
then
the
the
default
cue
set
inherits
those
with
web
service.
You
should
only
really
have
to
touch
them
if
you
absolutely
have
to
so.
I
don't
necessarily
want
to
require
the
deployments
object
to
be
populated,
basically
go
if
there
are
no
deployments
just
make
the
default.
A
B
Yeah,
I'm
also
not
sure
what
delivery's
intent
is
with
the
ingresses
like
as
if
they're
planning
to
roll
their
own
or
not.
A
Ours
so
there'll
be
there.
There
will
be
a
load
balancer
in
front,
so
the
gka
would
come
in
hit,
I
think
aj
proxy
and
then
aj
proxy
would
divvy
traffic
out
canary
and
prod,
and
then
that
would
actually
hit
the
ingress
for
our
chart
and
then
divvy
the
traffic
as
appropriate.
A
And
how
to
populate
those
now
the
good
news
is,
you
can
actually
just
have
more
than
one
ingress
this.
This
demo
was
an
attempt
to
not
populate
everything.
If
we
don't
have
to
right
so,
like
the
config
maps
are
the
same,
the
ingress
is
shared
because
we're
basically
just
changing
paths,
but
if
we
have
to
actually
set
you
know,
hey,
don't
proxy
buffer.