Comment installer et configurer MongoDB sur un VPS (Guide complet)

MongoDB est une base de données NoSQL orientée documents qui stocke les enregistrements sous forme de documents BSON (Binary JSON), permettant une modélisation des données sans schéma avec une évolutivité horizontale grâce au sharding natif. Contrairement aux bases de données relationnelles, MongoDB ne nécessite pas de schéma de table prédéfini, ce qui en fait le choix dominant pour les applications avec des structures de données évolutives, un débit d’écriture élevé ou des relations de données hiérarchiques.

Ce guide présente un déploiement MongoDB de qualité production sur un VPS Linux — couvrant l’installation depuis le dépôt officiel, le renforcement de l’authentification, le contrôle d’accès réseau, la configuration TLS, l’optimisation des performances et l’automatisation des sauvegardes. Chaque étape suppose que vous opérez dans un environnement serveur réel où la sécurité et la fiabilité ne sont pas négociables.

Prérequis

Avant de continuer, confirmez les points suivants :

• Un VPS fonctionnant sous Ubuntu 20.04 LTS ou Ubuntu 22.04 LTS (les commandes sont identiques pour les deux)
• Accès utilisateur root ou sudo-privilégié via SSH
• Un minimum de 2 GB RAM (4 GB recommandé pour les charges de travail en production)
• Au moins 20 GB d’espace disque disponible sur un volume de stockage rapide
• UFW ou iptables disponible pour la gestion du pare-feu
• Familiarité de base avec la ligne de commande Linux

> Note d’architecture : Le moteur de stockage WiredTiger de MongoDB utilise un cache interne par défaut de 50% de (RAM – 1 GB). Sur un VPS de 2 GB, cela donne environ 512 MB de cache. Pour les charges de travail à lecture intensive, provisionnez au moins 4 GB de RAM pour éviter les I/O disque constants dus à la pression du cache.

MongoDB vs. Autres bases de données NoSQL : Comparaison rapide

Étape 1 : Mettre à jour le système

Commencez toujours avec un système entièrement mis à jour. Les paquets obsolètes introduisent des CVE connus qui peuvent être exploités avant même que vous n’installiez votre pile applicative.

sudo apt update && sudo apt upgrade -y

Après avoir appliqué les mises à jour du noyau ou de libc, redémarrez pour activer le nouveau noyau :

sudo reboot

Reconnectez-vous via SSH après que le serveur soit de nouveau en ligne (généralement 30 à 60 secondes).

Étape 2 : Installer MongoDB depuis le dépôt officiel

Les dépôts apt par défaut d’Ubuntu fournissent une version obsolète et repackagée par la communauté de MongoDB qui manque des correctifs de sécurité récents et des améliorations du moteur. Installez toujours depuis le dépôt officiel de MongoDB.

Ajouter la clé GPG et le dépôt MongoDB

La commande apt-key est obsolète sur Ubuntu 22.04. Utilisez la méthode de trousseau recommandée, qui fonctionne sur les deux versions 20.04 et 22.04 :

curl -fsSL https://www.mongodb.org/static/pgp/server-7.0.asc | 
  sudo gpg --dearmor -o /usr/share/keyrings/mongodb-server-7.0.gpg

Ajoutez l’entrée du dépôt officiel :

echo "deb [ arch=amd64,arm64 signed-by=/usr/share/keyrings/mongodb-server-7.0.gpg ] 
  https://repo.mongodb.org/apt/ubuntu $(lsb_release -cs)/mongodb-org/7.0 multiverse" | 
  sudo tee /etc/apt/sources.list.d/mongodb-org-7.0.list

> Note de version : Remplacez 7.0 par votre version cible (par exemple, 6.0) si vous avez besoin d’une version spécifique pour la compatibilité applicative. MongoDB 7.0 est la version à support à long terme actuelle depuis 2024.

Installer les paquets MongoDB

sudo apt update
sudo apt install -y mongodb-org

Cela installe les composants suivants :

mongod — le démon de base de données principal
mongos — le routeur de sharding (utilisé dans les déploiements de clusters shardés)
mongosh — le Shell MongoDB moderne (remplace le binaire mongo hérité)
mongodb-database-tools — inclut mongodump, mongorestore, mongoexport et mongoimport

