Tighten your Ansible quality feedback loop nsible

Why I trust ansible code, but not mine. There many ways to get my yaml config wrong - syntax errors, wrong vars, - bad module usage, - wrong order between tasks - missing handler - ...

How Use my developer habits to get quick feedback on my coding/config errors Let’s have look at the tools that can do - syntax check, enforce best practices - help me write integration tests

ansible-playbook --syntax-check server-spec test playbook in vagrant Ansible Lint in your continuous build

Syntax check & Best practices

--syntax-check ● prevent stupid typo issue ○ yaml spacing/syntax ○ bad include ○ ... ERROR: Syntax Error while loading YAML script, _test.yml Note: The error may actually appear before this position: line 4, column 22 tasks: - debug: msg= "foo: bar" ^

Ansible lint https://github.com/willthames/ansible-lint ● promote best practices ○ use idempotent module instead of raw command ○ always specify tag/sha not latest for git ● Got flamed when announced ● Making his way in ansible core

Ansible lint (2) Additional rules, I’d like to see - Prefer Shell over Raw - Too long playbook, split in tasks or roles - Too long roles, use includes - Enforce a style guide (prefer multiline) - Check for copy/paste of action (name) - Didn’t forget to remove debug action

Integration tests

Vagrant as your dev environment create machines on the fly, provision, test, drop → in a sandox

Ansible test playbook sample : https://github.com/blueboxgroup/ursula/tree/master/playbooks/tests/tasks --- - hosts: controller tasks: - name: horizon is up shell: curl http://localhost:8080 | grep "Login - OpenStack Dashboard" - name: common timezone is utc shell: grep Etc/UTC /etc/timezone - name: common date command has utc shell: date | grep UTC

Ansible test playbook + same language (used by ansible for integration test) accelerate vagrant provision-ssh-check-provision-... - test are low level, open for human error : no reusable assertion simple report and runner

server-spec sample : https://github.com/volanja/ansible-sample-tdd require 'spec_helper' describe package('nginx') do it { should be_installed } end describe service('nginx') do it { should be_enabled } it { should be_running } end describe port(80) do it { should be_listening } end describe file('/etc/nginx/nginx.conf') do it { should be_file } it { should contain "worker_connections 1024;" } end

Why these tests ? Safety net to refactor your config/code/vars - a growing small tasks/part of roles that becomes a role in it self, extract in a separate task/role did I include the task, does some tasks were depending on it,... - introduction of a variable, use in a template, verify it’ s taken into account by the service Introduce a new variable for redis password, the conf should contain the require pass, when issuing a redis-cli pong without auth token shouldn’t allow my command. Did I miss a service restart ?

Other developer habits - Version control - Pull request, feature branch, code reviews - Issue tracking - Refactoring - Patterns / Anti-patterns - Profiling callbacks - Continuous Integration & Delivery

Continuous integration http://renemoser.net/blog/2014/01/01/test-ansible-roles-with-travis-ci/ all these tests can be run on your CI server - at each commit - on multiple platforms - with a fresh environment - in an objective way : red or green

Stuff I borrowed, more on the subject http://willthames.github.io/devops-bris-ansible/#/ http://renemoser.net/blog/2014/01/01/test-ansible-roles-with-travis-ci/ https://groups.google.com/forum/#!msg/ansible-project/7VhqDDtf6Js/wVH6jm-sjGUJ http://www.sharknet.us/blog/2013/12/12/ansible-testing/ http://www.sharknet.us/blog/2014/02/06/infrastructure-testing-with-ansible-and-serverspec-part-2/ http://arrfab.net/blog/?p=431