Using the features of cloud providers like AWS and GCP, we can create Infinitely scalable GitHub Actions runners on Cloud but why do we need them?
Understanding The Problem
In the tech world, everyone wants CI/CD. As we all know GitHub Actions is a CI/CD platform used to automate the builds, test, and deployment process. GitHub Actions uses workflows to automate the whole process. We can run the builds and tests on every push and pull request, or even on merging the pull request with workflows. For all this GitHub Actions use its cloud machines but also they have some limitations.
GitHub Actions does not provide support for custom images, or customized configurations of hardware. Sometimes users need a custom image to complete their build and run tests on it according to their use case. Also, GitHub Actions provides a fixed configuration of the systems.
It does not provide users with GPU instances. When working on stuff like MLops that may requires GPU to build.
GitHub Actions provide you with limited execution time for each run in a workflow that is 6 hours. If a job takes more than this time to execute it will automatically terminate. GitHub provides you with 2000 minutes/month and 500 MB of free storage. To use beyond these limits we have to pay some amount. You can see the pricing here.
What if we can automate this whole process on our cloud and have minimum cost?
Definitely, we can do this on our cloud using GitHub actions feature self-hosted runners and Cirun. Also, we can reduce the cost by doing Infinitely scalable GitHub Actions runners on the cloud with Cirun.
About Cirun and Infinitely scalable runners
Cirun provides self-hosted GitHub Actions Runners on your clouds.
Before understanding the flowchart let's understand:
How does Infinitely scalable Runners works?
Sometimes we may don't have limit of time and we want the minimum cost of our process. Clouds like AWS and GCP allow us to do so with an option. In the case of AWS, it is SPOT. A spot instance allows us to make a machine whenever capacity is available with no time constraints. To automate this whole process, Cirun provide us with a flag named
preemptible. When we pass value true, It creates the cheapest self-hosted VM.
We can see whenever an event is triggered on the repository. GitHub sends a webhook to cirun. Cirun authenticates the cloud using credentials provided by you. It takes Machine configurations and
preemptible flag defined in
.cirun.yml from your GitHub repository and sends a request to the cloud for Spot instance. Cloud keeps checking for available capacity. Whenever it meets its conditions, the cloud will create a spot instance using
.cirun.yml file, and then all workflow files defined on the GitHub repo will run on the instance. Besides all of this, Cirun continuously checks whether the workflow is completed and the machine is idle or not? If condition is satisfied then cirun delete's the VM. By doing this we have minimum cost for our desired machine.
This blog explains how to set up Infinitely scalable GitHub Actions runners on AWS with Cirun. For reference, you can check cirun documentation.
The steps are almost the same for other cloud providers which provide the scalable option.
- In Cirun, log in with GitHub
- Install Cirun on your Repository
- Toggle on the Repository to activate.
- Pass your cloud credentials and connect AWS with Cirun
- Add workflow file and
.cirun.ymlfile on your repository
.cirun.ymlalong with machine config also specify the flag
- Now push a trigger in your Repository
It's done! 🚀
In Cirun login with GitHub
Install Cirun on your Repository
- Configure Cirun
- Give access to repositories
- To activate the repository toggle the button.
Adding AWS to Cirun
- Navigate to IAM user.
- Paste your Access key Id and Access Secret key in Cirun dashboard
Add Workflow file on your Repository
aws.yml file inside
.github/workflows. In workflow you can put jobs you want. For example paste the yml file given below to print the system info, memory, architecture. For latest file you can visit GitHub repo.
name: AWS on: [push] jobs: build: runs-on: [self-hosted, cirun-aws-runner] steps: - uses: actions/checkout@v3 - name: System Info run: | uname -a - name: Print Memory run: | free -m - name: Print Architecture run: | dpkg --print-architecture
Now add a
.cirun.yml file in your Repository
In this yml, we define the configuration and flags we want on your clouds (AWS, GCP, Oracle, etc.), instance_type, and machine_image. For Infinitely scalable GitHub Actions runners we must have pass flag
To explore more you can visit cirun documentation.
In this blog, we are creating
.cirun.yml file for the AWS cloud with the infinitely scalable runner.
runners: - name: "aws-runner" cloud: "aws" instance_type: "t2.micro" machine_image: "ami-05e786af422f8082a" preemptible: "true" workflow: .github/workflows/aws.yml labels: - "cirun-aws-runner"
Pushing a trigger
- To trigger an event we must commit something in our repo.
- With a new commit, cirun sends a request to the cloud then the cloud makes a spot instance and runs the workflow
- Printed the system info, memory info, system architecture.
GitHub Actions provide us with self-hosted runners for your repository but setting up them is a tedious task. You can automate the set-up process using cirun. Cirun charges some amount for private repositories and you have to pay for what you use on your cloud. Cirun supports all major cloud providers at this time. (AWS, GCP, Digital Ocean, Azure, Openstack, Oracle).
For more information you can visit cirun.io.
If you have any questions and feedback about this blog, feel free to comment or reach out Cirun.io.
Top comments (0)