اتصال Cloud Spanner با GKE Autopilot

۱. مقدمه

کلود اسپنر یک سرویس پایگاه داده رابطه‌ای، توزیع‌شده در سطح جهانی و مقیاس‌پذیر افقی است که تراکنش‌های ACID و مفاهیم SQL را بدون از دست دادن عملکرد و دسترسی‌پذیری بالا ارائه می‌دهد.

GKE Autopilot یک حالت عملیاتی در GKE است که در آن گوگل پیکربندی خوشه شما، از جمله گره‌ها، مقیاس‌پذیری، امنیت و سایر تنظیمات از پیش پیکربندی شده را برای پیروی از بهترین شیوه‌ها مدیریت می‌کند. به عنوان مثال، GKE Autopilot قابلیت Workload Identity را برای مدیریت مجوزهای سرویس فعال می‌کند.

هدف این آزمایش این است که شما را در فرآیند اتصال چندین سرویس backend که روی GKE Autopilot اجرا می‌شوند به یک پایگاه داده Cloud Spanner راهنمایی کند.

3d810aa9ec80a271.png

در این آزمایش، ابتدا یک پروژه راه‌اندازی و Cloud Shell را راه‌اندازی خواهید کرد. سپس زیرساخت را با استفاده از Terraform مستقر خواهید کرد.

پس از اتمام این کار، با Cloud Build و Cloud Deploy تعامل خواهید داشت تا یک مهاجرت اولیه طرحواره برای پایگاه داده Games انجام دهید، سرویس‌های backend را مستقر کنید و سپس بارهای کاری را مستقر کنید.

سرویس‌های موجود در این آزمایشگاه کد، مشابه آزمایشگاه کد Cloud Spanner Getting Started with Games Development هستند. اجرای این آزمایشگاه کد برای اجرای سرویس‌ها روی GKE و اتصال به Spanner الزامی نیست. اما اگر به جزئیات بیشتر در مورد ویژگی‌های سرویس‌هایی که روی Spanner کار می‌کنند علاقه‌مند هستید، آن را بررسی کنید.

با اجرای بارهای کاری و سرویس‌های backend، می‌توانید شروع به تولید بار کنید و نحوه‌ی عملکرد سرویس‌ها را با هم مشاهده کنید.

در نهایت، منابعی را که در این آزمایشگاه ایجاد شده‌اند، پاکسازی خواهید کرد.

آنچه خواهید ساخت

به عنوان بخشی از این آزمایشگاه، شما:

  • فراهم کردن زیرساخت با استفاده از Terraform
  • ایجاد طرحواره پایگاه داده با استفاده از فرآیند مهاجرت طرحواره در Cloud Build
  • چهار سرویس بک‌اند Golang را که از Workload Identity برای اتصال به Cloud Spanner استفاده می‌کنند، مستقر کنید.
  • چهار سرویس بار کاری را که برای شبیه‌سازی بار سرویس‌های backend استفاده می‌شوند، مستقر کنید.

آنچه یاد خواهید گرفت

  • نحوه آماده‌سازی خطوط لوله GKE Autopilot، Cloud Spanner و Cloud Deploy با استفاده از Terraform
  • چگونه Workload Identity به سرویس‌های روی GKE اجازه می‌دهد تا حساب‌های سرویس را جعل هویت کنند تا به مجوزهای IAM برای کار با Cloud Spanner دسترسی پیدا کنند.
  • نحوه تولید بار شبیه به محیط عملیاتی در GKE و Cloud Spanner با استفاده از Locust.io

آنچه نیاز دارید

  • یک پروژه گوگل کلود که به یک حساب صورتحساب متصل است.
  • یک مرورگر وب، مانند کروم یا فایرفاکس .

۲. تنظیمات و الزامات

ایجاد یک پروژه

اگر از قبل حساب گوگل (جیمیل یا برنامه‌های گوگل) ندارید، باید یکی ایجاد کنید . وارد کنسول پلتفرم ابری گوگل ( console.cloud.google.com ) شوید و یک پروژه جدید ایجاد کنید.

اگر از قبل پروژه‌ای دارید، روی منوی کشویی انتخاب پروژه در سمت چپ بالای کنسول کلیک کنید:

6c9406d9b014760.png

و در پنجره‌ی باز شده روی دکمه‌ی « پروژه‌ی جدید » کلیک کنید تا یک پروژه‌ی جدید ایجاد شود:

