1. Introduction to Introduction to Singularity

2. Introduction Developed at Lawrence Berkeley Labs
Container technology targeted at scientific applications
Focuses on reproducibility and portability

3. Why Singularity When We Have Docker?
Docker is not supported by (all?) HPC systems
Security vulnerabilities of Docker and privilege escalation issues
Docker uses root owned daemons and HPC systems wont allow such processes to be run by normal users

4. Singularity Features Encapsulation of the environment
Package scientific workflows, software, network, and data
Image based containers (single image file)
Files inside image are owned by appropriate users
Users have full control of the their environment
Easy to run scientific applications that use legacy software.
Blocks privilege escalation within the container
To get root access inside container you have to be root outside container

5. Singularity Features (contd.)
Root owned daemon processes not used
User’s job becomes a sub-process of the daemon
Daemon process is outside the reach of resource manager or batch scheduler
MPI supported
Better use of HPC resources

6. Singularity Commands in a Nutshell

7. Singularity Commands singularity create <container_name>
singularity import <container_name> docker://<docker_image_name>
singularity pull docker://<image_name>:<tag>
pull = create + import
Entire image is downloaded instead of multiple layers
singularity shell <container_name>
singularity exec <container_name> <program>
Directly runs a program within container

8. Singularity in Comet and TACC
Tools for automated conversion of Docker images to Singularity containers
Relevant directories are mounted inside singularity: /oasis/projects, /oasis/scratch, etc.
User permissions are maintained
Compatible with most XSEDE systems
Mostly targeted at Comet but can work with other systems too.

9. References