►
Description
Enabling workload portability across cloud and On-Prem with Containers, Kubernetes, and Knative is half the battle when modernizing applications into Cloud Native solutions. The other half is operating cross-functional teams in a Cloud Native way with GitOps principles.
During this webcast, you will learn how to use GitLab on Anthos, configure your first CI/CD pipeline to deploy apps to any GKE cluster, and set up your Source Code Repository with appropriate config files for all administrative policies that can be applied to your Kubernetes clusters both on-premises and in the cloud.
A
A
Yeah
so
today
we're
really
just
going
to
give
a
high-level
overview
of
amphos
and
gitlab
and
how
we
can
use
them
together
to
really
deliver
a
smooth
and
consistent,
get
ops
experience.
And
so
teo
is
going
to
give
us
a
demo
of
seeing
that
in
action
with
a
sample
project
that
he's
put
together,
that's
running
on
gitlab
and
then
we'll
talk
about
some
key
takeaways
and
what
this
means
and
setting
that
up
and
then
really
how
to
get
started.
Who
to
reach
out
to
how
to
get
some
more
information
on
implementing
this
yourself.
A
There
are
a
few
building
blocks
that
we're
putting
together
to
create
this
solution,
and
so
we're
really
starting
with
containers
and
really
that's
the
smallest
unit
of
this
puzzle
that
we're
gonna
that
we're
piecing
together
and
that
really
your
your
code
and
your
application
logic
is
gonna,
live
within
a
container,
and
that
is
going
to
help.
You
make
workloads
portable,
make
them
be
consistent,
easy
to
version
and
and
easy
to
deploy
to
infrastructure
and
the
containers
basically
roll
up
into
kubernetes.
A
And
you
know,
if
you're,
using
kubernetes,
currently,
if
you're,
if
you're
leveraging
that
that
kubernetes
provides
a
lot
of
orchestration
and
management
of
your
clusters.
But
a
lot
of
times
as
your
application
can
grow
and
as
your
infrastructure
expands,
kubernetes
becomes
a
whole
other
platform
and
system
that
needs
to
be
managed
and
administrated
and
configured
and
also,
as
you
start,
to
spool
up
multiple
clusters
depending
on
environments
or
needs
around
deployments.
Internal
external
again,
we're
just
adding
complexity
onto
something
that
already
has
a
lot
of
individual
moving
pieces.
A
A
And
then
you
can
deploy
your
application
to
different
cloud
providers
or
an
on-prem
kubernetes
cluster
and
then
you're
still
able
to
provide
policy
enforcement
configuration
management
across
those
different
clusters
and
that
way
you're
having
a
unified
and
consistent
experience.
Really,
regardless
of
what
infrastructure
you're
using
whether
that's
aws
or
google
cloud
environment
or
really
whoever
you're
deploying
to
and
so
really
what
ties?
A
So
we
talked
about
github.
So,
let's
talk
about.
Why
do
we
want
to
use
github?
What
do
we
get
out
of
utilizing
githubs?
So
there's
a
couple
of
different
components
that
we're
getting
here.
So
we
get
reliability
once
we've
defined
a
configuration
or
a
security
policy
that
lives
in
git,
and
it
can't
be
changed
without
whatever
approval
process
you'd
like
to
put
around
that
and
there's
no
secret
changes
or
stealth
changes.
A
A
B
Thanks
kurt
so
in
in
in
the
demo
that
I
going
to
show
you,
we
are
using
three
main
components:
the
first
one
is
gitlab,
of
course,
and
that's
at
the
core
of
of
everything
and
every
user
interaction
that
we
are
going
to
have
almost
every
user
interactions
that
we're
going
to
have
is
with
with
gitlab
the
next
component
that
we're
going
to
use
is
enforce.
Config
management
so
enforce.
Config
management
is
a
product,
that's
part
of
enforce
and
it's
a
github-slide
product
to
manage
your
configuration
and
policies.
B
The
second
the
the
last
tool
that
we're
going
to
to
show
you
is
called
application,
delivery
manager
or,
and
the
cli
is
called
abcdl,
I'm
going
to
use
both
of
those
words
and
abstitle
so
enforce.
Config
management
is
ready,
githubs
for
config
and
policies
and
app
ctrl
is
really
githubs
for
applications
and
with
abctl.
You
have
one
application
repository
and
that's
one
that
you
already
have
today.
B
Okay,
that's
where
your
your
source
code
leaves
your
python,
your
your
golang,
your
java
whatever,
and
you
have
another
repository,
called
deployment
repository
and
that's
where
all
your
communities
configurations
for
that
that
application
of
that
application
are
going
to
leave
and
ab
ctl,
I'm
going
to
dip
a
bit
deeper
into
that.
But
app
ctl
makes
the
link
between
those
those
two
ripples
and
is
going
to
build
those
kubernetes
configurations,
and
it's
going
to
help.
B
The
first
one
is
called
configsync
and
is
actually
available
for
free
outside
of
enforce
config
sync
reads:
configurations
and
policies
from
a
git
repository
in
our
case
gitlab
and
applies
those
configurations
and
policies
to
kubernetes
clusters
and
those
configuration
policies
can
be,
as
I
said
like
either
like
airbag
network
policies.
Everything
that
that
you
need
to
run
your
platform
in
in
general.
B
Then
you
have
another
component
called
policy
controller
policy
controller
is
a
managed
version
of
an
open
source
project,
called
open
policy,
agent,
gatekeeper
and
that's
really
a
web
administ
a
web
admission,
an
admission
admission
web
book
for
humanities,
meaning
that
you
can
write
policies
with
four
policy
controller
that
say:
okay.
I
want
all
my
deployments
to
have
a
specific
label.
B
So
really,
you
have
one
part
config
sync
for
applying
stuff
and
policy
controller
for
controlling.
What's
what's
getting
applied,
and
the
last
the
last
component
that
I'm
not
actually
going
to
show
in
that
in
the
demo
is
called
config.
Connector
and
config
connector
makes
the
link
between
all
of
that
and
the
broader
gcp.
B
So
you
can
define
gcp
resources
such
as
a
cloud
sql
instance
for
mysql
or
postgres,
for
example,
as
the
kubernetes
custom
resource
and
config
connector
is
going
to
create
and
manage
that
resource.
For
for
you,
based
on
that
humanities,
customer
resource
and,
of
course,
because
it's
given
this
customer
resource,
you
can
apply
policies
on
them
based
on
policy
with
policy
controller,
so
enforce.
Config
management
is
a
globally
available
product.
It's
part
of
enforce
and
and
those
different
subcom
components
have
various
status
and
are
available
as
different
pieces
elsewhere.
B
The
second,
the
second
part
of
the
demo,
is
the
github's
workflow
for
applications.
So
that's
with
app,
ctl
and
and
the
workflow
can
be-
can
seem
a
bit
complex,
but
it's
actually
not
that
not
that
com
complicated.
So
as
a
developer,
you're
going
to
develop
your
application
as
usual.
Okay
and
you
do
merge
requests,
then
you
run
tests
and
you
do
code
review.
B
Everything
is
normal
and
when
you
want
to
release
a
version
of
your
application,
then
you're
going
to
tag
your
application
repository
with
the
tag
that
you
want:
1.2.3,
whatever,
okay
and
once
that's
done,
and
you
want
to
release
your
application
to
a
pre-production
environment.
In
our
case
it's
called
staging,
but
you
can
call
those
environments.
However,
you
want
you
run
that
command
absolutely
prepare
staging
and
what
that.
A
B
This
is
those
are
like
diagrams
of
your
two
git
repositories
for
that
whole
workflow.
So,
on
the
left,
once
again
we
have
the
application
repository
and
that's
really
a
normal
application
repository
where
you
have
commits
you
have
merge
requests
and
you
are
going
to
tag
things
and
in
that
repository
you
have
your
source
code
and
you
have
basically
the
templates
for
your
humanities,
kubernetes
configurations
when
you
run
abctl
prepare
staging.
B
We
create
a
merge
request
on
the
staging
branch
of
the
deployment
repository
okay,
using
the
kubernetes
configurations
from
the
tag,
the
last
stack
that
you
created
okay
and
once
you
merge
that
merge
request.
That's
this!
This
red
commit
here,
you
can
run
abctl,
apply,
staging
and
that's
going
to
deploy
that
and
when
you
run
abstitle
prepare
pod
from
and
staging,
then
you
create
a
merge
request
on
production
branch.
B
B
Do
you
have
my
my
demo
screen
live?
I
think
you'd.
Please
tell
me
if
I
could
yep
so
it
looks
good
okay,
so
we
are
starting
with
the
enforce
config
config
management
part,
so
the
configs
and
policies
part
of
the
demo.
Okay,
on
the
left.
Here
I
have
two
google
kubernetes
engine
clusters,
one
for
prod
and
one
for
staging
we're
currently
in
u.s
central
one,
and
you
can
see
that
I
have
different
cluster
size,
etcetera,
etcetera
on
my
local
terminal.
Here
I
get,
I
have
access
to
those
clusters.
B
In
that
case
I
have
access
to
my
staging
cluster
with
two
nodes:
yeah.
Okay.
So
the
first
thing
that
I'm
going
to
show
you
is
this
repository,
so
you
can
see
it's
still
on
gitlab.
It's
called
enforce:
config
management,
okay!
So
that's
the
repository
where
all
my
configuration
and
policies
live
and
in
that
repository
you
have
different
directories
that
you
can
use
for
different
things.
But
a
few
that
I
want
to
point
out.
Are
this
one
cluster
registry?
B
You
are
not
going
to
apply
the
same
thing
to
all
clusters
and
that's
why,
for
example,
on
my
cluster,
I
put
a
label
saying
that
this
is
in
the
environment
pod
and
then
I
can
differentiate
between
environments
or
anything.
I
want
him
and
then
I
have
the
namespaces
directory
and
that's
where
I'm
going
to
define
namespaces
that
are
going
to
be
created
everywhere.
I
want,
and
so
for
example.
B
That
namespace
already
exists
on
my
on
my
cluster.
You
can
see
it
the
hello
world
namespace.
Yes,
my
application
is
an
helloworld
application
because
I'm
not
really
a
very
good
developer.
So
on
that
github
repository,
I
already
have
a
merge
request
created
okay,
so
let's
let's
get
there
and
that
merge
request.
B
So
I
want
basically
all
my
deployments
to
have
a
team
label
and
as
a
platform
administrator
that
allows
me
to
know
from
which
team
each
deployment
comes
from
which,
if
you
have
many
application
teams,
that
can
be
quite
useful
to
know
and
because
this
is
a
gitlab
merge
request,
we
can
actually
use
gitlab
ci
to
test
all
of
that
and
we
have.
We
have
a
pipeline
that
has
already
run
because
I
created
that
match
request
a
couple
of
days
ago,
and
you
can
see
that
I
have
a
few
steps
here.
B
What
we
are
doing
here
is
that
we
we're
taking
all
the
configs
that
we
have
in
that
repository
all
the
policies
and
which
we
are
checking
that
our
configs
are
actually
compliant
with
the
policies
that
we
have
within
inforce
config
management
itself,
which
is
the
first
step
of
actually
being
compliant
and
running.
That
test
here
allows
you
to
catch
policy
violations
directly
during
the
the
creation
of
those
configs
and
those
policies
before
they
actually
reach
any
cluster,
be
developed,
staging
or
whatever.
B
It
allows
you
to
sh
to
shift
all
of
that
left
to
shift
all
that
security
left
and
to
have
much
faster
iterations
on
on
those.
So,
let's
get
back
at
the
merge
request,
so
you
may
have
noticed
that
enforce
configure
management
is
a
fairly
powerful
product.
Okay,
with
enforce
config
management
configured
the
right
way.
B
So,
for
example,
you
may
have
you
may
want
the
platform
team
to
have
a
saying
that
you
may
want
the
security
team
to
have
a
saying
that
and
that's
where
really
shines,
also
because,
for
example,
we
are
going
to
use
the
approval
features
of
gitlab
to
make
sure
that
everyone
who
needs
to
approve
that
change
is
going
to
approve
the
change.
So
in
our
case,
I
just
put
a
curtain
myself
as
approval
approvers,
but
really
you
can
add
the
security
team
and
the
infra
team,
etc,
etc.
So
I'm
just
going
to
approve
and
merge.
B
We
start
there's
no
such
constraint
in
my
cluster,
but
in
a
few
seconds
you're
going
to
see
it
appear,
because
I
just
merge
on
my
master
branch
and
and
and
enforce
config
management
constantly
reads
from
that.
That
repository
and
applies
it
and
you
can
see
it.
It
just
appeared
on
my
cluster
okay.
So
now
my
policy
saying
that
all
deployments
need
a
team
label
either
is
applied
across
all
my
clusters
at
once.
B
B
So
I
have
this
very
simple
application:
it's
an
hello
world
application
and
it's
in
python
and
it's
a
flask
application
and,
as
you
can
see,
it's
really
simple
it
just
written
returns,
an
hello
world
message
on
the
home
page
and
I
can
customize
that
message
with
an
environment
variable.
Okay,
I
have
a
docker
file
that
packages
that
application
inside
a
container
image
that
I'm
I
want
to
be
able
to
deploy
as
a
developer
to
different
environments.
B
So
that's
the
part
where
we
start
with
with
abcdl.
So,
as
a
developer,
I
want
to
be
able
to
deploy
that
application
to
the
staging
environment
into
the
prod
environment.
So
the
first
thing
I'm
going
to
do
is
initialize
my
application,
okay
with
app
ctl,
so
I
run
absolutely
init
the
name
of
the
application,
and
then
I
give
it
the
advice.
The
github
address
of
my
application,
so
fair
warning
and
then.
B
So
I'm
just
going
to
add
that
to
my
ssh
agent,
otherwise
it's
going
to
be
a
bit
boring.
Okay,
and
now
it's
asking
me
if
I
want
to
create
the
deployment
repository.
So
that's
a
fully
separate
repository
where
all
my
full
kubernetes
configs
are
going
to
leave
and
I'm
going
to
say
yes
and
app.
Ctl
is
going
to
create
that
form.
B
B
B
For
pod
and
now
in
my
delivery
directory,
I
have
my
two,
my
two
environments,
that
that
are
here
in
the
config
in
the
config
directory.
So
that's
where
my
kubernetes
configs
are
going
to
live.
I
also
have
my
environments.
So
if
I
look
at
this
customization
file
for
pod,
we
see
that
actually
looks
for
configs
in
the
base
directory
and
that's
currently
empty,
because
I
haven't
defined
anything
so
just
to
make
things
quicker.
I'm
going
to
copy
over
some
existing
configurations.
B
B
The
one
thing
that
you're
going
to
notice
is
that
I
don't
have
any
image
tag
here:
okay
and
I
have
a
service,
that's
just
creating
a
load
balancer
and
in
my
customization
file
I
say
I'm
using
that
deployment
that
service
and
I'm
also
overriding
the
image
that
the
image
tag
that
I'm
going
to
use.
In
that
case,
I'm
just
going
to
use
0.0.1
and
if
we
take
a
look
at
our
environments,
so
we're
still
using
the
base
config.
B
So
I
have
one
yeah
running
and
we
have
a
couple
of
things
here
happening
the
first
ones
that
I
want
to
show.
You
are
fairly
standard,
so
I
have
a
lint
linting
job
going
on
and
a
unit
testing
job
going
on.
So
if
I
just
take
a
look
at
the
linting,
for
example,
it's
it's
just
starting
and
if
I
take
a
look
at
the
unit
tests.
B
And
once
those
those
finish
running,
they're
actually
actually
going
to
show
the
results
here
in
gitlab
jack.
That's
like
a
very
nice
feature
of
gitlab
ci,
and
we
can
see
here
that
I
have
a
third
test
that
just
failed
validate.
So
let's
take
a
look
at
that,
so
we
have
an
error
here
that
says
that
all
deployments
must
have
a
team
label
and
that
should
ring
a
bell
because
that's
the
policy
that
we
just
defined
in
the
first
part
of
the
demo
as
a
platform
is
administrator.
B
It
says
that
every
deployment
must
have
a
team
label
and
I
don't
have
a
team
label.
I
just
showed
you
the
the
the
deployment
file.
I
don't
have
anything
here,
okay,
but
how
did
that
end
up
here?
So
it's
actually
fairly
neat.
So
if
I
take
a
look
at
the
previous
job
here,
we
actually
downloaded
all
the
policies
directly
from
the
enforce
configmed
management,
git
repository,
okay
and
we're
running
our
application
configs
against
those
policies
to
make
sure
that
our
application
is
compliant
with
the
policies
before
it
even
hits
any
development
or
staging
environment.
B
And
how
did
that
end
up
in
my
ci
pipeline?
That's
also
very
neat.
If
I
take
a
look
at
my
ci
pipeline
here,
you
can
see
that
I'm
using
the
include
feature
of
gitlab
ci,
where
I
just
point
gitlab
ci
to
that
secondary
gitlab
ci
file
that
comes
from
directly
from
enforce
config
management.
So
my
platform
team
has
basically
given
me
a
ready
to
use
policy
check
for
my
application.
Okay,
I
don't
have
any
job
to
define.
B
Actually
you
can
see,
I
don't
define
the
validate
job
in
that
in
that
gitlab
ci
file,
I'm
just
using
what
the
platform
platform
team
has
given
me,
and
I
can
very
quickly
make
sure
that
my
application
is
compliant
with
any
policies
that
my
organization
may
have.
Okay,
so
let's,
let's
fix
that
policy
violation
and
to
fix
that
I'm
just
adding
the
right
labels,
labels
team
and
I
need
it
to
match.
B
B
B
B
Okay,
so
I
have
a
new
job,
a
new
pipeline
running
and
a
spoiler
alert.
This
one
is
going
to
succeed.
Okay,
so
while
that's
running,
let's,
let's
move,
let's
move
forward.
So
now
that
I
have
fixed
my
policy
violations
and
that
I
have
successfully
tested
my
my
application,
everything
is
fine.
I've
built
a
docker
image
that
last
step
here
is
building
and
pushing
the
docker
image.
B
Deploy
so
it's
going
to
read
from
my
hello
world
repository
check
that
I
indeed
have
a
0.0.2
tag
and
then
it's
actually
creating
a
merge
request.
You
know
you
can
see
it,
but
it's
not
creating
that
match.
Request
in
the
hello
world
repository
it's
creating
it
in
the
hello
world
deployment
repository,
which
is
a
new
repository
that
was
created
when
I
run
aptl
in
it.
So
let's
take
a
look
at
that
merge
request
so
that
match
request.
Once
again,
we
are
in
the
hello
world
deployment
repository
here,
not
the
hello
world
one.
B
So
that's
the
repository
used
to
actually
deploy
stuff
so
we're
creating
a
merge
request.
We
have
a
merge
request
to
to
be
merged
into
the
staging
branch
because
we
want
to
deploy
to
the
staging
environment
and,
let's
take
a
look
at
the
changes,
and
I
have
my
full
deployment
here:
okay
and
my
full
service-
and
you
can
see
that
I
have
my
new
tag
and
I
have
the
the
custom.
A
B
B
So
that's
going
to
take
what's
on
my
staging
branch
on
the
deployment
repository
and
apply
it
on
my
staging
cluster
and
because
this
is
a
merge
request,
we
can
actually
implement
approval
workflows
for
specific
branches.
So
if
I
don't
want
anyone
to
be
able
to
merge
to
production,
I
can
just
put
an
approval
on
that
use.
The
code
owners
features
all
kinds
of
all
kinds
of
stuff.
We
can
actually
once
again
run
tests
on
those
configurations.
If
you
want
at
that
stage,
we
can
do
all
kinds
of
things.
B
So
absol
is
now
connecting
to
the
staging
cluster
and
is
deploying
my
application.
So
if
we
get
back
to
the
gcp
console
here,
we
actually
have
an
applications
page
and
if
we
take
a
look
at
that,
we
have
our
hello
world
application
in
staging
okay,
with
my
two
components:
the
deployment
and
the
service-
and
I
have
my
version
history.
So
I
have
a
single
version
for
now,
but
if
I
deploy
another
version
it's
going
to
to
get
here
and
if
we
take
a
look
at
our
services
and
we
filter
by
namespace.
B
C
B
B
So
this
is
really
the
end
of
the
demo.
We're
just
going
to
wait
a
few
seconds
for
for
that
to
finish
so,
what
I
want
to
to
say
is
that
so
enfo
enforce
config
management
is
really
for
deploying
configuring
policies.
The
main
users
of
that
are
going
to
be
platform
administrators,
but
that's
going
to
allow
everybody
to
collaborate
on
on
configuring
policies
with
developers,
platform,
admins
security,
team,
etc.
Using
like
the
usual
git
lab,
workflows
and
app
ctl
is
a
really
designed
for
application
developers
to
deploy
their
app
by
the
way.
B
B
A
Great,
thank
you
too.
Thanks
for
putting
that
together,
it
was
a
good
walk
through
and
and
really,
let's
break
down
a
little
bit.
What
we
saw
so
really
we're
looking
at
anthos
handling,
get
ops
and
we
talk
about
get
opposites,
we're
piecing
together
using
git
and
and
versioning
of
your
configurations
and
manifests
to
really
drive
consistency
in
your
operations.
So
it's
more
just
like
we
create
we
use
version,
control
and
git
to
create
consistency
around
multiple
people
contributing
to
a
software
project.
A
We
can
apply
that
and
expand
it
to
policy
of
deployments,
versioning
of
deployments
environments
for
deployments
and
really
we
use
amphos
to
do
that
and
by
putting
emphos
kind
of
as
the
mid
layer
across
all
of
our
kubernetes
clusters.
We
get
that
consistent,
get
driven
experience
for
managing
changes
to
our
configuration
and
really
we're
using.
So
we
have
git
at
the
core
and
get
labs.
Ui
and
ux
enables
more
features
around
git,
so
we
get
versioning
of
files,
but
we
also
get
from
git
lab
collaboration.
A
Around
changes,
as
we
saw,
merge,
requests,
merge,
requests
approvals
and
then
you
know
additional
policies
and
tooling.
We
want
to
place
around
specifically
how
we
make
those
changes,
how
we
implement
those
changes
who
can
approve
those
changes
within
gitlab?
You
know
discussing
what
the
nature
of
those
changes
are
being
able
to
reason
about.
A
You
know
we
can
extend
this
entire
approach
to
again
how
we
deploy
and
develop
and
release
all
of
our
applications.
So
configurations,
policy
and
security
are
all
tightly
bound
in
one
place,
and
we
have
a
very
easy
to
follow.
Audit
trail
of
every
change
that's
made,
who
made
that
change?
Who
approved
that
change
when
the
change
was
introduced
into
production
or
whatever
the
infrastructure
was,
and
that
just
gives
us
more
clarity
around
what
our
devops
experience
is
going
to
be.
A
They're
great
partners
within
the
google
ecosystem
and
also
arctic
very
knowledgeable,
get
lab
service
providers
and
partners
who
can
certainly
help
you
get
up
to
speed,
and
we
also
have
some
additional
resources
in
terms
of
really
just
links
and
other
places
to
get
a
lot
of
this
information
that
you
can
find
either
within
our
website
on
gitlab.
Within
you
know,
on
google,
we
have
some
documentation
around
anthos
config
management.
A
How
to
implement
anthos
managing
your
specific
applications,
how
to
leverage
app
ctl
in
a
proper
development
pipeline
so
as
as
teo
mentioned,
appctl
is
is
available,
but
it's
not
a
generally
available
stable
release.
So
it's
it's
certainly
on
its
way
to
full
ga
maturity
and-
and
it's
currently
at
a
at
a
location
at
a
place
in
the
development
process,
where
we're
collecting
feedback
and
looking
how
to
implement
and
iterate
on
those
pieces
of
feedback
to
deliver
a
real
production
level
application.
A
C
All
right,
thank
you
very
much
and
theo
and
kurt
for
your
presentation
and
for
the
demo
yeah.
We
still
have
a
few
minutes
left
for
the
q,
a
so
I
would
say,
let's
start
right
into
it.
The
first
question
that
I
have
is:
what
are
the
advantages
of
yeah
playing
together,
enforce
with
terraform
or
polumi,
and
how
does
it
work
in
the
end?
Is
it
working.
B
It
depends
on
what
you
want
to
do
with
telephone
and
terraform,
and
pull
me
so
enforce
is
really
based
on
on
kubernetes.
So
you
have
many
different
different
parts
of
enforce,
but
the
core
of
it
is
always
humanities
and
if
you
want
to
use
terraform
or
polumi
to
manage
resources
within
humanities
within
an
enforced
humanities,
cluster,
that's
definitely
possible
and
we
have
customers
doing
that.
B
You
can
also
use
terraform
and
polumi
to
match
the
enforce
resources
themselves.
If
the
providers
are
available,
that's
that's
definitely
possible
and
and
for
example,
if
you
are
using
enforce
on-prem,
which
currently
runs
on
vmware
you
can.
You
can
use
those
the
terraform
vmware
provider,
for
example,
to
manage
those
resources.
B
C
B
Very
good
question:
so
actually,
yesterday,
google
cloud
introduced
a
new
nation
called
environs
which
allows
you
to
group
clusters
by
environment
and
to
apply
so
instead
of
syncing
all
your
clusters
on
to
the
master
branch
at
once.
The
the
idea
behind
that
is
that
you're
going
to
say:
okay,
my
production
clusters.
B
I
want
them
to
synchronize
on
this
specific
tag
or
this
specific
commit
and
all
my
non-production
clusters
onto
that
other
tag
and
then
so
that's
the
first
of
the
first
place
where
you
can
control
what
gets
applied
where
exactly
and
then
you
can
use
all
the
powerful
features
of
git
lab,
some
of
which
we
showed
today
to
actually
control
who
can
merge
onto
those
branches
at
which
time
so
approvals.
The
approvals
in
the
merge
request
is
one
such
feature,
but
you
can
also
use,
for
example,
the
code
owners
feature
to
to
say.