Briques applicatives, Docker Compose et proxy : héberger plusieurs applications sur un serveur

Quand on héberge plusieurs applications sur un même serveur, deux questions arrivent vite : comment les isoler les unes des autres, et comment les rendre accessibles sans exposer le serveur entier ? Une réponse courante tient en trois idées : des briques applicatives dans des conteneurs Docker, Docker Compose pour les assembler, et un proxy unique qui reçoit les requêtes et les redirige. Voici le principe, sans jargon inutile, avec l’exemple de ma propre organisation.

Le principe des briques applicatives

Une application moderne n’est presque jamais un bloc unique. Elle se compose de services : une interface web, une interface de programmation (API), une base de données, un espace de cache, des tâches de fond. Une brique applicative correspond à un de ces services, avec une seule responsabilité. L’avantage est le même qu’en construction : on remplace ou on met à jour une brique sans démonter le reste, et on voit tout de suite laquelle pose problème.

Docker : une brique, un conteneur

Docker emballe un service avec tout ce dont il a besoin pour fonctionner (système minimal, bibliothèques, configuration) dans un conteneur. Ce conteneur démarre de la même façon sur mon poste, en préproduction et sur le serveur. Ce que cela apporte :

• la reproductibilité : plus de « ça marche chez moi » ;
• l’isolement : chaque service a ses propres versions de bibliothèques, sans conflit avec les autres ;
• des limites de ressources : on peut plafonner la mémoire d’un conteneur pour qu’un service gourmand ne fasse pas tomber les autres ;
• une installation et un retour arrière simples : on remplace l’image, on relance.

Docker ne règle pas tout : un conteneur mal configuré reste vulnérable, et les données qu’il contient doivent être stockées dans des volumes sauvegardés, pas dans le conteneur lui-même.

Docker Compose : décrire l’ensemble dans un fichier

Lancer à la main une dizaine de conteneurs avec leurs options est fragile. Docker Compose permet de décrire tout l’ensemble dans un seul fichier : quels services, quelles images, quels réseaux, quels volumes, quelles variables, dans quel ordre démarrer. Une commande lance, arrête ou met à jour l’application entière.

• Un fichier lisible et versionné : l’infrastructure d’une application se relit et se compare comme du code.
• Des réseaux internes : la base de données n’est joignable que par les services qui en ont besoin, pas depuis l’extérieur.
• Des variables d’environnement : les secrets sont fournis au démarrage, jamais écrits dans le fichier ni dans l’image.
• Des vérifications de santé : un service n’est considéré démarré que lorsqu’il répond.

Le proxy : un point d’entrée unique

Un serveur qui héberge plusieurs applications ne devrait pas exposer chacune sur son propre port. Je place devant elles un reverse proxy : un seul service qui reçoit tout le trafic des ports web et le redirige vers la bonne application selon le nom de domaine demandé.

• Un seul endroit pour le chiffrement : les certificats sont obtenus et renouvelés par le proxy, les applications n’ont pas à s’en occuper.
• Une surface d’attaque réduite : seul le proxy est joignable depuis Internet ; les applications, les bases de données et les caches restent sur des réseaux internes.
• Des en-têtes de sécurité communs : politique de transport sécurisé, masquage de l’identité du serveur.
• Des journaux centralisés : un seul point pour voir qui a demandé quoi, avec des adresses tronquées quand c’est possible.
• Ajouter ou retirer une application sans toucher aux autres : on ajoute ou on désactive un fichier de configuration, puis on recharge.

Exemple : un proxy unique qui route par nom de domaine

Dans mon organisation, un dépôt dédié contient ce point d’entrée unique : un proxy (Caddy) qui est le seul conteneur à publier les ports web et qui gère le chiffrement automatiquement. Il route chaque nom de domaine vers l’application correspondante :

