App Engine टास्क सूची से माइग्रेट करना, टास्क को क्लाउड टास्क में पुश करना (मॉड्यूल 8)

1. खास जानकारी

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

इस कोडलैब का मकसद, Python 2 App Engine डेवलपर को यह दिखाना है कि App Engine टास्क क्यू (पुश टास्क) से Cloud Tasks पर कैसे माइग्रेट किया जाए. Datastore को ऐक्सेस करने के लिए, App Engine NDB से Cloud NDB पर इंप्लिसिट माइग्रेशन भी होता है. इसके बारे में मुख्य रूप से मॉड्यूल 2 में बताया गया है.

हमने मॉड्यूल 7 में, पुश टास्क के इस्तेमाल के बारे में बताया है. साथ ही, मॉड्यूल 8 में, इस इस्तेमाल को Cloud Tasks पर माइग्रेट करने के बारे में बताया है. इसके बाद, मॉड्यूल 9 में Python 3 और Cloud Datastore के बारे में बताया है. पुल किए गए टास्क के लिए Task Queues का इस्तेमाल करने वाले लोग, Cloud Pub/Sub पर माइग्रेट करेंगे. उन्हें मॉड्यूल 18-19 देखना चाहिए.

आपको इनके बारे में जानकारी मिलेगी

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

सर्वे

इस ट्यूटोरियल का इस्तेमाल कैसे किया जाएगा?

सिर्फ़ इसे पढ़ें इसे पढ़ें और एक्सरसाइज़ पूरी करें

Python के साथ अपने अनुभव को आप क्या रेटिंग देंगे?

शुरुआती सामान्य एडवांस

Google Cloud की सेवाओं को इस्तेमाल करने के अपने अनुभव को आप क्या रेटिंग देंगे?

शुरुआती सामान्य एडवांस

2. बैकग्राउंड

App Engine Task Queue, पुश और पुल, दोनों तरह के टास्क के साथ काम करती है. ऐप्लिकेशन पोर्टेबिलिटी को बेहतर बनाने के लिए, Google Cloud की टीम का सुझाव है कि Task Queue जैसी लेगसी बंडल की गई सेवाओं से, Cloud की स्टैंडअलोन सेवाओं या तीसरे पक्ष की मिलती-जुलती सेवाओं पर माइग्रेट करें.

टास्क को पुल करने की सुविधा के बारे में, माइग्रेशन मॉड्यूल 18-19 में बताया गया है. वहीं, टास्क को पुश करने की सुविधा के बारे में मॉड्यूल 7-9 में बताया गया है. App Engine Task Queue के पुश टास्क से माइग्रेट करने के लिए, हमने इसका इस्तेमाल मौजूदा Python 2 App Engine के सैंपल ऐप्लिकेशन में जोड़ा है. यह ऐप्लिकेशन, नए पेज विज़िट रजिस्टर करता है और हाल ही की विज़िट दिखाता है. मॉड्यूल 7 के कोडलैब में, सबसे पुरानी विज़िट को मिटाने के लिए पुश टास्क जोड़ा गया है. ये विज़िट कभी भी दोबारा नहीं दिखेंगी. इसलिए, इन्हें Datastore में ज़्यादा स्टोरेज क्यों इस्तेमाल करना चाहिए? इस आठवें मॉड्यूल के कोडलैब में, पहले की तरह ही काम करने की सुविधा दी गई है. हालांकि, इसमें टास्क क्यू के पुश टास्क से Cloud Tasks में, क्यूइंग के बुनियादी तरीके को माइग्रेट किया गया है. साथ ही, Datastore ऐक्सेस के लिए, App Engine NDB से Cloud NDB में दूसरे मॉड्यूल के माइग्रेशन को दोहराया गया है.

इस ट्यूटोरियल में ये चरण शामिल हैं:

  1. सेटअप/प्रीवर्क
  2. कॉन्फ़िगरेशन अपडेट करना
  3. ऐप्लिकेशन कोड में बदलाव करना

3. सेटअप/प्रीवर्क

इस सेक्शन में, यह बताया गया है कि:

  1. अपना Cloud प्रोजेक्ट सेट अप करना
  2. बेसलाइन सैंपल ऐप्लिकेशन पाना
  3. बेसलाइन ऐप्लिकेशन को (फिर से) डिप्लॉय करें और उसकी पुष्टि करें
  4. Google Cloud की नई सेवाओं/एपीआई को चालू करना

इन चरणों से यह पक्का किया जाता है कि आपने काम करने वाले कोड से शुरुआत की है और आपका सैंपल ऐप्लिकेशन, क्लाउड सेवाओं पर माइग्रेट करने के लिए तैयार है.

1. प्रोजेक्ट सेट अप करना

