Apptainer: Difference between revisions
No edit summary |
No edit summary |
||
(One intermediate revision by the same user not shown) | |||
Line 6: | Line 6: | ||
# Users need to update their library constantly; | # Users need to update their library constantly; | ||
# It also makes the user more independent of the cluster admins. | # It also makes the user more independent of the cluster admins. | ||
== Instructions == | == Instructions == | ||
Line 16: | Line 14: | ||
Building the container takes only one line of code, the structure (when building directly from a prebuilt image) is as follows | Building the container takes only one line of code, the structure (when building directly from a prebuilt image) is as follows | ||
<code>apptainer build [OPTION] <name-for-the-container> <library>://<prebuilt-image></code> | <code>apptainer build [OPTION] <name-for-the-container> <library>://<prebuilt-image></code> | ||
In order to know all the available “options”, one can run <code>apptainer build --help</code>. For the <code><library></code> part, usually we rely on DockerHub (for more options see the apptainer documentation). In general, we are interested in building a container image that is a single .sif file that can be transferred between computers. However, there is an interesting option called --sandbox, which creates an expandable container image. Sandboxes will be useful when trying to build a custom image. However, this type of container has two side effects. First, these containers take up more space. Secondly, they are not reproducible. | In order to know all the available “options”, one can run <code>apptainer build --help</code>. For the <code><library></code> part, usually we rely on DockerHub (for more options see the apptainer documentation). In general, we are interested in building a container image that is a single <code>.sif</code> file that can be transferred between computers. However, there is an interesting option called <code>--sandbox</code>, which creates an expandable container image. Sandboxes will be useful when trying to build a custom image. However, this type of container has two side effects. First, these containers take up more space. Secondly, they are not reproducible. |
Latest revision as of 06:55, 3 July 2024
Apptainer is the most widely used container system for HPC. It is a replacement (or next generation) for Singularity supported by the Linux Foundation.
Containers are a way to isolate your software and make it portable and reproducible. It is a valuable asset for reproducible science and, in addition, Its use is especially recommended when
- Users rely on “old” libraries (e.g., HDF4);
- Users need to update their library constantly;
- It also makes the user more independent of the cluster admins.
Instructions
The steps to build a container always start with loading the apptainer module as follows
module load apptainer
For the next step, users have two options: 1) to just use a prebuilt image, or 2) to use a .def file (called recipe) that will contain the instructions to build the container. When using the latter option, we can build our container on top of another prebuilt image.
Building the container takes only one line of code, the structure (when building directly from a prebuilt image) is as follows
apptainer build [OPTION] <name-for-the-container> <library>://<prebuilt-image>
In order to know all the available “options”, one can run apptainer build --help
. For the <library>
part, usually we rely on DockerHub (for more options see the apptainer documentation). In general, we are interested in building a container image that is a single .sif
file that can be transferred between computers. However, there is an interesting option called --sandbox
, which creates an expandable container image. Sandboxes will be useful when trying to build a custom image. However, this type of container has two side effects. First, these containers take up more space. Secondly, they are not reproducible.