หน้านี้ได้รับการแปลโดย Cloud Translation API

โมดูล 11: การย้ายข้อมูลจาก Google App Engine ไปยัง Cloud Functions

1. ภาพรวม

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

มีบางสถานการณ์ที่คุณไม่มี "ทั้งแอป" เพื่อกำหนดให้ใช้ทรัพยากรของ App Engine หรือ Cloud Run หากโค้ดมีเฉพาะ Microservice หรือฟังก์ชันอย่างง่าย Cloud Functions น่าจะเหมาะสมกว่า Codelab นี้จะสอนวิธีย้ายข้อมูลแอป App Engine แบบง่าย (หรือแยกแอปขนาดใหญ่ออกเป็น Microservice จำนวนมาก) และทำให้ใช้งานได้กับ Cloud Functions ซึ่งเป็นแพลตฟอร์มแบบ Serverless อีกแพลตฟอร์มหนึ่งที่สร้างขึ้นมาโดยเฉพาะสำหรับกรณีการใช้งานเช่นนี้

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

ใช้ Cloud Shell
เปิดใช้ Google Cloud Translation API
ตรวจสอบสิทธิ์คำขอ API
แปลงแอป App Engine ขนาดเล็กเพื่อให้ทำงานบน Cloud Functions
ทำให้โค้ดใช้งานได้กับ Cloud Functions

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

โปรเจ็กต์ Google Cloud Platform ที่มีบัญชีสำหรับการเรียกเก็บเงิน GCP ที่ใช้งานอยู่
ทักษะพื้นฐานเรื่อง Python
ความรู้เกี่ยวกับคำสั่งทั่วไปของ Linux
ความรู้พื้นฐานเกี่ยวกับการพัฒนาและการทำให้แอป App Engine ใช้งานได้
แอปโมดูล 2 Cloud NDB Python 3 App Engine ที่ใช้งานได้
แนะนำ: ทำตาม Codelab โมดูล 2 ให้เสร็จสมบูรณ์ รวมถึงขั้นตอนโบนัสของการย้ายแอปจาก Python 2 เป็น 3

แบบสำรวจ

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

อ่านเท่านั้น

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

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

มือใหม่

ระดับกลาง

ผู้ชำนาญ

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

มือใหม่

ระดับกลาง

ผู้ชำนาญ

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

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

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

Cloud Functions มีไว้เพื่อทำให้โค้ดส่วนเล็กๆ ใช้งานได้ซึ่งมีคุณสมบัติดังนี้

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

นอกจากนี้ คุณยังสามารถใช้ Cloud Functions เพื่อแยกแอปพลิเคชันขนาดใหญ่แบบโมโนลิธเป็น Microservice จำนวนมาก โดยแต่ละไมโครเซอร์วิสได้โดยใช้ฐานข้อมูลทั่วไปที่แชร์กัน เช่น Cloud Firestore หรือ Cloud SQL และหากต้องการให้ฟังก์ชันหรือ Microservice สร้างคอนเทนเนอร์และดำเนินการแบบ Serverless บน Cloud Run คุณก็ทำได้เช่นกัน

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

การตั้งค่า/งานล่วงหน้า
นำไฟล์การกำหนดค่าออก
แก้ไขไฟล์แอปพลิเคชัน

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

Codelab นี้เริ่มต้นด้วยเวอร์ชัน Python 3 ของแอปตัวอย่าง Cloud NDB App Engine โมดูล 2 เนื่องจาก Cloud Functions ไม่รองรับ Python 2 ก่อนอื่น ให้ตั้งค่าโปรเจ็กต์ รับโค้ด แล้วทำให้แอปพื้นฐานใช้งานได้เพื่อยืนยันว่าเราเริ่มต้นจากโค้ดที่ใช้งานได้

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

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

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

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

ไม่ว่าคุณจะใช้โค้ดของคุณเองหรือของเรา โค้ดโมดูล 2 Python 3 คือส่วนที่เราจะเริ่มดำเนินการ Codelab ของโมดูล 11 นี้จะแนะนำคุณเกี่ยวกับแต่ละขั้นตอน สรุปด้วยโค้ดที่คล้ายคลึงกับสิ่งที่อยู่ในโฟลเดอร์ที่เก็บของโมดูล 11 (FINISH)

