 Hello everyone and welcome to this video where I'll be setting up a GitLab cluster inside of Kubernetes, inside of GKE to be particular. What you can see here is that the only thing that I've done so far is set up an environment variable cluster name which contains the name of the environment that I want to set up just for my own reference to make this easy. And then I've run a gcloud container clusters create with that cluster name in order to actually create the cluster that we're going to deploy to. I've done that off camera because it takes a few minutes to do that, but that really is the only step that I've done. You can see here the machine type that I'm using is an N1 standard 2 with three nodes. That will give me enough capacity to run everything inside of GitLab in the production configuration as well as a little bit of headroom so I can deploy a couple of go apps later. What I've done for this series is to actually do some live coding of microservices using this instance that we're going to set up today and then show how GitLab CI CD can help you go from coding to delivering that software in production very, very easily. To introduce myself, my name is Jason Lenny and I'm the product manager for CI and CD here at GitLab. I've personally got a long career in doing build engineering, release engineering, release management and a lot of things in the continuous delivery and continuous integration space. So I'm excited to share some of what I've learned with you today, but to start we're just going to be setting up this environment. So the first thing that we need to do now that we've got our cluster up is set up a static IP and I have a command here which I can execute that will create this IP which I'm giving the cluster name just for my own reference again so I can find these things later. Inside of our GitLab internal project in my region I live in Europe so that's why I'm doing that and then with the network tier set to premium. The reason for that is that we're using premium load balancing inside of the Helen chart so this is what you need to do in order for that configuration to work. So let's go ahead and do that. And then the other thing that I need to do before I can set up Taylor or anything else like that is actually to switch to the admin user, give my own personal account permissions on the cluster, cluster admin. And the reason for that is that Google Cloud GKD does not give you that permission by default even if you're the person who created the cluster you don't get that access. So first thing I've done here is run a command that gets the cluster description and finds the password and it cuts it out and sets it inside of this admin pass variable. I'm going to use that now to set credentials for the admin user, set that context so that I'm actually able to run commands as a user. And now what I'm going to do is make my own personal email address, my own personal user as defined here by gcloud config get value account and really that's just going to be my personal email address, my GitLab email address. And then now I have cluster admin access so I can switch back to myself. So I'm going to do that now. So gcloud beta container clusters get credentials, just grab your own personal credentials. All right. So a few steps there is just kind of basic configuration within the Kubernetes cluster. Now what we're going to do is go ahead and get Taylor set up. So the first thing to do there is create the service account for Taylor. The problem though is that this does not have any permissions. So I have a YAML file here called Tiller cluster role binding YAML that all it does is set up the access for this account. So we'll go ahead and create that. That's done. Now we can start with the helm installation. So we'll init that using the service account Taylor. We also need to grab the GitLab repo and mention and connect that with that helm on the local system so that it can get that. And then we'll do updates so that it knows about all of the charts that are in that repo. So now helm knows about the GitLab chart and we can run the installation. There's one last thing to do in order to make all of this work. We need to have that static IP available to us. So similar to that command with the admin password. I've got a static IP environment variable that I set here by describing the address for the cluster name that I set up earlier. So we can see that that is in this case this. All right. So one more thing that I'm going to do before we actually run the home chart is set up that IP address as an A record within DNS. On one of our internal domains of gogitlab.com. So you can see here that I'm running gcloud DNS setting the project to our internal project that we use and then starting a transaction for the gogitlab zone. Then I add the A record as follows. You can see that it's just adding that static IP as a type A record to the domain. And then we complete the transaction and commit that. So it does say pending, but it really just takes a second or so to do that. If I pull up a browser, you'll see that that's probably actually already done. Yeah, so we can see here that this IP has been set and the DNS resolution should start anytime now. All right. So now it's time to run the home upgrade. There's a few variables that we set here and I'll show you what those are on the command line here. So what we're going to do is run install of the GitLab chart with a timeout of 600. It won't take anywhere near that long, but just in case there's a problem, we do set that timeout. We set the global host domain to the cluster name.gogitlab.com. It's going to set up a let's encrypt certificate. So HTTPS works on this domain. So the way that I set up everything here in DNS and with the way of name things is so that this name will work. Global.host.externalIP that maps to that static IP we created earlier. And then the cert manager issue email is just me. In the end, the actual way you connect to this host will be as gitlab.in this case, jln-gitlab.gogitlab.com. All right, let's go ahead and run this and see what happens. It should just take a minute as Helm pulls everything together and starts sending it up to the server. When Helm returns, it won't quite be done yet because it still needs to provision all of the pods and everything. But what will happen is that Helm will take care of all that for you and then Kubernetes will then make sure that the pods are created, instantiated, that the ingress works. It'll automatically connect the IP address to the ingress and then go to let's encrypt and get a certificate for the domain. And everything should be up and running, including a runner with autoscaling, including all of the core functionality of gitlab. And we should be good to go for where we're going to continue this series and start doing some live coding in order to see what happens when you build a microservice from scratch inside of gitlab and deploy it using the gitlab CXCD features. So this will take a few minutes and then the page will be up. But I won't have you sit here and watch that. This is really all there is to it. You can check your workloads in the Kubernetes cluster to see when this is done or even just check within gitlab here. So we are sorry, within Helm. So we could do a Helm status of gitlab and get the latest on where this is at. So you can see that some of these things are waiting for dependencies. So the ingresses are waiting for the services that they depend on. But once all of that's done, once all these pods are initialized and running, all of this will come up and be good to go. If you see things in here like insufficient resources, you should check your Kubernetes cluster and make sure that you do have enough resources. And as I mentioned earlier, that's about 16 gigs of RAM and six VCPUs is the main requirement. So I hope this was helpful and looking forward to continuing this series and seeing where we go from here. Thank you.