Building and Running Containers

Singularity

Singularity is not conceptually much different from Docker. Remember that it is really focused on HPC containers. Although rather easy to install, it is very dependent on a specific version of Go, which could cause issues, so be sure to read the installation documents and look at the release notes. However, once you have the matching version of Go, the installation is very easy.

In general, Singularity requires that you have root access to build your image (hold on, though, there is an exception). The HPC world could argue that root access is either a so-so thing or a bad thing. For the HPC users who have root access to their laptops, or even desktops, this is a non-issue. Work laptops, desktops, or workstations, however, typically won’t give you root access or even sudo access (maybe sudo  for a few commands). Your work site will have policies for this issue.

If you don’t have root access, you can always create your image on a home machine or boot a laptop to a Linux distribution on a USB stick.

The other option is to use the build option --fakeroot . I’ll discuss this option more later on in the article.

Building a Singularity image locally is very straightforward and not unlike that of Docker. A sample build command as root might be:

$ sudo singularity build container.sif container.def

The command takes the Singularity definition file container.def and builds the resulting image container.sif (where sif stands for Singularity Image Format).

A number of build options are listed on the Singularity website. The two I recommend are:

• --encrypt
• --fakeroot

A very important Singularity feature is the ability to build encrypted images. The -e or --encrypt option during a build encrypts the filesystem image within a Singularity image. This encryption can be done with either a passphrase or asymmetrically with an RSA key pair in Privacy-Enhanced Mail (PEM/PKCS1) format.

The great thing about the encryption is that the image is encrypted at rest. A container based on the image is encrypted in transit and while running. At no time is a decrypted version on disk. The decryption occurs at run time, completely in kernel space. The details of how you encrypt an image during the build is explained in the documentation.

A definite best practice for building Singularity images is always to encrypt . You can pick the encryption method you want, but the advantages of encryption far outweigh the extra effort needed to decrypt them.

Singularity has a unique feature called fakeroot for building images and running containers. The feature is called with the option --fakeroot and is commonly referred to as “rootless,” allowing an unprivileged user to run a container by leveraging user namespace UID/GID mapping.

A fakeroot user inside a container and the requested namespaces has almost the same admin rights as root. The first implication is that you don’t have to have root access to build an image. The other implications are that the fakeroot user:

• can set UID/GID ownership for files or directories they own,
• can change user:group identity with the su or sudo  commands, and
• have full privileges inside the requested namespace.

The Singularity documentation discusses the implications of encryption for filesystems and networking. If you struggle to understand fakeroot, then understanding the filesystem implications might help.

A fakeroot user can neither access nor modify files and directories on the host system, where they don’t have access or rights. For example, you wouldn’t be able to access root-only files such as /usr/shadow or the host /root  directory, just as a normal user cannot.

Almost everyone should be running a Linux distribution that can use this feature: Linux kernel greater than 3.8. Singularity recommends a kernel greater than 3.18.

If you don’t have root access or, for some reason, can’t use the --fakeroot option, how can you build an image? Sylabs, the company behind Singularity, has a service named Remote Builder that allows people without root or the ability to use --fakeroot to build a Singularity image. Conceptually, it’s very simple:

$ singularity build --remote output.sif /home/laytonjb/TEST/singularity.def

The --remote option tells Singularity to use Remote Builder. (You have to have an account first.) Remote Builder takes the image definition file, singularity.def , and copies it to the Remote Builder virtual machine (VM) that then creates the image. Afterward, Remote Builder copies the image back to the user’s specified location, and the VM is destroyed.

The documentation for Remote Builder seems to be a little sparse right now, but it appears that the first 30 days are free. Apparently, you are limited to 2GB images and a 30-minute build time. Presumably, you can pay to use the service longer, create larger images, and have longer build times, but you would have to contact Sylabs for more information.

The Remote Builder system offers a very cool solution to the root access requirement to build an image.

Running Containers

Running a container should be seen as a separate function from building the image (recall that a container is a running instance of an image). You can build images with Singularity or Docker or in other ways, and in some cases, other container run times can be used to “run” the container.