Exécutez Docker sur un VPS avec un plan d'exploitation de production
Docker facilite l'empaquetage d'une application, mais rendre un conteneur accessible n'est que le début de son exploitation. Un VPS a toujours besoin d'un budget de ressources, d'une exposition réseau réfléchie, de données récupérables et d'un processus de publication que quelqu'un peut maintenir.
L'essentiel à retenir
Traitez le projet Compose comme une définition applicative reproductible, gardez les données persistantes explicites, ne publiez que les points d'entrée prévus et testez un chemin de récupération avant de vous fier au déploiement.
Décrivez l'application et la frontière mono-hôte
Commencez par un schéma comprenant le reverse proxy public, l'application, la base de données, les workers et les fichiers persistants. Notez quels composants doivent communiquer entre eux et lesquels doivent être accessibles depuis Internet. Un petit déploiement Compose peut constituer un modèle d'exploitation pratique pour un seul VPS. Il ne devient pas un cluster hautement disponible simplement parce que plusieurs conteneurs fonctionnent.
Identifiez les responsabilités au niveau de l'hôte : mises à jour du système d'exploitation, maintenance de Docker, accès administratif, politique de pare-feu et planification des sauvegardes. Le comportement de redémarrage des conteneurs peut aider à récupérer un processus arrêté, mais il ne peut pas réparer des données perdues, un stockage indisponible ou un hôte défaillant. Décidez de ce que fait le projet lorsque l'ensemble du VPS est indisponible et comment l'application serait recréée ailleurs.
Vérifiez le système d'exploitation choisi et l'architecture de l'image applicative par rapport à la documentation logicielle. Séparez les commodités de développement des décisions de production. Un montage bind du code source, un mode débogage ou un identifiant local qui était utile sur un ordinateur portable ne doit pas faire partie du déploiement public simplement parce qu'il figure dans le même fichier Compose.
Budgétez ensemble la mémoire, le CPU et le disque temporaire
| Composant | Exemple d'allocation mémoire | Ce qu'il faut mesurer |
|---|---|---|
| Hôte et agents de support | 1 Go | Système d'exploitation et charge opérationnelle courante |
| Base de données | 2 Go | Tampons, connexions simultanées et charge réelle des requêtes |
| Processus applicatifs | 2 Go | Charge normale et pics de requêtes réalistes |
| Tâches de fond | 1 Go | Imports, traitement d'images et tâches planifiées |
| Marge non allouée | 2 Go | Chevauchement des versions et activité opérationnelle inhabituelle |
Ce budget indicatif de 8 Go est un exercice de planification, et non une exigence mesurée ni une promesse de performance d'hébergement. Confirmez l'usage réel avec l'application visée et configurez des contrôles de ressources adaptés à votre configuration Docker. Une base de données et une tâche de fond peuvent atteindre leur pic simultanément, même si chacune semblait à l'aise lors de tests séparés. Un nombre de conteneurs ne remplace pas utilement une mesure de charge.
La planification du disque nécessite plus que la taille actuelle de la base de données. Incluez les images, les volumes persistants, les téléversements de l'application, les journaux et l'espace temporaire pendant les imports ou les déploiements d'application. Gardez une réserve qui permette le travail d'investigation et de récupération. Si un déploiement doit télécharger une nouvelle image tout en conservant la précédente, un disque déjà presque plein peut transformer une mise à jour ordinaire en panne.
Définir les données persistantes et prouver leur restauration
Utilisez des volumes nommés explicites ou des montages bind soigneusement documentés pour les données qui doivent survivre au remplacement d'un conteneur. Nommez le propriétaire et l'usage de chaque montage. Dans les notes d'exploitation, distinguez clairement les fichiers de base de données, les fichiers téléversés et les caches jetables. La couche inscriptible d'un conteneur individuel ne doit pas être le seul emplacement où existe un document client.
Un volume Docker persiste indépendamment d'un conteneur, mais la persistance n'est pas une sauvegarde indépendante. Choisissez une méthode de sauvegarde cohérente prise en charge pour la base de données, capturez les fichiers applicatifs associés et testez la restauration dans un déploiement isolé. Ne partez pas du principe que la copie d'un volume de base de données actif produit un point de restauration exploitable. Consignez comment le volume, la version applicative et l'état de la base de données sont mis en correspondance lors de la restauration.
Avant de monter un volume, vérifiez sa source et sa destination. Monter un volume sur un répertoire peut masquer les fichiers déjà présents à cet emplacement dans le conteneur. Si une application semble vide de façon inattendue après un déploiement, vérifiez le montage réel et le volume sélectionné avant toute action de nettoyage destructive. Les données peuvent se trouver dans un autre volume plutôt que d'être absentes.
Publier les points d'entrée à dessein et les tester depuis l'extérieur
Le point d'entrée public est généralement le proxy inverse, tandis que la base de données de l'application reste joignable uniquement par le chemin interne prévu. Distinguez un port utilisé entre conteneurs d'un port publié sur l'hôte. Évitez d'exposer les interfaces de base de données, d'administration et de métriques simplement pour faciliter un test de connexion. Protégez l'accès d'administration séparément du site web public.
Docker crée des règles de réseau et de pare-feu sur Linux. Le trafic de ses ports publiés peut contourner le chemin du pare-feu de l'hôte auquel un opérateur s'attend avec ufw. Suivez la documentation Docker pour le backend réseau et pare-feu installé, puis vérifiez le résultat depuis l'extérieur du VPS. Une liste rassurante de règles sur l'hôte ne prouve pas qu'un port de conteneur publié est inaccessible.
Pour la première revue de production, listez chaque port joignable depuis l'extérieur et attribuez-lui un usage. Vérifiez le nom d'hôte de l'application via HTTPS et confirmez que les chemins d'administration non prévus ne sont pas publics. Gardez la configuration privée hors du code source des images et des dépôts publics. Examinez les privilèges, les montages et les interfaces hôte accordés à chaque service plutôt que de donner automatiquement un large accès à chaque conteneur.
Garantir des versions reproductibles et des journaux bornés
Consignez une version ou un digest d'image explicite pour chaque version et conservez la configuration utilisée pour la déployer. Examinez les paramètres Compose propres à la production, notamment le comportement de redémarrage, les ports, l'environnement et les montages. Testez l'application de remplacement avant de l'accepter. Revenir à une image précédente n'est sûr que si les modifications de schéma de base de données restent compatibles ou disposent de leur propre procédure de restauration éprouvée.
Définissez une politique de journalisation réfléchie. Les pilotes de journalisation Docker diffèrent, et la configuration json-file par défaut peut croître sans rotation. Choisissez une configuration bornée adaptée et confirmez-la sur les conteneurs réellement en cours d'exécution ; modifier une valeur par défaut du démon ne reconfigure pas automatiquement les conteneurs existants. Conservez les événements applicatifs utiles sans enregistrer de mots de passe, de jetons ni de corps de requêtes sensibles complets.
- L'image et la configuration Compose documentées permettent de recréer l'application.
- Les données persistantes disposent d'une procédure de restauration distincte et testée.
- Seuls les ports approuvés sont joignables depuis l'extérieur du VPS.
- Les journaux ont une politique de taille et de rétention vérifiée.
- Un opérateur nommé est responsable des mises à jour, de l'examen des alertes et des vérifications après chaque déploiement.
Commencez par un déploiement assez petit pour être compris. N'ajoutez de la complexité d'orchestration que lorsqu'une exigence mesurée le justifie et que l'équipe peut exploiter les composants supplémentaires. Un plan de restauration clair sur un seul hôte est plus utile qu'un ensemble de conteneurs dont personne ne peut retracer les données ni les responsabilités.
