פריסת אפליקציות ‎ .NET ב-Google Cloud

Last reviewed 2022-01-19 UTC

בדף הזה מוסבר איך אפשר לפרוס אפליקציות של ‎ .NET ב-Google Cloud , ומוצגות הנחיות לבחירת שיטת הפריסה המתאימה לאפליקציה.

מבוא

מסגרת Microsoft .NET מספקת קבוצה עשירה של כלים וספריות לפיתוח אפליקציות. עם הופעת התמיכה ב-Docker ב-Windows והאפשרות להריץ אפליקציות ‎ .NET ב-Linux, אפליקציות ‎.NET יכולות לתמוך עכשיו גם במגוון יעדי פריסה.

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

אין דרך אחת שהיא הכי טובה לפריסת אפליקציית ‎ .NET ב- Google Cloud. האפשרויות הכי טובות לפריסה תלויות באפליקציה ובדרישות שלכם. לדוגמה, אם האפליקציה דורשת את .NET Framework המלא או צריכה לפעול ב-IIS, הפריסה תתבסס על Windows. מצד שני, אם האפליקציה שלכם יכולה לפעול עם הפונקציונליות שנתמכת על ידי ‎ .NET, יש לכם אפשרות לפרוס אותה ב-Linux.

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

מודלים של פריסה

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

פריסות מבוססות-Push

בפריסה מבוססת-push, ארטיפקט הפריסה – קובץ ZIP, חבילת NuGet או ארטיפקט אחר – זמין בהתחלה רק לשרת פריסה. שרת הפריסה יכול להיות מכונה ייעודית או תפקיד שמערכת ה-CI מקבלת.

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

התרשים הבא מדגים את התהליך הזה.

פריסות מבוססות-Push

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

ב-Windows, כלים נפוצים לשימוש במודל הפריסה הזה כוללים:

דוגמאות לכלים פופולריים בקוד פתוח: ‫Ansible, ‫Chef Infra, ו-Puppet. הכלים האלה מיועדים בעיקר ל-Linux, אבל הם יכולים גם לפרוס יעדים של Windows.

אבטחה

כדי ששרת הפריסה ידחוף פריסה לשרת אפליקציות, צריך להיות זמין ערוץ אחורי. לדוגמה, Web Deploy ו-Octopus Deploy משתמשים בפרוטוקול וביציאה מותאמים אישית למשימה הזו, ואילו Ansible משתמש ב-SSH.

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

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

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

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

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

עדכונים של מערכת ההפעלה

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

אפשר גם להשתמש בגישת דחיפה לעדכוני מערכת הפעלה, שבה שרת הפריסה מפעיל עדכון של מערכת ההפעלה בשרתי האפליקציה. ב-Linux, נהוג להשתמש ב-SSH כדי להריץ מרחוק פקודות עדכון. ב-Windows,‏ PowerShell remoting (שמסתמך על WinRM) היא בחירה נפוצה. בשני המנגנונים, אתם צריכים להיות מסוגלים לבצע אימות מאובטח ולאחסן פרטי כניסה בצורה מאובטחת.

התאמה אוטומטית לעומס (Automatic scaling)

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

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

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

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

שינוי אוטומטי של קנה מידה באמצעות פריסות מבוססות-דחיפה

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

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

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

הפריסה מבוססת-הדחיפה היא אינטואיטיבית, אבל היא עלולה להיות מורכבת מאוד כשמביאים בחשבון את האבטחה, עדכוני מערכת ההפעלה וההתאמה האוטומטית לעומס. בקטע הבא נדון בפריסות מבוססות-משיכה, שהן הדרך ה<private unicode area>מבוססת-ענן<private unicode area> יותר לגישה לפריסות.

פריסות מבוססות-משיכה

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

פריסות מבוססות-משיכה

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

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

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

