 Well, hello and welcome to another Dev Nation. We are here today to talk about Tecton, a technology that helps you build your components, your applications on top of Kubernetes. So as you know, we've actually had a trend over the last several months or the last several years of running the show. We love a lot of Kubernetes topics, we love a lot of Java topics, and today is going to be a Kubernetes topic where we can dive deep into a certain area. Today we have Kamesh Sampath with us. He is our expert looking at Tecton, and he's got a great demonstration that you're going to want to see. So definitely want to check out what he shows us live today in today's session. Of course, this will be recorded and be available to you, and as always, hit me up on the chat tab for throwing in questions and we'll try to answer them in real time. We may not have time for Q&A with Kamesh, but we'll definitely try to answer them right here. As always, remind your friends and neighbors, the best way to hear and see is to refresh the browser. Let's get started. So Kamesh, let's turn it over to you. Thank you so much. Hello, everyone. It's good evening. Good night. Good morning anywhere you are. I'm live from Bangalore talking about Tecton today. So I just have a lot of things to show to you guys. So I'll just make a very quick slide intro, and then I have put the slides on the chat so that you can take the slides offline and read them as well, plus the demo sources. And without no further delay, I just get right into the introduction about this particular topic on Tecton. I'm going to go there and share my screen up for you guys so that you can start looking at my screen. I'm going to share my entire screen up so that you can watch my screen. I hope, yeah, I'm right there. So the big link here, this can take you to the slides here so that I can go there and pull the slides down. It's always available offline. I keep updating the slides. And then obviously there are a few other things for you to read offline. So without, I just started to give you a very quick introduction about what cloud native CI CD is, right? So we have heard about cloud native application development and Burr and we have been giving a lot of talks around that. We've been reading a lot of articles in the back about what's cloud native application development is. So cloud native continuous delivery is quite close to what's cloud native application development is, but it's just a step before how do we actually deploy your cloud native application in CI CD way, right? The three main components that for cloud native, obviously you know that we need, everything is based on Linux containers. So everything we are going to do, even the cloud native CI CD is also going to be used containers and built for container apps and runs and Kubernetes. That's an important term that we need to understand here. And we also kept in mind that serverless is catching up the hot topic around and then we made sure that the cloud native CI CD is should also be using serverless in a way that whenever I don't run any CI CD, I don't want any resources to be used saving you a lot of cost and money. Since it's going to be cloud native, the cloud native CI CD should also keep in mind about what's DevOps. So we are going to say, DevOps designed with microservice and distributed teams in mind. So all these three are different factors make up what a cloud native CI CD should be like. On this line, I'm going to introduce what's Tecton. Tecton is the latest upstream project with Red Hat, IBM, cloud bees and all the guys are doing and it's governed by cloud native delivery foundation. It's a new project. It's Kubernetes native way of doing CI CD. As one of the things obviously, since you have been with Kubernetes for quite a long time and observed that there is no way that you can do a build or image build within Kubernetes cluster, you have to use some other way to push the image into your container registry and pull them from there. Obviously OpenShift, the enterprise Kubernetes was giving you the S2Y features where you can build and deploy applications. But with Tecton, we're making sure that even it comes for the even Manila Kubernetes and a lot of our Red Hat guys are doing upstream work getting this to perfection with all our experience around S2Y and how we do build image building with OpenShift as well. So the four main concept I want to introduce probably my last slide for this thing. Maybe you can have the slides later but I want to get into a demo soon. But I want to share a few Tecton concepts so that when I start demoing, you can understand what they actually mean. Anything within Tecton is kind of divided into these four blocks you see on my screen. The first one being its type. What I mean by type is that I can define my resources. One of the important thing with CI CD is that the two things which we take are from there which is basically the sources, the GitHub repository or any other VCS repository. And two what is what we make out of these, right? What we do with CI CD taking your application to production or making the application pushing into content registry. So that's what we mean by type, which is reusable resources. And we also have, we break down each of these tasks which is a smallest unit of work. We make them with step. Each task has multiple steps. You'll see the multiple steps, how do you build image. It can mount volumes, use any moment variables, et cetera, et cetera. So that your container builds are much easier and much smoother to do. And also like pipelines, you can also run the task individually but also you can group tasks together. We see both examples given in the demo. So we can also group this with pipelines. With pipelines, you make sure that the application tasks are grouped together and run a specified order in which you want to run. So obviously end of the day, we want to be cloud native. So everything is run as a container inside a Kubernetes clusters. So we need to have a way by which we need to run your pipeline or your task. Individually, that's what the task and pipeline are used for. So with this short introduction, I would straight away jump into doing a quick demo on how do we do this? So let me shift to my screen. I hope everyone is seeing my CLI. I'm just going to do a quick demo on this. So let's go to my editor. So I'm just going to build up a few demos. I have an OpenShift cluster basically. So this is a cluster which I have online in the cloud. So we're going to use this cluster to deploy my application. I already pasted my source code, which is from this, a simple Hello World application based on Java application, which says Hello World. So let's not worry about Java or anything. I'm just going to do a Java build. So I'm just going to have this. Yeah. Kamesh, we lost your screen share. So let's try to screen share one more time. It disappeared. Okay. So is it? Uh-huh. Let's start with screen shared, right? With the editor. Okay. I think it's dropped. I don't know why it's dropped. I think I'm just going to share my entire screen app. I hope you got me back. Yeah. Well, we see ourselves. Okay. So I think the presentation was good, right? I just need to start from here, I guess. So the demos, I think I said like, I start from the cluster which I have basically. So I'm going to have an, I have my OpenShift platform deployed with enterprise Kubernetes where I'm going to do all my deployments right now. It is deployed there available on cloud. And I shared this repository, which is a simple hello world application, Java based application, which I'm going to build. And this particular stuff, the link of this repository is already shared on the chat so that you can just go look at what's application looks like. And I have also made sure that I documented all the steps which I'm going to do right now on my demo so that you don't miss anything. In case even if you miss, you can come back and check these things and start running as well. And there are, without further delay, I'm just going to go to my editor and start doing this. The first step, as I said, like pipeline resources is something which we need to create. So I'm trying to rely on VS Code snippets and the snippets link is also part of the slides. You can just use add the snippets to your stuff. I'm just going to create a first thing. I call this as Git resource, a resource named pipeline resource. It's our type. This is what I mean by type. So it takes two parameters. I just need to give a name, which is basically the URL of your repository. The value is, I'm just going to say, sttpsgithab.com, the repository which I showed you right now. My repository is pipeline. Hello world, right? And that's the repository I have. And then I need to give one more parameter for this, which says, what's the revision I need to use? Obviously, I'm going to use a master revision. This helps you to change the revision whenever you do CICD. I'm just going to say master. Let me make this a little bit bigger so that it's easy to see the screen well. And again, I need to create one more pipeline resource. This is what I'm talking to you about, two watt. I got the sources. I'm going to build to what something is called. And just let me call this as a low world image. I am a GE. And then this is going to be off type image, which is nothing but a renex container image. And it also has a similar parameter called as URL. But let's see what this URL means here. It has a different meaning for this case. So in this case, the URL is going to be the URL of the container registry URL, right? That which you usually use. Since I said I'm going to use OpenShift, I already have an internal content registry. Well, I'm just going to copy and paste this. It's a long name, so that I'm just going to push this image into my local registry so that it's quicker and faster for the demo sake. And I'm going to call this image as hello world within my namespace called as tutorial. So with this first one, like we are ready with the resources. Next one, what you have to do is like we have to build the task. The task is basically the smallest unit of work which I said earlier. The task is going to have multiple steps. In our case, I'm going to have a task which is going to have three steps. Basically the first one is going to build your Java application. The second one is going to be build the container image out of the Java application which we built. And the third step is going to be like push this image into the container registry which is typically your internal container registry that I have here. So as usual, I'm going to go with my snippets, which I already have and then secrete a task. I call this task as build app and then build sources. And then I'm going to use a builder image. This could be any image you wish to use to build your application. In my case, I'm just going to use a Quarkus Java builder because this is a Quarkus based Java application. I just go in, I already have a builder here which I'm going to use. I don't have any commands but I do have arguments which I need to pass to this. And to tell it like where to go and pull run the script this is going to be maven run.sh which I already have in my Quarkus image. I'm just going to use this. It also takes two parameters. I'm just going to use the first one is going to be called maven, maybe EN, cmd args. This is going to be the maven goals that I need to run. So I'm just going to say fnd skip test. So I don't want to run any test, clean install. So these are the goals I'm just going to give for that. And obviously any given enterprise Java thing like you want to do a bit of caching of your maven artifacts so that they build up much faster. So I'm just going to give a maven mirror URL. In this case, I'm going to use a new notation that is specific for tectons where you can pass parameters. I'm just going to say inputs.params, params, dot maven mirror URL. I'll come back to who we define parameters in a few seconds. And then the last parameters that I need to give a working day are obviously we already specify the working DR, but my builder image is a bit old even before tecton. So I need to tell this back to go and take the application run from. This is what I need to give it. I'm just going to use the same URL as you saw here. We have some input parameters as well. So since it's going to be a Java build, sometimes you need to have more memory, less memory, et cetera. So which means that I'm going to have another snippet which defines my resources. I'm going to say the resources say, okay, I have a maximum limit of six GB for this particular container to run. It's four CPUs. And I'm going to give a request for a minimum of two CPUs and four GBs of RAM, right? This is something which I needed to do. The next step is that I go back and say, define a security context because my builder image run as a root user and OpenShift does not allow you to run as root user. So I need to give privileged leagd. So I need to run this privilege. That's pretty much what we have for this particular first step, which we are right now have. So I need to go back and say and add another step, which is basically I told you earlier that I need to start building the image again. So I just say go build. I just say I have another task step, which I define here. I call this as build image. And then I'm going to use builder. Builder is a kind of dockerless way of doing a container image building. I have a link to builder as well as part of the slides. You can just check it out builder later. And then it does not have anything else, but what I'm going to say to this is run builder. Build my docker file. That's what butt stands for. And then I'm going to use pass argument to layerize each build. And then I'm going to say, don't do TL as verify. That's what it means because I'm going to push it to internal registry and I'm using a self-signed certificate. So I want to ignore TL as verification. And then I need to tag this image, which is technically what I call this right now. Go to use another parameter here. Inputs.params.imagename, let me call this image name here. Once I have this, then I need to give us a docker file to build. Obviously, since most of the time we use docker file for easy container image building, I'm just going to call the same name as docker file. I have the docker file. I have this thing. And then I need to give it the context. Obviously, I'm just going to give the context. And let me grab, I'm going to give a similar resource to this as well, just to make sure that it's faster and quicker. And the last but not the least, I also need to give a volume mount here, will give you mounts. And then I save name. And then I give call this as badlipc. And then I give a mount path. This is the path that build up will be pushing. It's built image, which is nothing but a target ball end of the day, badlip containers. And then this is what I need to have. So this is pretty much I have for this step. And we just left with one more step, which we need to create is the last step of pushing the image back to the registry. That's what I'm going to do right now. I have build image step. And then I need to call this step as push image step. And then pretty much the same command I need to say push. And then I also need to give it what needs to be pushed, right? So I just need to have, I just tell this all of this off and then say, okay, I need to have a TLS verify as well. Otherwise my push will fail. I say TLS verify. And then I say Docker, since we built from Docker thing, it's the Docker format of open container initiative. I'm just going to skip those details further. Just imagine that we need to push it like this. And I have all of the parameters are pretty much same. One last, two more last things which we need to do. The first one is that I need to define the volumes. I'm just going to say volumes, U-L-U-M-E-S. And then the name I'm going to give this particular one. Since I don't have any storage attached right now with me, I'm just going to say MTDAR. And that's what it's going to take. And we are done with all the steps. The three steps are done. But one last thing if we need to do with the task is that I need to set these params up with the default values. And that's what I'm going to do right now. I already have a snippet that does this. I have a source. And then it's type git, which is going to be the thing which is going to be used here inside. And then there is an output which is going to be built image. And then the first parameter which we need to do is a context DAR. The DAR from where your build is going to run. So by default, I'm going to say this. And then I need to say the Maven mirror URL. I think I remember that we added this. So we need to give the mirror URL as well. And let me point to my local nexus repository here, which is here, which is running within my same cluster. I'm just going to give this here. And the next one I need to say is the Docker file, which I need to use. Let me go and pull this out from here, the image name. We're going to find another convention here for the image name. We know this image is going to be built from this one. That's output. So let's use that same URL which I need to have, which is your fully qualified image URL. I'm just going to say outputs dot resources. We see outputs dot resources. And then I say the built image dot URL. So that's where it's going to take the image from. And the last one is I need to set that Docker file here. So I say the Docker file, okay, the last parameter, which we need to pass. I'm just going to take it from the sources, src slash main slash Docker, Docker file dot jvm. If you're wondering what this is, if you go to my sources, I have a Docker file within here. src main Docker Docker file jvm. That's what I'm going to use. You can map it to any path within your sources as well. So with this, we are done with creating a task. And then now next task we need to do is like make this task run. First, we'll try to run it with just a task alone. And then finally we'll try to see if the time permits will try to create a pipeline and try to deploy using a pipeline with multiple tasks together. The first thing I need to do right now is go write a task run. The task run is used to run an individual task. And then I say call this as task run. And then I have the snippet which gets me to do this. And then I say build app is going to be the task run name. And then I put a dash and come back to that in a second. My task reference is nothing but this particular task which I just now wrote. I need to give a reference. And now you see that I need to pass some parameters here because I define some parameters, default values. I'm not happy with those default values. So I'm just going to pass some extra values to this. So I'm just going to say task input. If you see this is exactly, if you see this one and this one, this one pretty much same what you see here as well, right? So just be careful when you're writing it for first time, just make sure that these task inputs are on same line. And then I need to give something called as resource ref. And then name. So you'll be wondering what is this? This is how I'm connecting my pipeline resource to my actual thing which is going to be passed. This way, this is one thing Tecton is super exciting because I can plug and play with my resources. I don't need to have static resources attached to your build tasks so that I can change from production to QA, QA to different registry, different GitHub repo, et cetera, et cetera. I can have any kind of those combinations. So that's what we call as decouple and loose decouple and tight. That's what we mean in Tecton, all right? So and then let me in the same way, I also need to tell my image and just go with the resource ref. So that it uses this particular image here which I'm going to push it back. I'm just going to do the same thing here as well. And then that's two things. And I need to say one thing right here what happens is that now my build task is not reusable, right? So I'm just going to give a context here as the first parameter I'm going to say. And then I'll just use value. There's no default here. So I just need to take the value here and then going to say app. You'll be wondering what this context here is if you go to my sources, my Java sources reside within a directory called as app. So that's where you form XML, right? Which main and reason builds that is within the app. This is directly what I call as context directory here. So I give a context directory, but if you see I have hard-coded the main and mirror you already have which makes this build task not reusable across. Because in case if you don't have Nexus, then this will not work. So to make this thing change what I'm going to do is like I'm just going to make this as a parameter. I'm just going to say another parameter called as name. And I'll pass it from here, okay. And then I use this value here. I call this value. And then this one, the default value, I'm going to make this to look like not called as repo one dot main one dot odd is always there. And then maybe in two. In this way, what happens, your task now becomes reusable. It can give this task to your friends or anybody else within your organization who want to reuse the same build task with different set of sources or anything because everything you see in the task is pluggable. And then we have a bunch of tasks in the catalog here. I share these links as well in the tech. I'm just showing it for a second. We have a lot of tasks here which are the reusable tasks as well. We can plug and play with them. I will be using one of the reusable tasks in our next demo within a few seconds. One more last thing which I need to do here is that I have the app, I have this. What happens is now my task run can run many times. So we'll be running once and then probably it might be failing. I mean, we're running multiple more times as well. So to award this, if you give a static name, like what I've given there, what happens is that I will not be able to create it again. And I'm not going to revisit back and say what's problem happened, anything I need to fix. So I'll not have history or loss. So that's what I'm going to do right now. I'm just going to make use one feature called as generate name, G-N-E-R-A-T-E. And then what right now happens is that when I give this, what I'm giving it is when it creates this particular resource, it will suffix this build app and then it will also attach a five digit alphanumeric characters with this, which gives you unique ID for this particular thing so that you will have multiple task runs given there. So we're right now, we are good with the task line. So what we'll quickly jump to create these ones. Let me go and say, so I use something called as DKN. The link is there, DKN CLI, the CLI command line binary, which is used to kind of interact with your Tecton binaries. I mean, Tecton CLI is a way to interact with Tecton. So I will be using multiple commands here. I have the link to download this binary so that you can use this binary as well with your demos as well. So let me do this. So right now I don't have, I say Tecton task ls, which is a what our task I have. Sorry about the typo. I don't have any tasks. So I'm just going to see OC create. So let me see and just use the command here. I'm just going to create build resources, open ship client task. I'll come back for that in a second. Now build task which we have right now. And then we also have an app build task right now, which is going to create right now, right? Just have three things. I'll just make sure that I'm good with all the stuff here. So we have the mount parts, we have resources, we have volumes, map, everything is done. We also have the Tecton task run here. And then I have reference resource, reference name here and passing the parameters which I need to have, right? So this is good here and then let's go there and then fire this commands. And then you see this is what I was talking to you about. Each task run will have a unique name, right? So just to see the logs, how do you refer whether this task has done? Let's say TKN, TR is task run and then I say LS. Now it takes fail. Let's see what happens to this. We'll see describe TR slash. Now it says that, okay, I have privilege, I'm using privilege container, but I don't have privilege permissions given here, right? So which means that in Kubernetes way, let me go back to this error, which says that you don't have something failed here. The problem is that in Kubernetes, everything runs with a service account. What I have done is that I have a service account already created for pipeline, which has necessary permissions. If you go to my example repository, it defines what permissions you need to be given in there, right? So I'm going to go there and then say, okay, use the service account. Let's see, R, V, I, C, E account here, and then P, I, P, E, L, I, N, E, that's a service pipeline account here. And then now when I go and create this task again, that's what I'm going to do right now. O, C, create dash F, and then doing this, right now we'll get a new ID, you can see this. And then this way, like you have multiple tasks and then when I say TKN, TR, LS, TKN, TR, LS, I'll be having one task and another task is started to run. Let's see how to see the logs. This is the next step I'm going to do, TKN, Tasker and TR is a Tasker and Shortcut, TR, logs, follow, and all the containers because you'll be seeing there'll be multiple containers which gets created here. Right now it's going to show you all the logs. It started to do the build right now. While it does the build, we'll also go and create a pipeline, right? So the one of the things right now with pipeline is that just creating this build, pushing the image to container registry is not going to help me in any way. So I need to have a way by which I push this image and create a deployment, right? I'm going to do a pipeline here for the, I think I'm running short of time. So probably what I'll do is like, I just go to copy the pipeline from here, SRC. Okay, I have it here. And then I say I have a pipeline deploy. I just copy paste this one here because I need to respect the time. And then I have the pipeline here. So which is going to say, run this command for me now and then create a deployment as well, right? So in this case, if you see, I'm using another task, two tasks here in the pipeline. One is called as Deploy App. And then I'm going to use OpenShift Client, the OC Client, which you saw in my command right now. I'm just going to use that right one there. And then I have few other parameters. This is a pipeline CRD, which I define. I have your resources here, which is set. And then finally it deploys. If you see this, this is going to create a deployment for me, right? Not rolling out a deployment. I'm just doing it a very crude way, but usually we'll have the deployment YAMLs, which is trigger the deployment YAMLs firing and all this stuff. So that's how we do this. And it also what you should also see this, this particular Deploy App runs only after I build the application. So this is one of the things which you can do with pipeline. I can define my order in which my task needs to be executed. You can imagine a pipeline like multiple tasks runs together. So that's how I'm going to do right now. Let's go and create this pipeline and also like run one more time as well. So let's see what happened to my thing. You see here, so I have my task run TK and TR LS. If you see this, we have, we should have one failed one, which we saw earlier and we should have one, which one succeeded right now. My task run has succeeded. Right now I'm going to go back and then say OC create my pipeline, create dash F, App Deploy, right? And then when I say TK and pipeline, PI, DL, NELS, and then when I say this, this should give me the pipeline which I just created, which should be called as App Deploy, right? Now I'm not going to use to run a pipeline. There is another way we can start. That's what I'm going to use. I'm just going to copy this command for the sake of time. I'm just going to copy this. And then I say, okay, if you see here, I'm just going to create this pipeline and this using TK and CLI to start a pipeline. And then I'm passing some parameters. See if you put TK and resource, LS, we have two resources which already created. One is called as a gift resource and another one is called as Hello World Image, right? If you go to our pipeline, I have two resources, App Resource and App Image, which I need to map, which gets mapped here. And then the moment I start to do this, what happens is this application gets created and it gets mapped. So I'm just going to use the same thing. And the moment I start this, I should have a new pipeline created. Let's wait for some time. And then TK and PR, LS, which is pipeline run, LS, it says running. And I follow the pretty much the same way to see the logs, CLS, TK and PR logs, FNF, FNA. The TK and help will give you all these options. Just follow on all containers because if I say, cube OC get pods, dash W, if you see this pods, this deployment has seven containers in it. So I need to get the logs from all the seven containers. That's what I'm giving the option dash A, which means that get the logs, follow the logs from all the seven containers. So we see the pods getting initialized right now. We'll give some time for this to run while it runs. I will also probably can take few questions if we have you. Yeah, we are down to just a couple of minutes left. One question that came up early though, Kamesh, was what YAML plugins are you using for your VS Studio code? People like this? Yeah. So this is the Red Hat YAML plugin. So we just contributed by Red Hat YAML plugin. If you go to VS Code Marketplace and then type Red Hat YAML plugin, you'll see the plugin which is there. And then the snippets, I already have the snippet shared as part of the slides. The slide resources will have the snippet links. Once you get the snippet links, you can add it to your VS Code plugin so that it can give you what all the, I mean the command completions which I actually done with my YAML creations. Okay, yeah, now if you have that link to your snippets, go ahead and add that to the chat, if you don't mind. Okay, and I'm just going to do that. Yeah, I'm just going to do the right away there. And then I'm just going to put that here. And then there we go. And let's see what's the status of my task run. I think we have done with the build. Let me quickly share my screen with the one minute I left to show the deployment happens. I think I hope you got the screen back. And then if I go here and you see this deployment has been created and then the task has been completed, you see this on my screen, which says the deploy app OC in this way. And then let's TKN, PR, LS, and then see the task has been deployed and has been succeeded. So in this way, like pipeline is used to combine multiple tasks together so that you can have stitch multiple tasks. The tasks not necessarily need to be from your own application. It can also, as I said earlier, it can also come from these tasks which you need to pre-install. As we did in our case, when you observe the first command, I install the ownership task. Let me do this TKN task as one last time. You see this ownership client task, which I installed when I did this create dash F earlier, if you remember. Okay, I don't have this in my history right now. So we need to create the task. Once you have the task to your TKN library, then you can use this task like how I did here. In my example, I just use the ownership task and each task will define some parameters. I just need to pass the parameters and that will go. So if in this case again, so I'll also try to see, but I think I'm running out of time, I guess. I think I can also expose a particular staff, OC, expose allowable deployment. I have the deployment exposed and then OC expose SVC allowable so that I get the route. And the moment I do this, if you go to your ownership console and networking and routes, I have exposed this application and there you go. This is your application, which is a simple allowable application which we built. So we did everything within the cluster, no pulling images. We are using the internal registry here, using Tecton pipelines and tasks and pipeline resources to do all the task burning. And that's pretty much I have for today, Bird. I think over to you. Okay, we are out of time, but two quick questions. One is someone would love to know exactly how you can figure your theme in your shell for iterm2. Okay, all right. Okay, this one is using something, I'm just going to TMAX config. I have my TMAX config here. So I'm just using a TMAX console and just putting that back on the chat. So I just use TMAX configuration from here. That's my TMAX config. And then I use iterm2. I just update, I think this item got a new look and feel a couple of days. I mean, last week, if I'm not wrong. So I just use this and then map these iterm shortcut keys to my thing. For example, if I need to create a new tab, I just use new tab here. They still create a TMAX console, but the keys are registered with your iterm, right? It's using this, there's a way I can make it into the key maps as well. All right, we're very cool. We are out of time. Thank you so much for that, Kamesh. It was awesome to see all that live demonstration. I know people got a lot out of it, got a lot out of the session as well. Do be ready for the recording. We'll send the information out soon. You can check that on YouTube or on this platform also. And then thank you guys for your time, Dave. Thank you, Kamesh. Yeah, thank you, everyone. Thanks for your time. I'm sorry to take two minutes extra for you. Have a good day. Bye-bye.