Gitlab interservice communication

user_12289730 0
Viewed 203

Hi does gitlab support interservice comminication. I found a question related to it Gitlab-CI: Cross-service communication in this there is a link to gitlab issue https://gitlab.com/gitlab-org/gitlab-runner/-/issues/1042. Issue seems to be closed so i think support should be there.

I have an image in which i run my server which needs to connect to a database. In CI I have set my server image and postgres image as services. But Server is not able to connect to the postgres service. I get

psycopg2.OperationalError: could not translate host name "[MASKED]" to address: Name or service not known

I am able to connect to the database thorough CI. But not able to connect to database through my server. ie. not able to connect to another service from one service.

task1:
  stage: Test
  services:
    - name: postgres:latest
      alias: postgres
    - name: serverImage
      alias: server
  variables:
    FF_NETWORK_PER_BUILD: "true"
    POSTGRES_DB: testdb
    POSTGRES_USER: testuser
    POSTGRES_PASSWORD: ""
    POSTGRES_HOST_AUTH_METHOD: trust
  script: 
    - curl -i http://server:3000

I am using self-hosted runner shared runners.

Am just trying simple connection

from sqlalchemy import *
url = 'postgresql://testuser:@postgres:5432/testdb'
engine = create_engine(url)

with engine.connect() as conn:
    pass

When i added sleep before the connection, the error log is gone but now when i send request with curl i get another error:

curl: (7) Failed to connect to server port 4000: No route to host
gitlab gitlab-ci-runner gitlab-ci
1 Answers

Waiting for database to be ready

The issue with your server image connecting to the database service was caused because both services start up at the same time and the database may not be ready for connections by the time your service tries to connect. As discussed in the comments, adding retry/wait logic resolves this issue.

Custom service is not stable

The following No route to host error in your job will occur because your service image is exiting or failing to start before your job/curl connects to it. You need to make sure that your server continues to run successfully in order to be reachable.

Job configuration for inter-communication is correct

Your job configuration is correct, as evidenced by the fact that replacing it with the image strm/helloworld-http allows communication to work properly, as discussed in the comments. So, the communication between all the containers (job, server, database) has been established.

user_57479440
Related