۹۴۹d۸۳c۸a۴ee۱۷d۹.png

اگر از قبل پروژه‌ای ندارید، باید پنجره‌ای مانند این را برای ایجاد اولین پروژه خود ببینید:

870a3cbd6541ee86.png

پنجره‌ی بعدیِ ایجاد پروژه به شما امکان می‌دهد جزئیات پروژه‌ی جدید خود را وارد کنید:

6a92c57d3250a4b3.png

شناسه پروژه را به خاطر بسپارید، که یک نام منحصر به فرد در تمام پروژه‌های Google Cloud است (نام بالا قبلاً گرفته شده و برای شما کار نخواهد کرد، متاسفیم!). بعداً در این آزمایشگاه کد به آن PROJECT_ID گفته خواهد شد.

در مرحله بعد، اگر قبلاً این کار را نکرده‌اید، برای استفاده از منابع Google Cloud و فعال کردن Cloud Spanner API ، باید صورتحساب را در کنسول توسعه‌دهندگان فعال کنید .

15d0ef27a8fbab27.png

اجرای این آزمایشگاه کد نباید بیش از چند دلار برای شما هزینه داشته باشد، اما اگر تصمیم به استفاده از منابع بیشتر بگیرید یا اگر آنها را در حال اجرا رها کنید (به بخش "پاکسازی" در انتهای این سند مراجعه کنید)، می‌تواند بیشتر هزینه داشته باشد. قیمت Google Cloud Spanner در اینجا و GKE Autopilot در اینجا مستند شده است.

کاربران جدید پلتفرم ابری گوگل واجد شرایط دریافت یک دوره آزمایشی رایگان ۳۰۰ دلاری هستند که این کدلب را کاملاً رایگان می‌کند.

راه اندازی پوسته ابری

اگرچه می‌توان از راه دور و از طریق لپ‌تاپ، گوگل کلود و اسپنر را کنترل کرد، اما در این آزمایشگاه کد، از گوگل کلود شل ، یک محیط خط فرمان که در فضای ابری اجرا می‌شود، استفاده خواهیم کرد.

این ماشین مجازی مبتنی بر دبیان، تمام ابزارهای توسعه مورد نیاز شما را در خود جای داده است. این ماشین مجازی یک دایرکتوری خانگی ۵ گیگابایتی دائمی ارائه می‌دهد و در فضای ابری گوگل اجرا می‌شود که عملکرد شبکه و احراز هویت را تا حد زیادی بهبود می‌بخشد. این بدان معناست که تنها چیزی که برای این آزمایشگاه کد نیاز دارید یک مرورگر است (بله، روی کروم‌بوک هم کار می‌کند).

  1. برای فعال کردن Cloud Shell از کنسول Cloud، کافیست روی Activate Cloud Shell کلیک کنید. gcLMt5IuEcJJNnMId-Bcz3sxCd0rZn7IzT_r95C8UZeqML68Y1efBG_B0VRp7hc7qiZTLAF-TXD7SsOadxn8uadgHhaLeASnVS3ZHK39eOlKJOgj9SJua_oeGhMxRrbOg3qigddS2A (فقط چند لحظه طول می‌کشد تا آماده شود و به محیط متصل شود).

JjEuRXGg0AYYIY6QZ8d-66gx_Mtc-_jDE9ijmbXLJSAXFvJt-qUpNtsBsYjNpv2W6BQSr Dc1D-ARINNQ-1EkwUhz-iUK-FUCZhJ-NtjvIEx9pIkE-246DomWuCfiGHK78DgoeWkHRw

اسکرین شات 2017-06-14 ساعت 10.13.43 PM.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 Console جستجو کنید:

۱۵۸fNPfwSxsFqz9YbtJVZes8viTS3d1bV4CVhij3XPxuzVFOtTObnwsphlm6lYGmgdMFwBJtc-FaLrZU7XHAg_ZYoCrgombMRR3h-eolLPcvO351c5iBv506B3ZwghZoiRg6cz23Qw

Cloud Shell همچنین برخی از متغیرهای محیطی را به طور پیش‌فرض تنظیم می‌کند که ممکن است هنگام اجرای دستورات بعدی مفید باشند.

echo $GOOGLE_CLOUD_PROJECT

خروجی دستور

<PROJECT_ID>

کد را دانلود کنید

در Cloud Shell، می‌توانید کد مربوط به این آزمایشگاه را دانلود کنید:

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

خروجی دستور

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

این آزمایشگاه کد بر اساس نسخه ۰.۱.۳ است، بنابراین آن برچسب را بررسی کنید: 

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 تنظیم کنید. این کار به شما امکان می‌دهد هنگام کار با بخش‌های مختلف آزمایشگاه کد، پیمایش آسان‌تری داشته باشید. 

export DEMO_HOME=$(pwd)

خلاصه

در این مرحله شما یک پروژه جدید راه‌اندازی کرده‌اید، پوسته ابری را فعال کرده‌اید و کد مربوط به این آزمایش را دانلود کرده‌اید.

بعدی

در مرحله بعد، زیرساخت را با استفاده از Terraform فراهم خواهید کرد.

۳. زیرساخت‌های تأمین

نمای کلی

با آماده شدن پروژه، زمان اجرای زیرساخت فرا رسیده است. این شامل شبکه VPC، Cloud Spanner، GKE Autopilot، Artifact Registry برای ذخیره تصاویری که روی GKE اجرا خواهند شد، خطوط لوله Cloud Deploy برای سرویس‌ها و بارهای کاری backend و در نهایت حساب‌های سرویس و امتیازات IAM برای استفاده از این سرویس‌ها می‌شود.

خیلی زیاد است. اما خوشبختانه، Terraform می‌تواند راه‌اندازی این کار را ساده کند. Terraform یک ابزار "زیرساخت به عنوان کد" است که به ما امکان می‌دهد آنچه را که برای این پروژه نیاز داریم در مجموعه‌ای از فایل‌های '.tf' مشخص کنیم. این امر تأمین زیرساخت را ساده می‌کند.

آشنایی با Terraform برای تکمیل این آزمایشگاه کد الزامی نیست. اما اگر می‌خواهید ببینید مراحل بعدی چه کاری انجام می‌دهند، می‌توانید نگاهی به فایل‌های ایجاد شده در این پوشه infrastructure بیندازید:

  • vpc.tf
  • backend_gke.tf
  • آچار.tf
  • artifact_registry.tf
  • خطوط لوله.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

تأمین زیرساخت‌ها

حالا وقت فراهم کردن زیرساخت‌هاست! 

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.

بررسی کنید چه چیزی ایجاد شده است

برای تأیید آنچه ایجاد شده است، باید محصولات موجود در Cloud Console را بررسی کنید.

آچار ابری

ابتدا، با رفتن به منوی همبرگری و کلیک روی Spanner ، Cloud Spanner را بررسی کنید. ممکن است لازم باشد برای یافتن آن در لیست، روی «مشاهده محصولات بیشتر» کلیک کنید.

این شما را به لیست نمونه‌های Spanner می‌برد. روی نمونه کلیک کنید تا پایگاه‌های داده را مشاهده کنید. باید چیزی شبیه به این باشد:

10b7fc0c4a86c59.png

خلبان خودکار GKE

در مرحله بعد، با رفتن به منوی همبرگری و کلیک روی Kubernetes Engine => Clusters ، GKE را بررسی کنید. در اینجا خوشه sample-games-gke را که در حالت Autopilot اجرا می‌شود، مشاهده خواهید کرد.

9cecb1a702e6b7ff.png

ثبت آثار باستانی

حالا باید ببینید تصاویر کجا ذخیره می‌شوند. بنابراین روی منوی همبرگری کلیک کنید و Artifact Registry=>Repositories را پیدا کنید. Artifact Registry در بخش CI/CD منو قرار دارد.

در اینجا، یک رجیستری داکر با نام spanner-game-images مشاهده خواهید کرد. این رجیستری فعلاً خالی خواهد بود.

3f805eee312841b.png

استقرار ابری

Cloud Deploy جایی است که خطوط لوله ایجاد شده‌اند تا Cloud Build بتواند مراحلی را برای ساخت تصاویر فراهم کند و سپس آنها را در خوشه GKE ما مستقر کند.

به منوی همبرگری بروید و Cloud Deploy پیدا کنید که در بخش CI/CD منو نیز قرار دارد.

در اینجا متوجه دو خط لوله خواهید شد: یکی برای سرویس‌های backend و دیگری برای بارهای کاری. هر دو تصاویر را در یک خوشه GKE مستقر می‌کنند، اما این امر امکان جداسازی استقرارهای ما را فراهم می‌کند.

d2e4a659145ddf5e.png

