חיבור של Cloud Spanner עם GKE Autopilot

1. מבוא

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

GKE Autopilot הוא מצב פעולה ב-GKE, שבו Google מנהלת את תצורת האשכול, כולל הצמתים, ההתאמה לעומס (scaling), האבטחה והגדרות אחרות שנקבעו מראש כדי לפעול בהתאם לשיטות המומלצות. לדוגמה, GKE Autopilot מאפשר ל-Workload Identity לנהל את הרשאות השירות.

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

בשיעור ה-Lab הזה תיצרו פרויקט ותפעילו את Cloud Shell. לאחר מכן תפרסו את התשתית באמצעות Terraform.

בסיום התהליך, תוכלו להשתמש ב-Cloud Build וב-Cloud Deploy כדי לבצע העברה ראשונית של סכימה למסד הנתונים של Games, לפרוס את השירותים לקצה העורפי ואז לפרוס את עומסי העבודה.

השירותים ב-Codelab הזה זהים ל-codelab ב-Cloud Spanner 'תחילת העבודה עם פיתוח משחקים'. מעבר על Codelab הזה אינו חובה כדי שהשירותים יפעלו ב-GKE ויתחברו ל-Spanner. אבל אם אתם מעוניינים בפרטים נוספים על השירותים הספציפיים שעובדים ב-Spanner, כדאי לבדוק את זה.

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

בשלב האחרון מנקים את המשאבים שנוצרו בשיעור ה-Lab הזה.

מה תפַתחו

במסגרת שיעור ה-Lab הזה:

• הקצאת התשתית באמצעות Terraform
• יצירת סכימת מסד הנתונים באמצעות תהליך העברת סכימה ב-Cloud Build
• פריסה של ארבעת השירותים לקצה העורפי של Golang שמשתמשים ב-Workload Identity כדי להתחבר ל-Cloud Spanner
• פריסה של ארבעת שירותי עומסי העבודה שמשמשים להדמיה של עומס על שירותים לקצה העורפי.

מה תלמדו

• איך להקצות צינורות עיבוד נתונים ל-GKE Autopilot, Cloud Spanner ו-Cloud Deploy באמצעות Terraform
• איך Workload Identity מאפשר לשירותים ב-GKE להתחזות לחשבונות שירות כדי לגשת להרשאות IAM לעבודה עם Cloud Spanner
• איך ליצור עומס דמוי-ייצור ב-GKE וב-Cloud Spanner באמצעות Locust.io

מה נדרש

• פרויקט ב-Google Cloud שמחובר לחשבון לחיוב.
• דפדפן אינטרנט כמו Chrome או Firefox.

2. הגדרה ודרישות

יצירת פרויקט

אזהרה: ה-Codelab הזה מבצע שינויים בפרויקט. מומלץ מאוד להגדיר פרויקט ייעודי ל-Codelab הזה.

אם אין לכם עדיין חשבון Google (Gmail או Google Apps), עליכם ליצור חשבון. נכנסים למסוף Google Cloud Platform ( console.cloud.google.com) ויוצרים פרויקט חדש.

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

ולוחצים על New PROJECT (פרויקט חדש) בתיבת הדו-שיח שמתקבלת כדי ליצור פרויקט חדש:

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

בתיבת הדו-שיח הבאה ליצירת פרויקט תוכלו להזין את פרטי הפרויקט החדש:

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

בשלב הבא, אם עדיין לא עשית זאת, יהיה עליך להפעיל את החיוב ב-Developers Console כדי להשתמש במשאבים של Google Cloud ולהפעיל את Cloud Spanner API.

ההרצה של קוד ה-Codelab הזה לא אמורה לעלות לך יותר מכמה דולרים, אבל הוא יכול להיות גבוה יותר אם תחליטו להשתמש ביותר משאבים או אם תשאירו אותם פועלים (עיינו בקטע 'ניקוי' בסוף המסמך). התמחור ב-Google Cloud Spanner מתועד כאן, וה-GKE Autopilot מתועד כאן.

משתמשים חדשים ב-Google Cloud Platform זכאים לתקופת ניסיון בחינם בשווי 300$, שמאפשרת ל-Codelab הזה בחינם לגמרי.

הגדרת Cloud Shell

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

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

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

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

gcloud auth list

פלט הפקודה

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

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

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 במכונה משלכם, ההגדרות נשמרות במעבר בין סשנים. אבל אם אתם מריצים אותו ב-Cloud Shell, אתם צריכים לחזור על ההגדרות בכל סשן חדש ובכל התחברות מחדש.

להורדת הקוד

אתם יכולים להוריד את הקוד לשיעור ה-Lab הזה ב-Cloud Shell:

git clone https://github.com/cloudspannerecosystem/spanner-gaming-sample.git

פלט הפקודה

Cloning into 'spanner-gaming-sample'...
*snip*

ה-Codelab הזה מבוסס על גרסת v0.1.3, לכן חשוב לבדוק את התג הזה:

cd spanner-gaming-sample
git fetch --all --tags

# Check out v0.1.3 release
git checkout tags/v0.1.3 -b v0.1.3-branch

פלט הפקודה

Switched to a new branch 'v0.1.3-branch'

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

export DEMO_HOME=$(pwd)

סיכום

בשלב הזה הגדרתם פרויקט חדש, הפעלתם את Cloud Shell, והורדתם את הקוד של שיעור ה-Lab הזה.

השלב הבא

