Open james-nesbitt opened 7 years ago
Actually it appears that the new docker version breaks due to some changes in how docker-compose is expecting to use inter container communications.
There is a push to switch from linking containers explicitly to implicitly including containers in docker networks. The particularr usecases tested use explicit container links.
Warning: The --link flag is a deprecated legacy feature of Docker. It may eventually be removed. Unless you absolutely need to continue using it, we recommend that you use user-defined networks to facilitate communication between two containers instead of using --link. One feature that user-defined networks do not support that you can do with --link is sharing environmental variables between containers. However, you can use other mechanisms such as volumes to share environment variables between > containers in a more controlled way.
https://docs.docker.com/engine/userguide/networking/default_network/dockerlinks/
Additionally, it could be that our decision to use {service}.app
is confusing the linking system, which uses a .
to define that a volume is form another stack. This would be poor string validation, but it is a candidate for failure.
After investigation, it seems clear that network aliases for containers are not being set by libcompose.
I've created an upstream issue to see what I am doing wrong: docker/libcompose#438
This takes over from https://github.com/wunderkraut/radi-cli/issues/36
"Compose Containers do not properly link #36"
When using using a local project with libcompose, the orchestration succeeds, but the resulting containers cannot properly see each other.
The following log entries are recorded: