โมดูล 5: ย้ายข้อมูลจาก Google App Engine ไปยัง Cloud Run ด้วย Cloud Buildpack

1. ภาพรวม

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

บทแนะนำนี้จะสอนวิธีสร้างคอนเทนเนอร์ของแอป App Engine เพื่อนำไปใช้งานในบริการที่มีการจัดการเต็มรูปแบบของ Cloud Run โดยใช้ Cloud Buildpacks ซึ่งเป็นทางเลือกแทน Docker Cloud Buildpacks จะสร้างคอนเทนเนอร์ให้แอปโดยไม่ต้องจัดการไฟล์ Dockerfile หรือแม้แต่ต้องรู้เรื่อง Docker

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

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

  • สร้างคอนเทนเนอร์ให้แอปโดยใช้ Cloud Buildpacks
  • ทําให้อิมเมจคอนเทนเนอร์ใช้งานได้กับ Cloud Run

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

แบบสำรวจ

คุณจะใช้ Codelab นี้อย่างไร

อ่านอย่างเดียว อ่านและทำแบบฝึกหัดให้เสร็จ

2. ฉากหลัง

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

อย่างไรก็ตาม ความยืดหยุ่นของคอนเทนเนอร์ก็เป็นสิ่งที่น่าสนใจเช่นกัน นั่นคือความสามารถในการเลือกภาษา ไลบรารี หรือไบนารีใดก็ได้ Google Cloud Run มอบสิ่งที่ดีที่สุดจากทั้ง 2 โลกให้แก่ผู้ใช้ นั่นคือความสะดวกสบายของแบบไร้เซิร์ฟเวอร์ควบคู่ไปกับความยืดหยุ่นของคอนเทนเนอร์

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

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

ในบทแนะนำนี้ คุณจะได้เรียนรู้วิธีสร้างคอนเทนเนอร์ให้แอป นำไฟล์กำหนดค่า App Engine ออก จัดการเว็บเซิร์ฟเวอร์ รวมถึงวิธีเริ่มต้นแอป

การย้ายข้อมูลนี้มีขั้นตอนดังนี้

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

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

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

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

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

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

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

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

ไดเรกทอรีของไฟล์ START (ของคุณหรือของเรา) ควรมีลักษณะดังนี้

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

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

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

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

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

4. สร้างคอนเทนเนอร์แอปพลิเคชัน

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

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

ขั้นตอนการย้ายข้อมูลรวมถึงการแทนที่ไฟล์การกำหนดค่า App Engine และการระบุวิธีที่แอปควรเริ่มต้น ตารางด้านล่างสรุปไฟล์การกำหนดค่าที่คาดไว้สำหรับแพลตฟอร์มแต่ละประเภท เปรียบเทียบคอลัมน์ App Engine กับคอลัมน์ Buildpack (และ Docker หากต้องการ)

คำอธิบาย

App Engine

Docker

Buildpack

การกำหนดค่าทั่วไป

app.yaml

Dockerfile

(service.yaml)

ไลบรารีของบุคคลที่สาม

requirements.txt

requirements.txt

requirements.txt

การกำหนดค่าของบุคคลที่สาม

app.yaml (รวมถึง appengine_config.py และ lib [2.x เท่านั้น])

(ไม่มี)

(ไม่มี)

สตาร์ทอัพ

(ไม่มี) หรือ app.yaml (หากใช้ entrypoint)

Dockerfile

Procfile

ละเว้นไฟล์

.gcloudignore และ .gitignore

.gcloudignore, .gitignore และ .dockerignore

.gcloudignore และ .gitignore

เมื่อสร้างคอนเทนเนอร์ของแอปแล้ว คุณจะนำไปใช้งานใน Cloud Run ได้ ตัวเลือกแพลตฟอร์มคอนเทนเนอร์อื่นๆ ของ Google Cloud ได้แก่ Compute Engine, GKE และ Anthos

การกำหนดค่าทั่วไป

