Cloud Native Computing Foundation Kubernetes Community Day Czech Slovak 2022, 11 May 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: 28 04 management Savita Ashture Unleash CI CD with Tekton and ArgoCD

Description

KCD 2022 CZ & SK virtual - Prvá CNCF cloud native konferencia v regióne Čiech a Slovenska. kcd.live

A

And now I introduce a little bit uh about our speakers from india, hello, savita and shivam.

A

Please take over with your presentation thank.

B

You thank you thanks. A lot for the nice introduction uh I'll quickly share my screen, uh hello. Everyone welcome to kcd.

B

Today we are going to talk about how we can unleash cfcb technology a little bit about ourselves from india, working at red hat and.

A

Meet my colleague shiva.

C

B

You guys can find us on twitter linkedin, slack github. The informations are provided here. Moving on this is the pretty much agenda we have it for today. So basically, we are planning to cover overview of tecton different projects which are present in tecton and among those projects.

B

We are mainly focusing on pipeline and triggers uh project and with a live demo, then we will see a high level overview of argo siri and one of the important custom resource application of argosy and then finally, we have a end to end demo, where we will show how we can integrate both technology and how, with that, with the help of that integration, how we could be able to build.

C

The deploy on multiple.

B

Clusters moving.

C

B

C

Let's understand.

B

A little bit about tecton, so tecton is a open source project based on kubernetes. It provides a continuous delivery and continuous integration. I mean it also helps end-to-end application, building deployment and development.

B

And we used to call it as a bill and later it.

A

B

From k native and start and became an individual one, no today we call it as tetron and it was started by google, red hat, ibm, hotel and few few.

A

Many other companies, and now today it is.

B

Part of a cd foundation, so tecton is basically used by uh developers who write their ci cd for their daily and also very platform administrators who develop cicd.

A

For their organization.

C

So that their developers.

B

Or anyone of the organization can use it, so this is a pretty much uh overview about detector.

B

Moving on, let's understand a different problem which are existing tecton today, so even if initially, when it when tecton started, it was very small, but now, as the time goes on, it became a huge uh or kind of thing, and now.

A

It has a multiple sub.

B

Project, so among those projects, we are focusing on few major one which actually used by many users. So let's understand one by one, each of those. So we have a pipeline. So basically, it provides a declarative way of declaring the kids resources to write these either pipelines, and we have a triggers and and also pipeline, is a core project of tecton. I mean most of the apis are resides under this pipeline project and we.

A

Have a trigger so basically, if.

B

You want to do automation and if you want to deploy the pipeline resources dynamically based on some events, so in that case we will make use of trigger project moving on. We have a cli, so it is a command line interface, which helps us to uh interact with the tecton, and similarly, we have a dashboard. This is a kind of a it is a web-based ui. So, like the way we have a cli which interacts from the command line.

B

The dashboard will helps us to interact through the best uh uh things to interact with the technolon. It could be from pipelines triggers to any of the components we can interact via.

C

B

C

Then we have a catalog so basically.

B

Like uh if you take an example of jenkins, jenkin has many plugins right, which we, which we can use and use. Similarly, what pipe to start a catalog project where number of users from different different companies with different different scenarios. They will write tasks and put it in this repository catalog and anyone can use it from here I mean most of the single uh entity of the task will be added.

A

B

The catalog, so basically, if I want to say one term, catalog is a project which contains number of tasks which are reusable kind of thing.

B

It's again a web-based platform which show which shows the information of for tasks which are present in a catalog repository. So basically that helps us to decide which task is more popular, which task is used and how many stars are given. So based on those information, we can use the task so maybe like how we how we could be able to use tasks from this catalog repository. We will show in the live demo I mean today in our uh demo. We are using most of the tasks from the catalog repository.

B

Instead of writing from the scratch, then.

A

We have an operator, so we all.

B

Know that operator helps to do day. One and data operations, mostly so here also tecton as it becomes bigger and bigger. The installation is kind of a need to think a lot if end users want to install it. So we we provided.

A

B

A

B

Helps us to install the entire tecton in a few clicks, so basically it helps to manage day one and nato operations, so this is a different project which mostly many of the users use so moving on. Let's.

A

B

A few of the concept and core resources of tecton pipeline project itself, so here similar to like kubernetes, we have a container uh deployment service for tecton pipeline, also has its own concepts and few resources. So we have a task pipeline task run pipeliner these.

