Ansible and OpenShift: Connecting for Success

I have been involved with the Ansible project since its earliest days as a contributor, then later as a customer and consultant, and now as product manager. So I have been around Ansible automation for a quite awhile and have seen it from many perspectives. In my role as an Ansible product manager and evangelist, I have been fortunate enough to meet many IT professionals around the globe and discuss how automation and DevOps culture can be applied to their organizations. Sometimes I am asked what they should automate. Other times, I am challenged that an automation tool like Ansible is unnecessary or does not apply to what they are doing. 

No matter if we were talking about RHEL, Windows, networking infrastructure, security, or cloud services, my response has essentially been the same over the years. I have repeated it so often, sometimes out of frustration, during debates, with conviction, and even jokingly, that I have formulated the point into my own theorem on Automation:

"Every shell command and UI interaction is an opportunity to automate."

-- Appnel's Theorem on Automation

Cloud-native systems are no different. The extent of the automation, where the value lies in that automation and the details of where automation is best applied, varies. But I assert my theorem still applies. 

For the rest of this post, I will cover why Ansible fits into a Kubernetes environment and how you can apply it to your cloud-native systems. To explore these topics and more, I invite you to join the Ansible community at AnsibleFest, our user conference that we will  be hosting virtually October 13 and 14. You can register for free here.

Ansible Fits Naturally Into a Kubernetes Environment

There are many similarities to how Kubernetes and Ansible approach their individual problem domains that make a natural fit when we bring the two together. They are both highly active and widely used open source projects and have vibrant communities working to solve common problems. They make hard things easier through automation and orchestration. They also both work as desired state engines and make extensive use of YAML.

As we can see in these two examples, both use similar patterns and YAML to describe the desired state of the world: 

apiVersion: v1
kind: ConfigMap
metadata:
  name: foo
  namespace: default
data:
  color: red

- name: create foo configmap
  k8s:
    definition:
      apiVersion: v1
      kind: ConfigMap
      metadata:
        name: foo
        namespace: default
      data:
        color: “{{ color }}”

On the left, you have a Kubernetes ConfigMap object definition expressed in YAML that you could feed into your cluster using kubectl. On the right is a single Ansible task doing the same thing. If you compare the YAML on the left to what is in red on the right, they are almost identical. What is different is a small, but significant thing I left in: a template parameter (color) here using Ansible’s built-in Jinja2 template functionality that can leverage Ansible's ability to collect and collate inventory, hosts, and other data and utilize that to modify its execution.

Ansible provides the flexibility to maintain the entire definition as a separate Jinja2 template file like in this example:

---
- name: create foo configmap
  k8s:
    definition: "{{ lookup('template', 'foo.yml') | from_yaml }}"

Soon, in an upcoming release of the K8s module, this will become even easier and more elegant:

---
- name: create foo configmap
  k8s:
    template: foo.yml

{% endraw%}

We are working on simplified and more robust ways to interact with Kubernetes and other cloud-native systems, such as Helm and the advanced functions in Red Hat OpenShift.

Now let’s look at ways you can apply the Ansible Automation Platform to cloud-native systems.

Developing Kubernetes Operators With Ansible

You can use Ansible to encode human operational knowledge to automate Kubernetes environments. The Ansible Operator SDK is a collection of building blocks that makes it easier to deploy and manage Kubernetes apps in both a Kubernetes and Ansible-native way. It is a first class citizen of the Operator SDK, now a CNCF incubator project, and one of the available built-in types along with Go and Helm.

Ansible enables full-featured Operators to be developed. Arguably, you are not giving up anything using Ansible, and in some respects, you gain a lot of efficiencies. With Go, you do get that fine-grained control, but there are quite a few advanced and complex concepts involved in doing so. There are also a lot of generic and boilerplate functions every Operator needs to implement and manage in Go that we have embedded into the Ansible Operator SDK. 

The Operator SDK binary handles all of the low-level operator functions and details for you. Using Go is a very powerful way to write Kubernetes operators, but there are quite a few advanced and complex concepts involved in doing so. There is very advanced and powerful caching and queue management that are built into the Go client that are available to use, but it does take quite a bit of knowledge and expertise to get proficient with it. If you do not have that time to build up the expertise or do not want to take that time to work through that right now, you can leverage what comes as part of the Ansible Operator SDK so you can focus on writing your reconciliation logic.

Once deployed, the operator reads in the watches.yaml file and monitors events in the cluster that it defines. When a matching event occurs, the Operator SDK binary runs the associated Ansible automation using input coming from the CRD and the cluster. The Operator SDK binary provides a reverse proxy that takes calls to the K8s API (via the k8s module), is part of the reconciliation logic, and handles caching and embellishing those calls with things like owner references for proper garbage collection as a convenience. Once the Ansible automation has been completed, the Operator SDK binary will take the results of that run and update the status of the custom resource.  

As a developer creating Kubernetes Operator with Ansible, you are only responsible for providing the watches file and the Ansible content that manages the application lifecycle.

So combining Ansible and Kubernetes frees up application engineers to minimize the new skill sets required to maximize time to delivery. 

