Add overwrite strategy options to config

[CarstenHoyer]

This PR introduces two new configuration options; override_strategy and overwrite.

override_strategy: Can be either 'default' or 'overwrite'. Default does nothing except being explicit. 'Overwrite' overwrites the base config with the override config.

overwrite: If override_strategy is set, this does not apply. Otherwise it will look at all the fields in the overwrite array and again overwrite the base config with the override config.

• Relates to Overriding the set of values when extending the "ports" option. #2260
  Overriding the set of values when extending the "ports" option. #2260 (comment)

Note there is currently no tests, I wanted to just see if there was any interest in this PR first.

[GordonTheTurtle]

Please sign your commits following these rules:
https://github.com/docker/docker/blob/master/CONTRIBUTING.md#sign-your-work
The easiest way to do this is to amend the last commit:

$ git clone -b "override-strategy" git@github.com:CarstenHoyer/compose.git somewhere
$ cd somewhere
$ git commit --amend -s --no-edit
$ git push -f

Ammending updates the existing PR. You DO NOT need to open a new one.

[CarstenHoyer]

It could be made simpler by just including the overwrite option and not the override_strategy option.

I have prepared a branch for that: https://github.com/CarstenHoyer/compose/tree/overwrite

[bharley]

There hasn't been any activity on this in a while, is there any possibility this (or something similar) might make it in?

[fabricionaweb]

+1

[ababushkin]

Any chance this one can get merged (pending the conflict resolution of course)??

This is quite useful for non-trivial multi-container apps.

[CarstenHoyer]

I haven´t gotten any feedback from Docker about this issue. I am ok rewriting it, if you think it should follow some different approach. But it would be nice to hear, if you think the idea in the feature, could be merged at some point.

Thanks

[bluemoehre]

I would also love to have this option.
E.g. if you have lots of containers from different sources, you may run in port conflicts. You won't need to touch or copy the original config if it would be possible to overrwrite the ports instead of extending. This simplifies the container management a lot.

[gligoran]

Any news on this?

[bluemoehre]

I am afraid there was no progress - totally disappointing. Still have to use workarounds.

[vinyll]

Sooo looking forward for this feature.
Maybe a fork of docker-compose if Docker is not willing to merge this nor implement a similar functionality?

[topiaruss]

It's a shame that this has not been merged or resolved.

[codeasone]

This would be a helpful.

[sobolevn]

Totally agree, this solves the ports issue.

[Mobe91]

Will this be merged any time soon?

[pklingem]

@docker there's clearly a community desire for this feature, it'd be nice to know one way or another if it or something similar might be added to docker-compose.

[xenithorb]

@shin- @aanand Is this on your guys' radar? Would really like to see this happen!

[mykola-dev]

it looks like docker-compose is abandoned. we should create a community fork.

[nevergone]

@CarstenHoyer Please write test. Thanks.

[sharksforarms]

Any updates?

[CarstenHoyer]

I am closing this pull request. I am not working with this anymore, so I can't keep it updated or write tests. Please reference this issue in a new request.

[keithy]

Checkout how taurus does their config. Temped to repurpose their code into a docker compose wrapper

[twitchard]

I'm just going to experiment with generating docker-compose.yaml from dhall-lang which can generate yaml easily and has more flexible import and override semantics built-in.

[J7mbo]

Just wondering - why was this ignored by the docker team? No response or anything, is it just not useful and they disagree with it, no time?

[cbrunnkvist]

For now - without the ability to overwrite objects - we instead have to move the ports and other complex objects into yet another file, which we can cascade e.g.:

# docker-compose.yml
...
  some-svc:
    image: xyz:${RELEASE:-latest}
...

# docker-compose.prod.yml
...
  some-svc:
    env:
      - "X=y"
...

# docker-compose.local-ports.yml
...
  some-svc:
    ports:
      - "3000:3000"
...

# docker-compose.ci.yml
...
  some-integration-test-svc:
    ...
...

Generate a "production" (🤷) config to ship somewhere:

COMPOSE_FILE="docker-compose.yml:docker-compose.prod.yml" docker-compose config > docker-compose.${RELEASE}.conf

Run a composition for dev:

COMPOSE_FILE="docker-compose.yml:docker-compose.ports.yml" docker-compose up

Run a composition for some integration test:

COMPOSE_FILE="docker-compose.yml:docker-compose.ports.yml:docker-compose.ci.yml" docker-compose up --build --abort-on-container-exit

Not the end of the world, but a bit annoying.

[mstate]

I wanted to remove ports from my config files when executing in a devcontainer. So, I used fish shell and yq. Hopefully, someone will find this useful.

I added this to a fish config file in my ~/.config/fish/conf.d/ folder:

function config_file
  docker compose -f $THRIVE_SOURCE_DIR/docker-compose.yml -f $THRIVE_SOURCE_DIR/docker-compose.dev.yml config | yq 'del(.services[].ports)' | psub
end

Then, to use it:
docker compose -f (config_file) up -d

[gpetraroli]

For those interested there is a simpler way to achieve this:

• In the docker-compose.yaml create the config without ports mapping
• Create a docker-compose.override.yaml where you configue your ports for dev enviroment for example

At this point when you run docke compose up you have the same container as you would configuring all in the docker-compose.yaml

• For the other enviroments create a docker-compose.override.prod.yaml where you override the ports mapping specifically for that enviroment.

To build the containers run docker compose -f docker-compose.yaml -f docker-compose.override.prod.yaml up

Hope this helps!