How to write Ansible Roles and publish them on Ansible Galaxy?
Configuration management is one of the key areas when it comes to maintaining a fast-paced, agile, and continuous development environment. I am mentioning fast-paced because you can see the number of software and hardware updates you get day in, day out. Even the smallest of devices like your mobile phones get a system update every year. Your source code or library needs a patch fix, your operating systems get updates from time-to-time, your firewalls and firmware need an update. I won’t be able to list down all the changes your development computer goes through. Now imagine the number of changes for a typical development environment, where a number of systems and servers are communicating with each other. If not for the configuration management tools, you would be spending most of your time and a significant workforce just to maintain and enforce these changes. Preventing your environment from configuration drifts, maintaining version control and change control processes, maintaining consistency when it comes to performance, functional and operational aspects, and communication between the teams throughout the entire development and deployment process are some of the important functions that your configuration management tools can take care of. And there are a number of them – Chef, Puppet, Ansible, SaltStack, CF engine are some of the popular ones. Ansible is popular amongst developers to manage complex and multi-tier applications and services across virtual and physical environments because of its simplicity. Ansible Roles and Ansible Galaxy are one of the factors that simplify the management and delegation of tasks.
So, what is Ansible Galaxy?
Ansible Galaxy is Ansible’s official hub for sharing Ansible content. You can jump-start your automation project by using Galaxy with great content from the Ansible community. Galaxy provides pre-packaged units of work known to Ansible as Roles.
What are the Ansible Roles?
Role enables the sharing and reuse of Ansible tasks. It contains Ansible playbook tasks plus all the supporting files, variables, templates, and handlers needed to run the tasks. A Role is a complete unit of automation that can be reused and shared.
Why Ansible Roles?
Roles play an important part in breaking the complex Ansible Playbooks, the core component of any Ansible configuration, into easy to reuse multiple files. With Ansible Roles you can:
- Bundle automation content and make it reusable
- Group multiple sets of tasks in an effective manner
- Modify and reduce syntax errors
- Release modules independent of Ansible Core releases
Ansible Roles are equivalent to modules in Puppet and Cookbooks in Chef.
The ‘ansible-galaxy’ commands
The ‘ansible-galaxy’ command comes bundled with Ansible. You can create, install, and remove Roles using commands. It can be used for the following actions:
- Init: A Role requires various directories and main.yml files. Using the init command you can initialize the base structure of a new Role and save the time required to create directories and files.
- Info: With the info command you can see more details about a specific Role.
- Install: You can download and install Roles from the Galaxy website using the install command. (Works similar to ‘pip install’ in python)
- List: Use list to show the name and version of each Role installed in the roles_path. (Works similar to ‘pip freeze’ in python).
- Remove: Use remove to delete a Role from roles_path.
Ansible Role Structure and its significance
- README.md – This is the Readme file for the role. Put the detailed information of all the input parameters for the role and example yml in the readme file.
- tasks – You can enlist all tasks to be executed by the Role in tasks. Main.yml of the tasks is the entry point for the Role (this is where the execution starts). One can include other files into this file.
- handlers – Contains handlers, which may be used by this role or even anywhere outside this role.
- defaults – Default variables for the Role.
- vars – Other variables which are of more priority than the defaults for Role.
- files – This contains the files which can be deployed via Role.
- templates – Contains templates which can be deployed via Role.
- meta – You can define metadata for the Role in meta. Other Role dependencies, if any, should be mentioned in this file.
- tests – CI tests to be executed.
- library – Embedding Modules and Plugins in Roles (Not created by init command). If required one can define custom module in python in this folder and use it in the tasks.
Writing an Ansible Role
Writing an Ansible Role is fairly easy. Follow the aforementioned steps to write a Role:
1. Initialise the role structure using the command:
ansible-galaxy init <role-name>
2. Go to role directory using:
3. Initialise for Git:
4. Do the necessary changes required to add role functionality.
5. Add files to Git using the command:
git add *
6. Commit the changes to Git:
git commit -m “Initial commit for <role-name>”
7. Set your public repository origin:
git remote add origin <github-url>
8. Push the changes to the repository using the command:
git push origin master
9. Release a version in the releases tab of GitHub which will be published in Galaxy as a Role.
Publishing an Ansible Role
Log in to Galaxy using GitHub credentials.
Go to “My Content” tab. Click on “add content” of namespace where the role is pushed on GitHub.
Select the role repository to add to.
After adding the repository, you can find it in the tab “My Imports”.
Click on the import icon, in the top right corner, to import the latest release in Ansible Galaxy.
Best Practices to be followed while developing Ansible Roles
- Name of git repo should be same as Role name.
- Variables names in the Roles should be unique, should not override other Role/playbook variables. To achieve this, use Role prefix for every variable in the Role.
- List the other Role dependencies in the meta/main.yml
- Search for Ansible Galaxy role if you can reuse existing Role for the requirement.
- Use Git tags as Role versions
- As Role is a reusable component, it should not contain any inventories or playbooks.
- Add test automation in the test folder. Integration with Travis CI is a simple and easy way to write CI pipeline for Ansible Roles.
- Role variables defined in ‘vars’ have a very high precedence – they can only be overwritten by passing them on the command line in the specific task or in a block. Therefore all your variables should be defined in the ‘defaults’ unless those are constants.
Ansible Galaxy is like a vault with valuables for Ansible users. You can check for anything you want to implement by simply searching it in Ansible Galaxy if the same problem is addressed by someone else you can simply reuse it instead of starting from the scratch. Even if you find something close to what you are looking for you can simply make the changes as per the requirement and use it. So, if you have developed interesting workflows using Ansible which you think can be reused, consider developing Ansible Roles for the same.
This was all about how you can push your Ansible Roles on Galaxy. I will be coming up with a part 2 of this blog where I will be talking about how you can use Ansible Galaxy for faster development. Stay tuned!