today I was wondering if there is an equivalent to docker compose dependencies. Found a post from Sep 2022 Container dependencies and a bug filed Instance auto start dependencies At that time no OCI images have been on the radar and as such not really relevant?
I’m aware about the autostart options and they might work but wouldn’t it be great to have a feature like this? Quiet a few docker-compose solutions are a full stack of different OCI images depending on each other. In most cases if there is a database required or similar.
I have no idea how it is implemented in Docker if one start the other etc.
Having kind of an option to block one container from starting until the required is started would be great and kind of avoids finding out the right timing for autostart params…
Under Incus container startup, as far as what we control takes maybe 200-500ms per container.
So there’s little point in ordering things given that even if you have 100+ containers, they’ll all be started within a minute.
Incus doesn’t know what service you’re trying to expose from that container nor how to test for that service to be available which is probably what you’d actually be interested in when setting up dependencies between containers.
In general, having the various containers know to retry when an external service isn’t available tends to be the better approach anyway. It means that on startup they will just wait for each other and start when ready, but also that when one of those services goes down later on for maintenance, the others won’t just crash but will instead properly handle the service coming back later.
Thanks for the detailed explanation @stgraber, makes total sense to me now.
It just confirms again there is a huge difference architecture wise between Incus and all the other virtualisation’s. Each has it’s own pros / cons why they have certain features or configurations. Sometimes you just need a second thought why things are designed as they are.
I’m not sure that there is that much difference in this instance.
As far as I know, there is no service checking/tracking within Docker either.
So Docker must be assuming that having started the container means it’s operational, which really isn’t guaranteed, especially with more complex containers where the entry point is a small init system which then starts a lot of other processes which eventually become able to process user requests.
I have some application containers at home which will commonly take 1-2 minutes before they start responding and I had the same behavior back when they were being run under Docker.