A

Are the resources when I say resources.

B

These are the custom resources uh which is provided by tecton pipelines, and we have a step workspace result. These are the concepts which we used, which we use. When we write these resources, we will show how these are interrelated uh in a live demo on as well as in the next slide, where I will just explain high level uh things of these concepts moving on so instead of.

A

For showing in this way, I just.

B

Want to explain those concepts in a diagrammatical view, so that it will be easy to understand how they are interconnected with each other I'll, take a scenario of cloning, the code building the code and image and then pushing that image to the registry and then finally, getting the digest to get the digest. It means the in order to make sure pushy success and then, finally, I deploy that image using cubesat.

B

So you can see that these are the multiple stages I have done when I want to do these kind of operations, so like in kubernetes container, is an entity which does some operation and terminate right. So similarly, in tecton pipeline, we call as a step. This is not a resource, but it is a kind of a concept or object kind of thing which we used inside a one bigger resource. So I'll come I'll come to in a minute. So before that, I just want to say that step.

A

B

Entity entity which does some operation based on the provided information. So when we say information it could be like environment information, image, information, uh argument, information, volume, information. It could be anything so it's it, as I said, step is exactly similar to container so it expect or it accepts all those informations which container expects so now, like you can see. I have a step kept here and three step here and one step here so as entity. We need to club these step together to form an entity and that we call it as a task.

B

So basically task is a custom resource of tecton pipeline which helps to manage multiple steps together and execute those steps sequentially like if I have multiple steps it executes build. First, then push then digest so this is this is something managed by task itself and then we, I have a task called reply where we will do the deployment and the output of one task can be given as an input to other task.

B

So when I, if, if I, if you remember in the previous slide, I explained about the workspace and results. So these are nothing but the uh concepts which we use for input output operations, so workspace is nothing but kind of a storage where we store output of one task in the workspace and that workspace give.

A

B

An input to the another task so to handle input output operation between multiple tasks. We use workspace as well as results, so these are the two entity uh in tecton pipeline. Now you can think like why I have a kept as a three different task. I I can write as a single task with all these steps club together, I can do it. There is no issue, but I want to show one single task, which is a reusability right. So, let's suppose I have a scenario where I just want to clone the code.

B

Okay, so in that case I can just straight away use this task from which was checked out somewhere and I can use so that's. That is one of the benefit of task, so basically write which will do one particular job so that multiple users can use it. So, let's suppose I will write a task called clone, but after writing I will push that task to a catalog repository and like later after one month or after few days, some other user can easily use the task. The other user know.

B

So that's the reason I always prefer to write a single task which do some preferable work so that it can be reusable. That's the one of the benefit now to run this task so till now, when I apply this task camera on the kubernetes cluster, it's just a static entity. It won't run it run this task resource we have another custom.

B

So basically is a runtime entity which helps us to learn these tasks. Now I want to combine single object and we call them as a pipeline. So pipeline is a resource which contains multiple tasks and pipeline knows how to con this task.

B

So uh uh maybe in the live demo, we will show how the tasks execute one by one on what on what basis and again this file dt and this pipeline, we have a resource called runner, so a runtime entity which instantiate this pipeline so till now we see the theoretical part of these concepts and resources and how they are integrated with it.

B

Now I would like shiva to word and show us the live demo, how it exactly looks like and how our pipeline template looks like and how we could able to run the pipeline run shiva over to you. Thank you.

C

Yeah, uh thank you sabita. I will just share my screen.

C

Okay, so we saw the tecton typing concepts, so we just uh try out the concept and then see how the pipeline would run so for the demo we are using a application which is a new stem application. uh It's a simple application which you can search for news and there is nothing quite complicated.

C

So I have deployed this application on the cluster, so I will just- and we have another repo where we keep configuration for the ci cd there is. It is not required to have two requests, but we are like having the code at one place and configuration has worked this uh about the cluster, uh so it's openshift cluster. uh It is not required for the demo to be performed over shift. You can use any kubernetes cluster. uh The only thing which would be different is for openshift.

C

We are creating a route because it is easy to expose. uh You just need a kubernetes cluster where you can expose something outside. So basically you can. You just need ingress. uh So for this demo we are using uh open shift so for the demo. So this is the configuration repo in this. We have the application configuration uh the namespace deployment app, so I have applied this on the cluster as you can see here. So there is a deployment there is out and the app is working fine.

