Docker pour vos sites : 7 conseils pratiques pour faire tourner des conteneurs sur votre propre serveur
Un cache Redis, un worker de file, une petite API interne à côté de votre site — Docker rend ça propre sur votre propre VPS. Voici sept habitudes qui distinguent une configuration de conteneurs soignée d'une configuration fragile.
Faire tourner un site ne s'arrête presque jamais à PHP et une base de données. Tôt ou tard, vous voulez un cache Redis, un worker de file, une petite API interne ou un service headless juste à côté. Docker est la façon la plus propre de faire ça sur votre propre VPS — mais quelques habitudes séparent une configuration soignée d'une configuration qui lâche à 3 h du matin. En voici sept à adopter.
1. Un réseau par site, et communiquer par nom
Placez les conteneurs de chaque site sur leur propre réseau Docker et faites-les se joindre par nom de conteneur (redis:6379) plutôt que par localhost. Les services restent découvrables, on évite les collisions de ports entre projets, et les conteneurs d'un site ne peuvent pas accidentellement parler à ceux d'un autre.
2. Ne publiez pas les ports inutiles
Une instance Redis ou une API interne utilisée uniquement par votre app ne devrait jamais être liée à un port hôte. Joignez-la plutôt via le réseau interne. Chaque port publié est une surface d'attaque — n'exposez que ce dont le public a vraiment besoin, c'est-à-dire généralement votre seule app web.
3. Figez les tags d'image — évitez :latest
redis:latest aujourd'hui et redis:latest dans trois mois peuvent être des versions majeures différentes. Figez sur quelque chose de précis comme redis:7-alpine (ou un digest) pour qu'un rebuild ne change pas — ni ne casse — silencieusement un service dont vous dépendez.
4. Définissez toujours une politique de redémarrage
Sans --restart=unless-stopped, un redémarrage du serveur laisse vos services annexes à l'arrêt et votre app renvoie des erreurs de connexion jusqu'à ce que vous le remarquiez. Définissez la politique une fois et les conteneurs reviennent d'eux-mêmes après un reboot ou un crash.
5. Voyez Docker comme de l'isolation, pas un mur de sécurité
Les conteneurs partagent le noyau de l'hôte. Ils sont excellents pour garder les projets propres et séparer les dépendances — mais ce n'est pas une frontière stricte entre locataires non fiables. Fixez des limites de mémoire et de CPU pour qu'un conteneur ne prive pas les autres, et partez du principe qu'un conteneur compromis peut peser sur ses voisins.
6. Sachez lire les logs
Quand quelque chose casse, docker logs --tail 100 <nom> est votre premier réflexe. Assurez-vous que vos conteneurs écrivent sur stdout/stderr (la plupart des images officielles le font déjà) pour que la sortie soit réellement capturée et pas enfouie dans un fichier à l'intérieur du conteneur.
7. Étiquetez tout
Sur un serveur qui héberge plusieurs sites, docker ps devient vite illisible. Étiquetez chaque conteneur avec le site auquel il appartient (--label site=acme) pour pouvoir filtrer, auditer et nettoyer ensuite sans deviner quel conteneur fait quoi.
La façon simple
Chaque conseil ci-dessus est une étape manuelle qu'on peut oublier ou rater. C'est exactement le genre de corvée qu'un bon panel devrait gérer pour vous. Dans ShadowPanel, ajouter un conteneur à un site lui donne automatiquement son propre réseau par site, une étiquette de site, une politique de redémarrage unless-stopped et des mappages de ports validés et non privilégiés — depuis une interface claire, avec les logs et start/stop/restart à un clic. Vous obtenez les sept bonnes habitudes par défaut, sans mémoriser le moindre drapeau.
Faites tourner vos conteneurs proprement
Palier gratuit — 3 sites, sans carte bancaire — et vous pouvez l'installer sur n'importe quel VPS Ubuntu en une dizaine de minutes :
curl -fsSL https://shadowpanel.de/install.sh | bash