דף זה תורגם על ידי Cloud Translation API.

אירוח והתאמה לעומס של אפליקציית אינטרנט ב-Google Cloud באמצעות Compute Engine

1. מבוא

יש הרבה דרכים לפרוס אתרי אינטרנט ב-Google Cloud, כשכל פתרון מציע תכונות, יכולות ורמות שליטה שונות. ב-Compute Engine יש רמה גבוהה של שליטה בתשתית שמשמשת להפעלת אתר אינטרנט, אבל נדרש גם קצת יותר ניהול תפעולי בהשוואה לפתרונות כמו Google Kubernetes Engine, App Engine או אחרים. עם Compute Engine תוכלו לשלוט בצורה פרטנית בהיבטים שונים של התשתית, כולל מכונות וירטואליות, מאזן עומסים ועוד. היום תפרסו אפליקציה לדוגמה — אתר המסחר האלקטרוני של Fancy Store — כדי להראות איך אפשר לפרוס אתר ולהתאים אותו בקלות לעומס באמצעות Compute Engine.

מה תלמדו

איך יוצרים מכונות של Compute Engine
איך יוצרים תבניות של מכונות ממכונות מקור
איך יוצרים קבוצות של מופעי מכונה מנוהלים
איך מגדירים בדיקות תקינות ותיקון אוטומטי
איך יוצרים איזון עומסים מסוג HTTP(S)
איך יוצרים בדיקות תקינות למאזני עומסים
איך משתמשים ברשת להעברת תוכן לשמירה במטמון

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

דרישות מוקדמות

ריכזנו כאן סקירות כלליות של המושגים שבהם נשתמש בשיעור ה-Lab הזה:
ברוכים הבאים ל-Google Cloud Platform – העקרונות הבסיסיים של GCP
תחילת העבודה עם Google Cloud Compute Engine
תחילת העבודה עם Google Cloud Storage
תחילת העבודה: Cloud Shell

2. הגדרת סביבה

הגדרת סביבה בקצב אישי

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

חשוב לזכור את מזהה הפרויקט, שם ייחודי לכל הפרויקטים ב-Google Cloud (השם שלמעלה כבר תפוס ולא מתאים לכם, סליחה). בהמשך ב-Codelab הזה, היא תיקרא PROJECT_ID.

בשלב הבא צריך להפעיל את החיוב במסוף Cloud כדי להשתמש במשאבים של Google Cloud.

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

הפעלת Compute Engine API

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

כדי להפעיל את Compute Engine API ב-Cloud Shell, מריצים את הפקודה הבאה:

gcloud services enable compute.googleapis.com

Cloud Shell

אומנם אפשר להפעיל את Google Cloud מרחוק מהמחשב הנייד, אבל ב-Codelab הזה משתמשים ב-Cloud Shell, סביבת שורת הפקודה שפועלת ב-Cloud.

המכונה הווירטואלית הזו שמבוססת על Debian נטענת עם כל הכלים למפתחים שדרושים לכם. יש בה ספריית בית בנפח מתמיד של 5GB והיא פועלת ב-Google Cloud, מה שמשפר משמעותית את ביצועי הרשת והאימות. כלומר, כל מה שדרוש ל-Codelab הזה הוא דפדפן (כן, הוא פועל ב-Chromebook).

כדי להפעיל את Cloud Shell ממסוף Cloud, לוחצים על Activate Cloud Shell (ההקצאה וההתחברות לסביבה אמורות להימשך כמה דקות).

צילום מסך מתאריך 2017-06-14 בשעה 22:13.43.png

אחרי ההתחברות ל-Cloud Shell, אתם אמורים לראות שכבר בוצע אימות ושהפרויקט כבר מוגדר ל-PROJECT_ID שלכם.

gcloud auth list

פלט הפקודה

Credentialed accounts:
 - <myaccount>@<mydomain>.com (active)

gcloud config list project

פלט הפקודה

[core]
project = <PROJECT_ID>

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

