 Good afternoon. Good evening, man. Welcome to the Galaxy. I'll be your captain here in this journey. Christian Hernandez, a technical marketing here at Red Hat. As you see, I have no co-captain today, right? So I guess the co-captain today is you out there watching this. I hope there's no too many cooks in the kitchen here with everyone being a co-captain here. But thank you for joining another episode here. So a few things here today, where we'll be talking about CICD, we'll be talking about GitOps and CICD. A lot of people actually reached out to me talking about CICD and GitOps and how they're related. We've done a few shows, I think in the past, talking about Tecton, last time we had the Argo workflow. The guys from Intuit, come on, talk about Argo workflows. A lot of people doing CI with workflows. I'd like to show today a demo or a high-level overview of how to do a GitOps-ish workflow with Tecton and Argo CD. Before we get to that, I'd like to steal a little bit from Andrew, talk about a little bit on what's top of mind. First and foremost, if you haven't already, please subscribe, share. We'd like to grow the show. I love hearing from everyone all around the world on Twitter, on LinkedIn, people constantly message me. I like that. So go ahead and feel free to reach out to me either on Twitter. Follow me on Twitter. I believe my name is either down here or down here. I always forget when you married there, ChristianH at 1.4. Twitter handle. Get handle as well. Also, remember, subscribe, share. Again, all that cool influencer stuff here. So today I knew I was going to be alone. I had my two cups of coffee, so I'm ready to dive in. I have a little weird tradition of every Thursday I drink two cups of coffee instead of one. People always ask me, why don't you just drink as much as you can? It's like, oh, I don't know. It's just weird. If you treat something like a special occasion, it's actually a little bit more special. So I have it here. So first and foremost, let me share my screen here. Talk a little bit about what's top of mind here. Let me make sure the screen comes up. I think I've already, there we go. So yeah, again, redhat.com slash live streaming. If you haven't already, this is our one stop of everything. You'll have the calendar there. So make sure, you know, never miss an episode or if you're trying to figure out what's going to be what, go ahead and visit that. So little top of mind, like I mentioned before, ArgoCon is coming. First ever, not real ArgoCon. We try to make it a live event, but actually we just decided to make it virtual. So still time to register, still time to attend this event. There's gonna be a lot of cool things going on here. So let me click on the schedule here. It's multitrack. So this is really cool. So like if you're interested in like workflows, Argo workflows, Argo events or Argo CD and Argo rollouts, there's a couple of tracks. The region I'm mentioning this here selfishly is I do have a talk here talking about the stateful applications, right? Argo CD stateful applications. I did do a stream earlier here about stateful applications. This is kind of a continuation of that. So if you see that episode, and if you have the time next Wednesday, 125pm Pacific time, I'll be giving a talk at ArgoCon. So if you can attend that, it'd be great. I'll be going a little bit further in that conversation. So other cool things going on ArgoCon. I know Dan Garfield is going to do the keynote here at CodeFresh. Really cool guy. I work with him a lot in the open get-ups working group. And they have some Argo CD production best practices, another one from Alexander. He's been on the show as well. Talking about Argo CD, he's going to be talking about best practices. So a lot of cool stuff. If you're into Argo CD using the Argo projects for certain things, it's going to be a lot of great stuff there. And I think that's it. I think this next top of mind thing kind of just goes into what was, oh, before I forget, actually, I'm running a survey. It's the next top of mind thing before I get into the actual today's topic here. So I'm running a survey here. I'm going to throw this in the chat pretty soon here is we've been doing get-ups guide to the galaxy for a little over a year, almost two years, almost two years. So this will actually, this December will be the second winter break shutdown that we have here at Red Hat that we're going to take. So I'd like to think of it as two years. And we'd like to see where you guys think about the show, where we want to take it. So just make sure you get to get the survey and take that survey. Give me your thoughts, be as mean as you want. Maybe not as mean as you want, but give the feedback to see what you guys want to see. What more we want to explore in this get-ups journey. So saying that, my last top of mind thing here is that I was actually going to go to DevConf, speaking of events, they just made DevConf virtual. That's one thing. And two is Stephanie the producer is like, please don't be mean in the chat. So yes. So please, yeah, please don't be too mean. But we want to hear the truth. And actually, I was actually going to give a talk about actually a workshop about CICD and get-ups in Argo. So one that turned into a virtual event. So workshops are a little harder virtual event. So I'm actually only going to be doing a talk for DevConf as well. I'll give you that information as soon as I I'll probably tweet out that information as soon as I have more on that. So that being said, so let's talk a little bit about OpenShift, CICD, and Tecton, get-ups. How does all that look, right? And so I believe you guys seen this presentation before. It's been shared out. This is a public presentation. So, you know, I'll end up sharing it too. I'll probably tweet this out later on. We shared this presentation out before. There's nothing too hiding here. I'm not going to go over through this presentation, right? Bit by bit. But I do want to call out a few things, right? And so when we talk about CICD, right, and traditional event-based CICD, you know, a lot of those same concepts still exist in a Kubernetes world, the cloud-native world, except now you can go even further, right, extend it even beyond of what a traditional CICD is, CICD looks like. Just from the sole purpose or the sole fact that Kubernetes is a declarative infrastructure, right? So if you guys have been watching the show, we're all about declarative, right? We're all about being, you know, if you're watching the show, I hope you're all into the get-offs methodology of being declarative. So we just kind of take that and essentially run with it, right? So like making everything declarative. And so when here at Red Hat, when we were, you know, we have OpenShift, which is the enterprise Kubernetes offering. We're trying to reevaluate of what does CICD look like in an OpenShift world, right? And so, you know, a lot of people are used to things like a platform like Jenkins or CloudBees or, you know, something like that, which, again, there's nothing wrong with that, but a lot of people are in the traditional sense of having a platform to do their CICD, whereas now with Kubernetes and OpenShift, that can be part of the platform itself, right? So, you know, the platform that is delivering the application can also be the platform that does that build and does that check for you. And so, you know, if, so now that we have a platform like OpenShift that's declarative, then you can use some of these tools to have a declarative continuous delivery, continuous integration aspect of it, right? So I'm going to jump around this presentation, right? So don't let me make a little bigger here. I might not go in presentation mode only because I'm going to be jumping around. So let me make this just a little tiny bigger. How do you hide the, can you do this? Oh, there we go. Learning things new, alive. So we have a continuous delivery. Let me jump around here until I get to the tecton aspect of it, right? So the tecton aspect of it is the idea is having a kind of like a serverless aspect to a CI, right? And so you have the concept of having builds happening on demand only when you need them, right? Versus a traditional kind of like CI process where there's like a platform that does the builds for you. Tecton takes the serverless aspect of it to where it only comes up when you need it. So you want to do a build. That's a task, right? Each task has an individual step, right? Collection of tasks. It's called the pipeline. We've done a show with Tecton before, so I'm kind of going to gloss over this here, but kind of the idea is that you have a step that does a thing, right? And a collection of steps is called a task. So like step one is do this, step two is do that, that sort of thing. And a collection of tasks is called a pipeline. And I'll be going over kind of like what my demo, you know, how all that looks, right? Because the idea is that these are reusable, right? These are kind of like, you can specify a parameter, right? For example, like if you need to do a Maven build on something, you just, you know, if the Maven builds always the same, then maybe you'd make it a parameter of you just pass it the Git repo, for example. And so we take that concept, right? Okay. So like we have like kind of a cloud native serverless CI CD, right? Because Tecton does technically do CI and CD, right? But let's just kind of focus on the CI process of it, because we're doing the CD aspect of it with Argo CD, right? And so if you've seen the show, Argo CD, don't have to get too much into it, is the fact that Argo CD is the GitOps controller, right? For OpenShift. That's included in OpenShift that makes, not only does CD, right? Continuous delivery, continuous deployment, but make make sure that, that drift detection is always happening. So I'm not going to go deep into that, guys should already know, right? If you don't watch past episodes, right? Stephanie, Stephanie the producer, I'm going to call her. Stephanie the producer asked me, hey, there's any sharing links? And I actually forgot to show this link. So sorry, Stephanie. All right, put that in the chat, red.ht slash GitOps, hash past episodes, subscribe and like all that good stuff. So let's go, let's focus in on how does CI, CD look like in the GitOps world. So let's look at this guy right here for a little bit. So best practice is that you're always, you're always looking at, you always have at least two source repositories, right? You get repositories, right? You have the source repository of the actual application. That shouldn't be any different. That actually fits nicely in the GitOps model, but that doesn't really change in a GitOps model, actually, right? Because we say that you have, you have to separate your source, Git repository from your configuration repositories, what we call it. The, that separation, I've always thought that you would have, it's better to have it in one repo, right? The code and its deployment manifests. I quickly found out that that is really hard to manage. So I've always said, split it out. I've talked to hundreds of customers who always, because there's a contention where there's some customers that just say absolutely no, I want it all in one repo. And I say, okay, that's fine. I used to think like you too. So just, just trust me on that. I actually think you have multiple ones, right? You'll have a config repository specific to the cluster and a config repository specific to the deployment of the application. So I think you should at least have three, but we're going to keep it a little simpler than that. So you're going to have at least two, right? You have a config, Git repository, source code repository, right? And they're going to work in tandem. And so the idea is that since you have two, they each kind of have an independent life cycle, source code repository where that life cycle is going to stay the same. Really, right? You're going to, that process is going to stay the same whether you're using GitOps or not, I think for the most part, it'll stay the same. The config Git repository, I actually have an opinionated way of configuring those, whether it's the config for the cluster or the config for the deployment of the application. And it's something called trunk-based development, right? And so let's talk a little bit about trunk-based development. This is also another point of contention. One of my ex-co-workers, right? We still keep in touch, says that he does a lot in his current job with customers. He does a lot with ArgoCity and Tecton. So I wonder what he thinks about that if you're there, Nick, I know you'll pipe up and disagree with me because we're both opinionated guys. But just in short, trunk-based development is something that I use with the config repository. So this guy right here, not the source code, that's going to have a different life cycle than the config repository. So for those that don't know, let me drop this in the chat again. Sorry, Stephanie, the producer. You need to be, yeah. Yeah, so Benjamin says ex-co-workers still keep in touch. Kind of sounds like a friend. Yeah, so I guess, yeah, I have a friend of mine, ex-co-worker and still friend. So you're absolutely right. And so back to this trunk-based development. So back to trunk-based development. So from a high level, the trunk-based development means that you have a trunk that is the branch that you're deploying from, right? So I like to distill that down that basically you're deploying from main, right? Here it says master, get now switch to main, main, right? Doesn't have to be main, doesn't have to be master, but I'm just going to use that as an example. It could be production, right? That could be your trunk, right? Whatever the trunk is. And you have different release branches, right? So you have different like feature branches. So feature branches are basically things that are going to go back into trunk and things that are going to be deleted because release feature branches are short-lived essentially is what. So with the trunk-based development here, trunk-based development at scale is best with short-lived feature branches. So that's kind of like the idea, right? Like you have the trunk, you have main production staging, whatever, right? Whatever it is, I'm going to say main again, right? You do, you don't commit to the release branches, right? You do your work in the release branches and then it gets committed back down to the trunk. And in the trunk that gets deployed into production. So this is like one of the things that I find a lot of people are doing with going back to the presentation with the config git repository, right? With the source code repository that has its own life cycle that has that cycle is independent and different than the config repository. That'll have like feature branches, long-lived feature branches that'll have tags, that'll have, you know, all, you know, release bundles. That'll have, that'll have its own life cycle. The config git repository usually follows what I call a, what they call a trunk-based development. So not going to go through all of this here. This is a great read, especially if you're looking into your git workflows, whether you're a dev, on the dev side or the op side, or, you know, SRE, this is a great read about how, well, what the idea is behind trunk-based development. So if you haven't seen that, that's what this config repository is, right? So now let's look at the, this workflow. So I've been talking for a while. Let me take a quick trink. So what ends up happening is that someone makes a, a commit, right, to something, right? So it's to code that's going to trigger a CI process, right? So the CI process does something with it, right? It does everything that you would think with CI process, but it builds the application, does a test, you know, once the test passes, it pushes that image to image repository. In that same CI process, there's going to be a change to a config git repository, right? So actually in the CI process, the actual CI process is committing to your config git repository, right? Sounds a little scary, but we'll go through in detail in the demo. Once that is done, the GitOps controller, in our case, it'll be Argo CD. We'll see that change and it'll act on it, right? So it'll say, oh, hey, there's a new image update that was made to the deployment configuration. Let me push that into whatever environment that you pushed that into. CI process can do other things like create a pull request instead of committing directly. That's, you know, part of the little demo that I'm going to have here, that's going to happen, right? So really here in a GitOps application delivery model, the magic is really the CI process interacts with your Git repo, with a configuration deployment Git repo, once a build a success. So this can happen in any step of the CI process, but usually happens towards the end. And it's usually either a PR or a great direct commit to a specific branch, right? Or a feature branch. And so I think I'll go into the demo and then I'll show you how this kind of looks like from another view here. So here, let me... So here, what I have here is I'm going to drop it in the chat. This link I did give to Stephanie, the producer. So I did prepare at least for this here. I'm actually... So this is the CI CD demo that I have. You guys can take a look. There's actually a Helm chart for it. So if you're running OpenShift 4.7 or newer, this will work for you. And it needs to be a freshly installed OpenShift cluster. But this is kind of like what I was going to go through in DevConf, but it looks like that workshop's not going to happen. So that's why I decided to do this stream. So here, you can look at how I'm doing some of this demo here. And again, it's a Helm chart, so you can just add it and run with it here. So let me log in. And I'm actually going to log in as a developer. So let's carry here. Developer. And good. Come on, skip tour. All right, demo guides are with us. Let's log in here to Argo CD. Log in as developer as well. All right, there we go. Cool. So the way this is set up... So I actually logged in as a developer. I'm not a cluster admin here. I actually deployed my own... So here, I'm in welcome get ops. Let's go to... I'm sorry to hear. I actually deployed my own namespace scoped Argo CD instance. So that's part of the Argo CD. So if you go here, let me clear this. Get Argo CD. All right. So this is... OpenShift GetOps is the Argo CD that manages the cluster. And this is a deployment of my namespace scoped Argo CD. It's what we call it. Or... I guess, yeah, namespace scoped Argo CD. We had another name. I forgot. If you guys remember, we had another name for it. You drop in there. I think it's called Project Based. Not sure. Anyway, this is... The OpenShift GetOps, that kind of just takes care of the cluster as a whole, but I'm actually going to focus on... As if I'm a developer, I deployed my own version of Argo CD using the GetOps operator to a specific namespace. So this namespace, I'm going to call it WelcomeArgo CD. So that's what this is here. And that's what this is here. So as you can see that I have different environments set up, technically too. I have Dev and Prod, right? And I have a pipeline that's also being managed by Argo CD. So I have Dev and production here. Let me go to Pipelines. And I have a pipeline. So this pipeline... Let me go here. It does a few things, right? Let me get this a little bigger. This actually takes a while to run, so I won't talk about each individual step until I actually fire it off. But I have Pipeline here that basically builds and deploys the development, and then I'm going to promote it to production once things are going smoothly, right? I have this app here, DumbApp, right now it's shouting green, right? This is shouting green as well. And so this is production. This is Dev. And I have a git tinstance. Let me log into this. Oops. Here we go. All right. Yeah. So I hear, as you see, I have two repositories. I have... Yeah. So I have two repositories here. I have the actual application, right? The Welcome app. And this is just that application running, right? So this is like a static PHP page here. And I also have the deployment, right? So now, as you can see here, I have two repositories. One for the application and one for deployment here. And here, deploy an app. And then the Pipeline, right? So the Pipeline actually lives in the deployment, I believe. Yeah, Tecton, right? So I actually... So I'm kind of using everything declaratively, right? And so I'm using Argo CD to deploy to... I use Argo CD to point to the deployment repo that then creates the Dev, the Pipeline, the production. And that's all self-contained here. And so usually the first step here is let's make a... Let's... Do we have time? So let's make this a little longer here. Let's... Now this is deployment, right? We want to make a code change. So let's go to the application. And then let's make a code change here. So let's... Can we create a branch? How do we create a branch here? There's one branch. I'm logged in. Do I have to do it through the CLI? I thought you can do it here. If not, no big deal. New pull request? No. New pull request? No, because you need a branch for that, right? I thought you could do it in GitT. Maybe you can't. Oh, okay. I can do this. So let's make the edit and maybe that'll create a new branch. So here we have green, right? Say we have green and let's... Instead of blue-green, we're going green-blue. Or let's go yellow, right? Let's do another... Why not? And here... Yeah, create a new branch. There we go. Let's go here. Let's call this... Get off the Galaxy branch. Right? For profile change. So here I create a pull request. Right? Changing to yellow. Okay, pull request. Cool. All right. So now we have the application, right? I was a developer. I made a pull request. They called my hat, right? I'm a different developer now, right? I'm the architect. I'm like, all right, this looks good. Files changed. All right, yellow. Yeah, that's what we wanted. Looks good to me. Oops. And then let's go to merge pull request. Right? Reviewed. I can do... It looks good to me. So this is merged, right? And so what this does is this... If I go down the pipeline, is this kicks off another build, right? A lot of people ask me, how does build get kicked off when you commit to that? Well, as you probably already guessed, there is a... Where's my repo? Let me go back. There we go. There's a web hook, right? So let's go to web hook. I have a web hook. So a tecton has the ability... They call it event listener, right? To set up an event listener. And that just basically hits the web hook to fire off what we call... Let's go back here. A components token. Let's go to trigger template, right? Fires off a trigger template, right? So this trigger template says, hey, when an event listener hits me, I want you to pass these parameters to this pipeline. Let me go back to token here. And that pipeline is defined here, right? And so basically, it just takes that trigger template, takes that template, it feeds it into the pipeline with those parameters. And you can do really some pretty cool things with these parameters. You can do... You can extrapolate things from the payload, right? So like if you want certain information from the payload, you can take those as well and pass that to your pipeline as well. So here... So first thing it does, it just clones the repo locally, right? First step is always the cloning. So once it clones the repo locally, it'll set the image tag. So this is basically... It'll set a variable, right? So it'll say, okay, I'm going to set this commit as a tag, right? Because you want to be able to differentiate the tags of what's in dev versus the next environment, right? Between environments. I don't like floating tags, things like dev, things like colon dev or colon prod because that's kind of an anti-pattern, forget, right? Because in get, you want the source of truth, right? Because floating tags can change whereas things like either the SHA or like a specific UID don't. So you have that. Once it cloned and sets that variable, it'll actually do a build, right? So here's an aspect. So this is one task that has many steps, right? It has the step of building. So I'll actually build a container. It'll actually push the container to our repository here. And then my last step is basically take some of those, like the SHA, right? And load it up into a variable here. So here, I'm tagging latest, right? Even though I'm not using latest in my pipeline, I figure I'll tag to latest in case someone wants to, you know, play around with this image and they just want the latest doing some testing, right? Once I do that, I'm going to clone the deployment repo, right? So here, I just do, I was just, here before I was just working with the software application here. Now I'm actually cloning the deployment repository. And what I'm doing here is I want to have it here so that way I can interact with that repo, right? So first, I did a build on the application repo, and now I'm cloning the deployment repo. I'm going to work specifically with this guy here. I'm going to patch dev. Essentially, I'm running a customized edit. What this does is essentially is going to update the image to the new version here. And then I'm going to commit it to dev. So here, since I'm working with dev, and I'm probably doing a lot of iterative changes, I don't really care about doing a PR here. I just commit it to dev, just commit it to that, because I want to see my change right away. And you can see that in here if you go to app, if you go to overlays, if you go to dev here, right? If I look at the customization file, yeah, there we go. So the customization file sets the new tag. So it says, hey, I want this image, I wanted to use this new tag, which I should say in here. Yeah, one DD, one DD, right? So it'll, it updates the tag. And so when it updates the tag, it actually deployed it, right? So like, go refresh. I think, yeah, it already did it while we were talking. I wonder if you can see the, yeah, so here, this is the last sync was done, one DD, right? So it's there. So that actually already deployed. So if I go here, this should say yellow, let's cross our fingers. It says yellow, sweet. But in production, it's not yellow, right? Why is that? And so it's because in my workflow, I'm actually going to patch prod, right? Do the same thing. Instead of doing it in dev, I'm going to do it in the prod folder. You know, one DD, there it is. But I'm actually going to create a branch, right? This is my feature branch. This is the branch that I want. I don't want it directly in production just yet. Right? I want to, I want it in dev. I want the changes in place. But for prod, I want to make a PR because I need other people to look at it, right? So this is the process here is the process here is making a PR. So that way you kind of have that stop gaps or feature or gating, right? This is kind of how you would do a gating. So PR to prod is here. Oh, it looks like we're getting rated. Nice. Welcome, everyone. So here I make a PR to prod. And so we got a PR to prod. And here we can go to the repo. And you can see the PR is already there. So we have a PR to oops, let's go back here. So this here, it'll show you that in my production folder in the customization, that's the file I want to change, right? This is release 1DD. We want that here. And then to go back to the conversation here. So here, I would go into switching my hat. I'm an SRE. I'm whoever, a release manager. All right. I'm looking at this. This looks good. Now here, this is the part where it gets where we can kind of think about this a little bit. The here, we may, we may or may not want to merge this, right? So part of the pipeline, let's go back to the details and see where this here, you know, part of PR to prod can then trigger yet another pipeline that tests this right in production. It doesn't maybe, you know, this is kind of like a simple use case, right? So before I click merge, I want to, you know, kind of talk about how like other things you can do, right? So here, when it does a PR to prod, it can trigger yet another pipeline, right? Because it's just tecton, right? This is just, you know, it's all, it's all web hooks, right? So here, you can just web hook into it yet another pipeline that does yet even more testing, right? So like, hey, a pass dev, that's cool. You made a PR to prod, but we don't want to just merge it, right? Without testing. So this can then trigger yet another pipeline. I just want to mention that because, you know, every time I kind of just, you know, talk about this from a high level view, people go, well, wait, you know, what about other pipelines? It's like, well, yeah, you can do other pipelines here as well. You can chain these together. You can have either one big pipeline run or many little ones, right? You can have slack ops where it tells you it's something passed or something failed. All that good stuff. So but here, let's just say, assuming that it triggered another pipeline, it did all the testing and assuming all of that passed, assuming that, you know, someone did peer review on this stuff here. Maybe I want to merge pro requests, right? And it should do looks good to me. All right, let's merge pro requests right here. What I like doing is I delete this branch, right? You may or not want to delete it. I'm following trunk based, right? As soon as I merge that feature branch, I'm delete it shortly feature branch. I do that. I'll leave that up to you, right? I'll let you do that. You know, that I'll let I'll have you your DevOps team members here argue about whether or not to keep that. But for me, since we're following trunk based, I'll just delete that. We don't need to hang around. And so once you do that, I'm just going to refresh this, right? So usually the reconcile loop takes three minutes for Argo CD, right? So Argo CD has three minutes, that's adjustable, right? You can adjust that. So instead of sitting here for three minutes, I'll just hit the refresh. So it checks. And as you saw, it deployed that application. So here this is product. Sorry, this is dev. And this is my, my full production here. Now it's yellow, right? So now we are now they match, right? And so this is kind of the way to quickly do iterative application development with getouts, right? So here I actually so if you notice here, I didn't actually interact with Argo CD, all that often other than hitting refresh. And I didn't really interact with OpenShift, all that much. Everything was driven through get, right? So I'm using get t here, for example, but here I'm using get. Although this process, if you think about it was done via get, and I could even distill it even easier than that, I could have actually technically use something like VS code and just start a committee through a VS code. So in all the automation is happens that happens in the background there, see? So this is kind of how you would use here, you can see the history, right? Succeed, succeed. I had some issues here. I don't know if you guys had issues with the other day. We had an outage from our, I think it was one of our registries, registry.redhat.io, right? I was like, why is this taking so long? Why can I pull these images? I'm trying to prepare for a stream. And then I'm like, oh, yeah, I'm getting 404s for whatever. Anyways, they fixed that. So that's just another thing to look out for, right, is where you're keeping your images, right? A lot of people like to use something like Quay, or if you're an England key, right? Does it call it there? In Australia, I think in Canada as well. I don't know, I think there's some Canadians watching. Do you guys call it Quay or Quay? Drop that in the chat, if you guys know. But some of them like to have that in-house, right? So that way you don't run into the problem that I did. And I think it's a good idea is to have your in-house registry server, right? Even if it's just mirroring, right? So you can even have it as a mirror. I think that's another cool idea. Actually, that's another cool show idea is to have mirroring and mirroring Git repos, right? So the idea, someone brought this up, the idea of having a Git repo mirror your actual Git repo. So that way, when you have a network cut out or have the source of truth closer to where your clusters are, right? So this person I was talking to is a company, can't say the name, but they manage hundreds of clusters all around North America and they decided to use Git mirrors, right? Because they don't want an outage in their Git system. I think they're using a GitHub or Git lab internally. They don't want that going down to make the other systems going down or a network add outage, right? To mess anything up. So they actually had set up Git mirrors. So maybe I'll do an episode of that. That'd be kind of cool to explore. So anyways, back to the topic at hand. So here, this is kind of what I had in mind. Some other things to consider. Now I'll actually bring up the really, really cool slide that I wanted to show in the beginning, but I thought I think it's better to show this from a high level of you. So Nick, if you're watching, this is probably what you wanted to see. The other stuff was probably too high level for you. But here, this is how to use some of these, some of this offering, some of the OpenShift offering, right? So here, you can see how all the OpenShift offerings, the Red Hat offerings, all the technologies that we have here can be used together, right? And so, still same idea with the application Git repository config Git repository, you'll have one or many application Git repositories and one or many config repositories. And oh, hey, Tiger's here. Hey, Tiger. Tiger the intern. I guess you're not the intern here. So we got here the config here. You have one or more many config repositories here. And so the CI, our vision is we see it as tecton, right? And that's kind of like your CI process. Outside of GitOps, tecton can do CI CD, but in the GitOps world, right? In our journey here, we focus on the CI aspect of it here. You could also use Argo workflows, right? If you don't want to use tecton. And then doing Argo CD for the reconciliation of it as well, right? And, you know, we kind of went through that. But on top of that, you want to do something with security, right? So that's when advanced cluster security stack rocks comes into play, right? And that's how this interacts with your, not only your image registry, right? For your CI process, right? Because you can have scanning happen in your CI process. You can have scanning happen in an image registry as well. And you can make sure that those clusters that you're running are in compliance, right? So this is kind of where ACS fits in here. We had Michael Foster from ACS, really, really cool guy came on the show, talk about ACS. This is kind of where the ACS aspect fits into it, right? So the CI process interacts with, or I guess ACS interacts with your CI process in vice versa. And then you have Argo CD here doing the reconciliation for your applications, right? So you want to be able to deploy, like we saw, right? Have Argo CD making sure everything's in constant sync, making sure that there's no drift detection as well on top of doing the CD process of it as well. And then you have the advanced cluster management. The advanced cluster management here, or ACM, right? Right at ACM does life cycle management of your clusters as well, right? So whereas at Red Hat, we have the view of Argo CD is meant for a get up workflows, which kind of overlaps with ACM because ACM does have a get ups component. But ACM, I always tell people, and it's always, you know, whether it's people here at Red Hat, whether you're in the field at Red Hat, or really just customers here, you know, I always say calling ACM a get ups tool is really short selling ACM, right? So you're really cutting ACM short, right? You're like, I don't see the difference. I'm like, you don't see the difference between ACM and Argo CD because it's much more than just that, right? Like you're talking about cluster life cycle management. And whereas Argo CD is just a reconciliation, get ups tool, right? You can make it do other things, but really ACM shines in you manage the life cycle of your clusters. And you can use it in conjunction with ACS to enforce policies. It's really, really cool. So then here you kind of have a bigger picture of how that looks like. And so you can have ACM interact with your CI CD process to spin up even additional clusters. This is kind of think about that for a second. When you have like a want to test a feature branch, you can have ACM spin up a cluster, right? Interact with your CI process to spin up a cluster and do the test that way, right? Deploy the application on a test cluster before actually promoting it. You can do that with ACM. Can't do that with Argo, but you can definitely do that with ACM. And so this is kind of how that bigger picture, how everything fits together in that bigger picture. So everything here in the middle is batteries included, right? So for those people always ask me like, oh, how much are you charging for Argo? How much are you charging for Tecton? I was like, no, that's included. Use it supported. Batteries included in OpenShift. If you need anything beyond that, right? You'll definitely need something for ACS and ACM. That does have a skew, but you can always test, for example, open cluster management. That's the upstream of ACM. And StackRox is the upstream for ACS. So this is kind of the idea behind that, right? So that's kind of all I wanted to share. I don't know if there's any questions I'm looking. Looks like the Raiders may or may not have left. Thank you for joining anyways. Tiger is there. So Tiger the intern, now co-worker. So there you go. So we like hiring our interns here. One thing I did want to try is that, so notice how, so it, you may or may not have noticed it, but if you did notice that how I had to click refresh for this to do the reconciliation, right? So basically it's like, hey, you know, I click refresh, like you can actually have Argo do that for you. So let's kind of look into that for the, let me say we can do some exploring the last few minutes here. Web hook. There we go. There we go. Get web hook configuration. So here we have, so here it says you can do web hook configuration for the application here. So let's go. So the idea being that in the pipeline, let's go back to the pipeline. Once the patch or commit, where's the commit to, yeah, commit to dev. The commit to dev step, that can also hit a web hook, right? So I was thinking maybe we can hit that web hook to do the on demand reconciliation instead of waiting three minutes. We may run out of time, but let's kind of just start that journey. I haven't done this yet. I'm doing it live. So we'll see if I fail miserably here. So Argo CD slash API web hook. So how does that even look like? So let's try to, can we hit that payload? So here, there we go. Hopefully that wasn't too loud. So let's curl dash K. And here it says to do API web hook. Unknown web hook event. That's a good sign. Let's go to see what it does this year. Bad request, mark bundle, not supporting multiverse. It's by expecting a payload, but that's good. It looks like it's there. So it looks like the web hook is there. It's listening for a web hook. It's not, but we're not sending it the right information. So that's good. So at least we know that the web hook is there. It's just we're not sending it the right information. So probably it's expecting a trigger, but I wonder what the payload looks like. I would like to see if I could just curl it once to see if we can make it go. See here. Yeah, it doesn't tell you what the payload looks like. So JSON forum URL encoded. So if anyone knows, so if any of the engineers are on, sometimes the engineers are. So it's application JSON. The value is not supported by libraries then. Okay, so I have to use application JSON. So let's do some Google foo, see if we can find it here. Argo CD, web hook payload, notifications, that's for events. Maybe this will help. Ah, here we go. Web hook event source. Oh, this is Argo events, not Argo CD. Yeah, Bing. Does Bing have it? Let's go Bing. Not right. This is what happens when you do it live. Argo CD, web hook payload. Interesting. Let's look at the source code. We probably won't get this working because we have such a short time, but it's interesting kind of look at this here. Web payload. So interface. This is looking for web hook URLs. Revision, okay, so we need to provide it to revision. So I guess like main in our case. Parts revision, touch head, okay. This is for GitHub. Oh, what about Git T? Is there like a generic one? Yeah. Yeah. So using Google to find Bing. I actually didn't know the URL for Bing. So it's, I should have thought it, I should have guessed it was Bing.com here. Gogg's client. Oh, maybe a Gogg's client would be, is probably what we want because Git T is based on Gogg's. Let me see here. And this is just, I think it's just the, yeah, this is just a documentation. Yeah, I may have to, we may have to, it'd be interesting because I think this would be a good update to that CI CD demo for it to actually hit the web hook. So this might be homework for me because I don't think we're going to figure this out here because here it actually, so if we go back to the documentation, where's the documentation? I always lose the documentation. There it is. This is talking about actually on a commit, but I actually want to use the reason I'm using curl. So this kind of is my thought process. Go back a little bit. The reason I'm using curl is because I actually don't want to put it in, at least not initially, in Git. What I want to do is I want to put it in tecton because in tecton commit to dev, I want another step or another task. I'm not too sure. Another step that hits that web hook. And then, and maybe for the second one, the second reconciliation, yeah, when someone commits to main or whatever branch in my production instance, then yeah, then maybe I want that. But I kind of want to see what the payload that looks like. So that might be homework on my end. We're running out of time here. Let's see here. So if there's any questions, I don't see any questions here. So I just see just me and Tiger interacting. So again, Tiger the intern. I wonder when that intern is going to drop off to your title, Tiger. I'm used to calling you the Tiger the intern because you're actually not an intern anymore. You're in the Tiger the engineer. How about that? How about this? Tiger the engineer. Well, I'm going to transition you to Tiger the engineer. Yeah, being captain here and get off the galaxy, I can make those promotions here. So Tiger, you're no longer the intern. You're now the Tiger the engineer. So cool, cool. All right. So doesn't look like any questions coming down. We're coming up short on time. Maybe next time I show this whenever I'm on the road, probably the next time I show this on the road, I'll have those web hooks showed up. I'll post this on social media. So speaking of social media, make sure to follow me, Christian H814 on Twitter. I'm also on GitHub, the same handle. So be sure to follow me there. I'm always posting updates to shows. Maybe I just, I've been wanting to start a blog. The thing is, I'm a better talker. I mean, you may have a different opinion about a better talker than I am a writer. I always, I've been wanting to start a blog kind of how Andrew does to kind of, but I always definitely do update on Twitter. So make sure to follow that. Make sure to like and subscribe and share with others. Fill out that survey if you haven't already. I appreciate everyone who has. We've gotten some good feedback so far. Leave that open to the end of the year. Update in terms of shows. Let's see if we can find it here on the calendar. I don't think it goes that forward. Oh, it does. So Thursday, December 16th, get off Skype to the galaxy. That'll be the last show of the year. We are going, we're taking a, we have a company shut down here at Red Hat. It's something, you know, we do a recharge day every few days, but then towards the end of the year, we have like a week where we basically do a shutdown, Skeleton crew sort of thing here at Red Hat. Even after IBM, we're so continuing that for that tradition. So this will be the last show of 2021. Have something special lined up for you, right? So for those who are watching here, I'm going to be doing the top 10 best things and get ups. Be going through kind of the kind of some of the cool things that we've done through the year. I figure kind of close out the show doing something really, really cool about just kind of talking about the year, right? And then hopefully talking about the year ahead. So with that, thank you. Thank you, everyone. Again, remember, reach out to Twitter. If you ever have a question or anything like that, I'm also on the Kubernetes Slack. Same username, Christian H814. Find me using that handle everywhere. And yeah, I think that's it. And so like I close out every show, if it doesn't get, it's just a rumor. Thank you, everyone. Bye. Enjoy your day.