Arm Community
Arm Community
  • Site
  • User
  • Site
  • Search
  • User
  • Groups
    • Research Collaboration and Enablement
    • DesignStart
    • Education Hub
    • Innovation
    • Open Source Software and Platforms
  • Forums
    • AI and ML forum
    • Architectures and Processors forum
    • Arm Development Platforms forum
    • Arm Development Studio forum
    • Arm Virtual Hardware forum
    • Automotive forum
    • Compilers and Libraries forum
    • Graphics, Gaming, and VR forum
    • High Performance Computing (HPC) forum
    • Infrastructure Solutions forum
    • Internet of Things (IoT) forum
    • Keil forum
    • Morello Forum
    • Operating Systems forum
    • SoC Design and Simulation forum
    • 中文社区论区
  • Blogs
    • AI and ML blog
    • Announcements
    • Architectures and Processors blog
    • Automotive blog
    • Graphics, Gaming, and VR blog
    • High Performance Computing (HPC) blog
    • Infrastructure Solutions blog
    • Innovation blog
    • Internet of Things (IoT) blog
    • Operating Systems blog
    • Research Articles
    • SoC Design and Simulation blog
    • Smart Homes
    • Tools, Software and IDEs blog
    • Works on Arm blog
    • 中文社区博客
  • Support
    • Arm Support Services
    • Documentation
    • Downloads
    • Training
    • Arm Approved program
    • Arm Design Reviews
  • Community Help
  • More
  • Cancel
Arm Community blogs
Arm Community blogs
Infrastructure Solutions blog Auto-scale CI/CD deployment with GitHub actions and Arm-based Kubernetes clusters
  • Blogs
  • Mentions
  • Sub-Groups
  • Tags
  • Jump...
  • Cancel
More blogs in Arm Community blogs
  • AI and ML blog

  • Announcements

  • Architectures and Processors blog

  • Automotive blog

  • Embedded blog

  • Graphics, Gaming, and VR blog

  • High Performance Computing (HPC) blog

  • Infrastructure Solutions blog

  • Internet of Things (IoT) blog

  • Operating Systems blog

  • SoC Design and Simulation blog

  • Tools, Software and IDEs blog

Tags
  • cicd
  • aws
  • Open Source Software
  • Graviton2
  • Neoverse N1
  • infrastructure
Actions
  • RSS
  • More
  • Cancel
Related blog posts
Related forum threads

Auto-scale CI/CD deployment with GitHub actions and Arm-based Kubernetes clusters

Pranay Bakre
Pranay Bakre
January 6, 2022
7 minute read time.

GitHub is one of the most popular Git-based Source Code Management and DevOps tools. GitHub has over 73m developer community (1) contributing to over 170m pull requests and 61m+ new repositories created in 2020. It’s a code hosting platform that lets developers work together on projects. With GitHub Actions – a set of commands that help to automate software development tasks – GitHub added CI/CD capabilities to its SCM system. Now developers can build and test their code in their repositories.

A runner is a server that has the GitHub Actions runner application installed. You can use a runner hosted by GitHub, or you can host your own. A runner listens for available jobs, runs one job at a time, and reports the progress, logs, and results back to GitHub. CI/CD (Continuous Integration, Continuous Delivery) is key towards a successful DevOps practice. With GitHub Actions, developers can run CI and build, test and deploy applications.

GitHub introduced support for self-hosted Arm Neoverse-based GitHub Action Runners for developers to natively add AWS Graviton2-based Amazon EC2 instances to their CI/CD workflows.

AWS Graviton processors are custom built by Amazon Web Services using 64-bit Arm Neoverse cores to deliver the best price performance for your cloud workloads running in Amazon EC2. They power Amazon EC2 general purpose (M6g, M6gd, T4g), compute optimized (C6g, C6gd, C6gn), and memory optimized (R6g, R6gd, X2gd) instances, that provide up to 40% better price performance over comparable current generation x86-based instances for a wide variety of workloads. These include application servers, micro-services, high-performance computing, CPU-based machine learning inference, video encoding, Electronic Design Automation, gaming, open-source databases, and in-memory caches.