Author and Red Hat Developer Advocate, Jason Dobies will be presenting “Building Kubernetes Operators using Ansible” at AnsibleFest. Also, author and Ansible extraordinaire, Jeff Geerling, and I will be presenting “Fast vs. Easy: Operators by the Numbers” where we measured the performance of Operators at scale to better understand the tradeoffs between performance and ease. We will be presenting those results and talking about ways both the ease and performance of the Ansible Operator SDK can be improved in future releases. 

“Last Mile” Automation for Kubernetes Cluster Installations

There is a lot more to making Kubernetes useful than just installing it and starting it up. You will still need to perform additional setup and configuration of resources on the cluster and infrastructure off the cluster. You still need to handle things such as networks, firewalls, DNS, certificate management, and authentication (LDAP) just to finish off the setup for your needs. Enterprise Kubernetes offerings like Red Hat’s OpenShift platform have installer systems that help you with some of it, but they will only get you so far in dealing with the individual customizations we all have to do that are so hard for a product to capture out of the box.

I am a big proponent of cloud-native technology and architecture and believe its power has the potential to unlock tremendous business benefits for organizations that put it to work. That said, not all infrastructure can be hosted or replaced by a Kubernetes cluster. Many organizations have made significant and historical investments in IT infrastructure, skills and workflows that are working. So on some level, you will need to integrate and connect with resources and infrastructure not running in your cluster and that are not cloud-native. There’s a lot of potential combination and needs to what this specifically means to you. 

Ansible can be the IT automation “glue” for bringing traditional (off cluster) and cloud-native (on cluster) infrastructure together. It can provide the functionality needed to coordinate and manage these hybrid environments in as simple and effective a way as possible. 

If you are managing a large sophisticated estate of clusters and applications, you will need Red Hat Advanced Cluster Management for Kubernetes. We are working to enhance the power and sophistication of Red Hat Advanced Cluster Management to control clusters and applications from a single console with the flexibility and reach of Red Hat Ansible Automation Platform. To hear more about how Red Hat Advanced Cluster Management and Ansible can work together, come to Jimmy Alvarez and Colin McNaughton’s “Building the Next-Gen Applications for Multi-Cloud environments”. 

Application and Service Deployments

This is a bit similar and somewhat overlapping with last mile automation, but here the focus is on applications and services, rather than the cluster itself.

Here is the scenario: You want to deploy an application to your cluster and you are presented with a “quick start” guide that features a dozen or more kubectl, helm, oc, and sed commands, along with some manual edits to example files to get running. This has happened to me, and it gives me flashbacks to the days of sysadmin run books of the ’90s. 

Ansible can help here. Combining its variables and inventory management, templates, playbooks, roles and many collections, it can assist in creating repeatable and consistent Kubernetes application and service deployments just like traditional infrastructure. Standard procedures and settings can be shared while others can be modified according to the cluster being targeted, all from one central control plane.

Ansible can get you pretty far in a way that is simple and lightweight. Again, if you are managing a large sophisticated estate of clusters and applications, you will need Red Hat Advanced Cluster Management in addition to what Ansible can do. Join the breakout session at AnsibleFest to hear more.

Ansible GitOps for Kubernetes and Beyond

GitOps brings together deployments and operations with development processes and tooling, providing a consistent means of working in your organization. GitOps workflows increase productivity, velocity of deployments, and development by using Git as a single source of truth for declarative infrastructure and application deployments.

There are many tools you can use in your GitOps pipelines; however, Ansible Automation Platform provides unique benefits that make it the ideal solution for GitOps workflows. As I said earlier, Ansible is a desired state engine that enables declarative modeling of traditional IT systems without scripting through Ansible Roles and Playbooks. Ansible enables flexible and powerful capabilities to extend your GitOps workflows beyond Kubernetes to all existing IT infrastructure with one simple language, allowing teams to transition without having to learn new skills. Consistent with the Ansible way, there are no specialized agents to manage system state, giving organizations the freedom to tailor workflows to how they need to work. 

To hear more about GitOps the Ansible Way, come to my AnsibleFest talk “Ops by Pull Request: An Ansible GitOps Story”. 

Connecting for Success

There are many benefits to automating and many tools you could use to automate Kubernetes systems. 

So why use Ansible to automate your operations with Kubernetes systems?

Ansible lets you connect the different technologies that are ultimately needed to be successful in your efforts with Kubernetes, but it does so by complementing the technologies, becoming a multiplier in getting you to success in a simplified, faster way. The same tried and trusted Ansible tooling lets you automate and orchestrate your applications across both new and existing platforms, allowing teams to transition without having to learn new skills. 

With the k8s and Helm modules, an Ansible user can manage applications on Kubernetes on existing IT or across both with one simple language, no programming required and with faster iterations and easier maintenance in getting things done across all existing IT infrastructure.

What I have covered here are some of the most common ways Ansible can help automate the management of Kubernetes deployments, but they are not the only ways. Remember, every shell command and UI interaction is an opportunity to automate, and cloud-native environments are no different.

We hope you will join us at AnsibleFest October 13 and 14 to hear more about how Ansible can connect you for success.