Kial via firmaa prokura servilo provas solvi nomon de Compose-servo

HTTP-kliento povas sendi internan servopeton al sia agordita prokura servilo antaŭ ol uzi la servonomosolvadon de Docker. Aldonu intencajn preterirojn por la ĝusta kliento.

La aplikaĵo atingas la interreton per sia firmaa prokura servilo, sed http://catalog:8080/ malsukcesas kaj la prokura servilo ne povas solvi “catalog”. Tiu peto eble neniam uzis la internan DNS de Docker.

HTTP-kliento povas elekti sian prokuran servilon antaŭ ol fari rektan konekton. La ekstera prokura servilo tiam ricevas nomon, kies signifo ekzistas nur ene de la Compose-reto.

  1. Uzu la gastigantan nomon en la peto. Compose-servoj estas troveblaj laŭ servonomo en la taŭga reto. Aldonu catalog al la subtenata preterira agordo de la konsumanta kliento anstataŭ malmole kodigi ujIP-on, kiu povas ŝanĝiĝi.
  2. Konservu ekzistantajn esceptojn. Por medikonscia kliento, kunfandu la koncernajn erojn kun la listo de la organizo:
NO_PROXY=localhost,127.0.0.1,catalog
no_proxy=localhost,127.0.0.1,catalog

Kontrolu la faktan bibliotekon aŭ plenumeblon en la bildo pri uskleco, versio kaj kongrua gramatiko. Ne ekzistas universala NO_PROXY-analizilo. Programo nomata wget en malgranda bildo ne devas konduti kiel GNU Wget.

Post kiam la peto elektas rektan enkursigon, kontrolu la komunan reton de la alvokanto kaj la servo, la aŭskultantan servon kaj la ujhavenon. Publikigita gastiganta haveno estas alia finpunkto. Preteriro ne povas aldoni mankantan retan konekton, same kiel rekreado de reto ne povas instrui al ekstera prokura servilo privatan Compose-nomon.

Konservu la celitan dividon: internaj petoj uzas sian internan vojon; eksteraj petoj konservas la aprobitan prokuran servilon. Tutmonda malŝalto de la prokura servilo povas kaŝi ĉi tiun unu fiaskon dum ĝi forigas la vojon bezonatan por la sekva ekstera peto.

Rilataj artikoloj