►
From YouTube: Flux increased security & scalability with OCI
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
A
Our
agenda
for
this
webinar
will
be
as
follows.
I
will
introduce
you
to
the
terminology
and
semantics
of
getups
and
flux
itself.
What
flux
is
and
how
it
got
to
be,
and
I
will
introduce
you
also
to
oci
what
these
three
letters
stand
for
and
where
is
it
coming
from,
and
then
we're
gonna
get
our
hands
dirty
looking
into
what
flux
can
offer
with
oci
and
conjunction,
I'm
gonna
show
you
that
it's
still
getups
and
we're
going
to
run
through
two
demos,
one
for
helm
and
one
for
customize.
A
A
A
A
A
A
A
A
A
So
it
provides
githubs
for
not
only
your
apps,
but
also
your
infrastructure,
so
you
can
have
your
cluster
completely
declared
and
and
a
get
repository
and
flux
will
make
sure
to
install
all
the
applications
and
infrastructure
components
it
integrates
well
with
existing
tooling.
So
it
is
as
opinionated
as
necessary,
but
as
dynamic
as
possible.
A
A
Plexus
ways
to
alert
and
notify
users
upon
certain
actions.
This
is
done
using
crds.
You
are
very
flexible
with
which
actions
you
want
to
trigger
an
alert
from
uses
trust
flux.
So
we
have
a
huge
user
base
among
the
cloud
native
community
and
flux
itself
has
a
very
lovely
community,
and
I
myself
experienced
that
when
I
first
got
in
touch
with
flux
around
one
and
a
half
years
ago,
it's
just
a
very
lovely
experience
being
in
touch
with
the
flux
community.
A
In
one
of
these
controllers,
so
there's
source
controller,
for
example,
that
actually
clones
a
git
repository
or
fetches
a
home
repository
index
or
fetches,
an
oci
image
from
an
oci
registry.
As
we'll
see
later
in
the
demo,
then
we
have
customized
controller
that
implements
flux's
opinionated
way
of
applying
customize
it
as
a
helm
controller.
So
you
can
very
easily
use
flux
to
deploy
home
charts
and
create
homolysis
notification.
Controller
is
a
separate
component
that
is
configured
using
crds.
A
A
A
These
three
specifications
work
together,
so
there's
execution,
which
is
symbolized
here
by
docker,
run
so
there's
a
runtime
running
on
the
computer
that
takes
care
of
executing
the
image
and
then
there's
the
address
of
the
registry
docker.io,
which
implements
the
distribution
specification
and
eventually
the
image
itself
that
is
pulled
from
the
registry
is
specified
by
the
image.
From
that
specification.
A
A
Application
and
then
there's
customizer
a
project
by
one
of
flux's,
core
maintainer,
stefan
and
that's
very,
very
similar
to
what
flux
does
with
customize
and
what
we're
going
to
see
in
the
demos
there's
also
a
quite
new
project
and
a
company
that
has
been
founded
around
it
called
acorn
and
acorn
uses
oci
for
bundling
applications
as
oci
images.
So
you
have
a
very
nice
front
end
a
very
simple
way
of
declaring
an
application
and
then
acorn
pulls
all
the
definition.
A
And
the
great
thing
about
oci,
besides
its
open
specifications,
is
that
oci
registries
are
already
a
commodity
in
the
cloud
space.
So
every
cloud
provider
has
an
oci
registry
warning
that
hosts
the
application
images.
So
the
docker
images,
if
you
will
but
there's
also
lots
of
other
implementations
out
there
and
the
auros
project,
actually
provides
a
list
of
these
implementations.
A
A
A
But
eventually
it
provides
better
security
and
much
better
scalability,
so
pulling
an
oci
image
is
much
less
resource
intensive
compared
to
full
or
even
a
shallow
git
clone
high
available
registries,
as
I
said
before,
are
available
everywhere.
So,
if
you're
running
on
aws,
if
you're
running
on
gcp
or
azure,
you
will
have
an
oci
registry
available
available
for
your
purposes.
A
A
A
Now
I'm
going
to
use
the
flux
cli
a
lot,
however,
for
90
of
the
actions
that
I'm
showing
here,
the
flux
cli
is
not
really
necessary,
because
all
it
does
in
this
demo
is:
it
creates
kubernetes
objects
and
in
a
production
workflow,
you
would
just
store
these
kubernetes
objects.
In
your
get
repository,
all
right,
there's
one
exception,
and
I'm
going
to
call
that
out
later,
when
we
get
to
it
all
right,
let's
create
a
source.
A
A
A
Let's
verify
that
pods
are
there
and
that
the
service
is
there,
everything
has
become
ready,
and
it's
as
simple
as
that.
So
consuming
health
charts
from
oci
registries
doesn't
change
very
much
in
terms
of
your
workflow,
especially
if
you're
consuming
third-party
charts
and
you
don't
have
to
to
upload
them
to
an
oci
registry.
A
But
in
that
case
the
the
concrete,
the
actual
version
being
deployed,
wouldn't
be
reflected
in
your
source
in
your
get
repository,
for
example,
if
you
need
this
to
be
the
case,
you
can
now
use
automated
updates
to
get
with
oci
repositories,
because
flux
has
an
image
automation
component
built
into
it.
It
needs
to
be
explicitly
enabled,
though,
but
it's
just
a
command
line
flag
when
you're
using
the
flux
cli.
A
In
that
workflow
too,
and
you
will
get
git
commits
for
every
version
bump,
and
you
don't
have
to
do
that
yourself,
you
can
also
let
it
you
can
specify
the
branch
that
the
change
is
being
pushed
to
here
in
the
spec
of
the
image.
Automation,
object
and
have
it
push
to
a
certain
branch
that
another
workflow
will
take
off
from
and
create
a
gita
pr.
For
example,
if
you
don't
want
flux
to
directly
push
to
your
main
or
production
branch.
A
A
A
A
A
A
A
A
A
The
important
thing
is
the
layers.
Flux
by
default
creates
one
layer,
but
you
can
actually
push
oci
artifacts
with
several
layers
and
tell
flux
which
one
to
pick
based
on
the
media
type
right.
So
you
can
have
a
layer
for
configuration,
a
layer
for
your
artifact
and
maybe
a
layer
for
your
actual
docker
images.
And
then
you
tell
flux.
Please
pull
the
artifact
from
this
media
type
and
let's
have
a
look
at
the
actual
image
content.
A
A
A
A
And
here
you'll
see
that
flux
also
pull
down
the
annotations
from
the
image
and
stores
them
and
the
status
of
the
of
the
of
the
object,
which
is
also
very
helpful.
So
you
don't
have
to
pull
down
the
image
yourself
to
know
where
the
source
comes
from
or
where
the
oci
or
effect
comes
from
all
right.
So
I
have
another
terminal
open
on
the
right
side:
we're
going
to
watch
for
parts
being
created
in
the
default
namespace,
because
now
we
are
finally
going
to
create.
A
A
A
A
A
The
path
here
tells
flux
to
only
create
the
customization
objects
from
this
path,
and
this
actually
helps
you
when
you
want
to
deploy
the
same
ocr
ice,
oci
artifact
on
different
clusters,
for
example
a
dev
cluster
and
a
prod
cluster.
So
you
can
store
the
configuration
for
both
in
the
same
artifact,
just
a
different
path
and
then
on
the
dev
cluster.
You
point
it
to
the
path
def
and
on
the
prod
cluster.
You
would
point
it
to
the
path
prod,
just
as
you
would,
with
the
get
repository.
A
A
A
A
A
A
Now,
oftentimes,
the
question
comes
up:
how
to
track
back
a
certain
resource
to
the
source
that
is,
it
is
being
created
from
in
a
github's
workflow.
So
let's
say
we
have
this
deployment
here.
That
is
called
pod
info.
How
do
I
know
which
actual
source
repository
or
get
repository
it
is
coming
from
when,
for
example,
I
want
to
change
it
from
two
replicas
to
three
and
flux.
Has
this
handy
trace
command,
which
I
can
ask
this
exact
same
question?
A
A
So
this
is
this:
contains
the
branch
and
the
tag,
I'm
sorry
the
sha
of
so
the
commit
char
and
the
path
like
the
url
of
its
repository.
This
doesn't
need
to
be
a
url
by
the
way.
It
can
be
anything
that
makes
sense
in
the
environment
that
you're
working
in,
but
usually
it's
it's
a
url,
pointing
to
the
actual
git
repository
that
you
can
clone.
A
A
But
this-
and
this
isn't
specific
to
a
ci.
I
just
want
to
point
that
out
real
quick.
This
has
always
been
the
case
with
flux.
It
applies
labels
so
that
you
can
track
back
each
resource
back
to
its
source.
So
here
the
label
says
this
resource
has
been
created
by
the
customization
of
this
name.
Coming
from
this
namespace
and
there
you
can
trace
back
your
way,
using
cubecolor,
for
example,
and
for
flux,
push
artifact
it's
very
similar.
A
A
This
is
part
of
our
own
documentation
that
we
maintain
at
fluxcd.io
and
it
helps
you
just
getting
started
installing
flux
bootstrapping
with
your
own
cluster
and
everything.
And
then,
if
you
want
to
take
it
a
step
further,
you
can
browse
our
docs
a
little
more.
We
have
documentation
on
all
the
available
components,
source,
controller,
customize
and
so
on.
A
So
this
is
also
a
very,
very
helpful
reference
when
you're
using
flux
on
a
day-to-day
basis,
we
also
have
covered
use
cases
that
we
usually
stumble
upon
and
that
we
hear
from
people
using
flux.
We
have
guides
on,
for
example,
using
cl
secrets
or
mozilla
subs.
If
you
need
to
store
your
secrets
in
a
secure
way
in
your
get
repository
and
all
that,
so
I
really
encourage
you
browsing
the
docs
and
if
you
want
to
get
a
contact
with
the
broader
flux
community
or
the
flux,
maintainers.
A
A
We
also
have
a
mailing
list
where
we
put
out
monthly
updates
and
announcements
and
all
of
flux's
source
code
is
spread
across
github
and
the
fluxity
organization,
but
it's
best
to
start
with
a
flux
to
repository
where
we
also
have
many
discussions
going
on,
for
example,
enhancements
to
flux.
So
if
someone
has
wants
to
propose
an
enhancement
to
flux,
they
usually
start
a
discussion
on
github
and
the
flux
tool
repository.