Miniflux sur GKE Autopilot

Miniflux est un lecteur de flux RSS/Atom minimaliste et auto-hébergé — un unique binaire Go statique qui stocke tout son état dans PostgreSQL. Ce module déploie Miniflux sur GKE Autopilot au-dessus du socle App_GKE, qui provisionne et gère l'infrastructure Google Cloud et Kubernetes partagée.

Ce guide se concentre sur les services cloud qu'utilise Miniflux et sur la manière de les explorer et de les exploiter depuis la console Google Cloud et la ligne de commande. Pour les mécanismes communs à toute application GKE — Workload Identity, entrée, autoscaling, CI/CD, Cloud Armor, IAP, Binary Authorization, VPC Service Controls, sauvegardes et cycle de vie du déploiement — reportez-vous au guide du socle App_GKE plutôt que de les répéter ici.

1. Vue d'ensemble

Miniflux s'exécute comme une charge de travail web Go à conteneur unique. Le déploiement assemble un ensemble ciblé de services Google Cloud :

Fonctionnalité	Service Google Cloud	Remarques
Calcul	GKE Autopilot	Un seul binaire Go dans un Deployment, mis à l'échelle horizontalement entre `min`/`max` réplicas
Base de données	Cloud SQL for PostgreSQL 15	Obligatoire — Miniflux stocke tout son état ici ; pas de MySQL ni d'autre moteur
Stockage objet	Cloud Storage (aucun)	Miniflux n'a besoin d'aucun bucket ; un montage NFS Filestore facultatif est disponible mais inutilisé par défaut
Cache et file d'attente	Aucun	Miniflux ne dépend pas de Redis et n'a pas de worker séparé
Secrets	Secret Manager	`ADMIN_PASSWORD` généré automatiquement (propriétaire initial) ; mot de passe de la base de données
Entrée	Cloud Load Balancing	LoadBalancer externe avec affinité de session `ClientIP`, domaine personnalisé et certificat géré facultatifs

Valeurs par défaut judicieuses à connaître d'emblée :

PostgreSQL 15 est obligatoire. Le moteur de base de données est fixé par la couche applicative partagée ; choisir un autre moteur empêche le démarrage.
Le collecteur de flux s'exécute dans le processus. Miniflux n'a pas de worker séparé — le même pod sert l'interface et actualise les flux selon POLLING_FREQUENCY. Gardez au moins un réplica actif pour que la collecte se poursuive (GKE ne descend pas à zéro).
Le propriétaire initial est pré-créé, pas auto-inscrit. CREATE_ADMIN = 1 crée le compte admin à partir du secret ADMIN_PASSWORD au premier démarrage ; l'inscription libre en libre-service reste désactivée. Récupérez le mot de passe dans Secret Manager pour vous connecter.
Les migrations de schéma s'exécutent au démarrage (RUN_MIGRATIONS = 1) — il n'existe pas de job de migration séparé, de sorte que la mise à niveau de la version applique automatiquement les changements de schéma.
Pas de Redis. enable_redis = false — Miniflux conserve chaque flux, entrée et session dans PostgreSQL. Laissez-le désactivé. Comme il n'y a pas de file d'attente partagée, exécuter plusieurs réplicas revient simplement à répartir la charge des requêtes (chacune continue de collecter les flux indépendamment).
L'affinité de session est ClientIP. Elle maintient un client sur un même pod pour une session d'interface cohérente.
DATABASE_URL est composée à l'exécution par le point d'entrée du conteneur (forme mot-clé/valeur de libpq), selon le loopback de l'Auth Proxy GKE (127.0.0.1, sslmode=disable), afin que la même image fonctionne sur Cloud Run et GKE.

2. Services Google Cloud et comment les explorer

Toutes les commandes supposent que vous avez exécuté gcloud container clusters get-credentials <cluster> --region <region> --project <project> et que PROJECT, REGION et NAMESPACE sont définis. L'espace de noms et les autres identifiants sont indiqués dans les sorties du déploiement.

A. GKE Autopilot — la charge de travail Miniflux

Les pods Miniflux s'exécutent comme un Deployment sur Autopilot qui écoute sur le port 8080, facturé selon la CPU et la mémoire qu'ils demandent. L'autoscaling horizontal des pods dimensionne le déploiement entre le nombre minimal et le nombre maximal de réplicas.

Console : Kubernetes Engine → Workloads → sélectionnez la charge de travail Miniflux pour voir les pods, les révisions et les événements. Kubernetes Engine → Services & Ingress affiche l'IP externe.

CLI :

kubectl get pods,svc,hpa -n "$NAMESPACE"
kubectl logs -n "$NAMESPACE" deploy/<service-name> --tail=100
kubectl describe hpa -n "$NAMESPACE"          # current vs target utilisation

Consultez App_GKE pour la gestion d'Autopilot, de la mise à l'échelle et du type de charge de travail (Deployment ou StatefulSet).

B. Cloud SQL for PostgreSQL 15

Miniflux stocke toutes les données applicatives (flux, entrées, utilisateurs, sessions, catégories) dans une instance gérée Cloud SQL for PostgreSQL 15. Les pods y accèdent de manière privée via le sidecar Cloud SQL Auth Proxy sur le loopback (127.0.0.1) ; aucune IP publique n'est exposée. Au premier déploiement, le Job db-init crée la base de données et le rôle miniflux et installe l'extension hstore, dont le rôle applicatif est propriétaire.

Console : SQL → sélectionnez l'instance pour voir les connexions, les sauvegardes, les flags et les métriques.

CLI :

gcloud sql instances list --project "$PROJECT"
gcloud sql instances describe <instance-name> --project "$PROJECT"
# Open an interactive shell to inspect schema/data:
gcloud sql connect <instance-name> --user=miniflux --database=miniflux --project "$PROJECT"

