Zergatik baztertzen dute Docker edukiontzietakoek VPNaren DNS ebazlea

VPN-a martxan dago, arakatzaileak barneko guneak lortzen ditu, eta edukiontziak oraindik ezin ditu izen berberak ebatzi. Pakete-instalazio bat izen-ebazpen errore batekin hiltzen da, hala nola EAI_AGAIN, edo aplikazio batek ezin du aurkitu ostalari-makinak kexarik gabe ebazten duen datu-basearen ostalaria. Edukiontziak ez du VPNak instalatu zuen ebazlea erabiltzen. Dockerek ostalariaren ebazlearen konfigurazioa kopiatu zuen edukiontzia sortzean, eta geroago ezerk ez zuen berriz kopiatu.

Ebazlearen bi ikuspegi makina bakarrean

Linuxen, Dockerek edukiontzi bakoitzari ostalariaren ebazlearen konfigurazioaren kopia bat ematen dio sorrera-unetan, loopback helbideak iragazten ditu eta 127.0.0.11 helbidean txertatutako DNS zerbitzari bat exekutatzen du, kanpora bidaltzen dituena kontsultak. Edukiontzia abiarazi ondoren /etc/resolv.conf berridazten duen VPN bezero batek ez du ezer aldatzen haren barruan. Edukiontzia berrabiarazteak une horretan ostalariaren ebazlea kasualitatez zuzena bada bakarrik laguntzen du.

Docker Desktopek macOS edo Windowsen geruza bat gehitzen du, deabrua makina birtual batean bizi delako. Baliteke ostalariaren VPNaren ebazlea inoiz ez izatea VM horretarako ikusgai, beraz berrabiarazteak ez du ezer aldatzen. Alderatu bi ikuspegiak konponbidea aukeratu aurretik: docker exec mycontainer cat /etc/resolv.conf ostalariaren ebazleen zerrendaren ondoan.

Ebazle publiko bat zerrendatzen duen edukiontzi batek, ostalariak barnekoa zerrendatzen duen bitartean, izen publikoak ebatzi eta barnekoetan huts egingo du. Banaketa hori da arazo honen sinadura.

A aukera: tunelaren ebazlea edukiontzi bakoitzari ematea

Dockerek edukiontzi bakoitzeko DNS ezarpenak onartzen ditu, eta hori da funtzionatzen duen aldaketarik txikiena. Irakurri lehenik VPNaren ebazlearen helbideak: scutil --dns macOSen, resolvectl status edo bezeroaren beraren egoera-irteera Linuxen. Ondoren abiarazi edukiontzia horiekin, adibidez docker run --dns 192.168.2.1 --dns 192.168.123.1 myimage. Compose-n ezarpen bera zerbitzuaren azpiko zerrenda bat da, eta bertan bertsio-kontrolean bizi da, norbaiten shell historialaren ordez.

/etc/docker/daemon.json fitxategiko dns matrizeak edukiontzi berri guztiei eragiten die, eta horrek ordenatuagoa dirudi baina ez da. Tunela erorita dagoenean ere aplikatzen da, eta orduan VPNaren bidez soilik irisgarria den ebazle batek ohiko irudi-deskargak hausten ditu. Edukiontziko ezarpenak errazago justifikatzen eta errazago desegiten dira.

B aukera: edukiontziak ostalariaren sarea partekatzea

Ostalariaren sareak kopia erabat saihesten du, edukiontziak ostalariaren ebazlea eta ostalariaren tunela erabiltzen baititu. Era berean, ziurrenik nahi zenuen sare-isolamendua kentzen du, eta ez da berdin jokatzen Docker Desktopen. Linuxen erabilera bakarreko tresna batentzat aukera pragmatikoa da, barneko izenak ebatzi behar dituen tresnarentzat.

Bilketetarako ez da bi aukeretako bat ere aplikatzen, bilketa-urratsak ez baitituzte exekuzio-denborako banderak heredatzen. Bildu ostalariaren sarearekin plataformak uzten duenean, edo eduki menpekotasunen instalazioa tunela behar ez duen etapa batean.

Bi aukerek konpontzen ez dutena

DNS helbide bat alferrikakoa da edukiontziak hara biderik ez badu. VPNaren ebazlea tunelaren helbide-espazioaren barruan egon ohi da, beraz edukiontziak aurrizki horretarako bidea behar du. Dockeren zubi lehenetsiak ostalariaren bidez bideratzen du kanpora normalean, eta hori nahikoa da ostalariak tunelaren bidea duenean eta birbidalketa gaituta dagoenean. Helbide-pool propioak dituzten zubi-sare pertsonalizatuak VPNaren azpisarearekin talka daitezke, eta orduan kontsultak erabat beste leku batera joaten dira.

Egiaztatu Docker sarearen azpisarea VPNaren azpisarearen aurka ebazlea bera araztu aurretik. Gainjartzeak DNS zerbitzari hautsia bezalako hutsegitea sortzen du.

Egiaztatu edukiontziaren barruan

Probatu getent hosts db.internal erabiliz edukiontziaren barruan, arakatzaile edo hizkuntza-exekuzio ingurune baten ordez, haiek beren DNS politika eta beren cachea aplikatzen baitituzte. getent-ek izena ebazten badu eta aplikazioak oraindik huts egiten badu, ebazlea zuzena da orain eta gainerako arazoa aplikazio mailakoa da. Ebazten ez badu, DNS urratsa ez dago amaituta.

Sortu edukiontzia berriro haren DNS ezarpenak aldatu ondoren. Martxan dagoen edukiontzi baten barruan /etc/resolv.conf editatzeak harekin desagertzen da eta konfigurazio-arazoa ezkutatzen du norbaitek hura berrabiarazteko behar duen denbora zehatzean.