Nebula advertise_addrs או static_host_map: בחרו לפי הבעלים
מפה סטטית מתוחזקת על ידי כל peer שמחייג אליה; כתובת מוכרזת מתפרסמת על ידי המארח. בחרו לפי מי שמכיר את נקודת הקצה.
שתי ההגדרות static_host_map ו-advertise_addrs מציבות כתובת מול peer, והן עונות על שאלות שונות. האחת היא קובץ מקומי שמפרט כתובת overlay ואת נקודת הקצה של שכבת ה-underlay שאליה מחייגים. האחרת היא מארח שמספר למגדלוריו אילו נקודות קצה נוספות יכולות להגיע אליו. הבעלות היא ההבדל האמיתי: את המפה מתחזק כל מי שזקוק לה, ואת ההכרזה המארח עצמו.
החליטו לפי מי שמחזיק במידע
| Setting | Where it lives | Best for |
|---|---|---|
static_host_map | Every peer that needs the entry | Bootstrap endpoints, deliberately fixed paths |
advertise_addrs | The host's own config | Endpoints the host cannot otherwise discover |
כל peer משתנה בקובץ הסטטי של כל peer הוא עבודת תחזוקה שגדלה בריבוע של הצי. זו הסיבה המעשית לפנות להגדרה האחרת בכל פעם שהמארח עצמו יודע את התשובה.
שאלת הבעלות גם מנבאת מה קורה כשכתובת משתנה. עם מפה סטטית, מישהו צריך לזכור כל peer שמחזיק ברישום הישן. עם הכרזה, המארח מפרסם את נקודת הקצה החדשה והמגדלורים שלו מעבירים אותה הלאה, כך שהשינוי נשאר מקומי במכונה שזזה.
Bootstrap עדיין זקוק לרישומים סטטיים
לקוח חייב להגיע לפחות למגדלור אחד לפני שהוא יכול לשאול מישהו על peers אחרים. הקפיצה הראשונה הזו לא יכולה לבוא מגילוי, ולכן היא מגיעה מ-רישום סטטי בתצורת הלקוח. עשו את הרישום האחד הזה נכון ואת שאר ה-overlay אפשר ללמוד.
רישום במפה מזווג כתובת Nebula עם נקודת קצה אחת או יותר של IP או DNS שניתן להגיע אליהן, ועם פורטים. להחזיק את המגדלורים שם זה רגיל; להחזיק שם כל peer הוא הדפוס שמזדקן רע, כי כל peer חדש פירושו עריכת קבצים במכונות שאולי אינכם שולטים בהן. החזיקו את הרשימה קצרה מספיק שאדם עדיין יוכל לאמת אותה בקריאה.
הכריזו כשהמארח מכיר את נקודת הקצה
מארח מאחורי העברת פורטים נגיש בכתובת ציבורית שאינה מוקצית לאף אחד מהממשקים שלו. הוא לא יכול לגלות את הכתובת הזו בהסתכלות על עצמו. advertise_addrs מאפשר לו לפרסם את נקודת הקצה דרך המגדלורים שלו כדי ש-peers אחרים ילמדו נתיב שבאמת עובד. ההגדרה קיימת בדיוק משום שהמארח הוא הצד היחיד שיודע שהמיפוי נעשה.
השתמשו בכתובת ובפורט ש-peers אחרים באמת יכולים להגיע אליהם. אותו היגיון חל על מארח עם כמה נתיבי רשת, שבו נתיב אחד עדיף ל-peers ברשת מסוימת. הכרזה היא הצהרה על ה-underlay, לא בקשה לשום דבר. כשהמיפוי משתנה, עדכנו את ההכרזה במארח ותנו לגילוי לשאת אותה, במקום לערוך קבצים סטטיים בכל הצי.
הכרזה אינה נגישות
פרסום נקודת קצה לא יוצר את כלל ההעברה של הנתב, לא פותח חומת אש במעלה הזרם ולא גורם לשם DNS להיפתר. אלה חלקי עבודה נפרדים, והכרזה נכונה עם העברת פורט חסרה מייצרת בדיוק את הכשל שניסיתם לתקן. הכרזה היא טענה על נגישות, לא מנגנון שמקים אותה.
בדקו את הנתיב מבחוץ לפני שאתם מאשימים את הגילוי. ל-peer שלומד את נקודת הקצה אבל לא מצליח להשלים handshake יש בעיית ניתוב או סינון ב-underlay, וחזרה על אותה כתובת בשתי ההגדרות לא תשנה זאת.
החזיקו את כתובת ה-overlay בנפרד מנקודת הקצה
התעודה של הצומת מזהה את כתובת ה-Nebula שלה. הכתובות המוכרזות שייכות לרשת שמתחת, ומותר להן להשתנות בלי לגעת בתעודה. הנפקת תעודה חדשה עם כתובת IP אחרת ב-overlay היא פעולה אחרת, עם ההשלכות שלה לכל קשר אמון שהצמיד את הישנה. החזיקו את שני השינויים בנפרד ב-runbook, אחרת העברת נקודת קצה תירשם כהוצאה מחדש.
כשהטריאז' נתקע, הפרידו את שתי השכבות במפורש: האם הגילוי מחזיר את נקודת הקצה הצפויה, והאם handshake מגיע אליה? אם הגילוי נכון והחבילות נכשלות, הבעיה מתחת ל-overlay. אם הגילוי שגוי, הבעיה במפה או בהכרזה, והתיקון שייך לשם.