Si Testcontainers échoue lors du téléchargement d'une image, les réglages withEnv du futur conteneur ne peuvent pas aider. C'est le démon Docker qui effectue ce téléchargement depuis le registre avant que le conteneur existe.

Opération échouéeConfiguration de proxy à examiner
Téléchargement d'imageLe démon Docker utilisé par le test et sa route vers le registre
Téléchargement à l'intérieur du conteneur en cours d'exécutionLes entrées prises en charge par l'application dans ce conteneur
Le test Java se connecte à Docker ou à l'applicationLe client Java qui établit cette connexion

Pour le second cas, ajoutez des variables d'environnement à la définition GenericContainer existante :

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

Si un téléchargement dans le conteneur peut utiliser un point de terminaison HTTP public, renseignez ces valeurs à partir de la liste de proxies HTTP. Le programme de l'image doit lire ces variables. Elles ne transforment pas une socket de base de données quelconque en trafic de proxy HTTP. Le point de terminaison doit aussi être joignable depuis le conteneur : son 127.0.0.1 désigne lui-même.

Pour le premier cas, identifiez l'environnement Docker que Testcontainers utilise réellement. Un démon distant ou Docker Desktop peut prendre sa configuration à une autre source qu'un dockerd local. Gardez les services de test locaux et l'API Docker sur leurs routes prévues lorsque vous ajoutez un proxy par défaut étendu.

Articles similaires