Introduction to GitHub Actions Runner Controller: A Blog Series
Explore the power and flexibility of Actions Runner Controller(ARC), a Kubernetes operator optimizing GitHub Actions workflows. Dive into its benefits, features, versions, and how it stands out in the CI/CD landscape
Oops! Something went wrong while submitting the form.
Share This Post
Share This Post
Table of Contents
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.
What is 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.
Why Use Actions Runner Controller?
Cost-Efficiency
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.
Scalability
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.
Speed
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.
Control
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.
Security
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.
Kubernetes Integration
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.
Who Should Use Actions Runner Controller?
Actions Runner Controller is well-suited for organizations that:
Require stringent security protocols and high levels of control over their CI/CD environments.
Strict data protection and compliance regulations govern them.
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:
Needs to efficiently scale their operations.
Has custom requirements not met by GitHub-Hosted runners.
Installation Method
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.
ARC in Public Cloud
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.
Core Features of Actions Runner Controller
Automated Scaling
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
Runner Groups let you organize your runners by projects, team, and other categories as required.
Advanced Installation Options
ARC Helm charts allow enterprises to use several knobs to customize the deployment as per their needs.
An In-Depth Look at Advanced Features
Custom Runner Images
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.
Custom Volumes
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.
Entry-point Features
This feature lets you run custom scripts before or after a job across all Actions workflows, without modifying the code.
Cross-Organization Support
ARC’s ability to function across multiple GitHub organizations makes it a versatile choice for larger enterprises.
Monitoring and Troubleshooting
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.
Container Mode
As ARC Runners run as pods, ARC supports two modes for running container-based GitHub Actions or building container image. We will write a detailed blog post on container mode in the future.
Docker in Docker (DinD)
In this mode, the runner pod contains 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.
Different Versions of Actions Runner Controller: GitHub-Supported vs Community-Supported
Comparison between GitHub-Supported and Community-Supported ARC
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 its first version of ARC in March 2023.
Actions Runner Controller currently has two versions: one backed by GitHub and another by the community.
GitHub-Supported Actions Runner Controller
The GitHub-supported version hosted under actions.github.com namespace, is the more recent model. It's 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
Community-Supported Actions Runner Controller
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.
What's the Difference?
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.
Alternative Solutions and When to Use Them
GitHub-Hosted Runners
Ideal for smaller projects or those that don't require high levels of customization.
Self-Hosted Virtual/Physical Machines
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 the pros and cons of all Actions runner hosting options.
Conclusion
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.
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.
What is 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.
Why Use Actions Runner Controller?
Cost-Efficiency
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.
Scalability
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.
Speed
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.
Control
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.
Security
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.
Kubernetes Integration
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.
Who Should Use Actions Runner Controller?
Actions Runner Controller is well-suited for organizations that:
Require stringent security protocols and high levels of control over their CI/CD environments.
Strict data protection and compliance regulations govern them.
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:
Needs to efficiently scale their operations.
Has custom requirements not met by GitHub-Hosted runners.
Installation Method
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.
ARC in Public Cloud
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.
Core Features of Actions Runner Controller
Automated Scaling
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
Runner Groups let you organize your runners by projects, team, and other categories as required.
Advanced Installation Options
ARC Helm charts allow enterprises to use several knobs to customize the deployment as per their needs.
An In-Depth Look at Advanced Features
Custom Runner Images
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.
Custom Volumes
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.
Entry-point Features
This feature lets you run custom scripts before or after a job across all Actions workflows, without modifying the code.
Cross-Organization Support
ARC’s ability to function across multiple GitHub organizations makes it a versatile choice for larger enterprises.
Monitoring and Troubleshooting
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.
Container Mode
As ARC Runners run as pods, ARC supports two modes for running container-based GitHub Actions or building container image. We will write a detailed blog post on container mode in the future.
Docker in Docker (DinD)
In this mode, the runner pod contains 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.
Different Versions of Actions Runner Controller: GitHub-Supported vs Community-Supported
Comparison between GitHub-Supported and Community-Supported ARC
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 its first version of ARC in March 2023.
Actions Runner Controller currently has two versions: one backed by GitHub and another by the community.
GitHub-Supported Actions Runner Controller
The GitHub-supported version hosted under actions.github.com namespace, is the more recent model. It's 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
Community-Supported Actions Runner Controller
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.
What's the Difference?
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.
Alternative Solutions and When to Use Them
GitHub-Hosted Runners
Ideal for smaller projects or those that don't require high levels of customization.
Self-Hosted Virtual/Physical Machines
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 the pros and cons of all Actions runner hosting options.
Conclusion
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.
%20(2).png)
.png)
