"Lightweight Virtualization with Linux Containers and Docker". Jerome Petazzoni, dotCloud
Post on 28-Jan-2015
Embed Size (px)
DESCRIPTIONLightweight virtualization", also called "OS-level virtualization", is not new. On Linux it evolved from VServer to OpenVZ, and, more recently, to Linux Containers (LXC). It is not Linux-specific; on FreeBSD it's called "Jails", while on Solaris its "Zones". Some of those have been available for a decade and are widely used to provide VPS (Virtual Private Servers), cheaper alternatives to virtual machines or physical servers. But containers have other purposes and are increasingly popular as the core components of public and private Platform-as-a-Service (PAAS), among others. Just like a virtual machine, a Linux Container can run (almost) anywhere. But containers have many advantages over VMs: they are lightweight and easier to manage. After operating a large-scale PAAS for a few years, dotCloud realized that with those advantages, containers could become the perfect format for software delivery, since that is how dotCloud delivers from their build system to their hosts. To make it happen everywhere, dotCloud open-sourced Docker, the next generation of the containers engine powering its PAAS. Docker has been extremely successful so far, being adopted by many projects in various fields: PAAS, of course, but also continuous integration, testing, and more.
- 1. ! ( )
2. Lightweight Virtualization with Linux Containers and Docker Yet another Conference Moscow, 2013 Jrme Petazzoni, dotCloud Inc. 3. : ! 4. Outline Why Linux Containers? What are Linux Containers exactly? What do we need on top of LXC? Why Docker? What is Docker exactly? Where is it going? 5. Outline Why Linux Containers? What are Linux Containers exactly? What do we need on top of LXC? Why Docker? What is Docker exactly? Where is it going? 6. Why Linux Containers? What are we trying to solve? 7. The Matrix From Hell 8. The Matrix From Hell 9. Many payloads backend services (API) databases distributed stores webapps 10. Many payloads Go Java Node.js PHP Python Ruby 11. Many payloads CherryPy Django Flask Plone ... 12. Many payloads Apache Gunicorn uWSGI ... 13. Many payloads + your code 14. Many targets your local development environment your coworkers' developement environment your Q&A team's test environment some random demo/test server the staging server(s) the production server(s) bare metal virtual machines shared hosting 15. Many targets BSD Linux OS X Windows 16. Many targets BSD Linux OS X Windows Not yet 17. The Matrix From Hell Static website ? ? ? ? ? ? ? Web frontend ? ? ? ? ? ? ? background workers ? ? ? ? ? ? ? User DB ? ? ? ? ? ? ? Analytics DB ? ? ? ? ? ? ? Queue ? ? ? ? ? ? ? DevelopmentVM QA Server Single Prod Server Onsite Cluster Public Cloud Contributors laptop Customer Servers 18. Real-world analogy: containers 19. Many products clothes electronics raw materials wine 20. Many transportation methods ships trains trucks ... 21. Another matrix from hell ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 22. Solution to the transport problem: the intermodal shipping container 23. Solution to the transport problem: the intermodal shipping container 90% of all cargo now shipped in a standard container faster and cheaper to load and unload on ships (by an order of magnitude) less theft, less damage freight cost used to be >25% of final goods cost, now /usr/local/etc/couchdb/local.d/docker.ini EXPOSE 8101 CMD ["/usr/local/bin/couchdb"] 55. Yes, but... I don't need Docker; I can do all that stuff with LXC tools, rsync, some scripts! correct on all accounts; but it's also true for apt, dpkg, rpm, yum, etc. the whole point is to commoditize, i.e. make it ridiculously easy to use 56. Containers before Docker 57. Containers after Docker 58. What this really means instead of writing very small shell scripts to manage containers, write them to do the rest: continuous deployment/integration/testing orchestration = use Docker as a building block re-use other people images (yay ecosystem!) 59. Docker: sharing images you can push/pull images to/from a registry (public or private) you can search images through a public index dotCloud maintains a collection of base images (Ubuntu, Fedora...) satisfaction guaranteed or your money back 60. Docker: not sharing images private registry for proprietary code or security credentials or fast local access the private registry is available as an image on the public registry (yes, that makes sense) 61. Typical workflow code in local environment ( dockerized or not) each push to the git repo triggers a hook the hook tells a build server to clone the code and run docker build (using the Dockerfile) the containers are tested (nosetests, Jenkins...), and if the tests pass, pushed to the registry production servers pull the containers and run them for network services, load balancers are updated 62. Hybrid clouds Docker is part of OpenStack Havana , as a Nova driver + Glance translator typical workflow: code on local environment push container to Glance-backed registry run and manage containers using OpenStack APIs 63. Outline Why Linux Containers? What are Linux Containers exactly? What do we need on top of LXC? Why Docker? What is Docker exactly? Where is it going? 64. What's Docker exactly? rewrite of dotCloud internal container engine original version: Python, tied to dotCloud's internal stuff released version: Go, legacy-free the Docker daemon runs in the background manages containers, images, and builds HTTP API (over UNIX or TCP socket) embedded CLI talking to the API Open Source (GitHub public repository + issue tracking) user and dev mailing lists 65. Docker: the community Docker: >160 >170 contributors latest milestone (0.6): 40 contributors GitHub repository: >600 >680 forks 66. Outline Why Linux Containers? What are Linux Containers exactly? What do we need on top of LXC? Why Docker? What is Docker exactly? Where is it going? 67. Docker roadmap Today: Docker 0.6 LXC AUFS Tomorrow: Docker 0.7 LXC device-mapper thin snapshots (target: RHEL) The day after: Docker 1.0 LXC, libvirt, qemu, KVM, OpenVZ, chroot multiple storage back-ends plugins 68. Docker: the ecosystem Cocaine (PAAS; has Docker plugin) CoreOS (full distro based on Docker) Deis (PAAS; available) Dokku (mini-Heroku in 100 lines of bash) Flynn (PAAS; in development) Maestro (orchestration from a simple YAML file) OpenStack integration (in Havana, Nova has a Docker driver) Shipper (fabric-like orchestration) 69. Cocaine integration what's Cocaine? Open Source PaaS from Yandex modular: can switch logging, storage, etc. without changing apps infrastructure abstraction layer + service discovery monitoring: metrics collection; load balancing why Docker? Cocaine initially used cgroups wanted to add LXC for better isolation and resource control heard about Docker at the right time 70. device-mapper thin snapshots (aka thinp ) start with a 10 GB empty ext4 filesystem snapshot: that's the root of everything base image: clone the original snapshot untar image on the clone re-snapshot; that's your image create container from image: clone the image snapshot run; repeat cycle as many times as needed 71. AUFS vs THINP AUFS easy to see changes small change = copy whole file ~42 layers patched kernel (Debian, Ubuntu OK) efficient caching no quotas THINP must diff manually small change = copy 1 block (100k-1M) unlimited layers stock kernel (>3.2) (RHEL 2.6.32 OK) duplicated pages FS size acts as quota 72. Misconceptions about THINP performance degradation no; that was with old LVM snapshots can't handle 1000s of volumes that's LVM; Docker uses devmapper directly if snapshot volume is out of space, it breaks and you lose everything that's old LVM snapshots; thinp halts I/O if still use disk space after 'rm -rf' no, thanks to 'discard passdown' 73. Other features in 0.7 links linked containers can discover each other environment variable injection allows to expose remote services thru containers (implements the ambassador pattern) side-effect: container naming host integration we systemd 74. 0.8 and beyond beam introspection API based on Redis protocol (i.e. all Redis clients work) works well for synchronous req/rep and streams reimplementation of Redis core in Go think of it as live environment variables , that you can watch/subscribe to and much more 75. Thank you! Questions? http://docker.io/ https://github.com/dotcloud/docker @docker @jpetazzo