►
From YouTube: GitOps Demo Day - 2021 10 26
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
Hello,
everybody.
There
are
already
a
lot
of
people
joining,
so
we
are
glad
to
have
you
here
for
our
last
demo
day
and
we'll
give
others
two
more
minutes
to
join.
So
if
you
don't
have
a
coffee
yet
get
yourself
one
and
yeah.
If
you
don't
mind
you
can
put
in
the
chat
where
you're
joining
from
so
the
gitlab
team
is
joining
from
all
over
the
world.
A
A
After
the
webinar,
you
will
receive
a
follow-up
email
with
the
slides
and
the
recording.
Also,
this
will
include
the
recording
in
the
slides
of
the
past
two
demo
days,
as
this
is
part
three
of
offer
session.
So
it
means,
if
you've
missed
one
of
the
first
two
sessions.
You
can
still
check
out
and
watch
on
demand.
A
Yeah
apart
from
that
ask
whatever
you
wanna
ask
ask.
We
also
will
have
some
room
for
q
a
at
the
end
but,
as
I
said
answering
alongside,
and
we
will
have
some
polling
questions
so
also
other
information
for
you,
so
keep
an
eye
on
that.
We
try
to
keep
it
as
interactive
as
possible
and
for
you
also
to
have
the
chance
to
provide
some
feedback
and
there
with
I'll
hand
over
to
victor
notch.
Our
speaker
for
today
he's
product
manager
at
gitlab
and
yeah.
B
B
We
will
focus
on
just
one
part
of
what
githubs
can
mean
if
you
use
gitlab,
but
I
hope
you
find
it
interesting
few
words,
but
me
I'm
product
manager,
at
gitlab,
responsible
for
gitlab's,
qubits,
integration
and
instance,
just
code
capabilities
and
together
with
me
here,
is
on
the
call
mikhail
mazurski
from
australia
who
originally
from
russia
who
is
actually
the.
I
would
say
the
lead
engineer
behind
these
integrations
and
if
you
have
any
questions,
just
drop
them
in
the
chat.
He
will
try
to
answer
them.
B
If
I,
if
I
cannot
give
me
that
I'm
doing
the
demo,
but
hopefully
we'll
have
a
chat
at
the
end
and
in
formal
q,
a
live
as
well,
where
we
can
answer
some
of
the
questions.
If
you
have
some
interesting
kubernetes
oriented
use
cases
that
you
think
gitlab
cannot
serve
you
today.
Please
reach
me
out
on
one
of
the
contact
possibilities
here,
especially
try
to
be
active
on
twitter,
so
feel
free
to
reach
out
to
me
as
well
there,
and
I
would
love
to
have
a
call
in
this
case
with
you.
B
B
B
B
I
don't
know
if
you
see
the
results,
so
the
majority
of
you
are
still
evaluating
kubernetes,
no
production
workloads
yet,
but
there
are
quite
some
people,
like
the
quarter
of
you
who
has
even
production
these
days
already-
and
quite
a
few
of
you
are
actually
deploying
applications
that
you
develop
into
the
balance,
which
is
great
these,
I
I
I
think
we
we
will
be
able
to
serve
some
interest
for
all
of
you
and
there
is
some
interesting
monitoring
as
well
great
to
see
this
okay.
So,
let's,
let's
get
started.
B
By
that
time
I
knew
a
few
sysadmin
folks
who
were
more
specialized
than
me
in
specialized
infrastructure.
Followingly
in
the
early
2000s
came
the
devops
movement,
but
first,
let's
speak
about
the
s3
approach.
I
consider
the
sr
approach
is
one
implementation
of
of
devops,
but
to
fully
understand
the
website
fully
embrace
it.
I
think
we
we
have
to
understand
what
sre
is
first
and
to
make
it
very
short.
B
Google
basically
arrived
at
the
sre
after
they
threw
over
some
developers
into
the
ops
team,
and
that's
where
the
systematic
thinking
about
architecting
your
infrastructure
with
automation
in
mind,
comes
from,
and
this
provided
a
huge
boost
towards
institutions,
codes,
for
example.
So
for
this
you
should
just
drop
some
engineers
developers
to
europe's
team.
B
On
the
other
hand,
the
whole
idea
of
devops
is
when
you
throw
over
or
ops
responsibilities
to
death
team.
That's
often
called
shifts
things
to
the
left,
but
the
very
interesting
difference
between
sre
and
devops
is
that
in
devops
you
speak
about
responsibilities.
While
for
sre
you
move
people
developers
to
the
ops
side,
and
if
you
do
it
that
was
well,
then
likely
will
have
some
staple
in
the
deaf
team.
Otherwise
it
apps
will
be
really
frustrating
and
they
might
just
ignore
the
ops
part.
B
B
So
in
this
evolution
we
got
to
point
what
we
call
today
githubs
and
what
does
it
add
to
this
evolution?
Oh
you
know,
I
would
say:
gitops
is
just
a
minor
step
in
this
process
of
operations,
experience
evolution
and
this
primary
catch
marketing
phase.
The
reason
why
I
say
that
is
because
the
sre
approach
is
about
changing
business,
critical
processes
with
engineers
it's
hard
and
costly
devops
is
a
cultural
change.
It's
super
hard.
B
On
the
other
hand,
gitops
is
primarily
technology
driven,
so
it
seems
to
be
easy,
but
actually
you
might
think
that
okay,
we
just
started
meetups,
but
actually
there's
thing
about
an
evolution
here,
so
you
cannot
step
over
the
previous
steps.
You
cannot
ignore
them.
The
sri
stage
adds
automation
and
this
metrics
different,
driven
mindset
to
the
whole
experience.
B
B
So
I
would
argue
that
you
have
to
take
think
of
this
as
a
as
an
evolution,
and
if
this
is
an
evolution,
then
the
real
question
is:
what
comes
next
and
where
are
you
right
now,
so
you
can
go
to
next
steps
and
in
both
cases
you
you
want
to
look
at
it
as
an
evolution.
So
this
is
this.
Is
my
approach
to
github's?
B
I
try
to
to
summarize
the
the
current
state
of
art
in
terms
of
the
evolution.
As
we
know
it
today,
but
actually
we
are.
We
can
try
to
break
this
down,
even
more,
by
which
I
would
say
that
meetups
at
its
core
is
some
codified
infrastructure.
That's
automated
fast
feedback
loops.
If
you
look
at
this,
this
is
devops
applied
to
your
infrastructure,
okay.
So
this
was
all
the
introduction
part
and
let's
see
how
we
can
do
github
street
gitlab.
B
The
driving
principles
would
be
to
be
closely
automated.
Everything
is
stored
in
git.
We
recommend
using
teleform
for
infrastructure
provisioning,
as
gitlab
has
some
amazing
platform
integrations.
We
will
not
deal
with
tar
form
in
this
demo,
but
we
have
a
poll
for
you
for
future
demos
and
and
as
I
speak
you
can
you
can
ask
for
that.
B
You
can
set
up
your
cluster
with
connection
both
for
pool
or
push-based
deployments,
whichever
you
favor,
often
again,
it's
an
evolution.
You
might
prefer
to
have
push-based
deployments
for
your
development
clusters,
for
example,
and
two
basically
deployments
in
production
or
you
just
want
to
move
and
have
a
nice
migration
path.
B
What
will
you
do
today?
First,
for
this
demo,
you
have
to
have
a
kubernetes
cluster
at
hand.
I
will
and
you
have
to
be
able
to
access
it
from
your
cli,
either
use
k3d.
So
it
has
to
be
run
on
my
computer,
but
it
can
be
anywhere
in
aws
gk
wherever
you
want
and
what
we
do.
We
will
install
the
agent.
I
will
show
you
how
to
do
that.
B
A
few
ways.
I
will
use
the
advanced
method
in
the
end,
but
I
will
show
you
the
the
quick
start
way
as
well,
and
then
we
will
have
both
pool
and
push-based
deployments.
In
the
meantime,
I
will
I
will
describe
what
they
are
and
a
few
other
features
of
gitlab
will
be
presented
as
well.
So
what?
What
is
this
agent
that
I'm
speaking
about
and
that
I
mentioned
a
few
times?
B
You
can
connect
a
cluster
treat
lab
using
the
gitlab
commerce
agent
and
basically
it
is
a
component
called
agent
k
that
runs
within
the
cluster
and
we
will
have
to
install
it
into
the
cluster
and
it
will
reach
out
to
gitlab
authenticate
itself
and
we
set
up
a
bi-directional
streaming
channel
between
itself.
That
is
your
cluster
and
gitlab.
B
This
enables
all
kinds
of
amazing
features
like
the
agent
k
can
ask
gitlab
if
there
are
any
changes
in
the
git
repository
where
your
cluster
is
described
and
can
apply,
those
changes
to
a
cluster
or
gitlab
can
notify
the
agent.
I
have
some
new
changes
for
you,
so
please
update
the
cluster
or
we
can
actually
even
apply
content
network
security
policies
and
then
those
places
are
there's
a
breach.
B
So
that's
why
having
this
agent
is,
is
a
really
really
strong
feature
for
us
that
we
try
to
base
most
of
our
integrations
upon
what
our
pool
and
push-based
deployments
before
we
get
to
it.
If
you
are
not
familiar
with
it,
both
are
just
about
how
how
you
will
modify
your
cluster,
how
you
will
access
your
kubernetes
api
that
actually
modifies
your
cluster
in
pubes
deployment
setup.
B
What
happens
is
something
runs
within
the
cluster
like
agent
k,
as
I
just
showed
you
and
it
retrieves
the
manifest
from
a
repository
outside
of
your
cluster
and
applies
them,
so
the
whole
application
happens
within
the
cluster
so
inside
this,
in
our
case,
agent
k
can
follow
along
all
the
evens
that
are
fired
throughout
deployment.
Those
can
be
reported
and
it's
a
more
integrated
experience.
B
On
the
other
hand,
the
push-based
deployments
are
when,
for
example,
you're
on
github
ci
cd,
where
you
have
a
job
that
goes
out
to
your
cluster
and
starts
cube,
cutter,
apply
or
harm,
apply
or
anything
else,
and
pushes
the
changes
down
to
your
cluster
to
be
applied
in
the
cluster.
In
this
case,
you
have
to
have
a
logic
in
that
outside
to
a
cluster
component
that
checks
whether
the
changes
were
applied
successfully.
So
these
are
basically
two
different
approaches.
B
There
are
consequences
in
scalabits
and
many
other
aspects,
but
let's
keep
it
at
this
level
for
now.
Okay,
so
let's
go
to
the
demo.
Now
I
prepared
a
few
things
for
it.
Like
I
have
a
github's
demo
group,
it's
a
public
group.
You
will
be
able
to
see
the
project
that
we
create
here,
as
nothing
will
be
shared
that
shouldn't
be
shared.
B
B
B
B
B
B
A
B
B
Let
me
know
if
I
need
to
increase
it
more,
but
so
right
now
what
we
did.
We
just
created
a
new
project
in
git
lab
cloned
it
added
the
configurable
push
the
this
empty
file
back
to
bitlab,
and
now
we
are
registering
the
agent.
This
is
where
we
are
in
the
agent
registration
flow.
The
first
step
was
to
select
the
agent
that
we
created,
and
now
it
provides
us
a
token
that
we
can
copy.
B
B
Kpt
is
a
tool
by
google
that
has
many
nifty
features
and
what
we
are
going
to
use
we
use
it
mostly
to
it
enables
getting
a
part
of
a
git
repository.
Basically,
it
can
be
at
a
version
tag,
as
you
see
it
now
and
later
on.
It
enables
as
well
to
update
that
checked
out
that
clone
of
the
repository
by
keeping
your
changes
and
trying
to
merge
the
upstream
at
the
same
time.
So
that's
why
we
use
kpt
and
that's
why
I
recommend
using
that.
B
B
B
Okay,
I
do
not
push
these
changes
back
to
the
repository
yet
because
I
have
a
secret
to
be
added
somewhere
around
here,
but
first,
let's
see
our
docs
what
else
it
provides,
because
this
is
actually
a
set
of
kubernetes
customized
overlays
that
you
can
see
here.
So
we
can
do
something
like
shown
here.
B
And
you
can
set
all
these
variables.
The
agent
version
right
now
is
a
stable
version.
Let's
set
to.
Let's
set
that
to
the
version
that
you
will
want
to
use
cast
address
is
the
bitlab
address.
That's
perfect
cos
is
the
cluster
site
component
of
this
agent
workflow,
so
you
always
have
to
have
the
combat
agent
server
running
somewhere.
B
There
are
a
few
other
things
it
might
be
easier
to
read.
If
I
get
this
closed,
there
are
a
few
other
things
like
game
space.
You
can
add
name
prefix
as
well,
and
you
can
decide
whether
parameters
scraping
should
be
enabled
or
disabled.
It
will
be
enabled
by
that.
So,
if
you
don't
know
how
to
use
these
things
in
the
docs,
we
we
have
a
few
more
ideas
here
like
config
set.
I
will
use
that
to
set
the
agent
version.
B
B
B
A
B
C
B
B
B
B
So
let's
set
the
agent
version.
This
is
actually
the
only
change
that
appears
within
it
and
let's
push
it
just
to
save
everything
at
the
end
of
the
demo.
You
can
think
about
how
you
can
turn
this
agent
to
manage
itself,
because
we
will
install
some
applications
into
this
cluster
that
are
needed.
That
enables
you
to
to
manage
it
in
the
secret
within
the
git
repository.
B
So
but
now,
if
you
go
back
to
the
agent,
we
see
the
github
agent
namespace,
we
saw
that
was
created
and
we
see
the
agent
as
well
that's
running
and
you
can
check
out
its
logs.
There
isn't
much
happening
because
the
configuration
file
is
actually
empty.
So,
let's
start
by
adding
something
to
this
configuration,
I
will
deploy
now.
B
The
encrypted
secret
is
deployed
to
a
cluster
where
the
in
cluster
component
decrypts
that
secret
and
creates
a
normal
kubernetes
secret,
so
the
unencrypted
version
only
leaves
within
the
cluster
action
installation.
Actually,
I
know
that
I
should
go
to
the
releases
and
have
to
look
at
the
controller
yamo
that
we
will.
B
B
How
do
you
do
that?
First,
I
prefer
to
create
a
not
there,
but
at
the
top
level,
a
director
that
holds
all
the
manifest
because
oops
this
is
not
a
directory
but
a
file,
so
I
prefer
to
have
a
directory
that
holds
all
the
manifest,
because
in
a
true
setup
you
will
have
multiple
of
them
and
then
we
have
to
configure
the
agent
to
use
this
manifesto.
B
I
believe
many
many
comments
in
this
file
for
now,
but
of
course,
feel
free
to
remove
them
in
your
own
setup.
You
will
need
the
project
slug
that
you
use
in
this
case.
That's
gitlab
examples,
ops,
meetups,
democrats,
agent.
You
can
specify
a
default
namespace.
Let's
have
it
default
in
the
you
know.
We
always
specify
namespace
in
our
manifest,
so
it
doesn't
matter
much
and
they
will
deploy
every
ml
file.
B
We
leave
everything
at
default
right
now,
so
we
only
configured
where
the
ammos
should
come
from
and
I
think
we
are
good.
So,
let's
see
what
happens
next
added
secrets
and
we
will
see
a
very
interesting
thing
because
the
deployment
will
fail.
It
will
fail
because
the
agent
doesn't
have
necessary
access
rights
to
apply
this
gamble
that
we
have
here.
B
Yeah,
there
are
no
errors,
so
it
just
worked
okay,
then
they
had
enough
rights
to
to
apply.
The
next
step
is
to
retrieve
the
public
key
used
by
cs
secrets
and
just
to
make
sure
that
we
have
everything
set
up.
You
can
check
out
namespaces
and
seeing
secrets
is
actually
deployed
under
cube
system.
If
everything
goes
well-
and
you
see
it
here-
see
secrets
controller.
B
So
the
next
thing
is
that
we
need
to
get
the
public
key
from
seed
secret
seed
secrets
has
a
client-side
app
that
you
can
run
for
stealing
your
secrets
and
for
a
few
other
activities
like
fetching
the
certificate,
the
public
certificate
of
used
in
for
the
decryption.
We
are
just
going
to
add
that
to.
B
B
Is
we
install
the
agent
after
first
we
registered
it?
We
got
a
token,
then
we
use
kpt
t
and
customize
to
install
the
agent
into
our
cluster
and
we
installed
seed
secret
using
pool
based
deployments.
We
just
committed
the
manifest
files
into
a
bit
repository.
We
didn't
need
any
ci
files,
nothing
along
those
lines.
B
The
agent
just
grabs
those
manifest
files
and
applies
them
in
the
repository,
and
now
we
have
secrets
ready
for
action.
The
next
step
of
the
demo
is
that
we
will
use
these
sales
secrets
to
install
the
runner
and
another
together
with
another
gitlab
feature.
So
for
that,
let's
head
over
this
is
done.
This
is
good.
B
B
B
B
For
example,
as
you
can
see,
there
are
site
manager,
the
set
manager
and
ingress
in
here
that
you
can
use
together
with
autodeploy,
to
set
up
a
tls
endpoint
and
an
ingress
in
front
of
your
applications,
or
we
have
celium
apar,
morph,
falco
and
other
security
oriented
applications.
Within
this
repository
that
again,
you
can
just
install
in
the
cluster
and
integrate,
for
example,
the
already
mentioned
container
to
execute
policy
alerts
together
with
gitlab
and
all
of
this
works
using
this
project
and
the
gitlab
commands
agent
in
integrated
fashion.
B
So
what
we
will
use,
it
will
be
just
running
installation,
but
first,
let's
see
how
can
we
access
that?
Because,
as
you
can
see,
this
project
actually
has
comes
with
a
bit
left,
ci
ammo
and
that
little
cyayama
seems
to
be
kind
of
self-contained.
So
how
can
an
agent
use
this
one?
That's
the
big
question,
and
for
that
I
want
you
to
meet
the
cicd
tunnel.
B
B
I
think
this
is
the
right
code
and
then
it
would
just.
It
should
show
me
all
the
ports
that
exist
in
my
cluster,
but
actually
I'm
not
interested
in
this.
So
in
order
to
move
it
faster.
I
would
just
for
forget
about
all
of
it
right
now
and
let's
head
over
to
the
runner
project
that
we
actually
through
the
custom
management
project
where
we
want
to
install
the
runner.
How
can
we
use
this
cicd
tunnel
in
this
project?
That's
the
big
question.
B
B
B
B
B
As
you
can
see,
there
are
no
contacts
available
for
me
and
the
reason
is
just
security.
You
don't
want
all
your
agents
to
be
accessible
by
by
all
the
teams.
You
have
to
enable
a
specific
agent
to
be
accessible
by
other
groups
or
projects.
So
for
this
we
have
it
documented
under
authorizing
groups
to
use
the
agent.
So
I
will
have
to
add
something
like
this
to
my
agent
configuration
here.
We
go,
I
mean
here
we
go
and
you
add
the
new
section
where.
B
B
B
B
Extend
this
script
with
this
use
context.
So
what
we
do?
We
change
the
default
template
that
comes
with
the
ci
cd
with
this
management
project
and
we
change
the
apply
step
to
use
this
cube
context.
We
set
the
context
using
the
example
here:
okay,
let's
commit
the
change
to
master
use.
The
agent
context.
B
We
still
have
nothing
configured,
no
application
is
enabled
this
half
files
based
application
works
the
way
that
there
are
a
set
of
hand
files
for
one
for
each
application,
and
you
have
to
configure
that
home
file
and
the
application.
So
one
thing
you
can
do
here
is
to
go
back
to
the
web.
Ide
open
hemp
files
just
enable
runner,
and
then
you
likely
want
to
check
out
the
possible
settings
for
the
runner
in
this
values.
Demo,
gold
template
file.
B
B
B
B
B
C
B
Correct
and
this
environment,
this
environment
is
actually
given.
Okay,
let's,
let's
explain
everyone
what's
happening
under
infrastructure,
kubanta's
clusters:
you
can
see
two
tabs
one
is
the
clusters
connected
with
certificate
and
the
agent
managed
connections.
The
agent
managed
connection
is
comes
from
a
different
project,
but
here
this
cluster
has
an
environment
scope
of
star.
That
is
all
the
environments.
B
B
B
Yeah
now
we
can
see
the
context
is
available,
so
this
whole
scripts
that
we
saw
before
that
comes
from
the
template
itself
is
being
run.
It
takes
quite
some
time
because
it
assures
that
many
spaces
are
there.
It
checks
if
gitlab
owns
these
deployments,
for
the
deployments.
Are
there
already
and
has
to
apply
all
those
changes.
B
B
What
a
few
more
words
about
the
agent
until
we
wait
for
the
pipeline
to
finish,
as
you
can
see,
the
agent
lives
within
your
cluster
as
a
result,
it's
it's
managed
by
regular
kubernetes
airbag,
and
it
will
be
only
able
to
act
on
resources
that
it
it's
allowed
to
act
on.
So
we
don't
require
you
to
provide
us
class
admin
rights
or
anything
along
those
lines.
B
You
can
restrict
the
agent
as
much
as
you
want.
We
try
to
make
it
very
lightweight.
As
a
result,
even
multiple
agents
might
be
able
to
run
in
a
single
cluster,
and
we
see
here
an
error
that
we
are
actually
aware
of.
Sometimes
this
ci
tunnel
breaks
down
if
it's
under
heavy
use.
We
are
currently
working
to
fix
this,
so
I
would
just
hit
retry
and
we'll
start
to
speak
and
continue
to
speak.
B
B
You
can
use
it
with
a
few
other
integrations
that
gitlab
provides.
Basically
all
the
apps
in
this
cluster
management
project
provide
various
levels
of
integration
inside
of
gitlab
like
they
already
mentioned,
container
aspect
security
policies,
for
example,
they
just
surface
the
alerts
into
gitlab
if
there
is
a
breach.
B
B
A
A
B
We
recommend
everybody
to
use,
terraform
or
other
infrastructure
2
to
set
up
your
clusters
and
today,
in
the
docs
we
ship
an
example
project
only
for
gke
and
not
for
for
other
other
clouds.
But
you
can
use
software
for
any
of
those
and
the
integrations
that
beta
provides
should
just
work.
So
we
don't
have
specific
integrations
for
gke
within
the
specific
integrations
for
eks
or
any
other
cloud
provider.
We
have
integration,
deter
form
to
be
provider
agnostic
as
a
result,
as
long
as
they
have
triform
modules.
B
B
Yeah,
that's
a
very
good
question.
Actually
we
started
the
shared
code
base
that
was
called
the
github's
engine.
That's
the
underlying
detox
code
base
for
argo
cd,
but
we
moved
away
from
it
for
good
reason.
We
just
found
that
it
has
a
few
unnecessary
dependencies
and
we
could
make
the
agent
more
lightweight
and
more
modern
in
terms
of
how
it
operates
within
the
cluster,
using
something
that
you
might
have
spotted.
The
inventory
policy
object
that
we
speak
about
in
the
docs
and
in
the
agent
configuration.
B
So
it's
it's.
It
has
some
common
roots,
but
actually
moved
away
from
from
the
from
the
shared
code
base
in
terms
of
functionality.
From
the
user's
point
of
view,
it
serves
the
same
needs.
The
the
idea
is
that
you
want
pool-based
deployments
and
both
give
you
pull-based
deployments.
Argo
cd,
just
to
mention
the
third
tool
in
the
space
flux
compared
to
flux,
is,
I
would
say,
provides
a
better
user
experience.
B
Argo
is
only
for
pool
based,
so
you
always
have
to
somehow
make
your
repositories
available
to
the
to
the
argo
instance.
Here,
it's
more
developer-friendly
with
having
push-based
setup,
because
developers
might
be
familiar
with
those
workflows
why
they
might
not
be
familiar
with
the
full-based
approach
and
the
change
of
mind
might
be
harder
to
to
get.
Similarly
with
the
content
network
security
integration,
that's
simply
something
that
argo
likely
will
never
have
with
git
lab.
You
can
configure
content
network
security
policies
within
gitlab.
B
You
can
even
deploy
them
with
a
pool
based
fashion
using
the
agent
and,
if
there's
a
breach,
it
will
be
surfaced
into
gitlab.
As
an
incident-
and
we
are
just
adding
container
network
security
scanning
as
well,
so
these
are
the
things
argo
is
great
for
blue
base
deployment.
It
actually
has
a
little
bit
wider
support
in
terms
of
of
the
tools
that
it
has
like.
B
Yeah
one
more
note
about
this:
qr
code,
we
just
released
started
release
a
series
of
blog
posts
around
github
with
bitlab.
I
think
the
first
one
came
out
on
friday
and
this
qr
code
leads
to
the
first
article
in
that
series
of
blog
posts.
So
if
you
want
to
read
more,
there
is
infrastructure,
provisioning
discussed
as
well
with
gitlab
and
monitoring
vib
as
well.
B
B
It
should
just
work,
so
the
nice
thing
is
that,
as
long
as
you
use
kubernetes,
you
can
install
agent
k
in
the
cluster.
It
will
work,
as
you
can
see
in
my
demo.
It's
not
a
hybrid
cloud
in
the
sense
that
it's
local
cluster,
but
actually
I'm
using
gitlab.com
at
the
same
time.
So
you
just
need
an
egress
and
not
an
ingress
to
basically
from
your
cluster.
You
have
to
be
able
to
access
because
gitlab.com
domain.
In
our
case
and
as
long
as
that's
possible,
it
should
work
without
any
issues.
B
A
Okay,
thank
you
for
answering
this
yeah.
Well
also,
thank
you
from
my
side,
quick
reminder.
You
will
receive
a
follow-up
email
with
recording
and
slides
and
some
further
information,
so
you
can
also
watch
the
first
two
demo
days
in
case.
You
might
have
missed
them
and
I
have
put
a
link
in
the
chat
for
you
so
in
case
you're
interested
in
an
interactive
security
workshop.