Qu'est-ce que Docker ? Offres VPS pour l'exécution de charges de travail en conteneurs

Extrait / Intro

Docker est une plateforme open source qui regroupe les applications et leurs dépendances dans des unités isolées appelées conteneurs. Pour utiliser Docker sur InMotion Hosting, tu as besoin d'un Cloud VPS avec accès root ou d'un serveur dédié, car ces deux options te permettent de contrôler le système au niveau du noyau.WordPress mutualisé, revendeur etWordPress cPanel ne prennent pas en charge le démon Docker. Cet article explique le fonctionnement des conteneurs, quelles configurations VPS InMotion sont adaptées, et comment dimensionner ton environnement pour qu'il soit réellement performant.

Qu'est-ce que Docker, en gros ?

Docker regroupe une application avec tout ce dont elle a besoin pour fonctionner, notamment le moteur d'exécution, les bibliothèques, les outils système et les fichiers de configuration. On obtient ainsi un conteneur qui se comporte de la même manière sur l'ordinateur portable d'un développeur, sur un serveur virtuel de préproduction et sur un serveur de production.

Les conteneurs ne sont pas des machines virtuelles. Une machine virtuelle émule un système d'exploitation complet au-dessus d'un hyperviseur. Un conteneur partage le noyau de l'hôte et isole uniquement l'espace utilisateur à l'aide de primitives Linux telles que les espaces de noms et les cgroups. Selon la documentation officielle de Docker, cette conception te permet d'exécuter de nombreux conteneurs sur un seul hôte avec une charge bien moindre que si tu exécutais un nombre équivalent de machines virtuelles.

Les éléments clés de l'écosystème sont simples :

• Docker Engine: le démon qui crée et exécute les conteneurs
• Images: modèles en lecture seule qui contiennent ton application et ses dépendances
• Conteneurs: instances d'une image en cours d'exécution
• Docker Compose: un outil permettant de définir des applications multi-conteneurs dans un seul fichier YAML
• Répertoires: stockage d'images, Docker Hub étant le répertoire public par défaut

En quoi Docker diffère-t-il de l'hébergement classique ?

Avec l'hébergement traditionnel, les logiciels sont installés directement sur le système de fichiers du serveur. PHP, MySQL et Apache se trouvent dans les répertoires /etc et /usr, et ils partagent leurs bibliothèques avec tous les autres éléments présents sur la machine. La mise à jour d'une application peut en bloquer une autre. C'est l'une des raisons pour lesquelles les formules d'hébergement mutualisé limitent les installations autorisées aux utilisateurs.

Docker renverse ce modèle. Chaque conteneur intègre ses propres bibliothèques et son propre environnement d'exécution. Une application Node 18 et une application Node 22 peuvent fonctionner en parallèle sans entrer en conflit, car chacune contient sa propre version au sein de l'image. Tu peux également supprimer un conteneur en quelques secondes et le remplacer par une image dont tu sais qu'elle fonctionne, ce qui est bien plus propre que de réinstaller des paquets sur un serveur en production.

C'est justement cette isolation qui fait toute la différence. Les conteneurs te fournissent une unité de déploiement reproductible. L'image que tu as testée en local est exactement celle qui s'exécute en production.

Pourquoi utiliser des conteneurs plutôt que d'installer directement les logiciels ?

Voici quelques raisons pratiques qui reviennent souvent dans les projets concrets :

• Un verrouillage de version qui tient vraiment la route : les images de conteneurs verrouillent les versions exactes de PHP, Node, Python, Postgres ou de tout autre élément dont dépend ta pile. Finies les mises à jour accidentelles de paquets qui cassent un site en production.
• Intégration plus rapide : un développeur qui rejoint ton équipe peut lancer `docker compose up` et faire fonctionner l'environnement complet en quelques minutes, au lieu de passer une demi-journée à rechercher les dépendances.
• Rétrogradations simplifiées : si un déploiement ne se passe pas comme prévu, tu peux revenir à la balise d'image précédente. Il n'est pas nécessaire de désinstaller puis de réinstaller les paquets sur l'hôte.
• Des serveurs hôtes plus légers : ton VPS reste minimaliste. L'hébergeur exécute Docker, un pare-feu et SSH. Tout le reste se trouve dans des conteneurs.

