alt Hacker NewsApptainer: Application Containers for Linux
Comments
Great to see Apptainer getting some attention. It generally excels over other container options (like Docker and Podman) in these scenarios:
- Need to run more than one activity in a single container (this is an anti-pattern in other container technologies)
- HPC (and sometimes college) environments
- Want single-file distribution model (although doesn't support deltas)
- Cryptographically sign a SIF file without an external server
- Robust GPU support
Apptainer and singularity ce are quite common in HPC. While both implementations fork the old singularity project, they are not really identical.
We use singularity in the HPCs (like Leonardo, LUMI, Fugaku, NeSI NZ, Levante) but some devs and researchers have apptainer installed locally.
We found a timezone bug a few days ago in our Python code (matplotlib,xarray,etc.), but that didn't happen with apptainer.
As the code bases are still a bit similar, I could confirm apptainer fixed it but singularity ce was still affected by the bug -- singularity replaces the UTC timezone file by the user's timezone, Helsinki EEST in our case in LUMI HPC.
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.
Flatpak considers to move from OSTree to containers, citing the well-maintained tooling as a major plus point. How would that differ from Apptainers?
I agree with Havoc, the message is unclear: Is Apptainer a replacement for Flatpack on the desktop, or is it targeting the server?
Not a constructive comment, but I find the name "Apptainer" doesn't really work. Rolls funny on the tongue and feels just "wrong" to me.
In my environment, the number one reason Apptainer is used has nothing to do with deployment, isolation, or software availability: it is to work around inode limits.
On our HPC cluster, each user has a quota of inodes on the shared filesystem. This makes installing some software with lots of files problematic (like Anaconda). An Apptainer image is a single file on the filesystem though (basically squashfs) so you can have those with as many files as you want in each.
Installing the same software normally is easy and works fine though, you just exchaust your quota.
If any developers are looking to isolate different dev projects from each other using containers, I wrote a tool for it (using podman), maybe someone finds it useful or can thrash its security.
Find the code on https://github.com/evertheylen/probox or read my blog post on https://evertheylen.eu/p/probox-intro/
It is very handy in SLURM clusters and servers where you have no sudo.
Some attrition using it though: is there a good in-depth book about it?
I have yet to see a container technology that doesn't break a myriad of things.
To some extend I understand the problem that these solution are trying to address, I'm just not sure that simply stuff things into containers is really the right solution.
Perhaps the problems need to be addressed on a more fundamental level.
I tried looking into this, but I do development work on Mac, which is not supported, and so it became a non starter.
Whoever made this is trying to sell something to people who don't know how containers work. The "encryptable" part is giving major snake oil vibes. Is there some clueless administrator somewhere demanding encryption, not really getting what it's for?
Why doesn’t the OS simply provide this by default? I’ve never understood that.
Process isolation should be the default. You should be able to opt out of certain parts of it as required by your application.
This should not be something you add on top of the OS, nor should it be something that configures existing OS functionality for you. Isolation should be the default.
Only MacOS does anything like this out of the box, that I’m aware of, and I’m not sure that it is granular enough for my liking as it is today. I often see apps asking for full disk access or local network access and deny them, because they don’t need those things, they maybe need a subset of it, but I can’t allow a subset of “full disk access” or “local network access” if the application is running as myself.
Very interesting .. I was recently tasked with getting a bespoke AI/ML environment ready to ship/deploy to, what can only be considered, foreign environments .. and this has proven to be quite a hassle, because, of course: python.
So I guess Apptainer is the solution to this use case - anyone had any experience with using it to bundle up an AI/ML application for redistribution? Thoughts/tips?
Honestly switched to systemd isolation features (chroot, ro/rw mounts, etc) and never looked back.
Wish these sort of projects would do a better job articulating what the value proposition is over leading existing ones.
Like why should I put time into learning this instead of rootless podman? Aside from this secret management thing it sounds like same feature set
[flagged]
Argh, yet another way to distribute userland images. AppImages does it right by including the run-time with the image itself - no prior installation needed.
More nix less containers, btw.
E.g. docker run -ti nixery.dev/shell/cowsay bash for on-the-fly containers based on Nix.
We tried to use this on our compute cluster for silicon design/verification. We gave up in the end and just went with the traditional TCL (now Lua) modules.
The problems are:
1. You can't have apptainers that use each other. The most common case was things like Make, GCC, Git etc. If Make is in a different apptainer to GCC then it won't work because as soon as you go into Make then it can't see GCC any more.
2. It doesn't work if any of your output artefacts depend on things inside the container. For example you use your GCC apptainer to compile a program. It appears to work, but when you run it you find it actually linked to something in the apptainer that isn't visible any more. This is also a problem for C headers.
3. We had constant issues with PATH getting messed up so you can't see things outside the apptainer that should have been available.
All in all it was a nice idea but ended up causing way more hassle than it was worth. It was much easier just to use an old OS (RHEL8) and get everything to work directly on that.