کشیدن تصاویر پایه Docker: پروکسی سازنده در برابر آرگومان‌های ساخت
آرگومان‌های پروکسی که به مراحل ساخت داده می‌شوند، هر درخواست رجیستری که سازنده انجام می‌دهد را پیکربندی نمی‌کنند. سازنده‌ای را که تصویر پایه را حل می‌کند پیدا کنید.
یک ساخت می‌تواند هنگام حل FROM پیش از اجرای هر مرحله دانلود بسته در Dockerfile شکست بخورد. کلاینت رجیستری سازنده به مسیر خودش برای دریافت آن تصویر پایه نیاز دارد.
| عملیات | جزئی که به مسیر نیاز دارد |
|---|---|
| حل و واکشی تصویر پایه | کلاینت رجیستری سازنده |
| دانلود در طول RUN | فرایندی که مرحله ساخت را اجرا می‌کند |
| فراخوانی API در زمان اجرا | برنامه در حال اجرا |
سازنده را پیدا کنید
درایور پیش‌فرض Docker حول دیمن می‌چرخد. درایورهای دیگر Buildx می‌توانند از یک کانتینر اختصاصی BuildKit، Kubernetes یا یک سرویس راه دور استفاده کنند. مکانیزم پروکسی پشتیبانی‌شده توسط درایور انتخاب‌شده را همان‌جا که آن کارگر اجرا می‌شود پیکربندی کنید.
پروکسی لوپ‌بک روی لپ‌تاپ به‌طور خودکار از یک کارگر راه دور قابل دسترسی نیست، و ویرایش دیمن محلی آن سازنده راه دور را دوباره پیکربندی نمی‌کند.
یک ARG پیش از FROM می‌تواند در انتخاب ارجاع تصویر کمک کند. اما با این کار مسیر شبکه کلاینت رجیستری را پیکربندی نمی‌کند. دستورهای RUN بعدی که تنظیمات بسته را می‌نویسند یا گواهی‌نامه نصب می‌کنند نمی‌توانند این درخواست پیشین را ترمیم کنند.
اعتماد، حساب‌ها و داده‌های کش‌شده
مواد CA تأییدشده باید در دسترس جزئی باشد که اتصال اولیه رجیستری را اعتبارسنجی می‌کند. اعتبارنامه‌های رجیستری و اعتبارنامه‌های پروکسی طرف‌های متفاوتی را مجاز می‌کنند؛ ورود به رجیستری نمی‌تواند به 407 پروکسی پاسخ دهد.
کارگری که داده‌های کش‌شده تصویر را دوباره استفاده می‌کند ممکن است همان درخواست شبکه‌ای کارگر تازه را تکرار نکند. عملیات واقعی ثبت‌شده را مقایسه کنید. پس از اینکه دسترسی به تصویر پایه از مسیر موردنظر کار کرد، هر دانلود بعدی در مرحله ساخت را در آن مرز بعدی تشخیص دهید.