การย้ายข้อมูลจากแอป Java ของ Google App Engine ไปยัง Cloud Run ด้วย Buildpack

1. ภาพรวม

Codelab ชุดนี้ (บทแนะนำที่เรียนรู้ได้ด้วยตนเอง) มีเป้าหมายเพื่อช่วยนักพัฒนาซอฟต์แวร์ของ Google App Engine (มาตรฐาน) Java ปรับปรุงแอปให้ทันสมัย โดยแนะนำขั้นตอนการย้ายข้อมูลต่างๆ การทำตามขั้นตอนเหล่านี้จะช่วยให้คุณอัปเดตแอปให้พกพาสะดวกมากขึ้นได้ และตัดสินใจสร้างคอนเทนเนอร์สำหรับ Cloud Run ซึ่งเป็นบริการในเครือของคอนเทนเนอร์โฮสต์ของ Google Cloud ไปยัง App Engine และบริการโฮสต์คอนเทนเนอร์อื่นๆ

บทแนะนำนี้จะสอนวิธีสร้างคอนเทนเนอร์แอป App Engine สำหรับการทำให้ใช้งานได้กับบริการที่มีการจัดการครบวงจรของ Cloud Run โดยใช้ Buildpack Buildpack เป็นโครงการ CNCF ที่ช่วยให้คุณนำแอปจากซอร์สโค้ดไปยังรูปภาพที่สามารถพกพาได้ง่ายซึ่งสามารถทำงานบนระบบคลาวด์ใดก็ได้

นอกเหนือจากการสอนขั้นตอนที่จำเป็นในการย้ายจาก App Engine ไปยัง Cloud Run แล้ว คุณยังจะได้เรียนรู้วิธีอัปเกรดแอป Java 8 App Engine เป็น Java 17

หากแอปพลิเคชันที่คุณต้องการย้ายข้อมูลใช้งาน App Engine แบบกลุ่มแบบเดิมหรือฟีเจอร์เฉพาะอื่นๆ ของ App Engine มาก คู่มือการเข้าถึงบริการแบบกลุ่มของ App Engine สำหรับ Java 11/17 อาจเหมาะสมกว่า Codelab

คุณจะได้เรียนรู้วิธีต่อไปนี้

  • ใช้ Cloud Shell
  • เปิดใช้ Cloud Run, Artifact Registry และ Cloud Build API
  • สร้างคอนเทนเนอร์ให้กับแอปโดยใช้ Buildpack บน Cloud Build
  • ทำให้อิมเมจคอนเทนเนอร์ใช้งานได้กับ Cloud Run

สิ่งที่คุณต้องมี

แบบสำรวจ

คุณจะใช้บทแนะนำนี้อย่างไร

อ่านเท่านั้น อ่านและทำแบบฝึกหัด

คุณจะให้คะแนนประสบการณ์การใช้งาน Java อย่างไร

มือใหม่ ระดับกลาง ผู้ชำนาญ

คุณจะให้คะแนนความพึงพอใจในการใช้บริการ Google Cloud อย่างไร

มือใหม่ ระดับกลาง ผู้ชำนาญ

2. ที่มา

ระบบ PaaS อย่าง App Engine และ Cloud Functions ให้ความสะดวกมากมายแก่ทีมและแอปพลิเคชันของคุณ เช่น การทำให้ SysAdmins และ Devops สามารถมุ่งเน้นไปที่การสร้างโซลูชันได้ ด้วยแพลตฟอร์มที่ไม่จำกัด แอปของคุณสามารถปรับขนาดอัตโนมัติได้ตามต้องการ ลดขนาดเป็น 0 ด้วยการเรียกเก็บเงินแบบจ่ายต่อการใช้งานเพื่อช่วยควบคุมต้นทุน และใช้ภาษาในการพัฒนาทั่วไปที่หลากหลาย

