Faire tourner Docker sur un VPS à petit budget

Pourquoi Docker sur un petit VPS, au juste

L'argument en faveur de Docker n'a rien à voir avec la taille de la machine. Les déploiements reproductibles garantissent que l'image testée est, octet pour octet, celle qui tourne en production ; un rollback consiste simplement à relancer le tag précédent ; et le conteneur qui fonctionne sur votre portable fonctionne à l'identique en production.

Sur un petit VPS, ces propriétés comptent davantage, pas moins. Quand les ressources sont serrées, vous ne pouvez pas vous offrir de mystère — le débogage façon « ça marche sur ma machine » consume exactement le temps et la mémoire que vous n'avez pas. Une seule image, partout, et cette classe de problèmes disparaît.

La mémoire, c'est le budget

Sur un VPS à petit budget, la RAM est la ressource qui s'épuise en premier, et Docker laissera volontiers un conteneur affamer tous les autres si vous ne dites rien. Fixez une limite de mémoire explicite sur chaque conteneur, pour qu'une fuite se traduise par un service redémarré plutôt que par un serveur figé.

Ajoutez un fichier de swap modeste comme filet de sécurité — pas pour y vivre, mais pour survivre aux pics brefs sans que le noyau ne tue des processus au hasard. Et préférez les images slim ou alpine : une base plus petite, c'est moins de mémoire, des téléchargements plus rapides et une surface d'attaque réduite.

• Fixer des limites --memory par conteneur
• Utiliser des images de base légères
• Un processus par conteneur

Compose pour toute la stack

Un seul docker-compose.yml décrivant votre application et son reverse proxy transforme toute la stack en un fichier unique que vous pouvez lire, versionner et reproduire. Remonter le serveur depuis zéro devient une seule commande, au lieu d'un rituel à moitié oublié.

Gardez le fichier ennuyeux et explicite : tags d'images épinglés, politiques de redémarrage, limites de mémoire. Tout ce que le serveur exécute doit être visible dans ce fichier — si ce n'est pas dans Compose, ça n'existe pas.

services:
  app:
    image: ghcr.io/you/app:latest
    restart: unless-stopped
    mem_limit: 512m

Gardez la base de données hors du conteneur

Faire tourner PostgreSQL ou MySQL dans Docker sur une petite machine, c'est là que les configurations à petit budget vont mourir. Une base de données veut de la mémoire stable, du stockage soigné et de vraies sauvegardes — exactement ce qu'un petit VPS où les conteneurs se disputent la RAM ne peut pas promettre. Un seul OOM kill pendant une écriture, et vous restaurez à l'espoir.

Utilisez plutôt une base de données managée et laissez le VPS faire ce qu'il sait faire : exécuter votre application sans état. L'état a sa place ailleurs — sur Anested Cloud, PostgreSQL, MySQL et MongoDB managés démarrent gratuitement, et vos conteneurs reçoivent simplement une chaîne de connexion.

Des mises à jour sans drame ni interruption

La routine de mise à jour est courte : récupérer la nouvelle image, redémarrer le service, et laisser un health check confirmer que le nouveau conteneur répond vraiment avant de passer à autre chose. S'il ne répond pas, relancer le tag précédent est votre rollback — quelques secondes, pas une soirée.

Avant les gros changements — nouvelles versions majeures, réécriture du fichier Compose — prenez d'abord un snapshot du VPS. C'est l'assurance la moins chère qui soit : si la mise à niveau tourne mal, vous restaurez toute la machine à l'instant précis d'avant votre intervention.