►
From YouTube: GitOps Happy Hour (Ep 1): Demystifying GitOps
Description
Join Christian Hernandez, GitOps Extraordinaire, for a journey through how to achieve GitOps in any number of ways. The occasional Red Hatters and special guest will join us too.
B
Yeah
yeah
so
yeah,
my
name
is
chris
hernandez.
I'm
a
single
senior
now
principal
technical
marketing
manager.
Yes,.
A
B
At
red
hat
right
and
a
little
bit
background
about
me
right
so
as
we
start
this
this
new,
this
new
bi-weekly,
I
guess
a
stream.
My
background
is
mostly
in
operations
right,
but
I
think
I've
delved
into
I
think
as
everyone
into
into
devops
and
always
trying
to
find
new
and
interesting
ways
to
speed
up
the
delivery
of
applications
right
even
as
an
operations
guy,
that's
kind
of
kind
of
your
job
right.
You
you
like
to
think
your
job
is
spinning
up
vms.
It's
not
it's.
B
Just
your
job
is
to
support
the
developers
and,
if
the
the
quicker
you
realize
that
the
better
it'll
be
for
your
for
your
career
right,
so
you
know
I
had
to
have
that,
and
I
was
actually
one
of
the
two
first
openshift
sa.
So
I'm
talking
this
is
back
in
2015
right
back
when
openshift
was
back
with.
No
one
kubernetes
didn't
even
exist
right,
so
they
it.
A
C
B
Know
based
off
on
on
borg
and
all
those
everyone
should
know
that
story,
so
so,
but
one
of
my
biggest
passions
as
as
most
of
you
would
know
as
chris.
You
know.
C
B
Ops
right,
so
what
what
is
and
what
I
want
to
do
with
this
with
this
happy
hour,
oh
and
by
the
way
it
is,
it
is
a
is
technically
happy
hour
right.
So
I
have
I.
B
B
You
know
I
want
to
treat
this
as
an
office
hour,
it's
kind
of
similar
to
it.
Those
of
you
who
watch
the
level
up
hour
or
the
the
admin
office
hour
with
us.
My
co-workers
actually
write,
langdon
and
andrew
do.
Let's
do
that,
show
I'm
gonna
treat
it
something
similar,
but
since
everyone's
doing
office
hours,
I
just
decided
to
name
it
a
happy
hour
just
just
to
be
a
little
different
right.
I
always
have
to
be
like.
B
B
A
Thursday
nights,
if
you
build
the
environment
right,
you
can
but
yeah
you
can
yeah
exactly.
B
Yeah,
so
this
this
this
first,
I
think
this
first
episode
of
the
get
ops
happy
hour.
I
kind
of
want
to
talk
about
kind
of
demystifying
getups
right.
So
some
of
my
previous
streams,
you
see,
I
think,
a
lot
of
what
we
do
in
technology
right.
I
don't
want
to
like
put
this
on
like
any
one
company
or
any
one
group
of
people
or
anything
we
just
just
in
general.
We
focus
on
the
hammer,
is
what
I
like
to
say
right.
B
We
focus
on
the
tool
a
little
bit
a
little
bit
too
much
right
right,
and
I
always
I
always
make
the
analogy
of
building
a
house
right
when
you
build
a
house.
B
The
first
thing
you,
the
first
thing
you
talk
about
is
like
the
blueprints
and
how
you're
gonna
build
the
house,
not
what
brand
of
hammer
you're
gonna
use
right,
although
the,
although
the
tool
is
important,
you're,
it's
always
using
the
right
tool
for
the
job,
so
I
think
I
want
to
take
a
step
back
and
kind
of
demystify
get
ups
kind
of
independently
of
the
tool
of
what
what
we
use
right.
As
you
know,
I
use
a
lot
of
argo
cd.
Some
of
my
you've
seen
some
streams
here.
B
B
Exactly
it's
this:
let's
not
focus
on
the
tools.
So
what?
What
is
what
is
get
ops
exactly
right?
And
I
think
chris
you've
seen
the
slide
before
oh.
B
So
chris
chris
always
always
gets.
C
B
Yeah
so
yeah
exactly
right,
yeah,
so
you
see
you've
and
I
think
it's
a
it's
a
very
good.
It's
a
very
good
quote
right
like
so
I'm
quoting
directly
quoting
the
person
here.
Gitops
is
the
holy
grail
of
devops
right.
So
what
what
is
you
know?
What
does
that
mean
right,
so
get
ops
is
just
very
simply
using
git
as
your
source
of
truth
for
your
entire
stack
right.
So.
E
B
Only
your
your
application
stack
and
how
that
looks
like,
but
you're
actually
at
your
infrastructure
as
well
right.
So
as
things
like
infrastructure,
as
code
comes
along
right
like
things
like
puppet
and
ansible,
when
you're
like
describing
your
infrastructure
in
a
in
a
code-like
manner,
right.
B
Declaring
right
declarative
instead
of
imperative
right,
you
can
store
that
somewhere
right
and
using
the
get
ops
workflow
using
git
as
a
source
of
truth.
That's
really!
What
get
ops
is
right,
you're,
driving
everything
through
git,
you
know
it's
it's
taking
it's
taking
what
the
developers
done,
really
what
the
developers
done
with
git
kind
of
just
moving
that
to
operations
as
well.
C
C
A
B
B
It's
it's
really.
A
git
ops
is
like
cloud
native
and
devops
in
practice
right.
So
it's
it's
not
it's!
It's
just
a
natural
way
of
doing
devops
right!
That's
what
you
want
to
get
to
that's
what
it
is
right.
So,
just
simply
everything
you
have
everything
about
your
environment.
If
your
infrastructure
isn't
get
simply
right,
so
yeah
yeah,
so
there's
a
there's
always
these
here.
Let
me
let
me
make
this
a
little
bigger.
Thank
you.
There's
always
the
you
know.
What
do
I
gain
right
like
why?
B
Why
get
ups
right
so
like?
If
you
ask
you
know
the
getups
community
and
people
that
that
have
been
doing
this
like
there's,
like
you
know,
everyone's
shouting
pretty
much
the
same
things
right
right
like
like.
I
wanted
to
give
up
get
ups,
because
you
know
it
just
takes
weeks
and
months
for
vision
and
environment
or
like
there's
people
that
say
like
I
can't
like.
B
I
can't
audit
configuration
changes
right,
so
you
get
like
these
different
people
from
different
different
environments
right
so
like
from
the
security
guys
to
the
administrators
to
the
developers
they're.
All
like
shouting,
you
know
things
right
like
that
is
pink
points
for
them
and
the
the
good
news
is
that
get
ops
kind
of
provides
probably
a
little
bit
of
everything
for
everyone
right
like
it.
Really.
B
I
don't
want
to
say
it's
like
the
perfect
answer
for
all
workloads,
but
it
it
actually
attacks
a
lot
of
pain
points
for
a
lot
of
for
a
lot
of
for
a
lot
of
people
right
so
really
just
kind
of
like
the
like
the
benefits,
the
biggest
benefits
that
you
need
to
keep
in
mind
like
what
what
what
would
githubs
get
me
right
so,
like
all
changes,
are
audible
right
so,
like
you,
since
you're
using
a
git
workflow.
B
I
can
see
who
made
changes
what
and
why,
right
just
because
in
that
get
workflow,
I
can
look.
I
can
look
at
the
specific
commit
I
can
see.
Who
did
it
and
I
can
see
who
approved
it,
and
I
can
see
you
know
and
all
of
a
sudden
now
I
have
this
big
audit
trail
of
of
my
of
my
entire
environment
right.
So
the
security
guys
come
and
say,
and.
B
D
A
A
A
B
Everything
does
happen
in
your
environment,
everything
everything
in
your
environment
right
so,
and
you
also
get
you
know
not
to
miss
words
right
now,
not
to
play
on
words,
but
you
get
a
standard,
roll
forward
and
backwards
right
in
bed
of
failures.
Something
bad
happened.
I
can
point
to
a
different
tag
and
then
your
environment,
just
kind
of
just
changes
to
that
tag.
Right,
it'll,
roll
back
to
a
to
a
different,
commit
and
it'll
it'll
it'll,
make
sure
you're
at
in
that
specific
commit
right.
B
B
A
B
B
From
the
middle
up
yeah
exactly
so,
you
have
also
a
a
method
to
do
disaster
recovery
right.
So
you
have
a
method
of
saying,
okay.
Well,
if
I
lose
everything,
how
do
I
get
to
where
I
was?
I
was
like
well
everything's
conveniently
and
get
I
just
reapply
to
the
current
state
right
and,
and
the
experience
really
is
for
developers
it'll
be
it'll,
be
just
standard
pushes
and
pull
requests
right.
B
So
forks,
you
know
I
as
a
even
as
operations
guy
right,
I
can
fork
a
repo,
you
know
say:
hey
I
want
you
know
four
nodes
instead
of
three
make
a
pull
request,
really
easy
that
get
that
goes
through
the
process.
Right
I
go
through
it.
Somebody's.
B
Exactly
and
so
yeah
so
then
that's
the
experience
like
how
you
interact
with
your
cluster
is
all
consistent,
like
everyone
interacts
with
the
customers.
B
Yes,
yes,
exactly
so
and
really
get
ops
is
for
everyone
right,
whether
you're
a
developer
or
you
know
like
rockstar
developer
or
like
a
guru
operations
right
like
I
guess,
that's
that's
what
I'm
trying
to
illustrate
here.
B
So
so,
really
that's
like
what
get
ops
gets
you
right,
you're,
inner,
interacting
with
get
and
anytime
you
want
to
make
it
change.
Your
environment
is
just
simple
as
a
pull
request
right
I
want
to
scale.
I
want
to
make
a
blue
green
deployment.
I
want
x,
y
and
z
right,
so
so
that's
just
git
in
general.
B
B
Know
it
right,
but
it
is,
you
know,
unless
you've
been
unless
you've
been
living
under
a
rock
there's.
This
thing
called
kubernetes
out
there.
What
what's
that?
Yes
yeah?
I.
C
B
What
is
this
kubernetes
stuff
right?
So
you
know
trying
to
you
know,
I'm
pretty
sure
everyone
watching
has
been
beaten
over
the
head.
What
kubernetes
is
so
I
won't
spend.
I
won't
spend
more
than
a
slide
on
it.
It's
basically
how
to
orchestrate
containerized
workloads
right,
it's
abstract
underlying
infrastructure,
so
the
containerized
workloads,
you
don't
have
to
worry
about
where
your
containers,
land
or
anything
like
that
kubernetes.
Just
essentially
it's
a
resource,
scheduler
right.
You
give
it
something
and
it
makes
sure
it
runs.
B
And
it
does
it
exactly
so,
which
is
which
fits
in
perfect
with
you
know,
openshift
right
like
what
we
wanted
with
openshift.
B
You
know:
okay,
we
needed,
like
openshift
needed
a
way
to
schedule,
workloads
and
just
kubernetes.
Just
you
know.
I
was
part
I
came
on
to
red
hat.
When
you
know
I
was
an
openshift,
v2
administrator
right,
my
previous
life
and
red
hat's,
like
hey.
We
need
openshift
experts
because
we
only
have
one
in
north
america
and
they
go
okay,
I'm
coming
along.
So
so,
and
I
was
part
of
the
two
to
three
migration
and
now
from
three
to
four.
So
it's
been,
it's
been
wow,
you
know
it's.
B
A
Mean
I
remember
using,
I
remember,
using
the
cartridges
and
everything
from
the
old
open
shift
days
and
it's
funny
because
I
actually
used
it
to
do
a
fishing
campaign.
C
A
B
Well,
when
I
first
when
I
first
saw
it
when
I
first
saw
bishop
v2,
I
was
like
this
is
a
game
changer
right
like
yeah,
you
know
like
to
be
able
to
like
you
know
a
few
clicks.
I
got
an
application
up
and
running.
I
mean
you
know
it
may
seem
you
know,
even
as
an
admin
I
go
like
well.
This
is
this
is
big,
like
I
wonder
how
this
works
and
that's
how
I
delved
in.
A
B
And
you
know,
and
even
with,
like
you
know,
v2
to
v3
right
like
that's
how
we
you
know
like.
Oh,
this
is
new
kubernetes
thing.
You
know
these
google
guys
want
us
to
help
build
this
thing
that
they're
calling
kubernetes
and
we're
like.
Okay,
let's
do
it
so
I
was
part
of
that
migration
from
two
to
three.
B
But
really
this
is
you
know
when
you
think
of
of
open
ship,
the
other
thing
kubernetes
right,
because
it's
essentially,
as
you
see
here,
it's
the
the
core
of
what
openshift
is
right
and
then
you
know
we
have
some
some
some
tools
on
top
built
on
top
of
it
right
to
for
you
to
be
able
to
expedite
your
application
delivery
right
because,
as
we
all
know,
as
kelsey
hightower
says,
is
that
you
need
more
than
just
kubernetes
right.
So
right.
B
C
B
Not
even
the
starting
point
right,
it's
like
the
prerequisites,
because
you
have
to
build
so
much
on
top
of
it
right
and
so
and
then
you
know
this
is
kind
of
like
our
our
idea
of
like
what
a
smarter
kubernetes
platform
looks
like
right
and
it
includes
acm
which
all
touch
on
a
little
bit
right,
because
acm
gets
into
kind
of
like
get
off's.
B
So
so
openshift
and
get
ops
is
a
perfect
match.
Essentially
right
because
get
ops
is
you,
you
you're,
storing
everything
and
get
right,
and
you
need
a
way
for
it
to
sync
everything
into
your
environment
right
and
with
with
things
like
crds,
and
you
know,
methods
to
extend
the
kubernetes
api.
B
This
just
becomes
a
natural
fit
right.
So
now
I
can
declaratively
say
hey.
I
want
application
stack
to
go
in
kubernete,
you
know
my
kubernetes
cluster
and
then
and
then
that
that
tool,
whatever
it
is-
and
I'll
talk
about
the
tools
later
right,
we'll
sync,
that
from
git
right
and
then
you're,
taking
advantage
of
the
control
loop
in
inside
of
kubernetes,
to
keep
constant
watch
right
and
to
detect
drift
and
all
that
and
I'll
go
deeper
into
that
into
that.
B
Pattern,
yeah
custom
resource
definition,
custom
resource,
but
you
know
kubernetes,
slash,
openshift
and
git.
Ops
is
a
perfect
match
because
you
know
you
have
a
declarative
way
of
describing
infrastructure,
and
now
you
have
a
declarative
way
of
deploying
your
infrastructure
and
I'm
like
okay.
Well,
then,.
A
B
So
there
it's
it's
essentially,
you
know
a
match
made
in
heaven.
Essentially
so
so
there's
some
some
things
that
I
kind
of
want
to
touch
on
is
you
know,
I'm
kind
of
going
to
get
a
little
bit.
Opinionated
here,
surprise.
Surprise!
Right!
I
get
opinionated.
B
C
B
But
there's
like
a
group
of
us
and
actually
I
kind
of
want
to
give
a
shout
out
to
gerald
from
the
red
hat
canada.
He
actually
said
like
get.
Ops
is
kind
of
like
a
journey
and
a
lot
of
people
say
like
journey.
They
kind
of
just
use
it
as
like
a
marketing
thing
or
like,
like
a
sales
pitch
but
like
no.
This
is
literally
a
journey
because
you
know
I
started
with
get
ops
with
one
opinion
and
it
like
changes
like
more
and
more.
I
learned
about
it.
B
B
You
know,
there's
going
to
be
certain,
you
know
certain
verticals
that
will
have
opinions
on
it
right
like
the
like
the
public
sector,
and
you
know,
government,
and
you
know
all
of
that
financial
they'll
have
opinions
as
they
start
adopting
some
of
this
stuff.
Absolutely
like.
B
B
Yeah,
so
it
is,
it
is
salted
steel
from
gerald,
so
shout
out
to
gerald
from
red
hat
canada
by
the
way
red
hat
canada
a
bunch
of
smart,
smart
folks.
I
think
it's
the
best
kept
secret
at
red
hat.
It's
red
hat
canada,
there's
a
they're
because
they're
very
smart
and
then
they're
very
humble.
So
it's
like
it's
just.
You
know
the
perfect
combination.
So
this
is
a
journey
right.
B
So,
but
you
know
kind
of
some
of
the
principles
that
that
you
know
me
and
that
group
kind
of
came
up
with
is
you're
going
to
separate
your
application
code
from
the
actual
manifest
that
deploys
them
right
makes
sense
yeah.
So
you
have
your
your
code
and
then
you
in
one
repo,
and
then
you
have
your
manifest
to
deploy
that
code
in
another
repo
right.
C
E
B
Yeah
yeah
you're
working
together,
yeah
you're
working
yeah,
so
a
lot
of
so
I
kind
of
want
to
there's
also
trying
to
try
and
diversify,
get
up.
Sorry
devops
as
well,
because
right.
A
B
Know
like
I
would
have
conversations
with
people
it's
like.
Well,
it's
it's,
never
gonna
be
one
department
because
they
have.
You
know
like
different
goals
and
I'm
like
you're
you're
misconstrued
like
you're.
B
C
D
B
Yes,
process
change
is
more
processed
than
anything
else.
You
know
you're
not
going
to
be
sitting
next
to
the
java
developer.
I
mean.
Maybe
you
want
to,
but.
B
It
doesn't
necessarily.
B
D
B
So
so
yeah,
that's
like
like
one
thing
right.
We
found
that
you,
you
have
separate
separate.
Basically
repos,
you
have
one
for
your
application
and
one
for
your
for
the
all.
The
manifest
to
deploy
that
application
right
and
you're
in
all
of
the
plane
manifests
are
in
standard
kubernetes
manifest,
so
that.
B
Right,
you
have,
you
know
you
just
use
the
native,
so
like
yaml,
I
did,
I
would
argue,
is
the
most
popular
language
now,
because,
because
it's
like
you
know
you
just
kind
of
have
to
use
it
now.
C
A
A
See
where
it
is
the
red
monk
top
20.
yaml.
B
Yeah
and
that
which,
by
the
way,
which
is
why
I
said
standard
kubernetes
manifest
because
it
could
be
yama
or
json,
you
know
pick
your
poison
most
people
just
use
yaml,
just
because
they're
just
comfortable
with
it,
a
lot
of
python
developers
out
there
so
they're,
just
ucl.
B
Also
you
avoid
duplication
of
yaml
right
or
your
your
your
manifest
right,
so
you'll
have
one
you'll,
have
a
deployment,
and
instead
of
just
copying
that
deployment
for
each
environment,
you'll
you're,
going
to
need
a
way
to
reference
that
one
yama
and
I'll
talk
about
that
in
a
little
bit
as
well
so
and
yeah,
so
the
manifest
should
be
applied
with
like
standard
tooling,
essentially
right
so
essentially
here
just
keep
it
simple
is
the
is.
B
This
is
kind
of
the
guiding
principles
we've
been
we've
kind
of
been
talking
about
internally
so
day,
two
operations,
it's
actually
really
easy
right
kind
of.
Like
we've
been
talking
about.
You
know
I
you
know,
create
a
pull
request.
Someone
merges
it.
Someone
runs
a
pipeline
pretty
standard
right,
so
this
workflow
is
very.
B
The
developers-
but
this
is
tight
and
true
so
like
why
reinvent
the
wheel
kind
of
just
take
an
operations
approach
to
it
as
well
is
all
changes
are
triggered
from
from
get
right
once
so
once
you've
got
to
get
ups,
a
workflow
in
you
know
chris
short
may
want
five
new
nodes.
Pr.
C
B
C
B
B
A
specific
tool
I
want
to
talk
about
tools
of
the
trade
right.
I
want
to
talk
less
about
less
about
brand
more
about
you
know,
what's
available
there
to
you
right,
so,
you're
gonna
need
a
way,
so
you
have
like
get
and
get
repo
and
you
have
a
declarative
infrastructure.
Like
you
know,
kubernetes
openshift,
you
need
tools
in
order
to
make
all
that
work
right.
So
two
biggest
tools
really
is
a
sync
tool
right.
You
need
a
way
to
sync:
some
people
call
it
a
sync
tool.
B
Some
people
call
it
continuous
delivery,
continuous
deployment,
whatever
you
want
right,
it's
essentially
the
same
same
idea
right.
So
the
some
of
the
big
ones
out
there
for
for
syncing
is
like
argo
right.
Like
argo
cd
is
a
big
one,
flux.
E
B
Is
another
big
one?
We
have
acm
right,
which
is
you
know,
advanced.
B
Right,
there's
also
things
like
like
templating
tools
right
so
like
in
order
to
not
duplicate
yaml,
you
need
to
some
way
to
templatize
a
deployment
right.
A
C
B
D
B
A
B
B
D
B
Lot
of
check
those
out
guys,
if
you,
if
you
want
to
see
those
those
are
really
cool
you
can
you
can
google
for
them.
It's
like
the
first
first
things
that
come
up
is
from
red
hat.
B
B
About
that's
open
cluster
management,
but
that's
like
the
upstream
of
of
yeah,
so
yeah
under
argo
yeah.
So
that's
that's
the
yeah,
so
so
these
are
kind
of
the
tool
of
the
trades.
It's
really
kind
of
you
need
a
way
to
do
the
sync
and
a
way
to
do
templating
right
and
so-
and
you
know
I
want
to
talk
a
little
bit
about
the
the
the
sinking
tools
right
so
here
on
the
right.
You'll
see
an
example
of
argo,
but
just
in
general
the
syncing
tool
is
built
on
it.
B
It's
it's
used
to
detect
and
expedite
drift
detection
and
correction
right.
So
it's
used
to
help
with
that
and
it's
built
on
the
kubernetes
custom
crds
right,
custom
resource
definitions,
which.
E
B
Reasons,
yeah
yeah,
so
yeah
so
crds
is
essentially
is
a
way
to
extend
the
kubernetes
api
without
having
to
build
it
in
tree.
There's
actually
right.
There's
in
you
know
a
little
little
a
little
tangent
about
about
crds.
I
saw
a
talk
given
I
forget
it.
It
was
you
know
back
when
we
were
able
to
travel.
It
was.
C
D
A
B
Kind
of
interesting,
just
like
the
idea,
that's
how
powerful
crvs
are
like
right.
You
essentially
can
do
like
cube.
Ctl
get
mydb
and
whatever
you
define
mydb
to
be,
you
know,
that's
it
yeah
oc.
C
B
B
B
You
said
you
want
to
I'm
going
to
spin
up
the
second
one
same
idea
right.
They
took
advantage
of
that
control
loop
that
declarative
nature
of
of
of
kubernetes,
so
some
of
the
most
popular
get
up
tools
for
syncing
right
as
we
talked
about
before
flux.
Cd
right
is
very
popular
right,
developed
by
the
guys
that
we've
works,
argo
cd
right,
which
is
we
which
actually
we
just
announced
in
kubecon-
that.
B
Really
heavy
investment
in
it.
You
know
argo,
cd
and
acm.
Right,
which
is
advanced.
Cluster
management,
obviously
is
another.
B
B
Yeah
there
are
red
headers,
so
yeah
a
little.
You
know
a
little
bit
about
that
right,
a
little
bit
pulling
the
curtain
a
little
bit
yeah.
They
actually
like
here's
a
bunch
of
developers
so
which
is
kind
of
like
some
of
the
powerful
thing
that
what
happened
with
the
ibm
acquisition
is
like
they
can
do
that
right,
like
they
can
just
give
us
resources,
which
I
think
is
cool
yeah
yeah.
B
E
B
Is
like
okay,
well
you're
in
argo
and
acm
like
what's
deal
with
that,
like
really
one
of
them
is
going
to
be
a
a
developer
tool
and
one
of
them's
going
to
be
for
like
security
and
operations
right.
C
C
B
The
you
can't
have
a
get
ops
experience
with
acm.
You
know.
A
A
C
B
B
Maybe
maybe
it
is
yeah,
so
so
yeah.
So
here
you
essentially,
what
I
was
saying
before
is
like
it's
a
declarative
representation
of
the
entire
stack,
so
everything
that
needs
to
sync
whatever
sync
tool
you
need
to
whatever
sync
tool
you
decide
to
use
it
needs
to
the
the
entire
representation
of
that
stack
needs
to
be
get
right,
whatever,
whatever
tool
you
use
doesn't
matter.
What
tool
you
use
is,
is
it's
hot?
It's
what
you're
doing
right
and
you
need
to
get
that
that
whole
representation.
B
So
what
I
mean
everything
I
mean
everything
right.
So
I'm
talking
to
you
infrastructure,
guys
right
so
developers,
actually,
funnily
enough,
are
easier
to
talk
about
get
ops
because
they
kind
of
understand
the
whole
flow,
a
little
better
right
because
they're
a
little
ahead
of
that
stuff
with
operations
like
when
I
say
the
entire
stack
like
yes,
I
mean
the
entire
stack
right
like
I
mean
everything
like
the
definition
of
how
to
spin
up
a
vm.
B
The
definition
of
your
machine
set
definitions,
all
the
name
space,
all
the
deployments,
all
the
all
the
definition
on
how
everything
gets
shoved
in
to
get
and
that
actually
could
be,
could
be
a
little
scary
right,
as
you
mentioned
before,
to
the
operations,
but
it
actually
puts
more
control
in
your
hands
and
more
visibility
in
your
hands
right.
You
can
see
who's
doing
what
and
who's
requesting.
B
What
and
what's
happening
in
your
infrastructure
right
you
can
see,
you
have
a
representation
of
it
and,
and
usually
the
sync
tool
has
a
as
a
way
of
defining
what
gets
loaded
into
your
cluster
right
because,
like
here
again
there's
an
example
of
argo
and
how
to
get
you
know,
I'm
saying
hey,
I
want
you
to
target
this
revision.
I
want
you
to
get
this
repo
url.
B
You
know
I
want
you
to
deploy
to
this
server,
that
sort
of
thing
right.
It's
usually
declarative,
it's
they're,
all
pretty
similar
and
so
the
base.
This
is
a
basic
workflow
right.
So
I'm
going
to
talk
about
basic
workflow
right
like.
A
So
there
is
a
question
in
chat,
but
I
feel
like
we're
going
to
get
to
the
answer
about
how
to
you
know,
remove
race
conditions.
You
know.
E
B
B
Answer
to
but
like
from
this
is
like
a
not
even
a
10
000
foot
view
it's
like
a
10
million
foot
view
right
of
how
the
basic
workflow
is
is
right.
You
make
a
change
in
get
and
that's
the
the
sync
tool
checks
the
status
right
like
it'll
it'll
it'll
receive
like
oh
there's,
a
change
I'll
synchronize
that
into
the
cluster
right.
So
as
soon
as
whatever
branch,
you're
tracking
or
whichever
tag
you're
tracking.
As
soon
as
the
change
is
made,
it'll
it'll
start
it'll,
sync
that
to
your
cluster
right.
B
So
that's
basic
workflow
but
as
as
we
all
know,
it's
not
all
unicorns
and
rainbows
right.
There's
some
challenges
right!
There's.
Definitely
some
challenges
that
come
that
come
into
this
right.
So
you
know
we
there's
there's
been
a
lot
of
back
and
forth.
You
know,
within
with
my
my
fellow
argonauts,
we
need
to
change
our
name,
but
our
fellow
get
get
ops
folks
in
our
chat.
B
Enthusiasts
at
red
hat
right:
do
you
have
one
repo
or
do
you
have
a
separate
repo
for
or
basis
for
environments
like
like?
Do
you
have
one
monolithic
and
do
everything
with
tags?
I
think
that's.
That
was
the
original
idea.
Some
people
find
like
well.
No,
I
think
I
want
separate
repos
so,
like
you
know,
repost
structure
kind
of
gets
pretty
complicated
and
you'll
see
that
in
the
demo
right,
because
I
I
I
did
a
little
demo
right,
a
little
small,
easy
demo
managing
secrets
right
so
like.
B
B
Yeah
you're
going
to
manage
that
yeah.
Are
you
going
to
manage
that
yeah
there's
just
some
things
that
you're
just
like
okay?
Well,
like
you
know,
if
it's,
if
it's
not
in
get,
then
where
would
it
be
or
if
we
are
putting
it?
What
do
we
do
so?
That's
kind
of
like
some
of
the
things
kind
of
a
topic
I'm
actually
going
to
have
a
stream
specifically
about
secrets.
I
think
it's
episode.
2
is
going
to
be
about
because
I
need
to
look
at
my
list.
Yeah.
B
Yeah
we're
going
to
talk
about
sealed
secrets
and
so
order
of
dependent
deployments
right.
So
this
is
the
question
you
were
asking.
Was
it
calrissian
yeah.
B
Okay-
and
you
know,
order
deployments
right
like
there's
some
things
that
just
doesn't
lend
itself
to
declarative
right.
So
it's
it's.
You
know,
that's
gonna,
be
a
challenge
right,
like
I
said,
on
declarative
requirements
and
integration
with
your
ci
cd
tools.
Right,
like
you,
have
jenkins
openshift
pipelines
you
have
techton
like.
Does
the
ci
cd
or
the
sync
tool
manage
deployments
like
how
does
that
work?
So,
like
you
know,
you
already
have
a
process
in
place.
B
Like
just
challenges,
they're
trying
to
migrate
over
to
like
a
git,
ops,
workflow
right-
and
you
know,
there's
the
first
approach,
I
think-
is
it's
one
of
the
ones
that
the
again
shout
out
to
the
red
hat
canada
like
they
came
up
with,
is
that
to
have
multiple
repositories
right
so,
like
I
have
like
my
production
repo
I
have,
and
then
you
know
my
config
repo
for
for
staging
my
config
repo
for
for
testing,
and
then
I
have
like
my
code
right
in
one
repo
and
then
I
have
different
configurations
for
different
environments
right
so.
B
A
Some
modules
interesting.
C
B
Exactly
exactly
so
approach,
two
right
is
essentially
you
have
a
single
repository
for
everything
and
I'm
gonna
tell
you
right
now:
I'm
not
a
fan
of
this.
B
A
tree
one
giant
repo,
yeah,
yeah
yeah,
you
we
couldn't
fit
it
in
the
slide
like
this
is
one
repo
and
just
all
the,
and
not
only
the
directories
right
and
a
bunch
of
overlays,
a
bunch
of
bases,
a
bunch
of
directories.
You
also
have
like
tags
and
branches
to
worry
about
in
each
different
environment
right.
So
this
is
I'm
not.
You
can
do
this
this
way
too
yeah
it's
it's!
This
is
essentially
well.
B
You
wrote
this
probably
about
the
get
some
modules,
but
this
is
also
a
nightmare
to
match
which.
A
B
D
B
B
Opinions
feel
free
to
throw
in
the
chat
or
feel
free
to
send
us
a
tweet.
Whatever
the
you
know,
I
think
it's
a
better
way.
It's
it's
just
better.
It's
easier
to
manage
right
to
have
these
different
repos.
It's
like
okay!
I
need
to
make
a
config
change
to
the
dev
repo
versus
okay.
Let
me
go
to
the
main
repo
and
go
to
the
dev
branch
and
then
go
to
the
folder
that
has
the
dev
configuration
versus
the
like.
I
to
me
the
other
way
is
easier
right.
B
So
so
this
is
my
you
know
my
my
opinion
is
really
just
go
to
single
single
approach
right,
so
yeah.
A
Pretty
much
everybody
in
the
chat
is
like
poo
pooing
get
sub
modules,
so
yeah.
B
Well,
speaking
of
someone
with
with
a
strong
appearance.
C
B
So
the
next
thing
is
actually
managing
secrets
and
I
actually
had
a
pretty
interesting
conversation
I'll
be
curious
as
to
you
know,
we
can
kind
of
touch
on
it
and
we'll
get
into
deeper
in
the
next
episode,
but
so
you're
externalizing
your
secrets
right.
So
that
means
your
secrets
are
in
their
base64
right:
they're,
encoded,
they're
not
encrypted.
A
A
C
B
Do
this
yeah
and
there
is
ways
to
do
there's
ways
to
do
this
right
and,
like,
I
think,
the
the
consensus,
I
think
a
lot
of
people
like
even
at
red
hat.
I
think
bitnami
has
sealed
secrets
right.
The
weave
works,
guys
recommend,
still
secrets,
and
I
think
the
consensus
that
red
hat
is
like
sealed
secrets
is
how
you
store
it
right.
Yeah.
A
A
B
A
B
Yeah
yeah
definitely
definitely,
and
so
really
managing
secrets
is
no
secret.
You
just
have
to
encrypt
it
or
manage
it
somehow.
A
You
know
we're
not
we're
not
brushing
this
off
in
any
way,
shape
or
form.
We.
B
B
That
right,
I
think,
that's
a
very
good
startup
idea
by
the
way,
whoever
has
coding
skills
so
get
you
something
that
does
both
so
there's
sometimes.
B
A
A
A
B
A
E
A
A
B
We
go
so
yeah
so
again
order
of
some
someone
asked
right.
Sometimes
you
do
actually
have
cases
where
you
need
to
deploy
things
specific
order,
so
yeah
this.
This
was
an
issue
actually
at
red
hat
that
we
ran
into
because
we
went
all
in
on
operators
right
if
you,
unless
you're
living
under
a
rock.
If
you
talk
to
a
red
hatter,
you
would
at
some
point
they're
going
to
say
operators.
D
D
B
B
There's
there's
just
a
certain
order.
You
need
to
do
in
order
to
deploy
an
operator
right.
You
know
you
need
to
create
a
namespace
or
project
before
deploying
an
application.
You
need
to
wait
until
storage
gets
up.
There's
just
you
know,
there's
there's
a
way
to
do
this
right
and
the
tools
like
like
the
templating
tools
like
customize
and
help
automatically
handle
this
in
some
cases.
B
Right,
especially
like
the
order
and
things
right,
you
can
dictate
order
and
customize
and
and
helm,
and
also
the
tools
have
a
way
to
do
things
in
certain
orders
right
in
certain
and
argo
cd.
Has
this
thing
called
sync
phases
and
waves
right,
that'll
that
addresses
a
lot
and
all
the
other
tools
have
have
something
similar.
It's
just.
I
just
worked
with
argo,
so
much
that
I
kind
of
just
know
this
in
general.
B
There's
there's
like
a
sync
phase
right,
so
there's
like
stuff
to
do
before
you
sync
the
actual
sync
and
then
stuff
to
do
that
after
the
sync
happens
right,
so
the
the
sync
is
keeping
all
the
manifest
the
declarative,
manifest
in
sync
in
your
cluster.
You
can
do
things
before
and
you
can
do
things
after
so
that
way,
like
things
like
you
know,
wait
till
storage
is
set
up.
Wait
until
you
know
your
database
is
up
and
running
things
like
that
things.
B
You
just
need
to
do
and
then
within
each
phase
you
can
have
multiple
waves
right.
So
you
know
you
have
you
know
one
does
like
it'll
wait
until
one
wave
finishes
before
the
next
wave
starts
right.
So
you
know
with
these.
With
with
these
tools,
you
can,
you
know,
kind
of
dictate
in
what
order
things
run
and
in
my
demo
I
actually
run
into.
B
I
ran
into
this
issue
which,
which
I
fixed
with
sync
waves,
and
things
like
that
is
the
efk
stack
right
like
there's
just
yeah
things
that
need
to
have.
E
B
A
B
Yeah
yeah
and
then
there's
also
other
ways
to
do
it
as
well
right.
So
like
there's
things
that
just
you
can't
be
done
in
the
declarative
way.
So,
like
you
use
things
like
init
containers
and
jobs
right,
you
can
write
an
operator.
B
Do
resource
hooks
right,
so
I'll
have
a
way
you
know
have
some
some
hooks
have
them
hit
hooks
in
different
phases.
I'm
a
big
fan
of
init
containers
and
jobs,
just
because
it's
just
a
native
kubernetes
way
of
doing
it.
I
have
the
tool
there,
but
you
can
do
it.
You
can
do
things
in
in
different
ways
right,
so
so
so
integrating
with
ci
cd
tools
right.
So
it's
like
how
come
how
come!
B
C
B
B
Kind
of
took,
I
think,
jenkins,
is
its
own
category
because,
like
it's
like.
C
B
D
E
B
It
gets,
it
gets
crazy
right.
It
gets
it's
a
big,
a
bit
crazy.
So
you
know
remember
that
that
that
simple
high
level-
sync
right,
like
the
the-
if
I
go
back
a
few
slides
this
this
right
here,
right
like
so
this,
so
we
got
this,
that's
the
basic
workflow,
the
workflow.
Actually
right.
If
we
dig
a
little
deeper,
looks
like
this
right.
So
so
you
have
an
application
developer.
B
That
has
an
application
repo
and
we
have
an
environment,
repo
kind
of
like
what
we
said
here
right.
You
know:
does
it
commit
to
the
application
repo?
You
know
it'll,
you
know,
it'll
do
a
merge
somewhere
and
then
a
ci
cd
pipeline
happens.
Maybe
it
creates
an
image,
puts
an
image
to
a
container.
You
know
whether
it
be
quay
right
or
or
jfrog
or
whatever
you
want.
Wherever.
B
And
then
it,
and
then
that
pipeline
updates
the
environment
repo
manifest
right
because,
like
you,
may
have
a
different
tag.
You
want
to
deploy
into
your
environment,
right,
you're,
changing
versions,
v1
versus
v2s,
that
sort
of
thing
and
then,
and
then
that
gets
glommed
together
right
in
in
the
admin
side,
we
have
an
infrastructure
refill
right.
So.
D
B
A
repo
that
just
takes
care
of
the
underlying
infrastructure
of
of,
in
this
case,
openshift
right,
kubernetes
openshift.
However,
you
want
so
that
gets
an
infrastructure
repo
and
like
everything
in
the
center
of
all.
This
is
the
sync
tool
right,
whether
using
like
acm,
whether
you're
using
flux
with
argo,
whatever
it
applies
all
of
that
to
your
to
your
cluster
right.
So
this
is
the
cd
part,
the
delivery
part
it
actually
delivers
and
make
sure
that
your
cluster
is
in
the
same
version
as
you
have
in
your
repo
right.
B
So
so
this
is
this
here
is
something
you
know:
take
a
picture
memorize
it
right.
This
is
kind
of
how
it
looks
like
right
digging
a
little
deeper.
This
is
how
the
the
workflow
looks
like.
B
Nice,
so
get
ops
enables
you
to
deploy
across
multiple
clusters.
But,
like
you
know,
it's
a
trap
right.
B
Configuring
without
copying
and
pasting
yaml
everywhere
right.
So
first
we
talked
about
the
sync
tools
right,
you
know.
Well,
how
do
I
get
you
know
this
one
ammo
and
10
different
git
repos
without
duplicating
it
right.
So
one
of
the
things-
and
I
think
it's
the
tool
that
I
use
a
lot.
I.
B
Yeah
a
lot
of
people
like
helm
and
I
actually
haven't,
played
enough
with
helm.
I
don't
know
if
anyone
in
the
chat
uses
helm
within
their
get
up
works
flow.
I
haven't
used
telemavic
time
to
sink
my
teeth
into
it,
but
a
lot
of
people
love
using
helm
as
well
for
their
template.
I
use
customize
just
like
you
said
this
like
when
I
first
was
kind
of
delving
into
get
off.
Someone
said
just
use.
B
It's
essentially
the
powerful
thing
about
customize
is
that
you
can
reference
another
another
yaml
file
right,
so
the
deployment
I
say
I
want
to
reference
that
deployment
file,
but
when
you
read
it
into
the
cluster
patch
patch,
you
know
patch
the
scale
right
like
instead
of
yeah
instead
of
two.
I
want
three
right
right
or
instead
of
the
name
being
foo.
B
I
want
it
to
be
bar
right,
so
so
your
configuration
for
each
environment
gets
gets
very,
very
small,
because
you're
referencing
one
yaml,
but
then
you're
patching
it
to
match
your
environment,
and
I
think
that's
why
customizers
lends
itself
really
well
to
to
get
ops
is
just
the
templating
aspect
of
it.
I
think
it's
becoming
the
templating
language
of
get
ops
but
helm
is
coming
and
saying
hold
your
horses.
So
there's
a
lot
of
people
that,
like
helm,
that
conversations
that
I
yeah.
A
E
C
B
Yeah
finally,
yeah
yeah,
it's
especially
without
the
tiller.
Now
it's
going
to
get
a
wider
adoption,
so
I
think
I
think
that'd
be.
I
think,
it'd
be
interesting
to
see
where
we
end
up
here.
What
the
cool
thing
about
customize
is
actually
built
into
the
cli.
The.
D
B
Know
it
was
including
starting
at
1.14,
so
it's
it's
it's
there
so
like
their
customize
is
organized
like
in
a
hierarchy
right,
just
kind
of
like
everything
else
is
it's
a
series
of
directories
with
the
animals
there's
like
a
base
or
it
used
to
be
a
base.
Obviously
it's
deprecated.
Now
I
don't
know
if
you
all,
you
know,
if
you're,
if
you're
using
customize
the
base
directory,
is
deprecated
technically.
B
You
can
still
you
still
kind
of
use
it.
You
still
kind
of
have
it
with
you,
just
reference
it
as
a
resource,
and
you
know
you
put
it.
You
know
whatever
you
know,
however,
in
whichever
or
order
you
want
it
in
right
so
and
then
the
overlay
right
is
essentially
things
that
you're
overlaying
on
your
on
that
base
on
that
base.
Ammo
fire
right,
so
you
have
a
yama
file.
B
That's
that's
your
base
and
your
overlay.
You
overlay,
on
top
of
it
and
it'll
it'll,
basically
spit
out
another
yaml
right,
it'll,
take
the
base
ammo
and
whatever
you're
patching
it'll
spit
out.
You
know
the
the
yama
for
you
to
for
you
to
deploy
right,
so
you
have
kind
of
a
you.
Have
your
resources
here
right
when
you
run
when
you
run
your
your
environment
with
your
overlay,
it'll
include
the
base
and
it'll
just
do
whatever
patching.
It
needs
to
do
pretty
simple,
pretty
straightforward.
B
A
B
Yeah
yeah,
it
feels
kind
of
natural
right,
yeah
yeah.
It
feels
kind
of
natural
yeah.
It
just
feels
natural.
The
way
you
do
it
so
yeah,
it's
just
kind
of
just
some
of
the
things
I
already
mentioned.
Is
you
basically
don't
duplicate?
B
You
know
yama
right,
and
you
know
some
of
the
differences.
By
the
way
we
had
in
openshift
version
three.
We
had
a
way
to
do
templates
right
so,
like
people
would
ask.
Why
does
red
hat
do
templates?
Why
don't
they
just
use
helm
charts?
It's
like
this
is
back
when
helm
still
had
tiller
and
it
was
literally
right.
B
Templates
will
be
deprecated,
we
still
support
it
because
3.11
is
still
support,
but
moving
forward
helm,
charts
customize
the
way
to
do
it.
So
it's-
and
you
know
in
in
we
support
both
right
right
right
now
supports
both
helm
and
customize.
So.
D
B
Really,
it's
really
kind
of
like
choose
your
poison
sort
of
thing
right.
So
it's
again,
I
didn't
have
a
lot
to
talk
about
helm
because
I
don't
really
know
enough.
Maybe
one
of
these
episodes
will
you
know
I'll
I'll
dive
deep
a
little
bit.
A
E
C
B
Exactly
so
yeah,
so
I
have
a
quick
demo
to
kind
of
just
see.
You
know
what
it
looks
like
right.
So
like
right
in
the
last
few
moments,
I
know
we're
a
little
bit
over,
but
that's.
A
B
This
won't
take
very
long
right,
so
I
have.
I
have
a
gear,
repo
yeah.
Let
me
actually
put
this
in
the
chat
here.
B
A
A
B
No,
you
did
the
blob
there.
We
go
so
like
this
is
kind
of
explaining
kind
of
like
the
power
of
of
of
customize
right.
So
like
this,
this
repo
deploys
authentication
for
openshift
creates
three
groups.
It
does
the
cholesterol
binding
for
those
groups,
it
deploys
an
application
and
then
install
you
know
obviously
installs
argo
cd
first
obviously,
but
it
installs.
D
B
To
do
all
that,
and
and
it
does
the
r
back
for
argo
itself
and.
B
Access
right
so
like
it
does
it
does
everything
that
one
does
except
a
little
more
like.
If
I
go
here
to
hold
on.
Let
me
see
here:
config
overlays
default,
config
overlays
default
your
customization
right.
So
if
I
look
here
my
customization
script,
I
basically
say
take
that
config
right,
my
upstream
config
in
that
other
repo
and
I'm
just
going
to
add
a
little
bit
more
right.
I'm
going
to
add.
E
B
A
B
The
the
only
flow
is
that
you
would
have.
Let
me
go
over
this
here.
I
don't
do.
I
have
a.
I
have
an
example
of
patching.
B
B
Yeah
actually.
C
B
Repo,
so
let's,
let's
look
over
here,
not
this
one
overlays
yeah
cluster,
one
right!
So
I
have
this
is
my
so
I
do
a
so
I'm
I'm
loading
in.
Let
me
do
my
customization
right,
so
I'm
loading
in
the
base
right,
which
is
the
base.
When
I
read
that
I
want
to
take
the
deployment
and.
C
D
B
Right
all
right,
I'm
going
to
patch
it
with
whatever
it's
in
this
file
and
also
I
want
to
take
the
route
and
patch
it
whatever
it
is
in
this
file.
So
if
I
look
at
the
the
deployment
right,
I
said
replace
the
this
environment
variable
with
this
value.
Okay
and
then
read
that
same
base
deployment,
oops
and
replace
the
host
value
with
right
here,
I'm
making
I'm
leaving
it
blank
because
I
just
want
openshift
to
create
the
standard
route
but
like
if
I
had
a
specific
route.
I
would
right.
B
That
that's
essentially
like
the
difference
between
and
it's
all
in
the
customization
file,
so.
A
Yeah
narendev
is
like
hey,
you
need
to
use
octotree.
A
E
B
So,
essentially
yeah.
So
my
the
point
of
of
showing
you
that
other
repo
was
that
I'm
gonna
suck
things
in
from
other
repos.
A
B
B
Yeah,
it's
all
exactly
so
like
if
I
go
so
first,
let
me
let
me
install
argo
right
so
hold
on.
Let
me
go
to
my.
Let
me
export.
A
B
Yeah
right
like
if
I
get
pods
grip,
argo
right,
there's
nothing
there
yeah
so
I'll,
install
argo,
so
this
here
essentially
just
installs
argo
it'll.
It
will
loop
through
until
argo's
installed
nice,
so
it'll
fail
the
first
time.
Obviously,
because
it's
not
just
reasons
order
of
operations,
like
I
said
before,
is
hard
and
then
I'll
deploy
this
repo
right.
B
Yeah
so
yeah,
okay,
unchanged
yeah
paste
and
then,
if
this
essentially
installs
that
entire
stack
right
so
it'll
deploy
the
r
back
it'll,
deploy
the
users
it'll.
You
know
from
that
other
repo
and
then
on
my
repo,
I'm
installing
efk
and
it'll
install
that
stack
as
well.
It'll
do
all
that
syncing!
So
and
that's
my
cluster
config
right
and
my
in
my
cluster
config.
B
B
Yeah
project
base,
so
I
have,
I
know,
that's
that's
the
hardback.
B
The
so
here
I'm
saying,
okay,
you
know
I'm
going
to
deploy
this
application.
This
is
not
in
my
repo
right.
This
is
an
application,
that's
something.
B
That's
something
else
right,
so
that's
this
repo
here,
the
application
repo.
So
me
as
a
operations
I
can
deploy
the
cluster,
but
if
a
change
needs
to
be
made,
it
needs
to
be
made
in
the
application.
Repo
right
and
my
my
sync
tool.
Argo
cd's
job
is
only
to
make
sure
those
are
in
sync
right,
so,
whether
you're
using
article
cd
or
acm,
it
doesn't
seem
the
same
thing
right.
So,
if
I
go
here,
let's
see
where
it
is
cube.
Ctl
get
pods
dash
a
grip,
argo
cool.
B
Let's
go,
do
get
routes,
grab.
Argo.
B
Here,
yes,
advanced,
accept
the
self-signed
certificate
log
in
via
openshift
right,
because
we
want
to
do
the
oauth
we're
tying
in
oauth
another
shout
out
to
andy
bach,
who
block?
Who
did
the
tie-in
the
argo
cd
and
the?
So
that's
it
gives
me
an
hd
password
file.
That
means
my.
My
users
are
loaded
in.
B
Right
I'll
selected
permissions,
so
here
it
gives
me
a
configuration
here
like,
for
instance,
this
is
out
of
sync.
I
can
sync
this
on
demand.
You.
B
B
So
here
yeah,
so
here
I
have
my
cluster
config
right
that
this
is
like
you
know.
I
set
up
my
authentication,
my
container
security.
B
Efk,
you
know
monitoring.
B
A
Okay
but
yeah,
I
can
see
the.
B
A
A
B
And
you
know
what's
cool
about
this
is
like
I
can
log
in
not
that
one
I
can
log
in
via,
like
a
regular
user
right
like
ocp.
C
D
A
B
None
of
that
yeah,
I
just
see
my
app
because
really
that's
all
I
care
about
right
right.
You
know,
even
if
I
want
to
delete
it,
it
won't.
Let
me
right
because
it's
like
you
know.
B
A
B
It
goes
right,
and
so-
and
this
is-
and
this
is
just
my
view
right
so
right-
I'm
able
to
as
a
developer
just
see
without
having
to
worry
about
like
what's
the
underlying
infrastructure
and
without
like,
like
we
said
before:
it's
not
like
you
know,
you're,
not
you're,
not
letting
the
developers
run
the
run
the
farm
here
right,
there's
still
separation,
it's
just
how
this
is
driven
is
different
right
so
like
if
I
go
here
and
if
I
want
to
let's
say:
oh,
this
is
priceless
right
so
like
if
I
want
to
take
the
front
end
and
let's
go
to
the
deployment
right
like
if
I
want
two
replicas
here
right:
let's,
let's
just
go
through
a
simple
workflow,
where
what
can
I?
B
Right
and
then
here
I'm
gonna,
you
know,
make
a
change
front
end
and
I
want
to
right
edit
here
again
admin
guys.
This
is
easy
right.
You
can
even
do
it
through
the
web
ui.
I
want.
B
You
would
yeah
so
then
I
just
do
a
pr
right.
I
want
to
go.
I
want
to
take
my
pr
into
this,
because
I
want
two
replicas
right
so
now
you
can
already
see
that
there's
like
to
change
the
scale.
I
have
one
replica
here
tour
you
can
actually
already
see.
You
know.
You
know.
A
B
Verified
user.
The
whole
nine
yard
line
like
create
pull,
requests
right.
So
then,
now
right
you
go
through
the
process
right
here
I
go.
You
know,
like
you
know.
Why
do
you
want
this
right?
Like
you
just
go
through
the
same
workflow
as
you
would
normally
except
you
know.
You
start
to
review
blah
blah
blah
right
and
I
I
can
you
know:
merge,
pull
requests,
yeah,
that's
confirming
confirmed
right.
B
Argo
well
then,
where
is
the
deployment
here
yeah?
So
there's
one
pod
running
here
so
now
that
I
sync
this.
B
B
All
right,
you
wouldn't
do
that
in
production.
So
now
I
have
two
pods
right
so
now
you
know
I
as
a
developer.
B
A
C
B
Yeah,
so
so
yeah,
so
this
is
kind
of
so
this
is
this
this
first
episode
of
this
of
the
stream
I
kind
of
want
to
just
kind
of
level
set
of
what
we're
doing
you
know
what
what
I
want
to
do
with
this
with
the
stream
is
kind
of
having
like
an
office
hours,
but
first
I
kind
of
wanted
to
level
set
and
make
sure
we
all
kind
of
just
talk
in
the
same
language
right
so
like
what?
What
get
ops
is?
B
It's
nothing,
nothing,
fancy
it's
not
a
specific
tool,
it's
just
a
set
of
practices
right
and
then
right
in
another
episode,
we'll
dive
deep
into
specific
topics.
I
think
it's
worth
it
to
dive
into
specific
top
topics.
I
think
secret
management
is
like
the
biggest
one
I
always
get
asked
about.
So
I
think
my
next
episode
will
be
that
or
the
episode
after
that.
A
A
B
So
yeah,
so
I
hope
you
know,
I
hope
to
see
all
of
you
not
next
week
but
the
week
after
maybe
I'll
increase
the
cadence.
If
there's
enough
interest
in
it,
you
know
I'll
increase
the
cadence
and
we'll
have
I
already
have
a
few.
A
few
guests
lined
up
a
few.
Maybe
special
guests
may
be
able
to
come
on
wow.
B
B
As
as
much
as
as
much
as
possible,
so
so
yeah,
so
I
don't
have
anything
else.
A
A
You're
right
like
and
thank
thank
you
out
there
for
joining
us
everyone.
Tomorrow,
we
have
on
the
channel
not
much
because
it's
friday.
B
That's
right,
it's
friday,
nobody
works
on
friday,
though.
Well
I
mean.
A
You
know,
but
we
have
an
openshift
commons
briefing
with
a
good
friend
of
mine
from
github
sasha
rosenbaum,
so
she'll
be.
A
E
A
B
D
A
A
You
to
tune
in
because
that
talk
at
noon
tomorrow,
eastern
time
we'll
be
talking
about
how
you
create
allyship
within
your
organization.
That's.
B
C
A
You've
got
to
have
community
good
communications.
You
know
trust
assuming
positive
intent.
All
those
things
are
important.
B
C
A
All
right
awesome,
thank
you,
everyone
for
joining
us
and
if
you
have
any
questions,
any
concerns,
just
let
us
know
you
can
always
find
me
on
twitter
at
chris
short
and
subscribe
to
the
calendar.
If
you
want
to,
you
know,
check
us
out
in
the
future.
We
appreciate
it
and
have
a
good
one
out
there.