מחיקת ארגון ב-Apigee

הדף הזה רלוונטי ל-Apigee, אבל לא ל-Apigee Hybrid.

לעיון במסמכי התיעוד של Apigee Edge.

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

  • בארגונים שהוקצו עם קישור בין רשתות VPC שכנות (peering), יש גם קישור בין רשתות VPC שכנות של Service Networking בין ה-VPC שלכם לבין רשת הדיירים של Apigee. החיבור הזה, וכל טווח שמור של קישור בין רשתות שכנות ורשת VPC שמשויכת אליו, נשארים במקום אחרי שמוחקים את הארגון, וצריך לנקות אותם בנפרד אם כבר לא צריך אותם. המשך: ארגונים שהוקצו עם קישור בין רשתות VPC שכנות (peering).

  • בארגונים שהוקצו עם קישור VPC מושבת, משתמשים ב-Private Service Connect במקום בחיבור Service Networking, ולכן אין קישור של ספק שצריך להסיר. עדיין צריך למחוק את מאזן העומסים של Private Service Connect לכיוון צפון שיצרתם כשהקציתם את הארגון – כלל העברה, שרת proxy ל-HTTPS של היעד, מפת URL, שירות לקצה העורפי, קבוצה של נקודות קצה ברשת PSC, אישור SSL וכתובת IP שמורה – אחרת תמשיכו לצבור חיובים על כלל ההעברה וכתובת ה-IP השמורה. המשך: ארגונים שהוקצו בלי VPC Peering.

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

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

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

  • בארגון ב-Apigee (בדרך כלל APIGEE_PROJECT_ID): apigee.organizations.delete. ההרשאה הזו כלולה בתפקיד roles/apigee.admin, שמתואר במדריך התפקידים ב-Apigee כתפקיד היחיד שמאפשר ליצור, למחוק או לעדכן ארגונים.

  • בנוסף, אם הארגון שלכם הוקצה עם קישור VPC מופעל ואתם מתכננים לנקות את החיבור של Service Networking, את טווח קישור ה-VPC או את רשת ה-VPC, כמו שמתואר בקטע המשך: ארגונים שהוקצו עם קישור VPC: בפרויקט שבבעלותו רשת ה-VPC המקושרת (פרויקט הרשת, שיכול להיות שונה מהפרויקט שלכם ב-Apigee בהגדרה של VPC משותף), servicenetworking.services.deleteConnection, compute.globalAddresses.delete ו-compute.networks.delete.

קודם צריך למחוק את המשאבים התלויים

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

לגבות את כל הנתונים שרוצים לשמור

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

איך בודקים אם הארגון משתמש בקישור בין רשתות VPC שכנות (peering)

פעולות הניקוי שצריך לבצע אחרי מחיקת הארגון תלויות בשאלה אם הארגון הוקצה עם קישור VPC פתוח. לפני שמוחקים את הארגון, קוראים את ההגדרות שלו באמצעות ה-API‏ organizations.get:

curl -X GET \
  -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  "https://apigee.googleapis.com/v1/organizations/ORGANIZATION"

הקריאה הזו וכל קריאת Apigee REST אחרת בדף הזה מטרגטות את נקודת הקצה הגלובלית apigee.googleapis.com. אם הארגון שלכם נמצא באזור של מיקום אחסון נתונים, צריך להחליף את נקודת הקצה האזורית המתאימה בכל דוגמה.

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

  • אם התגובה מכילה את הערך "disableVpcPeering": true, הארגון הוקצה בלי קישור VPC שכנים (peering). אחרי שמוחקים את הארגון, פועלים לפי ההוראות במאמר המשך טיפול: ארגונים שהוקצו בלי קישור VPC.

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

    • השדה authorizedNetwork, שמזהה את רשת ה-VPC שמקושרת ב-Peering ל-Apigee. הוא מופיע באחת משתי צורות:
      • נתיב מלא של המשאב projects/NETWORK_PROJECT_ID/global/networks/NETWORK_NAME, שמכיל גם את פרויקט הרשת וגם את שם הרשת. הפורמט הזה משמש כשהרשת נמצאת בפרויקט שונה מהארגון ב-Apigee – בדרך כלל בהגדרה של VPC משותף, שבה הרשת נמצאת בפרויקט המארח.
      • רק שם הרשת (לדוגמה, apigee-network). אם מופיע רק השם, הרשת נמצאת באותו פרויקט בענן ב-Google Cloud כמו הארגון שלכם ב-Apigee. בשלבי הניקוי, התייחסו לפרויקט הזה (APIGEE_PROJECT_ID) בתור NETWORK_PROJECT_ID.
      שימו לב שהשדה authorizedNetwork מוגדר רק בארגונים עם קישור VPC.
    • השם של הכתובת הגלובלית שהוקצתה במקור לטווח ה-VPC Peering (לדוגמה, apigee-range). הכתובת הזו הוקצתה כשהארגון הוקצה לראשונה.

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

