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

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 का इस्तेमाल शुरू करना कोडलैब में इस्तेमाल की गई सेवाओं के जैसी ही हैं. GKE पर सेवाएं चलाने और Spanner से कनेक्ट करने के लिए, उस कोडलैब को पूरा करना ज़रूरी नहीं है. हालांकि, अगर आपको Spanner पर काम करने वाली सेवाओं के बारे में ज़्यादा जानकारी चाहिए, तो इसे देखें.

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

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

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

इस लैब में आपको ये काम करने होंगे:

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

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

  • Terraform का इस्तेमाल करके, 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 ( console.cloud.google.com) में साइन इन करें और एक नया प्रोजेक्ट बनाएं.

अगर आपके पास पहले से कोई प्रोजेक्ट है, तो कंसोल में सबसे ऊपर बाईं ओर मौजूद, प्रोजेक्ट चुनने वाले पुल-डाउन मेन्यू पर क्लिक करें:

6c9406d9b014760.png

इसके बाद, नया प्रोजेक्ट बनाने के लिए, डायलॉग बॉक्स में ‘नया प्रोजेक्ट' बटन पर क्लिक करें:

949d83c8a4ee17d9.png

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

870a3cbd6541ee86.png

इसके बाद, प्रोजेक्ट बनाने के डायलॉग बॉक्स में, नए प्रोजेक्ट की जानकारी डाली जा सकती है:

6a92c57d3250a4b3.png

प्रोजेक्ट आईडी याद रखें. यह सभी Google Cloud प्रोजेक्ट के लिए एक यूनीक नाम होता है. ऊपर दिया गया नाम पहले ही इस्तेमाल किया जा चुका है. इसलिए, यह आपके लिए काम नहीं करेगा. माफ़ करें! इस कोड लैब में इसे बाद में PROJECT_ID के तौर पर दिखाया जाएगा.

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

15d0ef27a8fbab27.png

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

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

Cloud Shell का सेटअप

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

यह Debian पर आधारित वर्चुअल मशीन है. इसमें डेवलपमेंट के लिए ज़रूरी सभी टूल पहले से मौजूद हैं. यह 5 जीबी की होम डायरेक्ट्री उपलब्ध कराता है और 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

Screen Shot 2017-06-14 at 10.13.43 PM.png

Cloud Shell से कनेक्ट होने के बाद, आपको दिखेगा कि आपकी पुष्टि पहले ही हो चुकी है और प्रोजेक्ट पहले से ही आपके PROJECT_ID पर सेट है.

gcloud auth list

कमांड आउटपुट

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

gcloud config list project

कमांड आउटपुट

[core]
project = <PROJECT_ID>

अगर किसी वजह से प्रोजेक्ट सेट नहीं है, तो यह कमांड दें:

gcloud config set project <PROJECT_ID>

क्या आपको PROJECT_ID की तलाश है? देखें कि आपने सेटअप के दौरान किस आईडी का इस्तेमाल किया था या Cloud Console के डैशबोर्ड में जाकर इसे देखें:

158fNPfwSxsFqz9YbtJVZes8viTS3d1bV4CVhij3XPxuzVFOtTObnwsphlm6lYGmgdMFwBJtc-FaLrZU7XHAg_ZYoCrgombMRR3h-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. इन्फ़्रास्ट्रक्चर उपलब्ध कराना

खास जानकारी

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

यह बहुत ज़्यादा है. हालांकि, Terraform की मदद से, इसे आसानी से सेट अप किया जा सकता है. Terraform, "Infrastructure as Code" टूल है. इसकी मदद से, हम इस प्रोजेक्ट के लिए ज़रूरी चीज़ों के बारे में बता सकते हैं. इसके लिए, हमें ‘.tf' फ़ाइलों की सीरीज़ का इस्तेमाल करना होता है. इससे इंफ़्रास्ट्रक्चर को आसानी से उपलब्ध कराया जा सकता है.

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

  • 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.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 की जांच करें. इसे सूची में ढूंढने के लिए, आपको ‘ज़्यादा प्रॉडक्ट देखें' पर क्लिक करना पड़ सकता है.

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

10b7fc0c4a86c59.png

GKE Autopilot

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

9cecb1a702e6b7ff.png

Artifact Registry

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

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

3f805eee312841b.png

Cloud Deploy

Cloud Deploy में पाइपलाइन बनाई गई थीं, ताकि Cloud Build इमेज बनाने के लिए चरण दे सके. इसके बाद, उन्हें हमारे GKE क्लस्टर पर डिप्लॉय किया जा सके.

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

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

d2e4a659145ddf5e.png

IAM

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

bed3d1af94974916.png

Terraform ने कुल छह सेवा खाते बनाए हैं:

  • यह कंप्यूटर का डिफ़ॉल्ट सेवा खाता होता है. इस कोड लैब में इसका इस्तेमाल नहीं किया गया है.
  • 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

खास जानकारी

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

