Developing Containers on zCX

Photo by Guillaume Bolduc on Unsplash

🖥🖥🖥

While z/OS Container Extensions is quite useful for deploying containerized workloads on z/OS, did you know that it is also possible to use it to develop containers and applications? As a function tester for zCX, I used this capability to simplify my efforts. I wanted an environment where I could construct test variations. Since these were going to run on IBM Z, I needed an environment where I could compile them for s390x.

During the initial phase of zCX development, I used a Linux system running under z/VM to accomplish this. While this was acceptable, it meant that I was performing a lot of work on a different system than the one I was actively testing. Since my goal was to flush out as many bugs in zCX as possible, I wanted to replicate my development environment within a zCX container.

My goal for this environment was that I should be able to create new containers inside it, and deploy them for testing. I wanted to stress test the virtualization code in zCX, so I decided that compiling some open-source software packages would be a good way to generate lots of instructions. To do this, I needed to create a container with a build toolchain. I created a Dockerfile, which I’ll discuss in detail below.

I started with a generic Ubuntu base, and then added the latest version of the gcc compiler. I also installed a number of libraries, in order to satisfy compile-time dependencies for a number of open-source packages.

In order to create the container from the above Dockerfile, I use the following command:

docker build -t docker.repository.example.com dev-container .

This will use the Dockerfile in the current directory to build the container, and tag it with the name dev-container. This will produce a lot of output, as the various dependencies are pulled in, and the shell commands are run. Once the command completes, the docker image is ready for use.

root@ec7145fe35a4:~# docker image ls
REPOSITORY                                                         TAG       IMAGE ID       CREATED          SIZE
docker.repository.example.com/dev-container                        latest    d231e64537d8   5 hours ago    1.24GB
ibm_zcx_zos_ssh_cli_image                                          latest    aba367bbd0d3   3 weeks ago      545MB
ubuntu                                                             21.10     1f9203d2a87b   2 months ago     77.6MB

The container is now ready to run. Since we will be using it in interactive mode, as well as doing development operations on it, we need to provide a few command line options to the docker run command.

docker run --name dev-container -v /var/run/docker.sock:/var/run/docker.sock:ro -dp 7022:22 --security-opt seccomp=unconfined dev-container

Let’s break down those options a bit. The first one is the --name option, which gives the container a meaningful name. Without this, the running container will get a generated name, which while being unique, won’t mean anything to the end user.

The second one is -v, which is for performing a bind mount on a volume. This binds the docker socket from the host filesystem and exposes it to the running container. This allows programs within the container to interact with the docker daemon, and perform container management actions.

The next option is -dp, which forwards port 22 in the container to port 7022 in the Linux guest. This allows you to ssh into the container from the outside world on port 7022. I chose this port as 8022 is used by the default CLI container that is shipped with zCX.

Next we have the --security-opt option, which we pass the seccomp=unconfined parameter. This disables the default docker security profile, and permits a number of system calls to pass through to the guest. This is something that should never be used on a production container, but can be useful during development.

Finally, we have dev-container, which is the name of the container that will be started. When you run this command, docker will start the container, and it will start running in the guest. You can now connect to the container via port 7022.

[angio@thinkmoo6 ~]$ ssh -p 7022 root@zcx_container_guest
X11 forwarding request failed on channel 0
Welcome to Ubuntu 21.10 (GNU/Linux 5.4.0-86-generic s390x)
 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/advantage
This system has been minimized by removing packages and content that are
not required on a system that users do not log into.
To restore this content, you can run the 'unminimize' command.
Last login: Thu Jan  6 21:43:29 2022 from 172.17.0.1
root@f9e646b94f48:~#

At this point, you can start performing development activities. Perhaps you could clone a git repo and compile some open-source software. I personally have a repository with a number of test containers, and I work on them within this development container. I originally started doing this as a way to dogfood zCX, as building software is a rather good stress test for a virtualization subsystem.