Component: github-actions-runner
This component deploys self-hosted GitHub Actions Runners and a Controller on an EKS cluster, using "runner scale sets".
This solution is supported by GitHub and supersedes the actions-runner-controller developed by Summerwind and deployed by Cloud Posse's actions-runner-controller component.
Current limitations
The runner image used by Runner Sets contains
no more packages than are necessary
to run the runner. This is in contrast to the Summerwind implementation, which contains some commonly needed packages
like build-essential
, curl
, wget
, git
, and jq
, and the GitHub hosted images which contain a robust set of
tools. (This is a limitation of the official Runner Sets implementation, not this component per se.) You will need to
install any tools you need in your workflows, either as part of your workflow (recommended), by maintaining a
custom runner image,
or by running such steps in a
separate container that has the tools
pre-installed. Many tools have publicly available actions to install them, such as actions/setup-node
to install
NodeJS or dcarbone/install-jq-action
to install jq
. You can also install packages using
awalsh128/cache-apt-pkgs-action
, which has the advantage of being able to skip the installation if the package is
already installed, so you can more efficiently run the same workflow on GitHub hosted as well as self-hosted runners.
In the current version of this component, only "dind" (Docker in Docker) mode has been tested. Support for "kubernetes" mode is provided, but has not been validated.
Many elements in the Controller chart are not directly configurable by named inputs. To configure them, you can use the
controller.chart_values
input or create a resources/values-controller.yaml
file in the component to supply values.
Almost all the features of the Runner Scale Set chart are configurable by named inputs. The exceptions are:
- There is no specific input for specifying an outbound HTTP proxy.
- There is no specific input for supplying a custom certificate authority (CA) certificate to use when connecting to GitHub Enterprise Server.
You can specify these values by creating a resources/values-runner.yaml
file in the component and setting values as
shown by the default Helm
values.yaml,
and they will be applied to all runners.
Currently, this component has some additional limitations. In particular:
- The controller and all runners and listeners share the Image Pull Secrets. You cannot use different ones for different runners.
- All the runners use the same GitHub secret (app or PAT). Using a GitHub app is preferred anyway, and the single GitHub app serves the entire organization.
- Only one controller is supported per cluster, though it can have multiple replicas.
These limitations could be addressed if there is demand. Contact Cloud Posse Professional Services if you would be interested in sponsoring the development of any of these features.
Ephemeral work storage
The runners are configured to use ephemeral storage for workspaces, but the details and defaults can be a bit confusing.
When running in "dind" ("Docker in Docker") mode, the default is to use emptyDir
, which means space on the kubelet
base directory, which is usually the root disk. You can manage the amount of storage allowed to be used with
ephemeral_storage
requests and limits, or you can just let it use whatever free space there is on the root disk.
When running in kubernetes
mode, the only supported local disk storage is an ephemeral PersistentVolumeClaim
, which
causes a separate disk to be allocated for the runner pod. This disk is ephemeral, and will be deleted when the runner
pod is deleted. When combined with the recommended ephemeral runner configuration, this means that a new disk will be
created for each job, and deleted when the job is complete. That is a lot of overhead and will slow things down
somewhat.
The size of the attached PersistentVolume is controlled by ephemeral_pvc_storage
(a Kubernetes size string like "1G")
and the kind of storage is controlled by ephemeral_pvc_storage_class
(which can be omitted to use the cluster default
storage class).
This mode is also optionally available when using dind
. To enable it, set ephemeral_pvc_storage
to the desired size.
Leave ephemeral_pvc_storage
at the default value of null
to use emptyDir
storage (recommended).
Beware that using a PVC may significantly increase the startup of the runner. If you are using a PVC, you may want to keep idle runners available so that jobs can be started without waiting for a new runner to start.
Usage
Stack Level: Regional
Once the catalog file is created, the file can be imported as follows.
import:
- catalog/eks/github-actions-runner
...
The default catalog values e.g. stacks/catalog/eks/github-actions-runner.yaml
components:
terraform:
eks/github-actions-runner:
vars:
enabled: true
ssm_region: "us-east-2"
name: "gha-runner-controller"
charts:
controller:
chart_version: "0.7.0"
runner_sets:
chart_version: "0.7.0"
controller:
kubernetes_namespace: "gha-runner-controller"
create_namespace: true
create_github_kubernetes_secret: true
ssm_github_secret_path: "/github-action-runners/github-auth-secret"
github_app_id: "123456"
github_app_installation_id: "12345678"
runners:
config-default: &runner-default
enabled: false
github_url: https://github.com/cloudposse
# group: "default"
# kubernetes_namespace: "gha-runner-private"
create_namespace: true
# If min_replicas > 0 and you also have do-not-evict: "true" set
# then the idle/waiting runner will keep Karpenter from deprovisioning the node
# until a job runs and the runner is deleted.
# override by setting `pod_annotations: {}`
pod_annotations:
karpenter.sh/do-not-evict: "true"
min_replicas: 0
max_replicas: 8
resources:
limits:
cpu: 1100m
memory: 1024Mi
ephemeral-storage: 5Gi
requests:
cpu: 500m
memory: 256Mi
ephemeral-storage: 1Gi
self-hosted-default:
<<: *runner-default
enabled: true
kubernetes_namespace: "gha-runner-private"
# If min_replicas > 0 and you also have do-not-evict: "true" set
# then the idle/waiting runner will keep Karpenter from deprovisioning the node
# until a job runs and the runner is deleted. So we override the default.
pod_annotations: {}
min_replicas: 1
max_replicas: 12
resources:
limits:
cpu: 1100m
memory: 1024Mi
ephemeral-storage: 5Gi
requests:
cpu: 500m
memory: 256Mi
ephemeral-storage: 1Gi
self-hosted-large:
<<: *runner-default
enabled: true
resources:
limits:
cpu: 6000m
memory: 7680Mi
ephemeral-storage: 90G
requests:
cpu: 4000m
memory: 7680Mi
ephemeral-storage: 40G
Authentication and Secrets
The GitHub Action Runners need to authenticate to GitHub in order to do such things as register runners and pickup jobs. You can authenticate using either a GitHub App or a Personal Access Token (classic). The preferred way to authenticate is by creating and installing a GitHub App. This is the recommended approach as it allows for much more restricted access than using a Personal Access Token (classic), and the Action Runners do not currently support using a fine-grained Personal Access Token.
Site note about SSM and Regions
This component supports using AWS SSM to store and retrieve secrets. SSM parameters are regional, so if you want to deploy to multiple regions you have 2 choices:
- Create the secrets in each region. This is the most robust approach, but requires you to create the secrets in each region and keep them in sync.
- Create the secrets in one region and use the
ssm_region
input to specify the region where they are stored. This is the easiest approach, but does add some obstacles to managing deployments during a region outage. If the region where the secrets are stored goes down, there will be no impact on runners in other regions, but you will not be able to deploy new runners or modify existing runners until the SSM region is restored or until you set up SSM parameters in a new region.
Alternatively, you can create Kubernetes secrets outside of this component (perhaps using SOPS) and reference them by name. We describe here how to save the secrets to SSM, but you can save the secrets wherever and however you want to, as long as you deploy them as Kubernetes secret the runners can reference. If you store them in SSM, this component will take care of the rest, but the standard Terraform caveat applies: any secrets referenced by Terraform will be stored unencrypted in the Terraform state file.
Creating and Using a GitHub App
Follow the instructions here to create and install a GitHub App for the runners to use for authentication.
At the App creation stage, you will be asked to generate a private key. This is the private key that will be used to
authenticate the Action Runner. Download the file and store the contents in SSM using the following command, adjusting
the profile, region, and file name. The profile should be the terraform
role in the account to which you are deploying
the runner controller. The region should be the region where you are deploying the primary runner controller. If you are
deploying runners to multiple regions, they can all reference the same SSM parameter by using the ssm_region
input to
specify the region where they are stored. The file name (argument to cat
) should be the name of the private key file
you downloaded.
# Adjust profile name and region to suit your environment, use file name you chose for key
AWS_PROFILE=acme-core-gbl-auto-terraform AWS_REGION=us-west-2 chamber write github-action-runners github-auth-secret -- "$(cat APP_NAME.DATE.private-key.pem)"
You can verify the file was correctly written to SSM by matching the private key fingerprint reported by GitHub with:
AWS_PROFILE=acme-core-gbl-auto-terraform AWS_REGION=us-west-2 chamber read -q github-action-runners github-auth-secret | openssl rsa -in - -pubout -outform DER | openssl sha256 -binary | openssl base64
At this stage, record the Application ID and the private key fingerprint in your secrets manager (e.g. 1Password). You may want to record the private key as well, or you may consider it sufficient to have it in SSM. You will need the Application ID to configure the runner controller, and want the fingerprint to verify the private key. (You can see the fingerprint in the GitHub App settings, under "Private keys".)
Proceed to install the GitHub App in the organization or repository you want to use the runner controller for, and record the Installation ID (the final numeric part of the URL, as explained in the instructions linked above) in your secrets manager. You will need the Installation ID to configure the runner controller.
In your stack configuration, set the following variables, making sure to quote the values so they are treated as strings, not numbers.
github_app_id: "12345"
github_app_installation_id: "12345"
OR (obsolete): Creating and Using a Personal Access Token (classic)
Though not recommended, you can use a Personal Access Token (classic) to authenticate the runners. To do so, create a
PAT (classic) as described in the
GitHub Documentation.
Save this to the value specified by ssm_github_token_path
using the following command, adjusting the AWS profile and
region as explained above:
AWS_PROFILE=acme-core-gbl-auto-terraform AWS_REGION=us-west-2 chamber write github-action-runners github-auth-secret -- "<PAT>"
Using Runner Groups
GitHub supports grouping runners into distinct
Runner Groups,
which allow you to have different access controls for different runners. Read the linked documentation about creating
and configuring Runner Groups, which you must do through the GitHub Web UI. If you choose to create Runner Groups, you
can assign one or more Runner Sets (from the runners
map) to groups (only one group per runner set, but multiple sets
can be in the same group) by including group: <Runner Group Name>
in the runner configuration. We recommend including
it immediately after github_url
.
Interaction with Karpenter or other EKS autoscaling solutions
Kubernetes cluster autoscaling solutions generally expect that a Pod runs a service that can be terminated on one Node and restarted on another with only a short duration needed to finish processing any in-flight requests. When the cluster is resized, the cluster autoscaler will do just that. However, GitHub Action Runner Jobs do not fit this model. If a Pod is terminated in the middle of a job, the job is lost. The likelihood of this happening is increased by the fact that the Action Runner Controller Autoscaler is expanding and contracting the size of the Runner Pool on a regular basis, causing the cluster autoscaler to more frequently want to scale up or scale down the EKS cluster, and, consequently, to move Pods around.
To handle these kinds of situations, Karpenter respects an annotation on the Pod:
spec:
template:
metadata:
annotations:
karpenter.sh/do-not-evict: "true"
When you set this annotation on the Pod, Karpenter will not voluntarily evict it. This means that the Pod will stay on the Node it is on, and the Node it is on will not be considered for deprovisioning (scale down). This is good because it means that the Pod will not be terminated in the middle of a job. However, it also means that the Node the Pod is on will remain running until the Pod is terminated, even if the node is underutilized and Karpenter would like to get rid of it.
Since the Runner Pods terminate at the end of the job, this is not a problem for the Pods actually running jobs.
However, if you have set minReplicas > 0
, then you have some Pods that are just idling, waiting for jobs to be
assigned to them. These Pods are exactly the kind of Pods you want terminated and moved when the cluster is
underutilized. Therefore, when you set minReplicas > 0
, you should NOT set karpenter.sh/do-not-evict: "true"
on
the Pod.
Updating CRDs
When updating the chart or application version of gha-runner-scale-set-controller
, it is possible you will need to
install new CRDs. Such a requirement should be indicated in the gha-runner-scale-set-controller
release notes and may
require some adjustment to this component.
This component uses helm
to manage the deployment, and helm
will not auto-update CRDs. If new CRDs are needed,
follow the instructions in the release notes for the Helm chart or gha-runner-scale-set-controller
itself.
Useful Reference
- Runner Scale Set Controller's Helm chart values.yaml
- Runner Scale Set's Helm chart values.yaml
- Runner Scale Set's Docker image and how to create your own
When reviewing documentation, code, issues, etc. for self-hosted GitHub action runners or the Actions Runner Controller
(ARC), keep in mind that there are 2 implementations going by that name. The original implementation, which is now
deprecated, uses the actions.summerwind.dev
API group, and is at times called the Summerwind or Legacy implementation.
It is primarily described by documentation in the
actions/actions-runner-controller GitHub repository itself.
The new implementation, which is the one this component uses, uses the actions.github.com
API group, and is at times
called the GitHub implementation or "Runner Scale Sets" implementation. The new implementation is described in the
official
GitHub documentation.
Feature requests about the new implementation are officially directed to the
Actions category of GitHub community discussion.
However, Q&A and community support is directed to the actions/actions-runner-controller
repo's
Discussion section, though beware that discussions
about the old implementation are mixed in with discussions about the new implementation.
Bug reports for the new implementation are still filed under the actions/actions-runner-controller
repo's
Issues tab, though again, these are mixed in with bug
reports for the old implementation. Look for the gha-runner-scale-set
label to find issues specific to the new
implementation.
Requirements
Name | Version |
---|---|
terraform | >= 1.3.0 |
aws | >= 4.9.0 |
helm | >= 2.0 |
kubernetes | >= 2.0, != 2.21.0 |
Providers
Name | Version |
---|---|
aws | >= 4.9.0 |
aws.ssm | >= 4.9.0 |
kubernetes | >= 2.0, != 2.21.0 |
Modules
Name | Source | Version |
---|---|---|
eks | cloudposse/stack-config/yaml//modules/remote-state | 1.5.0 |
gha_runner_controller | cloudposse/helm-release/aws | 0.10.0 |
gha_runners | cloudposse/helm-release/aws | 0.10.0 |
iam_roles | ../../account-map/modules/iam-roles | n/a |
this | cloudposse/label/null | 0.25.0 |
Resources
Name | Type |
---|---|
kubernetes_namespace.controller | resource |
kubernetes_namespace.runner | resource |
kubernetes_secret_v1.controller_image_pull_secret | resource |
kubernetes_secret_v1.controller_ns_github_secret | resource |
kubernetes_secret_v1.github_secret | resource |
kubernetes_secret_v1.image_pull_secret | resource |
aws_eks_cluster_auth.eks | data source |
aws_ssm_parameter.github_token | data source |
aws_ssm_parameter.image_pull_secret | data source |
Inputs
Name | Description | Type | Default | Required |
---|---|---|---|---|
additional_tag_map | Additional key-value pairs to add to each map in tags_as_list_of_maps . Not added to tags or id .This is for some rare cases where resources want additional configuration of tags and therefore take a list of maps with tag key, value, and additional configuration. | map(string) | {} | no |
attributes | ID element. Additional attributes (e.g. workers or cluster ) to add to id ,in the order they appear in the list. New attributes are appended to the end of the list. The elements of the list are joined by the delimiter and treated as a single ID element. | list(string) | [] | no |
charts | Map of Helm charts to install. Keys are "controller" and "runner_sets". | map(object({ | n/a | yes |
context | Single object for setting entire context at once. See description of individual variables for details. Leave string and numeric variables as null to use default value.Individual variable settings (non-null) override settings in context object, except for attributes, tags, and additional_tag_map, which are merged. | any | { | no |
controller | Configuration for the controller. | object({ | n/a | yes |
create_github_kubernetes_secret | If true , this component will create the Kubernetes Secret that will be used to getthe GitHub App private key or GitHub PAT token, based on the value retrieved from SSM at the var.ssm_github_secret_path . WARNING: This will causethe secret to be stored in plaintext in the Terraform state. If false , this component will not create a secret and you must create it(with the name given by var.github_kubernetes_secret_name ) in everynamespace where you are deploying runners (the controller does not need it). | bool | true | no |
create_image_pull_kubernetes_secret | If true and image_pull_secret_enabled is true , this component will create the Kubernetes image pull secret resource,using the value in SSM at the path specified by ssm_image_pull_secret_path .WARNING: This will cause the secret to be stored in plaintext in the Terraform state. If false , this component will not create a secret and you must create it(with the name given by var.github_kubernetes_secret_name ) in everynamespace where you are deploying controllers or runners. | bool | true | no |
delimiter | Delimiter to be used between ID elements. Defaults to - (hyphen). Set to "" to use no delimiter at all. | string | null | no |
descriptor_formats | Describe additional descriptors to be output in the descriptors output map.Map of maps. Keys are names of descriptors. Values are maps of the form {<br/> format = string<br/> labels = list(string)<br/>} (Type is any so the map values can later be enhanced to provide additional options.)format is a Terraform format string to be passed to the format() function.labels is a list of labels, in order, to pass to format() function.Label values will be normalized before being passed to format() so they will beidentical to how they appear in id .Default is {} (descriptors output will be empty). | any | {} | no |
eks_component_name | The name of the eks component | string | "eks/cluster" | no |
enabled | Set to false to prevent the module from creating any resources | bool | null | no |
environment | ID element. Usually used for region e.g. 'uw2', 'us-west-2', OR role 'prod', 'staging', 'dev', 'UAT' | string | null | no |
github_app_id | The ID of the GitHub App to use for the runner controller. Leave empty if using a GitHub PAT. | string | null | no |
github_app_installation_id | The "Installation ID" of the GitHub App to use for the runner controller. Leave empty if using a GitHub PAT. | string | null | no |
github_kubernetes_secret_name | Name of the Kubernetes Secret that will be used to get the GitHub App private key or GitHub PAT token. | string | "gha-github-secret" | no |
helm_manifest_experiment_enabled | Enable storing of the rendered manifest for helm_release so the full diff of what is changing can been seen in the plan | bool | false | no |
id_length_limit | Limit id to this many characters (minimum 6).Set to 0 for unlimited length.Set to null for keep the existing setting, which defaults to 0 .Does not affect id_full . | number | null | no |
image_pull_kubernetes_secret_name | Name of the Kubernetes Secret that will be used as the imagePullSecret. | string | "gha-image-pull-secret" | no |
image_pull_secret_enabled | Whether to configure the controller and runners with an image pull secret. | bool | false | no |
kube_data_auth_enabled | If true , use an aws_eks_cluster_auth data source to authenticate to the EKS cluster.Disabled by kubeconfig_file_enabled or kube_exec_auth_enabled . | bool | false | no |
kube_exec_auth_aws_profile | The AWS config profile for aws eks get-token to use | string | "" | no |
kube_exec_auth_aws_profile_enabled | If true , pass kube_exec_auth_aws_profile as the profile to aws eks get-token | bool | false | no |
kube_exec_auth_enabled | If true , use the Kubernetes provider exec feature to execute aws eks get-token to authenticate to the EKS cluster.Disabled by kubeconfig_file_enabled , overrides kube_data_auth_enabled . | bool | true | no |
kube_exec_auth_role_arn | The role ARN for aws eks get-token to use | string | "" | no |
kube_exec_auth_role_arn_enabled | If true , pass kube_exec_auth_role_arn as the role ARN to aws eks get-token | bool | true | no |
kubeconfig_context | Context to choose from the Kubernetes config file. If supplied, kubeconfig_context_format will be ignored. | string | "" | no |
kubeconfig_context_format | A format string to use for creating the kubectl context name whenkubeconfig_file_enabled is true and kubeconfig_context is not supplied.Must include a single %s which will be replaced with the cluster name. | string | "" | no |
kubeconfig_exec_auth_api_version | The Kubernetes API version of the credentials returned by the exec auth plugin | string | "client.authentication.k8s.io/v1beta1" | no |
kubeconfig_file | The Kubernetes provider config_path setting to use when kubeconfig_file_enabled is true | string | "" | no |
kubeconfig_file_enabled | If true , configure the Kubernetes provider with kubeconfig_file and use that kubeconfig file for authenticating to the EKS cluster | bool | false | no |
label_key_case | Controls the letter case of the tags keys (label names) for tags generated by this module.Does not affect keys of tags passed in via the tags input.Possible values: lower , title , upper .Default value: title . | string | null | no |
label_order | The order in which the labels (ID elements) appear in the id .Defaults to ["namespace", "environment", "stage", "name", "attributes"]. You can omit any of the 6 labels ("tenant" is the 6th), but at least one must be present. | list(string) | null | no |
label_value_case | Controls the letter case of ID elements (labels) as included in id ,set as tag values, and output by this module individually. Does not affect values of tags passed in via the tags input.Possible values: lower , title , upper and none (no transformation).Set this to title and set delimiter to "" to yield Pascal Case IDs.Default value: lower . | string | null | no |
labels_as_tags | Set of labels (ID elements) to include as tags in the tags output.Default is to include all labels. Tags with empty values will not be included in the tags output.Set to [] to suppress all generated tags.Notes: The value of the name tag, if included, will be the id , not the name .Unlike other null-label inputs, the initial setting of labels_as_tags cannot bechanged in later chained modules. Attempts to change it will be silently ignored. | set(string) | [ | no |
name | ID element. Usually the component or solution name, e.g. 'app' or 'jenkins'. This is the only ID element not also included as a tag .The "name" tag is set to the full id string. There is no tag with the value of the name input. | string | null | no |
namespace | ID element. Usually an abbreviation of your organization name, e.g. 'eg' or 'cp', to help ensure generated IDs are globally unique | string | null | no |
regex_replace_chars | Terraform regular expression (regex) string. Characters matching the regex will be removed from the ID elements. If not set, "/[^a-zA-Z0-9-]/" is used to remove all characters other than hyphens, letters and digits. | string | null | no |
region | AWS Region. | string | n/a | yes |
runners | Map of Runner Scale Set configurations, with the key being the name of the runner set. Please note that the name must be in kebab-case (no underscores). For example: hcl | map(object({ | {} | no |
ssm_github_secret_path | The path in SSM to the GitHub app private key file contents or GitHub PAT token. | string | "/github-action-runners/github-auth-secret" | no |
ssm_image_pull_secret_path | SSM path to the base64 encoded dockercfg image pull secret. | string | "/github-action-runners/image-pull-secrets" | no |
ssm_region | AWS Region where SSM secrets are stored. Defaults to var.region . | string | null | no |
stage | ID element. Usually used to indicate role, e.g. 'prod', 'staging', 'source', 'build', 'test', 'deploy', 'release' | string | null | no |
tags | Additional tags (e.g. {'BusinessUnit': 'XYZ'} ).Neither the tag keys nor the tag values will be modified by this module. | map(string) | {} | no |
tenant | ID element _(Rarely used, not included by default)_. A customer identifier, indicating who this instance of a resource is for | string | null | no |
Outputs
Name | Description |
---|---|
metadata | Block status of the deployed release |
runners | Human-readable summary of the deployed runners |
References
- cloudposse/terraform-aws-components - Cloud Posse's upstream component
- alb-controller - Helm Chart
- alb-controller - AWS Load Balancer Controller
- actions-runner-controller Webhook Driven Scaling
- actions-runner-controller Chart Values
- How to set service account for workers spawned in Kubernetes mode
Changelog
Initial Release
This release has been tested and used in production, but testing has not covered all available features. Please use with caution and report any issues you encounter.
Migration from actions-runner-controller
GitHub has released its own official self-hosted GitHub Actions Runner support, replacing the
actions-runner-controller
implementation developed by Summerwind. (See the
announcement from GitHub.) Accordingly, this
component is a replacement for the
actions-runner-controller
component. Although there are different defaults for some of the configuration options, if you are already using
actions-runner-controller
you should be able to reuse the GitHub app or PAT and image pull secret you are already
using, making migration relatively straightforward.
We recommend deploying this component into a separate namespace (or namespaces) than actions-runner-controller
and get
the new runners sets running before you remove the old ones. You can then migrate your workflows to use the new runners
sets and have zero downtime.
Major differences:
- The official GitHub runners deployed are different from the GitHub hosted runners and the Summerwind self-hosted
runners in that
they have very few tools installed.
You will need to install any tools you need in your workflows, either as part of your workflow (recommended) or by
maintaining a
custom runner image,
or by running such steps in a
separate container that has the tools
pre-installed. Many tools have publicly available actions to install them, such as
actions/setup-node
to install NodeJS ordcarbone/install-jq-action
to installjq
. You can also install packages usingawalsh128/cache-apt-pkgs-action
, which has the advantage of being able to skip the installation if the package is already installed, so you can more efficiently run the same workflow on GitHub hosted as well as self-hosted runners. - Self-hosted runners, such as those deployed with the
actions-runner-controller
component, are targeted by a set of labels indicated by a workflow'sruns-on
array, of which the first must be "self-hosted". Runner Sets, such as are deployed with this component, are targeted by a single label, which is the name of the Runner Set. This means that you will need to update your workflows to target the new Runner Set label. See here for the reasoning behind GitHub's decision to use a single label instead of a set. - The
actions-runner-controller
component uses the published Helm chart for the controller, but there is none for the runners, so it includes a custom Helm chart for them. However, for Runner Sets, GitHub has published 2 charts, one for the controller and one for the runners (runner sets). This means that this component requires configuration (e.g. version numbers) of 2 charts, although both should be kept at the same version. - The
actions-runner-controller
component has aresources/values.yaml
file that provided defaults for the controller Helm chart. This component does not have files like that by default, but supports aresources/values-controller.yaml
file for the "gha-runner-scale-set-controller" chart and aresources/values-runner.yaml
file for the "gha-runner-scale-set" chart. - The default values for the SSM paths for the GitHub auth secret and the imagePullSecret have changed. Specify the old values explicitly to keep using the same secrets.
- The
actions-runner-controller
component creates an IAM Role (IRSA) for the runners to use. This component does not create an IRSA, because the chart does not support using one while in "dind" mode. Use GitHub OIDC authentication inside your workflows instead. - The Runner Sets deployed by this component use a different autoscaling mechanism, so most of the
actions-runner-controller
configuration options related to autoscaling are not applicable. - For the same reason, this component does not deploy a webhook listener or Ingress and does not require configuration of a GitHub webhook.
- The
actions-runner-controller
component has an input namedexisting_kubernetes_secret_name
. The equivalent input for this component isgithub_kubernetes_secret_name
, in order to clearly distinguish it from theimage_pull_kubernetes_secret_name
input.
Translating configuration from actions-runner-controller
Here is an example configuration for the github-actions-runner
controller, with comments indicating where in the
actions-runner-controller
configuration the corresponding configuration option can be copied from.
components:
terraform:
eks/github-actions-runner:
vars:
# This first set of values you can just copy from here.
# However, if you had customized the standard Helm configuration
# (such things as `cleanup_on_fail`, `atmoic`, or `timeout`), you
# now need to do that per chart under the `charts` input.
enabled: true
name: "gha-runner-controller"
charts:
controller:
# As of the time of the creation of this component, 0.7.0 is the latest version
# of the chart. If you use a newer version, check for breaking changes
# and any updates to this component that may be required.
# Find the latest version at https://github.com/actions/actions-runner-controller/blob/master/charts/gha-runner-scale-set-controller/Chart.yaml#L18
chart_version: "0.7.0"
runner_sets:
# We expect that the runner set chart will always be at the same version as the controller chart,
# but the charts are still in pre-release so that may change.
# Find the latest version at https://github.com/actions/actions-runner-controller/blob/master/charts/gha-runner-scale-set/Chart.yaml#L18
chart_version: "0.7.0"
controller:
# These inputs from `actions-runner-controller` are now parts of the controller configuration input
kubernetes_namespace: "gha-runner-controller"
create_namespace: true
replicas: 1 # From `actions-runner-controller` file `resources/values.yaml`, value `replicaCount`
# resources from var.resources
# These values can be copied directly from the `actions-runner-controller` configuration
ssm_github_secret_path: "/github_runners/controller_github_app_secret"
github_app_id: "250828"
github_app_installation_id: "30395627"
# These values require some converstion from the `actions-runner-controller` configuration
# Set `create_github_kubernetes_secret` to `true` if `existing_kubernetes_secret_name` was not set, `false` otherwise.
create_github_kubernetes_secret: true
# If `existing_kubernetes_secret_name` was set, copy the setting to `github_kubernetes_secret_name` here.
# github_kubernetes_secret_name: <existing_kubernetes_secret_name>
# To configure imagePullSecrets:
# Set `image_pull_secret_enabled` to the value of `docker_config_json_enabled` in `actions-runner-controller` configuration.
image_pull_secret_enabled: true
# Set `ssm_image_pull_secret_path` to the value of `ssm_docker_config_json_path` in `actions-runner-controller` configuration.
ssm_image_pull_secret_path: "/github_runners/docker/config-json"
# To configure the runner sets, there is still a map of `runners`, but most
# of the configuration options from `actions-runner-controller` are not applicable.
# Most of the applicable configuration options are the same as for `actions-runner-controller`.
runners:
# The name of the runner set is the key of the map. The name is now the only label
# that is used to target the runner set.
self-hosted-default:
# Namespace is new. The `actions-runner-controller` always deployed the runners to the same namespace as the controller.
# Runner sets support deploying the runners in a namespace other than the controller,
# and it is recommended to do so. If you do not set kubernetes_namespace, the runners will be deployed
# in the same namespace as the controller.
kubernetes_namespace: "gha-runner-private"
# Set create_namespace to false if the namespace has been created by another component.
create_namespace: true
# `actions-runner-controller` had a `dind_enabled` input that was switch between "kubernetes" and "dind" mode.
# This component has a `mode` input that can be set to "kubernetes" or "dind".
mode: "dind"
# Where the `actions-runner-controller` configuration had `type` and `scope`,
# the runner set has `github_url`. For organization scope runners, use https://github.com/myorg
# (or, if you are using Enterprise GitHub, your GitHub Enterprise URL).
# For repo runners, use the repo URL, e.g. https://github.com/myorg/myrepo
github_url: https://github.com/cloudposse
# These configuration options are the same as for `actions-runner-controller`
# group: "default"
# node_selector:
# kubernetes.io/os: "linux"
# kubernetes.io/arch: "arm64"
# tolerations:
# - key: "kubernetes.io/arch"
# operator: "Equal"
# value: "arm64"
# effect: "NoSchedule"
# If min_replicas > 0 and you also have do-not-evict: "true" set
# then the idle/waiting runner will keep Karpenter from deprovisioning the node
# until a job runs and the runner is deleted. So we do not set it by default.
# pod_annotations:
# karpenter.sh/do-not-evict: "true"
min_replicas: 1
max_replicas: 12
resources:
limits:
cpu: 1100m
memory: 1024Mi
ephemeral-storage: 5Gi
requests:
cpu: 500m
memory: 256Mi
ephemeral-storage: 1Gi
# The rest of the `actions-runner-controller` configuration is not applicable.
# This includes `labels` as well as anything to do with autoscaling.