A review of AIX Container Technology: with perspectives on

Docker Management Operations

Zeyuan Zhu

AIX Development Engineer

In this paper, I'm going to give you an introduction to container technology, AIX

WPAR and Docker container. And I will show you how to perform some common

tasks using both containers.

Container technology in a Nutshell

Container technology has become a hot topic in the IT world in the last few years,

partly as a result of the popularity of Docker and its high adoption rate. Container

technology is the popularized alias for operating system level virtualization. It

provides workloads with isolated operating system environment instances, while all

the instances access the same kernel on the host. It has better cost efficiency than

virtual machines, which virtualize a complete operating system instance including

the kernel. Another common feature that containers have is the encapsulation of its

runtime stack, which enables quick deployment and convenient mobility. These

characteristics align well with today's agile development methodology and the large

distributed environment that workloads run in. It also helps business consolidate

their workloads into fewer machines so that it reduces the administration cost.

Workload Partitions (WPARs)

Operating-system-level virtualization technology has been around since much

earlier than Docker's debut in 2013. A Workload Partition(WPAR) is the operating-

system-level virtualization technology of the IBM AIX operating system.

It was first featured in AIX in 2007. The technology has matured over the years and

has successfully helped many AIX customers save resources and isolate workloads

from each other. Here I want to give a brief refresh on some features that AIX WPAR

technology has developed.

 Storage Options: AIX WPAR provides its user with different options for

storage configuration. hdisks configured in the LPAR (attached to physical FC,

NPIV, or vscsi) can be exported to and used inside WPARs as either rootvg or

datavg. FC Adapter, either physical or virtual, can also be exported to and

used inside WPARs which allows direct provisioning of a lun. WPARs without

storage of its own is another option.

 Shared vs. Non-shared WPARs: By default, a system WPAR shares the /usr

file system and the /opt file systems from the global environment using read-

only namefs mounts. You can configure WPARs to have non-shared,

writable /usr file system and /opt file system, which makes application

installation simpler. A non-shared WPAR is also the type of WPAR that you

can migrate a LPAR to.

 Conversion of a LPAR to a WPAR: A LPAR can be converted to a non-shared

WPAR using the image of the LPAR created by mksysb. This provides a way of

consolidating multiple LPARs on one single LPAR.

 WPAR Networking: WPAR has separate IP addresses, hostnames, domain

names and hostids. This makes a WPAR appear as a stand-alone system for

others as well as for the applications within it. Users may login to the WPAR

using telnet, ssh, rlogin, etc.

 Resource Controls: By default WPARs compete fairly for the LPAR

resources(CPUs, memories, etc.), but WPARs can also be configured with

 limits on how much resource they can use. Different schemes are available

for configuring the resource limits.

 Backup and Restore Facilities: savewpar/restwpar commands provide a

framework for saving WPAR backup images and restoring them later.

 AIX 5.3 Versioned WPAR: AIX versioned WPAR feature provides its users

with the option to run workloads on AIX 5.3 in versioned WPARs as a tactical

solution until able to migrate to latest AIX version. Once ready, versioned

WPARs can be migrated to the same level as the LPAR using migwpar

command.

 WPAR bootset Copy: chwpar command has an option to create an alternate

copy of the WPAR “bootset” to allow a quick roll-back in scenarios like testing

experimental changes to the WPAR.

WPAR and Docker differ in a few aspects, but it's not as different as you would think

when it comes to managing the container. I'm going to show you the comparison of

some basic container management tasks. A very common task that's involved in

container administration is the preparation of an image that contains everything it

needs to launch a container instance to serve web applications. The example I'm

about to show you uses Websphere Liberty Profile to serve a sample web application

provided by IBM.

System Environment
The demonstration of the WPAR usage is executed in an AIX 7.2 environment on an

IBM POWER server. The version of the bos.wpars fileset is 7.2.1.0.

The demonstration of the Docker usage is executed in a Ubuntu 16.04 LTS on an

IBM POWER server. The Docker version of both the server and the client Docker

modules installed on the partition are 1.10.3 with API version 1.22, GoLang version

