 Hi everybody. Good morning, good afternoon, good evening. Where are the times when you are? Mario and I are going to do a presentation today on Kubernetes with Tecton and GitOps. So what we're going to do is we're going to go straight to our first slide. So as I said, I'm Ryan Cook and this is an amazing engineer, Mario Vazquez, with me. And what we're going to do is we're going to present and talk about a product, actually two products today that have been just completely influential in the last year, year and a half of our work. We've been incredibly passionate about both these products and so we're happy to share what we've learned thus far with them. So why don't we just get straight into it? So let's start off by talking about what GitOps is. I know that it's been becoming a really popular term. We've seen a lot about it on Twitter within the community. GitOps is actually just storing your YAML Kubernetes objects within your Git repository, thus the Git portion of this. And then the operations part of it is the best way to describe it is that the ops part of it is running kubeply-f of your Git objects over and over and over again. So think of GitOps and implementing it with your environment as having an extra admin whose sole job it is is to just stare at your repository and apply objects as they come in or as they change. A lot of these GitOps tools and the one we'll be covering today have templating options with the help of Helm and Customize and you just have to kind of fit the tool versus Helm or Customize of how you want to use it. The best part about GitOps and all of these tools are that there is no object limit creations. So you can solve a third party tool such as crossplane or you know, some of the other plugins from the cloud providers store those in Git and the GitOps tool will apply it. And then lastly, there's remediation of your environment through webhooks or sometimes it's actually just a controller running within the environment just checking on your repository. But with this, there comes some best practices. As with everything that we do least privileges as possible. You don't want to give a GitOps tool just kind of cluster admin access to everything because you know, things go awry. If you don't have a testing framework set up, you might remove a very important namespace. So just identifying the privileges that are important to your environment and what you want to apply. And then store code and Kubernetes objects and different repositories. This one's kind of back and forth. We've had really good success with storing them separately just because of the fact that one might move faster than the other one. Depending on the GitOps tool that you use, you might have webhooks. And if you're committing a read me update, you don't actually just want to push out a new build or at least evaluate if there's a new build. There's also set up proper RBAC access for your Git repositories. And then avoid storing regular secrets within your Git repository. The reason why I say that is regular secrets are base 64. You run base 64 dash D and that's no longer a secret. So Mario will actually show today in the demonstration how to use sealed secrets. And then with always documentation is huge. Definitely document the process and to recreate your GitOps tool and artifacts and just document the whole process because you don't want to be trying to figure out how to do this at three in the morning. So there's a couple different deployment models when we're looking at GitOps. And there's different tools that use the different methodologies. There's some tools that can handle both. For example, we'll talk about the hub and spoke. What this is is a GitOps tool that sits on a cluster. We'll call this one that sits in your main office. And then from there, it interacts with all of your different Kubernetes clusters out in the world all over the place. But they don't have any sort of tooling on them that keeps them in sync. It is all handled straight from that in office Kubernetes cluster. On the other side of that, there is a cluster independent mode. And this one's a little bit different because it only cares about itself. So all of those independent clusters all over the world in the cloud, they have their own GitOps tool running and they're calling back to get themselves. This is kind of nice because it doesn't require a connection between your office to that cloud provider or that distributed data center. But it's kind of harder to manage because they're all of these individual GitOps tools and clusters and so on. So you really just have to kind of pick the tool that really fits your organization and your scale. So the tool that we've just been kind of almost in love with for the last year has been Argo CD. The reason why we've kind of chose this one is the fact that it can operate in a hub and spoke model and it can operate in a cluster independent module. So it has like that both kind of feel to it. There's templating with customized in Helm. We absolutely love customized because it's so easy, especially we do a ton of work in multi cluster. So customize and the GitOps tool are just like our best friends. Argo CD also brings in the idea of pruning, which a lot of GitOps tools are really scared of. When I say it does pruning, think of think of a situation where you apply something manually to your cluster and it's not in Git at all and it's just there. What Argo CD will do is it will actually remediate that and remove that manually created item from your cluster. So if you're security minded, this is awesome. This is a security administrator as well as your GitOps tool handling stuff for you. This GitOps tool is security and deployment. And as I said earlier, it does multi cluster configurations, which is massive for the work that we do. So as I was saying a minute ago, we love customize. Customize was actually the tool itself, the tooling and the ability to use it was integrated into Kubernetes 1.14. So if you run kubeply-k, it's going to attempt to customize your directory. All customized really does is allows you to provide overrides of specific entries. For example, if one location should have more replicas of a pod than another, it's just it's really cool and really simplistic. And it makes your code kind of minimalized. And it's super powerful when we talk about multi cluster. So now we're going to completely switch gears and go to Tecton. With GitOps and our Argo CD tool, that was applying resources to our environments and keeping them in check. Tecton is going to be actually our CI CD tool. And it's the ability to, when I say that CI CD tool, it's going to create our artifacts for environment. It can create images. It can create pull requests of our different deployment of the image that we just created. It runs serverless. So when I say that, that means there is no pod sitting there waiting for work to happen. You actually launch against the Tecton endpoint, and then a pod is created and then goes away when it's done. So it's different than previous generations where we have our Jenkins server that just hangs out and waits for work to be done. This only executes when called upon. It enables pipeline and workflow functionality. That is something that Argo can't do today. Argo will look at a directory and it's just going to apply everything in no specific order. A demonstration which I'll show here in a moment shows why order is sometimes important. And then the last piece of my cover, it's pluggable. When I say that it's pluggable, you could take the same set of tasks that your developers and your users and your administrators develop. And then you can actually just hand it out to everybody. So the cool thing is creates a really a sharing environment. You can reuse these tasks over and over in different pipelines or in different groups within your organization. And so the next step is I'm actually going to break down some of this terminology. I know that I just said pipeline. So they have these individual, I guess processes is the best way to put it. A task is the simplest process. A pipeline is a series of tasks. And you see this event list center trigger binding and trigger template. And that allows you to create a web hook that will execute this pipeline in these tasks. So to kind of break this a little bit easier for us to understand, let me show you example of a pipeline that I have to use regularly. So as you see what I'm sharing my screen here, I have to do like a ton of multi cluster work and I make mistakes frequently. So what I did was I have this pipeline that creates clusters, sleeves, and then peers the two newly created clusters together. So I have highlighted here this create tasks. So let's actually break down what this actually looks like. So this create cluster task, all that it really actually is, is running a cube CTL create command. And what it's doing is it's checking my get repository, and then applying whatever is in that repository. So where does the get repository actually come from? And that is actually where that task run comes in. Your task run tells the task what the answers are to the variables that it needs. So as you can see, I have my get repository here and my path to my YAML file in which that create cluster task actually has to run. The really cool thing is going back to this task here, actually, I'm able to use it more than one time. So you're seeing it here, going to my pipeline, you're going to see this create cluster one and create cluster two. That's the strength of pipelines because I have multiple tasks going in a specific order. And then at the end of it, I end up with two clusters that are Amazon pure together and allow me to develop and start working immediately. So looking at our pipeline, it's very similar to tasks. It's just a little bit more dense. We have a couple parameters that we require to run our pipeline. And those are actually answered within our pipeline run. As you see here, here's my answers. I'd like cluster one and cluster two, as you see here. And then it references our create cluster pipeline. So as you see, they all kind of tie back together. And then the last item that I'm going to cover is the what they call a trigger template. It looks very similar to pipelines. As you can see here, same variables. We have a pipeline resource and we have our pipeline run. And what this trigger template and below, as you see here, trigger binding an event listener, this actually creates a web hook. And what you can do with this web hook is you can give this to GitHub, get lab. And then anytime your code is committed, it's going to kick off a new build for you. So Mario is actually going to show that later on with a really fun demo with some CI CD testing. So going back to our slides, you're actually going to probably ask me right now, why are you using Argo and Tecton? And the easiest way and kind of why I showed that demonstration a minute ago is the fact that I need my clusters actually created before I can actually peer them. And that's one of the things Argo CD would actually create my clusters for me and do an amazing job of it. But it would never know when they were actually available to the point where I could actually peer them. So they kind of go hand in hand together and create a very, very strong team. And they utilize each other's strengths. Tecton is perfect at handling your image life cycle. Argo CD doesn't really have any idea of that. So when I say your image life cycle, Tecton is going to build your container image. It's going to put all the assets and then it's going to push it to your repository. You can add testing within Tecton, your Tecton tasks and your pipeline. And then the really fun thing where we tie this all back together with Argo and what I was saying earlier, you can have all of your tasks sitting in one get repository. And then you just provide the namespace and Argo is going to share out any tasks that your team comes up with to the different namespaces, to those different developer groups so that we're not recreating the same work over and over again. So it's such a good team together. One handles the YAML objects, other creates, handles the workflows and asset creation. So I'm actually going to cover a couple helpful binaries that you would actually use when it comes to these scenarios. You'll see there's an Argo CD binary. All this actually does is it allows you to interact with Argo CD, not using the web UI. There's also the TKN binary. Same exact story. It allows you to interact with Tecton without having to actually go and modify the YAML or running kubectl logs and trying to figure out what's this job is actually going on or what's happening to it. And then last, how I mentioned earlier with kubeseal. kubeseal will allow us to create sealed secrets, which we can actually store within our, excuse me, within our get repository. And these sealed secrets are only able to be unlocked unless you have the required certificates. And so with that being said, let's actually see a demonstration of all of these pieces together with Argo CD, Tecton. As you can see here, this is kind of the demo architecture. We're going to store our YAML files within get. And then Argo CD is going to actually populate our stage and production namespaces with the assets created by Tecton. And with that, I'm going to pass it over to Mario. Okay. Thank you, Ryan. All right. So let me explain the demo that we are going to do today a bit. So basically, we have a really simple goal and application that we want to, every time a new commit hits the master branch of our application repository, we want a pipeline to be run, which will link our code, then it will test our code. And finally, it will build our code. And when all of that happens, if everything goes okay, then we will create a new container image that will be pushed to a container registry. In this case, we're using Quay. And on top of that, we will update the deployment files. And then we will be able to deploy the new release automatically to the staging environment. And then for the production environment, we will see a different pipeline, which will basically promote the stage image to the production environment. And that will generate a PR. And when that PR is reviewed, when that merge, then the application will be deployed to the production environment. In this case, as Ryan said, we are using namespaces as environments, but this could be done using different clusters. And every cluster will be a different environment. Argo CD, as you know, supports multi-cluster. So you could do that as well. And without further ado, let me share my screen really quick. All right. So this is that you are seeing now is the Argo CD Web Drive. But let's just start explaining the different repositories that we have. So the first one, as I said, it's the application repository. Here we have a really simple goal and application. We have the Docker file, which instructs how to build the image using the binaries. We have the test files. And it's just a single run. That's pretty much it. And then we have the CI-CD repository. In this CI-CD repository, we have multiple branches. So the first one that I'm going to show is the CI. Here's where we store every single CI file that we use for tecton. Taking a bit to load. Let's see. All right. I cannot reach the... Okay. Anyway. So we have different branches. So we have the CI branch, which has the tecton files that we are going to use in our pipelines. Then we have the config branch, which will store the different files used to deploy our application to multiple environments. I really need this to load in order to explain it well. Maybe I can go to GitHub if this is not working. Okay. Never mind. Let me change the different repository really quick. Okay. So basically, this is the same repo, which is public on GitHub. So as I said, we have the config branch, where we have the files that are common to all our environments. So for example, here, we have a deployment. This is a really simple Kubernetes deployment. We have an image. And then we have a release environment variable, which we can set to different values. In this case, it's set to base release. And then we have the service and the customization file. The customization file in this case, for the ones that know about customize, it's really simple. We are just saying that we have two resources here, the deployment file and the service file. And then we have the different branches for our environments. We have, for example, production. And in this range, we have different files. Those are the files that differ from our base configuration. So if we look at the deployment, you can see that we are just using a different image. And then we are setting the release variable to a different value. In this case, production release. So that's okay. Other than that, here in the customization file, we are seeing that our base files are present on this same Git repository on the config branch. And then we have other resources that are specific to this environment, which are the name space and the ingress. And then we are patching the deployment file. So if we look at the name space, for example, here, we can see that we are using a reverse rose production name for our name space. For example, if we go to the states branch, we will see that we are using this name for the states. So that's what we have in the GitLab repository. And now I'm going to explain the different pipelines with a more detailed diagram. So first, our developers will send code changes to GitLab. And then when that happens, that will actually trigger a webhook. The webhook will instruct Tecton to run a pipeline. The pipeline will link test and then build our code, create a new image, will push the new image to the Red Hat IO registry. Then the pipeline will go ahead and update the CACD repository. And in the states branch, the deployment file will be modified. So now it uses the new release that was created on Quay.io, the new image. After that happens, that change on the CACD repository will trigger another webhook that will instruct ArgoCD to actually go ahead and deploy the application to the states name space. That way, once a commit hits the master branch on our application repository, we will get that code deployed automatically without human intervention. And then when we have tested the code on the staging environment and we are ready to move it to production, there's a different pipeline. In this case, the developers or the CISAD means whoever wants to need to run a pipeline manually, will need to introduce some data. And that will actually generate a pipeline run that will go ahead and open a pull request against our CACD repository on the production branch. And then that PR will be reviewed by some people or maybe the environment admins or whatever. And once that PR is merged, then ArgoCD that will trigger a webhook and ArgoCD will go ahead and create the production and deploy the production application. So let me go to ArgoCD really quick. So now we don't have anything loaded in ArgoCD. So the first thing that I'm going to do is I'm going to add the CICD repository. So GitHub is all about Git. So we need our Git repository loaded into GitLab. So I'm saying this is my Git repository. I don't need any username or password in order to clone it. So I will go ahead, click connect. So that our Git repository to, let me see. So I don't know if something is happening with the, with the GitLab server, but it's not working for me. Let me try, let's try using the CLI. Let's see if we have more. So it seems I cannot reach the, the GitLab server from my computer or from the server. So I need to, so our GitLab is down. So I'm going to try to perform the same demo using GitHub. I'm not sure if everything will work. I will try to make it work. So as I said, as I said, I'm going to use this repository here. In this case, it will be GitHub. Then, oops, sorry. Okay, let's go to GitHub. This is connected. And now I'm going to go ahead and create the staging application. Let me create applications really quick. So I'm going to name it reverse worst stage. Then the project will be used. So, ARGO CD has different projects. You can like have projects to store your different applications, like if it was an image space kind of thing. Sorry, I'm working on the web UI now. And yes, basically we are creating the application under default. Now the sync policy, I'm setting it to automatic, automatic. What that means is that ARGO CD will query the Git repository every three minutes by default and we'll try to see if any change is needed for our application. And then we have here the brand resources that Ryan explained before what branding is. We are not going to activate this. And then self-healing. It's kind of the opposite of branding, I would say. So in case there is something in Git that is not in the Kubernetes cluster because someone deleted it or something, ARGO CD will go ahead and create that for us again. Then we want to validate the resources against the schema. Then we have the repository URL, which is the reverse worst CI CD repository. As we are creating the stage application, we are going to use the stage revision and our deployment files are in the root folder for that repository so we don't have any folders. When you are using GitOps, there are multiple ways of storing your artifacts, let's say, inside the Git repository. You can go with folders or you can go with branches. This is not a standard. So you can do it the way that fits best for you. Then as a destination, we are using the cluster where ARGO CD is running. If we had more clusters added to this ARGO CD instance, we could basically choose different clusters here. That's the way that you do multi-cluster with ARGO CD. And then the name space that we are deploying is reverse worst stage. The customize is okay. Let me try to verify if GitLab is working. Okay. No luck. That's right. Some things will fail. We will try to see what fails and why. So basically, ARGO CD now went ahead and created the different objects. Here we can see the deployment, the service, the ingress that won't work because it's using a different domain that it's not properly set up at this point. Then we have the pod. Let me try to... I'm not sure if we will have time for doing this, but I want to basically that to work. So let's go to a stage. In the ingress, let's edit the ingress. All right. I'm going to do it from the CLI. Or maybe we can go ahead and we can go ahead and continue without that working. Okay. I will do that. Now I'm going to do the same thing. I'm going to create a new application for production. But in this case, I'm going to use the ARGO CD CLI. So this will be the command. ARGO CD create project. Then the project, same parameters. But in this case, I need to change the repository because this one is not working because it's down. So let me do that really quick. Okay. So now the production application is created. So we should see the production application coming up here. Same as before, the ingress will be wrong because it's pointing to a different server basically. So that will not work. But now what we wanted to show was the webhook. And I'm afraid that I'm not going to be able to show that on GitLab. So I'm going to show it on GitHub, which is kind of the same. But we won't be able to run the automatic webhook. So I will need to run the pipeline manually. But anyway, I need to log in really quick. Let me do that. Okay. Let me put my authenticator code. Okay. So if I go to settings, here you can see that we have the webhooks thing. So in GitLab, what I would do is basically come here. And this is for the deployment repository. I will configure a webhook that says that whenever there is a push to any branch, it needs to send a webhook to this URL. This URL, it's basically an argocid endpoint. And argocid, it's smart enough to understand which application it needs to update. Because when you create an application, you define a Git repository and then you define a branch for that application. So it will read the Git repository and then it will read the branch and will update the application that is configured with this repository and this branch. And now that I'm logging in, let me see if I can fix the URL for the application. In that way, we could see the different versions being deployed. So this is not like that. This will be a different... Well, it won't work anyway. So I'm not going to do that. We will see it using the CLI. Okay. And then for the reverse application, so for the other repository, which is the one for the application, it will be the same. So basically, a webhook that will connect to the Tekton event endpoint that we have published on our cluster. And that will be captured by Tekton and will run the pipeline as we want. So now let's see if I can basically force a pipeline run using the Tekton CLI. So we have here the TKN CLI. So now we are using the reverse or Tekton name space. And we want one sec. I'm going to copy paste this. So actually, we have the web UI for Tekton. Let me show that really quick. So here we have the Tekton dashboard where we can see the different pipelines that we have. And I think that, well, we can run the pipeline from here. So let me create a pipeline run. So basically here, we have the reverse, the name space where we are running the pipeline, the name of the pipeline that we will run. Then we need to provide some resources. So the repository for getting the code. I need to change that really quick because it's pointing to the GitLab instance that it's down. Okay. Let me do that really quick. I'm on the terminal now. This is in the build pipeline. So keep CTL one sec. Let's see if I can do it from the web UI. It will be easier for you and for me. Okay. So we have the CICT repository here. Let's update this YAML. I don't know if we can update this YAML here. Okay. We can back to the terminal. All right. I'm sorry. That was wrong. So now we have the pipeline resources. I'm going to edit these two resources here. So basically the CICT repository and the other repository for the application. Okay. I want the SSL verify. And then I'm going to the same for the base Git repository here. We don't need this. And then we have, I think that's pretty much it what we need. And now I'm going to, I'm going back to the web UI so we can go ahead and run the pipeline. So you can see it. So reverse build pipeline. Reverse work. We are using the application Git repository here. We need to use the, this image, which is the Quay IO image. We will use a different tag. For example, since we are running this manually, we will need to provide a tag. If this was run using the web hook, what will happen is that the, the commit ID from the Git repository for the application will be used as image tag. So that way you have the latest commit ID as your image tag. You can see which, you can know which changes were introduced by that image by looking at the commit ID. Okay. And then we need to use this service account which has privileges to push the image to Quay. And that should be it. Let's see. So we need to wait a bit because we need to wait the pods to start. In the meantime, I'm going to check if GitLab is up again, but it seems it's down. Okay. So basically what this is doing, if I go to a terminal, you will be able to see that we have some pods. Okay. So this is the pipeline run and the pod, the pipeline is running at the moment. Okay. So now the, the application code is being downloaded. And we will basically link the code. After that, we will go ahead and test and run the test. And when that, when that is done, we will basically go ahead and create a new image and publish it to the Quay IO repository. And then the last step will fail because the last step will be connecting to the GitHub repository and update the deployment file. And since the GitLab instance that we are using for demo is down, we won't be able to show that. So I'm sorry. Maybe we can share a video with you after that. All right. So the LinkedIn is complete. Now the next step will be testing the code. So the pod is still waiting to start. Okay. Now it's running. Same thing. So it will basically run our tests that are defined in our application repository. And in case all the tests are okay, then it will continue and will generate the image. This will take a bit because it's the first time that we run the pipeline in this cluster, but the next runs will be faster since we will have most of the container images available locally. So I'm going to show you what will happen in the Git repository. So in this repository here, in the CIC repository, the pipeline will go ahead and in the stage runs will basically update this file. And here this will be changed by the tag that the pipeline has defined. In this case, we defined the OSS20 tag. So we will need to update this to that tag when the pipeline ends. So let's wait for that to happen. And when that happens, I will manually update the file. So we will see the application being updated. So now while this is running, sorry, I was in the terminal for this whole time. And this was happening on the Argo CD, sorry, in the Tecton dashboard. So basically the LinkedIn and the testing is complete. And now we are building the image here. And next step will be pushing the image. And as I said, what will happen is that when the pipeline finishes, this file in the GitLab repository would be updated. So this tag will be set to OSS20 instead of this commit ID here. So I was saying that let's wait for that to happen. And then I will update the file. And we should see the application being updated. You can see here the tag that we defined. OSS20, sorry. And then this stage will likely fail because we don't have connectivity with the Git server. So I'm going to basically update the file manually. So here let's go ahead and use OSS20. So this is the tag that we use for the pipeline to run. So now as soon as I change this, or if that was changed by the pipeline, Argo CD will receive a web hook that will trigger an application deployment. This is not going to happen because this repository is not configured to use this Argo CD web hook. So what I'm going to do is basically run the sync, which is what will happen when the web hook is triggered. So basically we want to synchronize. And this should see that the repository is out of sync because the deployment file was updated. So now we can see how the Argo CD went ahead and updated the deployment object. And that generated a new pod, which if we go to the terminal now, here we can see that new pod deployed here. And if we look at the image, we can see that it's running the OS20 image. And then if we look at production, we can see here that we are using a different image. Sorry, I missed the pod. So next step will be running the promotion pipeline. So I'm going to do that. I'm going to show you the command that we will use for running this using the TKN CLI. So we will need to introduce the namespace where our pipeline is defined, then we will start the pipeline. This is the pipeline that we want to start. The resource that we're using as application is the CI CD repository. So this is a repository where the pod request will be created to update our deployment file. This is the file that we are updating. In this case is the deployment YAML. This is the stage branch. So where are we going to get the release that is deployed on the stage environment? In our case is a stage branch inside the reverse for CI CD repository. And then here we have the another parameter, which is the stage application URL, which can be used in order to run tests against our applications. In this pipeline, it was a really dumb test that was accessing the application using a core command. And then the pipeline will basically go ahead and create the pull request. So instead of creating the pull request, which won't work because Git is down, I will go ahead, go back to Firefox. Then I want to get this tag here. I want to go to production. And again, this is not how you do GitOps at all. So sorry about that. That will be a pull request. Then some reviewers should take care of reviewing that pull request, make sure that everything is okay. Different companies will have different workflows or different teams will have different workflows as well. But in the end, when the change reaches the production branch, that will trigger the Argos CD webhook. And now the production, as you can see, it fired the update automatically because basically every three minutes, Argos CD will basically go to the Git repository and see if anything changed. In this case, the deployment changed. So I didn't need to hit sync here. It's automatic. So you have two ways of working. You can just wait for Argos CD to go and get the changes or you can, using a webhook, you can, as soon as the file is updated, get the application deployed. And now if we look at the, well, that won't work. So we're not wasting time looking at the output. Here, we will see a different pod now. Sorry. So this pod will be using the product, the image that was tested on staging. So that's the way that you can basically go from the code to a stage and last step to production. And now I want to, so that will be the demo that shows how you get to production, your code. And then now I want to introduce you to Sealed Secrets. As Ryan said, uploading secrets to Git is not a good idea. So basically, I'm going to show this really quick. So KubeSeal, you need to deploy a controller, which basically uses PKI for encrypting your secrets. And then I'm going to create a dam secret here. So you can see, this is a regular Kubernetes secret. We're almost out of time. So I'm going really fast. This secret, as you can see here, you can decode it using base 64, that's the, as Ryan said, it is not secure at all. So you can, you shouldn't upload this file to Git, but instead you can use Sealed Secrets. So basically here, the KubeSeal command will read your Kubernetes credentials and will connect to the, will use the KubeSeal controller to encrypt your secrets. So we are saying, okay, I want to seal this secret. That is the secret that we just created before. And I want you to output the Sealed Secret in this file. Okay, so now this is a Sealed Secret. As you can see, we have the same data, but this is a new, it is a CRD, which has the encrypted data instead of data. And here we have the password, for example, if we try, if we try to decode this as we did before, this will fail, this binary binary output, because this file is actually encrypted. So now you could go ahead, upload this file to Git and it's safe. Then ArgoCD or the application that you use for deploying will basically create the Sealed Secret. And once the Sealed Secret is created in the cluster, for example, if I go ahead and I create this secret here, the Sealed Secret. Okay, now I should see after a while, I should see the, well, after a while, no, it should be in this repository, in this name space, I should see the Sealed Secret, which now it will be usable by Kubernetes. So you can see here that we have the password that we had before. In this case, you can go ahead and, oh, sorry, I was doing all of this in the terminal, I'm so sorry. You can go ahead and decrypt the secret. But the Sealed Secret, as you can see here, you cannot decode that. So if you try to do that, you will get a binary output, as you can see here. So that's the file that you should upload to Git. And when you create that file into Kubernetes using Argo CD, you will get the secret decode. So you will get an encrypted secret, and you could use that in your applications. And that's it. We will answer the questions after the talk. We are available on the Slack channel, the demo, the working demo, it's available in the GitHub repository that you will have on the SCAP website. You can go there. You have the slides there. And at the end of the slides, you have the link to the demo. So you can basically create an environment using any Kubernetes cluster you, so any Kubernetes distribution you use, and run the demo by yourself. Thank you very much for attending the session. I'm not sure if you all can still hear us, but thank you all for attending. We really appreciate your time today. Mario, thank you as well for creating a demo on the fly. So really cool stuff. I hope we answered a lot of your questions. Like Mario said, we'll be in the Slack after the call. And elsewhere, if you need to reach us, we're also on Twitter. So feel free to connect and ask us any questions you guys might see fit.