gcloud config set project <PROJECT_ID>

רוצה למצוא את ה-PROJECT_ID שלך? אתם יכולים לבדוק באיזה מזהה השתמשתם בשלבי ההגדרה או לחפש אותו במרכז הבקרה של מסוף Cloud:

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

echo $GOOGLE_CLOUD_PROJECT

פלט הפקודה

<PROJECT_ID>

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

gcloud config set compute/zone us-central1-f

אפשר לבחור מגוון אזורים שונים. מידע נוסף זמין במאמר אזורים ו אזורים.

יצירת קטגוריה של Cloud Storage

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

gsutil mb gs://fancy-store-$DEVSHELL_PROJECT_ID

3. שכפול מאגר המקור

אתר המסחר האלקטרוני הקיים של Fancy Store ישמש אתכם על סמך המאגר מונולית למיקרו-שירותים (microlith) למיקרו-שירותים של האתר שלכם. שכפול קוד המקור מהמאגר שלכם יאפשר לכם להתמקד בהיבטים של הפריסה ב-Compute Engine. בהמשך מבצעים עדכון קטן בקוד כדי להדגים את פשטות העדכונים ב-Compute Engine.

תוכלו לשכפל באופן אוטומטי את מאגר הקודים לפרויקט, וגם לפתוח את Cloud Shell ואת עורך הקוד המובנה, דרך הקישור הבא: Open in Cloud Shell.

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

cd ~
git clone https://github.com/googlecodelabs/monolith-to-microservices.git
cd ~/monolith-to-microservices

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

./setup.sh

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

cd microservices
npm start

פלט:

Products microservice listening on port 8082!
Frontend microservice listening on port 8080!
Orders microservice listening on port 8081!

ניתן להציג תצוגה מקדימה של האפליקציה על ידי לחיצה על סמל התצוגה המקדימה באינטרנט ובחירה באפשרות 'תצוגה מקדימה ביציאה 8080'.

פעולה זו אמורה לפתוח חלון חדש שבו ניתן לראות את החזית של Fancy Store בפעולה!

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

4. יצירת מכונות Compute Engine

עכשיו, אחרי שיצרתם את סביבת העבודה למפתחים, תוכלו לפרוס כמה מכונות של Compute Engine. השלבים הבאים:

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

יצירת סקריפט להפעלה

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

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

עוברים לתיקייה מונולית למיקרו-שירותים. לוחצים על קובץ > קובץ חדש ויוצרים קובץ בשם start-script.sh.

בקובץ החדש, מדביקים את הקוד הבא, שאת חלקו תערכו לאחר ההדבקה:

#!/bin/bash

# Install logging monitor. The monitor will automatically pick up logs sent to
# syslog.
curl -s "https://storage.googleapis.com/signals-agents/logging/google-fluentd-install.sh" | bash
service google-fluentd restart &

# Install dependencies from apt
apt-get update
apt-get install -yq ca-certificates git build-essential supervisor psmisc

# Install nodejs
mkdir /opt/nodejs
curl https://nodejs.org/dist/v8.12.0/node-v8.12.0-linux-x64.tar.gz | tar xvzf - -C /opt/nodejs --strip-components=1
ln -s /opt/nodejs/bin/node /usr/bin/node
ln -s /opt/nodejs/bin/npm /usr/bin/npm

# Get the application source code from the Google Cloud Storage bucket.
mkdir /fancy-store
gsutil -m cp -r gs://fancy-store-[DEVSHELL_PROJECT_ID]/monolith-to-microservices/microservices/* /fancy-store/

# Install app dependencies.
cd /fancy-store/
npm install

# Create a nodeapp user. The application will run as this user.
useradd -m -d /home/nodeapp nodeapp
chown -R nodeapp:nodeapp /opt/app

