Dear Ansible Community,
having your Infrastructure in Code, means you manage the code with a version control system (e.g. git). I have a case where I also configure the application we deploy with Ansible with various XML configuration files. Parts of this application configuration should not be touched by others, only by my code. But other parts of it should also be configured by others as well, outside of my code, to provide them with Self-Service.Because if I would not provide Self-Serivce, it means I get a ticket for each little change they want and I have to do it within my code and version control system. So parameters should come from an outside source and not be under version control. In Ansible this could come from a dynamic inventory. I like to work on this kind of topic in my bachelor thesis. So I’m looking for any whitepapers where such kind of topics have already been discussed and solved.
Hints to any source of information would be very appreciated! Thanks!
Dear Ansible Community,
having your Infrastructure in Code, means you manage the code with a
version control system (e.g. git). I have a case where I also configure the
application we deploy with Ansible with various XML configuration files.
Parts of this application configuration should not be touched by others,
only by my code. But other parts of it should also be configured by others
as well, outside of my code, to provide them with Self-Service.
I understand so far.
So parameters should come from an outside source and not be under
version control.
I don't get this bit - just because things are external, why would they not be
version-controlled?
In Ansible this could come from a dynamic inventory.
It could, yes, but why not simply give these "others" who need Self-Service
write access to selected parts of the git repository, and then get ansible to
pull everything in from a version-controlled and documented source?
I would in fact suggest that it is *more* important to have these Self-Service
inputs under a version control system, because sooner or later someone is
going to say "why is this machine doing that?" and you can point to the update
they made to the configuration which made it do it.
If ansible just pulls in non-versioned XML files from somewhere, you have no
way of telling when a certain change got made, by whom (or why), nor even what
it was changed from.
Regards,
Antony.
If that’s the case why not create a survey that these guys can fill out. The fields are mapped to extra vars and these can then be supplanted as parameters into the code. (Using the template module )
Hi! Thanks for your replies. Let me rephrase what I’m looking for:
I’m looking for solutions or experiences with having a Change Management Database (CMDB) as “parameter registry” for Ansible. So in a scenario where Ansible does also application configuration, externals could place their changes in a self-service portal (for example list of FTP users or address for mail notifications…). This portal then writes the changes as parameter into a CMDB and triggers Ansible (or AWX) to run for specified hosts to apply the changed/new parameter.
To answer the question: why not give the externals access to git?
I want something more user friendly. At the moment I have about 70 different group files in git, each of them would need specific access for each external. I also don’t want to teach them how to use git, commit messages, Merge Requests, YAML Syntax, understand our variables in git etc.
Thanks
Andreas
My question was not to give them access to git. I assumed you were using awx.
So let’s go back to using a cmdb and ansible cmdline. Ok. Then you could make use of a lookup of your cmdb database. It’s an interesting idea!
At a high level you would want something that can read your cmdb database. Create automation to put them as vars( whether that is a file or environment variables) that ansible can then read. Then execute the playbook with the right limit and environment variables to ansible-playbook
I am presuming yoy could do this in a pipeline such as gitlab.