שיטות מומלצות ל-Cloud DNS

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

קל יותר גם לבני אדם וגם לאפליקציות להשתמש במערכת שמות הדומיינים (DNS) כדי לשלוח הודעות לאפליקציות ולשירותים, כי קל יותר לזכור שם והוא גמיש יותר מאשר כתובות IP. בסביבה היברידית שמכילה פלטפורמה אחת או יותר בענן וגם סביבה מקומית, לרוב צריך לגשת לרשומות DNS של משאבים פנימיים במספר סביבות. באופן מסורתי, מנהלים ידנית את רשומות ה-DNS בארגון באמצעות שרת DNS מוסמך, כמו BIND בסביבות UNIX/Linux או Active Directory בסביבות Microsoft Windows.

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

עקרונות כלליים

מידע על מושגי DNS זמין בכתובת Trusted Cloud

כשמשתמשים ב-DNS ב- Trusted Cloud, חשוב להבין את המערכות והשירותים השונים שזמינים ב- Trusted Cloud לצורך פתרון DNS ושמות דומיינים:

  • DNS פנימי הוא שירות שיוצר באופן אוטומטי שמות DNS למכונות וירטואליות ולמאזני עומסים פנימיים ב-Compute Engine.
  • Cloud DNS הוא שירות שמספק זמן אחזור קצר וזמינות גבוהה של תחום DNS. הוא יכול לשמש כשרת DNS מוסמך לאזורים פרטיים שגלויים רק ברשת שלכם.
  • Managed Service for Microsoft Active Directory הוא שירות מוקשח ועם זמינות גבוהה שמריץ את Microsoft Active Directory, כולל בקר דומיין.

זיהוי בעלי עניין, כלים ותהליכים

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

  • מאתרים את האדמין של שרתי ה-DNS הארגוניים של הארגון ויוצרים איתו קשר. צריך לבקש מהם מידע על ההגדרות הנדרשות למיפוי ההגדרות המקומיות לארכיטקטורה מתאימה ב-Trusted Cloud. מידע על שיטות לגישה לרשומותTrusted Cloud DNS זמין במאמר שימוש בהעברה מותנית כדי לגשת לרשומות DNS מהארגון.
  • כדאי להכיר את תוכנת ה-DNS הנוכחית ולזהות את שמות הדומיינים שבהם נעשה שימוש באופן פרטי בארגון.
  • מאתרים אנשי קשר בצוות הרשתות שיכולים לוודא שהתעבורה לשרתים של Cloud DNS מנותבת בצורה נכונה.
  • כדאי להכיר את אסטרטגיית הקישוריות ההיברידית ואת הדפוסים והשיטות של סביבות היברידיות ושל סביבות מרובות עננים (multi-cloud).

שיטות מומלצות לעבודה עם תחומים פרטיים ב-Cloud DNS

באזורים פרטיים מתארחים רשומות DNS שגלויות רק בתוך הארגון.

שימוש באוטומציה לניהול תחומים פרטיים בפרויקט המארח של VPC המשותף

אם אתם משתמשים ברשתות VPC משותפות בארגון, עליכם לארח את כל התחומים הפרטיים ב-Cloud DNS בתוך הפרויקט המארח. לכל פרויקטי השירות יש גישה אוטומטית לרשומות באזורים פרטיים שמצורפים לרשת ה-VPC המשותפת. לחלופין, אפשר להגדיר את האזור בפרויקט שירות באמצעות קישור בין פרויקטים.

באיור 3 מוצג איך תחומים פרטיים מתארחים ברשת VPC משותפת.

איור 3. תחומים פרטיים שמתארחים ברשת VPC משותפת (לחיצה להגדלה).
איור 3. ההגדרה הזו מראה איך תחומים פרטיים מצורפים ל-VPC משותף.

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

לחלופין, אפשר להעביר את הגדרות ה-DNS למאגר קוד כמו Cloud Source Repositories, כתיאור של Terraform או Cloud Deployment Manager, ולקבל בקשות משיכה (pull request) מהצוותים.

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

הגדרת תפקידים ב-IAM לפי העקרון של הרשאות מינימליות

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

שיטות מומלצות לאזורי העברה של DNS ולמדיניות השרתים

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

