मॉड्यूल 4: Docker के साथ Google App Engine से क्लाउड रन पर माइग्रेट करना

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

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

यह ट्यूटोरियल आपको Docker की मदद से Cloud Run पूरी तरह से प्रबंधित सेवा में डिप्लॉय करने के लिए, App Engine ऐप्लिकेशन को कंटेनर में रखने का तरीका बताता है. Docker कंटेनर में ऐप्लिकेशन डेवलप करने, भेजने, और उन्हें चलाने के लिए इंडस्ट्री का एक जाना-माना प्लैटफ़ॉर्म है. Python 2 डेवलपर के लिए, यह ट्यूटोरियल मॉड्यूल 2 क्लाउड एनडीबी App Engine सैंपल ऐप्लिकेशन से शुरू होता है. वहीं, Python 3 डेवलपर, मॉड्यूल 3 क्लाउड डेटास्टोर सैंपल से शुरुआत करते हैं.

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

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

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

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

• के साथ एक Google Cloud Platform प्रोजेक्ट
  • चालू GCP बिलिंग खाता
  • App Engine चालू किया गया
• Python के बुनियादी हुनर
• सामान्य Linux कमांड के बारे में काम करने की जानकारी
• App Engine ऐप्लिकेशन डेवलप करने और डिप्लॉय करने की बुनियादी जानकारी
• सुझाया गया: मॉड्यूल 2 कोडलैब या मॉड्यूल 3 कोडलैब को पूरा करें
• काम कर रहा App Engine ऐप्लिकेशन कंटेनर होने के लिए तैयार है
  • Python 2: मॉड्यूल 2 क्लाउड एनडीबी सैंपल
  • Python 3: मॉड्यूल 3 Cloud Datastore सैंपल

सर्वे

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

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

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 कॉन्फ़िगरेशन फ़ाइलों को कंटेनर कॉन्फ़िगरेशन से बदलकर, अपने ऐप्लिकेशन को कंटेनर बनाने का तरीका बताया जाएगा. साथ ही, आपको यह भी पता चलेगा कि कंटेनर में क्या शामिल होता है और फिर आपको अपने ऐप्लिकेशन को चालू करने का तरीका कैसे पता करना है. इनमें से कई चीज़ें App Engine अपने-आप मैनेज होता है.

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

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

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

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

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

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

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

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

हम इस ट्यूटोरियल के Python 2 वर्शन और उसी तरह Python 3 के लिए मॉड्यूल 3 कोड का इस्तेमाल शुरू करेंगे. चाहे आप अपने या हमारे किसी अन्य कोड का इस्तेमाल करें, मॉड्यूल 2 कोड का इस्तेमाल करें. यह मॉड्यूल 4 कोडलैब आपको हर चरण के बारे में जानकारी देता है. आपके चुने गए विकल्पों के हिसाब से, आपको मॉड्यूल 4 रेपो फ़ोल्डर (FINISH) में से किसी एक से मिलता-जुलता कोड मिलने चाहिए.

• Python 2 (Cloud NDB ऐप्लिकेशन)
  • START: मॉड्यूल 2 कोड
  • पूरा करें: मॉड्यूल 4 कोड
• Python 3 (Cloud Datastore ऐप्लिकेशन)
  • START: मॉड्यूल 3 कोड
  • पूरा करें: मॉड्यूल 4 कोड
• पूरा रेपो (क्लोन करने या ZIP डाउनलोड करने के लिए)

Python 2 मॉड्यूल 2 की शुरुआती फ़ाइलों (आपकी या हमारी) की डायरेक्ट्री कुछ इस तरह दिखेगी:

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

अगर आप अपने खुद के मॉड्यूल 2 (2.x) कोड का इस्तेमाल कर रहे हैं, तो आपके पास एक lib फ़ोल्डर भी होगा. Python 3 के लिए न तो lib का इस्तेमाल किया जाता है और न ही appengine_config.py का, जहां मॉड्यूल 3 (3.x) का शुरुआती कोड ऐसा दिखना चाहिए:

$ 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 के बारे में पहले से ही पता है और Cloud Run के लिए अपने App Engine ऐप्लिकेशन को कंटेनर बनाने के बारे में ज़्यादा जानना है, तो यह सही जगह है. इसके बाद, मॉड्यूल 5 कोडलैब (इस कोड की तरह ही, लेकिन Cloud Buildpack के साथ) भी किया जा सकता है. सामान्य तस्वीरों वाला हमारा सैंपल ऐप्लिकेशन, Dockerfile से जुड़ी ऊपर बताई गई कुछ समस्याओं से बचने के लिए काफ़ी हल्का है.

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

