docker pull از طریق VPN: دیمن شبکه خودش را دارد

لپ‌تاپ شما روی VPN سازمانی است، curl به رجیستری داخلی می‌رسد و با این حال docker pull هنوز با EOF شکست می‌خورد. این ترکیب تناقض نیست. فرمانی که تایپ کرده‌اید در پوسته شما اجرا می‌شود، اما انتقال در همان دیمنی اجرا می‌شود که Docker CLI انتخاب کرده است، و آن دیمن ممکن است روی میزبان کاملاً دیگری باشد. مسیر شبکه آن است که باید کار کند، و تنظیمات پروکسی آن است که اعمال می‌شود.

با شناسایی موتور شروع کنید، نه مسیر

docker context show و docker version را اجرا کنید. خروجی نسخه یک بخش کلاینت و یک بخش سرور چاپ می‌کند، و بلوک سرور به شما می‌گوید چه چیزی پاسخ داده است: موتور بومی محلی، ماشین مجازی Docker Desktop، یا دیمنی روی یک ماشین دوردست. اگر می‌خواهید مطمئن شوید، docker context inspect نقطه پایانی زمینه انتخاب‌شده را نشان می‌دهد، و هیچ‌یک از این فرمان‌ها چیزی را تغییر نمی‌دهد.

متغیر محیطی مانند DOCKER_HOST می‌تواند CLI را بی‌صدا به موتوری متفاوت از آنچه فرض می‌کنید اشاره دهد، و این توضیح معمول لپ‌تاپی است که به نظر می‌رسد روی VPN است در حالی که pull جای دیگری می‌رود.

دیمن هویت شبکه‌ای خودش را دارد

موتور دوردست به مسیر تأییدشده خودش به رجیستری خصوصی نیاز دارد. اتصال کلاینت VPN لپ‌تاپ شما به آن لپ‌تاپ مسیر می‌دهد؛ اما به دیمنی که در آزمایشگاه یا زیرشبکه ابری نشسته است همان نشانی خصوصی را نمی‌دهد. اگر موتور Docker Desktop باشد، pull درون ماشین مجازی آن رخ می‌دهد، که پیکربندی شبکه و پروکسی خودش را جدا از محیط پوسته شما دارد.

به همین دلیل curl موفق روی میزبان شاهدی درباره میزبان است و نه بیشتر.

پیدا کنید کدام تبادل با رجیستری پایان یافته است

pull یک تصویر یک توالی است: احراز هویت، دریافت مانیفست، و سپس انتقال‌های blob که اغلب به ذخیره‌سازی شیئی یا نقطه پایانی CDN هدایت می‌شوند. docker login موفق فقط گام اول را اثبات می‌کند، و یک توکن می‌تواند کاملاً معتبر باشد در حالی که میزبان blob تغییرمسیر‌یافته از شبکه دیمن در دسترس نیست. پیش از تغییر هر چیزی، زمان دقیق، ارجاع تصویر و نخستین رویداد سودمند از گزارش دیمن یا کلاینت را یادداشت کنید.

EOF به‌تنهایی هیچ علتی را نام نمی‌برد. می‌تواند اتصال قطع‌شده، پروکسی‌ای که جریان را انداخته، پایان مهلت یا مشکل MTU باشد، و حدس زدن میان آن‌ها بدون رویداد زمان‌دار همان روشی است که مردم با آن یک موتور سالم را از نو می‌سازند. جابه‌جایی بایت در خروجی کلاینت را داده در نظر بگیرید، زیرا انتقالی که هر بار در همان اندازه متوقف می‌شود جانوری متفاوت از انتقالی است که هرگز شروع نمی‌شود. هر دو نتیجه را ثبت کنید و آن‌ها را میان تلاش‌ها مقایسه کنید.

جزئی را که انتقال می‌دهد پیکربندی کنید

برای موتور بومی Linux، پروکسی به محیط سرویس تعلق دارد، نه به پوسته شما. یک فایل drop-in زیر /etc/systemd/system/docker.service.d/ با ورودی‌های HTTP_PROXY، HTTPS_PROXY و NO_PROXY، و پس از آن systemctl daemon-reload و یک راه‌اندازی مجدد، چیدمان مستند است. Docker Desktop همان مقادیر را از طریق تنظیمات خودش ارائه می‌دهد، و ویرایش یک نمایه پوسته به هیچ‌یک از آن دو دست نمی‌زند.

اگر باید به رجیستری مستقیماً از طریق VPN دست یافت، دیمن به resolver، مسیر و حذف عمدی پروکسی نیاز دارد، نه فقط حذف. تطبیق NO_PROXY مقایسه رشته‌ای برای هر جزء است، و استثنایی بدون مسیر زیرین خرابی‌ای تولید می‌کند که شبیه مشکل پروکسی است.

وقتی بازرسی TLS سازمانی در مسیر تأییدشده قرار دارد، ریشه تأییدشده آن را از طریق جریان کاری موتور یا Desktop نصب کنید. افزودن رجیستری به insecure-registries تغییری متفاوت است که اعتبارسنجی را غیرفعال می‌کند، و پیکربندی مخزن اعتماد نیست.

یک pull کنترل‌شده را تکرار کنید و بررسی کنید چه تغییری کرده است

یک مرز را تغییر دهید، جزئی را که مالک آن است راه‌اندازی مجدد کنید، و همان pull را از همان زمینه تکرار کنید. ارجاع تصویر و digest حاصل را بررسی کنید، نه نبود خطا را، زیرا یک لایه ذخیره‌شده در حافظه نهان می‌تواند باعث شود تلاش دوم بخش بسیار کمتری از مسیر را بپیماید تا تلاش اول. انتقال‌هایی را که واقعاً رخ داده‌اند در تیکت نگه دارید، چون تنها سند آنچه تلاش دوباره واقعاً آزموده است همان‌ها هستند.

گام‌های build و کانتینرهای در حال اجرا زمینه‌های شبکه خودشان را دارند، پس وقتی خود pull کار کرد آن‌ها را پرسش‌های جداگانه بدانید.