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 ומכלי ה-CLI של לקוח הגילוי של Migration Center, כדאי לשים לב לנקודות הנתונים הבאות לגבי כל מופע של Amazon EC2 שרוצים להעביר:
- האזור והתחום שבהם מתבצעת הפריסה.
- סוג וגודל המופע.
- קובץ ה-Amazon Machine Image (AMI) שממנו המופע מופעל.
- שם המארח של המופע, ואיך מופעים ועומסי עבודה אחרים משתמשים בשם המארח הזה כדי לתקשר עם המופע.
- תגי המופע, וגם מטא-נתונים ונתוני משתמשים.
- סוג הווירטואליזציה של המופע.
- אפשרות הרכישה של המופע, למשל רכישה על פי דרישה או רכישת Spot.
- איך המופע מאחסן נתונים, למשל באמצעות חנויות מופעים ונפחי Amazon EBS.
- הגדרת השכירות של המכונה.
- אם המופע נמצא בקבוצת מיקומי מודעות ספציפית.
- אם המופע נמצא בקבוצת שינוי גודל אוטומטי ספציפית.
- קבוצות האבטחה שהמופע שייך אליהן.
- כל הגדרה של חומת אש ברשת AWS שכוללת את המכונה.
- האם עומסי העבודה שמופעלים במופע מוגנים על ידי 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 עם דעות מוצקות. הגישה הזו מבוססת על משאבים ב- 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 כחלק מתהליכי הפריסה והתפעול, כפי שמוסבר בהמשך המאמר הזה.
העברת דיסקים של מכונות וירטואליות לדיסק אחסון מתמיד
אפשר גם להשתמש ב-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 כדי לחלק את תעבורת הרשת ולשפר את יכולת ההתאמה של עומסי העבודה ב- 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במקום לפרוס אותם בסביבת המקור.
בשלב ההערכה בתהליך הזה, אספתם מידע על התהליכים האלה.
סוג השינוי שצריך לבצע בתהליכים האלה תלוי באופן שבו תכננתם והטמעתם אותם. השינוי תלוי גם במצב הסופי שרוצים להגיע אליו בכל תהליך. לדוגמה:
- יכול להיות שהטמעתם את התהליכים האלה בסביבת המקור, ואתם מתכוונים לעצב ולהטמיע תהליכים דומים ב- Google Cloud. לדוגמה, אפשר לשנות את התהליכים האלה כך שישתמשו ב-Cloud Build, ב-Cloud Deploy וב-Infrastructure Manager.
- יכול להיות שהטמעתם את התהליכים האלה בסביבה אחרת של צד שלישי, מחוץ לסביבת המקור. במקרה כזה, צריך לשנות את התהליכים האלה כך שיפעלו בסביבת Google Cloud היעד ולא בסביבת המקור.
- שילוב של הגישות הקודמות.
שינוי תהליכי הפריסה והתפעול יכול להיות מורכב ולדרוש מאמץ רב. אם תנסו לבצע את המשימות האלה כחלק מהעברת עומס העבודה, העברת עומס העבודה עלולה להיות מורכבת יותר, והיא עלולה לחשוף אתכם לסיכונים. אחרי שתעריכו את תהליכי הפריסה והתפעול, סביר להניח שתבינו את העיצוב והמורכבות שלהם. אם אתם מעריכים שנדרש מאמץ משמעותי כדי לבצע רפקטורינג של תהליכי הפריסה והתפעול, מומלץ לבצע רפקטורינג של התהליכים האלה כחלק מפרויקט נפרד ייעודי.
למידע נוסף על תכנון והטמעה של תהליכי פריסה ב- Google Cloud:
- העברה אל Google Cloud: פריסת עומסי העבודה
- העברה אל Google Cloud: מעבר מפריסות ידניות לפריסות אוטומטיות שמבוססות על קונטיינרים
המאמר הזה מתמקד בתהליכי הפריסה שמייצרים את הארטיפקטים לפריסה, ופורסים אותם בסביבת זמן הריצה של היעד. אסטרטגיית הרפקטורינג תלויה מאוד במורכבות של התהליכים האלה. הרשימה הבאה מתארת אסטרטגיית רפקטורינג כללית ואפשרית:
- הקצאת מאגרי פריטי מידע שנוצרו בתהליך פיתוח (Artifact) ב- Google Cloud. לדוגמה, אפשר להשתמש ב-Artifact Registry כדי לאחסן פריטי מידע שנוצרו בתהליך פיתוח (artifacts) ויחסי תלות בגרסת build.
- מבצעים רפקטורינג בתהליכי ה-build כדי לאחסן את הארטיפקטים גם בסביבת המקור וגם ב-Artifact Registry.
- מבצעים רפקטורינג בתהליכי הפריסה כדי לפרוס את עומסי העבודה בסביבת היעד שלGoogle Cloud . לדוגמה, אפשר להתחיל בפריסה של קבוצת משנה קטנה של עומסי העבודה ב- Google Cloud, באמצעות ארטיפקטים שמאוחסנים ב-Artifact Registry. לאחר מכן, מגדילים בהדרגה את מספר עומסי העבודה שנפרסים ב- Google Cloud, עד שכל עומסי העבודה להעברה יפעלו ב- 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 כדי לאחסן את הארטיפקטים, מומלץ להגדיר אמצעי בקרה שיעזרו לכם לאבטח את מאגרי הארטיפקטים, כמו בקרת גישה, מניעת גניבת נתונים, סריקת פגיעויות ואישור בינארי. מידע נוסף זמין במאמר בנושא שליטה בגישה והגנה על ארטיפקטים.
אופטימיזציה של Google Cloud הסביבה
אופטימיזציה היא השלב האחרון בהעברה. בשלב הזה, חוזרים על משימות האופטימיזציה עד שהסביבה המטורגטת עומדת בדרישות האופטימיזציה. השלבים של כל איטרציה הם:
- הערכה של הסביבה הנוכחית, הצוותים ולולאת האופטימיזציה.
- מגדירים את דרישות האופטימיזציה ואת המטרות.
- מבצעים אופטימיזציה של הסביבה ושל הצוותים.
- כוונון של לולאת האופטימיזציה.
חוזרים על הרצף הזה עד שמשיגים את יעדי האופטימיזציה.
מידע נוסף על אופטימיזציה של סביבת Google Cloud זמין במאמרים מעבר אל Google Cloud: אופטימיזציה של הסביבה וGoogle Cloud מסגרת Well-Architected: אופטימיזציה של ביצועים.
המאמרים הבאים
- מידע נוסף על תהליכי העברה אחרים מ-AWS Google Cloud
- השוואה בין השירותים של AWS ו-Azure ל- Google Cloud
- איפה אפשר לקבל עזרה בתהליך ההעברה?
- מומלץ להשתתף בקורס ההדרכה של Google Skills בנושא מעבר אל Google Cloud.
- לדוגמאות נוספות של ארכיטקטורות, תרשימים ושיטות מומלצות, עיינו במאמר Cloud Architecture Center.
שותפים ביצירת התוכן
מחבר: Marco Ferrari | Cloud Solutions Architect