อย่างไรก็ตาม ความยืดหยุ่นของคอนเทนเนอร์ก็น่าสนใจเช่นกัน คอนเทนเนอร์มีความสามารถในการเลือกภาษา ไลบรารี และไบนารีใดก็ได้ คุณจึงได้รับประโยชน์สูงสุดจากทั้ง 2 ด้าน ซึ่งก็คือความสะดวกสบายในการใช้งานแบบ Serverless และความยืดหยุ่นของคอนเทนเนอร์ และนี่คือหน้าที่ของ Google Cloud Run

การเรียนรู้วิธีใช้ Cloud Run ไม่ได้อยู่ในขอบเขตของ Codelab นี้ ที่อยู่ในเอกสารประกอบเกี่ยวกับ Cloud Run เป้าหมายนี้มีไว้เพื่อให้คุณทำความคุ้นเคยกับวิธีสร้างคอนเทนเนอร์แอป App Engine สำหรับ Cloud Run (หรือบริการอื่นๆ ที่โฮสต์บนคอนเทนเนอร์) มี 2-3 อย่างที่คุณควรทราบก่อนที่จะดำเนินการต่อ หลักๆ แล้วประสบการณ์ของผู้ใช้ของคุณจะแตกต่างออกไปเล็กน้อย

ใน Codelab นี้ คุณจะได้เรียนรู้วิธีการสร้างและทำให้คอนเทนเนอร์ใช้งานได้ คุณจะได้เรียนรู้วิธีสร้างคอนเทนเนอร์แอปด้วย Buildpacks, ย้ายข้อมูลจากการกำหนดค่า App Engine และกำหนดขั้นตอนบิลด์สำหรับ Cloud Build ซึ่งรวมถึงการย้ายออกจากฟีเจอร์บางอย่างของ App Engine หากคุณไม่ต้องการปฏิบัติตามเส้นทางนี้ คุณยังคงอัปเกรดเป็นรันไทม์ Java 11/17 ได้ในขณะที่เก็บแอปไว้ใน App Engine แทน

3. การตั้งค่า/งานล่วงหน้า

1. สร้างโปรเจ็กต์

ในบทแนะนำนี้ คุณจะใช้แอปตัวอย่างจากที่เก็บ appengine-java-migration-samples ในโปรเจ็กต์ใหม่ ตรวจสอบว่าโปรเจ็กต์มีบัญชีสำหรับการเรียกเก็บเงินที่ใช้งานอยู่

หากคุณตั้งใจที่จะย้ายแอป App Engine ที่มีอยู่ไปยัง Cloud Run คุณสามารถใช้แอปดังกล่าวเพื่อติดตามเนื้อหาแทนได้

เรียกใช้คำสั่งต่อไปนี้เพื่อเปิดใช้ API ที่จำเป็นสำหรับโปรเจ็กต์ของคุณ

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

2. รับแอปตัวอย่างพื้นฐาน

โคลนแอปตัวอย่างในเครื่องของคุณเองหรือใน Cloud Shell จากนั้นไปที่โฟลเดอร์พื้นฐาน

ตัวอย่างนี้เป็นแอป Datastore แบบ Java 8 แบบ Servlet ที่มีไว้เพื่อทำให้ใช้งานได้ใน App Engine ทำตามวิธีการใน README เกี่ยวกับวิธีเตรียมแอปนี้สำหรับการทำให้ App Engine ใช้งานได้

3. (ไม่บังคับ) ทำให้แอปพื้นฐานใช้งานได้

ข้อมูลต่อไปนี้มีความจำเป็นเฉพาะเมื่อคุณต้องการยืนยันว่าแอปทำงานได้บน App Engine ก่อนที่เราจะย้ายข้อมูลไปยัง Cloud Run เท่านั้น

โปรดดูขั้นตอนใน README.md

  1. ติดตั้ง/ทำความคุ้นเคยกับ gcloud CLI
  2. เริ่มต้น gcloud CLI สำหรับโปรเจ็กต์ของคุณด้วย gcloud init
  3. สร้างโปรเจ็กต์ App Engine ด้วย gcloud app create
  4. ทำให้แอปตัวอย่างใช้งานได้กับ App Engine
./mvnw package appengine:deploy -Dapp.projectId=$PROJECT_ID
  1. ยืนยันว่าแอปทำงานบน App Engine ได้โดยไม่มีปัญหา

