GKE Autopilot के साथ Cloud Spanner को कनेक्ट करना

GKE Autopilot के साथ Cloud Spanner को कनेक्ट करना

इस कोडलैब (कोड बनाना सीखने के लिए ट्यूटोरियल) के बारे में जानकारी

subjectपिछली बार अप्रैल 28, 2023 को अपडेट किया गया
account_circleDerek Downey ने लिखा

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 के साथ इंटरैक्ट करना होगा. साथ ही, बैकएंड सेवाओं को डिप्लॉय करने के बाद, वर्कलोड को डिप्लॉय करना होगा.

इस कोडलैब की सेवाएं, Cloud Spanner Get Started with Games Development कोडलैब की सेवाएं जैसी ही हैं. GKE (जीकेई) पर चल रही सेवाएं पाने और Spanner से कनेक्ट करने के लिए, कोडलैब का इस्तेमाल करना ज़रूरी नहीं है. हालांकि, अगर आपको Spanner पर काम करने वाली उन सेवाओं की खास बातों के बारे में ज़्यादा जानकारी चाहिए, तो उसे देखें.

वर्कलोड और बैकएंड सेवाओं के चलने के दौरान, लोड जनरेट करना शुरू किया जा सकता है. साथ ही, यह देखा जा सकता है कि सेवाएं एक साथ कैसे काम करती हैं.

आखिर में, इस लैब में बनाए गए संसाधनों को मिटाएं.

आपको क्या बनाना होगा

इस लैब का हिस्सा होने के नाते, आपको:

  • टेराफ़ॉर्म का इस्तेमाल करके इन्फ़्रास्ट्रक्चर का प्रावधान करें
  • Cloud Build में स्कीमा माइग्रेशन प्रोसेस का इस्तेमाल करके डेटाबेस स्कीमा बनाएं
  • Cloud Spanner से कनेक्ट करने के लिए, Workload Identity का इस्तेमाल करने वाली चार Golang बैकएंड सेवाओं को डिप्लॉय करें
  • चार वर्कलोड सेवाओं को डिप्लॉय करें. इनका इस्तेमाल बैकएंड सेवाओं के लिए, लोड को सिम्युलेट करने के लिए किया जाता है.

आपको क्या सीखने को मिलेगा

  • टेरेस पर GKE (जीकेई) Autopilot, Cloud Spanner, और Cloud Deploy पाइपलाइन का प्रावधान करने का तरीका
  • Workload Identity, GKE (जीकेई) पर मौजूद सेवाओं को, सेवा खातों के नाम पर काम करने की अनुमति कैसे देता है, ताकि Cloud Spanner के साथ काम करने के लिए, IAM अनुमतियों को ऐक्सेस किया जा सके
  • Locust.io का इस्तेमाल करके, GKE (जीकेई) और Cloud Spanner पर प्रोडक्शन जैसा लोड जनरेट करने का तरीका

आपको किन चीज़ों की ज़रूरत होगी

  • यह ऐसा 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 के तौर पर दिखाया जाएगा.

इसके बाद, अगर आपने पहले से ऐसा नहीं किया है, तो आपको Google Cloud के संसाधनों का इस्तेमाल करने के लिए, Developers Console में बिलिंग चालू करनी होगी. साथ ही, Cloud Spanner API को चालू करना होगा.

15d0ef27a8fब27.png

इस कोडलैब को आज़माने के लिए आपको कुछ डॉलर से ज़्यादा खर्च नहीं करना चाहिए. हालांकि, अगर आप ज़्यादा संसाधनों का इस्तेमाल करने का फ़ैसला करते हैं या उन्हें बंद कर देते हैं, तो यह ज़्यादा हो सकता है (इस दस्तावेज़ के आखिर में "क्लीनअप" सेक्शन देखें). Google Cloud Spanner की कीमत की जानकारी यहां दी गई है. साथ ही, GKE (जीकेई) Autopilot की कीमत के बारे में जानकारी यहां दी गई है.

Google Cloud Platform के नए उपयोगकर्ता 300 डॉलर के मुफ़्त में आज़माने की ज़रूरी शर्तें पूरी करते हैं. इसके तहत, कोडलैब का यह वर्शन बिना किसी शुल्क के इस्तेमाल किया जा सकता है.

Cloud Shell सेट अप करना

