Not really, as e.g. in the kubernetes domain it’s similar, environment variables are part of configuration, and then the services are redeployed with the new config. for example.
And if the services you use can ingest single line env vars, this “restart” model would work too.
In the balena space the the containers need to be restarted on change so that the container can have the new env vars (as that doesn’t happen dynamically) and internal code running can pick it up.
I understand that it’s all quite confusing, I think the entire industry is creating new mental models to deal with these use cases, so there’s a lot more to come
Yeah, we understood that. Hence our suggestion to do the sidecars + shared volumes + reload signals. But you outlined another viable (pretty generic) pattern and gave suggestion that when you are not using upstream, but make your own project, it would be a good place for that. Haven’t suggested doing that for cases when you use upstream containers unmodified.
Having said that, in practice we rarely see that all services in a solution are upstream. Your setup of prometheus + alertmanager + LoRa can very well be one of them, and in which case have to work with what you have (and sidecar + … approach is possibly viable).
Thus suggest following up as you mentioned before, actually implementing one of these in practice and seeing if it solves your use case.