Posted by artodeto on
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)
- 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
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
Posted by artodeto on
And as bonus, i found a cool page called top static site generators comparison.