Wêrom't jo bedriuwsproxy besiket in Compose-tsjinstnamme op te lossen

In HTTP-klient kin in ynterne tsjinstfersyk nei syn konfigurearre proxy stjoere foardat er de tsjinstnamme-oplossing fan Docker brûkt. Foegje bewuste omgongen ta foar de goede klient.

De applikaasje berikt it ynternet fia syn bedriuwsproxy, mar http://catalog:8080/ mislearret en de proxy kin “catalog” net oplosse. Dat fersyk hat miskien nea it ynterne DNS fan Docker brûkt.

In HTTP-klient kin syn proxy kieze foardat er in direkte ferbining makket. De eksterne proxy ûntfangt dan in namme wêrfan't de betsjutting allinnich binnen it Compose-netwurk bestiet.

  1. Brûk de hostnamme yn it fersyk. Compose-tsjinsten binne te finen op tsjinstnamme yn it passende netwurk. Foegje catalog ta oan 'e stipe omgongskonfiguraasje fan 'e brûkende klient ynstee fan in kontener-IP hurd te kodearjen dy't feroarje kin.
  2. Behâld besteande útsûnderings. Foar in omjouwingsbewuste klient, foegje de relevante ynfoegingen gear mei de list fan 'e organisaasje:
NO_PROXY=localhost,127.0.0.1,catalog
no_proxy=localhost,127.0.0.1,catalog

Kontrolearje de eigentlike biblioteek of it útfierbere bestân yn 'e ôfbylding foar haadletterbehanneling, ferzje en oerienkommende grammatika. Der is gjin universele NO_PROXY-parser. In programma mei de namme wget yn in lyts ôfbylding hoecht him net as GNU Wget te hâlden.

Sadree't it fersyk direkte routing kiest, kontrolearje it dielde netwurk fan 'e oanropper en de tsjinst, de tsjinst dy't harket en de kontenerpoarte. In publisearre hostpoarte is in oar einpunt. In omgong kin in ûntbrekkende netwurkferbining net tafoegje, likegoed as it opnij meitsjen fan in netwurk in eksterne proxy gjin privee Compose-namme leare kin.

Behâld de bedoelde splitsing: ynterne fersiken brûke har ynterne paad; eksterne fersiken behâlde de goedkarde proxy. It proxy wrâldwiid útskeakelje kin dit iene mislearren ferbergje wylst it de rûte fuorthellet dy't nedich is foar it folgjende eksterne fersyk.

Relatearre artikelen