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.
Hacking AWS OpsWorks
Sport Ngin Platform
February 11, 2015
8 applications running on 2
First new application launches on
Decision is made to move all
applications to OpsWorks
All 25 web applications running on
Running on 3 different platforms was hard
None of the 3 fully met our needs
Consolidating allowed us to become experts in a
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
What is OpsWorks
Rub Some DevOps
No seriously WTF is it?
Config Management - Chef/OpsWorks Lifecycle
Automated Deployments - Via Chef’s deploy resource
Application Stack definitions - Built-in or using custom
Resource Management - EIPs/EBS/ELBs
Chef Solo/Chef Zero
Agent pings home to see if it needs to run Chef
All life cycle events translate to a Chef run
with different run lists.
Life Cycle Events
IAM User Management
But will it blend?
Everything is an API
Direct integration with other Amazon tools
Fast release cycle
A bit of built in orchestration
User experience is OK-ish
It’s not a typical Chef setup
Auto Healing is a waste of a feature
Not enough orchestration
Use built-in layers!
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?
Don’t use built-in 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
Shipping all the bits
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
Deploying Your App
What’s your deployment strategy?
Built-in chef deploys with minimal downtime
Work must be done to make them zero downtime
Zero Downtime Deploys
Two reasonable techniques:
- Zero downtime on each instance
- Use orchestration to do rolling restarts
Improving the UX
Automation is key
Building good abstractions
CLI is faster
What does it do?
Chef Cookbook updates
Arbitrary Chef runs
Monitor deployment activity
ssh / ssh key management
Moves management closer to the code
Improve the developer experience
Build good layers of abstraction
Add more automation
More visibility into deployments
Instance management (start/stop/create/delete)
Why not normal Chef?
Everything has tradeoffs
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
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
Possible single point of failure
What Do You All Think?