wunderio / radi-handler-libcompose

LibCompose based handler for radi
0 stars 1 forks source link

LibCompose and Docker 1.13 #1

Open james-nesbitt opened 7 years ago

james-nesbitt commented 7 years ago

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:

[www_1]-->2017/02/10 09:31:03 [error] 5#0: *1 connect() failed (111: Connection refused) while connecting to upstream, client: 172.19.0.1, server: _, request: "GET / HTTP/1.1", upstream: "fastcgi://127.0.53.53:9000", host: "localhost:8081"
[www_1]-->2017/02/10 09:31:16 [info] 5#0: *1 client 172.19.0.1 closed keepalive connection
james-nesbitt commented 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/

james-nesbitt commented 7 years ago

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.

james-nesbitt commented 7 years ago

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