@lukeb0nd
http://yld.io
Luke Bond
CoreOS London November 2014
@lukeb0nd
http://yld.io
British Gas: Connected Homes (makers of Hive)
@lukeb0nd
http://yld.io
It has been an interesting project with interesting challenges, and more or less greenfield.
@lukeb0nd
http://yld.io
@lukeb0nd
http://yld.io
Therefore we opted from the beginning for a rigorously tested continuous deployment approach.
@lukeb0nd
http://yld.io
@lukeb0nd
http://yld.io
@lukeb0nd
http://yld.io
@lukeb0nd
http://yld.io
Or "units are more than just runners of Docker containers"
@lukeb0nd
http://yld.io
Example
$ fleetctl cat jq.service
[Unit]
Description=Install JQ
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/bin/mkdir -p /opt/bin
ExecStart=/usr/bin/curl http://stedolan.github.io/jq/download/linux64/jq -o /opt/bin/jq
ExecStart=/usr/bin/chmod +x /opt/bin/jq
[X-Fleet]
Global=true
@lukeb0nd
http://yld.io
@lukeb0nd
http://yld.io
Cluster presented as a systemd abstraction
Think: systemd of multiple hosts "taped together" to appear as one, using Etcd
Docker makes "abstracting the host" possible, but Fleet delivers it
You now think about the cluster, not hosts
I can't imagine going back from this thinking now :)
Very powerful when combined with 12-factor principles
@lukeb0nd
http://yld.io
@lukeb0nd
http://yld.io
@lukeb0nd
http://yld.io
Great for development
Fig instead of Vagrant
Great for testing
Fig for functional/acceptance tests
`docker build/tag/push` on green
Great for deployment
`docker pull`, `docker run`
@lukeb0nd
http://yld.io
I now naturally tend towards smaller, simpler, composable services
Docker and Node.js work really well together
Single-threaded* event-driven model maps well to the "one process per container" Docker model
(I don't like the supervisor model**, especially when you have systemd)
@lukeb0nd
http://yld.io
CoreOS terminal is a PITA
Etcd cluster losing quorum
CoreOS don't seem to have a recommended way of replacing an Etcd cluster, or dealing with this issue
Separate Etcd cluster?
Complex ordering systemd units for asynchronous tasks
e.g. not starting unit until EBS volume attached
Likewise detaching cleanly
@lukeb0nd
http://yld.io
It's a dangerous business, Frodo, going out your door. You step onto the road, and if you don't keep your feet, there's no knowing where you might be swept off to.
– J.R.R. Tolkein, The Lord of the Rings
We're using a lot of new technology at once
That wasn't the plan, but it was like tugging at a thread!
Or "swallow the spider to catch the fly", at times
@lukeb0nd
http://yld.io
May you live in interesting times
– Chinese Curse (apocryphal)
I look forward to when Docker networking is solved
@weavenetwork from Zettio looks very promising
But these early days of Docker are exciting times
Beware complex and gnarly service discovery solutions
@lukeb0nd
http://yld.io
Tricky to balance keeping it simple with robustness
Complexity and number of moving parts can skyrocket if you're not careful
For us, startup-time service discovery not enough
Needed dynamically configured internal load-balancers
Beware potential DNS implications
@lukeb0nd
http://yld.io
Mount volumes (of course)
Databases don't always like moving hosts
e.g. Couchbase, depending how it's configured
When choosing a DB, consider how running in Docker affect that choice.
i.e. how does it cluster/replicate?
Couchbase, Riak, Cassandra compared to MongoDB, CouchDB, MySQL?
@lukeb0nd
http://yld.io
Keep your wits about you
Keep it simple
Keep services small*
Expect services to move hosts
Accept limitations in order to simplify
Define per-host services via global units rather than in user-data
Get carried away
Neglect to consider persistent storage
Treat hosts like pets
Stovepiping
Force apps to do anything special in order to work
@lukeb0nd
http://yld.io
@lukeb0nd
http://yld.io