Épingler la version installée

Empêchez les mises à niveau non intentionnelles qui pourraient rompre la compatibilité applicative :

echo "mongodb-org hold" | sudo dpkg --set-selections
echo "mongodb-org-database hold" | sudo dpkg --set-selections
echo "mongodb-org-server hold" | sudo dpkg --set-selections
echo "mongosh hold" | sudo dpkg --set-selections
echo "mongodb-org-mongos hold" | sudo dpkg --set-selections
echo "mongodb-org-tools hold" | sudo dpkg --set-selections

Étape 3 : Configurer les prérequis au niveau système

MongoDB fonctionne mieux lorsque certains paramètres du noyau et du système de fichiers sont ajustés avant le démarrage du démon.

Définir le ulimit pour les fichiers ouverts

MongoDB nécessite une limite élevée de descripteurs de fichiers. Créez une substitution systemd :

sudo mkdir -p /etc/systemd/system/mongod.service.d
sudo tee /etc/systemd/system/mongod.service.d/limits.conf > /dev/null <<EOF
[Service]
LimitFNOFILE=64000
LimitNPROC=64000
EOF

Désactiver les Transparent Huge Pages (THP)

Les THP provoquent des pics de latence significatifs dans MongoDB. Désactivez-les de manière persistante :

sudo tee /etc/systemd/system/disable-thp.service > /dev/null <<EOF
[Unit]
Description=Disable Transparent Huge Pages (THP)
DefaultDependencies=no
After=sysinit.target local-fs.target
Before=mongod.service

[Service]
Type=oneshot
ExecStart=/bin/sh -c 'echo never | tee /sys/kernel/mm/transparent_hugepage/enabled > /dev/null'
ExecStart=/bin/sh -c 'echo never | tee /sys/kernel/mm/transparent_hugepage/defrag > /dev/null'

[Install]
WantedBy=basic.target
EOF

sudo systemctl daemon-reload
sudo systemctl enable --now disable-thp

Vérifiez que le paramètre a pris effet :

cat /sys/kernel/mm/transparent_hugepage/enabled

La sortie devrait afficher [never] comme valeur active.

Étape 4 : Démarrer et activer MongoDB

sudo systemctl daemon-reload
sudo systemctl start mongod
sudo systemctl enable mongod

Confirmez que le démon est en cours d’exécution :

sudo systemctl status mongod

Recherchez Active: active (running) dans la sortie. Si le service ne démarre pas, inspectez immédiatement le journal :

sudo tail -50 /var/log/mongodb/mongod.log

Les échecs de démarrage courants incluent :

• Port 27017 déjà utilisé — un autre processus est lié au port ; identifiez-le avec sudo ss -tlnp | grep 27017
• Permissions du répertoire de données — l’utilisateur mongod doit posséder /var/lib/mongodb ; corrigez avec sudo chown -R mongodb:mongodb /var/lib/mongodb
• THP toujours activé — le moteur WiredTiger enregistre un avertissement et peut dégrader les performances

Étape 5 : Sécuriser MongoDB — Authentification et autorisation

C’est la section la plus critique. Les instances MongoDB non protégées exposées à Internet ont été responsables de milliers de violations de données. L’installation par défaut n’a aucune authentification, ce qui signifie que quiconque peut atteindre le port 27017 dispose d’un accès complet en lecture/écriture à chaque base de données.

Créer l’utilisateur administratif

Connectez-vous au shell MongoDB local (aucune authentification requise avant de l’activer) :

mongosh

Dans le shell, basculez vers la base de données admin et créez un superutilisateur :

use admin

db.createUser({
  user: "adminuser",
  pwd: passwordPrompt(),
  roles: [
    { role: "userAdminAnyDatabase", db: "admin" },
    { role: "readWriteAnyDatabase", db: "admin" },
    { role: "dbAdminAnyDatabase", db: "admin" },
    { role: "clusterAdmin", db: "admin" }
  ]
})

L’utilisation de passwordPrompt() au lieu d’une chaîne en texte clair empêche le mot de passe d’apparaître dans l’historique du shell. Saisissez le mot de passe lorsqu’on vous le demande, puis quittez :

exit

Activer l’authentification dans mongod.conf

Ouvrez le fichier de configuration MongoDB :

