►
Description
Kubernetes is a game changer. New practices, tooling and habits will be needed to scale DevOps to support a cloud native infrastructure. In this meetup, Isaac Gaskin, Site Reliability Engineer, Tesla, will introduce GitOps concepts and Argo CD to automate the deployment of applications to Kubernetes clusters. This presentation will not only give us insights around Kubernetes, but also the new tooling and practices that large enterprises are embracing to support DevOps at Scale.
Isaac has served as a Cloud Engineer, DevOps Engineer and Site Reliability Engineer for high tech companies including Tesla, GoPro and Code42. Learn more about Isaac at https://www.linkedin.com/in/isaacgaskin/
A
Okay,
hello,
everybody-
this
is
tracy
reagan,
ceo
of
deploy
hub,
deploy,
hub,
hosts
these
cdf
online
meetups
and
we're
honored
to
do
so
and
we're
starting
to
get
a
nice
following.
So
thank
you,
everybody
who
is
has
showed
up
today.
Today
we
are
going
to
learn
about
argo.
I
know
that
argo
is
not
part
of
the
cd
foundation,
but
we
are
a
we're
happy
to
learn
about
lots
of
different
cd
tools
and
this
one
in
particular,
I've
been
very
curious
to
learn
about.
A
I
met
isaac.
I
reached
out
to
him
on
a
linkedin
chat
and
he
started
chatting
about
different
tools,
and
he
mentioned
his
experience
with
argo
cd
and
I
immediately
wrangled
him
to
do
a
presentation
for
us.
Isaac
has
served
as
a
cloud
engineer,
devops,
engineer,
sre
for
a
lot
of
high-tech
companies
and
including
companies
like
tesla
and
gopro
and
code42.
A
A
We
have
butter
knives
to
samurai
swords,
elevating
developers
to
ninja
warriors
so
this
one
I
try
to.
I
try
to
mix
up
kind
of
process
presentations
with
tools,
presentations
this
next,
one
that
we're
it's
going
to
be
held.
I
believe
in
I
don't
see
the
date
here.
It's
interesting
november.
10Th
12
p.m,
to
1
pm
mountain
time.
So
I
believe
that
is
an
hour
earlier,
but
on
november
10th
this
is
going
to
be
presented
by
guru,
mani.
A
He
is
the
director
of
devops
and
quality
engineering
at
markel
insurance
and
he's
really
going
to
talk
about
how
they
have
upskilled
their
devops
teams
and
their
devops
practitioners.
So
that
should
be
an
interesting
one
again.
It
will
be
again
more
of
a
process
presentation
than
a
tools
presentation,
and
on
that
note,
I
am
going
to
introduce
us
to
isaac
gaskin
isaac.
It
is
all
yours.
B
B
We're
also
going
to
talk
about
the
architecture
of
argo
cd,
so
we're
going
to
go
a
little
bit
deep
in
terms
of
the
design
of
the
platform,
as
well
as
how
it
interacts
with
different
subsystems
and
then
we're
going
to
spend
a
majority
of
our
time,
actually
demoing
the
tool
so
you'll
kind
of
get
to
have
like
a
hands-on
walk-through
of
what
it
looks
like
to
use.
Argo
cd
from
like
a
day-to-day
operations
perspective.
B
So
brief
history
on
get
ops,
getups
is
actually
a
term
coined
by
weaveworks
and
it
built
upon
these
principles
that
have
been
well
established
in
the
industry.
So
there's
plenty
of
tools
that
do
configuration,
management
and
infrastructure.
As
code
and
I'm
just
going
to
use
the
umbrella
term
of
infrastructure
as
code
to
reference
all
these
tools,
so
these
are
like
well
established
tools
in
our
industry.
B
Things
like
chef,
puppet
ansible
terraform
is
a
large
player
in
this
area
as
well,
and
the
goal
of
these
tools
is
really
to
establish
your
infrastructure
in
a
declarative
way.
So
everything
about
bringing
servers
up
to
configuring
them
is
all
defined
in
code,
and
this
works
works
really
well
and
get
ops
actually
builds
upon
these
principles
and
trying
to
take
it
a
little
more
like
one
step
further,
it
tries
to
answer
questions
such
as
what
if
the
system
diverges
from
the
source
of
truth,
how
is
the
state
reconciled?
B
Are
there
alerts
that
are
fired
if
you're
experiencing
drift
and
then
also?
How
do
you
trigger
conversions?
How
do
you
converge
the
expected
state
with
the
actual
state,
so
devops
or
sorry
get
ops
builds
on
all
these
principles,
especially
that
of
immutable
infrastructure,
which
is
somewhat
of
a
solved
problem
in
this
space
right
now,
so
this
is
taken
from
weaveworks.
B
B
So
that
means
that
everything
about
your
platform
is
in
code
and
declarative
means
that
it's
it's
going
to
be
immutable
or
hermetic.
So
when
you
define
it
in
code,
you
can
have
a
guaranteed
assurance
that
when
you
create
it
today,
five
days
from
now
five
years
from
now,
it'll
come
up
in
the
exact
same
way.
B
B
Thirdly,
approved
changes
can
be
applied
automatically
to
the
system.
So
what
I
mean
by
this
is
that
proposed
changes
to
the
system
all
go
through
your
your
standard
version
control
flow,
whether
that's
pr
or
peer
review,
or
just
like
pushing
commits
directly
and
once
those
commits
have
been
pushed
to
your
git
repository.
B
B
So
I
hope
that
makes
sense.
Also
I'll
take
a
pause
here
and
mention
that
get
ops
is
it's
a
principle.
It
is
not
associated
with
any
one
platform
or
tool
so
in
in
this
presentation,
we're
going
to
talk
a
bit
about
kubernetes
and
argo
cd,
but
these
things
can
be
applied
just
as
a
more
like
broad
sense.
It
doesn't
need
to
be
kubernetes
specific.
B
One
of
the
reasons
why
git
ops
has
really
developed
more
recently
around
the
kubernetes
ecosystem
is
because
kubernetes
as
a
platform
has
a
lot
of
controls
built
into
it
in
terms
of
like
state
reconciliation.
Everything
is
controller
driven
within
a
kubernetes
ecosystem.
So
it's
like
constantly
reconciling
state
which
just
works
really
well
with
get
ops
and
these
principles
of
you
know.
State
conversions.
B
B
B
So
the
component
that
retrieves
the
manifest
is
called
the
argo
cd
repo
server
and
that's
what
you're
seeing
here
on
the
right,
and
so
all
that
that's
responsible
for
is
pulling
git
repositories
and
cloning
them.
So
it
contains
just
you
know
stacks
of
directories
that
have
all
these
git
repositories
or
helm
repositories,
and
it
can
be
at
like
any
version
any
commit
in
time.
B
B
B
B
Okay,
cool.
I
thought
I
was
gonna
hear
your
question.
Lastly,
the
apply
changes
on
push
component
is
controlled
by
the
argo
cd
application
controller.
So
this
is
like
your
standard
kubernetes
controller
made
with
code
builder,
it's
like
a
kubernetes
controller
and
it
manages
custom
resources
which
I'll
talk
about
in
the
next
slide.
But
this
is
the
thing
that
is
like
the
meat
and
potatoes
of
the
system.
It's
like
constantly
re
receiving
a
stream
of
events
to
like
unmarshall
and
marshall
manifest
and
then
apply
them
to
your
live
clusters.
B
So
cargo
cd
is
a
kubernetes
native
construct.
It
runs
in
a
kubernetes
cluster
and
it
also
manages
other
kubernetes
clusters,
so
you
can
use
it
as
like
a
hub
and
spoke
model
where
you
have
like
a
central
argo,
cd
installation,
that's
managing
the
cluster,
that
it
runs
in
as
well
as
any
clusters
that
it's
connected
to
and
then,
of
course,
there's
caching
in
between
each
of
these
layers.
B
So
this
is
the
these
are
the
two
custom
resources
that
argo
cd
introduces.
It
introduces
a
resource
called
an
application
and
an
app
project
and
I'll
start
by
describing
what
the
application
is.
So
the
application
is
just
a
there's.
A
motorcycle
going
by
you
might
hear
some
background
noise.
There
is.
B
B
Next,
the
app
project
is
actually
just
a
construct
to
introduce
role-based
access
control
into
the
argo
cd
ecosystem,
so
it
defines
a
list
of
kubernetes
clusters
and
namespaces
that
can
be
accessed
within
a
given
project.
Oh,
I
misspelled
defines
that's
okay.
It
also
defines
a
list
of
git
repositories
that
can
be
accessed
in
that
project
and,
lastly,
it
has
like
oicd
group
bindings,
openid
connect
group
binding.
So
this
means
that
you
can
use
sso
with
argo
cd
and
actually
that's
that
is
like
the
way
to
log
into
the
ui.
To
authenticate
to
argo.
B
Cd
is
via
sso
there's
like
one
admin
account,
which
is
local
and
you
can
add
other
local
accounts,
but
it's
recommended
that
you
use.
You
know
your
standard
sso
provider,
whether
that's
you
know
key
cloak,
dex
github,
whatever,
whatever
sso
provider
you
use,
yeah,
you
can
integrate
that
with
argo
cd
and
you
can
just
start
onboarding
teams
that
way.
B
It
is
a
kubernetes
environment
tool,
so
you
can
use
it
in
aws.
If
you're
running
your
kubernetes
clusters
in
aws,
you
can
also
run
it
on
prem
or
in
a
hybrid
environment.
Argo
cd
is
like
very
agnostic
in
terms
of
the
actual
cloud
provider
that
you're
using
or
not
using
it.
All
it
cares
about
is
managing
state
within
kubernetes
clusters.
A
B
That's
a
that's
a
good
question.
I
think
in
general,
aws
has
the
lion's
share
of
the
cloud
market
in
terms
of
running
kubernetes
clusters.
I
think
gke
and
google
obviously
know
how
to
run
kubernetes
really
well,
since
they
created
the
project,
but
I
would
say
by
and
far
probably
aws
based
deployments,
yeah.
B
B
B
Yeah
yeah,
so
argo,
it
is
a
deployment
tool,
so
it
works
like
nicely
with,
like
other,
like
tool
chains
in
that
sense,
and
actually
the
company
that
is
the
maintainer.
The
core
maintainer
of
the
argo
project
is
intuit,
so
you
know
they're
like
a
large
financial
institution,
and
so
they
they
work
really
closely
with
companies
like
aws
and
red
hat.
So
red
hat
just
joined
the
argo
project
as
a
core
contributor,
and
I
know
that
intuit
works
really
closely
with
aws,
because
intuit
is
very
much
a
aws
shop.
B
B
A
B
B
Interesting
well,
I
hope
I
don't
need
to
do
this
all
I
can
do
it
all
local
and
in
fact
I
am
planning
on
showing
some
local
thing,
but
this
is.
I
wanted
to
share
this
because
this
is
like
an
argo
cd
installation.
That's
publicly
available,
it's
managed
by
intuit
and
that
way
folks
can
actually
click
around
instead
of
just
watching
me
click
around,
but
it
looks
like
it's
not
available,
but.
A
B
It
just
came
back,
you
know
what
I
you
know
what
happened.
This
is
really
funny
timing,
and
actually
I
wanted
to
talk
about
this
because
argo
cd
is
all
it
does.
Is
it
like
runs
kubectl
apply
at
the
end
of
the
day
right
it
just
creates
things
in
kubernetes
and
because
argo
cd
is
a
kubernetes
native
construct,
it
runs
in
kubernetes,
it
can
manage
itself
which
is
like
kind
of
meta,
and
so
what
we
just
witnessed.
There
was
kubernetes
upgrading
itself.
So
you
can
see
this
is
the
argo
cd
ui.
B
Every
one
of
these
boxes
is
an
application
and
remember
we
talked
about
applications.
They
are
an
association
of
a
kubernetes
cluster,
a
namespace
and
then
a
git
repository.
So
you
just
saw
this
box
for
argo
cd
go
from
blue
to
green,
which
meant
that
it
was
going
from
a
progressing
state.
So
there
was
a
change
that
was
being
applied
to
a
healthy
state
which
made,
which
meant
that
the
change
was
successfully
applied.
B
So
you
can
see
that
if
we
click
into
the
application
view,
we
kind
of
get
this
detailed
summary
and
every
one
of
these
boxes
is
a
resource
in
kubernetes.
So
I'm
going
to
be
using
a
lot
of
like
kubernetes
specific
terms.
So
if
you
need
me
to
clarify
any
of
those
things,
let
me
know
so.
You
have
things
like
service
accounts,
custom
resources.
Here
the
replica
sets
there
are
pods.
B
If
this
is
looking
too
busy,
you
can
also
come
up
here
in
the
top
right
and
click
filter,
and
then
you
can
just
start
filtering
out
stuff.
So
maybe
I
just
want
to
look
at
the
pods
in
this
case.
These
are
all
the
pods
that
are
running
for
this
argo
cd
installation
that
we're
looking
at
it
is
self-managing
itself.
B
So
that's
kind
of
cool.
You
can
like
click
into
these
as
well,
to
see
even
more
details.
So
it'll
tell
you
like
what
image
is
running.
It
will
give
you
an
output
of
what
the
live
manifest
is,
and
you
can
even
see
things
like
kubernetes
events.
These
are
just
native
kubernetes
events
as
well
as
logs,
so
you
can
see
the
repo
server
servers
like
pulling
things.
We
talked
about
the
responsibility
of
that
just
to
clone
repositories
yeah,
so
you
can
feel
free
to
click
around
here.
B
B
So
one
thing
to
be
cognizant
of
when
you're
starting
your
get
ops
journey
is
that
by
introducing
git
ops
into
your
system,
you're
kind
of
you're
kind
of
implicitly
breaking
down
the
barriers
of
power
back
that
exists
within
kubernetes,
so
because
people
can
apply
changes
to
your
system
just
by
a
commit.
You
just
want
to
be
aware
that
whoever
can
access
your
get
repository
can
probably
change
your
infrastructure.
So
just
be
aware
of
that.
B
So
this
is
what
we're
looking
at
is
a
custom
resource
and
the
custom
resource
of
an
application
defines
the
git
repository
to
pull
from
it
defines
a
path
in
the
git
repository.
It
defines
a
branch
or
target
revision,
so
this
could
be
you
know
main
or
master.
It
could
be
like
a
feature
branch
or
it
could
be
a
commit,
and
then
it
defines
a
destination
server.
So
in
this
case
it's
using
the
default
kubernetes
server,
which
is
the
in
cluster
server,
that
argo
cd
is
currently
running
in
and
then
it
defines
a
target
namespace.
B
B
If
I
open
the
repo
url
you'll
see
it
takes
me
to
a
git
repository
as
we
would
expect,
and
inside
of
that,
there's
a
sub
path,
so
path,
argo,
cd,
we're
going
to
click
into
argo
cd
and
then
here
there's
the
customization
for
everything,
and
you
can
see
that
someone
actually
just
committed
an
hour
ago
to
upgrade
it,
which
is
what
we
just
saw
there
happening.
We
saw
argo
cd,
upgrading
itself
and
yeah.
So
all
of
these
are
manifest.
B
B
A
B
I'm
kind
of
curious
what
the
commit
looks
like
okay,
so
here's
like
an
example
of
what
a
commit
looks
like
to
upgrade
an
application
or
a
change
in
application
and
we're
actually
going
to
go
through
this
process
here
in
just
a
second,
so
it'll
be
a
little
more
concrete,
so
I'm
actually
going
to
switch
gears
here.
A
little
bit
feel
free
to
continue
poking
around
in
this.
If
you
want
to
kind
of
familiarize
yourself
with
the
ui,
but
we're
actually
going
to
pivot
into
actually
creating
an
application
from
scratch.
B
You
can
see
my
applications
that
I've
already
set
up
so
how
we
create
a
new
app
first,
you
can
do
it
a
couple
different
ways:
you
can
create
it
via
the
ui
which
I'm
going
to
show
you
here,
but
in
practice
everything
should
be
created,
declaratively,
meaning
that
your
custom
resource
definitions
will
be
checked
in
to
version
control
nail
and
asks
have
used
rcd
in
a
production
environment.
If
so,
how's
your
experience
been,
and
how
have
you
handled
application,
configuration
and
db
migrations
associated
with
code
being
updated
via
argo
cd?
B
That's
a
good
question.
I
can't
really
comment
on
my
use
of
argo
cd,
but
from
the
chat
or
the
slack
channel
that
there's
like
an
rcd
slack
channel
which
I'll
share
at
the
end.
A
lot
of
folks
are
adopting
this
in
production
and
their
experience
has
been
like
very
positive,
like
it
helps
reduce
the
cognitive
load
of
doing
upgrades
and
rollbacks
a
lot.
B
Also,
it's
very
scalable
and
stable,
I
would
say
the
largest
user
of
argo
cd
in
production
is
intuit
themselves
who
run
at
like
a
humongous
scale
like
I
would
recommend
like
following
them.
If
you
are
interested
in
learning
about
how
to
run
kubernetes
at
scale
and
specifically
the
question
of
handling
application,
configuration
and
db
migration,
I
would
say,
for
the
first
part,
application
configuration
is
very
simple,
like
all
that
is
required
is
like
committing
a
change
to
your
source.
B
There
are
things
that
you
can
do
in
argo
cd,
that
perform
one-off
tasks,
but
it's
much
more
proficient
at
doing
like
an
entire
state
reconciliation
rather
than
just
doing
like
one-off
tasks.
There
are
things
that
are
called
like
precinct
hooks
or
sync
hooks
that
allow
you
to
execute
arbitrary
jobs
before,
during
and
after
your
deployment,
and
I
have
heard
of
people
using
those
to
do
like
db,
migrations.
B
Sync
policy,
it
you
get
two
options
here.
Manual
or
automatic
manual
means
that
you
need
to
sync
the
changes
yourself
with
a
command
or
a
button.
Click
and
automatic
means
that
once
the
code
is
committed,
argo
cd
will
automatically
apply
the
change.
So
I'm
going
to
click
manual,
I'm
going
to
click
auto,
create
namespace,
because
I'm
going
to
create
a
new
one
and
here's
the
list
of
repositories
that
I
have
added
locally,
I'm
actually
going
to
use
the
upstream
helm
chart
repository,
and
so
you
can
see
that
it
knows
that
it's
a
helm
repository
also.
B
B
So
this
is
kind
of
like
a
quality
of
life
thing,
so
argo
cd
will
look
for
home,
charts
or
customize
manifest
that
exists
within
a
repository
and
it'll
just
list
up
applications
it'll
list
out
this
things
that
you
can
install
based
on
what
it
finds.
So
in
the
case
of
helm,
it's
looking
for
the
chart.yaml
and
in
the
case
of
customize,
it's
looking
for
the
customization.yaml
file.
So
that's
how
it's
pre-populating
this
drop
down
here
and
I'm
just
going
to
install
everyone's
favorite
wordpress
90
of
the
internet
runs
on
wordpress.
B
B
And
finally,
you
can
see
here
that
it's
giving
us
the
option
to
configure
some
things
that
are
not
checked
into
version
control
or
they're,
just
like
not
defaults.
So
here's
the
full
values.yaml
file
associated
with
the
wordpress
chart,
and
here
it's
just
giving
us
some
options
to
to
change
the
parameters.
B
B
So
here
is
the
application,
the
full
application
spec.
This
is
the
custom
resource
of
the
application
we
were
talking
about,
which
is
a
the
yaml
version
of
what
we
just
created
via
the
ui.
So
you
can
see
that
I
gave
it
the
name.
You
can
see
the
destination,
so
that's
the
kubernetes
cluster.
It's
running
in
and
then
remember
we
have
a
source.
B
So
in
this
case
I
gave
it
the
repo
of
this
helm
chart
repository,
and
then
you
can
see
that
I'm
installing
the
wordpress
chart
at
this
version,
and
then
here
you
can
see
of
like
the
custom
overrides
that
I
added
so
I'm
going
to
say
this
looks
good.
I'm
going
to
hit
save
I'm
going
to
hit
create,
and
you
can
see
it
just
popped
in
here
as
a
new
application
called
demo,
and
if
we
click
in
here
you
can
see
all
the
resources
that
can
be
created
as
part
of
this
helm
chart.
B
B
So
I
just
click
app
diff
and
it
brings
up
this
nice
little.
U
anything
in
green
is
an
addition.
Anything
in
red
is
a
deletion
and,
as
you
can
see
here,
we
only
have
additions,
which
is
what
we
expect.
This
is
the
first
time
that
we're
deploying
this
application,
so
we
have
things
like
the
config
map.
B
B
B
Now
what
the
sync
button
does
is
it's
going
to
actually
go
ahead
and
apply
these
changes?
It's
going
to
do
the
deployment
for
us
and
after
clicking
sync,
it's
going
to
show
you
some
options
that
you
can
tune,
so
you
can
also
like
delete
things
that
are
no
longer
needed
with
the
prune.
You
can
also
selectively
just
apply
specific
things
in
this
case.
I'm
just
going
to
leave
all
the
defaults,
as
is
before
I
do
that
I'm
going
to
show
you
that
there
is
no
funny
business
happening
here.
B
Oh
cancel,
so
specifically
we're
deploying
this
to
a
namespace
called
demo,
so
I'm
just
going
to
do.
Kube
ctl
get
namespaces
and
make
this
a
lot
bigger,
and
you
can
see
that
there's
no
demo
name
face
there's
g
demo,
but
there's
not
demo.
I
made
that
just
a
couple
minutes
ago,
so
I'm
going
to
go
ahead
and
sync.
B
So
you
can
see,
things
are
starting
to
get
created
already.
A
lot
of
stuff
is
in
a
healthy
state,
meaning
that
it's
created
and
in
the
correct
state.
You
can
see
that
our
wordpress
pod
is
coming
up
and
we
can
click
into
it
to
see
some
more
details.
So
we
can
see
events
of
okay,
it
was
a
it
was
assigned
to
a
node.
The
container
was
already
present,
so
I
didn't
need
to
pull
it.
It
was
cached
and
it's
gone
ahead
and
created
the
actual
container
and
started
it.
B
And
if
we
look
at
the
logs,
you
can
see
that
wordpress
is
actually
starting
and
let's
go
ahead
and
do
our
grep
again
for
the
namespace,
and
you
can
see
that
demo
namespace
now
exists,
like
we
literally
just
made
that
so
I'm
going
to
switch
over
to
demo
and
I'm
gonna
run,
watch
coop
ctl
get
all
so
these
are
all
the
resources
that
were
just
newly
created.
You
can
see
by
the
age
that
they
didn't
exist
just
a
minute
ago
and
now
they're
coming
into
existence,
and
it
looks
like
everything
is
synced
and
successful.
B
B
I
see
wordpress,
so
I'm
going
to
grab
that
and
I'm
going
to
port
forward
to
it.
Just
so
I
can
see
it
so.
I'm
going
to
run
cube,
ctl
port
forward
svc
for
service
paste.
My
service
name,
give
it
a
random
host
port
and
then
give
it
the
the
port
that
is
bound
to
in
the
container
oops
did
I
mean
port
forward?
I
sure
did
cool
so
now.
If
I
come
over
here
to
localhost
9998.
B
B
Creating
an
application
is
one
thing,
but
updating
it
is
another
thing.
So
this
is
where
we're
kind
of
moving
from
like
day
one
operation
problems
to
day
two
operation
problems
like
how
do
I
make
this
an
ongoing
thing?
How
do
I
introduce
changes
into
my
system,
so
I'm
actually
going
to
use
just
a
sample
git
repository
here.
There's
really
nothing
to
it.
I'll
put
it
in
chat,
but
it's
just
a
default
helm
chart
and
I'm
going
to
create
a
a
new
application
using
it.
B
B
Yes,
it
does
so
argo
cd
by
default
will
pull
your
git
repository
every
three
minutes,
but
you
can
also
add
a
web
hook
to
do
like
an
event
driven
approach,
so
here
in
the
docs.
There's
an
example
of
how
to
do
that.
There's
an
endpoint
called
slash
api
web
hook
and
that
will
be
used
to
trigger
an
event
in
argo
based
on
the
events
that
you've
configured
here.
So
in
this
example,
you're
saying
for
this
repository
on
every
push
event
call
this
payload
and
so
argo
cd
will
see
that
event
get
triggered
it'll.
B
So
when
you
have
a
pull
request
get
merged,
you
can
also
set
that
up
as
an
event
to
trigger
this
web
hook,
and
so
the
moment
it
gets
merged
it'll
go
ahead
and
do
the
whole
state
reconciliation
we've
been
talking
about
so
very
easy
to
do
good
question.
This
will
also
help
release
some
load
from
your
version
control
servers
because
it
doesn't
need
to
pull
it
every
three
minutes.
B
B
And
so
now
you
can
see
it
the
same
type
of
view
that
we
saw
before
just
a
bunch
of
different
creations.
This
is
one
this
one's
really
simple:
it's
just
setting
up
nginx,
so
I'm
going
to
go
ahead
and
sync
that
I'm
also
going
to
come
over
here
and
switch
to
the
newly
created
namespace
and
you
can
see
it's
starting
to
spin
up
my
pods
and
my
service,
my
deployment
so
now
nginx
is
up
and
running,
and
I
can
show
you
that
it's
running
just
by
port
forwarding
to
it.
B
I
put
the
link
in
chat
if
you
want
to
look
at
the
contents
of
it
and
the
changes
that
we're
proposing
are
these
ones
so
we're
changing
an
image
tag
and
then
we're
just
changing
some
resource
limits
to
the
pod
so,
like
very
trivial
changes,
this
could
be
any
type
of
change.
It
could
have
been.
You
know,
upgrading
the
version
of
our
application
to
you
know
the
last,
the
next
blessed
version
or
it
could
have
been
like
updating,
an
ingress
or
host
name.
It
could
have
been
really
anything.
B
B
B
Did
it
already
apply
it?
No,
it
didn't.
Oh,
let's
hit
this
refresh
button.
Okay,
so
that
that
was
one
of
the
things
that
we
were
talking
about
in
chat.
Is
the
pulvers
pull
based
model
versus
the
push
based
model,
so
I
just
asked
it
to
refresh
it,
which
is
just
a
way
of
saying,
go
ahead
and
clone
the
git
repository
again
and
tell
me
if
there's
any
difference
in
state.
B
B
B
B
So
there's
a
meeting
on
the
first
wednesday
of
every
month
at
10am
pst
to
talk
about
argo,
cd
and
also
argo
rollouts,
which
is
another
part
of
the
argo
project
which
is
more
focused
towards
progressive
delivery,
which
is
basically
continuous
delivery
with
more
knobs
to
turn
and
then
there's
also
an
argo
cd
contributor
meeting
every
thursday
at
10
am
so
that
was
actually
today
at
10
a.m.
So,
if
you're
interested
in
contributing
back
to
the
code
base,
you
can
join
that
and
they'll
help.
B
B
B
B
B
So
there
is
an
api
that
you
can
develop
against
built
in
there's
like
a
swagger
documentation,
so
you
can
see
like
all
the
things
that
you
can
interact
with
with
argo.
It
also
has
native
go
libraries
which
I
would
recommend
using
because,
like
this
documentation
is
not
always
the
most
up-to-date
there's
also
a
cli.
B
Excuse
me
one
second,
when
I
open
the
chat
here
so
there's
also
cli,
so
you
can
do
argo,
cd
version
or
whatever,
and
so
it
gives
you
the
server
version
and
the
client
version.
You
can
also
interact
directly
with
your
applications,
so
I
can
do
a
fun
thing
here,
like
my
demo,
app
say
like
I'm
done
with
it,
so
I
can
do
argo
cd.
B
A
So
anyways
thank
you
isaac.
It
was
fabulous.
That
was
a
really
great
great
presentation
more
than
I
was
expecting,
and
I'm
very
excited
about
argo
cd.
Now,
so
you
did
your
job
and
everybody.
We
will
see
you
on
the
next
one,
which
is
november
10th,
and
I
will
be
yeah,
I'm
going
to
download
this
from
the
zoom
webinar
and
I'll
get
it
uploaded
to
the
youtube
channel.
We
don't
have
a.