I find docker compose override files whilst powerful ultimately much more confusing and error prone to work with. Instead I would recommend just duplicating your compose files and changing each separately, perhaps using a templating engine. It is often much easier to work with a single compose file containing all the config in one easy to read block. This compared to having to do a yaml merge of all the various blocks in your head whilst reasoning about override files.
Similarly yaml anchors are cool and can easily reduce duplication in your files. However I've found the majority of Devs and users find them confusing and unexpected in a compose file. As a result I would recommend not using them and just sticking with plain yaml for simplicity's sake and not being afraid of duplication.
One other alternative to yaml anchors is instead using the env_file: property on your services (https://docs.docker.com/compose/environment-variables/#the-e...) . This way you can place all of your env variables in a single file and share this same of env variables between many services without having to have large duplicate env blocks in your compose file.
I usually suggest passing `--env-file` to the actual compose binary. Gives you the "multiple deployment versions" without faffing about with external templating tools.
docker compose --env-file ${INSTANCE}.env -f docker-compose.yml up
services:
service-1:
# you need to be more explicit here
environment:
SOME_NAME_FOR_A: "${CONF_A_VALUE:?err}"
SOME_NAME_FOR_B: "${CONF_B_VALUE:?err}"
# but it gives you simple templating in other places
labels:
com.company.name.label.a: ${CONF_D_VALUE:?err}
com.company.name.label.b: ${CONF_E_VALUE:?err}
com.company.name.label.c: ${CONF_F_VALUE:?err}
ports:
- "${CONF_G_VALUE:?err}:8020"
service-2:
# also gives services more freedom to diverge from one another (if required)
environment:
MAYBE_ANOTHER_NAME_FOR_A_BECAUSE_COWBOY_TEAM_REASONS: "${CONF_A_VALUE:?err}"
SOME_NAME_FOR_C: "${CONF_C_VALUE:?err}"
Similarly yaml anchors are cool and can easily reduce duplication in your files. However I've found the majority of Devs and users find them confusing and unexpected in a compose file. As a result I would recommend not using them and just sticking with plain yaml for simplicity's sake and not being afraid of duplication.
One other alternative to yaml anchors is instead using the env_file: property on your services (https://docs.docker.com/compose/environment-variables/#the-e...) . This way you can place all of your env variables in a single file and share this same of env variables between many services without having to have large duplicate env blocks in your compose file.