Docker UserGroup Hamburg

• Betahaus Hamburg
• Eifflerstraße 43
• 22769 Hamburg

Introduction Docker

General

By Johannes Ziemke from docker

What is Docker

• version 1.0 released a few hours ago - api stable (a bit)
• written in go
• build, packs and ships applications as lightweight containers
• build once an run almost everywhere (since kernel 3.8.*)
• rewrite of docCloud PaaS code

Benefits

• start always from clean slate
• spawn up complete test infrastructures in seconds
• run your code against multiple versions easily
• easy up setup of software environment
• distribute complex setups as self-contained containers
• build own infrastructure
• easy ups deployment per day
• scaling and mantaining of infrastructure (state convergence, manage everything)
• helps you to solve managing complexity
  • similar problems
    • modules, classes, plugins
    • human communication: named concepts like car, cat or container
    • shipping goods: intermodal containers
  • solution: create an abstraction
    • does not matter what is in the container nor where it runs
    • clear separation of concerns (reduce communication between developers and ops)
    • developer can take care about used libraries, packagemanager, ...
    • op can take care about the system (alos resource planning and monitoring)
• running commandos on top of:
  • immutable, shipable, layered images (defined by dockerfile, built by builder and pushed/pulled to registry)
  • copy-on-write storage on top (provides writeable layer on top of read only images to persists changes done by running container)
    • aufs
    • btrfs
    • devicemapper
  • isolated environment
    • using kernal features
      • namespaces (isolation by scoping, available: pid, mnt, net, uts, jpc, user)
      • cgroups (limit, accound and isolated general devices, cou, memory, ...)
      • future (solaris zones ...)
  • via RESTish API
  • missing pieces
    • docker can not address service discovery or dynamic scheduling
    • projects to close the gap
      • openstack
      • coreOs
      • mesos + marathon
      • flynn.io

Demotime

• --privileged - can break out of container but control host
• images are read only and creating a container on each start
• docker commit - creates new image out of running container
• use boot2docker

Continous Delivery with Docker

By Tobias Schwab from Dynport GmbH

Philosophie

• continous delivery
• canarien releases
• "never touch running system", create a new one when something has to change
• immutable releases (once created, never change it)

Why They used Docker

• privacy concerns, aws not an option
• hoster they could not pick
• unreliable hoster API
• flash based structure management
• limited capacity
• they are the biggest customer

Learnings

• image based deployments -> use dockerfiles (do not add dockerfile generators on top)
• use syslog and rsyslog to log out of the container
• >>CMD ["/sbin/init"]<< to start debian based image
• caching
• configuration management
  • store configuration in environment
  • dependency injected with start of container (use same container for testing, stageing, testing ...)
  • logfiles and data outside of the container
• do not
  • full blown vm (best case, one service per container)
  • ssh deamon inside containers
  • syslog deamon inside containters (sometimes needed)
  • user management (everything can run as root)
  • chef/puppet makes caching useles
  • rely on external services (github, gem page)
• build management tools
  • bundler, pip, carton, composer, ...
  • problem is, they are slow on "clean slate"
  • ways to solve
    • add mainifest (like composer.lock) before code and use cached build files
    • pre-bundles base images
• multi host
  • image distribution via docker registry
  • weighted load balancing via HAProxy
  • SSL termination via HAProxy (container exists by Johannes Ziemke)
• load balancing
  • HAProxy
  • pool configuration stored in redis/etcd
  • configuration update
    • created
    • uploaded via ssh to host
    • verify configuration
    • replace configuration (old with new)
    • reload configuration
• logging
  • putting container id, revision of image (host, code, request) via rsyslog out of the container
• metrics
  • openTSDB
    • distributed, scalable time series database
    • hbase
    • tags/diminsions
    • from syslog via udp
    • rickshaw.js for graphs
    • compare status cudes, counts and times between actions of two revisions
• benefits (reduces)
  • external dependencies
  • "did work on my machine"
  • unused cpu cycles
  • number of hosts
  • feedback times (number of deploys per day)
  • time to get new host online
  • hosts are more flexible
  • controlled revision change (controlled on each host)
  • faster build