Edukiontziak ez du VPN bidez bakarrik dagoen API-ra iristen? Egin proxy ostalarian

Zure Compose zerbitzuak denbora-muga jotzen du makinako nabigatzaileak kexarik gabe irekitzen duen API baten aurrean. Desberdintasun hori da arrastoa: funtzionatzen duen eskaera VPN tunel bat duen ostalari batetik abiatzen da, eta zintzilik geratzen dena bere sare-pila propioa duen edukiontzi batetik. Edukiontziaren barruan ezerk ez daki tunelaren bideak, beraz helmuga pribatua iristezin jarraitzen du izena nola idatzi ere. Konponbidea ostalariaren bidezko jauzi deliberatua da, ez bide-taula argiago bat.

Has zaitez bi bideek zergatik desberdin egiten duten, eta gero erabaki non bizi behar duen tunelak.

Zergatik funtzionatzen duen ostalariak eta edukiontziak ez

Tunela altxatzeak interfaze bat, bide multzo bat eta, normalean, VPNak emandako resolver sarrera bat ematen dizkio ostalariari. Edukiontziak ez du horretatik ezer heredatzen: motorraren zubian interfaze batekin eta zubi horretara bideratzen duen bide lehenetsi batekin hasten da. Ostalarian instalatutako bideak ikusezinak dira izen-espazio horren barruan exekutatzen den edozertarako.

Horregatik sintomak inkoherenteak dirudite, ez besterik gabe hautsita. Ostalariak izen pribatua ebazten du eta konektatzen da, han bai izena bai bidea existitzen direlako. Edukiontziak zubiaren bidean ezerk irits ezin duen helbide pribatu batera bidaltzen du paketea, eta eskaerak denbora-muga jotzen du. Izena edukiontziaren hosts fitxategian gehitzeak ez du ezer aldatzen, helbidea bera iristezina delako edukiontzia dagoen lekutik.

Iritsi ostalarira edukiontziaren barrutik

Edukiontziaren barruan localhost deitzen duen prozesu batek edukiontzia deitzen du. Docker Desktopek host.docker.internal argitaratzen du motorra exekutatzen duen makinera atzera begiratzen duen izen gisa; Linux motorrek definitugabe uzten dute zerbitzuak eskatu ezean, eta beheko mapatzeak horixe egiten du. Horrekin, aplikazioak izen bat eta portu bat helburu ditu helbide pribatuaren ordez.

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

Tunela jauziaren ostalari aldean geratzen da, eta aldagai horretako portua proxya entzuten egongo dena da. Tunela galtzen duen edukiontziak orain jauzi ezagun bakarrean egiten du huts, inoiz izan ez zuen bide bat saiakeran aritu ordez.

Aukeratu non bizi den tunela

API pribatu bat behar duen Compose zerbitzu baterako hiru forma dira posible, eta prozesu zeinek duen tunela jabetzan bereizten dira. VPN bezero bat edukiontziaren irudiaren barruan exekuta daiteke, eta horrek tunel gailu bat agerian jartzea eta harekin datorren sare-administrazio gaitasuna ematea eskatzen du. Aplikazioak tunel edukiontzi bereizi baten sare izen-espazioa parteka dezake, beraz bi prozesuek pila bat eta bide-taula bat ikusten dute. Edo tunela ostalarian geratzen da, ostalaritik edukiontzira doan aurreratze-estu batekin.

Lehenengo biak profil fitxategiak, berriz konektatzeko portaera eta resolver politika proiektura ekartzen dituzte, eta fitxategiko zerbitzu bakoitza tunelaren osasunaren menpe jartzen dute. API dei bakar baterako akoplamendu gehiegi da. Barneko mutur puntu bakar bat irakurtzen duen garapen pilarentzat, ostalari aldeko aurreratzailea da aldaketarik txikiena eta kredentzialak plataforma taldeak kudeatzen dituen tokian mantentzen dituena.

Argitaratu bide estu bat ostalarian

Hasi aurreratzaileak heredatzen duenetik: exekutatu tunelaren jabea den kontuarekin, eta haren irteerako socketek ostalariaren bideak eta ostalariaren resolverra hartuko dituzte. nginx location bloke batek bide bat estaltzen du.

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

Hartu helbidea eta portua ordezkaritzat eta jarri APIak benetan entzuten duen bikotea. Hurrengo upstream bakoitzak bere location blokea merezi du, eta bloke bakoitzak zerbitzu honek deitzen dituen bideak bakarrik onartu behar ditu, proxya sare pribaturako ate orokor bihur ez dadin. Lotu entzulea zubiaren helbidera host-gateway bidez iristen diren bezeroentzat, loopback-era bezeroak ostalariaren sare izen-espazioa partekatzen duenean bakarrik, eta inoiz ez 0.0.0.0 helbidera. Aukeratu oraindik libre dagoen portu bat ere: lehendik hartutako zenbaki batek proxya entzuten ez duenean uzten du edukiontziak denbora-muga jotzen jarraitzen duen bitartean, eta hori hasi zinen sare akatsekin nahastea ezinezkoa da.

Portuak, izenak eta TLS erabakia

Izen ebazpena bideratzearen modu berean banatzen da. Edukiontziaren bilaketa publikoak motorraren resolverretik igarotzen dira, beraz ostalarian ebazten den izen pribatua ez da edukiontziaren barruan ebatziko. Proxya da izen pribatua ebazten duen osagaia, ostalariaren resolverra heredatzen duelako.

TLS da atzeratzen den eta gero hurrengo hutsegitea azaltzen duen erabakia. Proxyak byteak ukitugabe aurreratzen baditu, edukiontziak APIaren ziurtagiri propioa ikusten du eta barne CA behar du bere konfiantza biltegian. Proxyak TLS amaitzen badu, konfiantza hori ostalarira pasatzen da eta aplikazioak jasotzen duen host goiburutik estekak eraikitzen hasten da. Aukeratu antolaketa bakarra eta aplikatu baliabide bakoitzari, besteak jaulkitako birbideratzeak edukiontziak ebatzi ezin duen ostalari-izen batera eramaten duelako.

Egiaztatu zerbitzuaren barrutik

Bidali eskaera edukiontzitik, ez ostalaritik: curl arrunta proxyaren bidearen aurka, gero aplikazioaren beraren osasun egiaztapena. Proxyak erantzuten duenean baina aplikazioak huts egiten jarraitzen duenean, alderatu hiru gauza: eraikitzen duen oinarrizko URLa, bere inguruneko proxy aldagai edozein eta fidatzen duen CA. Guztiak edukiontziaren ingurunean eta erregistroetan daude, eta edozein konpontzeak VPNa bakean uzten du.

Idatzi aukeratutako antolaketa proiektuaren READMEan, oraindik freskoa den bitartean. Bestela, denbora-muga hau jotzen duen hurrengo pertsonak arratsalde bera emango du tunela ostalarian bizi dela berriro aurkituz.