Over the weekend I’ve done some testing and evaluating of Incus and I’m very pleased with it. I especially like the native OCI support and the obsolescence of having container-host-containers.
I have quite a few containerized services that I use and I’m using the wonderful doco-cd to manage the deployment and lifecycle from a git repo.
So I was wondering how other community members manage the lifecycle and especially updates of your OCI instances.
For me right now an acceptable path might be to utilize incus-compose in combination with ansible, to redeploy on new commits, but I still have to try that.
that keeps instance config/devices and swaps the rootfs from the new image. if app data is on a separate disk device it survives. if its all in rootfs, snapshot first:
-incus snapshot create INSTANCE pre-upd
incus-compose recreate on new commits works too if ur already on that flow.
Let me/us know if you’r using incus-compose with ansible how it works for you!
I have been thinking about a “watchtower” a like project for incus and oci, something that checks the registries for updates and either automatically applies updates or notices us somehow.
Will take some time until I get the time to implement that. Please let me know if someone else does it.
I didn’t really have time to progress with that all that much but I’ve been playing around with incus-compose more and I came across a limitation that I don’t quite understand and I’m hoping that you could give me some insight.
So I tried mounting a path on the remote host I run incus on and stumbled upon the bind-mount restriction:
volumes:
- "/etc/haproxy/certs:/certs:ro"
I understand that volume-seeding is a thing but it’s behaviour, that it only copies the data once and can only be re-seeded by removing the volume, is not really useful in my situation.
So I wanted to ask you why you chose to not include creating bind-mounts on the remote host, as it’s generally possible to do.