אבטחה

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

  • תמונת VM.
  • קובץ אימג' של Docker לפריסה ב-Google Kubernetes Engine.
  • חבילה לפריסה ב-App Engine.

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

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

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

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

עדכונים של מערכת ההפעלה

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

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

התאמה אוטומטית לעומס (Automatic scaling)

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

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

יעדי פריסה

בעבר, אפליקציות .NET פעלו רק ב-Windows, ו-Windows לא תמך במאגרי מידע. כך לא הייתה לכם הרבה ברירה לגבי הסביבה שבה האפליקציה תפעל.

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

מערכת הפעלה

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

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

לכן, שאלה בסיסית כשבוחרים מודל פריסה ויעד היא אם להשתמש ב-Linux (שדורש .NET) או ב-Windows (שתומך ב-.NET או ב-‎ .NET Framework).

היתרונות הפוטנציאליים של הפעלת אפליקציות ‎ .NET ב-Linux כוללים את היתרונות הבאים:

  • אתם יכולים להשתמש בסביבה גמישה של App Engine, שהיא סביבה מנוהלת.
  • אפשר להשתמש ב-GKE, סביבה מנוהלת שתומכת בארגון קונטיינרים.
  • כדי להימנע מהעלות הנוספת של תמונות פרימיום של Compute Engine שמשויכות לרישוי של Windows.

חשוב לשקול את היתרונות האלה מול החסרונות הפוטנציאליים הבאים של שימוש ב-‎ .NET ב-Linux:

  • יכול להיות שהמאמץ שנדרש להעברת אפליקציית .NET Framework קיימת ל-‎ .NET יקזז את החיסכון הפוטנציאלי בעלויות. או כמו שצוין, יכול להיות שאי אפשר להעביר אפליקציה קיימת של ‎ .NET Framework אל ‎ .NET.
  • ‫Linux לא תומך ב-IIS. Kestrel, שרת האינטרנט של ‎ .NET, מציג ביצועים טובים מאוד, אבל הוא לא מציע את אותה קבוצת תכונות כמו IIS. לכן, יכול להיות שתצטרכו להשתמש ב-Kestrel בשילוב עם שרת אינטרנט כמו Nginx.
  • אין מקבילה ישירה לשירות Windows ב-Linux. למרות שבדרך כלל אפשר להמיר שירותי Windows לאפליקציות קונסולה של Linux שיכולות לפעול כדמון, ההמרה הזו לא תמיד פשוטה.
  • פתרון בעיות וניפוי באגים באפליקציות .NET ב-Linux דורש כלים ומיומנויות שונים מאלה שנדרשים כשמשתמשים ב-NET ב-Windows. זה יכול להיות מאתגר אם לצוות שלכם יש ניסיון מוגבל ב-Linux.

קונטיינרים

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

  • שירותי Windows
  • אפליקציות מסוף של Linux שפועלות כדמונים
  • שירותי WCF באירוח עצמי
  • אפליקציות ASP.NET MVC או Web API שמתארחות ב-Kestrel

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

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

  • מכניסים את IIS, עם כל המאגרים והספריות הווירטואליות, לקובץ אימג' יחיד של Docker מבוסס-Windows באמצעות קובץ האימג' microsoft/iis כבסיס. אלא אם האפליקציות מקושרות זו לזו באופן הדוק, בדרך כלל לא מומלץ להשתמש בגישה הזו, כי היא לא מאפשרת לעדכן ולפרוס את האפליקציות בנפרד.
  • משתמשים בקובצי אימג' נפרדים של Docker מבוססי-Windows לכל אפליקציה, כאשר כל אחד מהם מריץ IIS. כך תוכלו לנהל את האפליקציות באופן עצמאי. עם זאת, ל-IIS יש תקורה לא זניחה שיכולה להיות משמעותית אם צריך להפעיל מספר גדול של קונטיינרים כאלה.
  • מעבירים חלק מהאפליקציות או את כולן מ-IIS אל Kestrel. אפשר לפרוס את Kestrel במאגר מבוסס-Windows או במאגר Docker מבוסס-Linux, ולכן הגישה הזו מאפשרת לכם לנהל מאגרים בנפרד.

