I’m trying to write a script that will (as much as possible) automate the process of converting our docker-compose.yml file into a docker-compose file that can work on top of BalenaCloud. The issue with this is that BalenaCloud works with a smaller feature-set than native docker-compose, meaning that all environment variables (we use a lot of them, and we use the different kinds of substitutions like errors and default values etc) will have to be normalized before submitted to BalenaCloud.
I read up about docker-compose config with the --env-file option, and that does normalize the environment variables as needed. The issue seems to be that it also provides (as the documentation suggests) a much more granular docker-compose file, the directives of which are not accepted by the balena CLI.
Is there any other alternative to normalize docker-compose environment variables found in a docker-compose.yml file?
By normalizing I mean converting ${USER_PASSWORD:-secret} to secret depending on its presence on the environment variable file, or any kind of environment variable directive, when an environment variable file is passed.
I tried using docker compose config but the issue is that it also converts other directives into more precise directives:
It has many subshells. Maybe it could be optimized. It is based on the fact that a simple shell can interpret the syntax and if it is converted to an “echo” command, you just need to “eval” it.
I got some ideas from this post:
but my original idea came from here:
where I didn’t read all the comments, so you could read it hoping you find something useful.
You could try if the output of docker compose config can be piped into composeverter somehow to convert it back to the short syntax. I assume it provides a cli interface with the same functionality as https://www.composeverter.com.
This could also be a nice feature request for docker compose actually.
There is a --no-normalization argument for docker compose config, but I have no idea what it does, and somehow fail to see a difference in the output.
--no-normalize removes some defaults like the network definition for a service when it is not defined in the file. It could also throw an error without --no-consistency when the default network is listed in the service block, but not in the top-level network block, which seems like a bug.