C'est justement cette prévisibilité qui a poussé les agences et les équipes SaaS à migrer une grande partie de leurs outils internes, de leurs environnements de test et de leurs microservices vers des conteneurs.

Quels sont les forfaits VPS InMotion qui prennent en charge Docker ?

En bref, n'importe quelle offre qui te donne un accès root sur une distribution Linux prise en charge. Dans la gamme InMotion, ça correspond au Cloud VPS, qui s'installe sur AlmaLinux 9, Ubuntu 22.04 LTS ou Debian 12. Ces trois distributions sont parfaitement adaptées à Docker Engine et Docker Compose.

Voici un comparatif des principaux types de forfaits pour les charges de travail en conteneurs :

Type de forfait	Accès à la racine	Compatible avec Docker ?	Notes
Hébergement mutualisé (Launch, Pro)	Non	Non	Pas de gestion des démons, le noyau est partagé avec d'autres comptes
WordPress (cPanel)	Non	Non	Pile à usage unique, sans prise en charge des conteneurs
Hébergement pour revendeurs	Non	Non	Conçu pour cPanel , pas pour les conteneurs
VPS cloud (non géré)	Oui	Oui	Le choix qui s'impose. AlmaLinux 9, Ubuntu 22.04 ou Debian 12
VPS géré (cPanel)	Oui (avec quelques réserves)	C'est possible, mais ce n'est pas l'idéal	cPanel Docker ne s'intègrent pas parfaitement
Serveurs dédiés	Oui	Oui	Idéal pour les déploiements de conteneurs à haute densité

Un VPS sur le cloud est le point de départ idéal pour la plupart des équipes de développement. Tu bénéficies d'une installation Linux vierge, d'un accès root complet et d'aucun panneau de contrôle préinstallé qui pourrait te gêner. Installe Docker Engine en suivant les instructions officielles de Docker pour ta distribution, et tu seras opérationnel en moins de dix minutes.

Et les serveurs VPS gérés avec cPanel?

Les formules VPS gérées d'InMotion utilisent cPanel WHM, ce qui est idéal pour héberger des sites web classiques et des services de messagerie, mais complique un peu les choses pour les opérations avec des conteneurs. cPanel pour contrôler directement Apache, PHP-FPM, MySQL, exim et d'autres services. Il est techniquement possible d'y ajouter Docker par-dessus, puisque tu disposes toujours des droits root, mais cela revient à faire tourner deux systèmes de gestion concurrents sur le même serveur.

En pratique, les équipes qui souhaitent disposer à la fois d'un cPanel géré et de conteneurs les font généralement tourner sur des machines distinctes. Un schéma courant : un VPS cPanel pour les sites web des clients, plus un Cloud VPS plus petit pour les outils basés sur Docker, comme une instance Git privée, une pile de surveillance ou un environnement de préproduction.

Si tu n'as le budget que pour un seul serveur et que tu veux utiliser des conteneurs, laisse tomber le panneau de contrôle et opte plutôt pour un Cloud VPS.

VPS cloud ou serveur dédié pour les charges de travail en conteneurs

Un VPS sur le cloud est une infrastructure virtualisée issue d'un serveur hôte plus grand. Tu partages le matériel sous-jacent avec d'autres utilisateurs, mais tu bénéficies d'allocations garanties de CPU et de RAM. Un serveur dédié est une machine physique entière qui t'est exclusivement réservée.

Pour les conteneurs, le choix se résume généralement aux exigences en matière de densité et d'isolation :

• Le Cloud VPS est idéal pour exécuter quelques conteneurs par projet, mettre en place des environnements de test ou gérer de petites charges de travail en production. Tu peux évoluer verticalement en passant à une offre supérieure lorsque le nombre de tes conteneurs ou ta consommation de ressources augmente.
• Les serveurs dédiés sont la solution idéale lorsque tu dois exécuter des dizaines de conteneurs, héberger des bases de données qui tirent parti NVMe locales ou respecter des exigences de conformité interdisant l'utilisation d'hyperviseurs partagés. L'offre Essential d'InMotion (99,99 $/mois) est fournie avec 64 Go de RAM DDR4 et deuxSSD NVMe de 1,92 To, ce qui offre une capacité suffisante pour un parc de conteneurs d'envergure.