4. สร้างที่เก็บ Artifact Registry

หลังจากสร้างคอนเทนเนอร์แอปแล้ว จะต้องมีพื้นที่สำหรับพุชและจัดเก็บรูปภาพ วิธีที่แนะนำในการจัดการกับเรื่องนี้บน Google Cloud คือการใช้ Artifact Registry

สร้างที่เก็บชื่อ migration ด้วย gcloud ดังนี้

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 แบบเดิมมากเกินไป เราขอแนะนำให้เข้าถึงบริการเหล่านั้นต่อไปขณะที่อัปเกรดเป็นรันไทม์ใหม่ Codelab นี้จะสาธิตเส้นทางการย้ายข้อมูลสำหรับแอปพลิเคชันที่ใช้บริการแบบสแตนด์อโลนอยู่แล้ว หรืออาจเปลี่ยนโครงสร้างภายในโค้ดเพื่อดำเนินการดังกล่าวได้

1. การอัปเกรดเป็น Java 17

หากแอปของคุณใช้ Java 8 ให้ลองอัปเกรดเป็นตัวเลือก LTS รุ่นที่ใหม่กว่า เช่น 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 กับ Cloud Run ความแตกต่างอย่างหนึ่งคือขณะที่รันไทม์ Java 8 ของ App Engine จัดหาและจัดการเซิร์ฟเวอร์ Jetty สำหรับแอปที่โฮสต์นั้น Cloud Run ไม่ได้ทำเช่นนั้น เราจะใช้ Spring Boot ในการจัดเตรียมเว็บเซิร์ฟเวอร์และคอนเทนเนอร์ของเซิร์ฟเล็ต

เพิ่มทรัพยากร Dependency ต่อไปนี้

<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 จะใช้เซิร์ฟเล็ตซ้ำได้โดยไม่ต้องแก้ไข แต่จะต้องมีการกำหนดค่าบางอย่างเพื่อให้ค้นพบได้

สร้างคลาส MigratedServletApplication.java ต่อไปนี้ในแพ็กเกจ com.example.appengine

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 เป็นลักษณะการทำงานเริ่มต้น

นำแท็ก packaging ในไฟล์ pom.xml ออก:

<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. การย้ายข้อมูลจากการกำหนดค่า บริการ และทรัพยากร Dependency ของ App Engine

ดังที่กล่าวในตอนต้นของ Codelab ว่า Cloud Run และ App Engine ได้รับการออกแบบมาเพื่อมอบประสบการณ์ที่แตกต่างกันให้กับผู้ใช้ ฟีเจอร์บางอย่างที่ App Engine มอบให้ให้ใช้งานได้ทันที เช่น บริการ Cron และ Task Queue จะต้องสร้างใหม่ด้วยตนเอง โดยจะอธิบายรายละเอียดเพิ่มเติมในโมดูลต่อๆ ไป

แอปตัวอย่างไม่ได้ใช้ประโยชน์จากบริการแบบแพ็กเกจแบบเดิม แต่ผู้ใช้ที่มีแอปจะสามารถดูคำแนะนำต่อไปนี้

เนื่องจากคุณจะทำให้ใช้งานได้กับ 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 อยู่เบื้องหลังเพื่อมอบประสบการณ์การติดตั้งใช้งานโดยไม่ต้องสัมผัส โปรดทราบว่าหากต้องการใช้ฟีเจอร์นี้ คุณจะต้องมีบัญชีที่มีสิทธิ์ต่อไปนี้อย่างน้อย 1 สิทธิ์ และปฏิบัติตามขั้นตอนการตั้งค่าสภาพแวดล้อมเหล่านี้ หรือใช้ Cloud Shell

เมื่อมีข้อกำหนดเบื้องต้นเหล่านั้นแล้ว ให้เรียกใช้สิ่งต่อไปนี้จากไดเรกทอรีต้นทาง

gcloud run deploy SERVICE --source .

