Local Setup with Rancher Desktop

The selected technical stack for this application comprises a Kubernetes cluster for handling backend requests, a PostgreSQL database cluster, and a static site supported by a Content Delivery Network (CDN). This setup, while not the most straightforward for hosting a web application, offers scalability and robust security.

Local Hosting

To develop and test the various components of the application, we employ Rancher Desktop with the Kubernetes feature enabled. This approach enables us to rigorously test and optimize our configurations in a local environment before proceeding to establish the development cluster. By adopting a local-first strategy, we aim to create a testing environment that closely mirrors the development and production settings, although it will be a very foggy mirror.

Rancher Desktop, available at https://rancherdesktop.io/, serves as an open-source substitute for Docker Desktop, utilizing https://k3s.io/ for the Kubernetes distribution and https://containerd.io/ for container runtime. It also provides compatibility with all Docker-related CLI commands.

Networking and security aspects of the application will be managed using

https://cilium.io/. Cilium provides robust support for the Gateway API, essential for managing ingress, and helps manage how data comes in and out of our app and gives us good control over our app’s network communication with Cilium Service Mesh: https://cilium.io/use-cases/service-mesh/.

In terms of database selection, PostgreSQL (https://www.postgresql.org/) stands out due to its widespread adoption and extensive tool support. While local development will see PostgreSQL running on the Kubernetes cluster, the production environment will transition to a cloud provider’s hosted version.

The installation process for MacOS can be found at https://garunski-co.github.io/scry-commons/local.

Initial Issues and Caveats

Sometimes the Persistent Volume Claim (PVC) for our database loses its binding and the database is cleared. I also ran into some problems with the default virtual machine for Rancher Desktop, QEMU, especially with network routing. Switching to the Experimental VZ Apple Virtualization framework helped fix these issues. When setting up Gateway API HttpRoute, if we don’t specify host values, we can use the Gateway IP address to route traffic. But this doesn’t work if we do set host values. Lastly, we are currently using the Node’s IP address for the Gateway, which means we can only have one Gateway in our local cluster.