Por qué Testcontainers withEnv no envía las descargas de imágenes por un proxy
Configure el demonio de Docker para una descarga fallida; las variables de proxy del contenedor solo llegan a los programas después de crear el contenedor.
Si Testcontainers falla al descargar una imagen, la configuración withEnv del futuro contenedor no puede ayudar. El demonio de Docker realiza esa descarga desde el registro antes de que el contenedor exista.
| Operación fallida | Configuración de proxy que revisar |
|---|---|
| Descarga de imagen | El demonio de Docker que usa la prueba y su ruta hacia el registro |
| Descarga dentro del contenedor en ejecución | Las entradas que admite la aplicación en ese contenedor |
| La prueba de Java se conecta a Docker o a la aplicación | El cliente de Java que realiza esa conexión |
Para el segundo caso, añada variables de entorno a la definición existente de GenericContainer:
container
.withEnv("http_proxy", "http://proxy.example:8080")
.withEnv("https_proxy", "http://proxy.example:8080");Si se permite que una descarga dentro del contenedor use un extremo HTTP público, rellene esos valores desde la lista de proxies HTTP. El programa de la imagen debe leer esas variables. No convierten un socket de base de datos arbitrario en tráfico de proxy HTTP. El extremo también debe ser accesible desde el contenedor: su 127.0.0.1 se refiere a sí mismo.
Para el primer caso, busque el entorno de Docker que Testcontainers usa realmente. Un demonio remoto o Docker Desktop puede tomar la configuración de una fuente distinta del dockerd local. Mantenga los servicios de prueba locales y la API de Docker en sus rutas previstas al añadir un proxy predeterminado amplio.