►
From YouTube: GitOps Based Infrastructure as Code with Rancher Fleet and Crossplane - Hossein Salahi, Liquid Reply
Description
GitOps Based Infrastructure as Code with Rancher Fleet and Crossplane - Hossein Salahi, Liquid Reply
With more demand for deploying at scale, we need a new concept for multi-cluster management. The majority of current multi-cluster and multi-cloud management solutions are missing a unified control plane not only to manage Kubernetes cluster life cycle (vanilla or managed), but also application deployment, security policies enforcement (e.g., RBAC, network policies, etc.). By using GitOps patterns we can solve most of the above-mentioned challenges. Fleet is the next generation of cluster management tooling and uses Kubernetes Custom Resource Definitions (CRDs) to manage GitOps at scale up to deployments of thousands of clusters. Crossplane, on the other hand is a cloud control plane that transforms Kubernetes API into an interface to the public or private cloud providers. The Crossplane fits really well into the Gitops realm, since it allows declarative specifications of cloud services that are stored in a git repository for GitOps tools to pull from it.
A
Hello,
everyone
thank
you
for
joining
this
talk
today,
I'm
going
to
talk
about
how
we
can
combine
infrastructure
as
a
code
with
githubs
and
how
we
can
manage
a
multi-cloud
infrastructure
and
I
will
introduce
a
new
concept
and
on
that
way
I
will
introduce
two
new
tools
short
about
myself.
My
name
is
hassan
salahi.
A
I
work
as
cloud
engineer
cloud
consultant
at
liquid
reply,
short
of
my
company.
We
are
a
company
based
in
germany
and
we
are
highly
focused
on
cloud
native
development.
We
help
our
customer
to
build
design,
build
container
organization
platforms
and
also
to
help
them.
You
know
underway
to
the
cloud
to
to
cloud
native
journey
in
topics
like
cloud
native
development
and
especially
phenoms.
A
What
are
my
focuses?
Like
my
company,
I
like
to
design
and
build
cloud
and
cloud
native
infrastructures.
I
I'm
highly
focused
on
automation.
I
like
to
automate
boring
stuff
that
I'm
daily
dealing
with
them,
and
I
look.
I
also
like
to
yeah
to
make
sure
myself
busy
with
cloud
platforms.
I
have
openstack
background
and
now
I'm
highly
focused
on
container
organization
platforms.
A
A
It
means
every
time
I'm
going
to
deploy
the
same
infrastructure,
I'm
going
to
not
to
face
runtime
issues
missing
dependencies,
so
infrastructure
as
a
code
is
lying
on
the
pillars
of
devops.
It
means
it's
using
git
as
a
single
source
of
truth,
where
our
code
is
lying
and
we
are
using
gitlab
cicd
pipelines
to
automate
the
deployment
and
provisioning
this
infrastructure
and
also
keeping
maintaining
the
life
cycle
of
these
cloud
resources.
A
A
A
I'm
sure
you
have
come
to
this
point.
You
are
using
terraform
to
provision
infrastructure
and
you
are
getting
this
point
that
terraform
cannot
handle.
All
the
requirements
cannot
tackle
all
the
dependencies.
I
want
so
my
case.
I'm
ending
up
writing
really
long,
terrible
dirty
shell
script
inside
terraform,
using
aws
cli
to
yeah
to
achieve
what
I
want,
but
this
is
like
really
painful.
A
A
First,
as
I
said,
one
tool
is
not
a
silver
bullet
to
tackle
all
the
requirements.
It
cannot
be
because
they
are
some
of
these
apis
of
the
cloud
providers.
They
are
highly
opinionated.
They
are
developed
for
their
own
toolings
and
our
infrastructure
as
the
code
tools
are
not
talking
to
the
same
api
all
the
time,
because
these
apis
are
changing
all
the
time.
A
The
other
challenge
I've
personally
been
dealing
with
lots
of
customers.
Someone
is
going
and
deleting
in
a
vm
in
aws
stack
and
my
tool
is
not
reconciling.
There
is
no
reconciling
working.
So
if
someone
deletes
one
vm
or
s3
buckets
the
next
time,
I'm
going
to
run
terraform
plan
apply,
it's
gonna
break
because
it
says
I'm
sorry
a
vm
is
missing.
A
I
don't
know
what
happened,
someone
deleted
by
mistake,
so
this
is
a
pain
and
such
a
setup
as
we
saw,
brings
complexity
for
the
platform
or
sre
team,
and
it
puts
them
on
the
back
foot
because
they
are
limited.
They
are
limited
in
terms
of
resources
to
deal
with
such
a
complex
setup
and
if,
like
one
developer,
comes
with
specific
requests
like
I
want
this
and
that
specific
cloud
resource,
please
do
do
it
for
me,
they
cannot
handle
it
and
the
other.
A
Last
but
not
least,
I
know
from
my
career
developers
are
not
interested
into
managing
cloud
infrastructure
because
they
are
from
my
point
of
view.
They
are
our
customer,
they
don't,
they
don't
want
to
deal
with
any
tooling.
They
just
want
to
get
the
resource
and
get
the
benefit
of
it.
They
don't
want
to
be
involved
at
any
part
of
creation
or
managing
the
life
cycle.
A
I
would
like
to
take
you
first
to
a
definition
of
githubs.
Let's
take
a
look
at
what
this
github
is
about.
Let's
make
a
recap:
githubs
is
born
in
cloud
native.
It's
the
declarative
way
to
get
to
continuous
delivery,
continuous
deployment.
Basically
it's
born
in
kubernetes.
So
at
the
end
it
means
nothing
then
combines
manifest.
A
The
core
part
of
this
concept
is
git
as
a
single
source
of
truth.
All
our
manifest
all
our
configurations
are
lying
there
and
the
other
integral
integral
part,
is
the
git
ups
operator,
which
is
based
on
kubernetes
operator
concept,
is
a
tool,
that's
running
on
a
target
cluster
and
is
reconciling
all
the
time
you
know
with
the
kit.
A
A
A
It
has
a
controller
which
is
running
in
a
cobias
cluster,
and
this.
This
controller
is
all
the
time
you
know,
reconciling
you
know
with
the
git
and
checking
the
state
of
the
git
and
as
our
classical
ci
part,
you
know.
As
soon
as
you
know,
a
developer
makes
changes.
You
know
in
a
helm,
chart
or
container
image.
It
will
be
built
by
our
ci
cd
pipeline.
It
will
be
pushed
to
the
artifactory,
and
one
of
the
features
like
just
came
out
in
fleet
is
that
fleet
is
also
able.
A
You
know,
to
check
the
state
of
the
artifactory
to
see
which
images
are
lying
there.
If
there's
update
it
can
detect
it,
but
it
won't
be
applied
till
the
user
like
more
specifically
allows
it,
and
at
the
left
side
we
have
our
dynasty
clusters.
So,
in
terms
of
fleet
downstream
clusters
are
our
target
clusters.
They
can
be
bundled
into
different
type
of
groups,
stage
based
provider
based
and
that's
how
you
know
you
can
deploy
kubernetes
application
scale.
A
So,
at
the
end
of
the
day,
there
is
a
one
agent
from
fleet
which
should
be
run.
You
know
at
the
target
cluster
and
that's
how
you
so
the
the
agent
is
always
in
contact
with
fleet
controller
and
like
asking
give
me
a
job
to
do
jimmy,
give
job
to
do
and
felid
says.
Okay,
there
are
changes
in
the
git
repo,
so
yeah
update,
target
cluster.
So,
like
short
about
the
fleet
bundle,
free
bundle
is
nothing
than
combined
is
manifest
or
helm
chart
or
customized
configuration.
A
How
we
can
achieve
this,
how
we
can
achieve
managing
infrastructure
using
githubs,
so
we
have
to
take
a
look
at
the
principles
of
githubs,
which
is
declarative
semantic,
so
we
have
to.
We
have
to
be
able
to
define
cloudy
sources
with
the
same
semantic
and
that's
where
we
are
going
to
benefit
the
combined
operator,
which
is
the
approach
to
implement
this
concept
so
based
on
nothing.
Then
x,
you
know
extending
kubernetes
api
using
crds.
A
A
Taking
the
benefit
of
managed
services
from
cloud
providers
like
s3
bucket
message,
queue
message
pop
or
database
like
arura
or
postgres,
so
this
tool
enables
us
to
create
a
self-managed
layer,
so
enables
the
developers
just
to
use
the
same
api
to
talk
to
cloud
cloud
providers
and
define
the
dependencies,
and
recently
they
introduced
a
new
project
called
terajet.
Terajet
enables
us
to
use
the
existing
terraform
providers
to
to
build
crossplane
providers,
so
we're
using
the
underlying
existing
providers
to
to
benefit
the
existing
ones,
not
to
write
the
new
ones.
A
A
This
is
a
this
is
exactly
how
when
we
want
to
create
and
manage
resources
it,
it
defines
how
this
managed
resource
looks
like
the
other.
Important
component
is
a
composite
resource
definition
similar
to
crd,
but
a
bit
different.
It's
how
we
define
the
type
and
the
schema
of
this
composite
resource.
Actually,
it
enforce
all
the
time
when
we
are
creating
a
claim.
So
I
will
talk
later
about
it.
Every
time
we
are
creating
a
we
want
to
create
a
managed
resource.
This
is
the
compass
resource
definition
to
it's.
A
Enforcing
the
semantic
and
type
of
the
resource
composition
is
nothing
then
one-to-one
mapping
between
the
managed
resources
in
term
of
cross-plane
and
the
real
cloud
resources.
It's
the
the
component
knows.
Okay,
when
I
want
to
create
rds
instance,
I
need
to
talk
to
exactly
the
cloud
real
cloud
resource
and
the
provider
is
similar
to
terraform
providers.
So
it's
how
you
know
you're
talking
to
the
any
specific
cloud
provider.
There's
a
controller
running
and
your
kubernetes
cluster
is
able
to
talk
to
your
target
provider.
A
So
imagine
such
a
concept
enables
us
to
create
the
self-managed
service
platform.
At
one
side
we
have
the
dev
team,
they
don't
really
care
about
what's
happening
at
the
background,
it's
like.
Let
me
give
example
of
persistent
volume
claim
and
persistent
volume
paid
system
volume
in
terms
of
storage
class.
Back-End
storage
are
mostly
managed
by
sre
or
platform
team
and
mostly
developer
team.
A
They
have
no
idea,
or
they
don't
want
to
be
involved
at
all
about
what's
happening
in
the
background,
so
they
just
want
to
create
a
claim
like
positive
volume,
flame
and
crossplane
will
take
care
of
creating
the
real
cloud
resources.
This
is
a
great
opportunity
just
to
put
both
of
this
team
under
the
same
concept
in
the
same
platform,
and
this
is
let's
step
enables
the
the
platform.
A
A
A
A
We
have
one
central
committee's
cluster
fleet
is
running
and
at
the
same
time,
crossplane
is
deployed.
Fleet
is
taking
care
of
deploying
cross
planes.
So
if
we
want
to
change
something
in
terms
of
cross
plane
version
configuration,
it
will
use
the
same
concept.
The
configuration
are
relying
in
the
git
and
as
soon
as
you
change,
something
in
the
configuration
of
crossplane
fleet
is
going
to
detect
it
and
will
update
the
crossplane.
A
So
this
enables
us
to
talk
to
one
single
api
at
universal
api,
which
is
kubernetes
in
a
declarative
way.
We
know
yaml
manifests
in
the
same
way
we
can
create
cloud
resources,
so
this
saves
us
from
the
hustle
of
using
different
languages,
different
tools
and
just
to
talk
one
api
and
get
the
benefit
of
the
declarative
manner.
A
I
will
show
a
short
demo,
but
before
jumping
to
the
demo,
I
will
just
talk
about
how
what
I
will
show
in
this
demo
to
you.
So
my
central
cluster
is
running
in
aks
cluster
and
felita
and
crosbyn
are
deployed
and
I
will
show
how
we
can
create
a
jke
cluster
and
then
gonna
be
a
fleet
agent
running
there
and
the
same
time
gonna
be
cloudy.
Sql
postgres,
created.
A
Shortly,
I
will
show
how
the
git
repository
looks
like
so,
as
I
said,
I'm
using
the
fleet
to
deploy
crossplane.
So
this
is
half
it's
defined
so
using
the
custom
resource
definition
concept
of
fleet.
So
I'm
just
like
yeah
pointing
this
to
a
helm,
repository
and
saying.
Okay,
I
want
this
chart
with
this
version
and
please
deploy
specific
cloud
provider
packages
when
you're
deploying
crossplane.
A
A
A
A
A
A
Okay
short
about,
what's
happening
right
now,
this
bootstrap
yeah.
We
can
ignore
it,
because
it's
for
the
initial
setup,
but
the
second
one
you
can
see.
You
know
this,
this
new,
a
github
I
just
deployed
yeah.
So
did
the
hash.
You
know
it's
standing
for
the
hash
commit,
so
that's
coming
directly
from
the
git
repo
and
what's
happening
you
see
it's
saying
it's
not
ready,
because
it's
now
talking
to
the
cloud
provider,
it's
trying
to
create
two
resources.
A
A
Same
it's
synced,
but
still
trying
to
create.
I
can
jump
into
the
gcp
console
just
need
to
refresh
yeah.
It's
spinning
up
the
cluster,
most
probably
yeah.
It's
deploying
and
if
you
look
at
take
a
look
at
the
nodes,
yeah
it's
starting
to
provision
the
nodes,
it
will
take
a
while
and
let's
take
a
look
at
the
sql
part
yeah,
it's
already
there.
It's
already
there
and
running
so
this.
A
So
I
would
like
to
summarize
my
call
so,
as
we
saw
this
creates
a
great
opportunity
to
have
a
common
api,
a
common
language
and
the
same
workflow
for
both
of
the
dev
and
sre
or
platform
teams.
They
can
use
the
same
git,
repo
and
everything
gonna
be
gatewayed,
using
the
pull
request
and
it
gonna
be
really
transparent
for
both
sides,
which
resources
have
we
deployed.
What
is
the
state?
Because
everything
is
declarative,
relying
in
the
git
repo
and
the
principle
of
lease
privilege?
So
it's
my
own
experience
from
my
customers.
A
Don't
give
cube
ctl
or
any
kind
of
cli
to
the
to
the
dev
team,
because
this
gonna
end
to
chaos,
so
git
is
the
best
place
to
direct
them.
So
please
use
the
git,
create
your
resources,
we're
gonna,
see
we're
gonna
gateway,
it
we're
gonna,
look
through
the
pull
request
and
keep
their
fingers
away
from
any
kind
of
command
line.
A
So,
as
we
saw
this
wanna
help
us,
you
know
to
avoid
having
different
setups
with
different
configurations,
because
everything
is
declarative.
Everything
is
managed
with
the
git,
so
we
can
always
see
the
state,
and
always
the
the
github
operator
is
reconciling
with
the
git,
and
the
state
of
the
system
is
up
to
date
and
this
also
good
opportunity
for
managed
day
two
operations
like
deploy.
Enforcing
you
know,
policies
like
opa
or
kyberno,
or
network
policies
or
any
monitoring
observability.
You
know,
tools
can
be
deployed
with
the
same
concept.
A
C
B
B
C
A
B
A
To
to
that
and
yep
I,
I
was
just
checking
a
couple
of
days
ago
for
this.
I
I
I
think
I
saw
example
for
the
main
club
providers.
I
was
looking
for
kvm
or
livbert
or
openstack.
Unfortunately
they
are
still
in
the
you
know
in
the
beginning.
So
I
I
hope
they're
gonna
be
more
movements
there,
but
yeah.
That's,
I
think
I
it
would
be
great,
but
I
think
it's
coming.