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
+16-13Lines changed: 16 additions & 13 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,12 +1,10 @@
1
1
# Terraform module for scalable self hosted GitHub action runners
2
2
3
-
> WIP: Module is in development
4
-
5
3
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.
6
4
7
5
## Motivation
8
6
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.
7
+
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 life cycle of the action runners.
10
8
11
9
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
10
@@ -37,12 +35,15 @@ Besides these permissions, the lambdas also need permission to CloudWatch (for l
37
35
Examples are provided in [the example directory](examples/). Please ensure you have installed the following tools.
38
36
39
37
- Terraform, or [tfenv](https://github.com/tfutils/tfenv).
40
-
- Bash shell or compatible.
41
-
- TODO: building lambda ?
42
-
- AWS cli
38
+
- Bash shell or compatible
39
+
- Docker (optional, to build lambda's without node).
40
+
- AWS cli (optional)
41
+
- Node and yarn (for lambda development).
43
42
44
43
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
44
45
+
GitHub workflows will fail immediately if there is no action runner available to host your builds. Since this module supports to scale from 0 and up your builds will fail in case there is no active runner available. So we recommend to create an offline runner with the matching label by default `self-hosted`. Create this runner by just following the GitHub instruction on you local machine. You can stop the process after the step of running the `config.sh`. This offline runner will will ensure you builds will not fail if a runner becomes available within 24 hours.
46
+
46
47
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
48
49
### Setup GitHub App (part 1)
@@ -88,14 +89,15 @@ output "files" {
88
89
}
89
90
```
90
91
91
-
Next run `terraform init && terraform apply` as result the lambdas will be download to the same directory.
92
+
Next run `terraform init && terraform apply` as result the lambdas will be download to the same directory. Alternatively you can download the zip artifacts with any other tool of you favour.
92
93
94
+
For local development you can build all the lambda's at once using `.ci/build.sh` or per lambda using `yarn`, check the`package.json` for the commands.
93
95
94
96
Next create a second terraform workspace and initiate the module, see the examples for more details.
Check the terraform output for the API gateway url, which you need in the next step. The lambda for syncing the GitHub distribution will be executed by a trigger via Cloud Watch. To ensure the binary is cached, trigger the `runner-binaries-syncer` manually. The payload does not matter.
130
+
Check the terraform output for the API gateway url (endpoint), which you need in the next step. The lambda for syncing the GitHub distribution will be executed by a trigger via Cloud Watch. To ensure the binary is cached, trigger the `runner-binaries-syncer` manually. The payload does not matter. (e.g. `aws lambda invoke --function-name <environment>-syncer respone.json`)
129
131
130
132
### Setup GitHub App (part 2)
131
133
@@ -136,9 +138,12 @@ Go back to the GitHub App and update the following settings.
136
138
3. Provide the webhook secret.
137
139
4. Enable the `Check run` event for the webhook.
138
140
141
+
You are now ready to run action workloads on self hosted runner, remember builds will fail if there is no runner available with matching labels.
139
142
140
143
## Examples
141
144
145
+
TODO
146
+
142
147
## Inputs
143
148
144
149
| Name | Description | Type | Default | Required |
@@ -169,8 +174,6 @@ Go back to the GitHub App and update the following settings.
0 commit comments