C

Now uh we have, we want to set up a pipeline uh which would uh fetch the code from here from this code, repo build the a new image, uh push it to our image history and update our different. Basically, we want to build that pipeline.

C

So if I go here in the pipelines, predictory- and we will see a pipeline here- okay, so at savita explain apply pipeline is nothing but a template with a task right. There are multiple tasks. So, if you see here, we have array of task so which we want to perform.

C

There are parents, so pipeline is just a template. You can share with other people and they can run it too. So we have multiple tasks, so we will see the first one, which is the thing, but the git clone. We want to clone the repo right, so we are using git load so where this task is coming so as with uh explain, we have a hub right. So if you go here and search for kit cloud, so you will find the task here.

C

You can see the yaml how it works, and if you want to install it, then you can just do this cover and in your pipeline you just need to reference. The task after you have installed. That's all so. Tasks are like a template where you can pass parents depending on your project. So uh so here we are passing the url of the repo and, like the revision, means with the branch we want to clone. So this is like that's all. We need to do to use a existing task.

C

Similarly, we have build and push for building the image which are using build up. That is also from the hub. So we are just reusing that one thing to notice is: there is a run after what that means. So we want to build the image only after we have cloned the repo right. So we don't want to execute this task first, so we mentioned here run this task after we have completed search repository successfully.

C

If it fails, then this complete pipeline will fail uh so yeah and another thing to notice is the workspace.

C

So let's say we have cloned the repo, so we we need to access the code uh in this repo right. So we need to build the image from that code. So workspace is nothing but a volume where you clone your repo and that volume is shared between all the tasks.

C

So this, if you notice here uh so this workspace, it says output, so the fetch task, the kid from us will clone the code and like clone it in this workspace, and this workspace will be used by uh another, the tasks which are in pipeline to execute their logic. So we have build and push. We have checked deployment so once we have built the image push to a registry now we want to create a deployment or update the deployment depending on so we first check the deployment whether the deployment exists on the cluster.

C

If it exists, then we will just update with the new image like a new image which we have built and if it doesn't take, we will create a deployment. So this is like we are uh first thing. Is cloning second, is build and pushing the to the registry, and third is creative deployment or updating a deployment, and there are two more tasks which I will skip for now, but we will come back to it later.

C

So here's a so uh so uh I will just run this script, so this script is nothing but it will install the task, uh create a namespace uh create secret, because we want to push our image to a registry right, so we need authentication. So I will just execute this script, which will create some secret. Some service account so pipeline needs some access right to create the deployment or update it from it. So this script will create everything we require and it will start a pipeline.

C

So pipeline is a template and pipeline is the instance of that pipeline running. So these are the parents uh which we will be passing to the pipeline and that will be used to execute the pipeline. Okay, so let's see is it in action.

C

So I will just pick pipeline run.

C

So it is installing the task first like we are using it flow and build a kubernetes action for creating a deployment. So these two tasks are, I am yet to explain, so I will extend them as we go.

C

So we have created some secrets which are required and some are back.

C

Okay, so the pipeline then, should have started because we have started it manually so pkn, which is the cli which is provided by tecton, uh which interacts with the tecton resources. So pr is nothing but pipeline run and ls like listing, so we can say see that the pipeline has started. So this is the one of the way we can see or access our pipeline or task.

C

Another is like the web view. So if we go to dashboard, which is also provided by technocd, uh if we go here take on- and we see the pipeline right so we can see, the pipeline has started. The first watch fetch that is flown, so it is now building and pushing the image right. uh So this will once it's it will check the deployment update requirement and so on.

C

So what we did here is like we created our task, which are required for a pipeline. We created some rbac and we then started a pipeline using the pipeline drill, but this was like manually started right. We can't do this every time. Every time we need to. We can't create a package, so we need something automated right. So whenever a code is updated in our git repo, we want a pipeline and iplane to start it right. So for that we have clicked on triggers so till okay. So we can see all everything is templated.

C

It shows completed if we go here. If we go here left it says the pipeline is succeeded, so it has updated the deployment.

C

Okay, so this is the deployment uh for the application, so you can see it is like 44 seconds, so it is recently updated with the new.

B

C

