Service aliases don't resolve with `FF_NETWORK_PER_BUILD`

How do I get service aliases to resolve when using cross-service communication?

I need services to be able to communicate with each other. Therefore, I set the FF_NETWORK_PER_BUILD feature flag as described in the documentation.

This works. I can confirm that a Docker network is created for each job, and the following is logged to the job log:

feature flags: FF_NETWORK_PER_BUILD:true

However, service aliases are not set in /etc/hosts. Therefore, services can’t reach each other by name. I found two posts with the same problem, both left unanswered:

Service aliases do resolve in the ‘build’ container.

The documentation contains the following vague phrasing:

For this solution to work, you must use the networking mode that creates a new network for each job.

‘Using the network mode’ seems to mean: setting the same feature flag (FF_NETWORK_PER_BUILD) in the runner configuration. The only difference with setting this feature flag in .gitlab-ci.yml seems to be the scope. Nonetheless, I tried setting the feature flag in the runner config as well, but that does not help.

Versions:

  • GitLab CE 15.8.0
  • GitLab Runner 15.8.0
1 Like

Additional information:

/etc/hosts in service container does not contain aliases:

root@5178cc254dc3:/data# cat /etc/hosts
127.0.0.1	localhost
::1	localhost ip6-localhost ip6-loopback
fe00::0	ip6-localnet
ff00::0	ip6-mcastprefix
ff02::1	ip6-allnodes
ff02::2	ip6-allrouters
172.17.0.5	5178cc254dc3
2a0c:eb00:dc:1ab:0:242:ac11:5	5178cc254dc3

/etc/hosts in build container contains aliases:

root@runner-g9cefn3e-project-83-concurrent-0:/# cat /etc/hosts
127.0.0.1	localhost
::1	localhost ip6-localhost ip6-loopback
fe00::0	ip6-localnet
ff00::0	ip6-mcastprefix
ff02::1	ip6-allnodes
ff02::2	ip6-allrouters
172.17.0.3	elasticsearch 3bd09f99c307 runner-g9cefn3e-project-83-concurrent-0-5dbf7f4462e65be6-elasticsearch-1
2a0c:eb00:dc:1ab:0:242:ac11:3	elasticsearch 3bd09f99c307 runner-g9cefn3e-project-83-concurrent-0-5dbf7f4462e65be6-elasticsearch-1
172.17.0.4	etcd e54923bd2f5e runner-g9cefn3e-project-83-concurrent-0-5dbf7f4462e65be6-gcr.io__etcd-development__etcd-2
2a0c:eb00:dc:1ab:0:242:ac11:4	etcd e54923bd2f5e runner-g9cefn3e-project-83-concurrent-0-5dbf7f4462e65be6-gcr.io__etcd-development__etcd-2
172.17.0.6	rabbitmq 097ce07ec368 runner-g9cefn3e-project-83-concurrent-0-5dbf7f4462e65be6-rabbitmq-4
2a0c:eb00:dc:1ab:0:242:ac11:6	rabbitmq 097ce07ec368 runner-g9cefn3e-project-83-concurrent-0-5dbf7f4462e65be6-rabbitmq-4
172.17.0.2	mariadb ddad723e3276 runner-g9cefn3e-project-83-concurrent-0-5dbf7f4462e65be6-mariadb-0
2a0c:eb00:dc:1ab:0:242:ac11:2	mariadb ddad723e3276 runner-g9cefn3e-project-83-concurrent-0-5dbf7f4462e65be6-mariadb-0
172.17.0.4	gcr.io__etcd-development__etcd e54923bd2f5e runner-g9cefn3e-project-83-concurrent-0-5dbf7f4462e65be6-gcr.io__etcd-development__etcd-2
2a0c:eb00:dc:1ab:0:242:ac11:4	gcr.io__etcd-development__etcd e54923bd2f5e runner-g9cefn3e-project-83-concurrent-0-5dbf7f4462e65be6-gcr.io__etcd-development__etcd-2
172.17.0.4	gcr.io-etcd-development-etcd e54923bd2f5e runner-g9cefn3e-project-83-concurrent-0-5dbf7f4462e65be6-gcr.io__etcd-development__etcd-2
2a0c:eb00:dc:1ab:0:242:ac11:4	gcr.io-etcd-development-etcd e54923bd2f5e runner-g9cefn3e-project-83-concurrent-0-5dbf7f4462e65be6-gcr.io__etcd-development__etcd-2
172.17.0.5	redis 5178cc254dc3 runner-g9cefn3e-project-83-concurrent-0-5dbf7f4462e65be6-redis-3
2a0c:eb00:dc:1ab:0:242:ac11:5	redis 5178cc254dc3 runner-g9cefn3e-project-83-concurrent-0-5dbf7f4462e65be6-redis-3
172.17.0.7	runner-g9cefn3e-project-83-concurrent-0
2a0c:eb00:dc:1ab:0:242:ac11:7	runner-g9cefn3e-project-83-concurrent-0
1 Like

Hi @wedwards,

  • Are you sure the behavior does only occur with FF_NETWORK_PER_BUILD?
  • docker-compose has the same problem, you can not link arbitrary containers but only in a sequential manner.
  • To my knowledge this is a problem for all kind of similar setups, i.e. gitlab-runner would need to fiddle with /etc/hosts after all service containers werde created.
  • In e.g. kubernetes it is a bit different because the containers there are resolvable with a proper DNS setup.