←back to thread

Apptainer: Application Containers for Linux

(apptainer.org)
106 points cl3misch | 3 comments | 26 Jun 25 09:45 UTC | HN request time: 0s | source
Show context
cs_throwaway ◴[26 Jun 25 11:51 UTC] No.44386489[source]▶
Funny this is here. Apptainer is Singularity, described here:

https://journals.plos.org/plosone/article?id=10.1371/journal...

If you ever use a shared cluster at a university or run by the government, Apptainer will be available, and Podman / Docker likely won't be.

In these environments, it is best not to use containers at all, and instead get to know your sysadmin and understand how he expects the cluster to be used.

replies(1): >>44387033 #
shortrounddev2 ◴[26 Jun 25 13:04 UTC] No.44387033[source]▶
Why are docker/podman less common? And why do you say it's better not to use containers? Performance?
replies(1): >>44387172 #
kgxohxkhclhc ◴[26 Jun 25 13:22 UTC] No.44387172[source]▶
docker and podman expect to extract images to disk, then use fancy features like overlayfs, which doesn't work on network filesystems -- and in hpc, most filesystems users can write to persistently are network filesystems.

apptainer images are straight filesystem images with no overlayfs or storage driver magic happening -- just a straight loop mount of a disk image.

this means your container images can now live on your network filesystem.

replies(1): >>44387810 #
0xbadcafebee ◴[26 Jun 25 14:30 UTC] No.44387810[source]▶
Do the compute instances not have hard disks? Because it seems like whoever's running these systems doesn't understand Linux or containers all that well.

If there's a hard disk on the compute nodes, then you just run the container from the remote image registry, and it downloads and extracts it temporarily to disk. No need for a network filesystem.

If the containerized apps want to then work on common/shared files, they can still do that. You just mount the network filesystem on the host, then volume-mount that into the container's runtime. Now the containerized apps can access the network filesystem.

This is standard practice in AWS ECS, where you can mount an EFS filesystem inside your running containers in ECS. (EFS is just NFS, and ECS is just a wrapper around Docker)

replies(3): >>44388068 #>>44388221 #>>44395112 #
NGRhodes ◴[26 Jun 25 15:14 UTC] No.44388221{3}[source]▶
Scale of data we see on our HPC, it is way better performance per £/$ to use Lustre mounted over fast network. Would spend far too much time shifting data otherwise. Local storage should be used for tmp and scratch purposes.
replies(1): >>44388707 #
1. snickerdoodle12 ◴[26 Jun 25 16:05 UTC] No.44388707{4}[source]▶
The docker image is a scratch purpose.
replies(1): >>44389545 #
2. trueismywork ◴[26 Jun 25 17:40 UTC] No.44389545[source]▶
Imagine copying 8gb image to 96000 ranks over network
replies(1): >>44389888 #
3. 0xbadcafebee ◴[26 Jun 25 18:18 UTC] No.44389888[source]▶
It's called caching layers bruv, container images do it. Plus you can stagger registries in a tiered cache per rack/cage/etc. OTOH, constantly re-copying the same executable over and over every time you execute or access it over a network filesystem wastes bandwidth and time, and a network filesystem cache is both inefficient and runs into cache invalidation issues.