Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Docker after 500M Containers

Docker after 500M Containers

Slides from ClusterHQ Meetup talk

video/blog followup: http://blog.heavybit.com/blog/2015/3/23/dockermeetup

Reed Allman

February 11, 2015

More Decks by Reed Allman

Other Decks in Programming


  1. Docker After Launching 500M Containers Travis Reeder & Reed Allman

  2. What would you say you do here?

  3. think SQS, but not Amazon (we copied them)

  4. think Lambda, but not Amazon (they copied us)

  5. The deets on

  6. 1) Write code using ${FAVORITE_LANG} that performs a specific function

    == your worker
  7. 2) Upload your code package

  8. 3) Queue a task. Or millions of tasks.

  9. 4) IronWorker executes tasks inside Docker containers across 1000’s of

  10. None
  11. or

  12. or

  13. 5)

  14. A time not so long ago, in this galaxy...

  15. We were using LXC

  16. Single one size fits all container

  17. Components were getting old Ruby 1.9, Node 0.8, Mono 2,

    Java 1.6, etc..
  18. Hard to upgrade risk breaking customer’s tasks

  19. None
  20. Hey, look what these whale activists are doing

  21. Solved our main problem Can upgrade and add images easily

    while being backwards compatible (hooray, tags)
  22. Good for you We can provide a lot of different

    stacks to run code in
  23. Good for you Try your code in the same docker

    image we’ll run it in (thanks Dockerhub)
  24. Good for us Complete isolation between user’s code and host

  25. Good for us Ration out resources between containers easily

  26. Good for us Layered FS makes means much less space

  27. But it hasn’t been all roses...

  28. None
  29. Docker gets bitten from time to time

  30. Since Docker owns all the things...

  31. ...and upstart/systemd can’t reap...

  32. tasks can’t terminate and can’t launch new ones...

  33. $ sudo reboot

  34. None
  35. Other things...

  36. phantom.js has issues...

  37. Docker has issues...

  38. None
  39. Moreover...

  40. Debugging Docker bugs sucks

  41. Since we’re sharing a kernel, it’s hard to tell whether:

    1) Docker has issues 2) Linux has issues or 3) We forgot to take our pills
  42. None
  43. Our Christmas List

  44. Better debugging tools (like stats in 1.5)

  45. Swarm looks awesome for resource based launching

  46. Docker+Iron_((?!worker).)* • Build containers (instead of servers) • Deployment (CoreOS+Fleet)

    • On-prem packaging / deployment (b/c RHEL)
  47. Questions?