Vous ajoutez network_mode: service:vpn à l’application, redémarrez la pile, et l’application meurt parce que db ne se résout plus. Rien n’a été renommé dans le fichier compose, donc les suspects évidents sont le DNS et la base de données. Le vrai changement est plus petit et plus étrange : l’application a cessé d’être membre du réseau Compose où ce nom existe. Tant que vous ne décidez pas de quel espace de noms la base de données doit répondre, chaque correction de nom d’hôte est une supposition.

Pourquoi le nom d’hôte db a cessé de se résoudre

Un service qui utilise network_mode n’a pas d’adresse propre sur un réseau Compose ; il emprunte l’espace de noms du service nommé. Cet espace de noms apporte ses propres interfaces, routes, espace de ports et résolveur, et il remplace le rattachement de l’application au réseau backend. Le nom db n’a jamais été abstrait : il vivait sur ce réseau et se résolvait via son DNS intégré. Retirez le rattachement et le nom n’a plus nulle part où se résoudre.

Confirmez-le depuis l’intérieur des conteneurs plutôt que depuis l’hôte. Une résolution qui échoue dans l’application mais réussit dans le conteneur de la base de données signifie que le nom est correct et l’appartenance non. Ce résultat place aussi la correction dans la topologie compose plutôt que dans les réglages du résolveur de l’application.

Trois questions avant de modifier le fichier

Répondez-y dans l’ordre, car chacune resserre la topologie. Sur quoi la base de données doit-elle répondre : un nom d’hôte que d’autres conteneurs utilisent, ou seulement l’application sur loopback ? L’application doit-elle publier un port vers l’hôte, et quel service le posséderait ? La base de données doit-elle être joignable depuis l’hôte ou depuis une autre machine, ou seulement depuis l’intérieur du tunnel ?

Si la base de données a besoin de son propre nom et que l’application ne publie rien, gardez-les sur des rattachements séparés. Si l’application doit publier un port et que tout passe par le tunnel, mettez la base de données dans l’espace de noms du VPN et utilisez loopback. Mélanger les deux produit une pile qui démarre proprement et échoue à la connexion.

Laissez la base de données où elle est

Le changement plus petit rattache le propriétaire de l’espace de noms au réseau qui contient déjà la base de données. L’application hérite de ce rattachement parce qu’elle partage la pile vpn, et db se résout exactement comme avant.

services:
  vpn:
    networks:
      - backend
  app:
    network_mode: service:vpn
  db:
    networks:
      - backend
networks:
  backend:

N’ajoutez pas networks à l’application non plus. Compose rejette cette propriété aux côtés de network_mode dans le même service, et l’erreur pointe le fichier plutôt que la paire. Si le client VPN filtre la destination backend à l’intérieur de son espace de noms, ajustez aussi sa politique de réseau local prise en charge ; un rattachement partagé offre un chemin mais ne neutralise pas ce filtre.

Déplacez la base de données dans l’espace de noms

Le changement plus grand place la base de données dans le même espace de noms et pointe l’application vers 127.0.0.1 avec le vrai port. Deux processus ne peuvent pas tous deux lier la même adresse et le même port simplement parce qu’ils ont démarré dans des conteneurs différents, donc une base de données qui écoute aussi sur l’adresse wildcard entrera en collision avec tout ce qui le fait. Vérifiez l’écouteur avant de le déplacer.

Les ports publiés appartiennent au service propriétaire de l’espace de noms. Ajouter ports à l’application est rejeté aux côtés de network_mode, et inventer une adresse d’application séparée décrit une interface qui n’existe pas.

Disponibilité, blocage et le résolveur

depends_on ordonne le démarrage des conteneurs ; ce n’est pas la preuve que le tunnel est actif et il n’arrête pas le trafic quand le tunnel tombe. Traitez l’accessibilité, la disponibilité du tunnel et le blocage des pannes comme trois exigences distinctes. Une pile qui ne satisfait que la première passe un test manuel un bon jour et fuit un mauvais jour. Écrivez les trois réponses à côté du fichier compose, là où la personne suivante regardera.

Partager l’espace de noms signifie aussi que l’application hérite du résolveur du conteneur VPN, ce qui aide quand le tunnel impose des serveurs DNS et perturbe quand il ne le fait pas. Vérifiez ce que l’espace de noms contient réellement au lieu de supposer que le résolveur de l’hôte s’applique. La référence des services Compose documente network_mode, ports et le comportement des dépendances au même endroit, y compris pourquoi un service network_mode n’a pas d’adresse propre.

Articles similaires