# Configure supervisor to run the node app.
cat >/etc/supervisor/conf.d/node-app.conf << EOF
[program:nodeapp]
directory=/fancy-store
command=npm start
autostart=true
autorestart=true
user=nodeapp
environment=HOME="/home/nodeapp",USER="nodeapp",NODE_ENV="production"
stdout_logfile=syslog
stderr_logfile=syslog
EOF

supervisorctl reread
supervisorctl update

עכשיו, בעורך הקוד, מחפשים את הטקסט [DEVSHELL_PROJECT_ID] ומחליפים אותו בפלט מהפקודה הבאה:

echo $DEVSHELL_PROJECT_ID

פלט לדוגמה:

my-gce-codelab-253520

עכשיו שורת הקוד ב-startup-script.sh אמורה להיות דומה לזו:

gs://fancy-store-my-gce-codelab-253520/monolith-to-microservices/microservices/* /fancy-store/

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

התקנת סוכן ה-Logging, שאוסף באופן אוטומטי יומנים מ-Syslog
התקנת Node.js ו-Supervisor, שמפעילה את האפליקציה כדימון (daemon)
שכפול קוד המקור של האפליקציה מהקטגוריה של Cloud Storage והתקנה של יחסי תלות
הגדרת המפקח, שמפעיל את האפליקציה, צריך לוודא שהאפליקציה מופעלת מחדש אם היא יוצאת באופן בלתי צפוי או נעצרת על ידי אדמין או פקודה, ושולחת את ה-stdout וה-stderr של האפליקציה ל-Syslog כדי שסוכן ה-Logging יאסוף

עכשיו מעתיקים את הקובץ start-script.sh שנוצר לקטגוריה של Cloud Storage שיצרתם קודם:

gsutil cp ~/monolith-to-microservices/startup-script.sh gs://fancy-store-$DEVSHELL_PROJECT_ID

הקישור זמין עכשיו בכתובת https://storage.googleapis.com/[BUCKET_NAME]/startup-script.sh. [BUCKET_NAME] מייצג את שם הקטגוריה של Cloud Storage. רק משתמשים מורשים וחשבונות שירות יכולים לראות את השם הזה כברירת מחדל, ולכן לא תהיה גישה אליו דרך דפדפן אינטרנט. המכונות של Compute Engine יוכלו לגשת אליו באופן אוטומטי דרך חשבונות השירות שלהן.

העתקת הקוד לקטגוריה של Cloud Storage

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

מעתיקים את הקוד המשוכפל לקטגוריה של Cloud Storage:

cd ~
rm -rf monolith-to-microservices/*/node_modules
gsutil -m cp -r monolith-to-microservices gs://fancy-store-$DEVSHELL_PROJECT_ID/

פריסת מופע קצה עורפי

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

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

gcloud compute instances create backend \
    --machine-type=f1-micro \
    --image=debian-9-stretch-v20190905 \
    --image-project=debian-cloud \
    --tags=backend \
    --metadata=startup-script-url=https://storage.googleapis.com/fancy-store-$DEVSHELL_PROJECT_ID/startup-script.sh

הגדרת החיבור לקצה העורפי

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

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

gcloud compute instances list

פלט לדוגמה:

NAME     ZONE           MACHINE_TYPE  PREEMPTIBLE  INTERNAL_IP  EXTERNAL_IP   STATUS
backend  us-central1-a  f1-micro                   10.128.0.2   34.68.223.88  RUNNING

בעורך הקוד של Cloud Shell, נכנסים לתיקייה monolith-to-microservices > react-app. בתפריט 'עורך קוד', בוחרים באפשרות תצוגה > מחליפים את מצב הקבצים המוסתריםכדי לראות את הקובץ .env.

עורכים את קובץ .env כך שיצביע על כתובת ה-IP החיצונית של הקצה העורפי. [BACKEND_ADDRESS] בהמשך מייצג את כתובת ה-IP החיצונית של מכונה בקצה העורפי, שנקבעת מהפקודה הקודמת בכלי gcloud.

REACT_APP_ORDERS_URL=http://[BACKEND_ADDRESS]:8081/api/orders
REACT_APP_PRODUCTS_URL=http://[BACKEND_ADDRESS]:8082/api/products

שומרים את הקובץ.

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

cd ~/monolith-to-microservices/react-app
npm install && npm run-script build

מעתיקים את קוד האפליקציה לקטגוריה של Cloud Storage:

cd ~
rm -rf monolith-to-microservices/*/node_modules
gsutil -m cp -r monolith-to-microservices gs://fancy-store-$DEVSHELL_PROJECT_ID/

