The Zen of Ansible

[This blog post is based on my presentation at AnsibleFest 2022 in Chicago and virtually.]

Recently, a suggestion was made to adopt Tim Peters’ “The Zen of Python” as an overall guiding principle for designing good automation content. That gave me pause because it didn’t seem like the right thing to me. While there is definitely some very good advice to “The Zen of Python” that can be applied to Ansible content, adopting it in its entirety would not provide the best user experience that Ansible is capable of and known for. Its presence as a guiding principle for content design gives the wrong impression and re-enforces a mindset we don't want to recommend.

This got me thinking, what is “the zen” of Ansible?

I considered the spirit of “The Zen of Python” and then I returned to the Ansible best practices talk that I first co-presented back in 2016 at Red Hat Summit and later touched upon here in this blog. In that talk, I said that Ansible was designed with a philosophy of sorts from the very beginning.

“The Ansible way” is to provide an automation tool that is simple, powerful and agentless. Ansible enables users with Continue reading

What’s New and What’s Changed in the Ansible Content Collection for Kubernetes

Increasing business demands are driving the need for increased automation to support rapid, yet stable, and reliable deployments of applications and supporting infrastructure. Kubernetes and cloud-native technologies are no different. That is why we recently released kubernetes.core 1.1, our first Certified Content Collection for deploying and managing Kubernetes applications and services.

Prior to the release of kubernetes.core 1.1, its contents were released as community.kubernetes. With this content becoming Red Hat supported and certified, a name change was in order. We are in the process of making that transition, starting with this release.

In this blog post, we will go over what else has changed and what’s new in this Content Collection as it transitions and enhances it from its community roots.

Focus on The Future

In looking to create a stable and supported release from the upstream sources that Red Hat is known for, the first thing we did was look at what was in community.kubernetes and elsewhere to organize it for the future. This not only led to the aforementioned name change: the content and underlying code was reorganized to be more maintainable and ready to serve as the Continue reading

Ops by Pull Request: An Ansible GitOps Story

In a previous blog post I introduced Automation Webhooks and their uses with Infrastructure-as-Code (IaC) workflows and Red Hat Ansible Automation Platform. In this blog post, I’ll cover how those features can be applied to creating GitOps pipelines, a particular workflow gaining popularity in the cloud-native space, using Ansible and the unique benefits utilizing Ansible provides.

What is GitOps?

Like so many terms that evolve and emerge from the insights and practices of what came before it, finding a definitive meaning to the term “GitOps” is a bit elusive.

GitOps is a workflow whose conceptual roots started with Martin Fowler’s comprehensive Continuous Integration overview in 2006 and descends from Site Reliability Engineering (SRE), DevOps culture and Infrastructure as Code (IaC) patterns. What makes it unique is that GitOps is a prescriptive style of Infrastructure as Code based on the experience and wisdom of what works in deploying and managing large, sophisticated, distributed and cloud-native systems. So you can implement git-centric workflows where you treat infrastructure like it is code, but it doesn’t mean it’s GitOps.

The term GitOps was coined by Alexis Richardson, CEO and Founder of Weaveworks, so a lot of how I’m going to define Continue reading

Intro to Automation Webhooks for Red Hat Ansible Automation Platform

If your organization has adopted DevOps culture, you're probably practicing some form of Infrastructures-as-Code (IaC) to manage and provision servers, storage, applications and networking using human-readable, and machine-consumable definitions and automation tools such as Ansible. It's also likely that Git is an essential in your DevOps toolchain, not only for the development of applications and services, but also in managing your infrastructure definitions.

With the release of Red Hat Ansible Tower v3.6, part of the Red Hat Ansible Automation Platform, we introduced Automation Webhooks that helps enable easier and more intuitive Git-centric workflows natively.

In this post we'll explore how you can make use of Automation Webhooks, but first let's look at IaC for some context and how this feature can be used to your organization's benefit.

Understanding Infrastructures-as-Code

Infrastructure-as-Code (IaC) is managing and provisioning computing resources through human-readable machine-consumable definition files, rather than physical hardware configuration or interactive configuration tools. It is considered one of the essential practices of DevOps along with continuous integration (CI), continuous delivery (CD), observability and others in order to automate development and operations processes and create a faster release cycle with higher quality. Treating infrastructure like it is code and subjecting Continue reading

OpenShift Ansible Broker: Available Now

Our Red Hat colleagues over on the OpenShift Container Platform team have announced the general availability of OpenShift Ansible Broker, which is a new way to easily orchestrate things external to an OpenShift-deployed containerized application by using Ansible automation. But just what is the OpenShift Ansible Broker, and how does it fit into the wider Ansible ecosystem?

At the simplest level, the Red Hat OpenShift team has given users a way to expose Ansible workloads in the OpenShift Container Platform Service Catalog via the Open Service Broker API.

If you haven’t already, we’d recommend you read What’s new in OpenShift 3.7 as this has a good explanation of the concepts and motivation behind the work.

This is a fantastic development that places Ansible in a prime position within the OpenShift Container Platform Service Broker and great news for the continued journey for Ansible as Red Hat’s language of automation. It extends the current capabilities of Red Hat OpenShift Container Platform with Ansible’s simple, powerful, and agentless capability, making the journey to hybrid cloud easier. There are some best practices about how you can use this new capability to achieve maximum benefit, and we’d like to discuss that here.

Ansible Best Practices: The Essentials

The Ansible Way

When I talk about how to develop automation solutions with Ansible, I begin by highlighting the philosophy behind its design. All Ansible best practices relate back to this thinking in one way or another.

Complexity kills

That’s not just a marketing slogan. We really mean it and believe it. We strive to reduce complexity in how we’ve designed Ansible tools and encourage you to do the same. Strive for simplification in what you automate.

Optimize your Ansible content for readability

If done properly, it can be the documentation of your workflow automation.

Think declaratively

Ansible is a desired state engine by design. If you’re trying to “write code” in your plays and roles, you’re setting yourself up for failure. Our YAML-based playbooks were never meant to be for programming.

Ansible is like the Swiss Army Knife of DevOps

Ansible is capable of handling many powerful automation tasks with the flexibility to adapt to many environments and workflows. Not all approaches are created equal though. Don’t let yours undermine the simplicity and power of Ansible.

Enough philosophy though. Let’s get down to brass tacks. Here I’ll cover some of the most important and impactful best Continue reading