We would like a way to have all of AWX’s configuration (e.g. projects, job templates, inventory scripts, users, teams, and so on) be sourced from a Git repo, so that we can spin up AWX clusters that obtain all of the same configuration, and also to take advantage of version control on those objects.
Is something like this possible out of the box? I see that there is some support to source some things other than the actual Ansible code from Git in recent versions, but that doesn’t appear to be the case for all objects within AWX.
Today if we need to copy configuration from one AWX instance to another, it generally means exporting/importing using the command-line awx or tower-cli in the past.
I’ve been thinking about perhaps starting a repo containing all of the configuration we are interested in, which we could use Jenkins to push changes out to one or more AWX instances. If something like this exists already I’d rather just use that however.
I think you’ll need to provision your AWX instances and deploy your configuration using ansible, I think that’s the easiest way of doing it. You can use the ansible tower modules or the awx collection to interact with AWX, that way you write your playbooks to provision your AWX instances and config.
Hi Cesar, indeed, long time no see, hope all is well.
Yeah, we are trying to come up with a better way than to store everything in playbooks… maintaining the code this way is kind of painful. What I am considering doing is exporting these using the CLI from a staging AWX instance into a repo where we could open PRs to merge into say the master branch. We would then push from master out to the production instances.
There are import/export modules in the collection which sit on top of awxkit if you want to leverage them. Not to state the obvious but I’d recommend awxkit instead of tower-cli for this work.
And I have my tower configuration as code as vars in the form of a yaml data structure. I use git lab so I have a pipeline that runs awx-cli that connects to my awx instance to make changes every time my configuration changes. This includes credentials which are vaulted.
I also include my inventory details in here as well and depending on what it is I use tags to run certain parts of a playbook to implement.
End result? I control my tower configuration. If it is a change in my inventory (depending on whether it will cause an outage). after I push to master, through my pipeline I also make the change to infrastructure at the same time after the tower configuration is made using the corresponding playbook