अगर आपने मॉड्यूल 7 का कोडलैब पूरा कर लिया है, तो उसी प्रोजेक्ट और कोड का फिर से इस्तेमाल करें. इसके अलावा, एक नया प्रोजेक्ट बनाएं या किसी मौजूदा प्रोजेक्ट का फिर से इस्तेमाल करें. पक्का करें कि प्रोजेक्ट में चालू बिलिंग खाता हो और App Engine ऐप्लिकेशन चालू हो. अपना प्रोजेक्ट आईडी ढूंढें, क्योंकि इस कोडलैब के दौरान आपको इसकी ज़रूरत होगी. जब भी आपको PROJECT_ID वैरिएबल दिखे, तब इसका इस्तेमाल करें.

2. बेसलाइन सैंपल ऐप्लिकेशन पाना

इसके लिए, Module 7 App Engine ऐप्लिकेशन का काम करना ज़रूरी है: Module 7 का कोडलैब पूरा करें (सुझाया गया) या repo से Module 7 ऐप्लिकेशन कॉपी करें. चाहे आपने अपने कोड का इस्तेमाल किया हो या हमारे कोड का, हम मॉड्यूल 7 के कोड से शुरुआत करेंगे ("START"). इस कोडलैब में, माइग्रेट करने का तरीका बताया गया है. इसमें आखिर में ऐसा कोड दिया गया है जो मॉड्यूल 8 के रेपो फ़ोल्डर ("FINISH") में मौजूद कोड जैसा है.

Module 7 के किसी भी ऐप्लिकेशन का इस्तेमाल करने पर, फ़ोल्डर ऐसा दिखना चाहिए. इसमें lib फ़ोल्डर भी हो सकता है:

$ ls
README.md               appengine_config.py     requirements.txt
app.yaml                main.py                 templates

3. बेसलाइन ऐप्लिकेशन को (फिर से) डिप्लॉय करें और उसकी पुष्टि करें

Module 7 ऐप्लिकेशन को डिप्लॉय करने के लिए, यह तरीका अपनाएं:

  1. अगर lib फ़ोल्डर मौजूद है, तो उसे मिटाएं. इसके बाद, pip install -t lib -r requirements.txt चलाकर lib को फिर से भरें. अगर आपने डेवलपमेंट मशीन पर Python 2 और 3, दोनों इंस्टॉल किए हैं, तो आपको pip2 का इस्तेमाल करना पड़ सकता है.
  2. पक्का करें कि आपने gcloud कमांड-लाइन टूल को इंस्टॉल और शुरू कर लिया हो. साथ ही, इसके इस्तेमाल की समीक्षा कर ली हो.
  3. (ज़रूरी नहीं) अगर आपको हर gcloud कमांड के साथ PROJECT_ID नहीं डालना है, तो gcloud config set project PROJECT_ID का इस्तेमाल करके अपना Cloud प्रोजेक्ट सेट करें.
  4. gcloud app deploy की मदद से, सैंपल ऐप्लिकेशन को डिप्लॉय करना
  5. पुष्टि करें कि ऐप्लिकेशन बिना किसी समस्या के उम्मीद के मुताबिक काम कर रहा है. अगर आपने मॉड्यूल 7 का कोडलैब पूरा कर लिया है, तो ऐप्लिकेशन में सबसे ज़्यादा बार आने वाले लोगों के साथ-साथ हाल ही की विज़िट भी दिखेंगी. इसकी जानकारी यहां दी गई है. सबसे नीचे, पुराने टास्क की जानकारी दी गई है. इन्हें मिटा दिया जाएगा.

4aa8a2cb5f527079.png

4. Google Cloud की नई सेवाओं/एपीआई को चालू करना

पुराने ऐप्लिकेशन में App Engine की बंडल की गई सेवाओं का इस्तेमाल किया जाता था. इनके लिए, अतिरिक्त सेटअप की ज़रूरत नहीं होती. हालांकि, स्टैंडअलोन Cloud सेवाओं के लिए ऐसा करना ज़रूरी होता है. अपडेट किए गए ऐप्लिकेशन में Cloud Tasks और Cloud Datastore, दोनों का इस्तेमाल किया जाएगा. इसके लिए, Cloud NDB क्लाइंट लाइब्रेरी का इस्तेमाल किया जाएगा. Cloud के कई प्रॉडक्ट के लिए, "हमेशा के लिए बिना शुल्क के उपलब्ध" टियर के कोटे होते हैं. इनमें App Engine, Cloud Datastore, और Cloud Tasks शामिल हैं. इन सीमाओं के अंदर रहने पर, इस ट्यूटोरियल को पूरा करने के लिए आपसे कोई शुल्क नहीं लिया जाएगा. Cloud API को Cloud Console या कमांड-लाइन से चालू किया जा सकता है. यह आपकी पसंद पर निर्भर करता है.