ระบบจะแจ้งให้คุณดำเนินการสิ่งต่างๆ ระหว่างเรียกใช้คำสั่งปรับใช้ เช่น

  • การระบุตำแหน่งซอร์สโค้ด
  • การระบุชื่อบริการ
  • กำลังเปิดใช้ Cloud Run API
  • การเลือกภูมิภาคของคุณ

หลังจากตอบสนองต่อข้อความแจ้งเหล่านั้นแล้ว กระบวนการติดตั้งใช้งานและทำให้ใช้งานได้จะเริ่มขึ้น ซึ่งระหว่างนั้น Cloud Build จะดำเนินการต่อไปนี้

  • สร้างไฟล์ ZIP และบันทึกแหล่งที่มาในที่เก็บข้อมูล Cloud Storage
  • ใช้บิลด์ของ Cloud Native Computing Foundation ในเบื้องหลังเพื่อสร้างอิมเมจ
  • สร้างรีจิสทรีเพื่อจัดเก็บอิมเมจคอนเทนเนอร์ที่เป็นผลลัพธ์ (หากยังไม่มี)
  • และสร้างบริการ Cloud Run เพื่อโฮสต์แอปของคุณ (หากยังไม่มี)

เมื่อสร้างและติดตั้งใช้งานเสร็จสมบูรณ์แล้ว คุณควรได้รับข้อความอธิบายว่าการแก้ไขใหม่พร้อมใช้งานแล้ว และมีการเข้าชม 100%

6. สรุป/ล้างข้อมูล

ขอแสดงความยินดี คุณได้อัปเกรด สร้างคอนเทนเนอร์ ย้ายข้อมูล และย้ายข้อมูลแอปแล้ว ซึ่งได้จบบทแนะนำนี้

ขั้นตอนถัดไปคือการศึกษาข้อมูลเพิ่มเติมเกี่ยวกับฟีเจอร์ CI/CD และซัพพลายเชนของซอฟต์แวร์ที่เข้าถึงได้แล้วตอนนี้ซึ่งทำให้ใช้งานได้ด้วย Cloud Build แล้ว

ไม่บังคับ: ล้างข้อมูลและ/หรือปิดใช้บริการ

หากคุณทำให้แอปตัวอย่างใช้งานได้ใน App Engine ระหว่างบทแนะนำนี้ อย่าลืมปิดใช้แอปเพื่อหลีกเลี่ยงการเรียกเก็บเงิน เมื่อพร้อมที่จะย้ายไปยัง Codelab ถัดไปแล้ว คุณก็เปิดใช้อีกครั้งได้ ในขณะที่แอป App Engine ปิดใช้อยู่ แอปเหล่านี้จะไม่ได้รับการเข้าชมใดๆ ที่มีค่าใช้จ่าย อย่างไรก็ตาม การใช้ Datastore อาจเรียกเก็บเงินได้หากเกินโควต้าฟรี ดังนั้นโปรดลบออกให้ไม่เกินจำนวนที่จำกัดไว้

ในทางกลับกัน หากไม่ต้องการย้ายข้อมูลต่อและต้องการลบทุกอย่างออกอย่างสมบูรณ์ คุณสามารถลบบริการหรือปิดโปรเจ็กต์ทั้งหมด

7. แหล่งข้อมูลเพิ่มเติม

ปัญหา/ข้อเสนอแนะเกี่ยวกับ Codelab ของโมดูลการย้ายข้อมูล App Engine

หากมีปัญหาใดๆ เกี่ยวกับ Codelab นี้ โปรดค้นหาปัญหาของคุณก่อนยื่น ลิงก์สำหรับค้นหาและสร้างปัญหาใหม่

แหล่งข้อมูลสำหรับการย้ายข้อมูล

แหล่งข้อมูลออนไลน์

ด้านล่างนี้คือแหล่งข้อมูลออนไลน์ที่อาจเกี่ยวข้องกับบทแนะนำนี้

App Engine

ข้อมูลอื่นๆ เกี่ยวกับระบบคลาวด์

วิดีโอ

ใบอนุญาต

ผลงานนี้ได้รับอนุญาตภายใต้ใบอนุญาตทั่วไปครีเอทีฟคอมมอนส์แบบระบุแหล่งที่มา 2.0