MONITOR-DRIVEN
INFRASTRUCTURE
DEVELOPMENT USING
ANSIBLE
Itamar Hassin
THE PREMISE
• Ansible scripts should be treated with the
same rigour with which we treat application
code
• In the way the...
JAMES WHITE MANIFESTO
•There is one system, not a collection of systems.
• The desired state of the system should be a kno...
UNTESTED CODE
WHY ANSIBLE?
•Assures scalability
•Repeatable and measurable
•Assures environments for consistent
development testing
Do n...
THE REVOLUTION
Specify infrastructure configuration using
Ansible
You are writing
code!
INFRASTRUCTURE AS
CODE
•Employ TDD
•Version in SCM
•Part of the deliverable
•Submit to CI
•Have a story on the board
•Depl...
XDD
• An activity whereby a feature is described
from its user’s perspective prior to its
implementation
SOFTWARE DELIVERY
User Story &
Acceptance
criteria
Code with unit
tests
Automated
tests
Specification Implementation Verif...
UNIFIED DELIVERY
From this To this
BDD
Configuration
Instructions
Acceptance tests
(code)
•Instructions can be the acceptance tests
•Environments emerge in a...
MDD
• ServerSpec will serve as the testing
framework for the Anisible code
• Not in production if it’s not monitored
SERVERSPEC
describe service('sshd') do
it { should be_running }
end
describe service('ntpd') do
it { should be_running }
e...
WHAT WE’RE GOING TO
DO
Controller
Watcher
TargetMonitor
Configure
{
WRITE A TEST
GET A TARGET
Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
config.vm.box = "precise64"
config.vm.define "webserve...
GET A TARGET
RUN THE TEST
GET APACHE PLAYBOOK
CONFIGURE TARGET
RUN THE TEST
CUCUMBER
Feature: App deploys to a VM
Background:
Given I have a vm with ip "33.33.33.33"
When I provision users on it
Sce...
CUCUMBER
IMPLEMENTATION
Then(/^I can log on to it as the "(.*?)" user$/) do |user|
result = system "ssh #{user}@#{@ip} exi...
WHY BOTHER?
• ServerSpec is to Ansible as rSpec is to Ruby
• You do not want your Ansible code to be
used untested
SOURCE CONTROL
SCaaCC
• Ansible code is part of the delivered code
• Developers and SysAdmins share code
using git for mod...
SOURCE CONTROL
• Run ServerSpec prior to committing code
• Commit
• CI will take care of the rest
• Integration tests
• En...
CI
Commit CI
ServerSpe
c
Cucumber VMTest
VMStaging
VMProd
XP PRACTICES
• SysAdmins are part of the development
team
• Participate in standups, part of a
story/task cards
• Particip...
devopsdays.org
REFERENCES
The Visible Ops Handbook
blog.websages.com/2010/12/10/jameswhite-manifesto/
rspec.info serverspe...
QUESTIONS & THANK YOU!
@itababy
www.in-context.com
Upcoming SlideShare
Loading in...5
×

Monitor-Driven Development Using Ansible

3,220

Published on

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.

Published in: Software, Technology

Monitor-Driven Development Using Ansible

  1. 1. MONITOR-DRIVEN INFRASTRUCTURE DEVELOPMENT USING ANSIBLE Itamar Hassin
  2. 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. 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.
  4. 4. UNTESTED CODE
  5. 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. 6. THE REVOLUTION Specify infrastructure configuration using Ansible You are writing code!
  7. 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. 8. XDD • An activity whereby a feature is described from its user’s perspective prior to its implementation
  9. 9. SOFTWARE DELIVERY User Story & Acceptance criteria Code with unit tests Automated tests Specification Implementation Verification
  10. 10. UNIFIED DELIVERY From this To this
  11. 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. 12. MDD • ServerSpec will serve as the testing framework for the Anisible code • Not in production if it’s not monitored
  13. 13. SERVERSPEC describe service('sshd') do it { should be_running } end describe service('ntpd') do it { should be_running } end
  14. 14. WHAT WE’RE GOING TO DO Controller Watcher TargetMonitor Configure {
  15. 15. WRITE A TEST
  16. 16. GET A TARGET Vagrant.configure(VAGRANTFILE_API_VERSION) do |config| config.vm.box = "precise64" config.vm.define "webserver" config.vm.hostname = "webserver" config.vm.network "forwarded_port", guest: 80, host: 8080 config.vm.network "private_network", ip: "33.33.33.33" config.vm.provision "ansible" do |ansible| ansible.playbook = "playbook.yml" ansible.inventory_path = "inventory.ini" ansible.sudo = true end end
  17. 17. GET A TARGET
  18. 18. RUN THE TEST
  19. 19. GET APACHE PLAYBOOK
  20. 20. CONFIGURE TARGET
  21. 21. RUN THE TEST
  22. 22. CUCUMBER Feature: App deploys to a VM Background: Given I have a vm with ip "33.33.33.33" 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. 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. 24. WHY BOTHER? • ServerSpec is to Ansible as rSpec is to Ruby • You do not want your Ansible code to be used untested
  25. 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. 26. SOURCE CONTROL • Run ServerSpec prior to committing code • Commit • CI will take care of the rest • Integration tests • Environment Promotion
  27. 27. CI Commit CI ServerSpe c Cucumber VMTest VMStaging VMProd
  28. 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. 29. devopsdays.org REFERENCES The Visible Ops Handbook blog.websages.com/2010/12/10/jameswhite-manifesto/ rspec.info serverspec.comcukes.info ansible.com galaxy.ansible.com
  30. 30. QUESTIONS & THANK YOU! @itababy www.in-context.com
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×