 So, before we start talking about Github's and ArgoCD, we're going to play a game. A game that the name is Roshamble. Probably most of you don't know exactly what is Roshamble, right? But it's that paper scissors rock game. Yeah, let's say the official name is Roshamble. So we're going to play this game. So please prepare your phones because we're going to play with the phones. And basically, these are the screenshots that you're going to see now. You're going to see these screens that say start game. Then you will need to join the game. Then I will see this third screen, which is we'll wait until we start the game. And one of the key things that you need to see is that you're going to be assigned it to a team. So it's going to be team one versus team two. We're going to collect all the rock scissors and papers. And the most voted of the both teams will just fight and see who is the winner. And to choose, you see that you will have these three buttons, rock, paper, scissors. And then you does a submit move and the move will be sent to our servers. OK, this is the QR code. So I'm going to scan it as well so I can play it. But I'm OK. Hopefully it works. Yeah, so yes, probably most of you say here a start game. Then you push a start game. If you get any warning about certificate, no worries. We're not stealing your data, nothing. It's just that I deployed this in my cluster and I do not have a valid certificate in my cluster. That's all the things. So you do a start game, then you will this. You put join game and you will get something that the game will resume soon. OK, so I'm in the team one. Probably some of you are in team one or in team two. OK, now I'm going to show you this is the administration dashboard. OK, so you see team one, team two, and then you will see your move. Now when I push new game, we will start. OK, so now I push new game and now you see rock, paper, scissors. So it's time to vote. So in my case, I'm not going to say you what I'm voting. I submitted my move and say processing and said the next round will begin short. OK, you see here that we've got like 37 rocks, 26 papers, 28 scissors. I'm scissors. OK, so and now it finished and oh, there's a tie. So it seems that the most voted move was the same in the team. So it's a tie. So let's do the next round and let's vote it. So I vote it. OK, let's see if now there is some kind of it's three rounds. OK, so it's not the long. Let's see. Yeah, maybe let's see. Maybe it's time. Oh, no, team one. So it's my team. We win. OK, well, that's great. And now the last round. So let's go ahead again. I'm going to vote the same because we get it. Good, good thing. OK, good, good, good. Oh, it's almost there. Seven, six, five, four, three, two, one. And hey, tie again. So congratulations to the team one because we are the winners. OK, so great. I see here we are the winners. Right, it's super great, right? Then I'm going to here. And let's start to see about, OK, this is a game. And what is this game about RCD and GitOps? And we'll see in a few moments because at the end is, what is GitOps? OK, yeah. GitOps, as you've seen, is a methodology that will help you to deploy to production faster. And at the end, for your company, delivering value is a key point, right? It's something super important. So you need to go to production as fast as possible. And GitOps will help you on this because maybe if you're not using GitOps, maybe delivering to production is something like this, right? You see all this is your application. And you can see here all the developers saying, yeah, we want to put in production this new feature, which is super cool, right, usually it's in this way. And then, oh, yeah, this is the product owner. The product manager say, no, no, we cannot go to production yet. We need more features or maybe the security team. No, the application is not security at all. Just not trying to stop the application. Oh, there is this guy. This guy probably is the architect, right? He's surfing right on your application there. Yeah, it's super cool architecture. It's going to kill it. And oh, yeah, probably this is the DBA. This is the DBA here. You're like, oh, wait, yeah, OK. I need to create some index. And oh, no, don't delete a column and things like that, OK? So usually it's in this way. When you try to release to production, and the problem in this happens once and once and once. So it's always the same thing. So probably what we need to do is change this to something like this, right? You just want to make a small application. It's super easy, right, to deploy to production. And this is exactly what DevOps helps you. So DevOps is just the key to meet the insoluble demand for delivering quality applications rapidly. So it will help you to deliver to production this value that helps to grow your company or your customers. But what is GitOps? OK, yeah, we could say that GitOps is somehow an implementation of DevOps, maybe, where you've got a Git repository that contains the single source of truth. So everything is there, not just your code, but also all your infrastructure. So how you deploy your application, how you build your application, all this stuff, how you configure your environment, everything is in Git. And one of the great things is that all the operations goes through Git workflows. So you see that you can do branches. So you can have one branch for production environment, another branch for staging environment, another branch for performance environment, right? And you start doing merges between branches. And then you are moving your application from one environment to another by just doing pull requests, merge, and so on. Then as you can see, at the end, GitOps is just a developer-centered approach to continuous delivery and infrastructure operation. So we are not inventing anything new. It's just what developers has been done for thousands of years. Well, yeah, with CVS first, then SVN. Now, yeah, we're with Git. We've been doing this for a long, long time. Then let's move the infrastructure operations also to this style. So why GitOps? OK, basically GitOps. It's using Git because why we need to learn a new tool? It's Git. It's super powerful. It works. We are used to work with it. So don't let us do not re-bend the wheel. Just use it. Then also innate you allow the security because remember that I said that you can send pull requests to update infrastructure or to update your application. For example, if you want to go from version 1 to version 2 of your application, you can just send a pull request. And if you send a pull request, it means that someone can review. And can say, hey, are you sure that this property value should be this value and not another value? Or are you sure that you want to go to production right now and not wait until, I don't know, this patch has been delivered wherever? So it's really important that anyone can review. And what is even more important is in my case, in the past when I was not using GitOps, sometimes we updated an application from version 1 to version 2. And we set it parameter. We changed the value of one parameter. For example, the database connection pull. And in these cases, after six months, we said, hey, why we changed this value? And no one remembers because in six months happened a lot of things. But things of GitOps, you can always do a Git log and see the message. And in the message, maybe you say, yeah, we're increasing the database connection pull because we're seeing an increase of users. So it's like, oh, OK, now I know why we added this change. Or maybe we want to ask the guy who or the developer who did the change, we can do Git blame, see who made the change, and ask him. So it's really nice, these kind of things. And finally, it helps you in the multi-cluster consistency. It doesn't matter if you've got just one cluster or several Kubernetes clusters, you can always deploy in the same way in all the clusters. So it's a really good technology. So what is the GitOps application delivery model? How we adopt these GitOps? You can see here at the bottom, sorry, on the top of the slide, the GitSource repository. This is just the Git repository where all applications is stored. We've got the CI, the continuous integration pipeline. We just build the application, run unit tests, wherever you want to do some kind of static code analysis. And finally, let's say we register or we push that container into an image registry. Of course, now we are in the container's era, so probably it's a container. But in the past, sometimes it's a jar file. So at the very end, you end up by publishing a container into an image registry. What happened after that point? The application is built. It's time to deploy it somewhere, maybe in a staging. How we do this with the GitOps? We do it doing a pull request. So basically, we've got another Git repository, which can be the config Git repository, infrastructure Git repository, call it whatever you want, but basically contains all the manifests to deploy this application, to configure my environment to deploy this application. And in this case, maybe I would send a pull request saying, hey, this manifest, if you will, this Kubernetes manifest, let's change that tag of the container image from version 100 to 200. And I sent a pull request. Of course, this is just a pull request. We will need to wait until someone merge this change into the config Git repository into the main branch. Then when this change happens, there is this continuous delivery part. Basically, it will take this change and deploy it to the Kubernetes cluster. I know that some of you might say, oh, but what is exactly inside this continuous delivery part? And it's this part, okay? So you see that basically it's a monitor part, which is monitoring any change in the config Git repository. So just checking, hey, is there is any change? Anyone has merged something to the main branch? Maybe someone has changed any manifest file. It's monitoring this. It detects the change when it happens. So it detects this drift and then it takes the action. So basically it says, oh, look, someone has updated the deployment YAML file and now the container image is not the 110, it's the 120. So what I'm going to do is deploy or apply this change to the configured environment. And then we start it again, just monitoring for any change. This is how the GitHub application delivery model works. Of course, we need an implementation of this, you know, of this monitor, detect drift, take action, deploy. We need a tool and this tool is, or one of these tools is Argo CD. Argo CD is an implementation of this life cycle of this workflow for Kubernetes. So you can use Argo CD if you are using Kubernetes. And basically it helps you to configure the cluster but also the application. As I said, GitHub, it's not only about the application itself but it's also about the environment that is required by the application. It automatically syncs configuration from Git to the clusters. As I said, you've got a Git repository, just detect the change and you apply this change and it can detect exactly this change and visualize what was the difference. Okay, so you can always get the dashboard and say, oh, look, before it was this and now it's that. And you can, for example, grow back to the previous version as well. They have a granular control over how you apply these manifests. Okay, so sometimes you won't just apply the YAML files but sometimes what you want to do is apply the YAML files in a certain order. For example, you want to first deploy a database and then your backend because it has not much sense to deploy the backend before the database or maybe you want to deploy the database and then apply some SQL script files for configuring the tables or inserting new data. In these cases, you want to first deploy the database and then apply this script files. This is what you can do with Argo CD. You can always roll back and roll forward to any Git commit because it's Git. You can deploy the new version, see that something was wrong and how you get back to the previous version, it's super easy, Git, Rebirth. You do a Git Rebirth and you're done. You've got the all version deployed to the cluster. Argo CD supports not only Kubernetes YAML files but also help and customize and even you can create or has an extension point to create your own way of deploying to production. And you will see that it comes with a really nice dashboard with all the information, if you will, that you can find it interesting. So let's do a demo about this. Here, this is my Git repo where I've got the game that we've seen at the beginning. You see that here. Well, this is the Argo YAML files. This is how you configure Argo CD. Basically, you just create a type of application of type Argo project and here you define where is the URL, where is the Git repo where all these manifests are to deploy this application. And then here, here in the key, double key, it is, it's the manifest files. You can see here that it's the how I deploy the backend, how I deploy the front, and it's the game. Now I'm going here to backend deployment and I'm just going to do it in this way, but you know that you will create a pull recalls and so on. And I'm going to change here the version from buttons because we've played with buttons to camera because you know what's happened is that sometimes comes your manager and says, oh, I really love that Roshambo game but I would like that people can play with the camera. So it just takes a picture of his head, right? And then we detect what is the shape and we play it in this way. So this is what we've done. We just go there, just we implemented super quickly. We just create the container image. Now I'm changing manually and I'm going to commit this change. Let's put here something like update to camera. I commit the change. Okay, and now here you see that this is the Argo CD dashboard. This is my application that was run before, right? With the buttons version. And you will see that when the change, I mean, I've done this change here and then we are sending a webhook to Argo CD and automatically we'll detect the change and deploy the new version. Let me oops, here not. Here, you see, let me refresh some time. I don't know, maybe I've been logged out. No, yes, for the reason I'm okay. I mean, and the password is co-argo pass, I think that this, no. Here, eco-argo pass. This is the password sign in. And now here, you can see that you can see here that now it's synced with update to camera. So I've not done anything at all, just updated the commit and automatically the Argo CD deployed my new version. Now, now we've got the new version deployed. Let me go here again. And now what we've got is exactly the same application but now when you refresh, you'll get the same thing with capture move and the camera. So you will need to put the hand in front of your back camera and do the sign, okay? Every time that you push the capture move, we are taking a photograph, no worries. We are not storing the photograph, it just send it to the front end, the front end sends to the backend. It just computes something in the backend, in the Quarkus backend. And then we send it to OpenShift data science, which basically it's a TensorFlow application that takes the photograph, interpret exactly what is the shape and we send it back. Just one thing is that since our manager was really in a hurry and wanted that, have this new version deployed to production pretty fast, we didn't have much time on modeling this data science picture. So expect some weird results, okay? So another thing, yeah, when you refresh, you will see grand camera access, okay? Basically, it's because we need to have access to the camera so we can take the pictures. And that's all. If you are already with the application open, just refresh the application and you will see it again, this star game. If not, just scan the, just scan them. I would say that the QR code and done. Okay, now I'm put a star game, it saves me grand camera access, okay? Grand camera access, yeah, I allow you. Yes, okay, that's nice. And then at the bottom, you see join game. Remember, just push join game and we are back to the screen where we are waiting until the application is up and running. Yeah, now, another thing is that in the dashboard, there is this button that says battle music that if you click it, because this is open source, I mean that you can use it anytime, you will get it here, let me just wait, go here. So now we're going to have some music as well. Here it is, from the beginning. So we need to go in a hurry, okay? Now, let me refresh. Okay, and we're going to start the new game. But now with the camera, so you need to just take, yeah, now everyone sees what I'm doing. Okay, it's done, and we're going to stop it. Why, I think that you're waiting for the next round. Wait, let me, wait, new game. Okay, let's try it again. Let's try, now I put the rock, while I'm going to, oh, 500, great. Okay, so it seems that we screw something during the update, let me, yeah, now, what I'm going to do, and it's super interesting, is that I'm going to scale down the application to zero, and you see that it automatically starts again to one instance, basically because remember that we've got ARCO CD, and ARCO CD don't let you scale to zero because you need to do it using GitOps, okay, for the reason we get it this, and now I'm going to start everything again, just in case, I think that the, this is, oh, sorry, this is the front end nut, I need to open the back end. Let's try it now, let's do a refresh of the application. We do a store game, grain camera access, okay, join the game, okay, now, hope that everyone is again here, I'm going to start new game again, and I'm going to capture, put it the rock, now let's see if it works or not. I've got an error, in my case, I got it an error, okay, and I don't know why you don't, okay, I'm going to leave it here because I don't want to spend more time on this. In theory, there should be this that the winner is, but I don't know why there is no winner, I will figure out why it worked yesterday and not today, maybe because a lot of people playing, I don't know, but I will figure out. Then, let's continue, but yeah, you've seen that with just changing the YAML file, everything was doing a rolling update and updating to the new version of the Roshambo game, and also, you've seen that if I try to modify the resource, for example, scaling to zero, automatically, I will see also the text that you are changing something in the cluster that is not in Git, and then it applies and it gets back you to one instance, so if you want to change the replicas from one replica to zero replicas, you need to do it through Git. So, with Argo CD, you'll see that there is a lot of different ways of deployment strategies that you can follow to have Argo CD in your cluster. One way is the central hub. Basically, it's okay, I've got one Kubernetes cluster with Argo CD. This Argo CD, of course, is getting inputs from several Git repositories, and then these changes are promoted to different Kubernetes clusters. It's a cluster that is not where Argo CD is running. Okay, you see here that I'm just having three clusters, and it can be Kubernetes or OpenChift, and I'm just promoting these changes to these clusters that are not where you are running Argo CD. Then there is a cluster scope. The cluster scope is a bit different. It's where you've got Argo CD running in the same cluster where you want to apply these changes. Okay, and basically you apply YAML files or changes that are on the cluster scope. For example, the registry, the configuration of the networking, the storage, like volumes, persistent volumes, and so on, install operators, create name spaces, all these kind of things that are more cluster scope are running in this way. And of course, then there is application scope, which I would say that is the most use case where you've got Argo CD running inside the Kubernetes cluster and deploying your application. This is what we have seen before. Then remember that I said that you can also define the order of what you want to run the manifest. So first you want, for example, to deploy a database and then apply some scripts against this database. So you want to put some order, and this is done by sync waves and hooks. Okay, basically you can just define in which order you want to run some manifest and then automatically Argo CD will run it as you specify it. But it's important to notice that sync waves is where you put numbers. So if you can see here that I'm setting a number zero, number one, number two, number three, so this is the order, but you also have one thing that is named hooks. And you can say, I want to run this before I run all this part. So the pressing is something that you run before you're starting the synchronization process or even you can run a posting, which is basically, okay, when you finish to deploy everything and everything is ready, then run the posting scripts. And here you can run, for example, some kind of testing jobs, right? You can create a Kubernetes job that tests your application has been deployed correctly. As I said, there is some good news. If you like GitOps and so on, you can just scan this QR code and you can download it, GitOps Cookbook for free. Okay, so just you can scan it. You need to register to developers.redcat.com and then you can download it for free. And the other thing is that tomorrow I will be with Natale, which is around my friend that we wrote this book and we will be in the redhead booth signing. And I know that there is a limited quantities of books. I don't know how many are, but we'll be there together and you can grab a physical copy, sign it, I ask. And yeah, of course, also it will be there if you're interested in Quarkus and Java and developing Java application for Kubernetes platform, then I will be also signing there the Quarkus Cookbook, which I think that it's also available to download it for free. And basically that's all. This is, these are some links. If you want to learn Argo CD, this is the end and the end of the Argo CD tutorial. We've got the GitOps Cookbook to download it and this is some stuff. And that's all. Thank you very much for the session. And I think we've got like one minute for questions, but in any case, I will be around and you can approach me at any time and ask me anything. Thank you very much. Thank you, Alex. We have some questions that you have been submitting. So let's go through the questions. Yeah, I said, is it mandatory to have a separate repo for deploying the application? I run a large monorepo and it might be interesting to have both deployment and deployment in the same repository. You can do it, but maybe you end up with some kind of recursive deployments, okay? Because what's happened is that you've got Argo CD. Okay, Argo CD is listening for a change in a Git repo and then when you change the deployment file with a new version, it's also a change. So it sends another, so it just sends another triggers another thing. If you've done this automatically, it triggers a new build that at the same time will do a change. And since it will do a change, it will trigger another build and you will end up with an infinite loop, okay? So if you are doing all this stuff automatically you can get these kind of problems that you end up with a recursive build. For the reason I always said that it's better to have two repositories to avoid the situations. Question from Tim. Can you elaborate how Argo handles... Oh, yeah, can it change the config values in relations in Argo CD directly? Does it automatically get commits then? Change the config values. Yeah, I think config values, you mean the config values of your application, I guess. Yeah, you can change it in, for example, in the config map, you can just update and then Argo CD will automatically update the config map that you've got in the cluster. The problem is that you will need some kind of hooks to do a running update to your application itself for getting these new values to the pot. Or you can also use some kind of tricky things which is creating an annotation, usually an annotation, with a hash, okay? So when you change the config map you can create a hook that changes this hash. And then since it will also change the YAML file Argo CD will deploy the new config map and the new deployment, so you get this new rollout for free. Say that, can you look at how Argo HEN does customize with overlays? Yeah, you can work with customize, you can also set some configuration properties and basically the text that automatically Argo CD detects that there's a customize.yaml file, it detects and then apply like it was a QVCADL-K command, okay? Advantages of having Argo polling the repository and update the cluster versus having a pipeline in the repository that runs automatically after every comment and updates the cluster. Yeah, basically I would say that the question is like, is it better to have everything automatically done or manual? Well, it depends on how mature is your organization at the end. I recommend you to start manually, so just don't do any web book, nothing, you just do a push to the main branch, then you go to the Argo CD dashboard and you say, okay, now I feel comfortable, I've tested, I'm going to sync. And well, you've got this sync button here. Here, the sync button basically checks if there is any change and then apply the changes. So I recommend you at the beginning to just do the change in your Git repo and then when you're comfortable, just push the sync method and Argo CD will do the rest. When you're comfortable, then yeah, let's go to the automatic way. More questions about best practices. Best practices for Argo CD configuration, how to apply it automatically? We don't want to click around the UI but use a GitOps approach. Well, yes, with Argo CD, I know that most of the things are configurable with YAML file, so I recommend you is to have a special folder in your repository where you can configure the Argo CD. If not, if you say, yeah, but I want to do something that it's not in the, I can do it with the YAML file or it's more complex, then you can always create a Kubernetes job with a container that has Argo CD, a CLI tool, because there is a CLI tool which is called Argo. And then you can just put that inside the container, you log in into the Argo CD and then you start running these comments as a shell script inside a Kubernetes job. So it's another way of doing it. Another question from Cristina. From the point help charts. When the point help charts, can I set different values for different staging environments? Yes, you can do it by changing the values.yaml file. You know that there is this values.yaml file in help, then you can just do a commit there. Also keep in mind that this is a big question because you can also define the Argo CD listen for several branches. And depending on the branches, it deploys to one environment or to another or uses some values or other values, okay? And this is name it application set. Basically application set is like a template of an Argo application. And there you can just get the branch name and then start changing things. But what I suggest you is that if you want to use Helm and several environments, for example, having one branch per environment. One more form. Oliver, big difference to implement anything. What are the benefits of the, what is the big difference to implementing it in Jenkins? Well, difference probably there is, I mean that not a big difference is just having something that it's Kubernetes native and something that is more general proposed. In both cases works, both cases, it's useful. If you feel comfortable with Jenkins, just go ahead with Jenkins. If you want something more native or you are not into the GitOps thing yet and you want to give a try, then I would suggest going to Argo CD. We will have time for five more minutes for... Yeah. What are the benefits of the different ways of operating Argo CD? Oh, well, yeah. I would say that, I think that you're meaning if the cluster scope, sorry here, the cluster scope or, yeah, at the end here, I think that you mean with this. If you have a central hub or not, well, it depends. I would say that if you are starting, I mean that ideally everything should, I mean that except this central hub, which usually I've never seen having just in a Kubernetes cluster a specific for running Argo CD. Usually what I see is that one Argo CD running inside the Kubernetes cluster, because usually people have only one Kubernetes cluster, okay, so usually it's that way. So the advantage is, if you've got several Kubernetes clusters then go with the central hub approach because it will be easier to just deploy to several clusters. If not, if you only have one Kubernetes cluster with several different name spaces, where for example you've got one name space for staging and another name space for production and so on, then a cluster scope or an application scope. And here it depends. If you just want to deploy your application using GitOps, then go to application scope. This is what you're going to do. But if you or the Kubernetes administrator says, well, yes, but I also want to administrate the Kubernetes cluster in using GitOps and not in a manual way of doing give-call applies, then yeah, then it's a cluster scope plus application scope, which is basically the same. The only difference is the kind of YAML files that you are applying. One from Mohammed. Can I deploy different branches, tags in the same application? Yeah, you can deploy different branches and tags of the same application. But of course you will need to decide if you want to apply this in a different cluster or in a different name space and so on because you're not going to start overriding everything. But yeah, it's called application set. Okay, so you create an object which is an application set and then in the book it's explained it. So if you download it in the book, here you will find all the, all how to do it. And one final one from Sebastian. Can you manage and update your Argo CD deployment as part of your cluster with? Argo CD itself. Well, at the end you need an Argo CD. So this is, so you can, for example, you could have an Argo CD that deploys Argo CDs in other clusters, I think that this is the question, but at the very end you need to install an Argo CD and that's true as far as I know that you will need to do it manually or for example, using some tools like for Ansible. Ansible, I'm speaking about it in one hour or something. There you'll see that you can manage all these zero-day Kubernetes cluster tasks with Ansible. And with that, we have other questions. Well, maybe, maybe exactly, but I need to jump because it's already two o'clock and we need to move into the next session. Yeah, but I'm here, so just feel free to come. So for the remaining questions, if you don't mind. And Alex will be with us answering. Okay. Thank you. Thank you so much, guys.