מעבר אל Google Cloud: מעבר מפריסות ידניות לפריסות אוטומטיות מבוססות-קונטיינרים

Last reviewed 2024-12-08 UTC

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

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

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

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

  • אתם פורסים את עומסי העבודה באופן ידני.
  • אתם פורסים את עומסי העבודה באמצעות כלים לניהול תצורה (CM).

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

  1. פריסה באמצעות כלים לניהול קונטיינרים.
  2. פריסה אוטומטית.

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

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

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

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

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

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

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

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

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

מעבר לכלים לתזמור קונטיינרים

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

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

הערכה וגילוי של עומסי העבודה

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

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

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

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

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

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

תכנון ובניית בסיס

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

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

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

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

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

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

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

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

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

פריסת הארטיפקטים באמצעות כלים לניהול קונטיינרים

בהתבסס על הדרישות שאספתם בשלב ההערכה ובשלב הבסיס של השלב הזה, מבצעים את הפעולות הבאות:

  • העברת עומסי עבודה לקונטיינרים.
  • הטמיעו תהליכי פריסה לטיפול בעומסי העבודה בקונטיינרים.

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

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

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

  1. יוצרים את התמונה.
  2. מריצים את חבילת מקרים לבדיקה.
  3. אחסון התמונה במאגר.

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

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

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

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

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

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

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

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

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

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

אלה הדרישות של איטרציית האופטימיזציה הזו:

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

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

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

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

מעבר לאוטומציה של פריסה

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

הערכה וגילוי של עומסי העבודה

בהמשך להערכה הקודמת, עכשיו אפשר להתמקד בדרישות של תהליכי הפריסה:

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

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

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

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

תכנון ובניית בסיס

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

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

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

פריסת הארטיפקטים באמצעות תהליכים אוטומטיים לחלוטין

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

אתם יכולים להשתמש בכלים כמו Cloud Deploy כדי להטמיע את תהליכי הפריסה האוטומטיים שלכם, בהתאם לדרישות שאספתם בשלב ההערכה של שלב ההעברה הזה.

לכל ארטיפקט, כל תהליך פריסה צריך לבצע את המשימות הבאות:

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

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

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

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

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

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

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

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

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

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

מחבר: Marco Ferrari | Cloud Solutions Architect