START: โค้ดโมดูล 2 (3.x [โฟลเดอร์ที่เก็บโมดูล 2b])
FINISH: โค้ดโมดูล 11 (3.x)
ทั้งที่เก็บ (เพื่อโคลนหรือดาวน์โหลด ZIP)

ไดเรกทอรีของไฟล์เริ่มต้น Python 3 โมดูล 2 (ของคุณหรือของเรา) ควรมีลักษณะดังนี้

$ ls
README.md               main.py                 templates
app.yaml                requirements.txt

3. (อีกครั้ง) ทำให้แอปพื้นฐานใช้งานได้

ขั้นตอนก่อนการทำงานที่เหลือของคุณที่ต้องดำเนินการตอนนี้มีดังนี้

ทำความคุ้นเคยกับเครื่องมือบรรทัดคำสั่ง gcloud
ทำให้แอปตัวอย่างใช้งานได้อีกครั้งกับ gcloud app deploy
ยืนยันว่าแอปทำงานบน App Engine โดยไม่มีปัญหา

เมื่อดำเนินการตามขั้นตอนเหล่านั้นเรียบร้อยแล้ว คุณก็พร้อมที่จะแปลงเป็น Cloud Function แล้ว

4. นำไฟล์การกำหนดค่าออก

ไฟล์ app.yaml เป็นอาร์ติแฟกต์ App Engine ที่ไม่ได้ใช้กับ Cloud Functions โปรดลบทันที หากคุณไม่ทำตามหรือลืมดำเนินการนี้ ก็ไม่เป็นอันตรายเนื่องจาก Cloud Functions ไม่มีการใช้งาน นี่เป็นการเปลี่ยนแปลงการกำหนดค่าเพียงอย่างเดียวเนื่องจาก requirements.txt ยังคงเหมือนกับจากโมดูล 2

หากคุณพอร์ตแอป Python 2 App Engine ไปยัง Python 3 ด้วย ให้ลบ appengine_config.py และโฟลเดอร์ lib หากมี เป็นอาร์ติแฟกต์ App Engine ที่ไม่ได้ใช้ในรันไทม์ของ Python 3

5. แก้ไขไฟล์แอปพลิเคชัน

มีไฟล์แอปพลิเคชันเพียงไฟล์เดียวคือ main.py ดังนั้นการเปลี่ยนแปลงที่จำเป็นทั้งหมดในการย้ายไปยัง Cloud Functions จะเกิดขึ้นในไฟล์นี้

การนำเข้า

เนื่องจากเราจะทำงานกับฟังก์ชันเท่านั้น จึงไม่จำเป็นต้องใช้เฟรมเวิร์กเว็บแอปพลิเคชัน อย่างไรก็ตาม เมื่อมีการเรียกใช้ Cloud Functions แบบ Python เพื่อความสะดวก ระบบจะส่งออบเจ็กต์คำขอผ่านออบเจ็กต์คำขอโดยอัตโนมัติเพื่อให้โค้ดของคุณใช้งานได้ตามต้องการ (ทีม Cloud Functions เลือกให้เป็นออบเจ็กต์คำขอ Flask ที่ส่งไปยังฟังก์ชันของคุณ)

เนื่องจากเฟรมเวิร์กเว็บไม่ได้เป็นส่วนหนึ่งของ Cloud Functions จึงไม่มีการนำเข้าจาก Flask เว้นแต่ว่าแอปของคุณจะใช้ฟีเจอร์ Flask อื่นๆ กรณีนี้เกิดขึ้นได้จริงเนื่องจากการแสดงผลเทมเพลตยังคงเกิดขึ้นหลังจากการแปลงเป็นฟังก์ชัน ซึ่งหมายความว่ายังคงต้องมีการเรียกใช้ flask.render_template() ดังนั้นจึงยังคงต้องมีการนําเข้าจาก Flask ไม่มีเฟรมเวิร์กเว็บหมายความว่าไม่จำเป็นต้องสร้างอินสแตนซ์แอป Flask ดังนั้นให้ลบ app = Flask(__name__) ออก โค้ดของคุณมีลักษณะดังนี้ ก่อนและหลังทำการเปลี่ยนแปลง

ก่อนหน้า:

from flask import Flask, render_template, request
from google.cloud import ndb

app = Flask(__name__)
ds_client = ndb.Client()

หลัง:

from flask import render_template
from google.cloud import ndb

ds_client = ndb.Client()

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

อัปเดตลายเซ็นของฟังก์ชันของตัวแฮนเดิลหลัก