בשלב הבא, תקצה את התשתית באמצעות Terraform.

3. אספקת התשתית

סקירה כללית

כשהפרויקט מוכן, הגיע הזמן להפעיל את התשתית. זה כולל רשתות VPC, Cloud Spanner, GKE Autopilot, Artifact Registry לאחסון תמונות שירוצו ב-GKE, צינורות עיבוד נתונים של Cloud Deploy לשירותים לקצה העורפי ועומסי עבודה (workloads), וגם את חשבונות השירות והרשאות ה-IAM לשימוש בשירותים האלה.

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

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

• vpc.tf
• backend_gke.tf
• spanner.tf
• artifact_registry.tf
• pipelines.tf
• iam.tf

הגדרת Terraform

ב-Cloud Shell, עוברים לספרייה infrastructure ומאתחלים את Terraform:

cd $DEMO_HOME/infrastructure
terraform init

פלט הפקודה

Initializing the backend...

Initializing provider plugins...
*snip*
Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.

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

cp  terraform.tfvars.sample terraform.tfvars
# edit gcp_project using the project environment variable
sed -i "s/PROJECT/$GOOGLE_CLOUD_PROJECT/" terraform.tfvars

הערה: באמצעות משתני ברירת המחדל, התשתית תפרוס באזור us-central1.

הקצאת התשתית

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

הגיע הזמן להקצות את התשתית!

terraform apply
# review the list of things to be created
# type 'yes' when asked

פלט הפקודה

Plan: 46 to add, 0 to change, 0 to destroy.

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

google_project_service.project["container.googleapis.com"]: Creating...
*snip*
Apply complete! Resources: 46 added, 0 changed, 0 destroyed.

הערה: השלמת ההגדרה של התשתית תימשך כמה דקות.

הערה:יכול להיות שתקבלו הערה על ההוצאה משימוש של default_secret_name ב-Kubernetes. אפשר להתעלם מההודעה הזו.

בדיקת הפריטים שנוצרו

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

הערה: יכול להיות שהמשאבים הבאים לא יופיעו עד לסיום השלב terraform apply.

Cloud Spanner

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

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

הערה: כאן תראו מכונה מפורטת שפועלת ב-100 יחידות עיבוד (100 PU), עם ההגדרה האזורית us-central.

GKE Autopilot

בשלב הבא, כדי לנסות את GKE, עוברים לתפריט ההמבורגר ולוחצים על Kubernetes Engine => Clusters. כאן יופיע האשכול sample-games-gke שפועל במצב Autopilot.

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

Artifact Registry

עכשיו מומלץ לראות איפה התמונות יאוחסנו. אז לוחצים על תפריט ההמבורגרים ומוצאים את Artifact Registry=>Repositories. Artifact Registry נמצא בקטע CI/CD בתפריט.

כאן מופיע קובץ הרישום של Docker בשם spanner-game-images. בינתיים, השדה הזה יהיה ריק.

Cloud Deploy

Cloud Deploy הוא המקום שבו נוצרו צינורות עיבוד הנתונים כדי לאפשר ל-Cloud Build לספק שלבים לבניית התמונות ולאחר מכן לפרוס אותן באשכול GKE.

עוברים לתפריט ההמבורגר ומאתרים את Cloud Deploy, שנמצא גם בקטע CI/CD בתפריט.

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

IAM

לבסוף, עיינו בדף IAM במסוף Cloud כדי לאמת את חשבונות השירות שנוצרו. עוברים לתפריט ההמבורגרים ומוצאים את IAM and Admin=>Service accounts. הוא אמור להיראות כך:

יש שישה חשבונות שירות שנוצרו על ידי Terraform בסך הכול:

• חשבון השירות המשמש כברירת מחדל במחשב. הערך הזה לא בשימוש ב-Codelab הזה.
• חשבון Cloudbuild-cicd משמש לביצוע השלבים ב-Cloud Build וב-Cloud Deploy.
• ארבעה 'אפליקציה' חשבונות שמשמשים את שירותי הקצה העורפי שלנו לאינטראקציה עם Cloud Spanner.

בשלב הבא צריך להגדיר את kubectl לאינטראקציה עם אשכול GKE.

הגדרת kubectl

# Name of GKE cluster from terraform.tfvars file
export GKE_CLUSTER=sample-game-gke 

# get GKE credentials
gcloud container clusters get-credentials $GKE_CLUSTER --region us-central1

# Check that no errors occur
kubectl get serviceaccounts

פלט הפקודה

#export GKE_CLUSTER=sample-game-gke

# gcloud container clusters get-credentials $GKE_CLUSTER --region us-central1
Fetching cluster endpoint and auth data.
kubeconfig entry generated for sample-game-gke.

# kubectl get serviceaccounts
NAME              SECRETS   AGE
default           0         37m
item-app          0         35m
matchmaking-app   0         35m
profile-app       0         35m
tradepost-app     0         35m

הערה: הבדיקה החשובה היא שלא אמורה להיות שגיאת אימות ב-kubectl.

סיכום

נהדר! הצלחתם להקצות מכונה של Cloud Spanner, אשכול GKE Autopilot, והכול ב-VPC לרשתות פרטיות.

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

לבסוף, חשבונות השירות נוצרו והוגדרו לפעול עם Workload Identity, כדי ששירותים לקצה העורפי יוכלו להשתמש ב-Cloud Spanner.

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

השלב הבא

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

4. יצירת הסכימה של מסד הנתונים

סקירה כללית

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

אם תסתכלו בקבצים בספרייה $DEMO_HOME/schema/migrations ממאגר ההדגמות, תראו סדרה של קובצי .sql שמגדירים את הסכימה שלנו. פעולה זו מחקה מחזור פיתוח שבו מתבצע מעקב אחר שינויים בסכימה במאגר עצמו, וניתן לקשר אותו לתכונות מסוימות של האפליקציות.

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

Cloud Build

בקובץ $DEMO_HOME/schema/cloudbuild.yaml מתוארים השלבים שיש לבצע:

serviceAccount: projects/${PROJECT_ID}/serviceAccounts/cloudbuild-cicd@${PROJECT_ID}.iam.gserviceaccount.com
steps:
- name: gcr.io/cloud-builders/curl
 id: fetch-wrench
 args: ['-Lo', '/workspace/wrench.tar.gz', 'https://github.com/cloudspannerecosystem/wrench/releases/download/v1.4.1/wrench-1.4.1-linux-amd64.tar.gz' ]

- name: gcr.io/cloud-builders/gcloud
 id: migrate-spanner-schema
 entrypoint: sh
 args:
 - '-xe'
 - '-c'
 - |
   tar -xzvf wrench.tar.gz

   chmod +x /workspace/wrench

   # Assumes only a single spanner instance and database. Fine for this demo in a dedicated project
   export SPANNER_PROJECT_ID=${PROJECT_ID}
   export SPANNER_INSTANCE_ID=$(gcloud spanner instances list | tail -n1 | awk '{print $1}')
   export SPANNER_DATABASE_ID=$(gcloud spanner databases list --instance=$$SPANNER_INSTANCE_ID | tail -n1 | awk '{print $1}')

   if [ -d ./migrations ]; then
     /workspace/wrench migrate up --directory .
   else
     echo "[Error] Missing migrations directory"
   fi
timeout: 600s

יש בעיקרון שני שלבים:

• הורדת מפתח ברגים לסביבת העבודה של Cloud Build
• הפעלת העברת מפתח הברגים

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

ל-Cloud Build יש אפשרות לבצע את השינויים האלה כי הוא פועל כחשבון השירות cloudbuild-cicd@${PROJECT_ID}.iam.gserviceaccount.com:

serviceAccount: projects/${PROJECT_ID}/serviceAccounts/cloudbuild-cicd@${PROJECT_ID}.iam.gserviceaccount.com

לחשבון השירות הזה יש את התפקיד spanner.databaseUser שנוסף על ידי Terraform, שמאפשר לחשבון השירות לעדכן DDL.

העברות סכימה

יש חמישה שלבי העברה שמבוצעים על סמך הקבצים שבספרייה $DEMO_HOME/schema/migrations. דוגמה לקובץ 000001.sql שיוצר טבלת players ואינדקסים:

CREATE TABLE players (
   playerUUID STRING(36) NOT NULL,
   player_name STRING(64) NOT NULL,
   email STRING(MAX) NOT NULL,
   password_hash BYTES(60) NOT NULL,
   created TIMESTAMP,
   updated TIMESTAMP,
   stats JSON,
   account_balance NUMERIC NOT NULL DEFAULT (0.00),
   is_logged_in BOOL,
   last_login TIMESTAMP,
   valid_email BOOL,
   current_game STRING(36)
) PRIMARY KEY (playerUUID);

CREATE UNIQUE INDEX PlayerAuthentication ON players(email) STORING(password_hash);
CREATE UNIQUE INDEX PlayerName ON players(player_name);
CREATE INDEX PlayerGame ON players(current_game);

שליחת הסכימה

כדי לשלוח את ה-build כדי לבצע את העברת הסכימה, עוברים לספרייה schema ומריצים את הפקודה הבאה ב-gcloud:

cd $DEMO_HOME/schema
gcloud builds submit --config=cloudbuild.yaml

פלט הפקודה

