FAQ | This is a LIVE service | Changelog

Document GKE-based GitLab runners

We now have the ability to provision GitLab runners in the cloud using the GKE GitLab runner infrastructure.

Do a first pass at documenting it. Potential diataxis quadrants:

  • How-to: create and register runners for a new project
  • Reference: where the project is, who has familiarity, team ownership and documentation which, for whatever reason, can't live in the repo itself.
  • Explanation: why we wanted GitLab runners in GCP, what it gives us (especially w.r.t. workload identity) and why we've set it up the way we have.

Notes

  • Ensure that there is clear instructions on how to define the docker-in-docker service in CI job yaml when using the GKE runners. For example:
job1:
  image: docker:24-git
  services:
    - docker:24-dind
  variables:
    DOCKER_HOST: tcp://docker:2376
    DOCKER_TLS_CERTDIR: "/certs"
    DOCKER_TLS_VERIFY: 1
    DOCKER_CERT_PATH: "$DOCKER_TLS_CERTDIR/client"
  • Add an explanation of the CI runner service account (i.e. gitlab-runner-prod-22257483.svc.id.goog[api-gateway-runner/gke-ci-run]) and why we want to use impersonation rather than direct IAM roles.
  • Add a how-to detailing how to add a service account with the correct bindings to be impersonated by the GKE runner service account. Also include examples of how to use impersonation with gcloud.
Edited by Ryan Kowalewski