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

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

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

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

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

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

FROM eclipse-temurin

ARG JAR_FILE=JAR_FILE_MUST_BE_SPECIFIED_AS_BUILD_ARG

COPY ${JAR_FILE} app.jar

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

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

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

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

यह कमांड चलाएं:

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

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

  • जगह: आपके रिपॉज़िटरी (डेटा स्टोर करने की जगह) के लिए क्षेत्रीय या एक से ज़्यादा-क्षेत्रीय जगह.
  • PROJECT_ID: आपका Cloud प्रोजेक्ट आईडी.
  • REPOSITORY: Artifact Registry के डेटा स्टोर करने की जगह का नाम.
  • IMAGE_NAME: आपके कंटेनर इमेज का नाम.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

App Engine

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

वीडियो

लाइसेंस

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