Upcoming SlideShare
Loading in...5

Like this? Share it with your network





How To Build Your Own Ops Framework (If You Really Have To) - RubyConf 2013 Presentation

How To Build Your Own Ops Framework (If You Really Have To) - RubyConf 2013 Presentation



Total Views
Views on SlideShare
Embed Views



0 Embeds 0

No embeds



Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

HTBYOOFIYRHT RubyConf Presentation Transcript

  • 1. How To Build Your Own Ops Framework (If You Really Have To) ! @svanderbleek
  • 2. Do You Really Have To? No Use Chef
  • 3. 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
  • 4. 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
  • 5. Components Api - Entry Point, Control Domain - Business Logic Ops - Meat Database - Persistence App - Frontend
  • 6. 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
  • 7. Domain Resources - States and logic Provisioners - State machines over Resources
  • 8. Ops Providers - Do steps as commanded by provisioner Cloud Services - Get things done Testing Tools - Prove things got done on actual provisioned resources
  • 9. Database It’s just a database stores data Ok, has the Mappers that map Resources to MongoDB and back Can boostrap MongoDB Cluster
  • 10. Resources Can transition between states Transitions are also resources (Inception) Ours: Image, Cluster, Settings, Users, Permissions
  • 11. Providers Define implementations of each state resource state Ending states and pending/doing states Tell provisioner success/failure
  • 12. 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
  • 13. Example Flow Image :pending Image :build_pending Image :building Image :built
  • 14. 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
  • 15. Roadmap DSL to build Resource/Provisioner Api side is already DSL, Grape and Grape-Entity The Frontend needs test coverage Open Source Profit?
  • 16. 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
  • 17. But It’s not done yet Lots of work Monolithic? How to integrate with small tools team builds
  • 18. Bootstrap 3 Looks Nice
  • 19. Static App Server, Ember.js with Emblem
  • 20. This will change our life Someday
  • 21. Cool Sources Test-Driven Infrastructure with Chef DevOps Weekly Just Release It! Classics: Patterns of Enterprise Architecture/Growing Object Oriented Software Guided By Tests