העברה של פרויקט Google Cloud היא פעולה שקשורה למטא-נתונים, שמשנה את המיקום של הפרויקט בהיררכיית המשאבים. בדף הזה מוסבר איך מתבצעות העברות, מה נשאר זהה ומה משתנה כשמעבירים פרויקט לארגון חדש.
פרויקטים בהיררכיית המשאבים
משאב הפרויקט הוא הישות המארגנת ברמת הבסיס במשאב ארגון ב- Google Cloud. פרויקטים נוצרים מתחת למשאבי הארגון, ואפשר למקם אותם מתחת לתיקיות או למשאב הארגון עצמו, וכך ליצור את היררכיית המשאבים.
יכול להיות שתצטרכו להעביר פרויקטים בין משאבי ארגון בגלל רכישות, דרישות רגולטוריות או הפרדה של יחידות עסקיות. אפשר להשתמש ב-Resource Manager API כדי להעביר את הפרויקטים האלה. ה-API מאפשר גם לבטל את ההעברה ולהחזיר את הפרויקט למקום המקורי שלו בהיררכיה, אם יש צורך בכך.
תרחישי העברה
המיקום של הפרויקט קובע באיזו מבין שתי הדרכים תבחרו:
- העברת פרויקטים מארגון אחד למשאב ארגון אחר.
- העברה של פרויקט עצמאי (שנוצר ללא ארגון) להיררכיה של משאב ארגון.
זיהוי המצב הנוכחי של הפרויקט
לפני שמתחילים, צריך לבדוק אם הפרויקט משויך למשאב מסוג 'ארגון'. כך תוכלו לדעת אם אתם צריכים לפעול לפי השלבים של מעבר מארגון לארגון או לפי השלבים של מעבר ללא ארגון.
אם אין לכם הרשאה resourcemanager.organizations.get במשאב הארגון ברמת ההורה של הפרויקט, סביר להניח שהפרויקטים לא יוצגו כמו שציפיתם בארגון בפועל בGoogle Cloud מסוף. יכול להיות שייראה כאילו הפרויקט לא משויך לאף משאב ארגוני.
כדי לבדוק אם הפרויקט משויך למשאב ארגוני, מריצים את הפקודה הבאה:
gcloud
gcloud projects describe PROJECT_ID
מחליפים את PROJECT_ID במזהה הפרויקט שרוצים להעביר.
אם הפלט כולל שדה parent, הפרויקט כבר חלק מהיררכיה של ארגון.
אם השדה parent חסר או ריק, הפרויקט הוא פרויקט עצמאי ללא משאב ארגון.
בהתאם למצב הפרויקט, פועלים לפי המדריך הרלוונטי:
- אם רוצים להעביר פרויקטים שנוצרו ללא ארגון משויך, אפשר לעיין במאמר בנושא העברת פרויקטים שלא משויכים למשאב ארגון.
- אם אתם רוצים להעביר פרויקטים מארגון אחד למשאב ארגון אחר, תוכלו לקרוא את המאמר העברת פרויקטים בין משאבי ארגון.
איך ההעברה פועלת
העברת פרויקט היא לא העברת נתונים. השירותים, מסדי הנתונים והמכונות הווירטואליות (VM) שלכם יישארו פעילים ולא תהיה השבתה. במקום זאת, המיגרציה מעדכנת את משאב ההורה של הפרויקט. מכיוון ש- Google Cloud פועל לפי מודל היררכי של העברה בירושה, מצב האבטחה של הפרויקט משתנה ברגע שהוא מצורף לישות אב חדשה.
| תכונה | סטטוס | השפעה |
|---|---|---|
| מזהה פרויקט ומספר | ללא שינוי | מפתחות API, שמות שירות ומזהים שמוטמעים בקוד לא משתנים. |
| נתונים ומשאבים | ללא שינוי | המכונות הווירטואליות, מאגרי האחסון ומסדי הנתונים נשארים אונליין. |
| תפקידי IAM ישירים | ללא שינוי | תפקידים שהוענקו ישירות בפרויקט עוברים איתו. |
| תפקידי IAM שעוברים בירושה | סיכום השינויים | התפקידים שניתנו ברמת הארגון או התיקייה של המקור לא נשמרים. |
| מדיניות הארגון | סיכום השינויים | אילוצים של מקור מוחלפים באילוצים של יעד. |
| מכסות | סיכום השינויים | המיכסות שמועברות בירושה ברמת הארגון יאבדו, אבל המיכסות ברמת הפרויקט יישארו. |
| חשבון לחיוב | ללא שינוי | הפרויקט נשאר מקושר לחשבון לחיוב המקורי. |
השפעה על המכסה
אם הגדרתם מכסות ברמה מסוימת של משאב, ההיבטים הבאים יחולו אחרי ההעברה:
- כל המכסות שהוגדרו ברמת הפרויקט יישארו ללא שינוי.
- כל המכסות שמוגדרות ברמת משאב הארגון לא מועברות. הארגון מאבד את כל המכסות שהועברו בירושה.
בדפים הבאים אפשר לראות אילו מכסות חלות על משאב ארגוני:
דוגמה
$ gcloud alpha services quota list --service=compute.googleapis.com --consumer=projects/workloadyee --filter="metric: compute.googleapis.com/cpus"
...
- defaultLimit: '600'
dimensions:
region: us-central1
effectiveLimit: '650'
...
שיקולים חשובים
לפני שמתחילים בהעברה, חשוב לבדוק את האזורים המסוכנים האלה כדי למנוע שיבושים בשירות:
מגבלות מכסה: אם בארגון היעד יש מגבלות מכסה נמוכות יותר מאשר במקור, יכול להיות שהפרויקט יחרוג מהמכסה שלו כשהוא יגיע ליעד.
VPC משותף: אי אפשר להעביר פרויקט שמצורף ל-VPC משותף. כדי להעביר את הפרויקט, קודם צריך לנתק אותו מה-VPC המשותף של המקור.
תפקידים בהתאמה אישית: אם הפרויקט מסתמך על תפקידי IAM בהתאמה אישית שהוגדרו ברמת הארגון, התפקידים האלה לא יופיעו ביעד. צריך ליצור אותם מחדש בארגון היעד לפני ההעברה.
תוכנית ההעברה
התוכנית הבאה תעזור לכם להתמצא בתהליך העברת הפרויקט:
- הכנה: יוצרים תוכנית העברה כדי לתאם את התזמון.
- ביצוע: הקצאת תפקידי IAM והגדרת מדיניות ארגונית והפעלת ההעברה.
- אימות: השלמת משימות אחרי ההעברה, כמו ביקורת על מדיניות שהועברה ועדכון החיוב.