Since I intend to use Ansible for deployments of software into the various tiers (development, integration, production), the last thing I will provision in the #devops environment is Ansible itself. In #316: Install Ansible on CentOS7, I had installed it manually but will now roll it into the general provisioning of the environment, and stick with a specific version.
(1) In the local inventory (ansible.inventory), define a new role “ansible” for build servers on which Ansible will be installed.
(2) Setup the role with a directory layout similar to what’s in the image below.
The role’s playbook (tasks/main.yml) first checks whether Ansible is already installed, and if not, proceeds with its installation. It uses variables in vars/main.yml (unencrypted) and vars/secrets.yml (encrypted).
The secret here is the Ansible Vault password, which will be written to all build servers. The strategy is that sensitive data in source code is encrypted using this same Vault password across the board, and that the build servers should be able to decrypt the data in flight during tier configuration, builds, and deployments.
Vault is a huge bonus for Ansible in the world of infrastructure automation because it is part-and-parcel of the framework, as opposed to Chef or Puppet that do not have native encryption schemes. I also like that secrets are only decrypted in memory (and fast), eliminating the chance that temporary files with the decrypted secrets could exist post-process in the build environment. Beware that logging should be tweaked to not print secrets to logs and consoles during the process.
With Ansible installed, we have a system fully provisioned and ready to perform #devops duties, which will include obtaining source code from a Git repository, building the software and running tests in Jenkins, and deploying the final product to the designated tier as needed.
The complete sources can be reviewed from my Github/08_ANSIBLE branch.