Налаштування проксі DDEV для хоста та вебконтейнера

Використовуйте змінні хоста й конфігурацію проксі клієнта Docker для відповідних споживачів; демон Docker і далі відповідає за завантаження базових образів.

Змонтована конфігурація Wget може виправити Wget, не змінюючи Drush або Composer. Почніть із програми, яка робить невдалий запит, а потім задайте проксі на межі запуску цієї програми.

Програми на хості

Для програм на хості, що підтримують звичайні змінні, вкажіть:

export http_proxy=http://proxy.example:8080
export https_proxy=http://proxy.example:8080
export no_proxy=localhost,127.0.0.1,::1,.ddev.site

Змінна HTTPS вибирає призначення HTTPS; її HTTP-URL описує прослуховувач проксі. Кінцева точка зі списку HTTP-проксі є кандидатом, коли відповідне завантаження на хості або у вебконтейнері може використовувати публічний маршрут.

Збирання та робота контейнерів

DDEV документує розділ proxies у наявному ~/.docker/config.json:

{
  "proxies": {
    "default": {
      "httpProxy": "http://proxy.example:8080",
      "httpsProxy": "http://proxy.example:8080",
      "noProxy": "localhost,127.0.0.1,::1,.ddev.site"
    }
  }
}

Об єднайте цей розділ, а не замінюйте автентифікацію чи інші наявні записи, потім перезапустіть проєкт DDEV. Docker використовує ці налаштування для надання змінних середовища й аргументів збирання. Програми у вебконтейнері все ще мають їх підтримувати.

Завантаження базових образів

Відсутній базовий образ завантажує демон Docker. Наведена вище конфігурація клієнта не задає проксі цього демона, а гарячий кеш образів може повністю уникнути завантаження.

Зберігайте локальні маршрути застосунків і служб DDEV у передбаченій прямій області. Адаптуйте синтаксис обходу до реального споживача, додаючи внутрішні домени або діапазони адрес.

Схожі статті