Cloud Console से

Cloud Console में, सही प्रोजेक्ट के लिए एपीआई मैनेजर के लाइब्रेरी पेज पर जाएं. इसके बाद, पेज के बीच में मौजूद खोज बार का इस्तेमाल करके, Cloud Datastore और Cloud Tasks API खोजें:

c7a740304e9d35b.png

हर एपीआई के लिए, चालू करें बटन पर क्लिक करें. आपसे बिलिंग की जानकारी मांगी जा सकती है. यह Cloud Pub/Sub API लाइब्रेरी पेज का उदाहरण है. इस कोडलैब के लिए, Pub/Sub API को चालू न करें. सिर्फ़ Cloud Tasks और Datastore को चालू करें:

1b6c0a2a73124f6b.jpeg

कमांड-लाइन से

कंसोल से एपीआई चालू करने पर, विज़ुअल तौर पर जानकारी मिलती है. हालांकि, कुछ लोग कमांड-लाइन का इस्तेमाल करना पसंद करते हैं. दोनों एपीआई को एक साथ चालू करने के लिए, gcloud services enable cloudtasks.googleapis.com datastore.googleapis.com कमांड जारी करें:

$ gcloud services enable cloudtasks.googleapis.com datastore.googleapis.com
Operation "operations/acat.p2-aaa-bbb-ccc-ddd-eee-ffffff" finished successfully.

आपसे बिलिंग की जानकारी मांगी जा सकती है. अगर आपको अन्य Cloud API चालू करने हैं और उनके "यूआरआई" के बारे में जानना है, तो उन्हें हर एपीआई के लाइब्रेरी पेज पर सबसे नीचे देखा जा सकता है. उदाहरण के लिए, Pub/Sub पेज पर सबसे नीचे मौजूद, pubsub.googleapis.com को "सेवा का नाम" के तौर पर देखें.

इन चरणों को पूरा करने के बाद, आपका प्रोजेक्ट एपीआई को ऐक्सेस कर पाएगा. अब उन एपीआई का इस्तेमाल करने के लिए, ऐप्लिकेशन को अपडेट करें.

4. कॉन्फ़िगरेशन अपडेट करना

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

requirements.txt

मॉड्यूल 8 में, मॉड्यूल 1 में इस्तेमाल किए गए App Engine NDB और Task Queue को Cloud NDB और Cloud Tasks से बदल दिया गया है. google-cloud-ndb और google-cloud-tasks, दोनों को requirements.txt में जोड़ें, ताकि मॉड्यूल 7 से flask को जोड़ा जा सके:

flask
google-cloud-ndb
google-cloud-tasks

इस requirements.txt फ़ाइल में कोई वर्शन नंबर नहीं है. इसका मतलब है कि सबसे नए वर्शन चुने गए हैं. अगर कोई समस्या आती है, तो ऐप्लिकेशन के लिए काम करने वाले वर्शन को लॉक-इन करने के लिए, वर्शन नंबर डालें.

app.yaml

Cloud क्लाइंट लाइब्रेरी का इस्तेमाल करते समय, Python 2 App Engine रनटाइम के लिए तीसरे पक्ष के कुछ खास पैकेज की ज़रूरत होती है. जैसे, grpcio और setuptools. Python 2 का इस्तेमाल करने वाले लोगों को, app.yaml में इन जैसी बिल्ट-इन लाइब्रेरी के साथ-साथ, उपलब्ध वर्शन या "नवीनतम" की जानकारी देनी होगी. अगर आपके पास अब तक कोई libraries सेक्शन नहीं है, तो एक सेक्शन बनाएं और उसमें दोनों लाइब्रेरी इस तरह जोड़ें:

libraries:
- name: grpcio
  version: latest
- name: setuptools
  version: latest

आपके ऐप्लिकेशन को माइग्रेट करते समय, हो सकता है कि उसमें पहले से ही libraries सेक्शन हो. अगर ऐसा होता है और grpcio और setuptools दोनों मौजूद नहीं हैं, तो उन्हें अपने मौजूदा libraries सेक्शन में जोड़ें. अपडेट किया गया app.yaml अब ऐसा दिखना चाहिए:

runtime: python27
threadsafe: yes
api_version: 1

handlers:
- url: /.*
  script: main.app

libraries:
- name: grpcio
  version: latest
- name: setuptools
  version: latest

appengine_config.py

