1. ภาพรวม
Codelab ชุดนี้ (บทแนะนำที่เรียนรู้ได้ด้วยตนเอง) มีเป้าหมายเพื่อช่วยนักพัฒนา Google App Engine (มาตรฐาน) ปรับปรุงแอปให้ทันสมัย โดยแนะนำขั้นตอนการย้ายข้อมูลหลายครั้ง เมื่อทดสอบเสร็จสมบูรณ์แล้ว ผู้ใช้สามารถทำให้แอปเป็นแบบถ่ายโอนได้ได้ดีขึ้นด้วยการสร้างคอนเทนเนอร์สำหรับ Cloud Run บริการร่วมสำหรับการโฮสต์คอนเทนเนอร์ของ Google Cloud ไปยัง App Engine และบริการโฮสติ้งคอนเทนเนอร์อื่นๆ
บทแนะนำนี้จะสอนวิธีสร้างคอนเทนเนอร์แอป App Engine สำหรับการทำให้ใช้งานได้กับบริการที่มีการจัดการครบวงจรของ Cloud Run โดยใช้ Cloud Buildpack ซึ่งเป็นอีกทางเลือกหนึ่งสำหรับ Docker Cloud Buildpack สร้างคอนเทนเนอร์ให้กับแอปของคุณโดยไม่ต้องจัดการไฟล์ Dockerfile
หรือแม้แต่รู้ข้อมูลใดเลยเกี่ยวกับ Docker
Codelab นี้มีไว้สำหรับนักพัฒนาซอฟต์แวร์ Python 2 App Engine ที่ย้ายแอปออกจากบริการเดิมที่มีอยู่ในระบบและย้ายแอปไปยัง Python 3 แล้ว โดยกำลังมองหาวิธีเรียกใช้แอปในคอนเทนเนอร์ Codelab จะเริ่มต้นด้วยแอปโมดูล 2 ที่เสร็จสมบูรณ์ หรือแอป Python 3 โมดูล 3
คุณจะได้เรียนรู้วิธีการ
- สร้างคอนเทนเนอร์ให้กับแอปโดยใช้ Cloud Buildpack
- ทำให้อิมเมจคอนเทนเนอร์ใช้งานได้กับ Cloud Run
สิ่งที่คุณต้องมี
- โปรเจ็กต์ Google Cloud Platform ที่มีสิ่งต่อไปนี้
- ทักษะพื้นฐานเรื่อง Python
- ความรู้เกี่ยวกับคำสั่งทั่วไปของ Linux
- ความรู้พื้นฐานเกี่ยวกับการพัฒนาและการทำให้แอป App Engine ใช้งานได้
- เราขอแนะนำให้ทำ Codelab ของโมดูล 2 หรือโมดูล 3 ให้เสร็จสิ้น (หรือทั้ง 2 อย่าง) รวมถึงการย้ายไปยัง Python 3 ก่อนเริ่มการทดสอบนี้ (โมดูล 5)
- แอป Python 3 App Engine ที่ใช้งานได้ซึ่งพร้อมสำหรับการสร้างด้วยคอนเทนเนอร์
แบบสำรวจ
คุณจะใช้ Codelab นี้อย่างไร
2. ข้อมูลเบื้องต้น
ระบบ PaaS เช่น App Engine และ Cloud Functions จะอำนวยความสะดวกมากมายให้กับทีมและแอปพลิเคชันของคุณ ตัวอย่างเช่น แพลตฟอร์มแบบ Serverless เหล่านี้ทำให้ SysAdmin/Devops สามารถมุ่งเน้นไปที่การสร้างโซลูชันได้ แอปของคุณสามารถปรับขนาดโดยอัตโนมัติได้ตามต้องการ ลดขนาดเป็น 0 ด้วยการเรียกเก็บเงินแบบจ่ายต่อการใช้งานช่วยควบคุมต้นทุน และใช้ภาษาสำหรับการพัฒนาทั่วไปที่หลากหลาย
อย่างไรก็ตาม ความยืดหยุ่นของคอนเทนเนอร์ก็น่าดึงดูดใจเช่นกัน ความสามารถในการเลือกภาษา ไลบรารี และไบนารีใดก็ได้ Google Cloud Run นำเสนอสิ่งที่ดีที่สุดจากทั้ง 2 วิธีนี้ให้แก่ผู้ใช้ ความสะดวกสบายแบบ Serverless ตลอดจนความยืดหยุ่นของคอนเทนเนอร์
การเรียนรู้วิธีใช้ Cloud Run ไม่ได้อยู่ในขอบเขตของ Codelab นี้ ที่อยู่ในเอกสารประกอบเกี่ยวกับ Cloud Run เป้าหมายนี้มีไว้สำหรับคุณเพื่อให้ทราบวิธีสร้างคอนเทนเนอร์แอป App Engine สำหรับ Cloud Run (หรือบริการอื่นๆ) มี 2-3 อย่างที่คุณควรทราบก่อนที่จะดำเนินการต่อ หลักๆ แล้วประสบการณ์ของผู้ใช้จะต่างออกไปเล็กน้อย ลดระดับลงเล็กน้อย เนื่องจากคุณจะไม่ใช้โค้ดของแอปพลิเคชันและทำให้ใช้งานได้อีกต่อไป
แต่คุณจะต้องเรียนรู้ข้อมูลเกี่ยวกับคอนเทนเนอร์ เช่น วิธีสร้างและทำให้ใช้งานได้ นอกจากนี้ คุณยังต้องตัดสินใจเลือกสิ่งที่คุณต้องการจะใส่ในอิมเมจคอนเทนเนอร์ รวมถึงเว็บเซิร์ฟเวอร์ เนื่องจากคุณจะไม่ใช้เว็บเซิร์ฟเวอร์ของ App Engine อีกต่อไป หากคุณไม่ต้องการปฏิบัติตามเส้นทางนี้ การทำให้แอปอยู่ใน App Engine ก็ไม่ใช่ตัวเลือกที่เหมาะสม
ในบทแนะนำนี้ คุณจะได้เรียนรู้วิธีคอนเทนเนอร์แอป การนำไฟล์การกำหนดค่า App Engine ออก จัดการเว็บเซิร์ฟเวอร์ รวมถึงวิธีเริ่มต้นแอป
การย้ายข้อมูลนี้มีขั้นตอนดังต่อไปนี้
- การตั้งค่า/งานล่วงหน้า
- แอปพลิเคชันที่มีคอนเทนเนอร์
- แทนที่ไฟล์การกำหนดค่า
- แก้ไขไฟล์แอปพลิเคชัน
3. การตั้งค่า/งานล่วงหน้า
ก่อนจะไปยังส่วนหลักของบทแนะนำ เราจะสร้างโปรเจ็กต์ รับโค้ด แล้วทำให้แอปพื้นฐานใช้งานได้เพื่อให้เราทราบว่าเราเริ่มจากโค้ดที่ใช้งานได้แล้ว
1. สร้างโปรเจ็กต์
หากคุณทำ Codelab ของโมดูล 2 หรือโมดูล 3 เสร็จสมบูรณ์แล้ว เราขอแนะนำให้ใช้โปรเจ็กต์ (และโค้ด) เดียวกันนั้นซ้ำ หรือจะสร้างโปรเจ็กต์ใหม่หรือนำโปรเจ็กต์อื่นที่มีอยู่มาใช้ใหม่ก็ได้ ตรวจสอบว่าโปรเจ็กต์มีบัญชีสำหรับการเรียกเก็บเงินที่ใช้งานอยู่และเปิดใช้ App Engine (แอป) แล้ว
2. รับแอปตัวอย่างพื้นฐาน
ข้อกำหนดเบื้องต้นอย่างหนึ่งของ Codelab นี้คือแอปตัวอย่างโมดูล 2 หรือ 3 ที่ใช้งานได้ หากคุณยังไม่มี เราขอแนะนำให้ดูบทแนะนำ (ลิงก์ด้านบน) ให้เสร็จสมบูรณ์ก่อนที่จะดำเนินการต่อที่นี่ หรือหากคุณคุ้นเคยกับเนื้อหาในโฟลเดอร์อยู่แล้ว ก็เริ่มด้วยการเลือกโฟลเดอร์โค้ดโฟลเดอร์ใดโฟลเดอร์หนึ่งด้านล่าง
บทแนะนำนี้จะเริ่มต้นขึ้นไม่ว่าคุณจะใช้อุปกรณ์ของคุณเองหรือของเรา Codelab นี้จะแนะนำการย้ายข้อมูล และเมื่อคุณทำเสร็จ โดยส่วนใหญ่แล้วควรจะตรงกับสิ่งที่อยู่ในโฟลเดอร์ที่เก็บของ Module 5 FINISH
- เริ่มต้น:
- Cloud NDB: รหัสโมดูล 2
- Cloud Datastore: รหัสโมดูล 3
- FINISH: โค้ดโมดูล 5
- ทั้งที่เก็บ (เพื่อโคลนหรือดาวน์โหลด ZIP)
ไดเรกทอรีของไฟล์ START (ของคุณหรือของเรา) ควรมีลักษณะดังนี้
$ ls
README.md main.py templates
app.yaml requirements.txt
3. (อีกครั้ง) ทำให้แอปพื้นฐานใช้งานได้
ขั้นตอนก่อนการทำงานที่เหลือของคุณที่ต้องดำเนินการตอนนี้มีดังนี้
- ทำความคุ้นเคยกับเครื่องมือบรรทัดคำสั่ง
gcloud
- ทำให้แอปตัวอย่างใช้งานได้อีกครั้งกับ
gcloud app deploy
- ยืนยันว่าแอปทำงานบน App Engine โดยไม่มีปัญหา
เมื่อคุณดำเนินการตามขั้นตอนเหล่านั้นเรียบร้อยแล้ว คุณก็พร้อมที่จะสร้างคอนเทนเนอร์
4. แอปพลิเคชัน Containerize
Docker เป็นแพลตฟอร์มการขนส่งด้วยคอนเทนเนอร์มาตรฐานในอุตสาหกรรมในปัจจุบัน อย่างที่กล่าวไปแล้ว ความท้าทายอย่างหนึ่งในการใช้งานโซลูชันนี้คือการดูแลจัดการ Dockerfile
ที่มีประสิทธิภาพ ซึ่งเป็นไฟล์การกำหนดค่าที่กำหนดวิธีสร้างอิมเมจคอนเทนเนอร์ ในทางตรงกันข้าม Buildpack จะช่วยให้คุณไม่ต้องลงแรงมากเพราะใช้การตรวจสอบทรัพยากร Dependency ของแอป ทำให้คอนเทนเนอร์ Buildpack มีประสิทธิภาพมากที่สุดเท่าที่จะเป็นไปได้สำหรับแอปของคุณ
คุณมาถูกที่แล้วหากคุณต้องการข้ามการเรียนรู้เกี่ยวกับ Docker และต้องการสร้างคอนเทนเนอร์แอป App Engine ให้ทำงานบน Cloud Run หรือแพลตฟอร์มโฮสติ้งคอนเทนเนอร์อื่นๆ หากสนใจเรียนรู้วิธีใช้ Docker สำหรับการขนส่งแอปด้วยคอนเทนเนอร์ คุณสามารถทำได้ใน Codelab ของโมดูล 4 หลังจากทำขั้นตอนนี้เสร็จ นี่เหมือนกับตัวนี้ แต่ใช้ Docker เพื่อช่วยให้เข้าใจวิธีจัดการอิมเมจคอนเทนเนอร์ได้ดียิ่งขึ้น
ขั้นตอนการย้ายข้อมูลรวมถึงการเปลี่ยนไฟล์การกำหนดค่า App Engine และระบุวิธีที่แอปควรเริ่มต้น ด้านล่างคือตารางสรุปไฟล์การกำหนดค่าที่คาดหวังสําหรับแพลตฟอร์มแต่ละประเภท เปรียบเทียบคอลัมน์ App Engine กับคอลัมน์ Buildpacks (และเลือก Docker หรือไม่ก็ได้)
คำอธิบาย | App Engine | Docker | Buildpack |
การกำหนดค่าทั่วไป |
|
| ( |
ไลบรารีของบุคคลที่สาม |
|
|
|
การกำหนดค่าของบุคคลที่สาม |
| (ไม่มี) | (ไม่มี) |
เริ่มต้นทำงาน | (n/a) หรือ |
|
|
ละเว้นไฟล์ |
|
|
|
เมื่อแอปมีคอนเทนเนอร์แล้ว คุณจะทำให้แอปใช้งานได้กับ 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
ใน Python 3 app.yaml
ไฟล์จะมีลักษณะดังนี้
runtime: python38
entrypoint: python main.py
คำสั่ง entrypoint
จะบอก App Engine ถึงวิธีเริ่มต้นเซิร์ฟเวอร์ คุณจะย้ายไปไว้ใน Procfile
ได้เกือบโดยตรง สรุปว่าคำสั่งจุดเข้าถึงจะเชื่อมไปยังทั้ง 2 แพลตฟอร์มที่ตำแหน่งใด: ซึ่งจะแปลไปสู่ด้านล่างโดยตรง ยังแสดง Docker ที่เทียบเท่าเพื่อแจ้งให้ทราบดังนี้
- Buildpack: บรรทัดใน
Procfile
:web: python main.py
- Docker: บรรทัดใน
Dockerfile
:ENTRYPOINT ["python", "main.py"]
สำหรับการทดสอบและการทดลองใช้ เพียงเรียกใช้เซิร์ฟเวอร์การพัฒนาของ Flask จาก Python จาก Python ก็ทำได้ง่ายๆ แต่นักพัฒนาซอฟต์แวร์สามารถเลือกใช้เครื่องมือที่มีประสิทธิภาพมากกว่าสำหรับเวอร์ชันที่ใช้งานจริงได้ เช่น ตัวอย่าง Cloud Run Quickstart ที่ใช้ 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 จะสร้างขึ้นเพื่อโฮสต์แอปพลิเคชันเป็นหลัก แต่ก็เป็นแพลตฟอร์มสำหรับการโฮสต์บริการบนเว็บหรือแอปพลิเคชันด้วยชุด Microservice ใน 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 ก่อนหน้านี้ ตัวแอปเองจะไม่มีการเปลี่ยนแปลง หน้าแรกจะบันทึกการเข้าชมหน้าเว็บหลัก (/
) ทั้งหมด และมีลักษณะเช่นนี้เมื่อคุณเข้าชมเว็บไซต์ไปหลายครั้งพอแล้ว:
ตอนนี้โค้ดของคุณควรตรงกับสิ่งที่อยู่ในโฟลเดอร์ที่เก็บโมดูล 5 ขอแสดงความยินดีที่ Codelab ของโมดูล 5 นี้เสร็จสมบูรณ์
ไม่บังคับ: ล้างข้อมูล
จะต้องทำอย่างไรเพื่อหลีกเลี่ยงการเรียกเก็บเงินจนกว่าคุณจะพร้อมสำหรับการย้ายข้อมูลไปยัง Codelab ครั้งถัดไป และเนื่องจากตอนนี้คุณใช้ผลิตภัณฑ์อื่นอยู่ โปรดอ่านคู่มือการกำหนดราคาของ Cloud Run
ไม่บังคับ: ปิดใช้บริการ
หากยังไม่พร้อมดูบทแนะนำถัดไป ให้ปิดใช้บริการเพื่อหลีกเลี่ยงค่าใช้จ่ายเพิ่มเติม เมื่อพร้อมที่จะไปยัง Codelab ถัดไปแล้ว คุณก็เปิดใช้อีกครั้งได้ ระหว่างที่แอปปิดใช้อยู่ แอปจะไม่ทำให้เกิดการเรียกเก็บเงินใดๆ แต่อาจมีการเรียกเก็บเงินอีกอย่างหนึ่งคือการใช้พื้นที่เก็บข้อมูล หากแอปเกินโควต้าฟรี ให้ลบให้ไม่เกินจำนวนที่จำกัดไว้
ในทางกลับกัน หากไม่ต้องการย้ายข้อมูลต่อและต้องการลบทุกอย่างออกอย่างสมบูรณ์ คุณสามารถลบบริการหรือปิดโปรเจ็กต์ทั้งหมด
ขั้นตอนถัดไป
ขอแสดงความยินดี คุณได้สร้างแอปของคุณในแบบคอนเทนเนอร์ ซึ่งได้สรุปบทแนะนำนี้ จากที่นี่ ขั้นตอนถัดไปคือการเรียนรู้เกี่ยวกับวิธีทำแบบเดียวกันกับ Docker ใน Codelab ของโมดูล 4 (ลิงก์ด้านล่าง) หรือทำการย้ายข้อมูล App Engine อีกครั้ง
- โมดูล 4: ย้ายข้อมูลไปยัง Cloud Run ด้วย Docker
- สร้างคอนเทนเนอร์เพื่อให้แอปทำงานบน Cloud Run ด้วย Docker
- อนุญาตให้คุณใช้ Python 2 ต่อไป
- โมดูล 7: คิวงานพุชของ App Engine (จำเป็นหากคุณใช้คิวงาน [push])
- เพิ่มงานพุช
taskqueue
งานของ App Engine ลงในแอปโมดูล 1 - เตรียมความพร้อมให้กับผู้ใช้สำหรับการย้ายข้อมูลไปยัง Cloud Tasks ในโมดูล 8
- เพิ่มงานพุช
- โมดูล 3:
- ปรับการเข้าถึง Datastore ให้ทันสมัยจาก Cloud NDB ไปยัง Cloud Datastore
- นี่คือไลบรารีที่ใช้สำหรับแอป Python 3 App Engine และแอปที่ไม่ใช่ App Engine
- โมดูล 6: ย้ายข้อมูลไปยัง Cloud Firestore
- ย้ายข้อมูลไปยัง Cloud Firestore เพื่อเข้าถึงฟีเจอร์ของ Firebase
- แม้ว่า Cloud Firestore จะรองรับ Python 2 แต่ Codelab นี้มีให้บริการใน Python 3 เท่านั้น
7. แหล่งข้อมูลเพิ่มเติม
ปัญหา/ข้อเสนอแนะเกี่ยวกับ Codelab ของโมดูลการย้ายข้อมูล App Engine
หากมีปัญหาใดๆ เกี่ยวกับ Codelab นี้ โปรดค้นหาปัญหาของคุณก่อนยื่น ลิงก์สำหรับค้นหาและสร้างปัญหาใหม่
- เครื่องมือติดตามปัญหาสำหรับ Codelab การย้ายข้อมูลของ App Engine
ทรัพยากรการย้ายข้อมูล
คุณสามารถดูลิงก์ไปยังโฟลเดอร์ที่เก็บสำหรับโมดูล 2 และ 3 (START) และโมดูล 5 (FINISH) ได้ในตารางด้านล่าง นอกจากนี้ยังเข้าถึงได้จากที่เก็บสำหรับการย้ายข้อมูล Codelab ทั้งหมดของ App Engine ซึ่งจะโคลนหรือดาวน์โหลดไฟล์ ZIP ได้
Codelab | Python 2 | Python 3 |
(รหัส) | ||
(รหัส) | ||
โมดูล 5 | (ไม่มี) |
ทรัพยากร App Engine และ Cloud Run
ด้านล่างนี้คือแหล่งข้อมูลเพิ่มเติมเกี่ยวกับการย้ายข้อมูลครั้งนี้
- คอนเทนเนอร์
- ทั่วไป