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

All network links not available when using docker-compose run #4052

Closed
johanbrandhorst opened this Issue Oct 21, 2016 · 13 comments

Comments

Projects
None yet
8 participants
@johanbrandhorst

johanbrandhorst commented Oct 21, 2016

Hi,

It appears that when using docker-compose run --rm --service-ports master where my master container depends on another container, which itself needs a network connection with the master container, the last connection is not created. It appears network connections are only made available for explicit dependencies (using depends_on), and only one-way.

Note that when use with docker-compose up all expected network connections are created.

Here is an example docker-compose (v2) which when used with docker-compose run master creates a network from master to slave, but not from slave to master.

version: '2'
networks:
    internal:
        driver: bridge
services:
    slave:
        command: "ash -c 'sleep 1; ping master'"
        image: busybox
        networks:
            - internal
    master:
        command: "ping slave"
        depends_on:
            - slave
        image: busybox
        networks:
            - internal

When this is run with docker-compose up:

$ docker-compose up                                                                                                                                  
Creating network "my_internal" with driver "bridge"                                                                                                                    
Creating my_slave_1                                                                                                                                                    
Creating my_master_1                                                                                                                                                   
Attaching to my_slave_1, my_master_1                                                                                                                                
master_1  | PING slave (172.19.0.2): 56 data bytes                                                                                                                        
master_1  | 64 bytes from 172.19.0.2: seq=0 ttl=64 time=0.064 ms                                                                                                          
slave_1   | PING master (172.19.0.3): 56 data bytes                                                                                                                       
slave_1   | 64 bytes from 172.19.0.3: seq=0 ttl=64 time=0.146 ms                                                                                                          
master_1  | 64 bytes from 172.19.0.2: seq=1 ttl=64 time=0.126 ms                                                                                                          
slave_1   | 64 bytes from 172.19.0.3: seq=1 ttl=64 time=0.127 ms                                                                                                          
master_1  | 64 bytes from 172.19.0.2: seq=2 ttl=64 time=0.143 ms                                                                                                          
slave_1   | 64 bytes from 172.19.0.3: seq=2 ttl=64 time=0.153 ms                                                                                                          
master_1  | 64 bytes from 172.19.0.2: seq=3 ttl=64 time=0.058 ms                                                                                                          
slave_1   | 64 bytes from 172.19.0.3: seq=3 ttl=64 time=0.130 ms                                                                                                          
master_1  | 64 bytes from 172.19.0.2: seq=4 ttl=64 time=0.157 ms                                                                                                          
slave_1   | 64 bytes from 172.19.0.3: seq=4 ttl=64 time=0.142 ms
^CGracefully stopping... (press Ctrl+C again to force)                                                                                                                    
Stopping my_master_1 ... done                                                                                                                                          
Stopping my_slave_1 ... done 

Same thing run with docker-compose run --rm --service-ports master:

$ docker-compose run --rm --service-ports master                                                                                                     
Creating network "my_internal" with driver "bridge"                                                                                                                    
Creating my_slave_1                                                                                                                                                    
PING slave (172.19.0.2): 56 data bytes                                                                                                                                    
64 bytes from 172.19.0.2: seq=0 ttl=64 time=0.090 ms                                                                                                                      
^C                                                                                                                                                                        
--- slave ping statistics ---                                                                                                                                             
26 packets transmitted, 1 packets received, 96% packet loss                                                                                                               
round-trip min/avg/max = 0.090/0.090/0.090 ms                                                                                                                             
$ docker logs my_slave_1                                                                                                                          
ping: bad address 'master'   

Obviously I can't create dependency cycles using depends_on or links. Is there any way to get the expected result with docker-compose run?

@johnculviner

This comment has been minimized.

johnculviner commented Dec 31, 2016

Experiencing the same issue here. Not sure if there is a way around this but this is totally killing my CI/CD Karma + Selenium plans for Docker....

@johanbrandhorst

This comment has been minimized.

johanbrandhorst commented Jan 18, 2017

@johnculviner the workaround is to run something like

docker-compose up -d
while [[ $(docker inspect -f '{{.State.Running}}' <container_name>) != "false" ]]; do
    echo "Waiting for job to finish";
    sleep 2;
done
exit $(docker inspect -f '{{.State.ExitCode}}' <container_name>)
@johnculviner