And so now to set up triggers first see, we will see our concepts like what are the different concept intrigues and we will come back to the demo and set up like automated entwin figures for that. So back to you, savita.

B

Yeah, uh could you share the presentation shivam.

B

Yeah, can you go to the trigger slide.

B

Yeah yeah, so uh we saw till now like how we set up the pipeline manually, but when we talk about the ci cd, there should not be anything manual operation. I mean what is csd. It should be continuous integration, continuous deployment without the manual intervention, but the w we saw is something we manually ran the pipeline so that that is something we don't want. So to avoid that kind of thing, we have another project which does some operation for us, which is tecton trigger and few of the core concept trigger providers today.

B

So we have a event. Listener object, so it is kind of a custom resource which which tries to run kubernetes, pod and kubernetes service and which keep on watching for the incoming http request, and we have a another custom resource called trigger. So this trigger basically decides what to do with the incoming event, and then we have an interceptor.

B

It is again a continuous running for uh which, which does some operations, like uh validation of the validation of this, to know that whether the events are coming from the authorized sources or not, then we have a trigger template. It is kind of a blue, it actually contains the information of pipeline run. Okay or it could be task run. Then we have a trigger binding. So it is another custom resource which actually does some operation on the incoming request.

B

So what it will do is like once after the validation is success, the data come so it takes the values from the incoming event and extract values from that request and pass it to some variables and those values, or we can say those variables will be used further inside a trigger template, and then we have a clustered trigger binding. It is similar to trigger binding but runs at the cluster level.

B

Yeah so uh we saw the those are the different concept, but I just want to show how they are interconnected with each other with the diagrammatical view. So, as I said like when I apply even twister yaman, it creates a pod and kubernetes service for me and that power continuously watches for the incoming event. So you can see that a event is coming to the event listener.

B

For once event, once event comes to the event listener for uh trigger uh does some operations to what to do with that event, so what it will do, it will passes that event. Information to the interceptor interceptor does the validation and once validation is success. It will pass the incoming uh request to this trigger binding. So what does this trigger binding do?

B

As I explained, it will extract the data or we can say body from the event and do some operations and pass it pass it to the variable and those variables will be used inside trigger template and, as we discussed trigger template contains the information of pipeline run. So my point here is the event information coming from the any of the sources like github bitbucket gitlab.

B

That information will be finally passed to the trigger template where actual pipeline run or task run, resets right and then finally, it will create those resources and right now, tecton trigger provides few of the core interceptors like github gitlab, bitbucket cl. These are the interceptor.

B

I mean these are the event sources where trigger supports, but there is also one of the functionality of the tecton trigger is to write your own custom interceptor. I mean you can add your own event source. You can run your own event source and integrate with the kept on trigger and tecton trigger, which will easily use that one. uh This is how the tecton trigger works. Now I would like to take these concepts and explain uh how this tecton trigger dynamic is scheduled. Those pipeline done, which he has already written ot.

C

uh Sorry for that, uh okay, so we saw we ran a pipeline. Now, let's see how to set up triggers.

C

So we want to set up our triggers on this repo because we will be doing some code changes in this repo and the pipeline should have started right. So let's go to the files and let's see what are the different resources. If I go to triggers so we can see a event listener here. So this is the event list now which will be watching for the event. Basically.

C

uh So in this we have a binding and a template and an interceptor. So the interceptor is nothing, but it will help you filter out the event. So for this demo we will be using the push event. So let's say we configure our book for all the events, but we want to only like process only the push event. So we add a filter here uh which would filter out the events. Basically, uh there are many more interceptor git lab other or we can write our own interceptor. Also.

C

uh The second thing, which is the finding so, if you see binding so binding, is nothing but so the event which is coming from github or any other event source will have some payload right. So we want. If we want to use some data from that payload, then we use binding. So we say that from the event which is coming, uh get the head commit either url and the push thread, which is nothing but when the event was pushed.

C

So we want to use this data in our pipeline somewhere, so we define our binding and the last one is the trigger template. So this is where we define, which resource to be created, event came event: listener will listen the event, then it will using the trigger binding.

C

It will get that data from the payload and then it will create the resource which is mentioned here, which is nothing but pipeline run so in this pipeline, then we will say uh you need to start a python right, so you need to start this pipeline and these are the patterns we, which you need to pass to it so while creating the pipeline. Basically, so we saw event listener, which is watching the event interceptor, which is filtering out.

