Kāpēc Docker konteineri ignorē VPN DNS atrisinātāju
Konteineris startēšanas laikā nokopē resursdatora atrisinātāju, tāpēc VPN, kas vēlāk pārraksta DNS, paliek tā iekšienē neredzams. Nododiet atrisinātāju skaidri.
VPN darbojas, pārlūks sasniedz iekšējās vietnes, un konteiners joprojām nevar atrisināt tos pašus nosaukumus. Pakotnes instalēšana mirst ar nosaukuma atrisināšanas kļūdu, piemēram, EAI_AGAIN, vai lietojumprogramma neatrod datubāzes resursdatoru, ko resursdatora mašīna atrisina bez jebkādas sūdzības. Konteiners neizmanto atrisinātāju, ko instalēja VPN. Docker nokopēja resursdatora atrisinātāja konfigurāciju, kad konteiners tika izveidots, un pēc tam nekas to vairs nenokopēja.
Divi atrisinātāja skati vienā mašīnā
Linux sistēmā Docker izveides brīdī dod katram konteineram resursdatora atrisinātāja konfigurācijas kopiju, izfiltrē loopback adreses un palaiž iebūvētu DNS serveri adresē 127.0.0.11, kas pārsūta vaicājumus uz āru. VPN klients, kas pārraksta /etc/resolv.conf pēc tam, kad konteiners ir startējis, tā iekšienē neko nemaina. Konteinera restartēšana palīdz tikai tad, ja resursdatora atrisinātājs tajā brīdī nejauši ir pareizs.
Docker Desktop macOS vai Windows sistēmā pievieno slāni, jo dēmons dzīvo virtuālajā mašīnā. Resursdatora VPN atrisinātājs var nekad nebūt redzams tai VM, tāpēc restartēšana nemaina pilnīgi neko. Salīdziniet abus skatus pirms risinājuma izvēles: docker exec mycontainer cat /etc/resolv.conf blakus resursdatora atrisinātāju sarakstam.
Konteiners, kas uzskaita publisku atrisinātāju, kamēr resursdators uzskaita iekšēju, atrisinās publiskos nosaukumus un neizdosies ar iekšējiem. Šī šķelšanās ir šīs problēmas paraksts.
A variants: nodot tuneļa atrisinātāju katram konteineram
Docker pieņem DNS iestatījumus katram konteineram, un tās ir mazākās darba izmaiņas. Vispirms nolasiet VPN atrisinātāja adreses: scutil --dns macOS, resolvectl status vai paša klienta statusa izvade Linux. Pēc tam startējiet konteineru ar tām, piemēram, docker run --dns 192.168.2.1 --dns 192.168.123.1 myimage. Compose gadījumā tas pats iestatījums ir saraksts zem pakalpojuma, kur tas dzīvo versiju kontrolē, nevis kāda čaulas vēsturē.
dns masīvs failā /etc/docker/daemon.json attiecas uz katru jaunu konteineru, kas izklausās kārtīgāk, nekā tas ir. Tas attiecas arī tad, kad tunelis ir izslēgts, un tad atrisinātājs, kas pieejams tikai caur VPN, sabojā parasto attēlu lejupielādi. Iestatījumus katram konteineram ir vieglāk pamatot un vieglāk atcelt.
B variants: ļaut konteineram dalīt resursdatora tīklu
Resursdatora tīkls pilnībā apiet kopiju, jo konteiners izmanto resursdatora atrisinātāju un resursdatora tuneli. Tas arī noņem tīkla izolāciju, ko jūs, iespējams, gribējāt, un Docker Desktop vidē tas neuzvedas tāpat. Linux sistēmā tas ir pragmatiska izvēle vienreizējam rīkam, kam jāatrisina iekšējie nosaukumi.
Būvēm neviens no abiem variantiem nav piemērojams, jo būves soļi nemanto izpildlaika karodziņus. Būvējiet ar resursdatora tīklu tur, kur platforma to atļauj, vai turiet atkarību instalēšanu tādā posmā, kam tunelis nav vajadzīgs.
Ko neizlabo neviens no abiem variantiem
DNS adrese ir bezjēdzīga, ja konteineram nav maršruta uz to. VPN atrisinātājs parasti atrodas tuneļa adrešu telpā, tāpēc konteineram vajag ceļu uz šo prefiksu. Docker noklusējuma tilts parasti maršrutē uz āru caur resursdatoru, un ar to pietiek, ja resursdatoram ir tuneļa maršruts un pārsūtīšana ir iespējota. Pielāgoti tilta tīkli ar saviem adrešu baseiniem var sadurties ar VPN apakštīklu, un tad vaicājumi aiziet pavisam citur.
Pirms atrisinātāja atkļūdošanas pārbaudiet Docker tīkla apakštīklu pret VPN apakštīklu. Pārklāšanās rada kļūmi, kas izskatās tieši kā salauzts DNS serveris.
Pārbaudiet konteinera iekšienē
Testējiet ar getent hosts db.internal konteinera iekšienē, nevis ar pārlūku vai valodas izpildlaiku, jo tie piemēro savu DNS politiku un savu kešatmiņu. Ja getent atrisina nosaukumu un lietojumprogramma joprojām neizdodas, atrisinātājs tagad ir pareizs un atlikušā problēma ir lietojumprogrammas līmenī. Ja tas to neatrisina, DNS solis nav pabeigts.
Pēc DNS iestatījumu maiņas izveidojiet konteineru no jauna. /etc/resolv.conf rediģēšana darbojošā konteinerā pazūd kopā ar to un slēpj konfigurācijas problēmu tieši tik ilgi, cik kādam nepieciešams to restartēt.