InMotion utilise un RAID logiciel via mdadm pour toutes ces offres, ce qui est courant dans les environnements de serveurs Linux et fonctionne sans configuration particulière pour Docker.

Conditions requises pour utiliser Docker sur un serveur virtuel (VPS)

Les besoins de base sont modestes. Docker Engine lui-même nécessite environ 200 Mo de RAM et très peu de ressources CPU lorsqu'il est inactif. C'est aux conteneurs que tu exécutes par-dessus lui que revient la majeure partie des ressources.

Un bon point de départ pour le dimensionnement :

• Petits services ( nginx, redis, API légères) : 50 à 200 Mo de RAM par conteneur
• Applications web Node.js ou Python : entre 150 et 500 Mo selon le framework
• PHP-FPM avec un seul WordPress : 256 à 512 Mo
• PostgreSQL ou MySQL avec un trafic modéré : 512 Mo à 2 Go minimum
• Applications auto-hébergées comme Nextcloud ou Mattermost: 1 à 2 Go

L'utilisation du disque est également importante. Les images de conteneurs, les volumes et le cache de compilation s'accumulent rapidement. Prévoyez au moins 30 à 50 Go sur un Cloud VPS d'entrée de gamme, et surveillez l'espace disponible à l'aide de la commande `df` de Docker (documentation).

Tu auras également besoin de :

