Mainframes, DevOps, and Ansible

Source:-it.toolbox.com

Even while you’re working from home, work has to continue. Organizations have to stay in business, software needs to be updated to suit the new uses that its users would like it to be able to do. And end users like regular updates with new features that make their life easier. And, obviously, the best platform to do any of this on is the mainframe. That rock-solid platform that has, a bit like Dr Who, been transmogrifying itself over the past 50 or more years to meet the needs of its users.

DevOps is a portmanteau word combining software Development with Operations in order to shorten the systems development life-cycle and provide continuous delivery with high software quality. The aim is to develop the software that you need in the next few weeks or months and not in two years’ or more’s time like with old waterfall software development methodologies. DevOps is often associated with Agile ways of working and scrums, where everyone stands rather than sits during brief meetings where decisions are made and tasks allocated.

You probably know all this (and more), but what is Ansible? Ursula K Le Guin first used the word ‘ansible’ in her 1966 novel “Rocannon’s World”. The word was a contraction of ‘answerable’, because the device would allow its users to receive answers to their messages in a reasonable amount of time, even over interstellar distances. Other authors have also used the word. But that’s not what we’re talking about today!

Ansible is an open-source software provisioning, configuration management, and application-deployment tool that runs on Unix-like systems, and can configure both Unix-like systems as well as Microsoft Windows. It has its own declarative language to describe system configuration. Ansible was written by Michael DeHaan and was acquired by Red Hat in 2015. Ansible is agentless, temporarily connecting remotely via SSH or Windows Remote Management (allowing remote PowerShell execution) to do its tasks.

The exciting news is that it’s now available on mainframes as IBM z/OS Ansible, and it enables users to automate z/OS applications and IT infrastructure. It will also enable users to automate development and operations through unified workflow orchestration across platforms. And that makes it a DevOps tool. It can work with existing JCL, REXX, and z/OSMF assets.

Ansible uses modules, which are mostly standalone and can be written in scripting languages such as Python, Perl, Ruby, Bash, etc. If you read further, you’ll find the word ‘idempotency’ being used. This is from maths (and programming) and means that even if an operation is repeated multiple times (for example when recovering from an outage), it will always place the system into the same state.

It also uses the idea of inventory configuration. Inventory is a description of the nodes that can be accessed by Ansible. By default, the Inventory is described by a configuration file, in INI or YAML format. The configuration file lists either the IP address or hostname of each node that is accessible by Ansible. In addition, nodes can be assigned to groups.

Playbooks are YAML files that express configurations, deployment, and orchestration in Ansible. They allow Ansible to perform operations on managed nodes. Each Playbook maps a group of hosts to a set of roles. Each role is represented by calls to Ansible tasks.

Ansible Tower is a REST API, Web service, and Web-based console designed to make Ansible more usable for IT teams with members of different technical proficiencies and skill sets. It is a hub for automation tasks. Tower is a commercial product supported by Red Hat, Inc. but derived from AWX (an open source community project)

The Red Hat Ansible Certified Content for IBM Z helps users to connect IBM Z to their wider enterprise (ie hybrid IT environment) automation strategy through the Red Hat Ansible Automation Platform ecosystem. IBM Z Ansible content helps enable development and operations automation through unified workflow orchestration with configuration management, provisioning, and application deployment in a single platform.

The Red Hat Ansible Certified Content for IBM Z provides automation building blocks that can accelerate the automation of z/OS and z/OS-based software. The initial core collections include connection plugins, action plugins, modules, and a sample playbook to automate common tasks on z/OS such as:

zos_data_set: Create, delete, and manage attributes for data sets
zos_job_query: Query z/OS for a list of jobs
zos_job_submit: Submit a job and optionally monitor for its completion
zos_job_output: Capture the job output for a submitted job
In the future, there are plans to expand this to include Content Collections automating common configuration and management tasks for IMS and CICS.

The Certified Content will be available in Automation Hub, with an upstream open source version offered on Ansible Galaxy. This means that no matter what mix of infrastructure users are working with, Ansible will help them to manage it across their hybrid environment through a single control panel. By the way: Ansible Galaxy refers to the Galaxy website where users can share roles, and use a command line tool for installing, creating, and managing roles.

Barry Baker, IBM Z and LinuxONE offering management vice president, said about the product: “For developers and operations, Ansible allows them to break down traditional internal and historical technology silos to centralize automation — all the while leveraging the performance, scale, control, and security provided by IBM Z. This brings the best of both worlds together with a practical and more economical solution.”

What can we conclude? In a hybrid world, where organizations are making use of the opportunities provided by cloud computing as well as widespread distributed systems, it seems sensible to use the most secure and stable platform – the mainframe – as the place from which to manage these hybrid environments using a single control panel. It seems to be part of a trend to allow distributed systems management tools to run on the mainframe. We recently saw support for Red Hat OpenShift on the mainframe. And IBM supports mainframe DevOps integrations with Git and Jenkins through Z Open Development. This all seems to be part of IBM’s plan to make the mainframe available to people with open source experience rather than just those who have learned the dark arts that surround mainframes.