1.6.1 for the linux/ppc64le platform.

Creating the Image

A container image is the encapsulated collection of what you need to launch a

container instance. It includes the generic specification of your customized

container configuration and the files that need to be in the container instance. It can

be created by taking a snapshot of an container instance, or constructing a recipe

that's usually a script of some sort. Creating the container image enables quick

deployment of a standard workload, as well as moving a workload from one host to

another. As to make this demonstration simple and straightforward, I'm going to

show you how to create a container image by creating a prototype container

instance and then taking a snapshot of it.

The Websphere Liberty Runtime that I used in this example can be downloaded

from here https://developer.ibm.com/wasdev/downloads/liberty-profile-using-

non-eclipse-environments/ and I'm going to use wlp.zip as filename of the

downloaded from this site.

WPAR Image Creation:

First, create a private system WPAR. The option -l specifies that the WPAR being

created is a private WPAR. Private WPARs have their own copies of /opt and /usr

filesystems. Option -s starts the WPAR after it is created. WPARs can have their own

IP addresses so that they are able to communicate with the public network just like

an individual server, it is also required in order to make the WPAR accessible from

the network outside its host.

mkwpar –s -n tyrant -l -N address=9.3.63.38 broadcast=9.3.63.255

Now that the WPAR is created, you can use your favorite tool to transfer the

Websphere Liberty runtime zip to the WPAR. Here I'm using scp.

scp /tmp/wlp.tar root@tyrant:/opt/ibm/

Next, ssh to the WPAR.

ssh root@tyrant

unzip the Websphere Liberty runtime at its default location. /opt/ibm/

cd /opt/ibm/

unzip wlp.tar

The Websphere Liberty runtime contains a utility program that you can use to install

an application from the IBM repository, it also resolves and installs dependency

runtimes if it finds any.

/opt/ibm/wlp/bin/installUtility install Daytrader3Sample

By this point, the WPAR is ready to serve the application.

To save this WPAR instance to an image file, you can now go back to the terminal of

its host and then run:

savewpar -f /tmp/daytrader.bff tyrant

Docker Image Creation

Docker hub is a registry service that allows Docker users to manage images in a

centralized way. The official Docker hub has a collection of ppc64le Docker images

available to pull and there is a Websphere Liberty image that already contains the

runtime stack Docker needs to run Websphere Liberty. But for the sake of

comparison, I'm going to show you how to build a Websphere Liberty image based

on an image that only contains the basic Java runtime.

First you have to pull the base image that you will build your own image upon. In

this example, we choose ppc64le/java as the one.

docker pull ppc64le/java

Now that you have a base image, launch a container that we're going to use to create

our own image.

docker run –itd –-name wlp_prep ppc64le/java /bin/bash

A Docker container is created with an alias wlp_prep. In contrast to the WPAR

technology, Docker by default can't simply just assign an allocated public IP address

to the container that it is going to create. The most common way for a Docker

container to talk to the public network is to map ports to ports on its host. We will

go over that later when we launch the actual instance for serving the web

application. The –it is required if a tty needs to be allocated for the container. The

–d option leaves the container to start in the background as we need to copy the zip

file into the container next.

Once container is created, copy the Websphere Liberty runtime zip file using the

docker cp interface.
docker cp /tmp/wlp.zip wlp_prep:/opt/ibm/

Get into the terminal of the container using docker attach and unzip the wlp.zip

docker attach wlp_prep

cd /opt/ibm/

unzip wlp.zip

Run the Websphere InstallUtility to install the Daytrader3Sample web application.

/opt/ibm/wlp/bin/installUtility install Daytrader3Sample

Then we use Docker commit to capture the image.

docker commit wlp_prep daytrader3sample:latest

At this point, we have a new local image saved that is named daytrader3sample

Launch Instances from the Image

Launch a WPAR from an Image:

We use restwpar to launch a WPAR instance from the image file that has been saved,

the parameters required are the path to the base filesystem of the WPAR and the

network specification.

restwpar –s -F -f /tmp/daytrader.bff -h toyman -n toyman -d