Google Cloud और Spanner को आपके लैपटॉप से कहीं से भी ऑपरेट किया जा सकता है. हालांकि, इस कोडलैब में हम Google Cloud Shell का इस्तेमाल करेंगे. यह क्लाउड में चलने वाला कमांड लाइन एनवायरमेंट है.

Debian आधारित इस वर्चुअल मशीन में ऐसे सभी डेवलपमेंट टूल मौजूद हैं जिनकी आपको ज़रूरत पड़ेगी. यह पांच जीबी की स्थायी होम डायरेक्ट्री उपलब्ध कराता है और Google Cloud में चलता है. इससे नेटवर्क की परफ़ॉर्मेंस और पुष्टि करने की प्रक्रिया को बेहतर बनाने में मदद मिलती है. इसका मतलब है कि इस कोडलैब के लिए आपको सिर्फ़ एक ब्राउज़र की ज़रूरत होगी. हां, यह Chromebook पर काम करता है.

  1. Cloud Console से Cloud Shell को चालू करने के लिए, 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 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-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)

खास जानकारी

इस चरण में, आपने एक नया प्रोजेक्ट सेट अप किया है, क्लाउड शेल चालू किया है, और इस लैब के लिए कोड डाउनलोड किया है.

अगला अवॉर्ड

इसके बाद, आपकोterraform का इस्तेमाल करके इन्फ़्रास्ट्रक्चर मुहैया कराना होगा.

3. प्रॉविज़निंग इन्फ़्रास्ट्रक्चर

खास जानकारी

आपका प्रोजेक्ट तैयार है, इसलिए अब इंफ़्रास्ट्रक्चर को काम करने का समय है. इनमें VPC नेटवर्किंग, Cloud Spanner, GKE Autopilot, Artifact Registry जैसी सुविधाएं शामिल हैं. ये GKE (जीकेई) पर चलने वाली इमेज को सेव करती हैं, बैकएंड सेवाओं और वर्कलोड के लिए Cloud Deploy पाइपलाइन के साथ-साथ, सेवा खाते और IAM के खास अधिकार भी शामिल हैं जिनकी मदद से इन सेवाओं का इस्तेमाल किया जा सकता है.

यह एक बड़ी संख्या है. अच्छी बात यह है कि Terraform की मदद से, इसे सेट अप करना आसान हो जाता है. टेराफ़ॉर्म एक "कोड के तौर पर इन्फ़्रास्ट्रक्चर" है इस टूल की मदद से, हम ‘.tf’ सीरीज़ में यह तय कर सकते हैं कि इस प्रोजेक्ट के लिए हमें क्या चाहिए फ़ाइलें शामिल हैं. इससे, प्रॉविज़निंग इन्फ़्रास्ट्रक्चर आसान हो जाता है.

इस कोडलैब को पूरा करने के लिए, Terraform के बारे में जानकारी होना ज़रूरी नहीं है. हालांकि, अगर आपको यह देखना है कि अगले कुछ चरण क्या कर रहे हैं, तो यह देखें कि इन्फ़्रास्ट्रक्चर डायरेक्ट्री में मौजूद इन फ़ाइलों में क्या-क्या बनाया गया है:

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

टेराफ़ॉर्म को कॉन्फ़िगर करें

क्लाउड शेल में, आपको infrastructure डायरेक्ट्री में बदलाव करना होगा और टेराफ़ॉर्म को शुरू करना होगा:

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.tfvars.sample को कॉपी करके और प्रोजेक्ट वैल्यू में बदलाव करके, Terraform को कॉन्फ़िगर करें. अन्य वैरिएबल को भी बदला जा सकता है, लेकिन आपके एनवायरमेंट के साथ काम करने के लिए, सिर्फ़ प्रोजेक्ट को ही बदलना होगा.

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

सबसे पहले, हैमबर्गर मेन्यू पर जाकर और Spanner पर क्लिक करके, Cloud Spanner को देखें. आपको 'ज़्यादा प्रॉडक्ट देखें' पर क्लिक करना पड़ सकता है उसे सूची में ढूंढने के लिए.

इससे आप स्पैनर इंस्टेंस की सूची पर पहुंच जाएंगे. इंस्टेंस पर क्लिक करने पर आपको डेटाबेस दिखेंगे. यह कुछ ऐसी नज़र आनी चाहिए:

10b7fc0c4a86c59.png

GKE (जीकेई) ऑटो पायलट