इसके अलावा, बैकएंड सेवाओं और वर्कलोड के लिए दो 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 के फ़ाइल फ़ोल्डर में रिंच डाउनलोड करें
  • रेंच माइग्रेशन चलाएं

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

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

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

इस सेवा खाते में Terraform ने spanner.databaseUser भूमिका जोड़ी है. इससे सेवा खाते को updateDDL की अनुमति मिलती है.

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

माइग्रेशन के पांच चरण होते हैं. ये चरण, $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 का इस्तेमाल करके शुरुआती स्कीमा माइग्रेशन सबमिट किया. इसमें पांच अलग-अलग DDL ऑपरेशन लागू किए गए थे. इन कार्रवाइयों से पता चलता है कि डेटाबेस स्कीमा में बदलाव करने वाली सुविधाएं कब जोड़ी गईं.

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

ऐसे बदलावों के लिए जो पुराने वर्शन के साथ काम नहीं करते, आपको ऐप्लिकेशन और स्कीमा में बदलावों को अलग-अलग चरणों में लागू करना होगा, ताकि यह पक्का किया जा सके कि कोई रुकावट न आए.

अगला

स्कीमा लागू करने के बाद, अगला चरण बैकएंड सेवाओं को डिप्लॉय करना है!

5. बैकएंड सेवाओं को डिप्लॉय करना

खास जानकारी

इस कोडलैब के लिए बैकएंड सेवाएं, golang REST API हैं. ये चार अलग-अलग सेवाओं को दिखाती हैं:

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

d36e958411d44b5d.png

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

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

Workload Identity की मदद से, Kubernetes सेवा खाता, सेवाओं के Google Cloud सेवा खाते के तौर पर काम कर सकता है. इसके लिए, हमारे Terraform में यह तरीका अपनाएं:

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

एक सामान्य डायग्राम कुछ ऐसा दिखेगा:

a8662d31d66b5910.png

Terraform ने आपके लिए सेवा खाते और 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" टाइप, बैकएंड सेवा पॉड को बाहरी आईपी से कनेक्ट होने से रोकता है. इसलिए, सिर्फ़ वे इकाइयां बैकएंड सेवाओं को ऐक्सेस कर सकती हैं जो इंटरनल GKE नेटवर्क से कनेक्ट हो सकती हैं. इन सेवाओं को सीधे तौर पर खिलाड़ियों के लिए उपलब्ध नहीं कराया जाना चाहिए, क्योंकि ये Spanner डेटा को ऐक्सेस और उसमें बदलाव करती हैं.

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

Cloud Deploy, Kubernetes सेवा बनाने के साथ-साथ Kubernetes डिप्लॉयमेंट भी बनाता है. आइए, profile सेवा के डिप्लॉयमेंट सेक्शन की जांच करें:

---
apiVersion: apps/v1
kind: Deployment
metadata:
 name: profile
spec:
 replicas: 2 # EDIT: Number of instances of deployment
 selector:
   matchLabels:
     app: profile
 template:
   metadata:
     labels:
       app: profile
   spec:
     serviceAccountName: profile-app
     containers:
     - name: profile-service
       image: profile
       ports:
         - containerPort: 80
       envFrom:
         - configMapRef:
             name: spanner-config
       env:
         - name: SERVICE_HOST
           value: "0.0.0.0"
         - name: SERVICE_PORT
           value: "80"
       resources:
         requests:
           cpu: "1"
           memory: "1Gi"
           ephemeral-storage: "100Mi"
         limits:
           cpu: "1"
           memory: "1Gi"
           ephemeral-storage: "100Mi"

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

replicas: 2 # EDIT: Number of instances of deployment

इसके बाद, हम यह देखते हैं कि ऐप्लिकेशन को किस सेवा खाते से चलाना है और उसे किस इमेज का इस्तेमाल करना है. ये Terraform से बनाए गए Kubernetes सेवा खाते और 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 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 का इस्तेमाल कैसे करती हैं. इस सेवा खाते के पास, Spanner डेटाबेस में डेटा को पढ़ने और लिखने की अनुमतियां होती हैं.

अगले चरण

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

6. वर्कलोड डिप्लॉय करना

खास जानकारी

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

dd900485e2eeb611.png

वर्कलोड को बाहरी तौर पर ऐक्सेस किया जा सकता है. इस कोडलैब के लिए, हर बैकएंड सेवा के लिए एक वर्कलोड होता है.

ये वर्कलोड, Locust पर आधारित लोड जनरेशन स्क्रिप्ट हैं. ये स्क्रिप्ट, सैंपल सेवाओं के लिए अनुमानित ऐक्सेस पैटर्न की नकल करती हैं.

Cloud Build प्रोसेस के लिए ये फ़ाइलें मौजूद हैं:

  • $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, एक बाहरी आईपी पता उपलब्ध कराएगा. इसका इस्तेमाल, वर्कलोड से कनेक्ट करने के लिए किया जा सकता है.

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 Cloud संसाधन से कनेक्ट करने की ज़रूरत नहीं है.

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

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