פריסת מופע של קצה קדמי

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

gcloud compute instances create frontend \
    --machine-type=f1-micro \
    --image=debian-9-stretch-v20190905 \
    --image-project=debian-cloud \
    --tags=frontend \
    --metadata=startup-script-url=https://storage.googleapis.com/fancy-store-$DEVSHELL_PROJECT_ID/startup-script.sh

הגדרת רשת

יוצרים כללי חומת אש כדי לאפשר גישה ליציאה 8080 לחזית וליציאות 8081 ו-8082 לקצה העורפי. פקודות חומת האש משתמשות בתגים שהוקצו במהלך יצירת המכונה לאפליקציה.

gcloud compute firewall-rules create fw-fe \
    --allow tcp:8080 \
    --target-tags=frontend

gcloud compute firewall-rules create fw-be \
    --allow tcp:8081-8082 \
    --target-tags=backend

האתר אמור לפעול עכשיו. קובעת את כתובת ה-IP החיצונית של הקצה הקדמי. כדי לקבוע את הכתובת, צריך לחפש את ה-EXTERNAL_IP של המכונה של הקצה הקדמי:

gcloud compute instances list

פלט לדוגמה:

NAME      ZONE           MACHINE_TYPE  PREEMPTIBLE  INTERNAL_IP  EXTERNAL_IP      STATUS
backend   us-central1-a  f1-micro                   10.128.0.2   104.198.235.171  RUNNING
frontend  us-central1-a  f1-micro                   10.128.0.3   34.69.141.9      RUNNING

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

watch -n 5 curl http://[EXTERNAL_IP]:8080

אחרי שתתקבל פלט דומה לפלט הבא, האתר אמור להיות מוכן. לוחצים על Control+C (Command+C ב-Macintosh) בשורת הפקודה כדי לבטל את פקודת השעון.

דפדוף אל http://[FRONTEND_ADDRESS]:8080 באמצעות כרטיסייה חדשה בדפדפן אינטרנט כדי לגשת לאתר, כאשר [FRONTEND_ADDRESS] הוא ה-EXTERNAL_IP שנקבע למעלה.

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

5. יצירת קבוצות של מופעי מכונה מנוהלים

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

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

יצירת תבנית של מכונה ממופע מקור

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

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

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

gcloud compute instances stop frontend

gcloud compute instances stop backend

עכשיו יוצרים את תבנית המכונה ממכונות המקור.

gcloud compute instance-templates create fancy-fe \
    --source-instance=frontend

gcloud compute instance-templates create fancy-be \
    --source-instance=backend

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

gcloud compute instance-templates list

פלט לדוגמה:

NAME      MACHINE_TYPE  PREEMPTIBLE  CREATION_TIMESTAMP
fancy-be  f1-micro                   2019-09-12T07:52:57.544-07:00
fancy-fe  f1-micro                   2019-09-12T07:52:48.238-07:00

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

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

gcloud compute instance-groups managed create fancy-fe-mig \
    --base-instance-name fancy-fe \
    --size 2 \
    --template fancy-fe

gcloud compute instance-groups managed create fancy-be-mig \
    --base-instance-name fancy-be \
    --size 2 \
    --template fancy-be

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

gcloud compute instance-groups set-named-ports fancy-fe-mig \ 
    --named-ports frontend:8080

gcloud compute instance-groups set-named-ports fancy-be-mig \
    --named-ports orders:8081,products:8082

