We have an application that has differences in the containers deployed between different groups of devices.
These differences consist of more than just environment variables within the container, but instead vary the version of the container used and in some cases, require extra containers to be deployed.
The fundamental goals of the application remain the same in all its diversity, and the majority of the application is always the same. The difference could be a desire to use pre-built containers with specific ML model variations embedded, for example.
At the moment, the only way I can see to manage this diversity is to have every different permutation hardcoded and set to its own specific application in Balena.
Is there any way to put conditional logic into the docker-compose to drive the version of the container itself?
I see contracts and io.balena.features.optional can be used to drop containers altogether in certain circumstances, but the contract types are very specific and can’t be driven by things such as device variables.
Any suggestions or guidance is appreciated! Thanks
I think I would opt to adjust the application to make all these aspects configurable.
To take your ML model example. I would maybe separate them out so the application can download them from some place on (first) startup. You can then configure the correct model in an environment variable, maybe with a default value, so only the exceptions need to be confgured explicitly.
Hey. This seems to resemble software refactoring a bit, doesn’t it?
If the devices do a fundamentally different job, then it might make sense to arrange them as different applications.
Otherwise, as the previous comment says, you might want to make the unique aspects configurable within the application itself (using the environment variables).
There are container contracts for very specific use cases but the docker-compose natively does not support conditional statements AFAIK.
Yes, it is looking like we will need to refactor aspects to make them runtime configurable rather than having aspects embedded in containers. The applications are not fundamentally different, but we have embedded some configurable components within the containers at build time (rather than managing things like distribution outside of docker). I think there are valid use cases for container level differences between versions of the same app (Balena use docker templates to deal with architecture specific configs of the same app), but I understand the difficulty in this general situation.
I am not aware of anything natively in docker-compose either, but guess was reaching a bit for any potential handling from Balena that would allow us to configure at a higher level than just container environment variables, or perhaps a means for extending contracts for custom optionality.
Thanks