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

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

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

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

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

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

इस कोडलैब में, आपको कंटेनर बनाने और उन्हें डिप्लॉय करने का तरीका पता चलेगा. इस ट्यूटोरियल में, आपको 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 पर डिप्लॉय करने के लिए, 'रीड मी' में दिए गए निर्देशों का पालन करें.

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 पर, आर्टफ़ैक्ट रजिस्ट्री का इस्तेमाल करके ऐसा करने का सुझाव दिया जाता है.

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 Boot का इस्तेमाल करेंगे.

ये डिपेंडेंसी जोड़ें:

<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>

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

3. Spring Boot सेटअप करना

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

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 को बिल्ड टूल के तौर पर इस्तेमाल करना है — क्योंकि डिफ़ॉल्ट रूप से, jar पैकेजिंग का इस्तेमाल किया जाता है.

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 में पहले से मौजूद कुछ सुविधाओं को मैन्युअल तरीके से फिर से बनाना पड़ता है. जैसे, Cron और टास्क कतार सेवाएं. इन सुविधाओं के बारे में ज़्यादा जानकारी, आगे के मॉड्यूल में दी जाएगी.

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

अब से आप 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 ये काम करता है:

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

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

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

बधाई हो, आपने अपने ऐप्लिकेशन को अपग्रेड कर लिया है, कंटेनर में डाल दिया है, और माइग्रेट कर दिया है. इस ट्यूटोरियल में अब और कुछ नहीं बचा!

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

ज़रूरी नहीं: डेटा मिटाना और/या सेवा बंद करना

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

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

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

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

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

माइग्रेशन से जुड़े संसाधन

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

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

App Engine

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

वीडियो

लाइसेंस

इस काम के लिए, Creative Commons Attribution 2.0 जनरल लाइसेंस के तहत लाइसेंस मिला है.