use '-' as default separator and support of compatibility mode #294
Conversation
Signed-off-by: Guillaume Lours <guillaume.lours@docker.com>
Co-authored-by: Milas Bowman <milasb@gmail.com> Signed-off-by: Guillaume Lours <guillaume.lours@docker.com>
glours
force-pushed
the
use-dash-in-resource-names
branch
from
2f23f04
to
aa0ca5e
Compare
| if utils.StringToBool(options.Environment["COMPOSE_COMPATIBILITY"]) { | ||
| o.Separator = loader.CompatibilitySeparator | ||
| } |
There was a problem hiding this comment.
Please note that this only fixes docker/compose#9618 when passing an environment variable. In the case of Docker Compose getting a --compatibility from the command line I'm not sure that will work (didn't test though).
Given this: https://github.com/docker/compose/blob/v2/cmd/compose/compose.go#L162-L169
Looks like compose just evaluates the command line option after this code is already evaluated.
One solution would be checking the command line option before and setting the EnvVar before calling ProjectFromOptions in the Docker Compose repo for this PR to work properly.
|
Stupid breaking change - duplicates all my networks and returns conflicting ip ranges. reverted to 2.7.0 also because all referred "external" network names changed! Shouldn't that be announced as major change with necessary migration or the explicit use of "COMPOSE_COMPATIBILITY"? Thanks. Peter |
|
Compose v2 automatically changed container names for me when just using |
|
If you want to keep the previous behaviour, use the docker compose --compatibility up -d
[+] Running 5/5
⠿ Network react-express-mongodb_react-express Created 0.1s
⠿ Network react-express-mongodb_express-mongo Created 0.0s
⠿ Container mongo Started 4.8s
⠿ Container backend Started 5.1s
⠿ Container frontend Started |
|
??? i need to ediit ALL of my scripts? |
|
I think the issue here is that --compatibility flag is for compose v1 -> v2 migration, but breaking change (which should have probably been in v2.0) was introduced in a minor release 2.8.0 |
|
You can also use an environment variable for that: Like this you don't have to use |
|
@MrNaif2018 yes you can use it production, End-Of-Life of Compose V1 was announced months ago |
|
I still do think this is absurd. All running environments need to be rebuilt - even with recreation of all volumes. I do understand that the environment variable fixes this. But what other side effects has this, as I'm on v2 for a long time and I don't need compatibility with v1! Me don't like this. It's a minor version release! Please reconsider and make this an opt in. (Even better: if there are existing networks/volumes, leave them alone!) BTW: I'm not against the new separator. - is much better than _. But I don't want to change existing running environments. Quite a few in my case. |
|
@logopk I will rollback the changes and do releases Compose and compose-go |
|
@MrNaif2018 FYI we're rolling back the changes, do be to fast in your volumes migration! |
|
A new release of compose-go available without the breaking changes, a version of Docker Compose should follow soon edit: Compose |
|
@glours Oh I see. I didn't start implementing the migration script luckily. What should my next steps be? I mean I am migrating all deployments from compose v1 to v2 and finished it, but in the meantime when I didn't yet release the changes 2.8.0 release occurred. Ideally in our scripts I would install the latest version of compose v2: https://github.com/bitcartcc/bitcart-docker/blob/dc7de21a1826ede14318701a668956935c64a5d8/helpers.sh#L155-L174 What should my further actions be? Should I prepare that those changes will return back at a later point in compose v2, or they won't? Or they will return but with auto-migration from both compose 1.x and 2.x to the new version like it's done for container re-creation? I'm fine either way, ideally I would migrate all users to v2+ and then no weird bug reports would occur (: |
|
@MrNaif2018 just use |
|
Thank you for the quick response. Much appreciated! |
|
Nevermind I just found your response in docker/compose#9700 (comment), sorry for the disturbance. Compose file: version: '3.8'
services:
app:
build:
context: .
dockerfile: DockerfileVersion 2.9.0 ~/projects/foo ❯ ./docker-compose-2.9.0 --version
Docker Compose version v2.9.0
~/projects/foo ❮ ./docker-compose-2.9.0 --project-name foo_devcontainer -f docker-compose.yml build
[+] Building 0.2s (5/5) FINISHED
=> [internal] load build definition from Dockerfile 0.0s
=> => transferring dockerfile: 31B 0.0s
=> [internal] load .dockerignore 0.0s
=> => transferring context: 2B 0.0s
=> [internal] load metadata for docker.io/library/ubuntu:20.04 0.2s
=> CACHED [1/1] FROM docker.io/library/ubuntu:20.04@sha256:af5efa9c28de78b754777af9b4d850112cad01899a5d37d2617bb94dc63a49aa 0.0s
=> exporting to image 0.0s
=> => exporting layers 0.0s
=> => writing image sha256:b6139e4d50625d70c36fc0232ae66d887f4a58115d9579a989f4490f0a65cf28 0.0s
=> => naming to docker.io/library/foo_devcontainer-app 0.0sVersion 2.8.0 ~/projects/foo ❯ ./docker-compose-2.8.0 --version
Docker Compose version v2.8.0
~/projects/foo ❮ ./docker-compose-2.8.0 --project-name foo_devcontainer -f docker-compose.yml build
[+] Building 0.5s (5/5) FINISHED
=> [internal] load build definition from Dockerfile 0.0s
=> => transferring dockerfile: 31B 0.0s
=> [internal] load .dockerignore 0.0s
=> => transferring context: 2B 0.0s
=> [internal] load metadata for docker.io/library/ubuntu:20.04 0.4s
=> CACHED [1/1] FROM docker.io/library/ubuntu:20.04@sha256:af5efa9c28de78b754777af9b4d850112cad01899a5d37d2617bb94dc63a49aa 0.0s
=> exporting to image 0.0s
=> => exporting layers 0.0s
=> => writing image sha256:b6139e4d50625d70c36fc0232ae66d887f4a58115d9579a989f4490f0a65cf28 0.0s
=> => naming to docker.io/library/foo_devcontainer-app 0.0sVersion 2.7.0 ~/projects/foo ❯ ./docker-compose-2.7.0 --version
Docker Compose version v2.7.0
~/projects/foo ❯ ./docker-compose-2.7.0 --project-name foo_devcontainer -f docker-compose.yml build
[+] Building 0.6s (5/5) FINISHED
=> [internal] load build definition from Dockerfile 0.0s
=> => transferring dockerfile: 31B 0.0s
=> [internal] load .dockerignore 0.0s
=> => transferring context: 2B 0.0s
=> [internal] load metadata for docker.io/library/ubuntu:20.04 0.5s
=> CACHED [1/1] FROM docker.io/library/ubuntu:20.04@sha256:af5efa9c28de78b754777af9b4d850112cad01899a5d37d2617bb94dc63a49aa 0.0s
=> exporting to image 0.0s
=> => exporting layers 0.0s
=> => writing image sha256:b6139e4d50625d70c36fc0232ae66d887f4a58115d9579a989f4490f0a65cf28 0.0s
=> => naming to docker.io/library/foo_devcontainer_app 0.0s |
|
@glours wrote:
Eh ok but the network name can end up in a fully qualified dns name: and at least python is very strict about underscores, leading to Workaround: specify the network name in docker-compose.yml: |
|
You don't realise how much work such changes generate for projects. Mine is a medium-complexity project https://github.com/applied-knowledge-systems/the-pattern/ where deployment is now broken in multiple places. I spent time two years ago making all deployments docker and docker-compose based. Going forward, I will ditch docker-compose and only use docker for builds. Try to reach a point where benchmarks work: https://reference-architecture.ai/docs/bert-qa-benchmarking/ and track the effort required to update all docker-compose files. |
Change the default separator used between project name and resources to
-. This is especially needed for container names to avoid issue with hostname support.Also add detection of the
COMPOSE_COMPATIBILITYenv variable to support the compatibility usage of the_separatorFix docker/compose#9618