►
Description
ConfigMaps 102: Using ConfigMaps in Dynamic Application Deployments - Trevor McKay, Red Hat
ConfigMaps let you “decouple configuration artifacts from image content”. In other words, if you use ConfigMaps wisely in your apps you’ll never have to respin an image just to change a flag. This is a powerful feature which greatly simplifies creating and managing containerized applications. As powerful as they are, however, use of ConfigMaps has typically required a pretty static application deployment -- for example, ConfigMaps must exist before the apps that reference them, their names must be known ahead of time, and it was only recently that the (wonderful) idea of “optional” ConfigMaps was introduced. In this talk we’ll look at several ways we’ve found to use ConfigMaps dynamically in the context of a management platform for Apache Spark clusters we call Oshinko. You’ll leave armed with new ideas of how to leverage the power of ConfigMaps in dynamic applications with a broader set of deployment options.
About Trevor McKay
Trevor McKay is a Principal Software Engineer at Red Hat with a background in distributed computing and big data processing, having worked extensively with Apache Spark on OpenStack and now on Kubernetes. He is passionate about simplifying user experience in general and making analytics accessible in particular.
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
Alright,
so
you're
still
here,
it's
a
430
on
Friday.
A
lot
of
you
could
be
on
your
way
home
on
a
nice
airplane,
but
I
know
why
you're
here
right,
you
were
looking
at
that
schedule
and
you
said:
wait
a
minute.
This
guy's
gonna
talk
about
config,
Maps,
I
gotta,
hear
this
I'm
staying
right.
Is
that
what
happened?
Yeah
I
know
it.
That's
why
I'm
here
right?
A
Okay,
so
all
kidding
aside
you've
heard
a
lot
of
great
tech.
This
week,
there's
been
presentations
on
CR
DS
on
extending
coop.
All
kinds
of
you
know:
Enterprise
kubernetes,
success
stories,
machine
learning,
stuff,
there's
been
a
lot
of
really
great
stuff,
but
today
we're
going
to
take
sort
of
a
new
spin
on
a
golden
oldie.
We'll
take
a
quick
look
at
what
config
maps
are
I'm,
not
going
to
assume
that
you
necessarily
know
right.
This
might
be
your
first
kook
on.
A
You
might
been
have
been
around
kubernetes
for
a
while,
but
you've
just
never
really
run
into
a
config
map.
So
no
worries
we'll
go
over
exactly
what
those
things
are.
We'll
look
at
some
restrictions
related
to
typical
usage
restrictions
are
fine.
Every
design
system
has
some
limitations,
we'll
see
what
those
are
and
then
we'll
look
at
another
way
to
interact
with
these
things
and
it's
not
necessarily
V
method.
A
So,
first
of
all,
what
is
a
config
map
right?
It's
simply
a
kiva.
You
store
that
lives
as
a
kubernetes
object.
They
get
my
pointer
turned
on
here.
So
here's
our
key
right,
there's
Kubb
con.
It's
awesome,
that's
the
value!
Here's
kubernetes!
It's
awesome!
Excuse
me
brilliant,
that's
its
value!
This
is
an
export
of
config
map
object
in
kubernetes
after
I've
already
created
one.
So
it's
just
a
key
value
store
if
you're
familiar
with
Python,
think
dictionary
for
other
languages,
think
associative,
arrays
or
string
Maps,
it's
just
names
and
values.
A
That's
it
and
it
happens
to
live
a
net
CD
all
right.
So
how
do
these
things
make
my
life
better?
The
the
major
benefit
to
a
config
map
is
that
it
lets
you
modify
application
behavior
without
Reese
pinning
an
image
okay.
So
here
we
have
a
couple
of
pods
running:
go
back
to
pointer
mode,
so
here's
our
application
one
and
we
have
a
config
map
here-
config
map,
one
mounted
in
the
pod
as
a
volume.
Okay
and
likewise
here's
our
second
application
and
we
have
config
map
two
mounted
as
a
volume
in
the
application
pod.
A
So
if
you
design
your
applications
so
that
the
malleable
parts
are
expressible
as
as
key
value
pairs
right,
you
can
export
sort
of
the
changeability
outside
of
your
application
image.
And
then
you
can
use
the
same
image
over
and
over
and
over
again,
and
you
don't
have
to
re
spin
to
to
change
something
like
you
know,
the
number
of
backend
threads
you
have
on
a
database
or
something
you
just
make
that
part
of
your
config
right.
So
this
has
been
the
power
of
config
map
since
the
beginning.
This
is
why
they
were
invented
all
right.
A
So
that's
how
they
make
my
life
better.
How
can
I
create
one?
There
are
a
bunch
of
different
ways.
You
should
read
the
documentation,
but
here
are.
This
is
a
pretty
broad
view
here,
which
gives
you
a
lot
of
flexibility.
In
the
top
example,
we
see
we're
just
calling
cute
cuddle,
create
we're
making
a
config
map
called
my
config,
and
we
pass
in
some
literal
values
right.
You
can
stack
these
multiple
flags,
multiple
from
literal
flags,
you
give
it
an
equals
and
then
a
key
and
a
value.
A
So
in
this
case
we're
creating
a
key
name.
Verbose.
The
value
is
true
and
another
key
name
debug.
The
value
is
also
true.
A
second
way
to
do
this
is
to
descend
over
a
directory.
So,
in
this
case,
if
you
use
from
file,
you
can
stage
a
directory
with
a
bunch
of
config
files
in
them
and
what
kubernetes
will
do
is
actually
create
a
config
map
where
every
key
is
a
file
name
and
for
each
each
key.
The
value
is
the
entire
contents
of
the
file.
Okay,
so
that
can
be
quite
powerful.
A
If
you
have
you
know,
yamo
or
json,
descriptors,
all
kinds
of
stuff,
the
only
place
you
can
get
into
trouble,
there's
that
@
çd
puts
a
limit
of
one
megabyte
on
objects,
and
so
your
config
map
can't
be
over
a
megabyte.
So
if
you're,
you
know
putting
lots
and
lots
of
large
files
in
there
just
be
careful
and
of
course,
if
you're
doing
things
a
little
bit
more
interactively,
you
can
just
create
an
empty
config
map.
A
This
way
this
will
have
no
data
section
in
it
at
all,
and
then
you
can
call
cube
cuttle
edit
and
actually
add
the
data
section
by
hand.
So,
with
those
few
techniques,
you
should
be
off
to
the
races,
creating
config
Maps.
Alright,
that
was
how
to
create
one.
How
do
I
consume
one
again?
There
were
a
bunch
of
different
ways.
You
should
check
the
documentation.
You
can
mount
these
things
as
environment
variables.
You
can
do
all
kinds
of
stuff,
but
one
way
that
I
find
that's
really
flexible
to
consume.
A
These
is
as
a
volume
and
the
way
that
you
do
this
is
in
your
pod
spec.
You
simply
declare
a
volume
right
and
your
give
it
a
name,
and
you
tell
it
I'm
waiting
for
that
menu
to
go
away.
You
tell
it
that
the
datasource
is
a
config
map.
I.
Guess
it's
not
going
to
cooperate
with
me
and
you
give
it
a
name
so.
A
A
So,
in
a
nutshell,
any
pod
spec
you
have,
if
you
want
to
mount
a
config
map,
you
add
a
chunk
like
this
to
your
container
or
containers
into
the
pod,
and
what
this
will
result
in
is
when
your
pod
spins
up
this
in
this
container,
you
will
have
at
the
path,
slash
Etsy,
slash,
config,
everything
that
was
in
the
config
map
will
be
expressed
as
a
file
write.
The
file
name
for
each
of
them
will
be
a
key,
and
the
contents
will
be
a
corresponding
value.
A
Okay,
and
these
things
can
be
tiny,
they
can
be
a
single
value.
So
if
you
might
have
something
where
the
file
name
is
dog
and
the
content
is
Fido
and
that's
it,
that's
all
it
that's
in
there
or
it
may
be.
You
know
in
a
tile
an
entire
llamó
file
for
some
application
that
you're
running
all
right,
so
I
love,
config,
Maps,
I.
Think
these
things
are
great.
If
you
haven't
used
them,
you
should
give
it
a
try.
A
It's
a
it's,
a
small
piece
of
tech
in
the
kubernetes
world,
but
it's
it's
a
it's
really
powerful,
but
there
are
some
limitations
right.
There
are
all
those
limitations
you
can't
design
for
everything.
So
what
are
some
of
these?
Well,
the
name
must
be
known,
and
what
this
means
is
that
the
name
of
a
config
map
that
you're
consuming
in
a
pod
has
to
be
known
at
pod
creation
time.
Okay,
you
can't
get
away
with
an
empty
string.
A
Kubernetes
won't
let
you
do
that
it's
an
error,
so
it
has
to
be
a
definite
name
if
you're
using
some
kind
of
a
templating
engine.
That
gives
you
a
little
bit
more
flexibility
so
that
you
can,
you
know,
generate
your
pod
spec
from
a
from
a
template.
You
can
pass
the
name
in
that
way,
but
the
fact
Rene
remains
that
you
must
have
a
definite
name
for
this
thing
when
the
pod
gets
created,
update
latency.
A
So
if
you
have
one
of
these
things
mounted
into
a
config
map
as
a
volume
and
you
change
the
config
map,
it
will
be
up
to
one
pod,
sync
interval
latency
before
the
updates
get
written
through
and
by
default.
That's
a
minute
now
for
some
applications.
This
may
not
matter,
you
know,
might
be
fine
that
the
config
will
change.
You
know
up
to
a
minute
after
you've,
actually
written
to
the
config
map.
Some
applications
may
care
all
right,
they're,
not
easily
composable.
So
what
I
mean
by
this
is
there
is
no.
A
There
is
no
built-in
way
to
have
a
config
map
where
a
field
value
in
one
config
map
actually
refers
to
another
config
map
right,
so
you
can
kind
of
imagine
you
could
take
a
large
complicated
configuration
and
you
could
break
it
up
into
a
hierarchy
right
where
you
have
your
top-level
config
and
then
you
break
some.
You
know
piece
of
it
out
some
aspect
of
your
app
and
put
it
in
a
different
configuration.
A
Ocd
this
with
config
Maps
out-of-the-box
and
lastly,
order
matters.
There's
a
caveat
on
this.
Well
I'll
get
to
I'll
get
to
in
a
minute.
If
you
reference
a
config
map
in
a
container
spec,
the
config
map
must
exist
before
the
container
will
be
created.
I've
done
this
to
myself.
It's
not
always
immediately
apparent
as
a
developer,
why
your
container
is
stalled
and
is
not
being
created
unless
you
start,
you
know
pouring
into
the
events,
but
if
you
reference
a
config
map,
that's
not
there.
A
Your
container
will
just
I
forget
which
state
it
ends
up
in
container,
creating
or
pending,
or
something
but
it'll
just
sit
there
forever
right.
Now,
the
caveat
on
this
is
in
1-6.
There
was
this
awesome
PR
where
the
optional
keyword
was
added,
so
you
can
actually
call
out
a
config
map
as
optional,
and
in
that
case,
if
you
do
that,
and
it
doesn't
exist,
your
container
will
start
up
anyway
and
in
the
case
of
volume,
mounted
config
maps.
If
you
do
add
it
later
that
data
will
get
written
through.
A
However,
you
still
run
up
against
the
issue
that
you
have
to
have
a
definite
name
ahead
of
a
time.
You
know
empty
string,
isn't
good
enough
and
you
have
the
latency
issue,
but
this
was
a
big
help.
So,
if
you're
running
on
1/6
or
greater
that's
good,
there's,
probably
some
you
know
Enterprise
production
type,
people
who
are
still
on
1
5
or
earlier
because
right,
you
can't
be
changing
every
3
months.
So
what
is
an
alternative
method?
A
Here's
my
path
in
the
woods
like
I
said
I
have
another
way,
I'm,
not
saying
like
it's
the
way.
It's
just,
hopefully
something
that's
useful
to
you
and
what
is
that
all
right?
So
it's
a
more
dynamic
application
model
and
in
this
case,
what
we
do
is
we
just
embed
a
tiny,
kubernetes
client
inside
our
application,
which
talks
to
the
API
server
for
us
and
allows
you
to
consume
config
Maps
dynamically.
Now
this
isn't
necessarily
novel
if
you've
existed
in
the
kubernetes
core
or
you're
already
making
CR,
DS
or
you're,
making
API
extensions.
A
You
know
you're
writing
deployment
pods,
that
kind
of
stuff
you're
already
used
to
having
access
to
the
API
inside
your
pods
right.
But
there
are
a
lot
of
us
I,
think
developers
who
view
our
applications
really
strictly
as
running
on
kubernetes
right.
We
don't
think
of
ourselves
as
part
of
the
ecosystem
and
so
I
think
for
for
those
of
us
on
sort
of
that
side
of
the
game.
A
Yes,
yeah
and
I'm
gonna
show
you
how
all
this
works
right.
Okay,
so
that's
the
basic
model.
We
get
some
benefits
from
this.
What
what
are
those
well
really
quickly
going
back
through
referring
to
some
of
the
limitations,
did
before
order?
Doesn't
matter
right
if
you're
controlling
this
stuff
yourself
create
things
in
whatever
order
you
want.
Likewise,
you
have
flexible
naming
right.
If
you
want
to
leave
your
config
map
with
an
empty
string,
go
right
ahead
as
long
as
your
application
can
handle
it.
A
If
you
have
a
polling
interval
that
is
appropriate
for
your
app
go
ahead
and
pull
if
you
want
to
do
read
on
demand
every
time
you
hit
a
particular
piece
of
processing,
and
you,
if
you
know
that,
that's
you
know
infrequent
and
it's
not
gonna
overdrive.
The
API
server
or
anything
do
it
that
way.
You
know
if
you
receive
some
event
through
a
Kafka
queue
or
something
that
tells
you
hey
your
config
just
got
updated.
Why
don't
you
reread
it?
You
could
do
that.
The
point
is
you
have
choice
right?
A
You
can
you're
not
limited
to
updates
with
this
variable
duration
up
to
a
pod
sync
interval
anymore.
You
can
no,
you
can
update,
definitely
in
bounded
time
all
right.
You
also
get
composability
like
I
talked
about
before.
So
let's
pretend
we
have
a
web
app
here.
We've
broken
out
our
theme
and
our
scale
as
separate
configs.
Maybe
I'll
grab
the
pointer
here,
so
just
assume
dot,
dot,
dot
means
really
huge
right,
which
is
why
you
would
want
to
break
these
things
out
in
the
first
place,
but
we
have
a
western-themed
with
some
desert
and
cactus.
A
We
have
some
scale,
but
let's
say
that
we
run
this
thing
for
a
while
and
we
just
okay
I
really
need
a
large
scale
right.
So
I
go
and
I
define
a
large
scale
and
then
I
want
to
take
my
running
app
and
scale
it
up.
So
I
can
just
do
this
right.
I
can
just
go
into
my
top-level
config
change
this
one
entry
in
my
top-level
config
map
to
large
right
and
as
long
as
my
application
understands
that
this
is
my
convention
that
I've
set
up.
This
is
my
design.
A
A
Is
the
authentication
mechanism
you'll
see
that
in
a
few
minutes,
if
you're
running
a
client
there's
a
little
bit
of
off
code,
and
if
you
pull
that
out
and
separate
it
from
your
your
main
routine,
you
can
reuse
the
same
code.
So
here
we
are
in
a
pod.
Here
we
are
out
of
a
pod
running
on
a
laptop.
You
can
use
the
same
client,
snippet,
okay,
so
some
people
might
say.
Well,
maybe
this
is
too
much
right.
The
kubernetes
api
is
big.
A
You
know
there
might
be
a
security
risk
here,
because
I'm
exposing
more
of
the
API
surface
area
in
my
pod
I
might
be
pulling
down
lots
and
lots
of
dependencies,
and-
and
this
has
me
worried-
I'm-
not
sure
that
I
really
want
to
go
here.
But
what,
if
you
can
do
this
right?
What
if
you
take
the
API
and
you
take
that
huge
stack
of
books
and
turn
it
into
just
a
little
tiny
piece
that
you
need
right
in
our
case?
A
In
this
example,
all
we
need
is
a
single
call
to
get
on
a
particular
namespace
for
a
config
map.
Right,
that's
a
tiny
part
of
the
kubernetes
api.
Your
client
doesn't
need
to
actually
include
anything
other
than
that,
so
your
dependencies
are
limited
in
your
surface
area
is
limited
and
I.
Think
if
you
do
that,
then
the
risks
are
negligible
and
it's
worth
doing.
A
Okay.
So
let's
actually
look
at
this
thing
and
go.
This
is
the
actual
routine
I'm
going
to
show
you
in
a
demo
later.
The
only
difference
is
that
I
put
a
loop
around
it
for
the
demo.
Okay,
so
what's
in
here?
Well,
there's
our
client
set.
This
is
the
result
of
the
off
call
we'll
see
that
in
a
minute,
this
is
the
part
that
you
break
out
so
that
you
could
run
in
a
pod
or
outside
of
a
pod.
A
We
pass
in
a
name
a
directory
in
a
namespace
as
arguments
right,
so
those
are
pretty
simple.
This
right
here
is
the
core
of
this
whole
thing
right.
It's
a
get
on
a
config
map
in
a
particular
namespace,
and
what
you
get
from
this
is
a
string
map.
Okay,
it's
just
just
a
map
of
strings
I.
Don't
know
how
to
explain
it.
If
you
loop
over
this
thing
and
go
right,
you
loop
over
it
and
you
get
key
value
pairs
back
and
from
this
point
on
this
is
just
normal.
A
Processing
right
doesn't
have
anything
to
do
with
kubernetes
it's
what
you
would
do
anywhere,
so
I
get
keys
and
values.
I
create
a
new
path
based
on
the
key
I
open
a
file
and
I
write
my
string
boom.
That's
it
right!
So,
with
this
little
fragment
of
code,
you
can
read
config
Maps
all
day
long
and
write
them
to
a
directory.
Okay,
so
authentication
stuff
in
a
pod.
It
looks
like
this.
This
reads
your
config
from
the
pod
environment.
This
gives
you
a
client
set
and
you
return
it
outside
of
a
pod.
It's
very
similar.
A
A
Let's
see
here,
let's
start
fresh,
all
right,
so
I
don't
know.
If
you
can
see
that
okay,
let
me
blow
that
up
a
little
bit.
Does
that
look
pretty
good?
Let's
look
at
what's
in
our
you'll
file!
First,
it's
very
simple:
okay,
we
have
a
pod
here,
we're
just
going
to
run
this
pre-staged
image
that
I
created
you'll
notice,
if
you're
really
observant
that
this
is
setup
for
local
access.
A
A
A
A
A
And
this
is
how
you
add
a
data
section
and
we
will
give
Bob
a
car
he's
got
a
Ford.
He
likes
antiques,
so
we'll
give
them
a
Model
T
and
now
we
should
see
this
update
here
there
we
go
so
we're
polling
every
10
seconds.
We
saw
that
we
changed
and
now
we're
rewriting
our
config
directory.
You
see
that
we've
got
a
file
for
make
and
a
file
for
model.
So
we
can
do
this
all
day.
A
We
can
change
the
car
he
owns,
we
can
delete
Bob
and
it
will
keep
updating
but
I
think
you
get
the
idea
there,
let's
see.
So
if
we
go
back
to
our
presentation,
there's
something
else.
I
want
to
show
you
we
got
about
12
minutes
left
I
want
to
show
you
a
real
world
example
that
was
intentionally
simple,
so
you
could
see
how
it
worked.
Hopefully
that
made
sense
to
you.
A
I
work
on
a
project
called
rad,
analytics
I/o
and,
as
the
text
here
says,
it's
a
it's
about
empowering
insightful
data-driven
application
development
on
OpenShift,
so
the
piece
I
want
to
show
you
of
this
today
is
a
tool
we
have
for
creating
smart
clusters
very
easily
and
it
uses
some
of
these
techniques
to
let
you
configure
the
spark
cluster.
So
this
is
one
little
part
of
of
what
we're
doing,
but
I
have
links
up
to
our
site
at
the
end,
if
you
are
interested,
so
what
is
a
containerized
spark
application?
A
A
How
do
you
create
one
using
read,
analytics
I/o
tools?
Well,
we
have
a
tool
called
ocean
Co,
it's
very
simple.
It's
a
little
CLI
and
you
just
say,
create
my
cluster
and
in
this
case
the
default
number
of
workers
is
one,
but
we're
gonna
tell
it
here
to
create
two
workers.
So
that's
pretty
simple,
but
you
can
also
do
it
this
way.
A
This
is
sort
of
an
idealized
view
of
how
it
uses
them.
Here's
our
top-level
config.
We
include
things
like
how
many
workers
you
want.
We
let
you
turn
on
optional
services
like
this
oops
that
turns
on
spark
metrics.
We
won't
actually
see
that
today
and
then
here
this
is
where
we
use.
The
composability
spark
takes
its
configuration
from
a
bunch
of
yeah,
a
bunch
of
files
just
like
if
you've
ever
done,
anything
with
HDFS
right
Hadoop
is
configured
in
the
same
way.
It
has
a
collection
of
files
in
the
in
the
config
directory.
A
So
we
put
an
entry
for
the
spark
master
config
in
an
entry
for
the
spark
worker
config,
but
ischenko
expects
that
these
are
the
names
of
other
config
maps
right.
So
we
have
another
one
called
debug
master:
it's
got
a
log4j
properties
file
in
there
that
controls
logging.
You
can
put
metrics
properties
in
there.
You
can
put
spark
defaults
comp
in
there.
Those
should
actually
be
lower
cased.
There's
a
typo
in
the
slide
anyway.
A
Just
know
that
when
we
want
that
to
throw
you
off
and
we've
got
the
same
thing
for
the
worker
config
down
here
right,
so
we
break
these
things
out.
So
what
does
this
look
like
in
an
actual
run,
so
here's
ocean
co
running
on
our
laptop
outside
of
kubernetes,
we're
going
to
create
a
cluster
from
our
command
line
and
we're
gonna
hook
a
spark
application
up
to
it
later,
so
it
uses
an
embedded
client
like
the
one
we
just
saw
to
go
and
read
the
debug
config.
It
reads
that
and
finds
out.
A
Oh
okay,
this
thing
has
a
spark
master
config
in
it
that
points
to
another
config
map
named
debug
M,
so
I
am
going
to
go,
create
the
master
pod
and
in
this
case,
since
I'm,
actually
generating
the
pod
spec
I
go
ahead
and
mount
it.
The
good
old
fashioned
way
right.
I
generate
the
pod
spec
and
just
add
the
config
map
as
a
volume.
A
A
This
stuff
runs
on
open
shift
from
Red
Hat,
which,
if
you've
seen
other
presentations,
is
really
kubernetes
package
for
the
enterprise
it
Skoob
with
extensions,
but
it's
the
heart
of
it
is
kubernetes.
So
there's
really
nothing
different
here.
So
here
we
created,
we
spun
up
a
master
and
we
spun
up
a
worker.
This
is
our
tiny
spark
cluster
I'm
going
to
show
the
show
you
the
effect
of
the
config.
So
something
really
easily
observable
is
I,
don't
know
if
you
can
see.
A
That
is
the
logging
level
you
can
see
here
that
you've
got
like
regular
old
info
level.
Logging
in
the
master
pod
all
right.
So
let's
go
back
to
our
command
line
here.
What
if
we
want
to
create
another
one
right?
Actually
let
me
get
that
up
on
screen
a
little
bit
more,
so
you
can
see
it
well,
that's
not
gonna
help
is
it.
Maybe
I
can
shrink
the
window
all
right,
that's
a
little
higher
up.
So
if
I
do
ocean,
Co
create
my
second
cluster
and
I,
give
it
a
stored,
config
called
cluster
config.
A
It
went
and
created
a
second
cluster.
Now,
if
we
do
this,
let's
just
do
an
OC
export
here.
Oc
is
the
open
shift,
client
and
it
has
a
cool
extra
command
called
export,
which
gives
you
a
nice
view
of
objects
without
all
the
extra
values
in
them.
You
can
see
that
our
config
map,
in
this
case
called
for
three
workers
and
I,
had
an
an
spark
master,
config
called
out
and
a
worker
config
right.
So
if
we
go
back
here,
we
should
see
a
different
kind
of
cluster
and
we
do
here's
our
our
master.
A
A
Master
config
there
we
go
so
this
is
what
a
config
map
with
files
embedded
in
them.
Look
like
you
can
see.
Here's
the
data
section,
here's
the
key
name
right,
which
ends
up
being
a
file
name
and
then
you've
got
kind
of
the
the
yeah
mold
designation
for
multi-line
stuff.
You
have
the
license
file
and
everything
in
here
right.
So
that's
what
we
passed
in,
but
it's
nice
that
you
can
hide
these
things
away
and
using
that
little
composability
trick.
A
Okay,
so
I
need
to
go
back
to
where's
my
presentation
there.
It
is
all
right,
so
that
was
the
end
of
my
demos,
takeaways,
so
wire
config
back
it's
good
in
general,
you
can
change
behavior
without
a
Rhys
pin
they're
powerful
with
a
few
limitations
which
may
not
affect
you,
but
if
they
do
reading
it,
dynamically
is
very
easy.
A
Gives
you
a
ton
of
flexibility
and
it's
safe
is
if
you
use
a
small
scoped
client
that
doesn't
have
superpowers
you're,
not
really
endangering
anything,
I
mean
the
only
thing
our
extra
client
can
do
in
that
pod
is
read
a
config
map
and
it's
scoped
to
the
project.
Right
so
I
mean
you
can't
even
read
anybody
else's
stuff.
Not
very
dangerous
here
are
links
to
all
of
our
stuff.
I'll
leave
this
up
here.
If
you
want
to
take
a
picture
of
it,
rad
analytics
IO
is
our
community
landing
site?
A
If
you
want
to
see
more
about
the
work
that
we're
doing,
we
have
images
up
on
docker
hub.
Our
github
is
listed
here
and
the
little
looping
example
that
I
showed
you
first
I
actually
threw
up
the
the
pod
spec
and
the
code
for
that
on
my
github
account
in
case.
You
want
to
take
a
look
at
it
and
play
with
it.
It's
based
on
the
client
go
examples.
A
So
it's
pretty
easy
to
consume,
go
away,
go
away,
and
there
is
my
my
email
address
is
there
on
the
bottom,
but
it's
occluded
there
we
go
alright,
so
the
easiest
way
to
get
in
touch
with.
If
you
have
questions
or
comments
on
this
stuff
or
you
want
to
know
more
about
what
we're
doing
is
just
send
me
an
email
and
with
that
we've
got
three
minutes
for
questions.
I
mean
the
truth.
A
B
A
The
that's
one
of
the
things
that
makes
composability
kind
of
cool
that
the
limit
on
the
size
of
a
config
map
is
one
megabyte
across
your
whole
data
section.
So
that's
a
lot.
That's
a
lot
of
config,
but
if
you
ran
up
against
the
megabyte,
you
could
simply
chunk
it
up.
You
know
it's
like
packet,
izing
right,
you
say:
okay,
fine,
I
need
way
more
than
a
megabyte.
C
A
Are
you
asking,
can
multiple
applications
use
the
same
config
map?
At
the
same
time,
yeah?
That's
fine!
A
config
map
can
be
mounted
in
multiple
places.
The
downside
on
that
is,
if
you
change
the
config
map
for
one,
you
change
it
for
everybody
right.
So
in
that
case,
you
have
to
decide,
do
do
I
actually
want
to
be
able
to
change
the
configuration
for
applications
individually,
or
is
it
fine
to
change
them
as
a
group,
and
then
you
just
design
accordingly?
Okay,.
C
A
I
mean
you
could
you
could
give
if
you
have
multiple
instances
that
same
application,
you
can
set
each
one
to
read
a
different
name.
You
could
you
know
you
could
do
the
same
config
map
but
set
up
some
different
event
stream
to
cute
each
individual
application.
Like
okay,
read
this
once
and
cache
it
unless
I
tell
you
different
and
then
like
okay,
you
pay
attention
to
this
signal.
You
pay
attention
to
this
one.
You
pay
attention
to
this
one
and
then
you
know
key
them
to
to
read
individually.
You
could
do
all
kinds
of
stuff.
A
A
A
So
yes,
you
need
so
so
out
of
the
box
right.
The
role
that
you
need
is
edit.
Ok,
edit
gives
you
read
and
write,
but
that's
the
one
you
that
you
get
out
of
the
box.
However,
its
scope
to
the
namespace,
so
you
don't
get
edit
for
everybody
and
if
you
want
to
restrict
it
lock
it
down
further
than
that,
you
can
create
a
custom
role
which
only
has
access
to
get
right,
not
even
access
to
lists,
or
you
know
other
read
operations
and
indefinitely,
not
access
to
right.
A
A
If
you
run
without
doing
that,
and
you
run
a
version
of
this
with
a
error
handling
still
in
the
code
it
will,
it
will
tell
you
such-and-such
serve
service
account,
doesn't
have
privileges
to
read
config
maps
in
this
project.
So
it's
easy
to
see
if
you
actually
have
that
turned
on
like
oh
yeah.
I
have
to
go
at
this,
so
good
question.
A
Yeah
no
proxy,
so
in
that
off
code
from
okay.
So
so,
let's,
let's
say
you're
in
the
open
shift
land
in
OpenShift.
You
have
to
log
in
with
credentials.
You
know
ahead
of
time
and
then
it
modifies
your
coop
config
file.
So
it's
pointing
to
the
local
master.
It
knows
what
the
API
is,
and
it
knows
what
your
credentials
are
and
in
mini
cube.
It's
the
same
thing
except
you
don't
have
to
do
the
initial
login,
it's
just
when
you,
when
you
bring
up
mini
cube
it
modifies
your
local
coop
config.
A
So
when
you
run
that
little
those
little
authentication
code
snippets
that
I
put
on
the
slide
that
reads
your
coop:
can
your
coop
config
file
and
builds
the
client
set
for
you,
and
that
thing
knows
where
the
URL
for
the
kubernetes
master
is
so
there's
no
proxy
in
the
way
you're
just
talking
directly
to
the
kubernetes
master,
on
whatever
port,
it
is
what
is
it
like
port
5,000
or
something
you're
talking
directly
to
the
API
server
at
that
point?
So
anyone
else
since
we've
got
the
rest
of
the
afternoon.