App Engine จะเริ่มแอปพลิเคชันโดยอัตโนมัติ แต่ Cloud Run จะไม่เริ่ม Procfile มีบทบาทคล้ายกับคำสั่ง app.yaml entrypoint สำหรับแอปตัวอย่างของเรา Procfile จะเรียกใช้ python main.py เพื่อเริ่มเซิร์ฟเวอร์การพัฒนา Flask นอกจากนี้ คุณยังใช้เว็บเซิร์ฟเวอร์ที่ใช้งานจริง เช่น gunicorn ได้หากต้องการ และหากใช้ ให้เพิ่มลงใน requirements.txt ด้วย ดูข้อมูลเพิ่มเติมเกี่ยวกับวิธีติดตั้งใช้งานจากซอร์สโค้ดโดยใช้ Buildpack จากหน้าเอกสารประกอบของ Cloud Run นี้

คุณเพียงแค่ต้องย้ายคำสั่ง app.yaml entrypoint ไปยัง Procfile หากไม่มี ให้ใช้เซิร์ฟเวอร์การพัฒนา Flask ไปก่อน เนื่องจากนี่เป็นเพียงแอปทดสอบตัวอย่างเพื่อให้ผู้ใช้คุ้นเคยกับการย้ายข้อมูลนี้ แอปของคุณจะเป็นคำสั่งเริ่มต้นที่เฉพาะเจาะจงซึ่งคุณรู้จักดีที่สุด เบื้องหลังบริการ Cloud Run จะสร้าง service.yaml ซึ่งมีลักษณะ/การทำงานคล้ายกับ app.yaml คุณดู service.yaml ที่สร้างขึ้นโดยอัตโนมัติได้โดยไปที่ลิงก์ที่คล้ายกับลิงก์นี้ แต่เป็นลิงก์สำหรับบริการ SVC_NAME และ REGION ของคุณ: https://console.cloud.google.com/run/detail/REGION/SVC_NAME/yaml/view

ไลบรารีของบุคคลที่สาม

ไม่จำเป็นต้องเปลี่ยนแปลงไฟล์ requirements.txt Flask ควรอยู่ที่นั่นพร้อมกับไลบรารีไคลเอ็นต์ Datastore (Cloud Datastore หรือ Cloud NDB) หากต้องการใช้เซิร์ฟเวอร์ HTTP ที่เป็นไปตาม WSGI อื่น เช่น Gunicorn (เวอร์ชันปัจจุบัน ณ เวลาที่เขียนคือ 20.0.4) ให้เพิ่ม gunicorn==20.0.4 ลงใน requirements.txt

การกำหนดค่าของบุคคลที่สาม

Buildpack ไม่รองรับ Python 2 ดังนั้นเราจะไม่พูดถึงเรื่องนี้ที่นี่ แอป Python 3 ที่ทำงานในคอนเทนเนอร์บน Cloud Run จะคล้ายกับแอป Python 3 ของ App Engine ตรงที่ต้องระบุไลบรารีของบุคคลที่สามใน requirements.txt

สตาร์ทอัพ

ผู้ใช้ Python 3 มีตัวเลือกในการแปลงไฟล์ app.yaml ให้มี entrypoint แทนที่จะเป็นคำสั่ง script: auto ในส่วน handlers หากคุณใช้ entrypoint ใน app.yaml Python 3 จะมีลักษณะดังนี้

runtime: python38
entrypoint: python main.py

คำสั่ง entrypoint จะบอก App Engine วิธีเริ่มต้นเซิร์ฟเวอร์ คุณสามารถย้ายข้อมูลไปยัง Procfile ได้โดยตรง สรุปตำแหน่งที่ควรวางคำสั่ง Entrypoint ระหว่างทั้ง 2 แพลตฟอร์ม ซึ่งจะสอดคล้องกับข้อมูลด้านล่างโดยตรง และยังแสดงคำสั่ง Docker ที่เทียบเท่าเพื่อเป็นข้อมูลเพิ่มเติมด้วย

  • Buildpacks: บรรทัดใน Procfile: web: python main.py
  • Docker: บรรทัดใน Dockerfile: ENTRYPOINT ["python", "main.py"]

