הגדרת 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/orgpolicy.policyAdmin) בתיקייה או בארגון
• כדי לבדוק אם תיקייה מוכנה להעברה ל-DNS אזורי: דפדפן (roles/browser) בתיקייה או בארגון

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

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

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

סקירה כללית של ההגדרה

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

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

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

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

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

מגבלות

הפעלת שמות DNS אזוריים בכל הארגון מחילה הגדרות DNS אזוריות על מופעים בשירותים אחרים, כמו:

• הסביבה הגמישה של App Engine,‏ Google Kubernetes Engine וקונטיינרים שפועלים ב-Compute Engine
• ‫Cloud SQL,‏ פונקציות Cloud Run ו-Batch
• ‫Managed Service for Apache Spark ו-Dataflow

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

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

הגדרת ה-DNS שמוגדרת כברירת מחדל לארגון תלויה בשני גורמים:

• תאריך יצירת הארגון:

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

• הקיום והאכיפה של אילוץ של מדיניות הארגון:

  גם אם הארגון שלכם נוצר לפני 6 בספטמבר 2018, יכול להיות שאדמין אכף מדיניות לשימוש ב-DNS אזורי לכל הפרויקטים החדשים שנוצרו בארגון. כדי לבדוק אם קיימת מדיניות כזו, אפשר להשתמש במסוף Cloud de Confiance או ב-Google Cloud CLI.

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

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

1. יצירת מערך נתונים ב-BigQuery

2. ייצוא המטא-נתונים של הנכסים בארגון לטבלה ב-BigQuery.

   1. צריך לוודא ש-Cloud Asset Inventory API מופעל.
   2. מגדירים את ההרשאות שנדרשות לשימוש ב-Cloud Asset Inventory API.

   3. משתמשים בפקודה הבאה של ה-CLI של gcloud כדי לייצא את נכס compute.googleapis.com/Project:

      gcloud asset export \
         --content-type resource \
         --organization 'ORGANIZATION_ID' \
         --bigquery-table 'projects/PROJECT_ID/datasets/DATASET_ID/tables/TABLE_NAME' \
         --asset-types='compute.googleapis.com/Project' \
         --output-bigquery-force
      

      מחליפים את מה שכתוב בשדות הבאים:

      • ‫ORGANIZATION_ID: מספר הזיהוי של הארגון
      • ‫PROJECT_ID: מזהה הפרויקט
      • ‫DATASET_ID: השם של מערך הנתונים ב-BigQuery
      • ‫TABLE_NAME: הטבלה שאליה מייצאים את המטא-נתונים. אם הטבלה לא קיימת, BigQuery יוצר אותה.

3. עוברים אל BigQuery במסוףCloud de Confiance .

4. בוחרים באפשרות add_box Compose a new query (יצירת שאילתה חדשה).

5. באזור הטקסט של עורך השאילתות, מזינים את שאילתת GoogleSQL הבאה ולוחצים על play_arrow Run.

   SELECT
     JSON_VALUE(SAFE.PARSE_JSON(resource.data).vmDnsSetting) AS vmDnsSetting,
     count(*) as project_count
   FROM PROJECT_ID.DATASET_ID.TABLE_NAME
   GROUP BY 1
   

   מחליפים את מה שכתוב בשדות הבאים:

   • ‫PROJECT_ID: מזהה הפרויקט
   • ‫DATASET_ID: השם של מערך הנתונים ב-BigQuery
   • ‫TABLE_NAME: הטבלה שמכילה את המטא-נתונים המיוצאים, משלב 2.

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

6. אופציונלי: כדי לראות תצוגה מפורטת של vmDnsSetting לכל פרויקט, מזינים את שאילתת GoogleSQL הבאה ולוחצים על play_arrow Run.

   SELECT
     SUBSTR(name,35) as project_id,
     JSON_VALUE(SAFE.PARSE_JSON(resource.data).vmDnsSetting) AS vmDnsSetting
   FROM PROJECT_ID.DATASET_ID.TABLE_NAME
   

קביעת מוכנות להעברה של תיקייה

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

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

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

1. מוצאים את מזהה התיקייה. אם אתם לא יודעים מהו מזהה התיקייה, אתם יכולים לפעול לפי השלבים הבאים:
   1. במסוף Cloud de Confiance , עוברים לדף Managed resources.
   2. מחילים את המסנן Name:FOLDER_NAME כדי לקבל את מזהה התיקייה.

2. שולחים שאילתה לטבלה ב-BigQuery עם הנתונים שיוצאו compute.Project assets.

   הוראות ליצירת הטבלה ב-BigQuery מופיעות במאמר איך קובעים אילו פרויקטים בתיקייה או בארגון משתמשים ב-DNS גלובלי.

   מזינים את שאילתת GoogleSQL הבאה ולוחצים על play_arrow Run:

   SELECT
     SUBSTR(name,35) AS project_id,
   FROM PROJECT_ID.DATASET_ID.TABLE_NAME
   WHERE CONTAINS_SUBSTR(ancestors, 'FOLDER_NUMBER')
   

   מחליפים את מה שכתוב בשדות הבאים:

   • ‫PROJECT_ID: מזהה הפרויקט
   • ‫DATASET_ID: השם של מערך הנתונים ב-BigQuery
   • ‫TABLE_NAME: הטבלה שמכילה את המטא-נתונים המיוצאים
   • ‫FOLDER_NUMBER: מספר מזהה התיקייה

3. מעתיקים את רשימת מזהי הפרויקטים ושומרים אותה בקובץ.

4. מריצים את הסקריפט הבא של bash. הסקריפט חוזר על עצמו על כל מזהי הפרויקטים בקובץ השמור כדי לקבוע אם תיקייה מוכנה להעברה.

