←back to thread

106 points cl3misch | 1 comments | | HN request time: 0.211s | source
Show context
cs_throwaway ◴[] 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 ◴[] 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 ◴[] 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 ◴[] 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 #
jdjcdbxh ◴[] No.44388068[source]
yes, nodes have local disks, but any local filesystem the user can write to is ofen wiped between jobs as the machines are shared resources.

there is also the problem of simply distributing the image and mounting it up. you don't want to waste cluster time at the start of your job pulling down an entire image to every node, then extract the layers -- it is way faster to put a filesystem image in your home directory, then loop mount that image.

replies(1): >>44389930 #
0xbadcafebee ◴[] No.44389930[source]
> yes, nodes have local disks, but any local filesystem the user can write to is ofen wiped between jobs as the machines are shared resources.

This is completely compatible with containerized systems. Immutable images stay in a filesystem directory users have no access to, so there is no need to wipe them. Write-ability within a running container is completely controlled by the admin configuring how the container executes.

> you don't want to waste cluster time at the start of your job pulling down an entire image to every node, then extract the layers -- it is way faster to put a filesystem image in your home directory, then loop mount that image

This is actually less efficient over time as there's a network access tax every time you use the network filesystem. On top that, 1) You don't have to pull the images at execution time, you can pull them immediately as soon as they're pushed to a remote registry, well before your job starts, and 2) Containers use caching layers so that only changed layers need to be pulled; if only 1 file is changed in a new container image layer, you only pull 1 file, not the entire thing.

replies(2): >>44390593 #>>44390605 #
1. o7ri6246iu45 ◴[] No.44390605[source]
the "network tax" is not really a network tax. the network is generally a dedicated storage network using infiniband or roce if you cheap out. the storage network and network storage is generally going to be faster than local nvme.