►
From YouTube: OCB: GitOps in OpenShift using Helm and ArgoCD
Description
Join us for an overview and demo of GitOps in OpenShift using Helm and ArgoCD!
Speakers: Andrew Block, Christian Hernandez, Siamak Sadeghianfar, Karena Angell (Red Hat)
Host: Karena Angell
A
Hello,
everyone
and
welcome
to
another
openshift
commons.
We
have
a
great
show
for
you
today.
I'm
really
excited
about.
Well,
I'm
excited
about
all
of
them,
but
today
we
have
christian
hernandez.
He
is
get
ops,
rockstar
right
openshift.
If
you
haven't
watched
the
get
ops
happy
hour,
please
check
that
out.
That's
on
thursdays
and
he'll
plug
it
later.
A
We
also
have
andrew
block
distinguished
architect
and
openshift
guru,
pretty
much
everything
and
then
cmak
is
also
joining
us
today
and
he
is
an
openshift
product
manager
and
he
covers
all
the
stuff
that
you
are
interested
in
right,
get
offs
pipelines
a
bunch
of
stuff.
So
again
it's
an
amazing
group.
We
have
today
and
we
are
going
to
kick
it
off
with
this
get
offs
and
open
shift
with
argo,
cd
and
helm
and
christian.
Please
take
it
away.
B
Yeah,
so
thank
you
very
much
again.
My
name
is
chris
hernandez
technical
marketing
manager
at
red
hat
and
overall
git,
ops,
enthusiast
right,
and
so
what
I'm
gonna
do
is.
I'm
just
gonna
give
a
brief
overview
of
get
ops
and
argo
cd,
leaving
plenty
of
wiggle
room
for
any
questions
or
any
comments
that
may
come
up
and
and
then
I'll
hand
it
over
to
andrew
who
is
like
like
what
was
said.
B
Polyglot
yeah
exactly
so
it's
it's
one
of
the
things.
That's
I
kind
of
just
start
with
is
or
what
is
what
is
get
ops
right
and
it's
really
by
definition,
get
ops
is
when
the
entire
infrastructure,
your
application
deployment,
everything
is
fully
saved
and
installed
represented
in
a
git
repository
right.
So
generically.
That's
that's
that's!
What's
what
get
ops
is
right,
so
everything
in
your
having
to
do
with
your
environment
is
on
git,
and
so
I
usually
just
like
to
leave
it
at
that.
B
B
We
it
that
that
term
kind
of
gets
overused
a
lot,
but
this
is
literally,
I
actually
truly
mean
a
get
ops
journey
right
and
it's
it's
really
a
evolution
of
what
we
brought
with
like
the
idea
of
devops
and
and
agile
and
and
actually
chris
short,
as
as
you
may
all
know,
the
the
host
of
openshift.tv
in
2018
literally
said
get
ops
is
a
holy
grail
of
devops
right.
So
it's
really
a
really
with
you
know.
B
The
idea
of
dead
box
practices
where
we
want
to
get
to
get
ops
is
really
that
end
goal
right
where
everything
is
described
in
a
git
repository
and
everyone
can
get
them
involved,
so
so
really
like.
Why
get
us
right?
So
it's
like
you
know
you
hear
this
buzzword,
it's
like
well.
Why
would
I
want
okay?
Why
would
I
want
githubs
right?
B
And
so
these
are
some
of
the
challenges
that
get
ops
addresses
right,
I'll
call
a
call
out
a
few
of
these
things
like
it
takes
weeks
or
even
months
to
get
to
get
me
an
environment.
You
know
my
application
behaves
differently
in
production.
I
didn't
test.
These
are
some
of
the
things
that
I
that
I,
in
in
my
life,
have
heard
personally
and
things
like
production
deployments
have
very
low
success
rates.
B
So
if,
when
you
take
a
look
at
some
of
these
things
that
get
ups
addresses,
these
are
actually
some
of
the
things
that
devops
addresses
right.
So
it's
like.
Oh,
what's
really,
what's
what's
the
difference
right
between
like
get
ops,
devops
like?
What's
how
are
they
all
tied
together,
people
a
lot
of
the
times?
People
use
these,
you
know
if
it
fits
right
in
right,
they'll,
say
devops
and
get
ups.
You
know,
especially
us
that
that
are
really
into
get
ups.
B
You
know
talk
about
devops,
because,
while
devops
is
actually
a
culture
right
get
ops
is
actually
that
culture
in
practice
right.
So
it's
it's
really
as
as
again
as
chris
short
put
it.
I
guess
the
best,
which
is
why
I
always
quote
him
anytime,
I
present
get
ops.
Is
that
get
ops
is
literally
the
holy
grail
right?
It's
like
I
have
a
get
repo
that
everyone
can
contribute
to,
and
it
manages
my
infrastructure
anytime
via
pull
request
right.
B
So
so
some
of
the
benefits
right
you
get
it
is
that
since
it's
all
in
get
all
change
or
auditable,
meaning
like
you
have
this
convenient
trail
of
all
the
changes
that
you've
made
in
your
environment
right
anything
as
simple
as
someone
scaled,
this,
the
cluster
from
three
nodes
to
four
nodes.
That's
in
get
someone
deployed
a
new
version
of
application.
That's
get
that's
in
get
so
at
every
all.
The
benefits
you
get
from
git
is
you.
You
know
by
extension,
you
get
it
in
get
offs
right.
B
B
So
you
have
the
ability
to
you
know
just
I
can
get
just
like
in
your
code
repository
if
you
roll
out
a
change
and
that
change
breaks,
something
you
can
always
roll
back
to
a
previous
git
commit
right
or
get
tagged.
Disaster
recovery
is,
is
you
know
I'll
I'll
put
it
simply
reapply
the
current
state
of
the
manifest
meaning
you
just
reapply.
You
know
you,
you
lose
a
cluster,
you
just
reapply
what
you
have
there
in
your
last
known,
good
state,
and
then
you
have
the
cluster
up
and
running.
There
was
a.
B
There
was
a
good
article.
Actually
I
believe
it
was.
It
was
written
actually
by
weaveworks
who
talked
about
a
customer
that
essentially
they
they
restored
their
cluster
in
about
15
minutes
right,
so
they
were
went
from
down
to
fully
operational
back
in
15
minutes,
and
most
of
that
time
was
getting.
You
know,
storage,
backups
up
and
running.
So
the
experience
is
really
pushes
and
pull
requests
right.
So
you
make
a
pull
request
anytime.
You
want
to
make
a
change
that
change
can
come
from
anywhere
right.
B
There's
obviously
release
skates
in
place,
but
the
idea
is
the
you
know
if
I,
as
a
administrator
can
make
a
pull
request
to
the
deployment
code
of
the
application,
because
I
want
it
to
behave
differently
and
vice
versa
right.
So
it's
really!
You
know
you.
You
have
this
whole
convenient
way
of
working
together
inside
of
git
right,
so
it's
we've
get
already.
Has
that
the
the
it
has
the
the
practice
of
us
working
together
built
in,
and
we
just
take
advantage
so
and
get
ops
really
is
for
everyone
right.
B
So
a
lot
of
the
times.
People
think
that
git
ops
is
really
like
a
developer
tool
and
for
a
lot
of
time,
is
right.
You're,
literally
deploying
code
using
this
practice
right
and
I'll
go
over
in
a
bit
a
little
bit
about
things
like
the
sync
tools,
but
in
actuality
it's
really
for
everyone
right.
It's
really
it's
a
devops
tool
right,
it's
devops
in
practice,
so
you
can't
have
devops
without
the
ops
either.
B
So
it's
really
for
developers
for
operations
for
sre
teams,
for
it's
really
it's
really
not
as
geared
specifically
towards
any
any
core
user
group
so
and
so
there
so
open
shift
and
get
ops
right.
So
I
always
I
always
make
the
the
comparison
right
and
I
think
it's
going
to
become.
My
tagline
is
like
it's
like
peanut
butter
and
chocolate
right.
So
it's
you
know
get
ops
is
a
declarative
method
to
to
declare
what's
in
your
cluster
and
openshift
is
a
declarative
environment
right.
B
It's
built
on
kubernetes,
and,
and
so
you
know,
you
have
a
declarative
way
of
deploying
your
application
in
your
infrastructure
stack
and
now
you
have
a
a
method
platform
that
does
that
right,
so
it
kind
of
just
like
fits
together
right.
So
all
the
declarations
are
in
yaml
files
right,
so
it's
easily
stored.
B
B
So
some
of
the
get
off
principles
so
now
this
this
is
the
part
where
I
always
always
talk
about
how
like
this
is
a
journey.
This
is
where
we
are.
This
is
where
we
are
like
now
right.
This
is
kind
of
kind
of
the
the
idea
that's
where
we
are
currently
of
like
how
to
use
get
ops
and
openshift
right.
So
I
always
recommend
separate
application
source
code
from
your
manifest
yaml
right.
B
So
in
the
beginning
I
have
always,
I
always
had
the
application
source
code
and
the
yaml
manifest
deployment
in
in
the
same
repo.
Actually
it's
a
lot
better.
If
you
maintain
those
separately
right,
so
they
have,
they
have
source
code
commits
are
independent
from
deployment
commits.
So
all
your
deployment
manifests
are
in
standard.
Kubernetes
manifests
right.
Everyone
says
that
there's
a
you
know,
I'm.
B
It
doesn't
have
to
be
ammo
right,
it
could
be
json
as
well,
but
all
those
manifests
are
standard,
kubernetes
manifests
stored
and
get
right.
So
one
of
the
big
things
is
that
what
you
want
to
do
is
you
want
to
avoid
duplication
of
yaml
right
across
environments
and
I'll
go
over
I'll.
Go
over
that
in
a
little
bit.
How
that
looks
like
but
and
manifest
should
be
applied
with
standard
open
shipping
case
tooling
right,
so
it
it
there's
really
nothing
new
here
that
you
haven't
really
been
doing.
B
If
you've
been
working
with
kubernetes
or
or
openshift
there,
there's
not
really
any
new
tools
right
per
se
right.
There's
there's
there's
a
couple
new
tools,
but
it
really
is
just
kind
of
like
a
standard
open
shift
in
kate's,
tooling
here.
So
so,
really,
like
I
said
before
your
your
day,
two
looks
looks
really
a
lot
like
like
what
you've
been
doing
normally
right
for
for
the
developers
out
there.
It's
really
just
kind
of
like
what
you've
always
been
doing
right
you've
been
doing
a
pull
request.
B
You
know
you
merge
the
pull
requests
and
then
you
run
your
pipeline
and
it
just
you
know
it
just
automatically
happens
right
so
for
the
operation
guys
I
mean
for
me
from
an
operations
background.
This
is
a
little
change,
but
it's
it's.
It's
really
something
that's
been
there
for
a
long
time,
tire
tested
and
true
right
so
for
from
an
operations.
Guy
from
that,
when
you
hear
that
that
kind
of
just
calms
my
nerves,
okay,
it's
tired,
tested,
true
people
have
been
doing
it
for
a
long
long
time
for
years.
B
Is
this
whole
process
of
get
pull
requests
and
merges
right
and
automation?
So
so
all
the
changes
are
triggered
from
get.
I
remember
one
day
this
was
a
long.
Long
time
ago
I
saw
a
talk
by
kelsey,
kelsey
hightower
right.
Some
of
you
may
know
him
he.
This
is
really
really
early
on
kubernetes
right.
This
is
like
kubernetes
alpha,
and
he
was
talking
about
like
kubernetes
is
how
you
design
a
system.
When
I
take
your
ssh
keys
away
right
get
now
get
ups.
B
Now,
not
only
am
I
taking
your
ssh
keys
away,
I'm
taking
away
your
cube,
ct
all
the
way
right.
So
it's
it's
everything
is
driven
from
git
right
and
that's
that's
the
whole.
That's
the
whole
idea.
So
so
there's
one
of
the
one
of
the
things
that
get
ops
uses
right
and
I
think
one
of
the
things
that's
become
very
popular
is
a
syncing
tool
right.
So
a
sync
tool
is,
is
really
just
it's.
B
It's
built
on
native
kubernetes,
primitives
right,
it's
it's
the
whole
crd
and,
and
you
know,
custom
resource
custom
resource
definition,
that's
built
in
kubernetes
right.
The
way
to
extend
the
kubernetes
api
is
how
these
sync
tools
are
are
built
upon
right.
So
some
of
the
things
that
a
sync
tool
would
do
right.
The
example
on
the
right
here,
as
you
see,
is
argo
cd,
but
you
automatically
detect
drift
and-
and
you
correct
it
right
so
it's
it's.
B
It's
built
on
that
control
loop,
that
that's
just
built
natively
in
kubernetes,
right,
it'll,
see
desired,
state
and
it'll,
see
current
state
and
it'll.
Try
to
reconcile
that
right,
and
so
some
of
the
popular
get
ups
tools
for
syncing
is
like
things
like
argo,
cd,
acm,
ansible,
flux,
cd,
those
are
kind
of
just
some
of
the
big
ones
that
bubble
up
when
you're.
Looking
for
tools
that
do
the
syncing
right,
so
it's
really
nothing
new.
B
In
the
kubernetes
and
new,
I
mean
that
relative
to
kubernetes
right
is
basically
you're,
taking
the
concept
of
crds
and
crs,
and
we
built
a
tool
around
that
to
make
sure
their
clusters
completely
in
sync
right.
So
once
you
get
like
the
cr
implant
crd
in
place
right
once
you
get
your
sync
tool,
there's
a
way
to
represent
your
entire
stack
in
in
a
manifest
right.
So,
for
example,
the
example
on
the
right
here
shows
an
argo
cd.
B
Application
is
what
they
call
an
application,
and
you
basically
tell
it
things
like
what
server
I
want
to
deploy
it
on
what
project
I
want
to
deploy
it
to
what
you
know.
What
the
what
the
repo
url,
what
the
path
is,
what
the
the
branch
or
tag
name
is.
If
I
want
it
automated
right,
do
I
want
to
prune
anything?
That's
not
in
that
name
space
all
right,
so
you
can
kind
of
just
declare.
B
I
want
this
to
be
deployed
in
this
cluster
and
I
want
you
to
watch
this
repo
right
and
the
entire
stack
right
is
in
isn't
get
right,
all
name,
spaces
deployments,
ingress
definition,
secrets
right
operator
manifest,
and
so
usually
the
the
sync
tool
has
a
way
of
defining
that
right,
and
this
is
kind
of
right
here
again.
The
example
here
is
with
argo
cd,
so
so
the
synchronization
is.
This
is
a
basic
workflow
right.
B
This
is
not
like
the
end
result
workflow,
but
this
is
kind
of
just
conceptually,
so
you
get
get
an
idea.
The
real
workflow
is
a
little
bit
more
complex
than
this,
but
the
idea
is
from
a
10
million
foot
view.
Is
you
make
a
change
in
get
right?
Either
someone
merges
a
pull
request
or
you
have
some
sort
of
automation
that
automatically
approves
certain
pull
requests
and
merges
it.
B
The
the
sync
tool
will
either
be
either
via
polling
or
a
push
event
or
whatever
or
in
case
like
if
you're,
using
a
sync
tool.
Like
argo
cd
that
happens
in
the
control
loop
automatically
well
then
check
the
status
right.
It'll
check
to
see.
Okay,
hey
the
declared
state
says
one
thing
and
the
the
the
current
states
is
something
else.
So
I'm
going
to
go
ahead
and
synchronize
I'm
going
to
reconcile
those
two,
so
it'll
change
anything
it
needs
to
change
and
then
it
will.
B
So
one
of
the
things
one
of
the
one
of
the
issues
right
so
there's
there's
certain
challenges
that
come
with
get
offs
right
and
there's,
like
you
know
again,
I
could
do
you
know
a
whole
hour
a
whole
couple
hours
about
this,
but
really
is
to
avoid
yellow
duplication
right.
So
that's
like
one
of
the
big
things
right,
so
I
I
I
can
deploy
these
across
multiple
environments.
B
B
So
you
know
that's
one
of
the
one
of
the
things
that
you
have
to
look
out
for,
and
one
of
the
things
is:
did
you
use
templating
tools
right
so
there's
all
kinds
of
templating
tools
where
you
take
a
a
core
yaml
file,
and
then
you
templatize
that
right,
so
you
have
one
core
and
then
you
may
be
changing
a
few
pinching,
a
few
things
in
that
yaml
file
right.
So
some
of
the
popular
templating
tools
are
really
customized
and
and
helm.
B
C
There,
hopefully,
everyone
can
see
the
screen
so,
for
those
of
you
who
don't
know
helm
is
a
package
manager
for
kubernetes
applications.
So
those
of
you
who
are
familiar
with
typical
package
managers
on
your
operating
system,
dnf
yum
apt-get
brew,
which
is
kind
of
the
unofficial
for
mac
os
helen-
has
become
the
de
facto
packaging
mechanism
for
packaging,
different
components
in
a
kubernetes
application
into
getting
it
deployed
to
a
kubernetes
environment.
C
Hell
movie
consists
of
three
primary
pieces.
First,
one
is
a
chart.
A
chart
really
is
just
a
set
of
related
kubernetes
manifests.
A
typical
application
can
consist
of
one
or
more
different
types
of
kubernetes
manifests
everything
from
a
deployment
a
service,
maybe
a
config
map.
Anything
that
can
be
deployed
to
kubernetes
environment
and
encapsulated
into
it
into
a
single
atomic
unit
goes
into
a
chart.
C
C
C
So
you
have
your
chart
and
associated
templates
values
which
are
the
configuration
inputs
so
think
of
it,
as
templates
are
their
dynamic
abilities
to
customize
what
your
kubernetes
manifest
may
look
like.
So,
in
certain
cases
you
may
want
to
customize
the
image
location,
the
types
of
resources
that
you
want
to
apply
to
your
application,
maybe
a
liveness
or
readiness
probe,
along
with
other
components,
those
get
combined
with
values.
Those
are
the
injected
the
injected
inputs
for
customizing
those
specific
templates.
So
in
certain
cases
I
want
to
use
my
dev
image
or
my
prod
image.
C
So
here's
an
example
of
what
a
helm
template
does
look
like,
as
you
can
see,
a
lot
of
the
bracketed
fields.
Those
are
the
components
that
will
be
dynamically
templatized
and
replaced
by
the
values
or
other
types
of
injection
instantiated
injection
at
runtime.
So
for
those
of
you
who
are
familiar
with
the
helm
context
values.build.url.
C
So
when
you
go
in
and
specify
that
you
want
to
build
from
a
certain
uri,
you
either
provide
that
as
a
default
value,
that's
provided
potentially
within
your
helm,
chart
or
you
can
override
that
value
at
runtime
and
for
an
example,
a
value
file
looks
very
similar
to
what
it
what
it
is
here
on
the
left.
So
basically
build.uri
is
this
github
url
for
some
quick
starts
that
then
gets
combined
at
runtime
using
the
helm,
install
command,
and
then
you
can
specify
a
specific
file.
C
So
you
do
helm,
install
you
give
it
the
name
of
the
release
you
want
to
create.
You
give
it
the
location
of
the
chart,
whether
it
be
from
a
repository
or
a
local
directory
on
your
physical
machine,
and
you
specify
optionally,
a
set
of
values,
files
or
value
of
inputs
and
those
go
ahead
and
create
the
different
type
of
resources
that
will
be
installed
to
your
openshift
in
kubernetes,
environment.
C
Now
this
is
where
very
much
a
christian
said,
the
peanut
butter
and
the
chocolate
start
coming
together,
because
we
can
go
ahead
and
extend
the
capabilities
that
christian
mentioned
earlier
regarding
using
get
offs
argo
cd
in
this
reconciler
loop
and
integrate
it
with
helm.
You
can
add
charts
that
are
stored
in
git
repositories
or
helm
repositories.
C
Okay,
demo
time
my
favorite
time
of
the
day,
what
we're
going
to
show
today
is
a
git
ops
approach
for
managing
applications
as
helm,
charts
we're
going
to
leverage
a
the
quarkus
red
hat
helms
chart
which
is
in
alpha.
You
know
we're
still
curating
it
to
be
able
to
deploy
a
quarkus-based
application
to
an
openshift
environment
and
we're
going
to
explicitly
demonstrate
how
to
integrate
argo
cd,
to
really
show
you
how
git
ops
can
be
used
to
manage
not
only
your
openjet
cluster,
but
also
using
helm,
sound.
C
B
C
C
And
now
we
have
our
argo
cd
environment,
so
those
of
you
in
the
chat
who
here
has
never
used
argo
cd,
we're
going
to
kind
of
walk
through
how
to
use
argo,
cd
together
and
how
to
add
a
known
chart
to
it
and
then
have
it
managed
by
get
outs
so
just
to
browse
around
for
those
of
you
who
are
unfamiliar
with
it.
This
is
the
home
screen
for
argo
cd,
where
you
can
define
a
set
of
different
applications
in
christian.
C
All
right
so
inside
the
configuration
page,
we
have
a
set
of
repositories
that
we
can
set
up.
Certificates
are
important,
especially
when
working
in
large
you
know
typical
organizations
that
might
have
self-signed
or
industry
provided
certificates.
You
can
add
those
so
that
your
gets
your
github
server.
Argo
cd
can
trust
those
destinations
projects.
Allow
you
to
go
ahead
and
configure
different
types
of
permissioning.
C
So
let's
say
you
want
to
have
certain
teams
get
access
to
perform
certain
actions
in
certain
openshift
projects
and
name
spaces?
You
can
configure
it
there
as
well
as
customizing
the
type
of
resources
that
you
want
to
have
be
deployed.
So
let's
say
you
don't
want
to
give
them
access
to
create
custom,
resource
definitions
or
other
specific
types
of
resources.
You
can.
C
You
can
create
a
whitelist
and
blacklist
items
as
well,
but
in
particular
I
actually
cheated
here,
because
it's
I
actually
went
ahead
and
added
a
the
hell,
the
get
ops,
film,
quarkus
application
repository,
which
will
allow
us
to
basically
kind
of
get
really
fast
into
this
demo,
because
we
have
a
short
amount
of
time.
So
this
is
our
sample
application,
which
is
basically
a
hello
world
for
quarkus.
C
Quercus
is
a
lightweight
java
framework
super
supersonic,
subatomic
java
for
spinning
up
a
java
application
very
quickly,
very
little
runtime,
very
similar
to
if
you're
familiar
with
spring
boot,
even
faster,
but
using
that
micro
services
architecture
for
developing
java
applications
in
the
cloud.
Actually,
this
would
be
the
application.
C
And
it
is
basically
hello
world,
so
we're
going
to
we're
gonna
kind
of
demonstrate
that
in
argo,
cd,
so
to
add
a
helm
chart
to
argo
cd.
Very
much
like
you
would
any
other
get
off
space
application,
we'll
go
ahead
and
click
on
create,
we'll
give
it
a
name
and
we'll
give
it
the
name
of
the
repository
which
is
basically
get
offs,
helm,
quarkus.
C
B
Yeah,
so
there
is
a
the
sync
policy:
does
you
can
choose
one
or
two
things
right?
There's
the
manuals
manual,
sync
policy,
meaning
that
it'll
just
create
the
definition
right.
It'll
just
basically
create
the
instance
in
inargo,
but
not
do
anything
right,
yeah,
it'll,
wait
for
you
to
manually.
Do
the
syncing
each
time
it
happens
either
via
an
api
call
or
whether
you
actually
click
the
button
that
says
sync
or
automatic
right.
B
So
you
have
here
also
the
the
idea
here
is
I'd
like
to
call
out
real
quick.
Is
the
prune
resources
right,
so
the
prune
resources,
meaning
that
if
it
finds
something
on
in
in
the
name,
space
you're
deploying
to
that's
not
in
the
repo
it'll
delete
it
right?
So
it'll
you
have
the
you,
have
the
choice
of
either
keeping
things
it
doesn't
know
about
or
deleting
things
it
doesn't
know
about.
So
that's
a
very
important
thing
to
call
out.
C
C
C
And
that's
not
the
one
I
actually
wanted
to
deploy,
which
is
kind
of
strange.
Let's
double
check
that
really
fast.
This
is
basically
my
source
control,
okay,
cool.
What
we're
going
to
do
here
is
we're
going
to
specify.
Where
is
where
is
my
helm
chart
and
my
helm
chart
should
be
located
at
let's
go
ahead
and
double
check
that.
E
C
C
Quercus
and
we
got
a
chance
to
override
these
value
files.
Now,
if
you're
familiar
with
with
helm,
you'll
mention
you'll
notice
that
there
are
a
number
of
values,
everything
from
at
least
from
this
chart,
everything
from
where
your
image
is
located,
where
the
where,
if
you're
performing
a
build,
you
can
go
in
and
build
your
application.
C
So
what
we
can
do
is
we
can
either
provide
a
file
itself
or
we
can
override
certain
values,
and
I
am,
and
I'm
going
to
go
ahead
and
actually
override
a
few
values
number
one.
We
already
have
an
image
shipped
with
it's
already
out
there
in
quite
a
I
o,
we're
just
going
to
go
ahead
and
leverage
it.
So
I'm
going
to
turn,
builds
to
false
I'm
going
to
scroll
down
and
skip
all
the
build
stuff.
Don't
worry
about
that?
C
We're
going
to
go
down
all
the
way
to
the
bottom
and
we're
going
to
specify
the
image
name
and
the
image
tag,
and
once
again,
I'm
going
to
cheat
here
just
because,
like
a
good
cooking,
show,
just
gonna
go
ahead
and
go
down
and
find
the
values
that
I
want
to
leverage
and,
if
you're
familiar
with
customize,
I
am
using
customize
here,
which
will
show
a
little
bit
later
on
on
how
to
automate
this
entire
process.
So
christian,
do
you
want
to
kind
of
talk
about
customize
for
a
second?
B
Yeah,
so
customize
is
another
a
way
to
template.
Kubernetes
resources
right
so
like
the
idea
is
that
you
have
a
single
deployment.
Manifest
is
just
take
a
simple
example
of
a
deployment
manifest,
and
you
know
you
you
want
to
change
certain
things
depending
on
which
and
on
right.
So,
for
example,
the
the
most
common
use
case
is
the
image
right.
So
the
image
that
you
deploy
in
development
is
different
than
deploying
in
production.
The
only
difference
is
the
image,
but
the
manifest
is
the
exact
same.
B
So
what
you
can
do
with
customizing,
you
say
hey
when
you
deploy
to
this
cluster
use
this
image
when
you
deploy
to
the
other
cluster,
deploy
the
other
image
right
and
it's
done
using
json
patching
or
you
know
any
any
other.
There's
there's
a
lot
of
ways
to
patch
a
customize
and
you
can
do
again
another
hour
and
just
customize,
but
that's
the
that's.
The
idea
of
customize.
C
C
C
And
I
don't
need
to
see
that
so,
if
you
go
to
add,
this
is
brand
new.
Let's
go
ahead
and
just
pick
on
this
just
to
have
it
there's
an
entire
argo.
There's
an
entire
helm,
chart
section
of
the
opengl
developer
perspective
to
add
you
can
scroll
down
all
the
way
to
the
bottom
and
you'll
see,
there's
a
brand
new
helm
chart.
This
is
the
same
one
that
I'm
using
in
this
demo
right
now,
so
you
can
go
ahead
and
give
it
a
try
in
your
environment,
obviously
still
alpha.
C
C
Go
ahead,
copy
it
open
up
a
brand
new
tab
and
you'll
see
we
have
oh
github's.
Github
loves
helm
just
like
that.
It's
great,
but
this
doesn't
really
it
gets
us
there.
We
got,
we
got
you
know
deployed.
We
did
we
showcased
how
in
our
a
helm,
chair
can
go
ahead
and
be
used
with
argo
cd,
but
we
really
didn't
really
emphasize
the
get
ops
based
approach.
I
know
christian's
like
this
is
nice,
but
we
can
do
better
right.
C
C
We
have
the
technology
so
inside
this
example.
Application
on
the
main
branch
is
the
application
itself,
which
is
basically
you
know
hello,
world
quarkx
basics.
Now,
if
you
want
to
go
ahead
and
deploy
the
application
and
build
it
yourself
on
your
local
machine,
you
can
do
that,
but
there's
a
get
ops
branch
that
contains
all
the
different
manifests
that
you
can
use
to
not
only
demonstrate
or
spin
up
this
demo
in
your
environments,
but
we're
going
to
leverage
it
to
be
able
to
manage
our
argosy
manifest
right
now.
C
C
C
C
One
is
this
bootstrap
application
that
basically
includes
two
app
of
apps.
One
would
be
the
application
that
we
created
previously
the
get
ops,
helm,
porcus
app,
but
we
have
this
brand
new
one
get
ops,
helm,
focus
prod.
That
represents
our
production
application,
we're
using
the
same
charts,
we're
just
providing
different
values
and
we'll
walk
through
that
right
now.
So,
if
we
click
on
that
sorry
go
click
on
that
you'll
see.
This
is
basically
very
similar.
Everything's
been
synced,
everything's,
all
green
everything's
working
great.
C
C
Our
application
will
go
ahead
and
look
for
that
environment
variable
and
change
how
the
application
reacts.
So,
if
you
recall
in
our
development,
environment
or
our
non-production
environment,
we
have
a
little
blue
background.
Let's
go
ahead
and
look
at
the
route
that's
exposed
via
this
production
application.
We
go
here
to
the
route.
Wait
for
the
manifest
to
load.
C
C
B
I
just
want
to
add
one
little
quick
thing
you
you
mentioned,
and
I
think
it's
worth
calling
out.
As
you
mentioned,
you
have
an
application
called
an
app
an
app
of
apps
right.
So
this
is
something
that
that
a
lot
of
us
do
right
in
the
in
the
get
ops
world
is
we
do
an
app
of
apps,
meaning
it's.
We
try
to
solve
the
chicken
egg
problem
right.
B
It's
like
how
do
I
deploy
my
application
automatically
without
manually,
deploying
it
right
so
there's
this
concept
of
an
application
that
does
nothing
but
deploy
your
application
right.
So
it's
kind
of
true
we
try
to
solve
that
chicken
egg
problem
there
with
the
apple
apps
I'd
like
to
call
it
call
that
put
up,
which
is
something
I
do
a
lot
right
is
the
app
of
apps
as
well.
B
C
So
this
really
is
the
end
of
the
demo.
I
know
I'm
interested
in
your
feedback
and
especially
the
feedback
of
others
here
on
the
call
karina
cmac.
You
know
I'm
going
to
probably
turn
it
over
to
sir
to
not
turn
out
karina.
Pardon
me
karina.
Do
you
have
any
areas
that
you
want
to
start
addressing
as
we
start
moving
towards
the
panel
discussion.
A
E
Sure,
actually
to
create
it
for,
like
multiple
people
answering
today,
but
the
like.
Generally,
I
think,
as
a
as
a
high
level
like
conceptually,
you
shouldn't
see
git
ups
as
something
that
like
addresses
all
the
problems
around
deployment.
It
focuses
really
on
on
a
single
thing
and
solve
that
really
really
well.
E
It
focuses
on
driven
workflows
for
everything,
not
just
for
your
development
when
you're
developing
code,
but
also
driving
your
operation,
that's
the
single
problem
that
is
solved,
but
as
a
consequence
of
that,
you
get
a
lot
of
visibility
and
auditability
and
traceability
because
of
the
git
provider.
I
think
that's
what
it
focuses
on
when
it
comes
particularly
to
rollback
and
switching
between
versions,
so
it
doesn't
really
itself
do
anything
for
your
data
automatically.
E
E
There
are
hooks
in
argosy
that
you
can
tell
and
tell
say
saturday,
that,
before
you
sing
perform
these
operations,
for
example
after
you
using
do
these
other
operations
which
could
be
used
perhaps
for
backing
up
their
schema,
for
example,
restoring
and
things
like
that,
and
there
are
also
a
lot
of
discussions
around
like
regardless
of
what
kind
of
process
this.
This
is
not
a
question
related
to
github's
really
is
related
to
any
type
of
deployment.
How
do
we
manage
rollback,
regardless
of
how
you
perform
the
rollback
and
when
it
comes
to
data?
A
B
B
Source
hooks,
there's
actually
a
good,
a
good
demo
by
intuit
that
does
that
uses
hooks
to
put
up
a
if
under
construction
page
while
they
do
some
maintenance
and
once
the
maintenance
finishes,
it
deletes
the
that's
that
page
right
by
kind
of
just
doing
kind
of
showing
the
idea
of
a
b
deployment
and
schema
changes,
and
things
like
that.
So
it's
it's
really
heavily
dependent
on
the
process
and
the
tools
that
you've
and
how
you
leverage
the
tools
to
do
that
process.
A
E
I
can
talk
about
a
little
bit
so
and
if
you
look
at
the
role
of
argo
cd
in
this
process,
it
is
really
in
charge
of
your
deployment
to
make
sure
what
you
have
described
in
your
git
repo.
It
is
what
you
are
seeing
on
your
cluster.
So
what
happens?
If
our
cd
is
down?
Let's
say
you
completely,
remove
it
undeploy
it
altogether.
E
The
only
thing
that
happens
is
that
you,
you
cannot
do
any
new
deployments
through
this
kiddos
process,
so
no
new
releases
will
be
rolled
out
right.
I
just
want
to
put
in
perspective
the
the
criticality
of
the
role
of
argo
cd
for
the
application
itself.
The
applications
that
are
deployed
and
running
nothing
is
really
happening
to
them,
which
is,
if
you
think
about
it,
and
not
using
github's
process.
E
E
It
is
as
if,
in
the
github
sport,
your
github's
engine
is
non-existing
between
those
two
releases,
so
it
is
like
from
customers
perspective
from
a
lot
of
our
customers
that
I
work
with,
and
it's
it's
not
as
it
hasn't
been
as
critical
as
buying
into
the
overhead
of
running
like
thinking
about
hay
for
agua
city
or
in
multiple
instances
or
having
separate
management
clusters
for
argo
cd.
That
adds
all
of
this.
Have
they
at
the
for
the
high
availability
that
you
gain.
E
There
are
more
management
costs
and
operational
costs
to
to
gain
that,
and
we
haven't
seen
many
of
those
instances,
but
if
that
is
needed
is
required.
So
that
is
definitely
one
approach
to
externalize
it
from
from
the
cluster.
That
is
that
your
application
is
running
on.
There
are
other
approaches
around
hi
of
the
the
controllers
itself
to
be
discussed.
Are
there
ways
to
to
achieve
that,
but
I
haven't
seen
it
very
often.
A
B
Yeah
well,
there's
really:
two
schools
of
thought
right
in
terms
of
just
secrets.
Secrets
in
general
right
is
either
use
something
like
sealed
secrets
right
where
you're
encrypting
encrypting
the
secret
before
you
put
it
in
get
or
you
use
something
like
like
vault
right,
you
use
some
sort
of
secret
management
management
system
right.
They
both
have
the
pros
and
cons
and
there's
still
kind
of
discussion
going
on
in
the
community
in
terms
of
what
is
actually
get
ops
using
vault
is
actually
get
ops.
B
Is
it
we
don't
know
or
is
sealed
secret's
still
the
way
to
go
so
there's
there's,
there's
two
methods
of
doing
it.
Right,
I
don't
think
either
method
is,
is
right
or
wrong.
It's
really
what
it
works
for
you.
I
like
using
sealed
secrets
just
because
I'm
more
of
a
get
ups,
you
know
everything
and
get
right.
I'm
trying
to
push
myself
towards
everything
and
get
as
much
as
I
can,
but
yeah,
really
secret
management
and
storing
secrets.
B
Encryption
really
is,
is
your
friend
there,
especially
if
you're
really
just
putting
secrets
in
your
git
repository
in
your
environment?
So,
first
of
all,
you
have
your
own
personal,
get
repo
inside
the
environment
right
so
like
they're,
it's
behind
a
firewall
behind!
You
know
multiple
layers
of
security,
so
you're
just
adding
one
more
layer
of
the
encryption.
On
top
of
that.
So.
A
B
C
A
D
Yeah,
I
think
the
the
question
by
carlos
was
something
around
whether
we
can
use
get
ups
for
cluster
state,
and
I
answered
that.
I
think
yes,
the
answer
is
yes,
it's
very
common
to
maintain
cluster
configuration
on
git
but,
of
course,
to
a
large
extent,
as
long
as
you
can
describe
it
using
manifests,
that's
how
you
would
do
it
first
for
that
you
could
do
it
with
argo,
cd
or
flux.
Both
both
work.
A
C
C
B
C
A
C
C
B
C
A
C
A
A
So,
given
all
the
questions
that
have
been
asked
and
between
all
of
you,
I
mean-
are
there
any
other
things
that
you
want
people
to
take
away
from
this
discussion
today,
because
I
think
we
have
a
lot
of
follow-on,
freezos
and
demos
and
everything
after
this
one
deeper
dive.
So
all
right
sam
says,
maybe
spoiled
question.
So
what
is
the
state
of
acm
versus
argo
cd?
I
don't
think
that's
a
versus
c
mac.
Do
you
want
to
take
that?
One.
E
E
The
lot
immediately
lands
on
the
application
side
and
we
with
a
little
bit
of
touch
of
infrastructure,
because
kubernetes
is
a
declarative
platform
and
openshift
really
takes
it
to
the
extreme,
with
being
able
to
configure
everything
through
yaml's
that
he
put
in
git
repo,
but
it
doesn't
go
really
further
lower
than
that.
So,
if
I
want
to
provision
a
cluster,
we
we
usually
don't
talk
about
that.
E
How
do
I
go
from
nothing
to
a
cluster
on
azure
and
then
roll
out
my
application
to
it
right
or
if
I
want
to
also
enforce
that
once
the
cluster
is
up
on
azure?
There
are
certain
operators
installment
or
the
way
around,
there's
some
certain
operators
are
not
installing
it.
There
are
enforcement
of
policies
on
it.
So
that's
where
ac
and
that's
the
power
that
acn
brings
to
the
game,
and
it
could
be
the
combination
of
argo
cd
that
it
expands.
E
The
git
ups
store
your
github's
capabilities
beyond
just
the
open
shift
infrastructure
and
all
the
layers
on
top,
and
it
pushes
all
the
way
down
to
cluster
provisioning
and
policy,
governance
and
aspect
like
that
and
in
our
cd,
it's
in
fact
going
to
be
a
component
within
acn
as
well
that
drives
the
githubs
process
there
and
really
marries
well
to
those
provisioning
capables
of
acm
and
policy
partners.
So
this
is
something
that
you
would
see
rolled
out
gradually
over
the
next
six
months
in
as.
A
C
I
said:
oh
definitely
you
want,
you
would
definitely
want
to
make
because
just
think
about
it,
you
may
have
your
application
have
a
different
lifecycle
in
your
configuration.
Your
application
may
be
static
for
years,
but
your
database
password
or
configurations
may
change.
Let's
say
you
get
a
brand
new
image
repository
location,
your
application
may
never
change,
but
the
configuration
will,
but
that
lifecycle
should
be
managed
separately.
A
B
Yeah
so
yeah
the
people
who
can't
that's
watching
the
recording
they're
asking
about
the
argo
flux
join
forces.
That
was
an
idea
they
had
a
while
back
and
they
decided
to
go
separate
ways
right,
so
they
decided
to
they
had
different
goals,
so
they
decided
to
work
on
a
different
approach
to
to
that
goal.
So.
D
I
can
quickly
activate
in
general
what
that
means
for
the
community
and
customers
and
industry.
So
we
have
a
working
group
where
we
are
all
participating
together
to
ensure
that
the
basic
get-ups
principles,
the
best
practices.
We
should
all
have
general
agreement
on
that.
So
respect
which
tool
you
use
your
paradigm
shouldn't
be
shifted.
That
should
still
be
similar.
The
typical
get
ops
principles
or
the
devops
principles
that
we're
talking
about.
A
B
Yeah,
that's
part
of
the
ci
process.
Really
more
than
anything
else
is
the
it's
you
know
argo
cd
is
is
just
does
the
cd
aspect
of
it
the
ci
process
of
approval
gates
and
going
from
dev
to
prod?
That's
all
done
in
the
ci
process
right,
so
there's
there's
been
a
lot,
so
jenkins
did
a
really
good
good
job
of
like
globbing
them
together.
B
That's
why
it's
ci
cd
right,
but
really
now
that
we're
separating
the
responsibilities
is
your
ci
process
does
a
lot
of
that
that
gating
and
that
release
process
and
the
the
sync
tool
in
this
case,
argo
cd,
is
only
is
only
responsible
for
actually
doing
the
change
that
it
was
told
to
do
so.
The
approval
gates
will
definitely
just
still
be
in
your
normal
ci
process,
the
cd
process.
That's
that's!
That's
further
downstream.