העברה מ-AWS אל Google Cloud: העברה מ-Amazon EC2 אל Compute Engine

Last reviewed 2026-01-05 UTC

‫Google Cloud מספקת כלים, מוצרים, הנחיות ושירותים מקצועיים להעברת מכונות וירטואליות (VM) יחד עם הנתונים שלהן מ-Amazon Elastic Compute Cloud‏ (Amazon EC2) אל Compute Engine. במאמר הזה מוסבר איך לתכנן, להטמיע ולאמת תוכנית להעברה מ-Amazon EC2 אל Compute Engine.

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

המסמך הזה הוא חלק מסדרה של מסמכים בנושא מעבר מ-AWS אלGoogle Cloud , והוא כולל את המסמכים הבאים:

כדי לבצע את ההעברה אל Google Cloud, מומלץ לפעול לפי מסגרת ההעברה שמתוארת במאמר העברה אל Google Cloud: תחילת העבודה.

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

נתיב העברה עם ארבעה שלבים.

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

  1. הערכה וגילוי של עומסי העבודה והנתונים.
  2. מתכננים ובונים בסיס ב- Google Cloud.
  3. העברת עומסי העבודה והנתונים אל Google Cloud.
  4. אופטימיזציה של Google Cloud הסביבה

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

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

הערכת סביבת המקור

בשלב ההערכה, קובעים את הדרישות והתלות להעברת סביבת המקור אל Google Cloud.

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

שלב ההערכה כולל את המשימות הבאות:

  1. יוצרים מלאי מקיף של עומסי העבודה.
  2. מקטלגים את עומסי העבודה לפי המאפיינים והתלות שלהם.
  3. הדרכה ולימוד של הצוותים בנושא Google Cloud.
  4. יצירת ניסויים והוכחות היתכנות ב- Google Cloud.
  5. חישוב עלות הבעלות הכוללת (TCO) של סביבת היעד.
  6. בוחרים את אסטרטגיית ההעברה של עומסי העבודה.
  7. בוחרים את כלי ההעברה.
  8. מגדירים את תוכנית ההעברה ואת לוח הזמנים.
  9. מאמתים את תוכנית ההעברה.

מידע נוסף על שלב ההערכה ועל המשימות האלה זמין במאמר Migrate to Google Cloud: Assess and discover your workloads. הקטעים הבאים מבוססים על מידע שמופיע במאמר הזה.

יצירת מלאי של מכונות Amazon EC2

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

כדי ליצור את מלאי המשאבים של מופעי Amazon EC2, מומלץ להשתמש בMigration Center, הפלטפורמה המאוחדת שלGoogle Cloudשעוזרת לכם להאיץ את המעבר מקצה לקצה לענן, מהסביבה הנוכחית שלכם אל Google Cloud. Migration Center מאפשר לכם להריץ גילוי מלאי ב-AWS.

יכול להיות שהנתונים שמתקבלים מ-Migration Center ומכלי ה-CLI של לקוח הגילוי של Migration Center לא יכללו את כל המאפיינים שמעניינים אתכם. במקרה כזה, אפשר לשלב את הנתונים האלה עם התוצאות ממנגנונים אחרים לאיסוף נתונים שאתם יוצרים על סמך AWS APIs, כלי הפיתוח של AWS וממשק שורת הפקודה של AWS.

בנוסף לנתונים שמתקבלים מ-Migration Center ומכלי השורת הפקודה של לקוח הגילוי של Migration Center, כדאי לשים לב לנקודות הנתונים הבאות לגבי כל מופע של Amazon EC2 שרוצים להעביר:

  • האזור והתחום שבהם מתבצעת הפריסה.
  • סוג וגודל המופע.
  • קובץ ה-Amazon Machine Image ‏ (AMI) שממנו המופע מופעל.
  • שם המארח של המופע, ואיך מופעים ועומסי עבודה אחרים משתמשים בשם המארח הזה כדי לתקשר עם המופע.
  • תגי המופע, וגם מטא-נתונים ונתוני משתמשים.
  • סוג הווירטואליזציה של המופע.
  • אפשרות הרכישה של המופע, למשל רכישה על פי דרישה או רכישת Spot.
  • איך המופע מאחסן נתונים, למשל באמצעות חנויות מופעים ונפחי Amazon EBS.
  • הגדרת השכירות של המכונה.
  • אם המופע נמצא בקבוצת מיקומי מודעות ספציפית.
  • אם המופע נמצא בקבוצת שינוי גודל אוטומטי ספציפית.
  • קבוצות האבטחה שהמופע שייך אליהן.
  • כל הגדרה של AWS Network Firewall שכוללת את המכונה.
  • האם עומסי העבודה שמופעלים במופע מוגנים על ידי AWS Shield ו-AWS WAF.
  • האם אתם שולטים במצב המעבד של המופע, ואיך עומסי העבודה שפועלים במופע תלויים במצב המעבד.
  • ההגדרה של מתזמן קלט/פלט של המכונה.
  • איך חושפים עומסי עבודה שפועלים במופע ללקוחות שפועלים בסביבת AWS (כמו עומסי עבודה אחרים) וללקוחות חיצוניים.

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

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

הערכת תהליכי הפריסה והתפעול

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

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

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

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

  • מאחסנים את הארטיפקטים. אם אתם יוצרים ארטיפקטים שמאוחסנים במאגר ארטיפקטים בסביבת המקור, אתם צריכים להפוך את הארטיפקטים לזמינים בסביבת Google Cloud . אפשר לעשות זאת באמצעות אסטרטגיות כמו:

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

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

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

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

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

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

  • אימות. בודקים איך מתבצע אימות מול סביבת המקור.

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

    • משאבים ב-Terraform Provider: מתחילים מאפס באמצעות אבני בניין בסיסיות. Google Cloud
    • מודולים ותוכניות של Terraform ל- Google Cloud: מתחילים ממודולים בסיסיים של Terraform. הגישה הזו מבוססת על משאבים ב-Terraform Provider של Google Cloud .
    • תוכנית לניהול של תשתיות לארגונים: מתחילים מתשתית מקובעת ומאזורי נחיתה. הגישה הזו מבוססת על מודולים ותוכניות לניהול של Terraform ל- Google Cloud.
    • ‫Cloud Foundation Fabric: מתחילים מהגדרות בסיסיות ומהגדרות של אזורי נחיתה. Cloud Foundation Fabric הוא הטמעה עצמאית שמשתמשת במודולים משלה של Terraform. הגישה הזו מבוססת על משאבים ב- Google Cloud Terraform Provider.

תכנון ובנייה של הבסיס

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

  • תמיכה בעומסי העבודה בסביבת Google Cloud .
  • כדי להשלים את ההעברה, צריך לקשר בין סביבת המקור לבין הסביבה שלכם. Google Cloud

שלב התכנון והבנייה מורכב מהמשימות הבאות:

  1. בניית היררכיית משאבים.
  2. מגדירים את ניהול הזהויות והרשאות הגישה (IAM) של Google Cloud.
  3. הגדרת חיוב.
  4. הגדרת חיבור לרשת.
  5. הגברת האבטחה.
  6. הגדרת רישום ביומן, מעקב והתראות.

מידע נוסף על כל אחת מהמשימות האלה זמין במאמר מעבר אל Google Cloud: תכנון ובניית הבסיס.

העברת עומסי העבודה

כדי להעביר את עומסי העבודה מ-Amazon EC2 ל-Compute Engine, מבצעים את הפעולות הבאות:

  1. העברת מכונות וירטואליות מ-Amazon EC2 ל-Compute Engine.
  2. העברת הדיסקים של מכונת ה-VM לדיסק אחסון מתמיד (persistent disk).
  3. חשיפת עומסי עבודה שפועלים ב-Compute Engine ללקוחות.
  4. שינוי מבנה של תהליכי הפריסה והתפעול כדי לטרגט אתGoogle Cloud במקום לטרגט את Amazon EC2.

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

העברת מכונות וירטואליות ל-Compute Engine

כדי להעביר מכונות וירטואליות מ-Amazon EC2 ל-Compute Engine, מומלץ להשתמש ב-Migrate to Virtual Machines, שהוא שירות מנוהל מלא. מידע נוסף זמין במאמר תהליך ההעברה באמצעות Migrate to VMs.

במסגרת ההעברה, כלי Migrate for VMs מעביר מכונות Amazon EC2 במצב הנוכחי שלהן, מלבד שינויים נדרשים בהגדרות. אם מכונות Amazon EC2 שלכם מריצות תמונות AMI מותאמות אישית של Amazon EC2, ‏ Migrate for VMs מעביר את ההתאמות האישיות האלה למכונות Compute Engine. עם זאת, אם רוצים ליצור תשתית שניתן לשכפל, יכול להיות שיהיה צורך להחיל התאמות אישיות מקבילות על ידי יצירת תמונות של מערכת הפעלה ב-Compute Engine כחלק מתהליכי הפריסה והתפעול, כפי שמוסבר בהמשך המאמר הזה.

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

