העברת הפרויקטים ל-DNS אזורי

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

לפני שמתחילים

• אם עדיין לא עשיתם את זה, תצטרכו להגדיר אימות. אימות הוא תהליך שבו מאמתים את הזהות שלכם כדי לקבל גישה לממשקי API ולשירותים של Cloud de Confiance by S3NS . כדי להריץ קוד או דוגמאות מסביבת פיתוח מקומית, אפשר לבצע אימות ל-Compute Engine באחת מהדרכים הבאות:

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

  המסוף

  כשמשתמשים במסוף Cloud de Confiance כדי לגשת לשירותים ולממשקי ה-API, לא צריך להגדיר אימות. Cloud de Confiance by S3NS

  gcloud

  1. התקינו את ה-CLI של Google Cloud ואז היכנסו ל-CLI של gcloud באמצעות הזהות המאוחדת שלכם. אחרי שנכנסתם לחשבון, אתחלו את ה-CLI של Google Cloud באמצעות הפקודה הבאה:

     gcloud init

• הגדרת אזור ותחום כברירת מחדל

REST

כדי להשתמש בסביבת פיתוח מקומית בדוגמאות של API בארכיטקטורת REST שבדף הזה, צריך להשתמש בפרטי הכניסה שאתם נותנים ל-CLI של gcloud.

התקינו את ה-CLI של Google Cloud ואז היכנסו ל-CLI של gcloud באמצעות הזהות המאוחדת שלכם.

מידע נוסף מופיע במאמר אימות לשימוש ב-REST במסמכי האימות של Cloud de Confiance .

התפקידים הנדרשים

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

• העברת פרויקט לשימוש ב-DNS אזורי: עריכת פרויקטים (roles/resourcemanager.projectEditor) בפרויקט
• כדי להעביר מכונות וירטואליות ל-DNS אזורי בפרויקט: Compute Instance Admin (v1) (roles/compute.instanceAdmin.v1) בפרויקט
• אם המכונה הווירטואלית משתמשת בחשבון שירות: משתמש בחשבון שירות (roles/iam.serviceAccountUser) בחשבון השירות או בפרויקט

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

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

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

הגדרת מעקב אחרי כשלים בחיפוש DNS

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

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

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

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

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

1. בדיקה אם הפרויקט משתמש ב-DNS גלובלי כברירת מחדל
2. קובעים את מידת המוכנות של הפרויקטים למיגרציה באמצעות ניתוח שאילתות
3. העברת פרויקטים שתואמים ל-DNS אזורי
4. פתרון בעיות בשאילתות לא תואמות
5. מעקב אחרי יומני DNS גלובליים כדי לוודא שההעברה מוכנה.
6. העברת שאר הפרויקטים ל-DNS אזורי
7. איך בודקים אם שינוי ב-DNS אזורי משפיע על הפרויקט

בדיקה אם הפרויקט משתמש ב-DNS גלובלי כברירת מחדל

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

gcloud compute project-info describe --project=PROJECT_ID --flatten="vmDnsSetting"

GET https://compute.s3nsapis.fr/compute/v1/projects/PROJECT_ID?fields=id,name,vmDnsSetting

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

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

• ‫zonal_dns_ready (שאילתות תואמות): המדד הזה מייצג את המספר הכולל של שאילתות במהלך תקופה של 100 ימים שאפשר לפתור בהצלחה באמצעות DNS אזורי.

• ‫zonal_dns_risky (Incompatible queries): המדד הזה מייצג את המספר הכולל של שאילתות שלא ניתן לפתור באמצעות DNS אזורי. השאילתות האלה בדרך כלל כוללות תקשורת בין אזורים או תרחישים אחרים שבהם הפתרון האזורי נכשל. חשוב לדעת: אם הערך של המדד הזה שונה מאפס, הפרויקט שלכם עדיין לא מוכן להעברה. כדי לעבור ל-DNS אזורי, צריך קודם לטפל בשאילתות האלה שלא תואמות.

כדי לראות את המדדים האלה, משתמשים בMetrics Explorer במסוף Cloud de Confiance .

1. נכנסים לדף leaderboard Metrics explorer במסוף Cloud de Confiance :

   כניסה אל Metrics Explorer

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

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

3. אם שדה להזנת קלט של השאילתה לא נקרא PromQL Query, אז בשדה Language, צריך לבחור באפשרות PromQL.

4. בשדה להזנת קלט של השאילתה, מזינים את הטקסט הבא בדיוק כמו שהוא מופיע:

   increase({"compute.googleapis.com/global_dns/request_count", monitored_resource="compute.googleapis.com/Location"}[1d])
   

