Good morning,
I am working on setting up an ansible repository, for work. We are going to be using AWX eventually ( sooner rather than later ). What I am wondering, is how people decided to split up their ansible project directories. My first thought was to just have a single project with all of our playbooks in that but I am starting to question whether that is the correct path or not.
Along with that, when it comes to source control, are you storing your roles in a separate repo per role, or all in one repo. For myself personally ( homelab ), I have a single project, and all of my roles have their own repo, but I am not sure how that scales to a larger organization.
Good morning,
I am working on setting up an ansible repository, for work. We are going to be using AWX eventually ( sooner rather than later ). What I am wondering, is how people decided to split up their ansible project directories. My first thought was to just have a single project with all of our playbooks in that but I am starting to question whether that is the correct path or not.
Not so obvious to answer !
Along with that, when it comes to source control, are you storing your roles in a separate repo per role, or all in one repo. For myself personally ( homelab ), I have a single project, and all of my roles have their own repo, but I am not sure how that scales to a larger organization.
One role per repo with version tags !
Like this you can use version in your requirements file and decide which version is working for you in your context. Periodically you need to update versions and make some adjustments to code after testings !
The more a role is going to be used by different people, the more you will need a concensus about changes and decide what change can be done in in a minor and in a major release version !
One repo per role is the general advice, but it does depend a bit. We built a body of over 200 roles at my last job, and over time we found that managing a ‘package’ of know good versions got very unwieldy, and people had trouble managing their requirements.yml. Our first solution was to build a ‘bundle’ of roles. So, the devops central team published a package of all 200+ roles once per PI, and projects just unzipped the whole thing into their build folders as part of CI/CD pipeline. In my new job, I’m taking a different approach and using a mono-repo of all the roles and it seems to be working well. It has a lot to do with who will use the roles. In our case, we have a ton of devs who dont have the time or inclination to keep track of versions, or deug issues. They just want a bundle that has been tested and is know to work.
Interesting… I hadn’t thought about the versioning thing. Most of the stuff we are doing, is either package installs, or basic server administrative operational type tasks. We are just getting started using ansible ( I have been using it for my fleet of Pi’s for about 2 ish years now ), so I don’t have a good handle on how many roles we are going to have. I would like us to implement some sort of testing environment, using molecule or some other method as part of this, so hopefully any versioning issues we hope we can catch in test, but I know that won’t be 100% effective. I definitely keep going back and forth between a single repo for all the roles, or a repo per role.