►
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2023 in Amsterdam, The Netherlands from April 17-21. Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
GitOps with Flux and OCI Registries - Soulé Ba & Scott Rigby, Weaveworks
Flux is a CNCF tool that enables users to adopt the GitOps methodology for continuous deployment. Flux reconciles your workload from different sources: Git, Helm repository, an S3 bucket, and now Flux maintainers have added support for OCI registries. Not only can Helm charts be stored as OCI artifacts, but also your Kubernetes desired state in plain YAML and other popular formats like Kustomize and Terraform. We will demonstrate how to use OCI registries as a source to deploy workloads using flux: - Deploy charts and Kubernetes manifests from an OCI registry - Sign and verify the workloads - Automatically update configuration repository and observer automatic upgrades We will also present the Flux OCI as source architecture so users can better understand what's going on under the hood when they use OCI registries for their GitOps source.
B
A
B
B
You
know,
flux
has
the
concept
of
of
sources
and
they
can
be
get
as
a
source.
Oci
or
excuse
me,
you
know
F3
compatible
buckets
as
a
source,
Helm
repositories
as
a
source
and
now
oci
repositories
as
a
source
for
for
everything,
we're
going
to
start
with
an
intro
where
we'll
see
what
our
OC
artifacts
are,
what
their
advantages
are
and
why
we
even
want
to
use
them
and
we'll
then
cover
new
features,
introducing
flux
around
OCR
and
effects.
B
Okay
right,
so
thanks
yeah.
So
what's
what
is
an
OCR
effect,
and
why
would
we
want
to
use
it?
So
what
we're
showing
up
on
Serena
right
now
is
something
that
many
of
you
should
be
familiar
with
so
you're
here
at
kubecon,
but
if
not
and
either
way
we're
going
to
do
a
comparison
with
artifact.
So
this
is
an
actual
the
Json
for
an
oci
image
manifest
it
is
a
oci
for
everyone.
B
Hopefully,
you
know
stands
for
open
container
initiative
and
it's
essentially
what
happens
when
you
build
a
Docker
image
or
use
any
other
oci
compatible
tool
to
to
build,
distribute
images,
so
the
image
manifest
describes
the
the
components
that
makes
up
an
image.
So
it's
basically
what
pretty
much
everything
that
you
will
need
to
run
a
container
down
the
road,
so
the
and
the
config
layer
that
you
see
at
the
top
contains
layer
ordering
information.
B
So
if
you've
got,
you
know,
if
you
you've
seen
images
have
have
multiple
layers
right
so
that
you
want
them
to
go
in
a
certain
order,
generally
speaking
and
excuse
me
and
what
basically,
what
needs
to
be
applied
in
order
to
get
root
file
system,
so
the
digest
feature
of
or
the
the
digest
key
up.
There
is
a
cryptic,
a
cryptographic
hash
of
the
compressed
content
of
the
target
component,
so
the
media
and
then
the
media
type
will
tell
us.
B
Excuse
me
what
compression
standard
is
going
to
be
used.
So
the
you
know,
oci
dot,
image.config.v1
plus
Json
gives
you
that
that's
what
I'm
talking
about
and
gives
you
that
information,
and
so
you
know
the
the
digest
is
similar
to
digest
or
other
things
and
it's
a
unique
and
you
need
cache.
So
if
the
content
changes,
the
digest
will
will
also
change
right.
So
when
fetching
a
manifest
either
the
config
or
layer,
we
have
to
apply
the
hash
function.
To
verify
that
it's
consistent.
A
A
If
you,
if
you
look
at
the
top
here,
you
can
see,
we
have
several
endpoints
for
every
kind
of
components
we
have.
We
have
in
the
endpoint
resource
identifier,
identifier,
you
have
the
name
and
you
can
do
some
Access
Control
bed
based
on
the
name
and
on
the
top.
You
have
the
tag,
the
tagged
endpoint
that
you
can
use
for
Content
Discovery.
So
we
said
that
digests
are
immutable.
Tags
are
not
tags
are
emitable,
you
can
use
tags
for
the
human
readable
versioning
of
our
images.
A
So
if
you
use
the
tag
endpoint,
we
can
achieve
do
content,
Discovery
and
retrieve
tags
for
a
given
image.
Then
we
can
use
the
manifesting
point
and
giving
a
reference.
So
reference
is
either
a
tag
or
a
digest.
We
can
retrieve
the
Manifest
once
we
have
the
Manifest.
We
have
everything
needed
to
pull
the
configs
on
the
Block
on
the
blocks
of
our
given
image.
A
B
A
B
Excuse
me
artifact
type
for
Helm,
it's
registered
as
a
as
a
media
type
and
that's
the
application
vendor
cncf
Helm,
config,
B1,
plus
Json
type,
so
that
that
allowed
people
like
say
if
you're
using
tools
to
get
information
from
an
oci
registry
to
say,
hey
I,
just
want
my
Helm
charts
that
are
stored
there.
In
this
case
it's
Helen
charts,
other
artifacts
can
be
stored
as
well
and
a
different,
and
you
don't
want
to
say
parse
through
all
of
the
container
images
in
that
same
registry.
B
This
type
was
a
thing
to
allow
you
to
do
that
and
the
the
Microsoft
well,
what
was
then
the
Microsoft
Project,
which
is
now
cncf
vendor
independent
project
called
oras,
which
is
oci
registry,
as
at
Ridge
streets
as
storage
has
fun,
has
a
really
good
tool
set
to
allow
these
things.
So
you
don't
have
to
do
it
by
API,
but
you
could
yeah
and
we've.
B
B
That's
I
think
that's
what
you
meant
there
was
that
that
is
a
way
kind
of
to
to
categorize
artifacts
so
that
you
don't
have
to
register
every
type.
So
you
could
say
I
have
six
different
artifact
types.
You
know
one's
customized
manifests
one's
Helm,
charts
one's
oppa
policy,
you
know
whatever
right
and
and
I
want
to
be
able
to
get
only
those
things
through
an
API.
B
It
wasn't
really
easy
to
do
that
unless
you,
unless
you
specify
the
media
type
and
generally
you
have
to
register
that
if
you
want
to
use
it
for
anything
besides
internal
use,
and
so
so
what
the
spec
chain.
Basically
with
that
addition
very
soon
you'll
be
able
to
not
only
have
a
different
media
type
but
you'll
be
able
to
use
the
standard
media
type
for
artifacts,
with
different
artifact
type
keys.
A
So
why
would
you
use
OCR
artifact?
The
first
use
case
is
in
order
to
collocate
your
code
on
your
configuration.
You
could,
for
example,
for
those
of
you
that
know
about
flux,
image,
automation,
controllers.
Today
we
use
this
to
automatically
reconcile
actually
our
code,
our
application.
Every
time
we
have
a
new
version
of
our
code,
the
image
control,
automation,
automation
is
reconciling
it
for
us
into
our
kubernetes
cluster.
Today,
if
you
have
your
hotel,
you
config
as
possible
artifacts,
you
can
do
the
same
things
with
your
configuration.
A
B
Really
it's
just
these
two
things:
that's
the
square
of
red
around
there.
It's
really
in
the
spec
URL.
You
just
put
the
URL
as
if
you're
a
Helm
user.
You
know
that
you
can
do
this
using
the
helm,
CLI,
it's
the
exact
same
URL
that
you
would
pass
for
for
where
your
oci
charts
are
stored.
It
just
needs
to
use
the
the
the
oci
scheme
in
the
URI
and.
B
Good
good
distinction
yeah
so
or
we
should
probably
say
that
yeah
that
the
HTTP
Helm
repository,
if
for
anyone
that
doesn't
know,
has
an
index
file
that
lists
all
the
information
about
all
of
the
charts
in
that
https
Helm
repository
and
all
of
the
versions
for
each
of
those
charts.
So
there
have
been
cases.
This
is
a
pretty
important
point
for
people
that
are
concerned
with
bottlenecks,
for
example,
you
may
or
may
not
have
ran
into
this.
B
If
you're
a
legacy
chart
user
for
bitnami
betnami
is
one
of
the
major
chart
distributed
chart
sets
of
maintainers.
You
know
who
regularly
rigorously
tests
their
charts
and
images,
and
just
they've
been
doing
this
for
a
really
long
time,
and
so
a
lot
of
folks
trust
them.
They
had
to
truncate
all
older
versions
from
their
Beyond
a
certain
point
for
their
charts,
because
just
the
index
file
was
like
something
like
gigabytes.
It
was
just
ridiculously
huge
and
the
reason
that
it
needs.
B
A
So
we
have
also
implemented
an
integration
with
cosine
in
Flex,
so
just
to
tell
you
how
cosine
works,
the
cosine
is
used
to
to
sign
oci
artifacts.
So
the
way
it
works
is
you
create
a
key
pair
and
they
keep
an
electric
curve
keeper.
You
sign
yourself
or
your
artifact
manifest,
and
you
store
the
signature
with
the
other
oci
artifacts
and
in
order
to
do
the
decryption
the
verification
we
retrieve
the
signature
for
the
from
the
registry.
A
You
verify
the
signature
against
a
public
key
and
you
verify
the
claims
as
well
verifying
the
client
mean
you
have
a
payload
in
the
signature
that
they
knew.
What
what
digest
manifest
digest
has
been
signed,
and
you
verify
that
the
digest
correspond,
and
there
is
an
experimental
feature
of
that-
is
a
transparency
log
that
can
be
that
can
be
used.
A
That's
how
it
does
work.
So,
let's
just
show
you
how
we
do
the
Hem
release
reconciliation.
So
for
this
we
assume
that
we
have
a
running
plug
winning
clutch
controller,
a
hem
controller
or
Source
controller,
and
that
you
have
applied
given
many
test.
Then
how
does
it
work
from
a
user
spec
spectative?
You
push
your
hand
shot
so
to
your
officer,
which
is
in
your
repository,
then
Flex
Source
controller
is
managing
hemipositories
and
hemises
custom
resources.
So
what
it's
going
to
do
is
first
pull
the
signature,
so
this
is
optional.
A
That's
why
we
have
this
like
this
you,
but
if
you
have
enabled
it,
you
pull
the
signature
and
you
do
the
the
chart,
verification
if
the
charge
application
is
successful,
you
can
move
on.
If
not,
you
have
a
nice
condition
in
the
custom
resource
when
you
do
keep
cattle
describe.
That
shows
you
why
the
the
build
is
not
successful.
A
Otherwise,
after
the
verification,
it
is
going
to
pull
your
hair
much
effect
build
how
much
effect
with
the
given
optional
value
files,
because
what
we
do
with
search
controller
is
the
the
default
value
file
is
not
included.
If
it's
not.
If
you
do
not
specify
it,
then
you
package
the
store
to
do
the
chart
and
we
store
it
as
a
notch
effect
with
the
location
that
can
be
used
and
then
it's
the
kubernetes
API
servers
receive
a
notification
and
notify
all
watching
controllers,
and
one
of
the
watching
controllers
is
the
Hem
controller.
A
What
the
Hem
controller
is
going
to
do
is
first
fetch
all
the
values
that
you
have
set
and
into
your
resources,
the
resources
being
config
maps
and
secrets
that
you
merge
them
together
and
then
it
will
fetch
the
artifact
and
we'll
do
the
deployment
of
server
list,
the
deployment
being
either
a
hem
install
or
Helm
update.
And
then
this
is
the
same
process
that
exists
today.
A
A
What
we
do
is
this
is
something
that
we
already
had
with
the
image
automation,
controller.
What
what
it
does
is
that
it's
take
your
image,
your
profile,
your
cloud
provider,
identity
service,
and,
if
you
specify
that
we
want
to
use
a
given
provider,
it
will
use
the
workload
identity
either
to
the
service
account,
attach
your
controller
either
to
to
the
node.
B
Yeah
only
one
other
node
I
wanted
to
to
mention
about
that
is
it's.
It's
actually
a
yes
yeah,
I'm!
Sorry,
it's
it's
a
key
on
the
oci
registry
custom
resource
definition
that
just
says
provider.
We
didn't
put
those
in
the
earlier
slides
because
we
didn't
want
to
confuse
didn't
want
to
add
that
new
functionality
we
were
talking
just
about
migration,
but
but
yeah,
you
just
simply
say:
gcp
AWS
Etc
and
the
open
ID
connects.
B
Cool
yeah-
and
you
know
this-
the
CLI
has
some
flux.
Cli
again,
you
don't
need
to
use
the
flux
CLI
in
order
to
be
a
flux
user
it
just
it's
really
handy
so
most
people
like
to
use
it
for
different
things
such
as
this.
So,
for
example,
you
could
use
the
orus
project
directly
to
build
your
artifacts,
but
but
flux
has
built-in
tooling
to
call
that
just
like
Helm
does,
for
you
know
the
the
build
Push
Pull.
So
these
are
the
these.
B
You
just
do
your
Docker
login
to
get
your
config
or.
However,
you
want
your
to
authorize
your
to
the
registry
that
you
want
to
use,
and
you
just
do
a
flux,
push
you
do
the
same
thing
you
you
give
it
the
path
that
you
of
the
repo
excuse
me,
you
give
it
the
URI
of
the
oci
registry
that
you
want,
and
then
you
know
the
the
the
app
in
this
case.
B
A
B
A
Now,
the
for
the
demo
we
have,
we
will
be
using
a
fork
of
body
info
from
Stefan
and
we
have
two
skills
can
I
use.
The
first
one
is
that
you're
going
to
migrate
Podium
for
kubernetes,
manifest
from
git
to
oci,
so
we
will
be
handling
packaging
and
pushing
the
Manifest
to
GitHub
container
registry,
signing
it
with
cosine
and
deploying
them
to
kubernetes
the
the
second
one
is
the
same
thing,
but
you
will
be
using
the
provided
Helm
chart
to
Market
it
to
oci
and
again
packaging
signing
and
entering
to
kubernetes.
A
A
A
What's
the
package
them,
so
we
put
what
is
insured
and
what
is
in
customized
into
archive
I
will
show
you
what's
inside
and
then
we're
going
to
push
with
us
when
you
push
it
RS.
What
you're
going
to
do
is
we
give
the
location
and
the
name
of
the
the
other
artifact
with
the
tag
and
we
provide
as
well.
The
major
type
here
is
going
to
be
a
layer
of
the
and
compass
with
gzip.
A
A
So
when
we
sign,
we
specify
the
location
of
the
artifact
and
because
I'm
going
to
pull
it
retrieve
the
Manifest
and
sign
it
first
and
then
push
the
signature
collocated
with
the
Manifest
when
it
is
pushing
the
signature.
What
we
can
see
here
is
that
it's
it
set
a
tag
for
the
signature
find
finishing
with
that
Sig
and
the
tag
actually
is
the
digest
of
the
Manifest
of
the
USA
many
test.
A
So
now
this
is
done,
so
we
need
actually
we
need
the
public,
the
public
key
in
order
to
do
the
verification
in
kubernetes
side.
So
we
create
a
secret
with
this
and
then
what
you're
going
to
do
is
we're
going
to
coming
back
we're
going
to
deploy
an
oci
repository
then
put
info
with
the
location
of
our
wholesale
artifact
I'm,
going
to
provide
a
Sim
somewhere
and
at
the
end
we.
A
And
then,
once
it's
applied,
we
can
look
at
our
custody,
I
will
say
repository
and
here
what
you
can
see
is
that
you
have
an
artifact
Attica
containing
our
manifest,
and
we
can
see
at
the
end
that
we
have
a
60
in
the
condition
you
can
see
that
we
have
condition
type
search
by
a
file
and
that
it
has
six
digits
and
you
have
the
verified.
The
signature
of
the
given
revision.
A
A
And
you
provided
the
sub
decryption
key
for
the
for
the
subsequent,
so
this
is
applied
here
we,
but
you
can
see.
If
you
look
at
the
status
you
can
see
here
we
have
an
the
customized
controller
existing
as
an
inventory
in
the
inventory.
You
can
see
what
is
half
applied,
so
here
we
can
see
it
has
supplied
a
secret,
a
service,
a
deployment
and
an
HPA.
A
A
A
A
A
Then
we
do
experimental
cosine.
So
when
we
do
the
experimentary
cosine
see
a
keyless
signature.
What
it's
going
to
do
is
it's
going
to
authenticate
us
with
with
no
IDC
schemes,
so
we
are,
let's
see
so
what
we're
going
to
do
is
going
to
authenticate
this,
because
what
it's
going
to
do
is
is
using
the
special
certificate
authority
to
to
generate
a
really
short-lived
certificate.
To
do
to
do
that.
A
To
do
to
do
the
signature
shortly,
meaning
10
minutes
here
and
when
you
generate
the
certificate
as
a
alternate
name,
you
will
have
your
email
address.
Actually
this
is
something
to
know
so
now
this
is
done,
and
here,
but
you
can
see,
is
that
it
has
signed
and
pushes
at
the
bottom.
We
can
see
that
sassan
and
push
the
signature
to
our
view
this
way.
So
then,
what
you're
going
to
do
the
same
thing
here
that
we
showed
Hemi
repository
pointing
to
our
location
and
we
have
set
provider
gcp
here.
A
So,
let's
see
what
once
we
do
this
to
reapply
everything
so
first
we
declare
the
ham
repository.
We
see
that
this
has
168,
so
it
has
six
degrees
in
logging
and
verifying
the
Authentication
to
a
repository,
and
then
we
see
the
release
and
we
see
that
the
release
has
succeeded
and
it
has
installed
on
the
the
body
for
the
hand
shot,
and
it
has
done
the
verification
you
have.
You
can
see
here
that
we
said
verify
provide
a
cosine
and
if
you
look
at
the
helm,
charts
itself.
A
B
B
Yeah,
absolutely
so,
basically,
thanks
for
we're,
maybe
going
over
like
a
minute
and
a
half
two
minutes.
So
then
the
coffee
breaks
are
basically
just
like
wrap
up
a
couple
of
links
and
some
just
info
how
you
can
get
in
touch
with
us.
So
so,
basically
like
what
again,
why
are
we
transitioning
to
oci
from
Helm
it's
to
make
sure
that
we
adopt
the
same
delivery?
It's
when
you
want
to
I
shouldn't
say
when
you
want
to
adopt
the
same
delivery
mechanism
for
applications
and
configs.
B
So
there's
no
there's
also
no
scaling
issues
related
to
the
index.yaml
that
I
mentioned
before
as
an
example
with
bonami,
but
that's
just
one
example
of
many
really
every
time
you
call
out
to
the
index
file
you're
making
another
round
trip,
so
it
takes
that
away.
It
also
enables
charts
signature
verification,
the
same
way
that
you
do
your
images
and
it
as
sulay
was
just
showing
in
the
demo.
You
can
leverage
leverage
your
provider,
edit
ID
service
for
off
so
or
oven.
B
So,
and
then,
why
would
you
transition
from
get
to
oci
very
similar,
first
reason
adopting
the
same
delivery
mechanism?
You
also
avoid
Distributing
objects
with
different
life
cycles
within
the
same
repository
and
you
and
similarly,
you
enable
your
config
objects,
verification
using
cosine.
It
also
allows
better
access
control
over
a
given
artifact
and
the
same
with
your
your
off
end
as
well.
So
there's
some
links.
If
anyone
wants.