TLC’s Gitlab Actions self-hosted runner is a state-of-the-art OL 9.8 server with Gitlab Actions runner 2.3.3 pre-installed. It has python version 3.11 installed, just invoke your python scripts and packages with python3.11 instead of python or python3, as those two default to python3.9. The pre-installed Github runner software is over 1Gb so will save you time and disk I/O each and every time you instantiate a new runner. Unlike the Actions runners Github provides, these are self-hosted runners you own and maintain, giving you maximum flexibility into how you configure and run them. Whether it is resolving package and library dependencies, reducing costs, or protecting important encrypted secrets in your Amazon cloud account, self-hosted runners are pretty much a requirement for any serious technology organization.
The AMI is relatively generic and lean, with only bash and python shell as executor by default. Also, a lean 14Gb drive in case you really don’t need tons of space to run your builds. But because it is a standard Linux server, you can install (via your Github Action) any additional software libraries, packages and versions you need to perform your particular builds, as there are few, if any packages installed that would conflict. Because cloud-init is installed, it is usually as simple as increasing the root disk size before first boot and the cloud-init process will detect this and expand your filesystem to match the new disk size, as needed.
The AMI is configured with 1) open-source cloud-init, 2) proprietary AWS SSM and 3) TLC custom rc-local.service. The pre-configured custom rc-local.service allows SSH key access automatically, just ensure IMDSV2 only is configured at instance start-up. This provides the ‘one-click’ remote access required by AWS licensing, whether you configure SSM (policies) or use the locally installed cloud-init (via user-data) for your environment, or not. In addition to automatic filesystem resizing, the locally installed cloud-init allows you to pass the user-data necessary install the tokens and scripts necessary for you to register your instance at start-up, without needing to log in, at all.
Finally, this AMI is built to run with Technology Leadership’s Terraform (IaC) deployment for automatic/dynamic deployment of spot or on-demand instances. This relieves organizations from funding costly and complicated Kubernetes clusters and/or auto-scaling groups in order to dynamically provision spot market or on-demand self-hosted runners only when they are needed. The code is maintained by the founder, owner and CTO of Technology Leadership, and can be found here:
https://github.com/AndrewSimon/tf-files/tree/workflow
HOW TO ACCESS GITHUB ACTIONS RUNNER VIA REMOTE SSH ACCESS:
1. Launch your AMI ensuring you enable Public IP address and your security group allows SSH on port 22 and HTTP on port 80.
2. Allow about 2 to 3 min to fully boot after instance passes status checks (3/3 checks passed), note the assigned Public IP address (IP_ADDRESS for below).
3. Note the Public IP address assigned to your instance AND your instance ID
4. Use SSH to log in with a command similar to this:
ssh -i ~/.ssh/name_of_your_ssh_private_key ec2-user@IP_ADDRESS
HOW TO ACCESS GITHUB ACTIONS RUNNER VIA SSM
It is also possible to log into the instance without SSH access, however this will require some minor setup within your account to create policy for Simple Systems Manager (SSM) to manage EC2 resources. The instance itself will have policy and profile attached to it that will allow SSM to access it if you use the Terraform IaC (to create the AWS lambda function) that launches the instance as a Github Actions runner (via Github webhook). See the code here for more details: https://github.com/AndrewSimon/tf-files/blob/workflow/README.md
HOW TO DYNAMICALLY SCALE DOWN TLC GITHUB ACTION RUNNER
Using the Terraform IaC built for Github Actions self-hosted runners, the runners dynamically scale up to the number of runners you allow/permit to be running in your VPC based on the ‘push’ trigger to any Github repository you want configured. If you do not push code, you do not start runners. If you push code, you start a self-hosted runner to run the action. Because these default to spot instances, there is no particular need to scale them down as eventually the spot instance will be terminated when capacity becomes unavailable in the subnet in which it is launched. If you need to automatically scale down, it is advised to add to a shutdown or terminate step in your action.