Démarrer MongoDB à partir d'un modèle versionné
Utilisez le modèle MongoDB 7 et initialisez les identifiants administrateur via des références aux secrets, plutôt que d’enregistrer des mots de passe dans le manifeste.
Services de données · offres à partir de $10/mois
Déployer MongoDB.Conservez durablement les documents et protégez les identifiants.
Démarrez MongoDB 7 avec un stockage persistant, protégez les identifiants d’administration, connectez la base de données applicative et vérifiez les écritures après un redémarrage.
Conserver le dépôtExaminer la compilation et les journauxDomaines personnalisés et TLS
Déploiement Adios
Version candidate
MongoDB
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 à
MongoDB 7Données des documentsPersistanceSecretsBases de données applicatives
Le parcours de mise en production
Même opérationnel, un projet MongoDB 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
Le modèle officiel ajoute un volume de données persistant. Définissez les besoins de sauvegarde, de restauration, de capacité et de mise à niveau avant d’en faire le système de référence.
Garder l'état de service visible pour les opérateurs
Connectez-vous avec un utilisateur applicatif, insérez et lisez des documents représentatifs, redémarrez le service, puis vérifiez les données et la reconnexion du client.
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 projetname: document-db
template: mongodb:7
env:
MONGO_INITDB_ROOT_USERNAME: root
MONGO_INITDB_ROOT_PASSWORD: secret://MONGO_INITDB_ROOT_PASSWORDAprès l’initialisation, créez un utilisateur applicatif distinct plutôt que d’utiliser les identifiants root dans le code de l’application.
Points de départ déployables
Démarrer MongoDB à partir d'un modèle lorsque le dépôt n'est pas prêt.
Le modèle MongoDB 7 fournit une base pour un service persistant et un chemin exact vers le code source, que vous pouvez examiner avant le déploiement.
Services de données
MongoDB 7
Un modèle MongoDB 7 avec stockage persistant et une base de données pour votre application.
Données des documentsGéré par Adios
- Clé du modèle
- mongodb:7
- Environnement d’exécution
- mongodb
- Dépôt
- template-mongodb-7
- Emplacement de la source
- .
git clone https://github.com/adiosdotdev/template-mongodb-7.git
cd template-mongodb-7
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 identifiants root et applicatifs sont distincts.
- La base de données applicative et ses index sont reproductibles.
- Les clients se reconnectent après un redémarrage du service.
- Les responsabilités en matière de sauvegarde et de restauration sont documentées.
Prévisualiser quand...
- Une migration de schéma ou d’index touche une collection volumineuse.
- L’application change de version majeure de MongoDB.
- Un comportement propre aux replica sets est nécessaire.
Les réponses à vos questions
Ce qu’il faut savoir avant de déployer MongoDB.
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 MongoDB à partir d’un modèle officiel ?
Oui. Choisissez le modèle MongoDB 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 MongoDB utilise-t-il un stockage persistant ?
Le modèle officiel ajoute un volume de données persistant. Définissez les besoins de sauvegarde, de restauration, de capacité et de mise à niveau avant d’en faire le système de référence.
L’URL de la page est-elle /deploy-mongo ou /deploy-mongodb ?
Cette page utilise le terme de recherche courant Mongo dans son URL, tout en décrivant précisément MongoDB dans son contenu et en proposant des liens vers le modèle et la documentation MongoDB.
Une application Node.js ou Python peut-elle se connecter à ce service MongoDB ?
Oui. Injectez le paramètre de connexion applicative sous forme de secret et testez l’authentification, les index, les écritures, les lectures, les reconnexions et le comportement en cas d’échec.
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 PostgreSQL
Choisissez une version de PostgreSQL, conservez les identifiants de la base de données hors de Git, ajoutez un stockage persistant, connectez l’application et vérifiez les données après un redémarrage.
Déployer MySQL
Démarrez MySQL 8 avec un stockage persistant, créez une base de données et un utilisateur applicatifs dédiés, protégez les deux mots de passe et vérifiez les données après redémarrage.
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.
Déployer Python
Exécutez une application web ou un worker Python en conservant le fichier de dépendances, la commande du processus, la route de contrôle de santé et la configuration alimentée par des secrets avec le code source.
La première version
Déployer MongoDB 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.