मॉड्यूल 11: Google App Engine से Cloud Functions पर माइग्रेट करना

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

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

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

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

  • Cloud Shell का इस्तेमाल करना
  • Google Cloud Translation API को चालू करें
  • एपीआई अनुरोधों की पुष्टि करना
  • App Engine के छोटे ऐप्लिकेशन को Cloud Functions पर चलाने के लिए बदलना
  • अपने कोड को Cloud Functions पर डिप्लॉय करना

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

सर्वे

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

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

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

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

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

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

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

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

हालांकि, App Engine का इस्तेमाल फ़ुल-स्टैक वेब ऐप्लिकेशन डेवलपमेंट या मोबाइल ऐप्लिकेशन के लिए जटिल बैक-एंड बनाने के लिए किया जा सकता है. हालांकि, अक्सर डेवलपर कुछ फ़ंक्शन को ऑनलाइन करने की कोशिश करते हैं. जैसे, न्यूज़ फ़ीड अपडेट करना या होम टीम के प्लेऑफ़ गेम का नया स्कोर पाना. दोनों ही स्थितियों के लिए कोडिंग लॉजिक मौजूद है. हालांकि, दोनों में से कोई भी "ऐप्लिकेशन" नहीं है. इसलिए, इनके लिए App Engine की ज़रूरत नहीं है. ऐसे में, Cloud Functions का इस्तेमाल किया जा सकता है.

Cloud Functions का इस्तेमाल, कोड के उस छोटे हिस्से को डिप्लॉय करने के लिए किया जाता है जो:

  • पूरे ऐप्लिकेशन का हिस्सा नहीं है
  • पूरे डेवलपमेंट स्टैक में इसकी ज़रूरत नहीं होती
  • किसी ऐप्लिकेशन या एक मोबाइल ऐप्लिकेशन के बैकएंड में हो, जो किसी एक चीज़ पर फ़ोकस करता हो

Cloud Functions का इस्तेमाल करके, बड़े और मोनोलिथिक ऐप्लिकेशन को कई माइक्रोसेवाओं में बांटा जा सकता है. हर माइक्रोसेवा, Cloud Firestore या Cloud SQL जैसे शेयर किए गए कॉमन डेटाबेस का इस्तेमाल करती है. अगर आपको अपने फ़ंक्शन या माइक्रोसेवा को कंटेनर में रखना है और Cloud Run पर सर्वरलेस तरीके से एक्ज़ीक्यूट करना है, तो ऐसा भी किया जा सकता है.

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

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

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

यह कोडलैब, Module 2 Cloud NDB App Engine के सैंपल ऐप्लिकेशन के Python 3 वर्शन से शुरू होता है. ऐसा इसलिए, क्योंकि Cloud Functions, Python 2 के साथ काम नहीं करता. सबसे पहले, हम अपना प्रोजेक्ट सेट अप करेंगे, कोड हासिल करेंगे, और फिर बेसलाइन ऐप्लिकेशन को डिप्लॉय करेंगे. इससे यह पुष्टि हो जाएगी कि हम काम करने वाले कोड से शुरुआत कर रहे हैं.

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

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

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

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

चाहे हमारा कोड इस्तेमाल करें या अपना, हम Module 2 के Python 3 कोड से शुरुआत करेंगे. इस 11वें मॉड्यूल के कोडलैब में, आपको हर चरण के बारे में बताया गया है. साथ ही, इसमें ऐसा कोड भी दिया गया है जो 11वें मॉड्यूल के repo फ़ोल्डर (FINISH) में मौजूद कोड से मिलता-जुलता है.

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

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

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

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

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

इन चरणों को पूरा करने के बाद, इसे Cloud फ़ंक्शन में बदला जा सकता है.

4. कॉन्फ़िगरेशन फ़ाइलें हटाना

app.yaml फ़ाइल, App Engine का आर्टफ़ैक्ट है. इसका इस्तेमाल Cloud Functions के साथ नहीं किया जाता. इसलिए, इसे अभी मिटाएं. अगर आपने ऐसा नहीं किया है या आप ऐसा करना भूल गए हैं, तो इससे कोई नुकसान नहीं होगा, क्योंकि Cloud Functions इसका इस्तेमाल नहीं करता है. कॉन्फ़िगरेशन में सिर्फ़ यही बदलाव किया गया है, क्योंकि requirements.txt मॉड्यूल 2 में मौजूद कॉन्फ़िगरेशन जैसा ही है.

अगर आपको Python 2 App Engine ऐप्लिकेशन को Python 3 में पोर्ट करना है, तो appengine_config.py और lib फ़ोल्डर को मिटा दें. ये App Engine के ऐसे आर्टफ़ैक्ट हैं जिनका इस्तेमाल Python 3 रनटाइम में नहीं किया जाता.

5. ऐप्लिकेशन की फ़ाइलों में बदलाव करना

सिर्फ़ एक ऐप्लिकेशन फ़ाइल, main.py होती है. इसलिए, Cloud Functions पर माइग्रेट करने के लिए ज़रूरी सभी बदलाव इसी फ़ाइल में होते हैं.

आयात

हम सिर्फ़ फ़ंक्शन के साथ काम कर रहे हैं. इसलिए, वेब ऐप्लिकेशन फ़्रेमवर्क की ज़रूरत नहीं है. हालांकि, Python पर आधारित Cloud Functions को कॉल करने पर, उन्हें अनुरोध ऑब्जेक्ट अपने-आप पास कर दिया जाता है, ताकि आपका कोड ज़रूरत के हिसाब से उसका इस्तेमाल कर सके. (Cloud Functions टीम ने इसे Flask Request object के तौर पर चुना है, जिसे आपके फ़ंक्शन को पास किया जाता है.)

वेब फ़्रेमवर्क, Cloud Functions के लैंडस्केप का हिस्सा नहीं हैं. इसलिए, Flask से कोई इंपोर्ट नहीं किया जाता है जब तक आपका ऐप्लिकेशन, Flask की अन्य सुविधाओं का इस्तेमाल नहीं करता. यह हमारा ही मामला है, क्योंकि फ़ंक्शन में बदलने के बाद भी टेंप्लेट रेंडरिंग हो रही है. इसका मतलब है कि flask.render_template() को कॉल करने की अब भी ज़रूरत है. इसलिए, इसे Flask से इंपोर्ट किया जाता है. वेब फ़्रेमवर्क नहीं होने का मतलब है कि Flask ऐप्लिकेशन को इंस्टैंटिएट करने की ज़रूरत नहीं है. इसलिए, app = Flask(__name__) को मिटा दें. बदलाव लागू करने से पहले और बाद में, आपका कोड कुछ इस तरह दिखेगा:

BEFORE:

from flask import Flask, render_template, request
from google.cloud import ndb

app = Flask(__name__)
ds_client = ndb.Client()

AFTER:

from flask import render_template
from google.cloud import ndb

ds_client = ndb.Client()

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

मुख्य हैंडलर फ़ंक्शन के सिग्नेचर को अपडेट करना

फ़ंक्शन सिग्नेचर में ये बदलाव करने होंगे:

  1. ऐप्लिकेशन को Cloud Function में बदलने के बाद, Flask का इस्तेमाल नहीं किया जाता. इसलिए, रूट डेकोरेटर हटा दें.
  2. Cloud Functions, Flask Request ऑब्जेक्ट को पैरामीटर के तौर पर अपने-आप पास करता है. इसलिए, इसके लिए एक वैरिएबल बनाएं. हमारे सैंपल ऐप्लिकेशन में, हम इसे request कहेंगे.
  3. डिप्लॉय किए गए Cloud फ़ंक्शन का नाम होना चाहिए. हमारे मुख्य हैंडलर का नाम App Engine में सही तरीके से root() रखा गया था, ताकि यह बताया जा सके कि यह क्या है (रूट ऐप्लिकेशन हैंडलर). Cloud फ़ंक्शन के तौर पर, उस नाम का इस्तेमाल करना सही नहीं है. इसके बजाय, हम visitme नाम वाला Cloud फ़ंक्शन डिप्लॉय करेंगे. इसलिए, इसे Python फ़ंक्शन के नाम के तौर पर भी इस्तेमाल करें. इसी तरह, हमने मॉड्यूल 4 और 5 में Cloud Run सेवा का नाम भी visitme रखा था.

इन अपडेट के बाद, यहां पहले और बाद की जानकारी दी गई है:

BEFORE:

@app.route('/')
def root():
    'main application (GET) handler'
    store_visit(request.remote_addr, request.user_agent)
    visits = fetch_visits(10)
    return render_template('index.html', visits=visits)

AFTER:

def visitme(request):
    'main application (GET) handler'
    store_visit(request.remote_addr, request.user_agent)
    visits = fetch_visits(10)
    return render_template('index.html', visits=visits)

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

668f30e3865b27a9.png

लोकल डेवलपमेंट और टेस्टिंग

App Engine में dev_appserver.py लोकल डेवलपमेंट सर्वर होता है, जबकि Cloud Functions में Functions Framework होता है. इस फ़्रेमवर्क की मदद से, स्थानीय तौर पर डेवलपमेंट और टेस्टिंग की जा सकती है. आपके कोड को Cloud Functions पर डिप्लॉय किया जा सकता है. हालांकि, इसे Compute Engine, Cloud Run जैसे अन्य कंप्यूट प्लैटफ़ॉर्म पर भी डिप्लॉय किया जा सकता है. इसके अलावा, इसे Knative के साथ काम करने वाले ऑन-प्रेम या हाइब्रिड क्लाउड सिस्टम पर भी डिप्लॉय किया जा सकता है. Functions Framework के बारे में ज़्यादा जानने के लिए, यहां दिए गए लिंक पर जाएं.

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

Cloud Functions पर डिप्लॉय करने का तरीका, App Engine से थोड़ा अलग है. requirements.txt के बाहर किसी भी कॉन्फ़िगरेशन फ़ाइल का इस्तेमाल नहीं किया जाता है. इसलिए, कमांड-लाइन पर कोड के बारे में ज़्यादा जानकारी देनी होगी. इस निर्देश का इस्तेमाल करके, Python 3.10 पर चलने वाले नए एचटीटीपी ट्रिगर किए गए Cloud फ़ंक्शन को डिप्लॉय करें:

$ gcloud functions deploy visitme --runtime python310 --trigger-http --allow-unauthenticated

आपको इससे मिलता-जुलता आउटपुट दिखेगा:

Deploying function (may take a while - up to 2 minutes)...⠛
For Cloud Build Logs, visit: https://console.cloud.google.com/cloud-build/builds;region=REGION/f5f6fc81-1bb3-4cdb-8bfe?project=PROJECT_ID
Deploying function (may take a while - up to 2 minutes)...done.
availableMemoryMb: 256
buildId: f5f6fc81-1bb3-4cdb-8bfe
buildName: projects/PROJECT_ID/locations/REGION/builds/f5f6fc81-1bb3-4cdb-8bfe
dockerRegistry: CONTAINER_REGISTRY
entryPoint: visitme
httpsTrigger:
  securityLevel: SECURE_OPTIONAL
  url: https://REGION-PROJECT_ID.cloudfunctions.net/visitme
ingressSettings: ALLOW_ALL
labels:
  deployment-tool: cli-gcloud
name: projects/PROJECT_ID/locations/REGION/functions/visitme
runtime: python310
serviceAccountEmail: PROJECT_ID@appspot.gserviceaccount.com
sourceUploadUrl: https://storage.googleapis.com/uploads-853031211983.REGION.cloudfunctions.appspot.com/8c923758-cee8-47ce-8e97-5720a5301c34.zip
status: ACTIVE
timeout: 60s
updateTime: '2022-05-16T18:28:06.153Z'
versionId: '8'

फ़ंक्शन डिप्लॉय होने के बाद, डिप्लॉयमेंट आउटपुट से मिले यूआरएल का इस्तेमाल करें और अपने ऐप्लिकेशन पर जाएं. यूआरएल इस फ़ॉर्म में होता है: REGION-PROJECT_ID.cloudfunctions.net/visitme. आउटपुट, App Engine पर पहले डिप्लॉय किए गए आउटपुट जैसा ही होना चाहिए:

2732ae9218f011a2.png

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

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

इस छोटे App Engine ऐप्लिकेशन को Cloud Functions में बदलने के लिए बधाई! इस्तेमाल का एक और सही उदाहरण: किसी बड़े App Engine ऐप्लिकेशन को कई माइक्रोसेवाओं में बांटना. हर माइक्रोसेवा को Cloud Functions के तौर पर इस्तेमाल किया जा सकता है. यह डेवलपमेंट का ज़्यादा मॉडर्न तरीका है. इससे "प्लग-एंड-प्ले" कॉम्पोनेंट (जैसे, " JAM स्टैक") स्टाइल मिलती है. इससे मिक्स ऐंड मैच और कोड का दोबारा इस्तेमाल किया जा सकता है. ये दो लक्ष्य हैं. हालांकि, इसका एक और फ़ायदा यह है कि इन माइक्रोसेवाओं को समय-समय पर डीबग किया जाता रहेगा. इसका मतलब है कि कोड स्थिर रहेगा और रखरखाव की कुल लागत कम होगी.

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

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

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

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

अगले चरण

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

  • मॉड्यूल 4: Docker की मदद से Cloud Run पर माइग्रेट करना
  • Docker की मदद से, अपने ऐप्लिकेशन को कंटेनर में बदलें, ताकि उसे Cloud Run पर चलाया जा सके
  • इस माइग्रेशन की मदद से, Python 2 का इस्तेमाल जारी रखा जा सकता है.
  • मॉड्यूल 5: Cloud Buildpacks की मदद से Cloud Run पर माइग्रेट करना
  • Cloud Buildpacks की मदद से, अपने ऐप्लिकेशन को कंटेनर में बदलें, ताकि उसे Cloud Run पर चलाया जा सके
  • आपको Docker, कंटेनर या Dockerfile के बारे में कुछ भी जानने की ज़रूरत नहीं है.
  • इसके लिए, आपके ऐप्लिकेशन को पहले ही Python 3 पर माइग्रेट किया गया हो. Buildpacks, Python 2 के साथ काम नहीं करता

अन्य कई मॉड्यूल में, डेवलपर को यह दिखाया गया है कि App Engine की बंडल की गई सेवाओं से, Cloud की स्टैंडअलोन सेवाओं पर कैसे माइग्रेट किया जाए:

अगर कंटेनराइज़ेशन, ऐप्लिकेशन डेवलपमेंट के आपके वर्कफ़्लो का हिस्सा बन गया है, तो Cloud Functions के बजाय Cloud Run पर माइग्रेट करें. खास तौर पर, अगर इसमें सीआई/सीडी (लगातार इंटिग्रेशन/लगातार डिलीवरी या डिप्लॉयमेंट) पाइपलाइन शामिल है. Docker की मदद से अपने ऐप्लिकेशन को कंटेनर में बदलने के लिए, मॉड्यूल 4 देखें. इसके अलावा, कंटेनर, Docker की जानकारी या Dockerfile के बिना ऐसा करने के लिए, मॉड्यूल 5 देखें. Cloud Functions या Cloud Run में से किसी एक को चुनने के लिए, बिना सर्वर वाला कोई दूसरा प्लैटफ़ॉर्म इस्तेमाल करना ज़रूरी नहीं है. हमारा सुझाव है कि कोई भी बदलाव करने से पहले, अपने ऐप्लिकेशन और इस्तेमाल के उदाहरणों के लिए सबसे सही विकल्पों पर विचार करें.

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

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

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

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

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

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

कोडलैब

Python 3

Module 2

code

Module 11

code

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

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

App Engine

Cloud Functions

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

वीडियो

लाइसेंस

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