- [Instructor] Okay, welcome back. In this lecture, we'll deploy and configure our MongoDB replica set database. In this lecture, we'll provision the following resources to support our cloud-native application. We'll create a stateful set, which is used to provision three pods, each running the official Mongo image. Each pod will mount to its own dedicated persistent volume. And we'll create a headless service. This is used to create individual stable network DNS names for each of the Mongo pods created within the stateful set. 

Okay, let's start. Within the terminal, I'll first run the command sudo yum install -y tmux. tmux is a terminal multiplexer which will give us the ability to split the current terminal session into multiple panes. This is very useful when creating resources in a Kubernets cluster. Okay, now that tmux is installed, let's split up our terminal session by running tmux to split the current terminal into two panes. In one pane, we'll setup a watch to watch the resources being provisioned, and in the other pane, we'll actually run the provisioning command. I've entered the key sequence Control + B together with a double quote. This splits the terminal horizontally. 

The focus is currently on the bottom pane. We'll move focus back to the top pane by entering the key sequence Control + B followed by the up arrow. In the top pane, I'll now navigate into the database directory and list its contents. Here we can see the following YAML file. Next, I'll move focus back to the bottom pane by again entering the key sequence Control + B followed by the down arrow key. In the bottom pane, I'll set up the following watch command to refresh every two seconds. This will allow us to observe the resources as they are created. 

Okay, we are ready to go. Jumping back into the top pane, I'll now run the command kubectl apply -if mongo.statefulset.yaml. Observing the bottom pane, we can see the orderly startup sequence that the stateful set guarantees us. The first container, which is currently in container creating status, takes a little longer to complete, as the Docker image has to first be pulled down. We'll give it more time to complete the entire launch. Great. 

The first Mongo pod is now up and running, and the second Mongo pod has started to launch, and it also has just completed, with the third and final Mongo pod now launching, and has also just completed. Okay, as you can see, each of the three Mongo pods that we just created are named in the sequence that they were started up in. We can also see that the stateful set also has three of three and a ready status. So this is a good result. We can now use the kubectl command to directly examine the pods created as part of the stateful set, like so. 

Again, notice how the pods are named with an ordinal number representing the startup and tear-down order. We'll now enter the Mongo shell on the mongo.0 pod and initialize the Mongo replica set, adding to the replica set the remaining two Mongo pods. Running the following command will give us a shell on the mongo.0 pod, kubectl exec -it mongo.0 bash. Great. We're now on the mongo.0 pod and we can now launch the Mongo shell by running the command mongo by itself. This will connect to the local Mongo service. 

Okay, that succeeded. Let's immediately exit the Mongo shell by entering the key sequence Control + C. Next, we'll quickly test using the Mongo shell to connect to each of the three stable DNS names registered for us, like so. Brilliant. This confirms that the names resolve and that we are able to form network connections to each pod. We can now proceed and configure the Mongo replica set. So we'll jump back into the Mongo shell on the current instance. We then initiate the replica set using the Mongo function rs.initiate, like so. 

Okay, that looks good, but we'll need to fix the name that was registered, as it should use the proper DNS name mongo-0.mongo. We'll fix this after we've added and joined the remaining two Mongo pods into the replica set. To do so, I'll run the following Mongo function, rs.add. Now, this fails, since it's not using the proper DNS name, and therefore is unable to resolve and connect. Let's repeat this command but use the proper DNS name that was registered when the statefulset was created, which is in the form of podname.servicename. Okay, that worked, and we'll now repeat it for the last pod. 

Next we'll go back and fix the name that was registered with the Mongo replica set for the first pod. First we need to capture install the current replica set configuration, like so. We can then print out the current configuration to the screen by entering cfg. We'll now take a closer look at the host value on the first member, and we can see the current value, which needs to be corrected. That is, we need to update it to use the proper stable network DNS name registered for this pod. We'll perform the correction like so. We can then apply the update by running the Mongo function rs.reconfig, passing in the new config and setting force to true. 

Okay, that looks good. Now, before I do a final check, I'm going to first exit out of the tmux session so that we can reuse the full screen again. I'll then jump back into the first Mongo pod, like so, and again fire up the Mongo shell. Here I'll reexamine the updated configuration that we previously applied by running the Mongo function rs.status. Great. We can now see that the Mongo replica set is fully initialized in a functional, redundant configuration. This is indicated by the fact we have a primary and two secondaries. The final thing we'll do while we're still within the current Mongo shell is to create our database and populate it with some sample data that our voting application will work with. 

We'll create the database by running the command use langdb. Next we populate the languages collection with three documents using the insert function, like so. We can then examine all current collections within the current database, and then finally query back out all documents within the languages collection, like so. Brilliant. We've launched, configured, and populated our MongoDB replica set database. At this stage, we're ready to move on and deploy the API resources.