This comment has been minimized.

johnculviner commented Jan 19, 2017

@johanbrandhorst thanks for that! I ended up going this route which worked great for isolated bi-directional container communication (required for certain types of selenium tests). Each container is addressable within the container via DNS which is just their respective container names. Hope this helps someone setup something similar:

version: '2'
services:
  my-app-under-test:
    image: my-app-image
    networks:
      - my-app-bridge
    command: "sleep infinity" #keeps the container alive for 2 way networking to work, test is ran with docker-compose exec
  selenium-chrome:
    image: selenium/standalone-chrome
    networks:
      - my-app-bridge
    environment:
        - SCREEN_WIDTH=1024
        - SCREEN_HEIGHT=768
networks:
  my-app-bridge:
    driver: bridge

and then running this command (or something similar) to kick of the tests and get stdout/err as I need.

docker-compose exec -T my-app-under-test npm test
@johanbrandhorst

This comment has been minimized.

johanbrandhorst commented Jan 20, 2017

@johnculviner your solution is better than mine, thanks for your response 👍 . I didn't know about docker-compose exec until now!

@drFabio

This comment has been minimized.

drFabio commented Apr 11, 2017

Is there anyway to do that with run without the sleep?
Of doing something like:

  1. Run some container with run
  2. Run another container with run that will link or use the network to the first one
@paunin

This comment has been minimized.

paunin commented Jun 29, 2017

Any updates or workarounds here, guys. That's really sad :(

@kingbuzzman

This comment has been minimized.

kingbuzzman commented Jul 19, 2017

Agreed. I've come to the same hack independently (the docker-compose.yml -- sleep infinity and then docker-compose exec ...), but i would like the thing to work as one would expect it to run (docker-compose run ...).

Ps. #4811 (looks like someone is working on it -- there is an open PR)

@Vanuan

This comment has been minimized.

Vanuan commented Sep 1, 2017

Had the same issue (#5147)
It is reported that network aliases should be used with run:

version: '2'
networks:
    internal:
        driver: bridge
services:
    slave:
        command: "ash -c 'sleep 1; ping master'"
        image: busybox
        networks:
            internal:
               aliases:
                 - slave
      
    master:
        command: "ping slave"
        depends_on:
            - slave
        image: busybox
        networks:
            internal:
               aliases:
                 - master
      

Could somebody confirm it working?

@johanbrandhorst

This comment has been minimized.

johanbrandhorst commented Sep 1, 2017

@Vanuan that actually seems to fix the issue 🤔 . Thanks for updating this issue! What a weird requirement. The absolute absence of any replies to this issue by a contributor to the project is still pretty disgraceful 🙄 .

@holms

This comment has been minimized.

holms commented Apr 9, 2018

@johanbrandhorst is this even documented? I've been googling for 20 hours already about this issue

@johanbrandhorst

This comment has been minimized.

johanbrandhorst commented Apr 9, 2018

It appears not? Worthwhile raising an issue about the documentation of the workaround.

@holms

This comment has been minimized.

holms commented Apr 9, 2018

Desided to go without networking for now, but I had problem that all dependencies couldn't access main app container, after half of a night googling I've found that --name should be passed or else hostname of container name won't work. This is also not documented :(

@johanbrandhorst it's submitted feel free to add something in there. I really think this should be pushed forward also as --name and --use-aliases parameters together with --service-ports which are all undocumented almost at all.

@DonAurelio

This comment has been minimized.

DonAurelio commented Sep 3, 2018

I was running the ubuntu version of docker holded in this respository (docker.io 18.06.0). I removed that version an install docker.io using apt-get install docker.io. So now I have this version:

Client:
Version: 17.12.1-ce
API version: 1.35
Go version: go1.10.1
Git commit: 7390fc6
Built: Wed Apr 18 01:23:11 2018
OS/Arch: linux/amd64

Server:
Engine:
Version: 17.12.1-ce
API version: 1.35 (minimum version 1.12)
Go version: go1.10.1
Git commit: 7390fc6
Built: Wed Feb 28 17:46:05 2018
OS/Arch: linux/amd64
Experimental: false

Containers running with docker-compose doesn't have the file resolv.conf with the dns consiured as expected, but, each container can access Internet. I think that change solve mi problem.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment