למה docker pull מתעלם מהגדרות הפרוקסי של הקונטיינר
הגדירו את רכיב Docker שבאמת מושך תמונות במקום לצפות שמשתני הפרוקסי של הקונטיינר ישלטו ב-daemon.
אם docker pull נכשל, הגדירו את Docker daemon או Docker Desktop. התמונה יורדת לפני שקונטיינר היישום יכול לקרוא את משתני הפרוקסי שלו.
Docker Engine מקומי
מזגו את הקטע הזה בהגדרת הפרוקסי הקיימת של ה-daemon, החליפו את נקודת ההדגמה ושמרו הגדרות לא קשורות. לבדיקות משיכת תמונות ציבוריות שבהן מותר פרוקסי ציבורי, רשימת הפרוקסי HTTP מספקת מועמדים:
{
"proxies": {
"http-proxy": "http://203.0.113.10:8080",
"https-proxy": "http://203.0.113.10:8080",
"no-proxy": "localhost,127.0.0.1,registry.example.internal"
}
}המפתחות עם המקפים של ה-daemon שונים ממפתחות camelCase ב-~/.docker/config.json של לקוח Docker. מקטע הפרוקסי בלקוח מספק משתני סביבה לקונטיינרים חדשים ולבניות; הוא אינו מגדיר הורדות daemon או סביבות של קונטיינרים שכבר קיימים.
בצעו את אתחול ה-daemon המתועד להתקנה ותכננו את השפעתו על העבודות הנוכחיות. ה-daemon יכול לקבל משתני פרוקסי גם בסביבת ההפעלה שלו; export מאוחר יותר במסוף אינו מעדכן שירות שכבר פועל.
Docker Desktop
השתמשו בהגדרות הפרוקסי של Desktop. Docker מתעד ש-Desktop מתעלם מרשומות פרוקסי ב-daemon.json, ולכן שינוי חוזר של דוגמת Engine מקומי לא מגדיר את המסלול של המוצר הזה.
נסו שוב למשוך את התמונה אחרי עדכון הרכיב הנכון. בדקו אם הכשל בגישה ל-registry, באימות, בהפניות או בהורדת שכבות. בקשת HTTP שפועלת בתוך קונטיינר קיים בודקת רק את מסלול אותו יישום. אל תכללו פרטי התחברות לפרוקסי בצילומי מסך משותפים או בקבצים שנכנסים ל-commit; הגדרת daemon וסביבת קונטיינר אינן מאגרי סודות.