Has your wife been wishing for a way to consume her DRM-stripped audiobooks on her phone, without having to resort to side-loading apps or media? Fear not, for this new recipe has received 10/10 WAF (wife-acceptance-factor)...
When setting up my Mastodon instance, I jumped directly to storing all media in object storage (Backblaze B2, in my case), because I didn't want to allocate / estimate local storage requirements.
This turned out to be a great decision, as my media bucket quickly grew to over 100GB, but as a result, all of my media was served behind URLs like https://f007.backblaze.com/file/something/something-else/another-something.jpg, and could technically be scraped without using my Mastodon URL.
Here's how to improve this, and also serve your Mastodon instance from behind a CloudFlare proxy...
I work on several large clusters, administered using FluxCD, which in which we carefully manage the update of Helm releases using Flux's HelmRelease CR.
Recently, we've started using Renovate to alert us to pending upgrades, by creating PRs when a helm update or an image update in the associated helm values.yaml is available (I like to put the upstream chart's values in to the HelmRelease so that changes can be tracked in one place)
The problem is, it's likely that the images in a chart's values.yaml will be updated when the chart is updated, but I don't need a separate PR for each image! (imagine a helm chart with 10 image references!)
The first time I tried this, I ended up with 98 separate PRs, so I made some changes to Renovate to try to "bundle" associated helmrelease / helm values together...
I'm approaching the end of the journey of applying Velero to a client's "hardened" Kubernetes cluster, and along the way I stubbed my toes on several issues, which I intend to lay out below...
Prior to v0.13, MetalLB was configured using a ConfigMap. This has all changed now, and CRDs are required to perform configuration (which improves syntax checking, abong other things)