GitHub Actions lets you execute and automate their CI/CD workflows with the help of self-hosted runners. Developers can set up their code pipelines and build/test applications on Arm-based GitHub Action Runners. This empowers the developers with multi-arch pipelines, however, when the runners are not in use and sitting idle, they incur huge costs. With Arm based AWS Graviton2 instances customers can benefit from 20% less cost than comparable x86 based instances. The savings are greatly increased when the runners are dynamically managed with the execution of a code pipeline.  

Use case: Auto-scale CI/CD deployment with GitHub Actions and Arm-based Kubernetes clusters

In the diagram below, we showcase how developers can scale their CI/CD practices leveraging Arm-based GitHub Action runners (GHA) on AWS Graviton2 instances:

  • A GHA runner is deployed automatically on code commit, performs the job, and is destroyed on completion of the pipeline
  • This autonomous process results in reduced costs by removing the need for keeping static cloud-based runners
  • A GitHub repository hosts the source code of a Wordpress application. When a code change is committed to the repository, a GHA runner is automatically deployed and picks up the build job
  • The runner executes the code, builds the container image, pushes it to Amazon ECR registry and deploys the container in an Arm-based Amazon EKS cluster
  • This cluster is running on Arm Neoverse based Amazon EC2 M6g instances

 GitHub on Kubernetes architecture

Take a look at the following video showing the DevOps workflow of this use case:

Configurations 

Prerequisites

  • Amazon EKS cluster with AWS Graviton2-based worker nodes
  • AWS CLI configured
  • IAM roles to create Lambda functions
  • GitHub account access and repo created

Create the actions runner's image by following the steps below:

Navigate to the home directory on Arm-based EC2 instance (M6g.large). It is typically the following directory -

/home/ec2-user

Install expect and jq with the following command:

sudo yum update -y
sudo yum install jq, expect -y

Install docker and provide ec2-user with needed permissions.

Use the following command to create your runner folder and change the current directory to it.

mkdir actions-runner; cd actions-runner

Download a new runner package using the following command:

curl -O -L https://github.com/actions/runner/releases/download/v2.273.2/actions-runner-linux-arm64-2.280.1.tar.gz

Unpack the runner's binaries to the folder you created with the next command:

tar xzf ./actions-runner-linux-arm64-2.280.1.tar.gz

Navigate to /home/ec2-user/actions-runner. Using the text editor create file script.exp and paste the contents of this file. Verify the contents with the cat command:

After script and binaries are edited and added, exit the ssh connection and navigate back to EC2 Dashboard. Create an AMI of the EC2 instance. The runner image is now created. We use it with the Lambda function as mentioned below

Create AWS Lambda function for GitHub Actions Runner

In AWS console, navigate to AWS Lambda and on the dashboard select the Create function. Provide a Name for the function, select Python 2.7 runtime and select an IAM Role

In the function, scroll down to the Basic settings and select Edit. Set the Handler to "lambda_function.lambda_to_ec2" and save it.

 Edit basic settings

In the function code, please add this script and update with relevant environment details.  

Scroll up and save the changes.

On the same screen, scroll down to Triggers. Select Add Trigger.

Select the API Gateway. Create an API based on HTTP API type with the security type and default deployment stage.

 Trigger configuration

After Trigger is created, we should be able to see the details in the Designer section. Here we can find the API Endpoint.

 API Endpoint

Now, let’s create a GitHub Webhook to trigger Lambda function.

In our GitHub repo navigate to Settings, then select Webhooks

Select Add Webhook and add the API Gateway endpoint into Payload URL section. After the webhook is created, the lambda function will trigger on every push to the repository.

 Manage Webhooks

Kubernetes workflow

On the image builder instance, ensure that the pre-requisites are met by installing docker, awscli, and kubectl.

Use a text editor of your choice to edit the script.exp file by adding a Pod-runner tag.
On the image builder VM, please navigate to the actions-runner folder.

