WARNING: The IMAGE_REPO variable is not set. Defaulting to a blank string.
WARNING: The IMAGE_NAME variable is not set. Defaulting to a blank string.
WARNING: The IMAGE_TAG variable is not set. Defaulting to a blank string.
services:
demo:
environment:
IMAGE_NAME: repo
IMAGE_REPO: name
IMAGE_TAG: latest
image: '/:'
restart: on-failure
version: '3.9'
Note the warnings and also the value of services.demo.image. But, also look at services.demo.environment - they are correct values.
The env_file parameter is for defining environment variables inside the running container. It will not be used for variable substitution in your docker-compose.yaml file (as you have seen).
You have two options:
(1) You can run: source image.env before running docker-compose up so that those environment variables are set in your system environment
(2) You can rename image.env to .env and then docker-compose will read them as environment variables to be used for substitution in your docker-compose.yaml file.
I believe fo from your example that you want the second option.
@rofrano indeed, I ended up with option 2. Nevertheless, is there a way to parameterize the compose YAML also? Perhaps, similar to what kustomize does with Kubernetes YAML, etc.?
@nsubrahm Actually in researching this a bit more there is a third option. Instead of renaming image.env to .env you can also tell compose the name of the environment file that you want to use like this:
docker-compose --env-file image.env up
Which, I believe, answers your follow-on question of how to parameterize the compose YAML similar to what kustomize does with Kubernetes YAML. You can have multiple xxx.env files and run docker-compose passing different ones in with the --env-file option to get similar behavior as kustomize.
Thanks, @rofrano. It will be interesting to know, if I can use both the --env-file (for users to edit) and the default .env file (that I do not want to be edited) with non-overlapping variables. Will set-up some experiments.