Jib के साथ Google App Engine Java ऐप्लिकेशन से क्लाउड रन पर माइग्रेट करना

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

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

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

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

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

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

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

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

सर्वे

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

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

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

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

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

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

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

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

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

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

इस कोडलैब में, आपको कंटेनर बनाने और डिप्लॉय करने का तरीका बताया जाएगा. आपको, इनके बारे में जानकारी मिलेगी:

  • अपने ऐप्लिकेशन को Jib की मदद से कंटेनर बनाएं
  • 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 के साथ रहेगा. हम Jetty वर्शन को भी कॉन्फ़िगर कर सकते हैं, ताकि वह App Engine के उपलब्ध कराए गए वर्शन से मेल खाए.

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

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. ऐप्लिकेशन को JAR के तौर पर पैकेजिंग करना

किसी युद्ध के बाद अपने ऐप्लिकेशन को Jib के साथ कंटेनर बनाया जा सकता है. हालांकि, अगर आप अपने ऐप्लिकेशन को एक्ज़ीक्यूटेबल JAR के तौर पर पैकेज में शामिल कर लेते हैं, तो यह काम आसान हो जाता है. इसके लिए ज़्यादा कॉन्फ़िगरेशन की ज़रूरत नहीं होगी. खास तौर पर, उन प्रोजेक्ट के लिए जो बिल्ड टूल के तौर पर 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 का इस्तेमाल करता है. हम बाद के मॉड्यूल में, सोर्स डिप्लॉयमेंट के बारे में ज़्यादा जानकारी देंगे.

इसके अलावा, अगर आपको ऐप्लिकेशन के डिप्लॉयमेंट के तरीके पर ज़्यादा कंट्रोल चाहिए, तो ऐसा करने के लिए cloudbuild.yaml फ़ाइल तय करें. यह फ़ाइल, ऐप्लिकेशन बनाने के आपके मकसद के बारे में साफ़ तौर पर बताती है:

1. Cloudbuild.yaml फ़ाइल के बारे में बताएं

इस cloudbuild.yaml फ़ाइल को pom.xml के लेवल पर ही बनाएं:

steps:
  # Test your build
  - name: maven:eclipse-temurin
    entrypoint: mvn
    args: ["test"]
  # Build with Jib
  - name: maven:eclipse-temurin
    entrypoint: mvn
    args: [ "compile", "com.google.cloud.tools:jib-maven-plugin:3.2.1:build", "-Dimage=northamerica-northeast1-docker.pkg.dev/PROJECT_ID/migration/visitors:jib"]
  # Deploy to Cloud Run
  - name: 'gcr.io/google.com/cloudsdktool/cloud-sdk'
    entrypoint: gcloud
    args: [ 'run', 'deploy', 'visitors', '--image', 'northamerica-northeast1-docker.pkg.dev/PROJECT_ID/migration/visitors:jib', '--region', 'northamerica-northeast1', '--allow-unauthenticated']

जब हम Cloud Build को यह तरीका अपनाने के लिए कहेंगे, तब वह:

  1. ./mvnw test का इस्तेमाल करके जांच करें
  2. Jib की मदद से आर्टफ़ैक्ट रजिस्ट्री में अपनी इमेज बनाएं, पुश करें, और टैग करें
  3. gcloud run deploy की मदद से, अपनी इमेज को Cloud Run पर डिप्लॉय करें

ध्यान दें कि Cloud Run को ‘visitors', अपनी पसंद की सेवा के नाम के तौर पर दिया गया है. –allow-unauthenticated फ़्लैग की मदद से, उपयोगकर्ता पुष्टि किए बिना वेब ऐप्लिकेशन पर जा सकते हैं. cloudbuild.yaml फ़ाइल में, PROJECT_ID की जगह अपने प्रोजेक्ट का आईडी डालना न भूलें.

इसके बाद, Cloud Build के सेवा खाते को Artifact Registry में शामिल करने की अनुमति देने के लिए, यहां दी गई आईएएम नीति की बाइंडिंग जोड़ें:

export PROJECT_ID=$(gcloud config list --format 'value(core.project)')
export PROJECT_NUMBER=$(gcloud projects describe $PROJECT_ID --format="value(projectNumber)" )

gcloud projects add-iam-policy-binding $PROJECT_ID \
--member=serviceAccount:$PROJECT_NUMBER@cloudbuild.gserviceaccount.com \
--role=roles/run.admin \
--project=$PROJECT_ID
gcloud iam service-accounts add-iam-policy-binding $PROJECT_NUMBER-compute@developer.gserviceaccount.com \
--member=serviceAccount:$PROJECT_NUMBER@cloudbuild.gserviceaccount.com \
--role roles/iam.serviceAccountUser --project=$PROJECT_ID

2. बिल्ड प्रोसेस चलाना

आपने Cloud Build को बिल्ड के लिए अपनी पसंद के चरणों के बारे में बता दिया है, तो अब आप एक-क्लिक में डिप्लॉयमेंट के लिए तैयार हैं.

नीचे दिया गया निर्देश चलाएं:

gcloud builds submit

प्रक्रिया पूरी हो जाने के बाद, आपके कंटेनर की इमेज बन जाती है, Artifact Registry में सेव हो जाती है, और Cloud Run पर डिप्लॉय हो जाती है.

इस कोडलैब के आखिर में, आपका ऐप्लिकेशन ठीक वैसा ही दिखना चाहिए जैसा java17-and-cloud-run/finish में है.

यह रहा आपका काम! आपने Java 8 App Engine ऐप्लिकेशन को Java 17 और Cloud Run पर माइग्रेट कर लिया है. साथ ही, अब आपको होस्टिंग के विकल्पों के बीच चुनने और स्विच करने में होने वाले काम के बारे में बेहतर जानकारी है.

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

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

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

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

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

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

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

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

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

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

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

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

App Engine

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

वीडियो

लाइसेंस

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