 Hello, my name is Peter. I'm a customer reliability engineer with Benify JetStack Consult. We're gonna talk today about GitOps application preview environments with a demo in hopefully just under five minutes. What is an application preview environment? Your version might differ slightly, but they are roughly the same. It's a deployment of your application. It's based on the latest changes to that application and deployment-wise it has very similar configuration to any other instance application. It's live and accessible to stakeholders and it's probably on some custom domain, either a new one or a sub-domain of something else in your environment. Now, when does a preview environment fit into development mode? Now, I would say they're most useful before your code hits main. Imagine you have a feature branch where you have made some commits for a new feature to your application. You want your work to be reviewed and you open up a pull request as you usually do. Now, when that pull request is opened up, people can review the code, but wouldn't it be good if they also had an instance of the application to also go and review it? Now, this is where an application preview environment comes in really handy. A live instance with your changes that people can use to test it actually works how it was meant to work. And when it's done, when the codes merge or the PR is closed, the environment should be removed because it's served its purpose. Now, you can create these environments manually with YAML or any other tool or manually. But what about when there's problems scales? So how many feature branches do you have in your application impossible? And just how many pull requests do you have associated with that? Well, as you can see, as your application scales with more features and more work going on, the amount of environments being managed also scales. And there must be a better, more GitOps out native Kubernetes way of managing these. And luckily, we do have an answer. Today, we're going to use Argo CD as the GitOps CD tool. We're going to be using an application set resource, which is a relatively advanced feature of Argo CD. It defines an Argo CD application per some iterable x. In our case, we've already identified that we have an iterable of pull requests. There's probably many of them. And we want to have an application per pull request so that we can review what the application looks like at that point in time before we merge to main and then hit release processes for that application. So in this demo, we'll be using namespace isolation, whether format is going to, whether application preview will create a namespace with the application so that you can apply isolation in a cluster so that it really is its own instance of an application without interfering with other things. But you could also get up to some shared services, which you might need to for bigger applications. The format is going to follow that branch number that's shown. Now, very quickly, the application on the left has a spec field and application set also has a spec field that is very, very similar. It's defining the specification of the application. It's just indented so that we have a generator section and some metadata that applies to the applications. Now, the key and item on you will notice that we've made some tweaks to the values there. Actually, we're using two sets of values. We've got values while some of the repository itself with the deploys values dev.yaml. And then we've also got some values embedded. And this is where we're taking advantage of a feature where we can input some template variable. On the left, I've identified the ones here that I've used. The head char is going to keep us up to date with the most recent commit on the feature branch. Great, our preview environment is going to be up to date. The branch is referring back to where it came from and the number is referring back to the pull request number that actually initiated the environment. The branch log is also a really handy DNS compatible version of your branch name. So in the example here, I'm using it with an ingress specification so that we hopefully get a real world endpoint we can use to test today. That's about it for slides. We'll come back at the end, but let's skip straight onto the demo. I want to show you that I already have my application. So I'm going to go to the terminal. I'm just going to clear it quickly. And I'm also going to show the structure here. I've got my chart in the repo. I've got my source code in the repo. I've also got my application set deployment. Now let me just show you this quickly. You can see here, I've got my generator pull request but I'm only specifying pull request with specific label of previous. I'm also re-curing quite quickly for demo purposes here so that this continually pulls to keep it up to date. Now you can also see that my destination is inked in the operations cluster where obviously it's deployed but the naming format for the namespace is here. But you can also see I'm using the same naming format for the application name itself. So it should be obvious when the applications generate. Now I'm just going to skip right over into Git here. So over here in my Git repository in the interest of time, I've already opened up any PR. I just haven't labeled it yet. So let me do that now. The label that would preview. You might not do this in a real world set up where you might automatically apply labels to things that need to have a preview environment. But let's give that a second to check if that deploys. So I'm going to go into AlgoCD. Oh, and you can see there already, it's already picked up my application. That was really quick. Now you can see here it's deployed in new namespace a few seconds ago. It's got my deployment, service account, service, and my ingress. And it's also generating a certificate for me. So hopefully if we give this a few minutes, that will work. But let me show you on the command line as well. It's the same cluster that I can get in your namespace and you can see here that I have a new namespace 39 seconds ago when my application is deployed. Now what we can also do is we can try to curl the endpoint. Now I already know what the endpoint is going to be because I used a format, but I can use the ingress link in AlgoCD to also go into the application. So I know I'm getting a privacy error here. My certificate hasn't been generated yet. So it's using the default one that isn't valid. So let's leave that for now and go back to the command line. And what we'll do is we will curl the endpoint, but we will not use, we will ignore the SSL format. And you can see here, I've got my response. I've got my hello world, welcome from branch new endpoint PR number 25. And I can double check in my preview because I pass the same as conflict from application passing in the variables that were needed. So I knew I got the right response. Now I also, if I go back to my PR, I actually add a new feature in here. If I look at the files changed, you can see I updated some dependencies, but I also added a slash JSON endpoint because I wanted to get some JSON output. So let us see now if that works as well. So I'm going to do similar curl here, but I'm going to pass slash JSON and I'm going to hopefully find that to JQ and there we go. My new endpoint is actually working. My host is, I've got the same message, so the same new endpoint branch that I'm currently on. I've got the PR number 25 and I've also got the time here to prove to you that this is a real life demo. Do that again. You can see the times moved on. So the things are working awesome. Let me just see if this works without ignoring it. Yes. And it does. I have a real life certificate. So that's an added bonus. I wanted to show that it's entirely possible to have real-world certificates. It might take a little bit longer, but in the previous environments, if the PR is going to be open-virus before someone looks at it, that probably doesn't matter. But then just go into UI now. You can see my new endpoint works here and I can also hit my new JSON endpoint. Awesome. It works as exactly how I wanted to. Now I'm actually going to close this PR because I'm not entirely happy with the app though. So I'm just going to close it for now. Notice I've left the label, but what we should see in Argo now is if I go back to the main view very quickly, it's going to pick up that I've closed the PR and that it no longer should have an environment there. And it's already deleted. That was quick. So I can do get namespace on the command line and you can see my namespace is gone. I've cleaned up after myself. So that's the demo over. Let's quickly go back to the slides. One final wrapper. So what do we get out today? Well, we defined one YAML file for a previous environment, but that one YAML file would create many environments if we had many PRs. And it would also clean them up like you see. We could reuse our existing application specifications, manifests, charts, and we can hand over configuration control to development teams. That form team can set up the application set resource with development overrides to make sure you get unique environments. And best of all, there was no copy and paste involved at all. No YAML sprawl and much easier to maintain than lots of copies of essentially the same YAML file. Now, where do we go from here? Well, there are definitely some security implications. Please go and read them for application sets. They're very important. The project and AlgoCD RBAC considerations are also important here because you're essentially allowing people to generate applications which could go in any project or any cluster and you need to have the right controls in place. You might want to consider automatic container image updates with AlgoCD image update so that you could apply tagged versions of the applications. And maybe in the future, maybe there's something that's going to write back some links to the PRs because that would be much nicer than having to go to another place to find a link or having to know what the link is going to be beforehand. If it's written on the PR, it would be nicer. Now, this is a simple example, but I hope you found it useful and I hope that you can see that application sets are a powerful entry point to providing advanced business features. In this case, it's a preview environment, but there are lots more cases, use cases for application sets. Thank you.