1. खास जानकारी
कोडलैब की इस सीरीज़ में, Google App Engine (स्टैंडर्ड) डेवलपर को अपने ऐप्लिकेशन को बेहतर बनाने में मदद मिलेगी. इसके लिए, उन्हें माइग्रेशन की सीरीज़ के बारे में जानकारी दी जाएगी. ये कोडलैब, डेवलपर अपनी सुविधा के हिसाब से कभी भी ऐक्सेस कर सकते हैं. साथ ही, इनमें प्रैक्टिकल ट्यूटोरियल भी शामिल हैं. इसके बाद, उपयोगकर्ता अपने ऐप्लिकेशन को ज़्यादा पोर्टेबल बना सकते हैं. इसके लिए, उन्हें Cloud Run और कंटेनर होस्ट करने वाली अन्य सेवाओं के लिए, ऐप्लिकेशन को कंटेनर में रखना होगा. Cloud Run, App Engine की कंटेनर होस्ट करने वाली सिस्टर सेवा है.
इस ट्यूटोरियल में, App Engine ऐप्लिकेशन को कंटेनर में बदलने का तरीका बताया गया है. इससे उन्हें Cloud Run की पूरी तरह से मैनेज की गई सेवा पर डिप्लॉय किया जा सकता है. इसके लिए, Docker का इस्तेमाल किया जाता है. यह इंडस्ट्री में, कंटेनर में ऐप्लिकेशन डेवलप करने, शिप करने, और चलाने के लिए एक जाना-माना प्लैटफ़ॉर्म है. Python 2 के डेवलपर के लिए, यह ट्यूटोरियल Module 2 Cloud NDB App Engine के सैंपल ऐप्लिकेशन से शुरू होता है. वहीं, Python 3 के डेवलपर के लिए, यह Module 3 Cloud Datastore के सैंपल से शुरू होता है.
आपको इनके बारे में जानकारी मिलेगी
- Docker का इस्तेमाल करके अपने ऐप्लिकेशन को कंटेनर में बदलना
- Cloud Run पर कंटेनर इमेज डिप्लॉय करना
आपको इन चीज़ों की ज़रूरत होगी
- Google Cloud Platform प्रोजेक्ट जिसमें ये शामिल हों:
- Python की बुनियादी जानकारी
- Linux की सामान्य कमांड के बारे में जानकारी होना
- App Engine ऐप्लिकेशन डेवलप और डिप्लॉय करने की बुनियादी जानकारी
- सुझाया गया: मॉड्यूल 2 का कोडलैब या मॉड्यूल 3 का कोडलैब पूरा करें
- App Engine का ऐसा ऐप्लिकेशन जो काम कर रहा हो और जिसे कंटेनर में बदला जा सकता हो
- Python 2: Module 2 Cloud NDB sample
- Python 3: Module 3 Cloud Datastore का सैंपल
सर्वे
इस कोडलैब का इस्तेमाल कैसे किया जाएगा?
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 की कॉन्फ़िगरेशन फ़ाइलों को कंटेनर कॉन्फ़िगरेशन से बदलना, यह तय करना कि कंटेनर में क्या-क्या शामिल किया जाए, और यह तय करना कि ऐप्लिकेशन को कैसे शुरू किया जाए. इनमें से कई काम, App Engine अपने-आप करता है.
इस माइग्रेशन में ये चरण शामिल हैं:
- सेटअप/प्रीवर्क
- ऐप्लिकेशन को कंटेनर में बदलना
- कॉन्फ़िगरेशन फ़ाइलें बदलना
- ऐप्लिकेशन की फ़ाइलों में बदलाव करना
3. सेटअप/प्रीवर्क
ट्यूटोरियल के मुख्य हिस्से को शुरू करने से पहले, आइए हम अपना प्रोजेक्ट सेट अप करें, कोड पाएं, और फिर बेसलाइन ऐप्लिकेशन को डिप्लॉय करें. इससे हमें पता चलेगा कि हमने काम करने वाले कोड से शुरुआत की है.
1. प्रोजेक्ट सेट अप करना
अगर आपने मॉड्यूल 2 या मॉड्यूल 3 के कोडलैब पूरे कर लिए हैं, तो हमारा सुझाव है कि आप उसी प्रोजेक्ट और कोड का दोबारा इस्तेमाल करें. इसके अलावा, एक नया प्रोजेक्ट बनाया जा सकता है या किसी मौजूदा प्रोजेक्ट का फिर से इस्तेमाल किया जा सकता है. पक्का करें कि प्रोजेक्ट में, बिलिंग के लिए ऐक्टिव खाता हो और App Engine (ऐप्लिकेशन) चालू हो.
2. बेसलाइन सैंपल ऐप्लिकेशन पाना
इस कोडलैब के लिए, यह ज़रूरी है कि आपके पास मॉड्यूल 2 या मॉड्यूल 3 का सैंपल ऐप्लिकेशन हो. अगर आपके पास ऐसा कोई ऐप्लिकेशन नहीं है, तो यहां आगे बढ़ने से पहले, ऊपर दिए गए लिंक पर जाकर कोई भी ट्यूटोरियल पूरा करें. अगर आपको इसके कॉन्टेंट के बारे में पहले से पता है, तो नीचे दिए गए मॉड्यूल 2 या 3 के कोड का इस्तेमाल करके शुरू करें.
चाहे हमारा कोड इस्तेमाल करें या अपना, हम इस ट्यूटोरियल के Python 2 वर्शन के लिए मॉड्यूल 2 के कोड से शुरुआत करेंगे. इसी तरह, Python 3 के लिए मॉड्यूल 3 के कोड से शुरुआत करेंगे. इस चौथे मॉड्यूल के कोडलैब में, आपको हर चरण के बारे में बताया गया है. आपके विकल्पों के आधार पर, आपको ऐसा कोड मिलेगा जो पूरा होने पर, चौथे मॉड्यूल के रेपो फ़ोल्डर (FINISH) में से किसी एक जैसा होगा.
- Python 2 (Cloud NDB ऐप्लिकेशन)
- START: Module 2 code
- पूरा करें: मॉड्यूल 4 का कोड
- Python 3 (Cloud Datastore ऐप्लिकेशन)
- START: Module 3 code
- पूरा करें: मॉड्यूल 4 का कोड
- पूरी रीपो (क्लोन करने या ZIP फ़ाइल डाउनलोड करने के लिए)
Python 2 Module 2 की STARTing फ़ाइलों (आपकी या हमारी) की डायरेक्ट्री ऐसी दिखनी चाहिए:
$ ls
README.md appengine_config.py requirements.txt
app.yaml main.py templates
अगर आपने अपने Module 2 (2.x) कोड का इस्तेमाल किया है, तो आपके पास एक lib फ़ोल्डर भी होगा. Python 3 के लिए, न तो lib और न ही appengine_config.py का इस्तेमाल किया जाता है. इसमें मॉड्यूल 3 (3.x) का शुरुआती कोड ऐसा दिखना चाहिए:
$ ls
README.md main.py templates
app.yaml requirements.txt
3. बेसलाइन ऐप्लिकेशन को (फिर से) डिप्लॉय करना
अब आपको ये काम करने हैं:
gcloudकमांड-लाइन टूल के बारे में फिर से जानेंgcloud app deployकी मदद से, सैंपल ऐप्लिकेशन को फिर से डिप्लॉय करना- पुष्टि करें कि ऐप्लिकेशन, App Engine पर बिना किसी समस्या के काम करता है
इन चरणों को पूरा करने के बाद, इसे कंटेनर में रखा जा सकता है.
4. ऐप्लिकेशन को कंटेनर में बदलना
Docker, आज इंडस्ट्री में कंटेनर बनाने का स्टैंडर्ड प्लैटफ़ॉर्म है. जैसा कि हमने पहले बताया था, इसका इस्तेमाल करने में एक चुनौती यह है कि एक असरदार Dockerfile तैयार करने में काफ़ी मेहनत लगती है. यह कॉन्फ़िगरेशन फ़ाइल यह तय करती है कि आपकी कंटेनर इमेज कैसे बनाई जाती हैं. दूसरी ओर, Buildpacks का इस्तेमाल करना आसान होता है. ऐसा इसलिए, क्योंकि यह आपके ऐप्लिकेशन की डिपेंडेंसी का पता लगाने के लिए इंट्रॉस्पेक्शन का इस्तेमाल करता है. इससे Buildpacks कंटेनर, आपके ऐप्लिकेशन के लिए ज़्यादा से ज़्यादा फ़ायदेमंद बन जाता है.
अगर आपको कंटेनर और Docker के बारे में पहले से पता है और आपको Cloud Run के लिए, अपने App Engine ऐप्लिकेशन को कंटेनर में बदलने के बारे में ज़्यादा जानना है, तो आप सही जगह पर हैं. इसके बाद, मॉड्यूल 5 का कोडलैब भी आज़माएं. यह कोडलैब, इस कोडलैब जैसा ही है. हालांकि, इसमें Cloud Buildpacks का इस्तेमाल किया गया है. हमारा सैंपल ऐप्लिकेशन, इन Dockerfile समस्याओं से बचने के लिए काफ़ी हल्का है.
माइग्रेशन के चरणों में, App Engine की कॉन्फ़िगरेशन फ़ाइलों को बदलना और यह तय करना शामिल है कि आपका ऐप्लिकेशन कैसे शुरू होना चाहिए. यहां दी गई टेबल में, हर प्लैटफ़ॉर्म टाइप के लिए कॉन्फ़िगरेशन फ़ाइलों की खास जानकारी दी गई है. App Engine कॉलम की तुलना Docker कॉलम (और चाहें, तो Buildpacks) से करें:
ब्यौरा | App Engine | Docker | Buildpacks |
सामान्य कॉन्फ़िगरेशन |
|
| ( |
तीसरे पक्ष की लाइब्रेरी |
|
|
|
तीसरे पक्ष का कॉन्फ़िगरेशन |
| (लागू नहीं) | (लागू नहीं) |
स्टार्टअप | (लागू नहीं) या |
|
|
फ़ाइलों को अनदेखा करना |
|
|
|
ऐप्लिकेशन को कंटेनर में बदलने के बाद, उसे Cloud Run पर डिप्लॉय किया जा सकता है. Google Cloud के अन्य कंटेनर प्लैटफ़ॉर्म विकल्पों में, Compute Engine, GKE, और Anthos शामिल हैं.
सामान्य कॉन्फ़िगरेशन
App Engine से माइग्रेट करने का मतलब है कि app.yaml को Dockerfile से बदलना. इसमें कंटेनर बनाने और चलाने का तरीका बताया गया है. App Engine, आपके ऐप्लिकेशन को अपने-आप शुरू कर देता है. हालांकि, Cloud Run ऐसा नहीं करता. Dockerfile ENTRYPOINT और CMD कमांड का इस्तेमाल इसी काम के लिए किया जाता है. Cloud Run के दस्तावेज़ वाले इस पेज पर जाकर, Dockerfile के बारे में ज़्यादा जानें. साथ ही, Dockerfile का एक ऐसा उदाहरण देखें जो gunicorn को स्पॉन करता है.
Dockerfile में ENTRYPOINT या CMD का इस्तेमाल करने के बजाय, Procfile का इस्तेमाल किया जा सकता है. आखिर में, .dockerignore की मदद से ऐप्लिकेशन से जुड़ी फ़ाइलों को फ़िल्टर किया जाता है, ताकि आपके कंटेनर का साइज़ कम रहे. इनके बारे में ज़्यादा जानकारी जल्द ही उपलब्ध होगी!
app.yaml मिटाएं और Dockerfile बनाएं
app.yaml का इस्तेमाल कंटेनर में नहीं किया जाता. इसलिए, इसे अभी मिटाएं. कंटेनर कॉन्फ़िगरेशन फ़ाइल Dockerfile है. हमारे सैंपल ऐप्लिकेशन के लिए, सिर्फ़ एक फ़ाइल की ज़रूरत होती है. इस कॉन्टेंट का इस्तेमाल करके, अपना Dockerfile बनाएं. इसके लिए, NNN को 2 या 3 से बदलें. यह इस बात पर निर्भर करता है कि Python के किस वर्शन का इस्तेमाल किया जा रहा है:
FROM python:NNN-slim
WORKDIR /app
COPY . .
RUN pip install -r requirements.txt
ENTRYPOINT ["python", "main.py"]
ज़्यादातर Dockerfile से पता चलता है कि कंटेनर कैसे बनाया जाए सिर्फ़ ENTRYPOINT से पता चलता है कि कंटेनर को कैसे शुरू किया जाए. इस मामले में, Flask डेवलपमेंट सर्वर को एक्ज़ीक्यूट करने के लिए python main.py को कॉल किया जाता है. अगर आपने Docker का इस्तेमाल पहले कभी नहीं किया है, तो FROM डायरेक्टिव से पता चलता है कि किस बेस इमेज से शुरू करना है. साथ ही, "slim" का मतलब है कि Python का कम से कम डिस्ट्रिब्यूशन. Docker Python इमेज पेज पर जाकर ज़्यादा जानें.
कमांड का बीच वाला सेट, वर्किंग डायरेक्ट्री (/app) बनाता है. साथ ही, ऐप्लिकेशन फ़ाइलों को कॉपी करता है. इसके बाद, pip install को चलाता है, ताकि तीसरे पक्ष की लाइब्रेरी को कंटेनर में लाया जा सके. WORKDIR, Linux की mkdir और cd कमांड को एक साथ जोड़ता है. इसके बारे में ज़्यादा जानने के लिए, WORKDIR का दस्तावेज़ पढ़ें. COPY और RUN डायरेक्टिव के नाम से ही पता चल जाता है कि इनका क्या काम है.
तीसरे पक्ष की लाइब्रेरी
requirements.txt फ़ाइल में कोई बदलाव करने की ज़रूरत नहीं है. इसमें Flask के साथ-साथ आपकी Datastore क्लाइंट लाइब्रेरी (Cloud Datastore या Cloud NDB) होनी चाहिए. अगर आपको WSGI के साथ काम करने वाले किसी दूसरे एचटीटीपी सर्वर, जैसे कि Gunicorn का इस्तेमाल करना है, तो requirements.txt में gunicorn==20.0.4 जोड़ें. इस लेख को लिखते समय, Gunicorn का मौजूदा वर्शन 20.0.4 है.
तीसरे पक्ष का कॉन्फ़िगरेशन
Python 2 App Engine डेवलपर को पता है कि तीसरे पक्ष की लाइब्रेरी को lib फ़ोल्डर में कॉपी किया जाता है, requirements.txt में रेफ़रंस दिया जाता है, app.yaml में आइटम के तौर पर शामिल किया जाता है, और appengine_config.py के साथ काम करती है. कंटेनर, जैसे कि Python 3 App Engine ऐप्लिकेशन, सिर्फ़ requirements.txt का इस्तेमाल करते हैं. इसलिए, बाकी सभी चीज़ों को हटाया जा सकता है. इसका मतलब है कि अगर आपके पास 2.x App Engine ऐप्लिकेशन है, तो delete appengine_config.py और किसी भी lib फ़ोल्डर को अभी हटाएं.
स्टार्टअप
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 में ले जाया जा सकता है. अगर ऐप्लिकेशन को कंटेनर में बदलने के लिए Buildpacks [मॉड्यूल 5 देखें] का इस्तेमाल किया जा रहा है, तो इसे Procfile में ले जाया जा सकता है. दोनों प्लैटफ़ॉर्म के बीच, एंट्रीपॉइंट डायरेक्टिव कहां जाएगा, इसके बारे में खास जानकारी:
- Docker:
Dockerfileमें मौजूद लाइन:ENTRYPOINT ["python", "main.py"] - Buildpacks:
Procfileमें मौजूद लाइन:web: python main.py
जांच के लिए, Flask डेवलपमेंट सर्वर का इस्तेमाल किया जा सकता है. हालांकि, अगर आपको अपने ऐप्लिकेशन के लिए gunicorn जैसे प्रोडक्शन सर्वर का इस्तेमाल करना है, तो पक्का करें कि आपने अपने ENTRYPOINT या CMD डायरेक्टिव को Cloud Run Quickstart सैंपल में दिए गए तरीके से सेट किया हो.
फ़ाइलों को अनदेखा करना
हमारा सुझाव है कि आप अपने कंटेनर का साइज़ कम करने के लिए, .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. खास जानकारी/सफ़ाई
पुष्टि करें कि ऐप्लिकेशन, App Engine की तरह Cloud Run पर भी काम करता है. अगर आपने इस सीरीज़ में, पहले के किसी भी कोडलैब को पूरा किए बिना हिस्सा लिया है, तो ऐप्लिकेशन में कोई बदलाव नहीं होता. यह मुख्य वेब पेज (/) पर आने वाले सभी लोगों को रजिस्टर करता है. साइट पर कई बार जाने के बाद, यह इस तरह दिखता है:

आपका कोड अब Module 4 repo फ़ोल्डर में मौजूद कोड से मेल खाना चाहिए. भले ही, वह 2.x हो या 3.x. इस चौथे मॉड्यूल का कोडलैब पूरा करने के लिए बधाई.
ज़रूरी नहीं: साफ़ करना
जब तक आप माइग्रेशन के अगले कोडलैब पर जाने के लिए तैयार नहीं हो जाते, तब तक बिलिंग से बचने के लिए क्या किया जा सकता है? अब किसी दूसरे प्रॉडक्ट का इस्तेमाल किया जा रहा है. इसलिए, Cloud Run की कीमत से जुड़ी गाइड को ज़रूर पढ़ें.
ज़रूरी नहीं: सेवा बंद करना
अगर आपको अभी अगले ट्यूटोरियल पर नहीं जाना है, तो अतिरिक्त शुल्क से बचने के लिए, अपनी सेवा बंद करें. जब आपको अगले कोडलैब पर जाना हो, तब इसे फिर से चालू किया जा सकता है. जब आपका ऐप्लिकेशन बंद होता है, तब उसे कोई ट्रैफ़िक नहीं मिलता. इसलिए, आपसे कोई शुल्क नहीं लिया जाता. हालांकि, अगर मुफ़्त कोटे से ज़्यादा Datastore का इस्तेमाल किया जाता है, तो आपसे शुल्क लिया जा सकता है. इसलिए, इतना डेटा मिटाएं कि वह सीमा के अंदर आ जाए.
दूसरी ओर, अगर आपको माइग्रेशन जारी नहीं रखना है और आपको सब कुछ पूरी तरह से मिटाना है, तो अपनी सेवा मिटाएं या अपने प्रोजेक्ट को पूरी तरह से बंद करें.
अगले चरण
बधाई हो, आपने अपने ऐप्लिकेशन को कंटेनर में बदल दिया है. इस ट्यूटोरियल में इतना ही! इसके बाद, अगला चरण यह है कि आप पांचवें मॉड्यूल के कोडलैब (नीचे दिया गया लिंक) में, Cloud Buildpacks का इस्तेमाल करके ऐसा करने का तरीका जानें. इसके अलावा, App Engine को माइग्रेट करने का कोई दूसरा तरीका भी आज़माया जा सकता है:
- अगर आपने अब तक Python 3 पर माइग्रेट नहीं किया है, तो ऐसा करें. सैंपल ऐप्लिकेशन, पहले से ही 2.x और 3.x के साथ काम करता है. इसलिए, Docker का इस्तेमाल करने वाले लोगों को सिर्फ़
Dockerfileअपडेट करना होगा, ताकि वे Python 3 इमेज का इस्तेमाल कर सकें. - पांचवां मॉड्यूल: Cloud Buildpacks की मदद से Cloud Run पर माइग्रेट करना
- Cloud Buildpacks की मदद से, अपने ऐप्लिकेशन को कंटेनर में बदलें, ताकि उसे Cloud Run पर चलाया जा सके
- आपको Docker, कंटेनर या
Dockerfileके बारे में कुछ भी जानने की ज़रूरत नहीं है - इसके लिए, यह ज़रूरी है कि आपने अपने ऐप्लिकेशन को पहले ही Python 3 पर माइग्रेट कर लिया हो
- मॉड्यूल 7: App Engine की पुश टास्क कतारें (अगर [push] टास्क कतारों का इस्तेमाल किया जाता है, तो यह ज़रूरी है)
- App Engine
taskqueueपुश टास्क को Module 1 ऐप्लिकेशन में जोड़ता है - यह मॉड्यूल, उपयोगकर्ताओं को मॉड्यूल 8 में Cloud Tasks पर माइग्रेट करने के लिए तैयार करता है
- App Engine
- तीसरा मॉड्यूल:
- 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 माइग्रेशन मॉड्यूल कोडलैब से जुड़ी समस्याएं/सुझाव/राय
अगर आपको इस कोडलैब में कोई समस्या मिलती है, तो कृपया शिकायत दर्ज करने से पहले अपनी समस्या खोजें. नई समस्याएं खोजने और बनाने के लिए लिंक:
- App Engine माइग्रेशन कोडलैब के लिए समस्या ट्रैकर
माइग्रेशन के लिए उपलब्ध संसाधन
मॉड्यूल 2 और 3 (START) और मॉड्यूल 4 (FINISH) के लिए, रेपो फ़ोल्डर के लिंक यहां दी गई टेबल में देखे जा सकते हैं. इन्हें App Engine के सभी कोडलैब माइग्रेशन के लिए बने रेपो से भी ऐक्सेस किया जा सकता है. इसे क्लोन किया जा सकता है या इसकी ZIP फ़ाइल डाउनलोड की जा सकती है.
कोडलैब | Python 2 | Python 3 |
(code) | ||
(code) | ||
Module 4 |
App Engine और Cloud Run के संसाधन
इस माइग्रेशन के बारे में ज़्यादा जानकारी के लिए, यहां दिए गए संसाधन देखें:
- कंटेनर
- Google Cloud Run
- Google Cloud Build
- Google Cloud Container Registry
- Docker
- Cloud Buildpacks लॉन्च करने से जुड़ी पोस्ट
- Cloud Buildpacks deploy post
- Cloud Buildpacks repo
- CNCF Buildpacks की खास बातें
- App Engine से Cloud Run पर माइग्रेट करने में मदद करने वाला टूल — इससे अपना
service.yamlजनरेट किया जा सकता है
- सामान्य