Ansible Automation Controller streamlines IT tasks through automation. A key component of this power lies in workflows. These workflows allow you to orchestrate a sequence of disparate job templates, essentially chaining them together for intricate deployments. Workflows even boast approval nodes, enabling users to pause the process and grant permission before continuing. But what if your scenario demands more nuanced control over these approvals?
While approval nodes are undeniably helpful, they fall short when it comes to multi-level functionality. You can assign approval roles to multiple users or teams, but here’s the catch: everyone with access can approve any request. This becomes problematic when your deployment process necessitates a sequential approval process with designated teams handling specific stages.
Imagine a scenario where a deployment requires a development team’s approval for initial testing, followed by an operations team’s sign-off for finalization.
The built-in approval nodes wouldn’t differentiate who approves which step, potentially causing delays or confusion. For example, I have added both Team-A
and Team-B
as approvers. But you can see both team members (john
and lina
) can approve any nodes in the workflow.
For robust multi-level approvals, the best practice is to leverage your existing IT Service Management (ITSM) system. Popular ITSM solutions like ServiceNow or BMC Remedy often have built-in approval workflows. These workflows integrate seamlessly with Ansible Automation Controller through plugins or APIs. This approach offers several advantages:
If integrating with an ITSM isn’t an option, here’s a workaround within the Automation Controller (remember, this is not an official recommendation):
Design two independent workflows, each containing only an approval node.
Step 1: Assign Team-A
as approvers for the first workflow.
Step 2: Assign Team-B
as approvers for the second workflow.
Insert these “Approval-only” workflows sequentially within your main workflow. This establishes a multi-step approval process. You can select the Node Type as “Workflow Job Template” when you add the node for this.
Team-A
only sees the approval for their designated step, and Team-B
only sees theirs. Approvals progress sequentially, guaranteeing the correct teams authorize each stage.
Imagine a main workflow with four nodes and combine the sub -workflows for the approvals.
Team-A
)Team-B
)By inserting the “Approval-only” workflows (WF 101-TeamA-Approve
and WF 102-TeamB-Approve
) between Nodes 1 and 4, you create a sequential approval process.
The beauty of this workaround lies in its isolation.
Team-A
only receives notifications and has approval rights for the “WF 101-TeamA-Approve” node. Team-B
solely interacts with the “WF 102-TeamB-Approve” node.Ansible Automation Controller excels at automation, and its built-in approval nodes offer basic workflow control. However, for true multi-level approvals, leveraging your existing ITSM system is the gold standard. This approach provides superior control, and auditability, and streamlines your change management process.
We welcome your feedback in the comments below! Have you encountered similar multi-level approval challenges? How did you approach them?
Disclaimer:
The views expressed and the content shared in all published articles on this website are solely those of the respective authors, and they do not necessarily reflect the views of the author’s employer or the techbeatly platform. We strive to ensure the accuracy and validity of the content published on our website. However, we cannot guarantee the absolute correctness or completeness of the information provided. It is the responsibility of the readers and users of this website to verify the accuracy and appropriateness of any information or opinions expressed within the articles. If you come across any content that you believe to be incorrect or invalid, please contact us immediately so that we can address the issue promptly.
Gineesh Madapparambath
Gineesh Madapparambath is the founder of techbeatly and he is the co-author of The Kubernetes Bible, Second Edition. and the author of 𝗔𝗻𝘀𝗶𝗯𝗹𝗲 𝗳𝗼𝗿 𝗥𝗲𝗮𝗹-𝗟𝗶𝗳𝗲 𝗔𝘂𝘁𝗼𝗺𝗮𝘁𝗶𝗼𝗻.
He has worked as a Systems Engineer, Automation Specialist, and content author. His primary focus is on Ansible Automation, Containerisation (OpenShift & Kubernetes), and Infrastructure as Code (Terraform).
(aka Gini Gangadharan - iamgini.com)
This site uses Akismet to reduce spam. Learn how your comment data is processed.
Leave a Reply