Advanced use of Singularity
Singularity CLI continued¶
Similar to Docker which uses a
Dockerfile to build its images, Singularity uses a file called
- Singularity images use the
.sifextension and appear as a single compressed file, versus Docker which uses many cached file layers to create a single image.
.siffiles also use layers, but these are not apparent.
.sifimages are cached in the folder where you build them, or designate them.
- When building from
docker://the Docker image layers are downloaded and cached by Singularity in a
/.Singularityfolder on your build environment.
.sif image using a Docker image as the template¶
As we've learned from the HPC and HTC groups, building Singularity images is not necessarily the most accessible and reproducible method for managing containers.
Most groups suggest that you build your containers with Docker, and host them on a Docker Registry first.
The market dominance of Docker and its wide acceptance as a container format, has led us to use Singularity with Docker in most cases.
We've already covered how you can pull an existing image from Docker Hub, but we can also build a Singularity image from the Docker Hub using the build command:
Test the new
Does it work?
When I try to install software to the image without
sudo it is denied, because
root is the owner inside the container. When I use
sudo I can install software into the container. The software remains in the sandbox container after closing the container and restart.
In order to make these changes permanant, I need to rebuild the sandbox as a
.sif from scratch¶
The contents of the
Singularity file differ from
%help- create text for a help menu associated with your container
%setup- executed on the host system outside of the container, after the base OS has been installed.
%files- copy files from your host system into the container
%labels- store metadata in the container
%environment- loads environment variables at the time the container is run (not built)
%post- set environment variables during the build
%runscript- executes a script when the container runs
%test- runs a test on the build of the container
Singularity file can be hosted on GitHub and will be auto-detected by Singularity-Hub when you set up your container Collection.
When you are building locally, you can name the
Singularity file whatever you wish, but a better practice is to put it in a specified directory and name it
Building your own containers requires that you have sudo privileges - therefore you'll need to develop these on your local machine or on a VM that you can gain root access on.
The top of the file, selects the base OS for the container, just like
FROM in Docker.
Bootstrap: references another registry (e.g.
docker for DockerHub,
library for Sylabs Container Library).
From: selects the tag name.
debootstrap with a build that uses a mirror:
Using CentOS-like container:
Note: to use yum to build a container you should be operating on a RHEL system, or an Ubuntu system with yum installed.
Using a localimage to build:
The container registries which Singularity uses are listed in the Introduction Section 3.1.
- The Singularity file uses sections to specify the dependencies, environmental settings, and runscripts when it builds.
%help section can be as verbose as you want
%setup commands are executed on the localhost system outside of the
container - these files could include necessary build dependencies. We
can copy files to the
$SINGULARITY_ROOTFS file system can be done
%files include any files that you want to copy from your localhost into the container.
%post includes all of the environment variables and dependencies that you want to see installed into the container at build time.
%environment includes the environment variables which we want to be run when we start the container
%runscript does what it says, it executes a set of commands when the
container is run.
%labels are used similar to Dockerfile which allow you to add metadata to the image file in key-value pairs
Labels can be read using the
Singularity file bootstrapping an Ubuntu (22.04) image.
Build the container:
Run the container:
Sandboxing is another approach to building up a container image.