Thanks for your patience! After discussing it thoroughly and testing on devices, I believe we have some good options for this specific case (and at the end, we discuss why this issue has not come up before, or doesn’t appear to have come up, from searching the forums).
Idea 1:
Do a kind of inverse of what you describe: Have the services optionally stop themselves on start after checking the env var, no need for a third manager service or interfacing with balena engine, etc. You should have restart: "no" in the service definition in docker-compose.yml, something like this:
version: '2'
services:
kiosk:
restart: "no"
build: ./kiosk
sensor:
restart: "no"
build: ./sensor
and then in the service, you’d have, top level in the entrypoint script (say we were using nodejs):
if (process.env['IS_SENSOR']) {
// code to run service ...
} else {
console.log('sensor not starting, did not find env var');
}
Idea 2:
Of course if you wanted to make a manager service for the sake of more control (I don’t know whether this is useful to you as you go on, or whether the simplest solution is best), you could take a look at the supervisor API [1].
Idea 3:
A final option is simply to deploy two separate applications. This would save the unused disk-space / network bandwidth of downloading and storing container images which won’t run. I would use a setup like you requested initially only in the case that I wanted to swap a device between sensor and kiosk mode in the field. If it’s determined when they’re shipped, then better to simply separate at the layer of application. This is the most common pattern and likely is used for this reason in preference to runtime “polymorphism”.
Let us know if you have any questions subsequent on this! We’ll be glad to assist.
[1] https://github.com/balena-io/balena-supervisor/blob/master/docs/API.md#service-actions