 Hi, my name is Christian Hernandez from the Cloud Platforms Business Unit over at Red Hat. In this video, I'm going to be showing you how to build a GitOps workflow using Kubernetes native CICD tools. Here, I have an OpenShift 4.7.1 cluster, which is running Kubernetes 1.20. Then I'm going to be using for this demonstration. And here, I have a sample application. This sample PHP application, for testing purposes, has a container file, Docker file, that'll be used for container builds in order to build this application. And I also have a deployment repository here. This deployment repository is my GitOps repository on how I'm going to keep this application continuously in sync in my cluster. So to get started, I'm going to go ahead and install the OpenShift GitOps operator by going to the operator hub and typing in OpenShift GitOps. Oops, if I spell that right. There it goes. Clicking Install and accepting the defaults. This will go ahead and install the Red Hat OpenShift GitOps operator. So the Red Hat OpenShift GitOps operator, what it is, it's a sort of meta operator. This operator installs Argo CD and Tecton in order for me to use in my CICD pipeline. So once the operator is up and running, I can go ahead and look at my installed operators, making sure I'm in the OpenShift GitOps namespace. I can see that it installs the ability to do an Argo CD and a Tecton pipeline. So if I click here and look at my Argo CD instance, this installs an instance of Argo CD. So what I'm going to do is I'm actually going to make some customizations for my current workflow. So first, what I'm going to do here is I'm just going to, instead of typing this out, I'm going to copy and paste it, I'm going to patch the instance of Argo CD to ignore routes, OpenShift routes, because in my GitOps repo, I am not specifying the routes. I just set the platform created for me. Also, what I'm going to do is I'm going to set up an OpenShift policy to allow the Argo CD service account access to my application. Next, I'm going to delete the pods. So I'm going to delete the pods in order for it to reset everything, especially since I'm updating roles and config maps. I'm going to delete the pod so that way it'll kick off here. So next, what I'm going to do is I'm going to install Seal Secrets. Installing Seal Secrets allows the platform to decrypt some of the secrets I have uploaded in the Git repo. So while that's going, I'll show you some other configurations I've done. In my application repo, I've actually set up a web hook. This web hook triggers a Tecton pipeline anytime I make a commit to a specific branch. In this specific example, I'm going to be using the main branch, but you can make it listen to whatever branch you want to. Going off here, double checking, Seal Secrets still waiting for it to come back up. Let's talk a little bit about my GitOps repo, my deployment repo. So there's a few things here. I'm leveraging Customize. Here, Customize is I have a base repo where all the manifests here are the same, no matter which environment I'm deploying in. And then I'm utilizing overlays for different environments. So I have the dev version, which takes the base configuration and then patches them for the specific environment. For example, I'm installing the dev application in the dev namespace, and I'm also patching the deployment to use a specific version of this image. Same for production. Production, what I'm overlaying is the same. I'm deploying in a different namespace. And then I am using a specific image tag. So I can use the same deployment config across multiple environments. And I'm leveraging Customize in order to change that depending on the environment I'm in. So going back here, Seal Secrets is installed. I can go ahead now and deploy my repo. Again, I'm going to be using Customize to deploy my application repo. So let me clear this. Oops, there we go. I'm going to be using Customize to override the default namespace because I'm using the OpenShift GetOps operator. And then I'm just going to use Customize build and apply this to the cluster. So as you see here, it created three different environments. Welcome dev, welcome prod for my development environment and for my production environment. And then I have a different namespace for my pipeline. And so in order to see what's going on here, let's actually log into the Argo CD interface versus get the password from a secret. I will then open this here, integrated UI here that'll take me to the, oops, that's not what I wanted. There it goes. Let me reload this and accept the self-signed certificate. So let's do username and password. So here, you can see that I have different environments now, right? I have the dev environment, my production environment, and then the pipeline, which is a different set of manifests. And that matches to what created here. So let's take a look at the dev environment. It says everything's in sync. Let's look at the live manifests here. So this is the development branch right here. And then let's take a look at the production right there. So in theory, this should all be the same, right? So yeah, so I have my development version here. I have an H2 that says blue. And it matches production because they're using the same code base at this point. So that's all, everything's green. Everything's synced up. We're good to go here. So now I'm going to be switching over to the developer perspective. Developer perspective gives the developer a set of tool sets that they need in order to do application development, right? And it comes with a tour so you can know where is where, right? I'm going to skip the tour since I'm already familiar. And then I'm going to go to the pipeline namespace, and I'm going to go to the pipelines. And as you can see here, there is, I set up a pipeline in order, a tactile pipeline to do the changes across the environments, right? And so let's introduce a change and see how this works out. So let me go to my visitor studio. I have the code up here already. So let's go down and change this H2 from blue to, let's say, something different, green, right? We're all familiar with that. And let's do a get commit, get add, get commit. And let's go updated to green, right? Something useful for the tracking, right? Get push. So what's going to happen here, it's going to hit that web hook. Remember that web hook I showed you earlier from the welcome app, and that should trigger a pipeline run, right? So when that web hook, going back to the settings and looking at the web hook here, it sees that I have a listener here set up for tecton. And that hit the web hook, and that's fired off a pipeline run. So this is going to go through a few phases. So let's take a look here, see what's going to go on. So I have a few steps, right? So first, I have the step talking about cloning the repo. Once it clones the repo, it's going to set the image tag for a specific version, right? I don't use a floating tag like dev or prod. I actually use the specific hash of the get commit as my image tag, and it's going to build and push it into my image repository. Once it does that, it's going to clone the deployment repository, right? My get ops repository. So this is different than my application repository. Once it clones that, it's going to edit the image tag on the get ops repo to this current one that it's building. Part of this, I have parallel tasks. Parallel tasks in tecton is just tasks that run at the same time. My latest always matches what my dev is, and that's just something I do as part. That's independent of cloning the repo. And then once that's done, I'm going to patch the dev repo, right, the dev overlay with the new image tag. I'm going to commit it to the repo, and then I'm going to patch production. Once I patch production, I'm going to create a branch in my production get ops repo, and I'm going to submit a PR. So this is how I do gating in tecton, is that I submit a PR instead of automatically pushing it into production. So if I take a look at the logs here, you can see the log for each individual task. I do a get clone. I do the commit. And now I am using build to push the steps up here. So this pipeline could take some time. So I'm going to pause here. I'm bringing you back here to show you that I made a commit to development. I want to switch back over here and look at the development environment and do a refresh here. So Argo CD sees the fact that the image has changed in the repo. The image has changed. So therefore, Argo CD assumes that since I had this set to auto sync that I want this at the latest available dev version. And it does essentially a rolling rollout of the new version of the image. So the image tag changed. Changed and get, then Argo CD saw that change and automatically synced it for me. So if I go to my dev environment, remember that it said blue. Right now, they're both matched dev prod. Now it says green. Same as my commit. Now it says green. Production, though, stays the same as blue. So going back to the pipeline, let's see what happened here. If finished, I committed to dev, a patched production. So production, the step here, is that I'm going to patch the image, the latest image here, and create a branch and then create a PR. So then here, now it says, now you have a new PR. Let's take a look at this PR. So if I go to my GitOps repo and look at this pull request, notice that I have a new PR here. This PR here is saying that I'm going to update the image matching dev into prod. So if I click on Files Change and take a look at here, you can see that my Overlays Production Deployment goes from this tag to this new tag that just happened while I built this. So going back to my pull request here, I can, once I've gone through all the code reviews and all of this, all the process that you have in place, I can merge the pull requests. You know, once you merge, I don't need this branch anymore. So I just delete it. But if I go back to my Ergo here and do a refresh, you can see that it now saw that, oh, hey, there's been an update in Git. Let me complete, let me sync that for you and make sure you're at the version you told me that you wanted in Git, which happened to just update since we're using GitOps, right? So now the application is done syncing. I can go over to, you know, this is the dev version. I go to the production version. I do a refresh. And now production shows green. So now they match as they do in the Git repo. So anytime I want to make a change, I can either, to the code base, I can go back here to Visual Studio, make an update to the code base. If I want to change something like, let me go back to my repo, like the scale of the application, I would just do a PR to the Git repo and then our goal would reflect that change. So thank you for watching this video. I hope you found it informative and how you can use Kubernetes native CI CD workflows in order to build your GitOps pipeline. Thank you.