Skip to content
GitLab
Closed
Issue created by Sid Sijbrandij@sytsesOwner5 of 5 checklist items completed5/5 checklist items

GitLab Runner Autoscale

MR in https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/merge_requests/53

This technology is a great way to create new VM's when there is demand for extra CI capacity. This is not even possible with Kubernetes today (hooks in Kubernetes to allow other applications to autoscale are planned for 1.2).

How it works

  1. You run the GitLab Runner program with Autoscale and supply it credentials to any provider supported by Docker machine (left side of the page)
  2. When needed GitLab Runner Autoscale spins up a new VM, this takes 50s on DO, 8mins on Azure
  3. On this VM Docker Engine is installed by the central GitLab Runner
  4. GitLab Runner start a container on which the build job is run (one container per VM is better for reliability)
  5. The central GitLab Runner keeps watching for new builds, using one GitLab Runner can optimise selection of Docker-machine created node to increase the chance of image hit ratio (this is not yet a feature, but can be someday).
  6. At a configurable time (an hour or so) unused machines are removed (while keeping a reserve of machines standby)
  7. Also see https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/merge_requests/53#how-it-works

Promotion plan

  1. We should write documentation for it
  2. We should make graphics to explain it
  3. We should use it for Dev on DO
  4. We should use it for .com on Azure (free credits)
  5. We should write a great blog post about it

@ayufan @axil @nearlythere