יצירת תוכנית מיגרציה

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

במהלך ההעברה, Cloud Resource Manager API מתייחס לפרויקט ולשירותים הבסיסיים שלו כיחידה אחת, בלי שינויים בהגדרות הפנימיות. עם זאת, כללי מדיניות ההרשאות, הדחייה והארגון שעוברים בירושה לא מועברים עם הפרויקט, אבל כללי המדיניות וחשבונות השירות שמצורפים ישירות נשארים. השינוי הזה בהיררכיה עלול לגרום להתנהגות בלתי צפויה או להפעיל הפרות של מדיניות הארגון בארגון היעד.

סקירה כללית של המלאי

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

אתם יכולים גם להשתמש ב-Cloud Asset Inventory כדי להעביר את הנתונים האלה ל-BigQuery. כך תוכלו לשלוח שאילתות לנתונים באמצעות SQL, שקל יותר לקרוא בהשוואה לפרשנות של נתונים בפורמט JSON. למידע נוסף על ייצוא הנתונים האלה, קראו את המאמר ייצוא ל-BigQuery.

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

אימות המדיניות

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

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

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

ניהול מפתחות מוצפנים

צריך לבדוק אם בפרויקט מופעל מפתח הצפנה בניהול הלקוח או שירות אחר של Cloud Key Management Service. המפתחות הקריפטוגרפיים נמצאים בבעלות הפרויקט, ולכן משתמש עם גישת owner לפרויקט יוכל לנהל ולבצע פעולות קריפטוגרפיות במפתחות ב-Cloud KMS באותו פרויקט.

למידע נוסף, קראו את המאמר הפרדת תפקידים.

תכונות בגרסת טרום-השקה (Preview)

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

זיהוי החשבון החדש לחיוב

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

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

איך משנים או מעבירים חשבון לחיוב?

תוכנית חזרה למצב הקודם

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

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

תיקיות ייעודיות לייבוא ולייצוא

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

כשמתכננים העברה, כדאי להגדיר קודם תיקיית מקור ייעודית. כדי לעשות את זה, יוצרים תיקייה לכל משאב ארגון יעד שאליו רוצים לייצא פרויקטים. לאחר מכן, מגדירים מדיניות ארגון בתיקיות האלה, כשבכל אחת מהן האילוץ constraints/resourcemanager.allowedExportDestinations מוגדר למשאב הארגון היחיד שאליו רוצים לייצא פרויקטים.

לדוגמה, אפשר להגדיר תיקיות בשם Export to Marketing Org ו-Export to Sales Org, ולהגדיר לכל אחת מהן את האילוצים המתאימים של מדיניות הארגון.

באופן דומה, מגדירים תיקיות ייבוא ייעודיות במשאב הארגון של היעד, אחת לכל משאב ארגון שממנו רוצים לייבא פרויקטים. כדי לעשות את זה, יוצרים תיקייה לכל משאב של ארגון מקור שממנו מתכננים לייבא פרויקטים. לאחר מכן, מגדירים מדיניות ארגונית בתיקיות האלה, כשבכל אחת מהן האילוץ constraints/resourcemanager.allowedImportSources מוגדר למשאב הארגוני היחיד שממנו רוצים לייבא פרויקטים.

לדוגמה, אתם יכולים להגדיר תיקיות בשם Import from Marketing Org ו-Import from App Development Org, ולהגדיר לכל אחת מהן את האילוצים המתאימים של מדיניות הארגון.

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

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

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

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

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