Le nom de l'instance, la base de données, l'utilisateur et le secret du mot de passe figurent dans les sorties. Pour le modèle de connexion, les sauvegardes automatisées et la rotation des mots de passe, consultez App_GKE.

C. Cloud Storage et NFS

Miniflux n'a besoin d'aucun stockage objet — il conserve tout son état dans PostgreSQL, de sorte que la couche applicative ne provisionne aucun bucket de données. La variante définit toutefois par défaut enable_nfs = true (un montage Cloud Filestore sur /opt/miniflux/storage) pour les opérateurs qui souhaitent un stockage partagé des pièces jointes, mais Miniflux n'en a pas besoin ; désactivez-le pour réduire les coûts si vous n'en avez pas l'usage.

Console : Filestore → Instances (si NFS est activé) ; Cloud Storage → Buckets.

CLI :

gcloud filestore instances list --project "$PROJECT"
gcloud storage buckets list --project "$PROJECT"

Consultez App_GKE pour les options CMEK et les montages GCS Fuse.

D. Secret Manager

Un secret est généré automatiquement : ADMIN_PASSWORD — le mot de passe du propriétaire initial, injecté dans Miniflux au premier démarrage. Le mot de passe de la base de données est géré séparément par le socle.

Console : Security → Secret Manager.

CLI :

gcloud secrets list --project "$PROJECT" --filter="name~miniflux"
gcloud secrets versions access latest --secret=<secret-name> --project "$PROJECT"

Le nom du secret du mot de passe de la base de données figure dans les Sorties. Consultez App_GKE pour l'intégration Secret Store CSI et la rotation.

E. Réseau et entrée

Par défaut, la charge de travail est exposée via une IP Cloud Load Balancing externe avec une affinité de session ClientIP. Un domaine personnalisé avec un certificat géré par Google peut être activé, et une IP statique peut être réservée afin que l'adresse survive aux redéploiements. Lorsqu'un domaine personnalisé est utilisé, définissez BASE_URL pour que Miniflux produise des liens absolus corrects.

Console : Network services → Load balancing ; VPC network → IP addresses.

CLI :

kubectl get ingress,svc -n "$NAMESPACE"
gcloud compute addresses list --project "$PROJECT"

Consultez App_GKE pour les domaines personnalisés, Cloud CDN et les IP statiques.

F. Cloud Logging et Monitoring

Les sorties stdout/stderr des pods sont envoyées à Cloud Logging ; les métriques GKE et Cloud SQL sont envoyées à Cloud Monitoring. Des tests de disponibilité et des règles d'alerte facultatifs sont disponibles. Le point d'entrée journalise au démarrage son mode de connexion DATABASE_URL — utile pour diagnostiquer la connectivité à la base de données.

Console : Logging → Logs Explorer ; Monitoring → Dashboards / Alerting.

CLI :

gcloud logging read 'resource.type="k8s_container" AND resource.labels.namespace_name="'"$NAMESPACE"'"' \
  --project "$PROJECT" --limit 50

3. Comportement de l'application Miniflux

Configuration de la base de données au premier déploiement. Le Job db-init exécute db-init.sh avec postgres:15-alpine. Il se connecte via le Cloud SQL Auth Proxy et crée de manière idempotente la base de données et le rôle miniflux, accorde les privilèges, réattribue la propriété du schéma public et installe l'extension hstore dont le rôle applicatif est propriétaire (afin que la migration Miniflux v119, qui supprime hstore, réussisse). Le job envoie ensuite une requête à /quitquitquit sur le sidecar du proxy pour que le pod du Job se termine ; il peut être relancé sans risque.
Migrations de schéma au démarrage. Le point d'entrée définit RUN_MIGRATIONS=1, de sorte que Miniflux applique ses propres migrations de schéma à chaque démarrage — pas d'étape de migration séparée. Prévoyez un délai supplémentaire au premier démarrage pour la construction initiale du schéma.
Le propriétaire initial est pré-créé. CREATE_ADMIN=1 crée le compte admin (ADMIN_USERNAME) à partir du secret ADMIN_PASSWORD. L'opération est idempotente — les démarrages suivants journalisent « user already exists ». Récupérez le mot de passe pour vous connecter :
```
gcloud secrets versions access latest \
  --secret=secret-<resource-prefix>-miniflux-admin-password --project "$PROJECT"
```
Chemin de santé. Les sondes de démarrage et de vivacité de ce module ciblent par défaut HTTP / (la page de connexion, un 200 OK sans authentification). Miniflux renvoie également un 200 OK sans authentification sur /healthcheck si vous préférez un chemin de sonde dédié. Ne dirigez pas les sondes vers des pages authentifiées.
Le collecteur de flux s'exécute dans le processus. Les flux sont actualisés selon POLLING_FREQUENCY dans chaque pod. Gardez min_instance_count >= 1 pour que la collecte s'exécute ; les réplicas supplémentaires collectent chacune indépendamment (aucune file d'attente partagée ne les coordonne).
BASE_URL détermine les liens absolus. Sa valeur par défaut est l'URL du service interne injectée ; définissez-la explicitement (via environment_variables) sur l'URL du LoadBalancer externe ou du domaine personnalisé une fois l'adresse connue.

Inspecter le job db-init et les pods :

kubectl get jobs -n "$NAMESPACE"
kubectl logs -n "$NAMESPACE" job/<job-name>

4. Variables de configuration

Les variables sont regroupées exactement comme elles apparaissent sur la plateforme de déploiement. Seuls les paramètres propres à Miniflux ou notables pour lui sont listés ; toutes les autres entrées sont héritées d'App_GKE avec leur comportement et leurs valeurs par défaut standard.