Budibase sur GKE Autopilot

Budibase est une plateforme low-code open source permettant de créer des outils internes, des applications métier et des workflows à partir de vos données. Ce module déploie Budibase sur GKE Autopilot en s'appuyant sur le socle App_GKE, qui provisionne et gère l'infrastructure Google Cloud et Kubernetes partagée.

Ce guide se concentre sur les services cloud utilisés par Budibase 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 à toutes les applications 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

Budibase s'exécute sous la forme d'un unique pod tout-en-un. L'image officielle budibase/budibase regroupe CouchDB + MinIO + Redis ainsi que les applications/le worker/le proxy de Budibase, et sert le HTTP sur le port 80 — il n'y a aucune base de données gérée externe. Comme tout l'état réside dans /data, la variante GKE s'exécute en tant que StatefulSet avec un PVC en mode bloc monté sur /data. Le déploiement assemble un ensemble ciblé de services Google Cloud :

Fonctionnalité	Service Google Cloud	Remarques
Calcul	GKE Autopilot	Un seul pod tout-en-un, 2 vCPU / 4 GiB par défaut ; s'exécute en un seul réplica (min = max = 1)
État persistant	Persistent Disk (PVC en mode bloc)	`stateful_pvc_enabled = true` → StatefulSet avec un PVC de 20 GiB monté sur `/data`
Base de données	Aucune (CouchDB intégré)	`database_type = "NONE"` — CouchDB, MinIO et Redis s'exécutent tous dans le pod
Stockage d'objets	Cloud Storage	Un bucket de données provisionné automatiquement ; le stockage d'éléments propre à Budibase est le MinIO intégré
Cache et file d'attente	Redis intégré	S'exécute dans le pod sur l'interface loopback ; `enable_redis` est désactivé par défaut
Secrets	Secret Manager	Sept identifiants internes générés automatiquement, injectés comme variables d'environnement secrètes du service
Entrée	Cloud Load Balancing	Service LoadBalancer externe par défaut ; domaine personnalisé + certificat géré en option

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

StatefulSet avec un PVC en mode bloc sur /data. stateful_pvc_enabled = true (par défaut), ce qui résout automatiquement workload_type en StatefulSet. Tous les documents CouchDB et objets MinIO persistent sur un PVC standard-rwo de 20 GiB monté sur /data ; les données survivent donc aux redémarrages de pod et aux redéploiements.
S'exécute en un seul réplica. min_instance_count = 1 et max_instance_count = 1. Le pod tout-en-un conserve tout son état sur son propre PVC ; plusieurs réplicas ne partageraient donc pas les données (split-brain).
Sept identifiants internes sont générés automatiquement et stockés dans Secret Manager (INTERNAL_API_KEY, JWT_SECRET, MINIO_ACCESS_KEY, MINIO_SECRET_KEY, API_ENCRYPTION_KEY, REDIS_PASSWORD, COUCH_DB_PASSWORD). Ils ne doivent jamais faire l'objet d'une rotation après le premier démarrage — les données de /data sont chiffrées avec eux et deviennent illisibles s'ils changent.
Le port 80 est fixe. Le proxy nginx de l'image tout-en-un sert l'ensemble de l'application sur le port 80 ; container_port et les sondes du pod sont donc fixés à 80.
Aucune base de données externe ni job db-init. Budibase provisionne lui-même CouchDB et MinIO au premier démarrage ; database_type vaut NONE par défaut.
LoadBalancer externe par défaut. service_type = "LoadBalancer" expose une IP externe ; une IP statique et un domaine personnalisé peuvent y être ajoutés.

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 Budibase

Budibase s'exécute sous la forme d'un pod StatefulSet sur Autopilot, qui facture le CPU et la mémoire demandés par le pod. Comme il conserve tout son état sur son PVC, il s'exécute en un seul réplica.

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

CLI :

kubectl get statefulset,pods,svc,pvc -n "$NAMESPACE"
kubectl logs -n "$NAMESPACE" statefulset/<service-name> --tail=100
kubectl describe pod -n "$NAMESPACE" -l app=<service-name>

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

B. État persistant (PVC en mode bloc sur `/data`)

Tout l'état de Budibase — le magasin de documents CouchDB et le magasin d'objets MinIO intégrés — persiste sur un Persistent Disk en mode bloc provisionné via le modèle de PVC du StatefulSet (stateful_pvc_size = 20Gi, stateful_pvc_storage_class = standard-rwo) et monté sur /data. C'est ce qui fait de GKE la plateforme durable pour Budibase.

Console : Kubernetes Engine → Storage → Persistent Volume Claims ; Compute Engine → Disks.

CLI :

kubectl get pvc -n "$NAMESPACE"
kubectl describe pvc -n "$NAMESPACE" <pvc-name>
# Confirm the /data mount inside the pod:
kubectl exec -n "$NAMESPACE" statefulset/<service-name> -- df -h /data

