 Welcome everyone again to the depth and right now we have with us Mario who'd be speaking about the code to the production. Kubernetes with tecton and GI so I'd be having Mario as well in the session right now and if you have any of the questions for the session you can just push posted in the chat box to the right side of your screen. So I will go ahead and start the recording sessions. If you have any of the concern, just let me know. Hello everyone. Thank you for attending this session. My name is Mario Azquez. And today we're going to see how you can go from code to production using Kubernetes tecton and github. But let's just start by github. So what is github github is a way to do Kubernetes cluster management and application delivery. It works by using github as a single source of truth for declarative infrastructure and applications. So our application manifest for Kubernetes will be storing github and github will provide version control for our files as well as audit capabilities. We can do templating by using other tools like home or customize more on this later. On the cluster side, it's pretty simple. It's just a controller which runs QCTL applied that's F over and over again. So if there's any change, it will be applied. There are no object types creation limitations. So as long as the API type exists on the destination cluster, it will work. And usually change changes are applied using web hooks or by a controller monitoring the git repository every now and then. Today we are going to see Argo CD. Argo CD is the tool that will enable github's capabilities in our cluster. So it features a super nice web UI with proper RBAC which can be extended as well. We can manage multiple clusters from it. And we can use Helm or customize to configure different overlays for the different clusters more on this later. Argo CD offers multiple sync options. For example, we have planning support, which means that if something is removed from git, Argo CD will remove it from Kubernetes as well. Again, all these options are configurable, so you don't need to have all of them enabled if you don't want to. And self healing, if something exists in git but it's not present in Kubernetes, Argo CD will go ahead and create it. We have auto sync as well, which means that if it's enabled every three minutes, Argo CD will check if there are configuration drifts. And in case there are some configuration drifts, Argo CD will fix them. And it provides web hook capabilities that can be used to force Argo CD to run as synchronization against a git repository by using a web hook, as I said. And for example, this is useful when you are using, for example, a repository for storing your deployment files. If you change your deployment files, you want a web hook, which is sent to Argo CD and that triggers the deployment of that new file, for example. Then Tecton, the other big thing in today's demo. So Tecton enables CI CD workflows on your Kubernetes cluster. It's kind of serverless, meaning that you don't need to configure your CI server plus workers. It's built into the cluster. It introduces pipeline and workflow functionalities. And one of the best things that it has is that it's pluggable so you can define tasks or pipelines that can be used by multiple teams or processes by using different parameters and resources at runtime. So that means that you could have a task which builds an application. It uses your standard base image and then you only need to provide the binary, for example. So that task could be used by multiple teams and everything will provide its own binary. That's a basic example. So this is the first pipeline, which is the one in terms of building and deploying the code to a staging. So we can see here the developers that will push new code into the Git repository. In this case would be a repository in GitHub. We have a web hook configuring in this repository, in the application repository, which when new commits are received will trigger a pipeline run in Tecton. Tecton will link test and build the code, create the container image, and then will push the container image to the Red Hat Registry. And after that, the pipeline will connect to a different repository. In this case will be the CI CD repository for our application and will update the deployment file for the staging environment. And we will see the different repositories later. Once the CI CD repository gets that update, that will generate a new web hook, which will send the web hook will be sent to Argos CD, and Argos CD will go ahead and deploy the new image to the stage environment, running an open-sit. So that's the way that we go from code to a stage. And then we have the other pipeline, which is the promotion pipeline. In this case, we have the stage build running on a staging and we have TestVid. It's stable enough to be moved to production, so the developers will manually run the pipeline on Tecton. Tecton will go ahead and run some tests and after those tests are OK, will connect to the CI CD repository and open a PR, modifying the deployment file for the production environment. Then we will go ahead and review that PR, make sure that everything is OK. And when we merge that PR, that will generate a new web hook that will be sent to Argos CD. And Argos CD will then deploy the new image to production. That way we will be using the same image that we use in a staging and production, automatically as well. We just need to review the PR. And that's it for the different pipelines. And now we will jump to the demand environment. All right, so let's get started with the demo. First of all, in this kit repository, you can find the required files in order to create your own demo environment. So in this file, you will get the explanations for creating the environment itself. And then in this other file, you will find the instructions to run the demo. So with that, we have a scripts folder here, which has the required scripts to automate the deployment of the demo environment. And with that being said, let's jump to the two repositories that we will be using today for the demo. So the first repository is the application repository. This repository is a very simple one. This has one range called main. And then we have the application code in this file, the application testing this file. And then we have a Docker file, which we will use for building the image for the application. Other than that, we have some configurations on the web hooks. We will see those later. And now we are going to see the CI CD repository. So as you can see here, this repository has multiple branches. Let's get started by the CI branch. So in this branch, we have all the YAML files that are used by Tecton in order to configure the two pipelines, the one for building the application and the one for promoting the images to production. Everything that we need is here. So if we want to move these pipelines to another cluster or if we need to recreate the CI environment, we just need to run OC apply on all these files. And that's pretty much it. We will get the pipelines up and running again. Then we have the GitOps branches, let's say. So I like to configure multiple branches for GitOps. Other people like to have multiple folders. So as we said before, there is no standard around this. So as long as it works for you, it's okay. So usually I create a config branch where I store all the manifest are common to all environments. So in this case, I have two environments, a stage and production. So I have a deployment and a service, which are common to those two environments. So as you can see here, this is a basic deployment. We have an image here. This is important because later on we will see how we can override some configurations using customize. So here we have the image that we are using for the base deployment. And then the release, we are setting the base release here. This is a simple environment variable that is used by the application to show the release on a screen. Then the service, pretty simple, plus the AP service, that's it. And then we have the customization file. And in this case, it's super easy to understand. We have only two resources, deployment and service, that's it. And now we are going to see the two branches for the environments. Let's just start by a stage. So in the stage file, the customization file, it's a bit bigger, let's see. We have the base files, which are pointing to this git repository. That is the git repository that we are using for CACD. But we are pointing to the config branch. So that means that customize will read the files from here. It will read the deployment and the service. And then on top of that, it will create some other things. It will create these two resources, the name, space and the ingress. Let's review them. Name, space, pretty simple. It's just this reverse words stage. Name, space for the stage environment and for the production environment. It's reverse words production. And then the ingress file, really simple as well. We are basically defining this URL for the application reverse words depth for staging. And then for production, we are defining reverse words. And that's it for the ingress. And now we are running a patch on the deployment file. So this is where we say that we are patching this file deployment. And now in a stage, if we look at the deployment file, we will see that we are basically replacing the release environment variable. We are changing each value from base release to a stage release. And then the image that we are using, we are using this tag. And this tag, I will explain later where it comes from. But basically, this is for a stage. And this is for production. We're using production release. And in this case, we are using the same tag. So this tag is configured automatically when we run a build for from tecton. It will read the latest commit file in this case, as you can see is B440. This is longer than this small thing here. But it will read that commit ID and it will be used as tag for the image that we are building. That way, we will know which code is included in which image. So now I can see that I'm using this commit ID on the image. So I know that the code that is included in this image is the code which is present in this commit ID here. Okay, so that's automatically, as I said, that's configured on the pipeline. So the pipeline will read the commit, the latest commit ID that hit the main branch for our application. And we'll use that as a tag for our image when building the image itself. Okay, so the idea now is that when we run a new build of the of the application, we will generate any image and this file here will be updated automatically by the pipeline. As we mentioned in these slides, so we will get a new commit ID here. And then when we promote the image to production, the pipeline will read this file. We'll see, okay, this is a tag that it's using a stage at the moment. And it will open a PR against the production branch changing this tag by the new one. That's the main workflow that we will see today. So let's get started by adding the CIC repository to tech to our good city. So as you can see now, we don't have anything in in our good city. So the first thing that we need is to add the git repository. So for you know to that we hit this icon here, we go to repositories we will want to connect using HTTPS. We will add this repository here. So let's get here, let's copy this. Now we put this URL here. We don't need username or password because it's public. Everything looks fine. So let's click connect. We can see that now we are connected to the git repository. So now what we are going to do is we are going to define the two applications in our good city. So let's click here on the applications. Now we want to create one application. So let's give it. Let's give it a name. In this case, we are creating the states application. So let's call it reverse was a stage project. Our good city has something they call projects so you can organize your applications under some projects. Then you can use our back in order to give some users access to some projects and so on so forth. Then sync policy. This is interesting. Basically, this means that if we use manual, we need to tell our good city when to run the synchronization against the git repository. Or if we send a web hook in this case, it will run the synchronization or then we have automatic, which means that after some time it will run the synchronization automatically. The default is three minutes. Then automatic gives us two different options. So the first one, brand resources, we explain it in the slides but let's review it again. It means that if we have something in the cluster, which is not in the git repository, it will be deleted from the, from the cluster. Otherwise, the application will be market out of sync, meaning that, hey, there is something in the cluster which is not present in the git repository. And then the self healing is kind of similar. It means that if you have something in the git repository, which is not present in the cluster, because maybe some user has deleted or whatever. It will synchronize that file again. So in this case, we want to have self self healing. We want to use a schema to validate the resource manifest. This means that the YAML files will be validated before being created. Then the source for this application is the repository that we just created. We are using the stage runs because we are deploying the stage application and then the path, it's the root folder for this git repository. As you can see here, we have all our files in this, in the root repository, sorry, in the root folder for this repository. If we had folders, we could configure the folder here. And that's it. And then for the destination, we are using the in cluster destination, which is the cluster where RGC is currently running. If we had multiple clusters added to this RGC instance, we could choose different clusters for the application. In this case, we only have one cluster, so we are using it. And then the name space where we will run the application, in this case, is resource state. And everything else, it's fine. So let's hit create. And that should start deploying the application. So here we can see the application and you can see it's out of sync and it will start syncing and creating all the resources. So now we can see that the name space was created, the service, the deployment, the ingress, the ingress created a route, the deployment created a replica set, the replica set created the product, the pod, and then the service created some endpoints. So that's it. And now that we have the application deployed, we can go ahead and click the ingress button and we can see that we are running the stage release, the application version 009. All right. So now on this, it's in deploying the Opensiv cluster. Let's review it here. We have the reverse-versa stage and we have the same application here. I prefer the RGCDB to be honest. But that's it. Now, what we are going to do is we are going to use the RGCDB CLI in order to create the production application. So let's put the command here. As you can see, RGCDB, upgrade, the RGCDB project will be created in the application, default in this case, the name for the application, the repository that we are using, the pod in the repository, the destination server, the destination namespace, the branch that we are using, the self-healing and the sync policy to automated. So that's what we, the same that we use for states. So I'm going to hit enter and then we are going back to the web UI. Let's go back to Firefox and now here we should see a new application production, which is being deployed. Now it's ready. And now we can see that we have the production release here, application version 009, same version that in staging. So what we are going to do now, well, and again, we can see this application using the OpenCiv dashboard as well. All right. So what we are going to do now is run an automatic build for our application. How do we have this configured? So basically we have in the application repository, we have a webhook here, which is pointing to the reverse words webhook that we created in Tecton. So when we create a new, when we create a new commit and the commit hits the main branch of this application, a webhook will be sent to this URL. This URL is running on our OpenCiv cluster. So Tecton will get the webhook and will run the pipeline, will run the pipeline with some parameters. And that will end up being an image pushed to create.io. And then these other repository will be modified. So the deployment file here will be modified by the pipeline. And this repository has another webhook, which points to the Argo CD, as you can see here. So when that, when that file, the deployment file is modified, the webhook will be sent to the Argo CD application running on the, well, to the Argo CD server running on the OpenCiv cluster. And the Argo CD webhook will instruct Argo CD to sync the application automatically. So we will see how the application is updated automatically. The webhooks are protected. So they need to send a specific patch phrase to the, in the, in the webhook. So that way we can avoid people running the, well, triggering the webhook if they don't have that secret. So let's go back to the terminal. And in the terminal, I'm going to configure that webhook for Argo CD. So basically, this is our secret here. And we need to use that to patch a secret in Argo CD that will say, okay, this is the secret that we use for GitHub webhooks. Once we have done that, now we are ready to send a new commit to the application. So let's go ahead and do this. What we have done is basically bump the application version from 009 to 0010. And now we are ready to run this Git push. But first, let's go back to Firefox. So I can go to pipelines here. We are using the reverse world CI project for the pipelines. So now I'm going to run the Git push origin main in my terminal. And we will see how the pipeline is run automatically when this happens. Right. That's the push. And now we can see that the pipeline is running now. So now we can see the different steps in the pipeline. So the first step is linking the code, then testing the code, and then building and pushing the image. And once the image is pushed to the registry, we will update the state's deployment file. So if we click here, we can see the logs for that step. So the link is complete. Now we are going to run the test. All right. So we can see the test have run now. So next step is building and pushing the image. Now the build is done. Now we are going to push the image. Right. So the image has been pushed. And now we are going to update the deployment file in the Git repository. So as soon as the file is updated, we will see that the Argus application will be updated. So now, as you can see, it was saying out of sync and now we can see that the deployment is being updated. So we have a different logic asset here, which is deploying a new pod. Meanwhile, we are going to see the file in the state's run here. So now we can see that the deployment not says 8771 for the tag. And if we go to this Git repository for the application, we can see that the last commit ID that hit the main run is 171db. Let's see there. 171db. Now the new pod is running. So if we go to the application, we can see that we are running the application version 0010. And the production application is still running 009, sorry. All right. So what we need to do now is running the promote pipeline. Let's do that. Let's go back to the terminal. And we are using the TKN command line tool for running this pipeline. So let me copy the command really quick. Then we want to start the pipeline, which is called reverse words promote pipeline. We are configuring two resources. The first one is the app Git, which it's configured to use the CI CD Git repository. Then the path to deployment file inside this repository is the root folder deployment file. The state's run. It's a stage and the stage application URL is the one that is returned by this command, which basically gets the route configure host name. So what will happen is that this pipeline will connect to the states to the states application. In this case, you could run some tests against the states application, which is currently running. And we are just running a core command. That's it. And now I want to show you that you can basically use the TKN CLI to see the logs for the pipeline run. The same that we did using the web UI, we can do the same using the CLI. So you can see that the states core returned this thing here. So stage release application version 0010. And now I think that will happen is that we will update the deployment file in the production branch opening up here. So let's go back to the Firefox view. So now we need to get the release, which is configuring the states repository. And now we can run the promotion. So let's go back to reverse was production. This is the application as you can see here the deployment has not been updated. So now what we are going to do is go to the CICD repository. Well, we can see here that the pull request has been created. The pipeline has finished. So now in this repository, we should have a pull request. We can see it here. And this pull request. What we'll do is change the tag for the image. As you can see, we are changing the old tag by the new tag. So as soon as I merge this file, we will see how RGCD updates the application for us. Right, this merge. And now we can see how RGCD detected the change. And now we are deploying the new release on production as well. So let's open the states application in the meantime. Okay, so in a stage we are running 0010. And now in production, we are running 0010. So this is how you can go from code to production. So the only manual intervention as you have seen is the promotion. So there are different ways of doing this. You could have a pipeline that runs automatically and opens the PR. And then you have some people review that PR. And once that PR is reviewed, you can merge it and then you will get to the application to production as well. So in this case, we are just showcasing how you can do it. And then, of course, you need to introduce some steps in the workflow that fit your organization. So that was it for the first part of the demo. And now I want to introduce you the Asilet secrets. So in this application, we haven't used any secret, but in case that you want to use secrets, as you can imagine, pushing a standard Kubernetes secrets to give to pastures is not a good idea, because those secrets can be decoded. So instead of doing that, there are other applications that you can use in order to encrypt your secrets and make them safe to be pushed to Git. So let's review that. Let's go back to a terminal. I'm going to deploy the Kibsil controller really quick. So basically we are deploying this, this controller into our cluster. And now what I'm going to do is I'm going to go back to the CI-CD Rupa story. I'm going to status everything that we have here. So I'm going to change to the stage branch now. All right. And now I need to pull the changes. In this case will be the deployment file that we updated before. And what I'm going to do now is I'm going to create a secret and I'm going to store that secret in a temporary file. All right. So we're creating my test secret, which has a username called admin and then password. It's called very secure. We're basically running this in right run. So we have this file here. And as you can see, if we push this to Git, it's as easy as running this. Basically for the code. And now we have the secret in plain text. Okay. So what we want to do now is seal our secrets. So Kibsil works with private and public keys. And when we run this command, here what we are doing is saying, okay, Kibsil, I want the output to be YAML. The input is this test secret here. And then the output I want it to be this test secret seal it here. So what we will, what will happen is that Kibsil tool will use our Kib config to talk to the Kibsil controller in our cluster. And it will use the public key to create this secret. And then the controller will use the private key to the creep that secret. So the secret can be created on the cluster. So now we have the test secret. The seal it secret here. Sorry. So as you can see here, if we try to run this base 64 decode command in this output here, we'll get a binary output because this is encrypted. All right. As you can see that it didn't work. So this, this file, it's not, is now safe to be uploaded to the git report story. So the first thing that I'm going to do is I'm going to add this file to the customization. So now you can see here that the customization has a new resource, which is called test secret seal it. I need to add this customization new customization file and the test secret seal it. I'm going to commit this and push this to the stage branch. And now if we go back to Firefox, if we go back to the August, the application, we will see that the application is being updated. And now we have the seal it secret that has created the, the secret file that it's just by Kubernetes. So if we go back to the terminal, now in the reverse words, a stage name a space, we have a secret, which is called my test my test secret. What we can run this and we can we will get the standard corner secret that now we can decode. The difference here is that the secret it's encrypted in the git repository. So if we go to the git repository, and we go to the CI CD repository, we can go to the stage branch. And here we have the seal it secret. So this cannot be decrypted by anyone that doesn't have the private key and the private key it's currently in the keep system name a space in our cluster. And with that demo is finished. If you have any questions, feel free to reach me out. That's it. Take care. Bye. I didn't see any questions on the chat but as I said in the video, if you have any questions, feel free to reach me out. Even if you're watching this in the recording, feel free to send me an email. I'm more than happy or well you can open an issue on the git repositories that you have seen as well. And I'm more than happy to help you. Thank you.