สำหรับการทดสอบและการจัดเตรียม คุณสามารถเรียกใช้เซิร์ฟเวอร์การพัฒนาของ Flask จาก Python ได้อย่างง่ายดายตามที่เราได้กล่าวไว้ข้างต้น แต่นักพัฒนาแอปอาจเลือกใช้สิ่งที่มีประสิทธิภาพมากกว่าสำหรับการใช้งานจริง เช่น ตัวอย่างการเริ่มต้นใช้งานด่วนของ Cloud Run ซึ่งใช้ gunicorn

ไฟล์แอปพลิเคชัน

แอปโมดูล 2 หรือโมดูล 3 ทั้งหมดจะเข้ากันได้กับ Python 2-3 อย่างเต็มรูปแบบ ซึ่งหมายความว่าจะไม่มีการเปลี่ยนแปลงคอมโพเนนต์หลักของ main.py เราจะเพิ่มโค้ดเริ่มต้นเพียงไม่กี่บรรทัดเท่านั้น เพิ่ม 2 บรรทัดที่ด้านล่างของ main.py เพื่อเริ่มเซิร์ฟเวอร์การพัฒนา เนื่องจาก Cloud Run กำหนดให้ต้องเปิดพอร์ต 8080 เพื่อให้เรียกแอปได้

if __name__ == '__main__':
    import os
    app.run(debug=True, threaded=True, host='0.0.0.0',
            port=int(os.environ.get('PORT', 8080)))

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

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

บริการเทียบกับแอป

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

คุณไม่จำเป็นต้องตั้งชื่อใดๆ เมื่อทำให้แอปพลิเคชันใช้งานได้ เว้นแต่แอป App Engine ของคุณจะประกอบด้วยบริการหลายอย่าง แต่ใน Cloud Run คุณจะต้องตั้งชื่อบริการ ในขณะที่โดเมน appspot.com ของ App Engine จะมีรหัสโปรเจ็กต์ เช่น https://PROJECT_ID.appspot.com และอาจมีตัวย่อรหัสภูมิภาค เช่น http://PROJECT_ID.REGION_ID.r.appspot.com

อย่างไรก็ตาม โดเมนสำหรับบริการ Cloud Run จะมีชื่อบริการ ตัวย่อรหัสภูมิภาค และแฮช แต่ไม่มีรหัสโปรเจ็กต์ เช่น https://SVC_NAME-HASH-REG_ABBR.a.run.app สรุปคือ ให้เริ่มคิดชื่อบริการได้เลย

ติดตั้งใช้งานบริการ

เรียกใช้คำสั่งด้านล่างเพื่อสร้างอิมเมจคอนเทนเนอร์และทำให้ใช้งานได้กับ Cloud Run เมื่อได้รับข้อความแจ้ง ให้เลือกภูมิภาคและอนุญาตการเชื่อมต่อที่ไม่ได้รับการตรวจสอบสิทธิ์เพื่อให้ทดสอบได้ง่ายขึ้น แล้วเลือกภูมิภาคตามความเหมาะสมโดยที่ SVC_NAME คือชื่อบริการที่คุณกำลังติดตั้งใช้งาน

$ gcloud run deploy SVC_NAME --source .
Please choose a target platform:
 [1] Cloud Run (fully managed)
 [2] Cloud Run for Anthos deployed on Google Cloud
 [3] Cloud Run for Anthos deployed on VMware
 [4] cancel
Please enter your numeric choice:  1

To specify the platform yourself, pass `--platform managed`. Or, to make this the default target platform, run `gcloud config set run/platform managed`.

