network_mode: service:vpn ושם המארח db החסר

שיתוף מרחב השמות של ה-VPN הוא בחירה טופולוגית. או ש-db שומר על הכתובת שלו וה-vpn מצטרף לרשת הזו, או שהכול עונה על loopback.

אתם מוסיפים network_mode: service:vpn לאפליקציה, מפעילים מחדש את המחסנית, והאפליקציה מתה מפני ש-db כבר לא נפתר. שום דבר לא שונה בשם בקובץ compose, ולכן החשודים המובנים הם DNS ומסד הנתונים. השינוי האמיתי קטן ומוזר יותר: האפליקציה הפסיקה להיות חברה ברשת ה-Compose שבה השם הזה קיים. עד שתחליטו מאיזה מרחב שמות מסד הנתונים צריך לענות, כל תיקון של שם מארח הוא ניחוש.

למה שם המארח db הפסיק להיפתר

לשירות שמשתמש ב-network_mode אין כתובת משלו ברשת Compose; הוא שואל את מרחב השמות של השירות הנקוב. מרחב השמות הזה מביא איתו ממשקים, מסלולים, מרחב פורטים ופותרים משלו, והוא מחליף את החיבור של האפליקציה לרשת ה-backend. השם db מעולם לא היה מופשט: הוא חי ברשת הזו ונפתר דרך ה-DNS המובנה שלה. הסירו את החיבור ולשם אין איפה להיפתר.

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

שלוש שאלות לפני שתערכו את הקובץ

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

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

השאירו את מסד הנתונים במקומו

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

services:
  vpn:
    networks:
      - backend
  app:
    network_mode: service:vpn
  db:
    networks:
      - backend
networks:
  backend:

אל תוסיפו networks גם לאפליקציה. Compose דוחה את המאפיין הזה לצד network_mode באותו שירות, והשגיאה מצביעה על הקובץ ולא על הצמד. אם לקוח ה-VPN מסנן את יעד ה-backend בתוך מרחב השמות שלו, כווננו גם את מדיניות הרשת המקומית הנתמכת שלו; חיבור משותף מציע מסלול אך אינו עוקף את המסנן הזה.

העבירו את מסד הנתונים למרחב השמות

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

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

מוכנות, חסימה והפותר

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

שיתוף מרחב שמות פירושו גם ש-האפליקציה יורשת את הפותר של קונטיינר ה-VPN, מה שעוזר כשהמנהרה דוחפת שרתי DNS ומבלבל כשהיא לא עושה זאת. בדקו מה באמת מכיל מרחב השמות במקום להניח שהפותר של המארח חל. מדריך השירותים של Compose מתעד network_mode, ports והתנהגות תלויות במקום אחד, כולל מדוע לשירות network_mode אין כתובת משלו.

מאמרים קשורים