There are a number of variables that are important to set in the Ansible Tower configuration for correct operation with the SovLabs module. This document works through each entity in the Ansible Tower platform from base entities like Organizations, Credentials to the more complex entities like Projects and Inventories. We finish with the Job Template which defines the playbook execution parameters that the SovLabs module uses to launch Ansible playbooks.
Organization
The SovLabs module has the capability to create an Organization in Ansible Tower. This is useful for test environments as it reduces the configuration steps required in Ansible Tower. However for production scenarios it is not recommended to grant System Administrator rights for this functionality. It is recommended that the Ansible Tower administrator creates an Organisation in Ansible Tower.
User
The simplest configuration for the service account is to grant the user Admin rights on the Organization as follows. See http://docs.sovlabs.com/latest/vmware-vra7x-plugin/modules/configuration-mgmt/ansible-tower/prerequisites/ for more Advanced scenarios if you do not wish to grant Organization Admin rights.
Credentials
You will need a minimum of 2 credentials.
- Job Templates need a credential of CREDENTIAL TYPE: Machine.
- This must have an ORGANIZATION that is the same as the one used in INVENTORY.
- For Linux endpoints, these are the credentials used for the SSH connection to run the playbooks.
- Projects needs a credential of CREDENTIAL TYPE: Source Control.
- This can have ANY ORGANIZATION.
- These are the credentials required to checkout your playbooks from your git repo.
Project
The project is the collection of playbooks, these will mostly likely be maintained in git, so you can configure your project to automatically checkout the latest playbooks on launch as follows.
Inventory
Inventory Types: Static vs Dynamic
Static Inventory (preferred)
Static inventories only require API access to the Ansible Tower instance and so are preferred in restricted Ansible Tower deployments. From a SovLabs Ansible Tower module perspective, the node is added to the static inventory during provisioning and then it's removed from the static inventory during deprovisioning. This is preferred for most use cases. The user role can be granted sufficient permissions via the built-in Ansible Tower Role Based Access Control.
Dynamic Inventory (check with support before implementing)
Dynamic inventories are designed to be used in a "brownfield" scenario where you want to import the managed VMs in vRA into Ansible Tower. In this scenario, the inventory is populated by querying vRA for managed nodes and adding them to the inventory automatically instead of the add/remove method of the Static inventory type. Most use cases are better suited to the Static Inventory model. If you do want to control your inventory using the Dynamic type, it does require both API and SSH/SCP access to the Ansible Tower host. The requirement for SSH access to a root shell means that they’re often incompatible with docker based deployments and security policy for some organizations.
For further details on the pre-requisites for Dynamic Inventories see: http://docs.sovlabs.com/latest/vmware-vra7x-plugin/modules/configuration-mgmt/ansible-tower/prerequisites/
Static Inventory Example
Job Template
The most important thing to note on this page is to enable Prompt on Launch for the Limit. This ensures that when playbooks are executed from SovLabs that SovLabs is able to execute the playbooks exclusively on the machine being provisioned and not against all machines in the inventory.
0 Comments