آی ام

در نهایت، برای تأیید حساب‌های سرویس ایجاد شده، صفحه IAM را در Cloud Console بررسی کنید. به منوی همبرگری بروید و IAM and Admin=>Service accounts پیدا کنید. باید چیزی شبیه به این باشد:

bed3d1af94974916.png

در مجموع شش حساب کاربری سرویس وجود دارد که توسط Terraform ایجاد می‌شوند:

  • حساب کاربری پیش‌فرض سرویس کامپیوتر. این حساب در این آزمایشگاه کد استفاده نشده است.
  • حساب کاربری 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

خلاصه

عالی شد! شما توانستید یک نمونه Cloud Spanner و یک کلاستر GKE Autopilot را در یک VPC برای شبکه خصوصی آماده کنید.

علاوه بر این، دو خط لوله Cloud Deploy برای سرویس‌های backend و بارهای کاری و همچنین یک مخزن Artifact Registry برای ذخیره تصاویر ساخته شده ایجاد شد.

و در نهایت، حساب‌های کاربری سرویس ایجاد و پیکربندی شدند تا با Workload Identity کار کنند تا سرویس‌های backend بتوانند از Cloud Spanner استفاده کنند.

همچنین kubectl طوری پیکربندی کرده‌اید که پس از استقرار سرویس‌ها و بارهای کاری backend، با خوشه GKE در Cloud Shell تعامل داشته باشد.

بعدی

قبل از اینکه بتوانید از سرویس‌ها استفاده کنید، باید طرح پایگاه داده تعریف شود. در ادامه آن را تنظیم خواهید کرد.

۴. طرحواره پایگاه داده را ایجاد کنید

نمای کلی

قبل از اینکه بتوانید سرویس‌های backend را اجرا کنید، باید مطمئن شوید که طرحواره پایگاه داده (database schema) در جای خود قرار دارد.

اگر به فایل‌های موجود در دایرکتوری $DEMO_HOME/schema/migrations از مخزن نسخه آزمایشی نگاه کنید، مجموعه‌ای از فایل‌های .sql را خواهید دید که طرحواره ما را تعریف می‌کنند. این یک چرخه توسعه را تقلید می‌کند که در آن تغییرات طرحواره در خود مخزن ردیابی می‌شوند و می‌توانند به ویژگی‌های خاصی از برنامه‌ها مرتبط شوند.

برای این محیط نمونه، wrench ابزاری است که مهاجرت‌های طرحواره ما را با استفاده از 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، نمونه و پایگاه داده برای اتصال wrench به نقطه پایانی نوشتن مورد نیاز هستند.

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);

انتقال طرحواره را ارسال کنید

برای ارسال نسخهٔ ساخته‌شده جهت انجام مهاجرت طرحواره، به دایرکتوری 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

در خروجی بالا، متوجه لینکی به فرآیند ساخت ابر Created خواهید شد. اگر روی آن کلیک کنید، به ساخت در کنسول ابر هدایت می‌شوید تا بتوانید پیشرفت ساخت را زیر نظر داشته باشید و ببینید چه کاری انجام می‌دهد.

11b1cf107876d797.png

خلاصه

در این مرحله، شما از Cloud Build برای ارسال مهاجرت اولیه طرحواره استفاده کردید که 5 عملیات DDL مختلف را اعمال می‌کرد. این عملیات نشان می‌دهد که چه زمانی ویژگی‌هایی اضافه شده‌اند که نیاز به تغییرات طرحواره پایگاه داده دارند.

در یک سناریوی توسعه عادی، شما می‌خواهید تغییرات طرحواره را با برنامه فعلی سازگار کنید تا از قطع شدن برنامه جلوگیری شود.

برای تغییراتی که با نسخه‌های قبلی سازگار نیستند، بهتر است تغییرات را به صورت مرحله‌ای در برنامه و طرحواره اعمال کنید تا از قطع شدن سرویس جلوگیری شود.

بعدی

با قرار دادن طرحواره، مرحله بعدی استقرار سرویس‌های backend است!

۵. سرویس‌های بک‌اند را مستقر کنید

نمای کلی

