मॉड्यूल 5: Cloud Buildpack की मदद से, Google App Engine से क्लाउड रन पर माइग्रेट करना

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

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

इस ट्यूटोरियल में, App Engine ऐप्लिकेशन को कंटेनर में बदलने का तरीका बताया गया है. इससे उन्हें Docker के विकल्प के तौर पर, Cloud Buildpacks का इस्तेमाल करके, Cloud Run की पूरी तरह से मैनेज की जाने वाली सेवा पर डिप्लॉय किया जा सकता है. Cloud Buildpacks, आपके ऐप्लिकेशन को कंटेनर में बदल देते हैं. इसके लिए, आपको Dockerfile फ़ाइलों को मैनेज करने या Docker के बारे में जानने की ज़रूरत नहीं होती.

यह कोडलैब, Python 2 App Engine डेवलपर के लिए है. इन डेवलपर ने अपने ऐप्लिकेशन को ओरिजनल बिल्ट-इन सेवाओं से हटाकर, Python 3 पर पोर्ट कर दिया है. अब वे उन्हें कंटेनर में चलाना चाहते हैं. यह कोडलैब, Python 3 ऐप्लिकेशन के पूरे किए गए मॉड्यूल 2 या मॉड्यूल 3 से शुरू होता है.

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

  • Cloud Buildpacks का इस्तेमाल करके, अपने ऐप्लिकेशन को कंटेनर में बदलना
  • Cloud Run पर कंटेनर इमेज डिप्लॉय करना

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

सर्वे

इस कोडलैब का इस्तेमाल कैसे किया जाएगा?

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

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

App Engine और Cloud Functions जैसे PaaS सिस्टम, आपकी टीम और ऐप्लिकेशन के लिए कई सुविधाएं उपलब्ध कराते हैं. उदाहरण के लिए, ये सर्वरलेस प्लैटफ़ॉर्म, SysAdmin/Devops को समाधान बनाने पर ध्यान देने में मदद करते हैं. आपके ऐप्लिकेशन को ज़रूरत के हिसाब से अपने-आप बढ़ाया जा सकता है. साथ ही, इस्तेमाल के हिसाब से बिलिंग की सुविधा के साथ, इसे शून्य तक कम किया जा सकता है. इससे लागत को कंट्रोल करने में मदद मिलती है. ये सामान्य डेवलपमेंट भाषाओं का इस्तेमाल करते हैं.

हालांकि, कंटेनर की सुविधा भी काफ़ी अच्छी है. इसमें किसी भी भाषा, लाइब्रेरी या बाइनरी को चुनने की सुविधा मिलती है. Google Cloud Run, उपयोगकर्ताओं को सर्वरलेस की सुविधा के साथ-साथ कंटेनर की सुविधा भी देता है.

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

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

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

इस माइग्रेशन में ये चरण शामिल हैं:

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

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

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

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

अगर आपने मॉड्यूल 2 या मॉड्यूल 3 के कोडलैब पूरे कर लिए हैं, तो हमारा सुझाव है कि आप उसी प्रोजेक्ट और कोड का दोबारा इस्तेमाल करें. इसके अलावा, एक नया प्रोजेक्ट बनाया जा सकता है या किसी मौजूदा प्रोजेक्ट का फिर से इस्तेमाल किया जा सकता है. पक्का करें कि प्रोजेक्ट में, बिलिंग के लिए ऐक्टिव खाता हो और App Engine (ऐप्लिकेशन) चालू हो.

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

इस कोडलैब के लिए, यह ज़रूरी है कि आपके पास मॉड्यूल 2 या 3 का सैंपल ऐप्लिकेशन हो. अगर आपके पास ऐसा ऐप्लिकेशन नहीं है, तो हम आपको सलाह देते हैं कि यहां आगे बढ़ने से पहले, ऊपर दिए गए दोनों ट्यूटोरियल में से कोई एक पूरा करें. अगर आपको इनके कॉन्टेंट के बारे में पहले से पता है, तो यहां दिए गए कोड फ़ोल्डर में से कोई एक फ़ोल्डर चुनें और उसका इस्तेमाल शुरू करें.

चाहे आपने अपना खाता इस्तेमाल किया हो या हमारा, यह ट्यूटोरियल यहीं से शुरू होता है. इस कोडलैब में, माइग्रेट करने का तरीका बताया गया है. इसे पूरा करने के बाद, आपका कोड मॉड्यूल 5 के FINISH repo फ़ोल्डर में मौजूद कोड से मेल खाना चाहिए.

START फ़ाइलों (आपकी या हमारी) की डायरेक्ट्री ऐसी दिखनी चाहिए:

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

3. बेसलाइन ऐप्लिकेशन को (फिर से) डिप्लॉय करना

अब आपको ये काम करने हैं:

  1. gcloud कमांड-लाइन टूल के बारे में फिर से जानें
  2. gcloud app deploy की मदद से, सैंपल ऐप्लिकेशन को फिर से डिप्लॉय करना
  3. पुष्टि करें कि ऐप्लिकेशन, App Engine पर बिना किसी समस्या के काम करता है

इन चरणों को पूरा करने के बाद, इसे कंटेनर में रखा जा सकता है.

4. ऐप्लिकेशन को कंटेनर में बदलना

Docker, आज इंडस्ट्री में कंटेनर बनाने का स्टैंडर्ड प्लैटफ़ॉर्म है. जैसा कि हमने पहले बताया था, इसका इस्तेमाल करने में एक चुनौती यह है कि एक असरदार Dockerfile तैयार करने में काफ़ी मेहनत लगती है. यह कॉन्फ़िगरेशन फ़ाइल यह तय करती है कि आपकी कंटेनर इमेज कैसे बनाई जाती हैं. दूसरी ओर, Buildpacks का इस्तेमाल करना आसान होता है. ऐसा इसलिए, क्योंकि यह आपके ऐप्लिकेशन की डिपेंडेंसी का पता लगाने के लिए इंट्रॉस्पेक्शन का इस्तेमाल करता है. इससे Buildpacks कंटेनर, आपके ऐप्लिकेशन के लिए ज़्यादा से ज़्यादा फ़ायदेमंद बन जाता है.

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

माइग्रेशन के चरणों में, App Engine की कॉन्फ़िगरेशन फ़ाइलों को बदलना और यह तय करना शामिल है कि आपका ऐप्लिकेशन कैसे शुरू होना चाहिए. यहां दी गई टेबल में, हर प्लैटफ़ॉर्म टाइप के लिए कॉन्फ़िगरेशन फ़ाइलों की खास जानकारी दी गई है. App Engine कॉलम की तुलना Buildpacks कॉलम (और चाहें, तो Docker) से करें:

ब्यौरा

App Engine

Docker

Buildpacks

सामान्य कॉन्फ़िगरेशन

app.yaml

Dockerfile

(service.yaml)

तीसरे पक्ष की लाइब्रेरी

requirements.txt

requirements.txt

requirements.txt

तीसरे पक्ष का कॉन्फ़िगरेशन

app.yaml (साथ ही, appengine_config.py और lib [सिर्फ़ 2.x के लिए])

(लागू नहीं)

(लागू नहीं)

स्टार्टअप

(लागू नहीं) या app.yaml (अगर entrypoint का इस्तेमाल किया गया है)

Dockerfile

Procfile

फ़ाइलों को अनदेखा करना

.gcloudignore और .gitignore

.gcloudignore, .gitignore, और .dockerignore

.gcloudignore और .gitignore

ऐप्लिकेशन को कंटेनर में बदलने के बाद, उसे Cloud Run पर डिप्लॉय किया जा सकता है. Google Cloud के अन्य कंटेनर प्लैटफ़ॉर्म विकल्पों में, Compute Engine, GKE, और Anthos शामिल हैं.

सामान्य कॉन्फ़िगरेशन

App Engine, आपके ऐप्लिकेशन को अपने-आप शुरू कर देता है. हालांकि, Cloud Run ऐसा नहीं करता. Procfile, app.yaml entrypoint डायरेक्टिव की तरह ही काम करता है. हमारे सैंपल ऐप्लिकेशन के लिए, हमारा Procfile, Flask डेवलपमेंट सर्वर शुरू करने के लिए python main.py को एक्ज़ीक्यूट करेगा. अगर चाहें, तो प्रोडक्शन वेब सर्वर, जैसे कि gunicorn का भी इस्तेमाल किया जा सकता है. अगर ऐसा किया जाता है, तो इसे requirements.txt में ज़रूर जोड़ें. Cloud Run के दस्तावेज़ों वाले इस पेज पर जाकर, सोर्स कोड से डिप्लॉय करने के लिए Buildpacks का इस्तेमाल करने के बारे में ज़्यादा जानें.

आपको सिर्फ़ अपने app.yaml entrypoint डायरेक्टिव को Procfile में ले जाना होगा. अगर आपके पास ऐसा कोई सर्वर नहीं है, तो फ़िलहाल Flask डेवलपमेंट सर्वर का इस्तेमाल करें. ऐसा इसलिए, क्योंकि यह सिर्फ़ एक सैंपल टेस्ट ऐप्लिकेशन है. इससे लोगों को इस माइग्रेशन के बारे में जानकारी मिलेगी. आपका ऐप्लिकेशन, स्टार्टअप के लिए खास कमांड होगा. इसके बारे में आपको सबसे ज़्यादा जानकारी होगी. Cloud Run सेवा, पर्दे के पीछे एक service.yaml बनाती है. यह app.yaml की तरह दिखता/काम करता है. अपने-आप जनरेट हुआ service.yaml देखने के लिए, इस तरह के लिंक पर जाएं. हालांकि, यह लिंक आपकी सेवा SVC_NAME और REGION के लिए होना चाहिए: https://console.cloud.google.com/run/detail/REGION/SVC_NAME/yaml/view.

तीसरे पक्ष की लाइब्रेरी

requirements.txt फ़ाइल में बदलाव करने की ज़रूरत नहीं है. इसमें Flask के साथ-साथ आपकी Datastore क्लाइंट लाइब्रेरी (Cloud Datastore या Cloud NDB) होनी चाहिए. अगर आपको WSGI के साथ काम करने वाले किसी दूसरे एचटीटीपी सर्वर, जैसे कि Gunicorn का इस्तेमाल करना है, तो requirements.txt में gunicorn==20.0.4 जोड़ें. इस लेख को लिखते समय, Gunicorn का मौजूदा वर्शन 20.0.4 है.

तीसरे पक्ष का कॉन्फ़िगरेशन

Buildpacks, Python 2 के साथ काम नहीं करता. इसलिए, हम यहां इसके बारे में बात नहीं करेंगे. Cloud Run पर कंटेनर में चलने वाले Python 3 ऐप्लिकेशन, Python 3 App Engine ऐप्लिकेशन की तरह ही होते हैं. इनमें तीसरे पक्ष की लाइब्रेरी को requirements.txt में तय करना ज़रूरी होता है.

स्टार्टअप

Python 3 का इस्तेमाल करने वाले लोगों के पास, अपनी app.yaml फ़ाइलों को बदलने का विकल्प होता है. इससे वे अपने handlers सेक्शन में script: auto डायरेक्टिव के बजाय entrypoint का इस्तेमाल कर सकते हैं. अगर Python 3 app.yaml में entrypoint का इस्तेमाल किया जाता है, तो यह कुछ ऐसा दिखेगा:

runtime: python38
entrypoint: python main.py

entrypoint डायरेक्टिव से App Engine को यह पता चलता है कि आपके सर्वर को कैसे शुरू करना है. इसे सीधे Procfile में ले जाया जा सकता है. दोनों प्लैटफ़ॉर्म के बीच एंट्रीपॉइंट डायरेक्टिव कहां जाएगा, इसके बारे में खास जानकारी: यह सीधे तौर पर यहां दिया गया है. साथ ही, Docker के बराबर की जानकारी भी दी गई है:

  • Buildpacks: Procfile में मौजूद लाइन: web: python main.py
  • Docker: Dockerfile में मौजूद लाइन: ENTRYPOINT ["python", "main.py"]

टेस्टिंग और स्टेजिंग के लिए, ऊपर दिए गए तरीके से Python से Flask के डेवलपमेंट सर्वर को चलाना आसान है. हालांकि, डेवलपर प्रोडक्शन के लिए ज़्यादा बेहतर विकल्प चुन सकते हैं. जैसे, Cloud Run का क्विकस्टार्ट सैंपल, जो gunicorn का इस्तेमाल करता है.

ऐप्लिकेशन फ़ाइलें

मॉड्यूल 2 या मॉड्यूल 3 के सभी ऐप्लिकेशन, Python 2-3 के साथ पूरी तरह से काम करते हैं. इसका मतलब है कि main.py के मुख्य कॉम्पोनेंट में कोई बदलाव नहीं किया गया है. हम सिर्फ़ स्टार्टअप कोड की कुछ लाइनें जोड़ेंगे. main.py के सबसे नीचे दो लाइनें जोड़ें, ताकि डेवलपमेंट सर्वर शुरू किया जा सके. Cloud Run को पोर्ट 8080 खुला रखने की ज़रूरत होती है, ताकि वह आपके ऐप्लिकेशन को कॉल कर सके:

if __name__ == '__main__':
    import os
    app.run(debug=True, threaded=True, host='0.0.0.0',
            port=int(os.environ.get('PORT', 8080)))

5. बनाना और डिप्लॉय करना

App Engine के कॉन्फ़िगरेशन को Buildpacks से बदल दिया गया है और सोर्स फ़ाइल के अपडेट पूरे हो गए हैं. अब इसे Cloud Run पर चलाने के लिए तैयार किया जा सकता है. इससे पहले, आइए सेवाओं के बारे में कुछ जानकारी हासिल करें.

सेवाएं बनाम ऐप्लिकेशन

App Engine को मुख्य रूप से ऐप्लिकेशन होस्ट करने के लिए बनाया गया था. हालांकि, यह वेब सेवाओं या माइक्रोसेवाओं के कलेक्शन से बने ऐप्लिकेशन को होस्ट करने के लिए भी एक प्लैटफ़ॉर्म है. Cloud Run में, हर चीज़ एक सेवा होती है. भले ही, वह कोई सेवा हो या वेब इंटरफ़ेस वाला ऐप्लिकेशन. इसलिए, इसके इस्तेमाल को ऐप्लिकेशन के बजाय सेवा की तैनाती के तौर पर देखें.

अगर आपका App Engine ऐप्लिकेशन कई सेवाओं से मिलकर नहीं बना है, तो आपको ऐप्लिकेशन डिप्लॉय करते समय किसी भी तरह का नाम नहीं देना पड़ता था. Cloud Run में यह तरीका बदल जाता है. इसमें आपको सेवा का नाम देना होता है. वहीं, App Engine के appspot.com डोमेन में उसका प्रोजेक्ट आईडी होता है. उदाहरण के लिए, https://PROJECT_ID.appspot.com. साथ ही, इसमें क्षेत्र के आईडी का संक्षिप्त नाम भी हो सकता है. उदाहरण के लिए, http://PROJECT_ID.REGION_ID.r.appspot.com.