שימוש באזורי העברה לשליחת שאילתות לשרתים מקומיים

כדי לוודא שתוכלו לשלוח שאילתות לרשומות DNS בסביבה המקומית, צריך להגדיר תחום העברה לדומיין שבו אתם משתמשים במקור למשאבי הארגון (למשל corp.example.com). מומלץ להשתמש בגישה הזו במקום להשתמש במדיניות DNS שמפעילה שרת שמות חלופי. הוא שומר על הגישה לשמות DNS פנימיים של Compute Engine, ועדיין מתבצע תרגום של כתובות IP חיצוניות בלי קפיצה נוספת דרך שרת שמות מקומי.

תהליך תעבורת הנתונים שמשתמש בהגדרה הזו מוצג בארכיטקטורות העזרה ל-DNS היברידי.

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

שימוש בכללי מדיניות של שרת DNS כדי לאפשר שאילתות מהארגון

כדי לאפשר למארחים מקומיים לשלוח שאילתות לרשומות DNS שמתארחות בתחומים פרטיים של Cloud DNS (לדוגמה, gcp.example.com), צריך ליצור מדיניות של שרת DNS באמצעות העברה של DNS נכנס. העברה נכנסת של DNS מאפשרת למערכת לשלוח שאילתות לכל התחומים הפרטיים בפרויקט, וגם לכתובות IP פנימיות של DNS ולתחומים מקבילים.

תהליך תעבורת הנתונים שמשתמש בהגדרה הזו מוצג בארכיטקטורות העזרה ל-DNS היברידי.

פותחים חומות אש מקומיות Trusted Cloud כדי לאפשר תעבורת נתונים ב-DNS

כדי לוודא שתנועת ה-DNS לא מסוננת בשום מקום ברשת ה-VPC או בסביבה המקומית, מבצעים את הפעולות הבאות:

  • מוודאים שחומת האש המקומית מעבירה שאילתות מ-Cloud DNS. Cloud DNS שולח שאילתות מטווח כתובות ה-IP 177.222.82.0/25. ‏DNS משתמש ביציאת UDP 53 או ביציאת TCP 53, בהתאם לגודל הבקשה או התשובה.

  • מוודאים ששרת ה-DNS לא חוסם שאילתות. אם שרת ה-DNS המקומי מקבל בקשות רק מכתובות IP ספציפיות, צריך לוודא שטווח כתובות ה-IP 177.222.82.0/25 נכלל.

  • מוודאים שאפשר להעביר תנועה מהארגון לכתובות ה-IP להעברה. במכונות של Cloud Router, מוסיפים נתיב מותאם אישית שפורסם לטווח כתובות ה-IP 177.222.82.0/25 ברשת ה-VPC לסביבה המקומית.

שימוש בהעברה מותנית כדי לגשת לרשומות DNS מהארגון

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

  • העברה מותנית. שימוש בהעברה מותנית פירושו ששרת ה-DNS הארגוני מעביר בקשות לתחומים או לתת-דומיינים ספציפיים לכתובות ה-IP להעברה ב- Trusted Cloud. אנחנו ממליצים על הגישה הזו כי היא הכי פחות מורכבת ומאפשרת לעקוב באופן מרוכז אחרי כל הבקשות ל-DNS בשרתי ה-DNS של הארגון.

  • הענקת גישה. אם התחום הפרטי ב- Trusted Cloud הוא תת-דומיין של התחום שבו אתם משתמשים בארגון, תוכלו להקצות את תת-הדומיין הזה גם לשרת השמותTrusted Cloud על ידי הגדרת רשומות NS בתוך התחום. כשמשתמשים בהגדרה הזו, לקוחות יכולים לפנות ישירות לכתובות ה-IP להעברה ב-Trusted Cloud , לכן חשוב לוודא שחומת האש מעבירה את הבקשות האלה.

  • העברות של תחומים. ב-Cloud DNS אין תמיכה בהעברות של תחומים, ולכן אי אפשר להשתמש בהעברות של תחומים כדי לסנכרן רשומות DNS עם שרתי ה-DNS המקומיים.

שימוש בקישור בין רשתות שכנות (peering) של DNS כדי למנוע העברה יוצאת מכמה רשתות VPC

