Software Container (Admin Guide)

From HPC Wiki
Admin Guide Software Container
Jump to navigation Jump to search

Comparison of Container Technologies

Singularity Charliecloud Docker runc Podman
Default configuration suid root unprivileged Daemon (running with root rights) configuration needed unprivileged
not clear if unprivileged is possible yes, but limited functionality only unprivileged yes [1] yes, but with limitations yes
Image files? only with root no internal storage (various backends) no no
flat containers yes yes no yes yes
User Namespaces optional yes optional yes yes
Isolation mount, PID, opt. networking mount freely configurable freely configurable freely configurable
Creation of Containers yes yes (various builders) yes no yes
SL6-compatibility yes neo yes no unclear
“Composing” no no docker-compose no yes
Goals Docker usage for HPC user software stack for HPC, high-quiality Code industry-standard, encapsulation of services standardized container runtime OCI drop-in replacement for Docker, frontend for OCI Runtimes and Builder


General - About singularity

  • singularity is an hpc-friendly alternative to docker (and other container systems) because it
    • does not run a root daemon
    • does not fully containerize the software running
  • can be installed without root access (though not generally recommended due to limited functionality)
  • (The devs claim) the source has been reviewed by several renowned insitutions (MIT, etc) in search of security problems, and never found anything.

Admin side

  • Singularity needs to be installed on a drive that is mounted with SUID enabled. In the future there will be options available to use capability sets but for now this seems fairly limited.
    • It can be used without SUID, instead using namespaces, but this limits the container types to be used to sandbox containers (no images (.sif etc.) usable)
  • Best install using the package manager (singularity can be found on rhe, centOS and ubuntu using a ppa) in order to update alongside the system packages.
  • Singularity supports the option to limit usage to user groups (like docker) which can be handy for security.

User side

  • Use trusted images preferably
  • Build images before running them using the queuing systems.


Can be found on this site.

A set of examples (for the user side) can be found here


Sregistry is a service that is easily deployable using docker, which acts as a hub for storing and sharing singularity images on the local (cluster) network. If you find yourself sharing lots of containers or sharing lots of build pipelines with your colleagues, it might be easier to deploy an sregistry server.




  • Don’t use unofficial base-images/Don’t run untrusted container images
  • use /latest instead of fixed versions
  • use content trusted/signed images when possible