 Hello everyone, I know it's two o'clock. You might have lunch as well. So we'll try to make it As fun as possible. So let's see how it goes Welcome to CI CD on the open shift The title it all calls the CI CD in the open shift for developer, but there is a change Yeah, the change is for the Bob, sorry for Bob Now the question is who is Bob So Bob is developer obvious But Bob was building the applications and deploying applications The kind of applications develop Bob is like a small set of applications web services kind of workload But those are the just not one application, but it is a set of applications Essentially form it as the set of the microservices or it is basically microservice Obviously these are small applications. So The Bob is basically package this and run it as a containers rather than running on the traditional VM environments Hence these are the different set of the services and the applications So Bob keeps releasing and deploying at their individual pace Compared to the what we used to deploy traditional the monolith or rather than Taking in the batch of the changes and deployed in the production or relatively production the any environment, right? So basically Bob workload is looks like build test deploy repeat build test reply repeat And basically this is that and then to some form as a CI CD Just one question, how many you feel that you are Bob here Okay, great. How many of you would like to be a Bob in case? great, so But there are few challenges how the Bob is so one thing is like See I CD basically we form it as the continuous integration the continuous deployment We continuously integrated all the changes through In our source code and keep those changes of and keep releasing and deploying our applications into the target environment Essentially the production environment So Bob needs some mechanism where he can define or she can basically it's no gender-wise, but basically Bob can Bob needs a mechanism where it can define the CI CD definition Which says that how to take the source code and get it to the production environment? Correct now to understand that definition what needs some sort of the mechanism, right? I'm basically the CI CD server that can execute the jobs for the each of the applications that Bob is building And at the end that application need to understand so the CI CD server need to understand if there is a change in the application source code state it need to take the source code change, right? It need to test build deploy or the build test deploy whatever the flow is correct now coming back to the build step is basically As a developer or as an or writing the CI CD we need some mechanism or the tools that can take your source code and package basically Create a executable form of your application and packet is that as a container, right? So we need some tools or the Bob needs some tools to build the containers And then it needs also some tools or the way Where with that he can take the same container image and ship it to the different target environment It may be stage testing or it may be production environments correct so Yeah, and at then those are the environments we need For deploying our application. It may be stage products. I can it depends So these are the few challenges This is essentially we are seeing the one box for the challenges, right? But imagine the first thing we have said that it's just Bob is not dealing with just one application Bob is dealing with multiple set of applications, right? So Bob needs to recreate all those things for the each and every applications to basically implement a CI CD pipeline, correct and Putting out the golder. Yeah, now Bob is the builder. He's a developer, but now he's building something and But the pen point for the Bob is he really don't like to set up all these pipeline definitions, right? Because if the Bob is building let's attain and 15 applications in fact, right? He needs to probably reinvent the wheel or more more of like he needs to write down or Do this mundane repetitive work for the each and every applications then There are how it comes In the microservices or more of like the if you are having the multiple application in the system We need some DevOps engine of the platform engineers help so they can help a developer to set up this CI CD pipelines Correct and hence as a developer they keep reinventing the bill and that essentially one of the problem in the Microservices or the multiple set of application where the people are continuously deploying we need to solve and Here the open shift come to rescue to some extent. Yes, and let's see how to help us So basically a open shift comes with a built-in CI CD or more of like the pipeline definition Which is you can think is more of like the managed service. We can still deploy while building basically executing our CI CD workloads Since it is we know that Kubernetes and the open shift is more of like already container-based form. So it basically Comes out of box with the scalability. So where we can for each pipeline We can basically execute a bunch of the loads or the workloads or the parts in the different set of containers altogether Right. So that's how the system can scale in traditional Jenkins Philosophy we can say it's more of like the master master just integrate the definition of the job and actually delicate the workload to the slave Right, but let's see if it is that really easy still the moment will figure out Our most important thing the Jenkins that comes with the open shift has include some batteries Essentially, it's few of the plugins that helps a developer to write down the pipeline some of the steps And more of like the declarative way. We are just going to say it And yes, and it comes with some bunch of the conferations along with that plugins as well So so that's about solving the one part of the Exiting a CI CD job. Now, let's see how we can build our containers applications So open shift also provides engineers provides something called the source to image So basically its source to image is more of like intended for maybe developer for the other purpose, but basically It takes your application source code Right, whether it would be current directory or the working directory But essentially here it taking the source code from the gate URL here It taking some base image now that base image has assumed that it's we call it is a builder image Oh, and the builder image knows for basically how to create your application source code into the executable form and put It into a container package or more of like the container image, right? And then it says that create and hello python application out of your rest to I built So now if we take the same Construct into pipeline you have something called the build API Essentially, it's kind of the declarative API. We just say that okay. This is how it looks like. I'm not sure if able to see it Okay, great. So basically it takes your Source code right and then basically says that I want to use some sort of the strategy for the time being assumed that This is the way similar mechanism that we have executed in the story It's take your builder image and it basically essentially produces your target image Let's say we have for your source code, right? This is how the declarative way or the open shift allows to build your application containers then Let's look at the deploy Thing so basically when need to deploy our applications Usually the application will be standalone or maybe applications also comes with the dependent services For example, we say database message queues and caching systems, right? And probably we need to ship all these applications together in the one floor or we want to deploy all this application in the one floor So open shift provide something called the open shift templates So you can think of it's again one of the declarative form of the yaml where we can define all our application resources Including your applications dependent dependent services, but one of the magic of the template is It allows the parameterizing applications, right? So when you say parameterization to think of the previous example We want to take our builder image or more of like our application image, right? And when we execute our CI CD pipeline, we need to instead of tagging as the latest image like this one We want to tag it with a particular build number or the particular image Sorry particular CI CD version number itself, right? So we can templatize in this way and we can pass all those parameters while executing our CI CD job We'll let them see that how actually we are going to pass those parameters But that's how we can templatize our application workflow and use the same template to deploy our Applications on to the any kind of the environment We just need to customize those specific parameters related to applications while shipping or to the particular target environment And most important part as a developer We need some sort of the DSL Because as a developer probably we are more of not more of like writing the pipeline definition Which 100 lines of the code or the hundreds of the configuration lines, right? So We have something called the declarative ESL APIs that essentially provide a very primitive APIs As we've seen previously take my templates build my applications and deploy to the my target environment We will going to see that how it's essentially forms a declarative APIs, but as well as it's provide some sort of the Jenkins steps or more of like a very fluent DSL APIs that is essentially helps to interact with the open shift and do Execute some complex environments of a for example I want to build an application in the one cluster and then I need to take that application image into the another cluster to Deploy it to the different cluster, right? So it provides my form of the DSL APIs. So for example, if you see The first one we were saying that the declarative APIs if you can see here We are just processing our templates that we have discussed previously Now basically we are taking all the resources generated from this template and building our applications Then we are just declaratively saying that hey take this my applications and deploy to the stage environment Stage environment is it's nothing but my environment where I want to ship and again I want to take the same applications and deploy to the iron or more of like the production environment But with manual approval. So these kind of the pipeline API it provides one of the library we have and The part I was discussing about provide the Jenkins steps. It's something like this We can create the multiple clusters then more of like queries the resources and basically we can do more of like the Interator of the resources, right? So now we don't need to do all those CLIs. I think it's you doing shell scripts So it's provide nice wrapper around your basically OC CLI the way we interact with the OpenChift itself right And so basically but how to get everything is together. So here we have something called the code ready toolchain It's more of like the managed service That allows basically developers to bring you all things together and open-edited way of building Your application of more of like exiting CIC application on the open shift Essentially helps the developers to scaffold your application In a sense it helps to generate the default Jenkins file or more of like the pipeline definition Then provide the templates for your applications and set up all the sorry set up all the webhooks, right? And It basically forms Get everything in the place. So as a developer it is more of like a CI CD as a service But as a developer you can feel awfully feel of it is like I don't want to deal with most of the setup Just give me something out of box where I can go consume it and I can more of like get ready to deploy and code my applications So that's how if we are saying it's more of like wiring everything for your developers Now enough talk Let's see some of the demos and try to understand how everything works and in reality, right? So enough Bob want to go into action and here is what Bob want to do what want to set up a notice applications Essentially an application which says that it's ready to build and deploy But not only deploy in simple way. It's you want to deploy to the stage As soon as we build an application But again, we want to deploy the same applications on the prod with some sort of manual approval, right? But all these things it's going to happen in less than five minutes Let's see things work sure so Here I'm just showing the video recording because it would take some time to do everything but at the end of the demo We are going to see everything and in system. So basically I'm going to the cordy cordy.com. Basically, it's cordy the application. It's a hostage application But I'm creating some space for the time being. Let's keep it abstract. Let's not worry about it And now the next part is like I want to create a notice application And this platform provides some sample templates where we can use to create a simple web services a web service which would provide some hello endpoint and But some sort of the additional feature that really works helps really well with the open shift of the Kubernetes environment So here we are creating one health check applications for the Node.js stack Yeah, here is the most important thing as a user I can select what kind of the application workflow I want to execute here. We are seeing that build my image Roll out to stage and then with the manual approach related to run So once we select that kind of pipeline for our project It just asked to provide the name for your GitHub repository at the end. We just going to review and We are seeing that set of my application at the end Yes, this is how it's things are happening. It's essentially Creating your project in the GitHub repo Then basically configuring everything it's basically wiring all the GitHub web hooks with the Jenkins that is already running in your open shift environment and It's adding your pipeline Done as a developer your kind of all set to do everything now. Let's see actually what is happening behind the scene Yeah, this is the again the open shift console. We can see that it has created the pipeline So as an user as a developer, you don't need to worry about how it's going to create a pipeline for myself Right, but where is my pipeline definition at this moment? So let's see Here you can see the same project has been created in one of the Jenkins, which is running in the users environment Everything is still processing and now let's see some of the things So if you look at the source code of of the project that it has created You have something called the Jenkins files here, which is nothing but your pipeline definitions It's more of like the bunch of the step. It's instruct the Jenkins how to do everything as a CHD workflow And there is something called the dot open shift IO folder that we are going to look at but let's look at the Jenkins files first So it uses the declarative DSL that we were discussing before right. It's called the OCO pipeline Correct, but now let's look at the actually CD definition Think as a developer how declarative it is. It's just simply saying that Put something in the CD block, which is nothing but this continuous deployment put something in the CI block Which is nothing but continuous integration continuous deployment would trigger whenever there is a change in the master And basically CI would trigger then there is when the user or the developer submit a PR to repository But look at it just simply saying that take this the template Pass this the parameters to the template that we have discussed earlier in case of the Ruby image example then we are saying that Whatever the resources generated of processing templates step take those build the applications out of it deploy the application out of it And now let's look at how this template look exactly that template looks like this is the dot open shift IO directory that we are discussing And this is the open shift template That we are discussing now It's kind of the YAML. It's again declarative way But it is essentially taking few of the parameters. So when we run our pipeline So for example when you're executing a pipeline, we can say that use this release version number and tag my image take that image and deploy to my environment and For the time being Let's ignore the image stream, but understand the build config that we have discussed already how to build my applications and So it's again essentially taking very similar form. It's saying that create an image out of it This is my the gate repository. I'm going to provide. This is the commit ID that I'm going to provide here and It this is kind of the builder image that we are going to use Yeah, this is the builder image is going to use that essentially knows how to build your app your application And this is essentially nothing but the deployment config in the services and the routes essentially tells the open shift is basically how to basically deploy your application or basically how to run your containers and basically then Provide a construct to access. It's more of like reader routes and the services So the user can access the application outside of the cluster For the time being in the abstract. That's how we can say that And now This is actually the the first job that is running in your Your Jenkins essentially to executing the OC process that it's more of like the template processing as an user You don't need to worry about how things are being done But essentially the beauty of this DSL is like again, it's leveraging on the same OC CLI that provides by the open shift, right? So nothing magic as such It just brought nice rapper DSL around it. It's taking your build config and It essentially started building your applications It's running building your applications Yeah, we can see that Right and once we see everything is working And now it's we can see that our pipeline is still progressing. Yeah This is how it has basically rolled out our applications To the stage environment and then it's going to ask for the manual approval And then it's going to just process your template and take the deployment Deployment conferences out of it and just going to deploy our applications to the given namespace of the project in the open shift So that's it from the demo And just one demo just want to provide to get the glimpse of as an user How how your CI city pipeline can access the resources from the other clusters, right? So here is just simple definition we are saying that with some sort of the credentials Just query those credentials or more of like for the given project or for the given cluster URL give the project details and more of like By default if you are not going the particular project and the particular cluster then it's going to just print the default Current project working space where it is configured. Now if we see as an output of this pipeline We can essentially see that This is not default project It is actually accessing some other cluster or other project namespace which is running on some other open shift cluster Let's say some other one, but the default one is something like this So the aconode hink is so for example, right? So that's how this As an user you can leverage on this pipeline and still Yeah, so Excuse me So here is how you're trying to make the Bob happy. So he's just not developer now his builder He is able to ship the applications Yes, thank you for listening to this presentation. This is the team. We are working Any questions for stock Sure, so the question is Can we take this code ready set up and just run it on our local setup or it has to be online? Right now. It's it's always it's an online. It's managed service but If you if as an user of the developer you want to take everything it's everything is on the github To be honest, it's not really that well documented But if you understand the Kubernetes and open shift you can take all these things and actually we can spin up all the services on your Open shift cluster because everything is running on the open shift, but to be honest, it's really hard at this moment Yes, we have a plan for At this moment, we are really not sure but it's essentially we are more of like targeting all our Current plans considering the 4.0 as the center, but yes, definitely We may then focus on the previous versions of the open shift So you mean to say Understood you correctly You want to take the existing Jenkins file generations And more of like customize it for the particular Sure we can set up so for example if we go back and look at the first line of our library, right? So basically at this moment there are two things so one thing is the DSL APIs if you're considering Those are more of like can be used with any open shift environment not only this one. That is the first thing right and Second thing is like again You can extend or create the existing pipeline DSLs, right? And probably you can create more of like customized DSL for your enterprise company and probably you can package it and ship it It's quite easy to replace and use that extender version. I'm not sure if it does that answers your question Sure problem probably we can discuss it offline if you want Thank you very much for joining