Singularity to Apptainer renaming
Singularity has been renamed to Apptainer in 2022 due to legal constraints. In general, just the name has changed and all options are the same. Replacing the command `singularity` with `apptainer` should work on updated systems.
As Apptainer/Singularity needs to mount some auxiliary file systems and needs to use some kernel features, building a fresh container needs root/sudo permissions on the build host. E.g.,
> singularity build --sandbox MyContainerName.d Singularity
It is good practise (and strongly recommended) to write a proper Apptainer/Singularity recipe file stating all the steps that define the container.
If you build up your container by running it as writable sandbox container from some base image and install/config stuff manually, you will end up with an unmaintainable blob. Take the advice from a sysadmin and take your time to think and construct your container as a template - your future self will thank you!
Fixing Permissions
When you build a sandbox container under root, files in the resulting container's directory tree will probably belong to root.
So, we better change the ownership of all files in the container to our own user
> sudo chown -R YOURUSER:YOURGROUP MyContainerName.d
Additional we can make the files and directories readable for all, if we plan to share the container with others
> chmod -R a+r MyContainerName.d
> find MyContainerName.d -type d -exec chmod 0755 {} \;
Fat Containers vs. Sandbox Dir Containers
When building a container, Apptainer/Singularity will normally create a single image file, i.e., containing all the containers files in a packed blob. This has the advantage to be smaller and instantly portable.
However, the large disadvantage is, that to run in/from the container the whole image blob has to be loaded. That is probably not an issue, if you run just locally somewhere, but will increase latency etc. pp. when you reside on a network filesystem or cache from CVMFS.
Better use in such cases the '--sandbox' flag during builds, i.e., the container will be just an expanded directory tree with all files lying around on their own.
For example
> singularity exec --cleanenv --contain /cvmfs/grid.desy.de/container/sl6.d/ cat /etc/redhat-release | wc
1 4 28
> ls -hall /cvmfs/grid.desy.de/container/sl6/bin/cat
-rwxr-xr-x 1 cvmfs cvmfs 45K Jun 19 17:15 /cvmfs/grid.desy.de/container/sl6.d/bin/cat
will just cache from CVMFS the 'cat' binary in the container (plus the helper files around) from CVMFS and run it in the container's environment, where the output is send to stdout and can be further processed in your native environment.
In comparison, for ATLAS' fat SL6 container
> ls -hall /cvmfs/atlas.cern.ch/repo/containers/images/singularity/centos6-20180227012153-b83ffa8a16125230f106f29c07c681cddfcebf75151deb294f8a69cbfad35b4f.img
-rwxr-xr-x 1 cvmfs cvmfs 377M Feb 27 2018 /cvmfs/atlas.cern.ch/repo/containers/images/singularity/centos6-20180227012153-b83ffa8a16125230f106f29c07c681cddfcebf75151deb294f8a69cbfad35b4f.img
the whole 377M have to cached first on the host by CVMFS, before it can be executed just to run the 45k 'cat' in it...
(I prefer to name my containers with a trailing ".d" if they are sandbox containers, e.g., "condormon.d" - but that's just a matter of taste)
Shipping Sandbox Containers
If you plan to send a sandbox container somewhere else, pack its directories in one tarball to dodge it's advantage/disadvantage being not already a single file blob
> tar -cJvf MyContainerName.d.tar.xz MyContainerName.d
to unpack the tarball, run
> tar -xJvf MyContainerName.d.tar.xz MyContainerName.d
but also starting on a packed container tarball works (of course with some unpacking overhead)
> singularity shell MyContainerName.d.tar.xz