🚀 On-Demand GitHub Actions Runners w/ Kubernetes Pods | Full DevOps Project Walkthrough

Hello friends, welcome back to my channel. In today's video, we are going to look at how to use ephemeral Kubernetes paths as GitHub actions self-hosted runners where we are going to execute CI/CD jobs using GitHub actions. But we don't want to use the default machines that are provided by GitHub. In a production environment, you have to set up your own servers or runners and then link them to the GitHub actions repository so that it will run your jobs for you for security reasons. and also to save money and time. So we are going to create a Kubernetes cluster and then we will use Kubernetes pods that will spin up on demand to execute our CI/CD jobs. Now once the job is executed, the pod would automatically shut down. That's also why we call it ephemeral parts. Like, comment, and subscribe to my channel for more videos like this. And now let's get into it. By the way, if you're new here, this is my channel right here. Like, comment, and subscribe. Also I've created a GitHub repository here called ephemeral part self-hosted GitHub actions runners. This is the repository that we are using for our project. Okay. Now for some prerequisites we need a GitHub account repository which is what we have here. We will install an actions runner control. This is what's going to be our operator for setting up the ephemeral part as our self-hosted runners. We need a kubernetes cluster. Of course, we'll use mini cube for that. We need keep cuddle helm. We also need set manager. Now, we need set manager because action runner control uses it for admission web hooks. This controller uses it to admit new parts to start working. And then we need runner skill set. Now, this runner skill set is the component that creates the ephemeral parts on demand. So, let's go into the project. So first you will start a community cluster. By the way I have a full readme here that you can easily follow and I have a terminal here. Again this is the same stuff that I have in the readmi. So first we need to start our cluster. I do mini cube version. Mini cube is already installed and I also have docker installed. So I'll use docker as my mini cube driver to set up my cluster. If I check docker ps there are no containers running at the moment. So I'll create my cluster here. And this cluster is creating using two CPUs and 7.9 gigs of memory. Our cluster is ready. So cube cuddle get nodes. That's our cluster right there. I'll use the readme here instead. Next, we need to install our search manager. Now to install set manager, you can just go to Google and type install search manager. Now you can either use helm or cube cut to install it. So it's really up to you. I will use cube cut instead. And you have a single line command here to install it. Copy this link. Again, I've attached this link in the readme file right here. This is this link. The same thing. Paste it here and run it. So it takes a bit to get ready. So give it a few seconds for it to get ready. All right, let's check the parts to see that everything is ready. And you can use skip cod get parts and the name space is set manager. I'll clear the screen here. And you can see all the set manager parts are running. So it's ready. Now for our next step, we will look at how to install the arc operator. Now the arc operator needs set manager. That's why we needed to install set manager first. Okay. So with our set manager running currently, our next step is to install the ALC operator. By the way, ARC operator is just the GitHub actions runners controller operator. Now this is what controls and listens to different components that orchestrates the running of different parts to build different jobs. Okay. So to install it first you need to set up your nameace because we using it as an environment variable in this command. So I just run the first command here to set up our name space arc systems or arc systems and then we will use helm copy this. So we have homem install arc and the name space is the name space we just set arc systems if it's not available this will create the name space from scratch and then we are referencing the location of our arc controller and this is from githubcr.io and it's using the runner skill set controller from the github actions. So press enter for this. All right. So it's successfully installed it and you can see that it's labeled our release as arc or arc. Now that's because when we are using home to install it we use home install arc. So whatever name you want it to be you give it right here or whatever name space too you can set it right there. But usually because it's uses home charts here to install it. Most of the time I use arc systems because it's like a default kind of name space. Once it's done, we can check our parts. But our name space is already set. So we can use an environment variable to reference the name spaces. Let me clear the screen here. We've got get parts. And you see our controller is running. This is one of the parts running right here. If you also want to verify that the arc operator has been added to the helm list, can just use helm list- a. And you see that it's added right here. and the version is.12.1. Now for our next step, we are going to create a GitHub personal access token. It is also the same token that we generated that we will use to create a Kubernetes secret so that there's going to be an access between our GitHub repository and our Kubernetes cluster. Now there are some scopes that you need to add to your personal access token. If you're using a repository then repo workflow admin reple hook is fine. If you're using GitHub apps then you may want to add admin or any other scopes that you want to add. So I'll open a new page to create a token. So go to your GitHub account here. Go to settings developer settings. personal asset token. You use the classic one. See, there's no token here. So, generate new and I'm using the classic one. And I'll call this ephemeral parts token. 30 days is fine. And then for the scopes, I'll say repo workflow. By the way, workflow is what helps you to run GitHub actions, CI/CD pipelines. If you want to add more or remove some of them, it's really up to you. Create token. Now, this is our token. So, I'll copy it. I'll just open another terminal here and I'll paste it here just in case I need it. At this point, we need to set some environment variables. One of it is our token. First one is we are setting a runner name space to runner NS and we will set that name space to arc runners. I'll run this first. Let's go back to the other terminal here by the screen. And then you will do same for the token. For the token, I'm calling it GitHub. And then I need to copy my personal access token. I still think I have it here. Yeah, this is it. I'll paste it here. Put it in double quotes. So, we've set that as an environment variable as well. Now with that set we can create the name space by using keep color create NS and then reference the name space name that we referenced up there. So paste this here to create the name space cuddle get name spaces and you see all the name spaces here. This is the one from set manager. We have the one from the AR controller which is AR systems and then we have one for the runners which we just created. Next is to create our Kubernetes secret and for that we use a command like this. Now this command is going to create secrets and it will call it a GitHub config and it will create it in the name space we just created. And for what it's going to use to create a secrets, it will use the GitHub personal access token that we set. Right? That's why we run this commands in there. So I will just copy this directly paste it here and run it. Now that is created. So if I do cube cut get secrets we are in the name space or a runners and this is the secrets we just created. Now with that ready the next step is to set up our runners skill set. Now this is what is going to act like a autoscaling component of our arc. This will scale down parts and scale parts up as well. Now to install the runner skill set. Now you need to set some environment variables just to make this command not too long. You will need an installation name. By the way, you need installation name because when you are running a CI/CD pipeline inside GitHub actions, you always specify runs on as some value. Now since we are using selfhosted parts, you have to set this as your runs on. That's why we need this as our installation name. For the name space, I'll use the previous one I used for the Kubernetes secret. So I'll run these two commands here for the environment variables where the screen. The other one is a name space. You're still in the same name space. And now we also need to set a URL. Now this URL I'm calling it GitHub config URL. Now to generate this URL you need to go to the GitHub repository that you created. This is our repo. So your URL is just going to be github.com/qu which is the GitHub account you're using and then the name of the repository that you're using. So that usually comes from the address bar right there except you don't have to add this tree and main which are the branches to it. Okay. So we set that as well. Now once you've set that the rest is just to run this helm install command here and it will just reference the installation name name space. If the name space is not available it will create it. You set your config URL. We just talked about it. You use this as your secret. That's a P access token and then it will reference the GitHub actions runner scale controller from GitHub actions. So I'll copy this past this here press enter and you can see that I have started it. So it's claiming that my release name is AR runner set. So that is our GitHub runner. So remember when you are running CI/CD pipeline you will see that when I put runs on the value that I will give it is going to be arc runner set right let's check if the controller sets and the skill sets are all running we can use helm you see both of them here and then of course you can check your pods for all the different parts that should be running for everything to work correctly. So you see your controller running and this is the runner set also running. At this point you should know that your GitHub actions self-hosted runner is waiting for jobs. So let's see. And of course I've added some notes here. You should see the controller port list port running. These components are always going to be in always on mode so that whenever there's a job then they get to work. If there's no job they will lay idle but it will show that they are running still in the background. If you also want to check the yak runners of course you can use this to check that. Next step is to create our CI job which is going to be a sample job. And I've created some simple script here. Now this script is just going to check out the code, check the OS release of the pod. We check the host name as well. And then we run some Python command like Python 3 version just to see the version of Python that is being run inside the pod. You can see that when we start the jobs build runs on has exactly what I mentioned earlier, the arc runner set. So I will copy this and use it to create our CI sample. Remember when you are creating a CI/CD on GitHub actions, it has to be inside the GitHub/workflows and then you give the file name. It always has to be within this directory right here. I'll use the other page that I created earlier. Go to repositories. This is my repo. I go to add files. Create new files. And then for the name, I'll use GitHub/workflows. So it's workflows with an S. It has to come with an S or you will get a fill job. And then for the file, I'll give it arcdemo. Workflows/ ARC demo.l yml and then I'll paste the content that I copied here. Get rid of this and this is going to be my CI/CD pipeline sample. I will commit these changes here. So this is our pipeline. Let's go back to our repository. So our pipeline is inside this directory here. Now, as soon as you commit changes or you push changes, this will trigger the CI/CD pipeline to run or if it doesn't start automatically, go to actions and you'll see there's create arc demo yiml right here. So, it looks like it's ceued already. Let's go to build. Now, it says this job is about to start. Okay. Now it's already running. This will run successfully, but I want us to also monitor it as we run it from our terminal just to be sure that the parts that we are saying they are capable of running the jobs are actually the parts running the jobs. So the first job is run. So we can't really do anything about it cuz it's kind of picks it up automatically. But let's watch to see if the parts will automatically get to work. So clear the screen here and now we use cube cuddle get parts specify the name space and then add d-watch. So it's open now. Leave this running and then I'm going to execute another pipeline. either rerun all jobs or I can just make a tiny change to our pipeline. Either of them will still trigger it. I'm going to make this page a little shorter so that we can see what's going on down here. All right. Now, hit rerun all jobs. So, you see parts being run. It's creating containers. It's running now. And build is going on. As soon as build is done, you see it's terminated. So build is done. It started terminating and it's completed termination. Right? So that's what I wanted to show you on this project here. How to use ephemeral parts for running GitHub ach. And by this it kind of helps you to save money. It saves time and it also helps you to be more secured especially with your infrastructure or code. Most of the CI/CD companies actually prefer that you have your own hosted runner and then you just use the platform to link that to it. Let's just go through the results here. So first it sets up the job with all the permissions and name spaces it needs. It will do the check out of our GitHub repository. We get the showrunner info. By the way, the showrunner info is this step. And this is asking for host name and the OS release. If you go in here, you can see the host name. That's our host name. And then that's our OS release is Ubuntu 22.04. That means the port actually run Ubuntu OS. That is showrunner info. The other step was to print the Python 3 version. This is Python 3.10.12. Let's try one more build just to verify. I will squeeze this up a little bit again. I'll go to rerun all jobs. Rerun. And you see this will be activated again. Yeah, it's creating a container. It's running. Once it's done, it starts terminating and it's completed termination. Now, for the last few steps, we just need to do a cleanup. You first have to remove all the name spaces that you created, right? Delete all of them. Stop your mini cube. And if you like, you can delete the mini cube cluster as well. Before then, you need to exit out of this using Ctrl C. Mini cube status or do mini cube stop. Then mini cube delete. that that should get rid of everything. Now I will attach the GitHub repository link to the description part of the video if you want to follow this project so you can easily go through it. Uh do not forget to subscribe to my channel. I'm still a young channel. I'm trying to grow. So like, comment, and subscribe to my channel for more videos like this. And I'll see you on the next one.