Successfully reported this slideshow.

Dev-Friendly Ops

1

Share

Upcoming SlideShare
Introducing AWS OpsWorks
Introducing AWS OpsWorks
Loading in …3
×
1 of 34
1 of 34

More Related Content

Related Books

Free with a 14 day trial from Scribd

See all

Dev-Friendly Ops

  1. 1. Dev-Friendly Ops or how OpsWorks has made my life way better
  2. 2. A Little Background • Hi, I’m Josh • I’m not an Ops guy • Mostly a Ruby on Rails Dev • .Net in a previous life but OpsWorks doesn’t really support it • I’ve become an Ops guy by necessity
  3. 3. “You’re doing everything wrong.” –Every Programmer on Twitter
  4. 4. How We Use It • I Work There -> • We have ~8 clients on OpsWorks • This presentation is about how we’ve done things. Not always the “right” way. • Tell me why I’m wrong
  5. 5. OpsWorks 101 • Hosted Infrastructure on Amazon Web Services • Free* • Chef Solo / Chef Client (based on chef version) • Evolving really really quickly * (with purchase of everything else)
  6. 6. Four Structures 1. Stack 2. Layer 3. App 4. Instance
  7. 7. Stack • Stacks are supposed to represent your entire application and all of it’s infrastructure dependencies. • In general each environment will be a different stack • Production / Staging / QA / etc. • This is not how L7 is doing it. I’ll explain why in a bit. • Stacks set default values for future layers and instances
  8. 8. • Custom JSON • This is how you define config points for your app. • There’s a bunch of default JSON hooks that tie into opsworks recipes • You can use this in custom recipes • How you configure your database if you’re NOT using RDS
  9. 9. Custom Cookbook
  10. 10. Mysql??? WTF
  11. 11. Layer • This is a slice of your application • Application Server / Web Server / Database / Task Server / etc. • OpsWorks predefines a bunch (including Rails) • Only 1 of each (except custom) • This is why we don’t use stacks correctly
  12. 12. • Layer is where you setup individual chef recipes to run • You can also configure settings for the layer type • Ruby version, passenger vs nginx, bundler, load balancer and other resources • This will change based on the layer type and be pretty lean on custom layers
  13. 13. App • Details your specific App Settings • You CAN have multiple apps but they should rely on the same layer settings • aka same ruby version, web server, etc. • Git Settings, Environment Variables, Domains, SSL Certificates, Database Connection all goes here • Questions vary based on layer type
  14. 14. Instances • This defines the metal you’ll be running on • Inherits from Stack settings • Size, Name, Availability Zone, SSH Access, OS all configured here • You can also setup autoscaling here • Automatically spin up and down boxes based on load or time
  15. 15. Chef • Every Stack can define a Custom Cookbooks Repo • You can also use Berkshelf • If you don’t use Berkshelf I’d make each recipe an individual repo and submodule them in • Also: Make your cookbooks public if you can and keep sensitive info in environment variables • Getting a private repo to work is possible but a total PITA
  16. 16. • OpsWorks publishes their default cookbooks here: • https://github.com/aws/opsworks-cookbooks • Check the branch, master is useless the branches map to chef version • We fork this for each project and then edit • Matt Case told me I’m a bad person for doing this
  17. 17. Deployment • Goodbye Capistrano, hello mediocre Capistrano clone. • Same folder structure as cap • Terrible command line support. Working on rake tasks for this but who knows when we’ll be able to post them • 0 downtime deploys either need custom code or use the Web UI
  18. 18. • Deploy Hooks - /deploy folder in project, use for asset compile • Tasks - Create chef cookbook, execute as command • OpsWorks deploys are slower than other tools (getting better)
  19. 19. The Good • DevOps for Dummies (or developers like me) • Free* • Great integration with AWS (obviously) • Comprehensive API • Really detailed documentation
  20. 20. • Default server configs are pretty solid. (I’ve used Rails and Node) • Security Updates • Sidenote: Heartbleed and Shellshock • Amazon is actively improving the tool • RDS, Environment Vars both added recently
  21. 21. The Bad • Documentation is confusing at times • Reads like a technical manual because, well, it is a technical manual • Quick obsolescence • Chef updates, new features, etc.
  22. 22. AWS Integration • Recently added RDS support so no more giant JSON blocks • CloudWatch for monitoring as well as autoscaling • New Relic is still better for monitoring though • IAM Security makes it easier to control access • Servers are EC2, so you get all that stuff too • Can map resources within opsworks (load balancers, EBS volumes, etc.)
  23. 23. Questions? • Josh Schramm • @JoshReedSchramm on the twitters • josh.schramm@gmail.com • Slides on slideshare and I’ll try and remember to tweet that.

×