 Welcome everybody again on DevCon 2022 and I would give you a word for Savita. So, here you are. It's time to drink water. Hello. I hope I'm audible. Okay. Hello everyone. Welcome to DevCon 2022. I hope you guys are doing good and today we are going to talk about inspecting Kubernetes native CICD with Tecton. A little bit about myself. So, I'm Savita Ashram, a senior software engineer working at Red Hat and based out of Bangalore, India. So, you can find me over Tecton Slack, Twitter and LinkedIn. So, in today's agenda, we are going to see a brief about CICD and different CICD solutions we have, basic differences of Tecton versus Jenkins, then the high level overview of Tecton, different projects of Tecton and then we will go in depth about Tecton pipeline and Tecton trigger stuff project to know more about their concept and what are the different resources they support. And finally, we will execute a simple demo to write, I mean, executing the CICD pipeline manually and then automatically based on some detail events. So, this is how my high level agenda looks like for today's talk. So, now let's see the brief about CICD. So, before I go to a technical word about CICD, I just want to give a real life example which I feel myself. The reason is whenever I go to bed, I mean, before going to bed, I used to turn off the lights, PV if it is on and I play some relaxing music so that I can get a peaceful mindset. So, I feel sometime that I should have something automated all these operations so I should not spend like 5-10 minutes to do all these things. Instead of that, I could have got some remote control mechanism so that by sitting in one place, I can do all these things. So, this is really cool, right, if you get something like that. So, my point here is all of us want the automation everywhere wherever it requires some manual intervention. So, similarly, in software field, we always value or respect to the work which we do automation. I mean, any one of us don't want to do any work automatically, repeat it your time, right? So, in that case, we prefer automation for everything. So, CI is a continuous delivery and continuous integration and CD is a continuous delivery or deployment which plays important role in the software industry. So, basically, if I talk about CI, it's just a software deployment practice in which incremental code changes are made frequently and tested. Whereas, as part of this CD, that code is delivered quickly and seamlessly so that we can test it properly before making sure that everything works perfectly. Now, I want to just brief about those things in a diagrammatically way. So, I have a very general scenario where I will clone the source code and I do some operation on that source code. I mean, by sending the feature, doing some bug fix documentation. So, whenever I do some pull request to that source code, I feel to do building the code to make sure that I don't break it and then I do some unit test and e2it test to make sure that there is nothing breakage. So, this we do continuously every time whenever there is a change in the source code even if it is small part of it. So, we do this continuously. So, we call this part as a continuous integration and we write as a template for the automation and make it as a CI to run it whenever there is a change in the source code. So, this we call continuous integration and once we do this operation, we try to deploy our source code and try to test the functionality and we call that part of as a continuous deployment. So, this is how our general high level CI CD looks like. Now, let us understand the different CI CD solution available today in the market. So, I have listed very few, there could be many. So, the different types of CI CD are listed over there. Some of them are popular, some of them are not popular. Those we can use based on our use cases. So, today my focus is on Tecton and one point I want to state here is that the agenda of this talk is not to say that Tecton is good CI CD solution. Instead of that, I just my motive is to say that one of the solution for CI CD is Tecton. So, now based on the use case, we can use Tecton, we can use Jenkins, Circle CI. It depends on us and on our use cases. So, now before I go deeply into the Tecton, I just want to compare Tecton with highly usable CI CD solution which is Jenkins. So, here is the high level differences. I found it and I have written it here. Maybe you can read it if you guys are interested to know more like why Tecton we need to use, why Jenkins we need to use. So, this is the high level differences I have written it here. Now, let us go deep dive into the Tecton and see what is Tecton, why Tecton and who uses this Tecton and how it got started. So, basically, Tecton is a Kubernetes native open source framework for creating CI CD systems. And it helps us to do a end-to-end operation across multiple cloud environments. Then why Tecton? Why should we use it? So, I would say that if we have an application which is cloud native and which is always deployed on Kubernetes, I would say Tecton would be easier to integrate as a CI CD solution because it is very native to Kubernetes. And with Tecton we can achieve scaling easily if you want to increase the workload we can just add node to our cluster. So, this is how we can find useful Tecton in these kind of scenarios. Then who uses Tecton? Like basically the developer and the platform engineers who build CI CD for their organization. And coming to like how it started, how it got started. Earlier, we had a KNATU build project as part of KNATU. Later, it got separated from KNATU and that build project entirely got created as a separate project. We call today it as a Tecton. And initially it was started by Google, Red Hat, IBM, POTL and later many more companies started contributed. And now the Tecton is given to a CD foundation. So, this is how this is about a bit of overview of Tecton. Now let's see different projects available in Tecton today. So, we have a very popular one which is Tecton Pipelines. So, it basically provide a resources, K-test and resources for declaring the CI CD pipeline. And we have a Tecton trigger projects. So, it basically helpful to trigger those pipelines automatically based on some events. It can be from different different sources. And we have a command line tool called TKN which helps us to interact with Tecton components. And we have a dashboard which is a graphical interface to view and interact with the Tecton components. And we have a catalog. It is a project which keeps the task which can be reusable. If I give an example, in Jenkins we have plugins, right? Similarly, in Tecton the catalog project maintains the task which can be reusable based on our use cases. And then we have a hub. It is a graphical interface for the catalog project. And then we have an operator. Operator is basically help us to install, maintain, manage, upgrade the entire Tecton projects. And today, operator basically help supports the installation on Kubernetes and OpenShift platform. So, now we saw different, different sub-projects which are there in Tecton CDR. Now, let's just go bit deeper inside few projects called Tecton Pipeline and Tecton Triggers. So, we understood till now the purpose of Tecton Pipeline project and why it is. Now, let's understand the basic resources which are required to create our CI CD pipelines. Now, when I say resources, I just want to compare to the well-known Kubernetes resources so that it is easy to understand. So, in Tecton, like in Kubernetes, we have pod deployment services. In Tecton Pipeline also, we have a custom resources which is very specific to Tecton itself and that to pipelines. So, we have a step. This Tecton Pipeline has a resource called step which is very similar to a Kubernetes container. It means this step internally runs a container which takes some information like ENV, volume, etc. And we have another resource called task. If I compare with Kubernetes resources, task very exactly resembles to a pod in a Kubernetes world. So, task is basically an entity which contains multiple steps that run sequentially. And we have a pipeline which is again an entity or object in Tecton Pipeline which contains multiple tasks and execute those tasks in a certain order. Now, this pipeline, if I compare with Kubernetes resources, it's exactly similar to a deployment in Kubernetes. So, if I tell about the hierarchy, a pipeline is an object which contains multiple tasks and task is an object which contains multiple steps. Now, when I say pipeline contains multiple tasks, that means there should be a mechanism that a one task output is given to another task as an input. So, to handle that operation, we have an objects called results and workspaces which do very well input and output operations. Now, this task and pipeline are just a static template. To run these things, we have a runtime entity called task run to run the task and pipeline run to run the pipeline. Now, we just understood the theoretical thing. Let's go and see diagrammatically like how it looks like. So, I have a scenario where I'm cloning the code, building it, building the image and pushing to the registry and deploying it. So, I have separated it out in a multiple steps like clone, build, push and deploying using the OC which is applied to deploy it on the open ship. So, now I have divided into multiple steps and you can see different, different level I have divided. I'll tell like why I have done this way. So, now let's see one more resource called task. So, task fetch contains the step clone. A task build contains these three step operation and the task deploy contain the step called OC to deploy the image. Now, you can see like why I have divided this. Instead of this, I could have combined this and written as a single task, right? But I want to give one more scenario where I have two languages, one is Java and one is Go. So, for Go and Java, the cloning is same and deploying using OC client is also same, but building operation will differ. I mean, Go has different steps to build, Java has different steps to build. Now, if I want to do CI CD for both Go and Java, I need to write similar steps for multiple times if I have a one single task. That's the reason I have divided into three different tasks so that I can reusable this task fetch and reusable this task deploy for both different languages. And I can do some bit changes in the build task so that I can use for Go separately and Java separately. So, that is why we call in tecton task as a reusable entity similar to plugins in Jenkins. So, now these tasks are dependent on each other. I mean, deploy dependent on build, build dependent on fetch. To run these tasks individually, we have an entity as I said earlier, we have a task run to run those things. Now, let's suppose I want to combine this everything and run as a single unit. I can write a pipeline for this and to run that pipeline, I have a pipeline run object. So, this is just a high level diagram. Now, let's see this thing in action. So, by executing like I will have a three task git clone, which will clone the code and put it in one of the storage. And then another task called build up, which will refer that storage and get the code access. And then finally deploy that code and this entire thing I call it as a pipeline. Now, let's see these things in action. So, let me go back to my this thing. So, before that, I will show one point here, like I have a repo, I have kept everything ready. So, the prerequisites are cluster and for time being I have installed tecton and everything I have given step here. And even I have created a dashboard I given every steps here. So, if someone want they can refer it from here and my dashboard looks like this. So, there are no resources. Now, let's go on to try it out the example. So, I have already cloned the code here and now I will create a name space called demo. And then I will create a secret because I am doing push operation. So, it requires the access to my registry. So, I am doing creation of that. So, I have done in another terminal because it exposes a password. So, you can see secrets in the demo name space. And then I have mentioned in the project representation that I have a three task. So, I am just straight away using the task from the catalog repo. So, which are there here and the graphical view of that catalog repo is hub. I can directly take it from here and I can make use of it. So, I am just cloning this thing and we build that task. And then we cloned task to clone the code. So, now I have ready with all the tasks and I will do get operation on those tasks to make sure I have everything. After that, I will create a samples which contains some service account roles pipeline pipeline. Now, before that, I just quickly show like how it looks like. So, you can see that this service account contains some credentials that role role binding some permission to deploy. I mean the apps deployment and everything. Now, this is the important one I want to show which is pipeline. You can see kind pipeline is a resource. As I mentioned here in the presentation that I will have three tasks and they are dependent on each other. So, I have a task called fetch, I have a task called build, I have a task called deploy. And this fetch, I mean this build is dependent on fetch and that can be indicated by run. It means this build run after the fetch task. And similarly for deploy I have given build which is run after the build. So, this is how the tasks are dependent on each other and they execute. And then I will have as I said pipeline run is an entity, runtime entity which runs the pipeline. So, here I will give information about my repo and the image where I want to push it. So, the repo is this one. So, let me create these resources here. So, you can see I have started creating it. Once I create it, a pipeline run will be executing. I will show here you can see of six seconds ago. When I go inside this pipeline run, I will see three different tasks. And each task, the different different steps. Now in the fetch it is doing clone code. It has not yet started, that's why I get unable to fetch the log. But now when it started, it will show the logs. So, it will take some time. Before that I want to say that this is how I done the normal creation of my CI CD. I mean it will build and deploy it. But I want to do it automatically. Means whenever there is changes to some changes to this repo, I automatically want to build the code. Push the image and deploy my code so that I can test it. So, to do that we have a project called tecton trigger which is another entirely independent project. I mean entirely different project in tecton itself. So, this trigger helps us to do that automation, I mean automatic deployment of pipeline. So, if I want to show diagrammatically at high level, so till now we saw this right, I mean entire pipeline. Now to trigger this entire pipeline, I will back up with trigger. So, basically this trigger do that operation of building. I mean executing that pipeline automatically with some events. Now let me tell, I mean it is for time being if I go in depth about each of every resources of trigger, it will take time. So, I would refer to if someone interested to know about this trigger, go to tecton CD trigger official documentation. We have proper documentation over there and how each of the resources are there. So, to understand at high level I want to say that like kind pipeline run, we have a kind event listener in trigger. What it will do when we create that object, it will create an event listener pod. It is something which continuously run and watches for event. This event can be from GitHub, GitLab, Bitbucket or any other sources which we can refer. Whenever there is an event comes right, this event listener pod gives information to trigger and the responsibility of the trigger is to make sure to give it to the interceptor to validate whether the event is coming from the proper sources. And then we have two more entity called trigger binding and trigger template. So, basically this trigger binding will fetch the resource information like from which Git repo, from which branch, all those information it will fetch and it will give it to the trigger template. And this trigger template have the pipeline run object itself. I will show in ML. So, that pipeline run will be triggered and it finally create that tecton resources. Now, let us see this thing with demo. So, let me go back to my repository and before that I will show that this pipeline run previously which we ran manually, it is success now. So, let me create a tecton trigger objects. So, I will create, this is a tecton trigger object. Okay, sorry. Yeah. So, samples is here. Yeah. Tecton triggers object. So, I will create it here. So, once this is done, I will get an event listener object. Okay. So, you can see an event listener object. And as I told in presentation, I will get, this will internally create one part. You can see 10 second ago. So, let me do a watch on this part so that I can see events coming to this part. So, yeah. Okay. I will keep on watching on this part. And the next step is to create a ingress so that I can access it easily. Okay. So, let me create the ingress object for this. So, I will create the screen so that it will easy to view. So, I will do get on ingress to see what will be the address so that I can access it. It will take some time to get the address. So, once I get the address, I can do curl request. So, when I do curl request, I should able to see some events coming to this part. So, I hope it should come early. I will take some time to get the address. So, yeah. So, meanwhile, I want to tell is like once this is done. Okay. Before that, I will show, I will go and show how the trigger template looks like so that it can create the pipeline. So, you can see trigger template is an object which has embedded this pipeline run. So, that is what I showed over here in the presentation that when there is an event come this trigger template create this tecton resources. So, now here. Okay. So, I got the address. Right. So, what I will do, I will go here and I will send some request. So, you can see I got some response and event in the part, but it failed because I have not passed any body format. So, it straight away rejected. So, now let me configure it in the web book. So, let me open settings. I will copy this URL. Okay. So, yeah. So, in the web book section and in the add. Okay. I have added something. I will delete it. Okay. And the book and then here I will give the URL and it always refers to the content type. And this is the secret which helps to validate whether the event is coming from the proper source and I am interested in pull request not on any other event. So, I will just select that and add the web book. So, once I do this one, I will go for time being I have already raised some pull request and kept it. So, before that I want to just show like I am interested in pull request. You can see this is event listener object where I have given information like I am interested in pull request and that especially when pull request is open or reopen or synchronize on these three events. So, let us see that there are no more events coming to this. What I will do? I will close this pull request. So, when I close this pull request as I have selected on pull request event will come but again I am segregating it to the only three open reopen. So, now let me reopen this a successful event occur on the successful event it just created another pipeline run. So, this is how I can automatically schedule my pipeline based on some event to my GitHub repo. That is all from me and you can find us on Slack channel and there are regular meeting and all Tecton project repos are listed over here and documents are given here and I have given the demo link demo link where I have stepped the step and yes welcome to Tecton and thank you. Any questions would be welcome. Yeah, I can see here just one question. Probably you can see it as well in the Q&A session Q&A. Okay. In your experience it is best to have one CI series solution or a tool for each one CI and one. Okay. So, in my experience I would always prefer to have one solution for both CI and CD because it will ease our work but if you have a use cases where you want to handle some complex scenario where you can't do with one tool you can go for different solutions. Okay. I cannot see any other questions so thank you very much for the presentation.