سرویس‌های بک‌اند این آزمایشگاه کد، APIهای REST زبان golang هستند که چهار سرویس مختلف را ارائه می‌دهند:

  • پروفایل: به بازیکنان امکان ثبت نام و احراز هویت در نمونه "بازی" ما را بدهید.
  • مچ‌میکینگ: با داده‌های بازیکن تعامل داشته باشید تا به عملکرد مچ‌میکینگ کمک کنید، اطلاعات مربوط به بازی‌های ایجاد شده را پیگیری کنید و آمار بازیکن را هنگام بسته شدن بازی‌ها به‌روزرسانی کنید.
  • آیتم: به بازیکنان این امکان را می‌دهد که در طول بازی، آیتم‌ها و پول بازی را به دست آورند.
  • پایگاه تجاری: به بازیکنان اجازه می‌دهد تا در یک پایگاه تجاری اقلام بخرند و بفروشند.

d36e958411d44b5d.png

می‌توانید اطلاعات بیشتری در مورد این سرویس‌ها را در آزمایشگاه کدنویسی Cloud Spanner Getting Started with Games Development بیابید. برای اهداف ما، می‌خواهیم این سرویس‌ها روی کلاستر GKE Autopilot ما اجرا شوند.

این سرویس‌ها باید بتوانند داده‌های Spanner را تغییر دهند. برای انجام این کار، هر سرویس یک حساب کاربری سرویس ایجاد می‌کند که به آنها نقش 'databaseUser' اعطا می‌کند.

هویت بار کاری به یک حساب سرویس kubernetes اجازه می‌دهد تا با مراحل زیر در Terraform ما، حساب سرویس گوگل کلود سرویس‌ها را جعل هویت کند:

  • منبع حساب سرویس ابری گوگل ( GSA ) مربوط به سرویس را ایجاد کنید
  • نقش databaseUser را به آن حساب سرویس اختصاص دهید
  • نقش workloadIdentityUser را به آن حساب سرویس اختصاص دهید
  • یک حساب کاربری سرویس Kubernetes ( KSA ) ایجاد کنید که به GSA ارجاع دهد.

یک نمودار تقریبی به این شکل خواهد بود:

a8662d31d66b5910.png

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

نحوه کار ساخت به شرح زیر است:

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 هر سرویس پیروی می‌کند. فایل deployment سرویس شامل اطلاعات لازم برای ایجاد یک سرویس است که در این مورد یک clusterIP است که روی پورت ۸۰ اجرا می‌شود.

نوع " ClusterIP" مانع از داشتن IP خارجی برای پادهای سرویس backend می‌شود، بنابراین فقط موجودیت‌هایی که می‌توانند به شبکه داخلی GKE متصل شوند می‌توانند به سرویس‌های backend دسترسی داشته باشند. این سرویس‌ها نباید مستقیماً برای بازیکنان قابل دسترسی باشند زیرا آنها به داده‌های Spanner دسترسی پیدا کرده و آنها را تغییر می‌دهند. 

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

علاوه بر ایجاد یک سرویس 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 یک Kubernetes ConfigMap است که اطلاعات پروژه، نمونه و پایگاه داده مورد نیاز برای اتصال برنامه به 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}

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"

با این اطلاعات، وقت آن رسیده که سرویس‌های backend را مستقر کنیم.

سرویس‌های بک‌اند را مستقر کنید

همانطور که گفته شد، استقرار سرویس‌های backend از Cloud 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

برخلاف خروجی مرحله‌ی schema migration ، خروجی این ساخت نشان می‌دهد که تعدادی ایمیج ایجاد شده است. این ایمیج‌ها در مخزن رجیستری مصنوعات شما ذخیره خواهند شد.

خروجی مرحله gcloud build لینکی به Cloud Console خواهد داشت. به آنها نگاهی بیندازید.

وقتی اعلان موفقیت‌آمیز بودن نصب را از Cloud Build دریافت کردید، به Cloud Deploy و سپس به sample-game-services pipeline بروید تا پیشرفت نصب را زیر نظر داشته باشید.

df5c6124b9693986.png

پس از استقرار سرویس‌ها، می‌توانید kubectl بررسی کنید تا وضعیت پادها را مشاهده کنید: 

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

همچنین می‌توانید به رابط کاربری GKE در کنسول ابری بروید تا Workloads ، Services و ConfigMaps را مشاهده کنید.

حجم کار

da98979ae49e5a30.png

خدمات

406ca2fe7ad4818b.png

پیکربندی نقشه‌ها

a0ebd34ee735ee11.png

3b9ef91c77a4e7f0.png

خلاصه

