Standalone image deployment ?

[gsal]

To registry or not to registry, that is the question.

Hello, everyone: new user, here.

I am getting started with buildah and podman; spent several evenings and got something going.

I have quite a few command-line-based program executables and would like to start replacing them with containerized versions, instead.

I can already work locally, rootless, and use buildah to build an image from scratch with my program executable in it.

I can also launch the container with podman, and execute my program right from the command line...no https://localhost:xxxx, no web access, no server, no daemon, no nothing.

For now, I will spare the reader from my initial, intermediate, and penultimate questions; but, here is my ultimate question(s):
Is it possible to skip the registry, and even the pulling, and simply deploy in-house images of containerized programs to the one central spot in our Linux file system where we deploy all our programs and where all users can access them from directly? How?

Currenty I have bash scripts to launch the programs; take my uglyduck program, for example, minimally the launcher looks like this:

File: /launch/uglyduck.sh

#!/bin/bash
/programs/uglyduck/3.2.1/bin/uglyduck

I would like to let users continue to use the same launcher and simply replace its contents, to something like:

File: /launch/uglyduck.sh

#!/bin/bash
podman run -it --rm --name uglyduck -v ./:/work:Z -w /work uglyduck-3.2.1

[afbjorklund]

https://www.redhat.com/en/blog/expanding-podman-capabilities-deploy-sif-formatted-containers

[afbjorklund]

The main issue with the sif support today (4.4.2), is that it extracts the image every single time.

Instead of mounting it read-only and running it, it will first be converted from squashfs to tar.

$ time ./python.sif python hello.py
Hello, World!

real	0m0,194s
user	0m0,068s
sys	0m0,087s
$ time podman4 run --rm -v $PWD:$PWD -w $PWD -t sif://$PWD/python.sif python hello.py
Getting image source signatures
Copying blob e9918c1ed5d8 done  
Copying config a1074212a9 done  
Writing manifest to image destination
Storing signatures
Hello, World!

real	0m2,102s
user	0m1,772s
sys	0m0,999s

So that makes it less suitable, for running images directly from such a sif file.

With the normal workflow, it would just unpack the image (and layers) once:

$ time podman4 run --rm -v $PWD:$PWD -w $PWD -t python:alpine python hello.py
✔ docker.io/library/python:alpine
Trying to pull docker.io/library/python:alpine...
Getting image source signatures
Copying blob f56be85fc22e done  
Copying blob a24e881083d5 done  
Copying blob ea5757f4b3f8 done  
Copying blob 757892be48e6 done  
Copying blob 9c44c1393ea4 done  
Copying config a43e089276 done  
Writing manifest to image destination
Storing signatures
Hello, World!

real	0m8,308s
user	0m1,865s
sys	0m0,443s
$ time podman4 run --rm -v $PWD:$PWD -w $PWD -t python:alpine python hello.py
Hello, World!

real	0m0,177s
user	0m0,073s
sys	0m0,015s

[gsal]

Thanks for that link pointing to SIF.

Is this the only choice because podman truly does not have anything like it?
What is podman export for? It seems to be able to export images to a directory or tar file, etc. Or,
other that an actual registry, isn't there the concept of library?

Anyway, I did install apptainer and was able to create a standalone *.sif image using one user with its namespace and then turn around and execute that image with a regular user (one without its own namespace).

[gsal]

I did experiment with podman save/export, and I couldn't find a way to run the saved/exported image; I tried the various formats, but no luck.

The command help for save/export was not very usefull, just about said that:
save is good for saving and load is good for loading what you saved with save; and,
export is good for exporting and import is good for importing what you exported with export.

I'm still interested in a pure podman solution, if there is one.
If somebody could share step-by-step instructions.
Not totally familiar with everything or even the lingo, yet, but I think:

• I don't care for a registry
• I could live with the kind of directory like my own $HOME/.local/share/containers/storage
• What is that called? container storage library? image store?
• But, I would need for such image store directory to be read-only , centrally located and not in user's home
• And, of course, my preference would be for the image to be in whatever possible way but in a good old plain directory that does not need to be declared anywhere (think $HOME/.config/containers/storage.conf)

I guess I need to go back and re-read Exploring additional image stores and see if I can get somewhere; but, as mentioned above, it is not quite my preference since such location would need to be recorded in every user's storage.conf file.

[afbjorklund]

It should be possible to use image stores on NFS too, the main difference is if it is a single file or a directory I think ?

The key field we need to focus on in the configuration files is named additionalimagestores. [...] To provide more container image stores, add directories on your local system or mounted from a remote system to this field.

[afbjorklund]

For minikube, a simple local cache directory is used for images. It first tries to load the images, from these tarballs...

The only thing missing is the image digest, since that is only supported with a server. Also there are no image layers.

[gsal]

Ok, additionalimagestores. I guess this does not require any image format conversion, then; but, would require to add this entry in every user's own storage.conf file.
minikube? yet another tool; first time I hear about that one.

[afbjorklund]

minikube? yet another tool; first time I hear about that one.

it's a kubernetes tool, not a podman tool. It uses containers too...

It was just given as an example of a command-line tool, using a caching mechanism to avoid talking to the registry.
There is no global storage, it is just doing the equivalent of a save into the usual cache directory of each user.

[hmoffatt]

Why not podman save to docker-archive or oci-archive format, which you can run directly with podman run docker-archive:xyz.tar? (https://docs.podman.io/en/latest/markdown/podman-run.1.html#image)

I have a need to distribute an image without a repository and make it accessible to multiple local users, and transporting the archive and running it directly looks easier than using additionalimagestores.

[afbjorklund]

You can use the archive format for distribution, you might want to compress it with something like gzip as well, but before you can use it it will need to be copied to an image store. So that's an extra step, before it can run. Matters more for big images.

[hmoffatt]

That manual page says you can run a docker-archive or oci-archive directly from the archive file. It seemed to work for me. It may be slow to unpack a big image every time though.

[afbjorklund]

Currently it (the .tar format) works better than the .sif format, because it recognizes the layers while it is copying them...

Getting image source signatures
Copying blob 6aa872026017 skipped: already exists  
Copying blob b485c6cd33a6 skipped: already exists  
Copying blob ff61a9b258e5 skipped: already exists  
Copying blob 9ec39c52d830 skipped: already exists  
Copying blob b2e5b1eee192 skipped: already exists  
Copying blob 6373bafd92ea skipped: already exists  
Copying blob 619f43313141 skipped: already exists  
Copying blob 43ba18a5eaf8 skipped: already exists  
Copying config 28d8ca9ad9 done  
Writing manifest to image destination
Storing signatures

[hmoffatt]

So podman run oci-archive:... seems to be equivalent to load + run, and load is fast if the image is already in the local store, so this looks good for my purposes.

The only thing missing compared to using a shared additionalimagestore is cleaning up old images, which are going to accrue for each user.

[afbjorklund]

The squashfs mount is still faster, but it is not supported by Podman (only by apptainer/singularity)

But it (.tgz) should be a reasonable workaround, if a regular registry is not available for some reason.

[hmoffatt]

You can use the archive format for distribution, you might want to compress it with something like gzip as well

The oci-archive format seems to be gzipped internally already.

[afbjorklund]

Right, it is the docker-archive that uses tar - which allows you to use better compression like xz if you prefer.