 Hello, everyone. Often you end up in situations where you want to deploy your applications and you want those applications to run on specific nodes or specific parts of infrastructure. Or maybe you have your application made up of multiple components. And for example, you may want your front end to run on specific infrastructure, your database to run on some other part of the infrastructure. So you want your application components to run on different parts. So let's talk about how we can do that in OpenShift and how you want to run your application components on different nodes. In my OpenShift environment, I have a set of nodes. If you look at the nodes, I did some labeling. There is one node which is an infrastructure node and I labeled it as infra. But there are four nodes that I want to use to deploy my applications. And if you look at the labels, there are two nodes that have categorized as region equal to secondary and region equal to primary. So node one and node two are in the secondary region. Node three and node four are in the primary region. Now these labels, regions, and zones are just the names that we use because they come as set up by default. But you can choose to use whatever names you want. And the policies that based on which the scheduler makes a decision on where to deploy your application component depends on these labels. Now as a first example, let's look at how the OpenShift behaves by default and how we can configure the default behavior for the scheduler to make a selection of where to place your applications. So for that, in the OpenShift's master configuration file, you can set up a default node selector. And in my case, I set it as region equal to primary, which makes sure that if I don't provide any values on, or if I don't provide any configuration while deploying my application on where to place my application parts, those application parts will land up in region equal to primary. So the OpenShift administrator in my case has set up the default node selector in the configuration file as region equal to primary. If I don't provide any other selection, my application parts will land on the nodes that are labeled as region equal to primary. Let's verify that by deploying an application. I'll create a new project. And I'll deploy an application with a simple app. I'm just deploying whatever is the default. Let's see where it lands up. It takes a moment to build and deploy. The application is now running. A new pod is up. The pod is on node three, which is in the region primary. So by default, the pod land up on one of the nodes, which is node three, which is in the region primary. Let us try to scale up. I'll scale to two parts. Now, if you look at where the second pod is getting spun up, the second pod is on node four. So again, node three and node four are both in the region primary. If I scale up further, all the parts that get added will be either on node three or node four. So let me go to a different view. So these are all pods. Every pod is either on node four or node four, node three, node three, node four, node three. So they're all landing up in region which is labeled as primary. Now I'll clean up this project and we'll see how we can change this project configuration in such a way that any pods that are created in this project will land up in region secondary instead of primary. In order to do that, the OpenShift administrator needs to edit the project configuration to add a node selector to the namespace. So as an administrator, I got into the namespace for the new project and I'm adding a new annotation and the node selector here says region equal to secondary which means that any pods created in this project will end up in this region. Now let's go back and create the same application and see what happens. The application is getting built and it will get deployed. The app is now running and it is on node one. Node one is in the secondary region. Now if I again scale up, all the pods are either on node one or node two, node two, node one, node one. So everything lands in the secondary region. If I try to add another application component, let's say I had a MySQL database here, I have a second application component that's starting up and even this part is on node one which means it is in the same secondary region. So now we have the default as region primary and we have forced the namespace with an annotation of where we said node selector region equal to secondary and all the pods in spite of the default being region equal to primary, they are landing upon in the secondary region on one of these nodes, right? Now note that the default node selector configuration for OpenShift as well as the node selector configuration for individual projects is done by the OpenShift administrator. The administrator defines where pods created for any project should land. Now let us say you want the administrator to give you freedom to choose between primary and secondary as and as a developer you wanna choose where you want your application components to land up between these regions, right? How do we do that? That's the next use case. So as an administrator, we'll go and edit that namespace. As an administrator, I'm editing this namespace to have a node selector value as blank, empty string. Note that I am not deleting this node selector configuration. If I delete it, the default would apply. I don't want to delete it but I want the users of this project to be able to deploy the application to any region they want. So I'm just making it blank. Now back as a developer, I'll go back and delete all the contents of this project. Now let's add an application component. Again, I'll deploy my SQL database. Since we don't have any restriction now, it can land either on nodes within primary region or secondary region. So it could be anywhere, right? So the pod is now up. Let's see where it is. The pod is coming up and it would come up on node two. And node two is in the secondary region, right? In spite of the default region being primary, since the node selector is empty, the default did not get applied and the pod landed up in node in the region secondary. It is from the developer's point of view, right? How do I force this mySQL pod to land in the primary region? There are a couple of ways to handle that. Let's look at the deployment configurations. So the first way, we'll edit the deployment configuration for mySQL. I open the deployment configuration for mySQL and go to the spec under the template. This template represents how the pod's template is going to look like. And under this template, where you see spec, we'll add the node selector here. So our pod landed up on secondary, so we will force it to go to primary and I just made this change. Now, if I look at oscget pods, once I made this change, a new deployment would have started immediately, right? It's a deploy is running now. And you can see that the old pod went away and a new mySQL pod is getting deployed. Earlier one was OHTR, the new pod, it's mySQL2j71kd, right? This is the new pod that's coming up. So let's see where this new pod will land up, j71kd mySQL2, right? And this pod is on node four and node four is in the region primary, right? So just by changing the deployment configuration and adding a node selector in the deployment configuration, we moved the pod that was running, that landed up in the secondary region to the primary region and making the reverse change will again move the pod from primary region to secondary region. So it can land on any of these nodes, but you can force a region in the pod by changing the deployment configuration. So as a developer, this is the third way of doing it. You have control on where you want your pods to land up. Now the next example, another scenario, right? I have multiple application components in my application. Maybe I have, I want my database to land up on a different set of nodes. I want my application logic components to run on a different set of nodes. Let's say you want to divide it that way and you want your regions where your database runs to be separate from the region where your application logic turns, let's say, whatever your needs are, right? If you want to do it that way, what else are the possibilities? I mean, do I have to do it each individual component by changing the deployment configuration for each component separately? Or is there a way I can apply all these node selectors across different components in my architecture? Like in OpenShift, we have templates, right? So can I make this kind of a change in a template? And the answer is yes. So let's look at an example of same kind of a change in a template. I clean up the project again. So we will copy an existing template and edit it. So let's look at what templates we have. I'm interested in a template that has multiple components. So let's pick up this one, cake, PHP, MySQL example. Now we will get hold of this template. I'm searching for all the templates in the OpenShift project. Remember, all the templates are stored in the OpenShift project and I'm trying to find that specific template of my interest. The name starts with cake, PHP. So I'm looking at this cake, PHP, MySQL example. This has both PHP and MySQL. It deploys two components. So we'll pick up this template. I want to get this output of this template as a JSON file. And let me save that file. So now I have my template copied in, copied locally into this file. Let me open this file in an editor. And so we are looking for this template and this template has a spec that it deploys two different kinds of containers. One is a PHP and the other is MySQL. I'll add node selectors. We want to deploy the PHP part of the application in the secondary region. Again, I'm looking for the template for the database and for the database part, I want my database to be deployed in the primary region. I also want to change the metadata of my template so that I give it a different name and I'll also make another change to, I'll be using this template in my local project. So I'm also changing the namespace to deploy this template into the new project namespace. So I made totally four changes to this template. One, I changed the name of the template. I changed the namespace in which this template is going to be used. I have made a change to the deployment configuration part of the PHP part to get deployed into the secondary region. And I made a change to the deployment configuration part of the MySQL part to deploy into the, and then I will create a template in my project. So all I'm saying here is process this JSON file which has the specifications for the template which will end up creating this template in my project. So this template is now created. So if I say under this project, it shows the new template that I just added. Now let's go back to the project and this is the template that we just added. We'll use this template to deploy our application and this template deploys a PHP component as well as a MySQL. Just go ahead and say create. It's trying to deploy both the components. The MySQL is already deployed. Let's see where this part is running. This part is being spun up on node three. It's running on node three now. Node three is in the primary region. That's where we wanted our MySQL to get deployed. And we wanted the PHP part to be deployed in the second region, which is one of the node one and node two. The PHP application is being built. It'll take a couple of minutes for it to get deployed and the PHP part is now running in on node two, which is in the secondary region. This is an example of how you can change the templates to add node selectors so that when you have a bigger configuration, you can direct the individual application component parts, the parts of the application to go to different regions if you wanted to, right? Or different set of nodes if you wanted. To summarize, we discussed different ways of deploying the applications to the nodes of our choice. First, we covered how the default works for the entire environment. The administrator would set up a default node selector in the project configuration of the master config file, which will make sure that any project that gets created gets into that default node selector that is defined here if no other values are used by the user. Second, we talked about how you can define those, the node selectors at the project level, where any components that are within that project would go into whatever labels are given in the node selector. Third, we talked about leaving the node selectors at the project level open, but providing node selectors in the deployment configurations of the individual application components that are within the project so that you are directing those particular components to go to specific nodes. Fourth, we also talked about complex situations where you have a bunch of components getting deployed together using a template where you can go and edit the deployment configurations within the template so that when the individual components gets spun up, they go into the specific regions of your choice. So different ways to solve the problem. And each one has its own value. So use whatever makes sense for your situation. Thanks a lot for watching this video.