 Hello and welcome. My name is Regina Scott. I'm an associate software engineer on the OpenShift GitOps team at Red Hat. Today I'm going to be walking you through some of the changes in the OpenShift GitOps operator in OpenShift 4.9 and 4.10. The changes in 4.9 are some additions to the UI and 4.10 is mostly some bug fixes and code cleanups so just a heads up if you're already on 4.9. Going up to 4.10 you may not notice a lot of changes in this regards which is why these are being recorded together as one video. The cluster I'm on today is a 4.10 cluster and without further ado let's begin. So the first thing we're going to be doing is generating some Git manifests using CAM. CAM is a CLI tool and it's an acronym that stands for Kubernetes Application Manager and we use it to interact with our GitOps repos. So first what we need to do is log in through our terminal. So you'll go to QBadmin at the top and copy the login command and paste that into your terminal. Next what we're going to do is going to install the GitOps operator. So we'll go back and go into Operator Hub under the administrator view and we're going to type in GitOps here and find Red Hat OpenShift GitOps and now we're going to install this using the default installation options. Once that has installed successfully you're going to go back to Operator Hub and you're going to install the OpenShift Pipelines operator also using the same defaults. So now that we have the Pipelines operator installed it's time to do our cam bootstrapping command. So I'll be using GitHub as my Git service for this demo but this will also work for GitLab and I'm going to be using a public repo but this will also work for private repos in GitHub and GitLab as well. So in this bootstrapping command which I'm pasting here first we have an example of a service repo called Taxi which contains the source code deployment manifests and the CICD pipelines for our demo taxi application. Our GitOps repo URL is just the URL where our manifests are going to be created and I'm calling it GitOps demo but you can call this anything you want. If you already have this repo in existence however then this command will fail. As you can see this is where it would be if it was in existence but it is not. The Docker config JSON is something that I set up already in Kway. I have a repo in Kway called Taxi and I gave a robot account write access to it so when I run my cam bootstrapping command the CICD pipeline is going to build an image of Taxi and push it to this repo in Kway and then I downloaded my Docker config for it and I just have it in my downloads folder so it's getting that information from there. Our Githost access token is a token that I have in my account that should have write access to my Git account. Output is just the location of the file that will be created from the output of this cam bootstrapping command. It will contain all of my Git manifests and it should be the same as what will be created in my GitOps repo URL repo in GitHub that we just talked about above. I'm also specifying that this push to Git is true so that it'll push that GitOps repo URL content to Git and I won't have to do that manually and lastly the overwrite argument is to specify that if anything is already located in the output test folder that it's okay to overwrite it and before we run this command I'm just going to show you really quick under developer view under environments which is where your GitOps UI will be. We can see that there are no GitOps manifests URL found. So now let's run our bootstrapping command and it's been successfully created so now that that's successful we can go back into GitHub refresh this page and we can see that our manifests have been created in this repo. Okay so now you're going to go back to your terminal and we're going to cd into the directory that we just created which is output test. Next we're going to run this command oc apply dash k config argo cd and it's going to create all these apps in argo cd for us. Argo apps, CICD app, dev app taxi, dev environment and stage environment. Now back in OpenShift we can go to the application launcher up at the top click on argo cd go through the security and this will take us to the argo cd login page where we can click login via OpenShift. It's been a little bit so I need to input my credentials again and then I'm going to click alas elected permissions and now I'm in the argo cd app. Now I'm going to be adding a webhook so I go into settings, repositories, connect repo using HTTPS. I'm going to input the repo URL for my GitOps manifests, my username and my Git token and then I'm going to connect. It has been successful and now I'm going to re-sync my apps. It'll just take a second for it to finish syncing. Now that they've all finished syncing let's go back to OpenShift and in our environments page that used to say no GitOps manifests found. Now we can see that there is a list with application name, git repository, environment status and if we had the last deployment time it would be here. Now before we're going into the details page let's add a couple more environments and applications so that we can get a better sense of how it would look like in an actual production environment. So we're going to be adding a new environment first so we'll go into our terminal and we'll do this cam environment add command, give it the environment name called new environment and direct the pipelines folder to be our same output folder that we just used. So it has successfully created new environment. Now we're going to be adding a new service in new environment and going to run this cam service add command for new environment give it the app name app bus service name just bus the git repo URL is a URL that I already have with this bus application and the same pipelines folder that we just used again. So it has been successfully created an environment new environment. So now I'm going to go into VS code and you can see these files were generated for me from cam bootstrapping and the last two cam commands that I ran. So I'm going to be going into new environment under environments which is one I just created apps app bus services bus base and config and then in this I'm going to be adding new files to the config folder here. The first one we're going to add is a deployment email to specify how the service should be deployed. So let's create that in this file we're going to paste the deployment manifest and save. Secondly we're going to be creating the service and save that. And finally we're going to make a customization.yml file to reference to make references to both. Now back in my terminal I'm just going to do the git status. Let's add all of that do a commit with a message just titled um added new service save and then let's do git push origin main. So when argocd sees that changes have been detected in the gate repo it's going to automatically apply those changes to the cluster and deploy this new service. So we can see back in argocd sometimes they can take a little bit but now that we have all of our applications synced and in argocd we go back to the environments page and open shift and now we can see that we have a new application app bus and it has our environment which is new environment. I would just like to make a comparison real quick that this was what the application list page looked like in 4.8 so there are some changes to this so the application name and git repository are the same but now instead of just a list of environments you now get the sync status for those environments and for last deployment it is working now so in this one it was not. So we'll take a look at the details page for these really quick but I'm actually going to be switching over to a different GitOps repo that I set up with a couple more environments for each of these applications so that you get a better sense of what it looks like with more environments. Okay so now I switched over to this new GitOps repo that I had set up previously has a little bit more to it so we can see here that there are three environments dev new environment and prod. So let's take a closer look at this details page from the top. The page begins with the application name and the GitOps manifest URL so if we go here you'll see that this is just the repo that we had set up earlier. Each environment has the environment name at the top as well as the cluster URL and if it's not available it's going to tell you that the cluster URL is not available there instead. It also tells you the sync status options for this can be synced out of sync or unknown and this is the same sync status information that is reflected on the list page right here so as you see this one has three and this one has those same three. The next part is the latest revision metadata so that contains the most recent commit message the author and the shortened commit shot as well as the time of the latest deployment in that environment and then lastly under that we have the link to Argo CD that has the environment application and as you can see it's drilled into dev app bus right there. If we go to this one however it's going to take us to new end app bus. This next section here shows the resources that are available in each of the environments so as we added before in in dev we added a deployment and a services section which if you remember were this 100 deployment and 200 service files that we added previously. Now we're going to do something to make it go out of sync so we're going to say we have our 200 service in dev for app bus let's say we accidentally changed this to the wrong namespace for changing it from dev to new environment so let's save that and we'll do we'll push it to our get repo so that the changes get picked up by Argo CD. Okay so now back in Argo CD it should be picking up these changes we'll just do a manual sync really quick so that it picks it up quicker it will do it automatically but it's only after a certain amount of time so as you can see now there is a problem with the namespaces both new env and dev which we changed to new env are in the same namespace and fighting with each other which is why they're going back and forth so this is making each go in and out of sync so that will be reflected in our details page so if we just do a quick refresh we'll now see that dev is out of sync and our service that we have is also out of sync and that can also be seen in the list page as well and if we hit refresh on this page it should go back and forth between new env and dev so as Argo CD is going back and forth out of sync this is also going back and forth out of sync if you keep refreshing. The last new feature I want to show off is a little hard to force but I'll be showing a screenshot of it instead so if you have a resource that has a degraded status in Argo CD it'll just show this little broken heart icon to let you know that it's degraded. The last thing I want to know is the differences between 4.8 and 4.9 slash 4.10 for the GitHub details page so what I have here is an image of what it used to look like in 4.8 so you'll see that the top still has the app name and manifest file repo but the details cards are similar in some ways but different in many other ways so as you'll see here the cluster URL name time stamp and Argo CD link are all there still but there's more commit message details as well this part also changed at the bottom so instead of showing the the service and the image and a link to the service and the pod details we're now showing the resources instead we felt that it was better for the customer and more useful. So this concludes my presentation on GitOps in OpenShift Dev Console I hope you enjoyed it and thanks for watching!