docker pull דרך VPN: לדמון יש רשת משלו

המחשב הנייד שלכם מחובר ל-VPN הארגוני, curl מגיע לרג'יסטרי הפנימי, ובכל זאת docker pull עדיין נכשל עם EOF. השילוב הזה אינו סתירה. הפקודה שהקלדתם פועלת ב-shell שלכם, אבל ההעברה פועלת בדמון שה-Docker CLI בחר, והדמון הזה עשוי להיות על מארח אחר לגמרי. נתיב הרשת שלו הוא זה שחייב לעבוד, והגדרות ה-proxy שלו הן אלה שחלות.

התחילו בזיהוי המנוע, לא בנתיב

הריצו docker context show ו-docker version. פלט הגרסה מדפיס קטע לקוח וקטע שרת, ובלוק השרת אומר לכם מי ענה: מנוע מקומי מקורי, המכונה הווירטואלית של Docker Desktop, או דמון במכונה מרוחקת. docker context inspect יציג את נקודת הקצה של ההקשר הנבחר אם תרצו להיות בטוחים, ואף אחת מהפקודות האלה לא משנה דבר.

משתנה סביבה כמו DOCKER_HOST יכול להפנות את ה-CLI בשקט למנוע אחר מזה שאתם מניחים, וזהו ההסבר הרגיל למחשב נייד שנראה מחובר ל-VPN בזמן שהמשיכה נוסעת למקום אחר.

לדמון יש זהות רשת משל עצמו

מנוע מרוחק זקוק לנתיב מאושר משל עצמו אל הרג'יסטרי הפרטי. חיבור לקוח ה-VPN של המחשב הנייד נותן לאותו מחשב נתיב; הוא אינו נותן לדמון שיושב במעבדה או בתת-רשת ענן את אותה כתובת פרטית. אם המנוע הוא Docker Desktop, המשיכה מתרחשת בתוך המכונה הווירטואלית שלו, שיש לה תצורת רשת ו-proxy נפרדת מסביבת ה-shell שלכם.

לכן curl מוצלח על המארח הוא ראיה על המארח ולא יותר.

גלו איזה חילופין עם הרג'יסטרי הסתיים

משיכת תמונה היא רצף: אימות, אחזור המניפסט, ואחר כך העברות blob שלעיתים קרובות מופנות לאחסון אובייקטים או לנקודת קצה של CDN. docker login מוצלח מוכיח רק את הצעד הראשון, ואסימון יכול להיות תקף לחלוטין בזמן שמארח ה-blob המופנה אינו נגיש מרשת הדמון. רשמו את הזמן המדויק, את הפניה לתמונה ואת האירוע השימושי הראשון מהלוג של הדמון או הלקוח לפני שתשנו משהו.

EOF לבדו אינו נוקב בסיבה. זה יכול להיות חיבור קטוע, proxy שהפיל את הזרם, פסק זמן או בעיית MTU, וניחוש ביניהם בלי האירוע עם חתימת הזמן הוא הדרך שבה אנשים משחזרים מנוע בריא. התייחסו להיסט הבייט בפלט הלקוח כאל נתון, כי העברה שנעצרת באותו גודל בכל פעם היא חיה אחרת מזו שלעולם אינה מתחילה. תעדו את שתי התוצאות והשוו ביניהן לאורך ניסיונות.

הגדירו את הרכיב שמעביר

עבור מנוע Linux מקורי, ה-proxy שייך לסביבת השירות, לא ל-shell שלכם. קובץ drop-in תחת /etc/systemd/system/docker.service.d/ עם רשומות HTTP_PROXY, HTTPS_PROXY ו-NO_PROXY, ואחריו systemctl daemon-reload והפעלה מחדש, הוא הסידור המתועד. Docker Desktop חושף את אותם ערכים דרך ההגדרות שלו, ועריכת פרופיל shell אינה נוגעת באף אחד מהם.

אם יש להגיע לרג'יסטרי ישירות דרך ה-VPN, הדמון זקוק ל-resolver, לנתיב ולהחרגת proxy מכוונת ולא רק להחרגה. התאמת NO_PROXY היא השוואת מחרוזות לכל רכיב, ופטור בלי נתיב מתחתיו מייצר כשל שנראה כמו בעיית proxy.

כאשר בדיקת TLS ארגונית נמצאת בנתיב המאושר, התקינו את השורש המאומת שלה דרך זרימת העבודה של המנוע או של Desktop. הוספת הרג'יסטרי ל-insecure-registries היא שינוי אחר שמבטל את האימות, והיא אינה תצורת מאגר אמון.

חזרו על משיכה מבוקרת אחת ובדקו מה השתנה

שנו גבול אחד, הפעילו מחדש את הרכיב שבבעלותו הוא, וחזרו על אותה משיכה מאותו הקשר. אמתו את הפניה לתמונה ואת ה-digest שהתקבלו ולא את היעדר השגיאה, כי שכבה שנשמרה במטמון יכולה לגרום לניסיון שני לעבור חלק קטן בהרבה מהנתיב מזה שעבר הראשון. שמרו בכרטיס את ההעברות שבאמת התרחשו, כי הן התיעוד היחיד של מה שהניסיון החוזר באמת בדק.

לשלבי build ולקונטיינרים פועלים יש הקשרי רשת משלהם, אז התייחסו אליהם כאל שאלות נפרדות לאחר שהמשיכה עצמה תעבוד.