ربط Cloud Spanner باستخدام ميزة GKE Autopilot

1. مقدمة

‫Cloud Spanner هي خدمة قواعد بيانات ارتباطية مُدارة بالكامل وقابلة للتوسّع أفقيًا وموزّعة على مستوى العالم، وتوفّر معاملات ACID ودلالات SQL بدون التنازل عن الأداء العالي ومدى التوفّر العالي.

GKE Autopilot هو وضع تشغيل في GKE تدير فيه Google إعدادات مجموعتك، بما في ذلك العُقد والتوسيع والأمان والإعدادات الأخرى المُعدّة مسبقًا لاتباع أفضل الممارسات. على سبيل المثال، تتيح ميزة GKE Autopilot استخدام Workload Identity لإدارة أذونات الخدمة.

تهدف هذه الميزة الاختبارية إلى إرشادك خلال عملية ربط العديد من الخدمات الخلفية التي تعمل على GKE Autopilot بقاعدة بيانات Cloud Spanner.

في هذا التمرين العملي، عليك أولاً إعداد مشروع وتشغيل Cloud Shell. بعد ذلك، ستنشر البنية الأساسية باستخدام Terraform.

بعد انتهاء ذلك، ستتفاعل مع Cloud Build وCloud Deploy لإجراء عملية نقل مخطط أوّلية لقاعدة بيانات "الألعاب"، ونشر خدمات الخلفية، ثم نشر أحمال العمل.

الخدمات الواردة في هذا الدرس التطبيقي العملي هي نفسها الواردة في الدرس التطبيقي العملي بدء استخدام Cloud Spanner في تطوير الألعاب. لا يُشترط إكمال هذا الدرس العملي للحصول على الخدمات التي تعمل على GKE والاتصال بخدمة Spanner. ولكن إذا كنت مهتمًا بمزيد من التفاصيل حول خصائص هذه الخدمات التي تعمل على Spanner، يمكنك الاطّلاع عليها.

بعد تشغيل أعباء العمل وخدمات الخلفية، يمكنك البدء في إنشاء الحمل ومراقبة طريقة عمل الخدمات معًا.

وأخيرًا، ستنظّف الموارد التي تم إنشاؤها في هذا الدرس التطبيقي.

ما ستنشئه

في هذا الدرس التطبيقي، ستنفّذ ما يلي:

• توفير البنية الأساسية باستخدام Terraform
• إنشاء مخطط قاعدة البيانات باستخدام عملية نقل المخطط في Cloud Build
• نشر خدمات الخلفية الأربع المستندة إلى Golang والتي تستخدم Workload Identity للاتصال بخدمة Cloud Spanner
• نشر خدمات أحمال العمل الأربع المستخدَمة لمحاكاة الحمل لخدمات الخلفية

أهداف الدورة التعليمية

• كيفية توفير مسارات GKE Autopilot وCloud Spanner وCloud Deploy باستخدام Terraform
• كيف تتيح Workload Identity للخدمات على GKE انتحال هوية حسابات الخدمة للوصول إلى أذونات "إدارة الهوية وإمكانية الوصول" من أجل استخدام Cloud Spanner؟
• كيفية إنشاء حمل مشابه لحمل الإنتاج على GKE وCloud Spanner باستخدام Locust.io

المتطلبات

• مشروع على السحابة الإلكترونية من Google Cloud مرتبط بحساب الفوترة.
• متصفّح ويب، مثل Chrome أو Firefox

2. الإعداد والمتطلبات

إنشاء مشروع

تحذير: يُجري هذا الدرس البرمجي تغييرات على مشروعك. ننصح بشدة بإعداد مشروع مخصّص لهذا الدرس التطبيقي.

إذا لم يكن لديك حساب Google (Gmail أو Google Apps)، عليك إنشاء حساب. سجِّل الدخول إلى "وحدة تحكّم Google Cloud Platform" (console.cloud.google.com) وأنشِئ مشروعًا جديدًا.

إذا كان لديك مشروع حالي، انقر على القائمة المنسدلة لاختيار المشروع في أعلى يمين وحدة التحكّم:

وانقر على الزر مشروع جديد في مربّع الحوار الناتج لإنشاء مشروع جديد:

إذا لم يكن لديك مشروع، من المفترض أن يظهر لك مربّع حوار مشابه لما يلي لإنشاء مشروعك الأول:

يتيح لك مربّع حوار إنشاء المشروع اللاحق إدخال تفاصيل مشروعك الجديد:

تذكَّر رقم تعريف المشروع، وهو اسم فريد في جميع مشاريع Google Cloud (الاسم أعلاه مستخدَم حاليًا ولن يكون متاحًا لك، نأسف لذلك). سيتم الإشارة إليه لاحقًا في هذا الدرس العملي باسم PROJECT_ID.

بعد ذلك، إذا لم يسبق لك إجراء ذلك، عليك تفعيل الفوترة في Developers Console من أجل استخدام موارد Google Cloud وتفعيل Cloud Spanner API.

لن تكلفك تجربة هذا الدرس التطبيقي حول الترميز أكثر من بضعة دولارات، ولكن قد تكون التكلفة أعلى إذا قررت استخدام المزيد من الموارد أو إذا تركتها قيد التشغيل (راجِع قسم "التنظيف" في نهاية هذا المستند). يمكنك الاطّلاع على مستندات حول أسعار Google Cloud Spanner هنا، ومستندات حول GKE Autopilot هنا.

يمكن لمستخدمي Google Cloud Platform الجدد الاستفادة من فترة تجريبية مجانية بقيمة 300 دولار أمريكي، ما يجعل هذا الدرس العملي مجانيًا تمامًا.

إعداد Cloud Shell

على الرغم من إمكانية تشغيل Google Cloud وSpanner عن بُعد من الكمبيوتر المحمول، سنستخدم في هذا الدرس التطبيقي حول الترميز Google Cloud Shell، وهي بيئة سطر أوامر تعمل في السحابة الإلكترونية.

يتم تحميل هذا الجهاز الافتراضي المستند إلى Debian بجميع أدوات التطوير التي تحتاج إليها. توفّر هذه الخدمة دليلًا رئيسيًا دائمًا بسعة 5 غيغابايت وتعمل في Google Cloud، ما يؤدي إلى تحسين أداء الشبكة والمصادقة بشكل كبير. وهذا يعني أنّ كل ما تحتاجه لهذا الدرس التطبيقي حول الترميز هو متصفّح (نعم، يمكن استخدامه على جهاز Chromebook).

1. لتفعيل Cloud Shell من Cloud Console، ما عليك سوى النقر على "تفعيل Cloud Shell" (يستغرق توفير البيئة والاتصال بها بضع لحظات فقط).

بعد الاتصال بـ Cloud Shell، من المفترض أن يظهر لك أنّه تمّت المصادقة عليك وأنّ المشروع تمّ ضبطه مسبقًا على PROJECT_ID.

gcloud auth list

ناتج الأمر

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

ملاحظة: تكون أداة سطر الأوامر gcloud مثبّتة مسبقًا في Cloud Shell. لمزيد من المعلومات، يُرجى الاطّلاع على نظرة عامة على أداة سطر الأوامر gcloud.

gcloud config list project

ناتج الأمر

[core]
project = <PROJECT_ID>

إذا لم يتم ضبط المشروع لسبب ما، ما عليك سوى تنفيذ الأمر التالي:

gcloud config set project <PROJECT_ID>

هل تبحث عن PROJECT_ID؟ يمكنك الاطّلاع على المعرّف الذي استخدمته في خطوات الإعداد أو البحث عنه في لوحة بيانات Cloud Console:

يضبط Cloud Shell أيضًا بعض متغيرات البيئة تلقائيًا، ما قد يكون مفيدًا عند تنفيذ الأوامر المستقبلية.

echo $GOOGLE_CLOUD_PROJECT

ناتج الأمر

<PROJECT_ID>

ملاحظة: عند تشغيل gcloud على جهازك، سيتم الاحتفاظ بإعدادات الضبط في جميع الجلسات. ولكن في Cloud Shell، عليك ضبط هذا الإعداد لكل جلسة جديدة أو إعادة اتصال.

تنزيل الرمز

في Cloud Shell، يمكنك تنزيل الرمز البرمجي لهذا التمرين العملي:

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

ناتج الأمر

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

يستند هذا الدرس التطبيقي حول الترميز إلى الإصدار 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. سيسمح لك ذلك بالتنقّل بسهولة أكبر أثناء العمل على الأجزاء المختلفة من الدرس العملي.

export DEMO_HOME=$(pwd)

ملخّص

في هذه الخطوة، أعددت مشروعًا جديدًا وفعّلت Cloud Shell ونزّلت الرمز البرمجي لهذا الدرس التطبيقي.

التالي

بعد ذلك، ستوفّر البنية الأساسية باستخدام Terraform.

3- توفير البنية التحتية

نظرة عامة

بعد أن يصبح مشروعك جاهزًا، حان الوقت لتشغيل البنية الأساسية. ويشمل ذلك شبكات السحابة الافتراضية الخاصة وCloud Spanner وGKE Autopilot وArtifact Registry لتخزين الصور التي سيتم تشغيلها على GKE، بالإضافة إلى مسارات Cloud Deploy لخدمات الخلفية وأحمال العمل، وأخيرًا حسابات الخدمة وأذونات إدارة الهوية وإمكانية الوصول لاستخدام هذه الخدمات.

هذا كثير. لحسن الحظ، يمكن أن يسهّل 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

ملاحظة: باستخدام المتغيّرات التلقائية، سيتم نشر البنية الأساسية في المنطقة us-central1.

توفير البنية الأساسية

تحذير: تؤدي هذه الخطوة إلى إجراء تغييرات على مشروعك. قد يؤدي ذلك إلى عواقب غير مقصودة إذا كنت تستخدم مشروعًا حاليًا. ننصح بشدة بإعداد مشروع مخصّص لهذا الدرس التطبيقي.

حان الوقت الآن لتوفير البنية الأساسية.

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 Console.

ملاحظة: قد لا تظهر المراجع أدناه إلى أن تكتمل الخطوة terraform apply.

Cloud Spanner

أولاً، تحقَّق من Cloud Spanner من خلال الانتقال إلى قائمة الهامبرغر والنقر على Spanner. قد تحتاج إلى النقر على "عرض المزيد من المنتجات" للعثور عليه في القائمة.

سينقلك هذا الإجراء إلى قائمة مثيلات Spanner. انقر على المثيل وستظهر لك قواعد البيانات. من المفترض أن تظهر بشكلٍ مشابه لما يلي:

ملاحظة: ستلاحظ أنّ هذا مثيل دقيق يعمل على 100 وحدة معالجة (100 PU)، مع الإعداد الإقليمي us-central.

GKE Autopilot

بعد ذلك، يمكنك تجربة GKE من خلال الانتقال إلى قائمة الخطوط الثلاثة والنقر على Kubernetes Engine => Clusters. سيظهر لك هنا مجموعة sample-games-gke تعمل في وضع "القيادة الذاتية".

ملاحظة: يُرجى العِلم أنّ مجموعة 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 نفسها، ولكن يتيح ذلك فصل عمليات النشر.

إدارة الهوية وإمكانية الوصول

أخيرًا، اطّلِع على صفحة "إدارة الهوية وإمكانية الوصول" في Cloud Console للتحقّق من حسابات الخدمة التي تم إنشاؤها. انتقِل إلى قائمة الهمبرغر وابحث عن IAM and Admin=>Service accounts. من المفترض أن تظهر بشكلٍ مشابه لما يلي:

هناك إجمالي ستة حسابات خدمة يتم إنشاؤها بواسطة 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

ملاحظة: يجب أن لا يعرض 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 لكي يتمكّن 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 السحابية. إذا نقرت على ذلك، سيتم نقلك إلى الإصدار في Cloud Console حتى تتمكّن من تتبُّع مستوى تقدّم الإصدار والاطّلاع على الإجراءات التي يتم تنفيذها.

ملاحظة: تتطابق خطوات نقل البيانات مع عدد الملفات في الدليل $DEMO_HOME/schema/migrations.

ملخّص

في هذه الخطوة، استخدمت Cloud Build لإرسال عملية نقل المخطط الأوّلية التي طبّقت 5 عمليات مختلفة للغة تعريف البيانات (DDL). تمثّل هذه العمليات الوقت الذي تمت فيه إضافة ميزات تتطلّب تغييرات في مخطط قاعدة البيانات.

في سيناريو التطوير العادي، من المفترض أن تريد إجراء تغييرات على المخطط تكون متوافقة مع التطبيق الحالي لتجنُّب الانقطاعات.

بالنسبة إلى التغييرات التي لا تتوافق مع الإصدارات السابقة، عليك نشر التغييرات على التطبيق والمخطط على مراحل لضمان عدم حدوث أي انقطاعات.

التالي

بعد إعداد المخطط، الخطوة التالية هي نشر خدمات الخلفية.

5- نشر خدمات الخلفية

نظرة عامة

خدمات الخلفية لهذا الدرس التطبيقي هي واجهات برمجة تطبيقات REST بلغة Go تمثّل أربع خدمات مختلفة:

• الملف الشخصي: يتيح للاعبين إمكانية الاشتراك والمصادقة على "اللعبة" التجريبية.
• المطابقة: التفاعل مع بيانات اللاعبين للمساعدة في وظيفة المطابقة وتتبُّع المعلومات حول الألعاب التي يتم إنشاؤها وتعديل إحصاءات اللاعبين عند إغلاق الألعاب
• العناصر: تتيح للاعبين الحصول على عناصر وأموال داخل اللعبة أثناء اللعب.
• مركز التبادل: يتيح للاعبين شراء وبيع العناصر في مركز التبادل

يمكنك الاطّلاع على مزيد من المعلومات حول هذه الخدمات في برنامج Cloud Spanner Getting Started with Games Development التعليمي. بالنسبة إلى أغراضنا، نريد تشغيل هذه الخدمات على مجموعة GKE Autopilot.

يجب أن تكون هذه الخدمات قادرة على تعديل بيانات Spanner. لإجراء ذلك، يتم إنشاء حساب خدمة لكل خدمة يمنحها دور "databaseUser".

تسمح Workload Identity لحساب خدمة Kubernetes بانتحال هوية حساب خدمة Google Cloud الخاص بالخدمات من خلال اتّباع الخطوات التالية في Terraform:

• إنشاء مورد حساب خدمة Google Cloud الخاص بالخدمة (GSA)
• امنح حساب الخدمة هذا الدور databaseUser.
• امنح حساب الخدمة هذا الدور workloadIdentityUser.
• إنشاء حساب خدمة Kubernetes (KSA) يشير إلى حساب خدمة Google

سيبدو المخطط التقريبي على النحو التالي:

ملاحظة: لكل خدمة حساب خدمة Google (GSA) وحساب خدمة Kubernetes (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

تعمل عملية الإنشاء على النحو التالي:

• أنشأ 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" وحدات Pod الخاصة بالخدمة الخلفية من الحصول على عنوان 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 هي 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}

ملاحظة: يتم إنشاء الملف 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 لنشر خدمات الواجهة الخلفية. كما هو الحال مع عمليات نقل المخطط، يمكنك إرسال طلب الإنشاء باستخدام سطر أوامر 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، تشير نتيجة هذا الإصدار إلى أنّه تم إنشاء بعض الصور. وسيتم تخزينها في مستودع Artifact Registry.

سيتضمّن الناتج من الخطوة gcloud build رابطًا يؤدي إلى Cloud Console. يمكنك الاطّلاع عليها.

ملاحظة: حتى إذا تلقّيت رسالة SUCCESS من Cloud Build، لن يكتمل النشر إلا بعد تشغيل وحدات pod.

بعد تلقّي إشعار النجاح من Cloud Build، انتقِل إلى Cloud Deploy ثم إلى sample-game-services خط الأنابيب لتتبُّع تقدّم عملية النشر.

بعد نشر الخدمات، يمكنك التحقّق من 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

ملاحظة: لا تحتوي الخدمات الخلفية على عنوان IP خارجي مخصّص لمنع الوصول الخارجي إلى واجهات برمجة التطبيقات.

يمكنك أيضًا الانتقال إلى واجهة مستخدم GKE في Cloud Console للاطّلاع على Workloads وServices وConfigMaps.

أحجام المعالجة

الخدمات

ConfigMaps

ملخّص

في هذه الخطوة، نشرت خدمات الخلفية الأربع على GKE Autopilot. تمكّنت من تنفيذ خطوة Cloud Build والتحقّق من مستوى التقدّم في Cloud Deploy وعلى Kubernetes في Cloud Console.

تعرّفت أيضًا على كيفية استخدام هذه الخدمات لـ Workload Identity من أجل انتحال هوية حساب خدمة لديه الأذونات المناسبة لقراءة البيانات وكتابتها في قاعدة بيانات Spanner.

الخطوات التالية

في القسم التالي، ستنفّذ أحمال العمل.

6. نشر أحمال العمل

نظرة عامة

بعد تشغيل خدمات الخلفية على المجموعة، عليك نشر أحمال العمل.

يمكن الوصول إلى أحمال العمل خارجيًا، ويتوفّر حمل عمل واحد لكل خدمة خلفية لغرض هذا الدرس البرمجي.

أحمال العمل هذه هي نصوص برمجية لإنشاء الأحمال تستند إلى 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.

سيوفّر 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 عدد الموارد اللازمة لتلبية طلبات جميع وحدات 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

ملاحظة: على عكس خدمات الخلفية، يتم تخصيص عناوين IP خارجية لأحمال العمل.

ملخّص

لقد نشرت الآن أحمال العمل في مجموعة GKE. لا تتطلّب أحمال العمل هذه أذونات إضافية في "إدارة الهوية وإمكانية الوصول"، ويمكن الوصول إليها خارجيًا على المنفذ 8089 باستخدام خدمة LoadBalancer.

الخطوات التالية

بعد تشغيل خدمات الخلفية وأحمال العمل، حان وقت "اللعب"!

7. بدء اللعبة

نظرة عامة

تعمل الآن خدمات الخلفية الخاصة بـ "اللعبة" النموذجية، ويمكنك أيضًا إنشاء "لاعبين" يتفاعلون مع هذه الخدمات باستخدام أحمال العمل.

تستخدم كلّ عبء عمل Locust لمحاكاة الحمل الفعلي على واجهات برمجة التطبيقات الخاصة بالخدمة. في هذه الخطوة، ستشغّل العديد من أحمال العمل لإنشاء حمل على مجموعة GKE وعلى Spanner، بالإضافة إلى تخزين البيانات على Spanner.

في ما يلي وصف لكل عبء عمل:

• عبء العمل item-generator هو عبء عمل سريع لإنشاء قائمة game_items يمكن للاعبين الحصول عليها أثناء "لعب" اللعبة.
• تحاكي profile-workload عملية تسجيل اللاعبين للدخول.
• يحاكي matchmaking-workload اللاعبين الذين ينتظرون في قائمة الانتظار ليتم تعيينهم في المباريات.
• يحاكي game-workload اللاعبين الذين يحصلون على game_items وأموال أثناء لعب اللعبة.
• يحاكي tradepost-workload إمكانية بيع اللاعبين وشراء العناصر في مركز التداول.

ملاحظة: إذا كنت تريد المزيد من التفاصيل حول طريقة عمل مولّدات Locust هذه، يمكنك الاطّلاع على برنامج Cloud Spanner Getting Started with Games Development التعليمي.

سيركّز هذا الدرس العملي على تشغيل item-generator وprofile-workload تحديدًا.

تشغيل أداة إنشاء العناصر

يستخدم 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. من المفترض أن تظهر لك صفحة مشابهة لما يلي:

سيتم ترك القيمتين users وspawn على القيمة التلقائية 1. بالنسبة إلى host، أدخِل http://item. انقر على الخيارات المتقدّمة، وأدخِل 10s في حقل مدة التشغيل.

في ما يلي الشكل الذي يجب أن تظهر به الإعدادات:

ملاحظة: بما أنّ أحمال العمل وخدمات الخلفية تقع على مجموعة GKE نفسها، يمكنها استكشاف بعضها البعض باستخدام التحويل باستخدام نظام أسماء النطاقات (DNS) لاسم الخدمة. لهذا السبب يمكنك الرجوع إلى اسم المضيف http://item.

انقر على "بدء البحث الجماعي".

ستبدأ الإحصاءات في الظهور للطلبات التي يتم إصدارها على نقطة النهاية POST /items. بعد 10 ثوانٍ، سيتوقف التحميل.

انتقِل إلى Charts وستظهر لك بعض الرسومات البيانية حول أداء هذه الطلبات.

الآن، عليك التحقّق مما إذا كانت البيانات قد تم إدخالها في قاعدة بيانات 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 ضمن Cloud Console.

سمحت أيضًا للاعبين بالاشتراك في لعبتك، واطّلعت على كيفية تمكُّن Locust من إنشاء أحمال عمل شبيهة بأحمال العمل في مرحلة الإنتاج مقابل خدمات الخلفية.

الخطوات التالية

بعد تنفيذ أحمال العمل، عليك التحقّق من سلوك مجموعة GKE ونسخة Spanner.

8. مراجعة استخدام GKE وSpanner

بعد تشغيل خدمة الملف الشخصي، حان الوقت للاستفادة من الفرصة والاطّلاع على سلوك مجموعة GKE Autopilot وCloud Spanner.

التحقّق من مجموعة GKE

انتقِل إلى مجموعة Kubernetes. لاحظ أنّه بعد نشر أحمال العمل والخدمات، أُضيفت بعض التفاصيل إلى المجموعة حول إجمالي وحدات المعالجة المركزية الافتراضية والذاكرة. لم تكن هذه المعلومات متاحة عندما لم تكن هناك أي أحمال عمل على المجموعة.

الآن، انقر على المجموعة sample-game-gke وانتقِل إلى علامة التبويب "إمكانية المراقبة":

من المفترض أن تكون مساحة اسم kubernetes default قد تجاوزت مساحة الاسم kube-system في ما يتعلق باستخدام وحدة المعالجة المركزية، لأنّ أحمال العمل وخدمات الخلفية تعمل على default. إذا لم يتم ذلك، تأكَّد من أنّ profile workload لا يزال قيد التشغيل وانتظِر بضع دقائق حتى يتم تحديث الرسوم البيانية.

للاطّلاع على مهام العمل التي تستهلك معظم الموارد، انتقِل إلى لوحة بيانات Workloads.

بدلاً من الانتقال إلى كل عبء عمل على حدة، انتقِل مباشرةً إلى علامة التبويب "إمكانية تتبّع البيانات" في لوحة البيانات. ستلاحظ أنّ معدّل استخدام وحدة المعالجة المركزية (CPU) في profile وprofile-workload قد زاد.

الآن، انتقِل إلى Cloud Spanner.

التحقّق من مثيل Cloud Spanner

للاطّلاع على أداء Cloud Spanner، انتقِل إلى Spanner وانقر على المثيل sample-instance وقاعدة البيانات sample-game.

من هناك، ستظهر علامة التبويب إحصاءات النظام في القائمة اليمنى:

تتوفّر هنا العديد من الرسومات البيانية لمساعدتك في فهم الأداء العام لمثيل Spanner، بما في ذلك CPU utilization وtransaction latency and locking وquery throughput.

بالإضافة إلى "إحصاءات النظام"، يمكنك الحصول على معلومات أكثر تفصيلاً حول عبء عمل طلب البحث من خلال الاطّلاع على الروابط الأخرى في قسم "إمكانية تتبّع البيانات":

• تساعد إحصاءات طلبات البحث في تحديد أهم N طلب بحث تستخدم الموارد على Spanner.
• تساعد إحصاءات المعاملات وعمليات القفل في تحديد المعاملات التي تتضمّن أوقات استجابة طويلة.
• تساعد أداة Key Visualizer في عرض أنماط الوصول بشكل مرئي ويمكن أن تساعد في تتبُّع النقاط الفعّالة في البيانات.

ملخّص

في هذه الخطوة، تعرّفت على كيفية التحقّق من بعض مقاييس الأداء الأساسية لكلّ من 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 Console، انتقِل إلى Spanner وKubernetes Cluster وArtifact Registry وCloud Deploy وIAM للتأكّد من إزالة جميع الموارد.

10. تهانينا!

تهانينا، لقد تمكّنت من نشر نماذج لتطبيقات Golang على وضع التشغيل الآلي في GKE وربطها بخدمة Cloud Spanner باستخدام Workload Identity.

بالإضافة إلى ذلك، تم إعداد هذه البنية التحتية وإزالتها بسهولة بطريقة قابلة للتكرار باستخدام Terraform.

يمكنك الاطّلاع على مزيد من المعلومات حول خدمات Google Cloud التي تفاعلت معها في هذا الدرس العملي:

• ‫GKE Autopilot وWorkload Identity
• Cloud Spanner
• Artifact Registry
• Cloud Build وCloud Deploy

ما هي الخطوات التالية؟

بعد أن أصبحت لديك فكرة أساسية عن كيفية عمل GKE Autopilot وCloud Spanner معًا، لماذا لا تتّخذ الخطوة التالية وتبدأ في إنشاء تطبيقك الخاص للعمل مع هذه الخدمات؟