C

The events uh trigger binding, which will get some data from the event payload and the template is nothing but what we want to create. So this only pipeliner and task run are currently supported and route. So we need to configure this event listener with github right, so we want something publicly accessible.

C

So as it is the openshift cluster, we are using route, but for any other customer you just need to create a ingress on this service and you will be fine that nothing extra okay, so I added this router script that will just execute this command. So, let's see.

C

So it should create all the resources and the.

C

Okay, if we do cube cpl gate box, okay, there is a event listener pod, which just came up and if we do keep city allocate outs and we will get an event listener route. So you just need to take this, and now we will go to our code, repo, which is this one.

A

C

So if we go to the settings so we want to set up a book right so we'll just go to web book. Add a web book.

C

So we will add our.

C

uh Url here we'll do this run format. uh We just want to push event and we will just say just add a book, so you will get a successful year. If your event listener is up and running, it will just ping it and just tell you this okay, so we have set up our triggers. We.

A

C

Ready to do any code changes so to see whether the triggers is working or not so so I have a code. The code repo is generally like flown here, so I will just do a no edit comment and just post push it. We just want to check whether the pipeline, then we started or not. We will do a code changes and do an end to later so for now I will just do of course like I will just create a push event.

C

I will just first push to the main branch and there should be our pipeline run, started.

C

Okay, let's see.

C

Okay, something is wrong.

C

So let's see our logs.

C

B

C

Paper, which is here, if you see here, okay, something is filled.

C

Okay, this time it has. Actually, I don't know why, but it should have started a pipeline okay, so we can see a new pipeline basically.

A

C

Event was not delivered due to some reason, and if we go to the dashboard we will receive a new pipeline. So so what I did was the event was unable to deliver, so I just re-delivered it. Ideally, this doesn't happen, but I don't know why it happened this time so yeah. So we have set up a web book so whenever there is a new push event, so this event will be delivered to the event listener.

C

The event listener will process the event uh pick some data from that payload, which is define the binding, then uh add it to the pipeline run because we have added here right. You can see here like add the git triple url, which is coming from the event, uh the revision and then start this pipeline run and this python we can see here, which is started so which will execute all the things uh so yeah. So this is how we can set up the end to end ci cd.

C

So we can see that this is also updating our dev instance. So currently, the application which I deployed here we are called, let's say, call it as a dev instance, because we are going to set up another instance and then we will integrate both rcd and tecton together. So this is nothing but a one instance where we have end to end-to-end cicd.

C

Whenever some code changes are done, that will be built, a new image will be created and the image will be updated on the instance. So this is like how you can set up the ci cd using tecton.

C

Now we will see what is ago cd and how then we will see why we want to integrate tecton analysis together. What are the benefits so back to you? Savita? Let's start with our cd1.

B

Oh sir, can you go to next slide? I was speaking on mute, yeah, okay, so till now we saw how we can ensure end-to-end ci cd with tecton. Now, let's understand ergo cd and what is the use case of argo cd to use?

B

Okay, so before that argo cd is also a kubernetes controller, which is something similar to like how we have tecton and it's a declarative, uh github's continuous delivery tool for kubernetes and argo cd is used as a standalone tool or it can be used as a ci, cd workflow and the single source truth for the argo is the git repository where the kubernetes manifest or health charts resets, and why should we use arco siri? So, basically, argo cd will be helpful for the application deployment life cycle management, everything in an automated fashion.

B

So if you want to understand the use case, why we want to go for or go? Why can't? We just do with the test on. So I I, as per my understanding, what is like, if, if argo cd will be very helpful if we want to do with the multi-cluster githubs operations, so what is that?

B

So, let's take a scenario where I want to deploy: 10 application like in a 5 clusters, and I can make use of for any of the uh jenkins or jenkins use any of the helm or customize to deploy my application, and even I can do update also if there is any change in the image, information or something else. But what so here? What I need to do. I need to configure such a way that it should go.

B

uh I should go in a five different, five different cluster and do the changes every time, but what, if I have it, ten thousands of application and thousands of clusters? In that case, it will be very difficult to do this stuff manually. There is a lot of chances like we may forget. We may tend to do some mistakes and all those stuffs. So here comes a gitoff's operation, which is a best solution to uh to to to solve this kind of multi-cluster operations, and we have the argo which does easily for us now.