در این مرحله، شما چهار سرویس backend را در GKE Autopilot مستقر کردید. شما توانستید مرحله Cloud Build را اجرا کنید و پیشرفت را در Cloud Deploy و Kubernetes در Cloud Console بررسی کنید.

همچنین آموختید که چگونه این سرویس‌ها از Workload Identity برای جعل هویت یک حساب کاربری سرویس که مجوزهای لازم برای خواندن و نوشتن داده‌ها در پایگاه داده Spanner را دارد، استفاده می‌کنند.

مراحل بعدی

در بخش بعدی، بارهای کاری را مستقر خواهید کرد.

۶. حجم کار را مستقر کنید

نمای کلی

اکنون که سرویس‌های backend روی کلاستر اجرا می‌شوند، بارهای کاری را مستقر خواهید کرد.

dd900485e2eeb611.png

بارهای کاری از خارج قابل دسترسی هستند و برای هر سرویس backend، یکی از آنها برای اهداف این codelab وجود دارد.

این بارهای کاری، اسکریپت‌های تولید بار مبتنی بر Locust هستند که الگوهای دسترسی واقعی مورد انتظار این سرویس‌های نمونه را تقلید می‌کنند.

فایل‌هایی برای فرآیند ساخت ابری وجود دارد:

  • $DEMO_HOME/workloads/cloudbuild.yaml (تولید شده توسط Terraform)
  • $DEMO_HOME/workloads/skaffold.yaml
  • یک فایل deployment.yaml برای هر بار کاری

فایل‌های workload deployment.yaml کمی متفاوت از فایل‌های استقرار سرویس backend به نظر می‌رسند.

در اینجا مثالی از 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 اجرا می‌شود.

LoadBalancer یک 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 به جز سرویس‌های backend که روی کلاستر GKE اجرا می‌شوند، ندارد.

تفاوت دیگر این است که برای این بارهای کاری به هیچ متغیر محیطی نیاز نیست. نتیجه، زمان استقرار کوتاه‌تر است. 

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

تنظیمات منابع مشابه سرویس‌های backend است. به یاد داشته باشید که GKE Autopilot از این طریق می‌داند که چه تعداد منبع برای پاسخگویی به درخواست‌های همه podهای در حال اجرا روی کلاستر مورد نیاز است.

ادامه دهید و حجم کار را مستقر کنید!

حجم کار را مستقر کنید

درست مانند قبل، می‌توانید درخواست ساخت را با استفاده از خط فرمان 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

برای بررسی وضعیت، حتماً لاگ‌های Cloud Build و خط لوله Cloud Deploy را در Cloud Console بررسی کنید. برای بارهای کاری، خط لوله 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

خلاصه

اکنون بارهای کاری را در کلاستر GKE مستقر کرده‌اید. این بارهای کاری به مجوزهای IAM اضافی نیاز ندارند و با استفاده از سرویس LoadBalancer از طریق پورت ۸۰۸۹ قابل دسترسی خارجی هستند.

مراحل بعدی

با سرویس‌های بک‌اند و حجم‌های کاری در حال اجرا، وقت آن رسیده که بازی را شروع کنیم !

۷. شروع بازی

نمای کلی

سرویس‌های بک‌اند برای «بازی» نمونه شما اکنون در حال اجرا هستند، و شما همچنین ابزارهایی برای ایجاد «بازیکنانی» دارید که با استفاده از بارهای کاری با آن سرویس‌ها تعامل دارند.

هر بار کاری از Locust برای شبیه‌سازی بار واقعی در برابر APIهای سرویس ما استفاده می‌کند. در این مرحله، شما چندین بار کاری را برای ایجاد بار در خوشه GKE و Spanner و همچنین ذخیره داده‌ها در Spanner اجرا خواهید کرد.

در اینجا شرح هر بار کاری آمده است:

  • بار کاری item-generator یک بار کاری سریع برای تولید فهرستی از آیتم‌های بازی است که بازیکنان می‌توانند در طول «بازی کردن» بازی به دست آورند.
  • profile-workload ثبت‌نام و ورود بازیکنان را شبیه‌سازی می‌کند.
  • matchmaking-workload صف کشیدن بازیکنان برای اختصاص داده شدن به بازی‌ها را شبیه‌سازی می‌کند.
  • game-workload نحوه‌ی کسب آیتم‌های بازی و پول توسط بازیکنان را در طول بازی شبیه‌سازی می‌کند.
  • tradepost-workload توانایی بازیکنان در خرید و فروش اقلام در پایگاه معاملاتی را شبیه‌سازی می‌کند.

