Gitlab-ci Services DNS resolution

we’re having some trouble with using dependant services in our CI at the moment, and perhaps i’ve got a understanding problem.

Let’s assume we’ve got a gitlab CI like this:

image: docker:17.11
- name : postgres:9.6.5
  alias: db

Our runner is a docker runner (no dind, but socket forwarded), nothing special. No DNS servers configured in the gitlab-ci.toml.

Issue is, that the ci container is unable to resolve ‘db’ (the alias defined for our service). resolv.conf inside this container is mounted to the host’s resolv.conf (this is done automagically by the runner) which points to our AD servers. Of course, these don’t know anything about ‘db’.

My understanding was, that gitlab runner somehow injects the service’s alias into the ci container, either by adding it to the container’s hostfile (as it has been done by docker-compose years ago) or by injecting a docker-compose-like dns forwarder which holds all those alias names. Or how was this meant to work? Can’t find anything about that in the documentation. The created hostname (as stated in the docs), here ‘postgres’, doesn’t work, too. Or something with the container linking isn’t working as it should.

Btw; gitlab runner 10.3.0, gitlab EE 10.4.0

From the logs:

the container’s job pipeline

Using Docker executor with image docker:17.11 ...
Starting service postgres:9.6.5 ...
Pulling docker image postgres:9.6.5 ...
Using docker image postgres:9.6.5 
ID=sha256:bd287e105bc19ee63b0862c4819b5d4e90966f96ddf490fd6fa707241be562bc for postgres service...

jumped into the running ci container with docker exec -it…

# dig db 
;db.				IN	A

# dig postgres
;postgres.			IN	A

# cat /etc/resolv.conf

Linking doesn’t seem to work (executed on the running ci container):

docker inspect -f "{{ .HostConfig.Links }}" 797dc2119815  

The (somehow not linked) postgres container is running and is also removed after cancelling the job (it’s running endlessly as we added a script…)

Any thoughts?

best regards,

Answering myself:
Everything works as expected. We just startet a container inside this docker ci image, and of course, this knows nothing about the db link. looking into the correct container (the one generated here) , everything is fine…