הגדרת התיקון האוטומטי

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

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

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

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

gcloud compute health-checks create http fancy-fe-hc \
    --port 8080 \
    --check-interval 30s \
    --healthy-threshold 1 \
    --timeout 10s \
    --unhealthy-threshold 3

gcloud compute health-checks create http fancy-be-hc \
    --port 8081 \
    --request-path=/api/orders \
    --check-interval 30s \
    --healthy-threshold 1 \
    --timeout 10s \
    --unhealthy-threshold 3

יוצרים כלל של חומת אש כדי לאפשר לבקשות של בדיקת התקינות להתחבר למיקרו-שירותים ביציאות 8080 ו-8081:

gcloud compute firewall-rules create allow-health-check \
    --allow tcp:8080-8081 \
    --source-ranges 130.211.0.0/22,35.191.0.0/16 \
    --network default

מחילים את בדיקות התקינות בשירותים הרלוונטיים:

gcloud compute instance-groups managed update fancy-fe-mig \
    --health-check fancy-fe-hc \
    --initial-delay 300

gcloud compute instance-groups managed update fancy-be-mig \
    --health-check fancy-be-hc \
    --initial-delay 300

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

6. יצירת מאזן עומסים

כדי להשלים את קבוצות המופעים המנוהלות שלנו, משתמשים ב-HTTP(S) Load Balancing כדי לשרת את תעבורת הנתונים למיקרו-שירותים (microservices) בקצה הקדמי ובקצה העורפי, ובשימוש במיפויים כדי לשלוח תעבורת נתונים לשירותים המתאימים לקצה העורפי על סמך כללי ניתוב. הפעולה הזאת תחשוף כתובת IP אחת עם איזון עומסים לכל השירותים.

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

יצירת איזון עומסים של HTTP(S)

ב-Google Cloud יש סוגים רבים של איזון עומסים, אבל צריך להשתמש באיזון עומסים HTTP(S) לתעבורת הנתונים שלכם. איזון עומסים של HTTP(S) בנוי באופן הבא:

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

מומלץ ליצור בדיקות תקינות כדי לקבוע אילו מכונות יוכלו להציג תנועה לכל שירות בנפרד.

gcloud compute http-health-checks create fancy-fe-frontend-hc \
  --request-path / \
  --port 8080

gcloud compute http-health-checks create fancy-be-orders-hc \
  --request-path /api/orders \
  --port 8081

gcloud compute http-health-checks create fancy-be-products-hc \
  --request-path /api/products \
  --port 8082

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

gcloud compute backend-services create fancy-fe-frontend \
  --http-health-checks fancy-fe-frontend-hc \
  --port-name frontend \
  --global

gcloud compute backend-services create fancy-be-orders \
  --http-health-checks fancy-be-orders-hc \
  --port-name orders \
  --global

gcloud compute backend-services create fancy-be-products \
  --http-health-checks fancy-be-products-hc \
  --port-name products \
  --global

הוספת השירותים לקצה העורפי.

gcloud compute backend-services add-backend fancy-fe-frontend \
  --instance-group fancy-fe-mig \
  --instance-group-zone us-central1-f \
  --global

gcloud compute backend-services add-backend fancy-be-orders \
  --instance-group fancy-be-mig \
  --instance-group-zone us-central1-f \
  --global

gcloud compute backend-services add-backend fancy-be-products \
  --instance-group fancy-be-mig \
  --instance-group-zone us-central1-f \
  --global

יצירת מפה של כתובות URL. מפת כתובות ה-URL מגדירה אילו כתובות URL יופנו לאילו שירותים לקצה העורפי.

gcloud compute url-maps create fancy-map \
  --default-service fancy-fe-frontend

אפשר ליצור כלי להתאמה לנתיב כדי לאפשר לנתיבים /api/orders ו-/api/products לנתב לשירותים המתאימים.

