This document serves to guide the development of Ansible roles, by providing relevant templates and style guides.

Generating roles

1. Roles should be generated with ansible-galaxy using the role skeleton

Coverage

1. The role must be accurately described in meta/main.yml
2. Your role should support at least the operating systems currently supported for EGI sites, unless it’s specific to a particular supported OS.

Variables

• ℹ️ Remember Ansible variable file separation
• ℹ️ Remember the Ansible variable precedence

1. All variables used in defaults/ and vars/ must be described in meta/main.yml, in the relevant section.
2. Default variables should be defined wherever possible
3. Variables names should not bias deployment scenarios or include platform names. Instead, use facts
   • Avoid variables like if_centos ➡️ Prefer if (ansible_os_family == 'redhat')
4. Construct unique variables for various deployment scenarios.
   • If a variable value varies across environments, construct it so that these environments are taken into account.
   • Avoid
5. Default vars should pass tests.
6. Provide sane range defaults for variables where applicable, in the README.
7. Variables should be kept to the bare minimum; unused variables should be eliminated.
8. Check Ansible best practices: the essentials.

Secrets

• ℹ️ Secrets are variables which are required for the role to be expressed and which may change the desired behaviour of the role from site to site.
• ℹ️ Examples include, but are not limited to
  • user data, especially passwords
  • API tokens
• ℹ️ Ansible provides a vault which can be used to protect secrets.

1. ☠️ ☠️ ️☠️️ ️ ️Avoid putting secrets in the repo ☠️ ☠️ ☠️ ️
2. ☠️️☠️️ If you must put secrets in the repo ☠️️☠️️ then they must be encrypted and the repository should be private.
3. ☠️️ Remove the need to use secrets in a role️️ ☠️
   • If secrets variables are needed, default them to safe values
   • Document the need to pass variables on the command line