Firwat Testcontainers withEnv Image-Pulls net iwwer e Proxy leet
Konfiguréiert den Docker-Daemon fir en net gelungenen Pull; d'Proxy-Variabele vum Container erreechen d'Programmer eréischt nodeem de Container ugeluecht gouf.
Wann Testcontainers beim Pull vun engem Image feelt, kënnen d'withEnv-Astellungen vum zukünftege Container net hëllefen. Den Docker-Daemon mécht deen Download aus der Registry, ier de Container existéiert.
| Net gelungen Operatioun | Proxy-Konfiguratioun fir z'iwwerpréiwen |
|---|---|
| Image-Pull | Den Docker-Daemon, deen den Test benotzt, an säi Wee bis an d'Registry |
| Download am lafenden Container | D'Inputen, déi d'Applikatioun an deem Container ënnerstëtzt |
| Den Java-Test verbënnt sech mat Docker oder mat der Applikatioun | De Java-Client, deen déi Verbindung mécht |
Fir den zweete Fall, füügt Ëmweltvariabelen zu der existéierender GenericContainer-Definitioun derbäi:
container
.withEnv("http_proxy", "http://proxy.example:8080")
.withEnv("https_proxy", "http://proxy.example:8080");Wann en Download am Container en ëffentlechen HTTP-Endpunkt däerf benotzen, fëllt déi Wäerter aus der HTTP-Proxy-Lëscht aus. D'Programm am Image muss déi Variabelen liesen. Si maachen aus engem beliebige Datebank-Socket keen HTTP-Proxy-Traffic. Den Endpunkt muss och aus dem Container erreechbar sinn: säin 127.0.0.1 weist op sech selwer.
Fir den éischte Fall, fannt d'Docker-Ëmwelt, déi Testcontainers tatsächlech benotzt. En entfernten Daemon oder Docker Desktop kann d'Konfiguratioun aus enger anerer Quell huelen wéi e lokalen dockerd. Halt lokal Testservicer an d'Docker-API op hire virgesihene Weeër, wann Dir eng breet Proxy-Standardastellung derbäisetzt.