Ansible - Tighten your quality feedback loop

Keep your development habits when using Ansible.

Transcript

1. Tighten your Ansible quality feedback loop nsible
2. 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 - ...
3. 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
4. ansible-playbook --syntax-check server-spec test playbook in vagrant Ansible Lint in your continuous build
5. Syntax check & Best practices
6. --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" ^
7. 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
8. 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
9. Integration tests
10. Vagrant as your dev environment create machines on the fly, provision, test, drop → in a sandox
11. 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
12. 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
13. 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
14. 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 ?
15. Other developer habits - Version control - Pull request, feature branch, code reviews - Issue tracking - Refactoring - Patterns / Anti-patterns - Profiling callbacks - Continuous Integration & Delivery
16. 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
17. 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