View source for Admin Guide Software Container

[[Category:HPC-Admin|Software Container]]<nowiki />
[[Category:HPC.NRW-Best-Practices|Software Container]]<nowiki />
[[Category:Singularity]]<nowiki />
[[Category:Docker]]<nowiki />
{{DISPLAYTITLE:Software Container (Admin Guide)}}<nowiki />

= Comparison of Container Technologies =

{|
!width="11%"|
!width="14%"| Singularity
!width="22%"| Charliecloud
!width="22%"| Docker
!width="19%"| runc
!width="10%"| 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 <ref>https://docs.docker.com/engine/security/rootless/</ref>
| 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
| <code>docker-compose</code>
| 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
|}

= Singularity =

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

== Documentation ==

Can be found on [https://sylabs.io/docs/ this] site.

A set of examples (for the user side) can be found [https://cloud.sylabs.io/home here]

== Sregistry ==

[https://singularityhub.github.io/sregistry/ 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.


= Docker =

== Administrator ==

* Container access for user only as non-root user if possible
* Update your system regularly
* Don’t trust Docker image providers to apply security updates to their images in a timely manner. Check manually for available system updates ''inside'' your Docker containers every 1-2 weeks
* Don’t allow unofficial base-images, i.e. only use images that stem from the software/distribution itself; the packages can be obtained from https://hub.docker.com/ and are labelled “official image”. Unfortunately, the admin has to implement any verification checks themselves - use the official Docker API to verify the images, see https://docs.docker.com/registry/spec/api/
* It’s now possible to use signed images: Content Trust in Docker https://docs.docker.com/engine/security/trust/content_trust/ and Automation with Content Trust https://docs.docker.com/engine/security/trust/trust_automation/
* Limit resource usage if possible - should either be set through the “run” parameter https://docs.docker.com/config/containers/resource_constraints/ or set in the compose files of the specific containers https://docs.docker.com/compose/compose-file/#resources. Setting it for all images through the daemon shouldn’t be the norm.

== User ==

* 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