|
Size: 4513
Comment:
|
Size: 5047
Comment: Feedback von Günter
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 8: | Line 8: |
| It has similarities to Docker but it's security model is specifically engineered to be used in HPC environments and easy integration in managed client environments.<<BR>> | It has similarities to Docker but it's security model is specifically engineered to be used in HPC environments and for easy integration in managed client environments.<<BR>> |
| Line 10: | Line 10: |
| A typical use case is to install a specific software with all its dependencies in order to run the application in a batch job on our [[Services/SLURM|Slurm cluster]]. Providing such dependencies on our managed Linux systems would be time consuming in preparation and maintenance. On the other hand such installations can be quickly done with elevated (sudo or root) privileges in a container.<<BR>> | A typical use case is to install a specific software with the latest tool versions and all its dependencies from third-party repositories in order to run the application in a batch job on our [[Services/SLURM|Slurm cluster]]. Providing such dependencies on our managed Linux systems would be time consuming in preparation and maintenance. On the other hand such installations can be quickly done with elevated (sudo or root) privileges in a container.<<BR>> |
| Line 16: | Line 16: |
| [[https://www.sylabs.io/docs/|The official documentation]] for users is a great starting point to get up and running with Singularity. | [[https://www.sylabs.io/docs/|The official documentation]] for users is a great starting point to get up and running with Singularity.<<BR>> The analogue of a ''Docker file'', a so-called ''Singularity recipe'' or ''Singularity Definition File'' is documented in detail section [[https://sylabs.io/guides/3.7/user-guide/definition_files.html|Definition Files]]. |
| Line 32: | Line 33: |
| The simplest use case is to convert an existing Docker image and run a command inside it. A well made Docker image can be converted without elevated privileges. | The simplest use case is to convert an existing Docker image, run commands inside it and customize it for personal requirements. A well made Docker image can be converted without elevated privileges. |
| Line 35: | Line 36: |
| Directly from Docker Hub: | |
| Line 38: | Line 40: |
| Converting a Docker image stored locally as tar file: {{{ singularity build docker-image.sif docker-archive:///path/to/docker-image.tar }}} |
|
| Line 43: | Line 50: |
| If the command to be executed from the SIF is not found in the SIF's `PATH` variable, it's path needs to be specified explicitely: | If the command to be executed from the SIF is not found in the SIF's `PATH` variable, it's path needs to be specified explicitly: |
| Line 49: | Line 56: |
| === Build your own container === A more complex use case is to install software on a specific Linux distribution with all its dependencies. This is easier with elevated privileges, as available step-by-step guides may be followed. To run Singularity operations as root we provide [[Services/SingularityBuilder|SingularityBuilder]] . |
=== Build your own SIF === A more complex use case is to install software on a specific Linux distribution with all its dependencies. This is easier with elevated privileges, as available step-by-step guides may be followed. To run Singularity operations as user `root` we provide [[Services/SingularityBuilder|SingularityBuilder]] . |
| Line 52: | Line 59: |
=== Build a writeable sandbox to build your own SIF === From the Singularity Library: |
==== Create a writeable sandbox ==== From the Singularity Library, where the example sandbox directory `ubuntu_16.04` is created in the current directory: |
| Line 62: | Line 68: |
| Sandbox directory paths may be relative or absolute paths. | |
| Line 63: | Line 70: |
| ==== Start a Shell in a Sandbox ==== | ==== Start a shell in a sandbox ==== |
| Line 69: | Line 76: |
| === SIF/Sandbox conversions === | ==== Convert a sandbox to a SIF ==== |
| Line 71: | Line 78: |
| ==== Convert a sandbox to a SIF ==== | |
| Line 75: | Line 81: |
| It's also possible to convert a SIF back to a sandbox. | |
| Line 77: | Line 83: |
| It's also possible to convert a SIF back to a sandbox.: | |
| Line 82: | Line 89: |
| ==== Using a GPU ==== | ==== Using GPU resources ==== |
| Line 89: | Line 96: |
| A user's home directory is available per default from a SIF. To be able to access additional storage paths they need to be defined by using the option `--bind`, either by using the same path as on the host: | A user's home directory is available per default from a SIF. To be able to access additional storage paths they need to be defined by using the option `--bind`, either by automatically creating the same path `/scratch/$USER` inside the SIF as it exists on the host: |
| Line 93: | Line 100: |
| or specifying a different path in the SIF: | or mapping a specific path on the host `/scratch/$USER` to a different path `/mnt/$USER` inside the SIF: |
| Line 97: | Line 104: |
== To be documented ? == * Singularity recipes * Convert local Docker image stored as tar file {{{ singularity build --sandbox my_sandbox docker-archive:///path/to/docker-image.tar }}} |
Singularity
This article explains the purpose and use of Singularity.
Description
Singularity is a container system for isolating software and computing environments from the host system. It allows to package software in highly portable and reproducible environments encapsulating all dependencies, including the operating system.
It has similarities to Docker but it's security model is specifically engineered to be used in HPC environments and for easy integration in managed client environments.
A typical use case is to install a specific software with the latest tool versions and all its dependencies from third-party repositories in order to run the application in a batch job on our Slurm cluster. Providing such dependencies on our managed Linux systems would be time consuming in preparation and maintenance. On the other hand such installations can be quickly done with elevated (sudo or root) privileges in a container.
Docker is not secure as it provides a means to gain root access on the host it's running on, therefore we provide Singularity as a secure alternative.
Official documentation
The official documentation for users is a great starting point to get up and running with Singularity.
The analogue of a Docker file, a so-called Singularity recipe or Singularity Definition File is documented in detail section Definition Files.
Concepts
Sandbox: A writeable directory containing the container's directory structure
Singularity Image File (SIF): An immutable container runtime image containing the container's directory structure
SingularityBuilder: A virtual machine to allow Singularity operations with elevated privileges
Image sources
Pre-built SIFs and Docker images are available in the Sylabs Cloud Library or on the Docker hub.
Common use cases
Using a Docker image
The simplest use case is to convert an existing Docker image, run commands inside it and customize it for personal requirements. A well made Docker image can be converted without elevated privileges.
Convert a Docker image to a SIF
Directly from Docker Hub:
singularity build lolcow.sif docker://godlovedc/lolcow
Converting a Docker image stored locally as tar file:
singularity build docker-image.sif docker-archive:///path/to/docker-image.tar
Run a command in a SIF
singularity exec lolcow.sif cowsay "Mooh!"
If the command to be executed from the SIF is not found in the SIF's PATH variable, it's path needs to be specified explicitly:
singularity exec lolcow.sif /usr/games/cowsay "Mooh!"
Build your own SIF
A more complex use case is to install software on a specific Linux distribution with all its dependencies. This is easier with elevated privileges, as available step-by-step guides may be followed. To run Singularity operations as user root we provide SingularityBuilder .
Create a writeable sandbox
From the Singularity Library, where the example sandbox directory ubuntu_16.04 is created in the current directory:
singularity build --sandbox ubuntu_16.04 library://library/default/ubuntu:16.04
Or from the Docker Hub:
singularity build --sandbox ubuntu docker://ubuntu:16.04
Sandbox directory paths may be relative or absolute paths.
Start a shell in a sandbox
To install the software according to an installation guide or as you see fit, start a shell in your sandbox:
singularity shell ubuntu_16.04
Convert a sandbox to a SIF
After a sandbox is set up and tested it can be converted to a SIF:
singularity build my_image.sif my_sandbox
Convert a SIF to a sandbox
It's also possible to convert a SIF back to a sandbox.:
singularity build --sandbox my_sandbox my_image.sif
Running commands from SIFs
Using GPU resources
For software packaged into a SIF which requires access to the GPU resources of its host, the option --nv can be added:
singularity exec --nv lolcow.sif cowsay "Mooh!"
Accessing storage
A user's home directory is available per default from a SIF. To be able to access additional storage paths they need to be defined by using the option --bind, either by automatically creating the same path /scratch/$USER inside the SIF as it exists on the host:
singularity shell --bind /scratch/$USER lolcow.sif
or mapping a specific path on the host /scratch/$USER to a different path /mnt/$USER inside the SIF:
singularity shell --bind /scratch/$USER:/mnt/$USER lolcow.sif