במאמר הזה נסביר איך לארח אתר ב- Google Cloud. Google Cloud מספקת פלטפורמה חזקה, גמישה, אמינה וניתנת להרחבה לאירוח אתרים. Google בנוי Google Cloud באמצעות אותה תשתית שבה Google משתמשת כדי להציג תוכן מאתרים כמו Google.com, YouTube ו-Gmail. אתם יכולים לארח את התוכן של האתר שלכם באמצעות סוג ותכנון של תשתית שמתאימים לצרכים שלכם בצורה הטובה ביותר.
המאמר הזה יכול לעזור לכם אם אתם:
- יש לכם ידע לגבי יצירת אתר, ופרסתם והפעלתם בעבר תשתית לאירוח אתרים.
- הערכה אם ואיך להעביר את האתר אל Google Cloud.
אם אתם רוצים ליצור אתר פשוט, כדאי להשתמש ב-Google Sites, כלי ליצירת דפי אינטרנט ו-Wiki מובנים. מידע נוסף זמין בעזרה בנושא Sites.
בחירת אפשרות
אם אתם חדשים בשימוש ב- Google Cloud, כדאי להתחיל להשתמש בסוג הטכנולוגיה שאתם כבר מכירים. לדוגמה, אם אתם משתמשים כרגע בשרתים פיזיים או במכונות וירטואליות (VM) כדי לארח את האתר שלכם, אולי אצל ספק ענן אחר או בחומרה שלכם, Compute Engine מספק לכם פרדיגמה מוכרת. אם אתם מעדיפים מחשוב בלי שרת (serverless computing), כנראה ש-Cloud Run היא אפשרות טובה בשבילכם.
אחרי שתכירו טוב יותר את Google Cloud, תוכלו לגלות את מגוון המוצרים והשירותים ש Google Cloud מציעה. לדוגמה, אם התחלתם להשתמש ב-Compute Engine, יכול להיות שתשפרו את היכולות של האתר באמצעות Google Kubernetes Engine (GKE) או תעבירו חלק מהפונקציונליות או את כולה אל Cloud Run.
בטבלה הבאה מפורטות אפשרויות האירוח ב- Google Cloud:
| אפשרות | מוצר | אחסון הנתונים | איזון עומסים | מדרגיות | רישום ביומן ומעקב |
|---|---|---|---|---|---|
| אתר סטטי | Cloud Storage אירוח ב-Firebase |
קטגוריה של Cloud Storage | HTTP(S) אופציונלי |
אוטומטית | |
| מכונות וירטואליות | Compute Engine | Cloud SQL, Cloud Storage, Firestore ו-Bigtable, או שתוכלו להשתמש בספק שירותי אחסון חיצוני אחר. דיסקים לאחסון מתמיד שמבוססים על דיסקים קשיחים, שנקראים standard persistent disks, ודיסקים לאחסון מתמיד (SSD) שמבוססים על כונני SSD. |
HTTP(S) שרת proxy ל-TCP שרת proxy ל-SSL סיום IPv6 רשת בין אזורים פנימי |
באופן אוטומטי באמצעות קבוצות של מופעי מכונה מנוהלים | |
| קונטיינרים | GKE | דומה ל-Compute Engine אבל יש אינטראקציה שונה עם דיסקים לאחסון מתמיד |
רשת HTTP(S) |
התאמה אוטומטית לעומס (autoscaling) באשכול | |
| Serverless | Cloud Run |
Google Cloud שירותים כמו Cloud SQL, Firestore, Cloud Storage ומסדי נתונים נגישים של צד שלישי | HTTP(S) מנוהל על ידי Google |
מנוהל על ידי Google |
במאמר הזה נסביר על הטכנולוגיות העיקריות שבהן אפשר להשתמש לאירוח אתרים ב- Google Cloud , ונספק סקירה כללית על אופן הפעולה של הטכנולוגיות. במאמר יש קישורים למסמכים מלאים, למדריכים ולמאמרים עם פתרונות שיעזרו לכם להבין את הנושא לעומק, כשתהיו מוכנים.
הסבר על העלויות
יש כל כך הרבה משתנים וכל הטמעה שונה, ולכן לא ניתן לספק במאמר הזה עצות ספציפיות לגבי עלויות. כדי להבין את העקרונות של Google לגבי אופן התמחור ב- Google Cloud, אפשר לעיין בדף התמחור. כדי להבין את המחירים של שירותים ספציפיים, אפשר לעיין בקטע בנושא תמחור מוצרים. אפשר גם להשתמש במחשבון התמחור כדי להעריך את השימוש שלכם ב- Google Cloud . אתם יכולים לספק פרטים על השירותים שבהם אתם רוצים להשתמש ואז לראות הערכת מחיר.
הגדרת שירותי שמות דומיין
בדרך כלל, כדאי לרשום שם דומיין לאתר. אתם יכולים להשתמש ברשם שמות דומיין ציבורי כדי לרשום שם ייחודי לאתר שלכם. אם אתם רוצים שליטה מלאה במערכת שמות הדומיין (DNS) שלכם, אתם יכולים להשתמש ב-Cloud DNS כספק ה-DNS שלכם. במסמכי Cloud DNS יש מדריך למתחילים שיעזור לכם להתחיל.
אם יש לכם ספק DNS קיים שאתם רוצים להשתמש בו, בדרך כלל תצטרכו ליצור אצל הספק הזה כמה רשומות. לשם דומיין כמו example.com, יוצרים רשומת A אצל ספק ה-DNS. עבור תת-הדומיין www.example.com, יוצרים רשומת CNAME עבור www כדי להפנות אותה לדומיין example.com. רשומת A ממפה שם מארח לכתובת IP.
רשומת CNAME יוצרת כינוי לרשומת A.
אם רשם שמות הדומיין הוא גם ספק ה-DNS, כנראה שזה כל מה שצריך לעשות. אם אתם משתמשים בספקים נפרדים לרישום ול-DNS, צריך לוודא שלרשם שמות הדומיין יש את שרתי השמות הנכונים שמשויכים לדומיין.
אחרי שמבצעים את השינויים ב-DNS, יכול לעבור זמן עד שהעדכונים ברשומה יתעדכנו, בהתאם לערכי הזמן לחיים (TTL) באזור. אם זה שם מארח חדש, השינויים נכנסים לתוקף במהירות כי לשרתי ה-DNS אין ערכים קודמים ששמורים במטמון, והם יכולים ליצור קשר עם ספק ה-DNS כדי לקבל את המידע הדרוש לניתוב הבקשות.
אירוח אתר סטטי
הדרך הכי פשוטה להציג תוכן של אתר באמצעות HTTP(S) היא לארח דפי אינטרנט סטטיים. דפי אינטרנט סטטיים מוגשים ללא שינוי, כמו שהם נכתבו, בדרך כלל באמצעות HTML. שימוש באתר סטטי הוא אפשרות טובה אם הדפים באתר משתנים לעיתים רחוקות אחרי שהם מתפרסמים, כמו פוסטים בבלוג או דפים שמהווים חלק מאתר של עסק קטן. אפשר לעשות הרבה דברים עם דפי אינטרנט סטטיים, אבל אם אתם צריכים שהאתר שלכם יאפשר אינטראקציות חזקות עם משתמשים באמצעות קוד בצד השרת, כדאי לשקול את האפשרויות האחרות שמוסברות במאמר הזה.
אירוח אתר סטטי באמצעות Cloud Storage
כדי לארח אתר סטטי ב-Cloud Storage, צריך ליצור קטגוריה של Cloud Storage, להעלות את התוכן ולבדוק את האתר החדש. אתם יכולים להציג את הנתונים ישירות מ-storage.googleapis.com, או לאמת את הבעלות על הדומיין ולהשתמש בשם הדומיין.
אתם יכולים ליצור את דפי האינטרנט הסטטיים איך שאתם רוצים. לדוגמה, אפשר ליצור דפים באופן ידני באמצעות HTML ו-CSS. אפשר להשתמש במחולל אתרים סטטיים, כמו Jekyll, Ghost או Hugo, כדי ליצור את התוכן. מחוללי אתרים סטטיים מאפשרים ליצור אתר סטטי באמצעות כתיבה ב-markdown, וכוללים תבניות וכלים. מחוללי אתרים בדרך כלל מספקים שרת אינטרנט מקומי שבו אפשר להשתמש כדי לראות תצוגה מקדימה של התוכן.
אחרי שהאתר הסטטי פועל, אפשר לעדכן את הדפים הסטטיים בכל תהליך שרוצים. התהליך הזה יכול להיות פשוט כמו העתקה ידנית של דף מעודכן ל-bucket. אפשר גם להשתמש בגישה אוטומטית יותר, למשל לאחסן את התוכן ב-GitHub ואז להשתמש ב-webhook כדי להריץ סקריפט שמעדכן את ה-bucket. מערכת מתקדמת יותר עשויה להשתמש בכלי לאינטגרציה רציפה (CI) ולפיתוח רציף (CD), כמו Jenkins, כדי לעדכן את התוכן בדלי. ל-Jenkins יש תוסף Cloud Storage שמספק שלב Google Cloud Storage Uploader אחרי יצירת גרסת ה-build לפרסום ארטיפקטים של גרסת ה-build ב-Cloud Storage.
אם יש לכם אפליקציית אינטרנט שצריכה להציג תוכן סטטי או מדיה סטטית שהמשתמשים העלו, שימוש ב-Cloud Storage יכול להיות דרך חסכונית ויעילה לאירוח ולהצגה של התוכן הזה, תוך צמצום מספר הבקשות הדינמיות לאפליקציית האינטרנט.
בנוסף, Cloud Storage יכול לקבל ישירות תוכן שנשלח על ידי משתמשים. התכונה הזו מאפשרת למשתמשים להעלות קובצי מדיה גדולים ישירות ובאופן מאובטח, בלי להשתמש בשרתים שלכם כשרתי proxy.
כדי להשיג את הביצועים הטובים ביותר מהאתר הסטטי, כדאי לעיין בשיטות המומלצות לשימוש ב-Cloud Storage.
מידע נוסף זמין בדפים הבאים:
- אירוח אתר סטטי
- J is for Jenkins (פוסט בבלוג)
- Band Aid 30 on Google Cloud (פוסט בבלוג)
- מאמרי העזרה של Cloud Storage
אירוח אתר סטטי באמצעות אירוח ב-Firebase
אירוח ב-Firebase מספק אירוח סטטי מהיר ומאובטח לאפליקציית האינטרנט שלכם. באמצעות אירוח ב-Firebase, אתם יכולים לפרוס אפליקציות אינטרנט ותוכן סטטי לרשת גלובלית להעברת תוכן (CDN) באמצעות פקודה אחת.
אלה כמה יתרונות של שימוש ב-Firebase Hosting:
- אישורי SSL ללא הגדרה מובנים באירוח ב-Firebase. מקצה אישורי SSL בדומיינים מותאמים אישית בחינם.
- כל התוכן מוצג באמצעות HTTPS.
- התוכן שלכם מועבר למשתמשים מנקודות קצה של רשתות CDN ברחבי העולם.
- בעזרת Firebase CLI, תוכלו להפעיל את האפליקציה תוך שניות. משתמשים בכלים של שורת הפקודה כדי להוסיף יעדי פריסה לתהליך build.
- אתם מקבלים תכונות לניהול גרסאות, כמו פריסה אטומית של נכסים חדשים, ניהול גרסאות מלא והחזרה לגרסה קודמת בלחיצה אחת.
- האירוח מציע הגדרה שימושית לאפליקציות של דף יחיד ולאתרים אחרים שדומים יותר לאפליקציות.
- האירוח נועד לשימוש חלק עם תכונות אחרות של Firebase.
מידע נוסף זמין בדפים הבאים:
שימוש במכונות וירטואליות עם Compute Engine
לתרחישי שימוש בתשתית כשירות (IaaS), Google Cloud מסופק Compute Engine. Compute Engine מספק תשתית מחשוב חזקה, אבל אתם צריכים לבחור ולהגדיר את רכיבי הפלטפורמה שבהם אתם רוצים להשתמש. ב-Compute Engine, אתם אחראים להגדיר את המערכות, לנהל אותן ולעקוב אחריהן. Google מוודאת שהמשאבים זמינים, אמינים ומוכנים לשימוש, אבל אתם צריכים להקצות אותם ולנהל אותם. היתרון כאן הוא שיש לכם שליטה מלאה במערכות וגמישות ללא הגבלה.
אתם יכולים להשתמש ב-Compute Engine כדי לעצב ולפרוס כמעט כל מערכת לאירוח אתרים שתרצו. אתם יכולים להשתמש במכונות וירטואליות, שנקראות מופעים, כדי לבנות את האפליקציה שלכם, בדומה למה שהייתם עושים אם הייתה לכם תשתית חומרה משלכם. ב-Compute Engine יש מגוון סוגי מכונות שאפשר להתאים אישית את ההגדרה שלהן בהתאם לצרכים ולתקציב שלכם. אתם יכולים לבחור את מערכות ההפעלה, חבילות הפיתוח, השפות, המסגרות, השירותים וטכנולוגיות תוכנה אחרות שאתם מעדיפים.
הגדרה אוטומטית באמצעות Google Cloud Marketplace
הדרך הקלה ביותר לפרוס חבילה מלאה של אירוח אתרים היא באמצעות Google Cloud Marketplace. בכמה לחיצות, תוכלו לפרוס כל אחד מתוך יותר מ-100 פתרונות מלאים באמצעות Google Click to Deploy או Bitnami.
לדוגמה, אפשר להגדיר חבילת LAMP או WordPress באמצעות Cloud Marketplace. המערכת פורסת מחסנית תוכנה מלאה ופעילה תוך כמה דקות בלבד במופע יחיד. לפני הפריסה, ב-Cloud Marketplace מוצגות הערכות עלויות להפעלת האתר, מידע ברור על הגרסאות של רכיבי התוכנה שמותקנים בשבילכם, ואפשרות להתאים אישית את ההגדרה על ידי שינוי שמות של מופעי רכיבים, בחירת סוג המכונה ובחירת גודל הדיסק. אחרי הפריסה, יש לכם שליטה מלאה במכונות Compute Engine, בהגדרות שלהן ובתוכנה.
הגדרה ידנית
אפשר גם ליצור את התשתית ב-Compute Engine באופן ידני, או לבנות את ההגדרה מאפס או על בסיס פריסה של Google Cloud Marketplace. לדוגמה, יכול להיות שתרצו להשתמש בגרסה של רכיב תוכנה שלא מוצע ב-Cloud Marketplace, או שאולי אתם מעדיפים להתקין ולהגדיר הכול בעצמכם.
המאמר הזה לא כולל מסגרת מלאה ושיטות מומלצות להגדרת אתר. אבל אם מסתכלים על זה ברמה גבוהה, כדי להגדיר תשתית לאירוח אתרים ב-Compute Engine צריך:
- הסבר על הדרישות אם אתם בונים אתר חדש, חשוב שתבינו את הרכיבים שאתם צריכים, כמו מופעים, צורכי אחסון ותשתית רשת. אם אתם מעבירים את האפליקציה מפתרון קיים, סביר להניח שאתם כבר מבינים את הדרישות האלה, אבל אתם צריכים לחשוב איך ההגדרה הקיימת שלכם ממופה לשירותיGoogle Cloud .
- תכנון העיצוב. כדאי לחשוב על הארכיטקטורה ולכתוב את העיצוב. כדאי להיות כמה שיותר מפורטים.
- יוצרים את הרכיבים. הרכיבים שאתם בדרך כלל חושבים עליהם כנכסים פיזיים, כמו מחשבים ומתגי רשת, מסופקים דרך שירותים ב-Compute Engine. לדוגמה, אם רוצים מחשב, צריך ליצור מכונה של Compute Engine. אם רוצים כונן קשיח של אחסון מתמיד (persistent disk), יוצרים גם אותו. כלים של תשתית כקוד, כמו Terraform, הופכים את התהליך הזה לפשוט וניתן לחזרה.
- הגדרה והתאמה אישית. אחרי שבוחרים את הרכיבים הרצויים, צריך להגדיר אותם, להתקין ולהגדיר תוכנה, ולכתוב ולפרוס קוד התאמה אישית שנדרש. אפשר לשכפל את ההגדרה על ידי הפעלת סקריפטים של מעטפת, וכך לזרז את הפריסות העתידיות. גם כאן Terraform יכול לעזור, כי הוא מספק תבניות הצהרה גמישות להגדרות לפריסה אוטומטית של משאבים. אפשר גם להשתמש בכלים לאוטומציה של IT, כמו Puppet ו-Chef.
- פורסים את הנכסים. כנראה שיש לכם דפי אינטרנט ותמונות.
- בדיקה. מוודאים שהכול פועל כמו שרוצים.
- פריסה בסביבת הייצור. פותחים את האתר לשימוש ולצפייה של אנשים בכל העולם.
אחסון נתונים באמצעות Compute Engine
רוב האתרים צריכים נפח אחסון כלשהו. יכול להיות שתצטרכו נפח אחסון מסיבות שונות, למשל כדי לשמור קבצים שהמשתמשים מעלים, וכמובן את הנכסים שבהם האתר משתמש.
Google Cloud מספקת מגוון שירותי אחסון מנוהלים, כולל:
- מסד נתונים של SQL ב-Cloud SQL, שהוא שירות מנוהל של מסד נתונים רלציוני ל-MySQL, PostgreSQL ו-SQL Server.
- אפשרויות לאחסון נתוני NoSQL: Firestore ו-Bigtable.
- שירותים מנוהלים במלואם של מאגרי נתונים בזיכרון:
- אחסון אובייקטים עקבי, ניתן להרחבה ובעל קיבולת גדולה ב-Cloud Storage.
Cloud Storage מגיע בכמה סוגים:
- המהדורה Standard מספקת זמינות מקסימלית.
- Nearline היא אפשרות בעלות נמוכה שמתאימה לנתונים שניגשים אליהם פחות מפעם בחודש.
- Coldline היא אפשרות בעלות נמוכה שמתאימה לנתונים שניגשים אליהם בתדירות נמוכה יותר מפעם ברבעון.
- Archive מספק את האפשרות הכי זולה לארכיון, לגיבוי ולתוכנית התאוששות מאסון (DR).
- דיסקים לאחסון מתמיד ב-Compute Engine לשימוש כאחסון הראשי של המכונות. Compute Engine מציע גם דיסקים לאחסון מתמיד שמבוססים על דיסקים קשיחים, שנקראים standard persistent disks, וגם דיסקים לאחסון מתמיד (SSD). אפשר גם להגדיר את טכנולוגיית האחסון המועדפת ב-Compute Engine באמצעות דיסקים קשיחים קבועים. לדוגמה, אתם יכולים להגדיר את PostgreSQL כמסד נתונים של SQL או את MongoDB כאחסון NoSQL. כדי להבין את מגוון שירותי האחסון ב- Google Cloudואת היתרונות שלהם, אפשר לעיין במוצרי האחסון שלGoogle Cloud .
איזון עומסים באמצעות Compute Engine
בכל אתר שפועל בהיקף גדול, לרוב נדרש שימוש בטכנולוגיות לאיזון עומסים כדי לחלק את עומס העבודה בין השרתים. יש מגוון אפשרויות כשמתכננים את שרתי האינטרנט עם איזון העומסים ב-Compute Engine, כולל:
- איזון עומסים ב-HTTP(S).
הסבר על היסודות של השימוש ב-Cloud Load Balancing.
- איזון עומסים מבוסס תוכן. הסבר על חלוקת תנועת הגולשים למופעים שונים על סמך כתובת ה-URL הנכנסת.
- איזון עומסים בין אזורים. המאמר הזה מדגים איך להגדיר מכונות וירטואליות באזורים שונים ואיך להשתמש במאזן עומסים ב-HTTP או ב-HTTPS כדי לחלק את תעבורת הנתונים בין האזורים.
- איזון עומסים בשרתי TCP Proxy. הדגמה של הגדרת איזון עומסים גלובלי בשרתי TCP Proxy לשירות שקיים בכמה אזורים.
- איזון עומסים של שרת proxy ל-SSL. המאמר הזה מדגים איך להגדיר איזון עומסים גלובלי של שרת proxy מסוג SSL בשביל שירות שקיים בכמה אזורים.
- סיום IPv6 לאיזון עומסים של HTTP(S), שרת proxy של SSL ושרת proxy של TCP. הסבר על סיום של IPv6 ועל האפשרויות להגדרת מאזני עומסים לטיפול בבקשות IPv6.
- איזון עומסים ברשת. מוצג תרחיש בסיסי להגדרת איזון עומסים בשכבה 3 כדי לפזר את תנועת ה-HTTP בין מופעים תקינים.
- איזון עומסים בין אזורים באמצעות קצה עורפי של Microsoft IIS. במאמר הזה מוסבר איך להשתמש במאזן העומסים של Compute Engine כדי להפיץ תנועה לשרתי Microsoft Internet Information Services (IIS).
- הגדרת איזון עומסים פנימי אפשר להגדיר מאזן עומסים שמפיץ את תעבורת הנתונים ברשת פרטית שלא חשופה לאינטרנט. איזון עומסים פנימי שימושי לא רק לאפליקציות אינטראנט שבהן כל התעבורה נשארת ברשת פרטית, אלא גם לאפליקציות אינטרנט מורכבות שבהן קצה קדמי שולח בקשות לשרתי בק-אנד באמצעות רשת פרטית.
פריסת איזון העומסים היא גמישה, ואפשר להשתמש ב-Compute Engine עם הפתרונות הקיימים. לדוגמה, איזון עומסים ב-HTTP(S) באמצעות Nginx הוא פתרון אפשרי שאפשר להשתמש בו במקום מאזן העומסים של Compute Engine.
הפצת תוכן באמצעות Compute Engine
זמן התגובה הוא מדד בסיסי לכל אתר, ולכן לעיתים קרובות נדרש שימוש ב-CDN כדי להקטין את זמן האחזור ולשפר את הביצועים, במיוחד באתר עם תנועת גולשים גלובלית.
Cloud CDN משתמש בנקודות קצה (edge) של נוכחות שמפוזרות באופן גלובלי של Google כדי לספק תוכן ממיקומי מטמון שהכי קרובים למשתמשים. Cloud CDN פועל עם איזון עומסים ב-HTTP(S). כדי להציג תוכן מ-Compute Engine, מ-Cloud Storage או משניהם מכתובת IP אחת, צריך להפעיל את Cloud CDN במאזן עומסים מסוג HTTP(S).
התאמה אוטומטית לעומס באמצעות Compute Engine
אתם יכולים להגדיר את הארכיטקטורה כך ששרתים יתווספו או יוסרו בהתאם לביקוש. הגישה הזו יכולה לעזור לכם לוודא שהאתר יפעל בצורה טובה בעומס שיא, וגם לשמור על עלויות נמוכות בתקופות שבהן הביקוש אופייני יותר. Compute Engine מספק כלי לשינוי גודל אוטומטי שאפשר להשתמש בו למטרה הזו.
התאמה אוטומטית לעומס (automatic scaling) היא תכונה של קבוצות מופעי מכונה מנוהלים. קבוצת מופעי מכונה מנוהלים היא מאגר של מכונות וירטואליות הומוגניות, שנוצרו מתבנית של הגדרות מכונה משותפת. מידרוג אוטומטי מוסיף או מסיר מופעי מכונה בקבוצת מופעי מכונה מנוהלים. למרות שב-Compute Engine יש קבוצות מנוהלות ולא מנוהלות של מכונות, אפשר להשתמש רק בקבוצות מנוהלות של מכונות עם קנה מידה אוטומטי. מידע נוסף זמין במאמר בנושא שינוי גודל אוטומטי ב-Compute Engine.
למידע נוסף על מה שנדרש כדי ליצור פתרון של אפליקציית אינטרנט עמידה וניתנת להרחבה, אפשר לעיין במאמר פיתוח אפליקציות אינטרנט עמידות וניתנות להתאמה.
רישום ביומן ומעקב באמצעות Compute Engine
Google Cloud כולל תכונות שבעזרתן אפשר לעקוב אחרי מה שקורה באתר.
Cloud Logging אוסף ומאחסן יומנים מאפליקציות וממשירות ב- Google Cloud. אפשר להציג או לייצא יומנים ולשלב יומנים של צד שלישי באמצעות סוכן רישום ביומן.
Cloud Monitoring מספק לוחות בקרה והתראות לאתר שלכם. מגדירים את המעקב באמצעות מסוףGoogle Cloud . אפשר לבדוק מדדי ביצועים של שירותי ענן, מכונות וירטואליות ושרתים נפוצים בקוד פתוח כמו MongoDB, Apache, Nginx ו-Elasticsearch. אתם יכולים להשתמש ב-Cloud Monitoring API כדי לאחזר נתוני מעקב וליצור מדדים בהתאמה אישית.
בנוסף, Cloud Monitoring מספק בדיקות זמני פעילות, ששולחות בקשות לאתרים שלכם כדי לבדוק אם הם מגיבים. אפשר לעקוב אחרי הזמינות של אתר באמצעות פריסת מדיניות התראות שיוצרת אירוע אם בדיקת זמן הפעולה נכשלת.
ניהול DevOps באמצעות Compute Engine
למידע על ניהול DevOps באמצעות Compute Engine, אפשר לעיין במאמר בדיקות עומס מבוזרות באמצעות Kubernetes.
שימוש בקונטיינרים עם GKE
יכול להיות שאתם כבר משתמשים במאגרי תגים, כמו מאגרי תגים של Docker. באירוח אתרים, יש כמה יתרונות לשימוש בקונטיינרים, כולל:
- חלוקה לרכיבים. אפשר להשתמש במאגרי תגים כדי להפריד בין הרכיבים השונים של אפליקציית האינטרנט. לדוגמה, נניח שהאתר שלכם מפעיל שרת אינטרנט ומסד נתונים. אפשר להריץ את הרכיבים האלה במאגרי קונטיינרים נפרדים, ולשנות ולעדכן רכיב אחד בלי להשפיע על השני. ככל שהעיצוב של האפליקציה הופך למורכב יותר, קונטיינרים מתאימים לארכיטקטורה מוכוונת-שירותים, כולל מיקרו-שירותים. סוג העיצוב הזה תומך בסקלביליות, בין היתר.
- ניוד. קונטיינר מכיל את כל מה שצריך כדי להפעיל את האפליקציה ואת יחסי התלות שלה. אתם יכולים להריץ את הקונטיינרים במגוון פלטפורמות, בלי לדאוג לפרטים של המערכת הבסיסית.
- פריסה מהירה. כשמגיע הזמן לפריסה, המערכת שלכם בנויה ממערך של הגדרות ותמונות, כך שאפשר לפרוס את החלקים במהירות, בצורה מהימנה ואוטומטית. בדרך כלל, קונטיינרים הם קטנים ופריסתם מהירה בהרבה בהשוואה למכונות וירטואליות, למשל.
מחשוב קונטיינרים ב- Google Cloud מציע יתרונות נוספים לאירוח אתרים, כולל:
- Orchestration. GKE הוא שירות מנוהל שמבוסס על Kubernetes, מערכת תזמור קונטיינרים בקוד פתוח שהוצגה על ידי Google. ב-GKE, הקוד שלכם פועל בקונטיינרים שמהווים חלק מאשכול שמורכב ממכונות של Compute Engine. במקום לנהל מאגרי תגים בנפרד או ליצור כל מאגר תגים ולסגור אותו באופן ידני, אתם יכולים לנהל את האשכול באופן אוטומטי דרך GKE, שמשתמש בהגדרה שאתם מגדירים.
- רישום תמונות. Artifact Registry מספק אחסון פרטי לקובצי אימג' של Docker ב- Google Cloud. אפשר לגשת למאגר דרך נקודת קצה של HTTPS, כך שאפשר לשלוף תמונות מכל מכונה, בין אם מדובר במכונה וירטואלית של Compute Engine או בחומרה שלכם. שירות הרישום מארח את התמונות המותאמות אישית שלכם ב-Cloud Storage בפרויקטGoogle Cloud . הגישה הזו מבטיחה כברירת מחדל שרק לגורמים שיש להם גישה לפרויקט תהיה גישה לתמונות המותאמות אישית.
- ניידות. המשמעות היא שאתם יכולים להעביר ולשלב עומסי עבודה עם ספקים אחרים של שירותי ענן, או לשלב עומסי עבודה של מחשוב ענן עם הטמעות מקומיות כדי ליצור פתרון היברידי.
אחסון נתונים באמצעות GKE
מכיוון ש-GKE פועל ב Google Cloud ומשתמש במכונות של Compute Engine כצמתים, אפשרויות האחסון שלכם דומות מאוד לאחסון ב-Compute Engine. אתם יכולים לגשת אל Cloud SQL, Cloud Storage, Firestore ו-Bigtable דרך ממשקי ה-API שלהם, או להשתמש בספק שירותי אחסון חיצוני אחר אם תרצו. עם זאת, GKE מקיים אינטראקציה עם דיסקים קבועים של Compute Engine באופן שונה מזה של מכונה רגילה של Compute Engine.
מכונה של Compute Engine כוללת דיסק מצורף. כשמשתמשים ב-Compute Engine, נפח הדיסק נשאר עם המכונה כל עוד המכונה קיימת. אפשר אפילו לנתק את הדיסק ולהשתמש בו עם מכונה אחרת. אבל במאגר, קבצים בדיסק הם זמניים. כשמפעילים מחדש קונטיינר, למשל אחרי קריסה, הקבצים בדיסק נמחקים. Kubernetes פותרת את הבעיה הזו באמצעות הפשטות של volume ו-Storage Class. סוג אחד של סוגי אחסון הוא GCE PD.
כלומר, אתם יכולים להשתמש בדיסקים קבועים של Compute Engine עם קונטיינרים כדי למנוע מחיקה של קובצי הנתונים כשאתם משתמשים ב-GKE.
כדי להבין את התכונות והיתרונות של נפח אחסון, כדאי קודם לקרוא קצת על pods. אפשר לחשוב על פוד כמארח לוגי ספציפי לאפליקציה עבור מאגר אחד או יותר. פוד פועל במופע של צומת. כשמאגרי תגים הם חברים בפוד, הם יכולים לשתף כמה משאבים, כולל קבוצה של נפחי אחסון משותפים. הנפחים האלה מאפשרים לנתונים לשרוד הפעלה מחדש של מאגרים ולעבור בין המאגרים בתוך ה-pod. כמובן שאפשר להשתמש בקונטיינר ובנפח יחידים ב-Pod, אבל ה-Pod הוא הפשטה נדרשת כדי לקשר את המשאבים האלה זה לזה באופן לוגי.
לדוגמה, אפשר לעיין במדריך שימוש בדיסקים לאחסון מתמיד עם WordPress ו-MySQL.
איזון עומסים ב-GKE
בארכיטקטורות רבות של אירוח אתרים גדולים צריך להפעיל כמה שרתים שיכולים לחלוק את הביקוש לתעבורה. מכיוון שאפשר ליצור ולנהל כמה קונטיינרים, צמתים ופודים באמצעות GKE, הוא מתאים באופן טבעי למערכת אירוח אתרים עם איזון עומסים.
שימוש באיזון עומסים ברשת
הדרך הקלה ביותר ליצור מאזן עומסים ב-GKE היא באמצעות איזון עומסים ברשת של Compute Engine. איזון עומסים ברשת יכול לאזן את העומס במערכות שלכם על סמך נתוני פרוטוקול האינטרנט הנכנסים, כמו הכתובת, היציאה וסוג הפרוטוקול. איזון עומסים ברשת משתמש בכללי העברה. הכללים האלה מצביעים על מאגרי יעד שבהם מפורטים המקרים שזמינים לשימוש לצורך איזון עומסים.
באמצעות איזון עומסים ברשת, אפשר לאזן עומסים של פרוטוקולים נוספים שמבוססים על TCP/UDP, כמו תנועת SMTP, והאפליקציה יכולה לבדוק את החבילות ישירות.
כדי להטמיע איזון עומסים ברשת, פשוט מוסיפים את השדה type: LoadBalancer לקובץ ההגדרות של השירות.
שימוש באיזון עומסים ב-HTTP(S)
אם אתם צריכים תכונות מתקדמות יותר של איזון עומסים, כמו איזון עומסים של HTTPS, איזון עומסים מבוסס-תוכן או איזון עומסים בין אזורים, אתם יכולים לשלב את שירות GKE עם התכונה של איזון עומסים של HTTP/HTTPS ב-Compute Engine. Kubernetes מספק את משאב Ingress שמכיל אוסף של כללים לניתוב תעבורה חיצונית לנקודות קצה של Kubernetes. ב-GKE, משאב Ingress מטפל בהקצאה ובהגדרה של מאזן העומסים HTTP/HTTPS ב-Compute Engine.
מידע נוסף על שימוש באיזון עומסים של HTTP/HTTPS ב-GKE זמין במאמר הגדרת איזון עומסים של HTTP באמצעות Ingress.
התאמה להיקף באמצעות GKE
כדי לשנות את הגודל של אשכולות באופן אוטומטי, אפשר להשתמש ב-Cluster Autoscaler. התכונה הזו בודקת מדי פעם אם יש פודים שמחכים לצומת עם משאבים פנויים, אבל לא מתוזמנים. אם יש פודים כאלה, המערכת לשינוי גודל אוטומטי משנה את גודל מאגר הצמתים אם שינוי הגודל יאפשר לתזמן את הפודים שממתינים.
Cluster Autoscaler גם עוקב אחרי השימוש בכל הצמתים. אם צומת לא נדרש למשך תקופה ממושכת, ואפשר לתזמן את כל הפודים שלו במקום אחר, הצומת נמחק.
מידע נוסף על Cluster Autoscaler, על המגבלות שלו ועל שיטות מומלצות זמין במסמכי התיעוד של Cluster Autoscaler.
רישום ביומן ומעקב באמצעות GKE
בדומה ל-Compute Engine, Logging ו-Monitoring מספקים את שירותי הרישום ביומן והמעקב. שירות Logging אוסף ומאחסן יומנים מאפליקציות וממשחקים. אפשר להציג או לייצא יומנים ולשלב יומנים של צד שלישי באמצעות סוכן רישום ביומן.
Monitoring מספק לוחות בקרה והתראות לאתר שלכם. מגדירים את המעקב באמצעות מסוףGoogle Cloud . אתם יכולים לבדוק את מדדי הביצועים של שירותי ענן, מכונות וירטואליות ושרתים נפוצים בקוד פתוח כמו MongoDB, Apache, Nginx ו-Elasticsearch. אתם יכולים להשתמש ב-Monitoring API כדי לאחזר נתוני מעקב וליצור מדדים בהתאמה אישית.
ניהול DevOps באמצעות GKE
כשמשתמשים ב-GKE, כבר נהנים מהרבה מהיתרונות שרוב האנשים חושבים עליהם כשהם חושבים על DevOps. זה נכון במיוחד כשמדובר בפשטות של האריזה, הפריסה והניהול.
כדי לענות על הצרכים שלכם בתהליך העבודה של CI/CD, אתם יכולים להשתמש בכלים שנוצרו לענן, כמו Cloud Build ו-Cloud Deploy, או בכלים פופולריים כמו Jenkins. מידע נוסף זמין במאמר Modern CI/CD with GKE.
פיתוח בפלטפורמה ללא שרת (serverless) באמצעות Cloud Run
פלטפורמת serverless שלGoogle Cloudמאפשרת לכם לכתוב קוד בדרך שלכם בלי לדאוג לתשתית הבסיסית. אתם יכולים לבנות אפליקציות מלאות ללא שרת (serverless) באמצעות האחסון, מסדי הנתונים, למידת המכונה ועוד שלGoogle Cloud.
בנוסף לשימוש ב-GKE, אפשר גם לפרוס את האתרים שלכם שמבוססים על קונטיינרים ב-Cloud Run. Cloud Run היא פלטפורמה מנוהלת ללא שרת (serverless) שמאפשרת להריץ אפליקציות בקונטיינרים עם יכולת התאמה רחבה לעומס ב- Google Cloud. התשלום הוא רק על הזמן שבו הקוד פועל.
באמצעות קונטיינרים ב-Cloud Run, אתם יכולים לנצל טכנולוגיות מבוססות כמו Nginx, Express.js ו-Django כדי לבנות אתרים, לגשת למסד נתונים של SQL ב-Cloud SQL ולעבד דפי HTML דינמיים.
במסמכי Cloud Run יש מדריך למתחילים שיעזור לכם להתחיל.
אחסון נתונים באמצעות Cloud Run
הקונטיינרים של Cloud Run הם זמניים, ולכן חשוב להבין את המיכסות והמגבלות שחלות עליהם בתרחישי השימוש שלכם. אפשר לאחסן קבצים באופן זמני לעיבוד במופע של קונטיינר, אבל האחסון הזה הוא חלק מהזיכרון שזמין לשירות, כפי שמתואר בחוזה זמן הריצה.
לאחסון קבוע, אפשר לבחור בשירותים של Google Cloudכמו Cloud Storage, Firestore או Cloud SQL. אפשר גם להשתמש בפתרון אחסון של צד שלישי.
איזון עומסים והתאמה לעומס (autoscaling) באמצעות Cloud Run
כברירת מחדל, כשמבצעים build ב-Cloud Run, המערכת מנתבת אוטומטית בקשות נכנסות למאגרי back-end מתאימים ומבצעת איזון עומסים בשבילכם. עם זאת, אם אתם רוצים ליהנות מהיכולות המלאות של איזון עומסים מסוג HTTP(S) ברמה ארגונית של Google Cloud, אתם יכולים להשתמש בקבוצות של נקודות קצה (endpoint) ברשת ללא שרתים.
עם איזון עומסים מסוג HTTP(S), אפשר להפעיל את Cloud CDN או להעביר תנועה ממספר אזורים. בנוסף, אפשר להשתמש בתוכנת ביניים כמו API Gateway כדי לשפר את השירות.
ב-Cloud Run, Google Cloud מנהל בשבילכם את ההתאמה האוטומטית לעומס של מופעי קונטיינרים. כל גרסה מותאמת באופן אוטומטי למספר המכונות של הקונטיינר שנדרשות כדי לטפל בכל הבקשות הנכנסות. אם גרסה לא מקבלת תנועה, כברירת מחדל היא מותאמת לאפס מופעים של מאגר התגים. עם זאת, אם רוצים, אפשר לשנות את ברירת המחדל הזו כדי לציין מכונה שתישאר במצב בלי פעילות או מוכנה באמצעות ההגדרה minimum instances (מספר המכונות המינימלי).
רישום ביומן ומעקב באמצעות Cloud Run
ב-Cloud Run יש שני סוגים של יומנים שנשלחים אוטומטית אל Cloud Logging:
- יומני בקשות: יומנים של בקשות שנשלחו לשירותי Cloud Run. היומנים האלה נוצרים באופן אוטומטי.
- יומני קונטיינר: יומנים שמופקים ממופעי הקונטיינר, בדרך כלל מהקוד שלכם, ונכתבים במיקומים נתמכים כפי שמתואר במאמר כתיבת יומני קונטיינר.
יש כמה דרכים לצפייה ביומנים של השירות:
- בדף Cloud Run במסוף Google Cloud .
- משתמשים ב-Logs Explorer של Cloud Logging במסוף Google Cloud .
בשתי השיטות האלה מוצגים אותם יומנים שמאוחסנים ב-Cloud Logging, אבל בכלי Logs Explorer יש יותר פרטים ויכולות סינון.
Cloud Monitoring מספק מעקב אחר הביצועים של Cloud Run, מדדים ובדיקות זמן פעולה תקינה, וגם התראות לשליחת הודעות כשחורגים מסף מסוים של מדד. התמחור של Google Cloud Observability חל על המדדים בגרסה המנוהלת במלואה של Cloud Run, כלומר אין חיוב על המדדים. שימו לב שאפשר גם להשתמש במדדים מותאמים אישית של Cloud Monitoring.
Cloud Run משולב עם Cloud Monitoring בלי צורך בהגדרה או בקביעת תצורה. המשמעות היא שהמדדים של שירותי Cloud Run נרשמים אוטומטית כשהם פועלים.
פיתוח מערכות לניהול תוכן
אירוח אתר פירושו ניהול נכסי האתר. Cloud Storage מספק מאגר גלובלי של הנכסים האלה. ארכיטקטורה נפוצה אחת היא פריסת תוכן סטטי ב-Cloud Storage, ואז סנכרון עם Compute Engine כדי לעבד דפים דינמיים. Cloud Storage פועל עם הרבה מערכות ניהול תוכן של צד שלישי, כמו WordPress, Drupal ו-Joomla. בנוסף, Cloud Storage מציע API שתואם ל-Amazon S3, כך שכל מערכת שעובדת עם Amazon S3 יכולה לעבוד עם Cloud Storage.
בתרשים הבא מוצגת ארכיטקטורה לדוגמה של מערכת ניהול תוכן.
המאמרים הבאים
- כדאי להעמיק את הקריאה ולהכיר דוגמאות לארכיטקטורות, תרשימים ושיטות מומלצות בנושאי Google Cloud. כל אלה זמינים במרכז הארכיטקטורה של Cloud.