این آزمایشگاه کد به طور خاص اجرای item-generator و profile-workload را برجسته خواهد کرد.

مولد آیتم را اجرا کنید

item-generator از نقطه پایانی سرویس backend 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 را در آن وارد کنید . باید صفحه‌ای مانند این را دریافت کنید:

۸۱۷۳۰۷۱۵۷d۶۶c۶۶۱.png

شما users رها خواهید کرد و در حالت پیش‌فرض ۱ spawn . برای host ، http://item را وارد کنید. روی گزینه‌های پیشرفته کلیک کنید و برای زمان اجرا، 10s را وارد کنید.

پیکربندی باید به این شکل باشد:

f3143165c6285c21.png

روی «شروع حمله گروهی» کلیک کنید!

آمار درخواست‌های ارسالی در نقطه پایانی POST /items شروع به نمایش می‌کند. پس از 10 ثانیه، بارگذاری متوقف می‌شود.

روی Charts کلیک کنید تا نمودارهایی از عملکرد این درخواست‌ها را مشاهده کنید.

abad0a9f3c165345.png

حالا، می‌خواهید بررسی کنید که آیا داده‌ها در پایگاه داده Spanner وارد شده‌اند یا خیر.

برای انجام این کار، روی منوی همبرگری کلیک کنید و به «Spanner» بروید. از این صفحه، به sample-instance و sample-database بروید. سپس روی « Query » کلیک کنید.

ما می‌خواهیم تعداد game_items را انتخاب کنیم :

SELECT COUNT(*) FROM game_items;

در پایین، نتیجه خود را دریافت خواهید کرد.

۱۳۷ce۲۹۱a۲ff۲۷۰۶.png

ما به تعداد زیادی game_items نیاز نداریم. اما اکنون آنها برای بازیکنان در دسترس هستند تا آنها را بدست آورند!

اجرای حجم کار پروفایل

با قرار دادن game_items ، مرحله بعدی ثبت‌نام بازیکنان برای انجام بازی‌ها است.

profile-workload Locust برای شبیه‌سازی ایجاد حساب کاربری، ورود به سیستم، بازیابی اطلاعات پروفایل و خروج از سیستم توسط بازیکنان استفاده خواهد کرد. همه این موارد، نقاط پایانی سرویس backend 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 را ۴ نفر تعیین کنید که ۴ درخواست کاربر را همزمان شبیه‌سازی می‌کند.

تست profile-workload باید به این شکل باشد:

f6e0f06efb0ad6e.png

روی «شروع حمله گروهی» کلیک کنید!

درست مانند قبل، آمار مربوط به نقاط پایانی مختلف profile شروع به نمایش می‌کند. برای مشاهده‌ی نمودارها و میزان عملکرد همه چیز، روی آنها کلیک کنید.

4c2146e1cb3de23e.png

خلاصه

در این مرحله، شما تعدادی game_items ایجاد کردید و سپس با استفاده از رابط کاربری Spanner Query در Cloud Console، جدول game_items را جستجو کردید.

شما همچنین به بازیکنان اجازه دادید تا در بازی شما ثبت نام کنند و دیدید که چگونه Locust قادر است بارهای کاری شبیه به محیط تولید را در برابر سرویس‌های backend شما ایجاد کند.

مراحل بعدی

پس از اجرای بارهای کاری، باید بررسی کنید که خوشه GKE و نمونه Spanner چگونه رفتار می‌کنند.

۸. بررسی استفاده از GKE و آچار

با اجرای سرویس پروفایل، وقت آن رسیده است که از این فرصت استفاده کنید و ببینید که خوشه GKE Autopilot و Cloud Spanner شما چگونه رفتار می‌کنند.

بررسی خوشه GKE

به کلاستر Kubernetes بروید. توجه داشته باشید که از آنجایی که بارهای کاری و سرویس‌ها را مستقر کرده‌اید، اکنون جزئیاتی در مورد کل vCPUها و حافظه به کلاستر اضافه شده است. این اطلاعات زمانی که هیچ بار کاری روی کلاستر وجود نداشت، در دسترس نبود.

61d2d766c1f10079.png

حالا، روی خوشه sample-game-gke کلیک کنید و به تب observability بروید:

fa9acc7e26ea04a.png

