A review of AIX Container Technology: with perspectives on. Docker Management Operations. Zeyuan Zhu. AIX Development Engineer

Transcription

1 A review of AIX Container Technology: with perspectives on Docker Management Operations Zeyuan Zhu AIX Development Engineer

2 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)

3 Operating-system-level virtualization technology has been around since much earlier than Docker's debut in A Workload Partition(WPAR) is the operatingsystem-level virtualization technology of the IBM AIX operating system. It was first featured in AIX in 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.

4 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 readonly 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

5 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

6 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 The demonstration of the Docker usage is executed in a Ubuntu LTS on an IBM POWER server. The Docker version of both the server and the client Docker modules installed on the partition are with API version 1.22, GoLang version 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 and I'm going to use wlp.zip as filename of the downloaded from this site. WPAR Image Creation:

7 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= broadcast= 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

8 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.

9 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= broadcast= ' 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:

10 docker run -itd -p 9080:9080 -p 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.

11 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= broadcast= 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. Create the Container mkwpar s -n name -l -N netattr Install Websphere Liberty Preparing the Image docker pull ppc64le/java docker run itd -name name ppc64le/java /bin/bash

12 scp /tmp/wlp.zip docker cp /tmp/wlp.zip name:/opt/ibm/ ssh 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 server run Daytrader3Sample stopwpar name startwpar name rmwpar name docker attach name server run Daytrader3Sample Stopping an Instance docker stop name Starting a Stopped Instance docker start name Removing an Instance 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.

13