Certified Operator Build Guide
Search…
Helm Operators
Ansible Operators
Golang Operator Gotcha's
OpenShift Deployment
Troubleshooting and Resources
Building an Ansible Operator
Ansible Operators use Ansible playbooks or roles as the core logic of the operator.
For more information on how to build an Ansible operator: Guide to building a Ansible Based Operator using Operator SDK.
Why Use Ansible in an Operator?
Ansible is useful for DevOps and infrastructure teams who are already familiar with the language. It also uses a similar pattern as Kubernetes in that playbooks/roles are written in declarative YAML. Jinja2 templating in Ansible is also easy to use, and is nearly identical in syntax to the templating engine used in Helm. This means that Helm templates can easily be converted or migrated into Ansible tasks, with only minor editing required.
Ansible adds the ability to perform operations in order (think multiservice deployments), without relying solely on the Kubernetes concept of Init Containers, or Helm chart dependencies. Ansible is also capable of full Day 2 management of Kubernetes Applications, and can be used to configure things off-cluster, if necessary. As you may recall from the Introduction, Ansible covers the entire Operator Maturity Model.
Ansible Operator at a Glance
An Ansible Operator is a Golang operator that uses Ansible for the reconciliation logic. This logic (contained in roles or playbooks) gets mapped to a particular Custom Resource by a watches.yaml file inside the operator image. The operator go code checks watches.yaml to see which playbook or roles to execute, and then launches the playbook/role using Ansible Runner. This is illustrated and contrasted with golang operators in the following diagram (key points are in orange):
The Ansible Operator's point of user interaction is through a Kubernetes Custom Resource. A user creates a Custom Resource yaml (or json) file and passes this to Operator using the command line
oc (OpenShift) or kubectl (upstream K8s) commands, or the web console (Operator Lifecycle Manager). The variables defined in the Custom Resource object get passed to Ansible Runner as --extra-vars, and Ansible Runner invokes the playbook or role containing your customized logic using these variables. The playbook/role execution loop occurs repeatedly at a certain interval, and is called the reconciliation loop in operator terminology
The next section outlines the basic steps for updating an Ansible Operator with certification changes. For more information on how to create an Ansible Role from a Helm Chart you can visit:
​
Copy link