 Hello everyone in this video. We'll discuss doing a be deployments using in OpenShift a be deployments is a deployment model that is used commonly these days for For achieving minimum downtime of applications where you would when you whenever you make changes to your application you would want to run more than one version of the application at the same time and then Switch over to the newer version of application over a bit of time. Let's let's look at what how it works let's say you have your application and and a version of your application is running, let's say you deployed a version one of your application and it's running and The end user is accessing this application using a using a URL assigned to this application and there is a router that is front-ending and when you Let's say there are multiple instances of your application running and when the user hits that URL the router takes care of directing the traffic to one of those Instances that are running for application, which is of version one Now let's say you need to make changes to this application and at that point you Introduce a changed version of of this application and in case of AB deployments Instead of turning off the older version of your application and then switching over to the newer version What you would try to do is run both the versions of applications at the same time wherein you would let's say you had four instances of application version one running you introduce just one instance of application version two here, right and Now and you will configure your router to Direct some of the traffic to application version two and If you are happy with how that version two is working, right? then you would increase the number of instances of Version two that you are changes and you will gradually reduce the number of instances of application version one and over a period of time you would You would completely remove application version one and Your application version two takes over from there, right and this also allows you to actually roll back The two application version one if you are not happy with version two then you can scale down the number of instances of version two and Increase the number of instances of version one as desired So you can do the reverse effect if if you wanted to right now This kind of a implementation of a AV deployments Comes naturally out of OpenShift due to the way in which OpenShift itself is architected And let's see how that is how that can be achieved with with what we have Basically if you look at if if you have understood the architecture of OpenShift in the past right OpenShift runs the application instances in OpenShift or Any app runs inside a Kubernetes part, so let's say your Application version one is running and it is running in four different parts. Let's say right and those parts are front-ended by a Service which groups all the parts related to this application. So let us say we have Assigned a label to this application version one and we and we assigned a label called AB member equal to true meaning I am going to be using An a bit deployment model for this application in the future So make me make me as part of this AB member or AB group We are just sitting a random label like that like you you can choose whatever name you want While creating an application we can add a labels For for the service to be able to group your parts based on that label We'll see how to do that in when we are creating an app so Now the service will be configured with a selector to Select all the parts that are with that label AB member equal to true, right and When you expose this service with a route Then your router will be configured to direct all the traffic coming to your application To any of these parts which are selected by using the selector, right? Now with this kind of an architecture being there When you have to introduce a change to the application in in our AB deployment model all you would do is add your Version 2 application the beef be version of the application and assign the same exact label and That's it your service will pick up your new parts based on the same selector that we had assigned to it before and The traffic gets now routed between version 1 and version 2 and eventually you can Just keep version 2 and remove version 1 if you're happy with version 2, right? So that's the model Let's look at the example of how to do that in OpenShift So now I'm logged on to my OpenShift environment on the web console. I am in a project creation screen I'm creating a new project with name avid deployment and I just give a display name and Description as well, and I'll say create this creates the new project and Now let's add an application version a right so on GitHub I have provided a sample code for this I have a simple application what it does is it it shows That it just displays a version number and it says where this part is running is it displays the IP address of the part, right? Now let's take this and apply it Into OpenShift as an application a so I'll go back and I'll use this URL and Since this is a PHP app, I'm selecting PHP I'll call this app a Right and we will since we are going to create a new service and We will be Using our own selectors. I will not create the route for now. I'll just remove the route so I am deploying app a with no route and We'll scale it up later as of now what I'll do is I'll add a label called AB group member is true right So now this label got added and when I create this application any part that gets Created would have that label applied Now this will take a couple of minutes for this application to spin up in the meanwhile. What we'll do is we will use our project C project AB deployment and And Let's look at what deployment configurations exist now there is a deployment configuration for app a that was that's already created So let's edit that We'll see edit DC now If you look at this it has a label AB group member equal to true right That means that any part that gets created will get added this label Now what we'll do is we'll also add this to the selectors right, so I added a selector here to this deployment config now, let us also add a new service to to expose this deployment configuration with this change that we just added right, so we'll add a new service and And So I'm exposing a service the DC app a with the name I'm assigning a name AB service because this is a common service that applies both to application a as well as application B so I'm calling it a B and I mean, it's just a naming convention. I'm using there's nothing you can call it any XYZ It doesn't matter and I am assigning the selector of AB group member equal to true This is the one that we configured right and we are going to generate a new service by default when OpenShift Created this application it would have added a service ignore that we are Creating a new service that can that is configured to with the selector AB group member equal to true right, so let's see If I do OC gets service You will see now there are two services one is that app a which was generated before right And there is a new service that we just added. This is what we are going to use now And this this is a service that we will use to expose via our route Okay, now, let's also create the a route By using this service I will expose service AB service and I'll create a new route with the name let's say AB route and I'll assign a URL a hostname equal to AB deploy okay Now my service is exposed via this route In the meanwhile, the build is still running So let's give it a couple of more minutes for it to be done. So the application is now deployed and Let's see the the build is complete The one part of this application is running Right, so let us and and if you look at the services There is a service that was created along with the application will ignore that and we created our own service a new service and We assigned a URL To expose the service. Let's open this link in a new tab so if I look at it now my Application is now running since there is a single part which is ending with 59, right? Let me show you on the overview page There is one part running that is 10 dot 1 dot 1 dot 59 and that's what is shown here right now Let's do something. Let's scale up this application OC scale EC App a this is the the I'm saying use the deployment configuration app a and scale this application and Set the number of replicas to four Right once I do that watch in the back it does it is spun up four different parts immediately and it's Slowly the parts start Turning into running status right now. They are all running now. Let's do something else We will Now run We'll put a for loop and run a curl to the same URL To see what we get right so the scaling is running. I did a 10-time curl To the same URL that we configured right it says I'm version one I'm version one I'm version all the time this version one and it says the it gives the part number 59 60 66 67 look at it 59 60 66 67 and then It's load balancing the track it's doing in the round robin way like 59 66 66 and again the same things will repeat right so basically we have an application version one and four instances of this application are running and when we are from the client side from the my local machine when I am Accessing this application I am hitting all different parts and My the route is the router is routing the traffic to between load balance the traffic across different parts That's what we have seen so far now Let us do the next step now will Go to the application and we will make a small change here, right? Edit this file. I'll change this to version 2 right now and I'll also Come at this changes I'm not asking OpenShift at this point to update app a to that new version instead what I'm going to do now is create an additional application within the same project right and I'll use the same The same GitHub URL To deploy my application. I'll select the same php 5.5 and This time I'm calling it app B instead of happy right that the first one was happy. This is at B now I'll not create a route because we already have a route and that will take care of this and What we'll do is we'll just create one part. So scaling replicas is set to one by default and We'll edit the labels and we'll give the same exact group membership a be group Member whatever you configured in in the selector for the service that same label name should apply to this these parts as well So and I'll add that Now now I'll create this app B Now open shift will do the source to image process it will go and pick up the source code from this Git repository and it will overlay that source code on the top of the php image It will create an application image and it will then deploy that image and that process will take a Couple of minutes for that to happen the app B is still the the schedule is still waiting to schedule a build Job so we'll give it a minute and and come back. So now the deployment of App B is complete. It was it's successfully build It's pushed into the repository and then now it is deployed and it is running with a single part And that pops parts IP address you can see is ten dot one dot two dot thirty seven right now Let's run that same for loop again As you can see that app a which is the version one is has four instances running, right? And app B which is version two of our application has only one instance running So we should see the same kind of thing when we Look at this the output of this for loop If you see this right there are four instances of app one running So with the drone robin scheduling, you'll see that There is 66 67 59 60 which are the app a parts right those are returning version one and 37 which is 2.37 which is pod Belonging to version two is returning. I am version two right and then this repeats so it's like four results from The from the version one and one result from version two which is Consistent with the number of parts that are running right to move forward with our AB deployment process now Let's say we are happy with The way in which version two is running So let's increase the scale of the number of parts for version two and scale down the number of parts for version one So all I'm going to do is OC scale Deployment configuration app a Replicas I'm going to reduce this to two right and for app B I'll increase this to two so we will have equal number of parts of both right as you can see while I'm making this change It's happening behind us Right behind the screen right you are seeing that the app a has two parts now and Ab B has two parts now it took a second for for those to get into the running status now Let's run that for loop again, right now. We should see that one result is from Version one other result from version two one result from version one other from so it's like it's equally distributed so you have 66 60 returning version one and 68 and 37 Returning version two right so now Let's say you are not happy with the change and you want to roll back you can always scale the App a up But let's assume that app B's the changes we made for app B are good and we can scale app a completely down So let's set the replicas to zero. It's gone You can see that app a there are no parts running at this point of time, right and for app B We'll set the number of replicas to four Our favorite number Now You'll see that quickly this app B has four parts. They are two of them are in the pending status now They're running. Okay. Now. Let's run the for loop again. Everything is version two now, right? So that's how AB deployments Can be achieved in open shift There are some improvements that are expected in this area in terms of assigning the percentages and all But we'll cover them when it comes to that so that's In short the a bit of employment in open shift. Thanks a lot for watching the video