Monitor-Driven Development Using Ansible
Upcoming SlideShare
Loading in...5

Like this? Share it with your network


Monitor-Driven Development Using Ansible



Discusses an XP approach to writing Ansible scripts: Start with a failing test and write code around it to make it pass. Write monitoring code, let it drive your Ansible code to have a functioning ...

Discusses an XP approach to writing Ansible scripts: Start with a failing test and write code around it to make it pass. Write monitoring code, let it drive your Ansible code to have a functioning server. I use ServerSpec and Cucumber as the monitoring code. Broader subject is that Ansible code should be treated as regular application code - use TDD, SCM, CI and pairing to create a single delivery team consisting of devs and sysadmins as a delivery team.



Total Views
Views on SlideShare
Embed Views



4 Embeds 43 23 8 7 5



Upload Details

Uploaded via as Microsoft PowerPoint

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

Monitor-Driven Development Using Ansible Presentation Transcript

  • 2. THE PREMISE • Ansible scripts should be treated with the same rigour with which we treat application code • In the way they’re tested • In the way they’re written
  • 3. JAMES WHITE MANIFESTO •There is one system, not a collection of systems. • The desired state of the system should be a known quantity. • The "known quantity" must be machine parseable. • The actual state of the system must self-correct to the desired state. • The entire system must be deployable using source media and text files. • The only authoritative source for the actual state of the system is the system.
  • 5. WHY ANSIBLE? •Assures scalability •Repeatable and measurable •Assures environments for consistent development testing Do not improve manual processes if you can automate them instead. •Fail fast (offline!) and cycle quickly •Time To Rebuild System < Time To Fix It
  • 6. THE REVOLUTION Specify infrastructure configuration using Ansible You are writing code!
  • 7. INFRASTRUCTURE AS CODE •Employ TDD •Version in SCM •Part of the deliverable •Submit to CI •Have a story on the board •Deploy to prod
  • 8. XDD • An activity whereby a feature is described from its user’s perspective prior to its implementation
  • 9. SOFTWARE DELIVERY User Story & Acceptance criteria Code with unit tests Automated tests Specification Implementation Verification
  • 10. UNIFIED DELIVERY From this To this
  • 11. BDD Configuration Instructions Acceptance tests (code) •Instructions can be the acceptance tests •Environments emerge in a running state •Coded tests are living documentation
  • 12. MDD • ServerSpec will serve as the testing framework for the Anisible code • Not in production if it’s not monitored
  • 13. SERVERSPEC describe service('sshd') do it { should be_running } end describe service('ntpd') do it { should be_running } end
  • 14. WHAT WE’RE GOING TO DO Controller Watcher TargetMonitor Configure {
  • 15. WRITE A TEST
  • 16. GET A TARGET Vagrant.configure(VAGRANTFILE_API_VERSION) do |config| = "precise64" config.vm.define "webserver" config.vm.hostname = "webserver" "forwarded_port", guest: 80, host: 8080 "private_network", ip: "" config.vm.provision "ansible" do |ansible| ansible.playbook = "playbook.yml" ansible.inventory_path = "inventory.ini" ansible.sudo = true end end
  • 17. GET A TARGET
  • 18. RUN THE TEST
  • 21. RUN THE TEST
  • 22. CUCUMBER Feature: App deploys to a VM Background: Given I have a vm with ip "" When I provision users on it Scenario: Adding users Then I can log on to it as the "deploy" user And I can log on to it as the "root" user Scenario: Adding Linux dependencies When I run the "webserver" ansible playbook And I log on as "deploy", there is no "ruby" But "gcc" is present
  • 23. CUCUMBER IMPLEMENTATION Then(/^I can log on to it as the "(.*?)" user$/) do |user| result = system "ssh #{user}@#{@ip} exit" result.should be_true end When(/^I run the "(.*?)" ansible playbook$/) do |playbook| command = %W(../devops/#{playbook}.yml -i webhosts) result = system 'ansible-playbook', *command result.should be_true end
  • 24. WHY BOTHER? • ServerSpec is to Ansible as rSpec is to Ruby • You do not want your Ansible code to be used untested
  • 25. SOURCE CONTROL SCaaCC • Ansible code is part of the delivered code • Developers and SysAdmins share code using git for modifications. • HugOps can use master • Others can use branching or forking
  • 26. SOURCE CONTROL • Run ServerSpec prior to committing code • Commit • CI will take care of the rest • Integration tests • Environment Promotion
  • 27. CI Commit CI ServerSpe c Cucumber VMTest VMStaging VMProd
  • 28. XP PRACTICES • SysAdmins are part of the development team • Participate in standups, part of a story/task cards • Participate in pairing sessions • Empathise
  • 29. REFERENCES The Visible Ops Handbook
  • 30. QUESTIONS & THANK YOU! @itababy