Apptainer: Difference between revisions

=Notice=

====<code>sudo</code> Access With Apptainer is NOT Available====

Many users ask about this since documentation and web sites do discuss using <code>sudo</code> with Apptainer/Singularity. A major design aspect of Apptainer is security and know that <code>sudo</code> access is '''NOT''' available on our clusters. Should you require using <code>sudo</code>, consider the following:

* Install Linux, Apptainer, and <code>sudo</code> in a virtual machine on a system you control where so you will be able to have <code>sudo</code> access within such. (Some images cannot be successfully built without using sudo.)

* If appropriate, [[Technical Support|submit a ticket]] asking if Alliance staff would be able to help build the image(s), etc. required needing <code>sudo</code>. (Understand that this may or may not be possible --but ask in a ticket if what you wish to achieve is beyond your means: there may be other ways to achieve those needs.)

* Apptainer version 1.1 (which has not yet been released as of this writing (August 2022)), may well allow users to use the <code>--fakeroot</code> option with various Apptainer commands. After such has been released, this web page will be updated after the feature has been explored more, tested, and installed on our clusters.

Additionally there is another option, <code>-W</code> or <code>--workdir</code>, one should consider using. On our clusters (and on most Linux systems), the <code>/tmp</code> and similar filesystems use RAM --not disk space-- and jobs are run on our clusters typically with limited RAM requests. This can result in jobs getting killed because they consume too much RAM (relative to what was requested). A suitable work-around for this is to tell Apptainer to use a "workdir" for such filesystems, <code>$HOME</code> (if <code>-c</code> is also used), etc. This is done by passing the <code>-W</code> option followed by a path to a disk space location where Apptainer can read/write temporary files, etc.

If you want to run MPI programs inside a container there are things that need to be done in the host environment in order for such to work. Please see the [[#Running_MPI_Programs_Inside_an_Apptainer Container|Running MPI Programs section below]] for an example of how to run MPI programs inside a container.

Apptainer images can be created in the following formats:

<code>SIF</code> files can contain multiple sections where each section is normally a squashfs, i.e., read-only and compressed, filesystem although read-write filesystems and overlay images can also be added to the <code>SIF</code> file. That said, unless such additional sections are present, one need not be concerned about the sections contained within an <code>SIF</code> file, e.g., the Apptainer <code>build</code> command produces a read-only <code>SIF</code> file when building images.

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 read-write access in order to be able to update the container image. (By default <code>SIF</code> files are read-only.)

If the container image will not need to be updated, one should create an <code>SIF</code> file image as disk performance with such is much faster, e.g.,

* an <code>SIF</code> file, which can be many gigabytes in size, is a single file which will result in excellent disk access performance and inode use on underlying filesystems,

* an <code>SIF</code> file, is (typically) read-only and compressed further improving disk access speeds, and,

* an <code>SIF</code> file that is read-only can be used with bind-mounted directories and/or overlay images that are not read-only should such be needed.