DEV Community: Narender Kumar Sharma

GitHub Actions runners on Oracle Cloud with Cirun.

Narender Kumar Sharma — Thu, 29 Dec 2022 15:17:49 +0000

Understanding The Problem

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 run workflows on desired machine?

Definitely, we can do this on our cloud using GitHub actions feature self-hosted runners and Cirun. Also, we have to pay what we are using.

About Cirun

Cirun provides self-hosted GitHub Actions Runners on your clouds.

From Flowchart

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 defined in .cirun.yml from your GitHub repository and sends a request to the cloud for creating instance. The cloud will create a 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, and we have to pay what we used.

This blog explains GitHub Actions runners on Oracle Cloud with Cirun.. For reference, you can check cirun documentation.

The steps are almost the same for other cloud providers.

In Cirun, log in with GitHub
Install Cirun on your Repository
Toggle on the Repository to activate.
Pass your cloud credentials and connect Oracle with Cirun
Add workflow file and .cirun.yml file on your repository
Now push a trigger in your Repository

It's done! 🚀

Demo

In Cirun login with GitHub

Install Cirun on your Repository

Configure Cirun
Give access to repositories
To activate the repository toggle the button.

Adding Oracle cloud to Cirun

NOTE: Make sure you have permissions to create VMs/runners.

Navigate to profile.

Click on API keys
After clicking on Add api key, download private key and hit add button.
After adding, you will have this kind of configuration file. Copy user, fingerprint, tenancy and paste them in text file.
Then navigate to compartments and copy ocid, then paste this inside text file as compartment_id=.

Paste your text saved in text file and downloaded private key in Cirun dashboard under cloud section.

Add Workflow file on your Repository

Create a oracle.yml file inside .github/workflows. In workflow you can put jobs you want. For example paste the yml file given below to print the hostname, system info, memory, architecture, OS version. For latest file you can visit GitHub repo.

name: GitHub Actions on Oracle Cloud

on: push
jobs:
  build:
    runs-on: [self-hosted, oracle-cloud]

    steps:
      - uses: actions/checkout@v3
      - name: Get Hostname
        run: |
          hostname
      - name: Get system Information
        run: |
          uname -a
      - name: Get Architecture
        run: |
          dpkg --print-architecture
      - name: Get system Disk space
        run: |
          df -h
      - name: Get OS version
        run: |
          cat /etc/*release
      - name: Run "lscpu"
        run: lscpu
      - name: hello world
        run: echo hello world
      - name: Todays Date
        run: date

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. 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:
  runners:
  - name: oracle-runner
    cloud: oracle
    instance_type: VM.Standard.E2.1.Micro
    machine_image: ocid1.image.oc1.uk-london-1.aaaaaaaavy5v3inu2ho2h57vwvvsclukdh4jvhg45um2nrejyxa7s46zcwoq
    region: uk-london-1
    workflow: .github/workflows/oracle.yml
    labels:
      - oracle-cloud

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 instance and runs the workflow

Printed the hostname, system info, memory, architecture, OS version.

Conclusion

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.

References

If you have any questions and feedback about this blog, feel free to comment or reach out Cirun.io.

Infinitely scalable GitHub Actions runners on AWS with Cirun

Narender Kumar Sharma — Thu, 29 Dec 2022 15:17:30 +0000

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.

From Flowchart

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.yml file on your repository
In .cirun.yml along with machine config also specify the flag preemptible: true
Now push a trigger in your Repository

It's done! 🚀

Demo

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.

Add users
Add user with credential type programmatic access

Add user with permission AmazonEC2FullAccess
Generate Access key ID and Access Secret key

Paste your Access key Id and Access Secret key in Cirun dashboard

Add Workflow file on your Repository

Create a 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 preemptible: true.
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.

Conclusion

References

If you have any questions and feedback about this blog, feel free to comment or reach out Cirun.io.

MLOps on GitHub Actions with Cirun

Narender Kumar Sharma — Thu, 29 Dec 2022 15:17:09 +0000

MLOps is very useful in ML world and when run on GPUs they are way faster. To have an idea how fast MLOps on GPUs, here we are doing comparison of MLOps on CPU and GPU using GitHub Actions and Cirun.

About MLOps and it's uses

MLOps is set of practices that establishes a smooth connection from the creation of the ML models to the production. MLOps continues by concentrating on the upkeep and overall monitoring of Machine Learning Engineering. MLOps reduce friction with DevOps and IT, allows better cooperation with data teams, makes ML pipelines reproducible, and speeds up the process.

Why MLOps are better on GPUs?

As ML models uses too many mathematical algorithms and demands to train the different data on same code and GPUs are designed to do so. So, whenever we do ML operations on GPUs, it will be done effectively and also minimize the computing time complexity.

How Cirun might help to do this?

Cirun enables us to create GPU enabled virtual machines on our cloud. It minimize the gap between GitHub Actions and automation of self-hosted runners. By using this feature we can automate MLOps on desired GPUs.

Setup of MLOps on CPU and GPU using GitHub Actions and Cirun for comparison

In first step created a workflow for MLOps to be run on a GitHub Actions machine having CPU and on a Self-hosted runner having GPU.
Then for MLOps we have to make ML friendly environment. For this we used CML, which is an open-source CLI tool for implementing CI/CD with a focus on MLOps. CML uses custom Docker images that come pre-installed libraries that are essential for MLOps like NodeJS, Python, DVC (Data Version Control).
To setup CML environment on CPU use docker container mentioned below.

image: "docker://dvcorg/cml-py3:latest"

To setup CML environment on GPU use docker container mentioned below.

image: "ghcr.io/iterative/cml:0-dvc2-base1-gpu"

Followed by container argument.

options: "--gpus all"

This is very important to pass the GITHUB_TOKEN to have a working workflow. So, that authentication is done on behalf of GitHub Actions. You can have look to GITHUB TOKEN.

- name: "MLops"
        env:
          repo_token: "${{ secrets.GITHUB_TOKEN }}"

Machines used for comparison:-

For MLOps on CPU, we used GitHub-hosted runners which only provides CPUs to work with.

Hardware configuration of GitHub Actions machine.

2-core CPU (x86_64)
7 GB of RAM
14 GB of SSD space

For MLOps on GPU, we used Self-hosted runners with NVIDIA T4 GPU.

In example we used AWS instance g4dn.xlarge to demonstrate MLOps on GPU.

To configure GPUs using self-hosted runner see Cirun Configuration.

Hardware configuration of instance g4dn.xlarge.

NVIDIA T4 GPU
4-core CPU (x86_64)
16 GB of RAM
125 GB of SSD space

Workflow used for comparison

This workflow created jobs for two runners, one is for self-hosted using GPU and another one is for GitHub action runner using CPU. To review the latest version of this workflow in this repository.

Also you can directly copy workflow for single runner. MLOps using GPUs

name: "GitHub Actions with your own GPUs"
on: 
  push:
    branches: [ "none" ] # When a push occurs on a branch workflow will trigger on your desired branch.
  workflow_dispatch: 
jobs:
  CPU_GPU_matrix: # Creating matrix for jobs.
    strategy:
      matrix:
        # Creating a 2d matrix to execute our jobs with respective docker containers.
        os: ["ubuntu-latest", "cirun.gpu"] 
        containers: ["docker://dvcorg/cml-py3:latest" , "ghcr.io/iterative/cml:0-dvc2-base1-gpu" ]
        container_arg: [" " , "--gpus all"]
        # Excluding the unwanted docker container and container_arg in our respective OS.
        exclude:
          - os: "ubuntu-latest"
            containers: "ghcr.io/iterative/cml:0-dvc2-base1-gpu"
          - os: "ubuntu-latest"
            container_arg: "--gpus all"
          - os: "cirun.gpu"
            containers: "docker://dvcorg/cml-py3:latest"
          - os: "cirun.gpu"
            container_arg: " "
    # Workflow to run commands in OS.
    # Dynamic passing of os, containers, container_agr using matrix 
    runs-on: "${{ matrix.os }}" 
    container:
      image: "${{ matrix.containers }}"
      options: "${{ matrix.container_arg }}"
    # Steps that we want to have with OS.
    steps:
      - uses: "actions/checkout@v3"
      - name: "Dependency Install"
        run: "pip install -r requirements.txt"
      - name: "MLops"
        env:
          repo_token: "${{ secrets.GITHUB_TOKEN }}"
        run: |
          # Your ML workflow goes here, you can pass your variable name
          "python train.py"

Conclusion

Comparison of time complexities:

Example repository uses a workflow to run MLOps on CPU and GPU using Cirun and returns execution times.

You can see the Time complexity difference in CPU and GPU here.

In this image we can clearly see that GPU is 5.53 times faster then CPU and we can choose between two.

How Cirun helped us to do this?

Cirun provides us with feature to create On-demand Self-Hosted Github Actions Runners with any configuration on our cloud. We also know that MLOps operates more efficiently on GPUs. Therefore we automated the entire process with GPU.
Using Cirun we created a machine on AWS with NVIDIA T4 GPU and performed our operations. As a result we can see the huge difference between time complexities of MLOps using CPU and GPU.

References

If you have any questions and feedback about this blog, feel free to comment or reach out Cirun.io.

DEV Community: Narender Kumar Sharma

GitHub Actions runners on Oracle Cloud with Cirun.

Understanding The Problem

What if we can automate this whole process on our cloud and run workflows on desired machine?

About Cirun

From Flowchart

Demo

In Cirun login with GitHub

Install Cirun on your Repository

Adding Oracle cloud to Cirun

Add Workflow file on your Repository

Now add a .cirun.yml file in your Repository

Pushing a trigger

Conclusion

References

Infinitely scalable GitHub Actions runners on AWS with Cirun

Understanding The Problem

What if we can automate this whole process on our cloud and have minimum cost?

About Cirun and Infinitely scalable runners

How does Infinitely scalable Runners works?

From Flowchart

Demo

In Cirun login with GitHub

Install Cirun on your Repository

Adding AWS to Cirun

Add Workflow file on your Repository

Now add a .cirun.yml file in your Repository

Pushing a trigger

Conclusion

References

MLOps on GitHub Actions with Cirun

About MLOps and it's uses

Why MLOps are better on GPUs?

How Cirun might help to do this?

Setup of MLOps on CPU and GPU using GitHub Actions and Cirun for comparison

Machines used for comparison:-

For MLOps on CPU, we used GitHub-hosted runners which only provides CPUs to work with.

For MLOps on GPU, we used Self-hosted runners with NVIDIA T4 GPU.

Workflow used for comparison

Conclusion

Comparison of time complexities:

How Cirun helped us to do this?

References

Now add a `.cirun.yml` file in your Repository

Now add a `.cirun.yml` file in your Repository