Thoughts by Will Furnass on research software, systems administration and teaching.
When I started as a Research Software Engineer at the Uni of Sheffield a year ago I was given a lovely Dell XPS 9550 laptop to work on. The first thing I did was to install Arch Linux on it, which has so far proved to be extremely stable despite the rolling release model and the main Arch repository offering very recent versions of most FOSS packages.
However, the one main issue with running Arch at work is that some commercial engineering software supports Linux but not all flavours: there are a fair few commercial packages that are only supported and only really work with RHEL/Centos/SLES and Ubuntu. Here's what happens when you try to install the Abaqus 2017 engineering simulation software on Arch:
$ bsdtar xf ~/Downloads/Abaqus2017.iso -C ~/abaqus-iso $ cd test/ $ ksh StartTUI.sh CurrentMediaDir initial="." CurrentMediaDir="/home/will/abaqus-iso/1/" Current operating system: "Linux" DSY_OS_Release="Arch" Unknown linux release "Arch" exit 8
I've no issue with companies not wanting to support every flavour of Linux but I stubbornly want to continue running Arch on my machine so as I see it I've three choices:
I've opted for #3:
Containers have been explained many times before in ways that I can't aspire to. All I'll say here is
The containerisation technology I used here is Singularity. You typically use it like so:
I say 'semi-isolated' as certain parts of the host are explicitly exposed to the container to make life simpler e.g.
There's quite a lot more to Singularity that I haven't explained here; I recommend reading the excellent docs for a better overview and tutorials etc.
Let's see if we can run
glxspheres64, a pretty graphical demo application, in a Centos 7 Singularity container from my Arch laptop.
After first installing Singularity (I'm using v2.4.2) we next need to build a Singularity image containing the version of Linux we want to use inside our container plus the applications we want to run. With Singularity, the cleanest way to build an image is from a definition file. For example, here's my
glxspheres.def definition file:
BootStrap: docker From: centos:7 %post wget -O /etc/yum.repos.d/VirtualGL.repo https://virtualgl.org/pmwiki/uploads/Downloads/VirtualGL.repo rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7 yum install -y VirtualGL glx-utils yum clean all && rm -rf /var/cache/yum %environment #export PATH=xxx %runscript vglrun /opt/VirtualGL/bin/glxspheres64 %labels Maintainer willfurnass Version v0.1
We can then build a Singularity image file from this definition file using:
sudo singularity build glxspheres.img glxspheres.def
Let's go explain the different parts of the definition file in turn:
glx-utilspackages, which provide some prerequisites for running a hardware-accelerated graphical app in a container plus
glxspheres64(in the VirtualGL package) and other graphical demo apps (in
glx-utils). The third line in the post section removes unnecessary files to reduce the Singularity image size.
vglrun, provided by VirtualGL, is necessary to run hardware-accelerated graphical apps within our container.
You may be wondering whether you need to be a root-equivalent user to build a container. Yes, you do, as with Singularity you have the same user ID inside and outside the container and you need to be able to modify the root-owned parts of the filesystem inside the container.
We can then run
glxspheres64 within our container with:
singularity run --nv glxspheres.img
Here we create a container that runs the default program in the associated image. From the perspective of this program it appears that it is running on Centos 7: pretty much everything in its local filesystems suggests that's the case.
I should note:
--nvflag tells Singularity to expose the host's NVIDIA graphics device and driver to the container. This is a new feature that works pretty well.
optirun, a tool on my machine that allows me to switch from using the on-board Intel graphics to my more power-hungry and powerful NVIDIA GeForce GTX 960M GPU.
/tmpdirectory are 'bind-mounted' (made available) in the container by default. This is usually what you want.
When you run the container you should see something like:
If you terminate the main process in your container then the container will also exit.
Okay, on to doing something more useful: containerising Abaqus 2017 by building a Centos 7-based image.
My definition file, Abaqus config files (for automated installation) can be found in this repo, as can a
README file that explains most of the specifics; read that if you want the details.
One major difference between the Abaqus 2017 Singularity
.def file and the one shown above is the Abaqus
.def file contains a setup section that runs various commands from the host's perspective before the post section runs (which runs commands from the container's perspective). Here the setup section copies files needed during the image build from the host into the image.
As per the previous example, to get NVIDIA GPU accelerated graphics we need: the
vglrun program (from the
VirtualGL package) inside the container, Singularity's
--nv flag and in my case
optirun (to select my NVIDIA graphics device).
The end result (you'll have to trust me here):
You may be wondering what, if anything, prohibits you from copying the Singularity image to another machine with a new-ish version of Singularity installed and running it there? Well, not much. You don't need be a
root-equivalent user to run a container, only to build one. The two main things you need to care about are that the license server is contactable at run-time from the new host, and secondly that copying the image may not be immediate as it's not exactly small.
$ du -hs *img 11G abaqus-2017-centos-7.img
But thanks to Singularity using compressed squashfs filesystems within its images it's about the same as size of a uncontainerised install of Abaqus 2017 (the Centos part of my image is pretty tiny compared to the Abaqus part).
Singularity containers are great for isolating many types of applications and workflows. Here I put a commercial graphical application in a container so it would think it was running on a different flavour of Linux than I have installed on my laptop, which it effectively is. I can now move this container image around and could run it on local computer clusters or a cloud platform (so long as I can still talk to the application's license server host); this is made easy by the image just being a single file. Also, I should note that the ability to use GPUs for graphics and computation from within containers is really neat, particularly now there is a standardised way of doing this with Singularity (the
There is much more I could write about Singularity but this post has already gotten a bit long so let's call it a day.
If you have any comments or suggestions as to how this post could be improved then get in touch via Twitter.