Welcome to the first blog post in our series focused on Actions Runner Controller! In this series, we're diving deep into ARC. We'll start with the basics and then move on to some advanced scenarios! Today, we're kicking off with an introduction to Actions Runner Controller.
GitHub Actions has become the go-to solution for automating software development workflows. Large organizations often need more control, scalability, and efficiency as their GitHub Actions jobs expand. This is where Actions Runner Controller (ARC) comes into play. It is a Kubernetes operator designed to manage and scale self-hosted GitHub Action runner pods.
Further, it is also necessary to secure your ARC environment to avoid exfiltration and release build tampering. If you’re looking for tools that can help you do that, we've got your back! Get in touch with us to learn more.
One of the most compelling reasons to use Actions Runner Controller is cost-efficiency. GitHub-hosted runners can become expensive as your project scales, particularly if you have multiple GitHub Actions jobs running in parallel. By hosting your own runners, you can significantly reduce these costs.
Actions Runner Controller leverages the power of Kubernetes to automatically scale runner pods based on workload. This ensures that you're not wasting runner resources, allowing for more efficient use of infrastructure.
Many enterprise customers configure ARC to keep a certain number of warm runner pods all the time. In addition, Kubernetes can fairly quickly spin up new runner pods as required. Because of these reasons, many workflows run faster on ARC as ARC runner instances have negligible boot time.
Self-hosting your GitHub runners gives you control over the environment. You can choose the operating system and the software packages. This is crucial for projects with specific dependencies or security requirements.
ARC allows customers to isolate their CI/CD environment, removing dependencies from GitHub and internet connectivity. In addition, ARC provides each Actions workflow with its own dedicated ephemeral Kubernetes pod.
As Actions Runner Controller operates on Kubernetes, it naturally integrates with existing enterprise workloads running on Kubernetes. This makes it a seamless addition to your current infrastructure.
Actions Runner Controller is well-suited for organizations that:
Organizations in industries such as healthcare and finance, as well as those handling Personally Identifiable Information (PII), frequently face these requirements.
In addition, an organization may choose to use ARC because it:
Helm is the officially supported installation method for ARC. Enterprise customers that prefer other methods such as ArgoCD can port the official Helm charts to their preferred solution.
As ARC uses vanilla Kubernetes, it can be deployed on a variety of cloud providers. One can use cloud-provider managed Kubernetes services such as AWS EKS, GCP GKE, and AWS AKS for running ARC. One can also spin up virtual machines with these cloud providers, configure Kubernetes manually, and use it to host ARC. ARC does not support certain restrictive Kubernetes environments such as GCP GKE Autopilot.
Actions Runner Controller introduces the concept of RunnerReplicaSets and HorizontalRunnerAutoscalers. These Kubernetes Custom Resource Definitions (CRDs) enable you to define rules for automated scaling of GitHub runners.
Runner Groups let you organize your runners by projects, team, and other categories as required.
ARC Helm charts allow enterprises to use several knobs to customize the deployment as per their needs.
One of the standout features of Actions Runner Controller is the ability to create custom runner images. This feature allows organizations to tailor runner images to their specific workloads, resulting in more efficient operations.
Custom runner images can also streamline GitHub Actions workflows by removing the need for action steps related to environment setup. You can build these images with the environment already configured. Actions Runner Controller supports the creation of multiple custom images for diverse project needs.
With Actions Runner Controller, you can define custom volumes for each runner. This is particularly useful for workloads that require access to specific data or configurations.
This feature lets you run custom scripts before or after a job across all Actions workflows, without modifying the code.
ARC’s ability to function across multiple GitHub organizations makes it a versatile choice for larger enterprises.
One of the standout features of Actions Runner Controller is its built-in monitoring capabilities. Troubleshooting is typically a straightforward process due to its extensive documentation.
As ARC Runners run as pods, ARC supports two modes for running container based GitHub Actions or building container image. We will write detailed blog post on container mode in the future.
In this mode, the runner pod contain the DinD (Docker-in-Docker) container as well. One can run the default DinD container with full root access or use the container in rootless mode. The DinD container requires the privileged mode.
In this mode, the runner creates additional Kubernetes pods to run containerized workflows. This mode does not require any privileged containers. However, you cannot run docker commands (e.g., docker build for building container images) from a GitHub Actions workflow.
ARC started off as a community project with most of the code contributions coming from a set of core maintainers. The first version was released in February 2020. The project rapidly grew in popularity among enterprises that were looking for self-hosted Actions runners. Such enterprise users started requesting GitHub to officially support the project. GitHub formally adopted the project in December 2022 and started the work to turn it into a full GitHub product. GitHub formally launched their first version of ARC in March 2023.
Actions Runner Controller currently has two versions: one backed by GitHub and another by the community.
The GitHub-supported version in hosted under actions.github.com namespace, is the more recent model. It's as an official extension of GitHub Actions. GitHub directly supports it, making it a trustworthy choice for large-scale operations. Moreover, the GitHub-supported version enhances the scaling of runner pods
The namespace actions.summerwind.dev manages community supported ARC. This version is more dynamic and frequently updated with new features and fixes, thanks to the open-source community's contributions.
It uses Custom Resource Definitions (CRDs) like apiVersion: actions.summerwind.dev/v1alpha1 for Kubernetes-based configurations.
The primary difference lies in the level of support and reliability. The GitHub-supported version offers a layer of assurance and is more suited for organizations that require robust, enterprise-level solutions. The community-supported version is often ideal for smaller teams or projects without the need for official GitHub support. The community supported version has an additional dependency on cert-manager.
Ideal for smaller projects or those that don't require high levels of customization.
You should consider this option If your tasks need hardware simulations or access to certain non-virtual devices.
We will be writing a detailed blog post in the future discussing pros and cons of all Actions runner hosting options.
Actions Runner Controller is an invaluable tool for running GitHub Actions workflows at scale. Stay tuned for our next blog post on ARC.
If you would like us to cover a specific ARC topic, please reach out to us.
If you’re looking for tools to secure your GitHub Actions, our team is here to help you out. Get in touch with us to know more.