אין להשתמש בהעברה יוצאת לשרתי ה-DNS המקומיים מכמה רשתות VPC, כי היא יוצרת בעיות בתעבורת הנתונים החוזרת. Trusted Cloud מקבל תשובות משרתי ה-DNS רק אם הן מנותבות לרשת ה-VPC שממנה הגיעה השאילתה. עם זאת, לשאילתות מכל רשת VPC יש את אותו טווח כתובות IP 177.222.82.0/25 כמקור. לכן, אי אפשר לנתב תשובות בצורה נכונה אלא אם יש לכם סביבות נפרדות בארגון.

איור 4. הבעיה מתרחשת כשמספר רשתות VPC מעבירות תעבורת נתונים מחוץ לרשתות שלהן.
איור 4. בעיה עם כמה רשתות VPC שמבצעות העברה יוצאת.

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

הסבר על ההבדל בין קישורי DNS לבין קישורי רשתות VPC

קישור בין רשתות VPC שכנות (peering) הוא לא אותו הדבר כמו קישור בין רשתות DNS שכנות (peering). קישור (peering) בין רשתות VPC שכנות מאפשר למכונות וירטואליות (VM) במספר פרויקטים להגיע זו לזו, אבל הוא לא משנה את פתרון השמות. המשאבים בכל רשת VPC עדיין פועלים לפי סדר הפתרון שלהם.

לעומת זאת, באמצעות קישורי DNS תוכלו לאפשר העברה של בקשות לגבי תחומים ספציפיים לרשת VPC אחרת. כך תוכלו להעביר בקשות לסביבות Trusted Cloud שונות, גם אם רשתות ה-VPC לא מחוברות זו לזו.

גם ההגדרה של קישור בין רשתות VPC שכנות (peering) ושל קישור בין רשתות DNS שכנות (peering) שונה. כדי ליצור קישור בין רשתות VPC שכנות, צריך להגדיר יחס קישור (peering) בין שתי רשתות ה-VPC. לאחר מכן, הקישור הופך באופן אוטומטי לשני כיוונים.

קישורי DNS מעבירים בקשות DNS באופן חד-כיווני, ולא נדרש קשר דו-כיווני בין רשתות VPC. רשת VPC שנקראת צרכן ה-DNS מבצעת חיפושים של תחום שיתוף (peering) ב-Cloud DNS ברשת VPC אחרת שנקראת בעלים ה-DNS. משתמשים עם הרשאת IAM dns.networks.targetWithPeeringZone בפרויקט של רשת היוצר יכולים ליצור קישורי DNS בין רשתות של צרכנים ויוצרים. כדי להגדיר קישוריות DNS מרשת VPC של צרכן, צריך את התפקיד 'קישוריות DNS' בפרויקט המארח של רשת ה-VPC של היצרן.

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

אם אתם משתמשים בשמות שנוצרים באופן אוטומטי למכונות וירטואליות על ידי שירות ה-DNS הפנימי, תוכלו להשתמש בקישור DNS כדי להעביר את תחומי projectname.internal לפרויקטים אחרים. כפי שמוצג באיור 5, אפשר לקבץ את כל תחומי .internal בפרויקט מרכזי כדי לאפשר גישה אליהם מהרשת המקומית.

איור 5. שימוש ב-DNS peering לארגון כל התחומים עם הסיומת ‎ .internal ברכז.
איור 5. שימוש ב-DNS peering לארגון כל המשאבים של .internal ברכז.

אם נתקלתם בבעיות, תוכלו לפעול לפי המדריך לפתרון בעיות

במדריך לפתרון בעיות ב-Cloud DNS מפורטות הוראות לפתרון שגיאות נפוצות שעשויות להתרחש במהלך ההגדרה של Cloud DNS.

ארכיטקטורות עזר ל-DNS היברידי

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

