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

Hacking AWS OpsWorks

Andy Fleener
February 19, 2015

Hacking AWS OpsWorks

At Sport Ngin we use AWS OpsWorks heavily. We running 25 applications across our platform, 50 different OpsWorks stacks between our staging and production accounts. We've been using OpsWorks basically since it was announced 2 years ago. We built a command line utility(http://github.com/sportngin/opsicle) to help us along the way. I could give a presentation about OpsWorks in general and the evolution of how we've use it. If there's time start talking about the tradeoffs of using OpsWorks vs rolling your own chef server/provisioning setup.

Andy Fleener

February 19, 2015
Tweet

More Decks by Andy Fleener

Other Decks in Technology

Transcript

  1. Sport Ngin Platform January 2013
 March 2013
 June 2014
 February

    11, 2015 8 applications running on 2 different “Paas” First new application launches on OpsWorks Decision is made to move all applications to OpsWorks All 25 web applications running on OpsWorks
  2. Why Move Running on 3 different platforms was hard None

    of the 3 fully met our needs Consolidating allowed us to become experts in a 
 single platform
  3. Why OpsWorks High level of customizability Did the low level

    work for us Stayed out of our way Good pricing model Stays fresh by releasing new features
  4. Application Manager Config Management - Chef/OpsWorks Lifecycle orchestration Automated Deployments

    - Via Chef’s deploy resource Application Stack definitions - Built-in or using custom defined stacks Resource Management - EIPs/EBS/ELBs
  5. Chef/OpsWorks Agent Chef Solo/Chef Zero OpsWorks Agent Agent pings home

    to see if it needs to run Chef All life cycle events translate to a Chef run 
 with different run lists.
  6. The Good Everything is an API Direct integration with other

    Amazon tools Fast release cycle A bit of built in orchestration
  7. The Bad User experience is OK-ish It’s not a typical

    Chef setup Auto Healing is a waste of a feature Not enough orchestration
  8. Questions to Ask Am I going to run this in

    production? Will this application have users? Do I need zero downtime deployments? Do I care about what software is running on my servers?
  9. Custom Layers Reuse OpsWorks’ chef cookbooks Still have full control

    over the run list Replace parts that don’t meet your needs Use Layers as roles to attach run lists to layers Use custom security groups
  10. Updating Your Chef All Chef versions use a site-cookbooks pattern

    Berkshelf can help Watch out for indeterminate dependency resolution All the OpsWorks cookbooks are open source
 https://github.com/aws/opsworks-cookbooks
  11. Deploying Your App What’s your deployment strategy? Built-in chef deploys

    with minimal downtime Work must be done to make them zero downtime
  12. Zero Downtime Deploys Two reasonable techniques: - Zero downtime on

    each instance - Use orchestration to do rolling restarts
  13. What does it do? Deployments Chef Cookbook updates Arbitrary Chef

    runs Monitor deployment activity ssh / ssh key management Moves management closer to the code
  14. OpsWorks Easy to get started Built-in server management OpsWorks runs

    the backend service Removes some of the complex parts of Chef It’s only kind of Chef
  15. Chef Server It’s actually Chef Cookbooks from the community will

    work if you set them up right More freedom about how to run/maintain Bigger investment into ensuring you have a working Chef server Possible single point of failure