שינוי מאגר ברירת המחדל של Docker אינו ממספר מחדש רשתות

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

המיתוס: שינוי מאגר אחד מתקן את החפיפה

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

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

טווח בסיס והקידומת שהוקצתה

בתצורה יש שני שדות שקל לבלבל ביניהם. base הוא הטווח שממנו המקצה גוזר, ו-size הוא אורך הקידומת של כל רשת מוקצית, כך שבסיס 10.10.0.0/16 עם גודל 24 מחלק /24 בתוך ה-/16 הזה. היפוך התפקידים מייצר תבנית הקצאה שלא התכוונתם לה, בדרך כלל רשת ענקית אחת או מאגר שמוצה.

מאגר הוא הזמנה, לא הוכחה. Docker נמנע מהתנגשויות שהוא רואה בטבלת הניתוב של המארח, והוא אינו יכול לראות VPN שעדיין לא התחברתם אליו.

המגבלה הזו היא כל הסיבה לבחור בכוונה. הטווחים להשוואה הם אלה שהמארח חייב להגיע אליהם: ה-LAN של המשרד, תת-הרשתות הפנימיות של ה-VPN הארגוני, הקידומות של המעבדה או הסטייג'ינג, וכל מארח קונטיינרים אחר על אותו overlay. רשמו אותם כ-CIDR לפני שאתם נוגעים בדמון, כי רשימה בראש תפספס בדיוק את זו שחשובה. אחר כך בחרו בסיס שאינו חופף לאף אחד מהם, ושמרו את הרשימה יחד עם הפריסה כדי שהאדם הבא לא יחזור על התרגיל מהזיכרון.

עשו מלאי לפני שתבחרו

קודם עשו מלאי של מה שקיים. docker network ls מציג את הרשתות, ו-docker network inspect bridge -f '{{.IPAM.Config}}' מדפיס את תת-הרשת שרשת מסוימת משתמשת בה. חזרו על זה לכל רשת שמוגדרת על ידי המשתמש, כי פרויקטי Compose יוצרים רשתות משלהם ו---subnet מפורש בקובץ compose עוקף את המאגר לגמרי.

הנקודה האחרונה היא זו ששורדת את המעבר. שינוי מאגר לא מונע מעמית לנעוץ 172.18.0.0/16 בקובץ compose, וההתנגשות חוזרת עם מחבר אחר.

העברת מה שכבר קיים

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

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

אחר כך אמתו את שני הדברים שהשינוי היה אמור לתקן. בדקו את תת-הרשת החדשה עם docker network inspect ואשרו שהיא בתוך הבסיס שנבחר, ואז בדקו את המסלול ליעד VPN מייצג עם ip route get 10.20.30.40 ו-אשרו שהוא הולך לאן שאתם מצפים ולא לגשר. בדקו גם גילוי שירותים ותקשורת בין קונטיינרים, כי רשת שנוצרה מחדש עם מיעון אחר יכולה לשבור פתרון שמות בדרכים שנראות כמו באג באפליקציה.

מה עוד נשבר אחרי זה

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

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