You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+102-1Lines changed: 102 additions & 1 deletion
Original file line number
Diff line number
Diff line change
@@ -2,8 +2,109 @@
2
2
3
3
> WIP: Module is in development
4
4
5
+
This [Terraform](https://www.terraform.io/) modules create the required infra structure needed to host [GitHub Action](https://github.com/features/actions) self hosted runners on [AWS spot instances](https://aws.amazon.com/ec2/spot/). All logic required to handle the lifecycle for an action runners is implemented in AWS Lambda functions.
5
6
7
+
## Motivation
6
8
9
+
GitHub Actions `self hosted` runners provides you with a flexible option to run your CI workloads on compute of your choice. Currently there is no option provided to automate the creation and scaling of action runners. This module takes care of creating the AWS infra structure to host action runners on spot instances. And provides lambda modules to orchestrate the lifecycle of the action runners.
10
+
11
+
Lambda is chosen as runtime for two major reasons. First it allows to create small components with minimal access to AWS and GitHub. Secondly it provides a scalable setup for minimal costs that works on repo level and scales to organization level. The lambdas will create Linux based EC2 instances with Docker to serve CI workloads that can run on Linux and/or Docker. The main goal is here to support Docker based workloads.
12
+
13
+
A logical question would be why not Kubernetes? In the current approach we stay close to the way the GitHub action runners are available today. The approach is to install the runner on a host where the required software is available. With this setup we stay quite close to the current GitHub approach. Another logical choice would be AWS Auto Scaling groups. This choice would typically require much more permissions on instance level to GitHub. And besides that, scaling up and down is not trivial.
14
+
15
+
## Overview
16
+
17
+
The process of scaling runners on demand starts by registering a GitHub App which sends a [check run event](https://developer.github.com/v3/activity/events/types/#checkrunevent) via a webhook to the API Gateway. The Gateway triggers a lambda which will verify the signature and filter for queued build events. Accepted events are posted on a SQS queue. Messages on this queue will be delayed for a configurable amount of seconds to give the available runners time to pick up this build.
18
+
19
+
In case the build is not picked up yet and no limits are reached the lambda requests a registration token for a new runner at GitHub, stores the token in the SSM parameter store and starts an EC2 instance via a launch template. The EC2 instance installs the required software via a [`user_data`](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/user-data.html) script, fetches and deletes the registration token from SSM and configures the action runner.
20
+
21
+
Scaling down the runners is at the moment brute-forced, every configurable amount of minutes a lambda will check every runner (instance) if it is busy. In case the runner is not busy it will be removed from GitHub and the instance terminated in AWS. At the moment there seems no other option to scale down more smoothly.
22
+
23
+
Downloading the GitHub Action Runner distribution can be occasionally slow (more than 10 minutes). Therefore a lambda is introduced that synchronizes the action runner binary from GitHub to an S3 bucket. The EC2 instance will fetch the distribution from the S3 bucket instead of the internet.
24
+
25
+
26
+
27
+
Permission are managed on several places. Below the most important ones. For details check the Terraform sources.
28
+
29
+
- The GitHub App requires access to actions and publish `check_run` events to AWS.
30
+
- The scale up lambda should have access to EC2 for creating and tagging instances.
31
+
- The scale down lambda should have access to EC2 to terminate instances.
32
+
33
+
Besides these permissions, the lambdas also need permission to CloudWatch (for logging and scheduling), SSM and S3.
34
+
35
+
## Usages
36
+
37
+
Examples are provided in [the example directory](examples/). Please ensure you have installed the following tools.
38
+
39
+
- Terraform, or [tfenv](https://github.com/tfutils/tfenv).
40
+
- Bash shell or compatible.
41
+
- TODO: building lambda ?
42
+
- AWS cli
43
+
44
+
The module support two main scenarios for creating runners. On repository level a runner will be dedicated to only one repository, no other repository can use the runner. On organization level you can use the runner(s) for all the repositories within the organization. See https://help.github.com/en/actions/hosting-your-own-runners/about-self-hosted-runners for more information. Before starting the deployment you have to choose one option.
45
+
46
+
The setup consists of running Terraform to create all AWS resources and configure the GitHub App. The Terraform module requires configuration from the GitHub App and the GitHub app requires output from Terraform. Therefore you should first create the GitHub App, configure the basics. Then run Terraform and finalize the configuration of the GitHub App afterwards.
47
+
48
+
### Setup GitHub App (part 1)
49
+
50
+
Go to GitHub and create a new app. Beware you can create apps your organization or for a user. For now we handle only the organization level app.
51
+
52
+
1. Create app in Github
53
+
2. Choose a name
54
+
3. Choose a website (mandatory, not required for the module).
55
+
4. Disable the webhook for now (we will configure this later).
56
+
5. Repository permissions, enable `Checks` to receive events for new builds.
57
+
6._Only for repo level runners!_ - Repository permissions, `Administration` - Read and Write (to register runner)
58
+
7._Only for organization level runners!_ - Organization permissions, `Administration` - Read and Write (to register runner)
59
+
8. Save the new app.
60
+
9. Next generate a private key on the General page.
61
+
10. Make a note of the following app parameters: app id , client ID, and client secret
62
+
63
+
### Setup terraform module
64
+
65
+
1. Create a terraform workspace and initiate the module, see the examples for more details.
0 commit comments