GitLab CI CD | Install and Configure GitLab Runner on Kubernetes with Helm

hey what's up everybody my name is moss and in this video I'm going to show you how to run gitlab runner inside of a kubernetes cluster in order to follow along with the tutorial you'll need a gitlab server you'll need a Kate's cluster that you can administrate the cube cuddle a CLI tool installed and the helm client installed as well in this tutorial I'm only going to focus on installing and configuring the gitlab runner program on a kubernetes cluster via a Helm chart that's provided by gitlab and I hope you enjoy this video and if you do please consider throwing a like on the video and subscribing to the channel for more videos like this foreign so the first thing that I want to do is provide a quick refresher on how the gitlab runner program works specifically the type of executors that are available if you're not familiar with how the gitlab runner program works I suggest you take a look at my prior video where I go into more detail about how the program works and what executors are and how they work but I'll provide a kind of a refresher here so when you install the gitlab runner program on a machine you have to specify the executor and the executor is basically um a way to specify the runtime environment for gitlab CI pipeline jobs and one of the first environments the runtime environments or the first executor is the shell executor and so it's going to execute a pipeline job on in the Shell environment of the machine that the gitlab runner is installed on with other executors you can like the docker executor you can actually have the gitlab runner program spin up a Docker container and execute the pipeline job within that container so the executor that we are going to be using in this video is the kubernetes executor for gitlab Runner and with the kubernetes executor the gitlab runner program will either be running inside of a kubernetes cluster or it will be running outside of a kubernetes cluster connecting to that cluster and then spawning pods within that cluster that will be running the gitlab CI pipeline jobs so we're going to be taking a look at a lot of this documentation I think the gitlab documentation is great but it's very dense and there's a lot of it and so it's hard to find uh kind of what you're looking for and understand um what is Meaningful to your specific use case so I'll provide links to all the documentation that's relevant to this video in the video description in the example that I'm going to be demonstrating in this video the gitlab runner is going to be installed inside of the kubernetes cluster and it's not going to be running outside of the kubernetes cluster connecting to it and spawning pods it's going to be spawning pods from within the cluster so the question is how do we install the gitlab runner program in the kubernetes cluster and gitlab provides multiple ways to install the gitlab runner program in your kubernetes cluster so let's take a look at the documentation for the first method and the method that we'll be using in the video we can install the gitlab runner program via a Helm chart that is supported by gitlab and this is as you can see here the official way of deploying a gitlab runner instance into your kubernetes cluster so like I was discussing before this chart will configure the gitlab runner program to utilize the kubernetes executor and then when the gitlab runner program receives a new job from gitlab it will provision a pod within the the gitlab runner's namespace and run it and here you can see the prerequisites that I mentioned at the beginning of the video that you would need in order to um get the gitlab runner program up and running via the helm chart So the instructions here are pretty straightforward and there's not too many steps to take the first step and we'll follow it here is to Simply copy this command where we add the helm repository for the gitlab helm chart that we want to use and then we simply need to install the chart into a namespace that we've already created or we create a new namespace but before we run the helm install command we'll want to fill out the values.yaml file for this Helm chart and that will configure it with the configure the Manifest files with our environment specific values so for instance if we're running an on-premise instance of gitlab the gitlab URL is going to be different we'll also need to specify a gitlab runner registration token so that our gitlab runner program can authenticate with the gitlab project or group so to get started I am going to copy this uh Helm repo add command and I'm going to navigate to my terminal now I've connected to over SSH to my controller node my cluster controller node and I'm running a Raspberry Pi 4 cluster so my worker nodes are other Raspberry Pi 4 computers and I've installed the um Cube control CLI on the controller node as well as Helm the helm client so from this Raspberry Pi I can control the kubernetes cluster so I'm going to paste the helm repo add command into the command line and I'm not going to execute it because I've already added the repository but go ahead and hit enter and add that repository and once you've added the repository I'm going to navigate back to my browser and since I'm not using Helm 2 I'm not going to run the helmet knit command and the next step would be to fill out the values.yaml file for this chart now if you're not familiar with Helm Helm is a package manager for kubernetes you can deploy an entire application to kubernetes cluster using a Helm chart which just kind of packages a lot of manifest files together and bootstraps a application into your kubernetes cluster and how it works is it templates all of the Manifest files for your application and then basically all you have to do is set the values of those templated files in a values.yaml file so what I'm going to do is navigate to the gitlab repository hosting this um this Helm chart uh this gitlab Runner Helm chart and I'll share a link to this repository in the video description but if I navigate to the top directory of the repository uh let's see there should be a values.eml file here at the bottom and I can open that up and um we could download this file simply by clicking download but what I want to do is download this file on the controller node the Raspberry Pi controller node so what I'll do here is I'll open Raw and I'll just copy this URL and I'm going to navigate back to my terminal and I can just W git and then the URL I've already downloaded the values.yaml file so I don't need to I don't need to download it again but you would just download that file to your controller node or wherever you have whatever machine you have access to administrate the Target kubernetes cluster now going back to the documentation if I scroll down to the configuration section it shows the required configuration for the gitlab runner specifically the required configuration in the values.yaml file so you do need to set a couple of values at a minimum in order to get the gitlab runner program up and running correctly the first thing that you have to specify is the gitlab URL which in our case or in my case is going to be just gitlab.com I'm not running like an on-premise incident or some private instance of gitlab and then the second thing is the runner registration token and that registration token is used to add new Runners to either your gitlab project or gitlab group in my case I'm using a gitlab project so how do we get the runner registration token well we should navigate in my case I'm going to navigate to the gitlab project that I want to um execute CI jobs in the kubernetes kubernetes cluster so I'm going to navigate to my Repository and then under settings I'm going to go to CI CD and then under Runners I'm going to expand that and here is my registration token so I'm going to want to copy this token into the values.eml file uh in order to properly configure the gitlab runner that gets installed in the kubernetes cluster so make sure you copy that registration token and have it saved somewhere or just easily accessible at least and you'll notice here that it says set the token directly in the values.yaml file or store it in a kubernetes secret the best practice here is for sure going to be storing it in a secret and making sure that it's encrypted but I'm not gonna I'm not going to show that here I'm just going to set it in plain text directly in the values.eml file the other thing that needs to be configured that they don't mention in the required configuration and it uh kind of tripped me up took me a little while to figure out uh is that you need to configure um parback for your cluster specifically the service account that gitlab is going to use in order to to provision new pods I don't remember exactly where they mentioned it but somewhere in the documentation they say like make sure the service user has the right permissions and it's not explicitly stated um in the instructions uh anywhere it was just like one line that was that was kind of hard to find but anyway let's go ahead and take a look at the values.yaml file I've already set the values in my values.eml file but I do want to show you what the um the base values.yaml file looks like when you download it so if I take a look at the values.eml file it's pretty large file but remember we really only need to set um like a couple of things the first is the gitlab URL so we would want to sit set that to in my case I'm going to set it to gitlab.com and then the registration token needs to be set here and then the last thing that we would want to set is we would want to configure our back okay so for our back support uh under here if you set create to true then the helm chart is automatically going to create a new service account and provide it with um the permissions that you specify here the rules that you specify here okay if you set it to false then you need to specify what service account to use so here you can see it says use the following kubernetes service account name if our back is disabled in this Helm chart and so you would just uncomment this out and specify which service account you want these rules applied to so obviously here you would want to delete this empty empty set and uncomment these rules because this is what these are the permissions that would be required in order to properly provision pods and execute the gitlab CI jobs now the other thing and this isn't like this really isn't relevant unless you're running a Raspberry Pi cluster so I'm not going to spend a lot of time on it but if you go down to the configuration uh this is where you would specify the gitlab runners configuration and under the configuration when I was trying to run uh this base configuration on my Raspberry Pi cluster it was not working and I ended up finding an issue in gitlab with someone who encountered the same issue and they had to specify uh a rm64 specific image for not only the gitlab runner but also the Builder and helper images that run inside of the gitlab runner uh con um pod when it's in the kubernetes cluster and I'll show those values uh in the values.yaml file that I edited as well so let's take a look at the values.yaml file that I've edited so I'm connected over SSH to my Raspberry Pi controller node and this is the values file that I'm I'm going to use when deploying the helm chart so if I scroll down I have the gitlab URL set to gitlab.com I have the runner registration token set to the Token of my uh set to the Token of my gitlab project so if I go back to here you can see this is the registration token and it's the same that I have here as well okay and then in addition to uh setting those two values if I scroll down to the r back section currently I have um I have our back set to true so this is going to create a service account that will be used in um in the namespace the gitlab runner namespace and then I've simply uncomp uh uncommented the rules that were commented out in like the base values.eml file and then finally if we scroll down to the runner configuration section this is the configuration that I set and you only need to do this you only need to change this if you are like me running um running the gitlab runner on a Raspberry Pi cluster which I'm assuming is kind of a niche use case but I had to update the gitlab runner image and the helper image to the correct like architecture otherwise I ran into kind of weird errors and it took me a little while to finally uh find an issue in gitlab where someone said you know this is a workaround to the issue and they were also running on on Raspberry Pi's so this isn't relevant uh unless that's uh that's your use case as well right now I have the values.eml file just sitting on my controller node it's not backed up anywhere it's not version controlled but ideally you would Version Control the values.eml file and keep it with your code base wherever that might be if it's in a repository in gitlab okay so now that we've updated the values.yaml file if we take a look back at the instructions here uh for um installing the gitlab runner program in our kubernetes cluster for Helm 3 which is what I'm using you can simply use the helm install command you specify the namespace that the gitlab runner uh should be installed in you specify the release and then the file use the dash F option to specify the values.eml file that we edited in the helm repository forward slash Helm chart so if I navigate back to my terminal and I'm going to do a reverse search here for the helm install command that I used so Helm install specifying the namespace as gitlab Runner I also specified and you'll want to do this if you're installing it in a namespace that hasn't been created I'm also using the create namespace option if this namespace hasn't been created and then specifying the release name the the file which is the values.eml file and then the helm repository and Helm chart okay I'm not going to use the create namespace because I did already create the gitlab runner but I just wanted to show that option because you will want to use that if you're if you're wanting to install it in a new namespace so once I run this command I should be able to pretty quickly see the gitlab runner that's installed in this cluster registered with my gitlab project so I'm going to go ahead and hit enter and as you can see in the output it says your gitlab Runner should now be registered against the following gitlab instance and it's in the runner namespace gitlab runner I can use the describe command so Cube cuddle describe pods in specifically the gitlab runner pod and in the namespace gitlab runner and we can check the status of that pod and so it looks like looking at the events the gitlab runner pod has been started so I'm going to navigate to my gitlab project and let's check if it successfully registered with my gitlab project so when I refresh the page we should see the gitlab runner from the kubernetes cluster registered and sure enough we do this is the uh the git lab Runner that's running in my kubernetes cluster now I will say that not every time I've run that Helm install command uh this has worked uh sometimes when I run the helm install command for whatever reason it just it doesn't register and then after about 90 seconds it says there's like an unhealthy Readiness probe or something like that it doesn't work all I had to do was uninstall uh perform a Helm uninstall of that release and then run the install again and it seemed to work so I don't know specifically what causes those intermittent issues so now that we have that Runner registered we should be able to utilize it when we execute the pipeline the gitlab CI pipeline that exists in this gitlab project so if I go to CI CD and then pipelines actually let's go to the editor just so you can see what the pipeline looks like it's very simple it uses a maven image and then it has a single stage called deploy has some variables set it enables a cache and then it has a single job called the deploy job I did have I commented out this um Maven deploy command because it was failing for whatever reason I didn't want to get into all of those details because it wasn't really important to this uh video so I commented out that command and just left in the Echo statement and that seemed to work uh fine so um pretty simple Pipeline and if we go back to the pipelines page I'm going to select run pipeline and then I'll select a run Pipeline and so if we go into the deploy job pretty soon we should see a console output and it should show that you know it picked uh our runner because I've disabled all other Runners uh disabled shared Runners and it is utilizing the runner that's running on our kubernetes uh our kubernetes cluster so as you can see at the top of the console output it says using the kubernetes namespace gitlab runner which is the one that we created it's using the kubernetes executor with image Maven so I spawned a pod that is running the maven image and then it takes the usual steps that a gitlab pipeline typically does when it's configuring the environment within the within the job and finally we see the echo statement I think it's um let's see Echo publishing Maven package to package registry and then it uh it completes successfully so that's really how easy it is to install and configure the gitlab runner program in your kubernetes cluster and start utilizing your kubernetes clusters resources to facilitate gitlab CI pipelines and before I finish the video I do want to specify the other two methods that you can install the gitlab runner program in your kubernetes cluster so the one that we covered in this video is via the helm chart and it's the official way to deploy git lab runner in the cluster but you can also use two other methods so if I navigate back to the documentation you'll see here in the documentation it says you can install on Linux Mac OS Windows Helm chart and then you have gitlab agent and operator so these three methods are installing the gitlab runner program uh on a kubernetes kubernetes cluster and I think that the documentation could do a better job at comparing uh these different methods I mean I guess they kind of just expect expect you to know what the differences are and how to compare these but I kind of it just took me some time to kind of understand uh the differences and what the use cases would be so in terms of ease at least for me and I think for any beginner the helm chart is probably the way to go if you don't need a lot of customization or anything you just need the basics you want gitlab Runner running on your kubernetes cluster the helm chart seems to be the way to go it's the most like polished method of deploying git lab runner in a kubernetes cluster and then I think the next option would be the operator and so if I expand I have this tab open with the operator documentation so they also offer a gitlab operator that you can install on an openshift cluster uh or directly on kubernetes in the gitlab runner operator is kind of a heavier deployment of the gitlab runner program in your kubernetes cluster if I look at the operators gitlab Repository and navigate down here it's it says the gitlab runner operator aims to do a few things here but you'll notice uh this specifically kind of caught my eye uh it allows you to Aggregate and visualize metrics using Prometheus and grafana so I believe the operator is deploying uh grafana instance and a Prometheus incense that's scraping metrics from the gitlab runner program as well as I'm not certain but I believe it's you know scraping metrics from pods that it Provisions to execute jobs as well so I think that you get a little bit more functionality when you deploy the gitlab runner operator like I said before the helm chart is kind of like the simplest way to go uh it's lightweight in that sense that you know you're not getting a Prometheus incense and a griffon instance to visualize all the metrics related to the gitlab runner program so this is another method method of installing the gitlab runner via the gitlab runner operator and the final method of installing the gitlab runner is via the gitlab agent so if you want to connect your gitlab project to a kubernetes cluster and you intend on deploying your the code base of your project to that cluster you can Implement a git Ops workflow with the gitlab agent so I think that again I'm not like an expert on this I haven't spent a lot of time in this particular area but I believe the gitlab agent is kind of like Argo CD or flux in that it implements a get Ops workflow where you install the agent in your cluster and then the agent is monitoring uh get lab repositories that you specify for any changes and if changes happen to kubernetes manifest files in those repositories it will automatically apply those updated manifests to the cluster so you can use the gitlab agent to not only deploy your code base to a kubernetes cluster but you can also use the gitlab agent to install the gitlab runner program install and manage the gitlab runner program so in my opinion I mean if you're looking at like devops best practices and where devops is headed you know having a git Ops workflow is great I think that this might be the most uh I mean at least from what I can tell it seems like a more involved deployment of git lab Runner because you have an additional prerequisite of installing and configuring the gitlab agent but if you really want that get Ops workflow I guess this would be the the way to go and I think that you know in the future this is also where it's headed as well they do specify that the git Ops workflow is the recommended workflow uh if you're going to be connecting a kubernetes cluster to your gitlab project so in the documentation for installing gitlab Runner via the agent they specify you know this is a git Ops workflow where you create the values.yaml file you also create a runner manifest file and then the agent will monitor those manifest files in the gitlab project and if any changes are made to the gitlab runner manifest files it will automatically update the the cluster accordingly so I would definitely encourage you to take a look and research all of these methods on your own but I felt like for the purposes of this video uh the most straightforward methods seem to be and the lightweight method seem to be via the helm chart if especially if you just kind of want to test it out and see how it works so that's pretty much all I had for this video I hope you enjoyed it that you found it valuable if you did please consider throwing a like on the video and subscribing to the channel for more videos like this if you have any questions comments or feedback please leave them Below in the comments as I said before I'm going to try and Link most of this documentation in the video description so that you can kind of quickly access it and you don't have to search around for it like I did thanks for watching

Channel: Tech and Beyond With Moss

Views: 37,071

Keywords: kubernetes, gitlab, gitops, helm, kubectl, k8s, gitlab runner, gitlab ci, gitlab pipeline, cicd, continuous integration

Id: 0Fes86qtBSc

Length: 29min 41sec (1781 seconds)

Published: Sun Sep 25 2022