Kāpēc starpniekservera konteiners automātiski neizmanto DNS konteineru

Starpniekservera un DNS servera darbināšana vienā Docker resursdatorā nesavieno to DNS ceļus. Svarīgas ir trīs atsevišķas attiecības:

• Tīkla sasniedzamība. Atsevišķiem Compose projektiem parasti ir atsevišķi noklusējuma tīkli. Ievietojiet pakalpojumus piemērotā kopīgā tīklā — vienā projektā vai ar skaidri kopīgu tīklu starp projektiem.
• Pakalpojumu atklāšana. Pielāgota Docker tīkla iebūvētais DNS spēj atrisināt konteineru nosaukumus. Tas ļauj lietojumprogrammai atklāt kaimiņu; tas automātiski neizvēlas šo kaimiņu par savu DNS atrisinātāju.
• Atrisinātāja izvēle. Nosakiet atrisinātāju, kas tiek izmantots starpniekservera konteinerā. Compose lauks dns uzņem DNS serveru adreses. Nosaukums, piemēram, dns.local, kas tiek atrisināts lietojumprogrammā, nepadara to par derīgu vērtību šim laukam.

Izsekojiet vaicājumam no starpniekservera konteinera līdz tā konfigurētajai atrisinātāja adresei. Pārliecinieties, ka šajā adresē ir maršruts un DNS klausītājs. Resursdatora porta 53 publicēšana izveido piekļuves ceļu resursdatora pusē; tā nepasaka konteineriem to izmantot. Konteineri, kas kopīgo tīklu, tā vietā var sazināties tieši.

Ja konfigurācija atsaucas uz DNS konteinera adresi, saglabājiet to stabilu saderīgā IPAM konfigurācijā. Dinamiski piešķirta adrese, kas nokopēta no vakardienas konteinera, var neizdoties atkārtotas izveides laikā. Pārbaudiet arī atrisinātāja augšupējo ceļu: neatbildētu vaicājumu pārsūtīšana atpakaļ pašam sev rada citu kļūmi nekā nesasniedzams atrisinātājs.

Visbeidzot, nosakiet, kas atrisina galamērķi. HTTP starpniekserveris, kas atrisina CONNECT nosaukumu, var izmantot šo konteinera ceļu; SOCKS klients, kas atrisina lokāli, to var nedarīt. Resursdatora uzmeklēšana pierāda resursdatora maršrutu, nevis starpniekservera procesa maršrutu.