1. ภาพรวม
Codelab ชุดนี้ (บทแนะนำที่เรียนรู้ได้ด้วยตนเอง) มีเป้าหมายเพื่อช่วยนักพัฒนาซอฟต์แวร์ของ Google App Engine (มาตรฐาน) Java ปรับปรุงแอปให้ทันสมัย โดยแนะนำขั้นตอนการย้ายข้อมูลต่างๆ การทำตามขั้นตอนเหล่านี้จะช่วยให้คุณอัปเดตแอปให้พกพาสะดวกมากขึ้นได้ และตัดสินใจสร้างคอนเทนเนอร์สำหรับ Cloud Run ซึ่งเป็นบริการในเครือของคอนเทนเนอร์โฮสต์ของ Google Cloud ไปยัง App Engine และบริการโฮสต์คอนเทนเนอร์อื่นๆ
บทแนะนำนี้จะสอนวิธีสร้างคอนเทนเนอร์แอป App Engine สำหรับการทำให้ใช้งานได้กับบริการที่มีการจัดการครบวงจรของ Cloud Run โดยใช้ Jib Jib ช่วยให้คุณสามารถสร้างอิมเมจ Docker ซึ่งเป็นแพลตฟอร์มที่เป็นที่รู้จักในอุตสาหกรรมสำหรับการพัฒนา จัดส่ง และเรียกใช้แอปพลิเคชันในคอนเทนเนอร์
นอกเหนือจากการสอนขั้นตอนที่จำเป็นในการย้ายจาก App Engine ไปยัง Cloud Run แล้ว คุณยังจะได้เรียนรู้วิธีอัปเกรดแอป Java 8 App Engine เป็น 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 ใช้งานได้
- แอปเซิร์ฟเล็ต Java 8 ที่คุณต้องการย้ายข้อมูลไปยัง Java 17 และทำให้ใช้งานได้ใน Cloud Run (อาจเป็นแอปใน App Engine หรือต้นทางเท่านั้น)
แบบสำรวจ
คุณจะใช้บทแนะนำนี้อย่างไร
คุณจะให้คะแนนประสบการณ์การใช้งาน Java อย่างไร
คุณจะให้คะแนนความพึงพอใจในการใช้บริการ Google Cloud อย่างไร
2. ที่มา
ระบบ Platform as a Service (PaaS) อย่าง App Engine และ Cloud Functions ให้ความสะดวกมากมายแก่ทีมและแอปพลิเคชันของคุณ เช่น การทำให้ SysAdmins และ Devops สามารถมุ่งเน้นไปที่การสร้างโซลูชันได้ ด้วยแพลตฟอร์มที่ไม่จำกัด แอปของคุณสามารถปรับขนาดอัตโนมัติได้ตามต้องการ ลดขนาดเป็น 0 ด้วยการเรียกเก็บเงินแบบจ่ายต่อการใช้งานเพื่อช่วยควบคุมต้นทุน และใช้ภาษาในการพัฒนาทั่วไปที่หลากหลาย
อย่างไรก็ตาม ความยืดหยุ่นของคอนเทนเนอร์ก็น่าสนใจเช่นกัน คอนเทนเนอร์มีความสามารถในการเลือกภาษา ไลบรารี และไบนารีใดก็ได้ คุณจึงได้รับประโยชน์สูงสุดจากทั้ง 2 ด้าน ซึ่งก็คือความสะดวกสบายในการใช้งานแบบ Serverless และความยืดหยุ่นของคอนเทนเนอร์ นี่คือข้อมูลเกี่ยวกับ Cloud Run
การเรียนรู้วิธีใช้ Cloud Run ไม่ได้อยู่ในขอบเขตของ Codelab นี้ ที่อยู่ในเอกสารประกอบเกี่ยวกับ Cloud Run เป้าหมายนี้มีไว้เพื่อให้คุณทำความคุ้นเคยกับวิธีสร้างคอนเทนเนอร์แอป App Engine สำหรับ Cloud Run (หรือบริการอื่นๆ ที่โฮสต์บนคอนเทนเนอร์) มี 2-3 อย่างที่คุณควรทราบก่อนที่จะดำเนินการต่อ หลักๆ แล้วประสบการณ์ของผู้ใช้ของคุณจะแตกต่างออกไปเล็กน้อย
ใน 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 จากนั้นไปที่โฟลเดอร์พื้นฐาน
ตัวอย่างนี้เป็นแอป Datastore แบบ Java 8 แบบ Servlet ที่มีไว้เพื่อทำให้ใช้งานได้ใน App Engine ทำตามวิธีการใน README เกี่ยวกับวิธีเตรียมแอปนี้สำหรับการทำให้ App Engine ใช้งานได้
3. (ไม่บังคับ) ทำให้แอปพื้นฐานใช้งานได้
ข้อมูลต่อไปนี้มีความจำเป็นเฉพาะเมื่อคุณต้องการยืนยันว่าแอปทำงานได้บน App Engine ก่อนที่เราจะย้ายข้อมูลไปยัง Cloud Run เท่านั้น
โปรดดูขั้นตอนใน README.md
- ติดตั้ง/ทำความคุ้นเคยกับ
gcloud
CLI - เริ่มต้น 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 และต้องการให้คลาสที่คอมไพล์ดังกล่าวใช้งานได้กับ 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 เพื่อลดความแตกต่างของลักษณะการทำงานเริ่มต้นหลังจากการย้ายข้อมูล นอกจากนี้เรายังกำหนดค่าเวอร์ชัน 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 จะใช้เซิร์ฟเล็ตซ้ำได้โดยไม่ต้องแก้ไข แต่จะต้องมีการกำหนดค่าบางอย่างเพื่อให้ค้นพบได้
สร้างคลาส 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 นับตั้งแต่สงคราม แต่จะง่ายขึ้นหากคุณจัดแพ็กเกจแอปเป็น 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. การย้ายข้อมูลจากการกำหนดค่า บริการ และทรัพยากร Dependency ของ App Engine
ดังที่กล่าวในตอนต้นของ Codelab ว่า Cloud Run และ App Engine ได้รับการออกแบบมาเพื่อมอบประสบการณ์ที่แตกต่างกันให้กับผู้ใช้ ฟีเจอร์บางอย่างที่ App Engine มอบให้ให้ใช้งานได้ทันที เช่น บริการ Cron และ Task Queue จะต้องสร้างใหม่ด้วยตนเอง โดยจะอธิบายรายละเอียดเพิ่มเติมในโมดูลต่อๆ ไป
แอปตัวอย่างไม่ได้ใช้ประโยชน์จากบริการแบบแพ็กเกจแบบเดิม แต่ผู้ใช้ที่มีแอปจะสามารถดูคำแนะนำต่อไปนี้
- การย้ายข้อมูลจากบริการที่รวมอยู่ในแพ็กเกจเพื่อค้นหาบริการแบบสแตนด์อโลนที่เหมาะสม
- การย้ายข้อมูลไฟล์การกำหนดค่า 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. แอปพลิเคชัน Containerize
ในจุดนี้ คุณสามารถทำให้แอปใช้งานได้กับ 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
ถัดไป ให้เพิ่มการเชื่อมโยงนโยบาย 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
เพียงเท่านี้ก็เรียบร้อยแล้ว คุณย้ายข้อมูลแอป Java 8 App Engine ไปยัง 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
- การเปรียบเทียบกับ แพลตฟอร์มรุ่นที่ 2
- การรองรับรันไทม์เดิมในระยะยาว
ข้อมูลอื่นๆ เกี่ยวกับระบบคลาวด์
- Google Cloud "ฟรีไม่จำกัดเวลา" ระดับ
- Google Cloud CLI (
gcloud
CLI) - เอกสารประกอบทั้งหมดของ Google Cloud
วิดีโอ
- สถานีย้ายข้อมูลแบบ Serverless
- การสำรวจแบบ Serverless
- สมัครใช้บริการ Google Cloud Tech
- สมัครใช้บริการ Google Developers
ใบอนุญาต
ผลงานนี้ได้รับอนุญาตภายใต้ใบอนุญาตทั่วไปครีเอทีฟคอมมอนส์แบบระบุแหล่งที่มา 2.0