►
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
Kubernetes and The GitOps Face-Off - Ricardo Aravena & Javeria Khan, Branch Metrics
During the last year, we have seen how Kubernetes GitOps has made organizations rethink CI/CD from storing all declarative aspects in git, reducing the use of manual kubectl commands and managing deployments using PRs. In this talk, we will review some of the more popular GitOps open source tools such as Flux, Gitkube, Draft, and Skaffold, and how they work in real-world production environments. We'll give the side by side comparisons. Which one is better for the GCP, Azure or AWS? How do you integrate them with container building tools such as Kaniko, img, etc? Which ones are easier for developers to use in local environments? By the end of the session, the audience will have a good understanding of the pros and cons of each these tools and how leverage templates such as the Kubernetes operator pattern to quickly deploy them in production ready environments.
To Learn More: https://sched.co/GrSe
A
A
B
A
Extensively
and
then
we're
using
tools
like
slots,
flux
and
basil,
and
then
we
have
some
homegrown
tools.
There
are
pre
de
some
of
these
get-ups
tools
that
we
used
to
build
and
deploy,
and
also
our
big
data
pipelines
are
fully
integrated
with
CI
CD.
All
the
pipelines
run
in
spark
and
Flint
a
little
bit
a
little
bit
of
what
we're
going
to
be
talking
about
today.
A
A
Why
to
use
them
and
also
side-by-side
comparisons,
and
then
we'll
talk
about
which
ones
you
may
want
to
choose
and
in
terms
in
terms
of
community
support
which
one
might
be
easier
to
use
which
might
be
more
stable
and
which
might
be
sort
of
production
ready
and
then
we'll
talk
about
some
future
enhancements
so
branch.
So
we
have
a
pretty
large
scale.
A
A
Some
of
the
get-ups
history
in
2003
bill
bot
was
released
as
kind
of
like
the
first
kid
or
CI
CD
tool
that
I
heard
of,
and
it's
actually
being
used
since
a
lot
of
places.
Today,
it's
pretty
bare-bones
and
within
Python,
then
in
2011,
Jenkins
Jenkins,
but
in
Travis,
came
into
the
world
and
then
Jenkins
that
that's
when
it
became
the
de
facto
standard
for
CI,
CD
and
travel
is
also
for
like
github
type
of
applications.
A
So
lots
of
options,
lots
of
different
tools,
so
hopefully,
in
this
talk,
you'll
learn
about
them
and
if
you're
currently
using
a
tool-
hopefully
you
can
maybe
see
if
you
can
improve
it
and
maybe
contribute
back
to
the
community.
If
you
don't
know
anything
about
any
of
these
tools,
hopefully
you
can
pick
one
of
those
one
of
the
tools
to
use
in
your
environment
and
if
you
are
currently
having
your
own
infrastructure,
CI
CD
you
this
session
will
be
more
for
informational
purposes.
B
Hi
everyone
thank
you
for
attending
our
session.
In
this
short
half
an
hour,
I
will
first
review
some
good
ops
tools
and
then
Rico
will
cover
the
image
building
tools.
While
this
isn't
enough
time
to
cover
more
of
this
landscape
or
even
going
to
more
details
of
any
of
these
tools,
please
feel
free
to
catch
us
afterwards
for
more
questions.
B
So
to
begin
with,
why
use
get
ops
in
the
first
place,
like
Rico
mentioned
this
term
was
originally
created
by
the
weave
works
people,
but
it
has
since
then
gotten
much
more
popularity
with
a
lot
of
tools
now
offering
automation,
support
for
deployments
and
config
updates.
So,
but
in
essence,
the
idea
is
that
you
control
both
your
infrastructure
and
your
code,
and
that
way
you
can
then
use
a
get
offs
tool
to
compare
your
current
state
of
your
cluster
or
your
code
to
the
desired
state
in
your
version
control
system.
B
By
this
way
by
automating
your
deployments
for
cluster
updates
or
for
code
versions,
you
gain
first
of
all,
reversibility,
because
roll
backs
are
not
easier.
You
have
the
previous
version
in
the
source
control
somewhere.
You
get
an
audit
trail,
which
is
good
because
everything
goes
through
PRS
and
you
know
who
did
what
at
what
time
and
most
importantly
teams
gain
transparency,
because
now
there
are
no
more
obscure
system
level
changes
that
only
one
person
knows
how
to
do
so.
Why
is
config
updates
and
code?
B
Deploy
is
an
issue
that
merits
another
full
kubernetes
cube
con
presentation.
Well
just
for
some
background.
We
showed
some
numbers
earlier,
but
here
at
branch
we've
been
running
our
production
cluster
traffic
through
communities
since
2016
we
have
about
ten
clusters
and
each
of
these
clusters
have
about
or
the
larger
larger
of
these
have
about
200
different
applications
deployed
to
them.
Like
Rico
mentioned,
our
CI
is
a
mixture
of
circle
CI
and
Jenkins,
but
we
have
a
build
running
almost
every
five
minutes,
so
to
build
a
sustainable
and
stable
system
from
the
ground.
B
So
if
you
were
using
git
ops
practices
in
your
infrastructure,
this
is
what
it
could
possibly
look
like.
So
your
developers
would
do
their
pre
prod
tests
and
development
testing
on
their
laptops,
and
then
they
would
use
image,
building
or
app
development
tools
to
build
that
source
code
into
containerized
applications.
B
Those
containerized
applications
could
either
run
directly
on
their
laptop,
so
they
could
run
on
your
motive
clusters.
Now.
Some
of
these
tools,
as
I,
will
show
later
also
further
help
automate
this
process
by
providing
iterative
update
support.
So
they
can
update
the
remote
changes
from
your
local
changes,
either
to
the
repo
or
running
your
source
code
or
either
to
the
remote
apps
that
you're
running
in
the
remote
dev
cluster.
B
They
can
also
help
integrated
testing
by
port
forwarding
those
remote
apps
to
your
local
dev
environment
to
your
laptop,
and
they
can
also
stream
those
remote
logs
for
you.
So
when
all
of
this
is
done
and
tested,
that
code
can
now
be
pushed
to
the
code
repose
to
for
production
PRS,
and
then
your
CI
system,
whatever
it
is,
can
then
run
further
testing
and
building
on
that
code,
eventually
pushing
it
to
new
images
in
your
private
doctor
registry
or
whatever
you're
using
for
that
portion.
B
B
B
So,
while
a
lot
of
these
tools
have
common
features,
they
are
not
exactly
interchangeable,
I
like
to
categorize
them
into
three
main
groups,
with
the
innermost
layer
being
templating
tools
such
as
case
on
it
and
helm.
So
what
these
basically
provide
is
way
is
a
way
to
define
your
applications
and
they
sort
of
make
it
easier
to
define
multiple
versions
for
different
clusters
that
you
might
deploy
them
on
a
layer
above
this
is
app
development
tools
such
as
draft
get
cube.
B
Scaffold
I
will
come
to
those
later,
but
these
are
meant
to
target
the
inner
workflow
of
a
developer
when
they're
still
working
on
their
code,
but
they're
still
testing
it
and
before
they
actually
push
it
to
the
final
production
system
and
the
topmost
layer
is
a
deployment
tools
such
as
flux
or
algo.
These
are
the
controllers
that
you
would
typically
run
in
your
cluster.
B
These
help
to
keep
your
cluster
stay
in
sync,
where
the
config
that
you
source
control
among
all
of
these
tools,
the
way
that
we're
going
to
rank
them
is
according
to
these
common
traits
or
features
first
of
all,
is
dependencies.
So
how
many
things
does
that
make
you
install
and
how
many
things
you
have
to
learn
for
that
tool
and
then
does
it
handle
source
control,
and
is
there
either
ativ
development
support?
What
that
means
is
once
the
developers
are
working
on
their
local
laptops.
B
Is
that
tools,
support
updating
their
repos
or
updating
their
remote
versions
from
the
source
control
on
their
laptops?
Do
these
app
development
tools
also
support
local
development
versus
remote
testing
and
development?
I'm
logging,
which
is
very
important
as
any
sis
admins
and
the
audience,
will
agree
with
me.
We
need
to
know
what
happened
where
and
who
did
it
and
then,
lastly,
how
stable
is
the
tool?
What
version
is
it
on?
Is
there
a
community
and
how
easy
is
it
to
get
support
for
that
tour?
B
And,
lastly,
is
it
recommended
to
be
used
in
production
or
not
so
coming
to
the
actual
tools
themselves?
This
is
by
no
means
an
exhaustive
list.
These
are
something
the
tools
that
we've
had
an
occasion
of
using
and
also
should
be
a
ones
that
we
found
to
be
more
popular
in
the
landscape
at
the
moment.
So
I'm,
starting
with
the
templating
tools
case
on
it,
is
the
first
one.
It's
meant
to
be
an
iterative
process
for
declaring
applications.
This
punchline
here
is
from
a
talk
by
Bryan
Liles
from
the
European
cube
con
earlier
this
year.
B
So
their
idea
is
that
Yama's
are
harder
and
case
on
I
or
JSON
is
for
people
when
they
want
to
define
their
apps,
so
it
was
created
by
the
people
at
happy
rabbit,
nummy.
It's
basically
your
way
to
define
app
because
it's
a
templating
tool,
it's
meant
to
be
an
alternative
to
cube,
CDL
or
helm.
The
way
you
do
that
is
through
JSON
manifests,
so
this
tool
is
great.
If
you
hate
llamó
and
you
don't
want
to
use
llamó
in
your
manifest
definitions.
B
B
B
A
B
Sorry
about
that
folks,
we
were
talking
about
templating
tools
and
I
had
just
started
with
case
on
it.
So
you
use
this
if
you
hate
Emal's
and
you
can
define
your
applications
in
JSON
the
best
thing
about
this
tool,
the
nicest
feature
I
found
was:
it
has
a
dependency
package
management
system
where
you
can
reuse
your
code
in
other
case
on
in
applications,
and
it
supports
github
file
system
and
helm
repositories.
So
you
can
pull
down
your
case
on
it.
B
Packages
from
these,
it
does
have
a
dependency
of
knowing
how
to
use
JSON,
but
that
is
actually
a
con,
because
obviously
the
idea
of
using
this
tool
is,
if
you
wanted
to
use
a
zone
in
the
first
place,
it
does
have
an
active
community,
but
remember
this
is
still
very
early
0.13
or
these
it's
a
templating
tool.
So
it
does
support
deploying
to
multiple
clusters
with
multiple
versions
of
the
same
application.
B
Okay,
the
next
one
is
draft
wrap,
is
an
app
development
rule,
it's
sort
of
meant
to
use,
be
used
for
streamlined
application
development.
It's
on
the
app
development
layer,
the
second
layer
that
I
showed
it's
a
Microsoft
Azure
open
source
project
and
it's
basically
used
to
build
your
application
and
then
test
them
on
kubernetes
cluster,
a
remote
one
or
a
local
one.
You
don't
have
to
use
a
docker
file,
but
you
can
make
one
and
use
one.
B
It
has
local
and
remote
support
like
I
showed
in
my
diagram
earlier,
you
do
need
a
docker
daemon
running
locally
to
build
your
applications.
The
best
thing
about
this
tool
is
that
it
supports
all
of
these
mainstream
popular
development
language.
At
the
moment
like
closure,
Gradle,
Java,
Ruby,
Swift
and
so
good
things
about
this
tool.
Is
you
don't
have
a
doc
refer
to
a
comment,
but
you
can
use
them.
B
You'd
also
don't
need
the
kids
kubernetes
manifests
already
created
to
be
able
to
use
this
tool
because
it
just
basically
builds
and
your
source
code
and
creates
containerized
applications
for
you.
You
need
to
have
helm
until
are
installed
for
this
as
one
of
the
dependencies,
and
you
do
need
a
local
docker
daemon
running.
It
obviously
has
an
active
community
and
but
it's
still
a
0.6
as
point
16
experimental
release.
The
best
thing
like
I
showed
earlier
is
that
it
supports
many
languages
and
it
has
an
integrated
docker
image
builder.
B
B
The
next
one
is
get
cube,
so
this
is
also
an
app
development
tool.
The
idea
in
here
is
that
it's
a
wrapper
for
your
common
tools
like
git
and
cube
cereal.
It
was
created
by
Joshua
it's
at
the
app
deployment
layer
and
the
way
you
do
this
is
forget.
You
use,
get
push
to
do
this.
To
do
the
deployments
you
do
need
a
docker
file
and
obviously
you
need
a
daemon
running
in
your
cluster
and
locally
and
it
supports
local
and
remote
development.
B
The
best
thing
about
this
tool
is
that
it
uses
commonly
tools
commonly
used
tools
already
like
get
in
cubes
video,
it's
very
easy
to
setup.
It
has
our
back
support,
so
you
can
put
in
the
appropriate
security
measures
for
your
installation.
It
supports.
Any
language
is
also
great.
It
also
handles
your
source
code,
so
it
has
source
code
management.
It
doesn't
have
a
CLI
runs
directly
on
the
cluster.
B
B
Sorry,
for
that
again,
the
next
one
is
flux.
This
is
purely
a
deployment
tool.
This
is
by
the
people
that
we've
works.
It
gives
you
automated
synchronization
for
your
cluster
and
the
stuff
that
you
keep
in
source
control,
so
it
was
created
by
weaved
about
the
weave
work,
people,
it's
a
deployment
tool
and
basically
you
use
git
push
or
the
flux
CTO.
It
has
its
own
CLI
to
apply
these
changes.
B
You
don't
need
docker
files,
because
it
is
not
an
image
building
tool
and
you
use
git
for
the
local
changes
and
you
use
the
flux,
CTO
CLI,
for
the
remote
changes.
You
don't
need
the
doctor
daemon,
obviously,
because
it's
not
an
image
building
tool,
but
you
can
combine
this
with
any
of
the
tools
that
rec
inventions
later.
The
good
things
about
this
one
is
that
it's
easy
to
deploy
the
controller
and
the
CR
D.
It
supports
helm,
charts
natively,
so
it
doesn't
matter
whether
you
have
your
deployments
in
llamo
or
in
helm.
B
You
can
use
their
helm
install
the
best
thing
about
this
is
that
it
manages
your
source
control.
It's
automatically
synced,
with
whatever
you
have
in
the
VCS
to
your
cluster.
It's
a
very
stable,
very
maturities.
They
have
an
active
community
and
support
is
easy
to
find.
The
cons
are
over
is
that
it
doesn't
actually
do
local
git
management.
So
any
changes
that
you
have
locally
do
not
get
synced
automatically
to
your
repos
there's
no
image
builder.
That
would
have
been
much
nicer
if
there's
also
built
the
images
for
you.
B
Another
concern
here
is
whether
it's
scales
or
not,
because
you
can
only
deploy
one
of
these
controllers
plug
cluster
and
it
has
to
work
with
all
of
your
namespace.
So
there's
some
fancy
things
that
you
can
do
with
our
back
rolls
and
namespace
white
listings
to
get
around
that.
But
the
other
thing
is
that
roll
backs
are
hard.
So
if
you
have
the
automatic
thing
on
for
this
tool
where
it
pulls
in
images
as
soon
as
it
sees
them,
it's
hard
to
roll
back,
because
you
have
to
first
do
to
make
that
deployment.
B
And
then
you
go
back
to
your
previous
version
and
then
you
automate
it
again
if
you
want
it
to
be
automatic.
So
while
it's
possible,
but
we
find
that
slightly
not
straightforward,
the
other
thing
is
that
if
you're
doing
more
fancier
deployment
models
such
as
Canaries
or
blue
greens,
these
also
become
harder,
because
it's
meant
to
sort
of
just
watch
for
images,
and
then
you
were
images
as
soon
as
it
sees
them
to
all
your
deployments.
B
The
way
it
does.
This
is
just
sort
of
ties
in
to
the
first
diagram
I
showed,
but
you
have
a
controller
running
within
your
cluster
called
a
reflex
controller
and
it
watches
your
config
report
and
it
washes
your
doctor
registry
as
well.
So
as
soon
as
you
have
new
images
in
your
doctor,
registry
it'll
apply
those
images
to
your
deployments
if
you've
set
them
to
automate.
If
you
haven't
set
them
to
the
automate
mode,
you
can
do
that
manually.
B
So
when
you
know
there
are
new
images
and
you
want
your
deployments
to
get
updated,
you
use
the
flux,
ETL
CLI.
It
also
watches
your
configure
APIs
so
for
any
changes
that
people
do
if
they
add
new
annotations
or
new
environment
variables.
Now
those
things
are
source
controlled
and
you
know
who
did
what?
When
and
you're
this
actually
is
what
I
think
is
the
best
thing
about
this
tool
is
that
you
can
use
this
configure
up
or
to
apply
your
cluster
automates
updates
automatically.
B
Second,
last
one
is
scaffold,
so
the
best
thing
about
this
tool
is
I.
Think
it's
the
most
well-rounded
tool.
It's
for
app
development
and
deployment.
It
was
created
by
Google
cloud,
you
do
need
docker
files
and
you
do
need
a
docker
Damons
running
because
it
builds
the
images
for
you,
but
it
supports
local
and
remote
development.
B
So
it
has
a
controller
and
the
best
thing
about
it
obviously
supports
any
language.
It
has
a
very
active
community.
Support
is
easy
to
get.
It
is
a
still
in
early
release,
point
16,
but
it
automatically
updates
the
remote
from
your
local
source
code.
It
has
an
integrated,
docker
image
builder.
You
do,
however,
need
local
docker
and
you
need
doctor
files
and
you
need
helm
and
K.
It
manifests
in
the
ripples
that
you
set
up
for
scaffold.
B
So
another
good
thing
about
scaffold
is
that
it
can
support
the
whole
build
pipeline
with
any
tool
that
you
use
at
any
stage.
So,
for
example,
if
you
were
doing
just
your
local
development,
so
it
can
use
local
docker,
Damons
or
if
you
were
doing
it
for
remote
deployments,
it
can
use
any
kind
of
builder
for
your
cloud
and
then
eventually
for
the
deployment
part
you
can
use
mini,
cube
or
cube
cereal
or
helm
or,
however,
you
choose
to
do
your
deployments,
so
it
supports
all
the
popular
tools
at
any
stage
of
the
build
pipeline.
B
Agro
is
a
tool
for
it's
actually
a
workflow
tool,
so
it
doesn't
actually
do
any
development
or
help
with
the
after
deployment
process.
It's
slightly
different
from
the
other
tools,
but
it
was
created
by
the
Athletics
people.
It's
used
in
CI
CDs,
mainly
where
you
can
use
it
to
define
workflows
for
your
build
pipeline,
and
it
has
a
controller.
You
don't
need
docker
files,
because
it's
not
building
images
for
you
and
you
don't
need
the
docker
Damon
it's
decorative
llamó
and
it
supports
pipelines.
The
good
thing
about
it
has
a
very
nice
UI
crew.
B
Benes
is
already
integrated.
It's
a
mature
release.
They
have
a
community.
It
is
very
active.
This,
however,
like
I,
said
it's
not
actually
a
deployment
or
development
tool,
it's
more
of
a
workflow
tool
and
it's
kind
of
like
a
CLI
for
cube
CDO.
The
other
con
is
that
it
does
have
a
slightly
complicated
set
up,
but
you
can
use
it
for
creating
tags
and
applying
those
workflows
from
those
tags
to
your
cluster.
B
The
last
one
is
a
meta
particle.
This
one
is
actually
slightly
different
from
the
rest,
as
in
it
was
created
by
Brendan
burns,
and
it's
used
for
templating
and
deployments
the
different
thing
here
is
it's
great:
if
your
developers
don't
want
to
know
how
to
actually
use
cube,
manifests
or
how
to
use
Dockers
or
how
to
build
images,
so
it
abstracts
all
those
details
and
you
get
native
language
modules
within
each
kind
of
source
code.
B
That
does
all
that
stuff
for
you,
so
you
use
actual
source
code
for
Java
or
Python,
and
those
modules
will
take
care
of
all
the
docker
image
building
and
the
deploying
for
you.
You
don't
need
the
doctor
daemon
and
you
don't
need
the
docker
file
because
it
abstract
solve
those
details,
so
it
has
a
llamó
format
and
it's
basically
infrastructure
as
real
code.
B
So
it
supports
a
few
languages
right
now,
we're
just
sort
of
constraining
because
there's
not
a
whole
lot
of
support,
but
there's
more
coming
in
the
future,
especially
go
arrest
in
Ruby
and
it's
it
needs
a
local
docker,
daemon
running,
which
is
a
con.
Like
I
mentioned
it
has
very
limited
language
support.
It's
very
alpha.
There's
no
community
support
is
hard
to
find
for
this
tool
if
you
choose
to
use
it.
A
A
One
thing
that
you
may
want
to
have
is
faster
builds,
there's
no
guarantee
that
you're
gonna
have
a
faster
build,
but
most
of
these
tools
will
build
faster
than
playing
dollar
bill
and
then
the
the
this
is
dependent
on
on
the
type
of
application
or
the
type
of
dependencies
in
your
container,
but
most
of
the
times
you
will
have
something
built
faster.
Another
aspect
is
that
you
may
want
to
run
your
contain
your
container
bills
in
a
non
privileged
way.
So
you
may
want
to
say
that
this
is
more
secure.
A
Another
aspect
is
you
don't
want
to
use
darker
and
darker
into
building
your
kubernetes
cluster,
so
you
can
build
with
these
tools.
You
can
build
on
a
kubernetes
cluster,
not
necessarily
not
in
darker
and
darker,
and
build
images
in
slaves
and
kubernetes.
Parts
in
another
aspect
is
more
related
to
basil.
Is
that
you
may
want
to
have
with
this
reproducibility
you,
you
have
a,
maybe
sometimes
you
go
or
run
make
inside
a
container.
A
So
instead
of
running
make
you
you
can
read
something
like
basil
and
have
something
reproducible
put
up
bill,
so
Kanaka
so
created
by
Google
cloud
and
allows
you
to
build
container
images
very
fast.
It
support
either
a
local
file
system
or
Amazon
s3
or
a
Google,
Cloud
storage,
so
object,
storage,
and
then
it
does.
It
use
in
a
category
executor
image,
it's
its
own
container
image
and
you
can
build
both
on
nested
way
and
also
in
an
unprivileged
way,
IMG
another
tools
created
by
jesse
for
sale.
A
A
A
Another
tool
is
faster
than
light,
it's
great
to
by
the
folks
at
Google
Cloud,
it's
very
fast.
That's
where
the
name
comes
from
is
Bill
container
container
in
which
is
quick,
very
fast.
The
only
thing
about
this
tool
is
that
it
has
the
specific
runtimes
like
to
build
the
container
images
in
Python,
PHP
and
nodejs,
and
how
does
the
Duarte
has
his
own
CLI
there's
no
dependency
on
the
darker
demon
or
the
docker
file.
It
has
his
own
way
to
push
automatically
to
a
registry.
A
Then
there's
basil
with
OCI
in
his
soccer
module
basil
is
a
tool
created
by
Google
and
the
the
OCI
module
allows
you
to
build
images
on
privilege
and
also
very
fast,
and
one
of
the
interesting
things
about
basil.
Is
that
allows
you
to
have
your
bill?
Be
reproducible
in
deterministic
and
you
can
take
it
totally.
Take
advantage
of
that
to
build
your
container
images,
then
there's
K
native
so
great
about
it.
Folks,
like
Google,
Cloud
and
pretty
much,
is
running
server
less
in
Torun.
B
A
By
side
some
of
the
image
building
tools
you
see
created
by
different
people
and
organizations,
so
you
can
see
pretty
much
all
of
them.
Allow
you
to
build.
Some
of
them
allows
you
to
just
building
or
specifically,
building
a
kubernetes
cluster,
and
then
they
have
different
ways
of
building
the
images
the
county
courts
under
nested
and
I'm
privileged
IP.
A
It's
need
it's
necessary
in
its
access
to
raw
proc.
Then
you
get
something
like
build
out.
The
requires
privilege
escalation
faster-than-light,
it's
just
with
layers
in
know,
docker
bouncer,
with
its
own
definition
files
and
then
k
native
with
its
own
templates.
So
you
see
one
of
the
interesting
things
of
these
tools
is
that
none
of
them
require
you
to
have
a
darker
daemon,
which
is
pretty
nice
right,
so
you
necessarily
have
to
have
docker,
and
all
of
them
allows
you
to
build
in
a
kubernetes
cluster.
It's
just.
A
Some
of
them
are
specific
for
that
for
like,
for
example,
catechu
and
the
other
ones.
You
need
other
ways
to
build
it.
So,
for
example,
builder
you
require
require
a
key
native
template
faster-than-light,
you
can
do
it
with
catechu
and
that's
all
you
require
can
occur
and
Kay
native,
so
the
tools
that
you
can
use
the
get-ups
tools
that
you
can
use
with
the
build
tools
together
so
are
pretty
much
the
ones
that
don't
have
any
dependency
on
building
anything
any
container.
A
So
the
top
four
tools
are
the
ones
that
you
can
use
with
any
of
these
flat
flux
case
on
it,
metal,
particle
and
Argo.
And
then
you
see
the
bottom
three
you
can't
you
cannot
use
with
with
these
container
build
tools,
graph
get
cube
and
scaffold
because
they
already
build
the
container
in
the
tool.
Itself
builds
the
container
right,
so
graph
has
its
own
CLI
and
then
and
then
you
say
draft
bill
and
it
builds
the
container
for
you
same
week.
A
A
A
So
we
came
up
with
easy
to
use
in
terms
of
get-ups
draft
and
scat
fall
in
flux
has
seemed
to
be
pretty
straightforward.
To
set
up
so
they'll
have
their
own
CL
eyes
and
documentation
is
extensive
and
in
terms
of
image
builds.
We
think
IMG
and
FDL
seem
to
be
pretty
easy
to
set
up
and
straightforward,
also
documentation
available
on
github
in
terms
of
community
support.
This
means,
maybe
which
organization
is
behind
it
or
how
many
github
starts
they
have,
or
maybe
how
much
traction
the
project
has
and
github
and
forget.
A
Ups,
we
came
up
with
flux,
graphing
scaffold,
which
is
the
same
tools
that
that
we
talked
about
previously
being
easy
and
in
in
terms
of
image
bills.
We
came
up
with
Bill
de
catechu
and
IMG
builder,
red
hats,
behind
it.
Canna
Co
Google
cloud
and
supporting
it
and
IMG
also
has
seems
to
be
very
popular
and
github
and
influx
is
supported
by
whip
works
and
graph
is
supported
by
Microsoft
and
scaffold
supported
by
Google.
A
A
Terms
of
production
ready
with
get
ups,
we
came
up
with
flux
on
our
go
there
like
a
1.7
1.8
release,
so
they've
been
around
it.
They've
had
a
lot
of
iterations,
so
we
think
they're,
stable
and
production
ready
and
turn
some
image
builds.
We
came
back
with
anything
that
is
darker
file
or
run
see
base.
Those
tools
have
been
around
for
four
plus
years,
so
they
there
would
be
a
good
choice
for
a
production
type
of
environments.
A
Also,
the
same
one:
more
1.0
releases
a
lot
of
zero
point
x
and
again
more
tools
to
build
in
inside
the
cluster
inside
your
kubernetes
cluster,
maybe
having
sort
of
like
a
Bill
CRD
and
your
kubernetes
cluster
that
allows
you
to
to
do
this
container
bills
and
helm
is
also
in
the
works,
is
another
tool
being
enhancing
v3.
The
proposal
is
out
and
it'll
support,
plugins
and
hooks
and
Lua.
So
you
can
run
write.
A
A
B
Actually,
no
because
rollback
is
more
of
a
deployment
feature,
so
there
were
only
two
deployment
tools
up
there.
We
use
flux,
but
we
only
use
the
sync
feature.
We
don't
use
an
automatic
image
pulling
feature.
Boback's
is
important
because
when
you're
rolling
out
new
code,
you
think
it
works
in
your
laptop
and
then
you
think
it
works
in
a
dev
cluster,
but
it's
sometimes
it's
always
different
in
the
production.