O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

Puppet Camp Seattle 2014: Docker and Puppet: 1+1=3

Jerome Petazzoni, Docker

Puppet Camp Seattle 2014: Docker and Puppet: 1+1=3

  1. 1. Docker and Puppet 1+1=3
  2. 2. Jérôme Petazzoni (@jpetazzo) ● Grumpy French DevOps – Go away or I will replace you with a very small shell script ● Operated and scaled dotCloud – PAAS on EC2, with LXC, Puppet, Python, Shell, ØMQ...
  3. 3. Jérôme Petazzoni (@jpetazzo) ● Runs everything in containers – VPN, firewalls – KVM, Xorg – Docker – … ● Helps others to do the same – CONTAINERIZE ALL THE THINGS!!!
  4. 4. What is Docker The quick elevator pitch
  5. 5. Docker Engine + Docker Hub = Docker Platform
  6. 6. Docker Engine
  7. 7. The Docker Engine ● Open Source ● Written in Go ● Runs containers ● On any modern Linux machine (Intel 64 bits for now)
  8. 8. Containers ?
  9. 9. Containers ● Software delivery mechanism (a bit like a package!) ● Put your application in a container, run it anywhere ● A bit like a VM, but ...
  10. 10. I have four words for you ● CONTAINERS boot faster (than VMs) ● CONTAINERS have less overhead (more consolidation) ● CONTAINERS bring native performance (on bare metal) ● CONTAINERS are cloud-compatible (can run in VMs)
  11. 11. CONTAINERS boot faster
  12. 12. CONTAINERS have less overhead
  13. 13. CONTAINERS bring native performance
  14. 14. CONTAINERS are cloud-compatible Docker runs on … ● Bare metal – packages, binary, CoreOS, Project Atomic, b2d... ● Desktop VM – boot2docker ● Cloud VM (Xen, ESX, KVM, HyperV...) – ready-to-run images on most public clouds
  15. 15. Docker Engine recap ● Approximation: it's an hypervisor to run containers ● Approximation: containers are like VMs, but lighter ● Docker makes containers available to everybody (not just veterans from the last emacs/vim war)
  16. 16. Stop. Demo time.
  17. 17. Docker Hub
  18. 18. Docker Hub ● Services operated by Docker Inc. ● Library of ready-to-use container images ● Registry for your container images (public or private) ● Automated builds (triggered by pushes to GitHub/Bitbucket) ● Free for public/open source code, $$ otherwise
  19. 19. Building containers
  20. 20. Dockerfile FROM ubuntu:14.04 MAINTAINER Docker Team <education@docker.com> RUN apt-get update RUN apt-get install -y nginx RUN echo 'Hi, I am in your container' >/usr/share/nginx/html/index.html CMD [ "nginx", "-g", "daemon off;" ] EXPOSE 80
  21. 21. FROM ubuntu RUN apt-get -y update RUN apt-get install -y g++ RUN apt-get install -y erlang-dev erlang-manpages erlang-base-hipe ... RUN apt-get install -y libmozjs185-dev libicu-dev libtool ... RUN apt-get install -y make wget RUN wget http://.../apache-couchdb-1.3.1.tar.gz | tar -C /tmp -zxf- RUN cd /tmp/apache-couchdb-* && ./configure && make install RUN printf "[httpd]nport = 8101nbind_address = 0.0.0.0" > /usr/local/etc/couchdb/local.d/docker.ini EXPOSE 8101 CMD ["/usr/local/bin/couchdb"] docker build -t jpetazzo/couchdb .
  22. 22. Dockerfiles vs. Shell scripts
  23. 23. Shell scripts ● OK-ish for simple stacks ● Tricky to handle all possible situations (that's why we have proper config management)
  24. 24. Shell scripts: the dilemma
  25. 25. Run from scratch every time ● Pros: – no side-effect, 100% repeatability ● Cons: – create machine each time – provision all the things, install tons of packages... – takes forever – you will eventually get bored and give up
  26. 26. Run iteratively over and over ● Pros: – much faster ● Cons: – have to deal with leftovers of previous run – have to make sure everything is idempotent – quickly gets tedious – you will eventually reinvent CM
  27. 27. The answer: Dockerfiles
  28. 28. Best of both worlds ● Build from scratch everytime (re-apply each command on top of clean build) ● Build fast (by re-using snapshots of previous runs) ● Win!
  29. 29. Dockerfile vs. Configuration Management
  30. 30. Configuration Management: the Good ● Deals with low-level stuff ● Abstracts some details (distro, sometimes OS) ● Ensures convergence to a known state ● Library of reusable, composable templates
  31. 31. Configuration Management: the Bad ● Steep learning curve ● Generally requires an agent (or something to trigger e.g. « puppet apply ») ● Resource-intensive (it's OK to run the agent on a 64 GB server, it's less OK to run 100 agents on said server)
  32. 32. Configuration Management ● Reusability is just as good as modules are (i.e. YMMV) ● Not as deterministic as you think ● Rollbacks are harder than you think { 'openssl' : ensure => present } { 'openssl' : ensure => '1.2.3-no-poodle-pls' }
  33. 33. Dockerfile to the rescue
  34. 34. Dockerfile ● Doesn't have to deal with « low-level stuff » (hardware, drivers... handled by the host) ● Doesn't need all the goodness of CM (because it doesn't have to converge) ● Partial rebuilds are fast (layered caching rebuilds only what is needed) ● Allows inheritance and composition (FROM <mycustombase>; see also: ONBUILD) ● Easy learning curve (if you know Shell, you already know Dockerfile)
  35. 35. But... ● Doesn't deal with « low-level stuff » (hardware, drivers...) ● Doesn't define resource dependencies (no before/after) ● Doesn't define what runs where
  36. 36. Puppet to the rescue
  37. 37. Before/After ● Use Puppet to setup hardware (or virtual hardware), install packages, deploy code, run services. ● Use Puppet to setup hardware (or virtual hardware), install Docker, run containers. ● Use Dockerfiles to install packages, deploy code, run services.
  38. 38. Do one thing, and do it well
  39. 39. ;
  40. 40. First things first https://github.com/garethr/garethr-docker https://forge.puppetlabs.com/garethr/docker
  41. 41. Installing Docker with Puppet include 'docker' class { 'docker': version => '1.3.1' }
  42. 42. Warm up our image collection # download the registry image docker::image { 'postgresql': } # don't download all ubuntu, # just '14.04' docker::image { 'ubuntu': image_tag => '14.04' }
  43. 43. Run containers docker::run { 'slavedb': image => 'jpetazzo/postgresql' command => '…' ports => ['5432', '22'], links => ['masterdb:master'], use_name => true, volumes => ['/var/lib/postgresql'], volumes_from => '420fc7e8aa20', memory_limit => 100000000, # bytes username => 'postgres', hostname => 'sdb.prod.dckr.io', env => ['FUZZINESS=42', FOO=BAR', 'FOO2=BAR2'], dns => ['8.8.8.8', '8.8.4.4'], restart_service => true }
  44. 44. Can I use Puppet to build Docker container images?
  45. 45. YES
  46. 46. Should I use Puppet to build Docker container images?
  47. 47. NO
  48. 48. OK, let's do it anyway
  49. 49. My other VM is a container ● write a Dockerfile to install Puppet ● start tons of containers ● run Puppet in them (agent, or one-shot apply) Good if you want a mix of containers/VM/metal But slower to deploy, and uses more resources
  50. 50. Sample Dockerfile FROM ubuntu:12.04 RUN apt-get install -qy wget RUN mkdir /puppet WORKDIR /puppet RUN wget -q http://apt.puppetlabs.com/puppetlabs-release-precise.deb RUN dpkg -i puppetlabs-release-precise.deb RUN apt-get update -q RUN apt-get install -qy puppet-common CMD puppet agent --no-daemonize --verbose
  51. 51. Lightweight, portable VMs ● Start containers instead of VMs – I can start 10 containers on this puny laptop! – You can start those 10 containers too! (Even though you have a totally different laptop!) – We can start those containers in the Cloud! ● Deploy sshd, syslogd, crond, etc. – You can... But do you have to?
  52. 52. The revolution will be containerized ● write a Dockerfile to install Puppet ● … and run Puppet as part of build process ● deploy fully baked, « golden » images Faster to deploy Easier to rollback
  53. 53. Sample Dockerfile FROM ubuntu:12.04 RUN apt-get install -qy wget RUN mkdir /puppet WORKDIR /puppet RUN wget -q http://apt.puppetlabs.com/puppetlabs-release-precise.deb RUN dpkg -i puppetlabs-release-precise.deb RUN apt-get update -q RUN apt-get install -qy puppet-common ENV FACTER_HOSTNAME database42 ADD ./site.pp /puppet/site.pp RUN puppet apply site.pp
  54. 54. Beyond Golden Containers
  55. 55. Separation of Operational Concerns
  56. 56. Wat?
  57. 57. What does that mean? ● Don't rebuild your app to change logging, remote access, and other unrelated things ● Have different policies in prod/dev/QA/etc ● Ship lighter containers
  58. 58. Virtual Machine deployment ● Linux base system ● Libraries ● Application ● Logging ● Backups ● Metrics ● ...
  59. 59. With configuration management node www { include common include web include logstash include backup include graphite }
  60. 60. Problems ● Conflicts between two components – e.g. logging and metrics use different Java versions ● Software certified for different distro – e.g. something wants RHEL 6.4 but you run Ubuntu ● Migration from one component to another – example: from syslog to splunk
  61. 61. Container deployment ● Linux base system ● Docker ● Application container ● Logging container ● Backups container ● Metrics container ● ...
  62. 62. More about that http://blog.docker.com/2014/06/why-you-dont-need- to-run-sshd-in-docker/ http://www.slideshare.net/jpetazzo/containerization -new-virtualization-docker-separation-operational-concerns
  63. 63. Thoughts...
  64. 64. What if we could... ● Run the Puppet agent outside of the container ● Run a single agent for many containers ● Share the cost of the agent
  65. 65. Thank you!
  66. 66. Would You Like To Know More? ● Now: ask me questions! ● Next hour: ask me more questions! ● Tomorrow: Docker mini-training (11am) ● Run a containers BoF at LISA? ● Later: www.docker.com, #docker, docker-user...

×