Hi!
Is it possible to include multiple containers in a release but not actually start all of them on device start? I have some complex interactions between containers and for example container A starts container B and C (through mounting the docker socket).
Hi @Oscarthorn, for your use case does it make sense to use depends_on keyword?
Docs are here: Compose file version 2 reference | Docker Documentation
depends_on controls the startup order and I’d suggest using that before looking into more complex control logic that you need to maintain as part of the application.
No unfortunately it does not, it not about the order of startup, we need to be able to start and stop containers dynamically and all of them do not start at device launch. So we need to be able to include containers that do not automatically start. Having everything in one container at starting things from there is also not really feasible since there can be conflicting dependencies between services.
We have it setup like this right now (containers starting other containers) and it works well for our purposes. But I’m evaluating if balena could be a good fit for our product, so that’s why I’m asking.
Hi @Oscarthorn I see. Thanks for the extra context.
As far as I know, docker-compose does not support a method to mark containers that shouldn’t be started automatically.
Checking our internal feature tracking system, I see that couple of our users and team members already raised the same feature request. I added your interest on your behalf and also pinged my teammates who maintain the relevant modules here.
In my opinion, it’s a good ask. I could imagine several scenarios that such a feature would enable. Then I cannot comment when we could work and implement this feature. For sure we will notify you here as we make progress and ask for your feedback.
Having said these, the balena supervisor already offers methods to start and stop containers from another container at demand. Here are the docs that explain how to do it: Interacting with the balena Supervisor - Balena Documentation
Let’s say that you’d like container-A to orchestrate the start/stop of container-B. You could set the restart policy of container-B to no or on-failure (Docker’s docs here). Then you’ll make sure that container-B exits (without failure) when the balena engine starts it automatically. Then using the supervisor API calls I referenced container-A will manage the starts and stops. You could use device tags to orchestrate the whole process. The value of the device tag would imply if a specific container is supposed to be stopped or started. Using the device tags has extra benefits like bringing visibility and control of the container lifetime via the balena dashboard and API (to control / observe container lifetimes from outside of container-A as well).
Let us know if this would work in your case or not.
Hey @Oscarthorn
Just checking if the suggestions made by my colleague were helpful?
Let us know how it goes and if we can help with anything.
Thanks