Controlling Container-Native Applications With Ansible Playbooks

Written by: Derek Winchester

Some time back, developers were facing a tough time controlling container-native applications. This was so because each container consisted of numerous features and services, where each unit had its unique network policies and security constraints.

So basically, cloud-native applications are quite the challenge when it comes to Day 2 of developer operations.

The Solution

Sure, patches, provisioning and upgrades can be controlled with Helm Charts and Ansible playbooks. However, deeper analyses like storage and application life cycles were still only possible to determine with application support and oftentimes, developer team intervention.

Shortly after, Red Hat’s Operator Framework initiative established the Operator-SDK framework. This move helped standardize Kubernetes Operator development and therefore, made it easier for developers using Kubernetes to establish Operators and also gain control of the lifecycle for container-native applications.

The Advantage of Kubernetes Operators

When Kubernetes Operators became a reality, developers could only design an Operator if they knew Golang, which is ironic, because most engineers at the time were new to this programming language. This is why, instead of choosing Golang, they settle for Helm Charts and Ansible Playbooks to update and deploy native applications.

Among the biggest benefits of Kubernetes or Ansible Operators is that their objects (secrets, stateful sets, deployments, etc.) can easily be added to the Operator with the help of Ansible playbooks and roles. Go ahead and read more about the K8 Ansible Module.

Couldn’t Find What You Were Looking For?

Were you, instead, planning to learn about Automation basics: ServiceNow and Ansible Tower Integration? Visit my YouTube channel for answers and answers to numerous other questions you may have along the way.