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

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

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

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

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

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

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

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

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

सर्वे

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

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

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

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

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

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

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

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

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

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

इस कोडलैब में, आपको कंटेनर बनाने और डिप्लॉय करने का तरीका बताया जाएगा. आपको Dockerfile के साथ, अपने ऐप्लिकेशन को कंटेनर बनाने का तरीका पता चलेगा. साथ ही, आपको 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. ऐप्लिकेशन को JAR के तौर पर पैकेजिंग करना

वैसे तो अपने ऐप्लिकेशन को युद्ध से शुरू करके कंटेनर तैयार किया जा सकता है, लेकिन अगर आप अपने ऐप्लिकेशन को एक्ज़ीक्यूटेबल 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 Build को अपने ऐप्लिकेशन का कंटेनर बनाने का तरीका बताने के लिए तैयार हैं. कंटेनर बनाने के इस तरीके का इस्तेमाल करने पर, एक अलग बिल्ड कॉन्फ़िगरेशन फ़ाइल (cloudbuild.yaml) की ज़रूरत नहीं होती. हम एक छोटे से Dockerfile को शुरुआती पॉइंट के रूप में परिभाषित कर सकते हैं:

ग्रहण-टेमुरिन से

ARG JAR_FILE=JAR_FILE_MUST_BE_SPECIFIED_AS_BUILD_ARG

${JAR_FILE} app.Jर को कॉपी करें

ENTRYPOINT ["java", "- Jar","/app.jar"]

यह Dockerfile, आपकी स्प्रिंग बूट सेवा के uber-Jer वर्शन को एक ही लेयर में बंडल करती है. यह Dockerfile कंटेनर के इस्तेमाल का सबसे आसान तरीका है. हालांकि, इसमें कई कमियां हैं. खास तौर पर, ऐसा बार-बार होने वाले समय की तुलना करने पर होता है, जहां डिपेंडेंसी ज़्यादा स्थिर होती है. इस तरह की समस्याएं होने की वजह से, कंटेनर बनाने के इस तरीके को ज़्यादा बेहतर माना जाता है. हालांकि, इसका अच्छी बात यह है कि अपना Dockerfile लिखने से, आपकी बेस इमेज पर पूरा कंट्रोल मिल जाता है. साथ ही, आपको सावधानी से लेयर वाली इमेज लिखने के परफ़ॉर्मेंस फ़ायदों का ऐक्सेस भी मिल जाता है.

2**. बिल्ड प्रोसेस चलाएं**

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

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

gcloud builds submit --tag LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY/IMAGE_NAME

ऊपर दिए गए निर्देश में मौजूद प्लेसहोल्डर वैल्यू को, इन वैल्यू से बदलें:

  • स्थान: आपके डेटा संग्रह स्थान के लिए क्षेत्रीय या बहु-क्षेत्रीय स्थान.
  • PROJECT_ID: आपका Cloud प्रोजेक्ट आईडी.
  • डेटा स्टोर करने की जगह: आपके Artifact Registry का डेटा स्टोर करने की जगह का नाम.
  • IMAGE_NAME: आपके कंटेनर इमेज का नाम.

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

इस कोडलैब के आखिर में, आपका ऐप्लिकेशन ठीक वैसा ही दिखना चाहिए जैसा mod4-Migrate-to-cloud-run फ़ोल्डर में है.

यह रहा आपका काम! आपने 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 जेनरिक लाइसेंस के तहत लाइसेंस मिला है.