Miniflux is a lightweight RSS reader, developed by Frédéric Guillot. (Who also happens to be the developer of the favorite Open Source Kanban app, Kanboard)
Compatible with the Fever API, read your feeds through existing mobile and desktop clients (This is the killer feature for me. I hardly ever read RSS on my desktop, I typically read on my iPhone or iPad, using Fiery Feeds or my new squeeze, Unread)
Send your bookmarks to Pinboard, Wallabag, Shaarli or Instapaper (I use this to automatically pin my bookmarks for collection on my blog)
Feeds can be configured to download a "full" version of the content (rather than an excerpt)
Use the Bookmarklet to subscribe to a website directly from any browsers
2.0+ is a bit different
Some things changed when Miniflux 2.0 was released. For one thing, the only supported database is now postgresql (no more SQLite). External themes are gone, as is PHP (in favor of golang). It's been a controversial change, but I'm keen on minimal and single-purpose, so I'm still very happy with the direction of development. The developer has laid out his opinions re the decisions he's made in the course of development.
A DNS name for your miniflux instance (miniflux.example.com, below) pointing to your load balancer, fronting your Traefik ingress
Preparation
Prepare traefik for namespace
When you deployed Traefik via the helm chart, you would have customized values.yml for your deployment. In values.yml is a list of namespaces which Traefik is permitted to access. Update values.yml to include the miniflux namespace, as illustrated below:
If you've updated values.yml, upgrade your traefik deployment via helm, by running helm upgrade --values values.yml traefik stable/traefik --recreate-pods
Create data locations
Although we could simply bind-mount local volumes to a local Kubuernetes cluster, since we're targetting a cloud-based Kubernetes deployment, we only need a local path to store the YAML files which define the various aspects of our Kubernetes deployment.
mkdir/var/data/config/miniflux
Create namespace
We use Kubernetes namespaces for service discovery and isolation between our stacks, so create a namespace for the miniflux stack with the following .yml:
Persistent volume claims are a streamlined way to create a persistent volume and assign it to a container in a pod. Create a claim for the miniflux postgres database:
The annotation is used by k8s-snapshots to create daily incremental snapshots of your persistent volumes. In this case, our volume is snapshotted daily, and copies kept for 7 days.
Create secrets
It's not always desirable to have sensitive data stored in your .yml files. Maybe you want to check your config into a git repository, or share it. Using Kubernetes Secrets means that you can create "secrets", and use these in your deployments by name, without exposing their contents. Run the following, replacing imtoosexyformyadminpassword, and the mydbpass value in both postgress-password.secret and database-url.secret:
Deployments tell Kubernetes about the desired state of the pod (which it will then attempt to maintain). Create the db deployment by excecuting the following. Note that the deployment refers to the secrets created above.
Fast-track with premix! 🚀
"Premix" is a git repository which includes necessary docker-compose and env files for all published recipes. This means that you can launch any recipe with just a git pull and a docker stack deploy 👍.
🚀 Update: Premix now includes an ansible playbook, enabling you to deploy an entire stack + recipes, with a single ansible command! (more here)
The db service resource "advertises" the availability of PostgreSQL's port (TCP 5432) in your pod, to the rest of the cluster (constrained within your namespace). It seems a little like overkill coming from the Docker Swarm's automated "service discovery" model, but the Kubernetes design allows for load balancing, rolling upgrades, and health checks of individual pods, without impacting the rest of the cluster elements.
The app service resource "advertises" the availability of miniflux's HTTP listener port (TCP 8080) in your pod. This is the service which will be referred to by the ingress (below), so that Traefik can route incoming traffic to the miniflux app.
The ingress resource tells Traefik what to forward inbound requests for miniflux.example.com to your service (defined above), which in turn passes the request to the "app" pod. Adjust the config below for your domain.
At this point, you should be able to access your instance on your chosen DNS name (*i.e. https://miniflux.example.com)
Troubleshooting
To look at the Miniflux pod's logs, run kubectl logs -n miniflux <name of pod per above> -f. For further troubleshooting hints, see Troubleshooting.
Chef's notes 📓
///Footnotes Go Here///
Tip your waiter (sponsor) 👏
Did you receive excellent service? Want to compliment the chef? (..and support development of current and future recipes!) Sponsor me on Github / Ko-Fi / Patreon, or see the contribute page for more (free or paid) ways to say thank you! 👏
Employ your chef (engage) 🤝
Is this too much of a geeky PITA? Do you just want results, stat? I do this for a living - I'm a full-time Kubernetes contractor, providing consulting and engineering expertise to businesses needing short-term, short-notice support in the cloud-native space, including AWS/Azure/GKE, Kubernetes, CI/CD and automation.
Want to know now when this recipe gets updated, or when future recipes are added? Subscribe to the RSS feed, or leave your email address below, and we'll keep you updated.