►
From YouTube: Webinar: Solving Configuration, Security and Collaboration Challenges in the Container Pipeline
Description
Moving a monolith application to run on Kubernetes was not the biggest challenge we faced when we moved Cloud 66’s stack to run on containers. We realized we have to change the way we think about pipelines, security, managing environments, and configuration to truly benefit from this move and keep the pipeline—and the clusters—in lockstep with code. In this webinar, we will share what we’ve learned so far, and some tooling we’ve developed to solve our problems—which are now open sourced.
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 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.
Join us for KubeCon + CloudNativeCon in San Diego November 18 - 21. Learn more at https://bit.ly/2XTN3ho. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy and all of the other CNCF-hosted projects.
A
Welcome
everyone:
my
name
is
yaara
wretzky
I
am
a
developer
advocate
at
a
cloud
native
computing
Foundation,
and
today
we
have
our
regular
CNC
of
webinars
to
happen
in
every
Tuesday.
Exactly
this
time
today
we
have
the
special
guest,
sir
Jerry
will
present
about
moving
to
kubernetes
and
share
some
insights
on
solar
and
configuration
security
and
collaboration
challenges
in
the
container
pipeline
go
ahead.
B
B
Is
you
can
imagine
we
as
a
company?
That's
four
or
five
years
old?
We
had
this
stack
all
set
up
on
AWS
running
on
ec2
s3,
the
normal.
You
know
the
usual
suspects
of
the
cloud,
and
this
was
delivered.
Our
service
was
delivered
as
a
service
on
the
web.
When
you
go
to
galaxies
calm.
This
was
working
perfectly
fine.
We
had
a
very
good
record
of
uptime.
We
had
a
track
record
of
delivering
around
probably
two
or
three
times
a
day
on
on
minor
releases
and
once
a
week
on
major
releases.
B
So
we
had
a
good
flow
of
everything
that
was
going
on
and
we
decided
to
move
this
to
kubernetes
for
support
for
different
reasons.
So
this
is
what
our
stack
used
to
look
like
now.
The
reason
there
are
so
many
colors
in
is
to
celebrate
that
necessarily
didn't
want
to
try
and
see.
If
what
what
color
combinations
I
can
use
it's
to
show
how
many
different
different
server
types
we
had
on
our
stack.
So
at
the
top
you
have
the
usual
in
al
de
lb
load
balancers.
That
Amazon
provides
you
and
then
at
the
bottom.
B
You
have
the
type
of
service
that
we
had
at
the
very
bottom
of,
though,
that
the
lower
square,
our
economy,
we
have
the
databases
and
this
persistence
or
services
that
we
had
so
my
sequel,
radius,
memcached,
influx,
TV
and
RabbitMQ
are
the
persistent
or
services
that
we
provide
and
we
use
within
the
application.
But
with
the
application
stack
itself,
we
had
five
or
six
different
types
of
servers
that
we
had
to
provision.
B
Every
time
said
a
bunch
of
web
servers
for
obvious
reasons
where
they
were
serving
three
types
of
traffic:
the
Web
API
and
our
admin
API,
which
is
something
that
we
use
internally
through
a
VPN
to
add
for
administration
purposes.
Think
of
it
as
a
management
that
work.
Then
we
have.
We
provide
get
services
to
our
customers.
So
there
was
a
good
server
for
a
cluster
of
good
servers.
I
should
say
we
have
we
collect
metrics
and
vital
signs
of
the
service
that
we
manage
for
our
customers.
So
those
metric
servers.
B
We
have
a
bunch
of
services
that
communicate
over
TCP,
so
they're,
not
traditional.
You
know
layer,
seven
web
HTTP
servers
and
those
are
used
for
various
different
purposes:
I'm
boxed,
all
of
them
into
one
TCP
in
Rio,
in
Rio
em
in
the
real
world,
the
the
Box
in
the
top
right,
the
TCP
server
in
in
reality,
it's
actually
about
three
or
four
different
types
of
server,
and
then
we
have
a
bunch
of
backgrounds
every
worker.
B
So,
as
you
can
see,
we
had
all
these
different
types
of
servers
that
we
had
each
one
being
an
AC
tube,
a
template
that
would
fire
up.
We
would
scale
them
from
that
type,
and
the
first
issue
that
we
had
around
this
was
was
about
something
of
an
issue
of
like
a
collective
collective
picture
that
you
couldn't
take,
and
the
image
is
where
that
had
that
issue.
The
first
issue
was
that
we
would
take
these
images
off
of
warriors.
B
So
we
can
fire
up
another
web
worker
server
later
on
and
by
the
time
we
were
firing.
It
up
that
image
was
already
out
of
date:
either
we've
updated
something
or
an
upstream
package
was
updated
or
there
was
a
security
vulnerability
found
in
its
week.
Our
job
ended
up
being
updating
those
images.
Now,
admittedly,
we
don't
have
hundreds
of
types
of
servers
and
100
types
of
images
by
as
a
consequence,
but
still
there
was
a
painful
process.
B
So
we
thought
about
this,
and
then
we,
you
know
as
a
company
that
provides
containerization
and
community
services.
Naturally,
we
had
to
move
our
own
stack
to
to
run
on
kubernetes
as
well.
So
this
is
what
we
wanted
to
build.
Ideally
with
is
what
we
wanted
to
build.
We
wanted
to
have
all
uniform
nodes,
doing
whatever
the
containers
inside
them
world,
but
from
outside
that
will
look
the
same.
There
is
no
taking
up
images.
B
We
have
different
types
of
load
balances
depending
on
the
traffic
type,
whether
is
level
4
level
5
at
level,
4
level,
7
and
different
ones,
and
and
hopefully
will
have
everything
in
the,
including
my
sequel
and
memcache
key
and
everything
else
that's
there.
So
that
was
the
ideal
stack
that
we
wanted
to
build.
We
set
out
to
build
this.
B
The
first
challenge
that
we
had
was
around
databases
and
persistent
storage
in
in
general.
The
first
realization
we
had
around
databases
was
that,
while
we
deploy
our
code
about
maybe
three
four
times
a
day,
we
wanted
to
ID
Liam.
Do
it
more
often
the
last
time
we
deployed
our
databases
in
bumped
up
the
version,
for
example,
or
change
anything
around
our
database.
B
B
Would
be
something
that
is,
you
know
when
it
runs?
If
there's
a
if
there's
an
issue
with
the
online
survey
can
be
moved
somewhere
else
with
databases,
we
would
benefit
from
that.
But
realistically
we
were
running
our
databases
on
Amazon,
RDS
or
other.
You
know
the
database
or
or
infrastructure
as
a
service,
essentially
components
that
were
provided
to
us,
so
we're
not
getting
that
much
of
a
mileage
out
of
of
using
databases
in
containers,
but
we
still
try
to
experiment
with
that.
B
The
biggest
issue
that
found
was
while
we
had
good
practices
around
making
sure
our
schema
is
backward
compatible
and
we
don't
ever
break
our
application
with
a
but
a
database
change,
and
we
could
keep
that
the
entire,
the
entire
containerization
if
a
database
did
not
really
fit
well
with
our
deployment
strategy,
we
had
to
technically
say
some
of
our
databases.
Some
of
our
containers,
which
contain
databases,
are
special,
that's
special
and
are
different
from
the
rest
of
them.
We
wanted
to
avoid
that
as
much
as
possible.
B
We
set
out
to
remember
we
set
out
to
do
this,
to
make
sure
that
none
of
the
servers
are
special.
All
of
them
are
uniform
and
all
of
a
sudden,
we
had
to
treat
some
of
the
containers
now
as
a
special
and
by
especial
I
mean
they
shouldn't
be
deployed
every
time,
because
you
want
to
database
to
be
always
up
to
date.
There
are
always
up
they,
preferably
couldn't
couldn't
move
even
with
the
best
storage
underneath
there
either.
B
What
there
were
hiccups
around
access
to
database
when
a
container
providing
the
database
moves
from
one
one
node
to
another,
so
we
had
to
pin
them
down,
which
means
that
Jen,
you
have
a
single
point
of
failure.
So
the
first
thing
that
we
realized
is
that
we're
not
going
to
take
our
databases
into
containers,
we
left
them
outside
and
we
still
carried
on
using
the
database
card
and
I'm
using
the
word
database
in
a
general
way
for
anything.
Persistent
stateful,
including
rabbitmq,
for
example,
and
we
kept
them
outside
as
services
provided.
B
The
second
part
that
we
found
challenging
we're
around
secrets.
So
traditionally,
what
we
do
is
we
put
the
secrets
around.
You
know
credentials
to
database
access
or
API
keys
to
any
service
that
our
application
use.
We
would,
we
would
put
them
inside
the
configuration
of
application
now
that
is
encrypted,
and
it's
not
committed
into
the
git
repository
it's
coming
from
outside.
We
had
some
something
very
similar
to
a.
She
cops
vault,
for
example,
built
a
long
time
ago.
B
We
called
it
secret
service
and
what
it
does
is
that
it
provides
secrets
to
the
application
in
a
short
time
window
when
the
application
starts
up,
and
we
wanted
to
move
that
over
to
kubernetes
world
and
use
it.
But
we
also
wanted
to
use
communities
native
secret
management,
the
config
manage
config
maps
and
secrets,
and
what
that
meant
was
that
we
had
to
put
our
secrets
into
config
kubernetes
configuration
files
and
commit
them
into
git.
B
Now,
you
might
say
you
don't
have
to
commit
those
files
into
git
repositories
or
you
can
commit
them
into
a
git
repository,
but
they
can
be
encrypted.
And
if
you
look
at
a
configuration
file
for
for
communities
for
secrets,
you
see
that
it
is
a
key
value
pair.
Essentially,
the
key
is
a
secret
name.
The
value
isn't
encrypted
or
unencrypted
a
value
for
the
secret,
and
in
theory
we
could.
We
could
have
left
those
files
outside
of
a
version
control,
but
the
issue
with
that
is
first
of
all:
it's
not
ideal.
B
Then
you
have
to
store
it
somewhere
because
obviously
do
and
the
second
part
is
it's
usually
secrets
and
applications
work
in
lockstep.
You
know
when
you,
when
you
have
a
new
API
service,
that
you
start
using.
You
want
to
add
the
secrets
to
it
address.
Add
the
API
keys
to
the
secrets
file
at
the
same
time,
and
you
want
those
to
go
out
at
the
same
time.
B
We'd
add
to
shopping
your
service,
so
we
had
to
have
them
in
some
sort
of
source
code
repository,
even
if
it
was
not
the
main
source
code
repository
of
our
application,
and
that
meant
how
the
issues
that
we
had
with
that
was
around
what
we
going
to
do
with
access
right
to
get.
What,
if
somebody,
you
know
just
commits
the
the
secrets
in
plain
text
into
the
into
the
good
repository
by
mistake,
I
forgets
to
encrypts
them.
We
had.
B
Clearly
we
didn't
develop
a
team,
especially
now
with
gdpr,
that
we
need
to
have
know
exactly
who's
got
access
with
what
we
needed
to
know.
We
needed
to
make
sure
that
production
secrets
are
only
accessible
in
very
few.
While
you
know
staging
and
test
environments
potentially
have
access
I
accessed
by
by
more
people,
so
the
gates
based
encrypted
of
secret
code
management
files,
solutions
didn't
really
work
for
us.
Another
thing
was
we
wanted
to
concept
of
the
right
only
access.
B
We
realized
that
that's
it's
really
necessary
thing
for
us
to
have,
and
by
that
what
I
mean
is
as
a
developer.
If
I
go
and
add
a
new
service
or
I
want
to
make
a
change
to,
for
example,
a
the
way
a
one
of
my
services
consumes.
A
secret
I
might
want
to
be
able
to
add
this
new
service
and
add
the
secrets
that
I
want
into
the
right
place,
which
is
the
community
secret
file,
but
necessarily
I,
don't
need
to
have
or
shouldn't
have
access
to
the
actual
secrets
themselves.
B
So
it
ended
up
being
something
like
a
writer
only
access
where
I
can
modify
the
secret
files
as
to
add
a
new
one
or
or
redirect
a
secret
from
another
place,
while
I
don't
have
access
to
seeing
the
secrets
themselves
or
what
other
secrets
are
available
for
me
to
see,
even
if
they're
encrypted,
and
that
was
a
challenge
for
us
another
concept
that
we
started
to
kind
of
struggle
with.
Where
were
environments?
B
Now
you
know
all
of
as
a
software
developers,
the
familiar
with
environments
like
staging
like
test
QA,
you
know
production,
but
one
of
the
things
that
started
to
show
up
quite
often
for
us
was
the
fact
that
we
ended
up
firing
up
the
entire
stack
on
kubernetes
with
the
same
environment
multiple
times.
An
example
is,
if
you
have
a
SAS
business
like
us,
and
you
want
to
start
selling
it
on
trim,
then
what
is
the
difference
in
terms
of
the
environment
between
your
SAS
version
and
the
one
that
you
sell
to
your
customer
on
Prem?
B
They
could
both
be
production.
So
now
you
have
two
production
environments,
but
they
have
different
configurations,
for
example
the
endpoints
that
they
get
things
from
or
the
API
keys
that
they
use
are
potentially
different,
they're,
not
using
going
to
share
the
same
secrets.
Same
endpoints
same
configuration
parameters
of
your
SAS,
so
you
have
two
production
environment
with
different
configuration
files
or,
alternatively,
you
might
have
a
case
of
wanting
to
have
multiple
stagings
based
on
different
branches
or
different
features
that
you
add
and
environments,
don't
cut
it
anymore
there
either.
B
B
We
experimented
with
another
environment
called
untrim,
which
was
equal
equal
to
production
in
every
other
sense,
and
it
had
its
own
slight
configuration
changes,
but
then,
as
we
started,
selling
cloud
66
on
Prem
more
to
more
customers
with
slight
variations
or
starts
like
customizations,
that
started
to
kind
of
go
out
of
whack
as
well.
So
we
realize
that
we
have
that
we
need
another
thing.
We
need
another
concept
on
top
of
an
environment,
something
that
that
is
more
like
a
deployment
destination
and
the
last
challenge
we
had
to
overcome
was
around
configurations
traditionally
pretty
much.
B
Everyone
puts
the
configuration
next
to
the
code
and
in
some
sort
of
a
file,
whether
it's
a
in
a
power,
arms
file
or
JSON
or
llamó
or
some
sort,
and
we
wanted
to
use
the
communities
native
way
of
config
push
it
out,
pull
it
out
into
into
kubernetes
to
manage
those
configurations
for
a
spare
namespace.
If
you
will,
but
we
we
realized
that
we
needed
that
to
be
either
repeated
in
multiple
namespaces
or
shared.
B
And
what,
by
that,
what
I
mean
is,
if
you
think
about
each
kubernetes
namespace
holding
one
instance
of
your
application,
then
you
can
think
of
configuration
of
that
namespace
of
that
instance
being
config
maps
within
that
namespace.
So
you
have
one
namespace
that
holds
your
code
and
also
your
configuration
as
conflict
maps,
and
you
have
another
namespace,
that's
another
version
of
your
application
or
another.
But
for
now
let's
call
it
still
environment
of
your
application
and
you
have
the
configuration
for
it
there
and
then
you
have
a
lot
of
repeats.
B
So
if
you
go
and
have
to
do
a
code
rotate
like
a
tab,
API
key
rotation
because
either
it's
compromised
as
best
practices,
you
want
to
rotate
the
API
keys
to
your,
for
example,
I,
don't
know
a
CWS
API.
You
have
to
go
around
every
single
one
of
those
namespaces
every
single
instance
of
your
names
of
your
application
and
do
the
key
rotation
over
there.
Obviously
there
are
solutions
around
that,
but
we
wanted
to
use
the
native
kubernetes
way,
and
that
was
another
challenge.
B
So
we
started
working
on
our
CRC
the
pipeline
to
solve
those
problems,
to
see
how
we
can
embed
rcic
these
things
into
our
CI
CD
problem,
CIC
department
that
we
have.
We
were
using
a
normal.
You
know
the
CI
CD
solution
that
would
just
take
our
code
from
the
git
repository,
run
the
tests
and
then
deploy
it,
and
we
found
that
very
difficult
to
to
adapt
that
solution
for
what
we
wanted.
It
would
do.
B
The
CI
CD
could
have
traditional
things
like
your
any
unit
tests
and
integration
test
very
well,
but
then
we
wanted
to
have
blue,
green
or
canary
deployments
or
be
easy
to
roll
back
in
production,
or
you
know,
do
things
like:
don't
pull
images
from
docker
hub
make
sure
that
you
pull
it
from
our
own
repositories.
Make
sure
that
there
are
no
no
developer,
adds
tag
latest,
for
example,
to
to
the
images
or
do
image
scans
for
for
known
security,
vulnerabilities
or
bad
base
images
and
all
all
those
things.
B
Obviously,
when
I
look
at
something,
for
example,
like
Jenkins
as
a
as
an
open
source,
see
I
see
dissolution
I,
look
at
it
as
a
as
a
bash
file
and
look
at
as
a
scripting
language
that
I
can
do
whatever
I
want
to
do
with
it,
and
I
can
find
a
plug
in
or
write
a
plug-in
for
it,
and
it
will
work
fine.
But
ideally
we
wanted
something
that
was
built
specific
for
these
requirements
around
containerization
around
solution
around
environments.
You
know
with
a
solution
around
our
secrets
and
configuration.
B
So
this
is
what
we
ended
up.
Building
all
those
problems
led
to
this
being
our
pipeline
and
we
called
it
I
continued
the
letter
view
pipeline
as
a
result
of
this.
We
release
the
product
and
we
open
source,
a
bunch
of
it
which
we
can
I
can
tell
you
about
a
little
bit
more
in
detail,
and
hopefully
you
will
find
those
open
source
solutions
useful,
but
on
the
top
left
we
would
get
the
code
from
source
code
from
a
git
repository
or
potentially
some
pre-built
stalker
images.
Now
the
pre-built
docker
images
on
the
top
left.
B
They
could
either
be
one
off-the-shelf,
docker
image
like
Redis,
for
example
the
official
Redis
image,
or
it
could
be
a
artifact,
an
artifact
of
our
pre-existing
CI
CD
solution
that
we
have.
So
if
we
have
Jenkins,
for
example,
that
takes
our
code
and
builds
it
into
an
image
as
an
artifact
of
this,
you
know
the
test
and
he
puts
it
into
a
docker
registry.
We
can
pull
it
from
there
either
way.
B
The
first
step
for
us
was
to
make
sure
the
code
is
tested
and
make
sure
that
every
deployment
is
tagged
with
the
same
uniform
tag
across
the
board,
whether
the
image
comes
from
off-the-shelf
Redis
or
it's
something
that
is
our
application
and
we
build
it
and
that's
what
this
we
tagging
and
building
steps
are.
So
we
built
that
step
the
building,
a
tree
tagging
as
the
first
step
to
make
sure
that
we
have
a
snapshot
of
our
application,
including
the
code,
configuration
environment
variables
and
everything
else.
That's
there.
B
The
result
of
this
effort
was
one
open
source
project
called
habitus,
which
you
can
see
here,
and
it
supports
build
steps
where
you
can
take
one
part
of
the
code,
build
it
into
a
bunch
of
docker
images
and
then
take
those
images
into
the
next
step
and
also
it
supports
other
around.
You
know
providing
secrets
during
build
files
where
you
want
to
have,
for
example,
a
private
git
repository
junior,
build
potentially
for
private
dependencies
within
your
application
or
squash.
The
images
take
the
secrets
out,
take
layers
out
for
security
and
vulnerability
test
purposes.
B
It
does
all
of
that
and
then
it
tags
everything
at
one
step.
So
now
that
we
have
a
snapshot
of
the
code
configuration
everything
in
one
file,
then
we
can
put
it
into
a
container
registry.
Now
our
solution
worked
with
our
own
armed
registry,
but
we
do
support
other
ones
as
well,
because
we
wanted
to
you
know
when
we
go
to
an
on-prem
solution
to
sell
it
to
an
on-prem
customer,
they
might
have
a
different
content
registry.
So
we
had
to
support
that.
B
The
next
step
for
us
was
asset
management,
and
this
was
an
interesting
part
that
we
kind
of
it
was
a
late
realization,
after
a
bunch
of
production
issues
that
we
had,
that
we
needed
and
buy
annotations
were
mean.
Ideally,
what
we
wanted
was
to
go
into
a
COO
control
or
pod
describe
pod
in
a
certain
part
and
know
exactly
which
git
commit
was
used
to
build
this.
When
was
it
built
who
built
it?
B
Now,
as
you
can
imagine,
because
we
are
not
using
not
every
traffic
type
that
we
have
as
HTTP,
we
have
TCP
traffic,
it
wasn't
quite
possible
for
us-
and
it
is
about
it'd-
be
about
a
year
ago
to
use
a
service
mesh
completely
in
that
sense
that
we
could.
We
could
benefit
from
a
service
mesh
to
trace
traffic.
B
So
we
had
to
make
sure
that
the
metadata
is
available
to
the
code,
so
it
can
be
used
to
augment
the
locks
that
are
that
are
written
by
the
application
and
that's
the
first
step
that
we
do
after
the
images
are
registered.
So
all
the
images
are
tagged
and
registered
as
well
as
that
all
the
assets
that
up
the
resources
that
are
deployed
to
communities
are
attacked.
We
also
do
scanning
of
the
images
we
wanted
to
make
sure
there
is
no
security
vulnerability,
no
base
image
vulnerabilities
available
there.
B
B
The
neck
that
the
configuration
challenge
we
overcome
with
with
with
a
hybrid
solution
with
helm.
So
home
is
a
great
tool
when
it
comes
to
off-the-shelf
installation
of
applications.
We
looked
at
it
as
potentially
a
delivery
suffer
delivery
solution
where
we
could
have
the
best
practices,
installation
of
RabbitMQ
with
a
single
command
of
help,
but
what
we
found
it
lacking
was
that
we
couldn't
dictate-
or
we
couldn't
specify
policies
around
for
developers
so
when
they
create
new
services
in
kubernetes
how
those
services
should
look
like.
B
Now,
to
give
you
an
example,
if
we
wanted
to
make
sure
that
anyone
any
developer,
who
adds
a
new
say
ingress
to
our
communities,
follows
a
certain
criteria.
They
always
have
to
get
the
Stila
certificates
from
a
specific
place.
They
always
have
to
annotate
it
with
these
annotations.
They
always
have
to
call
it
a
certain
way
and
they
have
to
have
it
in
a
separate
file
named
such
and
all
those
things
that
can
be
applied
to
it.
B
While
we
could
go
to
our
ops
team
and
ask
them
to
write
helm,
charts
or
get
the
developers
to
write,
helm,
charts
and
get
them
to
be
validated
by
someone
else,
we
prefer
to
have
the
Native
communities
resources
written
as
guidelines
as
templates
and
now
as
we
call
it
stencils
for
each
one
of
those
resource
types.
So
now
what
we
ended
up
with
is
for
off-the-shelf
tools
like
rabbitmq
right,
like
our
memcache
key.
B
We
use
helm
but
as
guideline
for
any
new
development
within
our
applique,
with
our
own
application
users
and
I
can
I
can
show
you
what
census
looked
like
after
that.
Another
thing
that
we
found
quite
quite
useful
was
was
being
able
to
have
access
to
upstream
Native
communities
API
without
having
a
wrapper
around
it.
Now
this
kind
of
goes
back
to
this
entire
analogy
of
communities
being
a
vending
machine,
and
you
know
our
applications
being
candy.
Inside
of
that
vending
machine.
B
We
wanted
developers
to
have
access
to
stack
up
the
vending
machine
with
their
applications
and
external
vendors
to
also
stack
up
the
the
vending
machine
with
the
apps.
We
also
wanted
to
give
access
to
this
entire
API
of
this
vending
machine
a
or,
for
example,
kubernetes
in
this
case,
so
they
can
so
they
can.
You
know,
benefit
from
the
upstream
communities,
have
the
community
around
communities
and
and
in
the
entire
CN
CF.
You
know
community
around
it,
so
they
can
use
it
and
use
the
internet.
B
You
know
find
answers
on
Stack
Overflow
around
the
issues
that
they
have
without
us
restricting
access
to
that
kubernetes
api
to
avoid
mistakes
being
made.
You
know
an
example
of
that
was
was
an
example
around
the
load
balancer,
so
the
load
balance
is
that
we
have
the
level
four
level
seven
load,
balancers,
that
we
have
had
fixed
IP
address
a
global,
fixed
IP
address
on
google,
and
we
wanted
to
make
sure
that
those
then
get
changed.
We
could
have
locked
it
out.
B
It
could
be
like
an
our
back
policy
around
it,
but
we
couldn't
enforce
those
policies
around
the
file
names,
for
example,
in
a
file
name
of
a
configuration
for
Communities.
It's
completely
invisible
to
communities
when
you
apply
that,
so
we
open
sourced
another
project
called
copper
which
which
its
own,
which
the
entire
promise
of
it,
is
to
act
like
a
unit
test
for
your
kubernetes
configuration
files
with
a
simple
DSL
that
you
can
say
things
like
if
the
IP
address
for
the
load
balancer
has
changed.
B
Let
me
know
it
doesn't
necessarily
mean
it's
a
bad
thing.
The
deployment
has
to
stop,
but
somebody
has
to
sign
it
off,
or
you
can
say
things
like
if
somebody's
using
latest
as
a
tag
for
a
docker
image,
then
deployment
will
stuff
and
that's
an
open
source
project
that
we've
we
rolled
out
as
well
as
a
result,
deployment
work.
Furs
are
the
next
step,
so
we
wanted
to.
You
know
this
is
kind
of
a
normal
thing
in
the
CI
CDU.
Maybe
when
you
have
multiple
steps
of
rolling
out
to
staging
and
into
production,
etc,
etc.
B
So
that's
that's
one
and
then
with
manual
approvals
around
each
one
of
them,
so
another
team
member
has
to
sign
it
off
and
then
formations,
which
is
that
our
concept
that
we
came
up
with
when
we
had
issues
with
with
environments
so
formations
here
are
various
environments.
So
environments
are
independent
of
deployment,
it's
just
an
environment.
B
They
are
limited
to
the
number
of
environments
that
you
have
like
production,
staging
and
QA,
and
that's
pretty
much
it
and
usually
have
some
sort
of
undocumented
meaning
your
production,
everybody,
when
you
say
production,
environment,
everybody
kind
of
says
all
you
make
sure
that
you
don't
break
anything
and
staging
is
kind
of
like
oh,
it's
kind
of
ready
to
go
to
production,
maybe
you're
testing
it,
but
these
things
are
necessarily
a
convention
or
or
written
anywhere.
We
wanted
that
to
be
more
structured.
B
When
we
say
production
we
mean
certain
things
and
also
we
want
it
to
be.
We
wanted
to
have
multiple
sets
of
production
environments
on
trim
off
Prem.
You
know
dedicated
on
the
cloud
or
our
SAS
and
that's
the
concept
of
formation
for
us.
So
we
created
this
concept
called
formations
and
we
deployed
two
formations
not
to
environments
formations
are
likely
deployment
target.
You
can
have
as
many
formations
as
you
want.
B
Any
formation
can
have
an
environment,
you
can
have
a
formation
that
is
running
on
gke
and
it's
production
and
you
can
have
another
formation
that
is,
and
that
is
also
production.
But
it's
running
on
AWS
for
various
different
reasons.
You
might
have
different
formations
for
different
features
for
different
environments,
for
different
clients,
for
different
customers,
for
different
geographic
regions
and
when
it
comes
to
stencils
versus,
like
normal
templates
templates
like
helm
charge,
for
example,
version
control,
and
that
is
an
optional
thing.
If
you
have
a
chart
repository,
you
don't
necessarily
have
version
control.
B
If
you
opt
in
not
to
we
wanted
to
have
structure
around
that,
make
sure
that
our
configuration
files
are
version
controlled.
We
didn't
want
to
allow
people
to
use
flow
control
inside
of
llamó,
for
example,
something
like
you
know,
for
every
service,
loop
and
then
middle
of
it.
Somebody
would
go
and
add.
If
service
name
is
front
end,
then
there
is
a
difference
that
would
just
make
the
entire
configuration
fall.
I'm,
not
very
understandable,
not
maintainable
and
templates
are
kind
of
domain
independent.
They
are
sometimes
the
same
language.
B
Templating
language
is
used
for
rendering
HTML,
but
we
wanted
to.
We
wanted
to
have
something.
That's
that's
the
that's
aware
of
the
fact
that
is
rendering
the
yamo
file
for
containers
for
kubernetes,
essentially
some
sort
of
a
DSL.
So
we
built
a
sting
stencils
with
version
control
with
support
for
database
templates.
B
It
supports
multi,
step
bucket,
builds
and
it
does
support
multi
server,
so
you
can
roll
it
out
on
multiple
servers
and
each
step
can
build
can
be
built
on
different
server
in
your
farm
and
it
is
multi
tenant
it
as
well.
So
you
can
have
multiple
builds
running
of
the
same
thing
of
different
versions,
the
same
thing
and
it
doesn't
mess
up
docker
daemon.
B
It
also
is
cache,
aware
so
knows,
which
part
needs
to
be
built
where
you
can
find
out
and
happy
to
do,
and
it
also
just
does
support
secrets
during
the
build
where,
if
you
have
an
NPM
or
a
ruby
gem
or
a
goal
library
that
is
a
private
repository
and
it
means
it
private
and
sage
key.
It
does
for
providing
that
during
the
build
and
then
without
leaving
any
traces
and
copper.
As
I
mentioned.
It
allows
you
to
have
your
developers
to
have
access
to
vanilla
upstream
api's.
B
It
can
stop
the
build,
as
opposed
to
just
warning
you
and
asking
for
an
extra
pair
of
eyes,
tu-tu-tu-tu-tu
sign
of
the
deployment
flow
based
on
different
various
different
conditions.
That
could
happen,
and
you
can
have
extra
asset
policies
like
filenames
and
folders,
as
well
as
intra
assets.
Policies
where
you
know
you
can
say
things
like
some
asset
should
have
annotations,
or
some
asset
should
be
somewhat.
Some
IP
address
of
an
asset
should
be
within
a
specific
range.
B
At
the
end,
our
stack
ended
up
looking
like
this,
so
we
kept
our
databases
inside
of
our
database
as
a
service
or
in
rabbitmq.
As
a
service
providers-
and
we
had
now-
we
have
a
pool
of
nodes
that
identical
they
are
read-only
OS
as
well,
so
we
don't.
We
cannot
even
make
changes
to
those
deliberately.
So
that's
a
good
thing
and
we
can
fire
it
up.
Fire
up
new
ones
and
you
know,
shut
down
old
ones
with
rotating
upgrades
and
all
the
things
that
comes
with
it
now.
B
So
this
is
copper
that
you
can
see
here
around
copper,
SH
and,
if
I
show
you
some
examples
of
how
how
it
works
is
a
command-line
tool
that
you
can
run
and
the
example
for
example.
You
know
example
of
not
using
a
latest
tag
as
an
image.
It
kind
of
looks
like
this.
I
can
write
a
rule
and
this
rule
exists
in
a
file.
B
We
can
call
it
a
cop
file
and
I
just
fetch
any
image
under
my
containers
and
if
you
familiar
with
abilities
your
deployment
resource
you
can
you
know
that
the
image
of
a
docker
image
that's
used
inside
of
a
pod
is
defined
on
the
images
of
containers
of
spec
template
stick,
so
this
is
kind
of
a
you
know.
Jason
part
X,
Jason
part.
B
B
If
the
repository
or
registries
in
non-existent,
it
knows
this
docker
hub,
he
picks
up
the
tag
and
it
makes
sure
that
it's
not
latest
or
things
like
you
know
you
want
to
allow
your
developers
to
bump
up
your
my
sequel
version
if
you
run
and
get
inside
of
the
container
only
by
minor
versions,
not
major
versions-
and
you
can
do
things
like
this,
so
you
can
get
the
image
name
of
any.
My
sequel
is
there's
a
tag
picture
tag
and
it
understands
semantic
versioning.
So
you
can
you
can
look
at
the
semantic
version.
B
You
make
sure
satisfies
this
version,
control
extra
asset
policies.
You
can
do
things
like
make
sure
that
the
extension
is
EML,
not
YAML.
If
that's
what
you
want,
if
the
kind
of
an
asset
which
you
can
you
familiar
with,
this
is
a
kubernetes
concept.
If
the
con
is
a
deployment,
then
the
metadata
name,
metadata
name
in
the
metadata
name,
then
the
file
name
should
end
with
deployments
and
obviously
the
extension
is
llaman.
So
if
that's
a
that's
a
car,
you
can
think
of
it
as
a
policy
that
you
can
enforce
again.
It
understand
the
stance.
B
B
No
dr.
hub
images
is
another
one
that
you
can
think
of,
or
you
can
enforce
things
that
you
always
pull
the
images
from
a
private
registry
and
not
the
public
registry.
You
can
enforce
all
those
things,
so
it's
a
very
powerful
DSL,
it's
very
simple
syntax
allows
you
to
to
enforce
policies
that
would
allow
your
developers
in
turn
access
the
upstream
Native
communities
API
without
restricting
them,
and
and
without
you
having
to
check
every
time
manually
that
any
of
your
policies
or
components
things
that
broke
so
with
that
I
wanted
to.
B
Thank
you
for
your
time.
If
any
questions
I
would
love
to
answer
that
about
what
we've
built
and
what
we've
open-sourced,
we
return
this
entire
pipeline
into
a
product.
We
call
it
classic
Zeus
skycap
as
a
result
of
that
and
and
we're
where
we
are
now.
Our
uptime
stayed
pretty
much
the
same
as
before,
but
our
scaling
and
our
scaling
and
also
being
able
to
move
from
one
region
to
another
has
become
much
much
faster.
B
A
Ok,
so
we
have
around
20
minutes
for
your
questions
so
feel
free
to
drop
them
in
the
Q&A
tab.
There
webinar
interface,
and
we
are
happy
to
answer
them
before
we're
waiting
for
another
questions.
Probably
as
many
highlights
some
some
roadmap
on
your
on
your
projects
that
you
have
just
highlighted
for
us
and
some
further
steps
and
another
notable
items
that
have
have
not
been
current
by
this
presentation.
A
B
So
on
the
habit
aside,
which
we
didn't
really
I,
didn't
really
go
into
details
of
so
habitus
is
a
build
workflow
tool
for
doctor
files.
On
the
habitus
side,
we
are
working
with
Microsoft
specifically
to
integrate
into
integrate
that
into
draft,
which
is
a
continuous
build
solution
for
development,
where
we
can
build
using
your
local
doctor
demon,
but
also
multi-step,
builds
using
your
document
and
have
it.
So
that's
this
one
one
side
of
it
on
the
copper
side,
because
copper
is
not
necessarily
when
copper
works.
B
It
glows
your
configuration
file
into
a
a
JSON
format
and
everything
every
rule
and
every
policy
that
you
write
for
it
is
applied
to
that
Jason
for
in-memory
format.
That
means
you
can
load
pretty
much
any
file
format
and
if
any
file
type
into
copper
and
validations
for
it
as
a
result
with
copper,
what
we
can
do
is
we
are
going
to
open
it
up
to
other
non
kubernetes
configuration
files
for
any
configuration
system.
It
could
be
held,
charts
that
you
could
validate
and
it
could
be
non
communities
configuration
related
things
for
any
others.
B
For
example,
CN
CF
open
source
project
that
has
a
configuration
file
where
there
is
llamo,
jason,
tamil
or
anything
else.
We
can
do
that.
So
that's
on
the
roadmap
for
us
to
extend
the
reach
of
copper
into
more
more
configuration,
validation
for
non
kubernetes
specific
things
and
extend
this
dsl
to
understand
the
concepts
of
things
like
how
the
charts,
for
example.
So
that's
the
immediate
roadmap
around
those
two
projects,
as
four
classics
is
skycap,
you
know
rolling
it
out
for
four
more
customers
and
seeing
the
use
cases
they
have
and
how
we
can.
B
We
can
take
care
of
more
traditional
CI
CD
workers,
as
well
as
specific
deployment
to
production,
is
where
we
are
going
to
so
for
us
CI,
CD
tools
that
are
out
there
are
very,
very
good
solutions
for
building
and
testing
containers
infrastructure.
But
our
aim
is
to
to
pro
to
to
make
skycap
the
the
ultimate
kubernetes
deployment
tool
when
it
when
it
comes
to
a
micro
service
based
application.
A
Right
so
I'm
counting
to
three
and
we
are
close
to
this
webinar,
so
one
two
three:
that
was
the
final
call
for
the
questions
here.
Thank
you.
Thank
you.
Everybody
who
has
joined
us
here
today
just
to
remind
that
we
are
holding
this.
You
can
see
regular
webinars,
every
Tuesday
exact
at
this
time
independently,
which
teams
only
allocated
so
also
this
webinar
has
been
recorded
and
will
be
available
in
the
next
few
days
with
a
CNC
our
website.
Thank
you
for
joining
us
today
and
good
bye.