במאמר הזה נסביר איך לארח אתר ב- Google Cloud. Google Cloud מספקת פלטפורמה חזקה, גמישה, אמינה וניתנת להרחבה לאירוח אתרים. Google Google Cloud על ידי שימוש באותה תשתית שבה Google משתמשת כדי להציג תוכן מאתרים כמו Google.com, YouTube ו-Gmail. אתם יכולים לארח את התוכן של האתר שלכם באמצעות סוג ותכנון של תשתית שמתאימים לצרכים שלכם בצורה הכי טובה.
המאמר הזה יכול לעזור לכם אם אתם:
- יש לכם ידע לגבי יצירת אתר, ופרסתם והפעלתם בעבר תשתית לאירוח אתרים.
- הערכה אם ואיך להעביר את האתר אל Google Cloud.
אם אתם רוצים ליצור אתר פשוט, כדאי להשתמש ב-Google Sites, כלי ליצירת דפי אינטרנט ודפי ויקי מובנים. מידע נוסף זמין בעזרה בנושא 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. |
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 כדי להריץ סקריפט שמעדכן את הדלי. מערכת מתקדמת עוד יותר עשויה להשתמש בכלי של אינטגרציה רציפה/הפצה רציפה (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:
- אירוח ב-Firebase כולל SSL ללא צורך בהגדרה. מקצה אישורי 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. אם רוצים כונן קשיח של אחסון מתמיד, יוצרים גם אותו. כלים של תשתית כקוד, כמו Terraform, הופכים את התהליך הזה לפשוט וניתן לחזרה.
- הגדרת האפליקציה והתאמה אישית שלה. אחרי שבוחרים את הרכיבים הרצויים, צריך להגדיר אותם, להתקין ולהגדיר תוכנה, ולכתוב ולפרוס קוד התאמה אישית שנדרש. אפשר לשכפל את ההגדרה על ידי הפעלת סקריפטים של מעטפת, וכך להאיץ את הפריסות העתידיות. גם כאן Terraform יכול לעזור, כי הוא מספק תבניות הצהרה גמישות להגדרות לפריסה אוטומטית של משאבים. אפשר גם להשתמש בכלים לאוטומציה של IT, כמו Puppet ו-Chef.
- פריסת הנכסים. כנראה שיש לכם דפי אינטרנט ותמונות.
- בדיקה. מוודאים שהכול פועל כמו שרוצים.
- פריסה בסביבת הייצור. פותחים את האתר לשימוש ולצפייה של אנשים בכל העולם.
אחסון נתונים באמצעות Compute Engine
רוב האתרים צריכים אחסון כלשהו. יכול להיות שתצטרכו נפח אחסון מסיבות שונות, למשל כדי לשמור קבצים שהמשתמשים מעלים, וכמובן את הנכסים שבהם האתר משתמש.
Google Cloud מספקת מגוון שירותי אחסון מנוהלים, כולל:
- מסד נתונים של SQL ב-Cloud SQL, שהוא שירות מנוהל של מסד נתונים רלציוני ל-MySQL, PostgreSQL ו-SQL Server.
- שתי אפשרויות לאחסון נתוני NoSQL: Firestore ו-Bigtable.
- Memorystore, שירות מנוהל לחלוטין של מאגר נתונים בזיכרון ל-Redis ול-Memcached.
- אחסון אובייקטים עקבי, ניתן להרחבה ובעל קיבולת גדולה ב-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 משתמש בנקודות נוכחות (PoP) בקצה הרשת שמפוזרות ברחבי העולם כדי לספק תוכן ממיקומי מטמון שהכי קרובים למשתמשים. Cloud CDN פועל עם איזון עומסים ב-HTTP(S). כדי להציג תוכן מ-Compute Engine, מ-Cloud Storage או משניהם מכתובת IP אחת, צריך להפעיל את Cloud CDN במאזן עומסים מסוג HTTP(S).
התאמה אוטומטית לעומס באמצעות Compute Engine
אתם יכולים להגדיר את הארכיטקטורה כך שתוכלו להוסיף שרתים ולהסיר אותם בהתאם לביקוש. הגישה הזו יכולה לעזור לכם לוודא שהאתר יפעל בצורה טובה בעומס שיא, תוך שמירה על עלויות נמוכות בתקופות של ביקוש רגיל יותר. Compute Engine מספק מידרוג אוטומטי שאפשר להשתמש בו למטרה הזו.
התאמה אוטומטית לעומס היא תכונה של קבוצות מופעי מכונה מנוהלים. קבוצת מופעי מכונה מנוהלים היא מאגר של מכונות וירטואליות הומוגניות, שנוצרו מתבנית של הגדרות מכונה משותפת. מידרוג אוטומטי מוסיף או מסיר מופעי מכונה בקבוצת מופעי מכונה מנוהלים. למרות שב-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 פועל על מכונות של Compute Engine ומשתמש בהן כצמתים, אפשרויות האחסון שלכם דומות מאוד לאחסון ב-Compute Engine. Google Cloud אתם יכולים לגשת אל 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, אתם יכולים להשתמש בקבוצות של נקודות קצה ברשת ללא שרתים.
עם איזון עומסים מסוג 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.