1. ภาพรวม
ชุด Codelab นี้ (บทแนะนำแบบลงมือปฏิบัติด้วยตนเอง) มีจุดมุ่งหมายเพื่อช่วยให้นักพัฒนา Java ของ Google App Engine (Standard) ปรับแอปให้ทันสมัยโดยแนะนำขั้นตอนการย้ายข้อมูลต่างๆ การทำตามขั้นตอนเหล่านี้จะช่วยให้อัปเดตแอปให้พกพาได้มากขึ้น และตัดสินใจทำคอนเทนเนอร์สำหรับ Cloud Run ซึ่งเป็นบริการในเครือของ Google Cloud ที่ให้บริการโฮสต์คอนเทนเนอร์สำหรับ App Engine และบริการโฮสต์คอนเทนเนอร์อื่นๆ
บทแนะนำนี้จะสอนวิธีสร้างคอนเทนเนอร์แอป App Engine เพื่อนำไปใช้งานกับบริการที่มีการจัดการเต็มรูปแบบของ Cloud Run โดยใช้ Jib Jib ช่วยให้คุณสร้างอิมเมจ Docker ซึ่งเป็นแพลตฟอร์มที่รู้จักกันดีในอุตสาหกรรมสำหรับการพัฒนา จัดส่ง และเรียกใช้แอปพลิเคชันในคอนเทนเนอร์
นอกจากจะสอนขั้นตอนที่จำเป็นในการย้ายจาก App Engine ไปยัง Cloud Run แล้ว คุณยังจะได้เรียนรู้วิธีอัปเกรดแอป App Engine ที่ใช้ Java 8 เป็น Java 17 ด้วย
หากแอปพลิเคชันของคุณใช้บริการที่รวมไว้เดิมของ App Engine หรือฟีเจอร์อื่นๆ ของ App Engine อย่างหนัก เราขอแนะนำให้ย้ายข้อมูลออกจากบริการที่รวมไว้เหล่านั้นหรือแทนที่ฟีเจอร์เหล่านั้นก่อนที่จะย้ายไปยัง Cloud Run หากต้องการเวลาเพิ่มเติมในการตรวจสอบตัวเลือกการย้ายข้อมูลหรือต้องการใช้บริการแบบกลุ่มเดิมต่อไปในตอนนี้ คุณจะเข้าถึงบริการแบบกลุ่มของ App Engine สำหรับ Java 11/17 ได้ต่อไปเมื่ออัปเกรดเป็นรันไทม์เวอร์ชันใหม่กว่า เมื่อแอปของคุณพกพาได้มากขึ้น ให้กลับมาที่ Codelab นี้เพื่อดูวิธีนำวิธีการไปใช้กับแอป
คุณจะได้เรียนรู้วิธีต่อไปนี้
- ใช้ Cloud Shell
- เปิดใช้ Cloud Run, Artifact Registry และ Cloud Build API
- สร้างคอนเทนเนอร์แอปโดยใช้ Jib และ Cloud Build
- ทําให้อิมเมจคอนเทนเนอร์ใช้งานได้กับ Cloud Run
สิ่งที่คุณต้องมี
- โปรเจ็กต์ Google Cloud Platform ที่มีบัญชีสำหรับการเรียกเก็บเงินของ GCP ที่ใช้งานอยู่และเปิดใช้ App Engine
- มีความรู้พื้นฐานเกี่ยวกับคำสั่ง Linux ทั่วไป
- ความรู้พื้นฐานเกี่ยวกับการพัฒนาและการทําให้แอป App Engine ใช้งานได้
- แอป Servlet Java 8 ที่คุณต้องการย้ายข้อมูลไปยัง Java 17 และทําให้ใช้งานได้ใน Cloud Run (อาจเป็นแอปใน App Engine หรือเพียงแค่แหล่งที่มา)
แบบสำรวจ
คุณจะใช้บทแนะนำนี้อย่างไร
คุณจะให้คะแนนประสบการณ์การใช้งาน Java เท่าใด
คุณจะให้คะแนนประสบการณ์การใช้บริการ Google Cloud เท่าใด
2. ฉากหลัง
ระบบแพลตฟอร์มเป็นบริการ (PaaS) เช่น App Engine และ Cloud Functions มอบความสะดวกมากมายให้กับทีมและแอปพลิเคชันของคุณ เช่น การช่วยให้ผู้ดูแลระบบและ DevOps มุ่งเน้นที่การสร้างโซลูชันได้ แพลตฟอร์มแบบไร้เซิร์ฟเวอร์ช่วยให้แอปของคุณปรับขนาดขึ้นได้โดยอัตโนมัติตามต้องการ ลดขนาดลงเหลือ 0 ด้วยการเรียกเก็บเงินแบบจ่ายตามการใช้งานเพื่อช่วยควบคุมต้นทุน และใช้ภาษาการพัฒนาทั่วไปได้หลากหลาย
อย่างไรก็ตาม ความยืดหยุ่นของคอนเทนเนอร์ก็เป็นสิ่งที่น่าสนใจเช่นกัน เนื่องจากเลือกภาษา ไลบรารี และไบนารีใดก็ได้ คอนเทนเนอร์จึงให้ประโยชน์ทั้ง 2 อย่างแก่คุณ นั่นคือความสะดวกของแบบไร้เซิร์ฟเวอร์และความยืดหยุ่นของคอนเทนเนอร์ Cloud Run มีไว้เพื่อสิ่งนี้
การเรียนรู้วิธีใช้ Cloud Run ไม่อยู่ในขอบเขตของ Codelab นี้ แต่จะอยู่ในเอกสารประกอบของ Cloud Run เป้าหมายในที่นี้คือเพื่อให้คุณคุ้นเคยกับวิธีสร้างคอนเทนเนอร์แอป App Engine สำหรับ Cloud Run (หรือบริการอื่นๆ ที่โฮสต์คอนเทนเนอร์) ก่อนดำเนินการต่อ คุณควรทราบว่าประสบการณ์ของผู้ใช้จะแตกต่างออกไปเล็กน้อย
ใน Codelab นี้ คุณจะได้เรียนรู้วิธีสร้างและติดตั้งใช้งานคอนเทนเนอร์ โดยคุณจะได้เรียนรู้วิธีต่อไปนี้
- สร้างคอนเทนเนอร์ให้แอปด้วย Jib
- ย้ายข้อมูลจากการกำหนดค่า 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 จากนั้นไปที่โฟลเดอร์ baseline
ตัวอย่างนี้เป็นแอป Datastore ที่ใช้ Servlet ใน Java 8 ซึ่งมีไว้สำหรับการติดตั้งใช้งานใน App Engine ทำตามวิธีการใน README เกี่ยวกับวิธีเตรียมแอปนี้สำหรับการติดตั้งใช้งาน App Engine
3. (ไม่บังคับ) นำแอปพื้นฐานไปใช้งาน
คุณต้องทำตามขั้นตอนต่อไปนี้ก็ต่อเมื่อต้องการยืนยันว่าแอปทำงานใน App Engine ก่อนที่เราจะย้ายข้อมูลไปยัง Cloud Run
โปรดดูขั้นตอนใน README.md
- ติดตั้ง/ทำความคุ้นเคยกับ
gcloudCLI อีกครั้ง - เริ่มต้น gcloud CLI สำหรับโปรเจ็กต์ด้วย
gcloud init - สร้างโปรเจ็กต์ App Engine ด้วย
gcloud app create - ทำให้แอปตัวอย่างใช้งานได้ใน App Engine
./mvnw package appengine:deploy -Dapp.projectId=$PROJECT_ID
- ยืนยันว่าแอปทำงานใน 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 และต้องการให้คลาสที่คอมไพล์แล้วเข้ากันได้กับ JVM ของ Java 17
2. รวมถึงเว็บเซิร์ฟเวอร์
App Engine และ Cloud Run มีความแตกต่างกันหลายประการที่ควรพิจารณาเมื่อย้ายข้อมูลระหว่าง 2 บริการนี้ ความแตกต่างอย่างหนึ่งคือขณะที่รันไทม์ Java 8 ของ App Engine มีและจัดการเซิร์ฟเวอร์ Jetty สำหรับแอปที่โฮสต์ไว้ แต่ Cloud Run ไม่ได้ทำเช่นนั้น เราจะใช้ Spring Boot เพื่อจัดหาเว็บเซิร์ฟเวอร์และคอนเทนเนอร์ Servlet ให้
เพิ่มทรัพยากร 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 เพื่อลดความแตกต่างในลักษณะการทำงานเริ่มต้นหลังการย้ายข้อมูล นอกจากนี้ เรายังกำหนดค่าเวอร์ชัน 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 Boot
แม้ว่า Spring Boot จะสามารถนำ Servlet กลับมาใช้ใหม่ได้โดยไม่ต้องแก้ไข แต่ก็ต้องมีการกำหนดค่าบางอย่างเพื่อให้ค้นพบได้
สร้าง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. การแพ็กเกจแอปเป็น JAR
แม้ว่าคุณจะสร้างคอนเทนเนอร์ของแอปด้วย Jib โดยเริ่มจาก WAR ได้ แต่การแพ็กเกจแอปเป็น JAR ที่เรียกใช้งานได้จะช่วยให้ทำได้ง่ายขึ้น ซึ่งไม่จำเป็นต้องกำหนดค่ามากนัก โดยเฉพาะอย่างยิ่งสำหรับโปรเจ็กต์ที่ใช้ 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. การย้ายข้อมูลจากการกำหนดค่า บริการ และการอ้างอิงของ App Engine
ดังที่ได้กล่าวไว้ในช่วงต้นของโค้ดแล็บ Cloud Run และ App Engine ออกแบบมาเพื่อมอบประสบการณ์การใช้งานที่แตกต่างกัน ฟีเจอร์บางอย่างที่ App Engine มีให้พร้อมใช้งาน เช่น บริการ Cron และคิวของงาน จะต้องสร้างขึ้นใหม่ด้วยตนเอง และเราจะกล่าวถึงรายละเอียดเพิ่มเติมในโมดูลต่อๆ ไป
แอปตัวอย่างไม่ได้ใช้บริการแบบแพ็กเกจเดิม แต่ผู้ใช้ที่มีแอปที่ใช้บริการดังกล่าวสามารถดูคำแนะนำต่อไปนี้
- การย้ายข้อมูลจากบริการแบบแพ็กเกจเพื่อค้นหาบริการแบบสแตนด์อโลนที่เหมาะสม
- การย้ายข้อมูลไฟล์การกำหนดค่า XML ไปยัง YAML สำหรับผู้ใช้ที่ย้ายข้อมูลไปยังรันไทม์ Java 11/17 ขณะที่ยังคงใช้ 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 ทำตามขั้นตอนเหล่านี้แล้ว ระบบจะดำเนินการดังนี้
- ทำการทดสอบด้วย
./mvnw test - สร้าง พุช และติดแท็กรูปภาพไปยัง Artifact Registry ด้วย Jib
- ทำให้รูปภาพใช้งานได้ใน Cloud Run ด้วย
gcloud run deploy
โปรดทราบว่า ‘visitors' จะส่งไปยัง Cloud Run เป็นชื่อบริการที่ต้องการ ฟีเจอร์–allow-unauthenticatedช่วยให้ผู้ใช้เข้าชมเว็บแอปได้โดยไม่ต้องมีการตรวจสอบสิทธิ์ อย่าลืมแทนที่ PROJECT_ID ด้วยรหัสของโปรเจ็กต์ในcloudbuild.yaml file
จากนั้นเพิ่มการเชื่อมโยงนโยบาย IAM ต่อไปนี้เพื่อให้บัญชีบริการ 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
เมื่อสิ้นสุด Codelab นี้ แอปของคุณควรมีลักษณะเหมือนกับแอปใน java17-and-cloud-run/finish
เพียงเท่านี้ก็เรียบร้อยแล้ว คุณย้ายข้อมูลแอป App Engine ที่เขียนด้วย Java 8 ไปยัง Java 17 และ Cloud Run เรียบร้อยแล้ว และตอนนี้ก็เข้าใจงานที่เกี่ยวข้องเมื่อเปลี่ยนและเลือกตัวเลือกการโฮสต์ได้ชัดเจนขึ้น
6. สรุป/ล้างข้อมูล
ยินดีด้วย คุณได้อัปเกรด คอนเทนเนอร์ ย้ายข้อมูล และแอปของคุณแล้ว ซึ่งเป็นการสิ้นสุดบทแนะนำนี้
จากนี้ ขั้นตอนถัดไปคือการดูข้อมูลเพิ่มเติมเกี่ยวกับฟีเจอร์ความปลอดภัยของ CI/CD และซัพพลายเชนของซอฟต์แวร์ที่พร้อมให้ใช้งานแล้วในตอนนี้ที่คุณสามารถใช้ Cloud Build ในการติดตั้งใช้งานได้
- การสร้างขั้นตอนการบิลด์ที่กำหนดเองด้วย Cloud Build
- การสร้างและจัดการทริกเกอร์บิวด์
- การใช้การสแกนตามต้องการในไปป์ไลน์ Cloud Build
ไม่บังคับ: ล้างข้อมูลและ/หรือปิดใช้บริการ
หากทำให้แอปตัวอย่างใช้งานได้ใน App Engine ระหว่างบทแนะนำนี้ อย่าลืมปิดใช้แอปเพื่อหลีกเลี่ยงการเรียกเก็บเงิน เมื่อพร้อมที่จะไปที่ Codelab ถัดไปแล้ว คุณก็เปิดใช้ฟีเจอร์นี้อีกครั้งได้ ในขณะที่ปิดใช้แอป App Engine แอปจะไม่ได้รับการเข้าชมใดๆ ที่จะทำให้เกิดค่าใช้จ่าย แต่ระบบอาจเรียกเก็บเงินสำหรับการใช้งาน Datastore หากเกินโควต้าฟรี ดังนั้นให้ลบข้อมูลให้เพียงพอเพื่อไม่ให้เกินขีดจำกัดดังกล่าว
ในทางกลับกัน หากคุณไม่ต้องการดำเนินการย้ายข้อมูลต่อและต้องการลบทุกอย่างออกทั้งหมด คุณสามารถลบบริการหรือปิดโปรเจ็กต์ทั้งหมด
7. แหล่งข้อมูลเพิ่มเติม
ปัญหา/ความคิดเห็นเกี่ยวกับ Codelab โมดูลการย้ายข้อมูล App Engine
หากพบปัญหาเกี่ยวกับ Codelab นี้ โปรดค้นหาปัญหาของคุณก่อนที่จะยื่นเรื่อง ลิงก์สำหรับค้นหาและสร้างปัญหาใหม่
แหล่งข้อมูลการย้ายข้อมูล
- ตัวเลือกการย้ายข้อมูลสำหรับการแยกบริการ App Engine
- การตั้งค่าทริกเกอร์บิลด์สำหรับ Cloud Build
- ข้อมูลเพิ่มเติมเกี่ยวกับการย้ายข้อมูลไปยัง Java 11/17
แหล่งข้อมูลออนไลน์
ด้านล่างนี้คือแหล่งข้อมูลออนไลน์ที่อาจเกี่ยวข้องกับบทแนะนำนี้
App Engine
- เอกสารประกอบของ App Engine
- ข้อมูลราคาและโควต้าของ App Engine
- การเปรียบเทียบแพลตฟอร์มรุ่นที่ 1 และรุ่นที่ 2
- การสนับสนุนรันไทม์เวอร์ชันเดิมในระยะยาว
ข้อมูลอื่นๆ เกี่ยวกับระบบคลาวด์
วิดีโอ
- Serverless Migration Station
- Expeditions แบบ Serverless
- ติดตาม Google Cloud Tech
- ติดตาม Google Developers
ใบอนุญาต
ผลงานนี้ได้รับอนุญาตภายใต้สัญญาอนุญาตครีเอทีฟคอมมอนส์สำหรับยอมรับสิทธิของผู้สร้าง (Creative Commons Attribution License) 2.0 แบบทั่วไป