network_mode: service:vpn i nestalo ime hosta db

Dodate network_mode: service:vpn aplikaciji, restartujete stack i aplikacija umre jer se db više ne razrješava. Ništa u compose datoteci nije preimenovano, pa su očigledni sumnjivci DNS i baza podataka. Stvarna promjena je manja i čudnija: aplikacija je prestala biti član Compose mreže u kojoj to ime postoji. Dok ne odlučite iz kojeg imenskog prostora baza podataka treba da odgovara, svaka popravka imena hosta je nagađanje.

Zašto se ime hosta db prestalo razrješavati

Servis koji koristi network_mode nema vlastitu adresu na Compose mreži; on posuđuje imenski prostor imenovanog servisa. Taj imenski prostor donosi vlastita sučelja, rute, prostor portova i razrješivač, i zamjenjuje vezanost aplikacije za backend mrežu. Ime db nikada nije bilo apstraktno: živjelo je na toj mreži i razrješavalo se kroz njezin ugrađeni DNS. Uklonite vezanost i ime nema gdje da se razrješi.

Potvrdite to iz unutrašnjosti kontejnera, a ne s hosta. Pretraga koja ne uspije u aplikaciji ali uspije u kontejneru baze podataka znači da je ime ispravno, a članstvo nije. Taj rezultat također smješta popravku u compose topologiju umjesto u postavke razrješivača aplikacije.

Tri pitanja prije nego uredite datoteku

Odgovorite na njih po redu, jer svako sužava topologiju. Na čemu baza podataka mora odgovarati: na imenu hosta koje koriste drugi kontejneri, ili samo aplikaciji na loopbacku? Mora li aplikacija objaviti port na host, i koji servis bi ga posjedovao? Mora li baza podataka biti dostupna s hosta ili s drugog računala, ili samo iz unutrašnjosti tunela?

Ako bazi podataka treba vlastito ime, a aplikacija ništa ne objavljuje, držite ih na odvojenim vezanostima. Ako aplikacija mora objaviti port i sve ide kroz tunel, stavite bazu podataka u VPN imenski prostor i koristite loopback. Miješanje toga dvoje daje stack koji se čisto pokreće i pada u trenutku spajanja.

Ostavite bazu podataka gdje jeste

Manja promjena veže vlasnika imenskog prostora na mrežu koja već sadrži bazu podataka. Aplikacija nasljeđuje tu vezanost jer dijeli vpn stack, i db se razrješava točno kao prije.

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

Ne dodajte networks i aplikaciji. Compose odbija to svojstvo uz network_mode u istom servisu, a greška pokazuje na datoteku, a ne na par. Ako VPN klijent filtrira backend odredište unutar svog imenskog prostora, prilagodite i njegovu podržanu politiku lokalne mreže; zajednička vezanost nudi put, ali ne poništava taj filter.

Premjestite bazu podataka u imenski prostor

Veća promjena stavlja bazu podataka u isti imenski prostor i usmjerava aplikaciju na 127.0.0.1 sa stvarnim portom. Dva procesa ne mogu oba zauzeti istu adresu i port samo zato što su pokrenuta u različitim kontejnerima, pa će se baza podataka koja također sluša na wildcard adresi sudariti sa svime drugim što to čini. Provjerite slušatelja prije nego je premjestite.

Objavljeni portovi pripadaju servisu koji posjeduje imenski prostor. Dodavanje ports aplikaciji odbija se uz network_mode, a izmišljanje zasebne adrese aplikacije opisuje sučelje koje ne postoji.

Spremnost, blokiranje i razrješivač

depends_on poreda pokretanje kontejnera; to nije dokaz da je tunel aktivan i ne zaustavlja promet kad tunel padne. Tretirajte dostupnost, spremnost tunela i blokiranje kvarova kao tri odvojena zahtjeva. Stack koji zadovoljava samo prvi prolazi ručni test na dobar dan i curi na loš. Zapišite tri odgovora pored compose datoteke, gdje će sljedeća osoba pogledati.

Dijeljenje imenskog prostora također znači da aplikacija nasljeđuje razrješivač VPN kontejnera, što pomaže kad tunel nameće DNS servere, a zbunjuje kad ne. Provjerite što imenski prostor stvarno sadrži umjesto da pretpostavljate da razrješivač hosta vrijedi. Referenca za Compose servise dokumentuje network_mode, ports i ponašanje zavisnosti na jednom mjestu, uključujući zašto servis s network_mode nema vlastitu adresu.