B

How are go for us uh shivam? Can you go to next slide? Please yeah! So here we can see that, like we, we are go similar to tecton pipeline tecton trigger argo also have many custom resources, but as per our demo, we are just making use of application custom resource and that's the reason we. We took this as an example to explain uh this stuff. So basically, it's a custom resource definition, which does which have two important concept called destination and source.

B

So basically, this application contains information of your destination cluster, where the application should go and deploy right. That, as I said like, if you have a ten thousands of clusters, uh thousands of cluster ten thousands of application, how how uh how argo cd will get to know like where should go and deploy. So that is where a destination play important role. So here we will specify on which name space and on which cluster I want to go and deploy my application, and then we have a source.

B

I I mean: if you want to deploy something, there should be some source right. I mean it could be a kubernetes manifest or it could be health charts right. So to provide that information.

B

We have a source and this source contains create a stage which is nothing but the path of the kubernetes manifest, and if you have a helm charts you can specify the chart name, and then we have a repo url which is given down where you can specify where the url of the github repository, where actually the data exists, or you can say manifest exist so with this help help with the help of this applications. Here we could able to achieve that uh work and we have another concept of orgo called sync.

B

Now how virgo will get to know? Okay changes happen I mean, let's suppose I did some image change in my get repository where argo cd is watching, how how argo cd will get to know that? Okay, there is a change. I should get my cluster to be updated.

B

How that happens so there a sync process will come into a picture, so what it is tries to make always to uh to make sure that they are reso present in the git repository and the resource present in the cluster should be in sync, always they should not be. In sync, I mean out of sync, and this thing can we can do in two ways: it can be automatic or it can be manual.

B

So most of the time uh we do prefer automatic, but there will be a few scenario where we will do manual, because we want to make sure that before upgrading to my cluster, we want to make the updated changes in the github repositories proper or not. So to have that gap we will configure as a manual sync so that administrator or end user. They can just verify that pr and then do auto manual sync.

B

So this way it depends on our use case entirely, which one we want to do so this way we can able to make use of this thing this thing and try to make sure that the cluster state and the git state is always in sync. So this is at the high level concept of argo and why we need to use arco cd.

B

Now I would like shivam to uh take care from here and explain how uh we could able to integrate both argo and uh tecton and uh with the the pipeline which we have deployed previously and how we can how he he could be able to integrate with targo yep uh over to you shiva. Thank you.

C

Yes, thank you savita, uh so we saw that we have uh deployed our instance using technocrat. So let's deploy another instance uh using rbcd, then we will like uh integrate both of them together and see how beneficial that would be. So arco is quite big so, but we are using uh only one concept of it. That is the applications here uh where we are telling uh you need to deploy this application, uh which is stored here, which is in a git repo directly, and you just need to go and uh install that on our cluster.

C

So, okay, so I will show you.

A

The repo so in this repo.

C

There is a ksf stage, uh which is nothing but a staging configuration and the dev is nothing but which we use for the other instance.

C

So if I go to the cluster, if I do as well so I just have so this skip nothing, but I will create the uh we'll apply the application cr of argo cd and it will also create a config map which will have an api key. So the application which we are using needs api key, uh which is nothing but uh which we. So I don't want argo to manage my configuration, which just may be secret.

C

Of course, in that, so I will create the config map uh myself and I will just uh tell the con archosity yeah if you just. You, can just ignore this change uh to the config map, because I will handle that myself. So you can do this for secret or any other thing.

C

Okay. So let's do this cluster and create the applications here.

C

So it has create a config map with the api key which is required for the application to work, and here it has created the applications here so purpose cd has a nice dashboard where you can see all the created resources.

C

So, as I mentioned, the sync policy right so currently our application is out of sync because it has not been deployed on the cluster, but it is in a grid repo, so it is expecting a synchronized. So there.

A

C

Ways like one is automatic or we one is manual, so we have kept it manual for now we will say now you can sync, it is like I haven't, given you permission to swing basically, so if we go to the cluster, if we do cube city allocate parts and we will see the another news name of stage name space where the arrow cd will uh deploy a new instance. So this is like we can see the part if we see the route here, okay, so we have a new route.

C

If we go to the cluster browser and.

C

