इस कोडलैब (कोड बनाना सीखने के लिए ट्यूटोरियल) के बारे में जानकारी
1. परिचय
Cloud Spanner पूरी तरह से मैनेज की गई, हॉरिज़ॉन्टल तौर पर बढ़ाने लायक, दुनिया भर में डिस्ट्रिब्यूट की जाने वाली, रिलेशनल डेटाबेस सेवा है. यह परफ़ॉर्मेंस और ज़्यादा उपलब्धता को छोड़े बिना, ACID लेन-देन और SQL सिमैंटिक उपलब्ध कराती है.
GKE Autopilot, GKE में कार्रवाई का एक मोड है. इसमें Google आपके क्लस्टर कॉन्फ़िगरेशन को मैनेज करता है. इसमें आपके नोड, स्केलिंग, सुरक्षा, और सबसे सही तरीकों का पालन करने के लिए पहले से कॉन्फ़िगर की गई अन्य सेटिंग शामिल हैं. उदाहरण के लिए, GKE Autopilot सेवा की अनुमतियों को मैनेज करने के लिए Workload Identity को चालू करता है.
इस लैब का मकसद, आपको GKE Autopilot पर चल रही कई बैकएंड सेवाओं को Cloud Spanner डेटाबेस से जोड़ने की प्रोसेस के बारे में बताना है.
इस लैब में, आपको सबसे पहले एक प्रोजेक्ट सेट अप करना होगा और Cloud Shell को लॉन्च करना होगा. इसके बाद, आपकोterraform का इस्तेमाल करके इन्फ़्रास्ट्रक्चर डिप्लॉय करना होगा.
इसके बाद, आपको गेम डेटाबेस के लिए शुरुआती स्कीमा माइग्रेशन करने के लिए, Cloud Build और Cloud Deploy के साथ इंटरैक्ट करना होगा. साथ ही, बैकएंड सेवाओं को डिप्लॉय करने के बाद, वर्कलोड को डिप्लॉय करना होगा.
इस कोडलैब की सेवाएं, Cloud Spanner 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 पर प्रोडक्शन जैसा लोड जनरेट करने का तरीका
आपको किन चीज़ों की ज़रूरत होगी
2. सेटअप और ज़रूरी शर्तें
प्रोजेक्ट बनाना
अगर आपके पास पहले से Google खाता (Gmail या Google Apps) नहीं है, तो आपको एक खाता बनाना होगा. Google Cloud Platform कंसोल ( console.cloud.google.com) में साइन इन करें और एक नया प्रोजेक्ट बनाएं.
अगर आपके पास पहले से कोई प्रोजेक्ट है, तो कंसोल के ऊपर बाईं ओर मौजूद, प्रोजेक्ट चुनने के लिए पुल डाउन मेन्यू पर क्लिक करें:
और 'नया प्रोजेक्ट' पर क्लिक करें बटन:
अगर आपके पास पहले से कोई प्रोजेक्ट नहीं है, तो आपको अपना पहला प्रोजेक्ट बनाने के लिए इस तरह का डायलॉग दिखेगा:
इसके बाद, प्रोजेक्ट बनाने वाले डायलॉग बॉक्स की मदद से अपने नए प्रोजेक्ट की जानकारी डाली जा सकती है:
वह प्रोजेक्ट आईडी याद रखें जो Google Cloud के सभी प्रोजेक्ट के लिए एक यूनीक नाम होता है. ऊपर दिया गया नाम पहले ही किसी दूसरे प्रोजेक्ट के लिए इस्तेमाल किया जा चुका है. इसलिए, यह आपके लिए काम नहीं करेगा! बाद में, इस कोडलैब को इस कोडलैब में PROJECT_ID
के तौर पर दिखाया जाएगा.
इसके बाद, अगर आपने पहले से ऐसा नहीं किया है, तो आपको Google Cloud के संसाधनों का इस्तेमाल करने के लिए, Developers Console में बिलिंग चालू करनी होगी. साथ ही, Cloud Spanner API को चालू करना होगा.
इस कोडलैब को आज़माने के लिए आपको कुछ डॉलर से ज़्यादा खर्च नहीं करना चाहिए. हालांकि, अगर आप ज़्यादा संसाधनों का इस्तेमाल करने का फ़ैसला करते हैं या उन्हें बंद कर देते हैं, तो यह ज़्यादा हो सकता है (इस दस्तावेज़ के आखिर में "क्लीनअप" सेक्शन देखें). Google Cloud Spanner की कीमत की जानकारी यहां दी गई है. साथ ही, GKE (जीकेई) Autopilot की कीमत के बारे में जानकारी यहां दी गई है.
Google Cloud Platform के नए उपयोगकर्ता 300 डॉलर के मुफ़्त में आज़माने की ज़रूरी शर्तें पूरी करते हैं. इसके तहत, कोडलैब का यह वर्शन बिना किसी शुल्क के इस्तेमाल किया जा सकता है.
Cloud Shell सेट अप करना
Google Cloud और Spanner को आपके लैपटॉप से कहीं से भी ऑपरेट किया जा सकता है. हालांकि, इस कोडलैब में हम Google Cloud Shell का इस्तेमाल करेंगे. यह क्लाउड में चलने वाला कमांड लाइन एनवायरमेंट है.
Debian आधारित इस वर्चुअल मशीन में ऐसे सभी डेवलपमेंट टूल मौजूद हैं जिनकी आपको ज़रूरत पड़ेगी. यह पांच जीबी की स्थायी होम डायरेक्ट्री उपलब्ध कराता है और Google Cloud में चलता है. इससे नेटवर्क की परफ़ॉर्मेंस और पुष्टि करने की प्रक्रिया को बेहतर बनाने में मदद मिलती है. इसका मतलब है कि इस कोडलैब के लिए आपको सिर्फ़ एक ब्राउज़र की ज़रूरत होगी. हां, यह Chromebook पर काम करता है.
- Cloud Console से Cloud Shell को चालू करने के लिए, Cloud Shell को चालू करें
पर क्लिक करें. प्रावधान करने और एनवायरमेंट से कनेक्ट होने में कुछ ही समय लगेगा.
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 के डैशबोर्ड में देखें:
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 को देखें. आपको 'ज़्यादा प्रॉडक्ट देखें' पर क्लिक करना पड़ सकता है उसे सूची में ढूंढने के लिए.
इससे आप स्पैनर इंस्टेंस की सूची पर पहुंच जाएंगे. इंस्टेंस पर क्लिक करने पर आपको डेटाबेस दिखेंगे. यह कुछ ऐसी नज़र आनी चाहिए:
GKE (जीकेई) ऑटो पायलट
इसके बाद, हैमबर्गर मेन्यू पर जाकर और Kubernetes Engine => Clusters
पर क्लिक करके GKE (जीकेई) देखें. यहां आपको दिखेगा कि sample-games-gke
क्लस्टर, Autopilot मोड में चल रहा है.
Artifact Registry
अब आप देखना चाहेंगे कि चित्र कहां संग्रहित होंगे. इसलिए, हैमबर्गर मेन्यू पर क्लिक करें और Artifact Registry=>Repositories
ढूंढें. Artifact Registry, मेन्यू के सीआई/सीडी सेक्शन में होता है.
यहां आपको spanner-game-images
नाम की Docker रजिस्ट्री दिखेगी. फ़िलहाल, यह फ़ील्ड खाली रहेगा.
Cloud Deploy
Cloud Deploy वह जगह है जहां पाइपलाइन बनाई गई थीं ताकि Cloud Build इमेज बनाने के तरीके बता सके और फिर उन्हें हमारे GKE (जीकेई) क्लस्टर में डिप्लॉय कर सके.
हैमबर्गर मेन्यू पर जाएं और Cloud Deploy
खोजें. यह मेन्यू के CI/CD सेक्शन में भी मौजूद है.
यहां आपको दो पाइपलाइन दिखेंगे: एक बैकएंड सेवाओं के लिए और दूसरी वर्कलोड के लिए. वे दोनों, इमेज को एक ही GKE (जीकेई) क्लस्टर में डिप्लॉय करते हैं. हालांकि, इससे हमारे डिप्लॉयमेंट को अलग करने में मदद मिलती है.
IAM
आखिर में, बनाए गए सेवा खातों की पुष्टि करने के लिए, Cloud Console में आईएएम पेज देखें. हैमबर्गर मेन्यू पर जाएं और IAM and Admin=>Service accounts
ढूंढें. यह कुछ ऐसी नज़र आनी चाहिए:
टेराफ़ॉर्म ने कुल छह सेवा खाते बनाए हैं:
- डिफ़ॉल्ट कंप्यूटर सेवा खाता. इस कोडलैब में इसका इस्तेमाल नहीं किया गया है.
- 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 के बिल्ड पर ले जाएगा. इससे आपको बिल्ड की प्रोग्रेस को मॉनिटर करने और यह जानने में मदद मिलेगी कि वह क्या कर रहा है.
खास जानकारी
इस चरण में, आपने पांच अलग-अलग डीडीएल कार्रवाइयां लागू करने वाले शुरुआती स्कीमा माइग्रेशन को सबमिट करने के लिए, Cloud Build का इस्तेमाल किया था. इन कार्रवाइयों से पता चलता है कि डेटाबेस स्कीमा में बदलाव की ज़रूरत के लिए सुविधाएं कब जोड़ी गई थीं.
डेवलपमेंट की सामान्य स्थिति में, हो सकता है कि आप मौजूदा ऐप्लिकेशन के हिसाब से स्कीमा में बदलाव करने के साथ-साथ काम करने के दौरान होने वाली रुकावटों से बचना चाहें.
ऐसे बदलाव जो पुराने सिस्टम के साथ काम नहीं करते, उनके लिए आपको ऐप्लिकेशन और स्कीमा में बदलावों को अलग-अलग चरणों में डिप्लॉय करना चाहिए, ताकि कोई रुकावट न आए.
अगला अवॉर्ड
स्कीमा लागू होने के बाद, अगला कदम बैकएंड सेवाओं को डिप्लॉय करना है!
5. बैकएंड सेवाएं इस्तेमाल करें
खास जानकारी
इस कोडलैब के लिए बैकएंड सेवाएं, golang REST API (एपीआई) हैं, जो चार अलग-अलग सेवाओं के बारे में बताती हैं:
- प्रोफ़ाइल: खिलाड़ियों को हमारे सैंपल "गेम" के लिए साइन अप करने और पुष्टि करने की सुविधा मिलती है.
- मैचमेकिंग: मैचमेकिंग फ़ंक्शन में मदद करने के लिए, खिलाड़ी के डेटा के साथ इंटरैक्ट करें, बनाए गए गेम के बारे में जानकारी ट्रैक करें, और गेम बंद होने पर खिलाड़ी के आंकड़े अपडेट करें.
- आइटम: खिलाड़ियों को गेम खेलने के दौरान आइटम और पैसे पाने में मदद करता है.
- Tradepost: इसकी मदद से खिलाड़ी, ट्रेडपोस्ट पर आइटम खरीद और बेच सकते हैं
Cloud Spanner के गेम डेवलपमेंट का इस्तेमाल शुरू करना कोडलैब में, इन सेवाओं के बारे में ज़्यादा जानकारी पाई जा सकती है. हमारे उद्देश्यों के लिए, हम चाहते हैं कि ये सेवाएं हमारे GKE Autopilot क्लस्टर में चलें.
इन सेवाओं के पास स्पैनर डेटा में बदलाव करने की सुविधा होनी चाहिए. ऐसा करने के लिए, हर सेवा के पास एक सेवा खाता होता है, जो उन्हें 'databaseUser' देता है भूमिका.
Workload Identity, kubernetes सेवा खाते को, सेवाओं के नाम का इस्तेमाल करने की अनुमति देता है' google Cloud सेवा खाते को ऐक्सेस करने के लिए, हमारे Terraform में दिया गया तरीका अपनाएं:
- सेवा के लिए, google Cloud सेवा खाता (
GSA
) संसाधन बनाएं - उस सेवा खाते के लिए databaseUser की भूमिका असाइन करें
- उस सेवा खाते को workloadIdentityUser की भूमिका असाइन करें
- GSA से जुड़ा हुआ कोई Kubernetes सेवा खाता (
KSA
) बनाएं
रॉ डायग्राम ऐसा दिखेगा:
टेराफ़ॉर्म ने आपके लिए सेवा खाते और 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
बिल्ड के काम करने का तरीका यहां बताया गया है:
- टेराफ़ॉर्म ने
$DEMO_HOME/backend_services/cloudbuild.yaml
फ़ाइल जनरेट की है, जो कुछ ऐसी दिखती है:
serviceAccount: projects/${PROJECT_ID}/serviceAccounts/cloudbuild-cicd@${PROJECT_ID}.iam.gserviceaccount.com
steps:
#
# Building of images
#
- name: gcr.io/cloud-builders/docker
id: profile
args: ["build", ".", "-t", "${_PROFILE_IMAGE}"]
dir: profile
waitFor: ['-']
- name: gcr.io/cloud-builders/docker
id: matchmaking
args: ["build", ".", "-t", "${_MATCHMAKING_IMAGE}"]
dir: matchmaking
waitFor: ['-']
- name: gcr.io/cloud-builders/docker
id: item
args: ["build", ".", "-t", "${_ITEM_IMAGE}"]
dir: item
waitFor: ['-']
- name: gcr.io/cloud-builders/docker
id: tradepost
args: ["build", ".", "-t", "${_TRADEPOST_IMAGE}"]
dir: tradepost
waitFor: ['-']
#
# Deployment
#
- name: gcr.io/google.com/cloudsdktool/cloud-sdk
id: cloud-deploy-release
entrypoint: gcloud
args:
[
"deploy", "releases", "create", "${_REL_NAME}",
"--delivery-pipeline", "sample-game-services",
"--skaffold-file", "skaffold.yaml",
"--skaffold-version", "1.39",
"--images", "profile=${_PROFILE_IMAGE},matchmaking=${_MATCHMAKING_IMAGE},item=${_ITEM_IMAGE},tradepost=${_TRADEPOST_IMAGE}",
"--region", "us-central1"
]
artifacts:
images:
- ${_REGISTRY}/profile
- ${_REGISTRY}/matchmaking
- ${_REGISTRY}/item
- ${_REGISTRY}/tradepost
substitutions:
_PROFILE_IMAGE: ${_REGISTRY}/profile:${BUILD_ID}
_MATCHMAKING_IMAGE: ${_REGISTRY}/matchmaking:${BUILD_ID}
_ITEM_IMAGE: ${_REGISTRY}/item:${BUILD_ID}
_TRADEPOST_IMAGE: ${_REGISTRY}/tradepost:${BUILD_ID}
_REGISTRY: us-docker.pkg.dev/${PROJECT_ID}/spanner-game-images
_REL_NAME: rel-${BUILD_ID:0:8}
options:
dynamic_substitutions: true
machineType: E2_HIGHCPU_8
logging: CLOUD_LOGGING_ONLY
- Cloud Build का निर्देश इस फ़ाइल को पढ़ता है और दिए गए निर्देशों का पालन करता है. सबसे पहले, यह सेवा की इमेज बनाता है. इसके बाद, यह
gcloud deploy create
कमांड लागू करता है. यह$DEMO_HOME/backend_services/skaffold.yaml
फ़ाइल को पढ़ता है, जिससे पता चलता है कि हर डिप्लॉयमेंट फ़ाइल कहां मौजूद है:
apiVersion: skaffold/v2beta29
kind: Config
deploy:
kubectl:
manifests:
- spanner_config.yaml
- profile/deployment.yaml
- matchmaking/deployment.yaml
- item/deployment.yaml
- tradepost/deployment.yaml
- Cloud Deploy, हर सेवा की
deployment.yaml
फ़ाइल की परिभाषाओं को फ़ॉलो करेगा. सेवा की डिप्लॉयमेंट फ़ाइल में, सेवा बनाने की जानकारी शामिल है. इस मामले में, पोर्ट 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
पाइपलाइन पर जाकर, डिप्लॉयमेंट की प्रोग्रेस पर नज़र रखें.
सेवाएं लागू होने के बाद, 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 (जीकेई) यूज़र इंटरफ़ेस (यूआई) पर जाएं.
वर्कलोड
सेवाएं
ConfigMaps
खास जानकारी
इस चरण में, आपने GKE Autopilot में चार बैकएंड सेवाएं डिप्लॉय की हैं. आपके पास Cloud Build के चरण को चलाने और Cloud Deploy में और Cloud Console में Kubernetes पर प्रोग्रेस की जांच करने का विकल्प है.
आपने यह भी जाना कि ये सेवाएं, Workload Identity का इस्तेमाल कैसे करती हैं. इसकी मदद से, कोई ऐसा सेवा खाता बनाया जाता है जिसके पास स्पैनर डेटाबेस में डेटा पढ़ने और उसमें बदलाव करने की अनुमति होती है.
अगले चरण
अगले सेक्शन में, आपको वर्कलोड डिप्लॉय करने होंगे.
6. वर्कलोड को डिप्लॉय करें
खास जानकारी
अब जब बैकएंड सेवाएं क्लस्टर पर चल रही हैं, तो आपको वर्कलोड डिप्लॉय करने होंगे.
वर्कलोड को बाहर से ऐक्सेस किया जा सकता है. साथ ही, इस कोडलैब के लिए हर बैकएंड सेवा के लिए एक बैकएंड सेवा मौजूद है.
ये वर्कलोड 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
पर पॉइंट करें. आपको इस तरह का पेज दिखना चाहिए:
users
और spawn
को डिफ़ॉल्ट 1 पर छोड़ दिया जाएगा. host
, http://item
डालें. बेहतर विकल्पों पर क्लिक करें और मौजूदा अवधि के लिए 10s
डालें.
यहां बताया गया है कि कॉन्फ़िगरेशन कैसा दिखना चाहिए:
‘स्वैमिंग शुरू करें’ पर क्लिक करें!
POST /items
एंडपॉइंट पर जारी किए गए अनुरोधों के आंकड़े दिखने शुरू हो जाएंगे. लोड होने की प्रोसेस 10 सेकंड बाद बंद हो जाएगी.
Charts
पर क्लिक करने पर, आपको इन अनुरोधों की परफ़ॉर्मेंस के बारे में कुछ ग्राफ़ दिखेंगे.
अब आपको यह देखना होगा कि डेटा, स्पैनर डेटाबेस में डाला गया है या नहीं.
ऐसा करने के लिए, हैमबर्गर मेन्यू पर क्लिक करें और 'स्पैनर' पर जाएं. इस पेज से, sample-instance
और sample-database
पर जाएं. इसके बाद, 'Query
' पर क्लिक करें.
हम game_items
की संख्या चुनना चाहते हैं:
game_items से COUNT(*) चुनें;
सबसे नीचे, आपको नतीजा दिखेगा.
हमें बहुत ज़्यादा 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
टेस्ट कुछ ऐसा दिखना चाहिए:
‘स्वैमिंग शुरू करें’ पर क्लिक करें!
पहले की तरह ही, अलग-अलग profile
REST एंडपॉइंट के लिए आंकड़े दिखने लगेंगे. सभी चीज़ों की परफ़ॉर्मेंस देखने के लिए, चार्ट पर क्लिक करें.
खास जानकारी
इस चरण में, आपने कुछ game_items
जनरेट किए थे और फिर Cloud Console में स्पैनर क्वेरी यूज़र इंटरफ़ेस (यूआई) का इस्तेमाल करके game_items
टेबल के लिए क्वेरी की.
आपने खिलाड़ियों को अपने गेम के लिए साइन अप करने की भी अनुमति दी है. साथ ही, यह देखा कि Locut कैसे आपकी बैकएंड सेवाओं के लिए प्रोडक्शन जैसा काम कर सकता है.
अगले चरण
वर्कलोड चलाने के बाद, आपको यह देखना होगा कि GKE (जीकेई) क्लस्टर और स्पैनर इंस्टेंस कैसा काम कर रहे हैं.
8. GKE (जीकेई) और स्पैनर के इस्तेमाल की समीक्षा करना
प्रोफ़ाइल सेवा चालू होने के साथ, अब यह देखने के लिए समय है कि आपका GKE ऑटो पायलट क्लस्टर और Cloud Spanner कैसा काम कर रही है.
GKE (जीकेई) क्लस्टर की जांच करें
Kubernetes क्लस्टर पर जाएं. ध्यान दें कि आपने वर्कलोड और सेवाएं डिप्लॉय की हैं. इसलिए, अब क्लस्टर में कुल वीसीपीयू और मेमोरी के बारे में कुछ जानकारी जोड़ी गई है. यह जानकारी तब उपलब्ध नहीं थी, जब क्लस्टर पर कोई वर्कलोड नहीं था.
अब, sample-game-gke
क्लस्टर पर क्लिक करें और निगरानी करने की सुविधा वाले टैब पर स्विच करें:
default
kubernetes नेमस्पेस, सीपीयू के इस्तेमाल के लिए, kube-system
नेमस्पेस को पार कर गया होगा. ऐसा इसलिए, क्योंकि हमारा वर्कलोड और बैकएंड सेवाएं default
पर चलती हैं. अगर ऐसा नहीं है, तो पक्का करें कि profile workload
अब भी चल रहा है और कुछ मिनट इंतज़ार करें, ताकि चार्ट अपडेट हो सकें.
यह देखने के लिए कि कौनसे वर्कलोड सबसे ज़्यादा संसाधनों का इस्तेमाल कर रहे हैं, Workloads
के डैशबोर्ड पर जाएं.
हर वर्कलोड को अलग से देखने के बजाय, सीधे डैशबोर्ड के 'निगरानी करें' टैब पर जाएं. आपको दिखेगा कि profile
और profile-workload
सीपीयू बढ़ गया है.
अब Cloud Spanner की जांच करें.
Cloud Spanner इंस्टेंस की जांच करना
क्लाउड स्पैनर की परफ़ॉर्मेंस देखने के लिए, स्पैनर पर जाएं और sample-instance
इंस्टेंस और sample-game
डेटाबेस पर क्लिक करें.
यहां आपको बाएं मेन्यू में, System Insights टैब दिखेगा:
स्पैनर इंस्टेंस की परफ़ॉर्मेंस को समझने में आपकी मदद करने के लिए यहां कई चार्ट दिए गए हैं. इनमें CPU utilization
, transaction latency and locking
, और query throughput
शामिल हैं.
System Insights के अलावा, क्वेरी के वर्कलोड के बारे में ज़्यादा जानकारी पाने के लिए, निगरानी की सुविधा वाले सेक्शन में दिए गए अन्य लिंक पर जाएं:
- क्वेरी इनसाइट की मदद से, स्पैनर में मौजूद संसाधनों का इस्तेमाल करने वाली टॉपN क्वेरी की पहचान की जा सकती है.
- लेन-देन और लॉक से जुड़ी अहम जानकारी की मदद से, ज़्यादा इंतज़ार वाले लेन-देन की पहचान की जा सकती है.
- कुंजी विज़ुअलाइज़र, ऐक्सेस पैटर्न को विज़ुअलाइज़ करने में मदद करता है. साथ ही, डेटा में हॉटस्पॉट को ट्रैक करने में भी मदद कर सकता है.
खास जानकारी
इस चरण में, आपने GKE (जीकेई) Autopilot और Spanner दोनों के लिए कुछ बुनियादी परफ़ॉर्मेंस मेट्रिक को देखने का तरीका सीखा.
उदाहरण के लिए, जब आपकी प्रोफ़ाइल का वर्कलोड चल रहा हो, तो वहां सेव हो रहे डेटा के बारे में ज़्यादा जानकारी पाने के लिए, खिलाड़ियों की टेबल से क्वेरी करें.
अगले चरण
अब, स्टोरेज खाली करने का समय आ गया है!
9. साफ़ किया जा रहा है
स्टोरेज खाली करने से पहले, उन सभी कामों के बारे में जान लें जो पूरे नहीं हो पाए. खास तौर पर, matchmaking-workload
, game-workload
, और tradepost-workload
.
"खेलना" पूरा हो जाने पर आप अपने खेल के मैदान को साफ़ कर सकते हैं. अच्छी बात यह है कि यह काफ़ी आसान है.
सबसे पहले, अगर ब्राउज़र में आपका profile-workload
अब भी चल रहा है, तो उसे बंद करें:
हर उस वर्कलोड के लिए यही तरीका अपनाएं जो आपने शायद आज़माए हुए हैं.
इसके बाद, 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 एक साथ काम कैसे करें, तो क्यों न अगला कदम उठाएं और इन सेवाओं के साथ काम करने के लिए अपना खुद का ऐप्लिकेशन बनाना शुरू करें?