I am experimenting with Toolbox for development, and i found this thread about updating containers:
The thread advises that containers should normally not be updated locally, but by updating the image. I was left with a few questions.
As a test, i updated the image per the example in the thread. I started with this scenario, using a container i created a week ago:
IMAGE ID IMAGE NAME CREATED
37e09d63198d registry.fedoraproject.org/fedora-toolbox:41 8 days ago
CONTAINER ID CONTAINER NAME CREATED STATUS IMAGE NAME
c6e9070965ec fedora-toolbox-41 8 days ago exited registry.fedoraproject.org/fedora-toolbox:41
IMAGE ID IMAGE NAME CREATED
37e09d63198d <none> 8 days ago
82594d42ea61 registry.fedoraproject.org/fedora-toolbox:41 6 hours ago
CONTAINER ID CONTAINER NAME CREATED STATUS IMAGE NAME
c6e9070965ec fedora-toolbox-41 8 days ago exited registry.fedoraproject.org/fedora-toolbox:41
It seems the earlier image has been unregistered, for lack of a better word. But i have the feeling this doesnāt mean that the deployed container is now using the new image, or is it? How do i determine that?
There doesnāt appear to be a ātoolbox upgradeā command, only create, enter and list.
So while i updated the image (using podman) in my previous post, i have the feeling that the container is still based on the original image. But iām not sure if that is the case.
One thing i do notice is that when i enter the container, software i installed inside the container earlier like nodejs is still available.
How would installed apps stay intact inside the container while the base image was updated? I guess this same question would apply to containers created with Distrobox.
[Update] Yes it appears that updating the image with Toolbox doesnāt update the container although it unregisters the original image. This doesnāt seem an ideal way to update containers:
$ toolbox list
IMAGE ID IMAGE NAME CREATED
37e09d63198d <none> 8 days ago
82594d42ea61 registry.fedoraproject.org/fedora-toolbox:41 8 hours ago
CONTAINER ID CONTAINER NAME CREATED STATUS IMAGE NAME
c6e9070965ec fedora-toolbox-41 8 days ago exited registry.fedoraproject.org/fedora-toolbox:41
$ podman image rm 37e09d63198d
Error: image used by c6e9070965ec2444fba2a5a612201e33c5d883f2016b415d9559e7c4472c3405: image is in use by a container: consider listing external containers and force-removing image
From my modest experience with Toolbox/Podman containers, installing packages inside a container is not the same as layering a package on an RPM-OStree deployment. I donāt think there is a record of the packages installed/removed/upgraded, and diffs made between base images, in order to be able to deploy new images for existing containers.
The command podman container inspect c6e9070965ec | grep '"Image"' will probably show the old image ID.
Right, i think so too. Then the question becomes what the best approach is to update files in a container?
When issuing a dnf update from within a container this will give a lot of permission denied errors for core files and scripts than cannot be upgraded. At the same time, only updating the image, which was marked as the solution in the earlier thread, doesnāt update any deployed containers.
Perhaps this is a shortcoming of the toolbox command, and distrobox solves this through itās distrobox upgrade command(?). I will test that out as well to be sure.
Lacking official documentation regarding how to upgrade Toolbx container images, Iāve always used sudo dnf upgrade --refresh commands, and ignored the errors. But I donāt use containers for production purposes, so no issues here.
Others might be considering containers as static snapshots, and donāt even want/need to upgrade, but rather create new containers when needed.
I intend to use them for programming, so what i would like to avoid is having to install all the development tools again (weekly?) after creating a new container. Iām not entirely sure yet what the best approach would be for this.
āi would like to avoid is having to install all the development tools again (weekly?) after creating a new containerā
I donāt know whether the following is the BEST approach for your development container, but I can describe the approach I find useful for my development containers. I suspect the key detail to keep in mind here is that there is an important difference between local container instances versus container images.
I āinstallā all my development tools at least tens of times a year, not into local containers instances, but rather into container images using podman build (and/or buildah).
I have multiple Containerfile (aka Dockerfile) for slightly different development and testing scenarios. Tens of times a year I create new container images and then create new local container instances and then rename and eventually delete old local containers instances. I only do ādnf installā and other tweaks inside my local container instances sparingly; like when I try out a new tool or quickly test that something works/breaks. Anything that I want setup for the long term I put in a Containerfile for the next image re-build and container re-creation. I only do ādnf updateā inside a Containerfile and never inside a local container instance.
Because I have all the installation instructions in a Containerfile, itās really not hard to install all the dev tools again and again.
You use podman build (or buildah) to build images. To create and run images, you use a variety of tools. toolbx makes it easy to create and run containers and not think about the details. But you can use podman/buidlah directly (or make your own scripts to call them). You can learn more at https://cnest.readthedocs.io Feel free to ask me questions and/or provide feedback on that site.
If you want to see or re-use some of my development container images just let me know.
Toolbx/Distrobox are not using containers the traditional way.
Normally, all state of containers is meant to be in a compose file, and the containers are used as appliances and not a mutable environment.
With toolbx/distrobox, the moment you use them to actually install a package, the state is changed and you cannot normally update them, at least not without losing all the state you have manually changed (like a dnf install a b c).
Distrobox has support for compose files, where you can regenerate a box like containers normally work.
Alternatively, use a rolling distro inside the container (Debian testing, Arch, OpenSUSE tumbleweed, OpenSUSE slowroll, fedora rawhide) and only use package managers inside the mutable environment.
distrobox upgrade --all makes this easy too (by entering every container and invoking itās package manager), toolbx has nothing to automate this.
Thanks Castedo, that approach seems useful for deploying static containers or appliances (as they are named below).
Like you mention there would be a few downsides in relation to using a toolbox container as a mutable environment, where you install and tweaks apps along the way, since redeploying new containers means starting from scratch with a vanilla environment. It would involve more steps and take more time to redeploy and install new containers instead of issuing a simple āupdateā command. Iām not sure if this approach would fit my intended goal the best.
Right, this was the point that i had more or less reached as well. I do like the mutable aspect and i would ideally use a container for a number of months (or more), only upgrading packages along the way. Toolbox seems to not fully support this approach well at this point, but perhaps distrobox is a bit more advanced in this respect.
I would not call the cnest āpersonal multisession containersā approach static containers or appliances. I tweak and change my āpersonal multisessionā container instances because they are mutable. I just donāt plan on those tweaks and changes to the container instance to stick around for the long-term (a year). Changes I want for the long-term go into a Containerfile that I commit to git.
Unlike āapplianceā containers, I find mutable container instances very useful for development. When I want to tweak them, I can. If I want them to remain ācleanā then I donāt tweak them. It depends on the situation.
Instead of one simple āupdateā command, I essentially do the three steps below. This example assumes your dev container instance is named mydevbox, you call your dev container image mydevimg, and you save your dev stuff in ~/dev.