Please specify a region:
 [1] asia-east1
 [2] asia-east2
 [3] asia-northeast1
 [4] asia-northeast2
 [5] asia-northeast3
 [6] asia-south1
 [7] asia-southeast1
 [8] asia-southeast2
 [9] australia-southeast1
 [10] europe-north1
 [11] europe-west1
 [12] europe-west2
 [13] europe-west3
 [14] europe-west4
 [15] europe-west6
 [16] northamerica-northeast1
 [17] southamerica-east1
 [18] us-central1
 [19] us-east1
 [20] us-east4
 [21] us-west1
 [22] us-west2
 [23] us-west3
 [24] us-west4
 [25] cancel
Please enter your numeric choice: <select your numeric region choice>

To make this the default region, run `gcloud config set run/region REGION`.

Allow unauthenticated invocations to [SVC_NAME] (y/N)?  y

Building using Buildpacks and deploying container to Cloud Run service [SVC_NAME] in project [PROJECT_ID] region [REGION]
✓ Building and deploying... Done.
  ✓ Uploading sources...
  ✓ Building Container... Logs are available at [https://console.cloud.google.com/cloud-build/builds/BUILD-HASH?project=PROJECT_NUM].
  ✓ Creating Revision...
  ✓ Routing traffic...
Done.
Service [SVC_NAME] revision [SVC_NAME-00014-soc] has been deployed and is serving 100 percent of traffic.
Service URL: https://SVC_NAME-HASH-REG_ABBR.a.run.app

ไปที่ URL ที่ระบุด้วยเบราว์เซอร์เพื่อยืนยันว่าการติดตั้งใช้งานสำเร็จ

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

$ gcloud beta run deploy SVC_NAME --source . --platform managed --region REGION --allow-unauthenticated

หากใช้ตัวเลือกนี้ โปรดเลือกชื่อบริการเดียวกัน SVC_NAME และREGION ชื่อที่ต้องการ ไม่ใช่การเลือกเมนูที่จัดทำดัชนีแล้วเหมือนที่เราทำแบบอินเทอร์แอกทีฟด้านบน

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

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

แอป VisitMe

ตอนนี้โค้ดของคุณควรตรงกับโค้ดในโฟลเดอร์ที่เก็บโมดูล 5 ขอแสดงความยินดีที่ทำ Codelab โมดูลที่ 5 นี้เสร็จสมบูรณ์

ไม่บังคับ: ล้างข้อมูล

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

ไม่บังคับ: ปิดใช้บริการ

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

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

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

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

  • Module 4: ย้ายข้อมูลไปยัง Cloud Run ด้วย Docker
    • สร้างคอนเทนเนอร์แอปเพื่อเรียกใช้ใน Cloud Run ด้วย Docker
    • ช่วยให้คุณใช้ Python 2 ต่อไปได้
  • Module 7: คิวงานแบบพุชของ App Engine (ต้องระบุหากคุณใช้คิวงาน [push])
    • เพิ่มtaskqueueงานแบบพุชของ App Engine ไปยังแอปโมดูล 1
    • เตรียมผู้ใช้ให้พร้อมสำหรับการย้ายข้อมูลไปยัง Cloud Tasks ในโมดูลที่ 8
  • โมดูล 3:
    • ปรับปรุงการเข้าถึง Datastore จาก Cloud NDB เป็น Cloud Datastore
    • นี่คือไลบรารีที่ใช้สำหรับแอป Python 3 App Engine และแอปที่ไม่ใช่ App Engine
  • Module 6: ย้ายข้อมูลไปยัง Cloud Firestore
    • ย้ายข้อมูลไปยัง Cloud Firestore เพื่อเข้าถึงฟีเจอร์ของ Firebase
    • แม้ว่า Cloud Firestore จะรองรับ Python 2 แต่ Codelab นี้ใช้ได้ใน Python 3 เท่านั้น

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

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

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

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

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

Codelab

Python 2

Python 3

Module 2

รหัส

(รหัส)

โมดูล 3

(รหัส)

รหัส

โมดูล 5

(ไม่มี)

รหัส

ทรัพยากร App Engine และ Cloud Run

แหล่งข้อมูลเพิ่มเติมเกี่ยวกับการย้ายข้อมูลนี้มีดังนี้