Ansible

With Ansible you can automate the deployment and configuration of almost any part of your technology estate. The challenge with Ansible is that it is difficult to get visibility across teams and align configuration jobs with other release activities.

In Cutover, you can start an Ansible playbook as part of your release without direct access to Ansible Tower.

Which version of Ansible are you automating ?

A key factor to consider when invoking an Ansible automation is the mechanism required across the variants of the tool. Each requires a different integration method from Command Line to Managed Service.

Fig.1 - Ansible Variants - From Command Line to Managed Service

This means that an Integration to the UI driven RedHat Ansible or AWX (self hosted/managed service) can be achieved using a Cutover ‘Generic Webhook’ with a patterned configuration implementation.

Should an integration be required to Ansible - The tool or pure command line execution of Ansible commands or perhaps the execution of scripts to invoke build automations, a deeper integration is required and usually requires a middleware wrapper and development work between Cutover Connect and the target Endpoint. This method is classed as a Custom Integration with an increase in the time and cost of delivery.

What does an Integration Task look like in the Cutover UI?

There is a specific “Task Type” associated with starting an Ansible Playbook. This is identified in Cutover by the Ansible Icon associated with the task.

The Playbook URL and other defined parameters can be viewed in the tasks detail panel. When the runbook task is started, the status of the Ansible Playbook is updated in real-time from within the Cutover UI, meaning that the Runbook User can be kept informed of progress without having to access Ansible Tower.

What information is needed to setup a Generic Webhook?

This use-case could be as simple as implementing an Ansible Task Type out of the box which only needs the API endpoint / Playbook URL sent to an Ansible endpoint as in Fig.1 below. This typically supports AWX and Tower in the Cloud, having Public internet access and a prescribed and available authentication method for access and playbooks enabled.

Fig.2 - Ansible “Out of the Box” Tier 1 Connector - Playbook Parameter Only

For a requirement demanding additional Parameters and extended functionality, Cutover can provide a service to deliver a more tightly coupled solution integration which includes the addition of application specific Custom Fields allowing for more Parameters to be passed via the payload as in Fig.3 below.

Fig.3 - Ansible “Customized” Tier 2 Integration with Extended Parameters

Security considerations for on-prem or Cloud VPC deployments

Cutover Connect - Lightweight on-prem proxy & authentication module

For a customized deployment where Ansible Tower is on-prem or securely hosted, Cutover Connect is deployed (Cutover’s on-prem lightweight proxy and Auth module). Cutover Connect is egress only by design, which means that no inbound requests are made to a Client’s network but rather, all Data emanating from the Cutover Core Platform (such as an automation payload) is ‘pulled’ down and forwarded to the endpoint.

Secure transport and AWS Message signing (AWS SQS)

Cutover Clients have their SaaS Instance deployed on an isolated “Client exclusive” VPC. This includes integration specific (and unique) Lambdas, SQS (Queuing) & S3 Bucket infrastructure to support integration functionality. All messages and http headers are signed at the point of processing and delivery to the SQS queue then sent over a TLS 1.2 connection (IP restricted) to the CutoverAWSGlobal Proxy. The message is then pulled down by Cutover Connect after a long polling cycle detects a payload waiting on the Client specific SQS for immediate delivery to the Ansible endpoint.

Ansible Response (Callback & Polling)

Cutover Connect supports two methods to manage responses from Tower back to the Cutover Runbook. When Tower is able to Post a response to an API, a Callback URL is provided (managed by Cutover Connect on the local network) as the destination for all status messages. If Callback is not an option, a Polling method can be implemented by Cutover against a Client defined Endpoint that will respond to a Get request for Status Information.

Response data, for example Integration Status or an Execution ID, will then be surfaced in the Runbook, most commonly in the form of a Visible Tag (Pill) on the Task Itself or in a Custom Response Field allocated for this purpose.

In summary, feedback to the User is obtained by the following Methods:

  • Sync (block and wait or fire and forget)

  • Asynchronous with a callback url

  • Polling the status of a job at a regular frequency

The Cutover UI can update the status message at each point in the cycle and an acknowledgement of the message instantly passed directly in the UI.

Privilege options - Acting as Cutover

In this paradigm Tower is executed as a service user. Using Cutover logs it will be possible to see who set-up and initiated the task that triggered an Ansible playbook to be run.

Privilege options - Acting as an individual

In this paradigm an Auth Token that has been received as part of a SAML claim for an individual user who actioned a task can be placed in the automation message and used as the token against a third Party Auth Service such as Azure.

Fig.4 - Ansible Architecture - Web Sequence Diagram

Ansible Specific FAQs

How can we prevent a large amount of ungoverned Ansible Tasks ?

A Cutover Solutions Engineer will create a New Task type within Cutover associated with an integration to limit this.

Cutover then map to Cutover task types so that the user is not presented with many tasks that they may struggle to use, or may create governance issues if used unexpectedly. It is also advised that playbooks with lots of configuration options are separated into playbooks and makes use of the fact Ansible can reuse artifacts rather than being heavily configuration driven by variables.

As stated above, design a playbook for an app that incorporates two :

  • import_playbook: webservers.yml
  • import_playbook: databases.yml

This method is more effective than a boolean switch on the playbook to say whether it should have a database or not. This also allows your teams to have multiple “component sources” that could be called individually in Cutover, allowing for easier intervention or invoking only a partial automation.

Who can run an Ansible Tower Task?

Cutover can run Ansible playbooks as a service account or an identified Cutover user. Using a Service Account is only recommended for non destructive actions. Destructive actions or provisioning actions should be run as an identified user.

Does this integration run in rehearsal?

This integration does not run in rehearsal by default.