การเปลี่ยนแปลงที่จำเป็นในลายเซ็นของฟังก์ชันมีดังนี้

ระบบจะไม่ใช้ Flask อีกหลังจากแปลงแอปเป็น Cloud Function แล้ว โปรดนำเครื่องมือตกแต่งเส้นทางออก
Cloud Functions จะส่งออบเจ็กต์ Request ของ Flask เป็นพารามิเตอร์โดยอัตโนมัติ ดังนั้นคุณจึงสร้างตัวแปรให้กับออบเจ็กต์ดังกล่าว ในแอปตัวอย่าง เราจะตั้งชื่อว่า request
ต้องตั้งชื่อ Cloud Functions ที่ทำให้ใช้งานได้แล้ว ตัวแฮนเดิลหลักของเราได้รับการตั้งชื่ออย่างเหมาะสม root() ใน App Engine เพื่ออธิบายว่าตัวแฮนเดิลหลักคืออะไร (ตัวแฮนเดิลแอปพลิเคชันรูท) คุณอาจไม่ค่อยสนใจใช้ชื่อนั้นในฐานะ Cloud Function แต่เราจะทำให้ Cloud Function ใช้งานได้ด้วยชื่อ visitme แทน ดังนั้นจึงควรใช้ชื่อดังกล่าวเป็นชื่อฟังก์ชัน Python ด้วย ในทำนองเดียวกัน ในโมดูล 4 และ 5 เราตั้งชื่อบริการ Cloud Run visitme ด้วย

ต่อไปนี้คือข้อมูลก่อนและหลังการอัปเดต

ก่อนหน้า:

@app.route('/')
def root():
    'main application (GET) handler'
    store_visit(request.remote_addr, request.user_agent)
    visits = fetch_visits(10)
    return render_template('index.html', visits=visits)

หลัง:

def visitme(request):
    'main application (GET) handler'
    store_visit(request.remote_addr, request.user_agent)
    visits = fetch_visits(10)
    return render_template('index.html', visits=visits)

การอัปเดตที่จำเป็นทั้งหมดก็มีเพียงเท่านี้ โปรดทราบว่าการเปลี่ยนแปลงที่ทําขึ้นส่งผลต่อ "โครงสร้างพื้นฐาน" ของแอปพลิเคชันเท่านั้น โค้ด คุณไม่จำเป็นต้องทำการเปลี่ยนแปลงใดๆ ในโค้ดของแอปพลิเคชันหลัก และไม่มีการเปลี่ยนแปลงฟังก์ชันการทำงานของแอปใดๆ ทั้งสิ้น ต่อไปนี้เป็นภาพประกอบของการเปลี่ยนแปลงที่เกิดขึ้นเพื่ออธิบายประเด็นนี้

การพัฒนาและการทดสอบในเครื่อง

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

6. สร้างและติดตั้งใช้งาน

การทำให้ใช้งานได้กับ Cloud Functions แตกต่างจาก App Engine เล็กน้อย เนื่องจากไม่ได้ใช้ไฟล์การกำหนดค่าภายนอก requirements.txt จึงจะต้องระบุข้อมูลเพิ่มเติมเกี่ยวกับโค้ดในบรรทัดคำสั่ง ทำให้ Cloud Function ที่ทริกเกอร์ HTTP ใหม่ซึ่งทำงานภายใต้ Python 3.10 ใช้งานได้ด้วยคำสั่งนี้

$ gcloud functions deploy visitme --runtime python310 --trigger-http --allow-unauthenticated

คาดหวังผลลัพธ์ที่คล้ายกับข้อความต่อไปนี้

Deploying function (may take a while - up to 2 minutes)...⠛
For Cloud Build Logs, visit: https://console.cloud.google.com/cloud-build/builds;region=REGION/f5f6fc81-1bb3-4cdb-8bfe?project=PROJECT_ID
Deploying function (may take a while - up to 2 minutes)...done.
availableMemoryMb: 256
buildId: f5f6fc81-1bb3-4cdb-8bfe
buildName: projects/PROJECT_ID/locations/REGION/builds/f5f6fc81-1bb3-4cdb-8bfe
dockerRegistry: CONTAINER_REGISTRY
entryPoint: visitme
httpsTrigger:
  securityLevel: SECURE_OPTIONAL
  url: https://REGION-PROJECT_ID.cloudfunctions.net/visitme
