Калі 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 на іх прызначаных маршрутах, дадаючы шырокі проксі па змаўчанні.

Падобныя артыкулы