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 OperatiounProxy-Konfiguratioun fir z'iwwerpréiwen
Image-PullDen Docker-Daemon, deen den Test benotzt, an säi Wee bis an d'Registry
Download am lafenden ContainerD'Inputen, déi d'Applikatioun an deem Container ënnerstëtzt
Den Java-Test verbënnt sech mat Docker oder mat der ApplikatiounDe 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.

Ähnlech Artikelen