My Online Portfolio

Home Page

Hello, and welcome to my website!

I have made this website to serve as an online portfolio for my CV and other potential projects.

As someone who is constantly tinkering with computers, I found it was the smart thing to do to post projects of interest to a dedicated and private space for myself and interested parties.

Pi powered

This website is powered by a cluster of Raspberry Pi 4B computers using the K3s kubernetes distribution, allowing for a scaleable and distributed website for optimal performance on low powered machines.

This deployment is running a MySQL database in a StatefulSet configuration, and the WordPress application in a ReplicaSet config. This is combined with both deployments having their own Persistent Volume Claims in an nfs share ran from the master Pi node to ensure no data is stored solely on a single node.

This provides a stable database on one node. This can recover onto another if needed without worry of any data being left behind, as it will connect to the data path used by the previous instance. This is followed by WordPress instances, which can scale from a singular instance up to as many as the user (me) desires. This allows for high performance, as all traffic is routed through the traefik load balancer within K3s.

The ‘Bakery’ cluster up and running. These four computers power this website!

Picture taken in the dark for full Pi and switch light effect.

There are multiple ways to visualise this data that shows what the cluster is running. Here is an example showing all the pods in the ‘wordpress’ namespace.

Above are the pods for the WordPress database and application across the four Pi computers: one from the terminal and the other from the kubernetes dashboard. This is presenting the same data — which pod is running on which node — but presenting it differently.

These pods have been configured in the YAML so that the MySQL database runs on the master node, whilst the WordPress application pods are allocated to the worker nodes. The naming schema shows the name of the deployment, the replica set identifier, and the unique pod identity.

To me… To you…

Hosting a website from your own personal kubernetes cluster is one thing, but how does someone (you) access information I have from my own private network? How does your computer know to point the domain frichardson.co.uk to my ‘Bakery’ cluster? Below is a diagram that shows the overall rough process and flow of information from your device to mine.

As the diagram shows, the request is pointed through Cloudflare’s name severs to the IP of this network. The request on port 443 is then sent to the relevant host, with Nginx Proxy Manager waiting to receive the request. Nginx Proxy Manager then sends this request to the relevant host on the relevant port. This system can be used to host multiple websites and services from within the same network.

Pressure? What pressure?

When it comes to offering online services, whether it’s a simple website such as this one, or incredibly large scale business websites such as Amazon, a question will inevitably come to mind. How much traffic can the website take?

Thanks to tools such as Apache JMeter, you can find out from the comfort of your own home! Apache JMeter is a free piece of software which allows you to load test and measure performance of your target domain. Below are the results of the ‘Bakery’ cluster being put under an intensive stress test, with the MySQL database on worker-03, and WordPress instances on the other three Pi computers.

Above, Image #1, the ‘Bakery’ cluster during a load test.
Below, Image #2, results from Apache JMeter.

Using JMeter and load testing self-hosted applications is a new part of the process for me at the time of writing, so this mostly had to be done with trial and error. Through said trial and error, I discovered that the cluster could handle roughly 150 requests a second to the website, the consequences of which can be seen above in image #1. When going above 150 requests per second, errors started to show in JMeter as the Pis were returning 502 errors which can be seen in image #2.

Interestingly, while the three Pis with the WordPress instances are maxxed out, or close to being maxxed out, the Pi with the database running is only using ~35-45% of its CPU. This means that there is more room to grow with the cluster, and that these WordPress pods could be scaled to 6-8 instances before overwhelming the databse. Assuming linear scaling and that the internal K3s loadbalancer would handle everything with no issues, that means a potential of 300-400 requests per second before issues start to show. This also shows much potential for having the MySQL database on a fully capable x86-64 machine, with a fleet of Raspberry Pis to run the application.

You can do it too!

We’ve reached the end, thank you for reading everything and going through all these concepts I’ve learnt with this project. If you’ve looked at this website and thought that you would like to try it out for yourself, here’s how you can do that. Everything I used/what you need will be in the list below. I hope you have fun with your future projects!