4.3 Build process

4.3.1 Examples

There are different ways to generate Singularity image files. The most common way is so far thanks to existing Docker images already present in public registries. Through registries Docker Hub


    singularity build fastqc-0.11.9_cv7.sif docker://biocontainers/fastqc:v0.11.9_cv7 Biocontainers Via quay.io


    singularity build fastqc-0.11.9.sif docker://quay.io/biocontainers/fastqc:0.11.9--0 Via Galaxy project prebuilt images
    singularity pull --name fastqc-0.11.9.sif https://depot.galaxyproject.org/singularity/fastqc:0.11.9--0
Galaxy project provides all Bioinformatics software from Biocontainers initiative as Singularity prebuilt images. If download and conversion time of images is an issue for you, this is likely the best option if working in the biomedical field. Singularity catalog

Not as popular so far, but it provides a lot of recipes (to be discussed below) Docker Daemon

If you create your own images (as we did during the course) and you don’t want to share them publicly (and you have not access to any private image registry, either), you can convert your locally built Docker images into Singularity image files.

        singularity build fastqc-web-0.11.9.sif docker-daemon://fastqcwww

4.3.2 Sandboxing

Instead of generating an image file, it is actually possible to use a whole directory with its contents. This is handy when specific changes may be needed.

     singularity build --sandbox ./sandbox docker://ubuntu:18.04
     touch sandbox/etc/myetc.conf
     singularity build sandbox.sif ./sandbox
Apart from testing or debugging, as we commented with Docker, we don’t recommend this approach because it makes reproducibility more difficult.

4.3.3 Singularity recipes

Singularity provides its own build system and recipe syntax. Despite it is actually possible to generate images from scratch (known as bootstraping) thanks to these recipes, this is at time of writing far slower than converting from Docker ones. Docker has the advantage of saving every action line as a cached image. That is not happening with Singularity.

When using recipes, it’s mandatory to have administrator permissions (e.g., as beeing root or via sudo).

In any case, it can still be useful to boostrap an image derived from a previously existing one. Below we provide two common approaches: Docker bootstrap

Instead of converting a Docker image into a Singularity one, it’s possible to use one as a base one and modify it by using Singularity recipe syntax.

BootStrap: docker
From: biocontainers/fastqc:v0.11.9_cv7

    echo "Welcome to FastQC Image"
    fastqc --version

    echo "Image built"
    sudo singularity build fastqc.sif docker.singularity
The command %runscript would be equivalent to ENTRYPOINT/CMD in Docker. It is only triggered when using singularity run. This is useful if you want to hide from the user the complexity of a command-line path or an included custom script.
There are other bootstraping options, such as debootstrap: https://wiki.debian.org/singularity
It’s possible to sign cryptographically your images, so third parties can verify they are coming from their actual authors. This implies some matters beyond the scope of this course, but you have some details if interested at: https://singularity.hpcng.org/user-docs/3.7/signNverify.html