Now use the text editor to create selfconfig.sh script. This script will install the needed tools on the future runner containers. Now we add a script that is our entry point for the docker container. Use the text editor of your choice and create runner.sh script.

Now let’s create a Dockerfile with this content and build the docker image. Tag the image as shown below

docker build ./ -t arm-runner

Create an AWS ECR repository for the runner image. In the AWS management console, navigate to the Elastic Container Registry page and create a repository for the docker image.

After the repository is created, go to the image builder instance and login to ECR and push the docker image.

Now, let’s create a master-runner. It is an AWS Graviton2-based actions runner that deploys pod runners to EKS. We can use the Lambda function to deploy the Pod runners.
Let’s create the master-builder by cloning the existing image-builder machine by using AMI. 

Register the master-runner with GitHub and add the Master-Runner tag using the following command.

TOKEN=$(/usr/bin/curl --user "<GitHub username>:<GitHub PAT>" -X POST -H "Accept: application/vnd.github.v3+json" https://api. github.com/repos/<username>/<repository name>/actions/runners/registration-token | /usr/bin/jq '.token' | /usr/bin/awk -F\\" '{print $2}')

echo $TOKEN > /home/ec2-user/actions-runner/token.file chmod 755 /home/ec2-user/actions-runner/token.file ./config.sh --token $TOKEN


 Self-hosted runners

Use the same page to add the Pod-runner tag to the Runner-Placeholder.

Execute the following command:

sudo ./svc.sh install

sudo ./svc.sh start

The master runner is set up. Now let's create Kubernetes job manifest to deploy runners. Create job-runner.yaml file with this content.

In our repository, let’s create a CI YAML file wf-ci.yaml under:

<Repo Name>/.github/workflows/.

In this yaml file, we separate the workflow into two jobs. The masterbuild job runs on the master-runner, that deploys a pod runner to the EKS cluster. The runnerbuild job runs on Pod-runner, so it is queued until the container with the runner is deployed to EKS. It runs a simple sleep command for 20sec for demo purposes. To run some specific tasks with the specific instruments, those instruments should be added to a Dockerfile of the runner.

To start the workflow, commit a change to the repository by adding a new file. After committing the change, navigate to the Actions tab of the GitHub repository page.

We will see the masterbuild job run first, and then the runnerbuild job is waiting for the runner container. When the runner container is deployed, the runnerbuild job starts.

 armisv demo Update wf2-ci.yml

We can also see the newly deployed pod runner in the list of runners on the GitHub page. After both jobs are completed, the pod runner will remove itself from GitHub automatically.

 Self-hosted runners

Conclusion

As shown above, we can use self-hosted GitHub Actions runner to build our CI/CD system on AWS Graviton2 based EC2 instances. It can help in bringing down the overall cost of the build components by 20%. By adding auto-scaling and on-demand capabilities to our existing CI/CD infrastructure, we can mitigate the need to have static runners configured that incur additional costs. Please feel free reach out to us with any additional comments, questions, or concerns around GitHub Actions runner on Arm.

Explore Developer Resources

Anonymous
Infrastructure Solutions blog
  • Improve Apache httpd performance up to 40% by deploying on Alibaba Cloud Yitian 710 instances

    Martin Ma
    Martin Ma
    In this blog, we look at the advantages of using Alibaba Yitian 710 CPU Arm-based instances for Apache httpd compared to x86-based instances.
    • January 5, 2023
  • Deep learning inference performance on the Yitian 710

    Honglin Zhu
    Honglin Zhu
    In this blog post, we focus on Alibaba Elastic Cloud Service (ECS) powered by Yitian 710 to test and compare the performance of deep learning inference.
    • December 19, 2022
  • Improve NGINX performance up to 32% by deploying on Alibaba Cloud Yitian 710 instances

    Ker Liu
    Ker Liu
    In this blog, we look at the advantages of using Alibaba Yitian 710 CPU Arm-based instances for NGINX compared to x86-based instances.
    • December 14, 2022