sudo nano /etc/mongod.conf

Localisez la section security (elle sera commentée) et activez l’autorisation :

security:
  authorization: enabled

Enregistrez et quittez (Ctrl+X, puis Y, puis Enter), puis redémarrez le démon :

sudo systemctl restart mongod

Vérifier que l’authentification est appliquée

Tentez une connexion non authentifiée — elle devrait maintenant échouer :

mongosh --eval "db.adminCommand({ listDatabases: 1 })"

Vous devriez recevoir une erreur Unauthorized. Authentifiez-vous maintenant correctement :

mongosh -u adminuser -p --authenticationDatabase admin

Créer des utilisateurs à portée applicative

N’utilisez jamais le superutilisateur admin pour les connexions applicatives. Créez un utilisateur avec le moindre privilège pour chaque base de données applicative :

use myappdb

db.createUser({
  user: "appuser",
  pwd: passwordPrompt(),
  roles: [
    { role: "readWrite", db: "myappdb" }
  ]
})

Étape 6 : Configurer la liaison réseau et les règles de pare-feu

Restreindre ou étendre bindIp

Par défaut, mongod.conf se lie uniquement à 127.0.0.1. C’est le paramètre correct si votre application s’exécute sur le même VPS. Si vous avez besoin d’un accès distant (par exemple, depuis un serveur d’application sur un hôte séparé), modifiez /etc/mongod.conf :

net:
  port: 27017
  bindIp: 127.0.0.1,10.0.0.5

Remplacez 10.0.0.5 par l’IP privée spécifique de votre serveur d’application. Ne définissez jamais bindIp: 0.0.0.0 sur une interface publique sans règle de pare-feu restreignant l’accès aux IP connues. La liaison à toutes les interfaces sans pare-feu est la principale cause des incidents d’exposition de données MongoDB.

Redémarrez après les modifications :

sudo systemctl restart mongod

Configurer les règles de pare-feu UFW

Si un accès distant est requis, autorisez uniquement l’IP de confiance spécifique :

sudo ufw allow from 10.0.0.5 to any port 27017 proto tcp
sudo ufw enable
sudo ufw status verbose

Bloquez tout autre accès externe au port 27017 :

sudo ufw deny 27017

UFW traite les règles dans l’ordre — la règle allow from spécifique au-dessus de la règle deny générale a la priorité pour l’IP de confiance.

Étape 7 : Activer TLS/SSL pour les connexions chiffrées

Pour tout déploiement où le trafic MongoDB traverse un réseau — même un LAN privé — le chiffrement TLS est obligatoire. Sans lui, les identifiants et les données sont transmis en texte clair.

Générez un certificat auto-signé pour les tests (utilisez un certificat signé par une CA en production — envisagez de l’associer à un Certificat SSL pour votre domaine) :

sudo mkdir -p /etc/mongodb/ssl
sudo openssl req -newkey rsa:4096 -nodes -keyout /etc/mongodb/ssl/mongodb.key 
  -x509 -days 365 -out /etc/mongodb/ssl/mongodb.crt 
  -subj "/CN=your-vps-hostname"
sudo cat /etc/mongodb/ssl/mongodb.crt /etc/mongodb/ssl/mongodb.key | 
  sudo tee /etc/mongodb/ssl/mongodb.pem > /dev/null
sudo chown -R mongodb:mongodb /etc/mongodb/ssl
sudo chmod 600 /etc/mongodb/ssl/mongodb.pem

Ajoutez la configuration TLS à /etc/mongod.conf :

net:
  port: 27017
  bindIp: 127.0.0.1
  tls:
    mode: requireTLS
    certificateKeyFile: /etc/mongodb/ssl/mongodb.pem

Redémarrez MongoDB et connectez-vous avec TLS :

sudo systemctl restart mongod
mongosh --tls --tlsCertificateKeyFile /etc/mongodb/ssl/mongodb.pem 
  --tlsAllowInvalidCertificates -u adminuser -p --authenticationDatabase admin

L’indicateur --tlsAllowInvalidCertificates n’est acceptable que pour les certificats auto-signés en développement. Supprimez-le lors de l’utilisation d’un certificat signé par une CA.

Étape 8 : Optimisation des performances dans mongod.conf

