AWX supports version control

In an enterprise scenario, individuals storing playbooks locally could be a problem waiting to happen. For example, if user A updates a playbook with a critical fix, how do you ensure that user B has access to that code? Ideally, the code should be stored in a version control system (for example, GitHub) and the local copy updated for every single run.

Good processes are an important component of enterprise automation of Linux and while user B should update their local playbooks before running them, you cannot enforce this. Again, AWX addresses this issue by allowing playbooks to be sourced from a version control repository, with the local copy of the playbooks on the AWX server being updated automatically.

Although AWX can help you, especially when it comes to ensuring the latest version of code has been pulled from the repository, it cannot help with other errant behaviors such as someone not committing their code in the first place. The intention, however, of enforcing the use of AWX for Ansible playbook runs is that anyone who makes changes must commit them for AWX to run them. Local access to the AWX server should be tightly restricted to prevent people from making code changes on the local filesystem, and in this way, you can have confidence that everyone is actively and effectively using your version control system.

These updates can be event-driven so that, for example, local playbooks can be updated every single time a playbook from that store is run. They can also be updated on a scheduled basis or manually, as per the decisions of the AWX administrators. 

AWX can help with the security of your automation too. We shall explore this in the next section by looking at credential management in AWX.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset