Buildpack के साथ Google App Engine Java ऐप्लिकेशन से Cloud Run पर माइग्रेट करना

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

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

इस ट्यूटोरियल में आपको Buildpack इस्तेमाल करके, App Engine ऐप्लिकेशन को पूरी तरह से मैनेज की जाने वाली सेवा में डिप्लॉय करने के लिए, कंटेनर तैयार करने का तरीका बताया गया है. Buildpack एक CNCF प्रोजेक्ट है. इसकी मदद से, ऐप्लिकेशन को सीधे सोर्स कोड से पोर्टेबल इमेज में ले जाया जा सकता है. इन इमेज को किसी भी क्लाउड पर चलाया जा सकता है.

आपको App Engine से Cloud Run में जाने के ज़रूरी चरण पढ़ाने के साथ-साथ, आप Java 8 App Engine ऐप्लिकेशन को Java 17 में अपग्रेड करने के तरीके भी सीखेंगे.

आपको जिस ऐप्लिकेशन को माइग्रेट करना है, अगर वह App Engine की लेगसी बंडल की गई सेवाओं या App Engine की दूसरी खास सुविधाओं का बहुत ज़्यादा इस्तेमाल करता है, तो इस कोडलैब के मुकाबले, Java 11/17 के लिए ऐप्लिकेशन इंजन की बंडल की गई सेवाओं को ऐक्सेस करना गाइड बेहतर साबित हो सकती है.

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

  • Cloud Shell का इस्तेमाल करना
  • Cloud Run, Artifact Registry, और Cloud Build API चालू करती हैं
  • Cloud Build पर Buildpack का इस्तेमाल करके, अपने ऐप्लिकेशन को कंटेनर में लाना
  • अपनी कंटेनर इमेज को Cloud Run पर डिप्लॉय करें

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

सर्वे

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

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

Java के साथ अपने अनुभव को आप कितनी रेटिंग देंगे?

शुरुआती इंटरमीडिएट कुशल

Google Cloud की सेवाएं इस्तेमाल करने का आपका अनुभव कैसा रहा?

शुरुआती इंटरमीडिएट कुशल

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

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

हालांकि, कंटेनर का लचीलापन भी आकर्षक है. कोई भी भाषा, कोई भी लाइब्रेरी, और कोई भी बाइनरी चुनने की सुविधा होने पर, कंटेनर आपको दोनों का सबसे अच्छा अनुभव देते हैं: कंटेनर के साथ सर्वर की सुविधा के साथ-साथ बिना सर्वर की सुविधा. Google Cloud Run इसी के बारे में है.

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

इस कोडलैब में, आपको कंटेनर बनाने और डिप्लॉय करने का तरीका बताया जाएगा. इस लेख में, आपको Buildpack के साथ अपने ऐप्लिकेशन को कंटेनर बनाने, App Engine कॉन्फ़िगरेशन से माइग्रेट करने, और Cloud Build के लिए बिल्ड के चरण तय करने का तरीका पता चलेगा. इसमें, App Engine की कुछ खास सुविधाओं को हटाना होगा. अगर आपको यह पाथ फ़ॉलो नहीं करना है, तो अपने ऐप्लिकेशन को App Engine पर बनाए रखते हुए भी, Java 11/17 रनटाइम में अपग्रेड किया जा सकता है.

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

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

इस ट्यूटोरियल के लिए, नए प्रोजेक्ट पर मौजूद appengine-java-migration-samples डेटा स्टोर करने की जगह से सैंपल ऐप्लिकेशन का इस्तेमाल किया जाएगा. पक्का करें कि प्रोजेक्ट का बिलिंग खाता चालू हो.

अगर आपको किसी मौजूदा App Engine ऐप्लिकेशन को Cloud Run में ले जाना है, तो उस ऐप्लिकेशन का इस्तेमाल करें.

अपने प्रोजेक्ट के लिए ज़रूरी एपीआई चालू करने के लिए, यह कमांड चलाएं:

gcloud services enable artifactregistry.googleapis.com cloudbuild.googleapis.com run.googleapis.com

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

सैंपल ऐप्लिकेशन का क्लोन अपनी मशीन या Cloud Shell पर बनाएं. इसके बाद, बेसलाइन फ़ोल्डर पर जाएं.

यह नमूना Java 8, Servlet-आधारित Datastore ऐप्लिकेशन है. इसे App Engine पर डिप्लॉय करने के लिए बनाया गया है. इस ऐप्लिकेशन को App Engine डिप्लॉयमेंट के लिए तैयार करने का तरीका जानने के लिए, README में दिए गए निर्देशों का पालन करें.

3. (ज़रूरी नहीं) बेसलाइन ऐप्लिकेशन डिप्लॉय करें

नीचे दी गई चीज़ों की ज़रूरत सिर्फ़ तब होती है, जब आप Cloud Run पर माइग्रेट करने से पहले यह पुष्टि करना चाहते हों कि ऐप्लिकेशन App Engine पर काम कर रहा है.

README.md में दिए गए तरीके देखें:

  1. gcloud सीएलआई की मदद से खुद को इंस्टॉल करें/फिर से जानें
  2. gcloud init के साथ अपने प्रोजेक्ट के लिए gcloud सीएलआई शुरू करें
  3. gcloud app create की मदद से App Engine प्रोजेक्ट बनाएं
  4. सैंपल ऐप्लिकेशन को App Engine में डिप्लॉय करें
./mvnw package appengine:deploy -Dapp.projectId=$PROJECT_ID
  1. पक्का करना कि ऐप्लिकेशन बिना किसी समस्या के App Engine पर चलता है

4. Artifact Registry का डेटा स्टोर करने की जगह बनाना

अपने ऐप्लिकेशन को कंटेनर में रखने के बाद, आपको अपनी इमेज पुश और स्टोर करने के लिए किसी जगह की ज़रूरत होगी. हमारा सुझाव है कि Google Cloud पर इसके बारे में जानने के लिए Artifact Registry का इस्तेमाल करें.

gcloud के साथ migration नाम की रिपॉज़िटरी बनाएं. जैसे:

gcloud artifacts repositories create migration --repository-format=docker \
--description="Docker repository for the migrated app" \
--location="northamerica-northeast1"

ध्यान दें कि इस रिपॉज़िटरी में docker फ़ॉर्मैट टाइप का इस्तेमाल किया जाता है. हालांकि, रिपॉज़िटरी के कई टाइप उपलब्ध हैं.

इस समय, आपके पास अपना बेसलाइन App Engine ऐप्लिकेशन है और आपका Google Cloud प्रोजेक्ट उसे Cloud Run पर माइग्रेट करने के लिए तैयार है.

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

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

1. Java 17 पर अपग्रेड करना

अगर आपका ऐप्लिकेशन Java 8 पर काम करता है, तो सुरक्षा से जुड़े अपडेट पाने और भाषा से जुड़ी नई सुविधाओं का ऐक्सेस पाने के लिए, 11 या 17 जैसे एलटीएस वाले किसी बाद के वर्शन पर अपग्रेड करें.

अपने pom.xml में प्रॉपर्टी अपडेट करके शुरुआत करें, ताकि इन्हें शामिल किया जा सके:

<properties>
    <java.version>17</java.version>
    <maven.compiler.source>17</maven.compiler.source>
    <maven.compiler.target>17</maven.compiler.target>
</properties>

ऐसा करने से, प्रोजेक्ट वर्शन 17 पर सेट हो जाएगा और कंपाइलर प्लगिन को यह सूचना मिलेगी कि आपको java 17 लैंग्वेज की सुविधाओं का ऐक्सेस चाहिए. साथ ही, आपको कंपाइलर की मदद से इकट्ठा की गई क्लास को Java 17 JVM के साथ काम करना है.

2. वेब सर्वर शामिल करना

App Engine और Cloud Run के बीच कई अंतर होते हैं. इनके बीच आने-जाने का ध्यान रखा जाता है. एक अंतर यह है कि जब App Engine का Java 8 रनटाइम, होस्ट किए गए ऐप्लिकेशन के लिए एक Jetty सर्वर उपलब्ध कराता है और उसे मैनेज करता है, तो Cloud Run ऐसा नहीं करता. हम वेब सर्वर और सर्वलेट कंटेनर उपलब्ध कराने के लिए, Spring बूट का इस्तेमाल करेंगे.

इन डिपेंडेंसी जोड़ें:

<dependencies>
<!-- ... -->
   <dependency>
       <groupId>org.springframework.boot</groupId>
       <artifactId>spring-boot-starter-web</artifactId>
       <version>2.6.6</version>
       <exclusions>
           <!-- Exclude the Tomcat dependency -->
           <exclusion>
               <groupId>org.springframework.boot</groupId>
               <artifactId>spring-boot-starter-tomcat</artifactId>
           </exclusion>
       </exclusions>
   </dependency>
   <!-- Use Jetty instead -->
   <dependency>
       <groupId>org.springframework.boot</groupId>
       <artifactId>spring-boot-starter-jetty</artifactId>
       <version>2.6.6</version>
   </dependency>
<!-- ... -->
</dependencies>

स्प्रिंग बूट में डिफ़ॉल्ट रूप से एक टॉमकैट सर्वर शामिल होता है, लेकिन यह सैंपल उस आर्टफ़ैक्ट को बाहर कर देगा और माइग्रेशन के बाद डिफ़ॉल्ट व्यवहार में अंतर को कम करने के लिए, Jetty के साथ रहेगा.

3. Spring बूट सेटअप

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

com.example.appengine पैकेज में यह MigratedServletApplication.java क्लास बनाएं:

package com.example.appengine;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.EnableAutoConfiguration;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.boot.web.servlet.ServletComponentScan;

@ServletComponentScan
@SpringBootApplication
@EnableAutoConfiguration
public class MigratedServletApplication {
    public static void main(String[] args) {
        SpringApplication.run(MigratedServletApplication.class, args);
    }
}

ध्यान दें कि इसमें @ServletComponentScan एनोटेशन शामिल है. यह किसी भी @WebServlets के लिए, डिफ़ॉल्ट रूप से मौजूदा पैकेज में दिखेगा और उम्मीद के मुताबिक उपलब्ध होगा.

4. बिल्ड कॉन्फ़िगरेशन

इसके बाद, हमारे ऐप्लिकेशन को WAR के तौर पर पैकेज करने के लिए कॉन्फ़िगरेशन हटाएं. इसके लिए ज़्यादा कॉन्फ़िगरेशन की ज़रूरत नहीं होगी. खास तौर पर, उन प्रोजेक्ट के लिए जो बिल्ड टूल के तौर पर Maven का इस्तेमाल करते हैं — क्योंकि जार पैकेजिंग डिफ़ॉल्ट तरीका है.

pom.xml फ़ाइल से packaging टैग हटाएं:

<packaging>war</packaging>

इसके बाद, spring-boot-maven-plugin जोड़ें:

<plugins>
<!-- ... -->
  <plugin>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-maven-plugin</artifactId>
    <version>2.6.6</version>
  </plugin>
<!-- ... -->
</plugins>

5. App Engine कॉन्फ़िगरेशन, सेवाओं, और डिपेंडेंसी से माइग्रेट करना

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

सैंपल के तौर पर उपलब्ध ऐप्लिकेशन, बंडल की गई लेगसी सेवाओं का इस्तेमाल नहीं करता. हालांकि, जिन उपयोगकर्ताओं के ऐप्लिकेशन अपने ऐप्लिकेशन में मौजूद हैं वे नीचे दी गई गाइड देख सकते हैं:

अब से आप Cloud Run पर डिप्लॉय करेंगे, इसलिए appengine-maven-plugin को हटाया जा सकता है:

<plugin>
 <groupId>com.google.cloud.tools</groupId>
 <artifactId>appengine-maven-plugin</artifactId>
 <version>2.4.1</version>
 <configuration>
   <!-- can be set w/ -DprojectId=myProjectId on command line -->
   <projectId>${app.projectId}</projectId>
   <!-- set the GAE version or use "GCLOUD_CONFIG" for an autogenerated GAE version -->
   <version>GCLOUD_CONFIG</version>
 </configuration>
</plugin>

5. कंटेनर बनाना और ऐप्लिकेशन डिप्लॉय करें

अब आप अपने ऐप्लिकेशन को सीधे अपने सोर्स कोड से Cloud Run पर डिप्लॉय करने के लिए तैयार हैं. यह एक बेहतरीन विकल्प है, जो डिप्लॉय करने का बेहतरीन अनुभव देने के लिए, पर्दे के पीछे Cloud Build का इस्तेमाल करता है. ध्यान दें कि इस सुविधा का इस्तेमाल करने के लिए, आपके पास इनमें से कम से कम एक अनुमति वाला खाता होना चाहिए. साथ ही, एनवायरमेंट सेटअप करने के इन चरणों को पूरा करना होगा या Cloud Shell का इस्तेमाल करना होगा:

इन ज़रूरी शर्तों को पूरा करने के बाद, अपनी सोर्स डायरेक्ट्री से ये काम करें:

gcloud run deploy SERVICE --source .

रन डिप्लॉयमेंट कमांड के दौरान, आपको कुछ चीज़ों के लिए प्रॉम्प्ट किया जाएगा. जैसे:

  • सोर्स कोड से जुड़ी जगह की जानकारी देना
  • सेवा का नाम देना
  • Cloud Run API चालू करना
  • अपना क्षेत्र चुनना

उन प्रॉम्प्ट का जवाब देने के बाद, बिल्ड और डिप्लॉयमेंट की प्रोसेस शुरू हो जाती है. इस दौरान, Cloud Build ये काम करता है:

  • ज़िप करता है और आपके सोर्स को क्लाउड स्टोरेज बकेट में सेव करता है
  • आपकी इमेज बनाने के लिए, क्लाउड नेटिव कंप्यूटिंग फ़ाउंडेशन बिल्डपैक का इस्तेमाल करता है
  • मिलने वाले कंटेनर इमेज को स्टोर करने के लिए एक रजिस्ट्री बनाता है (अगर पहले से मौजूद नहीं है)
  • साथ ही, आपके ऐप्लिकेशन को होस्ट करने के लिए क्लाउड रन सेवा बनाता है (अगर पहले से मौजूद नहीं है)

बिल्ड और डिप्लॉयमेंट पूरा होने के बाद, आपको यह बताने वाला मैसेज मिलेगा कि नया वर्शन लाइव है और उस पर 100% ट्रैफ़िक आ रहा है.

6. खास जानकारी/क्लीनअप

बधाई हो, आपने अपने ऐप्लिकेशन को अपग्रेड किया, कंटेनर बनाया, माइग्रेट किया और जिसके साथ यह ट्यूटोरियल खत्म हुआ!

यहां CI/CD और सॉफ़्टवेयर सप्लाई चेन की सुरक्षा से जुड़ी उन सुविधाओं के बारे में ज़्यादा जानकारी दी गई है जो अब आपके पास उपलब्ध हैं. इन्हें Cloud Build के साथ डिप्लॉय किया जा सकता है:

ज़रूरी नहीं: क्लीन अप और/या सेवा बंद करना

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

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

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

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

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

माइग्रेशन संसाधन

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

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

App Engine

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

वीडियो

लाइसेंस

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