network_mode: service:vpn și numele de host db dispărut

Partajarea spațiului de nume al VPN este o alegere de topologie. Fie db își păstrează propria adresă și vpn se alătură acelei rețele, fie totul răspunde pe loopback.

Adaugi network_mode: service:vpn în aplicație, repornești stiva, iar aplicația moare pentru că db nu mai este rezolvat. Nimic nu a fost redenumit în fișierul compose, așa că suspecții evidente sunt DNS și baza de date. Schimbarea reală este mai mică și mai ciudată: aplicația a încetat să fie membru al rețelei Compose în care există acel nume. Până când decizi din ce spațiu de nume trebuie să răspundă baza de date, fiecare corectare a numelui de host este o presupunere.

De ce numele de host db a încetat să fie rezolvat

Un serviciu care folosește network_mode nu are adresă proprie pe o rețea Compose; împrumută spațiul de nume al serviciului numit. Acel spațiu aduce propriile interfețe, rute, spațiu de porturi și rezolvator, și înlocuiește atașarea aplicației la rețeaua backend. Numele db nu a fost niciodată abstract: trăia pe acea rețea și era rezolvat prin DNS-ul ei încorporat. Elimină atașarea și numele nu mai are unde să fie rezolvat.

Confirmă asta din interiorul containerelor, nu de pe host. O căutare care eșuează în aplicație dar reușește în containerul bazei de date înseamnă că numele este în regulă, iar apartenența nu. Acel rezultat așază corectarea în topologia compose, nu în setările rezolvatorului aplicației.

Trei întrebări înainte de a edita fișierul

Răspunde în ordine, pentru că fiecare îngustează topologia. La ce trebuie să răspundă baza de date: la un nume de host pe care îl folosesc alte containere, sau doar la aplicație pe loopback? Trebuie aplicația să publice un port către host, și ce serviciu l-ar deține? Trebuie baza de date să fie accesibilă de pe host sau de pe altă mașină, sau doar din interiorul tunelului?

Dacă baza de date are nevoie de propriul nume și aplicația nu publică nimic, ține-le pe atașări separate. Dacă aplicația trebuie să publice un port și totul trece prin tunel, pune baza de date în spațiul de nume al VPN și folosește loopback. Amestecarea celor două produce o stivă care pornește curat și eșuează la conectare.

Lasă baza de date unde este

Schimbarea mai mică atașează proprietarul spațiului de nume la rețeaua care conține deja baza de date. Aplicația moștenește acea atașare pentru că împarte stiva vpn, iar db este rezolvat exact ca înainte.

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

Nu adăuga networks și în aplicație. Compose respinge acea proprietate alături de network_mode în același serviciu, iar eroarea indică fișierul, nu perechea. Dacă clientul VPN filtrează destinația backend în interiorul spațiului său de nume, ajustează și politica de rețea locală acceptată; o atașare partajată oferă o cale, dar nu anulează acel filtru.

Mută baza de date în spațiul de nume

Schimbarea mai mare pune baza de date în același spațiu de nume și îndreaptă aplicația spre 127.0.0.1 cu portul real. Două procese nu pot lega amândouă aceeași adresă și același port doar pentru că au pornit în containere diferite, așa că o bază de date care ascultă și pe adresa wildcard se va ciocni cu orice altceva care face asta. Verifică ascultătorul înainte de a-l muta.

Porturile publicate aparțin serviciului care deține spațiul de nume. Adăugarea ports în aplicație este respinsă alături de network_mode, iar inventarea unei adrese separate pentru aplicație descrie o interfață care nu există.

Disponibilitate, blocare și rezolvatorul

depends_on ordonează pornirea containerelor; nu este dovada că tunelul este activ și nu oprește traficul când tunelul cade. Tratează accesibilitatea, disponibilitatea tunelului și blocarea defecțiunilor ca trei cerințe separate. O stivă care îndeplinește doar prima trece un test manual într-o zi bună și pierde într-o zi proastă. Scrie cele trei răspunsuri lângă fișierul compose, acolo unde se va uita următoarea persoană.

Partajarea spațiului de nume înseamnă și că aplicația moștenește rezolvatorul containerului VPN, ceea ce ajută când tunelul impune servere DNS și încurcă atunci când nu o face. Verifică ce conține de fapt spațiul de nume în loc să presupui că se aplică rezolvatorul hostului. Referința serviciilor Compose documentează network_mode, ports și comportamentul dependențelor într-un singur loc, inclusiv de ce un serviciu network_mode nu are adresă proprie.

Articole similare