Aplikacioni arrin internetin përmes proxy-it korporativ, por http://catalog:8080/ dështon dhe proxy-i nuk mund të zgjidhë “catalog”. Është e mundur që ajo kërkesë të mos ketë përdorur kurrë DNS-in e brendshëm të Docker.

Një klient HTTP mund të zgjedhë proxy-in e tij përpara se të krijojë një lidhje të drejtpërdrejtë. Proxy-i i jashtëm atëherë merr një emër kuptimi i të cilit ekziston vetëm brenda rrjetit Compose.

  1. Përdor emrin e hostit në kërkesë. Shërbimet Compose zbulohen me emrin e shërbimit në rrjetin e duhur. Shto catalog te konfigurimi i anashkalimit i mbështetur nga klienti konsumues, në vend që të kodosh fort një IP kontejneri që mund të ndryshojë.
  2. Ruaj përjashtimet ekzistuese. Për një klient të ndërgjegjshëm për mjedisin, bashko hyrjet përkatëse me listën e organizatës:
NO_PROXY=localhost,127.0.0.1,catalog
no_proxy=localhost,127.0.0.1,catalog

Kontrollo bibliotekën ose ekzekutuesin aktual në imazh për trajtimin e shkronjave të mëdha e të vogla, versionin dhe gramatikën e përputhjes. Nuk ekziston një analizues NO_PROXY universal. Një program i quajtur wget në një imazh të vogël nuk duhet domosdoshmërisht të sillet si GNU Wget.

Pasi kërkesa zgjedh rrugëtimin e drejtpërdrejtë, kontrollo rrjetin e përbashkët të thirrësit dhe të shërbimit, shërbimin që dëgjon dhe portin e kontejnerit. Një port hosti i publikuar është një pikë tjetër fundore. Anashkalimi nuk mund të shtojë një lidhje rrjeti që mungon, ashtu si rikrijimi i një rrjeti nuk mund t'i mësojë një proxy-i të jashtëm një emër privat Compose.

Ruaj ndarjen e synuar: kërkesat e brendshme përdorin rrugën e tyre të brendshme; kërkesat e jashtme mbajnë proxy-in e miratuar. Çaktivizimi global i proxy-it mund të fshehë këtë dështim të vetëm duke hequr rrugën e nevojshme për kërkesën tjetër të jashtme.

Artikuj të ngjashëm