-
Notifications
You must be signed in to change notification settings - Fork 112
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
use '-' as default separator and support of compatibility mode #294
use '-' as default separator and support of compatibility mode #294
Conversation
Signed-off-by: Guillaume Lours <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Co-authored-by: Milas Bowman <[email protected]> Signed-off-by: Guillaume Lours <[email protected]>
2f23f04
to
aa0ca5e
Compare
if utils.StringToBool(options.Environment["COMPOSE_COMPATIBILITY"]) { | ||
o.Separator = loader.CompatibilitySeparator | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 |
…esource-names" This reverts commit 56e6c33, reversing changes made to 0ab97a2. Signed-off-by: Guillaume Lours <[email protected]>
@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: Dockerfile Version 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.0s Version 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.0s Version 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_COMPATIBILITY
env variable to support the compatibility usage of the_
separatorFix docker/compose#9618