Welcome to our guided exercise, and in this guided exercise, we are going to take a look at how we can scale an application. How we can scale an application manually, and how we can deploy a Horizontal Pod Autoscaler to autoscale an application for us. As I said, we're going to take a look at the manual scalability. Then this is going to be in the OpenShift web console, and then we are going to configure an automatic scalability by using the Horizontal Pod Autoscaler based on the CPU load. Let's take a look at our application in the Visual Studio Code. I can open up the PHP scale application, which is a simple PHP application. This could have been a Node JS application. It is a PHP application just to spice things up, and all it does is print up the host name of the host that it's running on. In our case, it is going to be the name of the port of the OpenShift part that it is running on. As usual, we need to create a branch and the branch for this guided exercise is going to be scale. We need the branch named scale. As usual, you can create a branch from main. You can create the scale branch from main. There we go. Once that it's done. I can click "Source Control". Hide the HelloWorld repository. Let's make this a bit wider and push the DO101 apps. There we go. The scale branch is in my repository. That's all well and good. Now I can use the branch to actually deploy my application. Let's switch to my OpenShift web console. I'm already logged in and I can deploy my application. Switching back the developer catalog. Let's click "All Services" and this is a PHP application. I can select the PHP builder image. We want a S2I application or S2I build process. By this point, we know that we need a builder image, and as usual, we need our repository URL. The Git reference is scale. This is our branch. The context directory is php-scale. Let's verify. What else do we need? Application name and name, and that's about it. Let's do that. Application name, scale, name is scale, and we can keep our deployment as the main resource that will control our deployment pods. We want to expose our route. We don't need to inject any environment variables into this deployment. I can click "Create". Are built is complete. Let's take a look at our application, and there we go. We have our application and our application works because there's only one part the, application output is always the same. Let's close this one and let's spawn more positive scale the application to multiple pods. I can click the application details and scale the application to, let's say, three parts. At this point, if I could click at the "Resources" tab, I see three scale parts. That means that we should have three parts serving our application. Then the problem is that when I open up my application, I still see the same pod is serving my request. The reason for that is that my web browser has cached a cookie, and therefore, the route is by default behaving in such a way that it recognizes my client, and it attempts to reroute the requests to the pod that it rerouted previously. This is not consistent always, but it is consistent enough for our very simple application. What we can do is, we can actually modify the route, and the way we do it is by switching to our OpenShift Web Console. In the Resources tab, we can scroll down into the route section, and I can click the "Scale route". In the scale route, I can select the YAML tab. Here after everything has loaded up, what I want to do is I want to go to the annotations section right at the beginning of the YAML representation. This is the textual representation of the route that OpenShift has created for us. I want to add two annotations. We want to add the haproxy.router.openshift.io/balance is roundrobin. We want to serve the requests in a round robin fashion, and we want to disable cookies. As usual, whenever we modify a YAML file, we have to make sure that the indentation matters. Indentation is the same as the indentation above it. Right now, I need basically four spaces, which is exactly what I have. I have the balance and disable cookies set. Let's save this resource. There we go. Now if I reload, the annotation should stay. If I go back to the topology, this should all stay the same. If I reopen my application, I should be getting different results. Which is exactly what I'm getting. My every request is routed to different application pod. This was a way to manually scale an application up. I can scale it back down. Let's say that we do not need three pods anymore. Instead of three pods, we can have a one pod again. Suddenly we have destroyed the two previous pods, but my application is still up and running. My application did not see any disruption in service. At this point, what we can do is we can actually configure the Horizontal Pod Autoscaler. As we said in the lecture, you could configure it from the web console, and we can do that by using the OC command line utility. Because to be honest, it's simpler, or it's a one simple command that seems quite reasonable. Let's switch to our Visual Studio Code. Let's close this one, because we do not need it. Let's open up a terminal and we need it in the D0101 apps. I am already logged in with my OC Client. I can verify that with OC, who am I. Because I'm already logged in, I can simply create it. I'm using the OC command line utility and I want to auto scale. I want to configure the autoscaler, so I'm using the auto-scale command. Now what am I autoscaling? I'm autoscaling the deployment. The deployment is named scale, am I correct? Yes. We have a deployment, and deployment is called scale. The deployment is called scale, and then we have to configure a few parameters. At minimum, we want to have one pod. At least one pod will always be available for our application. At most, we want to have, for example, three pods, and then we want to configure the CPU percent and for example, to 80 percent. We want to follow the collective CPU percentage of all of the pods to be 80 percent. If it exceeds 80 percent, we want to spawn a new pod. If it falls below 80 percent, we want to destroy a pod up until one pod. Let's configure our CPU percent to 80. That is our oc autoscale command. Let's execute it. There we go. We have our HorizontalPodAutoscaler. In the topology, we do not see any autoscaler. You can actually see that we have an autoscaler by clicking the application, and we see autoscaling pods. That tells you that there's some autoscaling going on. We can actually also switch to the administrator perspective. We can definitely search for it. We can search for the HorizontalPodAutoscaler. This is the auto-generated YAML file that the oc command line utility generated for us. Let's switch back to the developer respective, and we have our scale deployment that is autoscaled for us. Now what do you want to do is we want to simulate the traffic. We want to simulate a lot of traffic going on, and the way we do that is by using, let's clear this one up, and we can actually keep this one up. We simulate it by using the stress application, and the stress application is a simple container file which uses HTTPD base container image, and it uses the Apache benchmark utility, and basically this Apache benchmark utility tries to send as many requests as possible to the scale service host as the scale service port. These are environment variables that are auto injected into the spot by OpenShift for us. We don't have to worry about injecting these environment variables because OpenShift does that for us for free, essentially. Let's deploy this application from the developer catalog. I can select and deploy from our import from Git, and we are on the scale reference. This is the branch. We are in the stress directory. There we go. We have a Dockerfile import strategy, which OpenShift knows how to build and deploy. So then we can change the application name. Application should be create application. Application is stress, and we do not want to create a route to this application, we do not need to expose this application because this is just an internal bench-marking application, right? So that's about it. At this point, we can simply create this application. Okay, so as we see, our stress application has been deployed. Our stress pod is running and right away, I see that my scale application has been auto-scaling to three pods, right? So one is running and multiple are creating, and so we have our stress pod and we can take a look at the logs. Usually, we could do that in the OpenShift console. We can also get the logs from the command line and we'll take a look at that in the future videos. But for now, I can simply get the logs by using all see logs, and we see that the bench-marking has started. So this means that the stress application has started the bench-marking and the PHP application has actually responded to it, or rather the autoscaler has responded to it and has auto-scaled the application, and so when I refreshed the window, we see that the three pods have come up and are running because of the autoscaler. And so now when I reduce the pod to zero, the stress pod, the bench-marking pod to zero. This means that I reduce the traffic, right? I simulate the drop-off in the traffic, and after sometime, the PHP application, scale application will be auto-scaled to zero. Okay, and after some time has passed, this can be quite a bit of time. The autoscaler will recognize that the traffic has reduced and will auto-scale the pods back to one. This was our guided exercise and all we have to do at this point is to clean up our project. So let's delete everything with the app equals stress selector, right? So let's open up our terminal and issue the delete all command. Then we have the delete all app equals scale selector, right? So that's quite simple, and we can delete the Horizontal Pod Autoscaler, and we can delete the scale secrets and stress secrets. So we have oc. We need to delete the GitHub secret as well, and so that does it for our guided exercise, and I'll see you in the next video.
