Ansible is a simple yet powerful automation tool, which makes it a very popular open source option. Using Ansible on z/OS, you can extend all the goodies of Ansible to the z/OS platform, including platform-agnostic integrated DevOps.
This code pattern shows you how to use Ansible on z/OS to complete common actions needed to do a simple deploy of a sample CICS-COBOL application.
IBM Z is the home to mission-critical applications and offers a range of services including security, availability, reliability, and scalability. DevOps technologies can be used with IBM Z including continuous integration (CI), continuous deployment (CD), and automated testing. As with any platform, you can integrate enterprise tools like Git, Jenkins, SonarQube, and Artifactory to create a DevOps pipeline for applications that run on z/OS.
Open-source-based Ansible automation is one of the tools in the DevOps toolchain that can simplify a variety of things including application deployments, middleware provisioning, orchestration, and much more. All of this can be accomplished using Ansible playbooks, a simple and easy-to-read script written in YAML that can be version controlled. Ansible employs an agentless architecture that typically consists of an x86 Linux-based control node with a number of managed nodes that span a variety of platforms like Linux/Unix/Windows (LUW) and IBM Z. Ansible runs playbooks on the control node to automate and bring managed nodes to a desired state. With the introduction of Red Hat Certified Ansible Content for IBM Z, you can accelerate your adoption of Ansible for IBM Z to incorporate additional efficiencies into your mainframe DevOps pipelines.
For ease of discussion, consider a simple CICS-COBOL-Db2 application. Typical steps to deploy such a mainframe application include:
- Backup load modules and DBRMs for rollback actions as needed
- Copy updated load modules to application library in CICS DFHRPL DD concatenation
- Bind updated Db2 DBRMs/Packages to Db2 plan
- Do CICS refresh (New Copy) to pick up updated load modules
- In the event of failure, rollback to old load modules and DBRMs
We will perform these actions on z/OS using Ansible.
Note: This code pattern does not cover the following, which needs to be addressed in real environment deployments:
- Ensure that you have a full tracking mechanism for all deployments, so you can understand what you have deployed into which environments. This is usually done with a deployment product such as UrbanCode Deploy.
- The backup process must be named, tracked, and stored to allow for rollback at any time in the future. You should also make sure that you are only backing up the specific files that are changing.
- For deploying multiple packages, associate a package manifest with each package to track and determine what to do with each package and the contents of that package.
- Provide the appropriate package management for both the update packages and the rollback packages.
- This is a sample that demonstrates what is possible; when working with Ansible, there are also alternatives for using Python, as well.
The Ansible playbook flow is as follows:
- Back up the load modules from the target load libraries to the backup load libraries.
- Copy the load modules from the source load libraries to the target load libraries.
- If the application is a Db2 application:
- Back up the DBRMs from the target DBRM libraries to the backup DBRM libraries.
- Copy the DBRMs from the source DBRM libraries to the target DBRM libraries.
- Do a Db2 bind to generate the Db2 plan.
- If the application is a CICS application, do a new copy of the modified programs.
Find the detailed steps for this pattern in the README file. The steps will show you how to:
- Define the Ansible environment configuration.
- Define the variables that can be used in the deployment playbook.
- Create an Ansible playbook to deploy the application.
- Back up and copy the load modules and DBRMs from the source libraries to the backup libraries and target libraries.
- Create a task to back up the load modules.
- Create JCL templates and tasks to copy the load modules to target libraries.
- Use the Ansible template module and Jinja2 templating to generate Db2 BIND JCL.
- Create an Ansible task to generate Db2 BIND JCL, copy the JCL to a z/OS USS path, and execute using the Ansible playbook.
- Do the CICS refresh from an Ansible playbook by executing CEMT transaction in the target CICS region.
- Perform rollback to reverse the changes in target libraries if required.
- Integrate the Ansible playbook into the CI/CD pipeline using Jenkins orchestrator.
Note: The order of execution of the tasks in deployment can be easily modified by updating the deploy_app.yml. For example, if the DB2 BIND needs to happen before CICS load module deployment, just interchange the order of the tasks in the deploy_app.yml file. An immediate rollback will be required if the DB2 BIND step fails.