‫IIS מאפשר להפעיל כמה אפליקציות אינטרנט באתר אינטרנט אחד, ולשתף שם דומיין אחד. כשאתם אורזים אפליקציות בקונטיינרים נפרדים, אתם יכולים לקבל את אותה הפונקציונליות באמצעות איזון עומסים מבוסס-תוכן. באופן דומה, מאזן עומסים HTTP של Google מייתר את הצורך בפריסת שרת proxy הפוך מותאם אישית לפני שרתי Kestrel.

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

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

לבסוף, אם אתם משתמשים במאגרי Docker מבוססי Windows, שימו לב ש-Google Cloud לא תומך ב-Hyper-V ולא מאפשר לכם להריץ מאגרי Hyper-V. לכן, אפשר לפרוס קונטיינרים של Windows Server רק ב-Google Cloud. קונטיינרים של Windows Server הם קלים יותר מקונטיינרים של Hyper-V ומציעים רמה שונה של בידוד.

מגבלות הפריסה

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

ארכיטקטורת האפליקציה

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

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

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

מצב (state) ואי-תלות במצב (statelessness)

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

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

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

מצב הסשן

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

  • אם כמות הנתונים של הסשן קטנה, אפשר לאחסן את הסטטוס בקובץ Cookie מוצפן או חתום.
  • במקום להשתמש בספק מצב הסשן שמוגדר כברירת מחדל InProc, אפשר להשתמש בספק SQLServer. עם זאת, הפעולה הזו דורשת מופע של SQL Server, שגורר עלויות נוספות ויכול להשפיע על זמן האחזור ועל הזמינות של האפליקציה.
  • אתם יכולים להשתמש בזיקה לסשן ב-Cloud Load Balancing. התכונה הזו מבטיחה שכל הבקשות מלקוח יחיד ינותבו לאותו מופע של האפליקציה. עם זאת, שימוש בזיקה לסשן (session affinity) עלול להשפיע לרעה על ההוגנות של איזון העומסים, כלומר, מקרים מסוימים של אפליקציות עלולים לקבל יותר בקשות מאחרים. בנוסף, אם מופסק מופע של אפליקציה מסיבה כלשהי, כל הסשנים שמטופלים על ידי המופע יאבדו, וזה עלול להשפיע על משתמשי הקצה. לכן, הסתמכות על שיוך סשנים לאפליקציה היא לא פתרון אידיאלי, אבל היא יכולה להיות פשרה טובה בין חוסן לעלות.

מטמון בזיכרון

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

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

אחסון

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

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

שיטות פריסה

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

יצירה מחדש של אסטרטגיה

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

אסטרטגיית כחול-ירוק

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

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

אסטרטגיית פריסה הדרגתית

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

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

אפשרויות פריסה

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

GKE (Windows או Linux)

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

ב-GKE, כל החלקים של האפליקציה צריכים להיות ארוזים כקובצי Docker. קונטיינרים מבוססי Linux מחייבים שימוש ב-‎ .NET ובסביבה מבוססת Linux. יכול להיות שיהיה לכם קשה לבנות קונטיינרים ב-Linux אם מערכת ה-CI שלכם מבוססת על Windows. עם זאת, גם Azure Pipelines וגם Team Foundation Server ו-Cloud Build מספקים תמיכה מובנית בבניית אפליקציות ‎ .NET ובבנייה ופרסום של קובצי אימג' של קונטיינרים מבוססי Linux.

‫GKE מציע את הגמישות הגדולה ביותר לאפליקציות שהן stateless. באמצעות קבוצות של StatefulSets ונפחים קבועים, אפשר גם להריץ סוגים מסוימים של אפליקציות Stateful ב-GKE.

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

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

