Peeps,
Sorry if this has been asked, but I couldn’t find it in the mailing list . . .
Does anyone have an opinion as to whether it’s better to keep all ansible code in one repo, or whether it’s better to keep separate repos for each group/app/arbitrary distinction? I can see the benefits and pitfalls of both, but can’t tell which outweighs the other.
Any thoughts are greatly appreciated.
Regards,
Guy Matz
I assume you’re talking about a git repo? If that’s the case, I think that it’s easier to keep it all in one repo (and there probably
isn’t a performance penalty since ansible code doesn’t take up much space). However, you could make a case that separate
repos are more security conscious. Keeping it all in one repo also makes it easier to re-use code.
J
Hi Guy,
I've probably tried a broad spectrum on this topic, from a huge playbook covering all my systems, to something very fine grained. I now lie in the middle.
My first approach few years ago was to try to encompass all my needs in one playbook . I didn't even have roles (it was more a side feature at that time). The result was, of course, something completely unusable: side effects were numerous, things were failing all the time, and configuration drift started to cripple in. So, in the end, whatever you choose do, please just don't do this. You wont manage everything in one playbook and one inventory (unless you have a small, i.e.. "project-size", infrastructure). It will just grow to a monster that will eat you.
Now, assuming you have dedicated systems per project, I (currently) think the right size is the project size.
- one repo per role
- one repo containing playbooks & inventories (you might have several inventories e.g. dev, prod, ...)
- each required role as a submodule in playbook's roles/
- one ansible.cfg to point to the proper inventory (dev by default, to limit production accidents)
Having roles as submodules in playbook will let you improve roles without impacting other projects.
I usually split my playbooks per topic (baseline install, daemons, application, ...) but I try to limit splitting as it complicates things (variable, facts & handlers scoping). I use tags when I can but they come with the same limitations, although fact caching (I use Redis) helps a bit.
I also try to list each role explicitely in my playbooks, and try not to rely on dependency magic (and I don't use Galaxy).
Listing dependencies explicitely helps tracking down problems, and makes playbooks much more readable. Generally speaking, role coupling is your worst enemy.
I am pretty happy with this setup right now, but in the end, it is very dependent on your environment and style.
M