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. However, it is difficult to get visibility across teams and align configuration jobs with other release activities using Ansible alone.
In the Cutover Runbook, any authorized user can schedule and start an Ansible Playbook as part of their release process without having direct access to Ansible Tower (AWX).
They do this by creating a specific Ansible Task Type (identifiable by the Ansible icon) which, through the integration, allows the passing of parameters associated with executing that Ansible Playbook. Users can also input and view the Ansible Playbook URL and other user-defined parameters in a Task Detail panel that opens when the Task Type is selected.
When an Ansible runbook task is started, the parameters are forwarded to the Ansible endpoint, executing the playbook, and the user can see the status of the Ansible Playbook in real-time in Cutover. Runbook users can therefore be kept informed of job progress without having to access Ansible Tower.
Want to find more information about our Ansible integration? Fill out the form below to speak to one of our team.
Ansible integration FAQs
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.
How can we prevent a large amount of ungoverned Ansible Tasks?
An API endpoint-specific Task Type is created and customized to be used only in line with agreed authentication and authorization policies. There are two 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.
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.
Runbook access locking: for repeatable executions of the same runbook, tasks can be locked so that paramaters are set, eliminating user risk. For runbook and task-type setup, as well as for more dynamic editing of automations, only authorized users will be able to edit the Task Type. In addition, Task Types can be limited to specific accounts and the Runbooks contained within, which results in more control over the limited amount of Task Types a user can implement as well as addressing governance issues for unexpected use.
Indelible audit trail: having audited logs attached to every action taken with the Cutover platform ensures compliance can be implemented.
Share this post:
You're in the Cloud. Now what?
Solving migration challenges with automation, governance, and controls
Operational resilience /
Can surgical scrutiny save us from Fastly outages?