Почему Testcontainers withEnv не проксирует загрузку образов
Настройте демон Docker для неудачной загрузки; прокси-переменные контейнера достигают программ только после создания контейнера.
Если Testcontainers терпит неудачу при загрузке образа, настройки withEnv будущего контейнера не помогут. Эту загрузку из реестра выполняет демон Docker ещё до того, как контейнер существует.
| Неудачная операция | Конфигурация прокси для проверки |
|---|---|
| Загрузка образа | Демон Docker, который использует тест, и его маршрут к реестру |
| Загрузка внутри работающего контейнера | Поддерживаемые приложением входные данные в этом контейнере |
| Java-тест подключается к Docker или приложению | Java-клиент, который устанавливает это соединение |
Во втором случае добавьте переменные окружения в существующее определение GenericContainer:
container
.withEnv("http_proxy", "http://proxy.example:8080")
.withEnv("https_proxy", "http://proxy.example:8080");Если загрузке внутри контейнера разрешено использовать публичную конечную точку HTTP, заполните эти значения из списка HTTP-прокси. Программа в образе должна читать эти переменные. Они не превращают произвольный сокет базы данных в трафик HTTP-прокси. Конечная точка также должна быть доступна из контейнера: её 127.0.0.1 указывает на него самого.
В первом случае найдите окружение Docker, которое Testcontainers действительно использует. Удалённый демон или Docker Desktop могут брать конфигурацию из другого источника, чем локальный dockerd. Держите локальные тестовые сервисы и Docker API на их предусмотренных маршрутах, добавляя широкое прокси по умолчанию.