network_mode: service:vpn e il nome host db mancante

Aggiungi network_mode: service:vpn all’applicazione, riavvii lo stack e l’applicazione muore perché db non si risolve più. Nulla è stato rinominato nel file compose, quindi i sospetti ovvi sono il DNS e il database. Il cambiamento reale è più piccolo e più strano: l’applicazione ha smesso di essere membro della rete Compose dove quel nome esiste. Finché non decidi da quale spazio dei nomi il database deve rispondere, ogni correzione del nome host è una congettura.

Perché il nome host db ha smesso di risolversi

Un servizio che usa network_mode non ha un indirizzo proprio su una rete Compose; prende in prestito lo spazio dei nomi del servizio nominato. Quello spazio dei nomi porta con sé le proprie interfacce, rotte, spazio delle porte e resolver, e sostituisce il collegamento dell’applicazione alla rete backend. Il nome db non è mai stato astratto: viveva su quella rete e si risolveva tramite il suo DNS incorporato. Rimuovi il collegamento e il nome non ha più dove risolversi.

Confermalo dall’interno dei container invece che dall’host. Una ricerca che fallisce nell’applicazione ma riesce nel container del database significa che il nome è a posto e l’appartenenza no. Quel risultato colloca anche la correzione nella topologia compose invece che nelle impostazioni del resolver dell’applicazione.

Tre domande prima di modificare il file

Rispondi in ordine, perché ciascuna restringe la topologia. Su cosa deve rispondere il database: un nome host che altri container usano, o solo l’applicazione su loopback? L’applicazione deve pubblicare una porta verso l’host, e quale servizio la possiederebbe? Il database deve essere raggiungibile dall’host o da un’altra macchina, o solo dall’interno del tunnel?

Se il database ha bisogno del proprio nome e l’applicazione non pubblica nulla, tienili su collegamenti separati. Se l’applicazione deve pubblicare una porta e tutto passa attraverso il tunnel, metti il database nello spazio dei nomi della VPN e usa loopback. Mescolare le due cose produce uno stack che parte pulito e fallisce alla connessione.

Lascia il database dov’è

Il cambiamento più piccolo collega il proprietario dello spazio dei nomi alla rete che già contiene il database. L’applicazione eredita quel collegamento perché condivide lo stack vpn, e db si risolve esattamente come prima.

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

Non aggiungere networks anche all’applicazione. Compose rifiuta quella proprietà insieme a network_mode nello stesso servizio, e l’errore punta al file invece che alla coppia. Se il client VPN filtra la destinazione backend dentro il suo spazio dei nomi, regola anche la sua politica di rete locale supportata; un collegamento condiviso offre un percorso ma non annulla quel filtro.

Sposta il database nello spazio dei nomi

Il cambiamento più grande mette il database nello stesso spazio dei nomi e punta l’applicazione a 127.0.0.1 con la porta reale. Due processi non possono entrambi associare lo stesso indirizzo e la stessa porta solo perché sono partiti in container diversi, quindi un database che ascolta anche sull’indirizzo wildcard entrerà in collisione con qualunque altra cosa lo faccia. Controlla l’ascoltatore prima di spostarlo.

Le porte pubblicate appartengono al servizio proprietario dello spazio dei nomi. Aggiungere ports all’applicazione viene rifiutato insieme a network_mode, e inventare un indirizzo separato per l’applicazione descrive un’interfaccia che non esiste.

Disponibilità, blocco e il resolver

depends_on ordina l’avvio dei container; non è prova che il tunnel sia attivo e non ferma il traffico quando il tunnel cade. Tratta raggiungibilità, disponibilità del tunnel e blocco dei guasti come tre requisiti distinti. Uno stack che soddisfa solo il primo supera un test manuale in un giorno buono e perde in un giorno cattivo. Scrivi le tre risposte accanto al file compose, dove guarderà la persona successiva.

Condividere lo spazio dei nomi significa anche che l’applicazione eredita il resolver del container VPN, il che aiuta quando il tunnel impone server DNS e confonde quando non lo fa. Controlla cosa contiene davvero lo spazio dei nomi invece di supporre che il resolver dell’host si applichi. Il riferimento dei servizi Compose documenta network_mode, ports e il comportamento delle dipendenze in un solo posto, incluso perché un servizio network_mode non ha un indirizzo proprio.