इसके बाद, हैमबर्गर मेन्यू पर जाकर और Kubernetes Engine => Clusters पर क्लिक करके GKE (जीकेई) देखें. यहां आपको दिखेगा कि sample-games-gke क्लस्टर, Autopilot मोड में चल रहा है.

9cecb1a702e6b7ff.png

Artifact Registry

अब आप देखना चाहेंगे कि चित्र कहां संग्रहित होंगे. इसलिए, हैमबर्गर मेन्यू पर क्लिक करें और Artifact Registry=>Repositories ढूंढें. Artifact Registry, मेन्यू के सीआई/सीडी सेक्शन में होता है.

यहां आपको spanner-game-images नाम की Docker रजिस्ट्री दिखेगी. फ़िलहाल, यह फ़ील्ड खाली रहेगा.

3f805eee312841b.png

Cloud Deploy

Cloud Deploy वह जगह है जहां पाइपलाइन बनाई गई थीं ताकि Cloud Build इमेज बनाने के तरीके बता सके और फिर उन्हें हमारे GKE (जीकेई) क्लस्टर में डिप्लॉय कर सके.

हैमबर्गर मेन्यू पर जाएं और Cloud Deploy खोजें. यह मेन्यू के CI/CD सेक्शन में भी मौजूद है.

यहां आपको दो पाइपलाइन दिखेंगे: एक बैकएंड सेवाओं के लिए और दूसरी वर्कलोड के लिए. वे दोनों, इमेज को एक ही GKE (जीकेई) क्लस्टर में डिप्लॉय करते हैं. हालांकि, इससे हमारे डिप्लॉयमेंट को अलग करने में मदद मिलती है.

d2e4a659145ddf5e.png

IAM

आखिर में, बनाए गए सेवा खातों की पुष्टि करने के लिए, Cloud Console में आईएएम पेज देखें. हैमबर्गर मेन्यू पर जाएं और IAM and Admin=>Service accounts ढूंढें. यह कुछ ऐसी नज़र आनी चाहिए:

bed3d1af94974916.png

टेराफ़ॉर्म ने कुल छह सेवा खाते बनाए हैं:

  • डिफ़ॉल्ट कंप्यूटर सेवा खाता. इस कोडलैब में इसका इस्तेमाल नहीं किया गया है.
  • Cloudbuild-cicd खाते का इस्तेमाल, Cloud Build और Cloud Deploy के चरणों के लिए किया जाता है.
  • चार ‘ऐप्लिकेशन’ ऐसे खाते जिनका इस्तेमाल हमारी बैकएंड सेवाओं में, Cloud Spanner के साथ इंटरैक्ट करने के लिए किया जाता है.

इसके बाद, GKE (जीकेई) क्लस्टर के साथ इंटरैक्ट करने के लिए, आपको kubectl को कॉन्फ़िगर करना होगा.

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

खास जानकारी

बढ़िया! निजी नेटवर्किंग के लिए VPC में, Cloud Spanner इंस्टेंस, GKE ऑटो पायलट क्लस्टर का प्रावधान किया गया.

इसके अलावा, बैकएंड सेवाओं और वर्कलोड के लिए, दो Cloud Deploy पाइपलाइन बनाई गईं. साथ ही, बनाई गई इमेज को स्टोर करने के लिए एक Artifact Registry रिपॉज़िटरी भी बनाई गई.

आखिर में, सेवा खातों को Workload Identity के साथ काम करने के लिए बनाया और कॉन्फ़िगर किया गया, ताकि बैकएंड सेवाएं Cloud Spanner का इस्तेमाल कर सकें.

बैकएंड सेवाओं और वर्कलोड को डिप्लॉय करने के बाद, आपने Cloud Shell में GKE (जीकेई) क्लस्टर के साथ इंटरैक्ट करने के लिए, kubectl को भी कॉन्फ़िगर किया है.

अगला अवॉर्ड

आपको सेवाएं इस्तेमाल करने से पहले, डेटाबेस स्कीमा को तय करना होगा. इसके बाद, यह सेट अप किया जा सकता है.

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 के फ़ाइल फ़ोल्डर में रेंच डाउनलोड करें
  • रेंच माइग्रेशन चलाएं

रिंच को राइट एंडपॉइंट से कनेक्ट करने के लिए, स्पैनर प्रोजेक्ट, इंस्टेंस, और डेटाबेस एनवायरमेंट वैरिएबल की ज़रूरत होती है.

