Awesome

<a href="https://cpco.io/homepage"><img src=".github/banner.png?raw=true" alt="Project Banner"/></a><br/> <p align="right"> <a href="https://github.com/cloudposse-terraform-components/aws-eks-github-actions-runner/releases/latest"><img src="https://img.shields.io/github/release/cloudposse-terraform-components/aws-eks-github-actions-runner.svg?style=for-the-badge" alt="Latest Release"/></a><a href="https://slack.cloudposse.com"><img src="https://slack.cloudposse.com/for-the-badge.svg" alt="Slack Community"/></a></p>

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.

:::info

There are (as of this writing) open feature requests to add some commonly needed packages to the official Runner Sets runner image. You can upvote these requests here and here to help get them implemented.

:::

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:

1. 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.
2. 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

Providers

Modules

Resources

Inputs

Outputs

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

[!NOTE] This project is part of Cloud Posse's comprehensive "SweetOps" approach towards DevOps.

<details><summary><strong>Learn More</strong></summary>

It's 100% Open Source and licensed under the APACHE2.

</details>

<a href="https://cloudposse.com/readme/header/link?utm_source=github&utm_medium=readme&utm_campaign=cloudposse-terraform-components/aws-eks-github-actions-runner&utm_content=readme_header_link"><img src="https://cloudposse.com/readme/header/img"/></a>

Related Projects

Check out these related projects.

• Cloud Posse Terraform Modules - Our collection of reusable Terraform modules used by our reference architectures.
• Atmos - Atmos is like docker-compose but for your infrastructure

✨ Contributing

This project is under active development, and we encourage contributions from our community. Many thanks to our outstanding contributors:

🐛 Bug Reports & Feature Requests

Please use the issue tracker to report any bugs or file feature requests.

💻 Developing

If you are interested in being a contributor and want to get involved in developing this project or help out with Cloud Posse's other projects, we would love to hear from you! Hit us up in Slack, in the #cloudposse channel.

In general, PRs are welcome. We follow the typical "fork-and-pull" Git workflow.

1. Review our Code of Conduct and Contributor Guidelines.
2. Fork the repo on GitHub
3. Clone the project to your own machine
4. Commit changes to your own branch
5. Push your work back up to your fork
6. Submit a Pull Request so that we can review your changes

NOTE: Be sure to merge the latest changes from "upstream" before making a pull request!

🌎 Slack Community

Join our Open Source Community on Slack. It's FREE for everyone! Our "SweetOps" community is where you get to talk with others who share a similar vision for how to rollout and manage infrastructure. This is the best place to talk shop, ask questions, solicit feedback, and work together as a community to build totally sweet infrastructure.

📰 Newsletter

Sign up for our newsletter and join 3,000+ DevOps engineers, CTOs, and founders who get insider access to the latest DevOps trends, so you can always stay in the know. Dropped straight into your Inbox every week — and usually a 5-minute read.

📆 Office Hours <a href="https://cloudposse.com/office-hours?utm_source=github&utm_medium=readme&utm_campaign=cloudposse-terraform-components/aws-eks-github-actions-runner&utm_content=office_hours"><img src="https://img.cloudposse.com/fit-in/200x200/https://cloudposse.com/wp-content/uploads/2019/08/Powered-by-Zoom.png" align="right" /></a>

Join us every Wednesday via Zoom for your weekly dose of insider DevOps trends, AWS news and Terraform insights, all sourced from our SweetOps community, plus a live Q&A that you can’t find anywhere else. It's FREE for everyone!

About

This project is maintained by <a href="https://cpco.io/homepage?utm_source=github&utm_medium=readme&utm_campaign=cloudposse-terraform-components/aws-eks-github-actions-runner&utm_content=">Cloud Posse, LLC</a>. <a href="https://cpco.io/homepage?utm_source=github&utm_medium=readme&utm_campaign=cloudposse-terraform-components/aws-eks-github-actions-runner&utm_content="><img src="https://cloudposse.com/logo-300x69.svg" align="right" /></a>

We are a DevOps Accelerator for funded startups and enterprises. Use our ready-to-go terraform architecture blueprints for AWS to get up and running quickly. We build it with you. You own everything. Your team wins. Plus, we stick around until you succeed.

<a href="https://cpco.io/commercial-support?utm_source=github&utm_medium=readme&utm_campaign=cloudposse-terraform-components/aws-eks-github-actions-runner&utm_content=commercial_support"><img alt="Learn More" src="https://img.shields.io/badge/learn%20more-success.svg?style=for-the-badge"/></a>

Your team can operate like a pro today.

Ensure that your team succeeds by using our proven process and turnkey blueprints. Plus, we stick around until you succeed.

• Reference Architecture. You'll get everything you need from the ground up built using 100% infrastructure as code.
• Deployment Strategy. You'll have a battle-tested deployment strategy using GitHub Actions that's automated and repeatable.
• Site Reliability Engineering. You'll have total visibility into your apps and microservices.
• Security Baseline. You'll have built-in governance with accountability and audit logs for all changes.
• GitOps. You'll be able to operate your infrastructure via Pull Requests.
• Training. You'll receive hands-on training so your team can operate what we build.
• Questions. You'll have a direct line of communication between our teams via a Shared Slack channel.
• Troubleshooting. You'll get help to triage when things aren't working.
• Code Reviews. You'll receive constructive feedback on Pull Requests.
• Bug Fixes. We'll rapidly work with you to fix any bugs in our projects.

<a href="https://cloudposse.com/readme/commercial-support/link?utm_source=github&utm_medium=readme&utm_campaign=cloudposse-terraform-components/aws-eks-github-actions-runner&utm_content=readme_commercial_support_link"><img src="https://cloudposse.com/readme/commercial-support/img"/></a>

License

<a href="https://opensource.org/licenses/Apache-2.0"><img src="https://img.shields.io/badge/License-Apache%202.0-blue.svg?style=for-the-badge" alt="License"></a>

Licensed to the Apache Software Foundation (ASF) under one
or more contributor license agreements.  See the NOTICE file
distributed with this work for additional information
regarding copyright ownership.  The ASF licenses this file
to you under the Apache License, Version 2.0 (the
"License"); you may not use this file except in compliance
with the License.  You may obtain a copy of the License at

  https://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing,
software distributed under the License is distributed on an
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express or implied.  See the License for the
specific language governing permissions and limitations
under the License.

Trademarks

All other trademarks referenced herein are the property of their respective owners.

Copyright © 2017-2024 Cloud Posse, LLC

<a href="https://cloudposse.com/readme/footer/link?utm_source=github&utm_medium=readme&utm_campaign=cloudposse-terraform-components/aws-eks-github-actions-runner&utm_content=readme_footer_link"><img alt="README footer" src="https://cloudposse.com/readme/footer/img"/></a>