4. Clocker
• What
does
it
do?
– Spin
up
and
manage
Docker
clouds
– Serve
up
containers
on-‐demand
• What
is
it?
– Apache
Brooklyn
Applica<on
– Apache
Brooklyn
Loca<on
• Who
started
it?
– Andrew
Kennedy
@grkvlt
6. Orchestra<on
–
The
New
Fron<er
“The
way
in
which
Docker
has
enabled
workloads
to
migrate
across
any
opera<ng
system
and
any
environment
has
really
kind
of
freed
up
development
and
opera<ons.
We
want
to
keep
them
going
at
the
next
layer
of
the
stack,
which
is
orchestra2on.
Docker
containers
have
been
around
for
15
months,
so
the
developers'
tools
around
them
have
an
even
shorter
lifecycle.
We're
in
the
very
early
days
of
the
category.”
Sco$
Johnston,
SVP
Product,
Docker
7. Clocker
Project
• Open
Source
• Apache
Licensed
• S<ll
in
Beta
– 0.7.0-‐SNAPSHOT
– h@p://brooklyncentral.github.io/clocker
8. Apache
Brooklyn
• Open
Source
• Donated
to
the
Apache
So^ware
Founda<on
• h@p://brooklyn.incubator.apache.org
• Started
by
@ahtwee<n
13. Apache
jclouds
• Drivers
for
REST
APIs
• Docker
Driver
– Created
by
Andrea
Turli
@turlinux
• Virtual
Container
– Using
SSH
Daemon
– Same
Endpoint
Type
as
VM
– Composi<on
on
any
Image
or
Dockerfile
14. Weave
• So^ware
Defined
Networking
– Ethernet
Switch
– User
Space
– Docker
Container
• Sniffs
Traffic
on
Host
• Forwards
over
TCP
• h@p://github.com/zepo/weave/
21. Clocker
Features
• Applica<on
Deployment
– Oasis
CAMP
Blueprint
– Same
as
Core
Brooklyn
• Mixed
Des<na<ons
– Some
Virtual
Machines
– Some
Bare
Metal
– Some
Containers
22. Clocker
Features
• Applica<on
Deployment
– Oasis
CAMP
Blueprint
– Same
as
Core
Brooklyn
• Docker
Extensions
– Container
or
Image
– Placement
Strategy
– Dockerfile
URL
23. Clocker
Placement
• Demand
Side
– New
Container
• Supply
Side
– Where?
– Placement
Strategy
– Provisioning
Strategy
24. Clocker
Placement
• Placement
Strategies
– Depth
First
– Breadth
First
– CPU
Usage
– Affinity
or
An<
Affinity
– Memory
or
CPU
Core
Availability
25. Clocker
Placement
• Provisioning
Strategy
– New
Docker
Host
Loca<on
• Constraints
– Docker
Infrastructure
Constraints
– En<ty
or
Applica<on
Constraints
• User
Defined
Strategies
• Intelligent
Container
Orchestra<on
27. Container
Management
id:
dockerfile-‐mysql
name:
Docker
Hub
MySQL
Application
origin:
"https://registry.hub.docker.com/_/mysql/"
locations:
-‐
my-‐docker-‐cloud
services:
-‐
type:
brooklyn.entity.container.docker.application.DockerfileApplication
id:
mysql
name:
MySQL
brooklyn.config:
docker.dockerfile.url:
file://Users/grkvlt/Git/docker-‐library/mysql/5.6/
env:
MYSQL_ROOT_PASSWORD:
"s3cr3t"
28. Container
Management
• Installa<on
of
Services
– Defined
by
Brooklyn
or
Dockerfile
– Common
to
all
En<ty
Instances
• Commit
Image
– Available
for
next
En<ty
• Push
Image
– Available
for
all
Hosts
29. Networking
• Shared
Weave
LAN
– Common
to
All
Containers
– Private
(Link
Local)
Addresses
• Clocker
Controls
IP
Alloca<on
– Applica<ons
Segmented
by
CIDR
• Docker
Port
Forwarding
Access
30. Networking
• S<ll
First
Steps…
• Name
Resolu<on
– BIND
and
DNSmasq
– Needed
for
JMX
et
al
• Enables
Many
More
En<<es
• But
Needs
Tested!
36. Roadmap
Now
• Improvements
To
Networking
– DNS
and
DNSmasq
Integra<on
– Work
in
Progress
• Be@er
Gepng
Started
– Self
Hos<ng
on
Localhost
– Brooklyn
Dockerfile