משתמשים בארכיטקטורת העזר שמתאימה לתכנון הרשת של VPC:

  • ארכיטקטורה היברידית באמצעות רשת VPC משותפת אחת: שימוש ברשת VPC אחת שמחוברת לסביבות מקומיות או מהן.

  • ארכיטקטורה היברידית באמצעות כמה רשתות VPC נפרדות: חיבור של כמה רשתות VPC לסביבות מקומיות באמצעות מנהרות VPN או צירופי VLAN שונים, ושיתוף אותה תשתית DNS מקומית.

  • ארכיטקטורה היברידית עם רשת VPC של צומת שמחוברת לרשתות VPC של קצוות: שימוש בקישור בין רשתות VPC כדי ליצור רשת VPC של צומת שמחוברת לכמה רשתות VPC של קצוות עצמאיות.

בכל מקרה, הסביבה המקומית מחוברת לרשתות ה-VPC Trusted Cloudבאמצעות מנהרה אחת או יותר של Cloud VPN או חיבורי Dedicated Interconnect או Partner Interconnect. לא משנה באיזו שיטת חיבור משתמשים לכל רשת VPC.

ארכיטקטורה היברידית באמצעות רשת VPC משותפת אחת

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

איור 6. בארכיטקטורה היברידית נעשה שימוש ברשת VPC משותפת אחת כדי להתחבר לרשת מקומית.
איור 6. בארכיטקטורה היברידית נעשה שימוש ברשת VPC משותפת אחת כדי להתחבר לרשת מקומית.

כדי להגדיר את הארכיטקטורה הזו:

  1. מגדירים את שרתי ה-DNS המקומיים כשרתי סמכות עבור corp.example.com.
  2. מגדירים תחום פרטי מוסמך (למשל, gcp.example.com) ב-Cloud DNS בפרויקט המארח של רשת ה-VPC המשותפת, ומגדירים את כל הרשומות של המשאבים באזור הזה.
  3. מגדירים מדיניות של שרת DNS בפרויקט המארח של רשת ה-VPC המשותפת כדי לאפשר העברה של נתוני DNS נכנסים.
  4. מגדירים תחום העברת DNS שמעביר את corp.example.com לשרתי ה-DNS המקומיים. רשת ה-VPC המשותפת צריכה לקבל הרשאה לשליחת שאילתות לאזור ההעברה.
  5. מגדירים העברה אל gcp.example.com בשרתי ה-DNS המקומיים, כך שתצביע על כתובת IP של מעביר נכנס ברשת ה-VPC המשותפת.
  6. מוודאים שתנועת DNS מותרת בחומת האש המקומית.
  7. במכונות של Cloud Router, מוסיפים לסביבה המקומית נתיב מודעה מותאם אישית לטווח 177.222.82.0/25.

ארכיטקטורה היברידית עם כמה רשתות VPC נפרדות

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

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

איור 7. בארכיטקטורה היברידית אפשר להשתמש בכמה רשתות VPC נפרדות.
איור 7. בארכיטקטורה היברידית אפשר להשתמש בכמה רשתות VPC נפרדות.

כדי להגדיר את הארכיטקטורה הזו:

  1. מגדירים את שרתי ה-DNS המקומיים כשרתי סמכות עבור corp.example.com.
  2. מגדירים תחום פרטי (לדוגמה, prod.gcp.example.com) ב-Cloud DNS בפרויקט המארח של רשת ה-VPC המשותפת בסביבת הייצור, ומגדירים את כל הרשומות של המשאבים בתחום הזה.
  3. מגדירים תחום פרטי (לדוגמה, dev.gcp.example.com) ב-Cloud DNS בפרויקט המארח של רשת ה-VPC המשותפת לפיתוח, ומגדירים את כל הרשומות של המשאבים בתחום הזה.
  4. מגדירים מדיניות של שרת DNS בפרויקט המארח של רשת ה-VPC המשותפת בסביבת הייצור ומאפשרים העברה של DNS נכנס.
  5. ברשת ה-VPC המשותפת בסביבת הייצור, מגדירים תחום DNS להעברת corp.example.com לשרתי ה-DNS המקומיים.
  6. מגדירים תחום של קישוריות DNS מרשת ה-VPC המשותפת לפיתוח לרשת ה-VPC המשותפת בסביבת הייצור עבור prod.gcp.example.com.
  7. מגדירים תחום של קישורי DNS מרשת ה-VPC המשותפת בסביבת הייצור לרשת ה-VPC המשותפת בסביבת הפיתוח של dev.gcp.example.com.
  8. כדי להגדיר העברה נכנסת, מעבירים את הטיפול בבעיית הפתרון של gcp.example.com. לכתובות ה-IP הווירטואליות של העברה נכנסת ב-Cloud DNS בשרתי השמות המקומיים.
  9. מוודאים שחומת האש מאפשרת תנועה של DNS גם בחומת האש המקומית וגם בחומת האש שלTrusted Cloud .
  10. במכונות של Cloud Router, מוסיפים נתיב מודעה מותאם אישית לטווח כתובות ה-IP 177.222.82.0/25 ברשת ה-VPC המשותפת בסביבת הייצור לסביבה המקומית.