appengine_config.py में google.appengine.ext.vendor.add() कॉल, lib में कॉपी की गई (कभी-कभी इन्हें "वेंडरिंग" या "सेल्फ़-बंडलिंग" भी कहा जाता है) तीसरे पक्ष की लाइब्रेरी को आपके ऐप्लिकेशन से कनेक्ट करता है. ऊपर app.yaml में, हमने तीसरे पक्ष की बिल्ट-इन लाइब्रेरी जोड़ी हैं. इन्हें setuptools.pkg_resources.working_set.add_entry() की ज़रूरत होती है, ताकि आपके ऐप्लिकेशन को lib में उन बिल्ट-इन पैकेज से जोड़ा जा सके. यहां मॉड्यूल 1 appengine_config.py की ओरिजनल इमेज दी गई है. इसके बाद, मॉड्यूल 8 में किए गए अपडेट की इमेज दी गई है:

BEFORE:

from google.appengine.ext import vendor

# Set PATH to your libraries folder.
PATH = 'lib'
# Add libraries installed in the PATH folder.
vendor.add(PATH)

AFTER:

import pkg_resources
from google.appengine.ext import vendor

# Set PATH to your libraries folder.
PATH = 'lib'
# Add libraries installed in the PATH folder.
vendor.add(PATH)
# Add libraries to pkg_resources working set to find the distribution.
pkg_resources.working_set.add_entry(PATH)

इसी तरह का ब्यौरा, App Engine माइग्रेशन के दस्तावेज़ में भी देखा जा सकता है.

5. ऐप्लिकेशन कोड में बदलाव करना

इस सेक्शन में, मुख्य ऐप्लिकेशन फ़ाइल main.py से जुड़े अपडेट दिए गए हैं. इसमें App Engine Task Queue की पुश कतारों की जगह Cloud Tasks का इस्तेमाल किया गया है. वेब टेंप्लेट में कोई बदलाव नहीं किया गया है. templates/index.html—दोनों ऐप्लिकेशन एक जैसे काम करने चाहिए और एक जैसा डेटा दिखाना चाहिए. मुख्य ऐप्लिकेशन में किए गए बदलावों को इन चार "करने के लिए" टास्क में बांटा गया है:

  1. इंपोर्ट और इनिशियलाइज़ेशन को अपडेट करना
  2. डेटा मॉडल की सुविधा अपडेट करना (Cloud NDB)
  3. Cloud Tasks और Cloud NDB पर माइग्रेट करना
  4. टास्क हैंडलर को अपडेट (पुश) करना

1. इंपोर्ट और इनिशियलाइज़ेशन को अपडेट करना

  1. App Engine NDB (google.appengine.ext.ndb) और Task Queue (google.appengine.api.taskqueue) को क्रमशः Cloud NDB (google.cloud.ndb) और Cloud Tasks (google.cloud.tasks) से बदलें.
  2. Cloud क्लाइंट लाइब्रेरी को शुरू करने और "एपीआई क्लाइंट" बनाने की ज़रूरत होती है. इन्हें क्रमशः ds_client और ts_client को असाइन करें.
  3. टास्क क्यू के दस्तावेज़ में बताया गया है कि "App Engine, default नाम की डिफ़ॉल्ट पुश क्यू उपलब्ध कराता है. यह डिफ़ॉल्ट सेटिंग के साथ कॉन्फ़िगर की जाती है और इस्तेमाल के लिए तैयार होती है." Cloud Tasks, default कतार की सुविधा नहीं देता है. ऐसा इसलिए, क्योंकि यह App Engine से अलग एक स्टैंडअलोन Cloud प्रॉडक्ट है. इसलिए, default नाम की Cloud Tasks कतार बनाने के लिए, नए कोड की ज़रूरत होती है.
  4. App Engine की टास्क क्यू सेवा के लिए, आपको क्षेत्र की जानकारी देने की ज़रूरत नहीं होती. ऐसा इसलिए, क्योंकि यह उस क्षेत्र का इस्तेमाल करती है जिसमें आपका ऐप्लिकेशन चलता है. हालांकि, Cloud Tasks अब एक स्वतंत्र प्रॉडक्ट है. इसलिए, इसके लिए किसी क्षेत्र की ज़रूरत होती है. साथ ही, यह क्षेत्र उस क्षेत्र से मेल खाना चाहिए जिसमें आपका ऐप्लिकेशन चलता है. कतार के यूनीक आइडेंटिफ़ायर के तौर पर "पूरी तरह से क्वालिफ़ाइड पाथनेम" बनाने के लिए, क्षेत्र का नाम और Cloud प्रोजेक्ट आईडी ज़रूरी है.

ऊपर तीसरे और चौथे बुलेट में बताए गए अपडेट, ज़्यादातर अतिरिक्त कॉन्स्टेंट और ज़रूरी इनिशियलाइज़ेशन के लिए ज़रूरी हैं. नीचे "पहले" और "बाद में" देखें और main.py में सबसे ऊपर ये बदलाव करें.

BEFORE:

from datetime import datetime
import logging
import time
from flask import Flask, render_template, request
from google.appengine.api import taskqueue
from google.appengine.ext import ndb

