Démarrer Qdrant à partir d'un modèle versionné
Le modèle officiel télécharge le binaire statique Qdrant 1.19.0 pour amd64 ou arm64, vérifie sa somme de contrôle fixée et génère des clés API distinctes pour l’administration et la lecture seule.
Services de données · offres à partir de $10/mois
Déployer Qdrant.Protégez le stockage vectoriel et vérifiez les recherches.
Démarrez un service Qdrant à version fixe sur un seul nœud, conservez les collections et les snapshots sur un stockage persistant, séparez l’accès administrateur de l’accès en lecture seule et testez des requêtes vectorielles représentatives.
Conserver le dépôtExaminer la compilation et les journauxDomaines personnalisés et TLS
Déploiement Adios
Version candidate
Qdrant
SOURCE
Git
REGION
de
ROUTE
HTTPS
01Source reçue
02Compilation terminée
03Environnement d’exécution démarré
04Vérification de santé réussie
Route promue en production
production.adios.run
Une mise en production adaptée à
Qdrant 1.19.0Base de données vectorielleREST + gRPCClés généréesPersistance
Le parcours de mise en production
Même opérationnel, un projet Qdrant doit être mis en production en toute sécurité.
L’application ou le service ne représente qu’une partie de la production. Les résultats de compilation, l’état d’exécution, les contrôles de santé, les secrets, les journaux, les routes et la version promue doivent pouvoir être examinés ensemble.
Faire de la persistance une décision explicite
Les collections, index et snapshots locaux sont conservés sous /app/qdrant-data sur un stockage persistant. Sauvegardez ce volume et testez la restauration des snapshots avant de l’utiliser pour la recherche en production.
Garder l'état de service visible pour les opérateurs
Utilisez /healthz pour vérifier la disponibilité, testez REST ou gRPC avec des vecteurs et filtres représentatifs et n’utilisez les clés API que via HTTPS ou un accès réseau privé.
Du code source à la mise en production
Trois étapes vous permettent de vérifier le parcours de déploiement.
Utilisez le code source et le fonctionnement en production déjà définis pour le projet. Le manifeste décrit ce que la plateforme doit compiler ou provisionner et les critères à remplir pour que le résultat soit prêt.
- 01
Commencer par la source ou un modèle
Importez le dépôt existant, ou examinez et déployez l’une des variantes de modèles précisément référencées ci-dessous.
$adios login - 02
Revoir le contrat de déploiement
Consignez dans adios.yaml les commandes, la version de l’environnement d’exécution ou du service, les critères de santé et les références aux secrets.
$git diff -- adios.yaml - 03
Déployer et inspecter le résultat
Suivez les résultats de compilation et d’exécution, vérifiez la version candidate, puis ouvrez la route ou la connexion de service promue en production.
$adios up
adios.yaml
Votre projettype: database
env:
QDRANT__SERVICE__API_KEY: secret://QDRANT_API_KEY
QDRANT__SERVICE__READ_ONLY_API_KEY: secret://QDRANT_READ_ONLY_API_KEY
secrets:
QDRANT_API_KEY: secret://generate:64
QDRANT_READ_ONLY_API_KEY: secret://generate:64
build_cmd: sh /app/install-qdrant.sh
start_cmd: cd /app/qdrant-data && exec /app/qdrant-server --config-path /app/qdrant.yaml
port:
- 6333
- 6334
runtime:
health_path: /healthz
volumes:
- name: qdrant-data
target: /app/qdrant-data
persistent: trueLe modèle complet désactive le clustering, les URL de snapshots distants et la télémétrie d’utilisation pour sa configuration volontairement limitée à un seul nœud.
Points de départ déployables
Démarrer Qdrant à partir d'un modèle lorsque le dépôt n'est pas prêt.
Examinez le modèle Qdrant complet, clonez son dépôt autonome ou déployez-le directement avec la clé publique qdrant.
Services de données
Qdrant 1.19.0
Qdrant 1.19.0 avec données vectorielles persistantes et clés d’administration et de lecture seule générées.
Vector APIVersion du projet d’origine
- Clé du modèle
- qdrant
- Environnement d’exécution
- pinned binary
- Dépôt
- template-qdrant
- Emplacement de la source
- .
git clone https://github.com/adiosdotdev/template-qdrant.git
cd template-qdrant
adios upAvant production
Vérifier la charge de travail.Puis promouvez la version en production.
Pour sécuriser la première mise en production, partez d’une compilation ou d’une configuration de service reproductible et d’un aperçu qui sollicite les dépendances réellement utilisées en production.
Prêt quand...
- Les clients administrateurs et les clients en lecture seule utilisent des clés distinctes.
- Les dimensions des vecteurs et les métriques de distance sont définies explicitement.
- Les écritures, les filtres et les recherches représentatifs réussissent.
- Les responsabilités concernant les snapshots et la restauration sont documentées.
Prévisualiser quand...
- Un changement de modèle d’embeddings modifie les dimensions des vecteurs.
- La reconstruction d’une collection ou un import massif modifie les besoins en espace disque.
- La charge de travail nécessite une haute disponibilité sur plusieurs nœuds.
Les réponses à vos questions
Ce qu’il faut savoir avant de déployer Qdrant.
Vérifiez les limites de l’environnement d’exécution ou du service, le chemin du modèle, le comportement en cas d’échec et les contrôles de production avant de créer la première version.
Puis-je déployer Qdrant à partir d’un modèle officiel ?
Oui. Choisissez le modèle Qdrant correspondant à la version ou à la configuration souhaitée, stockez les identifiants dans des secrets Adios et déployez-le depuis la console ou avec adios up.
Le modèle Qdrant utilise-t-il un stockage persistant ?
Les collections, index et snapshots locaux sont conservés sous /app/qdrant-data sur un stockage persistant. Sauvegardez ce volume et testez la restauration des snapshots avant de l’utiliser pour la recherche en production.
Quels ports Qdrant le modèle expose-t-il ?
L’API REST et le tableau de bord utilisent le port 6333, tandis que gRPC utilise le port 6334. La route HTTPS principale dessert l’API REST ; ne connectez gRPC que via un accès réseau approuvé.
S’agit-il d’un déploiement Qdrant en cluster ?
Non. Le modèle repose explicitement sur un seul nœud. Concevez et testez une topologie à plusieurs nœuds lorsque la charge de travail nécessite une haute disponibilité au-delà de la conservation des données après redémarrage.
Où stocker les mots de passe de la base de données et du broker ?
Stockez les valeurs sensibles dans les secrets Adios et référencez-les avec secret://NAME. Ne placez pas les identifiants de production directement dans adios.yaml et ne les enregistrez pas dans Git.
Que dois-je vérifier avant de recevoir du trafic de production ?
Vérifiez l’authentification, la connectivité applicative, les écritures et lectures, la persistance après redémarrage, les besoins de sauvegarde ou de restauration, la capacité et le comportement en cas d’échec de chaque application dépendante.
Autres options de déploiement
Connectez le reste de votre stack.
Déployer Typesense
Démarrez un serveur Typesense à version fixe, conservez les collections et les documents sur un stockage persistant, protégez la clé administrateur initiale et vérifiez l’indexation ainsi que la recherche avant le lancement.
Déployer pgvector
Démarrez PostgreSQL avec l’extension pgvector, connectez une application utilisant des embeddings, vérifiez les écritures vectorielles et les recherches de plus proches voisins, puis testez la persistance.
Déployer FastAPI
Déployez un service FastAPI en conservant avec son code source la cible d’import ASGI, l’installation des dépendances, le port d’exécution, l’endpoint de contrôle de santé, les secrets et la version promue.
Déployer Node.js
Déployez un processus web ou un worker Node.js persistant à partir de ses scripts de packages existants, avec les contrôles de santé de la version, les journaux, les secrets, le routage et l’historique Git associés.
La première version
Déployer Qdrant avec le code source et les éléments de vérification associés.
Partez du dépôt ou d’un modèle, vérifiez le contrat de déploiement et examinez la version qui sera promue en production.