 All right. He made it until Friday afternoon. I'm impressed. Woo! All right, so we're going to do a hands-on tutorial this afternoon on our go rollouts. So we're going to do a progressive delivery of our application. And yeah, you'll see if it works, first of all, because we've never done a hands-on lab for so many people. But we're reasonably confident, so we'll see. Anyways, so I'm Kevin Dubois. I'm a developer advocate at Red Hat. And with me is Natale. He's my manager. So make sure, yeah, any complaints, don't tell him. No. And then we have Christian, who's from Akuati. Then we have Harriet, also from Red Hat. So we have three people from Red Hat here. And then we also have Costis from CodeFresh. And, well, everybody here works a little bit on Argo CD, some Argo project, some little more. Christian and Costis are maintainers. And then some of them a little less, like me. And so that's why I'm doing a presentation, because I know the least about it. All right, so this is how I started with progressive delivery. So I don't know if you recognize this, so FileZilla. But anyway, with the FTP, like copy, paste, or in the CLI, maybe if you were a little more advanced already. Yeah, that wasn't really a very sustainable way. And we had many times that in the middle of the night, we'd have to get up and support any kind of issues, because it was very unpredictable. And then, of course, we evolved. So CI CD, basically, for most of us, meant Jenkins, right? So we built some advanced pipelines, and then maybe some automated delivery, too. But yeah, it's still a little bit finicky with Jenkins. It's not necessarily built for the continuous delivery. It's more a CI tool. And we evolved, right? We evolved from this more monolithic kind of applications, where we have one thing that needs to go to production. And it was still OK to do a more hands-on approach to delivering our software. But then once we went into more distributed architectures, that means more and more delivery pipelines, right? You see those little tubes, those present kind of pipelines. And we needed better ways, of course. So you can see our developer flow has kind of evolved over the years, right? And so now we have this interloop, where we're doing our local development, and we're doing our building, and our testing, and debugging, and maybe some sort of packaging on our local machine just to test it out. But then at some point, we're reasonably happy with our code, and we're going to push it to a repository. Somebody might do a peer review after we do a pull request or a merge request, depending on what tool you're using. And then we end up in this kind of outer loop, right? In this outer loop, we're doing maybe somebody might do a code review. We're doing security scans and automation of the building of our applications, and maybe some compliance checks and everything. And of course, you see in the build phase, we do some sort of continuous integration. And then in the deploy phase, I'm assuming since we're here for Argo roll out, some of you might be already familiar with Argo CD. But if not, that's OK. I'll explain it a little bit, too. But that's a nice way to deploy your applications in a more manageable way, right? And yeah, so Argo CD is one solution to do that. And then of course, we go to production after the outer loop. And you know how it goes, right? You implement a new feature, you go to production, and then yeah, it doesn't always go so well. And especially if you have like a kind of a big bang release, that means that all your users are affected and your management is probably not very happy with you. So we need maybe a slightly more gradual approach, where maybe we can test it out a little bit more in production and see and feel how it goes. So before we go into the progressive delivery, let's maybe first revisit GitOps for those who are not familiar with it or maybe not so familiar with it. So the idea with GitOps is basically that your Git is your single source of truth, not just for your application code, but also for how to configure your deployments and everything around that. So you have this is my desired state of my environment with how it should be deployed, how many replicas, and blah, blah, blah, and that should all go in a place where we can go see what should it be, who has made the changes, when were they changed, and we can also then roll back pretty easily, right? Because we can just use Git, so it gives us a lot more visibility. We can treat everything as code and then use the familiar Git workflows that we're using already for our code. The difference kind of between our traditional CI CD, which doesn't need to go away, right? We can still use CI CD for building our applications, for testing, and all those very important steps. But we can use GitOps to make sure that our desired state actually matches with the state of our environment in production or in tests or in stage. And it's basically this continuous feedback loop of checking to see the desired state that we have in Git, does that match with what we have running in our actual environments? And if not, let's make sure it gets mitigated either automatically or by notifying us and then we can maybe take some manual steps, depending on maybe the maturity of your organization. And so the tools that can do that are, of course, ArgoCity is one, FluxCity is another one. And so that's kind of the idea with GitOps. So then what is progressive delivery? Because, well, GitOps is cool, yeah, you'd say this is my desired state, and then by default what will happen is that your desired state will go to production as kind of a one-shot, big bang release, right? And so the idea with progressive delivery is that we do it in steps. So you can see here my little image that I found somewhere that goes step by step, right? So what is progressive delivery? The idea is that it's not a big bang release, so we have a gradual approach to releasing our software, and it also kind of means that deploy doesn't mean release, so we can deploy to production and not necessarily have it released yet, right? So we can have control over how we actually do that release. And then we rely on metrics to see if everything is going well, so we can go and look in something like Prometheus or another tool and see are there any kind of red flags for this deployment, and if so, well, then maybe our release isn't going so well, so we should probably roll back, and we can do that in multiple steps. And then the idea is that we can release to a subset of users so the impact is not as bad or as big as it would be if we released to everybody at once. So why would we want to use progressive delivery? Well, of course, the idea is to decrease the downtime to a smaller set of users, but also we have more confidence in our releases so we can limit the tragedy of a release and then the impact that that has, right? We can deploy to production faster because again, we have more confidence in what we're releasing, we have more confidence in our release process that even though something might go wrong, it's not the end of the world, right? It's only maybe few users might be affected, which is still not ideal, but at least we can have more insights, especially if we have the metrics to back it all up. And then if we can use production as kind of an additional testing environment, right? A little bit. That also means that we're maybe relying a little bit less on setting up mocks and fake services to try to mitigate how our production environment is set up, right? Because let's face it, a lot of us have still a little bit of differences between our testing environment, our UAT environment, our production environment, and there might still be some surprises. But with this way, we don't have to set up too many of those fake services. So we have some delivery techniques to go to production, right? So the first one you're probably familiar with, and I'm sure the second one too, that's gonna come up, but the blue-green deployment is basically you have version one, you're gonna deploy version two, not yet send your traffic to it, but you're gonna deploy it, and then at some point you're gonna say, okay, now switch my traffic from version one to version two, and if everything goes well, then you can tear down our version one. If something doesn't go right, you can still quickly flip it back, which is a pretty good solution, but Canary releases go a little bit further, right? Because then you can define, hey, I wanna roll out to, let's say, 10% first, and we'll see how those users are doing, and then we can change that to be more and more, and so just like the Canary and the coal mine, we have the early warning signs of, if those 10% of users are affected, well then let's not continue to roll out, right? So Argo rollouts then is a way to leverage Canary deployments and then add some more intelligence to the whole release using Canary and using Metrics, so Argo rollouts is basically kind of a drop in a replacement for the Kubernetes deployment, and you have some advanced capabilities for progressive delivery, and yeah, it supports blue-green, so we'll see in our hands-on lab that we'll first try to do a blue-green deployment, and then we'll work our way towards doing a Canary deployment. So the way that Argo rollouts works is basically Argo CD detects a change, and then Argo rollouts will take over basically to roll out the application, and in the meantime, monitor data from a Prometheus. We see Datadog here, that's just an example. There's many more tools, and then it can control the Canary release through sort of load balancer like an Istio or an Nginx or a few different tools, and then control how many pods will receive our version one traffic and how many are receiving version two traffic. So here's an example of a rollout manifest, so you'll get to play with YAML, of course, in the lab, and you can see here, we can see a rollout looks very similar to a deployment, except that in your strategy, you have Canary, and then you can set a certain amount of steps where you can set the weight, and the weight is basically a percentage, right? So you see here, in this case, rollout first to 20%, then the next step is to pause, and the pause is, in this case, one minute, it could be more, it could be less, whatever you wanna set it to, and in that time, you can monitor your system, see if everything is going well, and if so, then Argo rollouts will automatically continue rolling out, and in this case, in the second step to 50%, wait two minutes, and then keep rolling out, right? In this case, I've truncated a little bit because otherwise the manifest would be a little bit too long, but you can imagine that eventually it would get to 100%, right? Yeah, so there's a 20% and a 50%, like I was saying, and then we can make this even smarter, right? Because right now, we still have to go check during that pause phase ourselves to see if anything's going wrong, are we getting phone calls or something, so we can automate that part a little bit more by actually integrating metrics in these steps as well. So you do that by adding an analysis to your template. So you can see here, we have an analysis with a template name called success rate, and in that specific template, we can see that in this case, we're looking for a definition of success, which means that every 10 seconds is gonna check for a success condition, which basically wants at least 95% success rate, and then below we can see what we're actually looking for in terms of metrics, in this case, very simple example where we're just looking for 500-something errors, but this is something that you can completely configure, tailor to your organizations, to the metrics that you're collecting, maybe you're looking for certain metrics in the JVM that, you know, I'm a Java developer, so. But you're looking for maybe something is not going right because the garbage collector is collecting too much data, so anyway, you could go very far with this. And so that leads us to you, who gets to do the workshop now, so we have three different clusters set up, so we're gonna, seven, okay. We have seven different clusters set up. Do I need to refresh my slides? Okay, so we have three URLs that have seven clusters. Okay, perfect. Yeah. So I'll share the link in just a minute, so basically when you click on the link, you'll get to this page. Yeah, so the lab is created by our colleague who's not here, Gerald. Thank you, Gerald, by the way. And it's Argo rollouts running on top of OpenShift, so you'll see references to OpenShift, that doesn't mean you can't use Argo rollouts outside of OpenShift, right? It's a community project. We also have some of the co-speakers here, not from Red Hat. In this case, we're running it on OpenShift, but keep in mind, yes, of course, we from Red Hat would like you to use it on OpenShift, but again, it's totally fine to run this on a different Kubernetes cluster and get support from our friendly colleagues here as well. So you'll get to this page, then you'll just log in, just put a random email. We're not collecting this, it's just like a unique identifier. And then the password, once you log in, I think will be OpenShift, it'll say that. And then, let's see, and then we have to go to the URL and let's see, we're gonna split it up by row. So maybe if our co-speakers is gonna go stand in front of, so the first two rows over there will be number one, so you'll use the first link with Harriet there, and then Christian here, so from this row and that row, please use URL two, and then the last three, or the last two rows where COSIS is, they can use the third URL. And then the first password to access the lab will be kubecon24. You get to the page, and then for the rest of the lab, I think the password is OpenShift, but it says on that page in any case. So, yeah. Here they have to use this password, kubeconU24, and then they get the other access. Right, so I'll give you a moment to access this URL, and then if it makes sense, you can go ahead and continue following the instructions, and I'll show in a minute too, kind of I'll log in just to show you what it looks like as well. In the meantime, if you have any questions, yeah, stick your hand up, and our facilitators, our speakers will come and help you. Is there anybody that doesn't have the URL yet? Okay, then I'm gonna go ahead and click on the first one. So, you'll end up on this page, and like I said, just put anything in there, and I think I've already registered, so it might yell at me, we'll see. And then the password here is kubeconEU24. So, remember it's argorollouts with an S, so I encountered some people getting redirected by accident, so argorollouts, and then the number. The red dot hd slash argorollouts with an S, and then one, two, three. And then once you log in, you'll see the instructions for the tutorial, and so we'll see, the first link here is the lab guide, so go ahead and click on that, and you'll get to the lab guide, which will guide you through the lab, and then the second link is the access to your cluster, which you will of course need for deploying your application. And then the username is gonna be assigned to you, so there's gonna be a specific username, don't use user one, because that's me. So you'll have your own user, and then the password will be open shift when you log in. And then, yeah, then it's up to you. Read through the tutorial, and try out the different steps. In the meantime, I'll do a quick little demo of what we'll eventually see. So here we have an application. If you go to the argorollouts documentation, you'll see the exact same example, so that makes it a little easier. And you can see that in my case, I just wanna generate some color, so nice green color. And now I want to roll out to my new version, which might be a different color. Let's see, what color are we gonna do? Christian, what color, what is your favorite color? Red. Okay, we're gonna roll out to red. So I'm gonna do my commit, let's say that I'm making my code changes, right? Very complicated code. And I'm gonna push it straight to my main branch, of course. No peer review, no pull requests. I want straight to production. All right, so now I've pushed my change. And let's see, I have my argocd here. And I'm gonna make sure it's synced. And now we'll see that my application is gonna notice that there's a new configuration that has been pushed, right? So you can see here it's progressing and it's gonna start rolling out. So here on the left side, I can just monitor my rollout here with argorollout. And we can see that revision five, right? So kind of in the middle of that screen. And you see there's two new pods that are being created and the traffic is starting to be routed to my new version. So if we go to the demo, we can see that some red squares are starting to appear, right? So we're rolling out some of our, our pods are going to our new version or at least our traffic is going to our new version. In the meantime, there's this analysis run that's happening after every step that it's rolling out to. And we can see that in this case, things aren't going so well, right? We're seeing in our metrics that, make it bigger? Yeah, all right, let me, there we go. And we can see that we have three failed attempts. So we looked at our metrics, we were checking to make sure everything was going well. And in this case, actually it didn't, right? And we can see that our status is degraded and all our squares are back to green because there was some sort of error and I don't know if it's because of the wifi, I actually wasn't planning on it, but that's fine because it worked, right? I saw errors, it wasn't going well and Argo rollouts was friendly enough to say, hey Kevin, that's not going so well. So we're going to roll back to our previous version. So we can try it again, sometimes based on the network, I get more errors and if not, well at least you saw how to roll back automatically, right? So I'm going to recommit, what I could do is I could retry my rollout or I could just say, well maybe my code change in this version of red was bad. So I'm going to fix my changes and then actually red wasn't so good, so let's change it to purple. So change to purple, get push and then I go to the right side. I'm going to just give Argo CD a little bump to wake it up and you can see again, we're starting our rollouts, right? So we're starting with 20% because that's what I've defined in my template. So first rollout, 20% and you can see two new pods are being created and we'll see after a little bit. So now we're generating traffic here in our demo and we can see some of the pods are changing or our little squares are changing to purple. And again, we're seeing some errors in our analysis so we'll see. So I have the maximum set to, if there's more than two times we're running to errors then please roll back, which is again the case. So yeah, I guess there is a bug and I should fix that, right? I mean, or maybe there's a network issue or whatever and so it's going to roll back. Oh, but we do have a green check mark this time. So as long as it stays under three, we'll continue rolling out, which you see. So now we're actually starting our next step. So we're rolling out to 60% and again, we're generating metrics, we're generating the data for our application and if everything goes well, we continue rolling out, we're continuing rolling out until eventually we're fully on our new version, right? Our canary becomes our stable version which has happened in this case. Fortunately, we had maximum of two errors and not more and now in fact we are 100% on our new version and after a little bit of time, you can see here the delay is counting down nine, seven, six, five, four, three, two, one and then it's going to scale down the previous pods that we don't need anymore from our previous version. So it gives us a little bit of time for you to still like, oh wait, I still wanna go back to the previous version but now we can see that those pods have been terminated and we're fully on our new version and we did that in a nice progressive way, making sure that there are not too many errors and yeah, so that's the idea of progressive delivery and so you'll get to this as well. So again, we're a large group of people on Wi-Fi so hopefully the rollouts will work. If not, well then you see what happens when it doesn't work which to be frank, that's probably more interesting, right? Kevin, there was a question if the cluster stays up after the session, the cluster, the clusters themselves know but the tutorial you have will be up and running. It's served on, sorry, on GitHub pages so you can run the same exercise and check it out later. Yeah, the instructions are valid for any ARGO CD. This specific one is made on OpenShift. We have also the source code to deploy the whole workshop. It's in the same repo you are observing. There's on top right, you should see edit this page and that action will bring you to the source code. So someone did ask about, you noticed that he made a commit in order to retry the rollout but in ARGO rollouts you can actually retry the rollout without having to do a commit. He was just trying to fix something but you can actually, if it failed for whatever reason, you can, there's an ARGO rollouts CLI command that you can say, you know what, just retry the previous one that failed for me so that is possible so in case anyone was curious. Drops, Mike. It was around that everyone looks are okay with the access. If you have any issue, let us know. Let us know moreover if you can access the cluster. One is the tutorial link, the other is accessing the cluster. It's important you can access the cluster. Let us know if everything is okay. Yeah, so again if you wanna have access to the source code on the tutorial itself, top right here there's the edit this page that leads you straight to the GitHub repository and then you can just explore that and see how it's all set up and if you have any issues, you can always create issues of course. So folks, some SRE info stats. We have 300 people using the seven clusters. Those clusters are behaving good. The clusters are big enough. There are 12 nodes with 64 gigabytes of RAM each. So so far we're progressing fine. Weather forecast isn't. I hope he didn't just jinx it by saying, oh everything is fine. So in the meantime if you have any questions afterwards, you wanna reach out with anything. Here's our names and I just put our Twitter handles here but of course we're also on LinkedIn and all the other places. So feel free to find us there. We always appreciate it if we have any feedback or anything else on those channels. No, no, stay here. Hey, my friend David gave me a great idea to share with you our free eBooks you can download from our portal developers.com. In this portal you find the free eBooks and one of those are about GitOps, of course. And we have some very cool book. One is The Path to GitOps. The path to GitOps is made by our fantastic Christian Hernandez and it's a really good book that explain best practices on how to use GitOps, why to use GitOps, how to structure the repository, shall I use a branching, shall I use directories, what is customized, what is Elm? So it's really good for getting started into GitOps. And another book I strongly recommend you but just because I'm a strongly opinionated, it's the GitOps Cookbook. It's a book where you can find snippet of code for implementing GitOps workflow with Argo CD and there's also an introduction to things like customized, Elm, some example for the CI part as well with Tecton but those might be useful assets and you can download them for free using this QR code. So I leave this slide so you can get them for free. Thanks. So one thing that wasn't mentioned in the presentation and I think it's important is that if you like the Argo louts and you want to use them in your own applications, step zero is to talk with the developers and ask them, like tell them what you're going to do because not all applications can work with different versions at the same time. So you need to ask the developers, explain what you're going to do and ask them, hey, can I run your own application with version 1.1 and 1.2 at the same time? And maybe they say yes, maybe they say no, or maybe they say no and they're going to do some modifications. If they don't know about this and they have some strange shared resource locking mechanism or whatever, they will be very angry with you for trying this stuff. So ask them first. All right, so we're out of time here pretty much. I'm not entirely sure if there's a next session. There's not, so you can stick around here for a little longer if you want. We'll leave the lab running for a little bit longer. You cannot stick around. Okay, so I guess you can stick around. Okay, all right, so you can stick around for a little bit longer. We have to leave in a little bit. I don't know if some of the facilitators are going to stick around for a little bit longer, but you feel free to keep working on the lab if you want. And if you have any questions, you have our contact information here so you can always ping us about anything, possibly related to Argo rollouts, but yeah, if you have other questions, that's all so cool. Thank you in any case. Have a nice day.