Incus has no concept of health checks like docker does, which complicates things like zero-downtime deployments.
@stgraber Would adding a health check concept for Incus be something that you could see as in scope for Incus in the future, or do you envision this being handled outside of Incus? I personally like the concept of having it in Incus myself, but I’m still getting my feet wet here.
We do have a mechanism that instances can use to report back their readiness, but that’s not likely to get much support from regular OCI images.
We offer a guest facing API through /dev/incus/sock which allows an instance to flip its status between RUNNING
and READY
. The intent is for READY
to then be the state you’re looking for in the API when getting the list of targets for a reverse proxy or the like.
There also are some vague plans to allow delaying things like advertising of BGP routes until an instance has reached READY
state, basically avoiding any traffic from being pushed to it until the service is ready.
Interesting, I wasn’t aware of this api. So if we wanted feature parity with docker’s health checks we could create a health proxy service that performs the docker style checks (is mysql listening on port 3306, etc) and then update the guest status with the incus api.
There are a lot of variations on the health checks Docker allows, but it doesn’t seem to be complicated work, just time consuming.
Hello bketelson,
Is there a how-to for the “installation” and maybe a mapping what is working with incus compose and what is not working?
I compiled incus-compose on another machine and scp’ed it to my incus server. But that seems not to work, as i get always a warning, that something is not implement without any further information.
My plan was, to write write special dockerfiles that hopefully get used by incus-compose (e.g. s6-init) when i define that in the composefile and to config the containers with my predefined files, profiles and environment vars… for easily deploying my used images.
But at the moment im stuck with that warning.
Looking forward to your feedback.
BR Jan
just used incus-compose up… it’s working now
Hi bketelsen,
is there a way to do something like this:
# - frigate_storage:/media/frigate
- type: disk
source: default_frigate_storage
target: /media/frigate
x-incus-shift: true
networks:
eno1:
external: true
volumes:
frigate_storage:
driver: incus
driver_opts:
pool: storage_ext
My goal is to add an existing storage volume to the container.
Looking forward to your feedback.
Best regards
Jan
I don’t think that would work today, can you file an issue to track the request?