Introduction
We offer support for projects to run Linux containers in TSD if requested. Note that this is not a part of the base TSD project configuration, and so project administrators should contact us to request installation.
To facilitate container use, we deploy a special-purpose virtual machine running a container engine that allows project members to run OCI/Docker container images that they import into TSD.
Support level
TSD provides the container platform and the maintenance of it, while projects provide their own container images and are responsible for operating them.
Available container platforms
In TSD we offer Podman and Singularity for running containers.
TSD provides a deployment of the Podman container engine configured to be safe for project use. The container engine will be running as a non-root user and containers will be run in Linux user namespaces, but for the most part this should not differ much from running containers elsewhere in common usage.
The Podman container engine will be installed on a special-purpose containers host that project members can connect to via SSH from the project’s login node.
Unlike Podman, Singularity can be installed on regular project machines if requested. It is also available as a Colossus module for use in HPC jobs. We use the packages provided by the Extra Packages for Enterprise Linux (“EPEL”) project.
Podman
Usage
Podman offers completely a docker compatible command-line interface, as well as a Docker API v1.40 compatible API implementation for controlling the container engine.
Either docker or podman can be used interchangably within TSD when interacting with the container service.
As Internet registries aren’t available on the inside, container images need to be imported manually into TSD, which is documented below. Otherwise, the podman/docker command-line interface can be used in the same way as you normally would.
Examples
Example of running an Alpine 3.14 container interactively with pXXXX/data/no-backup bind mounted to /no-backup:
$ docker run --rm -ti -v /tsd/p1337/data/no-backup:/no-backup docker.io/alpine:3.14
/ # cat /etc/os-release
NAME="Alpine Linux"
ID=alpine
VERSION_ID=3.14.2
PRETTY_NAME="Alpine Linux v3.14"
HOME_URL="https://alpinelinux.org/"
BUG_REPORT_URL="https://bugs.alpinelinux.org/"
/ # id
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),11(floppy),20(dialout),26(tape),27(video)
/ # uname -a > /no-backup/alpine
/ # cat /no-backup/alpine
Linux 946afc425f65 4.18.0-305.19.1.el8_4.x86_64 #1 SMP Tue Sep 7 07:07:31 EDT 2021 x86_64 Linux
/ # ls -l /no-backup/
total 96
-rw-r--r-- 1 root bin 96 Nov 8 14:17 alpine
-rw-r--r-- 1 root bin 14 Nov 2 14:25 newfiles
-rw-r--r-- 1 root bin 22 Oct 29 08:20 test
Example of running an nginx container with host TCP port 8080 redirected to container port 80:
$ docker run -d -p 8080:80 docker.io/library/nginx:1.20.1-alpine
e501d9d4e4253dc9def589d2ec8147aaa661b37b96c58c99872883ed1892b9c8
$ curl http://127.0.0.1:8080
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
body {
width: 35em;
margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif;
}
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>
<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>
<p><em>Thank you for using nginx.</em></p>
</body>
</html>
Importing container images
On the outside of TSD, pull and save a container image you wish to bring into TSD. As an example, we will show how this would be done in the case of nginx version 1.21.3 from Docker Hub:
$ docker pull docker.io/nginx:1.21.3
Trying to pull docker.io/library/nginx:1.21.3...
Getting image source signatures
Copying blob b380bbd43752 skipped: already exists
Copying blob fca7e12d1754 done
Copying blob 1c84ebdff681 done
Copying blob a4723e260b6f done
Copying blob 745ab57616cb done
Copying blob 858292fd2e56 done
Copying config 87a94228f1 done
Writing manifest to image destination
Storing signatures
87a94228f133e2da99cb16d653cd1373c5b4e8689956386c1c12b60a20421a02
$ docker save docker.io/nginx:1.21.3 -o nginx-1.21.3.tar
Getting image source signatures
Copying blob e81bff2725db done
Copying blob 43f4e41372e4 done
Copying blob 788e89a4d186 done
Copying blob f8e880dfc4ef done
Copying blob f7e00b807643 done
Copying blob 9959a332cf6e done
Copying config 87a94228f1 done
Writing manifest to image destination
Storing signatures
You can then go to the TSD Data Portal and upload the prepared tarball into your project’s storage area.
On the inside of TSD, podman load/docker load the container tarball on the project’s container host. In the case of the above prepared nginx image:
$ docker load -i /tsd/pXXXX/data/durable/file-import/pXXXX-member-group/nginx-1.21.3.tar
Getting image source signatures
Copying blob 9959a332cf6e done
Copying blob 43f4e41372e4 done
Copying blob e81bff2725db skipped: already exists
Copying blob 788e89a4d186 done
Copying blob f7e00b807643 done
Copying blob f8e880dfc4ef done
Copying config 87a94228f1 done
Writing manifest to image destination
Storing signatures
Loaded image(s): docker.io/library/nginx:1.21.3
Container building
It’s possible to build container images within TSD, but as you are practically operating in an offline environment, you will not be able to pull arbitrary packages from Internet resources.
We recommend that you build your container images outside of TSD, and import the finalized images using the above instructions.
Container limitations
There are some limitations when running “rootless” containers, but for TSD users the most important caveats to note are:
- Ports below 1024 can’t be bound on the host system (within the containers you can bind any port you want).
- Users in container namespaces do not inherit the group memberships of the user running them. Normally containers are configured to only receive membership in the
pXXXX-member-group. - Network shares can only be bind mounted into a container from the top level (for instance
pXXXX/data/durablecan be mounted, but a directory further down in the hierarchy can not be directly mounted).
Singularity
The most widely used container system for HPC.
Singularity usage
Can be used in TSD as elsewhere, please refer to the upstream documentation.
Singularity limitations
The Singularity modules available in the Colossus module system can not be used on project machines, only in HPC jobs.
If you wish to use Singularity on TSD project hosts, please contact us and let us know which hosts you want it installed on.
Call us
Opening hours are weekdays from 08:30 to 17:00 and Saturdays from 10:00 to 15:00.
Phone number: 22 84 00 04
Book a Zoom meeting
Students and employees can book a Zoom meeting with UiO Helpdesk. Available hours are Tuesday to Thursday between 11:00 and 13:00.
Book a video call