CI/CD Inter-Service Networking

Hi @gitlab.padawan ,
I encountered the same problem and it surprises me that this issue hasn’t been fixed yet. There is another topic that indicates that people are struggling with this for almost 2 years now. imho service interconnection is an important “feature” one needs for testing.

Just like you I worked around the issue by using ip addresses. It turns out the runner assigns ip addresses starting from 172.17.0.2 incrementally. In your case dbhost would be reachable via 172.17.0.2 and middleware via 172.17.0.3

I don’t know how stable this approach is, especially if the runner is busy and there are many jobs running simultaneously.

Here is a minimal gitlab-ci config to reproduce this behavior:

stages:
  - test

mysql-test:
  stage: test
  services:
    - name: debian
      alias: debian
      command:
        - "sleep"
        - "60"
    - name: debian
      alias: deb-client-1
      command:
        - "ping"
        - "debian"
    - name: debian
      alias: deb-client-2
      command:
        - "ping"
        - "172.17.0.2"
  image: debian
  script:
    - ping debian -c 20
    - sleep 60

The first client fails

Service container logs:
2019-09-26T14:01:47.086531547Z ping: debian: Name or service not known

The container using the address to reach the target succeeds

Service container logs:
2019-09-26T14:01:48.010415693Z PING 172.17.0.2 (172.17.0.2) 56(84) bytes of data.
2019-09-26T14:01:48.010497873Z 64 bytes from 172.17.0.2: icmp_seq=1 ttl=64 time=0.136 ms

and the main environment can resolve the address:

[0K[32;1m$ ping debian -c 20[0;m
PING debian (172.17.0.2) 56(84) bytes of data.
64 bytes from debian (172.17.0.2): icmp_seq=1 ttl=64 time=0.157 ms
1 Like