Apptainer/en: Difference between revisions

* you need to access others' files on your research time in other locations, and/or,

<b>NOTE:</b> Please note and heed the advice concerning building images/overlays given in section <b>[[#Building_images_or_overlays|Building images and overlays]]</b>.

Apptainer "images" can be created in the following formats:

* as an <code>SIF</code> file, or,

* as a "sandbox" directory.

<code>SIF</code> files internally can contain multiple parts where each part is typically a squashfs filesystem (which are read-only and compressed). It is possible for <code>SIF</code> files to contain read-write filesystems and overlay images as well --but such is beyond the scope of this page: see the official Apptainer documentation on how to do such. Unless more advanced methods of building an "image" were used, the Apptainer <code>build</code> command produces a <code>SIF</code> file with a read-only squashfs filesystem when building images. (This is the preferred option since the resulting image remains as-is since it is read-only, and, the image is much smaller since it is compressed. Know that disk reads from that image are done very quickly.)

A "sandbox" directory is a normal directory in the filesystem that starts out as empty and as Apptainer builds the image it adds the files, etc. needed in the image to that directory. The contents of a "sandbox" directory should only be accessed, updated, etc. through the use of Apptainer. One might need to use a "sandbox" directory in situations where one needs to have read-write access to the image itself in order to be able to update the container image. That said, if updates are infrequent, it is typically easier and better to use an <code>SIF</code> and when updates need to be done, build a sandbox image from the <code>SIF</code> file, make the required changes, and then build a new <code>SIF</code> file, e.g.,

Using an <code>SIF</code> image is recommended as disk performance (from the container image) will be faster than storing each file, etc. separately on Alliance cluster filesystems (which are set up to handle large files and parallel I/O). Using an <code>SIF</code> file instead of a sandbox image will also only use a quota file count amount of 1 instead of thousands (e.g., images will typically contain thousands of files and directories).

Many Linux distributions' package managers require root in order to use them. This implies that Apptainer version 1.0.x and the older Singularity cannot be used on compute clusters to build images as a normal user. Should such occur, submit a ticket asking for help to create that image or use a computer with Apptainer installed and you have root permissions.

Apptainer has a <code>--fakeroot</code> feature that can be used to build and manipulate images. Before Apptainer version 1.1, one wanting to use this feature on a cluster requires submitting a ticket requesting a system administrator to consider adding that person so Apptainer's <code>--fakeroot</code> for a specific cluster. (This may or may not be done --such will be responded to in that ticket.) With Apptainer version 1.1, <code>--fakeroot</code> can be used without being formally added.

If all you need is to use a Docker image as-is with Apptainer, often those images can be built and run without issues, e.g.,  without any need to have additional permissions or explicitly use <code>--fakeroot</code>. Should you need to modify the image after creating it, such may require elevated permissions to successfully do this, e.g., if the image's Linux distribution's package manager requires such and you need to install a package using it. For this reason, the examples shown below assume one only needs to use a Docker image as-is.