हालांकि, Cloud Run सेवा के डोमेन में इसका सेवा का नाम, क्षेत्र के आईडी का छोटा नाम, और हैश शामिल होता है.इसमें इसका प्रोजेक्ट आईडी शामिल नहीं होता. उदाहरण के लिए, https://SVC_NAME-HASH-REG_ABBR.a.run.app. इसलिए, सेवा का नाम सोचें!

सेवा डिप्लॉय करना

अपनी कंटेनर इमेज बनाने और उसे Cloud Run पर डिप्लॉय करने के लिए, यहां दिया गया निर्देश चलाएं. जब आपसे पूछा जाए, तब अपना क्षेत्र चुनें. साथ ही, आसानी से टेस्टिंग करने के लिए, बिना पुष्टि किए कनेक्शन की अनुमति दें. इसके बाद, अपना क्षेत्र चुनें. यहां SVC_NAME उस सेवा का नाम है जिसे आपको डिप्लॉय करना है.

$ gcloud run deploy SVC_NAME --source .
Please choose a target platform:
 [1] Cloud Run (fully managed)
 [2] Cloud Run for Anthos deployed on Google Cloud
 [3] Cloud Run for Anthos deployed on VMware
 [4] cancel
Please enter your numeric choice:  1

To specify the platform yourself, pass `--platform managed`. Or, to make this the default target platform, run `gcloud config set run/platform managed`.

Please specify a region:
 [1] asia-east1
 [2] asia-east2
 [3] asia-northeast1
 [4] asia-northeast2
 [5] asia-northeast3
 [6] asia-south1
 [7] asia-southeast1
 [8] asia-southeast2
 [9] australia-southeast1
 [10] europe-north1
 [11] europe-west1
 [12] europe-west2
 [13] europe-west3
 [14] europe-west4
 [15] europe-west6
 [16] northamerica-northeast1
 [17] southamerica-east1
 [18] us-central1
 [19] us-east1
 [20] us-east4
 [21] us-west1
 [22] us-west2
 [23] us-west3
 [24] us-west4
 [25] cancel
Please enter your numeric choice: <select your numeric region choice>

To make this the default region, run `gcloud config set run/region REGION`.

Allow unauthenticated invocations to [SVC_NAME] (y/N)?  y

