GitHub has introduced its open-source platform for continuous integration and continuous delivery (CI/CD) “GitHub Actions”. Since its inception, GitHub Actions has gained overwhelming prominence and offers all the necessary utilities to streamline phases of the software development lifecycle including development, troubleshooting, testing, and deployment. Undoubtedly, it is one of the most preferred platforms of the DevOps teams that ensure rapid deployment and top-notch infrastructure security, and workflow automation.
The entire workflow automation is based on triggering the defined actions against particular events. These actions are based on a multitude of jobs in its VM framework runner that are intended to achieve one or more steps as you defined in your actions’ sequence.
In this guide, we are going to host a containerized app with the following key components of G42 Cloud using GitHub Actions.
- VPC (Virtual Private Cloud)
- Subnets (logical segmentation of entire network infrastructure)
- Routing Tables (To enable you to create customized network routes)
- CCE (Cloud Container Engine)
- Container Registry (To manage, pull, and push Images)
- SFS (Scalable File Server – A Low latency storage for high-performance computing solutions)
The Components of GitHub Actions
Before getting into creating a workflow to host containerized apps with GitHub Actions, let’s discuss some mandatory terminologies & key ideas that are going to be the core of our entire process.
- Workflows – The workflow is defined as an automated process that carries one or more jobs simultaneously. A workflow can be defined in a .yml file in your repository that will be called for action after being triggered by a particular event. You can define multiple workflows in the GitHub repositories (short: Repos) to carry out a range of jobs in a defined sequence and schedule.
- Events – Events are the prime activities that trigger your defined workflows once they happen in your GitHub Repos. For instance, Push a commit, or create a pull request.
- Jobs – A set of instructions implemented in response to particular events in accordance with the sequence or schedule defined in a workflow is called a Job. The jobs can be executed in series (following a defined sequence) or in parallel. If particular jobs are executed in series it means every leading job depends on the completion of the preceding one. Whereas, the jobs that lack any dependencies can be executed in parallel.
- Actions – An action is a customized app used to eliminate the iterative code during the workflow execution. You can leverage over 15000 default Actions offered by the GitHub Marketplace and also define your customized actions.
- Runners – They can be on-premise or self-hosted (Runner SaaS) infrastructures used to execute workflows. Each workflow is able to dynamically provision new runners via cloud APIs.
Setting up a Workflow – GitHub × Terraform × G42 Cloud
The setup below is intended to create a workflow that gets triggered against an event of code being pushed into the main GitHub repository. We will be using workflow jobs that streamline Terraform to implement the resources offered by the G42 cloud.
Prerequisites to Workflow Automation in GitHub
- A GitHub account with Actions turned to enabled
- G42 Account credentials including
- G42 Account name
- G42 Country/Region name
- G42 Access Key
- G42 Secret Key
- Terraform configuration files to administer resources (We are going to use G42 resources but it is not mandatory as you can use your preferred cloud resources).
For G42 account credentials, you can utilize IAM User (a cloud resource in IAM with relevant credentials and permissions) to get these credentials. Terraform will use IAM User uses credentials & permissions to validate the resources of G42 Cloud. In the following setup, we will be depending on Terraform Registry for G42 Cloud as our primary infrastructure.
Terraform for GitHub Actions
Terraform is an Infrastructure as a Code (IaaC) utility that ensures users develop and administer both cloud-native and in-house frameworks in a human-understandable configuration that can be shared, reused, and validated. These configuration files are based on Terraform HCL.
So Let’s start with the initial setup by setting up a GitHub repository for our resources.
- Visit GitHub’s login portal and Sign in with your Username/Email and Password.
2. After signing in to GitHub, click on the “Create Repository” button at the left panel of your window.
The next step is to “Push” your Terraform code into the new repository.
3. Now, to add secrets to your repository, go to Settings on your repository. In the Security section, click on the “Actions” option under the Secrets dropdown menu.
Settings window for the repository your created
4. In the new window, click on the “New Repository Secret” button. Then, label your secret, add value, then hit the “Add secret” button. (Repeat step 1-4 to add all the relevant credentials)
Actions window to set secret for new repository
5. In the .yml file, the snippet for the code shown below is intended to trigger a workflow when a “Push” event occurs on the main branch.
Code snippet to trigger workflows against a “Push” event
6. The next step is to define the job with all the necessary steps that a job is expected to execute as a response to the event on the main branch.
????[In the said case, Terraform is the job that executes on Ubuntu Runner with predefined sequences of steps that a job is intended to perform. You can define one or more than one sequence under the same job. In simple words, a job is the collection of one or many steps with the sequence defined by the user. The secrets you stored are the references for the environment variable with its values being fetched from the Action’s secret we defined in step 4.]
Code snippet to run jobs on Ubuntu Runner
7. Here is the final workflow configuration for our GitHub repository.
You can also check the execution logs for your pipeline in the following section.
Verify Deployment on G42 Cloud
Upon successful completion of the pipeline, you can verify the resources you created for the G 42 framework.
- Open G 42 Cloud Login Portal and sign in with your Username/Email & Password.
G42 Cloud – Log In Screen
G42 Dashboard – Main Screen
2. In the left panel, click on the “Resource Management” option. Then, click “Network” from the dropdown menu.
G42 Resource Management > Network
How TecBrix can Help You with Developing CI/CD Pipelines for G42 Cloud Deployment?
Cloud is where our expertise lies. TecBrix is a cloud-focused solutions provider with its headquarters based in the UAE. Our experienced team with proven experience in Application Development, Big Data, Data Preparation, DevOps, Infrastructure Security, and CI/CD Workflow is fueling the digital revolution in various sectors around the globe.
We at TecBrix, provide different Cloud & DevOps automation services to our clients, including;
- Cloud Consultancy (For Amazon, Azure, AWS, Huawei, & OpenShift)
- Cloud Migration
- Cloud Optimization
- Cloud Security
- DevOps Consultancy (Docker, Kubernetes, & Terraform)
- DevOps Managed Services
Our highly skilled and professional cloud experts with proven experience in completing enterprise-scale projects on the G42 framework & developing CI/CD pipelines are next to none. If you want to gain access to the exceptional talent of the industry to automate & optimize your workflows with CI/CD pipelines, feel free to connect with TecBrix.
Conclusion
We have covered the general configuration process that is intended to integrate Terraform with GitHub Actions and enable the allocation of your on-premise or cloud infrastructure to a GitHub workflow in a different set of processes on the G42 cloud service.
GitHub Actions allow you to automate your workflows to respond to an event in your GitHub repositories. To effectively automate your complex and repetitive workflows, GitHub provides support to Linux, Microsoft Windows, & Mac VMs with the liberty to execute workflows on cloud or on-premise network infrastructures.