HTBYOOFIYRHT RubyConf

369 views

Published on

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

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
369
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

HTBYOOFIYRHT RubyConf

  1. 1. How To Build Your Own Ops Framework (If You Really Have To) ! @svanderbleek
  2. 2. Do You Really Have To? No Use Chef
  3. 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. 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. 5. Components Api - Entry Point, Control Domain - Business Logic Ops - Meat Database - Persistence App - Frontend
  6. 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. 7. Domain Resources - States and logic Provisioners - State machines over Resources
  8. 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. 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. 10. Resources Can transition between states Transitions are also resources (Inception) Ours: Image, Cluster, Settings, Users, Permissions
  11. 11. Providers Define implementations of each state resource state Ending states and pending/doing states Tell provisioner success/failure
  12. 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. 13. Example Flow Image :pending Image :build_pending Image :building Image :built
  14. 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. 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. 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. 17. But It’s not done yet Lots of work Monolithic? How to integrate with small tools team builds
  18. 18. Bootstrap 3 Looks Nice
  19. 19. Static App Server, Ember.js with Emblem
  20. 20. This will change our life Someday
  21. 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

×