ingressSettings: ALLOW_ALL
labels:
  deployment-tool: cli-gcloud
name: projects/PROJECT_ID/locations/REGION/functions/visitme
runtime: python310
serviceAccountEmail: PROJECT_ID@appspot.gserviceaccount.com
sourceUploadUrl: https://storage.googleapis.com/uploads-853031211983.REGION.cloudfunctions.appspot.com/8c923758-cee8-47ce-8e97-5720a5301c34.zip
status: ACTIVE
timeout: 60s
updateTime: '2022-05-16T18:28:06.153Z'
versionId: '8'

หลังจากที่ทำให้ฟังก์ชันใช้งานได้แล้ว ให้ใช้ URL จากผลลัพธ์การทำให้ใช้งานได้และไปที่แอปของคุณ URL จะอยู่ในรูปแบบ REGION-PROJECT_ID.cloudfunctions.net/visitme ผลลัพธ์ควรจะเหมือนกับที่คุณทำให้ App Engine ใช้งานได้ก่อนหน้านี้

ฟังก์ชันการทำงานของแอปพื้นฐานจะไม่มีการเปลี่ยนแปลง เช่นเดียวกับ Codelab และวิดีโออื่นๆ ส่วนใหญ่ในซีรีส์นี้ วัตถุประสงค์คือการใช้เทคนิคการปรับให้ทันสมัยวิธีหนึ่ง และทำให้แอปทำงานได้เหมือนเดิมแต่ขับเคลื่อนโดยโครงสร้างพื้นฐานที่ใหม่กว่า เช่น ย้ายข้อมูลจากบริการเดิมของ App Engine เดิมไปยังผลิตภัณฑ์ Cloud แบบสแตนด์อโลนที่ทดแทน หรือย้ายแอปไปยังแพลตฟอร์ม Serverless ของ Google Cloud ในกรณีของบทแนะนำนี้

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

ขอแสดงความยินดีกับการแปลงแอป App Engine ขนาดเล็กนี้เป็น Cloud Function กรณีการใช้งานที่เหมาะสมอีกอย่างหนึ่งคือ การแตกแอป App Engine โมโนลิธขนาดใหญ่เป็นชุด Microservice โดยแต่ละแบบเป็น Cloud Function ซึ่งเป็นเทคนิคการพัฒนาที่ทันสมัยกว่าทำให้สามารถ "เล่นได้ทันที" มากขึ้น คอมโพเนนต์ (a " สแต็ก Jam") โดยเครื่องมือนี้ช่วยให้สามารถผสมผสานและจับคู่ ตลอดจนนำโค้ดมาใช้ซ้ำ ซึ่งเป็นเป้าหมาย 2 ประการ แต่ประโยชน์อีกอย่างคือ Microservice จะได้รับการแก้ไขเมื่อเวลาผ่านไป ซึ่งหมายถึงโค้ดที่มีความเสถียรและต้นทุนในการบำรุงรักษาโดยรวมลดลง

ล้างข้อมูล

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

การติดตั้งใช้งานในแพลตฟอร์มต่างๆ เช่น App Engine และ Cloud Functions จะทำให้มีค่าใช้จ่ายในการสร้างและพื้นที่เก็บข้อมูลเล็กน้อย ในบางภูมิภาค Cloud Build มีโควต้าฟรีของตนเองเช่นเดียวกับ Cloud Storage บิลด์จะใช้โควต้าบางส่วน โปรดคำนึงถึงการใช้พื้นที่เก็บข้อมูลของคุณเพื่อลดค่าใช้จ่ายที่อาจเกิดขึ้น โดยเฉพาะอย่างยิ่งหากภูมิภาคของคุณไม่มีรุ่นฟรีดังกล่าว

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

ขั้นตอนถัดไป

นอกเหนือจากบทแนะนำนี้ โมดูลการย้ายข้อมูลอื่นๆ ที่ควรพิจารณาจะประกอบด้วยการสร้างคอนเทนเนอร์แอป App Engine สำหรับ Cloud Run ด้วย ดูลิงก์ไปยัง Codelab ของโมดูล 4 และโมดูล 5