gcloud compute url-maps add-path-matcher fancy-map \
   --default-service fancy-fe-frontend \
   --path-matcher-name orders \
   --path-rules "/api/orders=fancy-be-orders,/api/products=fancy-be-products"

יוצרים את שרת ה-proxy שמקשר למפת כתובות ה-URL שנוצרה.

gcloud compute target-http-proxies create fancy-proxy \
  --url-map fancy-map

יוצרים כלל העברה גלובלי שמחבר בין כתובת IP ציבורית ויציאה לשרת ה-proxy.

gcloud compute forwarding-rules create fancy-http-rule \
  --global \
  --target-http-proxy fancy-proxy \
  --ports 80

עדכון ההגדרות האישיות

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

ב-Cloud Shell, עוברים לתיקייה של האפליקציה בתגובות, שמכילה את קובץ ה- .env שמכיל את ההגדרות האישיות.

cd ~/monolith-to-microservices/react-app/

מחפשים את כתובת ה-IP של מאזן העומסים:

gcloud compute forwarding-rules list --global

פלט לדוגמה:

NAME                    REGION  IP_ADDRESS     IP_PROTOCOL  TARGET
fancy-http-rule          34.102.237.51  TCP          fancy-proxy

עורכים את קובץ ה- .env באמצעות עורך הטקסט המועדף עליכם (למשל GNU nano) כדי להפנות לכתובת ה-IP הציבורית של מאזן העומסים. [LB_IP] מייצג את כתובת ה-IP החיצונית של המכונה של הקצה העורפי.

REACT_APP_ORDERS_URL=http://[LB_IP]/api/orders
REACT_APP_PRODUCTS_URL=http://[LB_IP]/api/products

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

cd ~/monolith-to-microservices/react-app
npm install && npm run-script build

מעתיקים את קוד האפליקציה לקטגוריה של GCS.

