docker pull عبر شبكة VPN: للبرنامج الخفي شبكته الخاصة

حاسوبك المحمول متصل بشبكة VPN الخاصة بالشركة، وcurl يصل إلى السجل الداخلي، ومع ذلك يفشل docker pull بخطأ EOF. هذا المزيج ليس تناقضًا. الأمر الذي كتبته يعمل في الصدفة، أما النقل فيجري داخل البرنامج الخفي (daemon) الذي اختاره Docker CLI، وقد يكون ذلك البرنامج على مضيف آخر تمامًا. مسار الشبكة الخاص به هو الذي يجب أن يعمل، وإعدادات الوكيل الخاصة به هي التي تنطبق.

ابدأ بتحديد المحرك، لا المسار

شغّل docker context show وdocker version. تُظهر مخرجات الإصدار قسمًا للعميل وقسمًا للخادم، ويخبرك قسم الخادم بما استجاب: محرك محلي أصلي، أو الجهاز الافتراضي Docker Desktop، أو برنامج خفي على جهاز بعيد. وسيعرض docker context inspect نقطة النهاية للسياق المحدد إن أردت التأكد، ولا يغيّر أي من هذه الأوامر شيئًا.

قد يوجّه متغير بيئة مثل DOCKER_HOST واجهة CLI بصمت إلى محرك مختلف عن الذي تفترضه، وهذا هو التفسير المعتاد لحاسوب يبدو متصلًا بشبكة VPN بينما يجري السحب في مكان آخر.

للبرنامج الخفي هوية شبكية خاصة به

يحتاج المحرك البعيد إلى مسار معتمد خاص به إلى السجل الخاص. فاتصال عميل VPN على حاسوبك يمنح ذلك الحاسوب مسارًا؛ لكنه لا يمنح برنامجًا خفيًا في مختبر أو في شبكة فرعية سحابية العنوان الخاص نفسه. وإذا كان المحرك هو Docker Desktop، يجري السحب داخل جهازه الافتراضي، الذي لديه تكوين شبكة ووكيل خاص به منفصل عن بيئة الصدفة لديك.

لهذا فإن نجاح curl على المضيف دليل يخص المضيف لا أكثر.

اكتشف أي تبادل مع السجل قد انتهى

سحب صورة هو تسلسل: مصادقة، ثم جلب البيان، ثم نقل كتل 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، فإن البرنامج الخفي يحتاج إلى محلّل ومسار واستبعاد متعمّد للوكيل، لا استبعادًا وحده. مطابقة NO_PROXY هي مقارنة نصية لكل مكوّن، والاستثناء بلا مسار أساسي ينتج فشلًا يبدو كمشكلة وكيل.

عندما يقع فحص TLS المؤسسي في المسار المعتمد، ثبّت جذره المتحقَّق عبر سير عمل المحرك أو Desktop. إضافة السجل إلى insecure-registries تغيير مختلف يعطّل التحقق، وليس تكوينًا لمخزن الثقة.

كرّر عملية سحب واحدة مضبوطة وتحقق مما تغيّر

غيّر حدًّا واحدًا، وأعد تشغيل المكوّن الذي يملكه، وكرّر السحب نفسه من السياق نفسه. تحقق من مرجع الصورة وdigest الناتجين لا من غياب الخطأ، لأن طبقة مخزّنة مؤقتًا قد تجعل المحاولة الثانية تمرّ بجزء أقل بكثير من المسار مما مرّت به الأولى. واحفظ في التذكرة عمليات النقل التي حدثت فعلًا، فهي السجل الوحيد لما اختبره الإعادة حقًا.

خطوات البناء والحاويات العاملة لها سياقات شبكية خاصة بها، لذا تعامل معها كأسئلة منفصلة بعد أن يعمل السحب نفسه.