רמפה קשתית של מיקרו-שירות (microservice)

1. מבוא

עדכון אחרון:6 במאי 2021

Rumpus ברמת מיקרו-שירות (microservice)

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

ייתכן שאתם תוהים... אבל מה קורה אם מיקרו-שירות (microservice) "פועל" או קשת במיקרו-שירותים אחרים? מיקרו-שירות (microservice) יכול לקבל בקשות רשת (בדרך כלל באמצעות HTTP) ולהחזיר תגובות. יש 'מנהל אזור' שתשלח למיקרו-שירות (microservice) את המצב הנוכחי של הזירה, ואז המיקרו-שירות (microservice) תגיב באמצעות פקודה שמציינת מה לעשות.

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

איך זה עובד

נפתח מיקרו-שירות (microservice) בכל טכנולוגיה שרוצים (או לבחור מבין האפשרויות הבאות: Go, Java, Kotlin, Scala, NodeJS או Python), ולאחר מכן פורסים את המיקרו-שירות (microservice) ב-Google Cloud. אחרי הפריסה, צריך להודיע לנו את כתובת ה-URL של המיקרו-שירות (microservice) ואז להוסיף אותו לזירה.

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

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

כך נראית אצטדיון בעבר:

20628e6bd442bd11.png

דוגמה ל-Battle One ארנה

מחלוקות משתנות

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

צפייה בקרב

כדאי לראות את הזירה בשידור חי כדי לראות את הביצועים של המיקרו-שירות (microservice) בקרב.

Battle API

כדי לעבוד עם מנהל/ת התחום שלנו, המיקרו-שירות (microservice) שלכם יצטרך להטמיע API ספציפי כדי להשתתף בזירה. מנהל הזירה ישלח את מצב הזירה הנוכחי ב-HTTP POST לכתובת ה-URL שסיפקתם לנו, במבנה הבא של JSON:

{
  "_links": {
    "self": {
      "href": "https://YOUR_SERVICE_URL"
    }
  },
  "arena": {
    "dims": [4,3], // width, height
    "state": {
      "https://A_PLAYERS_URL": {
        "x": 0, // zero-based x position, where 0 = left
        "y": 0, // zero-based y position, where 0 = top
        "direction": "N", // N = North, W = West, S = South, E = East
        "wasHit": false,
        "score": 0
      }
      ... // also you and the other players
    }
  }
}

תגובת ה-HTTP חייבת להיות קוד סטטוס 200 (OK) עם גוף תגובה שמכיל את הצעד הבא, מקודדת כתו גדולה אחת של אחד או יותר מהערכים הבאים:

F <- move Forward
R <- turn Right
L <- turn Left
T <- Throw

זה הכול! בואו נראה איך פורסים מיקרו-שירות (microservice) ב-Cloud Run, שירות של Google Cloud להרצת מיקרו-שירותים (microservices) ואפליקציות אחרות.

2. התחברות ל-Google Cloud

כדי שתוכלו לפרוס את המיקרו-שירות (microservice) ב-Cloud Run, תצטרכו להתחבר ל-Google Cloud. אנו נזכה את החשבון שלך ולא תצטרך להזין פרטי כרטיס אשראי. בדרך כלל פחות בעייתי להשתמש בחשבון אישי (למשל, gmail.com) במקום בחשבון G Suite, כי לפעמים האדמינים ב-G Suite מונעים מהמשתמשים שלהם להשתמש בתכונות מסוימות של Google Cloud. בנוסף, מסוף האינטרנט שבו נשתמש אמור לפעול היטב עם Chrome או עם Firefox, אבל ייתכן שיהיו בו בעיות ב-Safari.

3. פריסת המיקרו-שירות (microservice)

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

בחירת טעימה בתור התחלה

אפשר להתחיל מדוגמאות רבות של מיקרו-שירות (microservice):

קוטלין מגף קפיץ

מקור

קוטלין Micronaut

מקור

קוטלין קורקוס

