Aller au contenu principal

Metabase Common — Configuration applicative partagée

Metabase_Common est la couche applicative partagée de Metabase. Elle n'est pas déployée seule ; elle fournit la configuration propre à Metabase sur laquelle s'appuient à la fois Metabase_GKE et Metabase_CloudRun, afin que les deux variantes de plateforme se comportent de façon identique là où cela compte. Les utilisateurs finaux ne configurent jamais cette couche directement — elle n'a aucune entrée propre dans l'interface de déploiement — mais comprendre ce qu'elle fournit explique les valeurs par défaut que vous voyez dans la documentation des plateformes.

Pour l'infrastructure qui provisionne et exécute réellement Metabase, consultez les guides de plateforme (Metabase_GKE, Metabase_CloudRun) et les guides des socles (App_GKE, App_CloudRun, App_Common).

1. Ce que fournit cette couche​

DomaineFourni par Metabase_CommonOù cela apparaît
Image de conteneurÉpingle l'image officielle metabase/metabase et construit une couche Cloud Build personnalisée avec le point d'entrée de la plateformeSortie container_image du déploiement de plateforme
Moteur de base de donnéesFixe Cloud SQL for PostgreSQL 15 comme seul moteur pris en charge§Base de données dans les guides de plateforme
Amorçage de la base de donnéesDéfinit le job db-init du premier déploiement qui crée la base de données et l'utilisateurSortie initialization_jobs
Variables d'environnement fixesDéfinit MB_JETTY_PORT = "3000" et JAVA_TIMEZONE = "UTC" — elles ne doivent pas être remplacéesComportement de l'application dans les guides de plateforme
Contrôles de santéFournit le comportement par défaut des sondes de démarrage/de vivacité ciblant /api/health, avec des délais généreux adaptés à la JVM§Observabilité dans les guides de plateforme
Stockage d'objetsRenvoie une liste de buckets de stockage vide — Metabase stocke tout son état dans PostgreSQLSortie storage_buckets (vide)

2. Moteur de base de données et amorçage​

Metabase requiert PostgreSQL 15 ; le moteur est fixé et MySQL n'est pas pris en charge. Lors du premier déploiement, un job ponctuel db-init s'exécute avant le démarrage de la charge de travail Metabase. Il utilise postgres:15-alpine et se connecte à Cloud SQL via le socket Unix de l'Auth Proxy pour, de manière idempotente :

  1. créer la base de données Metabase (si elle est absente),
  2. créer l'utilisateur de l'application avec le mot de passe généré automatiquement,
  3. accorder à cet utilisateur tous les privilèges sur cette base de données.

Le job s'exécute avec execute_on_apply = true (il s'exécute pendant tofu apply), avec jusqu'à 3 nouvelles tentatives et un délai d'expiration de 600 secondes. Il peut être relancé sans risque. Inspectez directement la base de données avec :

gcloud sql connect <instance-name> --user=<db-user> --project "$PROJECT"

Les noms de l'instance, de la base de données et de l'utilisateur figurent dans les sorties du déploiement de plateforme.

3. Paramètres principaux de l'application​

Metabase_Common établit l'environnement Metabase de base afin que l'application démarre correctement dès le premier lancement :

  • MB_JETTY_PORT = "3000" — le serveur Jetty intégré de Metabase doit écouter sur le port 3000. Cette valeur est fixée pour correspondre à container_port = 3000. La remplacer via environment_variables dans le module de plateforme casse tout le routage et les contrôles de santé.
  • JAVA_TIMEZONE = "UTC" — le fuseau horaire de la JVM est fixé à UTC afin de garantir un traitement cohérent des horodatages dans les tableaux de bord, les questions planifiées et les exports de rapports. Le remplacer fait diverger le filtrage par date et la planification de Metabase du fuseau horaire de la base de données.
  • Les variables d'environnement supplémentaires fournies via environment_variables dans le module de plateforme sont fusionnées au moment du déploiement. Utilisez-les pour des paramètres Metabase tels que MB_EMBEDDING_ENABLED, MB_SITE_URL ou les options de tas Java.

4. Comportement des sondes de santé​

Les sondes de démarrage et de vivacité ciblent toutes deux /api/health en HTTP. Ce point de terminaison ne renvoie HTTP 200 qu'une fois la JVM complètement initialisée et connectée à PostgreSQL. Des délais initiaux généreux sont nécessaires, car la JVM de Metabase met 60 à 120 secondes à démarrer :

SondeTypeCheminDélai initialPériodeSeuil d'échecTolérance totale
DémarrageHTTP/api/health120s10s15~270s
VivacitéHTTP/api/health120s30s3—
Disponibilité (readiness)HTTP/api/health60s15s3—

Les variantes GKE et Cloud Run utilisent toutes deux des sondes HTTP — les contrôles de santé de Cloud Run atteignent directement le conteneur Metabase en HTTP/2 et ne rencontrent pas le comportement de redirection qui impose un contournement par sonde TCP dans les applications basées sur Apache.

Inspectez les événements des sondes sur GKE :

kubectl describe pod -n "$NAMESPACE" -l app=<service-name>

5. Aucun secret applicatif​

Contrairement à certains autres modules applicatifs, Metabase_Common ne génère aucun mot de passe administrateur au niveau de l'application. Metabase gère sa propre clé de chiffrement interne et les identifiants des utilisateurs via son assistant de configuration au premier démarrage. Le seul secret dont s'occupe cette couche est le mot de passe de la base de données, qui est généré et géré par le module socle.

Récupérez le nom du secret du mot de passe de la base de données dans la sortie database_password_secret du déploiement de plateforme, puis accédez-y avec :

gcloud secrets versions access latest --secret=<database-password-secret> --project "$PROJECT"

6. Stockage d'objets​

Metabase_Common renvoie une liste de buckets de stockage vide. Metabase stocke tout l'état de l'application — questions, tableaux de bord, collections, utilisateurs, autorisations — dans PostgreSQL. Aucun bucket GCS n'est provisionné par défaut.

Si votre déploiement nécessite un stockage d'objets (par exemple pour configurer le stockage compatible S3 de Metabase Enterprise Edition pour la mise en cache des résultats de requêtes, ou pour stocker des artefacts de plugins personnalisés), ajoutez des buckets via la variable storage_buckets du module de plateforme (Metabase_CloudRun ou Metabase_GKE) :

gcloud storage buckets list --project "$PROJECT"

7. Scripts​

Le répertoire scripts/ de Metabase_Common contient :

FichierRôle
DockerfileImage Metabase personnalisée qui étend metabase/metabase avec le script de point d'entrée de la plateforme.
entrypoint.shPoint d'entrée de la plateforme qui injecte les détails de connexion du Cloud-SQL-Proxy avant de passer la main au processus Metabase.
db-init.shScript idempotent de configuration de PostgreSQL — crée la base de données et l'utilisateur de l'application et accorde les privilèges. Exécuté avec postgres:15-alpine.

Pour la configuration propre à Metabase destinée aux utilisateurs (variables par groupe, sorties, et comment explorer chaque service depuis la console et la CLI), consultez les guides de plateforme : Metabase_GKE et Metabase_CloudRun.

Need RAD to do something it does not do yet? Request it on the roadmap, or vote on what is already there.

By · Google Cloud certified: ACE · PCA · PCD · PDE · PSE · CDL

Dernière mise à jour le