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

1. مقدمة

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

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

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

3d810aa9ec80a271.png

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

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

الخدمات الواردة في هذا الدرس التطبيقي حول الترميز هي نفسها الخدمات المتوفّرة في الدرس التطبيقي حول الترميز Cloud Spanner Getting Started with Games Development. ويُرجى العِلم بأنّ إكمال هذا الدرس التطبيقي حول الترميز ليس شرطًا لتشغيل الخدمات على 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) وأنشئ مشروعًا جديدًا.

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

6c9406d9b014760.png

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

949d83c8a4ee17d9.png

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

870a3cbd6541ee86.png

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

6a92c57d3250a4b3.png

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

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

15d0ef27a8fbab27.png

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

إنّ مستخدمي Google Cloud Platform الجدد مؤهّلون للاستفادة من فترة تجريبية مجانية بقيمة 300 دولار أمريكي، ما يجعل هذا الدرس التطبيقي حول الترميز بدون أي تكلفة.

إعداد Cloud Shell

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

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

  1. لتفعيل Cloud Shell من Cloud Console، ما عليك سوى النقر على رمز تفعيل Cloud Shell gcLMt5IuEcJJNnMId-Bcz3sxCd0rZn7IzT_r95C8UZeqML68Y1efBG_B0VRp7hc7qiZTLAF-TXD7SsOadxn8uadgHhaLeASnVS3ZHK39eOlKJOgj9SJua_oeGhMxRrbOg3qigddS2A (من المفترَض أن تستغرق عملية الإعداد والاتصال بالبيئة بضع دقائق فقط).

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

لقطة شاشة يوم 14-06-2017 في الساعة 10.13.43 مساءً.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-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*

يستند هذا الدرس التطبيقي حول الترميز إلى إصدار 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- توفير البنية الأساسية

نظرة عامة

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

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

Cloud Spanner

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

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

10b7fc0c4a86c59.png

التوجيه التلقائي في GKE

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

9cecb1a702e6b7ff.png

Artifact Registry

والآن ستحتاج إلى معرفة المكان الذي سيتم تخزين الصور فيه. انقر على قائمة الهامبرغر وابحث عن Artifact Registry=>Repositories. Artifact Registry متوفّر في قسم CI/CD من القائمة.

سترى هنا قاعدة بيانات المسجّلين في Docker باسم spanner-game-images. سيكون هذا الحقل فارغًا في الوقت الحالي.

3f805eee312841b.png

Cloud Deploy

النشر في السحابة الإلكترونية هو المكان الذي تم فيه إنشاء مسارات التعلّم كي تتمكن Cloud Build من توفير خطوات لإنشاء الصور ونشرها في مجموعة GKE.

انتقِل إلى قائمة الهامبرغر وابحث عن Cloud Deploy، وهو متاح أيضًا في قسم CI/CD من القائمة.

ستلاحظ هنا مسارين: أحدهما لخدمات الخلفية، والآخر لأعباء العمل. وكلاهما ينشر الصور إلى نفس مجموعة GKE، إلا أنّ ذلك يسمح بفصل عمليات النشر التي نجريها.

d2e4a659145ddf5e.png

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

أخيرًا، يمكنك الاطّلاع على صفحة "إدارة الهوية وإمكانية الوصول" في 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 خاصة بالشبكات.

بالإضافة إلى ذلك، تم إنشاء مسارَين للنشر في السحابة الإلكترونية لخدمات الخلفية وأعباء العمل، بالإضافة إلى مستودع Artifact Registry لتخزين الصور التي تم إنشاؤها.

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

لقد ضبطت أيضًا kubectl للتفاعل مع مجموعة GKE في Cloud Shell بعد نشر خدمات الخلفية وأعباء العمل.

التالي

قبل أن تتمكن من استخدام الخدمات، يجب تحديد مخطط قاعدة البيانات. ستقوم بإعداد ذلك بعد ذلك.

4. إنشاء مخطط قاعدة البيانات

نظرة عامة

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

إذا نظرت إلى الملفات في دليل $DEMO_HOME/schema/migrations من مستودع الإصدار التجريبي، ستظهر لك سلسلة من ملفات .sql التي تُعرِّف مخطّطنا. وهو يحاكي دورة تطوير يتم فيها تتبُّع تغييرات المخطط في المستودع نفسه، ويمكن ربطها بميزات معيّنة في التطبيقات.

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

Cloud Build

يوضّح ملف $DEMO_HOME/schema/cloudbuild.yaml الخطوات التي سيتم اتّخاذها:

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

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

   chmod +x /workspace/wrench

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

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

هناك خطوتان أساسيتان:

  • تنزيل مفتاح الربط إلى مساحة عمل Cloud Build
  • تشغيل نقل بيانات مفتاح الربط

هناك حاجة إلى متغيّرات مشروع Spanner وبيئة قاعدة البيانات والمثيل من أجل ربط مفتاح الربط بنقطة نهاية الكتابة.

يمكن لتطبيق Cloud Build إجراء هذه التغييرات لأنّه يتم تشغيله كحساب خدمة cloudbuild-cicd@${PROJECT_ID}.iam.gserviceaccount.com:

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

ويحمل حساب الخدمة هذا الدور spanner.databaseUser الذي أضافته Terraform، ما يسمح لحساب الخدمة بتحديث DDL.

عمليات نقل بيانات المخطط

