iamvikasbisht, Author at DEVOPS DONE RIGHT

GitHub: Self-Hosted Runner on Kubernetes

GitHub Actions is a powerful tool for automating software workflows, and it can be used to build, test, and deploy code right from GitHub. It provides a way to automate repetitive tasks and can be integrated with many popular tools and platforms.

GitHub Actions can use two types of runners: hosted and self-hosted.

Hosted runners are provided by GitHub and run on virtual machines in the cloud.
Self-hosted runners are machines that you set up and manage yourself. They run on your infrastructure, and you can customize them to meet your needs.

In this tutorial, we will show you how to set up GitHub’s self-hosted runner on Kubernetes.

Prerequisites

Before you begin, make sure you have the following:

A Kubernetes cluster
Helm Installed
Access to a GitHub repository for creating PAT and adding runners.

Know the Role of K8S Service Account in Granting Access

Have you ever wondered that when you access the API Server through kubectl you are authenticated through the API controller, but how will you do the same from the pod side? Here the Service Account role comes into play. As k8s definition itself says “Processes in containers inside pods can also contact the apiserver. When they do, they are authenticated as a particular Service Account (for example, default).”

Things we should know about service Account,

Created in a namespace.
Used to allow processes inside pods, access to the API Server.
Default service account = default (no access to the API server).
Create your own service account.
- Use it in a RoleBinding or ClusterRoleBinding.
- Use the service account secret to obtain the authentication token & CA certificate.

What we will be covering today,

Creating a pod (that gets automatically created in default Service Account)
Will create a Service Account
Creating a deployment that will be using appsa Service Account.
RBAC

Debugging in Shell Script

What is Shell?

The UNIX shell program interprets user commands which are either directly entered by the user, or which can be read from a file called the shell script or shell program. Shell scripts are interpreted, not compiled. The shell reads commands from the script line per line and searches for those commands on the system.

The below command is used to check known shells in a UNIX system.

root@localhost$ cat /etc/shells 
# List of acceptable shells for chpass(1).
# Ftpd will not allow users to connect who are not using
# one of these shells.

/bin/bash
/bin/csh
/bin/dash
/bin/ksh
/bin/sh
/bin/tcsh
/bin/zsh

To change the shell, just write down the shell name; since a shell is an executable file (program), the current shell activates it and it gets executed. A new prompt is usually shown because each shell has its typical appearance.