Google Cloud מספקת כלים, מוצרים, הדרכה ושירותים מקצועיים להעברת מכונות וירטואליות (VM) יחד עם הנתונים שלהן מ-Amazon Elastic Compute Cloud (Amazon EC2) אל Compute Engine. במאמר הזה מוסבר איך לתכנן, ליישם ולאמת תוכנית להעברה מ-Amazon EC2 ל-Compute Engine.
הדיון במסמך הזה מיועד לאדמינים של הענן שרוצים לקבל פרטים על תכנון והטמעה של תהליך העברה. המדריך מיועד גם למקבלי החלטות שבוחנים את האפשרות להעברה ורוצים להבין איך תיראה ההעברה.
המסמך הזה הוא חלק מסדרה של מסמכים בנושא מעבר מ-AWS אלGoogle Cloud , והוא כולל את המסמכים הבאים:
- שנתחיל?
- העברה מ-Amazon EC2 ל-Compute Engine (המסמך הזה)
- העברה מ-Amazon S3 ל-Cloud Storage
- מעבר מ-Amazon EKS ל-Google Kubernetes Engine
- העברה מ-Amazon RDS ומ-Amazon Aurora ל-MySQL אל Cloud SQL ל-MySQL
- העברה מ-Amazon RDS ומ-Amazon Aurora ל-PostgreSQL אל Cloud SQL ל-PostgreSQL ו-AlloyDB ל-PostgreSQL
- העברה מ-Amazon RDS ל-SQL Server אל Cloud SQL ל-SQL Server
- העברה מ-AWS Lambda ל-Cloud Run
כדי לבצע את ההעברה אל Google Cloud, מומלץ לפעול לפי מסגרת ההעברה שמתוארת במאמר העברה אל Google Cloud: תחילת העבודה.
התרשים הבא מדגים את התהליך של המעבר.
יכול להיות שתעברו מסביבת המקור אל Google Cloud בסדרה של איטרציות – לדוגמה, יכול להיות שתעבירו קודם חלק מעומסי העבודה ואחרים בשלב מאוחר יותר. בכל איטרציה נפרדת של ההעברה, פועלים לפי השלבים של מסגרת ההעברה הכללית:
- הערכה וגילוי של עומסי העבודה והנתונים.
- מתכננים ובונים בסיס ב- Google Cloud.
- העברת עומסי העבודה והנתונים אל Google Cloud.
- אופטימיזציה של Google Cloud הסביבה
מידע נוסף על השלבים של המסגרת הזו זמין במאמר מעבר אל Google Cloud: תחילת העבודה.
כדי לתכנן תוכנית העברה יעילה, מומלץ לאמת כל שלב בתוכנית ולוודא שיש לכם אסטרטגיה לביטול השינויים. כדי לאמת את תוכנית ההעברה, אפשר לעיין במאמר מעבר אל Google Cloud: שיטות מומלצות לאימות תוכנית העברה.
הערכת סביבת המקור
בשלב ההערכה, קובעים את הדרישות והתלות כדי להעביר את סביבת המקור אל Google Cloud.
שלב ההערכה הוא חיוני להצלחת ההעברה. אתם צריכים להכיר לעומק את עומסי העבודה שאתם רוצים להעביר, את הדרישות שלהם, את התלות שלהם ואת הסביבה הנוכחית שלכם. כדי לתכנן ולהוציא לפועל העברה מוצלחת, צריך להבין את נקודת ההתחלה. Google Cloud
שלב ההערכה כולל את המשימות הבאות:
- יוצרים מלאי מקיף של עומסי העבודה.
- מקטלגים את עומסי העבודה בהתאם למאפיינים ולתלות שלהם.
- הדרכה ולימוד של הצוותים בנושא Google Cloud.
- יצירת ניסויים והוכחות היתכנות ב- Google Cloud.
- חישוב עלות הבעלות הכוללת (TCO) של סביבת היעד.
- בוחרים את אסטרטגיית ההעברה של עומסי העבודה.
- בוחרים את כלי ההעברה.
- מגדירים את תוכנית ההעברה ואת לוח הזמנים.
- בודקים את תוכנית ההעברה.
מידע נוסף על שלב ההערכה והמשימות האלה זמין במאמר מעבר אל Google Cloud: הערכה וגילוי של עומסי העבודה. הקטעים הבאים מבוססים על מידע שמופיע במסמך הזה.
יצירת מלאי של מכונות 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 .
- שינוי מבנה של תהליך build של הארטיפקטים: מבצעים שינוי מבנה קל בסביבת המקור כדי לאחסן ארטיפקטים גם בסביבת המקור וגם בסביבת היעד. הגישה הזו תומכת בהעברה שלכם על ידי בניית תשתית כמו מאגר ארטיפקטים לפני שאתם צריכים להטמיע תהליכי בנייה של ארטיפקטים בסביבת היעד של Google Cloud. אפשר להשתמש בגישה הזו ישירות, או להשתמש בגישה הקודמת של יצירת ערוץ תקשורת קודם.
העובדה שהארטיפקטים זמינים גם בסביבת המקור וגם בסביבת היעד מאפשרת לכם להתמקד בהעברה בלי שתצטרכו להטמיע תהליכי בנייה של ארטיפקטים בסביבת היעד Google Cloud כחלק מההעברה.
סריקה וחתימה על קוד. כחלק מתהליכי בניית הארטיפקטים, יכול להיות שאתם משתמשים בסריקת קוד כדי להגן מפני נקודות חולשה נפוצות וחשיפה לא מכוונת של הרשת, ובחתימת קוד כדי לוודא שרק קוד מהימן פועל בסביבות שלכם.
פריסת ארטיפקטים בסביבת המקור. אחרי שיוצרים ארטיפקטים שאפשר לפרוס, יכול להיות שתפרסו אותם בסביבת המקור. מומלץ לבדוק כל תהליך פריסה. ההערכה עוזרת לוודא שתהליכי הפריסה שלכם תואמים ל- Google Cloud. הוא גם עוזר להבין את המאמץ שיידרש כדי לשנות את התהליכים בסופו של דבר. לדוגמה, אם תהליכי הפריסה שלכם פועלים רק עם סביבת המקור, יכול להיות שתצטרכו לשנות אותם כך שיפעלו עם סביבת Google Cloud היעד.
הוספת הגדרות בזמן ריצה. יכול להיות שאתם מזריקים הגדרות של זמן ריצה לאשכולות ספציפיים, לסביבות זמן ריצה או לפריסות של עומסי עבודה. יכול להיות שההגדרה תאתחל משתני סביבה וערכי הגדרה אחרים, כמו סודות, פרטי כניסה ומפתחות. כדי לוודא שתהליכי ההזרקה של הגדרות זמן הריצה פועלים ב- Google Cloud, מומלץ להעריך איך אתם מגדירים את עומסי העבודה שפועלים בסביבת המקור.
רישום ביומן, מעקב ויצירת פרופילים. כדאי להעריך את תהליכי הרישום, המעקב והפרופילים שמוגדרים אצלכם כדי לעקוב אחרי תקינות סביבת המקור, המדדים שמעניינים אתכם והאופן שבו אתם משתמשים בנתונים שמתקבלים מהתהליכים האלה.
אימות. בודקים איך מתבצע האימות מול סביבת המקור.
הקצאת משאבים והגדרתם. כדי להכין את סביבת המקור, יכול להיות שתכננתם והטמעתם תהליכים שמקצים ומגדירים משאבים. לדוגמה, יכול להיות שאתם משתמשים ב-Terraform יחד עם כלי ניהול תצורה כדי להקצות ולהגדיר משאבים בסביבת המקור. אם אתם משתמשים ב-Terraform, אתם יכולים לבנות את התשתית ואת אזור הנחיתה ב- Google Cloud באמצעות הכלים הבאים, בהתאם לנקודת ההתחלה המועדפת עליכם:
- משאבים ב- Google Cloud Terraform Provider: אפשר להתחיל מאפס באמצעות אבני בניין בסיסיות.
- מודולים ותוכניות לניהול של Terraform ב- Google Cloud: מתחילים ממודולים בסיסיים של Terraform. הגישה הזו מבוססת על משאבים ב- Google Cloud Terraform Provider.
- Enterprise Foundations Blueprint: מתחילים מיסודות ומתחומי נחיתה מוגדרים. הגישה הזו מבוססת על מודולים ותוכניות לניהול של Terraform ב- Google Cloud.
- Cloud Foundation Fabric: מתחילים מבסיס מובנה ומאזורי נחיתה. Cloud Foundation Fabric היא הטמעה עצמאית שמשתמשת במודולים משלה של Terraform. הגישה הזו מבוססת על משאבים ב- Google Cloud Terraform Provider.
תכנון ובנייה של הבסיס
בשלב התכנון והבנייה, מקצים ומגדירים את התשתית כדי לבצע את הפעולות הבאות:
- תמיכה בעומסי העבודה בסביבת Google Cloud .
- כדי להשלים את ההעברה, צריך לחבר את סביבת המקור ואת סביבת Google Cloud היעד.
שלב התכנון והבנייה מורכב מהמשימות הבאות:
- בניית היררכיית משאבים.
- מגדירים את ניהול הזהויות והרשאות הגישה (IAM) של Google Cloud.
- הגדרת חיוב.
- הגדרת חיבור לרשת.
- חיזוק האבטחה.
- הגדרת רישום ביומן, מעקב והתראות.
מידע נוסף על כל אחת מהמשימות האלה זמין במאמר מעבר אל Google Cloud: תכנון ובניית הבסיס.
העברת עומסי העבודה
כדי להעביר את עומסי העבודה מ-Amazon EC2 ל-Compute Engine, מבצעים את הפעולות הבאות:
- העברת מכונות וירטואליות מ-Amazon EC2 ל-Compute Engine.
- מעבירים את הדיסקים של מכונת ה-VM לדיסק אחסון מתמיד (persistent disk).
- חשיפת עומסי עבודה שפועלים ב-Compute Engine ללקוחות.
- שינוי מבנה של תהליכי הפריסה והתפעול כדי לטרגט את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 כחלק מתהליכי הפריסה והתפעול, כפי שמוסבר בהמשך המאמר הזה.
העברת דיסקים של מכונות וירטואליות לדיסק אחסון מתמיד (persistent disk)
אפשר גם להשתמש ב-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). הכוונה אוטומטית של TCP ב-IAP מאפשרת לכם ליצור מנהרה מוצפנת. אפשר להשתמש במנהור כדי להעביר 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:
- Cloud Domains כדי לרשום את דומייני ה-DNS.
- Cloud DNS לניהול של אזורי DNS ציבוריים ופרטיים ושל רשומות DNS.
לדוגמה, אם רשמתם דומיין באמצעות 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במקום להפריס אותם בסביבת המקור.
בשלב ההערכה, מוקדם יותר בתהליך הזה, אספתם מידע על התהליכים האלה.
סוג ארגון הקוד מחדש (Refactoring) שצריך לבצע בתהליכים האלה תלוי באופן שבו תכננתם והטמעתם אותם. הארגון מחדש תלוי גם במצב הסופי שרוצים להגיע אליו בכל תהליך. לדוגמה:
- יכול להיות שיישמתם את התהליכים האלה בסביבת המקור, ואתם מתכוונים לעצב וליישם תהליכים דומים ב- Google Cloud. לדוגמה, אפשר לבצע רפקטורינג בתהליכים האלה כדי להשתמש ב-Cloud Build, ב-Cloud Deploy וב-Infrastructure Manager.
- יכול להיות שהטמעתם את התהליכים האלה בסביבת צד שלישי אחרת מחוץ לסביבת המקור. במקרה כזה, צריך לשנות את התהליכים האלה כך שיפעלו בסביבת Google Cloud היעד ולא בסביבת המקור.
- שילוב של הגישות הקודמות.
ארגון מחדש של תהליכי הפריסה והתפעול יכול להיות מורכב ולדרוש מאמץ רב. אם תנסו לבצע את המשימות האלה כחלק מהעברת עומס העבודה, העברת עומס העבודה עלולה להיות מורכבת יותר, ואתם עלולים להיחשף לסיכונים. אחרי שתעריכו את תהליכי הפריסה והתפעול, סביר להניח שתבינו את העיצוב והמורכבות שלהם. אם אתם מעריכים שנדרש מאמץ משמעותי כדי לבצע ארגון הקוד מחדש (Refactoring) של תהליכי ה-Deployment (פריסה) והתפעול, מומלץ לשקול לבצע ארגון הקוד מחדש (Refactoring) של התהליכים האלה כחלק מפרויקט נפרד וייעודי.
למידע נוסף על תכנון והטמעה של תהליכי פריסה ב- Google Cloud:
- העברה אל Google Cloud: פריסת עומסי העבודה
- העברה אל Google Cloud: מעבר מפריסות ידניות לפריסות אוטומטיות מבוססות קונטיינרים
המאמר הזה מתמקד בתהליכי הפריסה שמייצרים את הארטיפקטים לפריסה, ופורסים אותם בסביבת זמן הריצה של היעד. אסטרטגיית ארגון הקוד מחדש (Refactoring) תלויה מאוד במורכבות של התהליכים האלה. הרשימה הבאה מתארת אסטרטגיית ארגון הקוד מחדש (Refactoring) כללית ואפשרית:
- הקצאת מאגרי פריטי מידע שנוצרו בתהליך פיתוח (Artifact) ב- Google Cloud. לדוגמה, אפשר להשתמש ב-Artifact Registry כדי לאחסן פריטי מידע שנוצרו בתהליך פיתוח (artifacts) ויחסי תלות בגרסת build.
- מבצעים רפקטורינג בתהליכי ה-build כדי לאחסן את הארטיפקטים גם בסביבת המקור וגם ב-Artifact Registry.
- מבצעים רפקטורינג בתהליכי הפריסה כדי לפרוס את עומסי העבודה בסביבת היעד שלGoogle Cloud . לדוגמה, אפשר להתחיל בפריסה של קבוצת משנה קטנה של עומסי העבודה ב- Google Cloud, באמצעות ארטיפקטים שמאוחסנים ב-Artifact Registry. לאחר מכן, מגדילים בהדרגה את מספר עומסי העבודה שנפרסים ב- Google Cloud, עד שכל עומסי העבודה להעברה יפעלו ב-Google Cloud.
- מבצעים רפקטורינג בתהליכי ה-build כדי לאחסן את הארטיפקטים רק ב-Artifact Registry.
- במקרה הצורך, מעבירים גרסאות קודמות של הארטיפקטים כדי לפרוס ממאגרי המידע בסביבת המקור אל Artifact Registry. לדוגמה, כדי להעביר תמונות של קונטיינרים אל Artifact Registry, אפשר להשתמש בכלים כמו gcrane או Rackware SWIFT.
- להוציא משימוש את המאגרים בסביבת המקור כשאין בהם יותר צורך.
כדי לאפשר ביצוע חזרה לגרסה קודמת במקרה של בעיות בלתי צפויות במהלך המעבר, אתם יכולים לאחסן קובצי אימג' בקונטיינרים במאגרי הארטיפקטים הנוכחיים שלכם ב- Google Cloud בזמן שהמעבר ל- Google Cloud מתבצע. לבסוף, במסגרת הוצאת סביבת המקור משימוש, תוכלו לארגן מחדש את תהליכי ה-build של קובץ האימג' של קונטיינר כדי לאחסן ארטיפקטים ב-Google Cloud בלבד.
יכול להיות שתצטרכו להעביר את הגרסאות הקודמות של הארטיפקטים מסביבת המקור למאגרי הארטיפקטים ב- Google Cloud, למרות שזה לא חיוני להצלחת ההעברה. לדוגמה, כדי לתמוך בהחזרת עומסי העבודה לנקודות זמן שרירותיות, יכול להיות שתצטרכו להעביר גרסאות קודמות של פריטי המידע שנוצרו בתהליך הפיתוח אל Artifact Registry. מידע נוסף זמין במאמר בנושא העברת תמונות ממאגר של צד שלישי.
אם אתם משתמשים ב-Artifact Registry כדי לאחסן את הארטיפקטים, מומלץ להגדיר אמצעי בקרה שיעזרו לכם לאבטח את מאגרי הארטיפקטים, כמו בקרת גישה, מניעת זליגת נתונים, בדיקת נקודות חולשה ו-Binary Authorization. מידע נוסף זמין במאמר בנושא שליטה בגישה והגנה על ארטיפקטים.
אופטימיזציה של Google Cloud הסביבה
אופטימיזציה היא השלב האחרון בהעברה. בשלב הזה, חוזרים על משימות האופטימיזציה עד שסביבת היעד עומדת בדרישות האופטימיזציה. השלבים של כל איטרציה הם:
- הערכה של הסביבה הנוכחית, הצוותים ולולאת האופטימיזציה.
- מגדירים את הדרישות והמטרות של האופטימיזציה.
- מבצעים אופטימיזציה של הסביבה ושל הצוותים.
- שיפור של לולאת האופטימיזציה.
חוזרים על הרצף הזה עד שמשיגים את יעדי האופטימיזציה.
מידע נוסף על אופטימיזציה של סביבת Google Cloud זמין במאמרים מעבר אל Google Cloud: אופטימיזציה של הסביבה וGoogle Cloud Well-Architected Framework: אופטימיזציה של ביצועים.
המאמרים הבאים
- מידע נוסף על תהליכי העברה אחרים מ-AWS Google Cloud
- השוואה בין השירותים של AWS ו-Azure ל-Google Cloud Google Cloud
- מתי כדאי לפנות לקבלת עזרה בנוגע להעברות
- לדוגמאות נוספות של ארכיטקטורות, תרשימים ושיטות מומלצות, עיינו במאמר Cloud Architecture Center.
שותפים ביצירת התוכן
מחבר: Marco Ferrari | Cloud Solutions Architect