►
From YouTube: OpenShift Commons Briefing #145 Bringing Policy-As-Code into Kubernetes Khash Sajadi (Cloud 66)
Description
Bringing Policy-As-Code into the Container Delivery Pipeline with Khash Sajadi (Cloud 66)
Containers bring Devs and Ops closer together, and at the pace of commits on a microservices app, that can be daunting to some IT Ops teams. A delicate balance is required between operational governance and developer freedom—and that balance needs to be automated. Now that they’ve put in place cutting edge containerized infrastructure on the likes of OpenShift, how do IT Ops teams and dev managers ensure infrastructure and security policies are embedded into the deployment pipeline, in an easily-maintainable way, and without slowing down code? How do they avoid building custom technology for deployment, in a rapidly commoditizing world?
This session will walk through tools (open source and otherwise) developed by Cloud 66, which runs 4,000 customer workloads on Kubernetes, supported by over 2,000 lines of configuration. These tools enable teams to:
secure images and manage secrets and IP in the build;
bring in configuration validation into the pipeline;
ensure fine-grained access control; and
Complement CI tools with powerful multi-environment, multi-team deployment capabilities.
Speaker: Khash Sajadi, Cloud 66 co-founder & CEO
A
A
Hello,
everybody
and
welcome
again
to
yet
another
OpenShift
Commons
briefing,
and
this
one
we've
waited
for
for
a
while.
We've
had
some
scheduling
conflicts
with
cash
and
his
team,
so
I'm
really
pleased
to
have
cloud
66
and
remember
to
the
open
ship
Commons
talking
about
bringing
policy
as
food
into
kubernetes,
so
I'm
gonna,
let
cash
introduce
himself
and
the
topic
and
explain
what
he
means
by
that
great.
B
Well,
thank
you
very
much.
Thank
you.
Everyone
for
joining
us
today,
I,
my
name
is
cash
I
work
for
cloud
66
and
today,
I
wanted
to
share
some
of
the
stories
that
we
had
to
the
problems
and
the
the
challenges
that
we
had
to
overcome
when
we
wanted
to
move
our
own
application
into
kubernetes
and
as
a
result
of
all
those
challenges
and
things
that
problems
that
we
had
to
solve,
we
had
to
build
a
product
open
source,
a
bunch
of
other
ones
and
I
thought
it's
a
great
opportunity
now
to
share
this
with
you.
B
If
it's
helpful
to
anyone
that
would
be
great
for
us,
it's
a
great
story
as
well
as
that,
if
you,
if
anybody
wants
to
come,
you
know,
ask
any
questions.
Please
feel
free
to
to
have
that
at
the
end
that
we
can
we
can.
We
can
moderate
that
so
you
get
started,
I
wanted
to
talk
about
a
little
bit
about
the
concept
of
kubernetes
day
one
and
what
I
mean
by
that.
B
People
like
Korres,
Red
Hat,
you
know
open
shift
itself
is
a
great
way
of
running
kubernetes
and,
and
we
kind
of
by
the
end
of
2017.
We
realized
that
setting
up
a
highly
secure
and
highly
available
communities
clusters
becoming
easier
and
easier
with
that,
with
the
help
of
tools
like
gke,
which
is
Google's,
managed
communities,
open,
OpenShift
and
Amazon
Web
Services,
just
coming
into
this
market
with
great
products
and
offerings
like
ECSC,
KSFR
gate
so
day.
B
One
of
kubernetes,
which
is
setting
up
your
cluster,
is
getting
easier
and
it's
becoming
more
available
to
everyone
at
a
good
running
cluster,
and
this
kind
of
leaves
us
leads
us
to
day
two
of
kubernetes
which
what
I,
what
I
see
as
day
two
so
now
day,
one
we
had
the
kubernetes
cluster.
What's
gonna
happen
in
day
two:
now
you
have
a
company's
class
that
you
have
access
to
it.
B
B
B
We
could
set
up
a
coconut
cluster
in
in
in
ours,
if
not,
if
that
shorter
than
that,
but
once
we
had
the
kubernetes
cluster
running,
we
realized
that
our
application
wall
is
containerized,
and
while
we
had
the
community's
configuration
files
for
it,
there's
a
bunch
of
things
that
we
couldn't
do
and
there's
a
bunch
of
things
that
we
were
not
really
confident
doing
so.
The
way
I
look
at
it.
Kubernetes
cluster
is
like
a
vending
machine.
B
If
you,
if
you
walk
into
a
you
know,
an
office
building
is
very
likely
that
you
see
a
vending
machine
packed
with
and
cookies
and
other
things
that
might
be
there
and
and
it's
kind
of
like
as
if
in
kubernetes
cluster
is
a
vending
machine
that
operations
guys
the
ops
build
for
developers
to
consume
it's
a
resource.
That's
available
me
is
made
available
internally.
So,
by
the
end
of
day,
one
we
have
the
vending
machines
installed
everywhere.
B
Now
developers
can
come
and
come
and
use
it,
and
in
order
for
this
vending
machine
to
be
usable
for
every
application
that
is
in-house
or
from
third-party
vendors
that
want
to
provide
us
with
services.
On
top
of
this
infrastructure
setup,
we
need
to
use
configuration
files,
we
need
to
use
and
draft
and
apply
configuration
and
for
our
application
into
this.
This
could
be
in
terms
of
community
services
deployments.
B
So
the
best
thing
about
communities
is
that
everything
is
a
resource
from
an
application
service
that
is
running
to
a
port
and
a
firewall
and
a
load,
balancer
they're,
all
equal
and
they're
all
resources,
and
that
makes
very
good
that
makes
it
a
very
interesting
thing
for
for
everyone,
operations
and
developers
within
an
organization
to
have
a
unique
and
a
uniform
view
of
the
infrastructure
by
looking
at
these
resources.
So
you
can
look
at
the
configuration
file
and
tell
that
you
know
this.
B
Ip
address
belongs,
but
a
firewall,
while
the
other
IP
address,
for
example,
or
service
name,
is
a
database.
That's
provided
and
that's
a
great
thing,
which
was
not
available
when
we
were
had
to
deal
with
recipes,
for
example,
but
this
also
presents
a
challenge
where,
as
a
developer,
I
can
technically
go
and
make
a
mistake
in
my
configuration
file
and
change
a
storage
class
and
that
will
potentially
can
bring
everybody
else
within
this
infrastructure
set
up.
Do
everybody
affect
everybody
else
and
bring
them
bring
the
application
down
one
of
the?
B
On
the
resource
by
resource
basis,
or
you
would
have
to
build
up
and
improve
all
the
process
where
changes
are
put
into
an
approval
request,
and
it
like
something
like
a
pull
request
and
you
would
have
to
owe
you
or
your
team
have
to
review
that
and
then
approve
it
and
then
for
it
to
go
out.
It
can
get
marriage
back
into
the
mainstream
configuration
repository
where
it
goes
out
and
hits
the
cluster,
and
just
by
creating
that
parallel
flow
of
approval.
B
We
realize
that
we
can
potentially
create
misalignment
between
the
teams
who
want
to
roll
out
a
service
within
the
within
the
organization.
For
example,
as,
for
example,
our
developers
decided
that
they
want
to
use
a
search
service
within
the
application,
and
that
search
service
was
very
easy
to
be
added.
The
communities
set
up
as
a
as
a
service
and
a
deployment
in
a
replica
set.
But
for
that
change
to
happen,
we
needed
the
true
wall
from
the
Ops
guys.
B
That
was
the
first
thing
that
we
realized
needed
to
do.
The
first
thing
was
that
we
need
to
have
a
multi
repository
approach
code
and
configuration
to
be
in
law,
step
together
without
the
approval
process
being
in
the
middle
of
the
way,
while
having
the
oversight
from
different
teams
to
make
sure
that
everything
goes
in
lockstep
and
nobody
can
break
the
vending
machine
they
won.
That
was
the
first
kind
of
thing
that
we
wanted
to
do.
The
second
one
that
we
realized
was
about
enforcing
conventions
and
standards
and
best
best
practices.
B
Some
of
those
conventions
that
we
have,
for
example,
are
around
naming
conventions
as
you
break
your
application
up
into
tens,
if
not
hundreds,
and
sometimes
thousands
of
micro
services.
How
would
you
configure
the
kubernetes
cluster
for
each
one
of
those
services?
Would
you
put
everything
in
one
file?
Would
you
create
a
split
them
based
on
the
type
of
services,
for
example,
right,
because
it's
on
one
side,
those
classes
on
another
file
that
deployments
on
another
file,
or
would
you
break
them
up
even
further
into
each
individual
deployment
or
each
individual
service?
B
And
then
how
would
you
go
about
naming
them
in
a
way
that
you
can
find
them
in
a
in
a
convention
based
way
and
also
how
would
you
know
how
what
there
was
the
application
order?
If
it's
not
a
same
file
a
lot
of
times,
we
construct
a
single
file,
that's
going
to
append
it.
Everything
is
appended
to
together
one
after
another,
and
then
we
can
then
apply
that
with
a
good
control
command
to
the
queries
cluster.
B
But
as
we
break
these
files,
apart
into
individual
parts,
individual
files
to
make
them
manageable
and
more
maintainable,
we
lose
the
cohesion
that
these
have
in
terms
of
the
order
that
would
apply.
So
that's
one
other
challenge
that
we
had
you
can
about
the
third
problem
that
we
had
to
think
about
was
secrets.
So,
ideally,
we
wanted
to
deal
with
deal
with
secrets
in
a
way
that
is
kubernetes
native.
We
know
that
kubernetes
has
a
two
sets
of
ways
of
injecting
configuration
into
application.
B
One
is
through
conflict
maps
which
is
non
secret,
configuration
key
value
pairs
and
the
second
one
is
secrets
and
both
of
them
are
treated
in
communities
the
same
way
they
they
are
applied
on
to
the
cluster,
either
through
command
line
or
a
configuration
file.
We
wanted
to
go
with
a
way
that
the
entire
application
can
be
deployed
from
its
one
file
or
a
set
of
files
every
time
in
a
reproducible
way.
B
B
We
couldn't
put
secrets
in
too
far
and
commit
them
into
a
source
control,
because
then
that
would
create
potentially
exposed
secrets
and
then
ways
around
that
where
you
can
replace
those
secrets
with
placeholders
and
then
use
other
stared
party
tools
like
stop,
for
example,
as
another
one
or
pull
it
out
of
the
vault
and
replace
them
at
the
end.
But
then
this
tool
chain
requires
to
be
built.
So
you
need
to
have
these
templates
weed
secrets
as
placeholders
and
then
have
a
secret
or
secure
server
somewhere.
B
That
will
then
pull
out
the
real
secret
and
put
it
into
the
file
and
apply
it
without
any
manual
intervention
or
anywhere.
That
is
some
some
eyes
conceal
secrets
and
they
get
leaked,
and
that
was
that
was
another
challenge
for
us
that
we
needed
to
need
to
overcome.
Sometimes,
we've
seen
that
secrets
are
committed
into
files,
but
the
files
are
then
encrypted,
which
then
takes
away
the
entire
benefit
of
using
git
and
diff,
and
the
version
control
for
those
files,
which
is
not
very
ideal
and
the
last
major
kind
of
challenge
that
we
had
was.
B
We
broke
our
mono-ethnic
application
into
multiple
micro
services
and
we
deployed
into
communities
and
everything
was
fun
and
we
kind
of
overcome
bunch
of
those
challenges.
But
then
we
realized
that,
as
the
complexity
of
application,
the
configuration
grows.
We
are
pushing
out
complexity
from
one
place
to
another,
namely
we
had
one
application
that
was
very
complex.
It
was
one
monolithic
application
of
a
very
big
beast
that
we
had
a
lot
of
complexity.
Inside
of
that
and
we
broke
it
apart
into
smaller
pieces,
which
was
great,
it
made
the
application
much
simpler.
B
The
tool
sets
to
manage
that
complexity
now,
I
have
to
say
that
managing
complexity
on
the
infrastructure
side
is
much
easier
than
managing
complexity
and
the
code
side,
and
the
reason
for
that
is
not
that
you
know
developers
we're
not
really
good.
It's
because
the
tool
tool
box,
the
tool
chain
and
tooling
that's
available
for
us
to
manage
complexity
on
the
infrastructure.
B
Chocolate
and
the
infrastructure
side
is
much
more
objective
and
much
more
available
and
widely
used
and
accepted
as
best
practices,
which
potentially
makes
admittedly
makes
the
entire
concept
of
DevOps
and
while
having
managing
complexity
on
the
code
side
is
a
very
subjective
thing
about.
You
know
the
cohesion
of
the
other
functional
the
complexity
of
the
method,
which
is
something
that
you
can.
You
can
argue
for
for
hours.
B
If
not
months
around
which,
by
which
ways
the
better
way
and
that
led
us
to
heavy
use
of
annotations
annotations
within
kubernetes,
so
every
asset
that
we
roll
out
or
have
to
be
annotated
in
specific
ways
and
then
specific
parts,
so
we
can
trace
every
asset,
but
there's
the
deployment
or
a
service
or
an
ingress
controller,
all
the
way
back
to
the
code.
Do.
Why
was
it
released?
When
was
it
released?
What
was
it
change?
B
Then
cells
now
Stenson's
are
like
templates
for
kubernetes
resources,
and
it
is
worth
here
for
me
to
you
convention,
another
CN,
CF
product
or
project
I
called
helm,
which
is
a
great
package
manager
for
for
kubernetes,
where
we
looked
at
and
used
initially,
and
we
still
do
useful
parts
of
it
and
then
I
kind
of
the
reasons
as
to
why
we
decided
to
do
stencils
instead
of
heavily
investing
on
Hell
itself.
So
the
first
thing
that
we
did
was
use
helm
for
everything
and
now
helm
for
those
who
might
not
be
completely
familiar
with.
B
It
is
the
package
manager
as
advertised
package
manager
for
kubernetes.
It
is
kind
of
like
NPM
for
nodejs,
but
for
communities,
or
you
know,
ruby,
gems
or
google
get
things
like
that.
Where
you
can,
you
have
vendors
who
software
developers
we
package
things
into
these
helm,
charts
and
then
you
can
then
do
a
helm
chart,
install
and
use
it
on
your
greatest
cluster.
The
first
thing
that
we
saw
was
as
advertised
helm
is
a
package
manager
and
we
don't
install
our
application
with
NPM
or
we
don't
install
our
application.
We'd
go
get.
B
We
use
NPM
package
manager
for
node
or
ruby
gems
for
Ruby
rails
or
go
get
Wayne
windows
and
got
networked
nuggets
for
packaging
dependencies
of
the
application
during
development.
But
when
it
comes
to
deployment
there
are
the
tools
that
we
used
to
deploy,
ie,
compile
obfuscate,
encrypt
and
scan
for
security,
vulnerabilities
rollout
in
terms
of
the
rollout
or
the
deployment
steps.
These
migrations
that
could
go
potentially
out.
You
know
a
B
rollout
canary
releases
and
all
sorts
of
things
that
come
different
methodologies
and
paradigms
of
deployment
that
we
wanted
to
make
sure
that
we
can.
B
We
can
do
and
we
can,
you
can
benefit
from,
and
the
package
manager,
just
by
definition,
there's
not
necessarily
something
that
you
want
to
you
want
to
have
you
want
to
overburden
with
all
these
functionalities
and
features?
That
was
the
first
reason
that
we
we
thought
about,
started
thinking
about
having
stencils.
B
Artifacts,
like
HTML,
for
example,
or
for
rendering
web
pages
and
kind
of
the
tools
are
not
necessarily
fit
for
purpose,
though
stencils
deliberately
don't
have
flow
controls
and
look
much
more
simpler
and
they
also
understand
the
paradigms
of
deployments
to
communities.
The
second
tool
that
we
built
and
the
open
source
is
called
copper,
which
is
a
communities
configuration
validator
where
we
wanted
to
make
sure
that
we
have.
We
give
access
to
the
vanilla
upstream
API
of
kubernetes
to
our
developers
where
they
can
do
whatever
they
want
to
do
and
they
can
use.
B
You
know
the
communities
that
overflow
or
everywhere
they
go
and
research
the
problems
they
have
and
they
can
apply
those
solutions
to
to
the
kubernetes
cluster.
They
have.
Obviously
we
are
back
on
top
of
it,
but
we
wanted
to
make
sure
that
they
we
don't
have
to
wrap
kubernetes
api
in
yet
another
api
to
just
restrict
down
and
make
sure
nobody
breaks
down
the
name
machine
by
having
some
sort
of
unit
test
for
the
configuration
file.
So
we
would
allow
developers
to
write
the
configuration
file.
However
they
want,
but
then
they
would
apply.
B
Copper
rule
files
to
this
to
highlight
things
that
are
that
should
be
stopped
or
things
that
need
a
an
ops
person
to
come
and
verify
and
validate
before
we
can
apply
to
this
class.
So
with
all
that,
build
up
I
wanted
to
show
you
a
demo
of
what
we've
built
and
assembled
them
off
a
single
page
application
with
a
single
service
that
need
deploy
equipment.
It
is
cluster
using
stencils.
Hopefully
it's
going
to
be
adding
a
little
bit
more
color
into
what
I
said
about
the
tools
that
we
had
to
build.
The.
B
Let
me
switch
over
to
skycap
dashboard,
though
skycab
has
a
concept
of
an
application,
and
I
can
start
using
that.
So
I
start
a
new.
What
we
call
an
application,
I
give
it
a
name
here.
I
can
just
add
services
to
this.
So
if
my
application
consists
of
like
another
10
micro
services,
I
can
just
add
them
one
by
one
here
or
I
can
add
them
as
a
yamo
file,
which
looks
very
much
like
a
docker
compose
file
here,
if
I
want
to
or
you
can
use
the
command
line.
B
If
you
want
to
delivers
more
power,
but
the
simplest
way
is
to
just
simply
use
the
UI
and
give
you
a
service
a
name
and
bring
it
in
now,
you
can
have
each
service
come
from
different
places.
You
can
get
it
from
a
git
repository
where
skycap
pulls
out
the
code
builds
it
for
you
and
then
the
artifact
is
then
pushed
to
a
private
repository,
all
of
it
provided
by
by
skycap.
But
you
can
bring
your
own
requester.
If
you
want
to,
you
can
build
it
on
your
own
machines.
B
If
you
want
to,
or
you
can
simply
just
choose
to
deploy,
it
read
stalker
image,
whether
it's
a
after
shelf
Gawker
image
or
some
other
attacker
image
that
your
CI
CD
tool
might
build
as
part
of
your
pipeline
here,
I'm
just
going
to
choose
one
or
three
that
we
have
is
a
simple
hello
world
application
written
and
go
with
a
little
bit
of
HTML
I'm,
just
gonna
paste.
The
repository
used
master
as
the
as
the
branch
and
click
go
so
what's
happening.
Now
is
just
skycaps
going
to
pull
out
the
code.
B
Have
a
look
at
it
always
found
the
docker
file
great,
so
it
will
be
able
to
build
it,
and
I'm
gonna
click
this
now,
while
this
is
being
built,
I'm
just
going
to
go
to
the
application
and
show
you
there,
it's
a
very
simple:
go
application
if
you're
familiar
with
go,
it
does
nothing
very
fancy.
It
just
serves
a
web
server
on
four
to
five
thousand
and
then
serves
a
webpage.
That's
that's
out
there
with
a
bunch
of
Jas
and
CSS,
and
the
taça
file
that
it
has
is
again
is
a
very
simple
one.
B
It
uses
the
native
go
Lang
official
base
image,
it
does
take
the
dependencies
off
the
web
and
runs
the
build
on
the
machine
on
the
inside
of
the
container
itself,
and
then
you
can
just
run
it
so
here
the
application
now
is
created.
It
has
the
web
service
as
we
defined
it,
but
no
snapshots
have
been
taken.
Ie
no
image
has
been
built,
so
the
first
thing
I
do
is
I.
B
Just
click
on
snapshot
and
what
this
is
going
to
do
is
going
to
pull
down
my
code
run
it
on
what
we
call
build
grid
and
then
generate
this
now.
This
is
all
available
on
fastest
comm,
which
is
a
SAS
service.
You
can
just
sign
up
for
it
and
use
it,
but
this
is
also
available
as
it's
download
and
it's
a
untrimmed
solution
as
well.
B
It's
just
for
finishing
off
the
last
parts:
okay,
great
now
I
have
a
choice
of
how
I
want
to
deploy
it
when
I
set
up
deployment,
I
can
deploy
bit
maestro,
which
creates
a
kubernetes
cluster
for
you
on
any
cloud
or
bare
metal,
and
you
can
just
simply
deploy
the
entire
application
onto
that,
but
today
I
wanted
to
show
you
the
stencils
and
formations.
So
let's
just
do
this,
but
when
I
go
to
formations,
I
can
create
multiple
formations
here
now.
B
B
Some
companies
have
a
little
bit
more.
Some
companies
have
a
little
bit
less,
but
usually
it's
not
more
than
six
or
seven
and
I.
Very
rarely.
We
get
to
about
ten
environments
for
an
application,
but
with
an
aim
of
being
able
to
deploy
the
entire
stack
end-to-end
with
a
with
a
single
file,
and
not
only
that
multiple
of
those
instances
of
application
on
a
single
cluster.
We
realized
that
either
the
concept
of
an
environment
is
not
going
to
cut
it
anymore.
B
Sometimes
you
want
to
have
the
entire
application
deployed
with
specific
features
hidden
or
as
a
canary
release
somewhere.
So
you
know
some
of
your
customers
can
see
it
when
you
climb
right,
gonna
sign
off
on
it
and
you
call
that
a
formation
as
well.
This
is
what
we
call
formations
so
I'm
going
to
go
to
formations,
I'm
going
to
call
it
nonfiction.
B
Now
here
we
have
a
repository
for
the
stencils.
Now
these
are
the
two
that
are
connected
through
my
formations.
The
base
template
essentially,
is
a
git
repository,
whether
with
a
sample
of
how
every
asset
within
communities
has
to
be
configured
and
I'll,
show
you
that
in
a
minute,
I'm
going
to
use
one
that
I
have
here
and
I'm
going
to
save
this
formation
now
before
I
create
any
stencils.
Let
me
show
you
what
that
Beach
template
repository
and
look
like.
B
Base
template
repository,
so
the
way
it
is
is
it's
a
normal
get
repository.
It
has
one
file
the
metadata
file
called
templates
JSON,
where
it
has
metadata
around
each
file,
that's
available.
But
when
you
look
at
every
of
one
of
those
files,
it's
a
communities,
normal
communities,
configuration
file
with
the
difference
that
it
has
these
placeholders
that
are
that
I'll
fill
that
and
that's
what
a
base
template
for
stencil
is,
for
example,
my
Ops
guys
want
to
make
sure
that
every
time
I
create
a
new
namespace.
B
It
is
annotated
with
this
annotation,
so
they
make
sure
of
that
or
they
want
to
make
sure
that
every
time
I
deploy
a
service.
My
service
is
named
as
such.
There
are
some
specific
things
that
should
be
there
or,
for
example,
they
want
to
make
sure
that
I
don't
forget
to
specify
the
ports,
the
internal
and
external
port
of
my
service,
so
they
put
this
placeholder
call
require,
which
will
then
stop
the
deployment
operation
if
I
fail
to
provide
this
value
and
I'll
show
you
this
in
action.
So
now
that
I
have
my
formation.
B
Let
me
add
my
first
stencil
right,
so
my
first
stencil
comes
from
this
set
of
base
template
stencils
that
I
have
connected
to
this
I'm,
going
to
start
with
a
setup.
Obviously,
I
need
a
namespace,
so
this
pulls
down
my
base
template
for
setup
for
every
namespace,
and
this
part
is
just
the
simple
communities
namespace
that
I
have
with
with
the
annotations
that
that
my
team
requires
as
a
convention,
and
the
second
part
is
interesting
because
this
as
the
darker
registry
credentials
to
my
namespace.
B
So
all
the
images
that
I
have
hand
login
all
the
parts
can
login
to
my
decorations
tree
and
pull
the
images
down.
As
you
can
see,
we
have
placeholders
like
registry
credentials,
which
then
just
understands
how
you've
connected
your
skycap
to
a
docker
registry.
How
kubernetes
consumes
those
secrets
and
all
the
sort
of
things
around
that
this
is
all
backed
by
a
git
repository
itself.
So
you
can
pull
these
out
on
your
favorite
browser
and
sorry
favorite
text
editor
and
then
with
a
good
client
without
having
to
go
through
UI.
B
B
B
So
there's
a
require
that
if
I
forget
to
do
this,
when
we
get
to
the
rendering
part
what
we
call
rendering
this
permission,
then
soul
into
a
kubernetes
configuration
file,
a
fully
fledged
kubernetes
configuration
file.
This
will
stop
and
show
up
as
red.
So
we
don't
need
to
fill
it
out.
I
believe
this
application
runs
on
towards
8080
if
I'm
not
mistaken.
Oh
sorry,
5,000!
B
B
B
B
Service
again
is
a
normal
vanity
service
for
the
external
port.
I'm
gonna
use
port
80
for
the
internal
poll
of
the
state
was
5,000.
I
think
the
rest
can
be
left
out
again.
You
see
that
the
naming
convention
is
the
name
of
service
with
SVC,
because
that's
what
is
the
convention
within
our
team
and
we
can
be
enforced
now
we
can
delete
these
if
you
want
to
and
it's
this
is
going
to
still
work,
there's
nothing
wrong
with
that.
B
If
you
want
to
make
any
changes
in
the
base
template,
you
can
do
it
here
or
you
can
do
it
in
the
base
itself.
So
it's
applicable
to
everything.
But
if
you
do
this,
and
if
it
is
something
that's
mandatory
by
your
team
or
by
your
development
manager
or
outside,
then
they
will
have
policies
written
to
ensure
that
these
things
present
are
present
in
your
configuration
file
and
it
will
stop
the
deployment
because
those
policies
are
not
met
and
those
are
forcibly
cut
by
which
we
can
get
into
the
later
service.
B
Okay,
so
now
I
have
my
namespace
a
deployment
and
my
service
now
remember
that
we
were
talking
about
how
the
concatenation
of
these
files
work
in
in
once
when
it
comes
to
rendering
a
single
file
that
can
be
applied
to
kubernetes,
but
here
I
can
just
drag
and
drop
these
to
make
sure
that
service
gets
created
before
the
deployment
or
deployment
before
the
service.
So
I
can,
or
you
know,
namespaces
after
all
of
them,
which
is
not
quite
right.
Obviously,
you
want
to
have
the
namespace
before
everything
else
and
you
know
commands
being
commanded.
B
Is
it's
not
going
to
break
anything?
We
can
apply
everything
twice
when
we
run
it.
If
the
communities
doesn't
have
the
namespace
at
the
beginning,
we
can
run
it
again
and
the
next
time
we'll
have
it,
but
we
just
want
to
make
sure
that
it
works
the
first
time.
Then
we
put
it
in
the
right
order
and
that's
basically
what
we
want
and
I
can
then
render
this
formation
or
force
me
to
click
on
this.
Here
has
a
guide,
and
here
you
see
that
we
have
the
father
ended
with
all
the
values
filled
out.
B
Following
my
conventions
now,
what
I
can
do
here
is
I
can
download
each
individual
file
or
select
a
subset
of
them
and
download
them
as
one
file,
but
easier
than
that.
We
can
use
the
command
line
that
we
have
so
I'm
going
to
copy
the
command
line
couch
over
to
my
terminal.
So
if
I
have
a
crew
control,
I
haven't
accumulated
many
crew
running
on
my
local
machine
here,
which
is
think
if
I
run
this
command
and
all
I
need
to
do
is
now
just
select.
B
B
B
Well,
then,
open
up
the
browser
and
there
we
go
so
it's
now
deployed
all
it
took
for
me
to
deploy
one
service.
Obviously,
it's
a
simple
application.
It's
a
single
service
application,
but
you
saw
how
easy
it
is
to
create
a
service
from
source
code.
Compile
it
push
it
into
the
repository
generate
the
configuration
files
for
communities
for
it
and
and
deploy
it
to
in
communities.
Cluster
I
can
simply
just
switch.
My
communities
accrue
control
to
a
different
class
than
with
a
company
use
context.
B
Another
cluster
that
I
want
and
by
that
I
can
then
apply
the
same
command
and
deploy
the
same
application
somewhere
else
in
another
cloud
or
another
competitors
cluster.
That
I
want
there's
a
lot
more
instances
around
secret
management,
different
versions,
a
tagging
of
existing
images
to
be
deployed
with
the
same
tag
as
with
my
build
applications
having
actions
that
you
want
to
happen
at
the
every
deployment
like
it
was
migrations,
for
example,
or
other
things
around
having
creating
subsets
of
your
entire
application
that
you
just
ran.
B
It's
very
cool
I
think
it's
very
useful
for
a
lot
of
us
that
we've
met.
So
one
of
the
things
that
we
see,
for
example,
is
that
we
want
to
ban
use
of
the
latest
tag
on
the
images
that
you
see
on
committees,
contribution
files,
because,
obviously
that's
not
best
practices.
You
don't
know
what
you're
getting,
which
my
version
is
coming
down,
and
sometimes
you
could
don't
have
a
policy
of
image
pool.
B
Always,
for
example,
you
might
have
a
stale
image
because
it's
still
called
natures,
and
for
that
this
is
a
simple
DSL,
domain-specific
language
that
copper
will
understand.
It
can
create
a
file,
call
it,
for
example,
no
latest
cop.
They
can
write
this
in
it
and
then
it
would
apply
that
to
a
company's
configuration
file.
As
you
can
see
here,
it's
adjacent
path
that
will
go
and
fetch
the
all
the
image
names
within
that
is
confined
within
my
configuration
file.
Then
it
will
look
that
image
names.
B
We'd
understand
that,
for
example,
if
you
don't
have
a
tag
then
its
latest,
if
you
don't
have
any
posture,
then
you
stock,
a
hub,
then
pick
the
tag.
So
it
understands
those
intricacies
of
syntax.
Then
if
it
says
contact
its
latest,
then
it
fails
this
rule
and
the
rule
is
of
type
ensure.
So
it
will
stop
the
deployment
you
can
have
it
integrated
in
your
CI.
Cd
skycap
has
support
for
this
in
a
native
way.
B
You
can
also
do
other
things
like
I
want
to
have
minor
upgrades
of
one
of
the
components,
not
a
major
one,
so
it
will
go
and
pick
up
the
version
of
your
image.
For
my
sequel.
It
would
pick
it
and
understand
semantic
versioning
and
says,
with
versioning
condition,
check
that
it
can
only
go
get
upgrade
from
five
point.
B
For
example,
you
want
to
make
sure
that
if
you
have
a
deployment
in
the
file
name,
then
your
file
name
should
be,
should
have
the
word
file
name
in
it,
and
the
extension
should
be
yml,
for
example,
not
like
a
ml
or
something
else,
or
you
want
to
make
sure
that
the
IP
address
for
load
balancers
within
the
range.
So
you
know
by
mistake:
it
doesn't
get
changed,
for
example,
or
the
namespace
is
always
something
not
the
default.
B
One
by
mistake,
you
can
want
to
make
sure
that
you
don't
pull
images
from
docker
hub,
for
example,
or
you
always
want
to
make
sure
that
no
image
is
pulled
from
a
anywhere
except
for
your
private
registry.
These
are
some
examples
of
things
that
you
can
do
with
with
copper,
and
you
probably
want
to
write
some
of
those
examples
and
share
with
others
as
well.
But
you
might
you
know
you
won't
want
to
use
this
as
part
of
your
your
tool
chain,
it's
very
easy
to
use
as
well.
B
You
can
just
write
the
file
and
then
do
a
cup
of
check
with
the
file
and
the
copy.
We
should
follow
that
want
to
check
and
it
will
give
you
a
pass
or
fail
and
that's
pretty
much
it
as
I
said,
with
formations
in
class.
This
is
skycap.
There
is
a
native
support
for
or
for
stencil
under
policies.
You
can
just
enter
your
copper
files
right
here
and
you
can
see
where
they
apply
to,
for
example,
to
state
kind.
B
B
You
know
how
we
use
this
if
you
can
find
or
think
of
any
other
tools
that
could
be
complementary
to
this
or
even
replace
these
ones
would
love
to
hear
that
and
talk
about
it
and
can
see
how
we
can
improve
this
either
product
or
our
best
practices
and
workflow,
as
it
was
the
collective
to
move
adoption
of
kubernetes.
Thank
you
very
much
for
your
time.
Well,.
A
Thank
you,
cash
for
taking
the
time
to
share
this
with
us.
I
mean
copper,
sounds
like
it
and
I
hadn't
heard
about
it
until
you
did
today's
presentation
so
now,
I'm
gonna
have
to
go
back
and
dive
into
that
a
little
bit
more
and
a
little
bit
more
deeply.
It's
wonderful!
When
these
things
are
out
in
the
open
source.
A
B
Know
that
complementary
to
those,
so
what
we
actually
do
ourselves
is,
we
do
use
help
ourselves
as
well.
We
we
use
helm
for
off-the-shelf
things
that
we
get.
For
example,
if
you
want
to
have
Redis
as
a
component
of
an
application
deployed,
we
usually
headed,
have
the
Redis
helm
chart
because
it's
written
by
people
who
know
how
to
run
operate,
for
example,
ready,
go
DB
or
rabbitmq
on
kubernetes
best,
and
they
can
do
a
much
better
job.
B
B
Sometimes
we
see
that
you
know
just
give
you
an
example
about
operators,
for
example,
admission
operators
that
we
use
for
immutable
web
hooks
where
we
want
to
inject
something,
has
a
sidecar
into
every
part
when
I
think
believe
we
use
it
first
year
and
you
want
to
have
you
know,
traffic
management
making
sure
that
traffic
to
every
service
Christie?
Oh,
we
so
used
those
instead
of
going
around
and
changing
every
single
configuration
file.
So
we
use
you
know,
operators
for
that.
B
For
that
purpose,
tencel's
is
very
much
about
a
repeatable,
auditable
and
traceable
way
to
generate
configuration
files
because,
regardless
of
whether
you
use
operators,
you
don't
know,
use
operators,
we
use
sidecar
that
we
don't.
You
know
we
use
our
backup,
we
don't
want.
Hopefully,
everybody
uses
our
back.
B
We
always
need
to
finally
build
configuration
files
and
apply
them
through
the
cluster,
whether
it's
to
deploy
the
operators
or
whether
it's
to
deploying
the
application
itself
or
even
change
the
are
back
settings.
So
the
good
thing
about
committed
is
that
always
works
off
of
a
configuration
file,
one
or
more
configuration
file,
and
that's
the
best
way
to
use
it.
Obviously,
my
own,
as
well
as
anybody
to
go
and
create
you,
know,
secrets
or
contribution
files
using
coop,
coop
controllers
command
lines.
B
A
A
Think
what
we're
all
going
to
do
is:
go
back
and
watch
this
video
again
so
that
we
can
get
some
of
the
nuances,
because
I'm
really
interested
to
see
see
how
this
works
out
deploying
on
OpenShift
as
well.
He
said
you
had
done
this
on
gke
and
I'm
curious
to
see
if
anyone's
using
it
in
relationship
to
with
OpenShift.
Yet
so.
B
B
You
probably
you
don't
have
a
little
I
mean
you
definitely
don't,
have
a
little
tensor
on
your
on
your
machine,
and
so
you
don't
want
to
have
a
service,
that's
exposed
as
a
balancer,
so
you
can
create
that
tiny
variation.
While
you
de
for
the
same
thing
to
say
you
know,
AWS,
you
wanna
have
it
as
load
data,
so
you
want
to
deploy
two
OpenShift.
You
just
deal
with
it
slightly
differently.
So
there's
some
very,
very
minor
variations
that
you
can
create
in
that
one
example
that
we
ran.
B
A
You
know
so,
hopefully
you
can
get
some
feedback,
some
of
the
open
ship
users
and
you
know,
maybe
have
a
demo
of
someone
using
it,
live
in
production
on
open
ship
sometime
in
the
not-too-distant
future,
and
I
mean
the
folks
a
number
of
the
folks
that
are
on
our
our
heavy-duty
Jenkins
middleware
people
from
Red,
Hat
and
so
they're,
they're,
quite
interested
in
in
copper
and
another
bits
that
you've
done
so
I.
Guess
we're
going
to
have
you
back
a
few
more
times.
So.
A
B
I
mean
definitely
one
thing
about
Jenkins,
then
and
and
copper
itself.
We
also
have
another
open
source
project
that
we
see
a
lot
of
users
with
Jenkins
is
called
habitus.
You
can
find
in
inhabitance
io
I'm
just
going
to
type
it
in
the
chat
and
we'll
share
it
with
you
as
well,
and
it's
a
what
do
you
thing?
Is
it's
a
it's
a
workflow
build
workflow
for
docker
and
you
might
you
basically
can
build
a
cascade
of
buildings
that
one
and
then
step
two
and
step
three,
but
it's
more
that
it
goes
beyond
that.
B
B
Making
the
image
is
smaller
and
the
second
thing
it
does
that
it
allows
you
to
inject
secrets,
serve
secrets
during
the
build
time
padalka,
and
this
is
very
useful
when
you
have
private
git
repositories
or
private
repositories
that
are
dependencies
of
your
build
time.
For
example,
you
have
a
dependency,
that's
in
a
private
repository.
B
You
need
to
have
these
private
SSH
key
to
access
it
or
a
secret
commercial
enterprise
version
that
you
need
some
sort
of
key
to
access
it,
and
you
don't
want
to
build
that
into
the
image
because
it
is
going
to
be
there
forever
and
my
potentially
leak
it
out
into
partner.
They
will
allow
you
to
do
it
in
secret
in
a
safe
way.
I'll
encourage
you
to
check
that
out
as
well.
It's
again
open
source
and
it
would
be
very,
very
useful
for
anybody
who's
using
Jenkins
in
Java
or
go
any
compiled
language
perfect.
A
Well,
we'll
definitely
give
you
some
feedback
on
that.
I
can
tell
you
and
we'll
take
a
look
at
that
as
well,
and
hopefully
we
can
get
some
collaboration
going
with
you
on
those
two
open
source
projects
and
work
through
ya
users
and
some
of
this
and
other
workflows
as
well.
So,
thanks
again
and
we'll
put
this
all
up
on
YouTube
on
the
RH,
openshift
channel
and
it'll
get
up
into
the
wild,
and
hopefully
we
can
get
you
some
feedback
on
all
of
this
from
our
community.
Thank
you.
Definitely.