Ian Wright
Systems Engineer
Update: On 12/7/23 Red Hat and IBM announced that the Ansible Automation Platform is generally available on IBM Power and IBM Z and IBM LinuxONE.
There are many benefits for using Ansible Automation Platform with the IBM zSystems platforms. The biggest benefit from the perspective of the overall Data Center is getting away from silos of automation while taking advantage of automation that’s already there – For example, Ansible playbooks can submit tasks containing IBM System z automation directly to the mainframe without having to go through JCL.
Tech Preview
In May, at Red Hat Summit, Ansible Automation Platform 2.4 was announced. Part of this announcement was a tech preview of Ansible Automation Platform (AAP) running on RHEL for Z (and on IBM Power Systems, as well). You could run the entire AAP environment on IBM Z including the Controller/GUI if you desired. It would be a great way to demonstrate the value of AAP to your business. However, just don’t run it in production now as something in tech preview isn’t intended for production work. Soon it will be a highly reliable and scalable place to host the majority of the platform.
But, if you are currently running AAP and you have a lab environment available, it could be useful to try something else by setting up a simple automation mesh with the mainframe. You can have the Linux on Z-based Execution Node connecting to its managed nodes via HiperSockets and it will perform beautifully.
What’s an Automation Mesh?
Automation Mesh is a feature of Ansible Automation Platform that allows you to break up where your templates and workflows are running. Instead of having everything running on the Tower Node (in the old days, since the architecture in 2.x the Control node is at the center), you can create nodes that are of different types.
If you already have a controller up and running, I’m suggesting that you set up a Red Hat Enterprise Linux virtual machine on the mainframe and run Ansible Templates and Workflows there.
Ok, but why?
Well, lots of reasons. The Mainframe is really good at efficiently running Linux VMs (really efficient at running most kinds of workloads, but I digress). So, depending on how your environment is structured and how heavily it’s being utilized, you could put many Execution Nodes in a single 19” rack. If you have multiple sites with IBM Z or LinuxOne, you could do the same in other sites.
But there’s also the great networking capabilities that are built into the Z platform. The concept of HiperSockets would allow all of the TCP/IP networking needed to connect from Execution Nodes to Managed nodes to occur inside of the Z. So, the Execution Node is inside the Z and it’s connecting to the managed nodes/LPARs across internal networking with the Z, increasing efficiency and removing extra networking costs.
How to Set-Up Execution Node on IBM Z
In trying this out, I have found that there are some gotchas involved with set up.
To help you avoid the gotchas, I offer these steps:
1. Get things set up on the Z
Initially, we’re not going to need to do anything with the existing controller. The only thing that we need to address is the Mainframe. So, you’ll need to install RHEL 8 or RHEL 9 in a VM on the Z. For my environment I decided to go “bleeding edge” and installed 9.2. Make sure that you have the correct repos set up (including Ansible Automation Platform 2.4). Then download the tarball. You can find the code here.
We run from this side because if you tried to run setup from the controller it’s only going to have the x86 version of AAP and you’ll error out when it tries to work with the Execution Node that you’re creating on the IBM z.
2. Edit Inventory File
When you have the tarball downloaded to your VM and extracted (tar xvf ansible-automation-platform-setup-bundle…) then you can edit your inventory file just like you would have done otherwise.
You can see in the image that I’ve listed my controller (ansible.bpic.mainline.com) and have peers=execution_nodes under the vars for the controller. Then the Execution Nodes are listed under the [execution_nodes] section.
3. Set Up Ansible / Run sudo
When you’ve finished making any changes to your inventory to fit your environment (database, vars for passwords, postgres, and ssl), then just run sudo ./setup.sh as you normally would to set up Ansible.
At this point you’ll be able to see the Execution Node in your topology:
What does this mean? Well, it means that it’s trying to run the job on s390x when it’s looking for x86.
4. Update Control Node Inventory File
At this point you need to update your inventory file on the control node to work with the execution nodes.
Then you need to run sudo ./setup.sh again. This time from the control node. This will correct things so that you’re able to sync up your projects, but there’s also a bit more work to do.
6. Execution Environments and Ansible-Builder
The problem that you could encounter at this point is that the default Execution Environments that come with Ansible are all going to be x86 architecture. You need to make sure that when you execute your Templates and Workflows that your Execution Environments are using the correct architecture.
You can download those from catalog.redhat.com and there are specific images from s390x. Then you’ll want to filter on both Image Type: “Automation Execution Environment” and architecture: S390x.
If you need to customize this, you can set up your own Execution Environments using one of these as a base image. For example, you could have an Execution Environment already baked in with all the relevant s390x collections and possible other, non-IBM System Z collections. (In my lab I made an execution environment for the Z Execution Environment to manage a Palo Alto Networks firewall, just for fun.)
7. Setting up Instance Groups
Instance Groups allow us to control where the Execution Environments will run the Templates and Workflows.
Each of your Hybrid and Execution nodes is going to be an instance. But since we have different architectures requiring different Execution Environments, it’s important to make sure that we have things associated correctly and don’t just have everything grouped together in the default instance group with no control.
You have no choice other than to have default contain instances. So, you need to make sure that you’re aware of this. If you try to disable the mainframe in the default instance group, it’s going to disable the mainframe in all groups.
I handled this by creating a separate instance group called “z” and a separate organization called ”z”. The instance group has only the mainframe Execution Node in it and the organization has only the z instance group in it. Any template that uses that group will always run on the correct Execution Environment. For my other, pre-existing, projects I needed to specify the instance that I’m using.
Summary
Implementing Ansible Automation Platform on IBM Z allows your business to broaden the use of automation, experience exceptional performance, and benefit from Ansible skill sets that may already be in house. I hope you and your mainframe team will be able to take advantage of this in a lab environment and I look forward to hearing how things perform!
More Information
As an IBM Platinum Business Partner and a Red Hat Premier Business Partner, Mainline has extensive experience helping customers with IBM Enterprise Servers, as well as across the three pillars of Red Hat’s business: hybrid cloud infrastructure; cloud-native application development; and IT automation and management. To set up an in-depth discussion about how to get started using these open source technologies, please contact your Mainline Account Executive directly or contact us here.
You may be interested in:
VIDEO: Red Hat Ansible Automation Platform 2.x (10:13)
BLOG: Red Hat Ansible LightSpeed: AI Capabilities that Propel IT Automation