I've been using Ansible for about a year now. It started off relatively simple to manage, but as more people have started contributing to my company's Ansible repo we have started to step on each others toes. We are in the process of splitting out our roles from a central ansible repo and into their own Github repos. We would then use "ansible-galaxy install" with a requirements.yml file that defines roles stored in Github with the version to use for specific playbooks.
I found a couple helpful blog posts and notes in Ansible documentation: http://guifreelife.com/blog/2015/05/16/Manage-Ansible-Playbooks-and-Roles/ http://willthames.github.io/2014/09/03/techniques-for-versioning-ansible-ii.html http://docs.ansible.com/ansible/galaxy.html#id2 Here's the directory structure of our shared Github repo after moving to external roles: main-ansible-repo . ├── inventory │ ├── hosts │ └── group_vars │ ├── prod.yml │ └── stage.yml │ └── host_vars │ ├── prod1.yml │ └── stage1.yml └── feature1-playbooks ├── roles/ ├── requirements.yml ├── ansible.cfg ├── playbook1.yml └── playbook2.yml └── feature2-playbooks └── roles/ └── vault-vars/ The main-ansible-repo contains a shared inventory with ansible-vault files and other variable files that are included in playbooks. We would like to keep the inventory centralized as there are a lot of variables defined that affect many roles and playbooks. Vault files are also difficult to share since you can't do a diff to find out what's changed. requirements.yml will look something like this (from Ansible Galaxy Docs <http://docs.ansible.com/ansible/galaxy.html#advanced-control-over-role-requirements-files> ): # from github, overriding the name and specifying a specific tag and path - src: https://github.com/bennojoy/nginx version: v1.0.0 name: nginx_role path: playbook-role/ I'm still trying to wrap my head around how best to develop the new roles if they are stored in a separate Github repo. I also want to workflow to be simple enough so that people who are not as familiar with Ansible and Github can start contributing without much of a learning curve. It seems like this workflow would add a few extra steps to contributing to roles that would hinder development because you would have to 1) commit and push changes to the role repo, 2) update the release tag in Github, 3) update the version of the role in requirements.yml, 4) run ansible-galaxy install to update the role, 5) then finally run a playbook to test your changes. I've thought of one possible workaround that may simplify the workflow: 1. Create directory structure on a development machine would look something like this: . ├── ansible-development/ ├── main-ansible-repo ├── ansible-role-feature1 └── ansible-role-feature2 2. Inside the main-ansible-repo/feature1-playbooks directory, ansible.cfg would include paths to the external roles as well as roles inside the main repo. roles_path = roles:../roles:~/ansible-development 3. When making changes to the role, I would delete the ansible-galaxy installed role, and make my changes directly to the cloned Github repository in the ansible-development folder. After changes have been made and tested, I would set a new version tag in Github and update requirements.yml to reflect the new version. Please send any other ideas or feedback. I've seen a lot of discussion on how to version roles in Ansible, but not a lot of how to setup a workflow for teams to collaborate. Is anyone else in a similar situation or have a similar setup? Thanks so much for your help and feedback! -- You received this message because you are subscribed to the Google Groups "Ansible Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/438e6f4c-cdeb-4b39-b9fb-9a1685f1f3e2%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