/wpars/toyman -M '-N address=9.3.63.36 broadcast=9.3.63.255'

The WPAR is up and running, now ssh to the WPAR and start the web server.

ssh root@toyman

/opt/ibm/wlp/bin/server run Daytrader3Sample

Launch a Docker Container from an Image

To start a new Docker container instance from the image we saved:

docker run -itd -p 9080:9080 -p 9443:9443 --name wlp_test

daytrader3sample:latest /bin/bash

Here, we're mapping the ports 9080 in the container to the port 9080 on its host,

this way all the packets sent to port 9080 on the host will be routed to port 9080 of

the container, on which Websphere is listening.

Then we get into the container and start the server:

docker attach wlp_test

/opt/ibm/wlp/bin/server run Daytrader3Sample

Stop, Restart and Remove Instances

The commands that are used to stop, restart and remove container instances

are quite straight forward, and they're almost identical for both WPAR and

Docker.

WPAR Docker
stop stopwpar Docker stop
start startwpar Docker start
remove rmwpar Docker rm

Performance Optimization for WPAR: Shared WPAR with a r/w

filesystem

When a private WPAR is created, the complete /opt and /usr filesystems are

copied to the WPAR's own filesystems, the usually large sizes of these two

filesystems would make operations on the WPAR take more time and result in a

larger image file. Although there are scenarios where keeping private copies of these

filesystems are necessary and beneficial, in some cases this would be unnecessary.
For example, Websphere Liberty keeps everything under its root path

/opt/ibm/wlp, so in this case we actually need just the /opt/ibm/wlp directory

to be private writable space for the WPAR while sharing the rest of the /usr and

/opt filesystem with the host with only read permission. The solution to achieve

this is to use a shared WPAR instead of a private WPAR and create the filesystem

that the WPAR needs write permission for. To do this, the only step involved from

the demonstration I showed above is mkwpar. First we create the mount point for

the wlp directory that the WPAR is going to use to mount the writable filesystem

mkdir –p /opt/ibm/wlp

Then, we run mkwpar

mkwpar -M directory=/opt/ibm vfs=jfs2 size=2G -r -n toyman -N

address=9.3.63.36 broadcast=9.3.63.255
The arguments after the –M option are used to create a filesystem exported to the

wpar.

Side-by-side Command Comparison

There is much similarity between how you manage WPARs and Docker containers.

Here I am putting together a comparison of all the commands from my

demonstration grouped by main steps in order to give you a clear view of the

similarities.

Preparing the Image

Create the Container
mkwpar –s -n name -l -N netattr docker pull ppc64le/java
docker run –itd –-name name ppc64le/java
/bin/bash

Install Websphere Liberty

scp /tmp/wlp.zip root@name:/opt/ibm/ docker cp /tmp/wlp.zip name:/opt/ibm/
ssh root@name docker attach name
cd /opt/ibm/ cd /opt/ibm/
unzip wlp.zip unzip wlp.zip

Install Sample Web Application

installUtility install Daytrader3Sample installUtility install Daytrader3Sample

Save the Image

savewpar -f /tmp/daytrader.bff name docker commit name daytrader:latest

Launching an Instance
Start the Container
restwpar –s -F -f /tmp/daytrader.bff -n name -d docker run -itd -p 9080:9080 -p 9443:9443 –name
/wpars/name -M '-N netattr' name daytrader:latest /bin/bash

Start the Web Server

ssh root@name docker attach name
server run Daytrader3Sample server run Daytrader3Sample

Stopping an Instance
stopwpar name docker stop name

Starting a Stopped Instance

startwpar name docker start name

Removing an Instance
rmwpar name docker rm name

Summary

I hope that this paper helps you as a guideline to start exploring the native container

technology on IBM AIX. As we have seen in this paper, the ways to perform some

basic container management tasks are quite similar between WPAR and Docker.

There are many additional aspects of the two container technologies that would be

interesting to investigate. I might write more about containers on AIX in the future

and I also encourage you to implement your container strategy exploiting the AIX

native container technology.