โมดูล 4: ย้ายข้อมูลไปยัง Cloud Run ด้วย Docker
สร้างคอนเทนเนอร์เพื่อให้แอปทำงานบน Cloud Run ด้วย Docker
การย้ายข้อมูลนี้ช่วยให้คุณใช้ Python 2 ต่อไปได้
โมดูล 5: ย้ายข้อมูลไปยัง Cloud Run ด้วย Cloud Buildpack
สร้างคอนเทนเนอร์เพื่อให้แอปทำงานบน Cloud Run ด้วย Cloud Buildpack
คุณไม่จำเป็นต้องทราบเกี่ยวกับ Docker, คอนเทนเนอร์ หรือ Dockerfile
ต้องย้ายข้อมูลแอปของคุณไปยัง Python 3 แล้ว (Buildpack ไม่รองรับ Python 2)

โมดูลอื่นๆ อีกหลายโมดูลจะเน้นการแสดงให้นักพัฒนาแอปเห็นถึงวิธีย้ายข้อมูลจากบริการที่รวมอยู่ในแพ็กเกจของ App Engine ไปยังการแทนที่แบบสแตนด์อโลนของ Cloud

โมดูล 2: ย้ายข้อมูลจาก App Engine ndb ไปยัง Cloud NDB
โมดูล 7-9: ย้ายข้อมูลจากงานพุชคิวงานของ App Engine ไปยัง Cloud Tasks
โมดูล 12-13: ย้ายข้อมูลจาก App Engine Memcache ไปยัง Cloud Memorystore
โมดูล 15-16: ย้ายข้อมูลจาก App Engine Blobstore ไปยัง Cloud Storage
โมดูล 18-19: ย้ายข้อมูลจากคิวงานของ App Engine (พุลงาน) ไปยัง Cloud Pub/Sub

หากการขนส่งด้วยคอนเทนเนอร์เป็นส่วนหนึ่งของเวิร์กโฟลว์การพัฒนาแอปพลิเคชัน โดยเฉพาะอย่างยิ่งหากประกอบด้วยไปป์ไลน์ CI/CD (การรวมอย่างต่อเนื่อง/การส่งมอบหรือการติดตั้งใช้งานอย่างต่อเนื่อง) ให้ลองย้ายข้อมูลไปยัง Cloud Run แทน Cloud Functions ดูโมดูล 4 เพื่อสร้างคอนเทนเนอร์แอปด้วย Docker หรือโมดูล 5 เพื่อทำคอนเทนเนอร์โดยไม่ต้องมีคอนเทนเนอร์ ไม่มีความรู้ Docker หรือDockerfile คุณจะเปลี่ยนไปใช้ Cloud Functions หรือ Cloud Run หรือไม่ก็ได้ และเราขอแนะนำให้พิจารณาตัวเลือกที่ดีที่สุดสำหรับแอปและกรณีการใช้งานก่อนทำการเปลี่ยนแปลงใดๆ

ไม่ว่าคุณจะพิจารณาโมดูลการย้ายข้อมูลใดในครั้งถัดไป คุณสามารถเข้าถึงเนื้อหาของสถานีย้ายข้อมูลแบบ Serverless (โค้ดแล็บ วิดีโอ ซอร์สโค้ด [เมื่อพร้อมให้บริการ]) ทั้งหมดได้ที่ที่เก็บโอเพนซอร์ส README ของที่เก็บยังให้คำแนะนำเกี่ยวกับการย้ายข้อมูลที่ควรพิจารณาและ "คำสั่ง" ที่เกี่ยวข้อง โมดูลการย้ายข้อมูล

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

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

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

ทรัพยากรการย้ายข้อมูล

คุณสามารถดูลิงก์ไปยังโฟลเดอร์ที่เก็บสำหรับโมดูล 8 (START) และโมดูล 9 (FINISH) ได้ในตารางด้านล่าง นอกจากนี้ยังเข้าถึงได้จากที่เก็บสำหรับการย้ายข้อมูล Codelab ทั้งหมดของ App Engine ซึ่งจะโคลนหรือดาวน์โหลดไฟล์ ZIP ได้

Codelab	Python 3
โมดูล 2	รหัส
โมดูล 11	รหัส

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

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

App Engine

Cloud Functions

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

Python บน Google Cloud Platform
ไลบรารีของไคลเอ็นต์ Google Cloud Python
Google Cloud "ฟรีไม่จำกัดเวลา" ระดับ
Google Cloud SDK (เครื่องมือบรรทัดคำสั่ง gcloud)
เอกสารประกอบทั้งหมดของ Google Cloud

วิดีโอ

ใบอนุญาต

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