How does communicate gitlab runners?

How to Use GitLab
1

Hello,

I was wondering how does work gitlab runners. How does it talk to gitlab.com and how is it syncronized ?

When we install the runner on a remote server with shell, is the connection to gitlab.com secure ?

On which protocol is based this communication ? Https, ssh, etc ?

Thank you in advance :smiley:

1 Like
2

Reply from the support :

Runners communicate with GitLab over HTTPS, entirely through connections initiated from the Runner to GitLab and never in reverse. The advantage here is that you can install a Runner behind a firewall and as long as the Runner has outbound access to GitLab.com it will work. From there, it really doesn’t matter which executor you use (Shell, Docker, etc).

:smile:

3 Likes
3

Hi,

I have a doubt. If connection is one way , from runner to gitlab then how does gitlab deploy to remote? How does runner comes to know that we have ran a pipeline and it has to comunicate with gitlab?

4

See gitlab access logs , runner is constantly polling the server

1 Like
5

the answer was useful, thanks @iahmad-khan and @mib-energreen

6

I would like to come back to this thread. Is there - meanwhile - any option to reverse the directory of connection initiation? Following scenario: I’ve an internal Gitlab server running on on-premises resources. It is - obviously - not accessible from the world. Now I want to deploy runners on container infrastructures like GCP or MassiveGrid. However, these runners can not connect to the Gitlab server while the Gitlab server could connect to these runners. Is there any option? Or workaround?

Thanks
Wolfgang

7

Hello @wolutator,

I think even if you achieved this , the next problem would be that the runner will firstly try to pull the git repository over https as well.

The only thing I could think of is to establish a VPN between the runner and the server?

2 Likes
8

This is how Gitlab runner works using AWS as example

  1. Outbound Connections: Runners on a private subnet in AWS can be configured to have outbound internet access using a NAT Gateway or a NAT instance. This allows the runners to initiate connections to the GitLab server (or any other external resource), even though they cannot be directly reached from the internet.
  2. Polling Mechanism: GitLab doesn’t need to initiate a connection to the runners. Instead, the runners are constantly polling the GitLab server for jobs. When you push code or trigger a CI/CD job, the GitLab server queues the job. The runner, during its next poll, picks up the job and executes it. The results, logs, and status are then sent back to the GitLab server by the runner.
  3. Security and Network Configuration:
  • The runners will need security group rules that allow outbound connections, typically to GitLab’s IP on port 443 (HTTPS).
  • A route in the private subnet’s route table should direct internet-bound traffic to a NAT Gateway or NAT instance, which is usually located in a public subnet.
  • The NAT device allows the runners in the private subnet to initiate outbound IPv4 traffic to the internet, while preventing unsolicited inbound traffic from reaching them.

This architecture allows the runners to remain isolated and secure in a private subnet while still being able to execute jobs from the GitLab server. The GitLab server doesn’t directly “reach into” the private subnet; instead, the runners reach out to the GitLab server.

1 Like