►
From YouTube: GitLab as a GitOps platform demo 3 - Platform Engineer
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,
my
name
is
Victor
Naj
I
am
one
of
the
product
managers
at
gitlab
and
me
and
my
team.
We
are
responsible
for
git
Labs,
kubants,
Integrations
and
infrastructures
code
functionality
in
this
series
of
videos
likely
in
three
videos.
I
would
like
to
demo
you
how
gitlab
can
help
you
if
you
are
an
infrastructure
engineer,
an
SRE
or
if
you
are
a
platform,
engineer
who's
setting
up
automations
for
your
teams
or
if
you
have
a
good
platform
engineer
and
want
to
benefit
from
their
work.
A
Actually,
everything
I'm
showing
here
could
be
in
a
separate
project
as
well.
I,
just
put
it
in
the
same
one
for
Simplicity.
Here
you
might
see
this
project
folder,
which
is
actually
a
transform
project.
As
you
can
see,
and
within
this
project
there
is
a
yaml
file
where
users
can
open
emerging
Quest
against
this
repository
to
edit
this
yaml
file,
and
they
can
add
Snippets
like
this
one.
This
Samuel
will
Define
a
new
delivery
project.
It
has
a
name
some
description.
It
will
have
a
namespace
in
the
cluster
in
this
case.
A
Actually,
I
will
deploy
the
application
into
two
namespace
in
the
same
single
cluster,
one
called
Potato
Head
and
the
other
with
the
suffix
of
Dev,
and
there
might
already
exist
an
application
project,
so
they
have
to
provide
the
path
to
that
project
and
a
few
other
settings
just
to
configure
the
project
itself
and
with
this
simple
configuration
when
the
user
wants
to
start
a
new
project,
they
want
the
everything
to
be
kicked
off
the
study
some
are
you
can
collaborate
with
the
merge
request
and
afterwards
this
terraform
project
will
run
what
it
does
is
actually
several
things.
A
This
is
the
delivery
project.
We
will
speak
about
it
in
a
minute.
It
creates
a
deploy
token
in
that
delivery
project.
This
deploy
token
will
be
used
by
flux
to
access
the
OCR
images
built
in
that
project.
We
are
using
flux
with
oci
images,
not
rigid
repository
to
provide
better
scaling,
but
you
could
use
read
registry
right
here
and
then
the
deploy
token
could
reach
could
read
the
git
registry
instead
and
we
store
project
variable
within
that
project
and
that
environment
variable
is
the
agent
Cube
context
name
for
the
agent
defined
in
this
project.
A
Here
it
will
be
this
project
slug
and
demo
afterwards,
and
we
started
there
because
it
will
help
us
to
trigger
a
flux,
reconciliation
easily
from
gitlab
Pipelines.
A
Once
a
project
is
configured
here,
so
we
create
the
project
followingly.
We
create
some
infrastructure
side
things,
namely
we
actually
just
render
files.
Here,
one
set
of
files
is
I'm
using
cubes
Cube
seal
I'm,
using
sales
secrets
from
bitnami
and
the
cubes
CLI
to
store
encrypted
secrets
in
the
git
repository.
A
A
This
was
the
base
that
we
started
with.
That's
why
we
have
two
of
them
to
always
know
where
to
start
with,
and
this
is
the
new
one,
so
what
we
started
with
included
the
container
scanning
and
basically
nothing
else.
A
The
new
one,
on
the
other
hand,
includes
CI
access
and
user
access
as
well,
and
this
means
that
from
these
projects,
gitlab
pipelines
can
access
your
cluster,
while
the
user
access
part
means
that
these
projects
can
access
your
cluster
from
the
gitlab
UI.
This
will
be
very
handy
in
the
environment
integration
that
I
will
share
with
you
afterwards.
Now,
to
note
is
that
here
I'm
using
the
accesses
agent,
which
means
that
we
don't
impersonate
the
gitlab
user?
A
A
That's
the
project
that
actually
deter
from
project
created
for
us
and
that's
how
you
can
scare
flux
so
with
flux.
What
you
can
do
that
you
have
a
central
repository
and
then
you
have
other
kind
of
leaf
repositories
or
whether
like
Branch
repositories,
that
can
further
scale
out
by
pointing
to
follow
up
OCR
repository
or
git
repository
sources.
A
So
this
is
what
happened
in
the
infra
project.
Now,
let's
see
what
happens
in
this
Potato
Head
delivery
project
here
who
owns
this
project
is
depends
very
much
on
your
organization.
It
might
be
the
platform
team,
it
might
be.
The
application
team
I
didn't
want
to
force
any
of
these
approaches
on
you
both
can
work
very
well
as
we
are
going
to
deploy
The
Potato
Head
application.
A
We
I
copied
the
chart
of
the
Potato
Head
project
under
here,
and
we
are
going
to
build
an
OCR
image
out
of
that.
Moreover,
in
the
Manifest
I
have
two
environments
Davenport
and
in
both
I
have
the
same
subdirectories,
app
and
setup,
and
here
I
just
have
a
secret
I.
Just
I
did
basically
to
show
you
that
it
can
be
done
and
how
I
would
do
it,
and
it
has
all
the
other
flux
resources
that
you
might
want
to
deploy.
A
Followingly
in
this
case,
it's
very
simple:
it's
just
a
single
oci
repository
with
a
single
customization
that
we
point
actually
to
that
app
directory
and
or
the
oci
image
that
we
build
out
of
that
directory.
But
the
whole
idea
is
that
you
could
add
anything
else
as
well.
You
could
add
other
Secrets
third-party
things,
whatever
whatever
you
need
and
then
in
the
app
directory.
A
We
have
a
ham
repository
because
we
are
deploying
it
with
the
ham
chart
that
you
have
seen
that
points
to
that
chart
in
the
same
Direct
in
the
same
project
with
the
secret
that
we
need-
and
this
is
the
same
secret
that
was
already
created
for
us
in
the
infrastructure
repo,
because
we
know
that
it
exists,
that's
how
it
can
read
itself
actually
and
then
we
have
the
ham
release
with
some
values
provided
the
other
environment.
The
dive
environment
is
almost
exactly
the
same.
A
I
will
show
you
later
how
one
can
upgrade
these
and
deploy
a
new
version
of
this
application
with
this
setup
and
then,
basically,
we
have
a
cimo
to
to
drive
all
these
things
in
the
ml.
We
have
a
job
to
build
the
chart.
It
will
build
an
oci
image,
as
you
can
see,
and
we
store
it
in
the
gitlab
container
registry.
The
gitlab
container
registry
can
store
both
Docker
containers
and
oci
containers,
and
then
we
use
we
have
a
set
of
jobs
to
build
the
flux,
rated
resources
again.
A
This
is
a
flux,
oci
image
that
we
are
building
and
afterwards
we
call
flux,
reconcile
immediately
that
oci
repository
so
that
it
we
don't
have
to
wait
for
the
regular
flux,
reconciliation
Loop
to
kick
in,
and
here
we
just
parameterize
that
hidden
job
to
say
it
where
the
Manifest
party,
that
needs
to
be
packed
and
a
few
other
things.
A
That's
all
what
we
have
in
here,
you
see
as
well
that
the
production
jobs
are
actually
manual.
This
will
allow
us
a
nice
controlled
rollout
into
production,
a
very
good
setup
acceptance
like
release
management
jobs
that
people
have
to
authorize
the
release
before
going
to
production.
A
In
the
end,
what
we
have
is,
then
we
will
have
these
container
images.
Actually,
all
these
are
built
from
those
jobs
that
you
have
seen,
and
this
is
what
we
are
going
to
deploy
so
once
again
to
recap
in
the
infra
repository
or
your
platform
repository,
if
you
want
to
have
one
of
those
we
point
to
this
entry
point
or
CI
image
and
to
the
entry
point
Dev
oci
image,
and
from
these
two
we
point
to
the
Potato
Head
dab
and
to
the
Potato
Head
images
both
of
these
images.
A
This
concludes
the
overview
for
platform
engineer
and
there
will
be
a
simple
overview
and
a
demo
on
how
this
all
looks
like
for
the
application
operator,
but
before
we
get
there.
Let
me
show
you
something
we
have
seen
in
the
infrastructure
repository
that
there
are
environments
there
for
the
infrastructure,
but
those
environments
were
not
very
interesting
for
us.
Unlike
in
the
delivery
aspect,
we
can
already
have
a
kubernetes
overview
of
that
specific
namespace
that
we
are
interested
at
in
this
case.
A
This
is
the
production
deployment
and
its
flux,
reconciliation
status,
and
similarly,
we
have
one
for
the
development.
It
will
be
exactly
the
same
in
this
case,
so
there's
nothing
to
to
look
at,
but
you
got
the
idea.
We
can
easily
have
a
very
quick
view
of
what's
happening
in
the
cluster
and
this
is
not
for
infrastructure
Engineers.
This
is
more
for
the
application
operators
for
the
users
of
a
platform
team.
A
Your
internal
developing
teams,
mostly
this
seem
these
same
views-
can
be
set
up
later
in
the
application
project
as
well,
because
the
agent
is
shared
with
that
project
as
well,
as
you
have
seen
before
here.
I
already
created
only
created
two
cluster
Dev
and
the
production
cluster,
and
you
have
the
same
exact
same
insights
in
these
projects
too.
Okay
and
now,
let's
go
to
next
video,
where
I
will
speak
about
how
your
developers,
the
applications
owners,
can
actually
use
these
processes
and
deploy
a
new
version.