cd ~
rm -rf monolith-to-microservices/*/node_modules
gsutil -m cp -r monolith-to-microservices gs://fancy-store-$DEVSHELL_PROJECT_ID/

עדכון המופעים של הקצה הקדמי

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

gcloud compute instance-groups managed rolling-action restart fancy-fe-mig \
    --max-unavailable 100%

בדיקת האתר

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

watch -n 5 gcloud compute instance-groups list-instances fancy-fe-mig

אחרי שהפריטים מופיעים ברשימה, צריך לצאת מפקודת השעון על ידי הקשה על Control+C (Command+C ב-Macintosh).

מוודאים שהשירות רשום כתקין.

watch -n 5 gcloud compute backend-services get-health fancy-fe-frontend --global

פלט לדוגמה:

---
backend: https://www.googleapis.com/compute/v1/projects/my-gce-codelab/zones/us-central1-a/instanceGroups/fancy-fe-mig
status:
  healthStatus:
  - healthState: HEALTHY
    instance: https://www.googleapis.com/compute/v1/projects/my-gce-codelab/zones/us-central1-a/instances/fancy-fe-x151
    ipAddress: 10.128.0.7
    port: 8080
  - healthState: HEALTHY
    instance: https://www.googleapis.com/compute/v1/projects/my-gce-codelab/zones/us-central1-a/instances/fancy-fe-cgrt
    ipAddress: 10.128.0.11
    port: 8080
  kind: compute#backendServiceGroupHealth

אחרי שהפריטים מופיעים ברשימה, צריך לצאת מהפקודה watch על ידי הקשה על Control+C (Command+C ב-Macintosh).

לאחר מכן האפליקציה תהיה זמינה דרך http://[LB_IP], כאשר [LB_IP] הוא ה-IP_ADDRESS שצוין עבור מאזן העומסים, שניתן למצוא באמצעות הפקודה הבאה:

gcloud compute forwarding-rules list --global

7. הרחבה של Compute Engine

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

שינוי אוטומטי של הגודל באמצעות שימוש

כדי ליצור את מדיניות ההתאמה לעומס (autoscaling), מריצים את הפקודות הבאות ב-Cloud Shell. הם ייצרו מדרגיות אוטומטיות בקבוצות של מופעי מכונה מנוהלים, שמוסיף באופן אוטומטי מכונות כאשר מאזן העומסים גבוה מ-60% ומסירות מכונות שבהן מאזן העומסים נמוך מ-60%.

gcloud compute instance-groups managed set-autoscaling \
  fancy-fe-mig \
  --max-num-replicas 5 \
  --target-load-balancing-utilization 0.60

gcloud compute instance-groups managed set-autoscaling \
  fancy-be-mig \
  --max-num-replicas 5 \
  --target-load-balancing-utilization 0.60

הפעלת רשת להעברת תוכן

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

gcloud compute backend-services update fancy-fe-frontend \
    --enable-cdn --global

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

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

8. עדכון האתר

עדכון תבנית של מכונה

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

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

כדי לשנות את סוג המכונה של תבנית המכונה, עוברים ממכונה מסוג f1-micro למכונה מותאמת אישית עם 4 vCPU ו-3840MiB RAM.

ב-Cloud Shell, מריצים את הפקודה הבאה כדי לשנות את סוג המכונה של החזית הקדמית:

gcloud compute instances set-machine-type frontend --machine-type custom-4-3840

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

gcloud compute instance-templates create fancy-fe-new \
    --source-instance=frontend \
    --source-instance-zone=us-central1-a

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

gcloud compute instance-groups managed rolling-action start-update fancy-fe-mig \
    --version template=fancy-fe-new

כך עוקבים אחרי סטטוס העדכון:

watch -n 2 gcloud compute instance-groups managed list-instances fancy-fe-mig

אחרי שיש לכם יותר ממכונה אחת בסטטוס RUNNING, ACTION מוגדרת ל-None, וכשהתבנית INSTANCE_TEMPLATE מוגדרת כשם התבנית החדש (fancy-fe-new), מעתיקים את השם של אחת מהמכונות המפורטות לשימוש בפקודה הבאה.

Control+S (Command+S ב-Macintosh) כדי לצאת מתהליך הצפייה.

כדי לבדוק אם במכונה הווירטואלית נעשה שימוש בסוג המכונה החדש (custom-4-3840), כאשר [VM_NAME] היא המכונה החדשה שנוצרה:

gcloud compute instances describe [VM_NAME] | grep machineType

הפלט הצפוי לדוגמה:

machineType: https://www.googleapis.com/compute/v1/projects/project-name/zones/us-central1-f/machineTypes/custom-4-3840

ביצוע שינויים באתר

צוות השיווק שלך ביקש ממך לשנות את דף הבית של האתר. הם חושבים שזה צריך לספק מידע רב יותר על החברה שלכם ועל מה שאתם מוכרים בפועל. בקטע הזה תוסיפו טקסט לדף הבית כדי לשמח את צוות השיווק! נראה שאחד מהמפתחים שלך כבר יצר את השינויים עם שם הקובץ index.js.new. ניתן להעתיק את הקובץ אל index.js והשינויים אמורים לבוא לידי ביטוי. צריך לבצע את ההוראות הבאות כדי לבצע את השינויים המתאימים.

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

cd ~/monolith-to-microservices/react-app/src/pages/Home
mv index.js.new index.js
cat ~/monolith-to-microservices/react-app/src/pages/Home/index.js

הקוד שמתקבל אמור להיראות כך:

/*
Copyright 2019 Google LLC

Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

    https://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
*/