Cloud Build इन बदलावों को कर सकता है, क्योंकि यह cloudbuild-cicd@${PROJECT_ID}.iam.gserviceaccount.com सेवा खाते के तौर पर काम कर रहा है:

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

साथ ही, इस सेवा खाते में Tenraform ने spanner.databaseUser की भूमिका जोड़ी है. इससे सेवा खाते को डीडीएल अपडेट करने की अनुमति मिलती है.

स्कीमा माइग्रेशन

$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. बैकएंड सेवाएं इस्तेमाल करें

खास जानकारी

इस कोडलैब के लिए बैकएंड सेवाएं, golang REST API (एपीआई) हैं, जो चार अलग-अलग सेवाओं के बारे में बताती हैं:

  • प्रोफ़ाइल: खिलाड़ियों को हमारे सैंपल "गेम" के लिए साइन अप करने और पुष्टि करने की सुविधा मिलती है.
  • मैचमेकिंग: मैचमेकिंग फ़ंक्शन में मदद करने के लिए, खिलाड़ी के डेटा के साथ इंटरैक्ट करें, बनाए गए गेम के बारे में जानकारी ट्रैक करें, और गेम बंद होने पर खिलाड़ी के आंकड़े अपडेट करें.
  • आइटम: खिलाड़ियों को गेम खेलने के दौरान आइटम और पैसे पाने में मदद करता है.
  • Tradepost: इसकी मदद से खिलाड़ी, ट्रेडपोस्ट पर आइटम खरीद और बेच सकते हैं

d36e958411d44b5d.png

Cloud Spanner के गेम डेवलपमेंट का इस्तेमाल शुरू करना कोडलैब में, इन सेवाओं के बारे में ज़्यादा जानकारी पाई जा सकती है. हमारे उद्देश्यों के लिए, हम चाहते हैं कि ये सेवाएं हमारे GKE Autopilot क्लस्टर में चलें.

इन सेवाओं के पास स्पैनर डेटा में बदलाव करने की सुविधा होनी चाहिए. ऐसा करने के लिए, हर सेवा के पास एक सेवा खाता होता है, जो उन्हें 'databaseUser' देता है भूमिका.

Workload Identity, kubernetes सेवा खाते को, सेवाओं के नाम का इस्तेमाल करने की अनुमति देता है' google Cloud सेवा खाते को ऐक्सेस करने के लिए, हमारे Terraform में दिया गया तरीका अपनाएं:

  • सेवा के लिए, google Cloud सेवा खाता (GSA) संसाधन बनाएं
  • उस सेवा खाते के लिए databaseUser की भूमिका असाइन करें
  • उस सेवा खाते को workloadIdentityUser की भूमिका असाइन करें
  • GSA से जुड़ा हुआ कोई Kubernetes सेवा खाता (KSA) बनाएं

रॉ डायग्राम ऐसा दिखेगा:

a8662d31d66b5910.png

टेराफ़ॉर्म ने आपके लिए सेवा खाते और Kubernetes सेवा खाते बनाए हैं. साथ ही, kubectl का इस्तेमाल करके, Kubernetes सेवा खातों की जांच की जा सकती है:

# 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 फ़ाइल की परिभाषाओं को फ़ॉलो करेगा. सेवा की डिप्लॉयमेंट फ़ाइल में, सेवा बनाने की जानकारी शामिल है. इस मामले में, पोर्ट 80 पर चलने वाला clusterIP है.

" ClusterIP" टाइप, बैकएंड सर्विस पॉड को बाहरी आईपी इस्तेमाल करने से रोकता है. इस वजह से, सिर्फ़ अंदरूनी GKE (जीकेई) नेटवर्क से कनेक्ट होने वाली इकाइयां, बैकएंड सेवाओं को ऐक्सेस कर सकती हैं. खिलाड़ी इन सेवाओं को सीधे तौर पर ऐक्सेस नहीं कर सकते, क्योंकि वे स्पैनर के डेटा को ऐक्सेस करते हैं और उसमें बदलाव करते हैं.

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 सेवा खाते और Cloud Build के चरण के दौरान बनाई गई इमेज से मेल खाते हैं.

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

इसके बाद, हम नेटवर्किंग और एनवायरमेंट वैरिएबल के बारे में जानकारी देते हैं.