מחיקת הארגון ב-Apigee

שולחים קריאה ל-API‏ organizations.delete כדי למחוק את הארגון. הקריאה מחזירה פעולה ממושכת, ובארגונים עם מינוי הערכה, היא מבצעת מחיקה מיידית. בארגונים בתשלום (מינוי או תשלום לפי שימוש), היא מבצעת מחיקה זמנית בכפוף לחלון השמירה.

curl -X DELETE \
  -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  "https://apigee.googleapis.com/v1/organizations/ORGANIZATION"

כדי להשתמש בחלון השמירה המינימלי (24 שעות) בארגון בתשלום, צריך להוסיף את פרמטר השאילתה retention:

curl -X DELETE \
  -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  "https://apigee.googleapis.com/v1/organizations/ORGANIZATION?retention=MINIMUM"

התשובה מכילה פעולה ממושכת. אפשר לדגום אותה באמצעות organizations.operations.get.

המשך: ארגונים שהוקצו בלי קישור בין רשתות VPC שכנות (peering)

אם השדה disableVpcPeering של הארגון הוא true, מחיקת הארגון לא משחררת משאבים של Service Networking, כי לארגון שהוקצה בלי קישור בין רשתות VPC שכנות אף פעם לא היה חיבור ל-Service Networking, ואין קישור בין רשתות שכנות של ספק שצריך להסיר.

עדיין צריך למחוק את מאזן העומסים של Private Service Connect לכיוון צפון שיצרתם בפרויקט שלכם כשהקציתם את הארגון. המשאבים האלה לא בבעלות Apigee, ו-organizations.delete לא מפיצה אף אחד מהם. מוחקים אותם בסדר הפוך של תלות:

  1. כלל העברה
  2. שרת proxy ל-HTTPS עם יעד
  3. מפת URL
  4. שירות לקצה העורפי
  5. קבוצה של נקודות קצה ברשת מסוג PSC
  6. אישור SSL
  7. כתובת IP שמורה

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

המשך טיפול: ארגונים שהוקצו עם קישור בין רשתות VPC שכנות (peering)

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

איסוף הערכים שאתם צריכים

בשלבי הניקוי הבאים נעשה שימוש חוזר באותם ערכים כדי להוסיף אותם להליכים במדריכים המקושרים של Service Networking ו-VPC. קובעים כל ערך פעם אחת, ואז מגדירים אותו כמשתנה מעטפת כדי שתוכלו להעתיק את הפקודות המקושרות מילה במילה:

  • ‫NETWORK_PROJECT_ID – הפרויקט שבבעלותו רשת ה-VPC המקושרת. הפרויקט הזה לא תמיד זהה לפרויקט של שירות Apigee: בהגדרה של VPC משותף, הרשת נמצאת בפרויקט המארח. מפיקים אותו מהערך של authorizedNetwork שתיעדתם בקטע בדיקה אם הארגון משתמש בקישור VPC:

    • אם authorizedNetwork הוא נתיב מלא למשאב projects/NETWORK_PROJECT_ID/global/networks/NETWORK_NAME, צריך לקחת את NETWORK_PROJECT_ID מהנתיב הזה.
    • אם authorizedNetwork הוא רק שם רשת (לדוגמה, apigee-network), הרשת נמצאת באותו פרויקט כמו הארגון ב-Apigee. צריך להשתמש בפרויקט ב-Apigee‏ (APIGEE_PROJECT_ID).
  • ‫NETWORK_NAME – השם של רשת ה-VPC (למשל, apigee-network). אפשר לקחת אותו מהנתיב המלא ב-authorizedNetwork, או להשתמש בערך הפשוט כש-authorizedNetwork הוא רק שם.

  • ‫APIGEE_RANGE_NAME – השם של הכתובת הגלובלית שהוקצתה לטווח ה-VPC Peering (לדוגמה, apigee-range) כשהארגון הוקצה. אפשר לראות את הטווחים השמורים שמצורפים להתאמת Peering ברשימה reservedPeeringRanges שמוחזרת על ידי gcloud services vpc-peerings list.

  • ‫NETWORK_PROJECT_NUMBER – מספר הפרויקט של NETWORK_PROJECT_ID. ב-Service Networking API בארכיטקטורת REST צריך לציין את מספר הפרויקט (ולא את מזהה הפרויקט) בשדה consumerNetwork:

    gcloud projects describe NETWORK_PROJECT_ID \
      --format="value(projectNumber)"

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

