Skip to content

Introduction Into Docker and Continous Delivery with Docker - Docker Usergroup Hamburg 09.06.2014

Docker UserGroup 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

Trackbacks

Keine Trackbacks

Kommentare

Ansicht der Kommentare: Linear | Verschachtelt

Noch keine Kommentare

Die Kommentarfunktion wurde vom Besitzer dieses Blogs in diesem Eintrag deaktiviert.

Kommentar schreiben

Die angegebene E-Mail-Adresse wird nicht dargestellt, sondern nur für eventuelle Benachrichtigungen verwendet.
Um einen Kommentar hinterlassen zu können, erhalten Sie nach dem Kommentieren eine E-Mail mit Aktivierungslink an ihre angegebene Adresse.

Um maschinelle und automatische Übertragung von Spamkommentaren zu verhindern, bitte die Zeichenfolge im dargestellten Bild in der Eingabemaske eintragen. Nur wenn die Zeichenfolge richtig eingegeben wurde, kann der Kommentar angenommen werden. Bitte beachten Sie, dass Ihr Browser Cookies unterstützen muss, um dieses Verfahren anzuwenden.
CAPTCHA

Markdown-Formatierung erlaubt
Formular-Optionen