spanner_config एक Kubernetes ConfigMap है, जो ऐप्लिकेशन को स्पैनर से कनेक्ट करने के लिए ज़रूरी प्रोजेक्ट, इंस्टेंस और डेटाबेस की जानकारी की जानकारी देता है.

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

Workloads, Services, और ConfigMaps देखने के लिए, Cloud Console में GKE (जीकेई) यूज़र इंटरफ़ेस (यूआई) पर जाएं.

वर्कलोड

da98979ae49e5a30.png

सेवाएं

406ca2fe7ad4818b.png

ConfigMaps

a0ebd34ee735ee11.png

3b9ef91c77a4e7f0.png

खास जानकारी

इस चरण में, आपने GKE Autopilot में चार बैकएंड सेवाएं डिप्लॉय की हैं. आपके पास Cloud Build के चरण को चलाने और Cloud Deploy में और Cloud Console में Kubernetes पर प्रोग्रेस की जांच करने का विकल्प है.

आपने यह भी जाना कि ये सेवाएं, Workload Identity का इस्तेमाल कैसे करती हैं. इसकी मदद से, कोई ऐसा सेवा खाता बनाया जाता है जिसके पास स्पैनर डेटाबेस में डेटा पढ़ने और उसमें बदलाव करने की अनुमति होती है.

अगले चरण

अगले सेक्शन में, आपको वर्कलोड डिप्लॉय करने होंगे.

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 पोर्ट पर चलता है.

लोड बैलेंसर एक बाहरी आईपी उपलब्ध कराता है, जिसका इस्तेमाल वर्कलोड से कनेक्ट करने के लिए किया जा सकता है.

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

डिप्लॉयमेंट सेक्शन में सबसे ऊपर, वर्कलोड के बारे में मेटाडेटा मौजूद होता है. इस मामले में, सिर्फ़ एक कॉपी डिप्लॉय की जा रही है:

replicas: 1 

हालांकि, कंटेनर की खास जानकारी अलग है. एक बात यह है कि हम default Kubernetes सेवा खाते का इस्तेमाल कर रहे हैं. इस खाते में कोई खास अधिकार नहीं है, क्योंकि वर्कलोड को GKE (जीकेई) क्लस्टर पर चल रही बैकएंड सेवाओं को छोड़कर, किसी भी Google क्लाउड संसाधन से कनेक्ट करने की ज़रूरत नहीं होती.

दूसरा अंतर यह है कि इन वर्कलोड के लिए, एनवायरमेंट वैरिएबल की कोई ज़रूरत नहीं होती. इसकी वजह से डिप्लॉयमेंट का छोटा वर्शन कम हो जाता है.

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 Console में Cloud Build के लॉग और Cloud Deploy पाइपलाइन को देखना न भूलें. वर्कलोड के लिए, Cloud Deploy पाइपलाइन sample-game-workloads है:

डिप्लॉयमेंट पूरा होने के बाद, Cloud Shell में kubectl की मदद से स्टेटस की जांच करें:

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 (जीकेई) क्लस्टर में डिप्लॉय कर दिया है. इन वर्कलोड के लिए किसी अतिरिक्त आईएएम की अनुमति की ज़रूरत नहीं होती. साथ ही, इन्हें लोड बैलेंसर सेवा का इस्तेमाल करके, पोर्ट 8089 पर बाहर से ऐक्सेस किया जा सकता है.

अगले चरण

बैकएंड सेवाओं और वर्कलोड के साथ, अब "चलाएं" का समय है गेम!

7. गेम खेलना शुरू करें

खास जानकारी

आपके सैंपल "गेम" के लिए बैकएंड सेवाएं अब चल रहे हैं और आपके पास "खिलाड़ी" जनरेट करने का तरीका भी है वर्कलोड का इस्तेमाल करके, उन सेवाओं को इस्तेमाल करना.

हर वर्कलोड, हमारे सर्विस एपीआई के मुकाबले असल लोड को सिम्युलेट करने के लिए Locust का इस्तेमाल करता है. इस चरण में, GKE (जीकेई) क्लस्टर और स्पैनर में लोड जनरेट करने के साथ-साथ, स्पैनर में डेटा सेव करने के लिए, कई सारे वर्कलोड चलाए जाएंगे.

