Updating Linkding Deployment With Cloudflare Tunnels
This is an update to my previous post regarding my process for creating a Linkding self-hosted service with FluxCD in my homelab Kubernetes cluster.
You can read the original post here: Creating Linkding Deployment with FluxCD
After getting my Linkding deployment working through my FluxCD GitOps lifecycle, I quickly realized that I was missing some key functionality and configuration steps.
The first one being that my Linkding app wasn't being exposed for me to access locally on my network. It was only accessible from a node in my cluster that could access the cluster IP addresses. This a is problem if I'm planning to use Linkding for all my bookmarks!
The next one being that the Deployment does not declare any superuser account. In the original version of my Deployment I was required to perform an exec command inside the Container to create my superuser name and password before I could ever login. This was using a python script and very tedious! Not what I want if my aim is to have a declarative, stateful Deployment where we could potentially deploy Linkding to a brand new Kubernetes cluster with a superuser already setup and configured. I have the PersistentVolumeClaim setup for the data directory to persist within the cluster, but an initial or bootstrap deploy to a brand new cluster would not result in any superuser account getting setup. This relates to the idea of idempotentency, where I want the Deployment to be applied the first time and any number of times after that without changing the outcome beyond the initial deployment.
These updates support declarative, repeatable deployments of linkding and improves security by not hardcoding credentials.
For a full breakdown of this updated structure to my Linkding Deployment you can check out my homelab GitHub repository at https://github.com/cyberwatchdoug/homelab/tree/main