I am using my homelab to bone up on how to do the day to day feeding and watering of incus images, and I’ve started turning on the auto.update feature. the rebuilding of them seems pretty simple and i am a big fan of this sorta “two or three cmdlines and youre all set” vibe incus has.
I have some questions surrounding order of operations, and how snapshots are handled with regards to updates.
The first thing I noticed was that when i took a snapshot, the underlying image ‘went away’. Super curious why that is and how I can work around it, because while I like the idea of snapshots, the image underneath the container vanishing can be problematic. Is there an intended order of operations here?
Next, I enabled auto.update on all my oci containers. These are things like the unifi controller, sickchill, jellyfin, radarr - little stuff thats not mission critical, but serve as happy little sacrificial goats for this sort of thing. I noticed when I do an ‘incus image list’ i now see an ‘upload date’ on the far right of the list. I am curious if there is an intended way of measuring “did this image just get updated? because if so, run this tiny script, or issue a rebuild command”. At present, I am thinking of creating a wrapper script that just runs at 1am (since the updates happen at midnight?) that checks to see if the image was just updated or not by doing a bunch of text parsing - but I figured I’d ask first to see if there was a more intelligent way of doing it - like if there is some kind of ‘recently updated’ or ‘due for a rebuild’ flag that gets set somewhere when an image gets an update. Is there something I’m missing here, or am I going to have to wonk together some sorta “cut grep sed awk parse this thing and do some math to make a go/nogo decision”?
And lastly, one of these containers was doing some super navel-gazy dumb stuff with s6, and so i had to shell into it with a machete and a blowtorch and deal some damage so that it would start correctly. I am sure that if I rebuild this container I’ve edited, I am going to lose my edits. Is there a way to, i guess, “take the edits i have made to the overlay that is the container, and blindly apply them to a rebuilt/updated version of the same container, from a freshly downloaded image”? or am i stuck writing a bash script that will have to fire upon rebuild to go redo my hatchet jobbery?
The correct way to do this is to build a new image with the fixes applied (e.g. using buildah or docker). Your “hatchet” script would then become part of the Dockerfile used to build this image. You can use the original image as the base layer which you build on top of.
The point of OCI images, after all, is that they are reproducible: what you run is the same everywhere, and exactly the same if you need to blow them away and recreate them.
of course - but not every single oci image gets ported into incus and survives. in those circumstances, there are extra steps, and in this circumstance as I explained, the s6 system in one of the oci images prevented the container from starting up correctly and had to be modified.
incidentally, since youve mentioned dockerfiles, I also recently tried to launch tradenote, a trading/tracking app. The docker file seems to want to create two containers - one for mongo, and one for the webapp. I had spent a few hours twiddling with various manual efforts, and then tried incus-compose, which being in its early phases of development, didnt’ really seem to help much. If you have some incantations available that could help grease the skids of using compose files to create new containers, I’m all ears.
A Dockerfile is for building container images. How you deploy them is separate from that.
Personally, on the occasions when I need Docker containers, I just run docker.io inside an incus container, with:
incus config set <foo> security.nesting=true \
security.syscalls.intercept.mknod=true \
security.syscalls.intercept.setxattr=true
(or inside a VM). This avoids having to deal with the subtle differences in how containers run under incus and docker.
I’m actually running 6.0.4 mostly, but I don’t think the incus OCI support uses a union filesystem like docker, so capturing the differences that you’ve made would be hard.
my intention is to expressly avoid using docker, so I wont be installing docker inside of incus to solve this problem. I am looking for a solution that doesnt require docker at all for this one.
reading the docker file to understand what kind of instances are created
now create each instance the same way on incus
The tedious part is adding all required env variables and adding persistent storage volumes.
After this has been deployed successful updating each OCI container is pretty much straight forward. This approach comes with another advantage where you can reuse things like databases or redis with multiple stacks to save resources but adds more dependencies.
OCI support is still in early stages and projects like Incus-Compose will make it simpler to deploy. For now it is rather manually but all do able.
In regarding to S6 I haven’t had any issues with recent Incus releases. In case you need to add some additional steps I think you can add (mount) a custom script. Take a look at this thread Incus proxy bind to host address issue - #9 by osch to get ideas what is now possible to avoid tinkering with OCI init scripts.
