Comment configurer un réseau Docker dédié pour les backends de reverse proxy

Connectez le proxy inverse et chaque backend HTTP à un même réseau défini par l'utilisateur ; gardez les bases de données sur des réseaux d'application privés.

Publier le port de chaque backend sur l'hôte NAS est inutile lorsque le proxy peut résoudre les noms de service Compose sur un pont défini par l'utilisateur. Une configuration à deux réseaux donne au proxy un accès contrôlé aux backends web, tandis que les bases de données restent accessibles uniquement par leurs applications. Définissez la propriété des réseaux, évitez les alias ambigus, déterminez quels services nécessitent un accès sortant et vérifiez que les ports de l'hôte restent fermés.

Établissez la matrice d'accessibilité prévue

Répertoriez chaque connexion : client vers proxy, proxy vers backend, backend vers base de données, backend vers API externes et administrateur vers points de terminaison de maintenance. Indiquez le protocole, le port, le nom DNS et si le chemin traverse l'hôte.

Normalement, seul le proxy inverse devrait publier les ports 80 et 443. Les backends exposent leur port d'application au réseau Docker sans mappage ports vers l'hôte. Les bases de données rejoignent uniquement le réseau privé de l'application, sauf si un accès d'administration explicite est requis.

Choisissez des noms de service ou des alias réseau stables et uniques. Le DNS Docker résout les services sur les réseaux définis par l'utilisateur et partagés, mais des alias génériques tels que web peuvent entrer en conflit lorsque plusieurs projets Compose se connectent au même réseau de proxy.

Créez un réseau de proxy partagé et un réseau d'application privé

Créez le réseau de proxy une seule fois, marquez-le comme externe dans chaque projet d'application et connectez-y le proxy ainsi que le backend prévu. L'identité du réseau reste ainsi stable lorsqu'un projet Compose individuel est recréé.

Définissez un réseau privé par défaut ou nommé distinct pour chaque application et connectez-y son backend et sa base de données. Le backend devient le pont contrôlé entre le trafic du proxy et l'état privé ; le proxy ne devrait pas rejoindre le réseau de la base de données.

La documentation des définitions de réseaux Compose décrit les réseaux externes et la connexion des services dans Compose. Considérez un réseau externe comme étant géré en dehors de la pile applicative : le déploiement doit vérifier qu'il existe au lieu de supposer que Compose le créera ou le supprimera.

networks:
  proxy:
    external: true
  app-private:
    internal: true
services:
  web:
    networks: [proxy, app-private]
  db:
    networks: [app-private]

Supprimez les ports hôte inutiles et examinez les connexions sortantes

Une fois la route du proxy fonctionnelle, supprimez les publications de ports hôte des backends. La déclaration expose peut documenter le port du conteneur, mais ne constitue pas un pare-feu ; c'est l'appartenance au réseau qui détermine quels conteneurs peuvent se connecter.

N'utilisez internal: true que pour les réseaux dont les membres n'ont réellement besoin d'aucune route externe. Les backends qui appellent des fournisseurs d'identité, des webhooks, des services de paquets ou des API distantes peuvent échouer sur un réseau exclusivement interne. Utilisez un second réseau capable d'assurer les connexions sortantes lorsque la conception de l'application l'exige.

Protégez le socket Docker utilisé pour la découverte automatique des proxys. Un montage en lecture seule réduit les écritures accidentelles, mais ne rend pas le socket inoffensif ; un proxy de socket limité ou une configuration statique offre une surface de contrôle plus restreinte.

-15% OFF

ZimaBoard 2 - Mini serveur domestique pour votre grande idée

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Vérifiez le DNS des services, l'exposition des ports et l'isolation

Depuis le conteneur du proxy, résolvez le nom du service backend et appelez son point de terminaison d'état sur le port du conteneur. Depuis un conteneur sans lien, confirmez que le nom ou la connexion est inaccessible, sauf si ce conteneur se trouve intentionnellement sur le réseau du proxy.

Analysez l'hôte NAS depuis un autre appareil du réseau local et confirmez que seuls les ports du proxy sont ouverts. Testez ensuite TLS, les en-têtes transférés, les mises à niveau WebSocket, les téléversements volumineux et les redirections de l'application via le nom d'hôte public. La carte des services du serveur domestique doit répertorier le réseau du proxy parmi les éléments de la carte des services du serveur domestique.

Effectuez la restauration en rétablissant l'ancien mappage de port uniquement à des fins de diagnostic, et non comme dépendance cachée permanente. Arrêtez-vous si le proxy nécessite un accès direct à la base de données, si les alias dirigent vers le mauvais projet ou si la suppression d'un port hôte interrompt une intégration non documentée.

FAQ 

Un réseau Docker externe est-il automatiquement plus sécurisé ?

Non. « Externe » décrit la propriété du cycle de vie, pas la sécurité. En règle générale, chaque conteneur connecté peut communiquer conformément au comportement du pilote réseau et du pare-feu de l'hôte.

Les services backend doivent-ils toujours déclarer expose ?

Cette déclaration est facultative pour la connectivité sur un réseau défini par l'utilisateur, mais elle peut documenter le port prévu du conteneur. Elle ne publie pas le port sur l'hôte.

Le réseau du proxy peut-il être marqué comme interne ?

Uniquement si la conception du proxy et du routage conserve les chemins entrants et sortants requis. Un réseau interne bloque la connectivité externe normale des conteneurs connectés et peut interrompre les flux de certificats ou d'identité.

Pourquoi utiliser les noms de service plutôt que les adresses IP des conteneurs ?

Les adresses des conteneurs peuvent changer après une recréation. La découverte des services Docker fournit un nom stable au sein du réseau partagé, ce qui rend la configuration du proxy plus durable.

Restaurez la référence enregistrée, appliquez une seule fois la configuration approuvée, répétez la charge de travail d'origine dans des conditions proches de la production, vérifiez le signal de réussite promis, puis exécutez la procédure de restauration documentée. Ne clôturez pas la modification tant que les journaux, le calendrier, les autorisations, la capacité et les résultats récupérés ne correspondent pas tous aux critères d'acceptation.