dev-friendly ops

34
Dev-Friendly Ops or how OpsWorks has made my life way better

Upload: josh-schramm

Post on 20-Jun-2015

544 views

Category:

Technology


1 download

DESCRIPTION

Opsworks presentation made for CleRB and Cle DevOps on 11/6/14

TRANSCRIPT

Page 1: Dev-Friendly Ops

Dev-Friendly Opsor how OpsWorks has made my life way better

Page 2: Dev-Friendly Ops

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

Page 3: Dev-Friendly Ops

–Every Programmer on Twitter

“You’re doing everything wrong.”

Page 4: Dev-Friendly Ops

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

Page 5: Dev-Friendly Ops

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)

Page 6: Dev-Friendly Ops

Four Structures

1. Stack

2. Layer

3. App

4. Instance

Page 7: Dev-Friendly Ops

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

Page 8: Dev-Friendly Ops
Page 9: Dev-Friendly Ops
Page 10: Dev-Friendly Ops

• 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

Page 11: Dev-Friendly Ops

Custo

m

Cookb

ook

Custom Cookbook

Page 12: Dev-Friendly Ops

Mysql??? WTF

Page 13: Dev-Friendly Ops

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

Page 14: Dev-Friendly Ops

• 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

Page 15: Dev-Friendly Ops
Page 16: Dev-Friendly Ops
Page 17: Dev-Friendly Ops
Page 18: Dev-Friendly Ops

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

Page 19: Dev-Friendly Ops
Page 20: Dev-Friendly Ops
Page 21: Dev-Friendly Ops

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

Page 22: Dev-Friendly Ops
Page 23: Dev-Friendly Ops
Page 24: Dev-Friendly Ops
Page 25: Dev-Friendly Ops

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

Page 26: Dev-Friendly Ops

• 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

Page 27: Dev-Friendly Ops

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

Page 28: Dev-Friendly Ops

• 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)

Page 29: Dev-Friendly Ops
Page 30: Dev-Friendly Ops

The Good

• DevOps for Dummies (or developers like me)

• Free*

• Great integration with AWS (obviously)

• Comprehensive API

• Really detailed documentation

Page 31: Dev-Friendly Ops

• 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

Page 32: Dev-Friendly Ops

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.

Page 33: Dev-Friendly Ops

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.)

Page 34: Dev-Friendly Ops

Questions?

• Josh Schramm

• @JoshReedSchramm on the twitters

[email protected]

• Slides on slideshare and I’ll try and remember to tweet that.