जानकारी	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 से माइग्रेट करने का मतलब है कि app.yaml को Dockerfile से बदलना, जो कंटेनर बनाने और उसे चलाने का तरीका बताता है. App Engine आपका ऐप्लिकेशन अपने आप शुरू करता है, लेकिन Cloud Run नहीं करता. Dockerfile ENTRYPOINT और CMD निर्देश इसी के लिए हैं. क्लाउड रन के इस दस्तावेज़ वाले पेज पर जाकर, Dockerfile के बारे में ज़्यादा जानें. साथ ही, gunicorn की शुरुआत करने वाले Dockerfile का उदाहरण देखें.

Dockerfile में ENTRYPOINT या CMD के बजाय, Procfile का इस्तेमाल किया जाता है. आखिर में, .dockerignore आपके कंटेनर का साइज़ कम रखने के लिए, बिना ऐप्लिकेशन वाली फ़ाइलों को फ़िल्टर करने में मदद करता है. इनके बारे में ज़्यादा जानकारी जल्द ही आने वाली है!

app.yaml मिटाएं और Dockerfile बनाएं

app.yaml का इस्तेमाल कंटेनर में नहीं किया जाता है. इसलिए, इसे अभी मिटाएं. कंटेनर कॉन्फ़िगरेशन फ़ाइल Dockerfile है और हमारे नमूना ऐप्लिकेशन के लिए सिर्फ़ एक छोटी सी फ़ाइल की ज़रूरत होती है. NNN को 2 या 3 से बदलकर, इस कॉन्टेंट का इस्तेमाल करके अपना Dockerfile बनाएं. यह इस बात पर निर्भर करता है कि Python के किस वर्शन का इस्तेमाल किया जा रहा है:

FROM python:NNN-slim
WORKDIR /app
COPY . .
RUN pip install -r requirements.txt
ENTRYPOINT ["python", "main.py"]

ज़्यादातर Dockerfile में यह बताया जाता है कि कंटेनर को छोड़कर, कैसे कंटेनर बनाया जाए, जो कंटेनर को शुरू करने का तरीका बताता है. इस मामले में, यह कंटेनर, फ़्लास्क डेवलपमेंट सर्वर को एक्ज़ीक्यूट करने के लिए python main.py को कॉल करता है.ENTRYPOINT अगर आपने Docker इस्तेमाल नहीं किया है, तो FROM डायरेक्टिव, मूल इमेज और "स्लिम" इमेज के बारे में बताता है कम से कम Python डिस्ट्रिब्यूशन को दिखाता है. इस बारे में ज़्यादा जानने के लिए, Docker Python इमेज पेज पर जाएं.

निर्देशों का बीच वाला सेट, काम करने वाली डायरेक्ट्री (/app) बनाता है और ऐप्लिकेशन फ़ाइलों में कॉपी करता है. इसके बाद, यह pip install चलाकर तीसरे पक्ष की लाइब्रेरी को कंटेनर में ले जाता है. WORKDIR, Linux mkdir और cd के निर्देशों को एक साथ जोड़ता है; WORKDIR दस्तावेज़ में इसके बारे में ज़्यादा पढ़ें. COPY और RUN डायरेक्टिव के बारे में अपने-आप जानकारी मिल जाती है.

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

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

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

Python 2 App Engine के डेवलपर को पता है कि तीसरे पक्ष की लाइब्रेरी या तो lib फ़ोल्डर में कॉपी की जाती हैं, उनका requirements.txt में बताया जाता है, जो app.yaml में आइटम के मुताबिक होती हैं, और appengine_config.py के साथ काम करती हैं. Python 3 App Engine ऐप्लिकेशन जैसे कंटेनर, सिर्फ़ requirements.txt का इस्तेमाल करते हैं. इसलिए, अगर आपके पास 2.x App Engine ऐप्लिकेशन है, तो बाकी सभी चीज़ें हटाई जा सकती हैं. ऐसे में, आपके पास अभी कोई lib फ़ोल्डर मिटाने appengine_config.py का विकल्प है.

स्टार्टअप

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

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

runtime: python38
entrypoint: python main.py

