Kial prokura ujo ne aŭtomate uzas la DNS-ujon

Kunhavigi Docker-gastiganton, kunhavigi reton kaj elekti solvilon estas tri malsamaj aferoj. Sekvu la DNS-demandon el la interno de la prokuro.

Ruli prokuron kaj DNS-servilon sur unu Docker-gastiganto ne kunligas iliajn DNS-vojojn. Tri apartaj rilatoj gravas:

  • Reta atingeblo. Apartaj Compose-projektoj kutime havas apartajn defaŭltajn retojn. Metu la servojn sur taŭgan kunhavigatan reton, ĉu ene de unu projekto ĉu per reto eksplicite kunhavigata inter projektoj.
  • Serva malkovro. La enkonstruita DNS de propra Docker-reto povas solvi ujo-nomojn. Tio ebligas al aplikaĵo malkovri najbaron; sed ĝi ne aŭtomate elektas tiun najbaron kiel sian DNS-solvilon.
  • Solvila elekto. Identigu la solvilon uzatan ene de la prokura ujo. La kampo dns de Compose akceptas adresojn de DNS-serviloj. Nomo kiel dns.local, kiu solviĝas en aplikaĵo, ne igas ĝin valida valoro por tiu kampo.

Sekvu la demandon de la prokura ujo ĝis ĝia agordita solvila adreso. Konfirmu itineron kaj DNS-aŭskultanton ĉe tiu adreso. Publikigi la gastigantan pordon 53 kreas alirvojon ĉe la gastiganta flanko; ĝi ne diras al ujoj uzi ĝin. Ujoj kunhavigantaj reton povas anstataŭe komuniki rekte.

Se la agordo referencas la adreson de la DNS-ujo, tenu ĝin stabila sub kongrua IPAM-agordo. Dinamike atribuita adreso kopiita el la hieraŭa ujo povas malsukcesi ĉe rekreado. Ankaŭ ekzamenu la suprentan vojon de la solvilo: resendi responditajn demandojn al ĝi mem kreas alian fiaskon ol neatingebla solvilo.

Fine, identigu kiu solvas la celon. HTTP-prokuro solvanta CONNECT-nomon povas uzi ĉi tiun ujon-vojon; SOCKS-kliento solvanta loke eble ne. Gastiganta serĉo pruvas la itineron de la gastiganto, ne tiun de la prokura procezo.

Rilataj artikoloj