Viss Testcontainers feilar under ei image-henting, kan withEnv-innstillingane til den komande containeren ikkje hjelpe. Det er Docker-daemonen som gjer den nedlastinga frå registeret før containeren finst.

Mislykka operasjonProxykonfigurasjon som må undersøkjast
Image-hentingDocker-daemonen som testen brukar, og ruta hans til registeret
Nedlasting inne i containeren som køyrerInndataa applikasjonen støttar i den containeren
Java-testen koplar til Docker eller applikasjonenJava-klienten som lagar den tilkoplinga

For det andre tilfellet, legg miljøvariablar til den eksisterande GenericContainer-definisjonen:

container
    .withEnv("http_proxy", "http://proxy.example:8080")
    .withEnv("https_proxy", "http://proxy.example:8080");

Viss ei nedlasting inne i containeren får bruke eit offentleg HTTP-endepunkt, fyll ut desse verdiane frå HTTP-proxylista. Programmet i imaget må lese desse variablane. Dei gjer ikkje eit vilkårleg databasesocket om til HTTP-proxytrafikk. Endepunktet må òg vere nåbart frå containeren: 127.0.0.1 viser til seg sjølv.

For det første tilfellet, finn Docker-miljøet som Testcontainers faktisk brukar. Ein ekstern daemon eller Docker Desktop kan hente konfigurasjonen frå ei anna kjelde enn ein lokal dockerd. Hald lokale testtenester og Docker-API-et på dei tiltenkte rutene når du legg til ein brei proxy-standard.

Relaterte artiklar