-
Notifications
You must be signed in to change notification settings - Fork 31
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
Cannot connect to named external network #35
Conversation
After more thorough investigation, tried to reproduced a closer behaviour to native docker compose CLI
@apocas Without this PR #35 in the context of the external network, a new network is created without being necessary. Please help us with this PR to fix this situation. Thank you! |
@adora-tech i guess there is always a default network for each compose as default!? otherwise you need to do something like that: networks:
default:
external: true
name: none |
https://docs.docker.com/compose/networking/
|
Hello, I'm not an expert in Docker, but while testing with dockerode-compose and docker compose cli, I noticed some differences. You may be right, the expectations are that dockerode-compose and docker compose cli using the same docker-compose.yml file will broadly have the same behavior.
In my case, the file has the following content:
and without this PR, an additional network is created, with name Considering the above, this additional network should not be created. Thank you, |
"app" depends on "db": why you need an extra network (external defined from the compose file)? all containers in the compose file can natively communicate with each other via the default network (and via container names which is nice) as mentioned in my comment above! |
Again, you may be right, but I choose to use more networks(one for each container), this is my choise ... Disable inter-container communication The architecture is much more complex and I use a reverse proxy in front of the containers ... That's all |
tbh, i just try to understand your use-case... i actually dont know the reason why this PR has been closed... maybe i can help with another PR to prevent the creation of the default network... but my assumption is its more an issue with the services.js/serviceTools.js not with the network.js edit: |
Hi @AndreasHeine , Sorry for not noticing your input here! Unfortunately I closed this PR, because I really needed to move forward and I wasn't getting any responses from a maintainer, so I forked and went on. Today, I took the time to see if I still needed to keep up my fork and doing so, I stumbled on your merged PR. As I'm try to figure out if we fix the exact same use case, I know my stuff has evolve too, so I will drop my fork and go back to using and contributing to this current repo. Thanks a lot for your work here! |
Cannot connect to named external network Use fix from this issue apocas#35
Since external networks aren't pushed into the
networks
array, when a service container tries to find this particular network to connect to, the network isundefined
.