5. לוחצים על הלחצן הפעלת שאילתה.

   Cloud de Confiance במסוף מוצג תרשים של שני המדדים (zonal_dns_ready ו-zonal_dns_risky) ומספר השאילתות התואם שבוצעו במהלך תקופת הזמן עבור כל מדד.

   

6. בודקים את הערך של המדד zonal_dns_risky.

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

העברת פרויקטים שתואמים ל-DNS אזורי

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

אחרי שמגדירים את רשומת המטא-נתונים הזו, מופעלות בדוגמאות של המחשוב הפעולות הבאות:

• הגישה אליהם אפשרית רק באמצעות שמות ה-DNS האזוריים שלהם (VM_NAME.ZONE.c.PROJECT_ID.internal) כשמשתמשים בנתיבי חיפוש.
• שומרים את נתיבי החיפוש האזוריים והגלובליים, אבל שמות ה-DNS הגלובליים, שלא כוללים את ZONE כחלק משם ה-DNS הפנימי, לא פועלים יותר.
• אפשר להשתמש בשמות DNS גלובליים כדי לגשת רק למופעים אחרים באותו אזור ובאותו פרויקט.

כך עושים את זה:

1. משתמשים במסוף Cloud de Confiance , ב-CLI של gcloud או ב-REST כדי לשנות את רשומת המטא-נתונים vmDnsSetting של הפרויקט.

   המסוף

   1. כדי לעדכן את ההגדרה ברמת הפרויקט, במסוף Cloud de Confiance , עוברים לדף Metadata של Compute Engine.

      מעבר לדף 'מטא-נתונים בהתאמה אישית'

   2. לוחצים על edit עריכה.

   3. אם קיים מפתח עם הערך VmDnsSetting, הערך שלו ישתנה ל-ZonalOnly.

   4. אם מפתח עם הערך VmDnsSetting לא קיים, לוחצים על add_box הוספת פריט.

      • בשדה מפתח, מזינים VmDnsSetting.
      • בשדה ערך, מזינים ZonalOnly.

   5. כדי לסיים את השינוי של רשומות המטא-נתונים המותאמות אישית, לוחצים על שמירה.

   gcloud

   1. כדי לעדכן את הגדרת המטא-נתונים של הפרויקט הנוכחי, משתמשים בפקודה project-info add-metadata.

      gcloud compute project-info add-metadata \
           --metadata vmDnsSetting=ZonalOnly
      

   2. אופציונלי: כדי לאמת את הגדרות המטא-נתונים של פרויקט, משתמשים בפקודה הבאה:

      gcloud compute project-info describe --project=PROJECT_ID --flatten="vmDnsSetting"
      

      מחליפים את PROJECT_ID בשם הפרויקט שרוצים לשלוח לו שאילתה.

   REST

   כדי לעדכן את הגדרת המטא-נתונים ברמת הפרויקט, יוצרים בקשת POST באמצעות השיטה projects.setCommonInstanceMetadata.

   1. אופציונלי: כדי לבצע נעילה אופטימית, אפשר לספק טביעת אצבע.

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

      אם לא מספקים טביעת אצבע, לא מתבצעת בדיקה של העקביות, וprojects.setCommonInstanceMetadataהבקשה מצליחה. אם משתמשים בשיטה instances.setMetadata, תמיד נדרשת טביעת אצבע.

      כדי לקבל את טביעת האצבע הנוכחית של פרויקט, צריך לבצע קריאה ל-method‏ project.get.

      GET https://compute.s3nsapis.fr/compute/v1/projects/PROJECT_ID
      

      הפלט אמור להיראות כך:

      {
        "name": "myproject",
        "commonInstanceMetadata": {
            "kind": "compute#metadata",
            "fingerprint": "FikclA7UBC0=",
            ...
        }
      }
      

   2. יוצרים בקשת POST לשיטה projects.setCommonInstanceMetadata כדי להגדיר את צמד המפתח/ערך של המטא-נתונים:

      POST https://compute.s3nsapis.fr/compute/v1/projects/PROJECT_ID/setCommonInstanceMetadata
      
      {
        "fingerprint": "FikclA7UBC0=",
        "items": [
          {
             "key": "vmDnsSetting",
             "value": "ZonalOnly"
          }
        ]
      }
      

      מחליפים את PROJECT_ID במזהה הפרויקט.

2. אחרי שמגדירים את רשומת המטא-נתונים vmDnsSetting לפרויקט, צריך לרענן את פרק הזמן לעיבוד (lease) של DHCP בכל מופע בפרויקט. אפשר לרענן את ההרשאה באחת מהשיטות הבאות:

   • הפעלה מחדש של המכונה
   • מחכים עד שתוקף החכירה יפוג

   • מריצים אחת מהפקודות הבאות:

     מכונות Linux

     sudo dhclient -v -r
     

     מכונות וירטואליות של Windows

     ipconfig /renew
     

