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