#!/bin/bash
inaccessible_projects=()
unready_projects=()

for project in $(cat ~/FILENAME | tr '\n' ' '); do
  echo -e "Checking project $project..."
  ERROR=`curl -s --request POST "https://monitoring.googleapis.com/v3/projects/$project/timeSeries:query"   -H "Authorization: Bearer $(gcloud auth print-access-token)"   -H "Accept: application/json"   -H "Content-Type: application/json"   --data '{"query":"fetch compute.googleapis.com/Location | metric '"'"'compute.googleapis.com/global_dns/request_count'"'"' | filter metric.zonal_dns_readiness = '"'"'zonal_dns_risky'"'"' | every 30d | within 30d"}'   --compressed | jq --raw-output '.error'`
  if ! [[ "$ERROR" -eq "null" ]]; then
    inaccessible_projects+=($project)
    continue
  fi
  QUERY_COUNT=`curl -s --request POST "https://monitoring.googleapis.com/v3/projects/$project/timeSeries:query"   -H "Authorization: Bearer $(gcloud auth print-access-token)"   -H "Accept: application/json"   -H "Content-Type: application/json"   --data '{"query":"fetch compute.googleapis.com/Location | metric '"'"'compute.googleapis.com/global_dns/request_count'"'"' | filter metric.zonal_dns_readiness = '"'"'zonal_dns_risky'"'"' | every 30d | within 30d"}'   --compressed | jq --raw-output '.timeSeriesData[0].pointData[0].values[0].int64Value'`
  if [[ "$QUERY_COUNT" -ne "null" ]] && [[ "$QUERY_COUNT" -ne "0" ]]; then
    unready_projects+=($project)
  fi
done

error_len=${#inaccessible_projects[@]}
unready_len=${#unready_projects[@]}

echo -e "$error_len projects were inaccessible"
echo -e "$unready_len projects were not ready for migration"

if [ $error_len -ne 0 ]; then
  echo "Unable to access the following projects:"
  for project in "${inaccessible_projects[@]}"; do
    echo "$project"
  done
fi
if [ $unready_len -ne 0 ]; then
  echo "The following projects are not ready for migration:"
  for project in "${unready_projects[@]}"; do
    echo "$project"
  done
fi

if (( $error_len + $unready_len > 0 )); then
  echo "This folder is NOT ready for gDNS -> zDNS migration."
else
  echo "This folder is ready for gDNS -> zDNS migration."
fi

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

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

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

תיקיות שמוחרגות לא מוכנות להעברה ל-DNS אזורי

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

1. נכנסים למסוף Cloud de Confiance כסופר-אדמין ב-Google Workspace או ב-Cloud Identity.

2. נכנסים לדף מדיניות הארגון במסוף.

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

3. לוחצים על בחירה ואז בוחרים את התיקיות שרוצים להחריג ממדיניות הארגון.

   Cloud de Confiance במסוף מוצגת רשימה של אילוצים של מדיניות הארגון עבור התיקייה הזו בדף אחד או יותר.

4. כדי למצוא את אילוץ מדיניות הארגון שאוכף DNS אזורי:

   1. לוחצים על סינון.
   2. בוחרים באפשרות שם.
   3. מגדירים את שם המסנן ל-Sets the internal DNS setting for new projects to Zonal DNS Only.

5. לוחצים על שם ההגבלה של מדיניות הארגון כדי לפתוח את הדף פרטי המדיניות.

6. לוחצים על Edit.

7. בדף עריכה, בוחרים באפשרות התאמה אישית.

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

9. לוחצים על Save.

מידע נוסף על התאמה אישית של אילוצים במדיניות הארגון זמין במאמר התאמה אישית של המדיניות בנושא אילוצים בוליאניים במסמכי מנהל המשאבים.

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

כדי להגדיר את מדיניות הארגון לתיקייה או לארגון:

1. נכנסים למסוף Cloud de Confiance כסופר-אדמין ב-Google Workspace או ב-Cloud Identity.

2. נכנסים לדף מדיניות הארגון במסוף.

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

3. בוחרים את התיקייה או הארגון שרוצים לראות את מדיניות הארגון שלהם. במסוף Cloud de Confiance מוצגת רשימה של אילוצים זמינים של מדיניות הארגון. יכול להיות שהרשימה תתפרס על פני כמה דפים.

4. כדי למצוא את המדיניות לאכיפת DNS אזורי, לוחצים על Filter (מסנן) ובוחרים באפשרות Name (שם), ואז מגדירים את שם המסנן ל-Sets the internal DNS setting for new projects to Zonal DNS Only (הגדרת ה-DNS הפנימי לפרויקטים חדשים ל-DNS אזורי בלבד).

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

   בדף הפרטים של המדיניות מופיע מידע על האילוץ ועל אופן ההחלה שלו.

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

6. כדי להתאים אישית את מדיניות הארגון, לוחצים על עריכה.

7. בדף העריכה, לוחצים על התאמה אישית.

8. בקטע אכיפה, בוחרים באפשרות מופעל.

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

9. לוחצים על Save.

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

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

חזרה לשימוש ב-DNS גלובלי בארגון או בתיקייה

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

1. משביתים את מדיניות הארגון constraints/compute.setNewProjectDefaultToZonalDNSOnly ברמת הארגון או התיקייה. הוראות לשינוי המדיניות הזו מופיעות במאמר החלת DNS אזורי כברירת מחדל בפרויקטים חדשים.

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

2. אם רוצים לחזור לשימוש ב-DNS גלובלי לכל הארגון, צריך לוודא שאף אחת מהתיקיות בארגון לא אוכפת את מדיניות הארגון constraints/compute.setNewProjectDefaultToZonalDNSOnly.

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

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

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