Dev-Friendly Ops
Download as PPTX, PDF1 like1,193 views
1. The document discusses how OpsWorks has made the presenter's life easier as a developer who also handles operations. OpsWorks provides hosted infrastructure on AWS for deploying applications using Chef recipes. 2. It describes the main structures in OpsWorks - stacks, layers, apps, and instances. Stacks represent entire applications, layers define different parts like web servers, apps contain specific settings, and instances define the servers. 3. The presenter discusses using OpsWorks with Ruby on Rails applications, including customizing Chef recipes, deploying code, and integrating other AWS services for monitoring, security, and scaling. While documentation can be confusing, OpsWorks provides an easy way for developers to manage operations.
Ad
More Related Content
What's hot (20)
Similar to Dev-Friendly Ops (20)
Ad
Recently uploaded (20)
Ad
Dev-Friendly Ops
- 1. Dev-Friendly Ops or how OpsWorks has made my life way better
- 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. โYouโre doing everything wrong.โ โEvery Programmer on Twitter
- 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. 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. Four Structures 1. Stack 2. Layer 3. App 4. Instance
- 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
- 10. โข 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
- 11. Custom Cookbook
- 12. Mysql??? WTF
- 13. 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
- 14. โข 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
- 18. 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
- 21. 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
- 25. 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
- 26. โข 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
- 27. 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
- 28. โข 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)
- 30. The Good โข DevOps for Dummies (or developers like me) โข Free* โข Great integration with AWS (obviously) โข Comprehensive API โข Really detailed documentation
- 31. โข 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
- 32. 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.
- 33. 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.)
- 34. Questions? โข Josh Schramm โข @JoshReedSchramm on the twitters โข [email protected] โข Slides on slideshare and Iโll try and remember to tweet that.