• Une distribution Linux prise en charge. InMotion Cloud VPS propose AlmaLinux 9, Ubuntu 22.04 LTS et Debian 12, toutes officiellement prises en charge par Docker
• Accès au réseau sortant pour récupérer des images depuis des référentiels
• Une clé SSH pour un accès sécurisé (l'authentification par mot de passe doit être désactivée)
• Une stratégie de règles de pare-feu, car Docker intervient sur iptables et peut entrer en conflit avec des configurations de pare-feu trop simplistes

Cas d'utilisation courants de Docker sur un VPS

Quelques schémas qui reviennent souvent :

• Outils de développement auto-hébergés : GitLab, Gitea, Drone CI, Vaultwarden et autres outils similaires se déploient facilement sous forme de conteneurs
• Backends d'application : API Node .js, Python ou Go derrière un proxy inverse
• Environnements de préproduction : crée une copie exacte de l'environnement de production à partir du même ensemble d'images
• Architectures de microservices : plusieurs petits services coordonnés via Docker Compose
• Proxy inverse avec SSL automatique : Traefik ou Caddy, déployés dans un conteneur, gèrent le trafic entrant et les certificats Let’s Encrypt pour tous les autres services de l’hôte
• Isolation des bases de données : exécute des instances PostgreSQL MySQL distinctes pour chaque projet sans surcharger l'hôte

Pour les agences, un seul serveur VPS dans le cloud héberge souvent un proxy inverse Traefik ainsi qu'une douzaine d'environnements de préproduction pour les clients, chacun étant isolé dans son propre ensemble de conteneurs. Les agences qui travaillent pour plusieurs clients devraient également se renseigner sur le programme de partenariat InMotion Agency Partner Program pour bénéficier d'avantages d'hébergement à plusieurs niveaux.

Facteurs de performance qui influent sur les charges de travail des conteneurs

Les performances des conteneurs sur un VPS ne dépendent pas uniquement des caractéristiques techniques brutes. Voici quelques points à surveiller :

• E/S disque : les conteneurs qui effectuent de nombreuses écritures (bases de données, agrégateurs de journaux) tirent pleinement parti des formules VPS NVMe. Les disques mécaniques constituent un goulot d'étranglement, même avec beaucoup de RAM.
• Pression sur la mémoire : lorsque tu dépasses la RAM disponible, le noyau commence à utiliser la mémoire de pagination ou le « OOM killer » ferme les conteneurs. Les deux solutions sont à éviter. Augmente la capacité avant d'atteindre 80 % d'utilisation en continu.
• Réseau : le trafic entre conteneurs sur un même hôte reste sur l'interface de bouclage et est rapide. Le trafic entre hôtes dépend du réseau de ton VPS. Les applications en temps réel y sont sensibles ; ce n'est généralement pas le cas des applications CRUD.
• Temps de vol du processeur : sur une infrastructure d'hyperviseur partagée, surveille le pourcentage « %st » dans top ou vmstat. Un temps de vol soutenu supérieur à quelques pour cent indique que l'hôte est surchargé.
• Mise en cache des images : créer des images sur le même serveur virtuel (VPS) que ton cache de registre est bien plus rapide que de les récupérer à chaque fois depuis une source distante. Utilise des builds en plusieurs étapes pour que tes images de production restent légères.

Les coûts à prendre en compte au-delà du prix affiché

Le tarif mensuel du VPS ne représente qu'une partie de la facture. Voici d'autres postes à prendre en compte dans ton budget :

• Sauvegardes : l'offre Premier Care pour VPS d'InMotion comprend 300 Go d'espace de stockage pour les sauvegardes, ce qui couvre la plupart des charges de travail en conteneurs. Pense à sauvegarder les volumes, et pas seulement le système de fichiers de l'hôte.
• Dépassement de la bande passante : la plupart des déploiements de conteneurs génèrent peu de trafic sortant, mais les pipelines d'intégration continue (CI) contenant beaucoup d'images ou les serveurs multimédia peuvent atteindre les limites.
• Stockage des registres d'images : l'offre gratuitede Docker Hub limite la fréquence des téléchargements. Un compte d'équipe ou un registre auto-hébergé directement sur le VPS permet d'éviter ça.
• Surveillance : les outils gratuits (Prometheus, Grafana, Uptime Kuma) fonctionnent dans des conteneurs et ne coûtent rien, hormis l'espace mémoire qu'ils occupent.
• Durée de la migration : le transfert d'un serveur virtuel (VPS) à un autre à l'aide de conteneurs est plus rapide qu'avec un hébergement classique, mais il faut tenir compte du temps de propagation du DNS et du renouvellement du certificat SSL.

C'est là que les coûts ont tendance à grimper. La densité de conteneurs semble économique jusqu'à ce que tu te retrouves à court de RAM à 2 heures du matin et que tu doives augmenter la capacité immédiatement.

Erreurs courantes lors du déploiement de Docker sur un VPS

Les schémas qui posent problème en production :

• Tout exécuter en tant que root à l'intérieur du conteneur : les conteneurs doivent réduire leurs privilèges à l'aide de la directive USER dans le Dockerfile
• Stockage des données à l'intérieur du conteneur : utilise des volumes nommés ou des montages liés pour que les données soient conservées lors des redémarrages du conteneur et des mises à jour de l'image
• Pas de limites de ressources : sans les options –memory et –cpus (ou leurs équivalents dans Compose), un conteneur qui part en vrille peut priver de ressources tous les autres
• Ignorer la taille de l'image : une image Node de 2 Go prend du temps à se reconstruire et use le disque. Les constructions en plusieurs étapes et les images de base allégées permettent de maîtriser ce problème.
• Ignorer la rotation des journaux : le pilote de journaux JSON par défaut de Docker crée des fichiers de taille illimitée. Configure les paramètres `max-size` et `max-file` ou transfère les journaux vers un autre emplacement.
• Conflit entre pare-feu : Docker génère des règles iptables que ufw et firewalld peuvent remplacer. Choisis une approche et tiens-t'en à celle-là.

La plupart de ces problèmes peuvent être résolus en cinq minutes dès lors que tu sais où chercher.

Quand passer à autre chose qu'un VPS

Un seul VPS cloud peut gérer un volume impressionnant de charges de travail en conteneurs. Voici les signes qui indiquent qu'il est temps d'évoluer en profondeur ou en largeur :

• Utilisation du processeur supérieure à 75 % dans plusieurs conteneurs
• La mémoire est à la limite ou presque, sans marge pour les pics
• Le temps d'attente des E/S disque dépasse les 10 % dans iostat
• Boucles de redémarrage des conteneurs provoquées par l'épuisement des ressources
• Exigences de conformité nécessitant du matériel dédié
• Déploiements multirégionaux où la latence vers un seul centre de données est importante

Quand tu atteins ces seuils, la marche à suivre consiste généralement à passer d'abord à un VPS plus puissant, puis à un serveur dédié avec plus de cœurs et de RAM, pour aboutir finalement à une configuration multi-serveurs avec un véritable outil d'orchestration comme Kubernetes ou Docker Swarm. La plupart des équipes n'ont pas besoin d'orchestration tant qu'elles n'exploitent pas plusieurs machines physiques.