การย้ายข้อมูลจากแอป 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 อาจเหมาะกับคุณมากกว่าโค้ดแล็บนี้

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

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

สิ่งที่ต้องมี

แบบสำรวจ

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

อ่านอย่างเดียว อ่านและทำแบบฝึกหัดให้เสร็จ

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

มือใหม่ ระดับกลาง เชี่ยวชาญ

คุณจะให้คะแนนประสบการณ์การใช้งานบริการ Google Cloud เท่าใด

ผู้ฝึกหัด ระดับกลาง ผู้ชำนาญ

2. ข้อมูลเบื้องต้น

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

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

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

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

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 และต้องการใช้คลาสที่คอมไพล์แล้วเข้ากันได้กับ JVM ของ Java 17

2. รวมถึงเว็บเซิร์ฟเวอร์

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

สร้างคลาส 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

ดังที่ได้กล่าวไว้ในตอนต้นของโค้ดแล็บว่า 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 จะดำเนินการต่อไปนี้

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

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

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

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

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

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

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

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

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

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

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

แหล่งข้อมูลการย้ายข้อมูล

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

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

App Engine

ข้อมูลอื่นๆ ในระบบคลาวด์

วิดีโอ

ใบอนุญาต

ผลงานนี้ได้รับอนุญาตภายใต้สัญญาอนุญาตครีเอทีฟคอมมอนส์สำหรับยอมรับสิทธิของผู้สร้าง (Creative Commons Attribution License) 2.0 ทั่วไป