Ansible is known for its simplicity, lightweight footprint and flexibility to configure nearly any device in your infrastructure. Therefore it’s used in large scale environments shared between teams or departments. This leads to even bigger Ansible environments which need to be tracked or managed in version control systems like Git.
Mostly environments grow with their usage over time, in this case it can happen that all roles are managed inside one big repository. Which will eventually lead to quite messy configuration and loss of knowledge if roles are tested or work the way they supposed to work.
Ansible provides a solution which is called Galaxy, it’s basically a command line tool which keeps your environment structured, lightweight and enforces your roles to be available in a specific version.
First of all you can use the tool to download and manage roles from the Ansible Galaxy which hosts many roles written by open-source enthusiasts. 🙂
# ansible-galaxy install geerlingguy.ntp -v
Using /Users/twening/ansible.cfg as config file
- downloading role 'ntp', owned by geerlingguy
- downloading role from https://github.com/geerlingguy/ansible-role-ntp/archive/1.6.4.tar.gz
- extracting geerlingguy.ntp to /Users/twening/.ansible/roles/geerlingguy.ntp
- geerlingguy.ntp (1.6.4) was installed successfully
# ansible-galaxy list
# /Users/twening/.ansible/roles
- geerlingguy.apache, 3.1.0
- geerlingguy.ntp, 1.6.4
- geerlingguy.mysql, 2.9.5
Furthermore it can handle roles from your own Git based repository. Tags, branches and commit hashes can be used to ensure it’s installed in the right version.
ansible-galaxy install git+https://github.com/Icinga/ansible-icinga2.git,v0.2.0
- extracting ansible-icinga2 to /Users/twening/.ansible/roles/ansible-icinga2
- ansible-icinga2 (v0.2.0) was installed successfully
It’s pretty neat but how does this help us in large environments with hundreds of roles?
The galaxy command can read requirement files, which are passed with the “-r” flag. This requirements.yml file can be a replacement for roles in the roles path and includes all managed roles of the environment.
# vim requirements.yml
- src: https://github.com/Icinga/ansible-icinga2.git
version: v0.2.0
name: icinga2
- src: geerlingguy.mysql
version: 2.9.5
name: mysql
Then run ansible-galaxy with the “–role-file” parameter and let galaxy manage all your roles.
# ansible-galaxy install -r requirements.yml
- icinga2 (v0.2.0) is already installed, skipping.
- downloading role 'mysql', owned by geerlingguy
- downloading role from https://github.com/geerlingguy/ansible-role-mysql/archive/2.9.5.tar.gz
- extracting mysql to /Users/twening/.ansible/roles/mysql
- mysql (2.9.5) was installed successfully
In case you work with Ansible AWX, you can easily replace all your roles with this file in the roles directory and AWX will download and manage your roles directory automatically.
A example project could look like this.
awx_project/
├── example_playbook.yml
├── group_vars
├── host_vars
├── hosts
└── roles
└── requirements.yml
In summary, in large environments try to keep your code and configuration data separated, try to maintain your roles in their own repository to avoid conflicts at the main project.
Check out our Blog for more awesome posts and if you need help with Ansible send us a message or sign up for one of our trainings!
0 Comments