Is there a way to force a start order without sidekicks?
I have 3 containers
primary service with exposed port(s) and initialization for named volume data(!)
a sidekick which just uses the named volume by name or maybe volumes-from (both would fine here…)
a second “sidekick”, but with an exposed port! It have to use the initialized volume data, not an empty volume!
So it would be important that the first / primary container starts up first, before the sidekick (no problem…) or the second “sidekick with exposed port” starts…
I’m not sure I understand exactly what your sidekicks are doing. However, I hope the below helps…
In Docker Compose, you can specify depends_on, which says that one container should start before another. That’s great, except when a container takes a while to start up.
The pattern you are expected to use is to have containers that depend on another gracefully fail and retry until their dependency is correctly in place.
E.g. if one container expects there to be data in a volume that another container must have put there, wrap your ‘start command’ in the first container with a small script that says “while no content; sleep 1”. After that, it starts your app as required. Or, have your “put data in a volume” container write a marker file for the main container to use as a trigger.
I’ve got a setup where I need six or seven events to happen in order. They are all created by Rancher Compose in random order, yet because the dependency checks are working nicely, the whole thing consistently starts up with all tasks completed in order, which is a delight to watch.
@denise thanks. Curiously, it seems that rancher-compose 0.8.2 fails when it sees depends_on, whereas rancher-compose 0.7.2 doesn’t. I hadn’t debugged why that was the case, but you have partially explained it.
I would still suggest you look at coding your app so that it can survive a dependency not being ready yet and wait accordingly. It will make your app far more resilient. If it is too hard to make the app itself do this, is it possible to wrap it in a script that will only start the app when dependencies are in place?
I moved to sidekick and volumes-from to solve it. Should be fine for now.
The second “primary service” could be added by share one volume as named volume.
I had created a catalog with a couple of depends_on, but its not starting the specified order. Also “depends_on” is not showing in the “view config” section deployed stack at all?
We do not support depends_on, and neither does Docker in Swarm mode. It is not a real solution to the problem anyway and leaves you with unhandled pointy-edge cases when failures occur and containers are being replaced. Your services should know how to either wait for their dependencies or exit and be rescheduled to retry.