Your SlideShare is downloading. ×
Scale Big With Docker — Moboom 2014
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Scale Big With Docker — Moboom 2014

5,295
views

Published on

Published in: Technology

1 Comment
11 Likes
Statistics
Notes
  • Great job (as usual) jpetazzo :]

    Regarding the 'Building images' section, I couldn't avoid to feel again the need I had when I wrote this tool [1] for easily writting Dockerfiles.
    You might find it interesting, at least as what it is, a PoC hehe

    I hope some developers out there find it useful in heavy container development phases since when you have a more or less definitive Dockerfile it might become a little pain to merge changes from the auto-Dockerfile.
    Anyhow it is interesting for recording every action inside a container just in case it might be useful and, since it's easy to remove any track of the auto-Dockerfiles (rm Dockerfile.* and you are done), I don't find any reason not to use it always you want to interact into a container.

    [1] https://github.com/rcmorano/docker-autocommit
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total Views
5,295
On Slideshare
0
From Embeds
0
Number of Embeds
13
Actions
Shares
0
Downloads
79
Comments
1
Likes
11
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Scale Big With Docker February 2014—Docker 0.8.0
  • 2. Outline ● Why should I care? ● The container metaphor ● Very quick demo ● Working with Docker ● Building images ● Docker future
  • 3. Outline ● Why should I care? ● The container metaphor ● Very quick demo ● Working with Docker ● Building images ● Docker future
  • 4. Deploy everything ● webapps ● backends ● SQL, NoSQL ● big data ● message queues ● … and more
  • 5. Deploy almost everywhere ● Linux servers ● VMs or bare metal ● Any distro ● Kernel 3.8 (or RHEL 2.6.32)
  • 6. Deploy reliably & consistently ● If it works locally, it will work on the server ● With exactly the same behavior ● Regardless of versions ● Regardless of distros ● Regardless of dependencies
  • 7. Deploy easily ● Don't learn a new CM tool ● Reuse components and recipes ● Don't install anything fancy locally (One single local VM to handle all your apps)
  • 8. Deploy at scale ● Build once ● Deploy anywhere ● Deploy quickly – – Docker runtime itself is lightweight – ● Images are lightweight Fast start/stop times Manage Docker with its REST API
  • 9. Outline ● Why should I care? ● The container metaphor ● Very quick demo ● Working with Docker ● Building images ● Docker future
  • 10. Problem: shipping goods ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
  • 11. Solution: the intermodal shipping container
  • 12. Problem: shipping code django web frontend node.js async API background workers SQL database distributed DB, big data message queue ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? my laptop your laptop staging prod on cloud VM prod on bare metal QA
  • 13. Solution: the Linux container
  • 14. High level approach: it's a lightweight VM ● I can SSH into it ● I have root access ● I can apt-get/yum install packages ● I don't see the host system (or other containers) « Machine Container »
  • 15. Low level approach: it's chroot on steroids ● I can run a single program ● container = isolated process(es) ● share kernel with host ● no device emulation → no overhead « Application Container »
  • 16. Outline ● Why should I care? ● The container metaphor ● Very quick demo ● Working with Docker ● Building images ● Docker future
  • 17. Outline ● Why should I care? ● The container metaphor ● Very quick demo ● Working with Docker ● Building images ● Docker future
  • 18. One-time setup ● On your servers (Linux) – – Single binary install (Golang FTW!) – ● Packages (Ubuntu, Debian, Fedora, Gentoo, Arch...) Easy provisioning on Rackspace, Digital Ocean, EC2, GCE... On your dev env (Linux, OS X, Windows) – – boot2docker (25 MB VM image) – ● Vagrantfile Natively (if you run Linux)
  • 19. The Docker workflow 1/2 ● Work in dev environment (local machine or container) ● Other services can be perfect copies of prod ● Whenever you want to test « for real »: – Build in seconds – Run instantly
  • 20. The Docker workflow 2/2 ● Push your build to a registry (public or private) ● Run it in CI/CD ● Run it in production ● Rejoice Something goes wrong? Just re-run previous version (it's still there!)
  • 21. I'm starting a new project! ● Each service will be in its own container(s) ● Build an image for each service ● Pin dependencies (packages etc.) accurately ● Link services together → Recommended workflow!
  • 22. I'm Dockerizing some code! ● ● ● ● Making a single service runnable on Docker Create a « Dockerfile » (Think Makefile, Vagrantfile...) If it's on GitHub, create a Trusted Build (will automatically build ready-to-run images) In any case, register it on index.docker.io
  • 23. I'm migrating to Docker! ● Easy if there is only one service per server – Dockerize the service – Containerize administrative functions (logs...) ● Otherwise, try to split services ● You don't need to move everything to Docker ● Don't use containers as VMs, even if you can!
  • 24. I'm already using Chef/Puppet/Salt/Ansible/...! ● Plan A: generic images – – Run that image just like you would run a VM – ● Put your configuration management tool in an image Great for mixed environments Plan B: specialized images – Put your configuration management tool in an image – Run that image, freeze the result, run it! – Faster and safer
  • 25. Outline ● Why should I care? ● The container metaphor ● Very quick demo ● Working with Docker ● Building images ● Docker future
  • 26. Authoring images with run/commit
  • 27. 1) docker run ubuntu bash 2) apt-get install this and that 3) docker commit <containerid> <imagename> 4) docker run <imagename> bash 5) git clone git://.../mycode 6) pip install -r requirements.txt 7) docker commit <containerid> <imagename> 8) repeat steps 4-7 as necessary 9) docker tag <imagename> <user/image> 10) docker push <user/image>
  • 28. Authoring images with run/commit ● Pros – – ● Convenient, nothing to learn Can roll back/forward if needed Cons – Manual process – Iterative changes stack up – Full rebuilds are boring, error-prone
  • 29. Authoring images with a Dockerfile
  • 30. FROM ubuntu RUN RUN RUN RUN RUN apt-get apt-get apt-get apt-get apt-get -y update install -y install -y install -y install -y g++ erlang-dev erlang-manpages erlang-base-hipe ... libmozjs185-dev libicu-dev libtool ... make wget RUN wget http://.../apache-couchdb-1.3.1.tar.gz | tar -C /tmp -zxfRUN 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 .
  • 31. Authoring images with a Dockerfile ● Almost nothing to learn ● Rebuilds are easy ● Caching system makes rebuilds faster ● Single file to define the whole environment!
  • 32. Outline ● Why should I care? ● The container metaphor ● Very quick demo ● Working with Docker ● Building images ● Docker future
  • 33. Docker: the community ● Docker: >330 contributors ● Docker inc.: <20 engineers ● latest milestone (0.8): >120 contributors ● ~50% of all commits by external contributors ● GitHub repository: >1400 forks ...and counting!
  • 34. Coming Soon ● Network acceleration ● Container-specific metrics ● Consolidated logging ● Plugins (compute backends...) Those things are already possible, but will soon be part of the core.
  • 35. Docker 1.0 ● Multi-arch, multi-OS ● Stable control API ● Stable plugin API ● Resiliency ● Signature ● Clustering
  • 36. Thank you! Questions? http://docker.io/ http://docker.com/ https://github.com/dotcloud/docker @docker @jpetazzo