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

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

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

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

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

    המסוף

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

    gcloud

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

      gcloud init

      אם אתם משתמשים בספק זהויות חיצוני (IdP), קודם אתם צריכים להיכנס ל-CLI של gcloud באמצעות המאגר המאוחד לניהול זהויות.

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

    • REST

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

      התקינו את ה-CLI של Google Cloud.

      אם אתם משתמשים בספק זהויות חיצוני (IdP), קודם אתם צריכים להיכנס ל-CLI של gcloud באמצעות המאגר המאוחד לניהול זהויות.

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

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

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

  • בודקים את מדיניות ה-DNS הגלובלית שמוגדרת כברירת מחדל: אדמין של מדיניות הארגון (roles/orgpolicy.policyAdmin) בתיקייה או בארגון
  • כדי לבדוק אם תיקייה מוכנה להעברה ל-DNS אזורי: דפדפן (roles/browser) בתיקייה או בארגון

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

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

ההרשאות הנדרשות

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

  • הגדרת אילוץ של מדיניות הארגון: orgpolicy.*
  • איך בודקים אם תיקייה מוכנה להעברה ל-DNS אזורי:
    • resourcemanager.folders.get
    • resourcemanager.folders.list
    • resourcemanager.organizations.get
    • resourcemanager.projects.get
    • resourcemanager.projects.list
  • בודקים שמות DNS גלובליים ומטא-נתונים של מכונות וירטואליות: compute.projects.get

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

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

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

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

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

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

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

מגבלות

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

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

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

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

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

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

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

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

המסוף

  1. נכנסים לדף IAM & Admin>Identity & Organization במסוף.

    כניסה לדף Identity & Organization

  2. בודקים את תאריך ההרשמה של הארגון.

    צילום מסך של הדף Identity & Organization במסוף, שבו מוצג התאריך שבו ההרשמה הושלמה.

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

    1. נכנסים לדף IAM & Admin>Organization Policies במסוף Google Cloud .
    2. בשדה Filter, מזינים constraints/compute.setNewProjectDefaultToZonalDNSOnly.
    3. אם המגבלה מוגדרת, לוחצים על השם Sets the internal DNS setting for new projects to Zonal DNS Only (הגדרת ה-DNS הפנימי לפרויקטים חדשים היא DNS אזורי בלבד).
    4. בדף פרטי המדיניות, בודקים את הסטטוס.
      • אם הסטטוס הוא Enforced, סוג ברירת המחדל של ה-DNS הפנימי הוא DNS אזורי בכל הפרויקטים החדשים שנוצרו בארגון.
      • אחרת, סוג ה-DNS שמוגדר כברירת מחדל בפרויקט עדיין נקבע לפי זמן יצירת הארגון.
    5. אם המגבלה לא הוגדרה לארגון, סוג ה-DNS שמוגדר כברירת מחדל לפרויקט נקבע לפי תאריך היצירה של הארגון.

gcloud

משתמשים בפקודה organizations describe ובפקודה resource-manager org-policies list כדי לקבוע את סוג ה-DNS שמוגדר כברירת מחדל בארגון.

  1. בודקים את ערך המטא-נתונים של הארגון creationTime.

    gcloud organizations describe ORGANIZATION_ID

    מחליפים את ORGANIZATION_ID במספר המזהה של הארגון או בשם הדומיין של הארגון.

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

    gcloud resource-manager org-policies list --organization=ORGANIZATION_ID \
   --filter="constraints/compute"

    בפלט, מחפשים את constraints/compute.setNewProjectDefaultToZonalDNSOnly.

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

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

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

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

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

    1. מוודאים שה-API של Cloud Asset Inventory מופעל.
    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 במסוףGoogle Cloud .

  4. לוחצים על Compose a new query.

  5. באזור הטקסט של עורך השאילתות, מזינים את השאילתה הבאה ב-GoogleSQL ולוחצים על  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 הבאה ולוחצים על  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. במסוף Google Cloud , עוברים לדף Managed resources.
    2. מפעילים את המסנן Name:FOLDER_NAME כדי לקבל את מזהה התיקייה.

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

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

    מזינים את השאילתה הבאה ב-GoogleSQL ולוחצים על  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 בשם הקובץ שבו שמרתם את רשימת מזהי הפרויקטים.

העברת תוצאות הניתוח של מוכנות ההעברה ל-Project Owner:

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

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

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

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

    כניסה לדף Organization policies

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    כניסה לדף Organization policies

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

  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.

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

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

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

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

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

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

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

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

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