Spring Boot CI/CD on Kubernetes using Terraform, Ansible and GitHub

Epilogue — where to from here

This is the final part of a series of articles that created a project to implement automated provisioning of cloud infrastructure in order to deploy a Spring Boot application to a Kubernetes cluster using CI/CD. This is only the starting point and this article looks at options from here.

Follow from the start — Introduction

If you have been following this series, you should now have a fully functioning Spring Boot application and postgres database running on a Kubernetes cluster that is running on cloud infrastructure provisioned using Terrraform and Ansible.

Congratulations are in order!

Where To From Here

As a final wrap up, I want to mention some of the areas that you might want to consider if you want to take this example project further. If this series is useful to people, I may write some of these up on Medium as well so look out for new articles from me.

Clean Up

As we went through this set of articles, you are probably wondering what to do with your nodes now. Well, we only installed things on to the master node. On this node there are things that we create that we no longer need. They were only created for demonstration reasons. You can safely delete these:

• deployment.yml
• service.yml

You probably want to keep the other files in case you want to redeploy any of them.

Local KubeCtl

In this series we have always executed kubectl on the master node. It is possible to set up kubectl on your development machine and connect to your cluster over the Internet.

Extension

You may have noticed that the deployment of ArgoCD was very manual. An exercise you may want to try is to add the deployment of ArgoCD into the configuration of the master node using Ansible.

Ultimately you should be able to create a fully automated creation process that leaves you with only the need to add Kubernetes secrets and ArgoCD applications.

Additional Applications

Your Kubernetes cluster is more powerful than a single application. You might want to use your cluster to host additional applications.

It can manage many applications, including front ends, delivered by way of a proxy such as nginx.

Try adding more applications using ArgoCD.

Helm

In this project we used Helm to load packages from the Helm repository. For the project itself we have used individual manifest files. You can use Helm charts with ArgoCD and one extra step you could perform is to create and deploy Helm charts for your project and deploy these instead.

Centralised Logging

This is a great thing to add. The ArgoCD logging panel is only basic and you can use other tools to bring together all your logs from all your Pods.

Grafana, Loki, prometheus and promtail can be used to create a great logging solution. There are many other options too.

Adding a Reverse Proxy

The Kubernetes solution presented in this series makes use of a virtual private servers on the cloud. This means that the solution (apart from the Terraform REST API configuration) should work for almost any cloud provider.

This design, however, presents services on an unsual port. You may want to use port 80 or 443 for your services. With a full service cloud provider, such as AWS, Azure or Google Cloud, you can change your Kubernetes Service to a LoadBalancer to provide these ingress points.

If you want to stick with the simpler architecture, you can add an nginx or apache reverse proxy to provide this type of ingress point.

Virtual Private Network

In our solution, we have all our nodes accessible to the Internet. This is not recommended and could be a security risk. You can better protect your cluster by isolating it from the Internet and accessing it by Virtual Private Network (VPN), jump or bastion server.

Separate Node for the Database

We have the database and its Persistent Volume (PV) on the master node. This is far from ideal and is better on its own node. You can also explore having a different types of PV for your database.

It is also important to have a backup for your database. In addition, Binary Lane allows you to keep backups of your entire server for a few days for a small additional fee.

Network Security

All of our connections are currently over http. You can improve security by at least ensuring that the traffic up to your ingress point is over Transport Layer Security (TLS). This is easy to achieve with an nginx reverse proxy and a free Let’s Encrypt certificate.

In addition, you can also encrypt the traffic between nodes and between pods for additional security.

Alerting

As a final thought you can look at alerting certain conditions through the use of Slack (or other messaging platform) integration. Linking this in to Grafana allows you to manage your cluster and your application at all levels of the stack.

Summary

I have enjoyed creating this series and I hope you have it informative, interesting and practical. There is a lot more to learn to be able to create professional level stacks but this should have given you a basic understanding on which to build your skills.

Now, if you have finished, you can tear down your stack with:

terraform destroy