Pour un déploiement en production sur un VPS avec des ressources dédiées, ajustez le cache WiredTiger et les paramètres de journalisation. Ouvrez /etc/mongod.conf et ajoutez ou modifiez ce qui suit :

storage:
  dbPath: /var/lib/mongodb
  journal:
    enabled: true
  wiredTiger:
    engineConfig:
      cacheSizeGB: 1.5

operationProfiling:
  slowOpThresholdMs: 100
  mode: slowOp

replication:
  oplogSizeMB: 1024

Paramètres d’optimisation clés expliqués :

• cacheSizeGB — Définissez ceci à environ 50% de la RAM disponible moins 1 GB. Sur un VPS de 4 GB, utilisez 1.5. Sur un VPS de 8 GB, utilisez 3.5.
• slowOpThresholdMs — Les requêtes dépassant ce seuil (en millisecondes) sont enregistrées dans le profileur. Abaisser cette valeur aide à identifier rapidement les requêtes non indexées.
• oplogSizeMB — Pertinent si vous prévoyez d’ajouter des membres à un replica set ultérieurement. Le pré-dimensionnement de l’oplog évite le retard de réplication sur les charges de travail à écriture intensive.

Appliquez les modifications :

sudo systemctl restart mongod

Étape 9 : Sauvegarde et restauration avec mongodump

Sauvegarde manuelle

mongodump 
  --uri="mongodb://adminuser:yourpassword@127.0.0.1:27017/?authSource=admin" 
  --out /var/backups/mongodb/$(date +%Y-%m-%d)

Restauration manuelle

mongorestore 
  --uri="mongodb://adminuser:yourpassword@127.0.0.1:27017/?authSource=admin" 
  /var/backups/mongodb/2024-06-15

Automatiser les sauvegardes avec Cron

Créez un script de sauvegarde dédié :

sudo tee /usr/local/bin/mongodb-backup.sh > /dev/null <<'EOF'
#!/bin/bash
BACKUP_DIR="/var/backups/mongodb"
TIMESTAMP=$(date +%Y-%m-%d_%H-%M-%S)
MONGO_URI="mongodb://adminuser:yourpassword@127.0.0.1:27017/?authSource=admin"
RETENTION_DAYS=7

mkdir -p "${BACKUP_DIR}/${TIMESTAMP}"
mongodump --uri="${MONGO_URI}" --out="${BACKUP_DIR}/${TIMESTAMP}"
find "${BACKUP_DIR}" -maxdepth 1 -type d -mtime +${RETENTION_DAYS} -exec rm -rf {} ;
EOF

sudo chmod +x /usr/local/bin/mongodb-backup.sh

Planifiez son exécution quotidienne à 2h00 du matin :

(crontab -l 2>/dev/null; echo "0 2 * * * /usr/local/bin/mongodb-backup.sh >> /var/log/mongodb-backup.log 2>&1") | crontab -

> Considération de production : Stockez les sauvegardes hors du serveur. Conserver les sauvegardes sur le même VPS que la base de données n’offre aucune protection contre une défaillance du disque ou une compromission du serveur. Utilisez rsync, rclone ou un stockage d’objets compatible S3 pour répliquer les sauvegardes vers un emplacement distant.

Étape 10 : Surveiller la santé de MongoDB

Commandes de surveillance intégrées

Dans mongosh, exécutez les statistiques du serveur :

db.serverStatus()
db.stats()
db.currentOp()

Utiliser mongostat et mongotop

Depuis le shell, surveillez les compteurs d’opérations en temps réel :

mongostat --uri="mongodb://adminuser:yourpassword@127.0.0.1:27017/?authSource=admin"

Surveillez le temps de lecture/écriture par collection :

mongotop --uri="mongodb://adminuser:yourpassword@127.0.0.1:27017/?authSource=admin"

Métriques clés à surveiller

Choisir l’hébergement adapté à MongoDB

Les performances et la fiabilité de votre instance MongoDB sont directement liées à l’infrastructure sous-jacente. Considérez ces niveaux de déploiement :