app = Flask(__name__)

AFTER:

from datetime import datetime
import json
import logging
import time
from flask import Flask, render_template, request
from google.cloud import ndb, tasks

app = Flask(__name__)
ds_client = ndb.Client()
ts_client = tasks.CloudTasksClient()

_, PROJECT_ID = google.auth.default()
REGION_ID = 'REGION_ID'    # replace w/your own
QUEUE_NAME = 'default'     # replace w/your own
QUEUE_PATH = ts_client.queue_path(PROJECT_ID, REGION_ID, QUEUE_NAME)

2. डेटा मॉडल की सुविधा अपडेट करना (Cloud NDB)

App Engine NDB और Cloud NDB, दोनों लगभग एक जैसे काम करते हैं. डेटा मॉडल या store_visit() फ़ंक्शन में कोई बड़ा बदलाव नहीं किया गया है. इन दोनों कोड में सिर्फ़ यह अंतर है कि store_visit() में Visit इकाई बनाने का काम, अब Python के with ब्लॉक में शामिल कर दिया गया है. Cloud NDB के लिए ज़रूरी है कि Datastore के सभी ऐक्सेस को इसके कॉन्टेक्स्ट मैनेजर में कंट्रोल किया जाए. इसलिए, with स्टेटमेंट का इस्तेमाल किया जाता है. नीचे दिए गए कोड स्निपेट से पता चलता है कि Cloud NDB पर माइग्रेट करते समय, यह मामूली अंतर कैसे दिखता है. इस बदलाव को लागू करें.

BEFORE:

class Visit(ndb.Model):
    'Visit entity registers visitor IP address & timestamp'
    visitor   = ndb.StringProperty()
    timestamp = ndb.DateTimeProperty(auto_now_add=True)

def store_visit(remote_addr, user_agent):
    'create new Visit entity in Datastore'
    Visit(visitor='{}: {}'.format(remote_addr, user_agent)).put()

AFTER:

class Visit(ndb.Model):
    'Visit entity registers visitor IP address & timestamp'
    visitor   = ndb.StringProperty()
    timestamp = ndb.DateTimeProperty(auto_now_add=True)

def store_visit(remote_addr, user_agent):
    'create new Visit entity in Datastore'
    with ds_client.context():
        Visit(visitor='{}: {}'.format(remote_addr, user_agent)).put()

3. Cloud Tasks और Cloud NDB पर माइग्रेट करना

इस माइग्रेशन में सबसे अहम बदलाव, क्यूइंग इन्फ़्रास्ट्रक्चर को स्विच करना है. यह fetch_visits() फ़ंक्शन में होता है. इसमें पुरानी विज़िट मिटाने का (पुश) टास्क बनाया जाता है और उसे लागू करने के लिए लाइन में लगाया जाता है. हालांकि, मॉड्यूल 7 की ओरिजनल फ़ंक्शनैलिटी में कोई बदलाव नहीं किया गया है:

  1. हाल की विज़िट के लिए क्वेरी.
  2. उन विज़िट को तुरंत वापस लाने के बजाय, आखिरी Visit का टाइमस्टैंप सेव करें. यह सबसे पुराना टाइमस्टैंप है. इससे पुरानी सभी विज़िट को मिटाना सुरक्षित है.
  3. स्टैंडर्ड Python यूटिलिटी का इस्तेमाल करके, टाइमस्टैंप को फ़्लोट और स्ट्रिंग के तौर पर अलग करें. साथ ही, दोनों का इस्तेमाल अलग-अलग कामों के लिए करें. जैसे, उपयोगकर्ता को दिखाना, लॉग में जोड़ना, हैंडलर को पास करना वगैरह.
  4. इस टाइमस्टैंप को पेलोड के तौर पर इस्तेमाल करके, एक पुश टास्क बनाएं. साथ ही, /trim को यूआरएल के तौर पर इस्तेमाल करें.
  5. टास्क हैंडलर को आखिर में, उस यूआरएल पर एचटीटीपी POST के ज़रिए कॉल किया जाता है.

इस वर्कफ़्लो को "before" कोड स्निपेट में दिखाया गया है:

BEFORE:

def fetch_visits(limit):
    'get most recent visits & add task to delete older visits'
    data = Visit.query().order(-Visit.timestamp).fetch(limit)
    oldest = time.mktime(data[-1].timestamp.timetuple())
    oldest_str = time.ctime(oldest)
    logging.info('Delete entities older than %s' % oldest_str)
    taskqueue.add(url='/trim', params={'oldest': oldest})
    return data, oldest_str

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

  1. Visit क्वेरी को Python with ब्लॉक में रैप करें (Module 2 को Cloud NDB में माइग्रेट करने की प्रोसेस को दोहराना)
  2. Cloud Tasks का मेटाडेटा बनाएं. इसमें टाइमस्टैंप पेलोड और यूआरएल जैसे ज़रूरी एट्रिब्यूट शामिल करें. साथ ही, MIME टाइप जोड़ें और पेलोड को JSON-कोड में बदलें.
  3. मेटाडेटा और क्यू के पूरे पाथनेम के साथ टास्क बनाने के लिए, Cloud Tasks API क्लाइंट का इस्तेमाल करें.

