 Welcome to this GitLab training video. My name is Brendan O'Leary and I'm a Solutions Architect with GitLab. Today we're going to be talking about how to install GitLab into a GKE cluster on the Google Cloud Platform using GitLab's Omnibus Helm charts. Today we're going to build everything from scratch. So we'll start by creating a new cluster inside of Google Cloud Platform. So I've logged into my Google Cloud Platform account and I've gone to the Kubernetes clusters under the Kubernetes Engine section. I'm going to go ahead and hit Create Cluster. Today we're going to be creating a cluster for a football team called Friday. So I'm going to call the cluster Friday Football. I'm going to go ahead and put that cluster in the US Central One zone. I'm going to give it two virtual CPUs to use in each node and I'm going to keep the default size of three nodes. And then I'm going to go ahead and keep the rest of the defaults here and hit Create. Next we're going to need an external IP address for this cluster so that it can be reached from the outside world. So I'm going to go ahead and navigate to VPC Network and external IP addresses. Here I'll press Reserve Static Address to make a new reservation. I'm going to call this Friday Football as well so that I know which cluster I'm associating with this with. And I'm not going to attach it to anything right now that it will be handled automatically later on. This external IP address once it's created will also allow my GitLab instance to use a domain name and use Let's Encrypt for automatic SSL. I'm going to go ahead and copy this IP address as we'll need it in just a minute. Next we're going to create a wildcard DNS entry for our domain pointing to this IP that we just created. For this I'm going to go to Network Services and Cloud DNS. And here in my Friday Dot Football zone I'm going to add a record set. And for this record set I'm going to make it a wildcard domain. I'm going to make it an A record and I'm going to make it map to the IPv4 address that we just created and reserve for ourselves in the previous step. And I'm going to go ahead and click Create. Okay, so now we see that Anything Dot Friday Dot Football is going to point to that IP address that we created in the previous step. Let's go see how that cluster is doing and see if it's spun up yet. To do that I'm going to go back to Kubernetes clusters. And we can see the cluster is still being created. I won't make you wait around for the cluster to be created, but I'll be back with you as soon as it is. Okay, we're back and we can see our cluster has got the green checkbox and it's ready to go. So here's that cluster we created. And we're going to go ahead and connect to that through our terminal. So we're going to show the gcloud command to get connected. Prior to this demo I already installed the gcloud SDK, which you can find more information about on Google's website. So here in this terminal window I'm going to go ahead and paste that to make the connection. I'm going to need that one extra piece of information, which is that external IP I created earlier. So I'm going to go ahead and go back to Cloud DNS and take a look at that. So here's that same external IP I created earlier. I'm just going to need that as part of the variables I'm going to pass to my helm chart. Okay, now that I have that I'm ready to go. I've created the kube config entry to point to my cluster. I'm going to go ahead and run helm init to initialize helm on that cluster. I'm going to add git labs helm chart repo. And now I'm going to spin up the entire git lab stack with our omnibus helm chart. You can see I've passed a base domain of friday.football. I've passed our base IP that we created and my email address. You can see it's now installing on our cluster and it's going to automatically spin up a lot for us. Let's take a look at what it's spun up. So if we scroll up here, we can see that it's going to create a namespace for everything to live inside of. It's going to create configuration maps that will tell the various pieces of the git lab stack how to communicate with one another. It's going to set up persistent volumes for all the persistent storage we'll need. And then it's going to spin up nginx to be a load balancer on the front end. It's going to spin up the ingress, a secret area, storage, services that are needed for git lab, and then all the deployments that go along with git lab. And in fact, if we open a new tab now and do kubectl proxy, we can then connect to our cluster. Let's go back and see it here. Google shows us how to connect really easily. Git lab is now deploying and we can watch the status from this workloads page in our Kubernetes dashboard. We'll watch for all the items here to have a green check mark showing that they have completed. This process can take a few minutes as GKE allocates all the resources needed and starts up all the various containers. You can see here several containers. The main git lab container has the Rails app, but also Mattermost for chat, integrated Docker repository and registry, and Prometheus for monitoring. There are separate containers here for Postgres and Redis and the autoscaling git lab runner for CI CD. This is everything you need for the DevOps lifecycle on Kubernetes. Great! We can now see that all of our Kubernetes deployments have been successful, and we're going to go ahead and open a new tab here and go to our git lab instance. So now if I go to gitlab.friday.football, here's our brand new git lab instance.