Gitlab Runner HADR

This project will help you make sure there is at-least one GitLab Runners group available for your GitLab projects. By checking the status of each GitLab Runner via the GitLabs server API, our μserivce will be able to switch the GitLab Runners around to have an Active-Active scenario 24/7.

Real Life Scenario

An organization has GitLab Runners installed in 2 separated clusters registered with different Tags:

Cluster	Tags
Cluster A	runner-a, main-runner
Cluster B	runner-b

Each job has to run on the same cluster as the previous job because of the caches configured per cluster.

In a scenario where Cluster A faints, our developers will be forced to change their .gitlab-ci.yml files to use runner-b instead of rnd-runner.

With our μserivce, your teams will not even know that Cluster A had any problems, and they can continue working as usual.

Sidecar

The sidecar will check the status about the GitLab Runner and export a liveness health check.

Decider

The decider has 2 jobs:

Status Check

• Checking the liveness health check of each available GitLab Runner installed on the same cluster

• Exporting the statuses (Online / Total) to the configured GitLab project

Update Runners

• Read the statuses of both clusters

• Decide if the current cluster is stronger (has more GitLab Runner available)

Stronger

If stronger, it will update the tag list of the GitLab Runners to the configured desired main cluster tag so users will not have to change their .gitlab-ci.yml files.

Weaker

If weaker, it will remove the configured desired main cluster tag from the tag list so users will stop using those runners without updating their .gitlab-ci.yml file.