מקור

Java ו- מגף קפיץ

מקור

Java ו- קורקוס

מקור

Go

מקור

Node.js ו- אקספרס

מקור

Python ו- בקבוקון לשתייה חריפה

מקור

אחרי שמחליטים באיזו דוגמה להתחיל, לוחצים על Deploy on Cloud Run (פריסה ב-Cloud Run) לחצן למעלה. פעולה זו תפעיל את Cloud Shell (מסוף מבוסס-אינטרנט למכונה וירטואלית בענן) שבה יש לשכפל את המקור ואז ליצור חבילה שניתן לפרוס (תמונת קונטיינר של Docer). לאחר מכן תתבצע העלאה אל Google Container Registry ואז נפרס ב-Cloud Run.

כשמופיעה בקשה, מציינים את האזור us-central1.

בצילום המסך למטה מוצג הפלט של Cloud Shell לפיתוח ולפריסה של מיקרו-שירות (microservice)

d88e40430706a32b.png

מוודאים שהמיקרו-שירות (microservice) פועל

ב-Cloud Shell אתם יכולים לשלוח בקשה למיקרו-שירות (microservice) החדש שנפרס, ולהחליף את הכתובת YOUR_SERVICE_URL בכתובת ה-URL של השירות (שנמצאת ב-Cloud Shell אחרי השורה 'האפליקציה שלך פעילה כאן'):

curl -d '{
  "_links": {
    "self": {
      "href": "https://foo.com"
    }
  },
  "arena": {
    "dims": [4,3],
    "state": {
      "https://foo.com": {
        "x": 0,
        "y": 0,
        "direction": "N",
        "wasHit": false,
        "score": 0
      }
    }
  }
}' -H "Content-Type: application/json" -X POST -w "\n" \
  https://YOUR_SERVICE_URL

מחרוזת התגובה אמורה להופיע F, L, R או T.

4. בקשת הצטרפות בזירה

כדי להצטרף לרומפוס בצבעי הקשת, עליכם להצטרף לזירה. פותחים את הקטע rainbowrumpus.dev ולוחצים על 'הצטרפות' בזירה שבה תספקו את כתובת ה-URL של המיקרו-שירות (microservice).

5. יצרן ו פריסת השינויים

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

gcloud projects list

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

export PROJECT_ID=YOUR_PROJECT_ID

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

# Copy and paste ONLY ONE of these
export SAMPLE=kotlin-micronaut
export SAMPLE=kotlin-quarkus
export SAMPLE=kotlin-springboot
export SAMPLE=java-quarkus
export SAMPLE=java-springboot
export SAMPLE=go
export SAMPLE=nodejs
export SAMPLE=python

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

cloudshell edit cloudbowl-microservice-game/samples/$SAMPLE/README.md

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

f910c9ef7b51c406.png

Cloud Shell עם כלי העריכה כשהפרויקט לדוגמה פתוח

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

cd cloudbowl-microservice-game/samples/$SAMPLE

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

curl -d '{
  "_links": {
    "self": {
      "href": "https://foo.com"
    }
  },
  "arena": {
    "dims": [4,3],
    "state": {
      "https://foo.com": {
        "x": 0,
        "y": 0,
        "direction": "N",
        "wasHit": false,
        "score": 0
      }
    }
  }
}' -H "Content-Type: application/json" -X POST -w "\n" \
  http://localhost:8080