• un réseau Docker partagé est créé par le proxy ;
• chaque application déclare ce réseau comme externe et n’y rattache que son service d’entrée, sous un nom d’alias (par exemple le nom de l’application suivi de « web ») ;
• les fichiers de production des applications ne publient aucun port et ne gèrent pas le chiffrement : ils font confiance aux en-têtes transmis par le proxy, et uniquement ceux du proxy ;
• un fichier de configuration par application permet de l’activer ou de la désactiver en le renommant, puis en rechargeant ;
• l’accès aux interfaces d’administration peut être limité à des adresses autorisées, et la configuration refuse de démarrer si cette liste est absente (échec fermé).

Le serveur d’entrée est lui-même durci : système de fichiers en lecture seule, droits système retirés sauf celui d’écouter sur les ports web, interdiction de gagner des privilèges, limites de ressources.

Ce que cela apporte aussi : de la capacité

Chaque application a plusieurs conteneurs, et chacun a un plafond de mémoire. Additionner ces plafonds donne un budget pour dimensionner le serveur. Un proxy unique permet en outre d’éviter qu’un proxy soit répété dans chaque application, ce qui libère de la mémoire et réduit le nombre de choses à surveiller. Je mesure la consommation réelle avant de décider du dimensionnement, plutôt que de me fier aux seuls plafonds.

Les limites à connaître

• Un réseau partagé relie les services d’entrée : si l’un est compromis, il peut voir les autres. Atténuation : retirer les droits inutiles des conteneurs ; correctif propre : un réseau par application.
• Le proxy est un point unique de défaillance : s’il tombe, tout tombe. Il doit être simple, surveillé et redémarrable rapidement.
• Docker ne remplace pas les sauvegardes : les volumes doivent être sauvegardés et la restauration testée.
• Le pare-feu de l’hôte reste nécessaire : Docker peut contourner certaines règles pour les ports qu’il publie ; n’ouvrir que les ports utiles.

Par où commencer

1. Découper l’application en services et identifier ce qui doit rester interne.
2. Décrire l’ensemble dans un fichier Compose, avec des volumes pour les données.
3. Sortir les secrets du fichier et des images.
4. Placer un proxy devant, avec chiffrement automatique.
5. Sauvegarder les volumes et tester une restauration.

Mettre à jour une application sans toucher aux autres

1. Je construis la nouvelle version de l’image de la brique concernée.
2. Je la déploie en préproduction, où l’ensemble Compose est identique à celui de production.
3. Après validation, je mets à jour uniquement ce service ; le proxy continue de router les autres applications sans interruption.
4. Si quelque chose ne va pas, je reviens à l’image précédente : la brique, pas le serveur, est restaurée.

Ce que je surveille

• La disponibilité de chaque application, par une sonde externe.
• La mémoire réellement consommée par conteneur, comparée au plafond fixé.
• Les certificats : leur renouvellement automatique doit être vérifié, pas supposé.
• Les sauvegardes des volumes : présence, date, test de restauration.
• Les mises à jour de sécurité des images et du système hôte.

Rien de tout cela n’est réservé aux grandes infrastructures : c’est une question de discipline, et de savoir à l’avance ce qui sera surveillé avant qu’un incident ne le révèle.

Quand Docker n’est pas nécessaire

Un site statique, composé de simples fichiers, n’a besoin ni de conteneur ni de proxy applicatif : un hébergement web classique suffit, et c’est plus simple à maintenir. Les conteneurs deviennent intéressants quand il y a plusieurs services qui dépendent les uns des autres, des versions précises à figer, ou plusieurs applications à faire cohabiter. Choisir l’outil proportionné au besoin fait partie du métier.

En résumé

Des briques isolées dans des conteneurs, un fichier qui les assemble et un proxy unique qui les expose : cette organisation rend un serveur multi-applications plus lisible, plus sûr et plus simple à faire évoluer. Elle n’est pas une fin en soi : elle sert à garder la maîtrise quand le nombre d’applications augmente. Pour la façon dont je déploie ces ensembles, lisez aussi bonnes pratiques de développement.