cc_staff
156
edits
Apptainer: Difference between revisions
Jump to navigation
Jump to search
no edit summary
(create empty page) |
No edit summary |
||
| Line 1: | Line 1: | ||
{{Draft}} | {{Draft}} | ||
=Notice= | |||
Text to come | This page is '''draft work-in-progress'''. At the time of writing (August 2022) Apptainer version 1.1 is in release candidate status and the full release may well induce further updates to this page. (This page's current content is correct for Apptainer version 1.0.) | ||
==If Currently Using Singularity== | |||
We strongly recommend that you start using Apptainer instead of Singularity. SingularityCE (up to v3.9.5) was adopted by The Linux Foundation and renamed to Apptainer with these changes: | |||
* added '''experimental''' support for [https://dmtcp.sourceforge.io/ DMTCP checkpointing], | |||
** NOTE: Support for such is not in Singularity. | |||
* removed support for the <code>--nvccli</code> command line option, | |||
* removed support for <code>apptainer build --remote</code>, | |||
* removed support the SylabsCloud remote endpoint replacing it with a DefaultRemote endpoint with no defined server for <code>library://</code>, | |||
** NOTE: If the SylabsCloud remote is needed, the [https://apptainer.org/docs/user/1.0/endpoint.html#restoring-pre-apptainer-library-behavior previous default can be restored]. | |||
* renamed all executable names, paths, etc. having <code>singularity</code> in their names to have <code>apptainer</code> in them, | |||
** e.g., instead of using the <code>singularity</code> command one uses the <code>apptainer</code> command | |||
** e.g., the <code>~/.singularity</code> directory is now <code>~/.apptainer</code> | |||
* renamed all environment variables having <code>SINGULARITY</code> in their names to have <code>APPTAINER</code> in them, | |||
Should you need to port scripts, etc. to Apptainer, know Apptainer version 1 is backwards compatible with Singularity --so such porting can be done incrementally. | |||
=Using Apptainer= | |||
In order to use Apptainer one must first already have a container image, e.g., a <code>.sif</code> file or a "sandbox" directory created previously. If you don't already have a container image, see the section on [[#Building_an_Apptainer_Container/Image|building an image]] below. | |||
==Loading an Apptainer Module== | |||
In order to use the default version of Apptainer available run: | |||
<source lang="console">$ module load apptainer</source> | |||
To see the available versions of Apptainer that can be loaded run: | |||
<source lang="console">$ module spider apptainer</source> | |||
==Running Programs Within a Container== | |||
Text to come. | |||
===<code>apptainer run-help</code>=== | |||
Text to come. | |||
===<code>apptainer run</code>=== | |||
Text to come. | |||
===<code>apptainer shell</code>=== | |||
Text to come. | |||
===<code>apptainer exec</code>=== | |||
Text to come. | |||
===<code>apptainer instance</code>=== | |||
Text to come. | |||
==Bind Mounts and Persistent Overlays== | |||
Text to come. | |||
===Bind Mounts=== | |||
Text to come. | |||
===Persistent Overlays=== | |||
Text to come. | |||
==Building an Apptainer Container/Image== | |||
Apptainer images can be created in the following formats: | |||
* as an <code>SIF</code> file, or, | |||
* as a "sandbox" directory. | |||
<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. | |||
===Building a Sandbox Directory=== | |||
In order to build a "sandbox" directory instead of an <code>SIF</code> file instead of providing an <code>SIF</code> file name, instead provide <code>--sandbox DIR_NAME</code> or <code>-s DIR_NAME</code> where <code>DIR_NAME</code> is the name of the to-be-created-directory where you want your "sandbox" image. For example, if the <code>apptainer build</code> command to create an <code>SIF</code> file was: | |||
<source lang="console">$ apptainer build bb.sif docker://busybox</source> | |||
then change <code>bb.sif</code> to a directory name, e.g., <code>bb.dir</code>, and prefix such with <code>--sandbox</code>: | |||
<source lang="console">$ apptainer build --sandbox bb.dir docker://busybox</source> | |||
Differences between building a "sandbox" image and a (normal) <code>SIF</code> file are: | |||
* the <code>SIF</code> file's image will be contained in a single file, compressed, and read-only, | |||
* the "sandbox" image will be placed in a directory, uncompressed, may contain thousands of files (depending on what exactly is in the image), and will be able to be read-write. | |||
Within an account, using a "sandbox" directory will consume significant amounts of both disk space and file count quotas, thus, if read-write access to the underlying image is not normally required, you are advised to use an <code>SIF</code> instead. Additionally, using an <code>SIF</code> file will have higher disk access speeds to content contained within the <code>SIF</code> file. | |||
===Building an SIF File=== | |||
'''NOTE:''' This section only discusses some basics of creating a simple compressed, read-only <code>SIF</code> file container image. See the [https://apptainer.org/docs Apptainer documentation] for more advanced aspects of building images. | |||
Text to come. | |||
=Using Conda Within a Container= | |||
Text to come. | |||
=Running MPI Programs Inside a Container= | |||
Text to come. | |||
=FAQ= | |||
Text to come. | |||