เกี่ยวกับ Codelab นี้
1 ภาพรวม
ชุดโค้ดแล็บ (บทแนะนำแบบฝึกหัดด้วยตนเอง) นี้มีจุดประสงค์เพื่อช่วยให้นักพัฒนาซอฟต์แวร์ Java ของ Google App Engine (มาตรฐาน) ปรับแอปให้ทันสมัยโดยแนะนำขั้นตอนการย้ายข้อมูล เมื่อทำตามขั้นตอนเหล่านี้ คุณจะอัปเดตแอปให้พกพาได้มากขึ้นและตัดสินใจที่จะใช้คอนเทนเนอร์สำหรับ 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
- แอป Servlet ของ Java 8 ที่ต้องการย้ายข้อมูลไปยัง Java 17 และทำให้ใช้งานได้ใน Cloud Run (อาจเป็นแอปใน App Engine หรือแค่ซอร์สโค้ด)
แบบสำรวจ
คุณจะใช้บทแนะนำนี้อย่างไร
คุณจะให้คะแนนประสบการณ์การใช้งาน Java เท่าไร
คุณจะให้คะแนนประสบการณ์การใช้งานบริการ Google Cloud เท่าใด
2 ข้อมูลเบื้องต้น
ระบบแพลตฟอร์มในฐานะบริการ (PaaS) เช่น App Engine และ Cloud Functions มอบความสะดวกมากมายให้กับทีมและแอปพลิเคชันของคุณ เช่น ช่วยให้ผู้ดูแลระบบและนักพัฒนาซอฟต์แวร์สามารถมุ่งเน้นที่การสร้างโซลูชันได้ เมื่อใช้แพลตฟอร์มแบบเซิร์ฟเวอร์เสมือน แอปจะปรับขนาดอัตโนมัติได้ตามต้องการ ปรับขนาดลงเป็น 0 ด้วยการเรียกเก็บเงินแบบจ่ายต่อการใช้งานเพื่อช่วยควบคุมค่าใช้จ่าย และใช้ภาษาการพัฒนาทั่วไปที่หลากหลาย
อย่างไรก็ตาม ความยืดหยุ่นของคอนเทนเนอร์ก็น่าสนใจเช่นกัน ความสามารถในการเลือกภาษา ไลบรารี และไบนารีใดก็ได้ทำให้คอนเทนเนอร์เป็นแพลตฟอร์มที่ให้คุณได้รับสิ่งที่ดีที่สุดจากทั้ง 2 โลก ทั้งความสะดวกของการใช้งานแบบเซิร์ฟเวอร์เลสและความยืดหยุ่นของคอนเทนเนอร์ Cloud Run สร้างขึ้นเพื่อวัตถุประสงค์นี้
การเรียนรู้วิธีใช้ Cloud Run ไม่ได้อยู่ในขอบเขตของ Codelab นี้ ซึ่งอยู่ในเอกสารประกอบ Cloud Run เป้าหมายของเราคือช่วยให้คุณคุ้นเคยกับวิธีบรรจุคอนเทนเนอร์แอป App Engine สำหรับ Cloud Run (หรือบริการอื่นๆ ที่โฮสต์คอนเทนเนอร์) โปรดทราบว่าคุณควรทราบข้อมูลบางอย่างก่อนดำเนินการต่อ โดยเฉพาะอย่างยิ่งประสบการณ์ของผู้ใช้จะแตกต่างกันเล็กน้อย
ในโค้ดแล็บนี้ คุณจะได้เรียนรู้วิธีสร้างและทำให้คอนเทนเนอร์ใช้งานได้ โดยคุณจะได้เรียนรู้วิธีต่อไปนี้
- สร้างคอนเทนเนอร์สำหรับแอปด้วย 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
- ติดตั้ง/ทบทวนการใช้
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 เพื่อจัดหาเว็บเซิร์ฟเวอร์และคอนเทนเนอร์เซิร์ฟเลต
เพิ่มการพึ่งพาต่อไปนี้
<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 จะใช้เซิร์ฟเล็ตซ้ำได้โดยไม่ต้องแก้ไข แต่จะต้องกำหนดค่าบางอย่างเพื่อให้ค้นพบได้
สร้างคลาส 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. การย้ายข้อมูลจากการกำหนดค่า บริการ และทรัพยากร Dependency ของ App Engine
ดังที่ได้กล่าวไว้ในตอนต้นของโค้ดแล็บว่า 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 คอนเทนเนอร์แอปพลิเคชัน
ตอนนี้คุณสามารถทำให้แอปใช้งานได้ใน 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 Flag –allow-unauthenticated
ช่วยให้ผู้ใช้เข้าชมเว็บแอปได้โดยไม่ต้องมีการตรวจสอบสิทธิ์ อย่าลืมแทนที่ PROJECT_ID ด้วยรหัสของโครงการในไฟล์ cloudbuild.yaml
จากนั้นเพิ่มการเชื่อมโยงนโยบาย IAM ต่อไปนี้เพื่ออนุญาตให้บัญชีบริการ Cloud Build เข้าถึงที่เก็บอาร์ติแฟกต์
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 ระหว่างบทแนะนำนี้ อย่าลืมปิดใช้แอปเพื่อหลีกเลี่ยงการเรียกเก็บเงิน เมื่อพร้อมที่จะไปยังโค้ดแล็บถัดไป คุณจะเปิดใช้โค้ดแล็บอีกครั้งได้ เมื่อปิดใช้แอป App Engine ระบบจะไม่เรียกเก็บเงินสำหรับการเข้าชมแอปดังกล่าว แต่อาจเรียกเก็บเงินสำหรับการใช้งาน Datastore หากเกินโควต้าแบบไม่มีค่าใช้จ่าย ดังนั้นให้ลบข้อมูลให้เหลือไม่เกินขีดจำกัดดังกล่าว
ในทางกลับกัน หากไม่ต้องการย้ายข้อมูลต่อและต้องการลบทุกอย่างออกอย่างสมบูรณ์ คุณสามารถลบบริการหรือปิดโปรเจ็กต์ทั้งหมด
7 แหล่งข้อมูลเพิ่มเติม
ปัญหา/ความคิดเห็นเกี่ยวกับ Codelab ของโมดูลการย้ายข้อมูล App Engine
หากมีปัญหาใดๆ เกี่ยวกับ Codelab นี้ โปรดค้นหาปัญหาของคุณก่อนยื่น ลิงก์สำหรับค้นหาและสร้างปัญหาใหม่
แหล่งข้อมูลการย้ายข้อมูล
- ตัวเลือกการย้ายข้อมูลสำหรับการแยกบริการ App Engine
- การตั้งค่าทริกเกอร์บิลด์สําหรับ Cloud Build
- ข้อมูลเพิ่มเติมเกี่ยวกับการย้ายข้อมูลไปยัง Java 11/17
แหล่งข้อมูลออนไลน์
ด้านล่างนี้คือแหล่งข้อมูลออนไลน์ที่อาจเกี่ยวข้องกับบทแนะนำนี้
App Engine
- เอกสารประกอบของ App Engine
- ข้อมูลราคาและโควต้าของ App Engine
- การเปรียบเทียบแพลตฟอร์มรุ่นที่ 1 กับรุ่นที่ 2
- การสนับสนุนระยะยาวสำหรับรันไทม์เดิม
ข้อมูลอื่นๆ เกี่ยวกับระบบคลาวด์
- ระดับ "ฟรีไม่จำกัด" ของ Google Cloud
- Google Cloud CLI (
gcloud
CLI) - เอกสารประกอบทั้งหมดของ Google Cloud
วิดีโอ
- สถานีย้ายข้อมูลแบบ Serverless
- Expeditions แบบ Serverless
- สมัครรับข้อมูลข่าวสารจาก Google Cloud Tech
- สมัครรับข้อมูลใน Google Developers
ใบอนุญาต
ผลงานนี้ได้รับอนุญาตภายใต้สัญญาอนุญาตครีเอทีฟคอมมอนส์สำหรับยอมรับสิทธิของผู้สร้าง (Creative Commons Attribution License) 2.0 ทั่วไป