אפשר גם להשתמש ב-Migrate to VMs כדי להעביר דיסקים ממכונות ה-VM של Amazon EC2 במקור ל-Persistent Disk, עם שיבושים מינימליים בעומסי העבודה שמופעלים במכונות ה-VM של Amazon EC2. למידע נוסף, אפשר לעיין במאמר בנושא העברת דיסקים של מכונות וירטואליות וצירוף שלהם למכונה וירטואלית חדשה.

לדוגמה, אתם יכולים להעביר דיסק נתונים שמצורף למכונה וירטואלית של Amazon EC2 ל-Persistent Disk, ולצרף אותו למכונה וירטואלית חדשה של Compute Engine.

חשיפת עומסי עבודה שפועלים ב-Compute Engine

אחרי שמעבירים את המכונות של Amazon EC2 למכונות של Compute Engine, יכול להיות שיהיה צורך להקצות ולהגדיר את סביבת Google Cloudכדי לחשוף את עומסי העבודה ללקוחות.

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

  • חומות אש
  • איזון עומסים של תנועה
  • שמות, אזורים ורשומות של DNS
  • הגנה מפני DDoS וחומות אש לאפליקציות אינטרנט

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

בקטעים הבאים מוסבר איך להקצות משאבים מסוגGoogle Cloud ולהגדיר אותם בקטגוריות האלה, ואיך הם ממופים למשאבי AWS בקטגוריות דומות.

חומות אש

אם הגדרתם קבוצות אבטחה של AWS ומדיניות וכללים של AWS Network Firewall, אתם יכולים להגדיר מדיניות וכללים של Cloud Next Generation Firewall. אפשר גם להקצות כללים של VPC Service Controls כדי לווסת את תעבורת הנתונים ברשת ה-VPC. אתם יכולים להשתמש ב-VPC Service Controls כדי לשלוט בתעבורה היוצאת מהמכונות שלכם ב-Compute Engine, וכדי לצמצם את הסיכון לזליגת נתונים.

לדוגמה, אם אתם משתמשים בקבוצות אבטחה של AWS כדי לאפשר או לחסום חיבורים למכונות Amazon EC2, אתם יכולים להגדיר כללי חומת אש דומים של רשת וירטואלית פרטית (VPC) שחלים על מכונות Compute Engine.

אם אתם משתמשים בפרוטוקולים של גישה מרחוק כמו SSH או RDP כדי להתחבר למכונות וירטואליות ב-Amazon EC2, אתם יכולים להסיר את כתובת ה-IP הציבורית של המכונה הווירטואלית ולהתחבר אליה מרחוק באמצעות שרת proxy לאימות זהויות (IAP). שרת proxy לאימות זהויות מאפשר להגדיר מנהור TCP מוצפן. אתם יכולים להשתמש במנהור כדי להעביר תנועת אינטרנט של SSH,‏ RDP ותנועה אחרת למכונות וירטואליות בלי להקצות להן כתובות IP ציבוריות. מכיוון שהחיבורים משירות ה-IAP מגיעים מטווח כתובות IP ציבוריות שמורות, צריך ליצור כללי חומת אש תואמים ב-VPC. אם יש לכם מכונות וירטואליות מבוססות Windows והפעלתם את חומת האש של Windows, אתם צריכים לוודא שחומת האש של Windows לא מוגדרת לחסימת חיבורי RDP מ-IAP. מידע נוסף זמין במאמר בנושא פתרון בעיות ב-RDP.

איזון עומסים של תנועה

אם הגדרתם איזון עומסים גמיש (ELB) בסביבת AWS, אתם יכולים להגדיר Cloud Load Balancing כדי לחלק את תעבורת הרשת ולשפר את יכולת ההתאמה של עומסי העבודה ב- Google Cloud. ‫Cloud Load Balancing תומך בכמה מוצרים לאיזון עומסים גלובליים ואזוריים שפועלים בשכבות שונות של מודל OSI, למשל בשכבת התעבורה ובשכבת האפליקציה. אתם יכולים לבחור מוצר לאיזון עומסים שמתאים לדרישות של עומסי העבודה שלכם.

‫Cloud Load Balancing תומך גם בהגדרת Transport Layer Security ‏ (TLS) להצפנת תעבורת הרשת. כשמגדירים TLS ל-Cloud Load Balancing, אפשר להשתמש באישורי TLS בניהול עצמי או בניהול Google, בהתאם לדרישות.

שמות, אזורים ורשומות של DNS

