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

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

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

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

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

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

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

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

सर्वे

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

सिर्फ़ इसे पढ़ें इसे पढ़ें और कसरतों को पूरा करें

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

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

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

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

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

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

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

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

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

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

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

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

2. बेसलाइन ऐप्लिकेशन का नमूना डाउनलोड करें

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

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

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

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

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

कार्रवाई से पहले, इन चरणों को पूरा करें:

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

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

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

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

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

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

जानकारी

App Engine

डॉकर

बिल्डपैक

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

app.yaml

Dockerfile

(service.yaml)

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

requirements.txt

requirements.txt

requirements.txt

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

app.yaml (साथ में appengine_config.py और lib [2.x-only])

(लागू नहीं)

(लागू नहीं)

स्टार्टअप

(लागू नहीं) या 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, फ़्लास्क डेवलपमेंट सर्वर को शुरू करने के लिए python main.py को एक्ज़ीक्यूट करेगा. अगर आप चाहें, तो gunicorn जैसे प्रोडक्शन वेब सर्वर का इस्तेमाल भी किया जा सकता है. अगर हां, तो इसे requirements.txt में ज़रूर जोड़ें. इस Cloud Run दस्तावेज़ पेज से Buildpack इस्तेमाल करके, सोर्स कोड से डिप्लॉय करने के तरीके के बारे में ज़्यादा जानें.

आपको सिर्फ़ अपने app.yaml entrypoint डायरेक्टिव को Procfile में ले जाना होगा. अगर आपके पास ऐसा सर्वर नहीं है, तो अभी के लिए फ़्लास्क डेवलपमेंट सर्वर का इस्तेमाल करें. यह सिर्फ़ एक सैंपल ऐप्लिकेशन है, जिसमें लोगों को इस माइग्रेशन के बारे में जानकारी दी गई है. आपका ऐप्लिकेशन एक खास स्टार्टअप निर्देश होगा, जिसके बारे में आपको बेहतर जानकारी है. कवर के नीचे, 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 फ़ाइल को बदलने की ज़रूरत नहीं है; फ़्लास्क, आपकी Datastore क्लाइंट लाइब्रेरी (Cloud Datastore या Cloud NDB) के साथ होना चाहिए. अगर आपको डब्ल्यूएसजीआई की शर्तों का पालन करने वाले किसी दूसरे एचटीटीपी सर्वर, जैसे Gunicorn का इस्तेमाल करना है, तो Gunicorn का मौजूदा वर्शन 20.0.4 है. इसके बाद, gunicorn==20.0.4 को requirements.txt में जोड़ें.

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

Buildpack 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 में ले जा सकते हैं. इस बारे में जानकारी देना कि दोनों प्लैटफ़ॉर्म के बीच एंट्रीपॉइंट डायरेक्टिव कहां पर होगा: इसका सीधे तौर पर अनुवाद किया जाएगा; डॉकर को FYI के तौर पर भी दिखा रहा है:

  • बिल्डपैक: Procfile में मौजूद लाइन: web: python main.py
  • Docker: Dockerfile में लाइन: ENTRYPOINT ["python", "main.py"]

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

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

सभी मॉड्यूल 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 कॉन्फ़िगरेशन को Buildpack से बदल दिया गया है और सोर्स फ़ाइल के अपडेट पूरे हो गए हैं. अब इसे 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. खास जानकारी/क्लीनअप

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

विज़िटमी ऐप्लिकेशन

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

ज़रूरी नहीं: स्टोरेज खाली करें

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

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

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

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

अगले चरण

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

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

Codelab

Python 2

Python 3

मॉड्यूल 2

कोड

(कोड)

मॉड्यूल 3

(कोड)

कोड

मॉड्यूल 5

(लागू नहीं)

कोड

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

इस खास माइग्रेशन से जुड़े अतिरिक्त संसाधन नीचे दिए गए हैं: