 Welcome to another demo video of the Red Hat OpenShift Container Platform. My name is Philip Lamb and I am the DevOps Solutions Architect for Red Hat's Global Partners and Alliances ISV team. Today, I'd like to demonstrate how easy it is to implement GitOps on OpenShift with GitLab. GitOps is an operational framework that takes DevOps best practices used for application development, such as version control, collaboration, compliance, and CICD, and applies them to infrastructure automation. GitLab is a web-based DevOps lifecycle tool that provides a Git repository manager providing wiki, issue tracking, and continuous integration and deployment pipeline features, all using an open source license. In this video, we will first demonstrate a simple running application written in Node.js. We will then install the GitLab runner operator and configure it. Next, we will take a look at an example GitLab CI configuration file, and finally, we will make a code change, commit it, push it, and then take a look at the results. Let's get started. Okay, so here we are in the OpenShift console. You can see that I'm in the developer mode. I'm looking at the topology here. We have our Node app, and if we take a look at what it's doing, it's running just a standard web app. Close out of that, and now we're going to go ahead and install the operator. So hop over to operators, then operator hub, and we're going to use the GitLab runner. We've got some installation instructions here. We'll look at that later. We click install. We want to use this in our installed namespace here, DSE GitOps. It's our example project, and click install. Just give this a minute. Alright, so now the runner is installed. You can see we've got some basic information here around usage. Now, in order to get started with this, we're going to first need to get a registration token from GitLab. So we'll go over to my GitLab project here. In order to do that, we hop to settings, and then CI CD. And then if you see here, runners, expand that out. And then we're going to be using a specific runner that we configure. So we'll take this registration token and copy it. Next, we're going to create a secret in OpenShift from YAML. And I've got some here that I used earlier. So that's my registration token. Click create. Now we'll hop back over to installed operators, and we're going to create a runner now. So we've got two views, FormView and YAMLView. We're going to use YAMLView just for simplicity's sake. Now the token that we created is called GitLab Runner Secret. We create and give that a few minutes to spin up. Here we can see that the runner is now running great. Everything is configured correctly. And now we just want to check back with GitLab to see that the runner has phone home and is now available. So we're back in under settings CI CD, under runners, and we can see we do indeed have a available runner. So the communication is good to go. Now that our runner is running and configured correctly, we're next going to take a look at the GitLab CI YAML file. That's where all the magic happens. It's in the root of the project. The file naming convention is .gitlab-ci.yaml. So we'll take a look at it. Alright, so that is a pretty big file. Let's break it down. What we're doing is establishing some defaults, configuring the stages our pipeline will contain, specifying some global configurations, and then for each stage we describe the job we want to run. You can see a few common elements for each of these jobs. First, they have a human readable label. Then we see they extend the default stage we defined earlier and define when in the pipeline the job is run. Now we specify our scripts for the job and then optionally establish rules. As an example, in the cases above, you can see that the job Prepare OpenShipped Environment Production would only be run if the branch we're merging into was labeled PROD. This allows you to be more or less picky about what occurs on different environments. In the case of this pipeline, we're taking the API objects described in the .openshift directory and the appropriate subdirectory and running an OC apply on them. If the apply succeeds, the job proceeds to the next stage where we build and package a new iteration of the application. The final stage deployed is configured to require manual action in order to roll out the new project. So now that we've got that out of the way, let's commit our pipeline code and see what it looks like on GitLab. Alright, so here we are back at the console looking at the topology view. I just wanted to demonstrate to you that there's no magic happening right now. We just have a single pod running for our app. Everything looks good. So what we're going to do is change the number of running pods for the replicas from one to let's say two. Alright, now we want to add that code change. Commit it, push, and there you go. Give that a second and we'll hop back over to GitLab now. So now that we've committed it, if you hop over to CICD and take a look at pipelines, you can see that we have one running that we just launched. So right now it's preparing, so it's setting up the environment. And then the next couple of steps are going to be build, package, and deploy. We'll stop here and we'll let it finish. Alright, so now we see that we've prepared, built, and packaged. And as I mentioned earlier, the deploy process is a manual one that requires us to click. We will click and wait for that to deploy. Alright, so now that we see that we have successfully deployed our application, all stages in the pipeline have passed. And now let's go take a look at our topology to see if any changes were affected. And we can see here we do indeed have two pods. When we look at the build history, we can see that we have this completed just a few minutes ago. And that's it. So let's recap. We've installed the operator and configured a secret and a runner using the operator. We reviewed an example CI configuration file, and after making a code change and pushing it, saw that it had the desired operational effect. Thank you for watching this demo video. We'll continue to release more in the future.