Meilisearch Common — Configuration applicative partagée
Meilisearch_Common est la couche applicative partagée de Meilisearch. Elle
n'est pas déployée seule ; elle fournit la configuration propre à Meilisearch
sur laquelle s'appuie Meilisearch_GKE. Elle servait
auparavant aussi une variante Cloud Run, retirée en septembre 2026 — voir la remarque
ci-dessous. Les utilisateurs finaux ne configurent jamais cette couche
directement — elle ne possède 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 Meilisearch, consultez le guide de plateforme (Meilisearch_GKE) et les guides du socle (App_GKE, App_CloudRun, App_Common).
1. Ce que fournit cette couche
| Domaine | Fourni par Meilisearch_Common | Où cela apparaît |
|---|---|---|
| Clé maître | Génère une MEILI_MASTER_KEY de 32 caractères et la stocke dans Secret Manager (enable_api_key = true) | Injectée automatiquement ; à récupérer via Secret Manager (voir ci-dessous) |
| Image de conteneur | Encapsule l'image officielle getmeili/meilisearch (figée sur v1.11) afin que le socle puisse la mettre en miroir dans Artifact Registry | Sortie container_image du déploiement de plateforme |
| Moteur de base de données | Impose database_type = "NONE" — Meilisearch n'a pas de base de données externe | §Base de données dans les guides de plateforme |
| Stockage d'objets | Déclare le bucket Cloud Storage storage, monté sur /meili_data | Sortie storage_buckets |
| Paramètres principaux | Définit l'environnement de base de Meilisearch : chemin des données, adresse d'écoute, mode production, télémétrie | Comportement de l'application dans les guides de plateforme |
| Contrôles de santé | Fournit les sondes de démarrage et de vivacité par défaut ciblant /health | §Observabilité dans les guides de plateforme |
2. La clé maître dans Secret Manager
Un secret est généré automatiquement et stocké dans Secret Manager — il n'est jamais défini en clair et ne doit faire l'objet d'une rotation qu'en même temps que tous les clients qui l'utilisent :
MEILI_MASTER_KEY— une chaîne alphanumérique aléatoire de 32 caractères, stockée soussecret-<wrapper_prefix>-<application_name>-api-key. Meilisearch s'exécute en mode production (MEILI_ENV = production), qui exige une clé maître d'au moins 16 octets ; le serveur refuse de démarrer sans elle. La clé maître est un identifiant racine — elle peut créer et supprimer des index, modifier les paramètres et émettre des clés d'API à portée limitée, restreintes à un locataire, viaPOST /keys. Les applications doivent recevoir des clés à portée limitée, jamais la clé maître.
Le secret est exposé au socle de deux manières afin que chaque variante de plateforme puisse l'injecter nativement :
- Cloud Run utilise
secret_ids({ MEILI_MASTER_KEY = <secret-id> }) via le mécanismemodule_secret_env_varsdu socle. - GKE utilise
secret_values(la valeur brute) et matérialise un Secret Kubernetes natif viaexplicit_secret_values.
Récupérez la clé maître après le déploiement :
# List the secret for this deployment (name includes the resource prefix):
gcloud secrets list --project "$PROJECT" --filter="name~api-key"
# Read the master key:
gcloud secrets versions access latest --secret=<secret-name> --project "$PROJECT"
Il n'y a pas de mot de passe de base de données distinct — Meilisearch n'a pas de base de données. Consultez App_Common pour le modèle partagé de secrets et de Workload Identity.
3. Moteur de base de données et stockage
Meilisearch ne nécessite aucune base de données ; le moteur est fixé à database_type = "NONE"
et MySQL, PostgreSQL et les autres moteurs ne s'appliquent pas. Meilisearch est un
binaire Rust autonome qui persiste ses index, documents, paramètres et sa file de
tâches dans un unique répertoire sur disque. Aucune instance Cloud SQL, aucun utilisateur
applicatif ni aucun job db-init n'est créé.
La durabilité repose entièrement sur le volume de stockage monté sur /meili_data
(MEILI_DB_PATH = /meili_data) :
- Cloud Run et GKE sans PVC montent le bucket Cloud Storage
storagesur/meili_datavia GCS FUSE (enable_gcs_storage_volume = true). - GKE avec
stateful_pvc_enabled = truemonte à la place un PVC Persistent Disk ; la couche Common définitenable_gcs_storage_volume = falseafin que les deux ne soient pas montés en double. Le PVC ne sert de support à/meili_dataque sistateful_pvc_mount_pathdeMeilisearch_GKEest explicitement surchargé à/meili_data— sa valeur par défaut est/meilisearch/storage, un chemin différent duMEILI_DB_PATHfixe, de sorte qu'avec les paramètres par défaut le PVC ne reçoit pas les données d'index (voir les pièges de configuration de Meilisearch_GKE).
Le bucket est déclaré ici (suffixe storage, classe STANDARD,
public_access_prevention = enforced, force_destroy = true) et provisionné par le
socle, qui accorde aussi l'accès au compte de service de la charge de travail. Listez-le avec :
gcloud storage buckets list --project "$PROJECT"
4. Image de conteneur
L'image personnalisée encapsule l'image amont officielle afin que le socle puisse la mettre en miroir dans Artifact Registry :
ARG MEILI_VERSION=v1.11
FROM getmeili/meilisearch:${MEILI_VERSION}
MEILI_VERSIONest un argument de build propre à l'application — volontairement pas leAPP_VERSIONgénérique qu'injectentApp_CloudRun/App_GKE. Le socle forceAPP_VERSIONà la valeur par défaut de campagne"latest"et l'emporte lors de cette fusion, maisgetmeili/meilisearch:latestn'est pas une bonne version figée pour la production ;Meilisearch_Commonconvertit doncapplication_version == "latest"en l'étiquette éprouvéev1.11et la transmet sous forme deMEILI_VERSION. Figezapplication_versionsur une version précise pour la production.- Pas de point d'entrée personnalisé. Le binaire amont
meilisearchdémarre directement et lit toute sa configuration depuis les variables d'environnement injectées — il n'y a rien à intégrer au-delà de l'image de base, si bien que les modifications d'image sont rares.
5. Paramètres principaux de l'application
Meilisearch_Common établit l'environnement de base de Meilisearch afin que
l'application démarre correctement dès le premier lancement :
- Chemin des données —
MEILI_DB_PATH = "/meili_data", aligné sur le point de montage GCS FUSE (Cloud Run, et GKE sans PVC) afin que les index persistent entre les redémarrages et les redéploiements. Sur GKE avecstateful_pvc_enabled = true, il ne s'aligne sur le PVC que sistateful_pvc_mount_pathest explicitement défini à/meili_data— sa valeur par défaut est un chemin différent (/meilisearch/storage). - Adresse d'écoute —
MEILI_HTTP_ADDR = "0.0.0.0:7700", afin que Cloud Run et le Service GKE puissent joindre le moteur sur le port 7700. - Environnement —
MEILI_ENV = "production". Cela rendMEILI_MASTER_KEYobligatoire (voir §2) et désactive le mini-tableau de bord web intégré. - Télémétrie —
MEILI_NO_ANALYTICS = "true"(désactivée par défaut ; aucune donnée envoyée à Meilisearch).
Toutes les environment_variables supplémentaires fournies par l'utilisateur de la plateforme sont fusionnées
par-dessus ces valeurs par défaut, de sorte que les opérateurs peuvent définir d'autres options MEILI_* (niveau de
journalisation, répertoires de snapshots/dumps, taille maximale de la file de tâches, etc.) sans modifier le module.
6. Comportement des sondes de santé
Les sondes par défaut ciblent /health — le point de terminaison de vivacité public et sans
authentification de Meilisearch, qui renvoie {"status":"available"} (HTTP 200) une fois que le serveur
a fini de se charger et est prêt à servir. Les deux variantes de plateforme utilisent le même
point de terminaison pour le démarrage et la vivacité :
- Cloud Run et GKE utilisent des sondes HTTP ciblant
/health— la sonde de démarrage accorde une fenêtre généreuse (délai initial de 15 secondes, période de 10 secondes, 10 tentatives) pour tenir compte du chargement des index lors d'un démarrage à froid, et la sonde de vivacité le revérifie (délai initial de 30 secondes, période de 30 secondes, seuil de 3 tentatives).
Comme /health ne requiert aucune authentification, le front-end Cloud Run et le kubelet GKE
peuvent le sonder directement même lorsque la clé maître est définie sur l'API.
7. Jobs d'initialisation et stockage d'objets
Meilisearch gère son propre stockage et ne nécessite aucune initialisation de base de données ;
Meilisearch_Common n'injecte donc aucun job db-init par défaut. L'entrée initialization_jobs
est transmise telle quelle pour les opérateurs qui souhaitent exécuter des tâches ponctuelles personnalisées
— par exemple alimenter un index depuis un système source ou restaurer un dump avant le
démarrage du service.
Le bucket Cloud Storage dédié déclaré ici (§3) est l'endroit où réside tout l'état persistant ; il n'existe pas de bucket de stockage de fichiers distinct pour Meilisearch. Listez-le avec :
gcloud storage buckets list --project "$PROJECT"
Pour la configuration propre à Meilisearch destinée aux utilisateurs (variables par groupe, sorties, et comment explorer chaque service depuis la console et la CLI), consultez le guide de plateforme : Meilisearch_GKE.
Meilisearch_CloudRun a été retiré en septembre 2026. Meilisearch stocke son index dans LMDB, qui conserve un
flockexclusif pendant toute la durée de vie du processus. Cloud Run maintient en vie une révision chaude après que le trafic l'a quittée, si bien que l'instance sortante ne libère jamais ce verrou et que chaque révision ultérieure échoue à sa sonde de démarrage avecResource temporarily unavailable (os error 11)— le service pouvait être déployé une fois mais jamais mis à jour de façon fiable, tout en paraissant sain.min_instance_count = 0permet une mise à jour sur un service inactif mais pas sur un service recevant du trafic. GKE n'est pas concerné : un StatefulSet arrête complètement l'ancien pod avant de démarrer le nouveau.
Guides associés
- Meilisearch sur GKE Autopilot — cette configuration déployée sur GKE.
Need RAD to do something it does not do yet? Request it on the roadmap, or vote on what is already there.