'Gitlab-CI: Cross-service communication
I’m currently using Gitlab-CI to test a jboss eap based java application. To be more precise, I’m using Postman’s newman tool to run some REST API tests on all my controllers.
For now, I’m doing this using an external EAP server that only host my application for the duration of the test, but I’d like to avoid this and use a gitlab-ci service.
The only problem being that my services requires a database (pgsql) and I’d like to also use a service for this one which brings me to my main question; is cross-service communication a thing with gitlab-ci ? is there any way to get this up and running ?
Thank you guys in advance!
Solution 1:[1]
Currently there is no way to do that.
However, Gitlab has an active issue to address this https://gitlab.com/gitlab-org/gitlab-runner/issues/1042.
Once implemented all services should be on the same network and thus would be able to resolve each other's IP by service name/alias.
Solution 2:[2]
GitLab employee here.
One way to accomplish this is using Docker and GitLab CI/CD’s concept of attached services. You can learn more about that here
Solution 3:[3]
This is now possible using the FF_NETWORK_PER_BUILD feature flag. You can add the following to your .gitlab-ci.yaml (at the root for all jobs or per job).
variables:
FF_NETWORK_PER_BUILD: 1
Or in your runner config.
This networking mode creates and uses a new user-defined Docker bridge network for each job. User-defined bridge networks are covered in detail in the Docker documentation.
Unlike legacy container links used in other network modes, Docker environment variables are not shared across the containers.
Docker networks might conflict with other networks on the host, including other Docker networks, if the CIDR ranges are already in use. The default Docker address pool can be configured by using default-address-pool in dockerd.
To enable this mode you must enable the FF_NETWORK_PER_BUILD feature flag.
When a job starts, a bridge network is created (similar to docker network create ). Upon creation, the service containers and the build job container are connected to this network.
Both the container running the job and the containers running the service can resolve each other’s hostnames and aliases. This functionality is provided by Docker.
The job container is resolvable by using the build alias as well, because the hostname is assigned by GitLab.
The network is removed at the end of the job.
Sources
This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.
Source: Stack Overflow
| Solution | Source |
|---|---|
| Solution 1 | klandaika |
| Solution 2 | olearycrew |
| Solution 3 | George |