 So let's get started with this presentation, part of a cloud and pipeline. So I'm guessing or assuming that most of you have probably heard about CICD by now. It's this concept that helps you to release faster and faster and deploy your applications faster and more reliably. So most organizations nowadays have pretty much adopted CICD as part of their core business processes. Now, today I wanna show you how you can integrate your CICD pipelines directly inside of your Kubernetes cluster. And this can be done with Tecton. Tecton is a cloud-native CICD framework that uses tasks and pipelines to build and to build your CICD pipelines. Now, I couldn't help, but I was like, oh, clouds and pipes and I decided to do a Super Mario Brothers theme talk because, hey, why not? You know, might as well have fun if we're learning something new, right? Okay, so I'm gonna talk about Tecton today. This is really the focus of my talk. Just before I get started, let me just find my window. All right, and let me get out of the way. There you go. So hi, my name is Joel. I am based in Ottawa, Canada. I'm French Canadian. That's the charming little accent. And that's also why it's Joel and Joel. So I work as a developer advocate for the Red Hat OpenShift platform. And if you ever wanna get in touch with me, if you have any questions about Tecton, about CICD, about OpenShift, Kubernetes, or just about Canada, why not? The easiest way is always reach me on Twitter. So that's Joel with two underscores. It's like the worst Twitter handle ever. But yeah, Joel underscore, underscore, Lord. Easy to find there. And I usually answer really, really quickly. Also, if you enjoyed this session, feel free to tweet using the hashtag defconseeshead. Let people know that you're here and that these events are, even though they're virtual, they're still happening and people are there and attending. So feel free to use those. That's the easiest way to reach me. Okay, so I'm gonna super mirror your brother rules. Yeah, I'm kind of old school. I'm also monitoring the chat somewhere right here. So if you see me kind of looking at my screen there, that's what's going on. So if you have any questions, feel free to just ask them during your presentation. And I'll try to answer them or I'll just let you know if it's addressed later on. So CICD, what is CICD? Just in case you haven't heard about it, it introduces ongoing automation and continuous monitoring throughout the lifecycle of apps from integration and testing faces to delivery and deployment. So basically it's a way just to, which I do have a picture here, it's just a way to make sure that you're continuously building your application, making sure that it's running all the tests that it needs and that you can create those images and that you can deploy those easier and faster and more quickly and more reliably to your servers. It's also great to build those images as you're working and as soon as you can. So as soon as code is merged, that you don't have merged conflicts and it helps with if you need to show some of that content to your product management team or to your customers or if you need to share that with a QA team, making sure that you're building faster and quicker and regularly really helps with sharing that information. So continuous integration, when we're talking about that, usually it's the automation process for developers. It's usually what happens or what can happen on your local machine. I'm a JavaScript developer. That's what I've been doing for years now. Sorry, no Java here. But yeah, so I run all of those tests and as part of my application building processes, that's kind of the continuous integration part. But it really helps with the merging and trying to merge that code as often as you can into the Git repository and it helps to avoid those conflicts. When we're talking about CD in the context of CI CD, CD can either mean continuous delivery or continuous deployment. Let's not be too picky about the vocabulary here, but generally what we're talking about is about the further stages of the application or of the deployment of the application. So can you just delivery is really when you're trying to build that image and then continuous deployment is really when you push that image into the server. But they're both, often time, I've referred to as continuous delivery. Or continuous disaster, I absolutely love that and I might steal that from you, Pavel. Thank you. All right. Now, Tecton is a cloud native CI CD solution. So what does that mean exactly? Well, actually, cloud native means a lot of stuff. Like it's kind of overloaded and it took me a while to actually understand what it means. Like there's so many potential definitions, but in the context of what we're looking at today, in the context of CI CD, really what we're looking at when we talk about cloud native CI CDs that those are applications that will run in containers. I think that they're kind of self-contained inside their container, they can be deployed, they can be and everything will run inside of a container. So all of your pipeline, all of the operations that are happening during your pipeline or throughout your pipeline will happen inside containers. So that makes it more reliable, more reproducible so you can get a lot of more out of it. We're also talking about serverless, not in the sense of AWS Lambda or Azure Functions, but more in the sense of no central place to manage all of your pipelines. So really we're looking at not having one person that is responsible of managing your bamboo instance, for example, so maybe being able to make it available to all of the developers inside of your system. So that's really what we're talking about when we talk about serverless in this context. And DevOps, making sure that we have DevOps practices built inside of it. So once again, it's kind of similar and has a little bit of overlap here, but just making sure that the developers can be in charge of their own pipelines and maintaining them so that they can actually take care of all of that without the need for an upstream. So this is where Tecton comes into play, it comes in here to help us. And the vision of Tecton is real to build this system of pipelines which are composable so it uses different building blocks to create those pipelines. It's declarative, we're using YAML to describe all of your files. It is reproducible as well. So because we're using containers and because we're using composable tasks so we can use those tasks and reuse those tasks as well. And it's also cloud native. So everything is built with cloud native in mind. All right, so let's get started. And the old schools, old school people like me will absolutely know what this image is, blowing into the nest cartridge. All right, so let's get started. And for this presentation, I want it to be a little bit more hands-on. So I'm actually gonna build some tasks and we're gonna try to deploy that. Of course, we never know how it's gonna work. Live demos, right? But hopefully I did my sacrifices to the demo gods this morning and it should potentially maybe work. So we'll see. So getting started with Tecton, the first thing that you'll need is some Kubernetes cluster, some sort of Kubernetes cluster. If you have OpenShift, that's great. You can use it with OpenShift. If you're using OpenShift though, and I just wanna mention that there is an operator that is available to you, which is called the OpenShift Pipelines, which is built on top of Tecton, kind of the same way that OpenShift is built on top of Kubernetes, right? So it kind of gives you Tecton on steroids. For this presentation, I'm gonna use Minikube. I'm not gonna run everything locally. And then you need to install the Tecton CRDs. It's relatively simple, relatively painless process. There is one line that you just can copy from the documentation. It installs everything for you and then you're ready to go. And we'll use the TKN CLI tool. Technically you don't need to use it, but it really, really makes it a lot easier to manage your Tecton pipelines by using it. All right, so the links are there. I'm gonna share all the links at the end through one single link. But yeah, Minikube, where you can find it and the Tecton CRDs and CLI in the Getting Started Guide from tecton.dev. All right, so the first basic building block that we can use for building our Tecton pipelines is called a task. So a task is just one thing that you want your pipeline to do. And in here, what we're gonna do, right? We've got this Super Mario Brothers welcome screen and we need to push start. So that's what our task will be today. So that's, I'm gonna take some kind of basic examples, but you'll see how we can build on top of that eventually. All right, so if you wanna build your own task, this is pretty much what you'll do. It uses the same syntax as any Kubernetes object. So API version, it uses tecton.dev slash v1 beta one. Yes, it is still in beta. It actually recently came out of Alpha into beta. So those, well, recently it's been a few months, I guess already, time flies. We're gonna create an object of kind task. We're gonna use some metadata so you could put in some labels so that you can find those throughout your cluster. We're gonna give it a name and this name will be called star game. And then we have our spec and in our spec, we have a bunch of steps. So steps are different operations that you're gonna perform. Each step is executed in their own container. So you'll see here, you'll recognize here the syntax, which is exactly the same syntax as you're using for your images inside, or sorry for your images inside of your pods. So your task runs inside of a single pod and all of your steps will run into inside different containers. So let's take a look at what this actually looks like and I'm gonna make this a little bit bigger because I'm seems like it's not very large. There it is. And let's open up a code editor and here it is. Where is it? Okay, oh, it's hiding. Oh, no, there it is. Whoa, okay. So it's creating a new file. Why is it, it's touch1.yaml. And let's see if I can bring my, while I'm off for a good start, right? That is not what I want. I'm almost there. Please bear with me. And new file 1.yaml, I know you can't see, don't worry. Just gonna do that, bring it back. And I need to cheat, I need to have another one open here. And okay, I'm almost there. Oh, come on, really? This is killing me. Code dot. Okay, so, where is my other editor? Boom, there it is, perfect. So we're gonna create our first API version. So tecton.dev, as I've mentioned, v1 beta one. And you can install the tecton extension, which is great. It lets you build, like you can use a lot of syntax and it will check for syntax and all this stuff. So we're gonna build an object of kind task. Some reason I can't get it to the auto completion metadata. So I'm off for a good start. This is not gonna end well. Okay, name, start game. So we're gonna have our first task. It's gonna be called start game. We have our spec. In our spec, we're gonna have a series of steps. And that's the only required element for your spec inside of your task. And in here, we'll have an array. The first one will be called press start because that's what we need to do to start Super Mario. And we'll use, we'll use the image alpine, alpine, 3.1. 3.12, I think it is. See, that's why I have this outer array that are. Okay, our command. What do we do once this container starts? We're gonna run slash bin slash SH out of habit. I do bash, but SH for alpine. And then the arguments that we're gonna pass dash C and then echo, I guess we'll just say starting game. Starting game, okay. So just a simple task. The only thing that it'll do is that it'll just echo something out there. So this is saved now. So I now have my TKN tool installed. Before I actually use that, I'm gonna need to apply this file. So QCTL, apply dash F1.yaml. And there it is. So it did create our first tasks. So that's good. And now that we have our task, we can do TKN task. TKN task, TKN task, LLS, to see the list of tasks. So we can see that we've got a start game task. It's 15 seconds old. So that's all good. So I can actually use TKN task start to actually trigger that task. And it was called start game. There it is. And it started. Of course, I always forget the dash dash show log argument. And I'm too lazy to copy and paste this. So I'll just do show log. So now my task is started. It actually created a task run, which is the actual execution of the task. And this one runs inside of its own pod. It starts a container, which has the Alpine image. And while it does that echo statement, it actually ran faster than it took me to actually explain what's going on in here. So you can see that it's really fast just to get that image up and running and to echo that statement. So that's what we needed to do for now. Cool. So yeah, level up. So we just managed to do our first task. So it was kind of a hello world-esque example, but still, we've got something. So let's see those steps. And as I mentioned, you have all of those steps and you can reuse those steps or you can have more than one step. And that's typically what would happen inside of your task, right? If you need to run a task to run some tests, well, first of all, you'll need to install the dependencies and then you'll need to run a test suite. So that's two different steps. So let's see if we can do two steps. So when you open up Super Mario, once again, the first step is to press start and then you need to select the number of players. So that's what we're gonna do here by adding a second step inside of our task, sorry. So in here, I'm just gonna take that same task but I'm gonna add the press start and then I'm gonna add a select player step, which is just gonna echo something again. We're just kind of faking something here. So why don't I open up my code editor again if I can find it. Let me just create that 2.yaml file and where is it? All right, so I'm gonna start with this. I don't know why this doesn't work anyways. 2.yaml and we're gonna add a first step here. So the first step will be select player, so players, I guess players, plural. And then we're gonna use an alpine image again. So oops, image alpine 3.12 and command. It's gonna be very similar slash bin slash sh and we're gonna take some arguments and I know that you're all hoping that I'm gonna fail. If you miss yes, no style flags, which shell commands and idea could be to define an alias that already contains a flag. Yes, that's actually a very good idea, Eric. I should definitely do that. It's actually very smart. Selecting players, okay. Also I'm glad that at least one person is paying attention. All right, QCTL apply dash f2.yaml. This will overwrite original tasks. So it says configured and instead of created because I've reused the same name and now I have TKN task LS. I can see that my task was created three minutes ago, but it's not changed. So I can now do TKN task start, start game. And all right. So I can't help it. All right, there's three people paying attention. All right, show logs. Yes, okay, so far so good. So selecting players, starting games and that seems like this is working. So you can see how we can build on top and create those different steps. Interesting fact, the task will run until all of these steps are successfully completed or one fails. So they will be executed one after the other. So this is what happened. Each one of those has been executed in their own container as well. Okay, let's make it a little bit more complex. Let's add parameters and let's see who knows what this screen is out of curiosity, bonus point if you can figure it out. So let's add parameters to our task now. So one of the goals is to make sure that we can make those tasks reusable as much as we can. If you have a get clone task you'll want to be able to specify the repository so that you can reuse that get clone task in all of your different pipelines. You don't have to reinvent the wheel every time, right? So this is how you will make your tasks more reusable. You'll use parameters to do that. So in here what I'm doing, I'm adding inside of the parameters section. I'm adding a parameter that will specify the number of players and then I'll be able to inject that value inside of my container. So I'm gonna use parameters to our players to display the number of players that we've specified in our parameter here. So code editor again, where are you? There you are. Let's add this extra file three.yaml. We're gonna start from the same task again and three. Okay, so in our spec we're gonna add some parameters. And the first one will be a name, players. Nope, just players, thank you. You can add a description. That can be useful, especially if you're using the command line. We're gonna see that in just a few seconds. So number of players. Pavel, I think you are correct. That screen was the game genie. Default to one player and this will be of type string. So you need to specify the type is either a string or array. And yeah, so we've got our parameter now. And instead of selecting players, we will say selected and we'll inject params.params.players. So I did one player and okay, let's not mess around with plural, all right. Please bear with me. So, where it is, where it is. Okay, so now I'm gonna apply that file again. Three.yaml and let's start this task again. So TKN start, don't forget the show log. Don't know TKN task, start, start game dash dash show log. All right, so you can see now that it's asking me and I'm sorry my terminal inside of my slides is not really friendly with color quotes, fancy quotes. But you can see now that I'm being asked for the value for that parameter players of type string default is one. I can either accept the default value or just change it to two. So value has been changed to two. And it almost worked, almost, almost. Let me just change. I think that's with the, oh, I'll need to, cube CTL apply dash F3. With that parent thesis that I've added for the player S, I think that's what caused the error there. Okay, so, well, not found, not found. Well, you can see that what happens when a step fails. So that's a good first step. What happened? That's funny. And I think I understand why I'm having issues. This is actually running in demo. This is there, this is there. Let me just take this. And as I said, I'm allowing myself to cheat and to just copy and paste from a working example that I know I have. All right, let's give that a try. F3.yaml, oh, really? It's one of those days. It's Friday, isn't it? Yeah, all right. So TKN, task, start, show log, YAML engineering. Okay, waiting for logs. Seems like it might be work. Okay, even with my original demo, which I don't know, used to work. But anyways, you kind of get the point. I'm not sure why it's not cooperating right now, but let's not spend too much time trying to do some live debugging here. So what I can do is that actually pass that string, or pass that a parameter. I can also add it as an additional parameter, so I can say players equals two. And now it won't ask me for the question because I've actually specified it directly as part of the CLI. So why is that one working? Oh, I think it has to do with those ANSI codes. Like it just doesn't like the, like it's yeah, okay, okay. Okay, so you can specify it as part of the command line and it works, you know, and it doesn't work. Yeah, exactly. I sent the semicolon 78, yada, yada. So, you know, I was trying to be fancy and do a terminal inside of my slide deck, or like, yes, it has its downsides. Another cool thing that you can do, and now I never remember the syntax of that one, but I believe it's dash dash use param defaults. So there's a plural that, oh, there we go. So that one will automatically use all the default values that you've put in, so selecting one player starting game. So you can see how that parameter, already I have a task that can do two different things. It can, well, you know, based on the number of players, and I've been able to reuse that task to get different outputs because I'm putting in those parameters. Okay, so let's move on. Let's make this a little bit more complex and let's add some pipelines. So what is a pipeline? Well, a pipeline is a collection of tasks, basically. So you'll just chain up different tasks. So if we look at this chart directly from the Tecton documentation, we've got this pipeline and in here you've got four different tasks. So task A starts and then B and C will then run once A is completed and then task D is run after B and C is completed. Each one of those tasks will have their different steps. So this is what a pipeline looks like. Let's try to see what it looks like in YAML. Well, you will have your task. I'll add an additional task in here inside of my cluster that will be Defeat Bowser because that's our ultimate goal, right? We want to defeat Bowser. So the ultimate thing that it will do is that it'll echo bounding browser. It'll sleep for one second and say that you won. All right, I know, I know. I could have been a little bit more elaborate with my game, but hey, you know, just trying to demonstrate a concept here. So for building our pipeline, what we will have is our same type of syntax API version, kind of object pipeline, some metadata. We'll call it play Mario and then we'll have inside of our spec, we'll have all of our different tasks. So our first task will be start, which is the start game task that we've used. We can see it in the task reference here. And the second task will be called win, which will be in reference to the Defeat Bowser task that was just added right here. Also notice that inside of my first task, I'm specifying the parameters that I want, right? So I can actually put that in. I can put in the number of players directly inside of my task reference here. So let's take a quick look at this. Where is my, I'm having a hard time with my code editor. There it is. So let's create a new file for that YAML and we'll create that second task here. So tecton.dev slash if you want beta one, that's good, kind, task. Bugs me that I don't have my auto-complete anymore. Metadata will have a name. I think I've removed it and I'll tell you a little secret later on, not default, Defeat, Defeat, Bowser, and I always type browser. Okay, spec, we'll have some steps and the first step will have a name and the name will also be Defeat Bowser because that's good enough. And then we'll use Alpine once again because we want this to be blazing fast and command command slash bin slash sh and some arguments. Well, I really can't type today dash C and echo battling Bowser and sleep one and echo you one. Whew, that's hard. Okay, so I've got my task now. Let's also go ahead and build our pipeline. So five dot YAML because I'm not feeling fancy for naming things today. So we'll have the same type of thing. So API version, this is also tecton.dev v1 beta one. We'll have an object of kind pipeline. Oh, was it there? Was it? Oh, no, it's just my Kubernetes. Oh, for a second there, I thought I would be able to use that out of complete metadata, we'll give it a name. We'll call it play Mario and we'll have our spec. It will have some tasks, tasks, tasks. Come on, tasks, first one will be start. And this is the name for our task, but not the actual original task, which is specified here. So the reference will be or name start game. Okay, so I'm actually referring to that specific task. And then I'll have my parameters and it will have name, players and value. And don't forget it's a string. Ah, okay, why are you messing with me today? And the second task, second task will also have a name. It will be called win. And it will just have the task reference in here name, defeat, defeat Bowser. And I think this will be my last typing because I just can't do it today. So kubectl, unless you really want to see me having errors and typos all the time, apply dash F four. And we can also kubectl apply dash F five, five dot YAML. And let's clear this. So TKN task list, we can now see that we have two different tasks. Also, it helps me to keep track on how much time I have left TKN, no, not yes, TKN pipeline, pipeline LS. We can see the list of pipelines. This one was never run. So we see that last run does not exist. So let's actually start it. Pipeline, start, play, and there it goes. Guess what, show a lot. Okay, so now it started. So what it's doing is actually starting that first task, creating that first pod, selecting one player, oops. And we see that something odd just happened here. So it kind of started that first pod with the first task and it said selecting one player. And then the second step of that first task was starting game, but battling browser and U1 kind of appeared in the middle. So that's kind of weird, isn't it? Well, not really, because that's kind of what I asked it to do. So the task sequence here is not a glitch. It's actually what I've told it to do. So you right here, you see that you can actually specify the order of our tasks and this is not what I did not do in this case. So what I can do here is to add this run after. By using that, I can actually specify when this task will run. So let's actually go back and change the change just here. And I'll just create a new task, six.yaml. I said I wouldn't do it anymore, right? But that one should be fairly easy. And I'll make sure I win will run after and this one will take an array and I have to refer to the name of the task here. So start, which is in reference to that. So it will actually run after the first task is successfully completed. So kubectl apply-f6 and there it is. And now we can actually do TKN pipeline, start, play, Mario, and there it is. And there it is. Boy, it's really, I can't help it. Now we have selecting one player, starting game and now the second pod is triggered, baling bowser and then you won. So there was that little pause between the two there. Good, so now that you can specify the order, now you can do things like making sure that you have reusable parallel tasks. You can do stuff like cloning a repository and then installing the required dependencies. And then you can also have parallel tasks, which is kind of interesting. Let's take a look at this task here and I'm not gonna type it, I'm just gonna go through it here. So very similar to the other ones. So API version, and then in the spec section I have one parameter. So this task will be called collect and the parameter is object. What should I collect? It will default to coins because that's what Mario usually collects, right? Coins, but he can also collect stars and mushrooms and a lot of different things. So we're gonna try to make that task a lot more reusable. And then for our step, it will have a single step, which will just do an echo statement once again. It will pick a random number between one and five and then it will sleep for that number of seconds. You'll see why that's important. And then it will echo the number of objects and the type of objects that it actually collected. In my pipeline, I'm gonna reuse that task twice. So this is where you can get those really powerful tasks and you can reuse them. So in here, if you can see that I have a reference to the task called collect and that is to collect some coins. So I'm just using the default values here. And the second task has a reference to collect once again. So that has a reference to that same task, but in here I've changed the parameter to be a value mushroom in here. So it will be able to collect both coins and mushrooms in the same pipeline by using the exact same task. Both of these will start, will run after start, and then the win task will run after both of these collect tasks has been executed. So you can see how we can use the run after with the multiple arguments here. So why don't I go ahead and, oh, this is actually something very interesting as well. You have the Tecton pipeline and I think I've disabled it. I think that's what happened. But you can see a screenshot here of my task and the Tecton pipelines VSCode extension is very useful to visualize what's going on inside of your task, because it'll actually give you a preview of that pipeline. So that's a very, very cool feature that you can have in here. All right, five minutes left. So I'm actually gonna go a little bit faster here. Kube CTL, apply dash F, I believe I'm at seven now. Of course it's not there because I haven't created it. Let's just copy it from here. Wow, that time check just stressed me out. All right. Kube CTL, apply dash F7.yaml and we now have everything. So TKN pipeline, pipeline, start, play. Mary, don't forget, don't forget, don't forget. There you go. All right, so now it's gonna do all of that stuff. It's gonna do, run those two tasks. So first it starts by selecting a player, doing that first task, then it executes both of the tasks simultaneously and it will wait for both of those tasks. So that first one took only one second because it slept for one second while it was collecting that one coin. The second one also slept for one second and then you have the battling browser. If I ran this, I'd get different numbers but it will always be executed in the same number thanks to my run after. All right, there's also a task catalog that is available to you. So obviously you won't wanna do some echo statements. You'll wanna do some stuff that is a little bit more interesting. So GitHub, there's, or check out for the Tecton Hub. It is available on GitHub. There is a bunch of different tasks that you can use out of the box. Pipeline resources, they're still in alpha so I'm not gonna spend time here. What is used nowadays is more workspaces. Workspaces is a shared volume between all of the different containers that you have all of the different containers that you have running inside of your pod. So you can share that information through a persistent volume. They can be used both in the tasks and in the pipeline. Yeah, and real-world examples, well, you can pretty much do whatever you want now that you have your tasks. And just by using reusable tasks here, you can clone your repository, perform some unit tests with MPM install, NPM test, compile your code if you're doing some Java stuff with, what is it, Maven? I have no clue what I'm talking about. Then you can build your image and then you can finally deploy that image to a cluster by using OC or Cube CTL. So all of that can be done throughout the various tasks inside of your system. So just a quick recap of Cognitive CICD framework. So Tecton all lives inside of your Kubernetes cluster. It uses steps, tasks, pipeline and workspaces. I'm absolutely, I love Tecton, so I speak way too much about it, as you can see. Also, I'll let you know a little secret. There's a book coming up sometime soon. So check me out on Twitter if you want more information about that. So thank you very much for being here. Thank you for attending. I'll have a few minutes for questions, I believe. And yeah, that's the one link that you're where you'll find all the information. So easy URL to slash pipes and clouds. Thank you.