اتصال Cloud Spanner با GKE Autopilot

1. مقدمه

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

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

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

3d810aa9ec80a271.png

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

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

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

با اجرای بارهای کاری و خدمات باطن، می توانید شروع به تولید بار کنید و مشاهده کنید که چگونه سرویس ها با هم کار می کنند.

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

چیزی که خواهی ساخت

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

  • زیرساخت را با استفاده از Terraform فراهم کنید
  • طرحواره پایگاه داده را با استفاده از فرآیند Schema Migration در 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 که به یک حساب صورت‌حساب متصل است.
  • یک مرورگر وب، مانند کروم یا فایرفاکس .

2. راه اندازی و الزامات

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

اگر قبلاً یک حساب Google (Gmail یا Google Apps) ندارید، باید یک حساب ایجاد کنید . به کنسول Google Cloud Platform ( consol.cloud.google.com ) وارد شوید و یک پروژه جدید ایجاد کنید.

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

6c9406d9b014760.png

و روی دکمه " پروژه جدید " در گفتگوی حاصل کلیک کنید تا یک پروژه جدید ایجاد کنید:

949d83c8a4ee17d9.png

اگر قبلاً پروژه ای ندارید، باید یک دیالوگ مانند این را ببینید تا اولین پروژه خود را ایجاد کنید:

870a3cbd6541ee86.png

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

6a92c57d3250a4b3.png

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

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

15d0ef27a8fbab27.png

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

کاربران جدید Google Cloud Platform واجد شرایط استفاده آزمایشی رایگان 300 دلاری هستند که باید این نرم افزار کد را کاملاً رایگان کند.

راه اندازی Cloud Shell

در حالی که Google Cloud و Spanner را می‌توان از راه دور از لپ‌تاپ شما کار کرد، در این نرم‌افزار از Google Cloud Shell استفاده می‌کنیم، یک محیط خط فرمان که در Cloud اجرا می‌شود.

این ماشین مجازی مبتنی بر دبیان با تمام ابزارهای توسعه که شما نیاز دارید بارگذاری شده است. این دایرکتوری اصلی 5 گیگابایتی دائمی را ارائه می دهد و در Google Cloud اجرا می شود و عملکرد شبکه و احراز هویت را بسیار افزایش می دهد. این بدان معنی است که تمام چیزی که برای این کد لبه نیاز دارید یک مرورگر است (بله، روی کروم بوک کار می کند).

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

JjEuRXGg0AYYIY6QZ8d-66gx_Mtc-_jDE9ijmbXLJSAXFvJt-qUpNtsBsYjNpv2W6BQSrDc1D-ARINNQ-1EkwUhz-iUK-FUCZhJ-NtjkWkWE2C w

Screen Shot 2017-06-14 at 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 جستجو کنید:

158fNPfwSxsFqz9YbtJVZes8viTS3d1bV4CVhij3XPxuzVFOtTObnwsphlm6lYGmgdMFwBJtc-FaLrZU7XHAg_ZYoCrgombMRR3h-eolLPcvOZwZw51

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*

این Codelab بر اساس نسخه نسخه 0.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)

خلاصه

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

بعدی

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

3. تامین زیرساخت

نمای کلی

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

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

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

  • 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

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

اکنون زمان آن است که زیرساخت ها را فراهم کنیم! 

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 Autopilot

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

9cecb1a702e6b7ff.png

رجیستری مصنوعات

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

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

3f805eee312841b.png

Cloud Deploy

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

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

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

d2e4a659145ddf5e.png

IAM

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

bed3d1af94974916.png

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

  • حساب پیش فرض سرویس رایانه. این در این کد لبه استفاده نشده است.
  • حساب cloudbuild-cidd برای مراحل 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 را برای تعامل با خوشه GKE در Cloud Shell پیکربندی کرده‌اید.

بعدی

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

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

نمای کلی

قبل از اینکه بتوانید خدمات باطن را اجرا کنید، باید مطمئن شوید که طرح پایگاه داده در جای خود قرار دارد.

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

برای این محیط نمونه، آچار ابزاری است که مهاجرت های طرحواره ما را با استفاده از 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);

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

برای ارسال بیلد برای انجام مهاجرت طرحواره، به دایرکتوری 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 مشاهده خواهید کرد. اگر روی آن کلیک کنید، شما را به بیلد در Cloud Console می برد تا بتوانید پیشرفت ساخت را زیر نظر داشته باشید و ببینید چه کار می کند.

