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