Build a GitOps pipeline with this Kubernetes, Jenkins X tutorial

Hello. Today we're going to go over how to set up a GitOps deployment workflow using Jenkins X, Google Cloud Platform and Kubernetes.

So first of all, I'm here in my Google Cloud Platform, and I'm going to go ahead and open up a Cloud Shell instance. And let's put that into a new window to make sure we have enough space to work on here. All right, now, first things first, I want to make sure that I'm in my project that I want to do here, which is the "GitOps Demo Project." Perfect. Now, next we're going to go through and get the Jenkins X binaries. Jenkins X is an orchestrator that we're going use to run this whole project, and the command-line tool for it is Jenkins X. They're fairly easy, it's just downloading the command line and then adding it to our bin directory. But after that, we can test and see if it worked by running JX, which is going to tell us we do have a working Jenkins X command line, and we can clear that off now and start working on creating our Kubernetes cluster.

So the command to do that is "jx create cluster," and here it's expecting an argument -- usually the cloud provider or on-premises instance you're setting up in your Kubernetes cluster. Since we are on the Google Kubernetes Engine, we're going to use "gke." And there's a little bit of a gotcha when we're using Google Cloud Platform: We want to make sure we put in the "skip login" flag as well, and that'll save us some headache later on. So let's go ahead and run that. All right, now that it's run a little bit, it's asking us what type of cluster we want to create. We're going to pick "Zonal," for this case. And as far as which zone we want to deploy it to, I'm in the Eastern United States, so we're going to go ahead and pick the "us-east1-cloud zone." And the Google cloud machine type is the size of the nodes that you want Kubernetes to generate when it scales up and scales down. It's worth noting that any one of these options, if you type in a question mark, it will tell you a little bit more about it, in some cases even give you a link to further documentation. For this demo purpose, we're going to go ahead and just use the defaults for everything, including the three minimum nodes and five maximum nodes. We're not going to use Preemtible VMs, or access the Google Cloud Storage or Google Container Registry, and we're not going to enable Kaniko for building container images.

So now we've run through all of those, it'll prompt us a little bit later on for some next steps, but for now, let's just let the cluster create in the background. Okay. Now that that's run for a little while, it's going to ask us if we want to set up an ingress controller for our kube-system namespace. We definitely want to do this. This is how we're going to interact with not only Jenkins X, but our application as well. Next up we're being prompted to add a domain -- this is if we have a custom domain we want to use for our application. If we don't, it will actually give us an IP address on the nip.io domain, which is what I'm going to choose for this. Next we're being prompted for an API token for GitHub, and we're being given a URL to run here. So I'm going to go ahead and do that in another window, and then bring it up here. So this is my personal GitHub account, and this is what that URL redirects to. It's a personal access token that has already got these permissions filled out. And what we need to be able to do is generate a token here and give that to Jenkins X so that it can make modifications to GitHub on our behalf. I'm going to go ahead and generate the token, and then copy it off, and then I will go back to my Jenkins X installation and enter it from there. Okay. I've got my API token and I'm entering it now. So this does mean that in order to set this up you have to have the ability to delegate at least repo level permissions on your GitHub account. And, yes. I'm going to select the defaults and use GitHub as the pipeline's Git server.

Next, when we select Jenkins installation type, we want to pick our static Jenkins server and Jenkins files. All right, as for the default workload build pack, we're going to go with the Kubernetes Workloads: Automated CI+CD with GitOps Promotion. All right, now that all that's been provisioned, it's given us an admin password for our Jenkins instance. We're going to go ahead and copy that off. And next, it's asking us to generate an API token that's logged into the Jenkins server. So let's go ahead and go into "Admin," and enter that password. There we go. So now we have our Jenkins server. Let's go back here and select the organization where we want to create our environment files. We're going to select "devbyaccident," because that is my GitHub account. All right. And it looks like that's been provisioned. Let's go to my GitHub and see if anything's changed. So I'm back in my GitHub account here, and it does have the two environment folders -- there's "Staging" and "Production," with the "Samuraibead," which is the name that GK auto-generated for us.

All right, so let's go back to our Cloud Shell and see what else we could do. Okay. So I'm back on my Cloud Shell window, I'm going to go ahead and type in that command down there. We're going to start a new microservice from a quickstart, so that is "jx create quickstart." And we'll go ahead and use the Git username we set up earlier, the same organization, and we'll go ahead and call this a "golang-http-test." And out of our choices here, we have several that we can pick from, but we will pick our "golang-http" endpoint, and we will go ahead and initialize it and stick with the default message which is "Initial Import." Now we'll let this run for a minute. All right, now that that's done, let's go ahead and see if we can run some of these basic commands. I'll run a "jx console," which will pull up our Jenkins console here. All right, and we see we have our golang-http-test environment, and we have staging and production environments. Let's go ahead and see if we can get the activity for that. I'm going to go back to my Cloud Shell here and run this first pipeline command here. We're actually pending, so let's let that run for a little bit and see if we can come back to it after it's done.

All right. It looks like all our deployments have succeeded, so I've gone ahead and gotten out of there. We can also run a "jx get applications," to see that we do have our golang-http-test version 1 in staging, we have one pod, and we have the URL for it as well. But it's not just enough to put it in staging -- let's actually see if we can get this into production. So, if I run a list directory, I see I have my golang-http-test, let's go ahead and get into that. And then I'll run a "jx promote golang-http-test." All right, so let's break this down a little bit. We have our "jx promote golang-http-test," which is our application, we have the version 0.0.1, which is the version we're going to promote into production, and we want to specify the environment, which is production. So let's go ahead and run that. Okay. So, we've entered the username and password for my GitHub account. We've entered the password for my account, which since I have two-factor authentication on, is a personal access token, so that's something to keep in mind. Let's go ahead and wait for this to finish. Actually, let's do one better, let's go ahead and go into Jenkins and take a look at it. So you see, in my production environment, it's open to pull request, and it's now validating the environment and getting ready to deploy.

All right, and that's it. That's how we run a GitOps workflow from Jenkins X in the Google Cloud Engine. Thanks for watching.