To deploy the sample Blog App, we need to define application resources. We’ve already discussed what our app is composed of. We have defined the application bundle as a Kubernetes manifest file called blog-app.yaml. We need to copy this YAML to the manifests/blog-app directory using the following command:
$ cp ~/modern-devops/ch12/blog-app/blog-app.yaml \
~/mdo-environments/manifests/blog-app/
I’ve prebuilt the microservices and used the required git-sha as the tag, as we did in the previous chapter. You can edit the YAML and replace it with your image for each application.
Once done, commit and push the changes to the mdo-environments repository.
As soon as you push the changes, you should notice that the blog-app application starts appearing in the Argo CD UI in less than five minutes:
Figure 12.14 – Argo CD Web UI – Applications
Wait for the application to progress. Once it turns green, you should see the following within the application:
Figure 12.15 – Argo CD Web UI – blog-app
Now that the application is all synced up, we can check the resources that were created within the blog-app namespace. Let’s list the Services first using the following command:
$ kubectl get svc -n blog-app
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S)
frontend LoadBalancer 10.71.244.154 34.68.221.0 80:3203/TCP
mongodb ClusterIP None 27017/TCP
posts ClusterIP 10.71.242.211 5000/TCP
ratings ClusterIP 10.71.244.78 5000/TCP
reviews ClusterIP 10.71.247.128 5000/TCP
users ClusterIP 10.71.241.25 5000/TCP
As we can see, it lists all the Services that we’ve defined. Note that the frontend service is of the LoadBalancer type and has an External IP. Note down this External IP as we will use it to access our application.
Now, let’s list the pods to see whether all the microservices are running fine:
$ kubectl get pod -n blog-app
NAME READY STATUS RESTARTS
frontend-7cbdc4c6cd-4jzdw 1/1 Running 0
mongodb-0 1/1 Running 0
posts-588d8bcd99-sphpm 1/1 Running 0
ratings-7dc45697b-wwfqd 1/1 Running 0
reviews-68b7f9cb8f-2jgvv 1/1 Running 0
users-7cdd4cd94b-g67zw 1/1 Running 0
As we can see, all pods are running fine. Note that the mongodb-0 pod contains a numeric prefix, but the rest of the pods have random UUIDs. You might recall that when we created a StatefulSet, the pods always maintained a unique ID and were created in order. At first glance, the application seems to be set up correctly. Let’s list the Secrets as well to see whether the mongodb-creds secret has been created:
$ kubectl get secret -n blog-app
NAME
TYPE
DATA
AGE
mongodb-creds
Opaque
2
80s
Here, we can see that the mongodb-creds Secret has been created. This shows us that SealedSecret is working fine.
Now, let’s go ahead and access our application by opening http://<frontend-svc-external-ip>.
If you see the following page, the application was deployed correctly:
Figure 12.16 – Blog App home page
As an exercise, play around with the application by clicking on Sign In > Not a user? Create an Account and then fill in the details to register. You can create a new Post, add Reviews, and provide Ratings. You can also update your reviews, delete them, update ratings, and more. Try out the app to see whether all aspects are working correctly. You should be able to see something like the following:
Figure 12.17 – Blog App posts
As we’re happy with the application, we can raise a pull request from the dev branch to the prod branch. Once you merge the pull request, you will see that similar services will emerge in the production environment. You can use pull request-based gating for CD as well. This ensures that your environments remain independent while being sourced from the same repository, albeit from different branches.
Summary
This chapter has covered continuous deployment and delivery, and we understood the need for CD and the basic CD workflow for a container application. We discussed several modern deployment strategies and how CI tools cannot fulfill those responsibilities. Using the GitOps principles, we created an Environment repository and deployed our GKE-based environment using GitHub Actions by employing the push-based model. Then, we looked at using Argo CD as our CD tool and installed it. To avoid committing sensitive information in Git, such as secrets, we discussed Bitnami’s Sealed Secrets. We then deployed the sample Blog App using Argo CD, using GitOps all the while.
In the next chapter, we will explore another vital aspect of modern DevOps – securing the deployment pipeline.
