This Amazon Machine Image (AMI) is an EBS backed HVM image without the Oracle product codes.
Automatic root filesystem resizing: Due to the complexities and limitations of Oracle’s Linux OS installers, cloud-init cannot automatically resize the root volume of a standard OL9 image such as this one; but THIS ORACLE LINUX IMAGE CAN because it has TLC’s custom rc-local.service pre-installed! The AMI starts with a lean 14Gb root filesystem that boots in about a minute and has 6Gb free. If you need more space, just specify a larger volume size at boot. It will expand automatically once, at either first boot or any subsequent boots where the volume size is increased above 14Gb. After it is expanded (via automation or manually), it can be expanded yet again, but for quality control purposes and Amazon requirements, additional volume size expansions usually must be done manually.
Github Actions Runner 2.333.0: The image also has the gh-runner user installed and the full 1GB gh runner installation directly under /home/gh-runner (it does not use, nor need, the ./actions-runner/ directory beneath /home/gh-runner). This means that when manually adding a new Github Actions runner to your ‘self-hosted’ runners, you do not have to download the software OR run the installer. Simply log in and run the last two commands given to you through the ‘Add Runner’ button in the Github UI, which (to summarize) is ./config.sh (with API key and whatever options you desire) and then ./run.sh (with API key). Having the software pre-installed not only saves time, but saves on (fairly expensive) AWS disk I/O charges – and both time and I/O has expense in AWS (let alone payroll).
TLC GH Actions Runner and Terraform: The best part is, that if you are tired of provisioning instances, like the idea of provisioning spot runners instead of on-demand, or prefer the stability of on-demand and can handle shutting instances down at the end of the day or when you are finished with them, the TLC Terraform plan called tf-files is THE modern alternative you have been searching for. It is an alternative to really expensive platform-in-a-platform solutions like Kubernetes that Github itself recommends for its solution to ‘ephemeral’ runners; and is vastly better than hand-cobbled auto-scaling groups that have triggers that are completely unrelated to your workflows! This solution is far superior because it is a hybrid ephemeral/long-running solution. The terraform plan creates a whole new VPC for you then populates it with all of the subnets, routes, igw, security group and policies you need on the infrastructure side. But, it also creates the github webhook for your repo AND the lambda components to be able to dynamically create runners on a git push. No need to call a help desk to launch a new runner! No need to spend time configuring a new runner again, and again, and again. For spot instances, they can last a few hours to a few days, but eventually get terminated due to lack of capacity. No need to terminate a spot instance unless you really need to keep a tight budget. And, if you can handle a scheduled shutdown of instances (tons of AWS examples out there which we do not have to document) your spot or on-demand runners can safely terminate knowing they will come back ONLY when they are needed. This is a huge advantage over large, slow, clunky kubernetes clusters that run all day or, at best, allow for worker node shutdown at night. Huge drawbacks for kubernetes is 1) the control plane never shuts down and you are ALWAYS paying for it, 2) you configure one node for a volume size, they all get it and all keep it as you run it all day. Generally, Kubernetes nodes need to be pre-provisioned with large disks because they will not ‘grow and shrink’ throughout the day as they are not ephemeral and are not triggered by Github or Terraform. Terraform will provision your cluster and it will run whether you have developers using it or not! If you schedule worker nodes to come up in the morning, they run with a preset amount of disk, usually a lot of it, all day, whether it is used or not! This simply poor architecture that TLC has finally addressed in the tf-files. It can be pretty easily modified as needed, but does work pretty much as0is with little to know modification (other than the s3 backend storage bucket which we cannot name for you in advance).
The server comes up SELinux Permissive mode but easily toggled to enforcing by adding “setenforce 1” to your EC2 Instance User-Data before launch.
Select this AMI in market place, then simply Launch the AMI as any other AMI. Make sure you use a valid SSH key if you do not use the Terraform plan this image is built for.