 In the last video, we saw how developers can point to the code in the Git repository and deploy microservices in their development product. Now, in this video, we'll see how to group these into microservices as a template and deploy these microservices as that template into other areas. So, for example, when you create these microservices in the development project, you are getting build configurations for each of these areas. So, for your email service, you have a build configuration. For your user registration back-end service, there's a build component. For the front-end microservice, there's a build component. For MongoDB, there is none because there is nothing to build there. But the rest of the things are built based on the code. So, there are build configurations. However, when you are moving to other environments, let's say, when you are deploying into production, these builds are not even relevant because you are not going to have builds in the production project. You are going to deploy whatever you have built in your development project into production. There are other things like deployments, the deployment configurations. There are routes that we created. There are services that we created. So, there are so many different objects that get created, and we followed step-by-step approach to create these microservices. So, how do we group them as independent packages of microservices that go together? If you remember from the last video, we used labels to tag these microservices when they were getting created in that development project. Let us say if you want to get the service deployment configuration and route based on the label microservice equal to email service, then we will see all those components that are available in that project with that label. So, we can group together the relevant components based on the labels, as you can see. And we can do the same thing with the user registration service and the front end. So, there is a way to get the relevant components together by using this labeling, and that's the reason why we tagged the microservice components by using the label. So, if you look at the user registration service, we are seeing both MongoDB and user registration service having the same label, and that's the reason why they are grouped together. Now, if you see the packaging structure, we need to deploy this entire unit as a microservice that has this database and the business logic layer, including the pods and services and this particular route. And in case of the user registration front end, we again need the PHP pod plus service plus the route to be packaged together. So, the reason why we did the labeling earlier was to apply those labels to all the relevant pieces so that we can group them together into one package. And that package, in case of OpenShift, is a template. So, let us see how to create that template so that we have a deployable unit which contains all the relevant components together as a group to promote to a different environment. Now, before we create those packages to deploy, there is another thing that we would want to think about. You may want to run n number of instances of your application parts in production. So, when you deploy, maybe you want three instances of your backend service part to run by default. And maybe you want five instances of your front end to run by default. Can you configure that in advance? So, let's increase the number of instances of your backend to three. And let's increase the number of instances of your front end component to five. Now, when I made this change, it went ahead and changed the deployment configurations to replicas equal to three or replicas equal to five. Also, the application was built based on the code, if you remember, and the code can change a number of times. So, when we are deploying this application into a different environment, let's say you want to promote it to production. You want to know which particular version of image you are promoting, right? So, let's assume that the current versions of our images and we want they are ready to be promoted to production. And let us tag those images first. If you want to tag those images, let's get the image streams. First, let us tag the email service image. The latest image is this one and we'll use OC tag, the hashtag for the image and what we are going to tag it as. I'm going to give it a tag promote. Now, if I describe this image again, I have the image with the promote tag. This is the one we are going to use to promote into our production project. And let's do the same thing for the other two images as well, the user registration service and the user registration front end. I'm tagging the user registration front end and I have tagged the user registration service as well. So, now all the three images that we have developed in the development project are tagged as ready to promote to the production environment. Now, we are ready to export those packages that can be deployed as micro services as a unit. So, we are using the OC export command. This is the one used to create a template. And what are we interested in when we are trying to deploy into production, right? We are interested in a deployment configuration that says how the pod should be created. We are interested in the service and the route. And these three components, if they get deployed, your service is ready and running. The first thing that we will do is group all these together into one package for your user registration service back end and we'll export it as a template and I'm giving it a name user registration service micro service. I want the output format as JSON. It's easy to edit and see and I'm saving it into a file. Now, the service is created. I'll open this service. We need to make some minor changes to this service. So, this micro service is a template now. It's a whole package where all the objects are together. There is a deployment configuration object and this is for MongoDB and this MongoDB deployment configuration object has the environment variables for username, password and all that stuff and it has the values that we gave in development. If you want to change it, you can change. You can parameterize it. So, you can replace this with some parameter name, dollar, database password for example and provide those parameters at the end of this template if you wanted to. I'm not going to show how to do that. It's pretty easy but we can cover that in a different session. There is a deployment configuration for your user registration service and then this also has the same exact parameters to be able to connect to the MongoDB. It has that email application domain parameter which expects to talk to the email service. It has the services for the database as well as the business logic layer as well as it has a route. Let's make a small change. This route has a host name and this host name, it just borrowed whatever the host name was there in development. We will remove this host name because we want OpenShift to assign a host name based on whichever project it is deployed into. In the deployment configuration for your user registration service, it is pulling it from the user registration service, latest tag and but we wanted to use the promote tag. Let's replace that as well as we'll also add an additional parameter called namespace here and we'll set it to development project. The reason being your image stream where this image with promote tag is stored is in your development project. So when you are deploying in your production project, you want to pull the image from the development project and deploy. That's the reason why we have to provide this namespace as well. I'm going to say this. Next, we'll create the same exact thing for the email service, email service, micro service. We'll export the deployment configuration for the service. In this case, the route is not relevant because we didn't expose a route for the email service. It is not externally facing and I'll edit this email service for the same exact reasons. I'm going to the triggers. I'm changing it so that it picks the image with promote tag. I have added a namespace label that points to the development project. Next, we'll deal with the third micro service which is the user registration front end. This time we are picking up based on the label to user registration front end. Again, we are exporting this as a template. In this case, we have the route as well. I selected deployment configuration, service and route. I'll edit this file as well. I removed the host name so that we get a value assigned by OpenShift when it gets deployed. I'm getting into the triggers section, changing it so that it uses the user registration image with promote tag and I added my project name as the namespace. I have three templates ready and these are the packages for deploying micro services into my production project. Now let us create another project for production. I'm going to call it MSPROD. I'll go back to my command line and I'll assign the image pooler access to that production project. The image pooler access is assigned to the production project from the namespace micro services developer. I'll switch over to the production project. Let us look at all the micro service templates that we created the packages and we'll process each one of them to deploy. So first the production project is now empty. Let us deploy the email service. All we are saying is process this template and use the result to create whatever the objects are there in this template. It has a deployment configuration and a service. The email project will be deployed. So if you go back and look at what's happening behind the scenes, it's in the production project, it is pulling the email service from the development project and it is creating a part and deploying it. It has already created a service. Now in the same way, let us deploy the user registration back end service. Remember we set the number of replicas to more than one. It would create those many instances of the parts when it processes this template. So now it has created a deployment configuration for MongoDB, the user registration service, business logic, a service for MongoDB, a service for the business logic layer and a route all together with just this one command. So you are taking this package and deploying this whole together into production and all these things are created. Now it's actually creating two different parts for the same service. You are seeing that there's a service deployed. There's a route already assigned and the part is also deployed. So compared to what we did in development, look at what all is happening here. It's doing a bunch of things at the same time. Next we'll deploy the front end service. We'll just process that microservice package template and it creates the deployment configuration and the service and the route. Now we go back and see it's deploying the front end components. It will spin up a bunch of parts for the front end component. So now it is spinning up five instances of the front end, two instances of the back end and a MongoDB and an instance of email service all together. So all we needed was to create that packaging format using templates and have the deployment configuration, service and the routes for the relevant parts and put them together into a package and then use that to deploy into production. So when we are doing in development, you would need the build configuration. When you are in production, you would only need those relevant pieces that need to go to production. So when you hand over from one group to another, you can just hand over that package. So you have seen how to build microservices in a development project, how to package them together using templates and how to deploy them into production. I hope you enjoyed this video series. Thanks a lot for watching.