Containers
From a users perspective containerized application environments offer the freedom to select any Linux distribution of choice to build a custom container image. Users can install any package or software required. Containers provide a high level of customization down to a very specific collection of compliers, libraries and other tools in any desired version. This chapter provides an over how to work with containers on the compute cluster.
Overview
It is very difficult to provide application dependencies for all possible use-cases of a compute cluster within a single environment. Linux container technology1 allows the infrastructure provider to overcome this limitation. Containers are in many ways the next logical progression from virtual machines and implement operating system-level virtualization2 to encapsulate a software environment (typically called software stack). They enable multiple users/groups to execute and build their own instance of an application environment.
Containers make it possible to better decouple user application software from the host platform. Which gives cluster administrators more freedom to migrate the underling platform running the hardware. This is not only relevant for security patch management. But even more important to support a broad scope of hardware, including accelerators like GPUs with software drivers bound to specific Linux kernel versions.
In context of containers a custom environment to execute a program is called an application (run-time) environment. These application environments are executed by a container run-time engine (CRE) like Apptainer3. Typically CREs load the application environment from a container image, which is a single binary file storing the file-system tree including all applications dependencies.
Limitations
Linux containers have limitations concerning portability and abstraction:
- Containers are build for a specifics machine architecture in binary format. For instance, a container build for Intel
x86_64will not run on any different platform. - Containers rely on the Linux kernel Application Binary Interface (ABI), which is not necessarily uniform across all Linux distributions. In particular older kernels may not have all required capabilities.
- Containers need to support hardware used by applications. This includes network devices interconnects like InfiniBand and hardware accelerator devices like GPUs.
- Multiple different formats for container images are available. Some of them are interchangeable or have means to convert between different formats.
The Virtual Application Environments (VAEs) provided by IT department are build and tested specifically for the Virgo cluster and relieve the users from the necessity of dealing with hardware support and optimization.
Container Images
Basically all HPC container run-time engines are in some way compatible to Docker 4. Container images build with Docker follow the container format specification of the Open Container Initiative (OCI) 5, which makes these run-time agnostic and to a certain extend future proof.
However, using a standardized container image format does not necessarily imply independence of a run-time infrastructure as described in the previous section about container limitations. Apptainer uses the SIF (Singularity Image Format) as a container image format to improve on the support of scientific computing application on HPC infrastructure. If you are interested in the relation and compatibility to Docker read the support for Docker and OCI 6 section in the Apptainer User Guide.
Footnotes
List of Linux Containers, Wikipedia
https://en.wikipedia.org/wiki/List_of_Linux_containers↩︎OS Level Virtualization, Wikipedia
https://en.wikipedia.org/wiki/OS-level_virtualization↩︎Apptainer Project, Linux Foundation
https://apptainer.org/↩︎Docker Software, Wikipedia
https://en.wikipedia.org/wiki/Docker_(software)↩︎Open Container Initiative
https://opencontainers.org↩︎Support for Docker and OCI Containers, Apptainer User Guide
https://apptainer.org/docs/user/latest/docker_and_oci.html↩︎