Perché Testcontainers withEnv non inoltra il download delle immagini tramite proxy
Configurate il demone Docker per un download non riuscito; le variabili proxy del container raggiungono i programmi solo dopo la creazione del container.
Se Testcontainers non riesce a scaricare un'immagine, le impostazioni withEnv del container futuro non possono aiutare. È il demone Docker a eseguire quel download dal registro prima che il container esista.
| Operazione non riuscita | Configurazione proxy da controllare |
|---|---|
| Download dell'immagine | Il demone Docker usato dal test e il suo percorso verso il registro |
| Download all'interno del container in esecuzione | Gli input supportati dall'applicazione in quel container |
| Il test Java si connette a Docker o all'applicazione | Il client Java che effettua quella connessione |
Per il secondo caso, aggiungete variabili d'ambiente alla definizione GenericContainer esistente:
container
.withEnv("http_proxy", "http://proxy.example:8080")
.withEnv("https_proxy", "http://proxy.example:8080");Se un download all'interno del container può usare un endpoint HTTP pubblico, compilate quei valori dall'elenco di proxy HTTP. Il programma nell'immagine deve leggere quelle variabili. Non trasformano un socket di database arbitrario in traffico proxy HTTP. L'endpoint deve anche essere raggiungibile dal container: il suo 127.0.0.1 si riferisce a se stesso.
Per il primo caso, individuate l'ambiente Docker che Testcontainers usa davvero. Un demone remoto o Docker Desktop può prendere la configurazione da una fonte diversa da un dockerd locale. Mantenete i servizi di test locali e l'API Docker sui percorsi previsti quando aggiungete un proxy predefinito ampio.