 My name is Chris Timberlake. I'm a senior professional services engineer at GitLab. I'm here to demonstrate to you the new GitLab operator for OpenShift. Today, we're going to be installing a GitLab runner into OpenShift using the operator. Now for those that are unfamiliar, the GitLab runner is a piece of software that orchestrates all of our CI CD builds. When a new CI CD build is triggered, the GitLab runner grabs that workload, loads it into a new pod, and executes that workload. As you can see from the installed operator screen in OpenShift, I've already gone ahead and installed the operator. If you want to do this yourself, you can install it from the operator hub like so. Go ahead and go to the operator hub. In the filter section, go ahead and type GitLab. Go ahead and click on GitLab, and when it pops up, it will greet you with this page and offer to install the operator. While you're installing the operator, it will ask you to fill out a form. Go ahead and fill that form out and the operator will be installed. The operator does require a cluster admin permissions, so keep that in mind. When installed, the operator will then listen for CRDs with the type of runner. To install these CRDs, you're going to need a secret with a GitLab runner registration token. Let's go ahead and grab that now. Once you have a GitLab project, as an admin, you can access the settings of the project. Once you go to settings, then CICD, you'll be met with a page for all of your CICD options. Look for runners and click expand next to it. Go ahead and scroll down. On this page, you'll find a registration token and a URL that is required for setup. Let's go ahead and create a secret in OpenShift now to go ahead and register our runner. Creating the secrets done from just a simple OC command. I've gone ahead and copied it to my clipboard already, but essentially, you're just going to OC create secret, a generic secret from literal with runner underscore registration underscore token. Pay attention to the name of your secret because you're going to be using that in the next step. Now that my secret's created, we're going to go ahead and make this CRD to get the runner going. And I've gone ahead and made the CRD already. I'll go ahead and show it to you now. As you can see, the CRD is short, but there's three things to pay attention to. The GitLab URL, which is used to point to your GitLab instance, the token, which is the name of the secret that we've created, and finally the tags. Runners in GitLab can specify tags that enable a pipeline or job to run only on a runner with that tag. For this, we've added tests in OpenShift. I'm going to go ahead and OC apply that CRD. Now that we see that the runner's all set up here in terms of the CRD, in just a few moments, that runner's going to come alive inside of our runners page. If we look at the project, you can automatically see that the GitLab runner is already spinning up and already setting itself up. If you go back to the GitLab runners page and scroll down, you should see a new runner there. The runner is now registered. The green circle here indicating good communication. From here, let's go ahead and edit the name of the runner and let's go ahead and edit the tags. So I'm going to go ahead and change the description of this runner, and I'm going to go ahead and indicate whether this runner can pick up jobs without tags. So we're going to go ahead and make it so that this runner can pick up any job inside of my project. Now that we've set up the runner and everything set up for our runner, let's go ahead and take a look at our sample pipeline. For us, this pipeline is very small. It's meant to just demonstrate an example of the basics for a pipeline inside of OpenShift. Here, you can see our project structure. Inside of this is a folder that's labeled.OpenShift. Inside of this are three separate folders, Dev, Problem, Staging. Inside of Dev, we have individual files. So we have our build config, our deployment config, our image stream, our route, and our service. Normally, a GitLab pipeline would be triggered via commit. This can happen from anywhere, your normal IDE or even a code ready workspace. In the interest of time, I'm going to show you a pipeline run that I ran a few moments ago. Here, we can see the individual stages of the pipeline. Let's go ahead and jump into the OpenShift preparation job. In this job, you can see that it is running from a pod and you can see the pods name at the top. As soon as that pod spins up, you can see the normal GitLab CI occurring as we scroll down towards the bottom and look at what it's doing. You can see that it's logging into OpenShift. It's selecting a project. And then what it's doing is it is applying all of the OpenShift objects that we have stored in our repository and ensuring that all of our objects in OpenShift match what is in our source repository. Now, for this pipeline, we see that everything is completed. The deployed job at the end I've marked is requiring manual approval. Let's go ahead and approve that. This will take a few moments to go ahead and spin up. But as you can see, it's running, which means that the request has already been sent to OpenShift. Now, if we look at the OpenShift dashboard, here, you can see the main runner pod, the operator pod, but now there's a new pod. This is the pod that a GitLab job runs in. For every job in a GitLab CI pipeline, a new pod spins up and does the work, then terminates. This is going to go ahead and take a few moments to spin up and do the work. But as we can see, it's already done. And what this is essentially done is it has gone ahead and conducted a rollout of our deployment. Now, if we migrate over to the developer section of the OpenShift container platform, we can see our deployment configuration here. And we can see our pod is currently terminating and currently spinning up a new pod. New pod has spun up. We can go ahead and take a moment to click the route and go ahead and see that our application is now live. Thanks, folks. This concludes my demonstration of the GitLab operator for OpenShift. I hope this helps provide a window into what we're doing. We have a lot more functionality and much more features coming, and we hope to have tighter integration with OpenShift. To follow along with this progress, you can go ahead and see our EPIC for first-class support for OpenShift on our GitLab repository. Go ahead and add any comments that you may have or concerns that you may have. And thanks for watching my demonstration on the GitLab operator for OpenShift.