Most scientific computing facilities, such us HPC or grid infrastructures, are shared among different research disciplines, and thus the system software environment needs to be generic enough to accommodate different user and applications profiles; they are multi-user environments.

Because of managerial and technical constraints, such infrastructures cannot afford offering every research project a tailored environment in their machines. Therefore the interest of exploring the applicability of containers technology on such systems is rather evident from the end-user point of view.

Researchers need then to customize their applications software to fit the computing center environment at the level of system software and batch system. Containers provide a way to pack and deploy software including all the dependencies in a way that can be executed in a seamless way, independently of the underlying Linux Operating System and environment. The main benefit of integrating the execution of containers in HPC systems would then be to provide a way to execute applications homogeneously across different resource centers.

The flagship container software, Docker, cannot be used in a satisfactory way on HPC systems, grids and in general multi-user oriented infrastructures. Deploying Docker on such facilities presents a number of problems related to the fact that within the container, processes are executed with the root id. This raises security concerns among system managers, as the Docker root might be able to gain access to root privileges in the host machine. Also, when executed as root, the processes escape from the usual managerial limits on resource consumption or accounting, imposed on regular users at shared facilities.

User-level tools

The user-level tool udocker provides a layer for users to execute Docker containers, that by definition, does not require the intervention of the system administrators. Udocker combines the pulling, extraction and execution of Docker containers without requiring privileges. The Docker image is extracted on a user-space filesystem area, and from there on, it is executed in an chroot-like environment.

udocker provides a command line interface that mimics Docker, providing a subset of its commands to be able to handle Docker images at the level of pulling, extracting and execute containers “á la Docker”.

Processes are run without privileges under the regular user id, under the same process tree, thus facilitating the enforcement of the managerial limits imposed to regular users in HPC or grid resource centers.

udocker provides several ways, depending on the application and host environment, to execute containerized applications. It is also possible to access specialized hardware like Infiniband for MPI jobs, or GPGPUs, making it adequate to execute containers in batch systems and HPC infrastructures.

udocker enables the execution of Docker containers with different engines based on intercepting system calls. Depending on the application requirements the user may choose to run in one execution mode or another. For instance CPU-intensive applications may use udocker in the ptrace execution mode, to intercept and modify pathnames; if the application is I/O intensive the interception of system calls via library pre-loading using the Fakechroot execution mode is a more adequate way to run the container. All the tools and libraries required by udocker and its execution modes are provided with udocker itself.

The udocker execution mode RunC employs the technology of user namespaces to run the containers in rootless mode. This feature can be used with modern Linux distributions with kernels from 3.9 on. However most HPC systems are conservative environments and it will take some time until they will be able to support this execution mode.

Regarding impact in performance, in the figure presented below we have plotted the weak scaling performance of openQCD, a comprehensive software package to run Lattice QCD simulations (a CPU-intensive application) from 8 to 256 cores.

As we see, the performance of the containerized version of openQCD is slightly higher than the one on the host itself. This is especially so when the execution takes place within a single node (the test machine has 24-core nodes).

This behavior has been reported consistently by container users across different hardware and system software settings, and it is related to the better libraries available in the more advanced versions of the operating systems inside the container. Clearly this feature opens the door to container exploitation in HPC mainframes since there the software system is by necessity very conservative.

Figure Caption: Weak Scaling performance of openQCD with a local lattice of Volume=32^4. The tests have been performed on the Finisterrae-II HPC system at CESGA (Spain).

Since its first release in June 2016 udocker expanded quickly in the open source community. It is being used in large international collaborations like the case of MasterCode, a leading particle physics phenomenology collaboration, which uses udocker to handle the library complexity of the set of codes included in the MasterCode.

It has also been adopted by a number of software projects to complement Docker. Among them openmole, bioconda, Common Workflow Language or SCAR.

System Administration level

Beyond the user level, several solutions have been developed in recent times to support system administrators in deploying customized containers for their users. These solutions rely on the installation of system software by the system administrator, which also is in charge of preparing the containers that the users are authorized to run on the system. The most popular of these tools is Singularity.

Singularity can be downloaded and installed from source or binaries, and must be installed by root for the software to have all the functionalities. Singularity binaries are therefore installed with SUID and need be deployed in a filesystem that allows SUID. Given the security concerns on network filesystems regarding SUID, Singularity is normally installed in a directory locally accessible to the users (i.e., not network-mounted).

Singularity offers its own containers registry, the Singularity Hub, and its own specification to create containers, the Singularity Recipe (i.e., the Singularity equivalent of the Dockerfile specification).

The default container format is squashfs, which is a compressed read-only Linux file system, where the images need to be created by root.

It also supports a sandbox format, in which the container is deployed inside a standard Unix directory, much like udocker. In particular, executing udocker in Singularity execution mode will cause the container to be executed via Singularity if installed in the system. In order to do this udocker exploits the sandbox mode.

The container building environment of Singularity belongs to root. Containers may be built either from a Singularity recipe, from a previous container coming from the Singularity Hub, or importing a container from the Docker repository. Notice that the Singularity format for containers is not compatible with Docker; therefore, in the latter case the container needs to be converted to the Singularity format.

Once the container exists, it can be executed by a regular user in a way analogous to Docker. These containers can also be checked at the binary level, at the level of sensitive content of the filesystem for example, or even for particular features defined by the system administrator.

The comparison of the most popular tools, udocker and Singularity, shows that they have a completely different scope, and the selection of one solution or another depends on the priorities at the user level and the computing center management policies.

Singularity is a system administration level tool, to be installed at this level, giving the managers of the infrastructure full control of which containers are run into the system or not. Udocker however is a user tool that acts as a layer over different execution methods, enabling regular users to run containers in their own user space, much in the philosophy of the jailed systems.

About the Authors

Jorge Gomes is a computing researcher at the Laboratory of Instrumentation and Experimental Particle Physics (LIP). He worked in the development of advanced data acquisition systems at CERN, and participated in pioneering projects in the domain of digital satellite data communications, IP over ATM, and advanced videoconferencing over IP networks. Since 2001 he has participated in numerous projects regarding distributed computing, networks and security in Europe and Latin America. He is the head of the LIP Advanced Computing and Digital Infrastructures Group and technical coordinator of the Portuguese National Grid Infrastructure, representative of Portugal in the Council of the European Grid Infrastructure (EGI) and responsible for the Portuguese participation in IBERGRID, that joins Portuguese and Spanish distributed computing infrastructures.

Isabel Campos is a physics researcher at the Spanish National Research Council (CSIC). She holds a PhD in the area of Lattice QCD simulations, and has hold research associate positions at DESY-Hamburg and Brookhaven National Lab, and Leibniz Supercomputing Center in Munich. Since 2005 she has participated in numerous project aimed at developing software and deploy distributed computing infrastructures in Europe. She is the head of the e-Science and Computing group at IFCA-CSIC, coordinator of the Spanish National Grid Infrastructure, representative of Spain in the Council of the European Grid Infrastructure (EGI) and responsible for the Spanish participation in IBERGRID, that joins the Spanish and Portuguese distributed computing infrastructures.