Ansible Tower

Ansible Tower is an agentless Open Source automation engine that can be used to automate software provisioning, configuration management, application deployment, and a host of other IT activities. Ansible Tower is a web-based solution that makes Ansible even easier to use for IT teams of all kinds. 

By default Projects in tower do not automatically pull from Git on a schedule. By default SCM updates will only occur on creation, and when manually requested. Schedules must be configured manually, which is covered in the Tower documentation.

If your playbook does not appear in this dropdown:

Usually this is because an SCM update has not been performed, so tower has an outdated version of your git repo. See 'Why don't my changes appear in Tower after being pushed to GitHub?' .

It's also possible that there is a syntax issue with your playbook, as Tower attempts to parse the playbook before displaying it. Verify that your playbook is syntactically correct.

Usually this is caused by a lack of permissions for your service account. Your DevOps service account must have the 'execute' role for your template. You can grant this permission to the account directly, or to a team that it's a member of. Granting this permission is covered in the Tower documentation.

There are 2 common reasons for a job to sit in 'pending' state:

• Blocked awaiting an SCM update. If a project is configured to 'update on launch', then jobs will remain in pending state until the SCM update is completed.
• Blocked by a concurrent job. If a job template is configured without 'enable concurrent execution', executions of the template that share an inventory will block.

SCM updates execute as a distinct job type 'project_update', and can be searched for from the job screen using 'type:project_update' as a parameter.

The simplest way to find the job relevant to your failed job is to view your job, and click the 'view project sync results' link:

Ansible errors can sometimes be cryptic, especially for those unfamiliar with Python. The most common issues are syntactical, so start with the syntax checking FAQ item. For more complex issues, often the simplest route is to rely on the troubleshooting work already done by others. The Ansible GitHub Issues page includes years of troubleshooting discussions, with examples of errors received and their solutions. Often searching for your error there will result in several similar examples, with explanations and solutions.

Github is full of publically available Ansible roles and playbooks, and is a great place to start when looking for relevant examples.

Jeff Geerling has written a good book on Ansible, and he provides all of the code samples for free on github.

For examples of how to use a specific module, the most reliable source is always the official documentation.

There are three modules that can be used to interact with a target and simulate human input. Links to documentation for each, as well as notes on use-cases:

• Command
  • Given command is passed directly into Popen on the target, with no shell . Ex. 'date' is run directly.
  • Shell functions like redirection, variable substitution, etc will not function
  • No profiles (ex. bashrc, .profile) will be loaded
  • Python required on target, command executed as a child process of Ansible's python interpreter.
• Shell
  
  • Not actually a distinct module. Uses 'command' under the covers, but prepends a shell executable to your commands. Ex: 'date' becomes '/bin/sh date' .
  • Shell functions are available
  • Profiles will be loaded based on shell configuration
  • Python required on target, shell executed as a child process of Ansible's python interpreter.
• Raw
  
  • Module is implemented entirely server-side, nothing is done on the target other than execution.
  • Command is passed into Ansible's SSH connection directly, without passing through Python.
  • Profiles and shell configuration can be configured based on the command provided.
  • Can be used to install Python prior to other modules
  • Can be used to workaround Python bugs on unsupported or out-of-date systems (Solaris legacy)

It's generally recommended to work 'down' through these options as dictated by your requirements. Ideally Ansible code should be target agnostic and idempotent, and that gets more difficult with Shell and especially Raw.

All users requesting Ansible Tower access must first have access to ServiceNow.  For instructions on the process, refer to the ServiceNow handout.

All users requesting Ansible Tower access must first have access to Zscaler.  For instructions on the process, refer to the Zscaler handout.

Step 1: If you did not have an Active Directory (AD) account previously, you will have an AD account provisioned for you. After your request has been approved, you will receive an email or phone call from the HIDS Windows team with details on your Active Directory (AD) account and VIP installation instructions.

Step 2: Log into Ansible Tower at  https://tower.hcqis.org/ using your AD credentials.