אזהרות שרלוונטיות לפירוק של Apigee

השלמת הניקוי

פועלים לפי ההליכים המקושרים, ומחליפים את המשתנים מאיסוף הערכים הדרושים:

  • מוחקים את החיבור של Service Networking. פועלים לפי ההוראות במאמר מחיקת חיבור פרטי. כבר מחקתם את הארגון ב-Apigee בקטע מחיקת הארגון ב-Apigee, ולכן התנאי המוקדם של המדריך להסרת המכונה של השירות מתקיים בארגונים להערכה, שנמחקים באופן מיידי. בארגונים בתשלום, המחיקה היא מחיקה זמנית, והחיבור נמחק רק אחרי שחלון השמירה חולף. אפשר לעיין בקטע חלון השמירה והקצאה מחדש, או למחוק את הארגון באמצעות ?retention=MINIMUM כדי לקצר את החלון ל-24 שעות. כשהתהליך מבקש את הרשת ואת פרויקט הרשת, משתמשים ב-NETWORK_NAME וב-NETWORK_PROJECT_ID. כשקריאת ה-REST הבסיסית של services.connections.deleteConnection מבקשת את consumerNetwork, משתמשים ב-projects/NETWORK_PROJECT_NUMBER/global/networks/NETWORK_NAME.

  • (אופציונלי) שחרור טווח ה-peering השמור. פועלים לפי ההוראות במאמר מחיקת טווח כתובות IP שהוקצה, באמצעות APIGEE_RANGE_NAME ו-NETWORK_PROJECT_ID. הטווח השמור הוא משאב בבעלות הלקוח שנשאר אחרי שמוחקים את הארגון ב-Apigee ואת החיבור של Service Networking. אם משאירים אותו, הוא לא משבש אף שירות של Google Cloud.

  • (אופציונלי) מחיקת רשת ה-VPC אם ניתבתם תנועה צפונה דרך קבוצת מופעי מכונה מנוהלים או מאזן עומסים פנימי ברשת הזו, קודם צריך למחוק את המשאבים האלה, אחרת מחיקת הרשת תיכשל עם שגיאת משאב תלוי: כלל העברה, שרת proxy לחלוקת העומס, מפת URL, שירות לקצה העורפי, קבוצת מופעי מכונה מנוהלים, תבנית של הגדרות מכונה, בדיקת תקינות, כללי חומת אש וכתובת שמורה. לאחר מכן, פועלים לפי ההוראות בקטע מחיקת רשת במדריך לרשתות VPC, באמצעות NETWORK_NAME ו-NETWORK_PROJECT_ID.

חלון זמן לשמירה והקצאה מחדש

כפי שמתואר במאמר העזר בנושא organizations.delete:

  • ארגונים להערכה נמחקים על ידי Apigee באופן מיידי.
  • ב-Apigee, ארגונים בתשלום (מינוי או תשלום על פי שימוש) נמחקים באופן זמני עם חלון שמירה של 7 ימים כברירת מחדל. במהלך חלון השמירה, אפשר לשחזר את הארגון על ידי שליחת כרטיס תמיכה ל-Apigee. אם מעבירים את הערך ?retention=MINIMUM בבקשת המחיקה, החלון מתקצר ל-24 שעות.
  • במהלך חלון השמירה, אי אפשר ליצור מחדש ארגון ב-Apigee באותו פרויקט בענן של Google.

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

הפניות ב-Apigee:

מקורות מידע על Service Networking וגישה לשירותים פרטיים: