►
From YouTube: Happy Helming with Service Catalog - Jeremy Rickard, Microsoft (Intermediate Skill Level)
Description
Want to view more sessions and keep the conversations going? Join us for KubeCon + CloudNativeCon North America in Seattle, December 11 - 13, 2018 (http://bit.ly/KCCNCNA18) or in Shanghai, November 14-15 (http://bit.ly/kccncchina18).
Happy Helming with Service Catalog - Jeremy Rickard, Microsoft (Intermediate Skill Level)
Helm has emerged as a popular tool for distributing and using applications on Kubernetes. The kubernetes/charts repo has almost 150 different packages today! Helm works by bundling Kubernetes resources together into an easy to use package and allows you to specify dependencies on other packages, enabling deployment of services like databases alongside your application. But what if you wanted to use a managed database from a cloud provider, instead of running it in your cluster? What if it was as simple as selecting it from a catalog? The service-catalog project is being built to bring this capability to the Kubernetes eco-system using the Open Service Broker API. In this talk, Jeremy will introduce service-catalog and the new resources it brings to Kubernetes. He will also demo how you can use Helm to deliver an application configured to use services provided by the service catalog.
About Jeremy
Jeremy Rickard is a software engineer at Microsoft in Colorado working on the Open Service Broker for Azure. Before that, he worked at VMware and helped build infrastructure and services that support VMware Cloud Services.
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.
A
All
right,
it
is
11:55,
so
we'll
go
ahead
and
get
started.
Thank
you
for
coming.
We're
gonna
talk
about
helm
and
service
catalog
today,
so
my
name
is
Jeremy
I
work
at
Microsoft
Azure
on
the
containers
team,
I'm,
specifically
working
on
open
service
broker
for
Asher,
which
is
an
implementation
of
the
open
service
broker.
Api
I'll
talk
about
that
in
a
little
bit.
I
also
do
some
contributions
to
six
Service
Catalog,
which
is
the
group
that's
building
service
catalog
for
kubernetes.
You
can
find
all
my
contact
info
here.
A
A
It
brings
you
a
lot
of
freedom
and
a
lot
of
choice
in
how
you're
gonna
build
your
system,
and
that
can
be
things
like
what
programming
language
you're
going
to
build
your
system
in
what
kind
of
interfaces
it's
going
to
expose,
whether
it's
HTTP
or
something
else,
and
then
what
kind
of
persistence?
It's
going
to
use,
are
you
gonna
use
a
relational
database
or
a
non
relational
database,
so
I
have
this
kind
of
notional
web
store
that
comes
from
one
of
the
spring
outfit
direct
debits.
That
is
built
up
of
a
bunch
of
Microsystems.
A
It's
using
my
sequel,
post,
Scrat
Oh,
so
my
sequel
neo4j,
which
is
a
graph
database,
MongoDB,
pretty
pretty
popular,
no
sequel
database
building,
something
like
this
in
deploying
to
kubernetes
is
probably
gonna,
be
a
challenging
thing
right
for
each
one
of
these
services,
you're,
probably
going
to
need
to
develop
some
sort
of
deployment
replica
set,
depending
what
you're
doing
for
the
things
like
post
graph
or
my
sequel
and
neo4j
and
MongoDB
probably
need
to
worry
about
persistence.
So
you
probably
need
to
figure
out
how
to
build
persistent
volumes
for
that.
A
What
you're
gonna
use
for
that
the
thing
on
top
probably
has
an
ingress
associated
with
it,
so
that
traffic
from
the
outside
can
come
in.
You
just
have
a
lot
of
pieces
that
make
this
thing
up
and
when
you
think
about
how
you're
going
to
deploy
these
things,
possibly
roll
them
back,
there's
not
really
a
thing.
A
You
end
up
with
that
that
final
state
that
you
want,
but
each
one
of
them
is
individually
controllable
and
that's
great
for
quickly
rolling,
back
and
handling
the
the
lifecycle
of
your
application.
In
a
way,
that's
really
manageable
version
control
understandable.
But
what
do
you
do
about
the
databases
when
you're
gonna
write
your
application?
Do
you
need
to
worry
about
how
to
containerize
my
sequel
or
Postgres
or
MongoDB
me
as
a
Java
and
go
developer?
Probably
not
the
best
person
to
do
that,
so
luckily,
the
community
has
been
thinking
about
that.
A
So
in
the
stable
helmut
arts,
repo
there's
a
number
of
databases
that
you
can
consume
with
your
helmet
art
and
they're
packaged
as
helmet
charts,
it
may
not
be
the
best
thing
for
deploying
for
production,
but
they're
really
easy
to
use
and
consume
and
get
started,
deploying
on
de
mini
coop
great
for
the
developer
experience.
When
you
move
into
production,
you
can
also
take
advantage
of
operators
right,
so
we
heard
about
operators
in
the
keynote
a
little
bit
today.
A
If
you
go
to
github,
do
google
search
you
can
find
a
number
of
operators
for
a
lot
of
popular
things
at
CD?
Obviously,
is
a
big
one
from
core
OS,
but
also
Oracle
has
one
for
my
sequel,
there's
one
for
four
Postgres
as
well
from
crunchy.
You
can
find
a
lot
of
these
things.
You
can
build
them
yourself
as
well,
and
luckily
a
lot
of
these
also
provide
helm
carts.
So
if
you're
already
using
helm,
this
is
another
way
that
you
can
kind
of
bring
that
experience
and
keep
your
common,
tooling
and
people.
A
This
is
the
canonical
example.
If
you
go
to
the
stable
home.
Transcript
of
this
is
the
WordPress
template.
This
is
the
requirements
file
from
the
WordPress
template
WordPress
chart
in
this.
It's
saying
that
it
depends
on
Reedy
B.
So
when
you
install
the
WordPress
helm
chart
assuming
you
have
that
condition
Moorea
to
be
enabled,
it's
gonna
use
the
Maria
DB
chart
and
you'll
end
up
with
a
deployment
oops.
Sorry,
we
see
the
resources
that
are
deployed
here
when
I
run
the
helm,
install
command.
You
end
up
with
a
persistent
volume
claim
for
Maria
DB.
A
You
end
up
with
a
service
from
really
be
a
deployment
and
a
pod
for
each
one
of
those.
So
by
simply
running
that
one
kind
of
package
manager,
you
know
helm,
install
command.
You
end
up
with
that
fully
functional
thing
using
that
helm
package
to
Moorea
DB.
So
that's
really
good.
Really
convenient
and
people
are
running
stateful
things
in
kubernetes,
so
this
was
a
tweet
from
Matt
Farina.
It
was
right
when
I
got
to
Copenhagen,
so
I
tweeted
starts
a
little
bit
to
include
it.
I
thought
it
was
super
relevant.
A
Obviously,
stateful
stateless
services
are
what
most
people
are
using
ku
gratis
for.
But
if
you
look
at
the
numbers
for
sequel
databases,
no
sequel,
message,
queues,
other
things
and
it's
between
25
and
50
percent
somewhere
in
that
range.
A
lot
of
people
are
running
stateful
things
on
kubernetes
and
it's
gotten
a
lot
better.
If
you
try
to
do
this
a
couple
years
ago,
a
lot
of
the
pieces
that
you
needed
to
do
this
weren't
really
there.
But
a
lot
of
progress
has
been
made.
A
Another
tweak
always
have
to
have
a
Kelsie
tweet
in
your
presentation,
so
this
was
from
February
and
it
was
a
really
crazy
long
thread.
The
takeaway
was
that
Kelsie
thinks
that
kubernetes
has
made
a
lot
of
improvements
to
run
stateful
workloads,
but
he
doesn't
like
to
do.
Stateful
work
floats
like
one
I
didn't
include
here,
was
kubernetes
supports,
stateful
workloads,
I,
don't
so
his
take
away.
His
alternative
was
you
know
either
you
run
these
things
in
a
dedicated,
node
group,
maybe
on
other
hardware
or
you
take
advantage
of
a
managed
service
from
a
cloud
provider.
A
A
It
turns
out
there's
two
things
make
this
really
possible,
so
you
could
definitely
do
outside
of
committees
like
you
could
build
terraform
to
go
deploy
Postgres
in
amazon.
Why
are
your
secrets
in
your
cluster
build
all
about
yourself,
but
it's
extra
work
that
you
don't
necessarily
need
to
do
because
kubernetes
ecosystems
bringing
that
along
for
you.
So
the
first
of
these
things
is
the
open
service
broker
API.
So
we
solve
that
again
in
the
keynotes
today
when
Abby
was
talking
about
cloud
foundry
and
kubernetes
together,
so
the
open
service
broker
API
originated
in
cloud
foundry.
A
So
if
anybody
is
a
cloud
foundry
developer,
you're
pretty
familiar
with
the
the
CF
create
service
command
that
goes
ahead
and
talks
to
a
service
broker
that
implements
the
open
service
broker
API
and
creates
the
thing
that
you
need
to
use.
Once
you
have
it,
then
you
can
run
a
CF
bind
or
declare
it
in
your
manifest
to
connect
that
application
to
the
thing
that
the
broker
has
created
and
then
obviously
unbind
update
the
instance.
A
If
you
need
change
parameters,
make
it
a
bigger
instance
or
shrink
it
down,
change,
firewall
rules,
things
like
that
and
obviously
a
deep
revision,
and
once
you
no
longer
need
it
get
rid
of
it.
All
of
these
things
are
trying
to
give
you
a
standard
way
of
talking
to
your
cloud.
Infrastructure
could
be
done,
cloud
administer
sure
you
could
write
it.
Your
own
broker
to
do
essentially
anything
as
long
as
it's
implementing
this
API
and
then
any
platform.
That's
consuming.
A
Osb
can
do
that
and
in
kubernetes
that
platform
is
Service
Catalog,
so
Service
Catalog
is
developed
as
an
API
extension.
You
register
install
service
catalog
on
your
cluster.
It
adds
some
resource
types
to
your
your
cluster
and
then
you
can
just
use
the
kubernetes
api
to
interact
with
the
broker
and
if
we
look
at
the
types
that
are
added,
the
first
one
is
cluster
service
broker.
So
cluster
service
broker
is
how
you
introduce
a
broker
into
your
cluster
and
you're,
going
to
include
things
like
the
URL
to
connect
to
the
username.
A
The
password
may
be
a
token
if
it's
doing
token-based
authentication.
So
you
create
that
as
the
desired
state
of
your
cluster
to
have
that
broker
added
and
then
the
broker
is
contacted
and
it's
going
to
create
some
extra
resources
in
the
cluster
for
you.
So
these
types
are
registered,
but
once
there
the
broker
is
added
it's
going
to
fetch
the
catalog,
so
the
catalog
is
made
up
of
two
things:
one
is
the
service
class
and
this
is
called
the
cluster
service
class.
That's
going
to
be
things
like
Postgres
or
my
sequel
or
MongoDB.
A
You
know
the
general
class
of
service
and
then
inside
of
that
you'll
also
have
service
plans
and,
though,
are
going
to
specify
the
topping
of
the
quality
of
service
you're
going
to
get
for
each
one
of
those
classes
could
be
like
a
free
plan
or
a
non
free
plan.
Maybe
it's
highly
available
replicated
in
multiple,
multiple
regions,
so
the
broker
is
added
to
the
cluster
service.
A
Catalog
gets
the
catalog
from
the
broker
and
then
once
you
have
that
information
you're
able
to
list
those
things
browse
the
catalog
and
figure
out
what
you
need
and
create
a
service
instance.
So
the
service
instance
is
where
you're
going
to
define
what
the
state
of
that
instance
should
look
like
it's
going
to
include
the
cluster
service
class
in
the
plan,
along
with
any
provisioning
parameters
that
are
necessary.
For
that
instance,
like.
Maybe
you
want
to
specify
firewall
rules,
it's
a
good
example.
A
You
have
those
things
in
the
definition
like
the
spec
of
that
cluster
instance
and
service
catalog
is
going
to
turn
that
into
a
provision
request
to
the
open
service
broker,
open
service
broker.
Will
then
asynchronously
do
the
things
that
it
needs
to
do
like
provision
whatever
makes
up
that
service
behind
the
scenes
and
make
that
available
as
an
instance
inside
of
your
cluster?
So
so
next
look.
The
last
thing
you
need
to
do
to
connect
that
is
to
create
a
service
binding
and
the
service
binding
again
allows
you
to
specify
parameters.
A
If
you
need
to
parameterize
your
bind
request,
you
create
that
into
the
cluster
and
service
catalog
says:
ok,
I
need
to
go
to
the
broker
and
create
a
binding,
and
that's
generally
going
to
be
something
like
creating
a
user
or
returning
some
sort
of
pre
pre
staged
connection
information,
the
URI
to
connect
to
you
host
port.
It
varies
from
bourbon
broker,
but
that's
returned
in
a
format
that
gets
turned
into
a
secret.
So
once
you
have
that
secret
in
your
cluster,
you
can
consume
it
from
any
application.
A
Like
you
would
any
other
secret
in
the
app
in
the
in
the
cluster,
so
you
can
deploy
your
your
pod.
Your
pod
can
load
that
into
environment
variables
and
it's
good
to
go.
So
at
that
point
you
have
a
thing
provisioned
in
the
cloud
or
on
VMs
in
your
infrastructure,
using
whatever
broker
could
be
crossed
cloud
and
you've
got
a
secret
created
in
your
cluster
that
you're
ready
to
use.
So
this
sounds
really
awesome
right.
A
So
you
can't
really
use
our
back
to
say
that
I
wanted
to
be
able
to
deploy
in
this
namespace
only
free
plans
and
in
this
namespace
I
only
want
to
do
product
like
really
expensive,
highly
available
plans
that
being
fixed,
Service
Catalog
is
actually
doing
a
lot
of
work
to
improve
the
user
experience.
But
that's
one
that
you
can't
really
work
around
yet
other
than
specifying
through
our
back
that
nobody,
except
a
certain
set
of
people
can
create
resources,
but
that's
work
you
can
you
can
handle
that
another.
A
Is
that,
while
this
is
trying
to
give
you
that
common
specified
API
for
interacting
with
cloud
resources
through
an
indirection
layer,
you're
still
exposing
some
things
that
are
not
common.
Obviously
the
class
and
the
plan
is
one
of
those
things.
So
if
you're
gonna
use
the
Google
broker
or
you're
gonna
use
the
azure
broker,
they're,
probably
gonna
use
different
class
names,
probably
different
plan
names
to
represent
those
things.
So
you
can't
really
just
say:
give
me
a
my
sequel.
A
A
So
that
is
pretty
easy
to
work
around
using
our
existing
tooling.
So
we're
gonna,
look
at
a
couple
of
ways
at
helm
can
help
us
with
that.
So
it's
easy
to
use
Service
Catalog
with
helm,
but
it's
also
easy
to
use
helm
to
kind
of
augment
the
user
experience
you
get
with
service
catalog.
So
you
end
up
in
a
better
state
kind
of
all-around.
A
A
So
there's
nothing
in
the
OSP
spec.
That
says
that
a
credential
block
should
include
the
following
key.
So
like
there's
some
guidance,
Cloud
Foundry
has
some
some
suggestions
about
what
you
should
do
for
your
broker.
If
you're
going
to
be
a
cloud,
foundry
broker
that
works
with
spring,
but
there's
nothing
in
this
back,
so
the
Asscher
broker
and
the
Google
broker
could
return
totally
different
sets
of
keys
the
shape
of
the
credential
to
be
totally
different.
A
Okay,
so
this
is
the
the
directory
that'll
be
in
github
we've,
three
charts,
one
is
cosmos
DB.
The
second
one
is
MongoDB,
is
generic,
so
the
first
one
is
just
gonna,
be
the
azure
service
and
look
at
that
and
then
we'll
do
play
the
application
which
I'm
calling
tweet
scraper.
It's
two
parts,
its
pod
with
two
containers.
One
is
gonna,
listen
for
the
coop
con
hash
tag,
stick
them
into
that
cosmos
DB
instance,
and
then
we'll
have
a
pretty
little
front-end
for
it.
A
So
I
have
a
text
file
here,
because
I'm
terrible
at
typing,
so
I'm
just
gonna,
do
a
little
bit
of
coffee
based
first,
we'll
show
you
that
there's
nothing
deployed
in
this.
This
group
and
the
G
in
this
I'm
using
that
as
your
command
line
tool,
I'm
just
gonna
list
the
resources
there's
nothing
there.
So
what
I'm
gonna
do
next
is
use
this
tool
called
SV
cat.
So
you
can
use
coop
CTL
to
do
this
as
well.
I
can
do
coop
CTL,
get
service
instances.
A
A
Now
we
have
one
that's
provisioning,
so
it's
gonna
go.
Asynchronously
talked
to
the
broker,
which
is
the
azure
open
service
broker.
It's
gonna
say:
please
provision
me
something
called
cosmos
DB,
which
is
made
up
of
a
couple
of
plans
and
services,
and
that
resource
looks
something
like
this
I'll
just
do
a
dry
run
on
it
to
spit
out
what
comes
out
so
we
can
see
the
the
the
spec
for
that
that
service
instance
includes.
A
The
class,
includes
the
plan
and
then
includes
whatever
parameters
are
necessary
for
that
thing,
and
in
this
case
the
kiss
of
azure,
when
you
know
what
location
to
deploy
it
in
so
that's
kind
of
like
which
region
for
Amazon,
we
need
to
know
what
group
it's
going
to
go
into
then
provide
some
parameters.
So
I
want
to
allow
this
to
be
accessed
from
the
azure
portal.
It's
pretty
important
to
be
able
to
manage
it
later.
A
A
So
let's
go
to
cosmos
DB
and
we
see
one
creating
right
there
in
West
Europe,
which
is
exactly
where
we
said
we
wanted
it.
So
it's
being
provisioned.
Now
this
takes
a
few
minutes,
so
I'm
not
going
to
wait
till
it
finishes,
go
on
to
the
next
demo
now
so
we
have
that
cosmos
to
be
deploying
once
that's
done.
We
could
then
deploy
any
application
we
wanted
to.
That
would
use
it
and
the
way
that
we
would
use
it
obviously
is
through
a
binding.
A
A
N
tweets,
it's
not
deployed
I
accidentally
deleted
it
perfect!
Oh
no!
It's
the
wrong
name!
So
we're
gonna
run
this
again.
This
is
the
command
that's
going
to
deploy
the
another
cosmos,
DB
plus
the
application.
So
you
can
see
the
kind
of
dependency
between
them.
So
now,
if
I
do
get
instances
on
tweets
namespace
there,
it
is
it's
provisioning
right.
If
we
do
get
bindings
on
that,
we
will
see.
A
The
instance
isn't
ready
yet
so
yeah
it
can't
create
the
binding.
So
when
you
do
these
kind
of
provisions
or
installs
with
helm,
the
instance
is
going
to
get
created.
Obviously
that's
what
kubernetes
does
but
it'll
eventually
be
consistent
with
what
you
specified
as
the
state.
So
once
that
instance
is
done,
Service
Catalog
will
say
now.
The
instance
is
ready.
I
can
go,
make
the
binding.
If
we
look
at
the
pods
that.
A
Container
can't
be
created
yet
because
it
depends
on
a
secret,
that's
going
to
be
generated
by
that
binding,
so
it
hasn't
started
yet
so
you
get
this
nice
dependency
flow
of
things,
kind
of
falling
out
from
doing
that
single
helm,
install.
If
we
look
at
the
chart
for
this,
this
is
the
look
at
that
command.
We
installed
tweet
scraper.
So
let's
look
at
tweet
scraper.
A
Okay,
so
in
this
we've
got
a
requirement
Seattle
and
if
you've
used
helm.
This
is
a
super
super
familiar
right.
It's
got
a
dependency
on
cosmos
TV
from
my
helm,
repo,
which
is
charts,
Museum,
Jeremy,
Richard,
calm
with
the
condition
database
create
and
when
we
ran
this
helm
command
this
helm,
install.
We
specified
database
create
equals
true.
So
that
condition
is
true,
so
we
went
ahead
and
made
that
cosmos
instance
for
us.
A
If
we
go
to
the
templates
we've
defined,
what
the
service
is,
we've
defined,
what
the
deployment
is
and
the
binding,
but
not
the
instance
itself,
because
that
came
from
that
helm
dependency
right.
So
if
we
look
at
the
deployment
really
quick,
here's
how
we're
consuming
the
secret,
so
we
have
the
environment
block
inside
of
the
the
pod
spec,
with
a
couple
of
names,
host
pour
user
and
password,
and
within
that
we
were
referencing
a
secret
with
the
template
of
the
full
name
of
the
chart.
A
So
we
don't
really
need
to
know
where
it
is
cosmos,
DB,
secret
and
that's
defined
in
the
cosmos
binding.
So
when
you
define
the
binding,
you
can
say
what
the
secret
that
should
be
output.
Is
you
have
control
over
all
of
that
stuff
and
you
can
link
them
together
really
nicely
with
helm.
Okay,
the
other
thing
you'd
get
out
of
that
is
a
full
working
system
when
it's
all
done
so
that
I
do
have
provisioned.
So
we'll
look
at
that
namespace.
A
A
A
A
And
we
can
also
show
the
secrets:
this
is
a
little
handy
thing:
that's
in
service
cattle
or
an
SP
cattle.
So
when
I
do
that,
it's
gonna
spit
out
and
base64
decode
that
thing.
So
it's
easy
for
me
to
debug
and
I
can
see
that
it
created
a
couple
of
things.
It
created
a
connection
string
in
the
secret,
a
password,
a
port
and
a
username.
A
A
Okay,
it's
running
doing
it
and
we'll
just
curl
it
so
again
that
application
is
to
two
containers
in
pod.
One
is
pointing
tweets
sticking
them
into
Cosmos
DB.
The
other
one
is
gonna,
be
a
little
web
front-end
to
that.
So
we
run
this
curl
command.
We
get
back.
Clippy
and
Clippy
has
some
random
tweet
from
from
the
week.
If
we
run
it
again,
get
different
cool.
So
we
have
this.
This
application
deployed
its
using
cosmos
DB.
The
data
is
stuck
into
that
thing.
Just
like
you
would
use
any
other
resource,
it's
defined
in
a
secret.
A
So
that's
really
cool,
that's
all
using
the
azure
broker.
So
let's
look
at
what
it
looks
like
if
you
use
a
different
broker.
So
if
I
look
at
what
I
have
installed
in
my
cluster
right
now,
I
have
a
couple
of
things
installed.
So
obviously,
at
the
top
you
can
see
catalog,
that's
Service
Catalog.
So
the
way
you
install
Service
Catalog
by
default
is
to
use
helm,
there's
a
lot
of
things
that
make
up
installing
Service
Catalog,
and
it
just
makes
it
easier
when
you
use
the
helm
package.
A
A
So
my
coworker
Carolyn
has
written
this
thing
called
mini
broker
and
what
mini
broker
does
is
secretly
install
Helms
tiller
for
you
and
then
use
helm
charts
to
install
things
on
the
cluster,
but
you
get
to
use
it
in
the
same
way
that
you'd
use
Service
Catalog
right.
So
if
I'm
gonna
use
the
helm
chart
to
install
MongoDB,
normally
I'm
not
gonna,
get
the
same
service
instance
service,
binding
things
that
I
can
depend
on
that
I
would
get
with
Service
Catalog,
but
mini
broker.
Does
that
for
you
so
mini
broker?
A
Goes
you
you
don't
see
that
you've
installed
something
with
helm,
because
it's
it's
in
a
separate
namespace
and
it's
not
exposed
to
you.
But
it's
really
what's
happening
behind
the
scenes,
so
we
can
provision
with
helm
or
with
mini
broker
really
quickly,
because
that
is
local,
so
we're
gonna
provision
again.
So
we're
gonna
use
SP
cat
to
do
this
instead
of
using
a
helm
jar
just
just
for
quickness.
A
So
as
you
can
allow
you
to
do
provisioning
all
the
operations
you
want
to
do
against
the
broker.
We're
gonna
say
that
we
want
this
thing
to
be
called
mini
broker.
We
want
to
use
the
class
MongoDB
and
the
plan
three
four
six,
so
I
run
that
and
I
have
a
new
instance
right.
So
if
I
do
SB
cat
get
instances
in
the
default
namespace
there's
my
mini
broker
ready
to
go
and
I
can
then
bind
to
it.
A
A
Okay,
so
we
get
back
a
host.
That's
great!
It's
the
same
thing.
That's
in
my
other
one.
We
get
back
a
port,
we
got
back
a
username
and
the
password,
so
I
could
directly
use
this
thing
and
it
should
be
good
to
go.
However,
if
I
had
been
using
the
connection
string,
which
is
a
totally
logical
thing
to
do,
because
it's
a
fully
built
MongoDB
connection
string
I'd
be
out
of
luck
in
this
case,
because
it's
called
URI
here
in
the
one
in
the
tweets
directory
or
name
space.
A
That
one's
called
connection
string
right,
so
those
don't
really
line
up
and
that
would
be
kind
of
problematic
if
I
had
to
been
depending
on
that
in
my
home
chart.
If,
instead
of
using
those
four
different
environment
variables
I
only
injected
the
one,
this
would
break
for
me
if
I
try
to
deploy
this
chart
or
that
chart.
So
the
thing
you
can
do
to
work
around
that
is
a
fairly
new
feature.
That's
in
Service
Catalog
called
secret
transformation.
A
So
let's
go
to
MongoDB
here,
okay,
so
in
this
one
you
see
two
things:
I've
defined
a
MongoDB
instance
and
a
binding.
So
when
I
install
this
chart,
it's
gonna
create
both
the
instance
and
the
binding.
But
what
I've
done
is
print
is
added
conditionals
to
this,
so
that
it
will
deploy
either
the
cosmos
DB
instance
or
it
will
deploy
the
MongoDB
instance
and
then
it'll
be
very,
very
nice
to
me
and
transform
that
secret.
So
the
interesting
part
of
this
again
as
a
conditional
right.
A
So
if
it's
not
set
to
instance
that
local,
it's
going
to
use
the
azure
information,
so
it's
going
to
do
as
your
cosmos
DB
account
and
account
as
the
plan
name.
Otherwise,
it's
going
to
use
MongoDB
and
three
four
six.
So
the
same
thing
I
did
with
SV
cat
and
provisioned
locally.
This
thing's
gonna
do
for
me
using
that
conditional
and
then
the
real
magic
is
in
the
binding,
obviously
so
binding.
So
we
specify
the
same
kind
of
VM
law
right.
A
It's
got
a
spec
inside
of
that
we're
gonna,
say
what
the
secret
name
should
be
what
instance
to
reference.
So
it
looks
exactly
like
the
binding
we
created
and
the
other
one,
but
here
we're
also
specifying
a
secret
transform
inside
of
a
conditional
block.
So
if
again,
it's
instance
that
local
we're
going
to
use
secret
transforms
to
change
the
name
of
URI
to
connection
strings.
A
So
when
I
run
this
thing
it's
going
to
apply
that
transform
before
it
creates
the
secret,
so
the
secret
that
I
get
will
be
shaped
exactly
like
the
other
one,
and
you
can
do
ads.
Renames
deletes
a
bunch
of
things
inside
of
this.
To
make
the
credential
look,
how
you
needed
to
look
okay,
just
quickly
run
that
so
again,
we're
gonna
do
helm,
install
of
this
chart
and
we're
gonna
set
instance
that
local
to
true.
So
that's
the
crucial
aspect
of
that.
A
Cool
that
instance
is
already
ready
because
it's
local-
if
we
do
this,
we
can't
get
bindings
n
cube
demo
to
there's
the
crazy
long
name,
the
secret
this
week
at
describe
binding
demo
to,
but
obviously
you
don't
see
you
Rin
anymore,
because
that
transform
when
it
wrote
the
secret,
took
care
of
changing
it
into
the
shape
that
I
want.
I
still
have
the
other
ones
like
MongoDB,
password
and
MongoDB
root
password
which
don't
match
so
if
I
wanted
to
use
those
other
four
I
would
need
to
transform
that
one
as
well.
A
But
the
really
nice
thing
is
that
I
was
able
to
install
it
just
by
specifying
that
I
wanted
to
do
the
local
instance,
and
it
did
that
for
me.
So
from
a
developer
point
of
view,
that's
really
great
right,
like
I,
can
run
mini
cube.
I
can
install
Service
Catalog
on
mini
cube,
which
is
super
easy
to
do,
and
I
can
work
with
Service
Catalog
in
the
same
way
that
I
would,
in
a
production
system
deployed
to
some
club.
A
You
know
either
by
my
on-prem
kubernetes
instance,
or
something
to
have
run
in
an
Amazon
or
Google
or
asher,
and
in
both
cases
I
can
use
cloud
resources.
So
when
I
use
mini
cube
locally
and
I'm
Hjelm
installing
my
application,
I
could
totally
use
a
cloud
resource
right
like
if
I've
got
great
bandwidth
and
I,
don't
care
about
the
latency
I
can
totally
deploy
my
application
locally
to
mini
cube
using
service,
catalog
or
I
can
use
this.
A
So
that
is
all
the
examples
that
I
had
so
I'll
turn
over
to
questions
now,
but
first
I
wanted
to
mention.
If
I
can
find
the
paper,
there
are
a
couple
more
service,
catalog
related
talks
today
at
4
o'clock
or
no
sorry
at
1400.
The
six
service
catalog
deep
dive
is
happening.
So
if
you
want
to
learn
more
about
service
catalog,
it's
a
great
place
to
go.
You
can
ask
questions
to
find
out
what's
up
and
then
tomorrow,
at
11
Scott
from
Google
is
gonna.
A
A
A
You
have
a
good
example
yeah,
it's
supportive
to
you
and
you
don't
even
need
examples.
Yeah
so
supported
totally
when
you
create
the
secret
or
when
you
create
the
binding,
it's
totally
supported,
but
I
don't
think
we
have
any
like
helm
examples
to
show
how
to
do
that.
If
you
check
the
docs,
though
it
you
can
find
a
good
example
of
how
to
do
that.
B
A
You
yeah
so
one
nice
thing
is
that
you
can
define
perfectly
for
provisioning,
you
can
you
can
specify
schemas
and
that
works
pretty.
Well,
there
isn't
something
because
the
the
brokers
don't
have
that
specified
credential.
You
don't
necessarily
have
like
a
defined
way
of
knowing
the
head
of
time.
What
they
are,
you
kind
of
have
to
look
at
the
broker:
documentation
yeah.
A
The
schemas
could
show
you
that
we
didn't
get
to
it
in
Ralf
squad
she's
demo
yesterday
when
he
was
showing
the
Visual
Studio
code
stuff.
But
one
of
the
things
we've
just
added
to
Visual
Studio
code
is
the
ability
to
do
this
kind
of
stuff
directly
from
Visual
Studio
code
and
one
of
the
nice
things
it
does
is
iterate
over
the
sacred
that
gets
created,
sticks
that
into
a
helmet
chart
for
you
using
a
for
loop.
A
Basically,
and
then
it
also
generates
a
block
that
you
can
stick
into
your
code,
that'll
name
all
the
environment
variables
out.
So
there
are
ways
you
could
kind
of
then
kind
of
make
that
a
little
bit
better
of
an
experience,
but
it's
not
finding
the
the
spec.
So
there's
no,
like
you
know,
codified
way
that
that
you
can
do
that.
A
A
What
you
do
for
that
is
get
classes,
and
in
this
case,
I
have
a
bunch
of
things
installed.
Obviously,
a
lot
of
things
from
the
Azure
broker,
but
also
the
things
that
come
from
the
helm
from
mini
broker,
so
the
helm,
shirt
from
Rio
DB
and
how
much
are
for
those
sort
of
things
you
can
do
the
same
thing
for
plans.
If
you
want
to
see
what
plans
are
available
if
you
use
Cloud
Foundry,
this
is
pretty
similar
to
the
CF
marketplace,
but
not
in
quite
as
a
nice
format.
A
So
like
as
an
example
from
the
mini
broker.
We
have
Redis
4.8.
So
then
you
know
what
those
names
are.
So
when
you
make
your
helm
chart
or
if
you
want
to
do
the
provision
operation,
you
use
those
external
names,
those
kind
of
friendly
names
too,
to
deploy
the
thing.
That's
how
you'd
know
what's
available
in
the
cluster,
and
it's
totally
based
on
the
broker
right,
like
the
these
things,
are
all
created
when
that
broker
gets
registered.
A
That's
one
of
the
use
cases
for
it
right
like
there
was
an
article
in
Forbes
I
think
a
couple
days
ago,
totally
weird
look
article
in
Forbes
and
the
title
of
the
article
was
kubernetes
plus
open
service
broker.
Api
is
the
key
to
cross
cloud,
so
there
is
absolutely
nothing
that
would
prohibit
me
from
installing
the
AWS
broker
and
provision
things
enable
us
so
I'm
running
in
a
chaos
which
is
after
his
managed
thing.
I
could
totally
install
that
broker
in
nazzer
and
it
would
connect
and
make
things
in
Asscher.
A
A
A
Yeah
yeah,
so
it's
kind
of
up
to
the
broker.
When
you
think
yeah,
the
question
was:
how
does
it
handle
authentication,
there's
two
pieces
of
that
question.
One
is
how
do
you
handle
authentication
between
service,
catalog
and
the
broker
itself,
and
then
how
do
you
handle
authentication
between
broker
and
and
the
thing
that
you're
going
to
provision
to
so
given
the
spec?
Doesn't
specify
really
how
that's
going
to
happen?
It's
kind
of
a
broker
implementation
detail
so
for
the
Azure
broker
right
now
it's
single
tenant,
so
you
can't
provide
multiple
credentials.
A
The
Google
brokers
host
it.
So
it
works
differently
when
you
provision
via
Service
Catalog.
One
of
the
things
you
can
send
is
originating
identity
as
a
header,
so
that
that
can
know
like
from
kubernetes.
This
person
is
doing
this
and
you
can
do
authentication
authorization
against
that.
The
connection
between
Service
Catalog
and
the
broker
itself
is
pre.
It's
a
pre
agreed
authentication
so
either
of
some
sort
of
token
or
username
password
basic
off
for
the
Azure
instance,
a
sure.
A
A
So
if
you
have
the
case
where
you
already
have
that
information,
it's
not
really
a
great
fit
right.
The
the
area
that
it
really
shines
is
when
you
need
to
go.
Do
that
provision
operation
when
you
need
to
go
create
something
probably
outside
of
the
context
of
the
cluster
Cerreta,
has
a
broker
called
the
automation
broker
and
the
way
that
it
works?
Is
you
define
ansible
playbooks
that
really
fulfilled
that
provision
buying
the
provision
workflow
right,
but
those
ansible
playbooks
could
do
anything
you
wanted
to
do
it
could
spin
up
lots
of
vm's?
A
Yes,
that's
not
really
defined
in
the
spec
right
now.
The
way
that
you
probably
handle,
that
is
with
the
user
provided
service,
where
you're
going
to
register
the
credentials
for
that
thing,
and
then
service
catalog
return
them,
so
you
can
use
them
in
the
same
same
way.
There
is
some
talk,
both
in
the
OSB
group
kind
of
a
side
group
about
allowing
you
to
do
two
things.
One
would
be
like
registering
those
external
services
that
you
can
still
manage
like
the
interesting
thing
for
me
with,
like
with
our
Postgres
instance.
A
Our
implementation
is
that
we
do
go
ahead
and,
like
every
time
you
do
a
bind,
we're
creating
a
new
database
user
for
you,
so
you
can
track
those
things
and
rotate
the
keys.
If
you're
just
registering
an
existing
credential,
you
don't
really
get
that.
The
other
thing
is
we're
allowing
we're
talking
about
allowing
you
to
create,
like
additional
databases
on
an
existing
database
server.
So
you
may
have
some
beefy
database
server.
A
You
want
to
create
a
lot
of
databases
on
there's
nothing
in
the
spec
right
now
that
allows
you
to
do
that
kind
of
parent-child
provisioning.
There
are
some
people
that
are
implementing
it
themselves,
like
we
did,
that
for
Postgres
and
for
a
bunch
of
other
services,
like
you
can
say,
provision
me
both
the
database
and
the
DBMS
or
just
provide
me,
the
DBMS
and
then
later
I'll
come
in
and
make
multiple
databases
on
it
again.
It's
a
broker
implementation
right
now,
because
the
spec
is
fairly
tight.
A
Yeah,
so
the
question
was
just
a
still
lock
you
to
another
cloud
provider
in
terms
of
performance
and
those
kind
of
characteristics,
and
that's
true,
like
you,
going
from
Azure
to
Google,
you're
gonna
hit
some
performance
flag
right
because
you're
gonna
go
outside
of
Azure
in
to
Google.
If
you're
running
within
the
same
region.
It's
it's
debatable
like
I.
Think
that's
a
general
cross
cloud
question
right,
like
you,
I'm
gonna
run
clusters
in
different.
A
Firewall
rules
come
into
play
like
what
kind
of
traffic
they're
gonna
do
it
doesn't
solve
those
that's
another
thing
that
people
are
talking
about
like
how
do
we
enable
you
know
this
thing
to
route
to
that
other
service.
The
spec
doesn't
provide
that
right
now.
So
it's
it's
not
a
really
answer
question,
but
it's
definitely
something
people
are
thinking
about.
A
So
what
does
it
take?
What
does
it
take
to
write
a
broker?
That's
your
question!
So
the
broker
API
right
now
is
very
simple.
You
implement
provision,
you
implement,
update,
you,
implement
deep
revision
and
you
don't
implement
unbind
like
those
those
operations
really
plus
you
get
the
catalog.
There
are
starter
packs
for
a
couple
of
languages,
so
pivotal
provides
one
that's
based
off
of
spring
boot.
It's
pretty
simple!
It
gives
you
the
API
surface,
so
you
don't
have
to
worry
about
informing
on
it
yourself,
there's
also
one
for
go.
A
So
there's
a
starter
pack
and
a
starter
broker
lib.
You
can
use
either
one
of
those
things
kind
of,
depending
on
how
much
you
need
to
implement
yourself.
They
give
you
the
same
thing
the
API
surface
and
they
usually
need
to
plug
in
the
business
logic,
for
whatever
you're
going
to
do.
The
other
thing
you
can
do
is
use
the
Red
Hat
danceable
broker,
if
you're
comfortable,
writing,
ansible
scripts
or
I
until
playbooks
to
go.
Do
that
stuff,
it's
a
great
opportunity
to
because
the
broker
runs.
A
Yeah,
yeah
sure,
like
that,
still
comes
down
to
your
your
logic,
so
I
think
we're
out
of
time
clothes
time,
I,
don't
know
yeah
till
35
or
out
of
time
now.
So
thanks
everybody
for
coming
the
still
here.
It
was
great
telling
you
about
serfs,
catalog,
and
the
questions
are
great,
so
I
will
be
in
the
hallway
for
a
little
while
and
also
be
at
the
azure
booth,
the
rest
of
today
all
day
tomorrow.
So
if
you
want
to
talk
more
about
Service
Catalog
feel
free
to
come
on.