פריסה מבוססת-משיכה באמצעות פקודות kubectl

פריסת אפליקציה ב-GKE מתבצעת בשני שלבים:

  1. פרסום קובצי אימג' של Docker ב-Artifact Registry או במרשם חיצוני של Docker באמצעות docker push או אמצעים אחרים. בדרך כלל, המערכת של CI מטפלת בשלב הזה.
  2. הפעלת הפריסה באמצעות kubectl. אפשר לבצע את השלב הזה באמצעות מערכת ה-CI או בנפרד. מכיוון שהפריסה מופעלת מרחוק, לא משנה אם kubectl מופעל ב-Linux או ב-Windows.

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

פריסה מבוססת-משיכה באמצעות Spinnaker

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

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

‫Knative ו-Cloud Run

עבור קונטיינרים של ‎ .NET בלי שמירת מצב, ‏Knative והגרסה המנוהלת שלו, Cloud Run, מספקים סביבת קונטיינרים בלי שרת (serverless). קונטיינרים בלי שרת מציעים יתרונות כמו הקצאת משאבים, התאמה אוטומטית לעומס ואיזון עומסים בלי תקורה של ניהול התשתית.

כדי לפרוס קונטיינרים באשכול Kubernetes, ‏ Knative מספקת ממשק API ברמה גבוהה יותר וקטן יותר מ-Kubernetes. לכן, Knative יכול לעזור לכם להימנע מהמורכבות של Kubernetes, וכך לפרוס את הקונטיינרים בקלות רבה יותר.

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

‫Knative serving היא גרסה גמישה יותר של Cloud Run שמציעה את הפשטות של Knative ו-Cloud Run עם הגמישות התפעולית של Kubernetes. לדוגמה, ב-Cloud Run ב-GKE Enterprise אפשר להוסיף יחידות GPU למופעים הבסיסיים שמריצים את הקונטיינרים, או להגדיל את מספר הקונטיינרים של האפליקציה.

‫Cloud Run משולב עם שירותים אחרים כמו Pub/Sub,‏ Cloud Scheduler,‏ Cloud Tasks ועם שירותי קצה עורפיים כמו Cloud SQL. אפשר להשתמש בו גם בחזיתות אינטרנט עם שינוי גודל אוטומטי וגם במיקרו-שירותים פנימיים שמופעלים על ידי אירועים.

‫Compute Engine (Windows או Linux)

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

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

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

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

כדי להריץ מופעי מכונות וירטואליות של Windows, צריך להשתמש בתמונות פרימיום. התמונות האלה מכילות עותקים ברישיון של Windows, ולכן הן כרוכות בתשלום נוסף. כתוצאה מכך, מכונות Windows VM בדרך כלל פחות חסכוניות ממכונות VM שמשתמשות בהפצות של Linux כמו CentOS או Debian, שלא כרוכות בתשלום עמלות רישיון.

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

אוטומציה של פריסת אפליקציות ב-Compute Engine כוללת את המשימות הבאות:

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

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

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

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

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

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

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

  • ליצור אימג' בהתאמה אישית של מכונה וירטואלית כחלק מתהליך CI/CD, תהליך שלרוב נקרא image baking. בגישה הזו, משתמשים באחת מתמונות מערכת ההפעלה הציבוריות כדי ליצור מכונה וירטואלית חדשה, מתקינים עליה את האפליקציה העדכנית, יוצרים תמונת מכונה וירטואלית מהמופע ומאפשרים את השימוש בתמונה ב Google Cloud פרויקט. אפשר לבצע את התהליך כולו באופן אוטומטי באמצעות כלי כמו Packer. אחר כך אפשר להפנות לתמונה שנוצרה בתבנית של הגדרות מכונה. התרשים הבא ממחיש את הגישה הזו.

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

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

