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

1. ภาพรวม

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

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

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

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

สิ่งที่คุณต้องมี

แบบสำรวจ

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

อ่านอย่างเดียว อ่านและทำแบบฝึกหัด

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

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

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

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

2. ฉากหลัง

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

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

Cloud Functions มีไว้สำหรับการติดตั้งใช้งานโค้ดขนาดเล็กซึ่งมีลักษณะดังนี้

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

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

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

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

3. การตั้งค่า/การเตรียมการ

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

1. ตั้งค่าโปรเจ็กต์

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

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

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

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

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

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

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

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

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

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

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

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

หากคุณพอร์ตแอป App Engine ของ Python 2 ไปยัง 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) หรือโครงสร้างพื้นฐานของเฟรมเวิร์กเว็บอื่นๆ คุณจะต้องแก้ไขการอ้างอิงเหล่านั้นทั้งหมด ค้นหาวิธีแก้ปัญหาที่เหมาะสม หรือนำการใช้งานออกทั้งหมด หรือค้นหาพร็อกซี จากนั้นคุณจึงจะแปลงโค้ดเป็น Cloud Functions ได้ ไม่เช่นนั้น คุณควรใช้ App Engine ต่อไปหรือเปลี่ยนแอปเป็นคอนเทนเนอร์สำหรับ Cloud Run

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

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

  1. ระบบจะไม่ใช้ Flask อีกต่อไปหลังจากแปลงแอปเป็น Cloud Function ดังนั้นให้นำตัวตกแต่งเส้นทางออก
  2. Cloud Functions จะส่งออบเจ็กต์ Request ของ Flask เป็นพารามิเตอร์โดยอัตโนมัติ ดังนั้นให้สร้างตัวแปรสำหรับออบเจ็กต์ดังกล่าว ในแอปตัวอย่าง เราจะเรียกฟังก์ชันนี้ว่า request
  3. Cloud Functions ที่ติดตั้งใช้งานแล้วต้องมีชื่อ เราตั้งชื่อตัวแฮนเดิลหลักอย่างเหมาะสม root() ใน App Engine เพื่ออธิบายว่าตัวแฮนเดิลนั้นคืออะไร (ตัวแฮนเดิลแอปพลิเคชันรูท) ในฐานะ Cloud Function การใช้ชื่อดังกล่าวจึงไม่สมเหตุสมผล แต่เราจะทำให้ฟังก์ชัน Cloud ใช้งานได้โดยใช้ชื่อ 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)

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

668f30e3865b27a9.png

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

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

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

2732ae9218f011a2.png

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

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

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

ล้างข้อมูล

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

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

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

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

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

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

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

  • โมดูลที่ 2: ย้ายข้อมูลจาก App Engine ndb ไปยัง Cloud NDB
  • โมดูล 7-9: ย้ายข้อมูลจากงานแบบพุชของคิวงาน App Engine ไปยัง Cloud Tasks
  • โมดูล 12-13: ย้ายข้อมูลจาก Memcache ของ App Engine ไปยัง 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 Migration Station ทั้งหมด (Codelab, วิดีโอ, ซอร์สโค้ด [หากมี]) ได้ที่ที่เก็บแบบโอเพนซอร์ส README ของที่เก็บยังให้คำแนะนำเกี่ยวกับการย้ายข้อมูลที่ควรพิจารณาและ "ลำดับ" ที่เกี่ยวข้องของโมดูลการย้ายข้อมูลด้วย

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

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

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

แหล่งข้อมูลเกี่ยวกับการย้ายข้อมูล

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

Codelab

Python 3

Module 2

รหัส

โมดูล 11

รหัส

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

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

App Engine

Cloud Functions

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

วิดีโอ

ใบอนุญาต

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