i am changing the basicstation project (lorawan / ttn gateway) from single docker to docker-compose atm and i run into the problem to set service variables for the different containers automaticly. In the original project inside the balena.yml the variables are set this way:
now it moved everything in a sub folder and created a docker-compose.yml and i would love to created service variables (those above for a container named âgatewayâ) and not environment variables like in the example above. Is there a way to achieve this? Or does the user have to create the service variables âby handâ?
This is a great question, but no straightforward answer as such so forgive me for the long reply! The balena.yml file applies to a single or multicontainer application as a whole and is used whenever the âDeploy with balenaâ button is clicked to set up the environment variables automatically. At the moment, thereâs no way to specify within the balena.yml file what service a variable belongs to in order to specify service variables and so they are all added at the application level. This is something we would want to enable in the future for sure, but ultimately youâre right in that today we donât have a way to add these automatically in the same way as the application environment variables. Iâll log this internally to make sure weâre recording your need for the feature.
The application level variables from the balena.yml as you have it above will still apply to the new gateway container youâve created in the multicontainer application, but theyâll also apply to all of the other containers as well. This shouldnât be a problem unless you need to set one of these variables to different values on a per-container basis.
There are options to create the service variables programmatically via the API and I appreciate this may not be of use in the scenario you describe, but Iâm linking here for completeness anyway.
I hope this helps but if not let us know, maybe in a bit more detail and weâll see if we can come up with any other methods to help achieve the same result.
@mpous this is not relevant for us any more. We used to have air-gapped devices that donât connect to the fleet at first deployment. So we wanted a way to set up services with envs without having to have contact to the balena cloud.
