Unless you're a cave-dwelling CLI geek like me, you might prefer a beautiful web-based dashboard to administer your Kubernetes cluster.
I've recently documented the necessary building blocks to make the dashboard work with your OIDC-enabled cluster, such that a simple browser login will give you authenticated access to the dashboard, with the option to add more users / tiered access, based on your OIDC provider.
authentik does an excellent job as an authentication provider using modern protocols like OIDC. Some applications (like Jellyfin or Harbor) won't support OIDC, but can be configured to use LDAP for authentication.
I recently migrated a Harbor instance from an OpenLDAP authentication backend to Authentik's LDAP outpost, and struggled a little with the configuration.
Now that it's working, I thought I'd document it here so that I don't forget!
Following up on our recent authentik recipe, I've updated our Kubernetes "Essentials" section to include cluster OIDC authentication, provided by authentik (among others).
While I've been a little distracted in the last few months assembling ElfHosted, the platform is now at a level of maturity which no longer requires huge amounts of my time1. I've started "back-porting" learnings from building an open-source, public, multi-tenanted platform back into the cookbook.
What is ElfHosted?
ElfHosted is "self-hosting as a service" (SHAAS? ) - Using our Kubernetes / GitOps designs, we've build infrastructure and automation to run popular self-hosted apps (think "Plex, Radarr, Mattermost..") and attach your own cloud storage ("bring-your-own-storage").
You get $10 free credit when you sign up, so you can play around without commitment!
We're building "in public", so follow the progress in the open-source repos, the blog or in Discord.
The first of our imported improvements covers how to ensure that you have a trusted backup of the config and state in your cluster. Using Velero, rook-ceph, and CSI snapshots, I'm able to snapshot TBs of user data in ElfHosted for the dreaded "incase-I-screw-it-up" disaster scenario.
Check out the Velero recipe for a detailed guide re applying the same to your cluster!
I've been working with a client on upgrading a Cilium v1.13 instance to v1.14.. and as usual, chaos ensued.. here's what you need to know before upgrading to Cilium v1.14...
I've just finished putting together a progress report ElfHosted for July 2023. The report details all the changes we went through during the months (more than I remember!), and summarizes our various metrics (CPU, Network, etc.)
What is ElfHosted?
ElfHosted is "self-hosting as a service" (SHAAS? ) - Using our Kubernetes / GitOps designs, we've build infrastructure and automation to run popular self-hosted apps (think "Plex, Radarr, Mattermost..") and attach your own cloud storage ("bring-your-own-storage").
You get $10 free credit when you sign up, so you can play around without commitment!
We're building "in public", so follow the progress in the open-source repos, the blog or in Discord.
I've worked way more than I expected, and the work has been harder than I expected, but I've immensely enjoyed the challenge of building something fast and in public.
What follows here are our recent changes, the current stats - time/money spent, revenue (haha), and lots of data / graphs re the current state of the platform.
I've consulted on the building and operation of an "appbox" platform over the past 2 year, and my client/partner has made the difficult decision to shut the platform down, partly due to increased datacenter power costs, and capital constraints.
So I've got two year's worth of hard-earned lessons and ideas re how to build a GitOps-powered app hosting platform, and a generous and loyal userbase - I don't want to lose either, and I've enjoyed the process of building out the platform, so I thought I'd document the process by setting up another platform, on a smaller scale (*but able to accommodate growth).
In a previous role as a senior infrastructure architect, one of my responsibilities was to review and approve post-incident reports, and I've come to appreciate how valuable they can be to improve future reliability.
Nothing motivates positive change like the pain of an unplanned outage, which, when you dig deep enough, could have been entirely avoided had you made different choices in the past.
To keep myself sharp in this role, I would pick public post-mortems1, and attempt to analyze them for learnings and ideas that my team could use, without having to make the same mistakes first. I published some of these reviews on my blog, but since I've transitioned to consulting and away from SRE-focused roles, I've not kept up with my reading.
This week I read You Broke Reddit: The Pi-Day Outage, and decided to revive my old habit of reviewing and commenting on nice, juicy outage reports.
, and don't need the java-based headaches of 
