Docker a changé la façon d'installer une application sur un serveur : fini les paquets qui se contredisent et les « ça marche sur ma machine ». Sur un VPS NVMe, un conteneur isole l'application, se remplace en une commande et se décrit dans un fichier versionnable. Encore faut-il l'installer proprement et savoir où vivent les données.
Docker sur un VPS : ce que ça change vraiment
Un conteneur n'est pas une machine virtuelle. Il partage le noyau de l'hôte et n'embarque que l'application et ses bibliothèques : quelques dizaines de mégaoctets au lieu d'un système complet, un démarrage en une seconde, de quoi faire tourner trois services sur un plan à 1 vCPU.
Trois situations le justifient :
- Les dépendances s'empilent. Une application Node, une base PostgreSQL et un reverse proxy n'ont pas le même rythme de mise à jour ; les isoler évite qu'une montée de version casse les autres.
- Vous voulez des environnements identiques. La même image tourne sur votre portable et sur le serveur, avec les mêmes bibliothèques.
- Vous préparez la suite. Le jour où un deuxième serveur arrive, la même définition se rejoue sans réinstallation manuelle.
Pour un site statique ou une application PHP unique, nginx et PHP-FPM installés à même le système restent plus simples : Docker ajoute un démon, une couche réseau et des gigaoctets d'images.
Installer Docker sans abîmer le système
Le dépôt officiel plutôt que le paquet de la distribution
Le paquet fourni par Ubuntu ou Debian est souvent plus ancien que Compose v2. Le script officiel curl -fsSL https://get.docker.com | sh installe le dépôt, le moteur et le plugin Compose en une passe. Téléchargez-le et lisez-le avant de l'exécuter : vous l'installez une fois, autant savoir ce qu'il modifie.
Trois vérifications avant d'aller plus loin
Contrôlez que le service tourne et que Compose est le plugin, non l'ancien binaire Python :
systemctl is-active dockerdoit répondre active.docker compose versiondoit afficher une version 2.x.docker run --rm hello-worlddoit se terminer sans erreur.
Attention : mettre un utilisateur dans le groupe docker revient à lui donner les droits root, puisqu'il peut monter n'importe quel répertoire de l'hôte. Sur un serveur que vous administrez seul, restez à sudo docker.
Une première pile : application, base, proxy et TLS
Trois services, un réseau interne
La pile minimale tient dans un fichier compose.yaml : un reverse proxy qui termine le TLS, l'application, la base sur un volume nommé. Seuls les ports 80 et 443 sont publiés, et les conteneurs se joignent par leur nom de service. Les commandes du quotidien :
docker compose up -ddémarre la pile en arrière-plan.docker compose psmontre l'état réel des services et leurs ports.docker compose logs -f appsuit les journaux du seul service qui vous intéresse.
Ne publiez pas la base sur 0.0.0.0 : un tunnel SSH fait le même travail sans exposer le service.
Certificats : le domaine d'abord, le TLS ensuite
Let's Encrypt vérifie que le domaine pointe vers votre machine : créez l'enregistrement A vers l'IPv4 dédiée incluse avec chaque plan, puis demandez le certificat. Deux approches courantes : certbot en mode webroot avec un volume partagé entre le proxy et la tâche de renouvellement, ou un proxy qui gère l'ACME lui-même comme Caddy. Vérifiez surtout que le renouvellement est planifié et testé : un certificat qui expire au bout de quatre-vingt-dix jours reste la panne la plus évitable du métier.
Volumes et sauvegardes : ce qui survit au conteneur
Un conteneur se supprime sans état d'âme : c'est son intérêt. Un volume nommé, lui, contient vos données et survit à la reconstruction de l'image. Le code part dans l'image ; les fichiers des utilisateurs et les données de la base vont dans un volume déclaré.
Mais un volume n'est pas une sauvegarde. Les plans incluent des sauvegardes automatiques, qui couvrent la panne serveur et l'erreur au niveau de la machine. Cela ne remplace pas un export applicatif cohérent : une copie brute prise pendant une écriture peut être inutilisable. Pour PostgreSQL, docker compose exec db pg_dump -U app app redirigé vers un fichier de l'hôte donne une copie relisible.
Deux habitudes : un export quotidien par tâche cron, une copie hors du serveur. Une sauvegarde jamais restaurée reste une hypothèse.
Limites de ressources : le conteneur qui étouffe le serveur
Par défaut, un conteneur prend toute la mémoire qu'il trouve. Sur un plan à 1 Go, une fuite suffit à déclencher le tueur de processus du noyau, qui ne choisit pas toujours la victime que vous auriez choisie.
- Fixez des plafonds.
mem_limitetcpusdans le fichier compose, ou le blocdeploy.resources.limitsen Compose v2. Un plafond mémoire rend l'incident local et prévisible. - Regardez la consommation réelle.
docker statsdonne CPU, mémoire et entrées-sorties par conteneur, en direct. - Tournez les journaux. Le pilote
json-filegrossit sans limite par défaut ; une politiquemax-sizeetmax-fileévite de remplir le disque NVMe. - Adaptez l'application. Une JVM ou un processus Node doit connaître le plafond, sinon il dimensionne son tas sur la mémoire de l'hôte.
Surveillez enfin le disque : docker image prune nettoie les images orphelines, mais ne lancez jamais docker system prune --volumes sans lire la liste de ce qui va disparaître.
Sécurité : cinq réflexes qui comptent
- Ne montez jamais
/var/run/docker.sockdans un conteneur. Qui contrôle le démon contrôle la machine entière, y compris ses disques. - Faites tourner l'application sans privilèges avec la directive
user, et lisez le système de fichiers en lecture seule quand c'est possible. - Épinglez les versions d'images plutôt que d'utiliser
latest: vous décidez du moment de la mise à jour, pas l'inverse. - Attention au pare-feu. Docker écrit ses propres règles iptables : un port publié contourne UFW. Passez par la chaîne
DOCKER-USERpour filtrer ce qui entre réellement. - Reconstruisez régulièrement. Une image laissée six mois sans mise à jour contient six mois de correctifs manquants.
La supervision 24/7 et le SLA de 99,9 % portent sur l'infrastructure : la machine, le réseau, l'hyperviseur. Ce qui tourne dans vos conteneurs reste votre responsabilité — aucun hébergeur sérieux ne peut garantir le code d'un autre.
Quel plan VPS pour une pile Docker ?
Le démon, la couche overlay2 et les images consomment mémoire et disque avant la première requête. Les cinq plans, aux prix publics en dollars et en dirhams hors taxes :
| Offre | vCPU | RAM | NVMe | USD/mois | DH HT/mois | Ce que Docker y fait bien |
|---|---|---|---|---|---|---|
| VPS-1G Démarrage | 1 | 1 Go | 30 Go | 9,99 | 94,48 | Un proxy, un site léger, une petite API |
| VPS-2G Business | 1 | 2 Go | 40 Go | 19,99 | 189,06 | Application et base sur la même machine |
| VPS-3G Performance | 2 | 3 Go | 50 Go | 34,99 | 330,93 | Trois ou quatre services, marge de manœuvre |
| VPS-4G Avancé | 2 | 4 Go | 80 Go | 39,99 | 378,22 | Empilement complet avec cache et files d'attente |
| VPS-5G Ultra | 3 | 5 Go | 100 Go | 49,99 | 472,80 | Plusieurs applications clientes, builds sur la machine |
Le plan à 1 Go est honnête pour un proxy et un service unique, en acceptant que le démon et les images prennent déjà leur part. À 2 Go, une application avec sa base respire. Au-delà, vous achetez de la marge pour les pics et les reconstructions d'images. Chaque plan inclut une IPv4 dédiée, la bande passante illimitée, l'accès root, les sauvegardes automatiques, le pare-feu et la protection DDoS ; le passage à une offre supérieure se fait sans migration douloureuse.
FAQ
Faut-il forcément Docker pour héberger une application sur un VPS ?
Non. Une application unique, avec nginx et son socle installés à même le système, reste plus simple à diagnostiquer. Docker devient rentable avec plusieurs services ou des dépendances qui se contredisent.
Docker tourne-t-il correctement sur un VPS à 1 Go de RAM ?
Oui, pour un proxy et un service léger : le démon, les images et le système occupent déjà une partie de la mémoire.
Les sauvegardes automatiques incluent-elles les volumes Docker ?
Elles protègent la machine et son disque, pas la cohérence applicative. Ajoutez un export logique de la base, planifié et testé, gardé hors du serveur.
Faut-il Kubernetes pour quelques conteneurs ?
Non, et c'est un mauvais calcul sur un seul serveur : l'orchestrateur consomme des ressources pour un bénéfice nul tant que vous n'avez pas plusieurs machines. Compose suffit.
Prochaine étape
Partez d'une pile minuscule, mettez-la en production, puis ajoutez des services à mesure que le besoin se confirme. Les VPS Open Vista sont livrés en moins de 15 minutes après commande depuis le datacenter de New York — un datacenter à Rabat est annoncé, pas encore ouvert. Comparez les plans dans les offres et tarifs et lisez la page VPS NVMe avant de choisir.