 To begin with, as I said, the day is full packed in this session. A lot of demos that you guys really would love to. And it will help your learning as well as using those technologies in your day-to-day work as well. So to begin with, we have Burr. You have heard him in the morning. He is the director of product management and a very awesome guy. He's going to start right now with GitHub with ArgoCity. Burr, all yours. Thank you. Thank you so much. All right. Pretend like you didn't see me before. Yay! This Burr guy is here. I'm kidding. I am very sleep deprived, so I got to stay on, otherwise I fall off, if you don't know what I mean. And be careful with that spot in the middle. That's where the internet comes into the building. You guys got to control the wire over there. OK, we're going to talk about this thing called GitOps. And GitOps, of course, is kind of one of those happening powerful, everyone's got to do it kind of moments. Don't you love that about the tech industry? Everyone was doing microservices five years ago, and now you're like, microservices. That's old stuff. And actually, you guys know about the Gartner hype cycle? You should be familiar with the Gartner hype cycle. It basically tracks when things are all hype and buzzy and all that. And then it goes through the trough of disillusionment, where people are like, that thing just sucks. And then it comes out to the plateau of productivity. Well, microservices just graduated through the trough last month. So now we're going to all be doing microservices and not talking about it anymore. Isn't that cool? That's basically what happens. You talk about it, talk about it, and it sucks. Then you just do it and stop talking about it. And every technology goes through that cycle. Eat some, go through it quickly. Like, Kubernetes kind of flew through it, right? I'm not even sure if it ever had a trough of disillusionment that anyone really noticed. But other things, like maybe relational databases, I remember when it went through that, you go through, everyone's got to do a relational database. Oh, relational databases suck. Oh, everyone's just doing relational database. So we're going to be talking about GitOps, which is going to fall in that category. Here's one tricky bit with GitOps, though, to get your head around. This principle, this technique, it's actually a technique, kind of like DevOps is a set of principles and techniques more than any technology. In this case, for GitOps, it's a technique. But it's only really available in the Kubernetes ecosystem because that's where it's been implemented. There's two different projects that implement it, one called Argo CD and one called Flux. So you might run into GitOps via Flux, you might run into GitOps via Argo CD. There's also something we call Advanced Cluster Management at Red Hat. You might have seen it, Advanced Cluster Management. It also has a GitOps feature, too, because once you understand the basics of the GitOps feature, it's really straightforward. So we're going to talk about that. But one thing I want to kind of do is just give you a quick kind of, let's see what I can do here kind of on the fly. I didn't plan for this, but I want to just discuss it briefly. So if I come over here and say, Git pods, right? So I'm talking to my database, let's just make this window bigger here, okay? So I'm talking to my database, sorry, whoo, not awake. I'm talking to my namespace in my Kubernetes cluster. You can see here, I have a bunch of interesting things running, I have an infinite span running. So that turbine application, when you're pounding on it or shaking it, it's shooting the data right over to the server. The server is in this case has Kafka and Kafka is three Kafka brokers with three Zookeepers. That's a production grade Kafka, right? So Kafka is receiving that stream of data and Finispan is collecting the leaderboard data. That's where it's getting aggregated so the leaderboard can get updated. And of course there's this windmill application. So this application is these five pods running right here. So in most cases, you will run an application pod with two or three or four, so you can just kind of load balance, right? A little failover, a little load balancing, a little high availability. So my application pod is this one right here. And we just decided to pick five. We could handle, I don't know how many people tried this morning, was it 200 people, 300 people? So you can handle 200 or 300 people just jamming transactions at you pretty fast. Probably could have done that with two pods. But we have five. It doesn't cost you much to run a couple extras because this is Quarkus and Quarkus is very small. So Quarkus based app is a Java app, but Java, this in case is a small Java application. But you can see what that's the application, that's the back end. I said Cube CTL get pods because what we do in a Kubernetes world is we stick all the containers in a pod. And you can actually tell how many containers are in a pod with this one slash one. So this is important because what you'll see in a little bit is some of these are different. See the three by three there? Three containers in a pod. When we run Tecton, you'll see like one or two or two or three. So sometimes you can have more than one Linux container in a pod and that's just something Kubernetes has always had. That's actually why they use the word pod instead of container. You can have more than one container in a pod. You don't normally, okay, so by default you can mentally think one container image, one pod, but there are special situations that are interesting that you'll see in Istio, you'll see it with Knative. If you were here three years ago, we showed you Knative, Istio and Tecton. This year we're kind of focusing on some different technologies for this event. Okay, so just be aware of that. And there's another thing that's super important. Let me just try this real quick. OC New Project, let's call it Burr. If I did that right, okay. Kubernetes, let's see here. I'm going to be in the Burr. Yeah, I'm in the Burr namespace now, so I have a Burr namespace. Okay, if I say kubectl get pods, there should be no pods in that namespace. kubectl get all. There should be nothing really in that namespace. It's an empty namespace I just created. So this concept of namespace in Kubernetes is like a folder. So get all, it can take a little while because it's searching for everything that might be in there. So I just created an empty folder within my Kubernetes cluster, and now I can put stuff in it, okay? So one key element to understand about Kubernetes, if I say kubectl get CRDs, grew up Kafka, have you folks heard of CRDs, custom resource definitions? So what this means is you can actually define custom types for our Kubernetes system. In other words, you can decide you want beer, pizza, right? Paneer, it doesn't matter what it is, aloha, you know? I love you. Any type you can create, like for a database, you can create a type in the Kubernetes world too. The tricky, the difference is when you create a type here, you also need to provide a controller that reacts to that type. So if you decide I want an aloha type, you would build a controller, and you can build that controller in multiple programming languages, though it's common to build it in Go because Kubernetes is written in the Go language, but there's Python controllers, Java controllers, et cetera, JavaScript controllers. And then every time the system sees a new aloha, you might respond, logging out the word aloha, welcome to Hawaii, right? That your controller does what it will with that data type, okay? So this one is called Kafka. That's like the Apache Kafka broker. And what's so powerful about that is I can come over here and let's say I want to basically send in a Kafka broker. So I'm gonna say QCTL get Kafka's, so there are no Kafka's up my sleeve at this moment, but I can paste this in, and I can say QCTL get Kafka's now, and we have a Kafka, my cluster coming online, and if I say watch, QCTL get pods. Basically the Kafka controller will take that declaration, that request for a Kafka object, Kafka custom resource, a CR, and it's going to make it a real live Kafka broker that's ready for production. So these little basic Kubernetes concepts are important to understand because everything hangs off these principles. You can basically override the service behavior, that's what Istio and Knative are doing, and you can override these custom types to do what you will. So we did this with Kafka, and now I have a nice, it's not fully running yet, but I have a full production ready Kafka in my namespace now. And I did that through this concept of a declaration. All I did was throw YAML at it. That was it. And the reason that's so important to understand is that's how the rest of the magic works in the Kubernetes ecosystem. So when you see Argo CD and this thing called GitOps, all it's doing is going, is the YAML that I have in my cluster different than the YAML in my Git repo? That's it. That's the whole magic trick, right? And it's kind of a cool magic trick. Because it's declarative in the cluster, it can basically say, is my YAML different here from there? If it's different, sync it. And that's all it is. And when it does that, it does look like magic. It looks like you just deployed applications, in my case, all around the globe, with a simple Git push, because that's what it is. Just Git push. You've changed the YAML in the Git repo. It's gonna find those objects in memory and fix them there. So that's the beautiful thing. And to understand this a little bit better, so I can say QCTL Git Kafka is now, right? And I can say QCTL edit Kafka, my cluster. I can come in here and edit it. And in this case, it's gonna open it up in Visual Studio Code. And so let's say I don't really want the, I have the three replicas. Let's say I want the one replica of Zookeeper, and one replica, so I don't want high availability anymore. I want something cheap and fast. I'm gonna hit save there. I'm gonna close that. And by the way, I've tried this before. I thought I'd try it live with an audience. Let's see what happens here. All right, and see, it's starting to terminate one of my Zookeepers there. And I think I changed the Kafka one too. There we go. So I'm now saving memory and CPU. It's no longer highly available, but maybe this is the only Kafka I need. But what I did was the key part. I can basically say, hey cluster, give me the YAML, let me change it on the fly, send it back. That's what Argo is gonna do, right? It's gonna look at the Git repo and sync it up. Yes? In this case, there was no Git. I literally edited the live object from the database, right? So, etcd is the database in this case. I went to the API, said give me the live object out of the database from the live cluster. By the way, you'd never do this in production, right? But it's great for training purposes and great for development purposes. And okay, so we have that now. And so let's just, by the way, and if I decide I don't want this anymore, I'm gonna do a QCTL delete Kafka by cluster. Okay, so I'm just gonna clean that up, save that memory. Well, in that case, there was no Argo CD. That was Burr doing all the manual changes. And Argo CD does something very similar. It edits the YAML for you. I did it manually. Yeah. Okay, so let's kind of get into this and we'll talk about it. We did that already. So we're gonna talk about what is GitOps, the techniques, the technologies, and then Argo CD and walk you through some examples. So GitOps really is nothing more than a principle, a technique, right? It's a technique. Just keep that in mind. DevOps, of course, is the key to meet the insatiable demand for delivering quality applications rapidly. The point here is what we made in the earlier presentation. It's Dev and Ops working together to build better software ever faster. And of course, when I say Dev and Ops, I mean the security team and the architecture team and the project management team and the product management team. You know, there's project management and product management. All of the above have to play nice here. UX, program people, because we wanna build better software ever faster. And so when it comes to CI CD, CI continues integration. Well, that's where some like Tecton comes into play or Jenkins or some other tool, GitHub Actions. And then CD, that's where something like Argo comes into play. So Argo helps you get an application distributed. Tecton helps you get an application built. Now Tecton can also do both, right? It's a generic workflow engine. You can do what you want with Tecton, but Argo has a very nice CD solution. So put CI with Tecton, okay? And then CD with Argo. So in the case of this process though, you wanna build, you wanna test, you wanna run your security checks, you wanna basically release, right? Think of that as your continuous integration. The release in this case is an image to an image repository. So in the case of a Docker build or Kubernetes apply-f, right? There's always this image that we're carrying around with us, right? It's the Linux container image and you gotta release that container image to a repo of some sort so you can go look at it later. And then you gotta deploy. And the deploy to stage, deploy to prod, that's where your continuous delivery and Argo CD does the deploy, right? I did the deploy manually live in front of you, but Argo CD will do that automatically when you set it up, okay? So GitOps basically means the Git is the source of truth. Put everything in Git, right? So all your operational stuff goes in Git also. Your operational stuff might be your Ansible playbooks. It might be your Bash shell scripts. It might be your PowerShell scripts. It might be your Argo CD declarations and those operational things go into Git repo. And the good news is, if someone actually has an accident and I actually saw this happen, someone had a car accident and they were the only people who knew how to make changes to the system. They were out of work for four weeks. They actually could not release any software for four solid weeks because that person had all the scripts on their hard drive and never checked into the Git and never wrote any documentation on how to do an update to the system. Has anyone experienced anything like that before? Right? Yeah, so it happens, right? And it wasn't a car accident though, but it was just, yeah. So put everything in Git, treat everything as code, okay? And then operations through Git workflows. Do your operations through some form of automation that comes from a Git repo as the source of truth. So automation and Git as the source of truth. So it's also a developer-centric approach though. Developers like Argo CD because they can now say, hey, with this little bit of change to my Git repo, and you saw it earlier in the earlier presentation, all I did was a Git push and it rolled all the way out. As a developer, that's awesome. I didn't have to do anything. All the checks and balances were checked and everything just automated. If anything was bad, it would have failed, but it was clean. I didn't make any bad code changes. I didn't introduce any major CVEs. And it just works. So people really like this concept of Git because Git is something you already know how to use. It's a tool you already know how to use and version control is a good thing. And I say that because some of you might remember when we used to use version control where I would bundle up the code on my system and email it to you and with a subject line of 1.0, that used to be our version control system. Anybody used to do that? Yeah? And then you would email it back 1.1 after you made a change? Yeah, some of you think it looking at me like I'm crazy, but some of you old timers know what I'm talking about. That was version control, literally an email. Okay, so version control is a good thing. You want to review changes beforehand, detect configuration drift. And one of the things Argo CD does is it does drift detection automatically for you. So the Git is a source of truth. If what changes in production does not match Git, it goes back to Git and gets the source of truth. And so you can try to hack it and it will respond the way Kubernetes responds, but then it fixes itself. Like all things in Kubernetes itself, healing, right? So that's the other nice thing about Kubernetes and account Argo CD works. You also want to think about your visibility and audit trail because everything is in Git. You know who changed what? There's your audit trail. Someone changed those files. It was Burr who changed those files. Now I know who to yell at when things break or sue if I need to sue somebody or fire, fire somebody. Everybody loves that, right? Auditability, right? You want to know who to fire. What throat to choke? Multi-cluster consistency. Argo CD works across many clusters. I deployed earlier to one cluster. What I'll show you next is I'll deploy this recluster simultaneously, okay? So it is about having a source Git repo based on your CAI engine kicks in. It creates the image in the image registry, okay? Then there's a configuration repo. This is, think of this as your Argo CD GitOps repo. And that basically makes a little update here. And then the CD system pushes it out to the production environment, okay? So let's actually, let's move along here before we run out of time. So it's all fully declarative. The declarative aspect of it is related to that YAML thing I showed you earlier, right? Because it sees everything in the YAML world, it can fix the YAML changes that have to be made. I did it manually. Argo CD does it automatically. All right? Let's see here. Yeah, this is all easy stuff. We'll go play with these things. What I wanna show you is this example, okay? Let's do this one more time. See where it says aloha right here? Let's kinda walk you through this one more time. So earlier, I made a code change. And okay, there, there. And I made a change right here where it says aloha. And let's go make this bonjour at this point, right? Make it French. And so this is just a little polling endpoint so I know that stuff is happening. So the actual application does a ton of stuff. I'm just simply updating one little endpoint and I have a polar. So I just know when the rolling upgrade happens. That's all that is. That's what happens there. And then if you want to enable the shaking thing again, I can say true here, all right? Inside the app. But I made, all I did was make two code changes. So git status, right? There's my two code changes. I can git diff, right? And see what they are. So I'm sort of doing main and web and then source and config, right? See, I enabled shaking false to true. And I can do a git commit. And, you know, made it true. And I can do a git push. All right, so here's the magic trick. The git push goes to GitHub, right? So it goes from my laptop out to GitHub and then a web hook triggers the tecton pipeline. So let's actually go look at that. So over here, here, OK. So right here, you can see this pipeline should be running now. So there's a pipeline running. And it's called a pipeline run, a PLR, pipeline run. So in this repository or in this cluster, QCTL gets CRDs, remember? Grip pipelines. You have this concept of pipeline objects, just like we have Kafka objects. We have pipeline runs also. And we also have something called tasks. And those are all tasks or part of pipelines, obviously. And so those guys make up this thing called tecton. So just like we can declaratively create Kafka's, we can declaratively create pipelines. And so the pipeline is now executing. And so if I say QCTL get pods now, we will see there's the 01 completed. So that's the git clone pod. So the first thing it has to do is git clone. That's how you do a build, git clone. Then it's doing a maven build. And it says not ready, but let's look at it again. OK, it's still not ready. It takes a little while to do maven build. Let's go look at it here inside the user interface. So easier to look at with a GUI. There we go. It's doing the maven build. If you're familiar with maven, you're used to downloading the internet, waiting for a while with maven. But it's going to go through that process, right? It's going to go through the process of git clone, maven build, build it build. You saw a builder earlier. That's the image build. It's going to push the image out to Quay.io. So right here where it says three hours, we're going to see that get updated. And then once that build-to-build gets updated and goes out to Quay.io with the image, it's going to do one final tweak to a GitOps repo. It's going to come out here and update this little digest with the latest image tag. So it knows, ah, something changed. And this little change is what says, argocd. Hey, something has changed. Sync your production runtime with what you see in this Git repo. So as simple as that, even though it's kind of complicated, I realized that. There are a lot of moving parts here. But it's kind of a cool technology, right? It's kind of the way it works. So let's actually go back to the slides, though, because I do have another way to describe this. Let's see here. So that's the app. And actually, the nature of the app, by the way, is, again, it basically had that client that you guys were playing earlier. So you assign a player name, and you assign a team, if you remember, there was blue versus yellow. And then you increment the cluster counter, right? So basically, you go into an infinite span and say, I've got a new player. And that Quarkus application is what is when you're pounding on it, it's generating a REST connection, or REST command, into the Quarkus. That sends the power event, right? Remember, it goes into Kafka. So every tap is going into Kafka, or every shake is going into Kafka. And of course, it's going back to the Quarkus application to update that dashboard, right? And that's using SSE, server-side events. So all that was happening. You guys were tapping, and the real-time cars were moving, and the leaderboard was updating. That's what that application does. But we're not here to talk about the application. We're here to talk about how to roll out the application. So it basically starts with GitHub and a Git push. And of course, this is what we're sitting in the middle here. We have Kubernetes based on OpenShift, Tecton and Argo there in the middle. A webhook gets triggered. So the webhook, just so you know, is right over here. Not that one. Let's see here. Where to go, where to go, where to go. I always get the wrong window. So here, and if I go to Settings and Webhooks, see that webhook right there? That webhook is basically just an HTTP call to basically say, Tecton, something changed. That's all it is. Something changed. That's what got this Tecton rolling over here. See how the Tecton is moving now? And now what it's going to be waiting for is for Argo CD to realize there's a change. So Argo CD is just chilling over here. And by default, Argo CD only looks at the Git repo by every three minutes. That's the default. If you wanted to go faster than that, if you remember what I did earlier, is I clicked the button. So Argo, something did change. But if we just wait about three minutes, you'll see my little aloha over here change. Looks like I'm a little scrolled off screen here. So let's just let it wait. Let it wait. And we'll come back and look at it. So here, and here. Not that one, this one. So we're going to just wait for that to happen. But the webhook you just saw, that does the Git clone. It does the Maven package. It does the Builder. That's what Tecton is doing. It also pushes the image to Red Hat Quay I.O. So let's go look at that. So here is Quay I.O. Where'd it go? Not that one. Oh, I'm in the wrong thing. I keep forgetting that I'm in one window of slides. Steve, by the way, Steve Bongeur rolling out over there. It's rolling out. We spent three minutes. But let's go here. Yep, over here. So here's Quay I.O. See where it says three hours ago? Let's hit Refresh. And it's going to say three minutes ago. And remember, three minutes was the magic number. And then here, there's this little tag right there. See 555DC7. Over here, let's hit Refresh here. And there's the 555DC7. So it's a simple trick. But all it's doing is saying, OK, we got the image out there. The image has a unique identifier. Let's update that in this Git repo. You can see the images right here. And now, Argo is going to do its thing. So Argo has realized something has changed. And it's already figured that out. And you can kind of see, yeah, we're all Bongeur now. So the rolling update occurs because Argo sees the world is different from what it sees in the Git repo. So it's a very simple concept. But it's insanely powerful if you think about it. Everything is now in Git. And everything is now automated. And it does all kinds of other drift detection and checks and balances. Like I said, if I go in there and hack on it, if it sees the world has changed, I don't know if we can try that real quick. So kubectl edit deployment. Well, Git deployment. Let's see if we can abuse it a little bit and see what happens here. All right, so there's the Quinoa wind turbine, kubectl edit deployment. And that, it's more fun if we do some live hacking. See where it says replicas5? Let's make it replicas2. Hit save and close. All right, kubectl get pods. Let's see what happens here. And OK, so yeah, two of them got shut down. But you notice there's two more coming right back to life. So we almost kept them offline for a little while, but they come right back. So this, again, kind of is a Kubernetes principle. But in this case, it sees that the world does not match what was in Git. So it fixes it. So that's pretty awesome. I want to show you a couple of other things. And we're going to be out of time. Does it feel like our time together has just flown by? Maybe because I talked too fast. OK, all right, so we saw the push the image. Then there's the push the, you know, the SHA, the digest number back out to GitHub. Argosedia is watching. Argosedia just rolls it out, all right? Just rolls it out, pulls that image and rolls it out. So that's the flow that you saw in this case. That's not the only way to configure things, but it is definitely one way. And I should mention, too, the bit.ly link down here is the link to the slide deck, the live slide deck, like it was in the first presentation, which will get you access to all the slides. OK, all right, so there's a couple of deployment strategies that I want to show you, one more demo. And that is you can do a pull or a push. And this is important to understand, because people who love Argosedia like the pull model, and what you just saw was the pull model, which was, I'm going to watch to get repo, and I'm going to see that something changed. I'm going to pull the changes in to my cluster. That's kind of the default Argosedia way to work. But there's also a push model, which is I have more of a hub and spoke architecture where Argos sits on the hub, not on the spokes, and says, hey, spokes, something has changed. It could go either way, right? And so you can mix and match these principles, too. So you can do the pull model where it's a cluster-scoped Argosedia, and that is the default. Argosedia is scoped to the entire cluster. And therefore, all those Argo applications you create are basically going to look at GitHub repos. And let me actually show you that bit. I guess I didn't show you that. So back over here, kubectl get applications. Let's see, I think this is it. And no, no, no, no, no, no, no, no, no. It's over here. Let me, let me, I can't remember which it's in. Yeah, OK, so it's oh, should get ops. See, that's actually the Argosedia declaration. So if I say describe application, win turbine, and in openshift get ops, OK, right there. See right there? What's your image? And then, yeah, right here, what is your repo? What repo are you going to be watching? That's kind of it. Tell Argosedia what repo to watch, and it makes the world look like that repo, OK? So you can see Anna says, synced. I synced it. And so that's it. There's more things than that, but that's good enough for now. But let's show you the push idea, OK? So the other option is push. So that was the pull. And so push, like I said, it kind of goes the other way. I basically have a central hub Argosedia that then can push out changes to the remote clusters. So right here, I have four different clusters, actually. I have a cluster in Toronto, EchoCubeConfig. And that is my hub. And then I have spokes in Amsterdam, Bangliru. Didn't say it right today. New York. And so basically, I have clusters out there across the world. What's kind of funny is I'm normally in Europe showing this. And I like having US-based, European-based, and Asia-based, because that kind of covers most of the globe. And you will notice the latency differences, depending on where you fly to and run this particular demo. So even still, we're going to basically make a change in Toronto and get it to roll all the way back here. Just kind of wild to think about. So let's say I want to make a change across those clusters. Again, the same process as before, I will come into my code editor. And I'm going to basically say, OK, this is Amsterdam. They like the word aloe. Over here, you're more Namaste, right? And then in New York, because I think New Yorkers are funny, we're going to say, hey, y'all. I'm from the South. Can you tell? Hey, y'all, how y'all doing? So we're going to say, hey, y'all, for New Yorkers. That would upset them, by the way, just so you know. But are there any New Yorkers in the room? You could say yes. I see people here wearing the hats. So there must be something New York like here. So get status, there's the three changes. And again, Argo CD is looking for get changes. So all they did was change the deployment in this case. I could have changed the code. In this case, I changed the deployment. I'm going to say get commit. AM, let's call it the localized messages. And yep, and get push. OK. And I'm not going to wait the three minutes in this case. I'm going to go kick it, tell it to go. And that's over here. So there's my three application clusters. So let's just hit refresh, refresh them all. And drop back over here so we can see it happening. And you'll see it roll out. You'll see, so there's the pod in New York. There's the pod up in Amsterdam. There's the pod here. See it's starting to do the rollouts. And then if you watch it, there's hey, y'all. There's Namaste, Arzalo. And this was from my Toronto cluster. So from here, we went to Toronto. Then it sent events out to all those clusters around the globe. Tell it, look at your Git repo. Make your change. So it's insanely powerful what you can do. But hopefully, you get a feel for how this works when it comes to the nice way Kubernetes is declarative. Think of everything is just YAML in the NCD database. It's not exactly that. But you can think of it like that way. You can do the edit, the kubectl edit, which means pull it back out. Let me hack on it, put it back in. Not the production thing you want. But essentially, that's what Argo is doing. It's basically saying, what's in my Git repo? What's in memory? Let me make those things look the same. So there, a global rollout of an application change with an audit trail in a few seconds live here from this stage. I think I'm out of time, right? Yeah. OK. So I'll be around after the session for questions. But I know we have to get to our next speaker. I thank you all for your time. Because me being able to speak to you means I stay away for a little bit longer. All right, thank you so much. So we have a couple of minutes, one or a few minutes, till the current set up the next one.