C. Magasin de données (CouchDB + MinIO intégrés)

Il n'y a aucune instance Cloud SQL — database_type = "NONE". CouchDB et MinIO s'exécutent dans le pod et persistent sur le PVC /data. Inspectez-les via le pod plutôt que via une console de base de données gérée :

CLI :

# Confirm database_type=NONE and the bundled-service env in the running pod:
kubectl exec -n "$NAMESPACE" statefulset/<service-name> -- env | grep -Ei 'couch|minio|redis'

D. Cloud Storage

Un bucket Cloud Storage dédié (suffixe de nom storage) est provisionné automatiquement. Le stockage d'éléments/de pièces jointes propre à Budibase est le MinIO intégré sur /data ; ce bucket GCS est disponible pour l'intégration du stockage au niveau du socle.

Console : Cloud Storage → Buckets.

CLI :

gcloud storage buckets list --project "$PROJECT"
gcloud storage ls gs://<data-bucket>/          # bucket name is in the Outputs

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

E. Redis (intégré)

Redis s'exécute dans le pod sur l'interface loopback et s'authentifie avec le REDIS_PASSWORD généré automatiquement. enable_redis est désactivé par défaut — n'activez pas de Redis externe sauf pour externaliser délibérément le cache.

CLI :

kubectl exec -n "$NAMESPACE" statefulset/<service-name> -- env | grep -i redis

F. Secret Manager

Sept identifiants internes sont générés automatiquement et stockés dans Secret Manager, puis injectés comme variables d'environnement secrètes du service : INTERNAL_API_KEY, JWT_SECRET, MINIO_ACCESS_KEY, MINIO_SECRET_KEY, API_ENCRYPTION_KEY, REDIS_PASSWORD et COUCH_DB_PASSWORD. Ils ne doivent jamais faire l'objet d'une rotation après le premier démarrage.

Console : Security → Secret Manager.

CLI :

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

Consultez App_GKE pour l'intégration Secret Store CSI et Budibase_Common pour ce que protège chaque secret.

G. Réseau et entrée

Par défaut, la charge de travail est exposée via une IP Cloud Load Balancing externe (service_type = "LoadBalancer"). 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.

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

CLI :

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

Consultez App_GKE pour les domaines personnalisés, Cloud CDN et les détails sur l'IP statique.

H. Cloud Logging et Monitoring

Les sorties stdout/stderr des pods sont envoyées vers Cloud Logging ; les métriques GKE vers Cloud Monitoring. Des tests de disponibilité et des règles d'alerte sont disponibles en option.

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 Budibase

Aucune initialisation de base de données externe. Avec database_type = "NONE", il n'y a pas de job db-init. Budibase provisionne lui-même ses CouchDB et MinIO intégrés au premier démarrage dans le pod. Seuls les initialization_jobs fournis par l'utilisateur sont pris en compte.
L'état persiste sur le PVC /data. Les documents CouchDB et les objets MinIO sont écrits sur le PVC en mode bloc monté sur /data ; les données survivent donc aux redémarrages de pod, aux replanifications et aux mises à niveau de version. Dimensionnez le PVC généreusement (stateful_pvc_size = 20Gi par défaut) — il grossit avec les données et les pièces jointes des applications.
Les identifiants internes sont immuables après le premier démarrage. Les sept secrets générés chiffrent les données de /data. Modifier API_ENCRYPTION_KEY corrompt toutes les données chiffrées stockées ; modifier JWT_SECRET invalide toutes les sessions ; modifier les identifiants MinIO ou CouchDB rompt l'accès aux magasins d'objets/de documents sur le PVC. N'effectuez de rotation que lors d'une réinitialisation planifiée.
Configuration au premier lancement. Budibase auto-hébergé est livré sans compte administrateur par défaut. Accédez à l'URL du LoadBalancer après le déploiement et créez l'administrateur initial (e-mail + mot de passe) via l'écran de configuration avant toute utilisation.
Chemin de santé. Les sondes de démarrage et de vivacité ciblent la racine non authentifiée /, qui renvoie 200 une fois les services intégrés démarrés. Prévoyez jusqu'à ~8-9 minutes au premier démarrage (la sonde de démarrage utilise un délai initial de 60 secondes plus une fenêtre de 30 tentatives à une période de 15 secondes) — le pod doit démarrer CouchDB, MinIO, Redis et la couche applicative.
StatefulSet à réplica unique. Conservez min_instance_count = max_instance_count = 1 ; le magasin de données est lié à un seul PVC et ne peut pas être partagé entre réplicas.

Vérifier la charge de travail en cours d'exécution :

kubectl get statefulset,pods,pvc -n "$NAMESPACE"
kubectl exec -n "$NAMESPACE" statefulset/<service-name> -- curl -s -o /dev/null -w '%{http_code}' localhost:80/

4. Variables de configuration

Les variables sont regroupées exactement comme sur la plateforme de déploiement. Seuls les paramètres propres à Budibase 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.