अगले चरण

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

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

खास जानकारी

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

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

यहां हर वर्कलोड के बारे में जानकारी दी गई है:

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

इस कोडलैब में, खास तौर पर item-generator और profile-workload को चलाने के बारे में बताया जाएगा.

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

item-generator, item बैकएंड सेवा के एंडपॉइंट का इस्तेमाल करके, Spanner में game_items जोड़ता है. 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 एंडपॉइंट पर किए जा रहे अनुरोधों के आंकड़े दिखने लगेंगे. दस सेकंड बाद, लोड होना बंद हो जाएगा.

Charts पर क्लिक करें. इसके बाद, आपको इन अनुरोधों की परफ़ॉर्मेंस के बारे में कुछ ग्राफ़ दिखेंगे.

abad0a9f3c165345.png

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

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

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

SELECT COUNT(*) FROM game_items;

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

137ce291a2ff2706.png

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

profile-workload को चलाएं

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 पर ले जाएं. आपको Locust का पेज दिखेगा, जो पिछले पेज जैसा होगा.

इस मामले में, होस्ट के लिए http://profile का इस्तेमाल किया जाएगा. साथ ही, ऐडवांस विकल्पों में रनटाइम तय नहीं किया जाएगा. साथ ही, users को 4 पर सेट करें. इससे एक साथ चार उपयोगकर्ताओं के अनुरोधों को सिम्युलेट किया जा सकेगा.

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

f6e0f06efb0ad6e.png

‘स्टॉर्मिंग शुरू करें' पर क्लिक करें!

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

4c2146e1cb3de23e.png

खास जानकारी

इस चरण में, आपने कुछ game_items जनरेट किए. इसके बाद, Cloud Console में Spanner Query UI का इस्तेमाल करके, game_items टेबल को क्वेरी किया.

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

अगले चरण

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

8. GKE और Spanner के इस्तेमाल की समीक्षा करना

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

GKE क्लस्टर की जांच करना

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

61d2d766c1f10079.png

अब, sample-game-gke क्लस्टर पर क्लिक करें और 'निगरानी' टैब पर जाएं:

fa9acc7e26ea04a.png

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

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

हर वर्कलोड में अलग-अलग जाने के बजाय, सीधे डैशबोर्ड के Observability टैब पर जाएं. आपको दिखेगा कि 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.

सिस्टम की परफ़ॉर्मेंस से जुड़ी अहम जानकारी के अलावा, क्वेरी वर्कलोड के बारे में ज़्यादा जानकारी पाने के लिए, Observability सेक्शन में मौजूद अन्य लिंक देखें:

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

खास जानकारी

इस चरण में, आपने GKE Autopilot और Spanner, दोनों के लिए परफ़ॉर्मेंस से जुड़ी कुछ बुनियादी मेट्रिक देखने का तरीका सीखा.

उदाहरण के लिए, अपनी प्रोफ़ाइल के वर्कलोड को चालू करके, players टेबल से क्वेरी करें. इससे आपको उस टेबल में सेव किए जा रहे डेटा के बारे में ज़्यादा जानकारी मिलेगी.

अगले चरण

अब बारी है साफ़-सफ़ाई की!

9. स्टोरेज खाली करना

क्लीन अप करने से पहले, उन अन्य वर्कलोड को एक्सप्लोर करें जिन्हें कवर नहीं किया गया था. खास तौर पर, matchmaking-workload, game-workload, और tradepost-workload.

गेम "खेलने" के बाद, अपने प्लेग्राउंड को साफ़ किया जा सकता है. अच्छी बात यह है कि ऐसा करना बहुत आसान है.

अगर profile-workload अब भी ब्राउज़र में चल रहा है, तो इसे बंद करें:

13ae755a11f3228.png

आपने जिन वर्कलोड की जांच की है उनके लिए भी यही तरीका अपनाएं.

इसके बाद, Cloud Shell में इन्फ़्रास्ट्रक्चर फ़ोल्डर पर जाएं. आपको terraform का इस्तेमाल करके, इन्फ़्रास्ट्रक्चर को destroy करना होगा:

cd $DEMO_HOME/infrastructure
terraform destroy
# type 'yes' when asked

कमांड आउटपुट

Plan: 0 to add, 0 to change, 46 to destroy.

Do you really want to destroy all resources?
  Terraform will destroy all your managed infrastructure, as shown above.
  There is no undo. Only 'yes' will be accepted to confirm.

  Enter a value: yes

*snip*

Destroy complete! Resources: 46 destroyed.

Cloud Console में, Spanner, Kubernetes Cluster, Artifact Registry, Cloud Deploy, और IAM पर जाएं. इससे यह पुष्टि की जा सकेगी कि सभी संसाधन हटा दिए गए हैं.

10. बधाई हो!

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

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

इस कोडलैब में इस्तेमाल की गई Google Cloud सेवाओं के बारे में ज़्यादा जानें:

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

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