אם אתם משתמשים ב-Amazon Route 53 בסביבת AWS, אתם יכולים להשתמש בערך הבא ב- Google Cloud:

לדוגמה, אם רשמתם דומיין באמצעות Amazon Route 53, אתם יכולים להעביר את רישום הדומיין אל Cloud Domains. באופן דומה, אם הגדרתם אזורי DNS ציבוריים ושרתי DNS פרטיים באמצעות Amazon Route 53, אתם יכולים להעביר את ההגדרה הזו ל-Cloud DNS.

הגנה מפני DDoS וחומות אש של אפליקציות אינטרנט

אם הגדרתם את AWS Shield ו-AWS WAF בסביבת AWS, תוכלו להשתמש ב-Google Cloud Armor כדי להגן על עומסי העבודה מפני התקפות DDoS וניצול לרעה נפוץ. Google Cloud

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

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

  • הקצאה והגדרה של משאבים בסביבת Google Cloud היעד במקום הקצאת משאבים בסביבת המקור.
  • ליצור ולהגדיר עומסי עבודה ולפרוס אותם ב- Google Cloudבמקום לפרוס אותם בסביבת המקור.

בשלב ההערכה בתהליך הזה, אספתם מידע על התהליכים האלה.

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

  • יכול להיות שהטמעתם את התהליכים האלה בסביבת המקור, ואתם מתכוונים לתכנן ולהטמיע תהליכים דומים ב- Google Cloud. לדוגמה, אתם יכולים לשנות את התהליכים האלה כך שישתמשו ב-Cloud Build, ב-Cloud Deploy וב-Infrastructure Manager.
  • יכול להיות שהטמעתם את התהליכים האלה בסביבת צד שלישי אחרת מחוץ לסביבת המקור. במקרה כזה, צריך לשנות את התהליכים האלה כך שיפעלו בסביבת Google Cloud היעד ולא בסביבת המקור.
  • שילוב של הגישות הקודמות.

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

למידע נוסף על תכנון והטמעה של תהליכי פריסה ב- Google Cloud:

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

  1. הקצאת מאגרי פריטי מידע שנוצרו בתהליך פיתוח (artifacts) ב- Google Cloud. לדוגמה, אפשר להשתמש ב-Artifact Registry כדי לאחסן פריטי מידע שנוצרו בתהליך פיתוח ויחסי תלות בגרסת build.
  2. מבצעים רפקטורינג בתהליכי ה-build כדי לאחסן את הארטיפקטים גם בסביבת המקור וגם ב-Artifact Registry.
  3. מבצעים רפקטורינג לתהליכי הפריסה כדי לפרוס את עומסי העבודה בסביבת היעדGoogle Cloud . לדוגמה, אפשר להתחיל בפריסה של קבוצת משנה קטנה של עומסי העבודה ב- Google Cloud, באמצעות ארטיפקטים שמאוחסנים ב-Artifact Registry. לאחר מכן, מגדילים בהדרגה את מספר עומסי העבודה שנפרסים ב- Google Cloud, עד שכל עומסי העבודה להעברה יפעלו ב-Google Cloud.
  4. מבצעים רפקטורינג בתהליכי ה-build כדי לאחסן את הארטיפקטים רק ב-Artifact Registry.
  5. במקרה הצורך, מעבירים גרסאות קודמות של הארטיפקטים כדי לפרוס ממאגרי המידע בסביבת המקור אל Artifact Registry. לדוגמה, כדי להעביר תמונות של קונטיינרים אל Artifact Registry, אפשר להשתמש בכלים כמו gcrane או Rackware SWIFT.
  6. להוציא משימוש את המאגרים בסביבת המקור כשאין בהם יותר צורך.

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

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

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

אופטימיזציה של Google Cloud הסביבה

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

  1. הערכה של הסביבה הנוכחית, הצוותים ולולאת האופטימיזציה.
  2. מגדירים את דרישות האופטימיזציה ואת המטרות.
  3. מבצעים אופטימיזציה של הסביבה ושל הצוותים.
  4. שיפור של לולאת האופטימיזציה.

חוזרים על הרצף הזה עד שמשיגים את יעדי האופטימיזציה.

מידע נוסף על אופטימיזציה של סביבת Google Cloud זמין במאמרים מעבר אל Google Cloud: אופטימיזציה של הסביבה וGoogle Cloud Well-Architected Framework: אופטימיזציה של ביצועים.

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

שותפים ביצירת התוכן

מחבר: Marco Ferrari | Cloud Solutions Architect