כשתהיו מוכנים לפרוס את השינויים, תצטרכו ליצור את הפרויקט ב-Cloud Shell באמצעות הפקודה pack. הפקודה הזו משתמשת ב-Buildpacks כדי לזהות את סוג הפרויקט, להדר אותו וליצור את הארטיפקט שניתן לפריסה (קובץ אימג' בקונטיינר של Docker).

# Make sure you are in a Cloud Shell tab where you set the PROJECT_ID
# and SAMPLE env vars. Otherwise, set them again.
pack build gcr.io/$PROJECT_ID/$SAMPLE \
  --path ~/cloudbowl-microservice-game/samples/$SAMPLE \
  --builder gcr.io/buildpacks/builder

עכשיו, אחרי שתיצרו את קובץ האימג' בקונטיינר, תוכלו להשתמש בפקודת Docer (ב-Cloud Shell) להעביר את קובץ האימג' בקונטיינר ל-Google Container Registry, כדי ש-Cloud Run יוכל לגשת אליו:

docker push gcr.io/$PROJECT_ID/$SAMPLE

עכשיו פורסים את הגרסה החדשה ב-Cloud Run:

gcloud run deploy $SAMPLE \
          --project=$PROJECT_ID \
          --platform=managed \
          --region=us-central1 \
          --image=gcr.io/$PROJECT_ID/$SAMPLE \
          --allow-unauthenticated

עכשיו הזירה תשתמש בגרסה החדשה שלך!

6. פיתוח מקומי (אופציונלי)

אתם יכולים לעבוד על הפרויקט באופן מקומי באמצעות סביבת פיתוח משולבת (IDE) משלכם:

  1. [ב-Cloud Shell] יוצרים ZIP של הדוגמה:
# Make sure the SAMPLE env var is still set. If not, re-set it.
cd ~/cloudbowl-microservice-game/samples
zip -r cloudbowl-sample.zip $SAMPLE
  1. [ב-Cloud Shell] מורידים את קובץ ה-ZIP למחשב:
cloudshell download-file cloudbowl-sample.zip
  1. [במחשב] מחלצים את הקובץ ואז יוצרים & בדיקת השינויים
  2. [במכונה שלכם] התקנת ה-CLI של gcloud
  3. [במכונה שלכם] התחברות ל-Google Cloud:
gcloud auth login
  1. [במכונה שלכם] מגדירים את משתני הסביבה PROJECT_ID ו-SAMPLE לאותם הערכים כמו ב-Cloud Shell.
  2. [במכונה שלכם] משתמשים ב-Cloud Build כדי ליצור את הקונטיינר (מספריית הפרויקט ברמה הבסיסית):
gcloud alpha builds submit . \
  --pack=image=gcr.io/$PROJECT_ID/$SAMPLE \
  --project=$PROJECT_ID
  1. [במכונה שלכם] פורסים את הקונטיינר החדש:
gcloud run deploy $SAMPLE \
  --project=$PROJECT_ID \
  --platform=managed \
  --region=us-central1 \
  --image=gcr.io/$PROJECT_ID/$SAMPLE \
  --allow-unauthenticated

7. פיתוח רציף (continuous delivery)

הגדרת SCM

אפשר להגדיר GitHub כדי לשתף פעולה עם הצוות במיקרו-שירות (microservice):

  1. התחברות ל-GitHub
  2. יצירת מאגר חדש
  3. אם אתם עובדים במחשב מקומי, אתם יכולים להשתמש בממשק שורת הפקודה git (CLI) או באפליקציית GUI של GitHub Desktop (Windows או Mac). אם אתם משתמשים ב-Cloud Shell, תצטרכו להשתמש ב-Git CLI. כדי לקבל את הקוד של המיקרו-שירות (microservice) ב-GitHub, צריך לפעול לפי ההוראות לשימוש ב-CLI או ב-GitHub Desktop.

דחיפת הקוד באמצעות git CLI

  1. פועלים לפי ההוראות ב-git over https עם אסימון גישה אישי.
  2. בוחרים 'מאגר' היקף
  3. הגדרת Git:
git config --global credential.helper \
  'cache --timeout=172800'
git config --global push.default current
git config --global user.email "YOUR@EMAIL"
git config --global user.name "YOUR NAME"
  1. הגדרת env vars של הארגון והמאגר ב-GitHub (https://github.com/ORG/REPO)
export GITHUB_ORG=YOUR_GITHUB_ORG
export GITHUB_REPO=YOUR_GITHUB_REPO
  1. דחיפת הקוד למאגר החדש
# Make sure the SAMPLE env var is still set. If not, re-set it.
cd ~/cloudbowl-microservice-game/samples/$SAMPLE
git init
git add .
git commit -m init
git remote add origin https://github.com/$GITHUB_ORG/$GITHUB_REPO.git
git branch -M main

# This will now ask for your GitHub username & password
# for the password use the personal access token
git push -u origin main
  1. אחרי שמבצעים שינויים, אפשר לשמור ולדחוף את השינויים ל-GitHub:
git add .
git status
git diff --staged
git commit -am "my changes"
git push

דחיפת קוד באמצעות שולחן עבודה של GitHub

  1. מורידים את הקוד לפי ההוראות שמפורטות ביעד "פיתוח מקומי" הקודם שיעור Lab
  2. התקנת GitHub Desktop, הפעלה והתחברות
  3. שכפול המאגר החדש שיצרתם

cf7f38c7c86a91cd.png

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

5f3c1552e30ad7c5.png

  1. פרסום ההסתעפות הראשית ב-GitHub

הגדרת פריסה רציפה (CD) של Cloud Run

באמצעות הגדרת SCM ב-GitHub, אפשר עכשיו להגדיר continuous Delivery כך שבכל פעם שהתחייבויות חדשות יועברו להסתעפות main, Cloud Build ייצור ויתפרס באופן אוטומטי את השינויים. אפשר גם להוסיף אינטגרציה רציפה (CI) שמריצה את הבדיקות לפני הפריסה, אבל השלב הזה נשאר כפי תרגול כי הדוגמאות המקוריות לא מכילות בדיקות.

  1. במסוף Cloud, נכנסים לשירות Cloud Run.
  2. לוחצים על 'הגדרת חלוקה מתמשכת'. לחצן
  3. אימות מול GitHub ובוחרים את מאגר המיקרו-שירות (microserivce)

a3b5692f178869bc.png

  1. בוחרים את המאגר שלכם ב-GitHub ומגדירים את ההסתעפות כ: ^main$

338f1c00f33d2f65.png

  1. איך מגדירים את סוג ה-Build כדי להשתמש ב-Buildpacks
  2. לוחצים על 'שמירה' כדי להגדיר 'פריסה רציפה'.

8. ניראות (observability)

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

מדדים

  1. מחפשים את השירות שלכם ברשימת שירותי Cloud Run.
  2. אפשר ללחוץ על שם השירות כדי לעבור למרכז הבקרה של המדדים שלו

8491b8ec6bc5b4db.png

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

f0d666d8f4221d45.png

יומנים

פלט STDOUT משירותים נשלח למערכת Google Cloud Logging. אפשר לגשת לתצוגת יומן בסיסית מדף ניהול השירות של Cloud Run, למשל:

40058a82c9299cff.png

ביומני Cloud Run אפשר לסנן לפי חומרה ולסנן את היומנים. כדי ליהנות מגמישות רבה יותר, אפשר ללחוץ על 186fdb0e6d39a6ca.png

התראות

  1. יוצרים כתובת URL של בדיקת חימום לשירות.
  2. לאתחול אביב, פשוט מוסיפים את התלות הבאה:
org.springframework.boot:spring-boot-starter-actuator
  1. יוצרים או מעדכנים את השדה src/main/resources/application.properties ומשביתים את בדיקת מרחב הדיסק:
management.health.diskspace.enabled=false
  1. יוצרים התראה על זמן פעולה תקינה ומציינים את הפרוטוקול, שם המארח והנתיב. באתחול אביב, הנתיב הוא: /actuator/health
  2. בדיקת ההתראה

6948d13b263bf573.png

  1. יצירת ההתראה

9. מזל טוב

כל הכבוד! פיתחתם ופרסתם בהצלחה מיקרו-שירות (microservice) שיכול להילחם במיקרו-שירותים (microservices) אחרים! בהצלחה!

מסמכי עזר