fetch_visits() में हुए इन बदलावों के बारे में यहां बताया गया है:

AFTER:

def fetch_visits(limit):
    'get most recent visits & add task to delete older visits'
    with ds_client.context():
        data = Visit.query().order(-Visit.timestamp).fetch(limit)
    oldest = time.mktime(data[-1].timestamp.timetuple())
    oldest_str = time.ctime(oldest)
    logging.info('Delete entities older than %s' % oldest_str)
    task = {
        'app_engine_http_request': {
            'relative_uri': '/trim',
            'body': json.dumps({'oldest': oldest}).encode(),
            'headers': {
                'Content-Type': 'application/json',
            },
        }
    }
    ts_client.create_task(parent=QUEUE_PATH, task=task)
    return data, oldest_str

4. टास्क हैंडलर को अपडेट (पुश) करना

पुश टास्क हैंडलर फ़ंक्शन को बड़े अपडेट की ज़रूरत नहीं होती. इसे सिर्फ़ लागू करने की ज़रूरत होती है. यह टास्क क्यू या Cloud Tasks पर लागू होता है. "कोड ही कोड है," ऐसा वे कहते हैं. हालांकि, इसमें कुछ मामूली बदलाव किए गए हैं:

  1. टाइमस्टैंप पेलोड को Task Queue में हूबहू पास किया गया था. हालांकि, Cloud Tasks के लिए इसे JSON-कोड में बदला गया था. इसलिए, इसे पहुंचने पर JSON-पार्स किया जाना चाहिए.
  2. टास्क क्यू के साथ POST को किए गए एचटीटीपी POST कॉल में, application/x-www-form-urlencoded का इंप्लिसिट MIMEtype था. हालांकि, Cloud Tasks के साथ इसे साफ़ तौर पर application/json के तौर पर तय किया गया है. इसलिए, पेलोड निकालने का तरीका थोड़ा अलग है./trim
  3. Cloud NDB API क्लाइंट कॉन्टेक्स्ट मैनेजर का इस्तेमाल करें (मॉड्यूल 2 को Cloud NDB पर माइग्रेट करने के लिए).

टास्क हैंडलर, trim() में ये बदलाव करने से पहले और बाद के कोड स्निपेट यहां दिए गए हैं:

BEFORE:

@app.route('/trim', methods=['POST'])
def trim():
    '(push) task queue handler to delete oldest visits'
    oldest = request.form.get('oldest', type=float)
    keys = Visit.query(
            Visit.timestamp < datetime.fromtimestamp(oldest)
    ).fetch(keys_only=True)
    nkeys = len(keys)
    if nkeys:
        logging.info('Deleting %d entities: %s' % (
                nkeys, ', '.join(str(k.id()) for k in keys)))
        ndb.delete_multi(keys)
    else:
        logging.info('No entities older than: %s' % time.ctime(oldest))
    return ''   # need to return SOME string w/200

AFTER:

@app.route('/trim', methods=['POST'])
def trim():
    '(push) task queue handler to delete oldest visits'
    oldest = float(request.get_json().get('oldest'))
    with ds_client.context():
        keys = Visit.query(
                Visit.timestamp < datetime.fromtimestamp(oldest)
        ).fetch(keys_only=True)
        nkeys = len(keys)
        if nkeys:
            logging.info('Deleting %d entities: %s' % (
                    nkeys, ', '.join(str(k.id()) for k in keys)))
            ndb.delete_multi(keys)
        else:
            logging.info(
                    'No entities older than: %s' % time.ctime(oldest))
    return ''   # need to return SOME string w/200

मुख्य ऐप्लिकेशन हैंडलर root() और वेब टेंप्लेट templates/index.html में कोई अपडेट नहीं है.

6. खास जानकारी/सफ़ाई

इस सेक्शन में, ऐप्लिकेशन को डिप्लॉय करके इस कोडलैब को पूरा किया गया है. साथ ही, यह पुष्टि की गई है कि ऐप्लिकेशन ठीक से काम कर रहा है और आउटपुट में कोई गड़बड़ी नहीं है. ऐप्लिकेशन की पुष्टि होने के बाद, क्लीन-अप करें और अगले चरणों पर विचार करें.

ऐप्लिकेशन डिप्लॉय करना और उसकी पुष्टि करना

gcloud app deploy की मदद से अपना ऐप्लिकेशन डिप्लॉय करें. आउटपुट, मॉड्यूल 7 के ऐप्लिकेशन जैसा ही होना चाहिए. हालांकि, आपको यह पता होना चाहिए कि आपने पुश क्यू के किसी दूसरे प्रॉडक्ट का इस्तेमाल किया है. इससे आपका ऐप्लिकेशन पहले से ज़्यादा पोर्टेबल हो गया है!

4aa8a2cb5f527079.png

व्यवस्थित करें

सामान्य

अगर आपको अभी और काम नहीं करना है, तो हमारा सुझाव है कि आप अपने App Engine ऐप्लिकेशन को बंद कर दें, ताकि आपसे शुल्क न लिया जाए. हालांकि, अगर आपको कुछ और टेस्ट या एक्सपेरिमेंट करने हैं, तो App Engine प्लैटफ़ॉर्म पर मुफ़्त कोटा उपलब्ध है. इसलिए, जब तक आप इस्तेमाल की उस सीमा से ज़्यादा नहीं होते हैं, तब तक आपसे कोई शुल्क नहीं लिया जाएगा. यह शुल्क कंप्यूट के लिए है. हालांकि, App Engine की सेवाओं के लिए भी शुल्क लिया जा सकता है. इसलिए, ज़्यादा जानकारी के लिए कीमत वाला पेज देखें. अगर इस माइग्रेशन में अन्य क्लाउड सेवाएं शामिल हैं, तो उनके लिए अलग से बिल भेजा जाता है. अगर लागू हो, तो दोनों ही मामलों में, नीचे दिया गया "इस कोडलैब के लिए खास जानकारी" सेक्शन देखें.

पूरी जानकारी के लिए बता दें कि App Engine जैसे Google Cloud के सर्वरलेस कंप्यूट प्लैटफ़ॉर्म पर डिप्लॉय करने से, बिल्ड और स्टोरेज के लिए मामूली शुल्क लगता है. Cloud Build का अपना मुफ़्त कोटा होता है. साथ ही, Cloud Storage का भी अपना मुफ़्त कोटा होता है. उस इमेज को सेव करने के लिए, स्टोरेज कोटा का कुछ हिस्सा इस्तेमाल किया जाता है. हालांकि, ऐसा हो सकता है कि आपके देश/इलाके में बिना किसी शुल्क के स्टोरेज इस्तेमाल करने की सुविधा उपलब्ध न हो. इसलिए, स्टोरेज के इस्तेमाल पर नज़र रखें, ताकि संभावित लागत को कम किया जा सके. Cloud Storage के कुछ "फ़ोल्डर" की समीक्षा करनी चाहिए. इनमें ये शामिल हैं:

  • console.cloud.google.com/storage/browser/LOC.artifacts.PROJECT_ID.appspot.com/containers/images
  • console.cloud.google.com/storage/browser/staging.PROJECT_ID.appspot.com
  • ऊपर दिए गए स्टोरेज लिंक, आपके PROJECT_ID और *LOC*ation पर निर्भर करते हैं. उदाहरण के लिए, अगर आपका ऐप्लिकेशन अमेरिका में होस्ट किया गया है, तो "us" दिखेगा.

दूसरी ओर, अगर आपको इस ऐप्लिकेशन या माइग्रेशन से जुड़े अन्य कोडलैब का इस्तेमाल नहीं करना है और आपको सब कुछ पूरी तरह से मिटाना है, तो अपना प्रोजेक्ट बंद करें.

इस कोडलैब के लिए खास तौर पर

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

अगले चरण

App Engine Task Queue के पुश टास्क से Cloud Tasks पर माइग्रेट करने की प्रोसेस यहां खत्म होती है. अगर आपको इस ऐप्लिकेशन को Python 3 में पोर्ट करना है और Cloud NDB से Cloud Datastore में माइग्रेट करना है, तो Module 9 देखें.

Cloud NDB, खास तौर पर Python 2 App Engine डेवलपर के लिए बनाया गया है. यह उपयोगकर्ताओं को लगभग एक जैसा अनुभव देता है. हालांकि, Cloud Datastore की अपनी नेटिव क्लाइंट लाइब्रेरी है. यह App Engine का इस्तेमाल न करने वाले उपयोगकर्ताओं या नए (Python 3) App Engine उपयोगकर्ताओं के लिए बनाई गई है. हालांकि, Cloud NDB, Python 2 और 3 के लिए उपलब्ध है. इसलिए, Cloud Datastore पर माइग्रेट करने की कोई ज़रूरत नहीं है.

