5.0 Building your own Containers from scratch¶
In this section we’ll go over the creation of Singularity containers from a recipe file, called
Singularity (equivalent to
5.1 Keep track of downloaded containers¶
By default, Singularity uses a temporary cache to hold Docker tarballs:
$ ls ~/.singularity
You can change these by specifying the location of the cache and temporary directory on your localhost:
$ sudo mkdir tmp $ sudo mkdir scratch $ SINGULARITY_TMPDIR=$PWD/scratch SINGULARITY_CACHEDIR=$PWD/tmp singularity --debug pull --name ubuntu-tmpdir.sif docker://ubuntu
5.2 Building Singularity containers¶
Like Docker, which uses a Dockerfile to build its containers, Singularity uses a file called
When you are building locally, you can name this file whatever you wish, but a better practice is to put it in a directory and name it
Singularity - as this will help later on when developing on Singularity-Hub and GitHub.
Create a container using a custom Singularity file:
$ singularity build ubuntu-latest.sif Singularity
We’ve already covered how you can pull an existing container from Docker Hub, but we can also build a Singularity container from docker using the build command:
$ sudo singularity build --sandbox ubuntu-latest/ docker://ubuntu $ singularity shell --writable ubuntu-latest/ Singularity ubuntu-latest.sif:~> apt-get update
Does it work?
$ sudo singularity shell ubuntu-latest.sif Singularity: Invoking an interactive shell within container... Singularity ubuntu-latest.sif:~> apt-get update
When I try to install software to the image without sudo it is denied, because root is the owner of the container. When I use
sudo I can install software to the container. The software remain 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
$ sudo singularity build ubuntu-latest.sif ubuntu-latest/
Why is creating containers in this way a bad idea?
5.2.1: Exercise (~30 minutes): Create a Singularity file¶
Singularity file can be hosted on Github and will be auto-detected by Singularity-Hub when you set up your container Collection.
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,
shub for Singularity-Hub).
From: selects the tag name.
Bootstrap: shub From: vsoch/hello-world
Pulls a container from Singularity Hub (< v2.6.1)
Using debootstrap with a build that uses a mirror:
BootStrap: debootstrap OSVersion: xenial MirrorURL: http://us.archive.ubuntu.com/ubuntu/
Using a localimage to build:
Bootstrap: localimage From: /path/to/container/file/or/directory
Using CentOS-like container:
Bootstrap: yum OSVersion: 7 MirrorURL: http://mirror.centos.org/centos-7/7/os/x86_64/ Include:yum
Note: to use yum to build a container you should be operating on a RHEL system, or an Ubuntu system with yum installed.
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.
The additional sections of a Singularity file include:
%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
Setting up Singularity file system¶
%help section can be as verbose as you want
Bootstrap: docker From: ubuntu %help This is the container help section.
%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 during %setup
%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.
Example Singularity file¶
Example Singularity file bootstrapping a Docker Ubuntu (16.04) image.
BootStrap: docker From: ubuntu:18.04 %post apt-get -y update apt-get -y install fortune cowsay lolcat %environment export LC_ALL=C export PATH=/usr/games:$PATH %runscript fortune | cowsay | lolcat %labels Maintainer Tyson Swetnam Version v0.1
Build the container:
singularity build cowsay.sif Singularity
Run the container:
singularity run cowsay.sif
If you build a squashfs container, it is immutable (you cannot –writable edit it)