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.

4.3.1.1 Through registries

4.3.1.1.1 Docker Hub

https://hub.docker.com/r/biocontainers/fastqc

    singularity build fastqc-0.11.9_cv7.sif docker://biocontainers/fastqc:v0.11.9_cv7

4.3.1.1.2 Biocontainers

4.3.1.1.2.1 Via quay.io

https://quay.io/repository/biocontainers/fastqc

    singularity build fastqc-0.11.9.sif docker://quay.io/biocontainers/fastqc:0.11.9--0

4.3.1.1.2.2 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.

4.3.1.1.3 Singularity catalog

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

• https://singularityhub.github.io/singularity-catalog/

4.3.1.2 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:

4.3.3.1 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

%runscript
    echo "Welcome to FastQC Image"
    fastqc --version

%post
    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