11b1cf107876d797.png

خلاصه

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

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

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

بعدی

با وجود طرحواره، گام بعدی استقرار خدمات باطن است!

5. خدمات باطن را مستقر کنید

نمای کلی

خدمات پشتیبان برای این کد لبه APIهای گلانگ REST هستند که چهار سرویس مختلف را نشان می دهند:

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

d36e958411d44b5d.png

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

این سرویس ها باید بتوانند داده های Spanner را تغییر دهند. برای انجام این کار، هر سرویس دارای یک حساب سرویس ایجاد شده است که به آنها نقش "کاربر پایگاه داده" را می دهد.

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

  • منبع حساب سرویس ابری گوگل ( GSA ) سرویس را ایجاد کنید
  • نقش پایگاه داده کاربر را به آن حساب سرویس اختصاص دهید
  • نقش 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 هر سرویس پیروی می کند. فایل استقرار سرویس حاوی اطلاعات ایجاد یک سرویس است که در این مورد یک ClusterIP است که روی پورت 80 اجرا می شود.

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

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

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

با این اطلاعات، زمان استقرار خدمات باطن فرا رسیده است.

خدمات باطن را مستقر کنید

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

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 در Cloud Console بروید تا Workloads ، Services و ConfigMaps را ببینید.

بارهای کاری

da98979ae49e5a30.png

خدمات

406ca2fe7ad4818b.png

ConfigMaps

a0ebd34ee735ee11.png

3b9ef91c77a4e7f0.png

خلاصه

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

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

مراحل بعدی

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

6. بارهای کاری را مستقر کنید

نمای کلی

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

dd900485e2eeb611.png

بارهای کاری به صورت خارجی قابل دسترسی هستند و برای هر سرویس پشتیبان به منظور این نرم افزار کد وجود دارد.

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

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

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

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

پیش بروید و بارهای کاری را مستقر کنید!

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

درست مانند قبل، می توانید درخواست ساخت را با استفاده از خط فرمان 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 بررسی کنید تا وضعیت را بررسی کنید. برای بارهای کاری، خط لوله استقرار ابری 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 اضافی نیاز ندارند و در پورت 8089 با استفاده از سرویس LoadBalancer قابل دسترسی خارجی هستند.

مراحل بعدی

با خدمات پشتیبان و بارهای کاری در حال اجرا، زمان " بازی " این بازی است!

7. بازی را شروع کنید

نمای کلی

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

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

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

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

این کد لبه به طور خاص در حال اجرا item-generator و profile-workload برجسته می کند.

Item-generator را اجرا کنید

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

817307157d66c661.png

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

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

f3143165c6285c21.png

روی "شروع ازدحام" کلیک کنید!

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

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

abad0a9f3c165345.png

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

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

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

COUNT(*) را از آیتم های بازی انتخاب کنید.

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

137ce291a2ff2706.png

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

پروفایل-workload را اجرا کنید

با seeded 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 باید به شکل زیر باشد:

f6e0f06efb0ad6e.png

روی "شروع ازدحام" کلیک کنید!

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

4c2146e1cb3de23e.png

خلاصه

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

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

مراحل بعدی

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

8. استفاده از GKE و Spanner را مرور کنید

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

خوشه GKE را بررسی کنید

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

61d2d766c1f10079.png

اکنون، روی خوشه sample-game-gke کلیک کنید و به برگه مشاهده پذیری بروید:

fa9acc7e26ea04a.png

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

برای اینکه ببینید چه حجم کاری بیشترین منابع را می گیرد، به داشبورد Workloads بروید.

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

f194b618969cfa9e.png

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

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

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

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

216212182a57dfd1.png

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

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

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

خلاصه

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

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

مراحل بعدی

بعد، زمان تمیز کردن است!

9. تمیز کردن

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

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

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

13ae755a11f3228.png

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

سپس در Cloud Shell به پوشه زیرساخت بروید. شما زیرساخت را با استفاده از 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 بروید تا تمام منابع حذف شوند.

10. تبریک می گویم!

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

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

می‌توانید درباره سرویس‌های Google Cloud که با آن‌ها تعامل داشتید، بیشتر بخوانید:

بعدش چی؟

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