Overview of experiences with Docker at Inbot.

1. Docker Experience
at Inbot
Jilles van Gurp

2. Who is Jilles?
www.jillesvangurp.com, and @jillesvangurpon *
Java (J)Ruby Python Javascript/node.js
Servers reluctant Devops guy Software Architecture
Universities of Utrecht (NL), Blekinge (SE), and Groningen (NL)
GX (NL),Nokia Research (FI), Nokia/Here (DE),Localstream (DE),
Inbot(DE).

3. Inbot app - available for Android & IOS

4. Reluctant Devops, so I Docker
Ops: I need it it done and I need it done right, so I can move on with Dev
If you want something done right: DIY.
Rant: Ops keeps sucking up my dev time; source of technical debt as well
because I don't actually have time to do it "properly" (for varying definitions of
properly). I need less Ops in my life; not more.
Docker is generally helping me to get closer to that goal.
It is also immature, flaky, and a bit of a moving target.

5. What is Docker?
Simple question, lots of answers,
beware bad metaphors & analogies
Bla bla cgroups bla bla security bla bla archaic
kernel stuff that has been around for ages but was
way to tedious to deal with for mere mortals
IMHO: 'standardized' way of building, packaging, running & configuring
software -> fixes a real problem!
clean separation between software provisioning (aka. DEV) and infrastructure
provisioning (aka. OPS)
https://en.wikipedia.org/wiki/Docker_(software)

6. Docker history @Inbot
2014 Just puppetized Inbot, looking at ansible. Hey: there's this cool new thing
called docker.
2015 Lets get our ass out of Hetzner and get rid of puppet; Docker!?
2016 Inboot: AWS, Cloudformation, ECS & Docker
2017 Lets cut some cost. Replace Inboot with Das-Boot.
2018 Who knows ...

7. Docker & Devops: separation of concerns
DEV: produce software & package it up as a docker image.
OPS: provision infrastructure to run the docker images
Interface between Dev & Ops == Docker + CI builds.
Installing software dependencies no longer an Ops concern.
No deployment time overhead for installing stuff (already in the container).
OPS part can be automated (das-boot)

8. What I love about Dockerfile
Dockerfile LOC <<<< Puppet/Ansible/Salt/whatever LOC.
WYSIWYG software provisioning:
ENV foo=bar
RUN whatever command
no silly magic
Reads like documentation for all the stuff you need to get something running.

9. Docker ecosystem
Snakeoil sellers are having a great time, once again. Usual suspects + a few new
ones ...
Smells:
Your docker infrastructure requires more hardware than your app
Anything you buy into is obsolete 6 months down the road.
Documentation: here's hello world, ops stuff left as an exercise to the reader.
TODO: Security? Logging? Service discovery? Configuration? Monitoring? Best
practices? ...

10. Our builds: docker build whatever
We have 1 managed script on our jenkins that does this on repos where we use it:
1. docker build . (downloads the world, compiles & tests)
2. docker push image,
3. trigger das-boot deploy to environment associated with branch (if any)
Das-boot == docker container with our deployment scripts (node.js, aws-cli, and
cloudformation yaml)
Dockerized build pipepline

11. Yay Layers & caching

12. Yay layers (2): Our production deploy process
merge master to newproduction
newproduction src now identical to master
docker build reuses most of the
layers of our master build
tests already ran for master build
so jumps straight to deploy

13. Logging: GELF log driver on every docker host

14. Also syslog, beware the OOM Killer

15. Ran into this one today ….

16. Unresolved/rapidly evolving stuff
Kubernetes vs. Docker Swarm vs. Amazon We Don't Quite Have This Yet?
Consul, Etcd, Zookeeper, DIY dns hacks (yay route 53)?
Fun fact: AWS doesn't do service discovery, yet. So what will they do and when?
Rkt vs. Docker vs. ...?
Network overlays? Security? Logging?
Running stateful services heavy storage requirements?
Running stateful, clustering services?
What about a batteries included Docker ready PAAS + CI + Monitoring + Logging + Alerting + Sane
defaults + ...?

17. QA?
@jillesvangurp, @inbotapp