فضای نام default kubernetes باید از نظر میزان استفاده از CPU از فضای نام kube-system پیشی گرفته باشد، زیرا بارهای کاری و سرویس‌های backend ما به default اجرا می‌شوند. اگر اینطور نیست، مطمئن شوید که profile workload هنوز در حال اجرا است و چند دقیقه صبر کنید تا نمودارها به‌روزرسانی شوند.

برای مشاهده‌ی اینکه کدام حجم کاری بیشترین منابع را مصرف می‌کند، به داشبورد Workloads بروید.

به جای اینکه به صورت جداگانه به هر بار کاری بپردازید، مستقیماً به برگه Observability داشبورد بروید. باید ببینید که CPU profile و profile-workload افزایش یافته است.

f194b618969cfa9e.png

حالا، برو و Cloud Spanner را بررسی کن.

نمونه Cloud Spanner را بررسی کنید

برای بررسی عملکرد Cloud Spanner، به Spanner بروید و روی نمونه sample-instance و پایگاه داده sample-game کلیک کنید.

از آنجا، یک برگه System Insights در منوی سمت چپ مشاهده خواهید کرد:

۲۱۶۲۱۲۱۸۲a۵۷dfd۱.png

نمودارهای زیادی در اینجا وجود دارد که به شما کمک می‌کند عملکرد کلی نمونه Spanner خود را از جمله CPU utilization ، transaction latency and locking و query throughput درک کنید.

علاوه بر System Insights، می‌توانید با مراجعه به لینک‌های دیگر در بخش Observability، اطلاعات دقیق‌تری در مورد حجم کار پرس‌وجو کسب کنید:

  • بینش‌های پرس‌وجو به شناسایی پرس‌وجوهای topN که از منابع Spanner استفاده می‌کنند، کمک می‌کند.
  • بینش‌های تراکنش و قفل به شناسایی تراکنش‌های با تأخیر بالا کمک می‌کند.
  • ابزار Key Visualizer به تجسم الگوهای دسترسی کمک می‌کند و می‌تواند به ردیابی نقاط حساس در داده‌ها کمک کند.

خلاصه

در این مرحله، یاد گرفتید که چگونه برخی از معیارهای عملکرد اولیه را برای هر دو GKE Autopilot و Spanner بررسی کنید.

برای مثال، با اجرای حجم کاری پروفایل خود، از جدول players پرس‌وجو کنید تا اطلاعات بیشتری در مورد داده‌های ذخیره شده در آنجا به دست آورید.

مراحل بعدی

بعدش، وقت تمیزکاریه!

۹. تمیز کردن

قبل از پاکسازی، در صورت تمایل می‌توانید سایر بارهای کاری که پوشش داده نشده‌اند را بررسی کنید. به طور خاص matchmaking-workload ، game-workload و tradepost-workload .

وقتی بازی را تمام کردید، می‌توانید زمین بازی خود را تمیز کنید. خوشبختانه این کار بسیار آسان است.

ابتدا، اگر profile-workload شما هنوز در مرورگر در حال اجرا است، آن را متوقف کنید:

13ae755a11f3228.png

همین کار را برای هر حجم کاری که ممکن است آزمایش کرده باشید، انجام دهید.

سپس در Cloud Shell، به پوشه infrastructure بروید. شما با استفاده از terraform زیرساخت را destroy : 

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 Console، به Spanner ، Kubernetes Cluster ، Artifact Registry ، Cloud Deploy و IAM بروید تا تأیید کنید که تمام منابع حذف شده‌اند.

۱۰. تبریک می‌گویم!

تبریک می‌گویم، شما با موفقیت برنامه‌های نمونه golang را روی GKE Autopilot مستقر کردید و آنها را با استفاده از Workload Identity به Cloud Spanner متصل کردید!

به عنوان یک مزیت، این زیرساخت به راحتی و به روشی تکرارپذیر با استفاده از Terraform راه‌اندازی و حذف شد.

می‌توانید در این آزمایشگاه کد، اطلاعات بیشتری در مورد سرویس‌های گوگل کلود که با آنها تعامل داشته‌اید، مطالعه کنید:

بعدش چی؟

حالا که درک اولیه‌ای از نحوه‌ی همکاری GKE Autopilot و Cloud Spanner دارید، چرا قدم بعدی را برنمی‌دارید و شروع به ساخت اپلیکیشن خودتان برای کار با این سرویس‌ها نمی‌کنید؟