- [Instructor] Okay welcome back! in this lecture we're going to provide you with a challenge. You might of noticed that the Frontend application is currently viewed with in the browser has a minor defect in it. If you refresh the page, the vote counters all reset to zero. The correct behavior is that they should reset to the currently saved value stored within the backend mongo database. This oversight or defect is intentional and now provides you the opportunity to fix and perform a rolling update back into the cluster. 

The challenge here is to pause the video and attempt to fix this yourself, but before you do I'll provide some basic tips as to how to complete the challenge. A coding change is to required somewhere with in the react source code The frontend docker image will need to be rebuilt and a rolling deployment for the updated frontend docker image should be preformed during the cluster to ensure no down time or impact to end user. As would be the requirement if this was in production. Okay, when you are ready pause the video and give it a go. Best of luck. You can restart the video at any stage and I will walk you through my solution. Okay the correction needs to be applied within the frontend react codebase. Therefore, I will jump back into the following directory. I'll now do a directory listing and then to remind ourselves of the structure within the directory I'll run the following tree command, filtering out with the node and score modules and build directories like so. 

The first correction will apply as to the source components programing language .js file. I'll make the updates using vim I'll turn on my numbers so you can clearly see which lines of code are being updated. For our first edit we need to create and populate a variable called vote count with the votes value which is return back in the AJAX response. To do this we'll simply copy and paste line 34 and then edit it like so. Then on line 40 we'll add a new line count property on the vote component and pass on the value of vote count like so. We'll now save this file and exit. 

Next, we need to edit and update the vote class found within the source components vote.js file. Again, back within vim ill enable line numbers like so. Navigating to lines 5 and 6 I'll update the constructor and the quarter super by passing in props like so. And then down on line 12 I'll simply replace the hard coded 0 set on the vote field within the state. To instill be the value of this.props.count we'll save this file and exit. Okay we're all good to go in terms of the required coding edits. 

Next we need to regenerate a production optimized version of our frontend assets. To do so I'll run the yarn build command. This will compile a new version for us and refresh the contents of the build directory. Okay it looks good. I'll now refresh the terminal and repackage the frontend docker image creating version 2 by running the command Docker build -t for tag cloudacademy frontend V2 for version 2. Excellent, the docker build has completed successfully. Let's now examine the local docker images and insure that version 2 of the frontend now exists. 

Okay, we are now ready to preform the actual rolling update but first, we need to update the frontend deployment YAML file to use version 2 of the frontend docker image. Let's go ahead and edit this file now. I'll jump back into the voteapp kubernetes directory I'll clear the terminal and preform a tree command to see the structure again and here I'll open and edit the following frontend deployment YAML file again using vim now all I have to do is update the frontend image to use v2 instead of v1 as seen here. Before we save and exit notice the rolling update strategy towards the top of the file. When we apply this updated deployment configuration back into the cluster. Kubernetes will be instructed to perform the update. 

Let's now watch this in action. To do so we'll clear the terminal again and launch tmux to give us dual panes on the current terminal session. In the bottom pane I'll put a watch on the current pods and then back up on the top pane I'll apply the updated configuration. Here in the bottom pane we can see the cluster performing the rolling update for us. Where it is updating one pod at a time rather than all at once. Watch, if we did would cause a brief outage which we don't want when we go to production. 

Okay we can see that the existing v1 frontend pods have all been replaced by v2 frontend pods. The acid test now is to refesh the voting application back within the browser and see that the votes are no longer being reset to 0 but rather are restored to the value held currently in the backend MongoDB database. Brilliant, everything has worked the defect has been addressed and corrected and we were able to roll out the change into the cluster without incurring any downtime. Congratulations if you managed to accomplish and solve the challenge on your own. 

Okay that now concludes this lecture. The key take away for this lecture was to understand the workflow required to make a versioned update of the cloud native application together with knowing how to leverage the kubernetes rolling update deployment strategy to maintain up time of the application.