Cloud NDB और Cloud Datastore, दोनों ही Datastore को ऐक्सेस करते हैं. हालाँकि, दोनों के ऐक्सेस करने का तरीका अलग-अलग होता है. इसलिए, Cloud Datastore पर माइग्रेट करने का एक ही कारण हो सकता है. वह यह है कि अगर आपके पास पहले से ही Cloud Datastore का इस्तेमाल करने वाले अन्य ऐप्लिकेशन हैं, खास तौर पर गैर-App Engine ऐप्लिकेशन, और आपको एक ही Datastore क्लाइंट लाइब्रेरी को स्टैंडर्ड बनाना है. Cloud NDB से Cloud Datastore पर माइग्रेट करने का यह वैकल्पिक तरीका, मॉड्यूल 3 में भी शामिल है. इसमें Task Queue या Cloud Tasks का इस्तेमाल नहीं किया जाता.

तीसरे, आठवें, और नौवें मॉड्यूल के अलावा, App Engine की लेगसी बंडल्ड सेवाओं से दूर जाने पर फ़ोकस करने वाले अन्य माइग्रेशन मॉड्यूल में ये शामिल हैं:

App Engine अब Google Cloud में सर्वरलेस प्लैटफ़ॉर्म नहीं है. अगर आपके पास कोई छोटा App Engine ऐप्लिकेशन है या ऐसा ऐप्लिकेशन है जिसमें सीमित सुविधाएं हैं और आपको उसे स्टैंडअलोन माइक्रोसेवा में बदलना है या आपको किसी मोनोलिथिक ऐप्लिकेशन को फिर से इस्तेमाल किए जा सकने वाले कई कॉम्पोनेंट में बांटना है, तो Cloud Functions पर माइग्रेट करने के लिए ये अच्छी वजहें हैं. अगर कंटेनर बनाने की प्रोसेस, ऐप्लिकेशन डेवलपमेंट वर्कफ़्लो का हिस्सा बन गई है, तो Cloud Run पर माइग्रेट करें. खास तौर पर, अगर इसमें सीआई/सीडी (लगातार इंटिग्रेशन/लगातार डिलीवरी या डिप्लॉयमेंट) पाइपलाइन शामिल है. इन स्थितियों के बारे में यहां दिए गए मॉड्यूल में बताया गया है:

  • App Engine से Cloud Functions पर माइग्रेट करना: मॉड्यूल 11 देखें
  • App Engine से Cloud Run पर माइग्रेट करना: Docker की मदद से अपने ऐप्लिकेशन को कंटेनर में बदलने के लिए, मॉड्यूल 4 देखें. इसके अलावा, कंटेनर, Docker की जानकारी या Dockerfile के बिना ऐसा करने के लिए, मॉड्यूल 5 देखें

किसी दूसरे सर्वरलेस प्लैटफ़ॉर्म पर स्विच करना ज़रूरी नहीं है. हमारा सुझाव है कि कोई भी बदलाव करने से पहले, अपने ऐप्लिकेशन और इस्तेमाल के उदाहरणों के लिए सबसे सही विकल्पों पर विचार करें.

अगले माइग्रेशन मॉड्यूल के तौर पर किसी भी मॉड्यूल को चुना जा सकता है. हालांकि, Serverless Migration Station का पूरा कॉन्टेंट (कोड लैब, वीडियो, सोर्स कोड [अगर उपलब्ध हो]) इसके ओपन सोर्स रेपो में ऐक्सेस किया जा सकता है. रेपो के README में यह भी बताया गया है कि किन माइग्रेशन पर विचार करना चाहिए. साथ ही, माइग्रेशन मॉड्यूल के "क्रम" के बारे में भी बताया गया है.

7. अन्य संसाधन

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

कोडलैब से जुड़ी समस्याएं/सुझाव/राय

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

माइग्रेशन के लिए उपलब्ध संसाधन

मॉड्यूल 7 (START) और मॉड्यूल 8 (FINISH) के लिए, रेपो फ़ोल्डर के लिंक यहां दी गई टेबल में दिए गए हैं.

कोडलैब

Python 2

Python 3

मॉड्यूल 7

code

कोड (इस ट्यूटोरियल में शामिल नहीं है)

मॉड्यूल 8 (यह कोडलैब)

code

(लागू नहीं)

ऑनलाइन संसाधन

यहां कुछ ऑनलाइन संसाधन दिए गए हैं, जो इस ट्यूटोरियल के लिए काम के हो सकते हैं:

App Engine Task Queue और Cloud Tasks

App Engine NDB और Cloud NDB (Datastore)

App Engine प्लैटफ़ॉर्म

क्लाउड से जुड़ी अन्य जानकारी

वीडियो

लाइसेंस

इस काम के लिए, Creative Commons एट्रिब्यूशन 2.0 जेनेरिक लाइसेंस के तहत लाइसेंस मिला है.