تنظیمات پروکسی DDEV برای میزبان و کانتینر وب

پیکربندی نصب‌شده 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 آن شنونده پروکسی را توصیف می‌کند. یک نقطه پایانی از فهرست پروکسی 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 را در محدوده مستقیم مورد نظر نگه دارید. هنگام افزودن دامنه‌های داخلی یا بازه‌های نشانی، نحو عبور را با مصرف‌کننده واقعی هماهنگ کنید.