Чому 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 на їхніх передбачених маршрутах, додаючи широкий проксі за замовчуванням.

Схожі статті