תאימות NO_PROXY בין curl, .NET וקונטיינרים

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

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

כתבו תחילה את המסלולים הצפויים

השתמשו בכתובות מייצגות, כולל גבולות ולא רק הצלחות קלות:

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

תרגמו במקום להעתיק בעיוורון

דוגמה מתועדת אחת להבדל אמיתי היא גבול דומיין האב. החרגת הדומיין של curl מכסה את הדומיין הנקוב ואת הילדים המתאימים. מדיניות הסביבה של .NET מבחינה בין השם החשוף לבין צורת תת-הדומיין עם נקודה מובילה. כלל אוניברסלי להוסיף תמיד נקודה מובילה אינו יכול לבטא את שתי המדיניות באופן אמין.

התמיכה בטווחי IP תלויה גם בצרכן ובגרסתו. מכונה עם curl עצמאי חדש עדיין יכולה להריץ אפליקציה המקושרת ל-libcurl ישן יותר, או לקוח שמשתמש בספרייה אחרת לגמרי. גרסת מערכת ההפעלה אינה מלאי לקוחות מלא.

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

הפרידו ראיות תצורה מראיות חיבור

הגדרה מנותחת או API להחלטות ניתוב יכולים להראות מה התוכנית בחרה. תוצאת בקשה מראה לאחר מכן אם המסלול הזה היה שמיש. ב-.NET, HttpClient.DefaultProxy.IsBypassed מספק את הבדיקה בצד התצורה כאשר הפרוקסי המוגדר כברירת מחדל הוא המדיניות שבשימוש. אל תאבחנו שירות ישיר שאינו נגיש ככשל של מנתח העקיפה רק משום שהבקשה פגה בזמן.

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