Build Your Own GitLab Runners on EKS

PAGE UNDER CONSTRUCTION¶

As more and more DevOps teams adopt GitLab for internal development, and furthermore use GitLab CI/CD pipelines, finding ways to manage costs while still delivering highly available, scalable pipelines is crucial.

In this post I will provide an overview of GitLab runners and their role in CI/CD pipelines, as well as how you can configure your own self-managed runners using the Kubernetes executor running in your own EKS cluster.

Overview¶

At a high level, a GitLab runner is an agent that runs CI jobs in your pipeline. This can be in the form of agents running on Linux, Windows, or Mac hosts, as well as Docker or Kubernetes.

GitLab offers a great selection of SaaS (hosted) runners and a generous amount of free compute hours (10,000 minutes monthly at the time of writing this post), but you would be surprised how quickly this can be consumed by development teams doing rigorous testing, troubleshooting pipelines, etc.

The benefit of Kubernetes is the scalability and elasticity you can take advantage of, as well as upgrade ease with Helm. If you have seen my other post on Karpenter and Why You Should Ditch Cluster Autoscaler then you might have an inkling of how you can provide high scalability and flexibility for your jobs using EKS.