यहां हर वर्कलोड का ब्यौरा दिया गया है:

  • item-generator का वर्कलोड, game_items की एक सूची बनाने के लिए एक तेज़ वर्कलोड है, जिसे खिलाड़ी "खेलने" के दौरान हासिल कर सकते हैं जा सकता है.
  • profile-workload में, उन खिलाड़ियों को सिम्युलेट किया जाता है जो साइन अप और लॉग इन करते हैं.
  • matchmaking-workload, गेम असाइन करने के लिए सूची में शामिल होने वाले खिलाड़ियों को सिम्युलेट करता है.
  • game-workload गेम खेलने के दौरान, game_items और पैसे पाने वाले खिलाड़ियों को सिम्युलेट करता है.
  • tradepost-workload उन खिलाड़ियों के बारे में बताता है जिनके पास ट्रेडिंग पोस्ट पर चीज़ें बेचने और खरीदने की सुविधा होती है.

यह कोडलैब, खास तौर पर item-generator और profile-workload को हाइलाइट करेगा.

आइटम-जनरेटर चलाएं

item-generator, game_items को स्पैनर में जोड़ने के लिए, item बैकएंड सेवा एंडपॉइंट का इस्तेमाल करता है. game-workload और tradepost-workload के सही तरीके से काम करने के लिए, ये आइटम ज़रूरी हैं.

सबसे पहले आपको 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

अब आपको यह देखना होगा कि डेटा, स्पैनर डेटाबेस में डाला गया है या नहीं.

ऐसा करने के लिए, हैमबर्गर मेन्यू पर क्लिक करें और 'स्पैनर' पर जाएं. इस पेज से, sample-instance और sample-database पर जाएं. इसके बाद, 'Query' पर क्लिक करें.

हम game_items की संख्या चुनना चाहते हैं:

game_items से COUNT(*) चुनें;

सबसे नीचे, आपको नतीजा दिखेगा.

137ce291a2ff2706.png

हमें बहुत ज़्यादा game_items सीड की ज़रूरत नहीं है. हालांकि, अब वे खिलाड़ियों के लिए उपलब्ध हैं.

प्रोफ़ाइल का वर्कलोड चलाएं

अपने game_items सीड (इनपुट के तौर पर रैंडम संख्या) के साथ, अगला चरण है खिलाड़ियों को गेम खेलने के लिए साइन अप करने देना.

खाते बनाने, लॉग इन करने, प्रोफ़ाइल जानकारी पाने और लॉग आउट करने वाले खिलाड़ियों को सिम्युलेट करने के लिए profile-workload Locust का इस्तेमाल करता है. ये सभी सुविधाएं, profile बैकएंड सेवा के एंडपॉइंट की जांच करती हैं. यह जांच, प्रोडक्शन जैसे सामान्य तौर पर किए जाने वाले वर्कलोड के साथ की जाती है.

इसे चलाने के लिए, 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 को चार पर सेट करें, जो एक बार में चार उपयोगकर्ता अनुरोधों को सिम्युलेट करेगा.

profile-workload टेस्ट कुछ ऐसा दिखना चाहिए:

f6e0f06efb0ad6e.png

‘स्वैमिंग शुरू करें’ पर क्लिक करें!

पहले की तरह ही, अलग-अलग profile REST एंडपॉइंट के लिए आंकड़े दिखने लगेंगे. सभी चीज़ों की परफ़ॉर्मेंस देखने के लिए, चार्ट पर क्लिक करें.

4c2146e1cb3de23e.png

खास जानकारी

इस चरण में, आपने कुछ game_items जनरेट किए थे और फिर Cloud Console में स्पैनर क्वेरी यूज़र इंटरफ़ेस (यूआई) का इस्तेमाल करके game_items टेबल के लिए क्वेरी की.

आपने खिलाड़ियों को अपने गेम के लिए साइन अप करने की भी अनुमति दी है. साथ ही, यह देखा कि Locut कैसे आपकी बैकएंड सेवाओं के लिए प्रोडक्शन जैसा काम कर सकता है.

अगले चरण

वर्कलोड चलाने के बाद, आपको यह देखना होगा कि GKE (जीकेई) क्लस्टर और स्पैनर इंस्टेंस कैसा काम कर रहे हैं.

8. GKE (जीकेई) और स्पैनर के इस्तेमाल की समीक्षा करना

