Vsebnik ne doseže API-ja, dostopnega samo prek VPN? Posredništvo na gostitelju

Vaša storitev v Composeu se ustavi s časovno omejitvijo pri API-ju, ki ga brskalnik na istem računalniku odpre brez pritožbe. Prav ta razlika je sled: zahteva, ki deluje, zapusti gostitelja s predorom VPN, zahteva, ki obvisi, pa zapusti vsebnik z lastnim omrežnim skladom. Nič v vsebniku ne pozna poti predora, zato zasebni cilj ostane nedosegljiv, ne glede na zapis imena. Rešitev je namerno preskočitev skozi gostitelja, ne pametnejša tabela usmerjanja.

Začnite s tem, zakaj se poti razlikujeta, nato odločite, kje naj živi predor.

Zakaj gostitelj deluje, vsebnik pa ne

Dvig predora gostitelju da vmesnik, nabor poti in običajno vnos v razreševalniku, ki ga zagotovi VPN. Vsebnik ne podeduje ničesar od tega: začne z enim vmesnikom na mostu pogona in privzeto potjo, ki kaže na ta most. Poti, nameščene na gostitelju, so nevidne vsem, kar teče v tem imenskem prostoru.

Zato so simptomi videti neskladni, ne le pokvarjeni. Gostitelj razreši zasebno ime in se poveže, ker tam obstajata tako ime kot pot. Vsebnik pošlje paket na zasebni naslov, do katerega ne seže nič na poti čez most, in zahteva poteče. Dodajanje imena v datoteko hosts vsebnika ne spremeni ničesar, ker je naslov sam nedosegljiv s tistega mesta, kjer vsebnik stoji.

Dosezite gostitelja od znotraj vsebnika

Proces v vsebniku, ki kliče localhost, kliče vsebnik. Docker Desktop objavi host.docker.internal kot ime, ki kaže nazaj na računalnik, ki poganja pogon; pogoni Linux ga pustijo nedoločenega, razen če storitev zanj prosi, in to počne preslikava spodaj. S tem se aplikacija usmerja na ime in vrata namesto na zasebni naslov.

services:
  app:
    extra_hosts:
      - "host.docker.internal:host-gateway"
    environment:
      INTERNAL_API_HOST: "host.docker.internal:8666"

Predor ostane na gostiteljski strani preskoka, vrata v tej spremenljivki pa so tista, na katerih bo posrednik poslušal. Vsebnik, ki izgubi predor, zdaj odpove na enem znanem preskoku, namesto da bi poskusil pot, ki je nikoli ni imel.

Izberite, kje predor živi

Za storitev v Composeu, ki potrebuje zasebni API, so možne tri oblike in razlikujejo se po tem, kateri proces ima predor. Odjemalec VPN lahko teče v sliki vsebnika, kar zahteva izpostavitev naprave predora in dodelitev z njo povezane zmožnosti upravljanja omrežja. Aplikacija si lahko deli omrežni imenski prostor ločenega vsebnika s predorom, tako da oba procesa vidita en sklad in eno tabelo usmerjanja. Ali pa predor ostane na gostitelju, z ozkim posredovalnikom z gostitelja v vsebnik.

Prva dva v projekt potegneta profilne datoteke, vedenje ob ponovnem povezovanju in politiko razreševalnika ter naredita vsako storitev v datoteki odvisno od zdravja predora. To je preveč povezanosti za en klic API. Za razvojni sklad, ki bere en sam notranji končni naslov, je posredovalnik na strani gostitelja najmanjša sprememba, ki vendarle ohrani poverilnice tam, kjer jih upravlja ekipa platforme.

Objavite eno ozko pot na gostitelju

Začnite s tem, kar posredovalnik podeduje: zaženite ga pod računom, ki ima predor, in njegove odhodne vtičnice prevzamejo poti gostitelja in razreševalnik gostitelja. En blok location v nginx pokriva eno pot.

server {
    listen 8666;
    location /search/ {
        proxy_pass http://10.20.30.40:8090/;
        proxy_set_header Host internal-api.example;
        proxy_read_timeout 60s;
    }
}

Naslov in vrata obravnavajte kot nadomestna in vstavite par, na katerem API dejansko posluša. Vsak nadaljnji upstream si zasluži svoj blok location in vsak blok naj prepušča le poti, ki jih kliče ta storitev, da posrednik ne postane splošna vrata v zasebno omrežje. Poslušalca privežite na naslov mostu za odjemalce, ki prihajajo prek host-gateway, na loopback le takrat, ko si odjemalec deli omrežni imenski prostor gostitelja, in nikoli na 0.0.0.0. Izberite tudi vrata, ki so še prosta: zasedena številka pusti posrednik brez poslušanja, medtem ko vsebniku še naprej poteče čas, česar ni mogoče ločiti od omrežne okvare, s katero ste začeli.

Vrata, imena in odločitev o TLS

Razreševanje imen se deli enako kot usmerjanje. Javna iskanja vsebnika gredo skozi razreševalnik pogona, zato se zasebno ime, ki se razreši na gostitelju, v vsebniku ne bo razrešilo. Posrednik je sestavni del, ki razreši zasebno ime, ker podeduje razreševalnik gostitelja.

TLS je odločitev, ki se odloži in nato pojasni naslednjo napako. Če posrednik posreduje bajte nedotaknjene, vsebnik vidi lastno potrdilo API-ja in potrebuje notranji CA v svoji shrambi zaupanja. Če posrednik zaključi TLS, se to zaupanje preseli na gostitelja in aplikacija začne graditi povezave iz glave host, ki jo prejme. Izberite eno ureditev in jo uporabite pri vsakem viru, ker preusmeritev, ki jo izda druga, kaže na ime gostitelja, ki ga vsebnik ne more razrešiti.

Preverite od znotraj storitve

Pošljite zahtevo iz vsebnika, ne z gostitelja: navaden curl na pot posrednika in nato lastno preverjanje zdravja aplikacije. Ko posrednik odgovori, aplikacija pa še vedno odpove, primerjajte tri stvari: osnovni URL, ki ga gradi, katero koli posredniško spremenljivko v njegovem okolju in CA, ki mu zaupa. Vse je v okolju in dnevnikih vsebnika, popravilo katere koli od njih pa pusti VPN pri miru.

Izbrano ureditev zapišite v README projekta, dokler je še sveža. Sicer bo naslednja oseba, ki bo naletela na to časovno omejitev, preživela isto popoldne z odkrivanjem znova, da predor živi na gostitelju.