Monitor-driven infrastructure Development using Ansible

Monitor-driven infrastructure Development using Ansible

Itamar Hassin

The premiseAnsible scripts should be treated with the same rigour with which we treat application codeIn the way theyre testedIn the way theyre written

Because: Code cannot go untested to prod. Merge development activities across the different teams

James White manifestoThere 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.

Basically eliminates the snowflake syndrome

Untested Code

Because: Code cannot go untested to prod. Merge development activities across the different teams

Why Ansible?Assures scalabilityRepeatable and measurableAssures environments for consistent development testingDo not improve manual processesif you can automate them instead.Fail fast (offline!) and cycle quicklyTime To Rebuild System < Time To Fix It

Do not improve manual processes if you can automate them instead.

The revolutionSpecify infrastructure configuration using Ansible

You are writing code!

DSL - Domain Specific Language

Infrastructure as codeEmploy TDDVersion in SCMPart of the deliverableSubmit to CIHave a story on the boardDeploy to prod

Source Code Management

XDDAn activity whereby a feature is described from its users perspective prior to its implementation

Software deliveryUser Story & Acceptance criteriaCode with unit testsAutomated testsSpecificationImplementationVerification

Unified DelivEry

From thisTo this

BDDConfigurationInstructionsAcceptance tests(code)

Instructions can be the acceptance testsEnvironments emerge in a running stateCoded tests are living documentation

No more VDDsNo more flakey smoke tests

MDDServerSpec will serve as the testing framework for the Anisible codeNot in production if its not monitored

Applies the same principles of lean development to code that represents machines

ServerSpecdescribe service('sshd') doit { should be_running }enddescribe service('ntpd') do it { should be_running }end

What were going to do

ControllerWatcherTarget

MonitorConfigure

{

Write a test

Get a targetVagrant.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 endend

Get a target

Run the test

Get Apache playbook

Configure target

Run the test

CucumberFeature: 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

Cucumber ImplementationThen(/^I can log on to it as the "(.*?)" user$/) do |user| result = system "ssh #{user}@#{@ip} exit" result.should be_trueend

When(/^I run the "(.*?)" ansible playbook$/) do |playbook| command = %W(../devops/#{playbook}.yml -i webhosts) result = system 'ansible-playbook', *command result.should be_trueend

Why bother?ServerSpec is to Ansible as rSpec is to RubyYou do not want your Ansible code to be used untested

Source controlSCaaCCAnsible code is part of the delivered codeDevelopers and SysAdmins share code using git for modifications.HugOps can use masterOthers can use branching or forking

SourceControl As A Communications Channel

Source controlRun ServerSpec prior to committing codeCommitCI will take care of the restIntegration testsEnvironment Promotion

SourceControl As A Communications Channel

CICommitCIServerSpecCucumberVMTestVMStagingVMProd

Automated Promotion

XP PracticesSysAdmins are part of the development teamParticipate in standups, part of a story/task cardsParticipate in pairing sessionsEmpathise

devopsdays.orgReferencesThe Visible Ops Handbookblog.websages.com/2010/12/10/jameswhite-manifesto/rspec.infoserverspec.comcukes.infoansible.comgalaxy.ansible.com

Questions & Thank you!

@itababywww.in-context.com