htbyoofiyrht rubyconf

How To Build Your Own Ops Framework

(If You Really Have To) !

@svanderbleek

Do You Really Have To?

No

Use Chef

Desirables

Testable - Unit, Integration, Acceptance

Available - Bootstraps into cluster, no single point failure

Debuggable - Failure modes for deployments, swap-over

Audit-able - Who/What triggering changes in system

Just Chef?

Chef server high availability? Setting it up on your stack will be non-trivial

Chef-Spec isn’t enough

Cucumber-Chef is cool

Test Kitchen - under rapid development

Components

Api - Entry Point, Control

Domain - Business Logic

Ops - Meat

Database - Persistence

App - Frontend

Api

Endpoints - Rack GET, POST, PUT etc

Entities - Output JSON Representation

Representations - Consume JSON Representation

Services - Interface to Domain and Ops

Clients - Interface to API for Domain/Ops/Command Line

Execution - Abstract asynchronous implementation

Domain

Resources - States and logic

Provisioners - State machines over Resources

Ops

Providers - Do steps as commanded by provisioner

Cloud Services - Get things done

Testing Tools - Prove things got done on actual provisioned resources

Database

It’s just a database

stores data

Ok, has the Mappers that map Resources to MongoDB and back

Can boostrap MongoDB Cluster

Resources

Can transition between states

Transitions are also resources (Inception)

Ours: Image, Cluster, Settings, Users, Permissions

Providers

Define implementations of each state resource state

Ending states and pending/doing states

Tell provisioner success/failure

Provisioner

Control provider flow

Tell client what’s up with resource state

Success and failure are transition events

Run inside Execution with run id of Transition

Example Flow

Image :pending

Image :build_pending

Image :building

Image :built

Make It A Framework

Just build your own subclasses of Resource/Provisioner/Provider

And then the same for Entity/Endpoint/Service

Plus Mapper for Database

Ok … This is hard

Roadmap

DSL to build Resource/Provisioner

Api side is already DSL, Grape and Grape-Entity

The Frontend needs test coverage

Open Source

Profit?

Key Process Benefits

Write acceptance tests using RSpec matchers that run on instances created by Api

When a deployment fails Api provides ssh access to machine to diagnose failure

One stop shop for managing settings and service discovery

Failover built in, fundamental construct

Endpoints have Entities, self documenting

But

It’s not done yet

Lots of work

Monolithic? How to integrate with small tools team builds

Bootstrap 3 Looks Nice

Static App Server, Ember.js with Emblem

This will change our life

Someday

Cool Sources

Test-Driven Infrastructure with Chef

DevOps Weekly

Just Release It!

Classics: Patterns of Enterprise Architecture/Growing Object Oriented Software Guided By Tests