On March 15, IBM announced the IBM z/OS Container Platform, including “Podman” (see: Podman ). As “Podman” is running on z/OS UNIX, it is also possible to automate containers using IBM Z System Automation. In this blog, we will give a short overview regarding “Podman”, create our first test container, and then automate it with IBM Z System Automation.

What is Podman and how it relates to IBM Z System Automation?

IBM z/OS Container Platform allows you to run containerized z/OS UNIX applications. Developers can build applications and consume resources in a self-service model, while in a secure and isolated environment on z/OS. It includes z/OS implementations of the industry-standard tools you need to build, run, and manage container images.

With IBM z/OS Container Platform you can now run containerized applications directly on z/OS. Podman is one element out of the IBM z/OS Container Platform and is the open-source tool used to build, manage, and run z/OS containers. 

It is now possible, with the current version of IBM Z System Automation and the addition of some scripts, to start and stop podman containers and monitor them, and further to supervise general podman activities.

Why should you automate Podman containers using IBM Z System Automation?

The IBM z/OS Container Platform offers new possibilities for in-house software development, as well as integrating third-party applications on the mainframe platform in a secure way. As these new applications get integrated on an enterprise level, dependencies between USS, MVS and containerized applications is expected to grow.

Today’s IBM Z System Automation allows to manage also containerized resources along with USS and MVS applications seeminglessly and on one unified platform. IBM Z System Automation can automate the messages from Podman or containers, start them in sequences as defined in the policy, and ensure high-availability of Podman containers across multiple LPARs and even on a GDPS scale.

How does IBM Z System Automation manage podman containers?

The foundation to ensure high-availability of podman containers is the capability to create on-demand containers and to monitor their processing in detail. At the current state, in order to handle containers by IBM Z System Automation, a collection of scripts are required.

Depending on the needs and the grade of automation, scripts for preparing the containers are required. As the scripts can create containers based on the images, it is possible to create containers dynamically during runtime. Using pre-defined configuration files, also more advanced containers can be created.

The monitoring of the containers can be achieved in different ways. By activating Podman’s event monitoring, and routing these messages to the NetLog, IBM Z System Automation can track the progress in real-time. With some monitoring routines involving podman inspect functionality, IBM Z System Automation is able to verify actively the state of a container. Additionally, passing information from the StandardOut and -Error of the containers to NetLog allows IBM Z System Automation to track further events occuring in the container itself and react accordingly, by raising WTOs or restarting further ressources.

Short Example

To showcase Podman container automation, we prepared in our test environment a simple scenario.

As a starting point we needed an image with the desired application. We decided to create an own image containing a Java application. The name of the image is idemoapp (“Image Demo Application”). But it could also be an image pulled from a registry.

First we introduce a general APL to monitor podman activities. In our case, we called the resource also PODMAN:

 

After starting the APL PODMAN we now start receiving messages in our NetLog as BPXM023I messages followed by internally defined Message ID. The Message ID MYPMON00I is used to mark the start of the monitoring process. Also in our USS system we can find the background process of podman events. The APL PODMAN is not specific for a special container and will notify IBM Z System Automation about general podman activities.

Once our general monitoring is active, we can start preparing the environment to start our actual resource. We create for our ressource an own pod and also prepare the container — the pod is called PODDEMO and so we also call the APL responsible for the environment. The container DEMOAPP is created, based on our image idemoapp, and assigned to PODDEMO.

We see the notifications from the APL PODMAN issueing MYPMON10I to notify about the new pod and some further notifications with MYPMON90I for additional information.

The environment is now set up, and now we start the actual container, which is also represented in IBM Z System Automation by the same name.

MYPMON20I and MYPMON21I inform IBM Z System Automation about the state of the container. Also these are defined in the policy to indicate that the container is now up and running.

In a similar way it would be possible to define the container as a dynamic ressource. At the moment it is not possible to generate dynamically the pods and then start the containers inside of the corresponding pod. Instead a static APL needs to be used and in the according script defined, so that the dynamic ressources can start.