IBM Destination Z - Group home

Develop With Docker

By Destination Z posted Mon December 23, 2019 03:41 PM


IBM z Systems containers aren’t as complicated as they may sound when you hear of young hotshot developers using them to build and deploy sexy new—often mobile—applications, leveraging a variety of backend systems. “If you want Docker on z Systems, you can do it in next to 30 seconds,” says Dale Hoffman, program director, Linux Software Ecosystem and Innovation Lab, at least if you’re running Linux on z Systems or on a LinuxONE server.

Get Started Easily

Start on your SUSE or Red Hat Enterprise Linux server, build your own container images and populate Docker hub, the public registry or pull and run existing z Systems container images from there. When Ubuntu is fully supported on IBM z early this year, Hoffman expects container activity to ramp up quickly. But you don’t have to wait. “Just build your own private registries on your favorite Linux distribution and you’re ready to roll,” he adds.

To make it even easier and bulletproof, Hoffman recommends using the processes his group has already built for the system. Find the binary for Docker on z Systems and the instructions for building your own private registries. Hoffman’s team is actually making Docker available to any open source product that is ported-validated on IBm z Systems to make it easier for users to hit the ground running. If you’re stumped, try a how-to document for first steps.

Once you have Docker on IBM z you can experience ease of use, simple portability and fast ramp up to develop anywhere. Through containers, Docker basically brings an engine/runtime on top of the OS and provides the virtual containers to deploy software into the container. This produces faster and more efficient portability and deployment for the applications.

Isolation and Portability

Out of concern for security, some users will want to add a small level of complexity. Explains Hoffman: z Systems shops may be worried about going into production on a bare metal image due to security concerns. Instead, he advises putting on a second level guest for added security isolation.

The biggest advantage of using a Docker container on a z/VM second level guest is to get isolation between containers of up to Evaluation Assurance Level (EAL) 4. For example, one can put item A and item B on the same Linux image for Docker as is but each one can see the other. However, if one puts item A on one z/VM guest and item B on another z/VM guest, both remain isolated. For even stricter separation but less flexibility of resource overprovisioning, the PRSM layer allows for isolation capabilities at the first level guest level up to EAL 5. Some mainframe shops start by using Docker on a native LPAR for development, and Docker on second level guests for production. If you’re running a LinuxONE or Linux on z Systems machine, the organization will barely notice the minimal added overhead.

The two main reasons for running containers on Linux on z Systems are portability and increased density. In terms of improved portability wherever there’s a Docker container you can move over your Docker application. Containers are built the same way on all platforms. In terms of density, Docker allows for greater density than conventional VMs since it doesn’t require the presence of a hypervisor, which enables more apps in one system. With Docker, the OS knows the applications loaded into memory by each container and can create synergies from that insight to further increase density and efficiency.

Shape Your Environment

Start using Docker containers with dev-test. When you’re ready to put the new app into production, add second level guests to get the isolation, and build on the hipervisor, which leverages HiperSockets—fast, memory-only TCP/IP connections—as the production environment. Use VM isolation for tenant-by-tenant granularity to get the isolation on a tenant basis. Very quickly you will have a sufficient mass of applications capitalize on z Systems container efficiency.

For mission-critical enterprise work, IBM recommends leveraging high-density bare metal servers in a dev-test environment, as noted above, to rapidly put everything on one LPAR on IBM z and eliminate the provisioning associated with hipervisors. When ready for production, shift back to second level guests for isolation, and live with the small hipervisor overhead. As a result you get isolation on a tenant basis and a sufficient mass of applications to gain from the container efficiency.

The bottom line: on z Systems, you can shape your environment with system virtualization and container elements according to your landscape and requirements. With hardly any constraints on performance you can define IT structures according to your needs. Docker containers on the platform don’t require any special tools, technologies or components. As Hoffman points out: “Docker is Docker is Docker, even on z Systems.”

Alan Radding is a Newton, Massachusetts, based freelance writer specializing in business and technology. Over the years his writing has appeared in a wide range of publications including the New York Times, CFO Magazine, CIO Magazine and Information Week. He can be reached through his website,