• Like
From vagrant to production - Mark Eijsermans
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

From vagrant to production - Mark Eijsermans

  • 611 views
Published

 

Published in Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
611
On SlideShare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
4
Comments
0
Likes
1

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. From Vagrant to production Mark Eijsermans HootSuite - Software Engineer @markeijsermans http://code.hootsuite.com
  • 2. HootSuite •  •  •  •  •  •  •  Social media dashboard 8M users 40 people committing code 4 ops AWS (2/3) & private cloud (1/3) 100M requests/day (hootsuite.com) 70M requests/day (ow.ly)
  • 3. •  Monolithic web app (PHP) •  Transitioning towards service oriented architecture (Scala)
  • 4. In the beginning dev server (LAMP) smb dev 1 svn smb dev 2 production (LAMP)
  • 5. In the beginning Release anytime •  Small team •  Is intimately aware of prod •  Low overhead to release DevOps?
  • 6. ..a while later web web web web web web web web svn dev server web web web web gearman smb gearman 0mq worker dev dev dev dev dev dev dev dev dev dev dev dev dev dev dev dev dev dev dev dev dev cron dev dev cron dev dev cron 0mq worker ops ops cron
  • 7. ..a while later 1 release / 2-4 weeks •  •  •  •  •  Medium sized team Branching, pre-release code freezes Only some devs knowledgeable of prod Ops mostly handles deploy Complicated process Devs vs. Ops?
  • 8. …and a few years more (now) Vagrant dev dev dev dev dev dev dev dev dev dev dev dev dev dev dev dev dev dev dev monolithic web app dev dev dev dev dev dev dev dev ops ops ops automate build test QA Service A Service B Service C Service D
  • 9. …and a few years more (now) 6 - 10 release / day •  •  •  •  •  •  Larger team No branching Anyone deploys Automated process Commit to production in 15min Much higher % of devs understand prod
  • 10. Perfection is the enemy of good •  You’re never going to get a perfect system •  How far along are we? •  How many things are actually: •  Automated •  Reproducible •  In a state we want them to be •  When can we start feeling good about it?
  • 11. The move to artifacts •  svn •  svn mirror •  PHP •  phar •  tar + zsync •  Scala •  debian packages
  • 12. Dev Build Deploy Jenkins project code unit test create artifact Artifact Repo build #124 build #123 smoke test staging dash4deploy production production service A/B/C
  • 13. Broke the build? “I’m on it”
  • 14. Vagrant •  Working on a shared web server over samba was simply painful •  extremely volatile environment •  Vagrant simply kicks ass •  Dev / prod parity •  Encourages experimentation •  go ahead and try out that new X
  • 15. Dev Build Deploy Jenkins project code (vagrant) unit test create artifact Artifact Repo build #124 build #123 smoke test staging dash4deploy production production service A/B/C
  • 16. Dev Build Deploy Jenkins project code (vagrant) Ansible unit test create artifact smoke test build vagrant box Artifact Repo vagrant.box build #124 build #123 dash4deploy production production service A/B/C staging
  • 17. Ansible (and why we love it) …yes, use any CM, but why we chose Ansible: •  New team members up to speed in a few days: •  Gentle learning curve – YAML •  Push over ssh - easy to understand •  The more declarative it is, the more it documents •  It's all about disseminating information •  Agentless model suits immutable ephemeral instances
  • 18. Digital archeology
  • 19. Auditing our infrastructure There are gems in that dirt •  logs •  you mean logs aren’t saved to /dev/null ? •  app was rotating logs, vs. using logrotate •  memcached, mongodb servers not all the same version •  what the hell is server X for ???
  • 20. Cache for gold •  With configuration management gold images become a caching layer to the build process •  Private cloud - idle instances are cheap •  AMI - need auto spinning to save $$$ & time
  • 21. Simplify for sanity •  200+ server types is hard to manage •  Amortize the stack •  Custom bespoke vs. generic appliances
  • 22. Devs on call •  Learning happens in production •  Production is still running at 3am
  • 23. “People who are really serious about software should make their own hardware” Alan Kay
  • 24. Devs on call •  Is your monitoring and tooling truly effective? •  Make sure they can ssh into the damn box! (if they have to) •  Throwing some poor dev onto a broken system they know nothing about doesn't work •  Choose your own adventure cookbooks •  Create registry of specialists
  • 25. Is this working?
  • 26. Working out loud •  Yammer (& HipChat for on call) •  Tried IRC, was too silo’ed •  5 whys post mortems •  Accountability •  Build fails - “I'm on it”
  • 27. Learning happens in production
  • 28. Thank you! @markeijsermans http://code.hootsuite.com