import React from "react";
import { makeStyles } from "@material-ui/core/styles";
import Paper from "@material-ui/core/Paper";
import Typography from "@material-ui/core/Typography";
const useStyles = makeStyles(theme => ({
  root: {
    flexGrow: 1
  },
  paper: {
    width: "800px",
    margin: "0 auto",
    padding: theme.spacing(3, 2)
  }
}));
export default function Home() {
  const classes = useStyles();
  return (
    <div className={classes.root}>
      <Paper className={classes.paper}>
        <Typography variant="h5">
          Fancy Fashion &amp; Style Online
        </Typography>
        <br />
        <Typography variant="body1">
          Tired of mainstream fashion ideas, popular trends and societal norms?
          This line of lifestyle products will help you catch up with the Fancy trend and express your personal style.
          Start shopping Fancy items now!
        </Typography>
      </Paper>
    </div>
  );
}

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

cd ~/monolith-to-microservices/react-app
npm install && npm run-script build

לאחר מכן, דוחפים את הקוד שוב לקטגוריה של Cloud Storage.

cd ~
rm -rf monolith-to-microservices/*/node_modules
gsutil -m cp -r monolith-to-microservices gs://fancy-store-$DEVSHELL_PROJECT_ID/

דחיפת שינויים עם עדכונים בהדרגה

עכשיו אפשר לאלץ את כל המכונות להפעיל מחדש כדי למשוך את העדכון.

gcloud compute instance-groups managed rolling-action restart fancy-fe-mig \
    --max-unavailable=100%

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

watch -n 5 gcloud compute instance-groups list-instances fancy-fe-mig

אחרי שהפריטים מופיעים ברשימה, צריך לצאת מפקודת השעון על ידי הקשה על Control+S (Command+S ב-Macintosh).

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

watch -n 5 gcloud compute backend-services get-health fancy-fe-frontend --global

פלט לדוגמה:

---
backend: https://www.googleapis.com/compute/v1/projects/my-gce-codelab/zones/us-central1-a/instanceGroups/fancy-fe-mig
status:
  healthStatus:
  - healthState: HEALTHY
    instance: https://www.googleapis.com/compute/v1/projects/my-gce-codelab/zones/us-central1-a/instances/fancy-fe-x151
    ipAddress: 10.128.0.7
    port: 8080
  - healthState: HEALTHY
    instance: https://www.googleapis.com/compute/v1/projects/my-gce-codelab/zones/us-central1-a/instances/fancy-fe-cgrt
    ipAddress: 10.128.0.11
    port: 8080
  kind: compute#backendServiceGroupHealth

אחרי שהפריטים מופיעים ברשימה, צריך לצאת מפקודת השעון על ידי הקשה על Control+S (Command+S ב-Macintosh).

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

gcloud compute url-maps invalidate-cdn-cache fancy-map \
    --path "/*"

דפדוף לאתר דרך http://[LB_IP] כאשר [LB_IP] הוא ה-IP_ADDRESS שצוין למאזן העומסים, שניתן למצוא באמצעות הפקודה הבאה:

gcloud compute forwarding-rules list --global

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

סימולציה של כשל

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

gcloud compute instance-groups list-instances fancy-fe-mig

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

gcloud compute ssh [INSTANCE_NAME]

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

sudo supervisorctl stop nodeapp; sudo killall node

יוצאים מהמכונה.

exit

עוקבים אחרי פעולות התיקון.

watch -n 5 gcloud compute operations list \
--filter='operationType~compute.instances.repair.*'

נחפש את הפלט הבא לדוגמה:

NAME                                                  TYPE                                       TARGET                                 HTTP_STATUS  STATUS  TIMESTAMP
repair-1568314034627-5925f90ee238d-fe645bf0-7becce15  compute.instances.repair.recreateInstance  us-central1-a/instances/fancy-fe-1vqq  200          DONE    2019-09-12T11:47:14.627-07:00

לאחר זיהוי התיקון, Control+C (Command+S ב-Macintosh) כדי לצאת מפקודת השעון. בשלב הזה, קבוצת המכונות המנוהלות יוצרת את המכונה מחדש כדי לתקן אותה.

9. הסרת המשאבים

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

gcloud projects delete [PROJECT_ID]

כדי לאשר את המחיקה, מזינים 'Y'. כשמוצגת הנחיה לעשות זאת.

10. מעולה!

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