So the application will be up okay, so this is our staging instance and we have our dimensions right, so the dev instance is deployed by tecton cd end to end uh from the code, and the staging instance is just deployed by ocd by watching over this uh manifest.

C

So now, how do we integrate them like and what is the benefit? The benefits which we get from obviously is like the transparency.

C

We know that that which, whatever is deployed on the cluster, it's coming from this so whatever whenever we change something here, rvcd will notice that and deploy it on the cluster and the pipeline, which we ran, which will have developed any new changes to our dev instance.

C

Okay, so I will just show you a diagram. So this is our code repo, and this is our configuration.

A

C

Just a sec.

C

Okay, so we have set up an event list now which is watching for events and which will start a pipeline, so everything is done in our pipeline. We saw there were two extra tasks which we I didn't explain before.

C

Okay, so in our pipeline we'll go back to our pipeline and see the two tasks which I didn't explain before. So there was this one. So after building our image, we have a new image right. So we want to create a pull request to our staging configuration.

C

uh Why we will see in a bit so the task two task square like it will use used to like create a full request to our staging configuration with the updated image and why it is created. We will see in the end-to-end demo and yeah, so the last two tasks for that.

C

So, let's see an end to end, so what we will do, we will do a code change. Then we will see our pipeline started. Then we will see the pool to be created and our ocd part okay. So let's go to our code.

C

So if you notice here, we have news demo written right. So we'll just do some small change here, news demo by technology. I will just do a replace and I'm just going to commit this change.

C

I would say updated.

C

C

And I just going to push this chain to the main branch and hoping a plane would get the event okay, so new change is pushed if we go to our code, repo, which is here and if we see here uh new, commit, has preferred and our pipeline should have started.

C

C

Okay, yeah, so this time the event listener got the event. uh Last time it may be a networking issue so like we, let's go to the dashboard so text on dashboard. If we go to pipeline, then okay, so the new pipeline started with a new change right. So this will get the new code, build a new image and update our dev instance. So we'll see the changes there and then okay. Here we saw that we had the last two type. So this time we will see what they are.

C

So let it finish uh till then I will just go to the image: okay here: okay, so how does it relate? uh We have a listener. We got the event, we started a pipeline. We cloned build and pushed. We updated our dev instance, which is running here and we created a full request to our configuration java with the updated image which is watched by argo cd and which, with nothing but handling our staging instance.

C

uh So let's see okay, so the.

A

C

Completed right, so if we go to our tab instance, which is in the news demo dev and see, let's see the pod okay, this one. This is our application port, which is started 35 seconds ago right. So if we go to our.

C

So we can see a change here right and this changes our dev instance. If we can notice this from the url, uh if we go to our staging instance, there is no change. It's the old one, okay, so in our pipeline we created a pull request right. uh So let's go to that. It is there. It is okay, let's see go into the. So this is the last task which is creating full request and in the result we have a pull request.

C

So let's go to that.

C

So this full request is on our staging configuration, so what it is doing, it's changing the image. So why so, let's say we? We merged a pull request in our code or we added some new code and which is will deploy. Our davinci is right. So now we have saw the changes right. We saw the changes are good and we want to uh these changes to apply on the staging configuration.

C

So we can build the code and set up a pipeline. That too will work, but we already have a image which is working fine and we will just go here and merge this full request.

C

So arbor city is already watching this right, so it is no way to watch for we have configured it for so if we go to our rcd and see okay, it's say out of sync yeah, because the image is updated in our configuration. So it is saying that uh so here you can see. This is a deployment right. It's say out of sync, because the image is updated. So now we have saw the changes here that the changes are fine, so we can promote them to our staging instance. So if we go back to.

B

C

We'll just say so: this can be done automatically for the demo purpose we just skipped manually, uh so it will fetch the new image and update our deployment.

C

So we saw the changes had been applied, so I will just show the changes once and pretty much okay, so the image is updated on the staging instance, and we go here okay, so this is our staging and the image is successful.

C

uh So, in short, so we saw that how end-to-end tecton pipeline helped our dev instance and how we use arco cd to manage other instance. So you will find all the code on this repo uh is tech.d.

C

uh You will find all the installation, steps and explanation. If you feel any issue, you can just create issue. We will help you out there and please do try out and let me know about your feedback we'll be happy to help you. Thank you.

A

Thank you for the very informative talk for I you and savita.

C

A

C