• Développement et staging : Un VPS standard avec 2 à 4 GB de RAM est suffisant pour les charges de travail hors production, les tests de schéma et les environnements d’intégration.
• Production nœud unique : Un VPS avec 4 à 8 GB de RAM, un stockage NVMe et un cœur CPU dédié gère un trafic de production modéré pour la plupart des applications web.
• Production à haut débit : Un Serveur Dédié élimine l’effet de voisin bruyant inhérent aux environnements virtualisés. Les modèles d’I/O de WiredTiger bénéficient significativement des baies NVMe bare-metal.
• Charges de travail ML/analytiques : Si vous exécutez MongoDB aux côtés de pipelines de données, d’analyses à forte agrégation ou de recherche vectorielle, l’Hébergement GPU peut accélérer les tâches de traitement en aval.

Pour les déploiements nécessitant une interface de gestion graphique, le VPS avec cPanel offre un environnement familier pour les équipes moins à l’aise avec l’administration en ligne de commande pure, bien que la modification directe de mongod.conf reste nécessaire pour la configuration avancée.

Matrice de décision de déploiement

Utilisez cette liste de contrôle avant la mise en production :

• [ ] MongoDB installé depuis le dépôt officiel, version épinglée
• [ ] Service mongod activé et confirmé active (running)
• [ ] Transparent Huge Pages désactivées et vérifiées
• [ ] ulimit pour les descripteurs de fichiers défini à 64000 ou plus
• [ ] Authentification activée dans mongod.conf (authorization: enabled)
• [ ] Utilisateur admin créé avec passwordPrompt() — aucun mot de passe en texte clair dans l’historique du shell
• [ ] Utilisateurs spécifiques aux applications créés avec des rôles à moindre privilège
• [ ] bindIp restreint à localhost ou à des IP de confiance spécifiques uniquement
• [ ] Règles UFW en place — port 27017 bloqué depuis l’internet public
• [ ] TLS activé avec un certificat valide
• [ ] Cache WiredTiger dimensionné à 50% de (RAM – 1 GB)
• [ ] Profilage des requêtes lentes activé (slowOpThresholdMs: 100)
• [ ] Sauvegardes quotidiennes automatisées avec réplication hors serveur
• [ ] Restauration de sauvegarde testée — une sauvegarde que vous n’avez jamais restaurée n’est pas une sauvegarde

FAQ

Sur quel port par défaut MongoDB écoute-t-il, et doit-il être modifié ?

MongoDB écoute par défaut sur le port TCP 27017. Le changer pour un port non standard ajoute une légère obscurité mais ne remplace pas l’authentification et les règles de pare-feu. Si vous le changez, mettez à jour net.port dans /etc/mongod.conf et ajustez toutes les règles UFW et les chaînes de connexion en conséquence.

Pourquoi MongoDB utilise-t-il autant de RAM même avec un petit jeu de données ?

WiredTiger pré-alloue son cache interne selon la formule max(50% of (RAM - 1 GB), 256 MB). C’est intentionnel — conserver les données de travail en mémoire élimine les lectures disque. Si la consommation de RAM est une préoccupation sur un petit VPS, définissez explicitement cacheSizeGB dans /etc/mongod.conf à une valeur inférieure.

Puis-je exécuter MongoDB sur un hébergement mutualisé ?

Non. MongoDB nécessite un démon d’arrière-plan persistant (mongod), un accès direct au système de fichiers vers son répertoire de données et la capacité de se lier à un port réseau. Aucun de ces éléments n’est disponible sur l’Hébergement Web Mutualisé. Un VPS est l’environnement minimum viable.

Quelle est la différence entre mongodump et un snapshot du système de fichiers pour les sauvegardes ?

mongodump effectue une sauvegarde logique — il lit les documents via l’interface de requête MongoDB et les exporte sous forme de fichiers BSON. Il est portable et fonctionne entre les versions, mais est plus lent et ne peut pas garantir la cohérence à un instant précis sur une instance active à écriture intensive sans --oplog. Un snapshot du système de fichiers (LVM, ZFS ou snapshot de stockage en bloc cloud) capture les fichiers de données bruts à un instant cohérent et est significativement plus rapide pour les grands jeux de données, mais nécessite que le moteur de stockage soit dans un état cohérent.

Comment vérifier quelle version de MongoDB est installée ?

Exécutez la commande suivante depuis le terminal :

mongod --version

Ou depuis l’intérieur de mongosh :

db.version()