network_mode: service:vpn en de ontbrekende db-hostnaam

De VPN-naamruimte delen is een topologiekeuze. Ofwel houdt db zijn eigen adres en sluit de vpn zich aan bij dat netwerk, ofwel antwoordt alles op loopback.

Je voegt network_mode: service:vpn toe aan de app, herstart de stack, en de app sterft omdat db niet meer wordt opgelost. In het compose-bestand is niets hernoemd, dus de voor de hand liggende verdachten zijn DNS en de database. De werkelijke verandering is kleiner en vreemder: de app is geen lid meer van het Compose-netwerk waar die naam bestaat. Tot je beslist vanuit welke naamruimte de database moet antwoorden, is elke hostnaam-correctie giswerk.

Waarom de db-hostnaam niet meer werd opgelost

Een service die network_mode gebruikt, heeft geen eigen adres op een Compose-netwerk; hij leent de naamruimte van de genoemde service. Die naamruimte brengt zijn eigen interfaces, routes, poortruimte en resolver mee, en vervangt de aansluiting van de app op het backend-netwerk. De naam db was nooit abstract: hij leefde op dat netwerk en werd opgelost via de ingebouwde DNS ervan. Verwijder de aansluiting en de naam heeft nergens meer om op te lossen.

Bevestig dat van binnenuit de containers in plaats van vanaf de host. Een opzoeking die in de app faalt maar in de databasecontainer slaagt, betekent dat de naam in orde is en het lidmaatschap niet. Dat resultaat plaatst de correctie ook in de compose-topologie in plaats van in de resolverinstellingen van de app.

Drie vragen voordat je het bestand bewerkt

Beantwoord ze op volgorde, want elk antwoord vernauwt de topologie. Waarop moet de database antwoorden: een hostnaam die andere containers gebruiken, of alleen de app op loopback? Moet de app een poort naar de host publiceren, en welke service zou die bezitten? Moet de database bereikbaar zijn vanaf de host of vanaf een andere machine, of alleen van binnenuit de tunnel?

Als de database zijn eigen naam nodig heeft en de app niets publiceert, houd ze dan op aparte aansluitingen. Als de app een poort moet publiceren en alles via de tunnel loopt, zet de database dan in de VPN-naamruimte en gebruik loopback. De twee mengen levert een stack op die schoon start en bij het verbinden faalt.

Laat de database waar hij is

De kleinere verandering koppelt de eigenaar van de naamruimte aan het netwerk dat de database al bevat. De app erft die aansluiting omdat hij de vpn-stack deelt, en db wordt precies zoals voorheen opgelost.

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

Voeg networks niet ook aan de app toe. Compose weigert die eigenschap naast network_mode in dezelfde service, en de fout wijst naar het bestand in plaats van naar het paar. Als de VPN-client de backend-bestemming binnen zijn naamruimte filtert, pas dan ook zijn ondersteunde lokaalnetwerkbeleid aan; een gedeelde aansluiting biedt een pad maar heft dat filter niet op.

Verplaats de database naar de naamruimte

De grotere verandering zet de database in dezelfde naamruimte en richt de app op 127.0.0.1 met de echte poort. Twee processen kunnen niet allebei hetzelfde adres en dezelfde poort binden alleen omdat ze in verschillende containers zijn gestart, dus een database die ook op het wildcard-adres luistert, botst met alles wat dat ook doet. Controleer de listener voordat je hem verplaatst.

Gepubliceerde poorten horen bij de service die de naamruimte bezit. ports aan de app toevoegen wordt samen met network_mode geweigerd, en een apart app-adres verzinnen beschrijft een interface die niet bestaat.

Gereedheid, blokkering en de resolver

depends_on ordent het starten van containers; het is geen bewijs dat de tunnel actief is en het stopt geen verkeer wanneer de tunnel wegvalt. Behandel bereikbaarheid, tunnelgereedheid en foutblokkering als drie afzonderlijke eisen. Een stack die alleen de eerste vervult, slaagt op een goede dag voor een handmatige test en lekt op een slechte. Schrijf de drie antwoorden naast het compose-bestand, waar de volgende persoon zal kijken.

Een naamruimte delen betekent ook dat de app de resolver van de VPN-container erft, wat helpt wanneer de tunnel DNS-servers opdringt en verwart wanneer niet. Controleer wat de naamruimte werkelijk bevat in plaats van aan te nemen dat de resolver van de host geldt. De Compose-servicereferentie documenteert network_mode, ports en het gedrag van afhankelijkheden op één plek, inclusief waarom een network_mode-service geen eigen adres heeft.

Gerelateerde artikelen