3. בודקים שהפרויקט משתמש ב-DNS אזורי.

תיקון שאילתות לא תואמות

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

• ביצוע שיחה למופע של מחשוב בפרויקט אחר
• ביצוע שיחה למופע של מחשוב באזור אחר

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

כדי לפתור בעיות של שאילתות לא תואמות:

1. אפשר להשתמש ב-Logs Explorer כדי לגשת לנתוני השימוש הגלובלי ב-DNS של מופעי מחשוב בפרויקט ולשלוח עליהם שאילתות.

   כניסה לדף Logs Explorer

2. בוחרים את הפרויקט.

3. החלת המסננים של המשאב ושם היומן:

   1. לוחצים על Resource.
   2. בתיבת הדו-שיח Select resource (בחירת משאב), בוחרים באפשרות VM Instance (מכונה וירטואלית) ולוחצים על Apply (החלה).
   3. לוחצים על שם היומן.

   4. בתיבת הדו-שיח Select log names (בחירת שמות יומנים), בוחרים באפשרות gdnsusage ולוחצים על Apply (החלה).

      שאילתה חלופית

      אפשרות אחרת היא להזין את הפרטים הבאים בשדה השאילתה:

       resource.type='gce_instance'
       log_name='projects/PROJECT_ID/logs/compute.googleapis.com/gdnsusage'
      

4. בחלונית Query results, לכל שאילתה יש שדה jsonPayload. כל שדה jsonPayload מכיל את הפרטים הבאים:

   • שם מכונת ה-VM של המקור, מזהה הפרויקט ושם האזור.
   • שם מכונת היעד, מזהה הפרויקט ושם האזור.

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

     "To use Zonal DNS, update the Global DNS query sent from the source VM
     VM_NAME.c.PROJECT_ID.internal to the following zonal
     FQDN: VM_NAME.ZONE.c.PROJECT_ID.internal"
     

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

   צילום המסך הבא מציג את פרטי השדה jsonPayload בדף של מסוף Logs Explorer.

   

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

   • שמות DNS פנימיים משרת המטא-נתונים: לא נדרשת פעולה כלשהי כי שם ה-DNS שמוחזר ישתנה ל-FQDN אזורי מיד אחרי המעבר ל-DNS אזורי. אם שם ה-DNS נמצא במטמון, צריך לבצע עוד קריאה אחת כדי לעדכן את הערך במטמון.
   • שמות DNS פנימיים שמשמשים לגישה למכונות וירטואליות באזור אחר: אם יש לכם אפליקציה שמשתמשת בשמות DNS פנימיים למכונות וירטואליות באזורים שונים, אתם יכולים לשנות את מדיניות ה-DHCP או את קובץ ההגדרה כדי לכלול את האזור באזור אחר.
   • שם דומיין מוגדר במלואו (FQDN) גלובלי שמוגדר בהארדקוד: אם יש לכם אפליקציה שמשתמשת בשמות FQDN גלובליים שמוגדרים בהארדקוד למכונות וירטואליות, אתם יכולים לעדכן את הקריאה באפליקציה כדי להשתמש בשם DNS פנימי או בשם FQDN אזורי במקום זאת. אפשר לבצע את השינוי הזה באמצעות שינוי קוד או שינוי הגדרה ב-Terraform.
   • מכונות וירטואליות בפרויקטים של שירותים שמשתמשים ברשת VPC משותפת: כדי לפתור שמות DNS של מכונות וירטואליות בפרויקטים של שירותים שמשתמשים ברשת VPC משותפת, צריך להשתמש בשמות דומיין מלאים (FQDN) אזוריים של המכונות הווירטואליות.

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

   1. משתמשים בדף Logs Explorer כדי לשלוח שוב שאילתה לגבי השימוש הגלובלי ב-DNS. אחרי שתתקנו את כל השאילתות הגלובליות של DNS שחוסמות, לא אמורים להופיע יומני ניפוי באגים בתוצאות השאילתה.

   2. בודקים שוב את מדד המעקב כדי לוודא שכל שאילתות ה-DNS הלא תואמות הוסרו.

צפייה ביומני DNS גלובליים ב-Logs Explorer

ב-Logs Explorer מוצגים בעיקר יומני DNS גלובליים של פרויקטים עם שאילתות שלא תואמות ל-DNS אזורי. היומנים האלה עוזרים לכם לזהות ולנתח את השאילתות הבעייתיות לפני המיגרציה.