entrypoint डायरेक्टिव, App Engine को आपका सर्वर चालू करने का तरीका बताता है. आप इसे सीधे अपने Dockerfile में ले जा सकते हैं (या अगर Buildpack इस्तेमाल कर रहे हैं, तो Procfile को अपने ऐप्लिकेशन में कंटेनर बनाने के लिए [मॉड्यूल 5 देखें] में ले जाया जा सकता है. यह कम शब्दों में बताना कि दोनों प्लैटफ़ॉर्म के बीच एंट्रीपॉइंट डायरेक्टिव कहां पर लागू होगा:

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

टेस्टिंग के लिए फ़्लास्क डेवलपमेंट सर्वर का इस्तेमाल करना ठीक है, लेकिन अगर आप अपने ऐप्लिकेशन के लिए gunicorn जैसे प्रोडक्शन सर्वर का इस्तेमाल कर रहे हैं, तो पक्का कर लें कि आप ENTRYPOINT या CMD डायरेक्टिव को Cloud Run क्विकस्टार्ट सैंपल की तरह ही इस्तेमाल कर रहे हों.

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

हम आपको अपने कंटेनर के साइज़ में काट-छांट करने के लिए, .dockerignore फ़ाइल बनाने का सुझाव देते हैं. इससे, कंटेनर इमेज में इस तरह की ग़ैर-ज़रूरी फ़ाइलें नहीं दिखेंगी:

*.md
*.pyc
*.pyo
.git/
.gitignore
__pycache__

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

सभी मॉड्यूल 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. बनाएं और डिप्लॉय करें

Docker कॉन्फ़िगरेशन और सोर्स फ़ाइल के अपडेट पूरे हो जाने के बाद, इसे 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 beta 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 Dockerfile and deploying container to Cloud Run service [SVC_NAME] in project [PROJECT_ID] region [REGION]
✓ Building and deploying new service... Done.
  ✓ Uploading sources...
  ✓ Building Container... Logs are available at [https://console.cloud.google.com/cloud-build/builds/BUILD-HASH?project=PROJECT_NUM].
  ✓ Creating Revision... Deploying Revision.
  ✓ Routing traffic...
  ✓ Setting IAM Policy...
Done.
Service [SVC_NAME] revision [SVC_NAME-00001-vos] 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 पर करता था. अगर आपने कोई भी पिछले कोडलैब का इस्तेमाल किए बिना इस सीरीज़ में शामिल होना शुरू कर दिया है, तो ऐप्लिकेशन में कोई बदलाव नहीं होगा; यह मुख्य वेब पेज (/) पर की जाने वाली सभी विज़िट को रजिस्टर कर लेता है. साथ ही, जब आप साइट पर कई बार आ चुके होते हैं, तो यह ऐसा दिखता है:

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

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

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

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

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

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

अगले चरण

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

• अगर आपने पहले से Python 3 पर माइग्रेट नहीं किया है, तो Python 3 पर माइग्रेट करें. सैंपल ऐप्लिकेशन पहले से ही 2.x और 3.x के साथ काम करता है. इसलिए, सिर्फ़ Docker उपयोगकर्ता ही अपने Dockerfile को Python 3 इमेज इस्तेमाल करने के लिए अपडेट कर सकते हैं.
• मॉड्यूल 5: Cloud Buildpack के साथ Cloud Run पर माइग्रेट करना
  • Cloud Buildpack की मदद से, अपने ऐप्लिकेशन को Cloud Run पर चलाने के लिए कंटेनर बनाएं
  • आपको Docker, कंटेनर या Dockerfile के बारे में कुछ भी जानने की ज़रूरत नहीं है
  • यह ज़रूरी है कि आपने अपने ऐप्लिकेशन को पहले ही Python 3 पर माइग्रेट कर लिया हो
• मॉड्यूल 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 माइग्रेशन मॉड्यूल कोडलैब से जुड़ी समस्याएं/सुझाव

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

• App Engine माइग्रेशन कोडलैब के लिए समस्या को ट्रैक करने वाला टूल
  • समस्याओं को खोजना
  • नई समस्या/सुझाव दर्ज करें

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

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

Codelab	Python 2	Python 3
मॉड्यूल 2	कोड	(कोड)
मॉड्यूल 3	(कोड)	कोड
मॉड्यूल 4	कोड	कोड

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

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

• कंटेनर
  • Google क्लाउड रन
  • Google Cloud बिल्ड
  • Google Cloud Container Registry
  • डॉकर
  • Cloud Buildpacks के लॉन्च की पोस्ट
  • Cloud Buildpacks, पोस्ट डिप्लॉय करते हैं
  • Cloud Buildpacks रेपो
  • CNCF Buildpacks की खास बातें
  • App Engine से Cloud Run टूल — अपना service.yaml जनरेट करने के लिए
• सामान्य
  • Google Cloud Platform पर Python
  • Google Cloud Python क्लाइंट लाइब्रेरी