هناك خمس خطوات لنقل البيانات يتم تنفيذها استنادًا إلى الملفات في دليل $DEMO_HOME/schema/migrations. في ما يلي مثال على ملف 000001.sql الذي ينشئ جدول players وفهارس:

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

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

إرسال عملية نقل بيانات المخطط

لإرسال الإصدار لتنفيذ عملية نقل بيانات المخطط، عليك التبديل إلى دليل 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- نشر خدمات الخلفية

نظرة عامة

خدمات الخلفية لهذا الدرس التطبيقي حول الترميز هي واجهات برمجة تطبيقات golang REST تمثل أربع خدمات مختلفة:

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

d36e958411d44b5d.png

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

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

تسمح Workload Identity لحساب خدمة kubernetes بانتحال هوية الخدمات. حساب خدمة السحابة الإلكترونية من google من خلال الخطوات التالية في Terraform:

  • إنشاء مورد حساب خدمة Google Cloud (GSA) للخدمة
  • إسناد الدور databaseUser لحساب الخدمة هذا
  • منح الدور workloadIdentityUser لحساب الخدمة هذا
  • إنشاء حساب خدمة Kubernetes (KSA) يشير إلى نظام أسماء النطاقات (GS)

سيبدو الرسم التخطيطي التقريبي كما يلي:

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
  • تتّبع ميزة "النشر في السحابة الإلكترونية" تعريفات ملف deployment.yaml لكل خدمة. يحتوي ملف نشر الخدمة على معلومات لإنشاء خدمة، والتي هي في هذه الحالة عنوان IP لمجموعة يتم تشغيله على المنفذ 80.

تشير صفحة " يمنع النوع ClusterIP" مجموعات الخدمة الخلفية من الحصول على عنوان IP خارجي، وبالتالي يمكن فقط للكيانات التي يمكنها الاتصال بشبكة GKE الداخلية الوصول إلى خدمات الخلفية. ويجب ألّا تتوفّر للّاعبين إمكانية الوصول المباشر إلى هذه الخدمات لأنّهم يصلون إلى بيانات 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"

وباستخدام هذه المعلومات، حان الوقت لنشر خدمات الخلفية.

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

وكما أسلفنا، نجد أن نشر الخدمات التي تتم في الخلفية يستخدم 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. ألقِ نظرة على تلك العناصر.

بعد تلقّي إشعار النجاح من Cloud Build، انتقِل إلى Cloud Publish (النشر في السحابة الإلكترونية) ثم إلى مسار 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 لكل تحميل عمل

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

انطلق وانشر أعباء العمل!

نشر أعباء العمل

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

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

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

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

817307157d66c661.png

ستترك users وspawn على القيمة 1 التلقائية. بالنسبة إلى 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;

ستظهر لك نتيجتك في أسفل الصفحة.

137ce291a2ff2706.png

لا نحتاج إلى الكثير من المحتوى الأساسي 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. من المفترض أن تظهر لك صفحة "موقع جغرافي" مشابهة للصفحة السابقة.

في هذه الحالة، ستستخدم http://profile للمضيف. ولا يمكنك تحديد بيئة تشغيل في الخيارات المتقدّمة. حدِّد أيضًا أنّ القيمة users هي 4، والتي ستحاكي 4 طلبات مستخدمين في الوقت نفسه.

من المفترض أن يظهر اختبار profile-workload على النحو التالي:

f6e0f06efb0ad6e.png

انقر على "بدء التجول"

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

4c2146e1cb3de23e.png

ملخّص

في هذه الخطوة، أنشأت بعض game_items، ثم قدّمت استعلامًا عن جدول game_items باستخدام واجهة مستخدم Spanner Query في Cloud Console.

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

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

بعد تشغيل أحمال العمل، ستحتاج إلى التحقق من سلوك مجموعة GKE ومثيل Spanner.

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

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

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

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

61d2d766c1f10079.png

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

fa9acc7e26ea04a.png

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

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

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

f194b618969cfa9e.png

والآن، انتقِل إلى خدمة Cloud Spanner.

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

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

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

216212182a57dfd1.png

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

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

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

ملخّص

في هذه الخطوة، تعرفت على كيفية التحقق من بعض مقاييس الأداء الأساسية لكل من GKE Autopilot وSpanner.

على سبيل المثال، أثناء تشغيل أعباء العمل في ملفك الشخصي، يمكنك الاستعلام عن جدول اللاعبون للحصول على مزيد من المعلومات حول البيانات المخزَّنة هناك.

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

بعد ذلك، حان وقت التنظيف!

9. التنظيف

قبل التنظيف، لا تتردد في استكشاف أعباء العمل الأخرى التي لم يتم تناولها. وتحديدًا matchmaking-workloadو game-workload وtradepost-workload.

عندما تنتهي من "اللعب" يمكنك تنظيف ساحة اللعب. لحسن الحظ، هذا سهل جدًا.

أولاً، إذا كان profile-workload لا يزال يعمل في المتصفّح، يُرجى الانتقال إليه وإيقافه:

13ae755a11f3228.png

نفِّذ الخطوات نفسها في ما يتعلّق بكل أعباء عمل اختبرتها.

ثم في Cloud Shell، انتقِل إلى مجلد البنية الأساسية. يجب 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. تهانينا!

تهانينا، لقد نجحت في نشر نماذج تطبيقات golang على GKE Autopilot وربطها بخدمة Cloud Spanner باستخدام Workload Identity.

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

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

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

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