אפשר גם להשתמש ב-Logs Explorer כדי לבצע את הפעולות הבאות עם שאילתות לא תואמות:

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

בדיקה אם שינוי ב-DNS אזורי משפיע על הפרויקט

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

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

1. תקשורת של מופע בשורת הפקודה

   משימה: ניסיון לשלוח פינג למכונה אחת ממכונה אחרת באמצעות ה-CLI של gcloud.

   gcloud compute ssh VM-A --command "ping VM-B"
   

   שגיאה פוטנציאלית: 'לא ניתן לפתור את שם המארח' – המשמעות היא ש-VM-A לא יכול למצוא את כתובת ה-IP של VM-B.

   פתרון: צריך לעדכן את שם המארח שבו אתם משתמשים עבור VM-B לשם הדומיין שמוגדר במלואו (FQDN), שכולל את שם האזור: INSTANCE_NAME.ZONE.c.PROJECT_ID.internal

2. תקשורת בין מכונות בשירותי Compute Engine

   משימה: אם אתם משתמשים בבדיקות תקינות עבור קבוצות של מכונות מנוהלות (MIG) שמסתמכות על שמות DNS פנימיים, כדאי לבדוק אם בדיקות התקינות עוברות.

   שגיאה פוטנציאלית: 'בדיקת תקינות נכשלה' – השגיאה הזו מציינת שבדיקת התקינות לא יכולה להגיע ליעד שלה בגלל בעיות בפענוח DNS.

   פתרון: מוודאים שבבדיקת התקינות נעשה שימוש בשם הדומיין שמוגדר במלואו (FQDN) של מופע היעד, כולל שם האזור.

3. תרחישים לדוגמה לשימוש באפליקציות

   הרבה אפליקציות מסתמכות על DNS פנימי למשימות כמו:

   • חיבור למסדי נתונים (לדוגמה, Cloud SQL)

   • אינטראקציה עם תורי הודעות (לדוגמה, Pub/Sub)

   • שגיאות אפשריות: השגיאות משתנות בהתאם לאפליקציה, אבל יכולות לכלול:

     • "אי אפשר להתחבר אל SERVICE_NAME"
     • "תם הזמן הקצוב לתפוגת החיבור"
     • ‫"No such host is known" (לא ידוע על מארח כזה)

   • פתרון: בודקים את ההגדרות של האפליקציה כדי לוודא שהיא משתמשת ב-FQDN (כולל שם האזור) כשמפנים לשירותים.

פתרון בעיות בתהליך ההעברה מ-DNS גלובלי ל-DNS אזורי

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

חזרה לשימוש ב-DNS גלובלי

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

חזרה לשימוש ב-DNS גלובלי בפרויקט

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

1. מוסיפים את הערך הבא למטא-נתונים של הפרויקט: vmDnsSetting=GlobalDefault.

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

2. מוודאים שאף אחת מהמכונות בפרויקט לא הגדירה את ערך המטא-נתונים vmDnsSetting ל-ZonalOnly.

   gcloud compute instances describe INSTANCE_NAME --flatten="metadata[]"
   

   מחליפים את INSTANCE_NAME בשם המכונה שרוצים לבדוק.

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

   • מופעי Linux: ‏ sudo dhclient -v -r
   • מכונה וירטואלית של Windows Server: ipconfig /renew

חזרה לשימוש ב-DNS גלובלי למופע

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

1. מעדכנים את המטא-נתונים של המופע כך שיכללו את vmDnsSetting=GlobalDefault.

   במאמר הגדרת מטא-נתונים מותאמים אישית והסרתם מוסבר איך מגדירים ערכים של מטא-נתונים של מכונת חישוב.

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

   • ב-Container-Optimized OS או ב-Ubuntu:

     sudo systemctl restart systemd-networkd
     

   • ב-CentOS‏, RedHat EL‏, Fedora CoreOS או Rocky Linux:

     sudo systemctl restart network
     

     או

     sudo systemctl restart NetworkManager.service
     

   • ב-Debian:

     sudo systemctl restart networking
     

   • במערכות Linux עם nmcli:

     sudo nmcli networking off
     sudo nmcli networking on
     

   • ב-Windows:

     ipconfig /renew
     

חזרה לשימוש ב-DNS גלובלי לקונטיינר

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

1. מגדירים את הגדרת המטא-נתונים של הפרויקט vmDnsSetting לערך GlobalDefault בפרויקטים שבבעלותם נמצאים המאגרים ומכונות ה-VM.

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

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

• כדאי לעיין בCloud de Confiance by S3NS היררכיית המשאבים כדי לקבל מידע על הקשר בין ארגונים, תיקיות ופרויקטים.
• מידע נוסף על DNS פנימי ל-Compute Engine