►
From YouTube: Webinar: Setting up Heroku git-push workflow on your Kubernetes cluster in 60 seconds with Gitkube
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
The Heroku workflow around being able to deploy microservices with a “git push” and scaling applications was revolutionary for developers. Gitkube makes it possible for developers to achieve the same GitOps workflow but on any Kubernetes cluster. In this webinar, you’ll learn how to setup Gitkube on any Kubernetes cluster without requiring any 3rd party dependencies.
This webinar will cover:
- Setup and installation of Gitkube on a Kubernetes cluster
- Deploying a microservice with a Dockerfile and Kubernetes manifests with git-push
- Monorepo configurations with multiple microservices and Kubernetes manifests
- Multi-repo configurations with different microservice repos
- Using helm charts instead of Kubernetes manifests
- Deployment access control using SSH keys and Kubernetes RBAC policies
A
Alright
looks
like
the
number
has
stabilized
so
we'll
go
ahead
and
get
started.
Welcome
to
today's
CNF
webinar
setting
up
Heroku
git
push
workflow
on
your
kubernetes
cluster
in
60
seconds,
with
git
cube,
I'm,
Kaitlin,
Barnard's
marketing
manager
at
CNCs
and
I'd
like
to
thank
everyone.
Who's
joining
us
today
and
I'd
like
to
give
a
warm
welcome
to
Tom
by
Gopal,
whose
co-founder
at
Co
Sarah
who's
our
presenter
today,
and
we
really
appreciate
how
sharing
his
expertise
on
get
key
with
everyone.
So
just
a
few
housekeeping
items
before
we
get
started
so
during
the
webinar.
A
You
are
not
able
to
talk
in
this
attendee,
but
there
is
a
chat
window
at
the
bottom
with
the
QA
function.
You
know,
please
feel
free
to
drop
any
questions
in
there
that
you
have
and
we'll
get
to
as
many
as
we
can
at
the
end.
Also,
the
session
is
being
recorded
and
I
will
send
that
out
afterwards,
along
with
the
link
to
the
presentation,
keep
an
eye
out
for
that
and
your
email
within
the
next
24
hours,
and
with
that
I'll
hand
it
over
to
Tom
way
to
get
started.
B
Thank
you,
occasional
intro,
hi
everybody
I'm
going
to
talk
about
git
cube
today
and
setting
up
get
you.
The
demo
itself
is
60
seconds
long.
So
this
is
going
to
be
a
short
webinar.
No
I'm
I
mean
I'm
gonna
talk
a
little
bit
about
how
good
Cube
works
as
well
and
be
the
way
get
cube
works
and
how
you
can
kind
of
also
use
get
cube
for
doing
stuff
that
for
customizing
your
own
workflows
with
git
push
and
then
I'm
going
to
do
an
end
with
the
gate
cube
demo.
B
So
this
is
still
going
to
be
a
fairly
short
but
not
but
after
they
said
back
so
many
questions
that
you
may
have
so
before
I
jump
in.
Let
me
just
quickly
give
you
a
brief
introduction.
I
am
one
of
the
founders
at
Hofstra
at
I/o
we
build
application
development
platform
on
kubernetes
and
we
also
build
a
draft
well
engine
for
existing
post
class
databases.
B
We
started
using
humanities
a
fairly
long
time
ago
and
our
entire
platform
is
to
actually
be
an
operator
which
would
basically
take
which
would
basically
take
kubernetes
config
maps,
and
it
would
actually
listen
to
changes
on
config
maps
and
then
apply
them
to
at
that
time.
Replica
sets
so
which
this
pattern
got
stabilized
and
the
idea
was
to
call
this
an
operator
or
controller
and
config
mastery
place
to
the
idea
of
customer
resources.
B
One
of
the
things
that
we
built
early
on
was
a
workflow
to
help
deploy
applications
and
that
that
today
is
get
queue.
The
idea
behind
the
get
push
workflow
is
that
this
is
primarily
for
developers
because
for
developers,
the
idea
of
not
having
to
worry
about
how
deployment
works
or
not
having
to
use
cube,
CTL
or
cube
control,
I
contacted
CTL.
It's
not
really
important,
so
developers
can
just
do
a
git
push
and
then
developers
can
apply.
B
But
then
who
did
this?
This
was
very.
This
was
revolutionary
for
developers
because
they
were
just
like
hey.
You
know
what
I
can
do.
I
can
just
do
a
git
push,
Heroku
master
and
wherever
my
source
code
is
at,
the
current
commit
will
get
deployed.
I,
don't
care
how
it
gets
deployed,
I,
don't
care
I,
don't
care
how
routing
works,
I,
don't
care
how
the
load
balancing
works,
I,
don't
care
beyond
the
configuration
that
I've
specified
saying
that
you
know
this
should
be.
B
This
should
be
then
replicas
of
the
shudra
node
2
GB,
damn
container
or
the
shoot-down
or
512
mb
ram
container.
I
don't
care
beyond
that
and
then
just
take
my
code
and
deploy
it
so
and
that
kind
of
work
through
today
can
be
replicated
by
everybody
using
just
cube,
CTL
and
keep
it.
So
you
can
find
a
set
of
your
own.
B
Get
push
style
workflows
just
like
just
like
Heroku
gave
you
and
you
can
set
that
up
or
you
can
set
it
up
for
your
developers
and
you
can
even
customize
it
and
just
by
using
these
two
tools.
So
I
really
like
the
idea
of
a
git
push
little
bit
because
of
this
slightly
pixelated
diagram,
which
basically
says
how
whether
I
really
like
the
idea
that
get
is
kind
of
that
surface
below
which
ops
folks
can
kind
of
do
that.
Automation
and
above
which
developers
work
right.
So
developers
only
need
to
use
their
own
tools.
B
Developers
only
need
to
use
git,
and
they
don't
I
mean
they
work
developers,
work
we'll
just
like
with
comics
or
branches
or
release
right
and
and
that's
the
kind
of
understanding
of
the
system
and
whenever
deployment
happens
either
by
you
know,
pushing
directly
to
the
kubernetes
cluster
or
webhook
or
two
particular
git
repository,
which
is
automatically
synchronized
with
your
kubernetes
cluster,
that
that
process
is
actually
relevant
only
to
the
ops
team
and
how
the
ops
team
actually
implements
that
right.
So
how
the
git
push
works
and
making
that
work.
B
Well
is
an
ops
concern,
but
but
using
it
and
using
it
to
do
trivial
tasks
like
plummet
is
kind
of
the
DEF
concern.
So
so
that's
a
nice
boundary
to
have-
and
you
know
maybe
that
kind
of
Billy
emerge-
is
the
stable
boundary
going
forward.
So
the
way
you
can
make
push
work
on
a
kubernetes
cluster,
but
to
kind
of
different
ways
of
doing
it.
The
Heroku
way
of
doing
it,
which
is
also
to
give
you
a
way
of
doing
it,
is
basically
by
having
is
not
by
having
any
external
dependency.
B
So
it's
the
diagram
that
you
see
on
the
left
here
and
the
idea
here
is
that
hey
you
know
what
I
can
I
have
my
machine
I
have
get
here
and
I'm
just
going
to
do
a
git
push
to
this
cluster,
and
so,
if
I
do
get
pushed
cluster
master,
my
quad
should
get
deployed
and
this
actually
works
using
git
hooks
because
on
the
cluster
is
there's
also
a
git
server
gift.
A
gift
server
is
not
a
technically
accurate
term,
but
there's
something
like
a
git
server.
B
So
that's
those
are
the
broad
ways
of
doing
it.
In
this
case,
you
need
an
external
agent
which
has
access
to
your
tinnitus
cluster
and
allows
you
to
kind
of
group
pipelines
in
this
case
it's
more
decorative
and
you're,
just
using
it
as
the
source
of
truth.
There
are
no
sequence
of
steps,
but
you
don't
need
a
third
party
and
if
you
don't
need
any
dependency
of,
you,
don't
need
to
give
access
to
anything
outside
of
wisdom.
B
The
way
this
would
have
worked
or
the
way
this
works
is
that
when
I
do
get
pushed
there's
a
docker
file,
it
gets
back
to
the
comment
and
once
the
raca
file
is
built
into
docker
image,
there
is
a
deployment
step
that
happens
that
rolls
this
deployment
out
right.
So,
if
I
look
at
it
before
the
git
push,
workflow
I
would
have
done,
and-
and
this
is
exactly
what
the
people's
workflow
is,
I
would
have
done.
B
A
docker
build
and
so
I
would
have
done
a
docker
build
in
my
in
my
in
my
in
my
repository
I
would
have
done
a
docker.
Build
I
would
have
tagged
it
with
the
name
of
my
registry,
then
I
have
and
then
I
would
have
packed
with
the
comment
or
tag
to
the
release
version
and
after
that,
I
would
have
done
a
docker
push,
and
once
the
proper
push
is
done,
I
would
have
done
a
chip
CTL
set
image
where
I
would
have
changed
the
image
of
the
deployment
where
this
image
is
being
used
right.
B
So
these
are
the
three
steps
that
I
would
have
done
or
I
would
have
used
some
kind
of
592
and
these
three
steps
get
coalesced
into
git
push
cluster
master
or
def
master
right.
So
that's
kind
of
that's
kind
of
what
the
that's
kind
of
what
the
experience
for
the
developer
is
going
to
be,
which
is
just
doing
a
git
push
which
actually
is
exactly
equivalent
to
doing.
A
B
Right
so
every
get
ripple.
Actually,
if
you
go
into
the
game
directory,
if
you
wanted
a
lot
of
it
directly,
you
see
a
bunch
of
sample
hooks
right
and-
and
these
are
hooks
on
the
different
events
that
you
have
on
a
fly
patch
and
comment
on
update
on
on
comment
or
push
on
debase
and
receive
right.
So
you
can
customize
any
of
these
behaviors
and
I'm
just
going
to
stop
my
video,
so
right,
yeah,
and
so
you
can
kind
of
customize
any
of
these.
B
B
Similarly,
there
are
server-side
hooks
which
are
basically
hooks
that
execute
when
I
do
a
push
to
the
Dumond,
so
let's
say
I'm
doing
a
git
push
to
a
git
remote.
There
is
a
get
kind
of.
There
is
instances
get
that
is
kind
of
sitting
there
remotely
and
when
I
do
that
git
push
and
when
there
is
that
kind
of
RPC
that
happens,
get
can
also
execute
pre
receive
and
post
receive
hooks.
So
the
the
Bri
push
hook
on
the
client
happens
before
the
gift
push
actually
happens.
B
So
it's
the
script
and
executed
before
they
get
pushed
that
happens
on
the
client
side,
then,
on
the
server
once
the
push
is
being
received
before
the
push
is
applied.
The
client,
the
server
can
execute
a
bunch
of
actions
which
is
the
pre
receive
set
of
actions
and
then
once
the
git
push
is
done,
where
the
objects
are
actually
taken
and
put
it
in
the
file
system.
The
git
commit
is
kind
of
received.
The
serve
will
then
execute
a
bunch
of
post
receive
steps.
So
that's
that's
the
post
as
you
cook.
B
Now,
if
you
look
at
pre
push
and
Piranesi
these,
if
your
scripts
have
an
error,
they
can
actually
abort
the
bush.
But
if
you
make,
if
your
script
actually
throws
an
error
in
the
post
receive
step,
you
can't
abort
the
portion
right.
So
so
these
detox
have
always
been
around
and
gives
you
a
lot
of
customizability
in
the
git
workflow
that
you
set
up-
and
this
is
a
nice
surface
area
for
doing
a
little
bit
of
automation
right.
B
Ultimately,
we
have
a
deployment
right,
so
the
ultimate
task
is
to
kind
of
update
this
deployment
because
of
things
or
changes
to
the
source
code
or
the
manifest
files
that
what
I
would
need
for
this,
obviously,
is
that
I
would
want
to
do
a
git
push,
and
that
means
that
I
need
some
kind
of
a
gift
remote,
that's
sitting
here
and
receiving,
get
pushes
and
then
applying
into
the
deployment
right.
So
this
is
the
agent
that
does
the
hard
work
of
actually
building
the
container
image
and
of
making
the
kubernetes
deployment
right.
B
So
how
do
I
get
access
to
so
this
obviously
has
to
be
exposed
to
external,
and
this
means
some
kind
of
access
control,
because
it's
get.
We
can
use
a
search
key
based
access
control.
So
we
can.
We
can
program
this
remote
to
only
receive
the
pushes
from
a
valid
from
a
bunch
of
value
in
the
search
keys
or
a
bunch
of
authorized
keys
and
that's
kind
of
what
the
simplest
one
flow
would
look
like.
But
if
you
think
about
it,
this
means
to
have
a
little
bit
of
conjugation
right.
B
So,
for
example,
you
know:
where
does
the
SHA,
what
message
keys
are
allowed
or
what
is
the
path
to
the
dockerfile,
where
the
doc
would
do
a
step
actually
needs
to
be
done
right,
so
that
configuration
has
to
come
from
somewhere.
If
I
want
to
change
the
configuration
of
the
git
remote
itself,
every
night,
then
I
have
to
kind
of
go
into
the
deployment.
B
Do
you
see
Taylor
in
the
dorm
and
then
change
the
configuration
or,
if
you,
of
course,
don't
want
to
do
that,
then
the
obvious
architecture
is
to
use
a
custom
resource
and
controller
to
do
this
work
there.
So
that
means
that
we
can
actually
or
float
our
configuration
inside
a
custom
resource
where
we
can
specify
what
the
authorized
fees
are
for.
B
What
I
do
have
is
this
is
my
repository.
This
is
the
this
is
my
code
that
I
wanted
to
apply.
This
is
a
moon
or
echo
configuration
where
I
have
all
of
my
source
code
and
my
doctor
files
in
a
particular
that
in
Cuba
and
I
have
all
the
manifests
also
the
kubernetes
manifest
also
in
a
particular
directory
right.
So
this
is
this
is
kind
of
what
this
is.
This
is
the
source
because
I
wanted
to
play.
B
The
first
thing
that
I
want
to
do
is
install
get
cube
on
this
classroom,
so
that
I
can
start
pushing
my
repository
to
the
cluster
the
way
in
Cuban
station.
So
we
used
to
have
a
gate
Cuban
station
step
that
would
require
you
do
I
would
use
a
chart
or
run
a
bunch
of
humanity.
Steps
of
cube,
CTL
steps.
We've
kind
of
now
wrap
that
into
a
CLI,
so
all
I
need
to
do
is
I
need
to
get
field
install
and
as
soon
as
I
hit
you
install.
B
It
basically
creates
the
custom
resource
definition,
the
deployments
and
right
so
that's
kind
of
central
to
the
architecture
that
I
was
talking
about.
So
these
these
three
things
for
us
God
created
when
we
need
to
get
to
and
so
on.
Let's
just
take
a
look
at
the
tube
system.
Namespace
we'll
see
what's
happening
so
you'll
see
that
we
have
get
you
controller
and
we
have
people
to
be
running
here
and
we
also
have
get
to
be,
which
is
the
git
remote
server.
That's
running.
B
Thank
you
so
so
now,
I
kind
of
have
get
cube
installed.
I.
Also.
This
also
now
has
an
external
IP.
So
then
I
can
do
a
big
push
to
it
that
that
step
got
done.
Let's
now
figure
out
how
we
can
actually
push
a
repository
to
the
cluster.
So
on
the
way.
The
way
it
works
is
that
whatever
configuration
of
what
you
want
to
do
on
this
cluster
is
configured
in
what
is
probably
a
remote
object.
B
So
you
have
a
remote
party
animal,
which
kind
of
contains
this
information,
and
this
remote
that
yeah
Mel
is
going
to
have
the
conjugation
of
how
do
what
is
to
be
deployed
in
house
to
be
deployed
now
I
already
have
a
remoter
damager,
which
I'm
going
to
move
so
so
we
need
to
generate
this
remote
audience.
So
I
can
do
a
gig
cube
remote.
You
generate,
and
this
kind
of
takes
me
to
an
interactive
workflow.
Where
is
it
helping
create
to
the
motor
memory
so
I'm
gonna
say
my
remote
name
is
called.
B
B
Also
I'm
not
going
to
push
this
to
a
registry,
so
get
a
boss
has
a
configuration
where,
if
you
basically
once
the
docker
built
happens
here,
YouTube
can
also
take
the
image
and
push
it
to
an
external
registry
for
you,
but
we
don't
have
to
indeed
zero
my
team
on
end
of
cluster.
You
should
be
pushing
it
to
a
registry
anyway,
because
you,
because,
because
different
nodes
in
the
cluster
will
not
have
access
to
the
local
end
of
the
aqua
diamond,
that
is
running
on
the
particular
node,
where
the
document
is
built.
B
B
B
B
B
Yeah
sorry,
so
now
what
I
can
do
is
I,
can
kind
of
take
this
picture
mode
and
say:
hey,
give
me
a
more
ad
and
so
now
I've
added
it
to
my
local
mode
and
let's
also
just
take
a
look
at
the
manifest
files
that
I
did
not
kind
of
show
you
before
I
do
this
with
Lana.
So
these
are
the
manifest
files
right
here.
This
is
the
Kouga
IDs
deployment.
B
It's
called
www,
which
is
why
in
the
prompt,
I
was
setting
everything
to
www
and
the
image
is
just
set
to
a
base
image.
This
is
this
state.
This
is
the
value
that
will
get
patched
every
time.
I
do
a
build
right
and
I
can
also
show
you
what
this
looks
like.
So
this
is
a
simple
service.
This
is
a
load
balancer
and
it
kind
of
points
to
our
deployment
right.
So
that's
what
goes
that's
what
my
manifest
are
and
now
I
should
pray
to
the
demo
gods
and
do
a
git
push
nginx
monster
cool.
B
So
so,
if
we
look
at
what
the
hook
is
kind
of
telling
us,
it's
done
the
push
and
once
the
objects
have
been
transferred,
it
now
starts
running
its
build
system.
The
first
thing
it
does
is
applies
the
kubernetes
manifest,
so
it
creates
the
deployment
and
the
service
that
I
just
showed
you
from
the
manifest
folder.
So
it
creates
that
and
after
creating
that
it
goes
ahead
and
starts
building
all
of
the
different
doctor
images
that
were
specified
in
this
case.
There
was
also
all
of
the
different
containers
that
were
supposed
to
be
built.
B
So
in
this
case
I
just
had
one
container,
so
it
used
the
darker
path
and
the
build
context
for
not
given
it
in
the
configuration
and
it
starts
kind
of
building
that
out.
So
it's
doing
a
build
and
it
basically
runs
to
the
doc
will
step
in
nginx
thing.
So
it
feels
pretty
fast
and
then,
once
that
docker
build
is
done,
you
will
see
that
it's
updating
the
kubernetes
deployment
and
setting
the
right
image
right.
B
B
And
so
now
let
me
do
a
bit
from
it
when
I
say
or
actually
you
know
what
I
can
do.
I
can
just
go
into
a
different
branch,
because
I
might
not
want
to
comment
on
the
direct
run,
so
I
can
say
test
and
then
I
can
do
a
good
comment
here
and
just
zoom
that
up
so
now,
I'm
on
the
test
branch
and
I'm
gonna
make
a
comment
that
says
so.
B
Imagine
that
I've
tested
this
locally
and
once
I'm
done
testing
locally
I
now
want
to
push
it
to
my
kubernetes
cluster,
to
see
to
see
what
the
workflow
is
like
so
hard
to
see
what
the
deployment
is
like.
So
I
will
get
comment
and
I
say
it
changes
index.html
and
then
I
do
a
git
push
nginx
test
master
right.
So
this
is
just
saying
that
take
my
test
branch
and
apply
to
the
master
branch
that
is
sitting
on
the
governess
cluster.
B
The
reason
why
I
have
to
specify
master
here
is
because
by
default,
get
cube
is
configured
to
pick
up
commits
only
on
the
master
branch.
If
I
push
to
the
test
branch,
get
cube
will
not
run
or
build
DQ
by
default
is
configured
to
run
away
only
on
the
master
branch,
but
the
cool
thing
is
that,
because
of
the
way
it
works,
your
local
branches
and
the
kubernetes
cluster
branches
need
not
have
anything
right,
so
I
can
do
with
you.
Git
push
inch
next
test
for
the
master
and
the.
B
And
let's
go
back
here
and
we
French
this,
then
you
can
see
that
there's
a
change,
that's
kind
of
happening
yeah.
The
cool
kind
of
thing
also
is
that
I
can
actually
start
making
changes
to
the
kubernetes
manifest
as
well,
because
everything
is
inside
the
same
level
right
so
so
I
don't
have
anything
else.
For
example,
I
can
go
to
my
deployment
file
and
say
I'm,
tired
of
having
just
one
replica
this.
A
B
B
B
If
I
do
this,
it
will
tell
me
that
you
fail
because
it
says
that
the
cluster
is
ahead
of
my
branch
locally,
but
the
source
of
truth
is
not
what
is
on
the
cluster.
The
source
of
truth
is
what
is
in
higher
or
in
this
case
and
okay,
we're
doing
a
force,
push
and
then
saying
goodbye
changes
right
and
now,
if
I
look
at
the
number
of
parts,
the
pods
are
scaled
back
to
1
right
and
if
I
go
refresh
this
page.
B
Everything
is
inside
the
same
repository,
but
if
you
go
to
the
github
repo,
you
will
see
that
you
can.
You
can
have
a
multi
repository
configuration
where
you
have
different
repositories,
so
you
have
a
config
repo
where
you
have
all
the
component
is
manifest
and
you
have
source
code
repo,
where
you
only
have
the
docker
file
and
source
port
right.
So
these
are
two
different
demos,
so
so
this
is
a
different
triple
and
and
that
this
is
a
business,
the
positive
right
so
they're,
two
different
repositories.
B
So
that's
a
more
common
pattern
and
that's
kind
of
more
fashionable
today.
I
personally
prefer
mono
rainbows,
just
because
it's
easier
to
manage
kind
of
different
things
happening.
Moving
around
and
different
pieces
of
configuration
that
are
moving
on
instead
of
using
kubernetes
manifest.
You
can
also
switch
to
he'll
manifest
sense.
B
So
that's
kind
of
what
gives
you
good
slang
I'm,
going
to
take
a
little
bit
of
time
and
talk
about
how
you
can
customize
get
queue
to
do
what
you
want
to
do
and
why
this
pattern
or
why
this
pattern
of
doing
it
based
workflows,
makes
is
becoming
interesting
and
especially
the
idea
of
key
box
as
well.
So
let
me
just
quickly
touch
on
those
points,
so
I've
been
through
this.
B
This
is
the
equivalent
of
a
human
being
that's
kind
of
looking
at
the
CML
file
and
actually
making
operational
changes
on
the
cluster
right.
So
this
is
the.
This
is
the
pattern.
This
is
how
open
it
is.
Itself
works.
Where
you
know
everything
is
decorated,
you
you
never
do
a
sequence
of
steps.
Everything
is
just
this
is
the
current
state
that
I
want
to
achieve?
Kubernetes
will
achieve
that
state
for
me
right
now.
B
The
the
nice
thing
is
that
you
can
do
this
yourself
right,
so
you
can
have
your
own
yarn
file.
You
can
have
your
own
operator
and
your
operator
can
do
and
your
operator
can
actually
do
stateful
things
right.
So,
even
though
you
as
a
as
a
person
using
the
system
or
as
a
developer,
were
only
interacting
with
the
Yama
file,
the
operator
is
actually
converting
the
nominal
file
into
much
of
series
of
into
a
sequence
of
actions
or
into
a
stateful
order
to
sense
a
stateful
task
that
actually
that
actually
happened
right.
B
These
younger
files
are
going
to
be
then
become
the
source
of
truth,
and
these
will
actually
specify
how
the
deployment
is
is
is
done
right,
so
you
kind
of
don't
need
a
sequence
of
tasks
or
jobs
in
a
run.
What
you
instead
do
is
say
here
is
where
I
want
to
be
in
of
my
source
code,
which
is
the
source
of
truth.
The
docker
image
is
just
an
na.
The
dr.
container
is
now
just
an
implementation
detail
right,
so
my
source
code
is
the
source
of
truth
of
where
my
application
is.
B
B
The
things
that
are
parts
are
not
easy
to
do
with
the
dogs
right
now,
and
the
things
that
are
not
possible
in
this
workflow
are
things
like
secrets,
so
secrets
obviously
cannot
be
committed
here
into
the
gem
inside.
There
is
an
emerging
idea
of
encrypting
secrets
and
then
putting
them
in
your
cuticle
so
that
they
can
get
applied
automatically
and
I'm,
not
being
another
big
fan
of
that
idea,
but
I
mean
I,
don't
think
it
equity
matters
to
me
there
are.
There
are
things
to
think
about
a
little
more.
B
You
have
to
think
about
things,
look
more
carefully
one
way
or
another,
so
so
secrets
are
a
problem
because
you
can't
commit
them
to
get
as
they
are.
The
cool
thing
is
that
if
you're
actually
willing
to
go
ahead
and
do
your
own
get
automation,
then,
depending
on
the
access
privileges
of
the
the
kind
of
access
control
that
an
individual
developer
has,
you
can
actually
apply
secrets
based
on
a
pre
push
book
right.
B
So
you
might
not
actually
have
secrets
that
that
are
committed
to
the
get
rebel
right,
but
the
three
push
hook,
which
is
when
I'm
executing
a
good
push
even
before
the
get
push
execute
scripts,
can
run
on
my
client
side,
so
I
can
have
a
people
show.
Let
me
just
quickly
show
you
an
example
of
what
I
mean
here.
B
So
what
I
can
actually
do
is
I
can
say
in
the
pre
pushed
over
right.
What
we're
going
to
do
is
you
could
actually
run
a
command
that
says
cube
CDL,
we
place
s
secrets
right
and,
and
this
would
work,
and
even
though,
even
though
secrets
is
not
committed
to
your
git
repo
right,
even
though
it's
not
committed
to
your
git
repository
this,
this,
this
step
would
actually
work,
and
this
uses
the
cube
CTL
privileges
that
I
have
a
my
machine
right.
B
So
this
is
this
is
something
that
won't
work
for
everybody
and
that's
why
it's
a
pre
push
hook,
because
it
is
only
available
to
me
right.
So
this
gives
me
again
a
convenient
it's
just
it's
just
like
the
minion
command-line
information
right.
It's
not
is
nothing
beyond
that.
So
that's
one
way
of
solving
the
problem
as
well.
The
other
things
that
are
hard
a
templating,
so
templating
is
also
cumbersome
to
do
so
so
different,
different
tools,
approach
it
differently.
B
B
There
are
a
few
interesting
ideas
on
templating
as
well
again
with
templating.
You
could
also
do
templating
on
the
pre
push
hook,
but
if
you
do
templating
on
the
people's
hope,
that
means
that
you
can't
actually
commit
to
kubernetes
manifests.
You
can't
apply
the
community's
manifest
in
the
server
side.
You
have
to
apply
the
kubernetes
manifest
on
the
three
push
on
the
client
side.
So
that's
that's
a
that's
a
bit
of
a
challenge.
The
other
way
to
think
about
this
is
that
you
don't
do
templating.
B
So
you
know
you
have
different
branches
for
different
environments
and
that
way
you
don't
have
to
do
complaining.
You
can
just
have
the
actual
manifest
files
on
different
branches.
This
is
may
or
may
not
work
again
depending
on
right,
but
things
like
January
deployments
releases
scaling
up
scaling
down.
All
of
these
are
actually
possible
to
do
with
with
get
ops
as
long
as
you
have
the
right,
yeah
Mel
files
that
can
be
configured
right.
B
So
if
you
have
the
ml
file
that
we'll
take,
then
we'll
take
an
HTM
configuration
that
will
say
that
you
know
this
is
the
split
that
I
want.
I
want
80%
traffic
here,
20%
traffic
stuff
and
that's
in
a
yam
inside
and
then,
if
that's
in
a
Yama
file,
you
can
put
that
in
your
repo.
You
can
do
it
push
with
git
cube
and
that
would
apply
that
Yama
file
and
apply
the
sto
change.
So
so
those
are
a
little
little
interesting
to
think
about
from
aggie
tops
point
of
view,
but
they
are
possible.
B
A
B
Yes,
it
is
very
similar
to
how
nginx
ingress
is
build
on
kubernetes
and
I.
Think
yeah,
the
the
architecture
of
how
git
Cube
works
is
the
same
as
how
Engine
Xing
ingress
is
also
placed
it's
the
same
operator
and
custom
resource
pattern.
What
you
can
do
will
get
Q
is
I'm,
not
sure
if
this
is
also
what
you're
asking,
but
what
you
can
also
do
with
get
cube
is
that
you
can
also
have
an
English
word.
B
B
B
These
are
the
changes
that
I
want
to
see
on
the
kubernetes
cluster
right,
but
if
you're,
actually
looking
at
a
governance
pipeline
right
where
you
are
looking
at
at
at
doing
things
that
are
not
just
related
to
deploying
on
your
kubernetes
cluster,
then
you
kind
of
need
to
have
a
pipeline
that
is
external
to
this.
The
end
of
that
pipeline
can
use
data
cube
to
do
the
deployment,
but
in
that
pipeline,
when
you're
doing
things
like,
for
example,
the
things
that
you
mentioned,
those
can
kind
of
be
done
in
the
pipeline.
B
If
you
think
about
testing,
it's
really
interesting,
it's
always
a
little
interesting.
Where
you
put
tests,
you
can
put
tests
in
a
pipeline
that
happened
before
this,
so,
for
example,
if
you
have
unit
tests,
you
can
actually
put
them
in
the
doc
file
and
you
can
have
a
bill
to
agra
file
or
development
or
production
doctor
file,
so
bill
can
actually,
after
the
talk
after
the
talker
file
is
built,
you
can
actually
learn
your
unit
tests
inside
it.
B
B
You
could
execute
the
test
here
and
if
those
tests
pass,
then
your
container
image
bills.
If
it
doesn't
your
git
push
itself
would
fail.
So
any
failure
in
building
the
Baka
file
or
building
the
image.
If
that
fails,
you
would
get
for
synchronous
response
in
a
haven
right.
So
that's
one
way
of
looking
at
unit
tests
in
sybiz
workflow,
but
the
other
way
of
doing
other
testing
is
kind
of.
If
you
want
make
it
a
part
of
your
pipeline.
B
B
B
B
If,
if,
if
kubernetes
allowed
you
to
have
consequently
less
that
could
kind
of
update
anything
in
the
kubernetes
system,
that
would
be
amazing
and
you
wouldn't
need
them
reading,
because
it
would
just
put
everything
in
one
big
map
and
then
just
the
driver
right,
config
man
for
the
right
environment
right.
There
is
another.
B
B
Right
this
won't
work
so
this
disk
in
word
here,
but
let's
say
for
example,
now
you
went
in
and
you
change
the
config
not
directly
right.
So
as
your
kubernetes
cluster
is
running,
you
went
in
and
you
changed
your
config
map
directly.
If
you
went
in
and
you
change
the
config
map
directly,
the
problem
is
that
it
might
not
get
applied
to
the
deployment
or
because
kubernetes
has
kind
of
has
has
has
a
time
interval
and
every
every
few
minutes
it
will
sync
the
config
not
with
the
deployment
file.
A
B
Could
use
this
for
CI
CD
with
something
like
Jenkins,
where
the
last
part
of
the
Jenkins
pipeline
is
doing
it?
Push
just
like
just
like
what
get
cube
does
because
gatekeepers
need
you
to
have
any
client-side
installation
and
things
right.
So,
in
the
last
step
of
your
Jenkins,
you
just
do
a
git
checkout
get
push,
and
as
long
as
you
have
gives
you
been
stored,
when
it
is
faster,
it
will
do
the
image
building
and
we'll
do
the
rollout
view.
So
the
advantage
of
using
that
is
that
you
don't
have
to
push
the
other
images.
B
B
So,
for
example,
you
need
to
have
a
post
press
operator
that
knows
how
to
have
database
migrations
that
are
available
as
the
amyl
files
and
actually
apply
those
migrations
right.
So
it's
kind
of
it
depends.
You
need
to
have
that
infrastructure
which
allows
you
to
do
things
that
creatively
and
allows
you
to
move
away
from
pipelines.
B
B
A
B
What
I
showed
you
was
what
the
so?
Let's
let's
to
get
to
people
in
the
system.
There
are
deaf
people
and
there
are
obstacle.
Fox
people
have
access
to
the
kubernetes
cluster.
Deaf
people
don't
have
access
to
the
kubernetes
cluster
directly
right.
They
can't
do
administrative
things.
So
let's
say
they
don't
have
access
to
the
cube
system
namespace.
So
the
activity
of
doing
the
gift
cube
install
this
is
done
by
the
operator,
because
this
will
actually
touch
the.
So
let
me
just
do
an
uninstall.
B
Right
and
so,
if
you
look
at
these
things,
these,
these
are
the
various
things
that
have
been
created
right.
A
service
account
cholesterol,
binding
config
map,
these
various
deployments
and
all
of
these
are
getting
created
in
the
chip
system
namespace.
So
this
this
bit
has
to
be
done
by
somebody
that
has
that
that
level
of
access
right.
B
So
that's
because
it
Cube
is
using
my
kubernetes
conjugation
cube,
CTL
foreign
context
right,
so
it's
using
my
kind
of
admin
access
to
the
cluster,
but
one
instead
of
set
this
up
once
that
set
up
the
get
cube
system
and
once
I've
set
up
the
remote
doing
this
action,
which
is
just
a
gate,
push
right.
This
only
uses
the
public
key,
so
this
is
now
done
by
a
developer,
and
this
doesn't
need
any.
B
This
has
business
the
context,
or
this
has
the
kind
of
service
account
or
the
access
that
is
needed
only
for
this
remote
right
and
so
this
executes
in
the
context
of
where
this
remote
is
created
and
so
that
the
developer,
the
heliport
just
has
it.
The
developer
strip
of
the
doctor
based
script
will
execute
only
in
a
particular
namespace
and
that
can
be
are
backed
by
the
operator
right.
So
because
I
am
running
this
remote
inside
the
namespace
default
right,
so
let's
say:
I
am
user.
One
and
I
have
a
namespace
for
user.
B
One
namespace,
then
I
would
I
would
I
would
be
able
to
run
this.
Only
in
my
namespace
right,
so
I
will
be
able
to
get
push
and
I
will
be
able
to
modify
things
only
in
my
name
space.
So
you
can
are
back
what
the
developer
can
do
inside
the
developers
instance.
So
you
can
use
all
of
the
kubernetes.
Are
that
stuff
I
in
this
demo
I
mixed
up
the
two
things
I
was
also
the
operator
setting
up
a
cube
and
I
was
also
the
developer.
The
plan
changes
you.
A
B
B
B
Right
and
then
in
the
remote
that
I
create
to
get
remote
that
I
create,
instead
of
setting
the
manifest
directly
to
manifest
here
as
a
command
fester,
all
right
so
I'll
use
this
for
the
production,
environment
and
I'll
use
just
manifest
for
the
development,
environment
and
yeah.
So
that's
that's
another
way
that
that's
another
way
that
would
work,
but
they
not.
You
see
you
duplicating
things
between
these
two
directories
and
that's
usually
when
people
want
to
start
integrating
right,
it's
not
like
to
use
them
getting
anywhere.
A
B
Not
correct
yeah,
so
that
is,
that
is
the
architecture
of
I
mean
that
is
the
gift
of
architecture
by
design
where,
if
you
see
this,
this
is
the
git
repo
is
running
on
the
governor
discussed
all
right,
the
branch
on
the
doge
it
did
so
this
is
where
I'm
pushing
to
is
running
on
the
same
Funes
cluster,
where
my
pods
independents
are.
This
is
both
good
and
bad.
It's
good
because
it
doesn't
need
further
access.
Whatever
access
you
believe
it
has,
it
has
access
to
all
the
resources
inside
the
kubernetes
cluster.