Building using Buildpacks and deploying container to Cloud Run service [SVC_NAME] in project [PROJECT_ID] region [REGION]
✓ Building and deploying... Done.
  ✓ Uploading sources...
  ✓ Building Container... Logs are available at [https://console.cloud.google.com/cloud-build/builds/BUILD-HASH?project=PROJECT_NUM].
  ✓ Creating Revision...
  ✓ Routing traffic...
Done.
Service [SVC_NAME] revision [SVC_NAME-00014-soc] has been deployed and is serving 100 percent of traffic.
Service URL: https://SVC_NAME-HASH-REG_ABBR.a.run.app

अपने ब्राउज़र में दिए गए यूआरएल पर जाएं. इससे आपको यह पुष्टि करने में मदद मिलेगी कि डिप्लॉयमेंट पूरा हो गया है!

gcloud कमांड से पता चलता है कि उपयोगकर्ता, आउटपुट और इंटरैक्टिविटी को कम करने के लिए, कई डिफ़ॉल्ट सेटिंग सेट कर सकते हैं. जैसा कि ऊपर दिखाया गया है. उदाहरण के लिए, सभी इंटरैक्शन से बचने के लिए, डिप्लॉय करने के लिए यहां दी गई एक लाइन वाली कमांड का इस्तेमाल किया जा सकता है:

$ gcloud beta run deploy SVC_NAME --source . --platform managed --region REGION --allow-unauthenticated

अगर आपको इस विकल्प का इस्तेमाल करना है, तो पक्का करें कि आपने सेवा का वही नाम SVC_NAME और मनचाहा REGION नाम चुना हो. इंडेक्स किए गए मेन्यू का विकल्प न चुनें, जैसा कि हमने ऊपर इंटरैक्टिव तरीके से किया था.

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

पुष्टि करें कि ऐप्लिकेशन, App Engine की तरह Cloud Run पर भी काम करता है. अगर आपने इस सीरीज़ में, पहले के किसी भी कोडलैब को पूरा किए बिना हिस्सा लिया है, तो ऐप्लिकेशन में कोई बदलाव नहीं होता. यह मुख्य वेब पेज (/) पर आने वाले सभी लोगों को रजिस्टर करता है. साइट पर कई बार जाने के बाद, यह इस तरह दिखता है:

visitme ऐप्लिकेशन

आपका कोड अब Module 5 repo folder में मौजूद कोड से मेल खाना चाहिए. पांचवें मॉड्यूल का कोडलैब पूरा करने के लिए बधाई.

ज़रूरी नहीं: साफ़ करना

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

ज़रूरी नहीं: सेवा बंद करना

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

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

अगले चरण

बधाई हो, आपने अपने ऐप्लिकेशन को कंटेनर में बदल दिया है. इस ट्यूटोरियल में इतना ही! इसके बाद, अगला चरण यह है कि आप मॉड्यूल 4 के कोडलैब (नीचे दिया गया लिंक) में Docker का इस्तेमाल करके, इसी काम को करने का तरीका जानें. इसके अलावा, App Engine से माइग्रेट करने का कोई दूसरा तरीका भी आज़माया जा सकता है:

  • मॉड्यूल 4: Docker का इस्तेमाल करके Cloud Run पर माइग्रेट करना
    • Docker की मदद से, अपने ऐप्लिकेशन को कंटेनर में बदलें, ताकि उसे Cloud Run पर चलाया जा सके
    • इससे Python 2 पर बने रहने की अनुमति मिलती है
  • मॉड्यूल 7: App Engine की पुश टास्क कतारें (अगर [push] टास्क कतारों का इस्तेमाल किया जाता है, तो यह ज़रूरी है)
    • App Engine taskqueue पुश टास्क को Module 1 ऐप्लिकेशन में जोड़ता है
    • यह मॉड्यूल, उपयोगकर्ताओं को मॉड्यूल 8 में Cloud Tasks पर माइग्रेट करने के लिए तैयार करता है
  • तीसरा मॉड्यूल:
    • Cloud NDB से Cloud Datastore में डेटा ऐक्सेस करने की सुविधा को अपग्रेड करना
    • इस लाइब्रेरी का इस्तेमाल, Python 3 App Engine ऐप्लिकेशन और गैर-App Engine ऐप्लिकेशन के लिए किया जाता है
  • मॉड्यूल 6: Cloud Firestore पर माइग्रेट करना
    • Firebase की सुविधाओं को ऐक्सेस करने के लिए, Cloud Firestore पर माइग्रेट करना
    • Cloud Firestore, Python 2 के साथ काम करता है. हालांकि, यह कोडलैब सिर्फ़ Python 3 में उपलब्ध है.

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

App Engine माइग्रेशन मॉड्यूल कोडलैब से जुड़ी समस्याएं/सुझाव/राय

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

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

मॉड्यूल 2 और 3 (START) और मॉड्यूल 5 (FINISH) के लिए, रेपो फ़ोल्डर के लिंक यहां दी गई टेबल में देखे जा सकते हैं. इन्हें App Engine के सभी कोडलैब माइग्रेशन के लिए बने रेपो से भी ऐक्सेस किया जा सकता है. इसे क्लोन किया जा सकता है या इसकी ZIP फ़ाइल डाउनलोड की जा सकती है.

कोडलैब

Python 2

Python 3

Module 2

code

(code)

Module 3

(code)

code

मॉड्यूल 5

(लागू नहीं)

code

App Engine और Cloud Run के संसाधन

इस माइग्रेशन के बारे में ज़्यादा जानकारी के लिए, यहां दिए गए संसाधन देखें: