- Development branch:
- Master branch:
Cookiecutter recipe to easily create ansible roles. This is a fork of the excellent iknite/cookiecutter-ansible-role project that I used as a starting point.
- Follows Ansible best practices
- Follows Ansible Galaxy best practices
- Only Creates the necessary files and folders
- Blazing fast creation, forget about file creation and focus in actions
- Lint checks (Ansible-lint, yamllint)
- Test infrastructure already implemented (Test-kitchen, kitchen-ansible, kitchen-docker, InSpec + kitchen-inspec):
- Test your roles against multiple platforms using the power of Docker
- The life cycle of each platform is automatically managed by Test-kitchen
- Your roles can be verified with InSpec
- Travis-CI integration ready, with support for parallel builds: (.travis.yml, badges in README.md for development and master branches)
- Parallel test execution ready ({{cookiecutter.role_name}}/test/scripts/test-role.sh)
- Install cookiecutter:
pip install cookiecutter cookiecutter https://github.com/ferrarimarco/cookiecutter-ansible-role
It will ask you questions about the structure of your role like tasks names, handlers names, and default variables. You can jump to the next question by entering an empty string.
See README.md of the generated role.
ROLE CONFIGURATION:
===================
Should it have tasks? [Y/n]
Add task name i.e (Install packages) Add some task
Add task name i.e (Install packages) another task
Add task name i.e (Install packages)
Should it have handlers? [Y/n]
Add handler name i.e (Restart uwsgi) restart something
Add handler name i.e (Restart uwsgi) alert someone
Add handler name i.e (Restart uwsgi)
It should contain default variables?: [Y/n]
Add variable i.e (operator: : drunken_master) var: name
Add variable i.e (operator: : drunken_master)
Should it have meta info? [Y/n]
- Should it have dependencies? [Y/n]
Add dependency i.e ({role: aptsupercow, var: 'value'}) {role: cool, version: latest}
Add dependency i.e ({role: aptsupercow, var: 'value'})
Should it have templates? [Y/n] n
Should it have files? [Y/n] y
While developing roles, I always wanted to test them in an ephemeral environment.
In my first role, I just ran a quick syntax check using the --syntax-check switch. Then I came across this blog post by Jeff Geerling and I was able to use his approach to use Travis CI to run my role against different platforms (via Docker), while also testing the its idempotence.
That methodology had a limitation: running tests on my local Docker environment was cumbersome and not practical as the process had too many "copy-and-paste-from-.travis.yml" steps. I managed to mitigate this issue to a certain extent by moving commands from .travis.yml to dedicated shell scripts (that you can now find in the test/scripts directory).
This partially solved the issue but the .travis.yml still contained the environment variables that described the platforms to run against (i.e. the Docker containers). So I still had some manual steps to tackle.
Then I stumbled upon Test-Kitchen. It's a testing framework with a plug-in interface. You can use it with various combinations of drivers (Docker, Vagrant...), provisioners (Ansible, Chef, Puppet...) and verifiers (RSpec, Serverspec, InSpec...). This completely abstracts the test environment from the "test runtime" environment, in the sense that you can run the same set of tests against different platforms, no matter the environment you use to run such tests. But wait, couldn't you just use plain docker for that? Yes, but you have to manage the life cycle of the test environments by yourself.