Creating temporary tarball archive of 8 file(s) totalling 11.2 KiB before compression.
Uploading tarball of [.] to [gs://(project)_cloudbuild/source/(snip).tgz]
Created [https://cloudbuild.googleapis.com/v1/projects/(project)/locations/global/builds/7defe982-(snip)].
Logs are available at [ https://console.cloud.google.com/cloud-build/builds/7defe982-(snip)?project=(snip) ].

gcloud builds submit only displays logs from Cloud Storage. To view logs from Cloud Logging, run:
gcloud beta builds submit

ID: 7defe982-(snip)
CREATE_TIME: (created time)
DURATION: 3M11S
SOURCE: gs://(project)_cloudbuild/source/(snip).tgz
IMAGES: -
STATUS: SUCCESS

הערה: הפריסה של העברת הסכימה תימשך כמה דקות

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

הערה: שלבי ההעברה תואמים למספר הקבצים בספרייה $DEMO_HOME/schema/migrations.

סיכום

בשלב הזה השתמשתם ב-Cloud Build כדי לשלוח את ההעברה הראשונית של הסכימה שבה הוחלו 5 פעולות DDL שונות. הפעולות האלה מייצגות מתי נוספו תכונות שנדרש בהן שינויים בסכימה של מסד הנתונים.

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

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

השלב הבא

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

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

סקירה כללית

השירותים לקצה העורפי ב-Codelab הזה הם ממשקי API של golang ב-REST שמייצגים ארבעה שירותים שונים:

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

כדי לקבל מידע נוסף על השירותים האלה, אפשר להיכנס ל-codelab ב-Cloud Spanner 'תחילת העבודה עם פיתוח משחקים'. למטרות שלנו, אנחנו רוצים שהשירותים האלה יפעלו באשכול GKE Autopilot.

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

Workload Identity מאפשר לחשבון שירות של kubernetes להתחזות לשירותים חשבון שירות הענן של google לפי השלבים הבאים ב-Terraform:

• יצירת המשאב של השירות לחשבון שירות Google Cloud (GSA)
• מקצים את התפקיד databaseUser לחשבון השירות הזה.
• מקצים את התפקיד workloadIdentityUser לחשבון השירות הזה.
• יצירת חשבון שירות ב-Kubernetes (KSA) שמפנה ל-Google Analytics

תרשים גס ייראה כך:

הערה: לכל שירות יש GSA ו-KSA משלו כדי להפריד בין ההרשאות ולפעול בהתאם לעקרון ההרשאות המינימליות.

Terraform יצרה עבורך את חשבונות השירות ואת חשבונות השירות של Kubernetes. ניתן גם לבדוק את חשבונות השירות של Kubernetes באמצעות kubectl:

# kubectl get serviceaccounts
NAME              SECRETS   AGE
default           0         37m
item-app          0         35m
matchmaking-app   0         35m
profile-app       0         35m
tradepost-app     0         35m

כך ה-build פועל:

• Terraform יצרה קובץ $DEMO_HOME/backend_services/cloudbuild.yaml שנראה בערך כך:

serviceAccount: projects/${PROJECT_ID}/serviceAccounts/cloudbuild-cicd@${PROJECT_ID}.iam.gserviceaccount.com
steps:

#
# Building of images
#
 - name: gcr.io/cloud-builders/docker
   id: profile
   args: ["build", ".", "-t", "${_PROFILE_IMAGE}"]
   dir: profile
   waitFor: ['-']
 - name: gcr.io/cloud-builders/docker
   id: matchmaking
   args: ["build", ".", "-t", "${_MATCHMAKING_IMAGE}"]
   dir: matchmaking
   waitFor: ['-']
 - name: gcr.io/cloud-builders/docker
   id: item
   args: ["build", ".", "-t", "${_ITEM_IMAGE}"]
   dir: item
   waitFor: ['-']
 - name: gcr.io/cloud-builders/docker
   id: tradepost
   args: ["build", ".", "-t", "${_TRADEPOST_IMAGE}"]
   dir: tradepost
   waitFor: ['-']

#
# Deployment
#
 - name: gcr.io/google.com/cloudsdktool/cloud-sdk
   id: cloud-deploy-release
   entrypoint: gcloud
   args:
     [
       "deploy", "releases", "create", "${_REL_NAME}",
       "--delivery-pipeline", "sample-game-services",
       "--skaffold-file", "skaffold.yaml",
       "--skaffold-version", "1.39",
       "--images", "profile=${_PROFILE_IMAGE},matchmaking=${_MATCHMAKING_IMAGE},item=${_ITEM_IMAGE},tradepost=${_TRADEPOST_IMAGE}",
       "--region", "us-central1"
     ]

artifacts:
 images:
   - ${_REGISTRY}/profile
   - ${_REGISTRY}/matchmaking
   - ${_REGISTRY}/item
   - ${_REGISTRY}/tradepost

substitutions:
 _PROFILE_IMAGE: ${_REGISTRY}/profile:${BUILD_ID}
 _MATCHMAKING_IMAGE: ${_REGISTRY}/matchmaking:${BUILD_ID}
 _ITEM_IMAGE: ${_REGISTRY}/item:${BUILD_ID}
 _TRADEPOST_IMAGE: ${_REGISTRY}/tradepost:${BUILD_ID}
 _REGISTRY: us-docker.pkg.dev/${PROJECT_ID}/spanner-game-images
 _REL_NAME: rel-${BUILD_ID:0:8}
options:
 dynamic_substitutions: true
 machineType: E2_HIGHCPU_8
 logging: CLOUD_LOGGING_ONLY

• הפקודה של Cloud Build קוראת את הקובץ הזה ופועלים לפי השלבים שמופיעים. ראשית, הוא יוצר את קובצי האימג' של השירות. לאחר מכן, היא תריץ פקודת gcloud deploy create. נקרא הקובץ $DEMO_HOME/backend_services/skaffold.yaml, שמגדיר איפה נמצא כל קובץ פריסה:

apiVersion: skaffold/v2beta29
kind: Config
deploy:
 kubectl:
   manifests:
     - spanner_config.yaml
     - profile/deployment.yaml
     - matchmaking/deployment.yaml
     - item/deployment.yaml
     - tradepost/deployment.yaml

• Cloud Deploy צריך לפעול לפי ההגדרות של קובץ deployment.yaml בכל אחד מהשירותים. קובץ הפריסה של השירות מכיל את המידע ליצירת שירות, שהוא במקרה הזה clusterIP שפועל על יציאה 80.

" סוג ClusterIP מונע מקבוצות השירות לקצה העורפי כתובת IP חיצונית, כך שרק לישויות שיכולות להתחבר לרשת GKE הפנימית תהיה גישה לשירותים לקצה העורפי. השירותים האלה לא צריכים להיות נגישים באופן ישיר לשחקנים כי הם ניגשים לנתונים של Spanner ומשנים אותם.

apiVersion: v1
kind: Service
metadata:
 name: profile
spec:
 type: ClusterIP
 selector:
   app: profile
 ports:
 - port: 80
   targetPort: 80

דוגמה: $DEMO_HOME/backend_services/profile/deployment.yaml

בנוסף ליצירת שירות Kubernetes, הפריסה של Cloud Deploy יוצרת גם פריסה של Kubernetes. נבחן את סעיף הפריסה של השירות profile:

---
apiVersion: apps/v1
kind: Deployment
metadata:
 name: profile
spec:
 replicas: 2 # EDIT: Number of instances of deployment
 selector:
   matchLabels:
     app: profile
 template:
   metadata:
     labels:
       app: profile
   spec:
     serviceAccountName: profile-app
     containers:
     - name: profile-service
       image: profile
       ports:
         - containerPort: 80
       envFrom:
         - configMapRef:
             name: spanner-config
       env:
         - name: SERVICE_HOST
           value: "0.0.0.0"
         - name: SERVICE_PORT
           value: "80"
       resources:
         requests:
           cpu: "1"
           memory: "1Gi"
           ephemeral-storage: "100Mi"
         limits:
           cpu: "1"
           memory: "1Gi"
           ephemeral-storage: "100Mi"

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

replicas: 2 # EDIT: Number of instances of deployment

לאחר מכן נראה באיזה חשבון שירות יש להפעיל את האפליקציה ובאיזו תמונה יש להשתמש. הם תואמים לחשבון השירות של Kubernetes שנוצר מ-Terraform ולתמונה שנוצרה בשלב ב-Cloud Build.

spec:
  serviceAccountName: profile-app
  containers:
    - name: profile-service
      image: profile

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

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

apiVersion: v1
kind: ConfigMap
metadata:
  name: spanner-config
data:
  SPANNER_PROJECT_ID: ${project_id}
  SPANNER_INSTANCE_ID: ${instance_id}
  SPANNER_DATABASE_ID: ${database_id}

הערה: הקובץ spanner_config.yaml נוצר על ידי Terraform על סמך files/backend_services/spanner-config.yaml.tpl.

ports:
  - containerPort: 80
envFrom:
  - configMapRef:
    name: spanner-config
env:
  - name: SERVICE_HOST
    value: "0.0.0.0"
  - name: SERVICE_PORT
    value: "80"

SERVICE_HOST ו-SERVICE_PORT הם משתני סביבה נוספים שנדרשים על ידי השירות כדי לדעת לאן לקשר.

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

resources:
  requests:
    cpu: "1"
    memory: "1Gi"
    ephemeral-storage: "100Mi"
  limits:
    cpu: "1"
    memory: "1Gi"
    ephemeral-storage: "100Mi"

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

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

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

cd $DEMO_HOME/backend_services
gcloud builds submit --config=cloudbuild.yaml

פלט הפקודה

Creating temporary tarball archive of 66 file(s) totalling 864.6 KiB before compression.
Uploading tarball of [.] to [gs://(project)_cloudbuild/source/(snip).tgz]
Created [https://cloudbuild.googleapis.com/v1/projects/(project)/locations/global/builds/30207dd1-(snip)].
Logs are available at [ https://console.cloud.google.com/cloud-build/builds/30207dd1-(snip)?project=(snip) ].

gcloud builds submit only displays logs from Cloud Storage. To view logs from Cloud Logging, run:
gcloud beta builds submit

ID: 30207dd1-(snip)
CREATE_TIME: (created time)
DURATION: 3M17S
SOURCE: gs://(project)_cloudbuild/source/(snip).tgz
IMAGES: us-docker.pkg.dev/(project)/spanner-game-images/profile:30207dd1-(snip) (+3 more)
STATUS: SUCCESS

הערה: תהליך העיבוד והפריסה של ה-build והפריסה יימשך כמה דקות.

בניגוד לפלט של השלב schema migration, הפלט של ה-build הזה מצביע על כך שנוצרו כמה תמונות. הקבצים האלה יישמרו במאגר של Artifact Registry.

בפלט של השלב gcloud build יהיה קישור למסוף Cloud. כדאי להציץ בקטעים האלה.

הערה: גם אם מקבלים מ-Cloud Build את ההודעה 'הצלחה', הפריסה לא תושלם עד לרצפים של המערכת.

אחרי שמקבלים את הודעת ההצלחה מ-Cloud Build, צריך לעבור אל Cloud Deploy ואז לצינור עיבוד הנתונים sample-game-services כדי לעקוב אחרי התקדמות הפריסה.

אחרי שהשירותים פרוסים, אפשר לבדוק את kubectl כדי לראות את ה-Pods סטטוס:

kubectl get pods

פלט הפקודה

NAME                           READY   STATUS    RESTARTS   AGE
item-6b9d5f678c-4tbk2          1/1     Running   0          83m
matchmaking-5bcf799b76-lg8zf   1/1     Running   0          80m
profile-565bbf4c65-kphdl       1/1     Running   0          83m
profile-565bbf4c65-xw74j       1/1     Running   0          83m
tradepost-68b87ccd44-gw55r     1/1     Running   0          79m

אחרי זה צריך לבדוק את השירותים כדי לראות את ClusterIP בפעולה:

kubectl get services

פלט הפקודה

NAME          TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
item          ClusterIP   10.172.XXX.XXX   <none>        80/TCP    84m
kubernetes    ClusterIP   10.172.XXX.XXX   <none>        443/TCP   137m
matchmaking   ClusterIP   10.172.XXX.XXX   <none>        80/TCP    84m
profile       ClusterIP   10.172.XXX.XXX   <none>        80/TCP    84m
tradepost     ClusterIP   10.172.XXX.XXX   <none>        80/TCP    84m

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

אפשר גם לנווט לממשק המשתמש של GKE במסוף Cloud כדי לראות את Workloads, את הServices ואת ה-ConfigMaps.

עומסי עבודה (workloads)

שירותים

ConfigMaps

סיכום

בשלב הזה פרסתם את ארבעת השירותים לקצה העורפי ל-GKE Autopilot. הצלחתם להריץ את השלב ב-Cloud Build ולבדוק את ההתקדמות ב-Cloud Deploy וב-Kubernetes במסוף Cloud.

למדתם גם איך השירותים האלה נעזרים ב-Workload Identity כדי להתחזות לחשבון שירות שיש לו את ההרשאות המתאימות לקריאה ולכתיבה של נתונים במסד הנתונים של Spanner.

השלבים הבאים

בקטע הבא, פורסים את עומסי העבודה.

6. פריסה של עומסי העבודה

סקירה כללית

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

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

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

יש קבצים לתהליך של Cloud Build:

• $DEMO_HOME/workloads/cloudbuild.yaml (נוצר על ידי Terraform)
• $DEMO_HOME/workloads/skaffold.yaml
• קובץ deployment.yaml לכל עומס עבודה

אפשר לעיין בקובץ cloudbuild.yaml ו-skaffold.yaml. הם כמעט זהים לשירותים לקצה העורפי, אבל הספריות והשמות של התמונות שונים.

הקבצים של עומס העבודה deployment.yaml נראים מעט שונים מקובצי הפריסה של השירות לקצה העורפי.

הנה דוגמה מתוך matchmaking-workload:

apiVersion: v1
kind: Service
metadata:
 name: matchmaking-workload
spec:
 type: LoadBalancer
 selector:
   app: matchmaking-workload
 ports:
 - port: 8089
   targetPort: 8089
---
apiVersion: apps/v1
kind: Deployment
metadata:
 name: matchmaking-workload
spec:
 replicas: 1 # EDIT: Number of instances of deployment
 selector:
   matchLabels:
     app: matchmaking-workload
 template:
   metadata:
     labels:
       app: matchmaking-workload
   spec:
     serviceAccountName: default
     containers:
     - name: matchmaking-workload
       image: matchmaking-workload
       ports:
         - containerPort: 8089
       resources:
         requests:
           cpu: "500m"
           memory: "512Mi"
           ephemeral-storage: "100Mi"
         limits:
           cpu: "500m"
           memory: "512Mi"
           ephemeral-storage: "100Mi"

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

ה-Load Balancer יספק כתובת IP חיצונית שאפשר להשתמש בה כדי להתחבר לעומס העבודה.

apiVersion: v1
kind: Service
metadata:
 name: matchmaking-workload
spec:
 type: LoadBalancer
 selector:
   app: matchmaking-workload
 ports:
 - port: 8089
   targetPort: 8089

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

replicas: 1 

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

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

spec:
  serviceAccountName: default
  containers:
    - name: matchmaking-workload
      image: matchmaking-workload
  ports:
    - containerPort: 8089

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

כדאי לפרוס את עומסי העבודה!

פריסה של עומסי העבודה

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

cd $DEMO_HOME/workloads
gcloud builds submit --config=cloudbuild.yaml

פלט הפקודה

Creating temporary tarball archive of 18 file(s) totalling 26.2 KiB before compression.
Some files were not included in the source upload.

Check the gcloud log [/tmp/tmp.4Z9EqdPo6d/logs/(snip).log] to see which files and the contents of the
default gcloudignore file used (see `$ gcloud topic gcloudignore` to learn
more).

Uploading tarball of [.] to [gs://(project)_cloudbuild/source/(snip).tgz]
Created [https://cloudbuild.googleapis.com/v1/projects/(project)/locations/global/builds/(snip)].
Logs are available at [ https://console.cloud.google.com/cloud-build/builds/0daf20f6-(snip)?project=(snip) ].

gcloud builds submit only displays logs from Cloud Storage. To view logs from Cloud Logging, run:
gcloud beta builds submit

ID: 0daf20f6-(snip)
CREATE_TIME: (created_time)
DURATION: 1M41S
SOURCE: gs://(project)_cloudbuild/source/(snip).tgz
IMAGES: us-docker.pkg.dev/(project)/spanner-game-images/profile-workload:0daf20f6-(snip) (+4 more)
STATUS: SUCCESS

הערה: תהליך העיבוד והפריסה של ה-build והפריסה יימשך כמה דקות.

חשוב לבדוק את היומנים של Cloud Build ואת צינור עיבוד הנתונים של Cloud Deploy במסוף Cloud כדי לבדוק את הסטטוס. לעומסי העבודה, צינור עיבוד הנתונים של Cloud Deploy הוא sample-game-workloads:

בסיום הפריסה, בודקים את הסטטוס עם kubectl ב-Cloud Shell:

kubectl get pods

פלט הפקודה

NAME                                    READY   STATUS    RESTARTS   AGE
game-workload-7ff44cb657-pxxq2          1/1     Running   0          12m
item-6b9d5f678c-cr29w                   1/1     Running   0          9m6s
item-generator-7bb4f57cf8-5r85b         1/1     Running   0          12m
matchmaking-5bcf799b76-lg8zf            1/1     Running   0          117m
matchmaking-workload-76df69dbdf-jds9z   1/1     Running   0          12m
profile-565bbf4c65-kphdl                1/1     Running   0          121m
profile-565bbf4c65-xw74j                1/1     Running   0          121m
profile-workload-76d6db675b-kzwng       1/1     Running   0          12m
tradepost-68b87ccd44-gw55r              1/1     Running   0          116m
tradepost-workload-56c55445b5-b5822     1/1     Running   0          12m

אחרי זה צריך לבדוק את שירותי עומסי העבודה כדי לראות את LoadBalancer בפעולה:

kubectl get services 

פלט הפקודה

NAME                   TYPE          CLUSTER-IP  EXTERNAL-IP     PORT(S)        AGE
game-workload          LoadBalancer  *snip*      35.XX.XX.XX   8089:32483/TCP   12m
item                   ClusterIP     *snip*      <none>         80/TCP          121m
item-generator         LoadBalancer  *snip*      34.XX.XX.XX   8089:32581/TCP   12m
kubernetes             ClusterIP     *snip*      <none>          443/TCP        174m
matchmaking            ClusterIP     *snip*      <none>          80/TCP         121m
matchmaking-workload   LoadBalancer  *snip*      34.XX.XX.XX   8089:31735/TCP   12m
profile                ClusterIP     *snip*      <none>          80/TCP         121m
profile-workload       LoadBalancer  *snip*      34.XX.XX.XX   8089:32532/TCP   12m
tradepost              ClusterIP     *snip*      <none>          80/TCP         121m
tradepost-workload     LoadBalancer  *snip*      34.XX.XX.XX   8089:30002/TCP   12m

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

סיכום

פרסתם את עומסי העבודה באשכול GKE. עומסי העבודה האלה לא צריכים הרשאות IAM נוספות, ואפשר לגשת אליהם באופן חיצוני ביציאה 8089 באמצעות שירות Load Balancer.

השלבים הבאים

כשהשירותים לקצה העורפי ועומסי העבודה פועלים, הגיע הזמן "להפעיל" המשחק!

7. מתחילים לשחק במשחק

סקירה כללית

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

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

תיאור של כל עומס עבודה:

• עומס העבודה של item-generator הוא עומס עבודה מהיר שיוצר רשימה של פריטי game_items שהשחקנים יכולים לרכוש במהלך ה-"playing" (משחק). את המשחק.
• profile-workload מדמה שחקנים שנרשמים ומתחברים.
• הסמל matchmaking-workload מדמה שחקנים שמחפשים שחקנים בתור משחקים.
• game-workload מדמה שחקנים שרוכשים פריטי game_item וכסף במהלך המשחק.
• tradepost-workload מדמה לשחקנים את היכולת למכור ולקנות פריטים בתחנת המסחר.

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

ה-Codelab הזה ידגיש הרצה ספציפית של item-generator ו-profile-workload.

הפעלת מחולל הפריטים

item-generator משתמש בנקודת הקצה (endpoint) של השירות לקצה העורפי item כדי להוסיף את game_items ל-Spanner. הפריטים האלה נדרשים כדי שהערכים game-workload ו-tradepost-workload יפעלו כמו שצריך.

השלב הראשון הוא למצוא את כתובת ה-IP החיצונית של השירות item-generator. ב-Cloud Shell, מריצים את הפקודה הבאה:

# The external IP is the 4th column of the output
kubectl get services | grep item-generator | awk '{print $4}'

פלט הפקודה

{ITEMGENERATOR_EXTERNAL_IP}

עכשיו פותחים כרטיסייה חדשה בדפדפן ומפנים אותה אל http://{ITEMGENERATOR_EXTERNAL_IP}:8089. אמור להתקבל דף כזה:

צריך להשאיר את users ואת spawn עם ערך ברירת המחדל 1. בשביל host, מזינים http://item. לוחצים על האפשרויות המתקדמות ומזינים 10s בשדה של משך ההפעלה.

כך אמורה להיראות ההגדרה:

הערה: מכיוון שעומסי העבודה והשירותים לקצה העורפי נמצאים באותו אשכול GKE, הם יכולים לגלות זה את זה באמצעות רזולוציית DNS בשביל שם השירות. לכן יש לך אפשרות להפנות לשם המארח http://item.

צריך ללחוץ על 'התחלת נחיל'!

נתונים סטטיסטיים יתחילו להופיע לגבי בקשות שהונפקו בנקודת הקצה POST /items. אחרי 10 שניות הטעינה תיפסק.

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

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

כדי לעשות זאת, לוחצים על תפריט ההמבורגר ומנווטים אל 'Spanner'. מהדף הזה, נכנסים אל sample-instance ואל sample-database. לאחר מכן צריך ללחוץ על 'Query'.

אנחנו רוצים לבחור את מספר game_items:

SELECT COUNT(*) FROM game_items;

התוצאה תוצג בתחתית המסך.

הערה: יכול להיות שהמספר המדויק של פריטי game_items לא יהיה זהה. זה בסדר.

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

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

כדי לשחק במשחקים, השלב הבא הוא רישום של שחקנים ל-game_items.

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

כדי להריץ את זה, צריך לקבל את כתובת ה-IP החיצונית profile-workload:

# The external IP is the 4th column of the output
kubectl get services | grep profile-workload | awk '{print $4}'

פלט הפקודה

{PROFILEWORKLOAD_EXTERNAL_IP}

עכשיו פותחים כרטיסייה חדשה בדפדפן ומפנים אותה אל http://{PROFILEWORKLOAD_EXTERNAL_IP}:8089. אמור להופיע דף של Locust שדומה לדף הקודם.

במקרה הזה, צריך להשתמש ב-http://profile בתור המארח. ולא מציינים סביבת זמן ריצה באפשרויות המתקדמות. כמו כן, צריך לציין את הערך של users ל-4, שידמהו 4 בקשות משתמשים בכל פעם.

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

צריך ללחוץ על 'התחלת נחיל'!

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

הערה: צריך להשאיר את השדה profile-workload פועל. בקטע הבא אפשר לבדוק את הביצועים של GKE ושל Cloud Spanner.

סיכום

בשלב הזה יצרתם כמה game_items, ואז הרצתם שאילתות על הטבלה game_items באמצעות ממשק המשתמש של Spanner Query במסוף Cloud.

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

השלבים הבאים

אחרי הרצת עומסי העבודה, חשוב לבדוק את ההתנהגות של אשכול GKE והמכונה של Spanner.

8. בדיקת השימוש ב-GKE וב-Spanner

כששירות הפרופיל פועל, זה הזמן לנצל את ההזדמנות כדי לראות איך מתנהלים אשכול GKE Autopilot ו-Cloud Spanner.

בדיקה של אשכול ה-GKE

עוברים לאשכול Kubernetes. שימו לב שמכיוון שפרסתם את עומסי העבודה והשירותים, לאשכול נוספו עכשיו כמה פרטים על סך כל יחידות ה-vCPU והזיכרון. המידע הזה לא היה זמין כשלא היו עומסי עבודה (workload) באשכול.

עכשיו לוחצים על האשכול sample-game-gke ועוברים לכרטיסייה ניראות (observability):

מרחב השמות default של kubernetes היה אמור לעבור את מרחב השמות kube-system לניצול המעבד (CPU), כי עומסי העבודה והשירותים לקצה העורפי שלנו פועלים ב-default. אם הוא לא פועל, צריך לוודא ש-profile workload עדיין פועל ולהמתין מספר דקות עד שהתרשימים יתעדכנו.

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

במקום להיכנס לכל עומס עבודה בנפרד, פשוט עוברים ישירות לכרטיסייה 'ניראות' במרכז הבקרה. רואים שהמעבד (CPU) של profile ושל profile-workload עלה.

עכשיו כדאי לבדוק את Cloud Spanner.

בדיקה של מכונת Cloud Spanner

כדי לבדוק את הביצועים של Cloud Spanner, צריך לעבור אל Spanner וללחוץ על המכונה של sample-instance ועל מסד הנתונים sample-game.

בתפריט הימני תופיע הכרטיסייה System Insights:

יש כאן הרבה תרשימים שיעזרו לך להבין את הביצועים הכלליים של מכונת Spanner, כולל CPU utilization, transaction latency and locking ו-query throughput.

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

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

סיכום

בשלב הזה למדתם איך לבדוק כמה מדדי ביצועים בסיסיים גם ל-GKE Autopilot וגם ל-Spanner.

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

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

השלבים הבאים

בשלב הבא, הגיע הזמן לפנות מקום.

9. מנקה

לפני הפינוי מקום, מומלץ לבדוק את עומסי העבודה האחרים שלא נכללו. באופן ספציפי matchmaking-workload, game-workload ו-tradepost-workload.

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

קודם כול, אם profile-workload עדיין פועל בדפדפן, צריך לעבור אליו ולהפסיק אותו:

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

לאחר מכן, ב-Cloud Shell, עוברים לתיקיית התשתית. מבצעים destroy של התשתית באמצעות terraform:

cd $DEMO_HOME/infrastructure
terraform destroy
# type 'yes' when asked

פלט הפקודה

Plan: 0 to add, 0 to change, 46 to destroy.

Do you really want to destroy all resources?
  Terraform will destroy all your managed infrastructure, as shown above.
  There is no undo. Only 'yes' will be accepted to confirm.

  Enter a value: yes

*snip*

Destroy complete! Resources: 46 destroyed.

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

במסוף Cloud, נכנסים אל Spanner, Kubernetes Cluster, Artifact Registry, Cloud Deploy ו-IAM כדי לוודא שכל המשאבים הוסרו.

10. מעולה!

מזל טוב, פרסת בהצלחה אפליקציות golang לדוגמה ב-GKE Autopilot וקישרת אותן ל-Cloud Spanner באמצעות Workload Identity!

בונוס – התשתית הזו הוגדרה בקלות והוסרה באמצעות Terraform.

ב-Codelab הזה אפשר לקרוא מידע נוסף על שירותי Google Cloud שהייתה לך אינטראקציה איתם:

• GKE Autopilot ו-Workload Identity
• Cloud Spanner
• Artifact Registry
• Cloud Build ו-Cloud Deploy

מה השלב הבא?

עכשיו, אחרי שהבנתם איך GKE Autopilot ו-Cloud Spanner יכולים לעבוד יחד, כדאי לכם להמשיך לשלב הבא ולהתחיל לפתח אפליקציה משלכם שתעבוד עם השירותים האלה.