ארכיטקטורה היברידית באמצעות רשת VPC של צומת שמחוברת לרשתות VPC של קצוות

אפשרות נוספת היא להשתמש ב-Cloud Interconnect או ב-Cloud VPN כדי לחבר את התשתית המקומית לרשת VPC של צומת. כפי שמוצג באיור 8, אפשר להשתמש בקישור בין רשתות VPC שכנות (peering) כדי ליצור קישור בין רשת VPC לבין כמה רשתות VPC משניות. כל רשת VPC של זרוע מארחת תחומים פרטיים משלה ב-Cloud DNS. מסלולים מותאמים אישית ב-VPC Network Peering, יחד עם פרסום של מסלול מותאם אישית ב-Cloud Router, מאפשרים החלפה מלאה של מסלולים וקישוריות בין הרשת המקומית לכל רשתות ה-VPC של הענן. קישורי DNS פועלים במקביל לחיבורים של VPC Network Peering כדי לאפשר רזולוציית שמות בין סביבות.

הארכיטקטורה הזו מוצגת בתרשים הבא.

איור 8. בארכיטקטורה היברידית אפשר להשתמש ברשת VPC של צומת שמחוברת לרשתות VPC של קצוות באמצעות קישור בין רשתות VPC שכנות (VPC Network Peering).
איור 8. בארכיטקטורה היברידית אפשר להשתמש ברשת VPC של צומת שמחוברת לרשתות VPC של קצוות.

כדי להגדיר את הארכיטקטורה הזו:

  1. מגדירים את שרתי ה-DNS המקומיים כשרתי סמכות עבור corp.example.com.
  2. מגדירים תחום פרטי (לדוגמה, projectX.gcp.example.com) ב-Cloud DNS לכל רשת VPC של זרוע, ומגדירים את כל הרשומות של המשאבים באותו תחום.
  3. מגדירים מדיניות של שרת DNS בפרויקט הרכז של רשת ה-VPC המשותפת בסביבת הייצור כדי לאפשר העברה של DNS נכנס.
  4. ברשת ה-VPC של הצומת, יוצרים תחום DNS פרטי בשביל corp.example.com ומגדירים העברה של תעבורת נתונים יוצאת לשרתי ה-DNS המקומיים.
  5. מגדירים תחום של קישור בין רשתות שכנות (DNS peering) מרשת ה-VPC של הצומת לכל רשת VPC של הזרוע עבור projectX.gcp.example.com.
  6. מגדירים תחום של קישור בין רשתות שכנות (DNS peering) מכל רשת VPC של זרוע לרשת ה-VPC של הצומת עבור example.com.
  7. מגדירים העברה אל gcp.example.com בשרתי ה-DNS המקומיים כך שתצביע על כתובת IP של מעביר נכנס ברשת ה-VPC של הצומת.
  8. מוודאים שחומת האש מאפשרת תנועה של DNS גם בחומת האש המקומית וגם בחומת האש שלTrusted Cloud .
  9. במכונות של Cloud Router, מוסיפים נתיב מודעה מותאם אישית לטווח כתובות ה-IP 177.222.82.0/25 ברשת ה-VPC של הצומת לסביבה המקומית.
  10. (אופציונלי) אם אתם משתמשים גם בשמות ה-DNS הפנימיים שנוצרים באופן אוטומטי, צריך ליצור שיתוף בין כל אזור של פרויקט Spoke (לדוגמה, spoke-project-x.internal) לבין פרויקט ה-Hub, ולהעביר את כל השאילתות לגבי .internal מהארגון.

המאמרים הבאים