השימוש בסקריפטים לטעינה בזמן ההפעלה כדי לפרוס את האפליקציה (האפשרות הראשונה) מגיע עם חסרונות ויתרונות הפוכים. היא לא יוצרת תקורה של אפיית תמונות בתהליך CI/CD, אבל היא מאטה את תהליך יצירת מכונות VM. בנוסף, אם סקריפט לטעינה בזמן ההפעלה לא אמין לחלוטין או אם המערכות שמהן קובצי ה-binaries של האפליקציה מורדים לא זמינות מאוד, הגישה הזו עלולה להוביל לזמינות נמוכה יותר.

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

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

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

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

אם אתם משתמשים בקונטיינרים של Windows Server, כדאי לפעול לפי ההנחיות האלה להרצת הקונטיינרים באמצעות Compute Engine וקבוצות של מכונות מנוהלות:

  • אפשר להשתמש בתמונה בהתאמה אישית עם Docker שהותקן מראש, או באחת מהתמונות הציבוריות הבאות:
    • Windows Server 2019 Datacenter Core for Containers
    • Windows Server 2019 Datacenter for Containers
  • משתמשים בסקריפט לטעינה בזמן ההפעלה כדי למשוך את קובץ האימג' של Docker ולהפעיל אותו כקונטיינר של Windows Server במהלך הפעלת ה-VM. אפשר להשתמש במיפויים מתאימים של יציאות כדי לחשוף את השירותים שפועלים בתוך הקונטיינר.

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

כשיוצרים קובצי אימג' מבוססי-Windows בסביבה שאינה בענן, יכול להיות שתסתמכו על Microsoft Deployment Toolkit (MDT) או על Windows Deployment Services (WDS). עם זאת, מכיוון שניהול תמונות ויצירת מכונות וירטואליות על סמך תמונות בהתאמה אישית הם תכונות ליבה של Compute Engine, אין צורך בכלים הנוספים האלה. ‫Compute Engine תומך לא רק בסקריפטים להפעלה, אלא גם בסקריפטים להתאמה אישית של מכונות וירטואליות מבוססות Windows. לכן, בדרך כלל אין צורך לעבוד עם קובצי unattend.xml מותאמים אישית. עם זאת, עדיין חשוב להכליל התקנה של Windows באמצעות GCESysprep לפני שיוצרים תמונה.

פריסה מבוססת-משיכה באמצעות Spinnaker

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

הגישה הבסיסית שבה משתמש Spinnaker כדי לתזמן פריסות ב-Compute Engine דומה לגישה שמתוארת בקטע הקודם – כלומר, היא גם מסתמכת על יצירת קובץ image. לכן, אותם השיקולים חלים גם כאן.

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

פריסה מרחוק מבוססת-דחיפה

לאפשרויות הפריסה מבוססות-השליפה שדיברנו עליהן בקטעים הקודמים יש מגוון יתרונות. אבל הן לא מתאימות לכל סוג של אפליקציה. בפרט, אפליקציות עם מצב (stateful) לא מתאימות לגישה הזו, ועדיף להשתמש בהן בגישה מבוססת-push.

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

אפשר להקצות מכונות וירטואליות של שרת האפליקציות באותו אופן כמו הקצאה של תשתית אחרת, באמצעות כלי אוטומציה כמו Terraform. אתם יכולים להשתמש בסקריפטים של הפעלה או התמחות כדי להתקין את הכלים שנדרשים לאוטומציה של פריסת האפליקציה. לדוגמה, אם אתם משתמשים ב-Puppet, ב-Chef או ב-Octopus Deploy, אתם צריכים לוודא שתוכנת הסוכן של הכלים האלה מותקנת.

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

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

בחירת אפשרות פריסה

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

לפריסת אפליקציות ‎ .NET ב-Linux:

עץ החלטות לפריסה באמצעות ‎ .NET ו-Linux

כדי לפרוס אפליקציית ‎ .NET או ‎ .NET Framework ב-Windows:

עץ החלטות לפריסה באמצעות Windows

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