Our application is currently running services that are not aware of Balena (ie generic services).
Our desire is to configure these services with information about the device context without having to make the service aware of Balena.
A prime example is one service that allows configuration of a “node” id. For consistency across devices it would be ideal to set this to the same value as BALENA_DEVICE_UUID.
The first thought would have been to use docker-compose variable substitution and set:
myservice:
environment:
NODE_ID: ${BALENA_DEVICE_UUID}
Two problems with that:
So on pure speculation I tried adding service / environment variables within the dashboard, with different values (spoiler These don’t work )
- NODE_ID = ${BALENA_DEVICE_UUID}
- NODE_ID =
BALENA_DEVICE_UUID
- NODE_ID = BALENA_DEVICE_UUID
So, two questions.
Is there anything in the roadmap to support his kind of functionality. Emphasising mapping of balena specific information to services which are not balena aware?
Is there an alternative way to achieve this with the current tools?
Hi David, As you discovered the dockercompose variable interpolation is not implements, the reason for that is because the example you have above with $
would pull the env variables from the build context, which is vanilla docker compose usually works, but since our builds and composition is all done on the cloud side it means that it would be looking for those variables in the cloud builders. So we would rather have to implement something like $$
to escape that and have it on land up on the device, but even then, as you noticed these variables are not on the hostOS, so it wouldn’t help you very much.
In the example you sited you should notice that every service/container you run already has the BALENA_DEVICE_UUID
env var injected into it by default so your code should be able to use that already with out having to try put it into the compose.
Thanks for the swift reply Shaun.
I understand I can update the container code to use BALENA_DEVICE_UUID the value. But that is something I’m aiming to avoid if possible.
We’re currently trying to port a number of services onto the balena platform, and the current images and builds have no idea that the variable BALENA_DEVICE_UUID exists.
They do know about NODE_ID though, and I’m trying to discover if there is a way to set NODE_ID=${BALENA_DEVICE_UUID} without having to update the application code.
As a side note. For the moment, I’m achieving this by setting NODE_ID to the UUID value per device, which is fine for testing, but would not be scalable beyond a few devices.
I could script something to update these vars per device via the api, but I think ultimately it would be ideal if this was something the balena supervisor injected at start time. (I’ve just looked into the code base, and it looks like there isn’t a feature like this).
Is it worth making a feature request?
Ah yeah I understand better now. Unfortunately I don’t think that is possible currently. I will check with some linux gurus, perhaps there is a way to escape bash variables in a way that NODE_ID=${BALENA_DEVICE_UUID}
can work, but failing that I think for now you would need to add something like : if BALENA_DEVICE_UUID then NODE_ID=BALENA_DEVICE_UUID
Its definitely worth rasing this as a feature request on the supervisor repo and I can champion it internally for you when it is discussed in our product brainstorms
Thanks. I’ll have a look and try and raise one.
Have added an issue: https://github.com/balena-io/balena-supervisor/issues/1343
Let me know if I need to add anything, or update / tag it. I didn’t see many options.
Looks great David, thanks for getting it submitted.