प्रोफ़ाइल सेवा चालू होने के साथ, अब यह देखने के लिए समय है कि आपका GKE ऑटो पायलट क्लस्टर और Cloud Spanner कैसा काम कर रही है.

GKE (जीकेई) क्लस्टर की जांच करें

Kubernetes क्लस्टर पर जाएं. ध्यान दें कि आपने वर्कलोड और सेवाएं डिप्लॉय की हैं. इसलिए, अब क्लस्टर में कुल वीसीपीयू और मेमोरी के बारे में कुछ जानकारी जोड़ी गई है. यह जानकारी तब उपलब्ध नहीं थी, जब क्लस्टर पर कोई वर्कलोड नहीं था.

61d2d766c1f10079.png

अब, sample-game-gke क्लस्टर पर क्लिक करें और निगरानी करने की सुविधा वाले टैब पर स्विच करें:

fa9acc7e26ea04a.png

default kubernetes नेमस्पेस, सीपीयू के इस्तेमाल के लिए, kube-system नेमस्पेस को पार कर गया होगा. ऐसा इसलिए, क्योंकि हमारा वर्कलोड और बैकएंड सेवाएं default पर चलती हैं. अगर ऐसा नहीं है, तो पक्का करें कि profile workload अब भी चल रहा है और कुछ मिनट इंतज़ार करें, ताकि चार्ट अपडेट हो सकें.

यह देखने के लिए कि कौनसे वर्कलोड सबसे ज़्यादा संसाधनों का इस्तेमाल कर रहे हैं, Workloads के डैशबोर्ड पर जाएं.

हर वर्कलोड को अलग से देखने के बजाय, सीधे डैशबोर्ड के 'निगरानी करें' टैब पर जाएं. आपको दिखेगा कि profile और profile-workload सीपीयू बढ़ गया है.

f194b618969cfa9e.png

अब Cloud Spanner की जांच करें.

Cloud Spanner इंस्टेंस की जांच करना

क्लाउड स्पैनर की परफ़ॉर्मेंस देखने के लिए, स्पैनर पर जाएं और sample-instance इंस्टेंस और sample-game डेटाबेस पर क्लिक करें.

यहां आपको बाएं मेन्यू में, System Insights टैब दिखेगा:

216212182a57dfd1.png

स्पैनर इंस्टेंस की परफ़ॉर्मेंस को समझने में आपकी मदद करने के लिए यहां कई चार्ट दिए गए हैं. इनमें CPU utilization, transaction latency and locking, और query throughput शामिल हैं.

System Insights के अलावा, क्वेरी के वर्कलोड के बारे में ज़्यादा जानकारी पाने के लिए, निगरानी की सुविधा वाले सेक्शन में दिए गए अन्य लिंक पर जाएं:

  • क्वेरी इनसाइट की मदद से, स्पैनर में मौजूद संसाधनों का इस्तेमाल करने वाली टॉपN क्वेरी की पहचान की जा सकती है.
  • लेन-देन और लॉक से जुड़ी अहम जानकारी की मदद से, ज़्यादा इंतज़ार वाले लेन-देन की पहचान की जा सकती है.
  • कुंजी विज़ुअलाइज़र, ऐक्सेस पैटर्न को विज़ुअलाइज़ करने में मदद करता है. साथ ही, डेटा में हॉटस्पॉट को ट्रैक करने में भी मदद कर सकता है.

खास जानकारी

इस चरण में, आपने 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. बधाई हो!

बधाई हो, आपने GKE Autopilot पर सैंपल golang ऐप्लिकेशन को सफलतापूर्वक डिप्लॉय कर दिया है और Workload Identity का इस्तेमाल करके उन्हें Cloud Spanner से कनेक्ट कर लिया!

बोनस के तौर पर, Terraform का इस्तेमाल करके इस इन्फ़्रास्ट्रक्चर को आसानी से सेट अप किया गया और बार-बार इस्तेमाल किया गया.

इस कोडलैब में, Google Cloud की उन सेवाओं के बारे में ज़्यादा जानकारी देखी जा सकती है जिनसे आपने इंटरैक्ट किया है:

आगे क्या करना है?

अब आपको यह समझ आ गया है कि GKE Autopilot और Cloud Spanner एक साथ काम कैसे करें, तो क्यों न अगला कदम उठाएं और इन सेवाओं के साथ काम करने के लिए अपना खुद का ऐप्लिकेशन बनाना शुरू करें?