1. ภาพรวม
ชุดโปรแกรม Codelab สำหรับการย้ายข้อมูลแบบ Serverless (บทแนะนำแบบลงมือทำด้วยตนเอง) และวิดีโอที่เกี่ยวข้องมีจุดประสงค์เพื่อช่วยให้นักพัฒนาแอป Google Cloud Serverless ปรับการดำเนินการให้ทันสมัยได้ด้วยคำแนะนำการย้ายข้อมูลอย่างน้อย 1 รายการ โดยให้ย้ายออกจากบริการเดิมเป็นหลัก การดำเนินการดังกล่าวทำให้แอปพกพาไปได้ทุกที่ รวมถึงมอบตัวเลือกและความยืดหยุ่นที่มากขึ้น ทำให้สามารถผสานรวมและเข้าถึงผลิตภัณฑ์ Cloud ที่หลากหลายยิ่งขึ้น และอัปเกรดเป็นรุ่นภาษาใหม่ๆ ได้ง่ายยิ่งขึ้น แม้ว่าในช่วงแรกจะมุ่งเน้นที่ผู้ใช้ Cloud รุ่นแรกสุด ซึ่งเป็นนักพัฒนา App Engine (สภาพแวดล้อมมาตรฐาน) เป็นหลัก แต่ชุดโซลูชันนี้ก็กว้างพอที่จะรวมแพลตฟอร์มแบบ Serverless อื่นๆ เช่น Cloud Functions และ Cloud Run หรือแพลตฟอร์มอื่นๆ ที่เกี่ยวข้อง
วัตถุประสงค์ของ Codelab นี้คือแสดงให้นักพัฒนา Python 2 App Engine ทราบวิธีย้ายข้อมูลจากงานพุลคิวงานของ App Engine ไปยัง Cloud Pub/Sub นอกจากนี้ ยังมีการย้ายข้อมูลโดยนัยจาก App Engine NDB ไปยัง Cloud NDB สำหรับการเข้าถึง Datastore (โดยครอบคลุมอยู่ในโมดูล 2) และการอัปเกรดเป็น Python 3
ในโมดูล 18 คุณจะได้เรียนรู้วิธีเพิ่มการใช้งานงานพุลในแอป ในโมดูลนี้ คุณจะได้ใช้แอปโมดูล 18 ที่เสร็จสมบูรณ์แล้ว และย้ายข้อมูลการใช้งานดังกล่าวไปยัง Cloud Pub/Sub ผู้ที่ใช้คิวงานสำหรับงานพุชจะย้ายข้อมูลไปยัง Cloud Tasks แทน และควรอ้างอิงโมดูล 7-9 แทน
คุณจะได้เรียนรู้วิธีต่อไปนี้
- แทนที่การใช้คิวงานของ App Engine (การดึงงาน) ด้วย Cloud Pub/Sub
- แทนที่การใช้ App Engine NDB ด้วย Cloud NDB (โปรดดูโมดูล 2 ด้วย)
- ย้ายแอปไปยัง Python 3
สิ่งที่ต้องมี
- โปรเจ็กต์ Google Cloud Platform ที่มีบัญชีสำหรับการเรียกเก็บเงิน GCP ที่ใช้งานอยู่
- ทักษะพื้นฐานเรื่อง Python
- ความรู้เกี่ยวกับคำสั่งทั่วไปของ Linux
- ความรู้พื้นฐานเกี่ยวกับการพัฒนาและการทำให้แอป App Engine ใช้งานได้
- ตัวอย่างแอปโมดูล 18 ของ App Engine ที่ใช้งานได้
แบบสำรวจ
คุณจะใช้บทแนะนำนี้อย่างไร
คุณจะให้คะแนนประสบการณ์การใช้งาน Python อย่างไร
คุณจะให้คะแนนความพึงพอใจในการใช้บริการ Google Cloud อย่างไร
2. ข้อมูลเบื้องต้น
คิวงานของ App Engine รองรับทั้งงานพุชและพุล หากต้องการปรับปรุงการถ่ายโอนแอปพลิเคชัน Google Cloud ขอแนะนำให้ย้ายข้อมูลจากบริการแพ็กเกจเดิม เช่น คิวงาน ไปยังบริการ Cloud แบบสแตนด์อโลนอื่นๆ หรือบริการของบุคคลที่สามที่เทียบเท่า
- ผู้ใช้งานพุชของคิวงานควรย้ายข้อมูลไปยัง Cloud Tasks
- ผู้ใช้งาน pull ของคิวงานควรย้ายข้อมูลไปยัง Cloud Pub/Sub
โมดูลการย้ายข้อมูล 7-9 ครอบคลุมการย้ายข้อมูลงานพุช ในขณะที่โมดูล 18-19 จะมุ่งเน้นที่การย้ายข้อมูลงานพุล แม้ว่างานระบบคลาวด์จะตรงกับงานพุชของคิวงานอย่างใกล้เคียงมากขึ้น แต่ Pub/Sub ก็ไม่ได้ใกล้เคียงกับงานพุลคิวงานเท่าที่ควร
Pub/Sub มีฟีเจอร์มากกว่าฟังก์ชันการดึงข้อมูลที่คิวงานมีให้ ตัวอย่างเช่น Pub/Sub ยังมีฟังก์ชันพุช แต่ Cloud Tasks จะเหมือนกับงานพุชคิวงานมากกว่า ดังนั้นการพุช Pub/Sub จึงไม่ครอบคลุมอยู่ในโมดูลการย้ายข้อมูล Codelab ของโมดูล 19 นี้สาธิตการเปลี่ยนกลไกการจัดคิวจากคิวการดึงคิวงานเป็น Pub/Sub รวมถึงการย้ายข้อมูลจาก App Engine NDB ไปยัง Cloud NDB เพื่อเข้าถึงพื้นที่เก็บข้อมูล โดยทำการย้ายข้อมูลโมดูล 2 ซ้ำ
ในขณะที่โค้ดโมดูล 18 มีการ "โฆษณา" เนื่องจากเป็นแอปตัวอย่าง Python 2 ตัวแหล่งที่มาเองก็เข้ากันได้กับ Python 2 และ 3 และจะยังคงเป็นเช่นนั้นต่อไปแม้ว่าจะย้ายข้อมูลไปยัง Cloud Pub/Sub (และ Cloud NDB) ในโมดูล 19 แล้วก็ตาม
บทแนะนำนี้มีขั้นตอนต่อไปนี้
- การตั้งค่า/งานล่วงหน้า
- อัปเดตการกำหนดค่า
- แก้ไขโค้ดของแอปพลิเคชัน
3. การตั้งค่า/งานล่วงหน้า
ส่วนนี้จะอธิบายวิธี:
- ตั้งค่าโปรเจ็กต์ที่อยู่ในระบบคลาวด์
- รับแอปตัวอย่างพื้นฐาน
- (อีกครั้ง) ติดตั้งใช้งานและตรวจสอบแอปพื้นฐาน
- เปิดใช้บริการ/API ใหม่ของ Google Cloud
ขั้นตอนเหล่านี้ช่วยให้มั่นใจว่าคุณเริ่มต้นด้วยโค้ดที่ใช้งานได้และพร้อมสำหรับการย้ายข้อมูลไปยังบริการระบบคลาวด์
1. สร้างโปรเจ็กต์
หากคุณทำ Codelab ของโมดูล 18 เสร็จแล้ว ให้ใช้โปรเจ็กต์ (และโค้ด) เดียวกันนั้นซ้ำ หรือสร้างโปรเจ็กต์ใหม่หรือใช้โปรเจ็กต์อื่นที่มีอยู่ซ้ำ ตรวจสอบว่าโปรเจ็กต์มีบัญชีสำหรับการเรียกเก็บเงินที่ใช้งานอยู่และแอป App Engine ที่เปิดใช้แล้ว หารหัสโปรเจ็กต์ตามความต้องการเพื่อนำไปใช้ในระหว่าง Codelab นี้ โดยใช้เมื่อใดก็ตามที่คุณพบตัวแปร PROJECT_ID
2. รับแอปตัวอย่างพื้นฐาน
ข้อกำหนดเบื้องต้นอย่างหนึ่งคือแอป App Engine โมดูล 18 ที่ใช้งานได้ คุณควรทำ Codelab ให้เสร็จ (แนะนำ ลิงก์ด้านบน) หรือคัดลอกโค้ดโมดูล 18 จากที่เก็บ ไม่ว่าคุณจะใช้เครื่องของคุณเองหรือของเรา นี่คือสิ่งที่เราจะเริ่มดำเนินการ ("START") Codelab นี้จะแนะนำการย้ายข้อมูล โดยสรุปด้วยโค้ดที่คล้ายคลึงกับสิ่งที่อยู่ในโฟลเดอร์ที่เก็บโมดูล 19 ("FINISH")
- START: โฟลเดอร์โมดูล 18 (Python 2)
- FINISH: โฟลเดอร์โมดูล 19 (Python 2 และ 3)
- ทั้งที่เก็บ (เพื่อโคลนหรือดาวน์โหลดไฟล์ ZIP)
ไม่ว่าคุณจะใช้แอป Module 18 แอปใด โฟลเดอร์ควรมีลักษณะตามด้านล่าง ซึ่งอาจมีโฟลเดอร์ lib
ด้วยเช่นกัน
$ ls README.md appengine_config.py queue.yaml templates app.yaml main.py requirements.txt
3. (อีกครั้ง) ติดตั้งใช้งานและตรวจสอบแอปพื้นฐาน
ดำเนินการตามขั้นตอนต่อไปนี้เพื่อทำให้แอป Module 18 ใช้งานได้
- ลบโฟลเดอร์
lib
หากมี แล้วเรียกใช้pip install -t lib -r requirements.txt
เพื่อป้อนข้อมูลlib
ใหม่ คุณอาจต้องใช้pip2
แทน หากติดตั้งทั้ง Python 2 และ 3 ไว้ในเครื่องการพัฒนาแล้ว - ตรวจสอบว่าคุณได้ติดตั้งและเริ่มต้นเครื่องมือบรรทัดคำสั่ง
gcloud
และตรวจสอบการใช้งานแล้ว - (ไม่บังคับ) ให้ตั้งค่าโปรเจ็กต์ที่อยู่ในระบบคลาวด์ด้วย
gcloud config set project
PROJECT_ID
หากไม่ต้องการป้อนPROJECT_ID
ด้วยคำสั่งgcloud
แต่ละรายการที่คุณออก - ทำให้แอปตัวอย่างใช้งานได้ด้วย
gcloud app deploy
- ยืนยันว่าแอปทำงานตามที่คาดไว้โดยไม่มีปัญหา หากคุณทำ Codelab ของโมดูล 18 เสร็จสมบูรณ์แล้ว แอปจะแสดงผู้เข้าชมอันดับสูงสุดพร้อมกับการเข้าชมล่าสุด (ภาพด้านล่าง) หากไม่มี อาจไม่มีการนับผู้เข้าชมให้แสดง
ก่อนย้ายแอปตัวอย่างโมดูล 18 คุณต้องเปิดใช้บริการระบบคลาวด์ที่แอปที่แก้ไขแล้วจะใช้ก่อน
4. เปิดใช้บริการ/API ใหม่ของ Google Cloud
แอปเดิมใช้บริการแพ็กเกจของ App Engine ซึ่งไม่ต้องมีการตั้งค่าเพิ่มเติม แต่บริการระบบคลาวด์แบบสแตนด์อโลนต้องใช้ทั้ง Cloud Pub/Sub และ Cloud Datastore (ผ่านไลบรารีไคลเอ็นต์ Cloud NDB) App Engine และ Cloud APIs ทั้งสองมี "ฟรีเสมอ" โควต้า และตราบใดที่คุณยังใช้งานไม่เกินขีดจำกัดดังกล่าว คุณไม่ควรเสียค่าใช้จ่ายเมื่อดูบทแนะนำนี้จนจบ เปิดใช้ Cloud APIs ได้จาก Cloud Console หรือจากบรรทัดคำสั่งก็ได้ ทั้งนี้ขึ้นอยู่กับค่ากำหนดของคุณ
จาก Cloud Console
ไปที่หน้าไลบรารีของตัวจัดการ API (สำหรับโปรเจ็กต์ที่ถูกต้อง) ใน Cloud Console แล้วค้นหา API ของ Cloud Datastore และ Cloud Pub/Sub โดยใช้แถบค้นหาตรงกลางหน้า
คลิกปุ่มเปิดใช้สำหรับ API แต่ละรายการแยกกัน คุณอาจได้รับแจ้งให้ใส่ข้อมูลสำหรับการเรียกเก็บเงิน ลองดูตัวอย่างหน้าไลบรารี Cloud Pub/Sub API ดังนี้
จากบรรทัดคำสั่ง
แม้ว่าฟีเจอร์นี้จะทำให้แสดง API ต่างๆ ได้จากคอนโซลอย่างชัดเจน แต่บางรายก็เลือกใช้บรรทัดคำสั่งมากกว่า ออกคำสั่ง gcloud services enable pubsub.googleapis.com datastore.googleapis.com
เพื่อเปิดใช้ API ทั้งสองพร้อมกันดังนี้
$ gcloud services enable pubsub.googleapis.com datastore.googleapis.com Operation "operations/acat.p2-aaa-bbb-ccc-ddd-eee-ffffff" finished successfully.
ระบบอาจแจ้งให้คุณใส่ข้อมูลสำหรับการเรียกเก็บเงิน หากคุณต้องการเปิดใช้ Cloud API อื่นๆ และต้องการทราบ URI ของ API เหล่านั้น โปรดไปที่ด้านล่างของหน้าไลบรารีของ API แต่ละหน้า เช่น สังเกต pubsub.googleapis.com
เป็น "ชื่อบริการ" ที่ด้านล่างของหน้า Pub/Sub ด้านบน
หลังจากทำตามขั้นตอนเรียบร้อยแล้ว โปรเจ็กต์จะเข้าถึง API ได้ ตอนนี้ถึงเวลาอัปเดตแอปพลิเคชันเพื่อใช้ API เหล่านั้นแล้ว
4. สร้างทรัพยากร Pub/Sub
สรุปลำดับของเวิร์กโฟลว์คิวงานจากโมดูล 18 ดังนี้
- โมดูล 18 ใช้ไฟล์
queue.yaml
เพื่อสร้างคิวพุลชื่อpullq
- แอปจะเพิ่มงานลงในพุลคิวเพื่อติดตามผู้เข้าชม
- ในท้ายที่สุด งานจะได้รับการประมวลผลโดยผู้ปฏิบัติงาน โดยให้เช่าเป็นระยะเวลาจำกัด (1 ชั่วโมง)
- โดยระบบจะดำเนินการเพื่อรวมจำนวนผู้เข้าชมล่าสุด
- งานจะถูกลบออกจากคิวเมื่อเสร็จสิ้น
คุณกำลังจะทำซ้ำเวิร์กโฟลว์ที่คล้ายกันด้วย Pub/Sub ส่วนถัดไปจะแนะนำคำศัพท์เกี่ยวกับ Pub/Sub พื้นฐาน พร้อมกับวิธีสร้างทรัพยากร Pub/Sub ที่จำเป็นใน 3 วิธี
คิวงานของ App Engine (แบบพุล) กับคำศัพท์ของ Cloud Pub/Sub
การเปลี่ยนไปใช้ Pub/Sub ต้องมีการปรับเปลี่ยนคำศัพท์เล็กน้อย รายการด้านล่างนี้คือหมวดหมู่หลักพร้อมด้วยคำที่เกี่ยวข้องจากผลิตภัณฑ์ทั้งสอง และอ่านคำแนะนำในการย้ายข้อมูลซึ่งมีข้อมูลการเปรียบเทียบที่คล้ายกัน
- โครงสร้างข้อมูลการจัดคิว: ข้อมูลในคิวงานจะเข้าไปอยู่ในพุลคิว เมื่อใช้ Pub/Sub ข้อมูลจะอยู่ในหัวข้อ
- หน่วยของข้อมูลที่อยู่ในคิว: พุลงานด้วยคิวงานจะเรียกว่าข้อความด้วย Pub/Sub
- ผู้ประมวลผลข้อมูล: เมื่อใช้คิวงาน ผู้ปฏิบัติงานจะเข้าถึงงานพุลได้ สำหรับ Pub/Sub คุณต้องมีการสมัครใช้บริการ/ผู้สมัครใช้บริการจึงจะรับข้อความได้
- การดึงข้อมูล: การเช่างานการดึงข้อมูลจะเหมือนกับการดึงข้อมูลข้อความจากหัวข้อ (ผ่านการสมัครใช้บริการ)
- การล้างข้อมูล/การดำเนินการให้เสร็จสมบูรณ์: การลบงานในคิวงานออกจากพุลคิวเมื่อดำเนินการเสร็จแล้ว จะคล้ายกับการรับทราบข้อความ Pub/Sub
แม้ว่าผลิตภัณฑ์ที่อยู่ในคิวจะเปลี่ยนไป แต่เวิร์กโฟลว์จะค่อนข้างคล้ายคลึงกัน ดังนี้
- แอปจะใช้หัวข้อชื่อ
pullq
แทนที่จะเป็นพุลคิว - แอปจะส่งข้อความไปยังหัวข้อ (
pullq
) แทนการเพิ่มงานลงในพุลคิว - ผู้สมัครตั้งชื่อ
worker
ดึงข้อความจากหัวข้อpullq
แทนที่จะเป็นผู้ปฏิบัติงานที่เช่างานจากพุลคิว - แอปจะประมวลผลเพย์โหลดของข้อความ ซึ่งเป็นการเพิ่มจำนวนผู้เข้าชมใน Datastore
- แอปจะรับทราบข้อความที่ประมวลผลแล้ว แทนที่จะลบงานออกจากพุลคิว
เมื่อใช้คิวงาน การตั้งค่าจะต้องมีการสร้างพุลคิว เมื่อใช้ Pub/Sub การตั้งค่าจะต้องมีการสร้างทั้งหัวข้อและการสมัครใช้บริการ ในโมดูล 18 เราได้ประมวลผล queue.yaml
นอกเหนือการดำเนินการของแอป ก็จะต้องทำเหมือนกับ Pub/Sub
การสร้างหัวข้อและการสมัครใช้บริการมี 3 ตัวเลือก ดังนี้
- จาก Cloud Console
- จากบรรทัดคำสั่ง หรือ
- จากโค้ด (สคริปต์ Python แบบสั้น)
เลือก 1 ตัวเลือกจากด้านล่าง แล้วทำตามวิธีการที่เกี่ยวข้องเพื่อสร้างทรัพยากร Pub/Sub
จาก Cloud Console
หากต้องการสร้างหัวข้อจาก Cloud Console ให้ทำตามขั้นตอนต่อไปนี้
- ไปที่หน้าหัวข้อ Pub/Sub ของ Cloud Console
- คลิกสร้างหัวข้อที่ด้านบน หน้าต่างกล่องโต้ตอบใหม่จะเปิดขึ้น (ดูรูปภาพด้านล่าง)
- ป้อน
pullq
ในช่องรหัสหัวข้อ - ยกเลิกการเลือกตัวเลือกที่เลือกไว้ทั้งหมด แล้วเลือกคีย์การเข้ารหัสที่จัดการโดย Google
- คลิกปุ่มสร้างหัวข้อ
กล่องโต้ตอบการสร้างหัวข้อจะมีลักษณะดังนี้
เมื่อคุณมีหัวข้อแล้ว คุณต้องสร้างการสมัครรับข้อมูลสำหรับหัวข้อนั้น โดยทำดังนี้
- ไปที่หน้าการสมัครใช้บริการ Pub/Sub ของ Cloud Console
- คลิกสร้างการสมัครใช้บริการที่ด้านบน (ดูรูปภาพด้านล่าง)
- ป้อน
worker
ในช่องรหัสการสมัครใช้บริการ - เลือก
pullq
จากรายการแบบเลื่อนลง เลือกหัวข้อ Cloud Pub/Sub โดยให้จดจำ "ชื่อเส้นทางที่มีคุณสมบัติครบถ้วน" ตัวอย่างเช่นprojects/PROJECT_ID/topics/pullq
- สำหรับประเภทการนำส่ง ให้เลือกพุล
- ปล่อยตัวเลือกอื่นทั้งหมดไว้ตามเดิม แล้วคลิกปุ่มสร้าง
หน้าจอสร้างการสมัครใช้บริการจะมีลักษณะดังนี้
นอกจากนี้คุณสามารถสร้างการสมัครรับข้อมูลจากหน้าหัวข้อ ซึ่งเป็น "ทางลัด" นี้ อาจเป็นประโยชน์สำหรับคุณในการช่วยเชื่อมโยงหัวข้อเข้ากับการสมัครใช้บริการ ดูข้อมูลเพิ่มเติมเกี่ยวกับการสร้างการสมัครใช้บริการได้ในเอกสารประกอบ
จากบรรทัดคำสั่ง
ผู้ใช้ Pub/Sub จะสร้างหัวข้อและการสมัครใช้บริการได้ด้วยคำสั่ง gcloud pubsub topics create
TOPIC_ID
และ gcloud pubsub subscriptions create
SUBSCRIPTION_ID
--topic=
TOPIC_ID
ตามลำดับ การดำเนินการเหล่านี้ด้วย TOPIC_ID
ของ pullq
และ SUBSCRIPTION_ID
จาก worker
จะทำให้เกิดเอาต์พุตต่อไปนี้สำหรับโปรเจ็กต์ PROJECT_ID
:
$ gcloud pubsub topics create pullq Created topic [projects/PROJECT_ID/topics/pullq]. $ gcloud pubsub subscriptions create worker --topic=pullq Created subscription [projects/PROJECT_ID/subscriptions/worker].
โปรดดูหน้านี้ในเอกสารประกอบของ Quickstart การใช้บรรทัดคำสั่งอาจช่วยลดความซับซ้อนของเวิร์กโฟลว์ที่มีการสร้างหัวข้อและการสมัครใช้บริการเป็นประจำ ทั้งยังสามารถใช้คำสั่งดังกล่าวในสคริปต์ Shell เพื่อวัตถุประสงค์นี้ได้
จากโค้ด (สคริปต์ Python แบบสั้น)
อีกวิธีหนึ่งในการสร้างหัวข้อและการสมัครใช้บริการโดยอัตโนมัติคือการใช้ Pub/Sub API ในซอร์สโค้ด ด้านล่างนี้คือโค้ดสำหรับสคริปต์ maker.py
ในโฟลเดอร์ที่เก็บโมดูล 19
from __future__ import print_function
import google.auth
from google.api_core import exceptions
from google.cloud import pubsub
_, PROJECT_ID = google.auth.default()
TOPIC = 'pullq'
SBSCR = 'worker'
ppc_client = pubsub.PublisherClient()
psc_client = pubsub.SubscriberClient()
TOP_PATH = ppc_client.topic_path(PROJECT_ID, TOPIC)
SUB_PATH = psc_client.subscription_path(PROJECT_ID, SBSCR)
def make_top():
try:
top = ppc_client.create_topic(name=TOP_PATH)
print('Created topic %r (%s)' % (TOPIC, top.name))
except exceptions.AlreadyExists:
print('Topic %r already exists at %r' % (TOPIC, TOP_PATH))
def make_sub():
try:
sub = psc_client.create_subscription(name=SUB_PATH, topic=TOP_PATH)
print('Subscription created %r (%s)' % (SBSCR, sub.name))
except exceptions.AlreadyExists:
print('Subscription %r already exists at %r' % (SBSCR, SUB_PATH))
try:
psc_client.close()
except AttributeError: # special Py2 handler for grpcio<1.12.0
pass
make_top()
make_sub()
การเรียกใช้สคริปต์จะทำให้ได้เอาต์พุตตามที่คาดไว้ (หากไม่มีข้อผิดพลาด)
$ python3 maker.py Created topic 'pullq' (projects/PROJECT_ID/topics/pullq) Subscription created 'worker' (projects/PROJECT_ID/subscriptions/worker)
การเรียก API เพื่อสร้างทรัพยากรที่มีอยู่แล้วจะทำให้มีข้อยกเว้น google.api_core.exceptions.AlreadyExists
จากไลบรารีของไคลเอ็นต์ที่จัดการด้วยสคริปต์อย่างสวยงาม:
$ python3 maker.py Topic 'pullq' already exists at 'projects/PROJECT_ID/topics/pullq' Subscription 'worker' already exists at 'projects/PROJECT_ID/subscriptions/worker'
หากคุณเพิ่งเริ่มใช้ Pub/Sub โปรดดูเอกสารประกอบเกี่ยวกับสถาปัตยกรรม Pub/Sub เพื่อดูข้อมูลเชิงลึกเพิ่มเติม
5. อัปเดตการกำหนดค่า
การอัปเดตในการกำหนดค่าจะรวมทั้งการเปลี่ยนไฟล์การกำหนดค่าต่างๆ และการสร้างเทียบเท่ากับคิวพุลของ App Engine แต่อยู่ในระบบนิเวศ Cloud Pub/Sub
ลบQueue.yaml
เรากำลังจะย้ายออกจากคิวงานทั้งหมด ดังนั้นโปรดลบ queue.yaml
เนื่องจาก Pub/Sub ไม่ได้ใช้ไฟล์นี้ คุณจะสร้างหัวข้อ Pub/Sub (และการสมัครใช้บริการ) แทนการสร้างพุลคิว
requirements.txt
เพิ่ม google-cloud-ndb
และ google-cloud-pubsub
ต่อท้าย requirements.txt
เพื่อเข้าร่วม flask
จากโมดูล 18 โมดูล 19 requirements.txt
ที่อัปเดตแล้วของคุณควรมีลักษณะดังนี้
flask
google-cloud-ndb
google-cloud-pubsub
ไฟล์ requirements.txt
นี้ไม่มีหมายเลขเวอร์ชันใดๆ ซึ่งหมายความว่าระบบจะเลือกเวอร์ชันล่าสุดไว้ หากเกิดปัญหาเข้ากันไม่ได้ ให้ทำตามแนวทางปฏิบัติมาตรฐานในการใช้หมายเลขเวอร์ชันเพื่อล็อกเวอร์ชันที่ใช้งานได้ของแอป
app.yaml
การเปลี่ยนแปลงใน app.yaml
จะแตกต่างกันไป โดยขึ้นอยู่กับว่าคุณใช้ Python 2 ต่อไปหรืออัปเกรดเป็น Python 3
Python 2
การอัปเดต requirements.txt
ข้างต้นจะเพิ่มการใช้ไลบรารีของไคลเอ็นต์ Google Cloud รายการเหล่านี้ต้องมีการสนับสนุนเพิ่มเติมจาก App Engine อันได้แก่ ไลบรารีในตัว 2 รายการ setuptools
และ grpcio
การใช้ไลบรารีในตัวต้องมีส่วน libraries
ใน app.yaml
และหมายเลขเวอร์ชันไลบรารี หรือ "ล่าสุด" สำหรับข้อมูลล่าสุดที่พร้อมใช้งานในเซิร์ฟเวอร์ App Engine โมดูล 18 app.yaml
ยังไม่มีส่วนดังกล่าว:
ก่อนหน้า:
runtime: python27
threadsafe: yes
api_version: 1
handlers:
- url: /.*
script: main.app
เพิ่มส่วน libraries
ใน app.yaml
พร้อมด้วยรายการสำหรับทั้ง setuptools
และ grpcio
โดยเลือกเวอร์ชันล่าสุด เพิ่มรายการ runtime
ของตัวยึดตำแหน่งสำหรับ Python 3 ซึ่งแสดงความคิดเห็นพร้อมกับรุ่น 3.x ในปัจจุบัน เช่น 3.10 ณ เวลาที่เขียนนี้ การเปลี่ยนแปลงเหล่านี้จะทำให้ app.yaml
มีลักษณะเช่นนี้
หลัง:
#runtime: python310
runtime: python27
threadsafe: yes
api_version: 1
handlers:
- url: /.*
script: main.app
libraries:
- name: setuptools
version: latest
- name: grpcio
version: latest
งูหลาม 3
สำหรับผู้ใช้ Python 3 และ app.yaml
ทั้งหมดนี้เป็นเรื่องของการนำสิ่งต่างๆ ออก ในส่วนนี้ คุณจะลบส่วน handlers
, คำสั่ง threadsafe
และ api_version
และจะไม่สร้างส่วน libraries
รันไทม์รุ่นที่ 2 ไม่มีไลบรารีของบุคคลที่สามในตัว จึงไม่จำเป็นต้องใช้ส่วน libraries
ใน app.yaml
นอกจากนี้ คุณไม่จำเป็นต้องคัดลอก (บางครั้งเรียกว่าการเป็นผู้ให้บริการหรือการรวมกลุ่มอีเมลด้วยตนเอง) แพ็กเกจของบุคคลที่สามที่ไม่มีในตัวอีกต่อไป คุณจำเป็นต้องแสดงไลบรารีของบุคคลที่สามที่แอปของคุณใช้ใน requirements.txt
เท่านั้น
ส่วน handlers
ใน app.yaml
มีไว้สำหรับการระบุแอปพลิเคชัน (สคริปต์) และตัวแฮนเดิลไฟล์แบบคงที่ เนื่องจากรันไทม์ของ Python 3 ต้องใช้เว็บเฟรมเวิร์กเพื่อดำเนินการกำหนดเส้นทางของตนเอง ตัวแฮนเดิลสคริปต์ทั้งหมดต้องเปลี่ยนเป็น auto
หากแอป (เช่น โมดูล 18) ไม่แสดงไฟล์แบบคงที่ เส้นทางทั้งหมดจะเป็น auto
ซึ่งทำให้เส้นทางไม่เกี่ยวข้อง ด้วยเหตุนี้ ส่วน handlers
จึงไม่จำเป็นเช่นกัน ให้ลบส่วนดังกล่าว
สุดท้าย ไม่ได้ใช้คำสั่ง threadsafe
และ api_version
ใน Python 3 ให้ลบคำสั่งเหล่านั้นด้วย สรุปง่ายๆ ก็คือ คุณควรลบทุกส่วนของ app.yaml
เพื่อให้มีเฉพาะคำสั่ง runtime
เท่านั้น ซึ่งระบุ Python 3 เวอร์ชันใหม่ เช่น 3.10 นี่คือลักษณะของ app.yaml
ก่อนและหลังการอัปเดต
ก่อนหน้า:
runtime: python27
threadsafe: yes
api_version: 1
handlers:
- url: /.*
script: main.app
หลัง:
runtime: python310
สำหรับผู้ที่ยังไม่พร้อมที่จะลบข้อมูลทั้งหมดจาก app.yaml
สำหรับ Python 3 เราได้จัดเตรียมไฟล์สำรองขนาด app3.yaml
ไว้ในโฟลเดอร์ที่เก็บโมดูล 19 หากต้องการใช้แทนสำหรับการทำให้ใช้งานได้ โปรดเพิ่มชื่อไฟล์นี้ต่อท้ายคำสั่ง: gcloud app deploy app3.yaml
(มิฉะนั้น แอปจะใช้ค่าเริ่มต้นและทำให้ใช้งานได้ด้วยไฟล์ Python 2 app.yaml
ที่คุณไม่เปลี่ยนแปลง)
appengine_config.py
หากอัปเกรดเป็น Python 3 คุณไม่จำเป็นต้องใช้ appengine_config.py
โปรดลบก่อน สาเหตุที่ไม่จำเป็นคือการรองรับไลบรารีของบุคคลที่สามกำหนดให้ระบุใน requirements.txt
เท่านั้น ผู้ใช้ Python 2 โปรดอ่านต่อไป
โมดูล 18 appengine_config.py
มีโค้ดที่เหมาะสมเพื่อรองรับไลบรารีของบุคคลที่สาม ตัวอย่างเช่น Flask และไลบรารีของไคลเอ็นต์ระบบคลาวด์ที่เพิ่งเพิ่มลงใน requirements.txt
:
ก่อนหน้า:
from google.appengine.ext import vendor
# Set PATH to your libraries folder.
PATH = 'lib'
# Add libraries installed in the PATH folder.
vendor.add(PATH)
อย่างไรก็ตาม โค้ดนี้เพียงอย่างเดียวไม่เพียงพอที่จะรองรับไลบรารีในตัวที่เพิ่งเพิ่มเข้ามา (setuptools
, grpcio
) ต้องใช้เพิ่มอีก 2-3 บรรทัด ดังนั้น ให้อัปเดต appengine_config.py
ให้มีลักษณะดังนี้
หลัง:
import pkg_resources
from google.appengine.ext import vendor
# Set PATH to your libraries folder.
PATH = 'lib'
# Add libraries installed in the PATH folder.
vendor.add(PATH)
# Add libraries to pkg_resources working set to find the distribution.
pkg_resources.working_set.add_entry(PATH)
ดูรายละเอียดเพิ่มเติมเกี่ยวกับการเปลี่ยนแปลงที่จําเป็นเพื่อรองรับไลบรารีของไคลเอ็นต์ Cloud ได้ในเอกสารประกอบของการย้ายข้อมูลในแพ็กเกจบริการ
การอัปเดตการกำหนดค่าอื่นๆ
หากคุณมีโฟลเดอร์ lib
ให้ลบออก หากคุณเป็นผู้ใช้ Python 2 ให้เติมข้อมูลโฟลเดอร์ lib
ด้วยการออกคำสั่งต่อไปนี้
pip install -t lib -r requirements.txt # or pip2
หากติดตั้งทั้ง Python 2 และ 3 ไว้ในระบบการพัฒนาแล้ว คุณอาจต้องใช้ pip2
แทน pip
6. แก้ไขโค้ดของแอปพลิเคชัน
ส่วนนี้จะแสดงการอัปเดตไฟล์แอปพลิเคชันหลัก main.py
โดยแทนที่การใช้การดึงคิวงานของ App Engine ด้วย Cloud Pub/Sub ไม่มีการเปลี่ยนแปลงกับเทมเพลตเว็บ templates/index.html
ทั้ง 2 แอปควรทำงานเหมือนกันและแสดงข้อมูลเหมือนกัน
อัปเดตการนำเข้าและการเริ่มต้น
มีการอัปเดตการนำเข้าและการเริ่มต้นหลายรายการ ดังนี้
- สำหรับการนำเข้า ให้แทนที่ App Engine NDB และคิวงานด้วย Cloud NDB และ Pub/Sub
- เปลี่ยนชื่อ
pullq
จากชื่อQUEUE
เป็นชื่อTOPIC
- เมื่อใช้งานพุล พนักงานจะเช่างานดังกล่าวเป็นเวลา 1 ชั่วโมง แต่เมื่อใช้ Pub/Sub จะมีการวัดระยะหมดเวลาเป็นรายข้อความ ดังนั้นให้ลบค่าคงที่
HOUR
- Cloud APIs จำเป็นต้องใช้ไคลเอ็นต์ API ดังนั้นให้เริ่มต้น API เหล่านั้นสำหรับ Cloud NDB และ Cloud Pub/Sub โดยให้ไคลเอ็นต์ทั้งในส่วนของหัวข้อและการสมัครรับข้อมูล
- Pub/Sub ต้องใช้รหัสโปรเจ็กต์ที่อยู่ในระบบคลาวด์ ดังนั้น โปรดนำเข้าและรับรหัสจาก
google.auth.default()
- Pub/Sub ต้องการ "ชื่อพาธที่สมบูรณ์ในตัวเอง" สำหรับหัวข้อและการสมัครใช้บริการ ดังนั้นโปรดสร้างรายการโดยใช้ฟังก์ชันอำนวยความสะดวกของ
*_path()
ด้านล่างนี้คือการนำเข้าและการเริ่มต้นจากโมดูล 18 ตามด้วยวิธีที่ส่วนต่างๆ ควรดูแลหลังจากนำการเปลี่ยนแปลงข้างต้นไปใช้ โดยโค้ดใหม่ส่วนใหญ่เป็นทรัพยากร Pub/Sub ที่หลากหลาย
ก่อนหน้า:
from flask import Flask, render_template, request
from google.appengine.api import taskqueue
from google.appengine.ext import ndb
HOUR = 3600
LIMIT = 10
TASKS = 1000
QNAME = 'pullq'
QUEUE = taskqueue.Queue(QNAME)
app = Flask(__name__)
หลัง:
from flask import Flask, render_template, request
import google.auth
from google.cloud import ndb, pubsub
LIMIT = 10
TASKS = 1000
TOPIC = 'pullq'
SBSCR = 'worker'
app = Flask(__name__)
ds_client = ndb.Client()
ppc_client = pubsub.PublisherClient()
psc_client = pubsub.SubscriberClient()
_, PROJECT_ID = google.auth.default()
TOP_PATH = ppc_client.topic_path(PROJECT_ID, TOPIC)
SUB_PATH = psc_client.subscription_path(PROJECT_ID, SBSCR)
ไปที่การอัปเดตโมเดลข้อมูล
โมเดลข้อมูล Visit
จะไม่เปลี่ยนแปลง การเข้าถึงพื้นที่เก็บข้อมูลต้องใช้การจัดการบริบทของไคลเอ็นต์ Cloud NDB API อย่างชัดเจน ds_client.context()
ในโค้ด การดำเนินการนี้หมายความว่าคุณรวมการเรียกใช้ Datastore ทั้งใน store_visit()
และ fetch_visits()
ภายในบล็อก Python with
การอัปเดตนี้เหมือนกับสิ่งที่กล่าวถึงในโมดูล 2
การเปลี่ยนแปลงที่เกี่ยวข้องที่สุดสำหรับ Pub/Sub คือการแทนที่การจัดคิวของงานพุลคิวงานด้วยการเผยแพร่ข้อความ Pub/Sub ไปยังหัวข้อ pullq
ด้านล่างนี้เป็นโค้ดก่อนและหลังทำการอัปเดตเหล่านี้
ก่อนหน้า:
class Visit(ndb.Model):
'Visit entity registers visitor IP address & timestamp'
visitor = ndb.StringProperty()
timestamp = ndb.DateTimeProperty(auto_now_add=True)
def store_visit(remote_addr, user_agent):
'create new Visit in Datastore and queue request to bump visitor count'
Visit(visitor='{}: {}'.format(remote_addr, user_agent)).put()
QUEUE.add(taskqueue.Task(payload=remote_addr, method='PULL'))
def fetch_visits(limit):
'get most recent visits'
return Visit.query().order(-Visit.timestamp).fetch(limit)
หลัง:
class Visit(ndb.Model):
'Visit entity registers visitor IP address & timestamp'
visitor = ndb.StringProperty()
timestamp = ndb.DateTimeProperty(auto_now_add=True)
def store_visit(remote_addr, user_agent):
'create new Visit in Datastore and queue request to bump visitor count'
with ds_client.context():
Visit(visitor='{}: {}'.format(remote_addr, user_agent)).put()
ppc_client.publish(TOP_PATH, remote_addr.encode('utf-8'))
def fetch_visits(limit):
'get most recent visits'
with ds_client.context():
return Visit.query().order(-Visit.timestamp).fetch(limit)
การอัปเดตโมเดลข้อมูลจำนวนผู้เข้าชม
โมเดลข้อมูล VisitorCount
จะไม่เปลี่ยนแปลงและ fetch_counts()
ยกเว้นการรวมการค้นหา Datastore ไว้ในบล็อก with
ดังที่แสดงด้านล่าง
ก่อนหน้า:
class VisitorCount(ndb.Model):
visitor = ndb.StringProperty(repeated=False, required=True)
counter = ndb.IntegerProperty()
def fetch_counts(limit):
'get top visitors'
return VisitorCount.query().order(-VisitorCount.counter).fetch(limit)
หลัง:
class VisitorCount(ndb.Model):
visitor = ndb.StringProperty(repeated=False, required=True)
counter = ndb.IntegerProperty()
def fetch_counts(limit):
'get top visitors'
with ds_client.context():
return VisitorCount.query().order(-VisitorCount.counter).fetch(limit)
อัปเดตรหัสผู้ปฏิบัติงาน
รหัสผู้ปฏิบัติงานจะอัปเดตไปมากถึงการแทนที่ NDB ด้วย Cloud NDB และคิวงานด้วย Pub/Sub แต่เวิร์กโฟลว์จะยังคงเหมือนเดิม
- รวมการเรียกใช้ Datastore ในบล็อก
with
ของเครื่องมือจัดการบริบท Cloud NDB - การล้างข้อมูลคิวงานจะเกี่ยวข้องกับการลบงานทั้งหมดออกจากพุลคิว เมื่อใช้ Pub/Sub "รหัสการตอบรับ" ได้รับการรวบรวมใน
acks
และจากนั้นก็ลบ/รับทราบในตอนท้าย - งานพุลคิวงานจะเช่าในลักษณะเดียวกับการดึงข้อมูลข้อความ Pub/Sub แม้ว่าการลบงานพุลจะดำเนินการกับออบเจ็กต์งานด้วยตัวเอง แต่ข้อความ Pub/Sub จะถูกลบผ่านรหัสการรับรู้
- เพย์โหลดข้อความ Pub/Sub ต้องการไบต์ (ไม่ใช่สตริง Python) ดังนั้นจึงมีการเข้ารหัสและการถอดรหัสแบบ UTF-8 บางอย่างเมื่อเผยแพร่และดึงข้อความจากหัวข้อตามลำดับ
แทนที่ log_visitors()
ด้วยโค้ดที่อัปเดตแล้วด้านล่าง เพื่อใช้การเปลี่ยนแปลงที่เพิ่งอธิบายไว้
ก่อนหน้า:
@app.route('/log')
def log_visitors():
'worker processes recent visitor counts and updates them in Datastore'
# tally recent visitor counts from queue then delete those tasks
tallies = {}
tasks = QUEUE.lease_tasks(HOUR, TASKS)
for task in tasks:
visitor = task.payload
tallies[visitor] = tallies.get(visitor, 0) + 1
if tasks:
QUEUE.delete_tasks(tasks)
# increment those counts in Datastore and return
for visitor in tallies:
counter = VisitorCount.query(VisitorCount.visitor == visitor).get()
if not counter:
counter = VisitorCount(visitor=visitor, counter=0)
counter.put()
counter.counter += tallies[visitor]
counter.put()
return 'DONE (with %d task[s] logging %d visitor[s])\r\n' % (
len(tasks), len(tallies))
หลัง:
@app.route('/log')
def log_visitors():
'worker processes recent visitor counts and updates them in Datastore'
# tally recent visitor counts from queue then delete those tasks
tallies = {}
acks = set()
rsp = psc_client.pull(subscription=SUB_PATH, max_messages=TASKS)
msgs = rsp.received_messages
for rcvd_msg in msgs:
acks.add(rcvd_msg.ack_id)
visitor = rcvd_msg.message.data.decode('utf-8')
tallies[visitor] = tallies.get(visitor, 0) + 1
if acks:
psc_client.acknowledge(subscription=SUB_PATH, ack_ids=acks)
try:
psc_client.close()
except AttributeError: # special handler for grpcio<1.12.0
pass
# increment those counts in Datastore and return
if tallies:
with ds_client.context():
for visitor in tallies:
counter = VisitorCount.query(VisitorCount.visitor == visitor).get()
if not counter:
counter = VisitorCount(visitor=visitor, counter=0)
counter.put()
counter.counter += tallies[visitor]
counter.put()
return 'DONE (with %d task[s] logging %d visitor[s])\r\n' % (
len(msgs), len(tallies))
ไม่มีการเปลี่ยนแปลงเครื่องจัดการแอปพลิเคชันหลัก root()
คุณไม่จำเป็นต้องทำการเปลี่ยนแปลงใดๆ ในไฟล์เทมเพลต HTML templates/index.html
ดังนั้น นี่จึงรวมการอัปเดตที่จำเป็นทั้งหมดไว้ ขอแสดงความยินดีกับการเข้าสู่แอปพลิเคชันโมดูล 19 ใหม่โดยใช้ Cloud Pub/Sub
7. สรุป/ล้างข้อมูล
ทำให้แอปใช้งานได้เพื่อยืนยันว่าแอปทำงานตามที่ต้องการและแสดงในผลลัพธ์ใดๆ ก็ตามที่แสดงขึ้น ให้ผู้ปฏิบัติงานประมวลผลจำนวนผู้เข้าชมด้วย หลังจากตรวจสอบแอปแล้ว ให้ทำตามขั้นตอนการทำความสะอาดและพิจารณาขั้นตอนถัดไป
ติดตั้งใช้งานและยืนยันแอปพลิเคชัน
ตรวจสอบว่าคุณได้สร้างหัวข้อ pullq
และการสมัครใช้บริการ worker
แล้ว หากการดำเนินการดังกล่าวเสร็จสมบูรณ์และแอปตัวอย่างพร้อมใช้งานแล้ว ให้ทำให้แอปใช้งานได้ด้วย gcloud app deploy
ผลลัพธ์ควรจะเหมือนกับแอปโมดูล 18 เว้นแต่ว่าคุณได้แทนที่กลไกการจัดคิวที่สำคัญทั้งหมดเรียบร้อยแล้ว
ขณะนี้ฟรอนท์เอนด์เว็บของแอปยืนยันว่าส่วนนี้ของแอปพลิเคชันทำงานได้แล้ว แม้ว่าส่วนนี้ของแอปจะสามารถค้นหาและแสดงผู้เข้าชมอันดับต้นๆ และการเข้าชมครั้งล่าสุดได้สำเร็จ แต่แอปจะบันทึกการเข้าชมนี้พร้อมกับสร้างงานพุลเพื่อเพิ่มผู้เข้าชมรายนี้ลงในจำนวนโดยรวม งานดังกล่าวอยู่ในคิวรอการประมวลผลแล้ว
คุณสามารถดำเนินการนี้ด้วยบริการแบ็กเอนด์ของ App Engine, งาน cron
, เรียกดู /log
หรือออกคำขอ HTTP แบบบรรทัดคำสั่ง ต่อไปนี้คือตัวอย่างการดำเนินการและการเรียกโค้ดผู้ปฏิบัติงานด้วย curl
(แทนที่ PROJECT_ID
)
$ curl https://PROJECT_ID.appspot.com/log DONE (with 1 task[s] logging 1 visitor[s])
จำนวนที่อัปเดตจะแสดงเมื่อเข้าชมเว็บไซต์ครั้งต่อไป เท่านี้ก็เรียบร้อย
ล้างข้อมูล
ทั่วไป
หากดำเนินการเสร็จแล้ว เราขอแนะนำให้คุณปิดใช้แอป App Engine เพื่อหลีกเลี่ยงการเรียกเก็บเงิน อย่างไรก็ตาม หากคุณต้องการทดสอบหรือทดลองเพิ่มเติม แพลตฟอร์ม App Engine จะมีโควต้าฟรี และตราบใดที่คุณใช้งานไม่เกินระดับการใช้งานดังกล่าว เราก็จะไม่เรียกเก็บเงิน ค่าดังกล่าวมีไว้สําหรับการประมวลผล แต่ก็อาจมีการเรียกเก็บเงินค่าบริการ App Engine ที่เกี่ยวข้องด้วย ดังนั้นโปรดดูข้อมูลเพิ่มเติมในหน้าราคา หากการย้ายข้อมูลนี้เกี่ยวข้องกับบริการระบบคลาวด์อื่นๆ ระบบจะเรียกเก็บเงินแยกต่างหาก ในทั้ง 2 กรณี หากมี โปรดดูส่วน "เฉพาะสำหรับ Codelab นี้" ด้านล่าง
เพื่อการเปิดเผยข้อมูลทั้งหมด การทำให้ใช้งานได้กับแพลตฟอร์มการประมวลผลแบบ Serverless ของ Google Cloud อย่าง App Engine จะมีค่าใช้จ่ายในการสร้างและพื้นที่เก็บข้อมูลเล็กน้อย Cloud Build มีโควต้าฟรีของตนเอง เช่นเดียวกับ Cloud Storage พื้นที่เก็บข้อมูลของรูปภาพจะใช้โควต้านั้นหมด อย่างไรก็ตาม คุณอาจอาศัยอยู่ในภูมิภาคที่ไม่มีรุ่นฟรีดังกล่าว โปรดระวังการใช้พื้นที่เก็บข้อมูลของคุณเพื่อลดค่าใช้จ่ายที่อาจเกิดขึ้น "โฟลเดอร์" เฉพาะของ Cloud Storage ที่คุณควรตรวจสอบมีดังนี้
console.cloud.google.com/storage/browser/LOC.artifacts.PROJECT_ID.appspot.com/containers/images
console.cloud.google.com/storage/browser/staging.PROJECT_ID.appspot.com
- ลิงก์พื้นที่เก็บข้อมูลด้านบนขึ้นอยู่กับ
PROJECT_ID
และ *LOC
*ของคุณ เช่น "us
" หากแอปของคุณโฮสต์ในสหรัฐอเมริกา
ในทางกลับกัน หากคุณไม่ต้องการดำเนินการกับแอปพลิเคชันนี้หรือ Codelab การย้ายข้อมูลอื่นๆ ที่เกี่ยวข้องต่อไป และต้องการลบทุกอย่างออกทั้งหมด ให้ปิดโปรเจ็กต์
เฉพาะสำหรับ Codelab นี้
บริการในรายการด้านล่างเป็นบริการเฉพาะสำหรับ Codelab นี้ โปรดดูข้อมูลเพิ่มเติมในเอกสารประกอบของผลิตภัณฑ์แต่ละรายการ
- องค์ประกอบต่างๆ ของ Cloud Pub/Sub จะมีรุ่นฟรี พิจารณาการใช้งานโดยรวมของคุณเพื่อให้ทราบได้ดียิ่งขึ้นเกี่ยวกับผลกระทบด้านค่าใช้จ่ายและดูหน้าราคาสำหรับรายละเอียดเพิ่มเติม
- บริการ App Engine Datastore ให้บริการโดย Cloud Datastore (Cloud Firestore ในโหมด Datastore) ซึ่งมีรุ่นฟรีเช่นกัน ดูข้อมูลเพิ่มเติมได้ที่หน้าราคา
ขั้นตอนถัดไป
นอกเหนือจากบทแนะนำนี้ โมดูลการย้ายข้อมูลอื่นๆ ที่มุ่งเน้นการย้ายจากบริการพร้อมแพ็กเกจแบบเดิมที่จะพิจารณามีดังนี้
- โมดูล 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
App Engine ไม่ใช่แพลตฟอร์มแบบ Serverless เพียงแพลตฟอร์มเดียวใน Google Cloud อีกต่อไป หากคุณมีแอป App Engine ขนาดเล็กหรือแอปที่มีฟังก์ชันการทำงานที่จำกัดและต้องการเปลี่ยนเป็น Microservice แบบสแตนด์อโลน หรือต้องการแตกแอปโมโนลิธให้เป็นคอมโพเนนต์ที่ใช้ซ้ำได้หลายรายการ เหตุผลที่ดีเหล่านี้ควรพิจารณาเปลี่ยนไปใช้ Cloud Functions หากการขนส่งด้วยคอนเทนเนอร์เป็นส่วนหนึ่งของเวิร์กโฟลว์การพัฒนาแอปพลิเคชัน โดยเฉพาะอย่างยิ่งหากประกอบด้วยไปป์ไลน์ CI/CD (การรวมอย่างต่อเนื่อง/การส่งมอบหรือการติดตั้งใช้งานอย่างต่อเนื่อง) ให้ลองย้ายข้อมูลไปยัง Cloud Run สถานการณ์เหล่านี้ครอบคลุมในโมดูลต่อไปนี้
- ย้ายข้อมูลจาก App Engine ไปยัง Cloud Functions: ดูโมดูล 11
- ย้ายข้อมูลจาก App Engine ไปยัง Cloud Run: ดูโมดูล 4 เพื่อสร้างคอนเทนเนอร์แอปด้วย Docker หรือโมดูล 5 เพื่อดำเนินการดังกล่าวโดยไม่ต้องมีคอนเทนเนอร์ ไม่มีความรู้เกี่ยวกับ Docker หรือ
Dockerfile
คุณจะเปลี่ยนไปใช้แพลตฟอร์มแบบ Serverless อื่นหรือไม่ก็ได้ และเราขอแนะนำให้พิจารณาตัวเลือกที่ดีที่สุดสำหรับแอปและ Use Case ของคุณก่อนทำการเปลี่ยนแปลงใดๆ
ไม่ว่าคุณจะพิจารณาโมดูลการย้ายข้อมูลใดในครั้งถัดไป คุณสามารถเข้าถึงเนื้อหาของสถานีย้ายข้อมูลแบบ Serverless (โค้ดแล็บ วิดีโอ ซอร์สโค้ด [เมื่อพร้อมให้บริการ]) ทั้งหมดได้ที่ที่เก็บโอเพนซอร์ส README
ของที่เก็บยังให้คำแนะนำเกี่ยวกับการย้ายข้อมูลที่ควรพิจารณาและ "คำสั่ง" ที่เกี่ยวข้อง โมดูลการย้ายข้อมูล
8. แหล่งข้อมูลเพิ่มเติม
รายการด้านล่างนี้เป็นแหล่งข้อมูลเพิ่มเติมสำหรับนักพัฒนาซอฟต์แวร์ที่ศึกษาเพิ่มเติมเกี่ยวกับโมดูลการย้ายข้อมูลนี้หรือที่เกี่ยวข้อง รวมถึงผลิตภัณฑ์ที่เกี่ยวข้อง ซึ่งรวมถึงพื้นที่สำหรับแสดงความคิดเห็นเกี่ยวกับเนื้อหานี้ ลิงก์ไปยังโค้ด และเอกสารประกอบต่างๆ ที่อาจเป็นประโยชน์กับคุณ
ปัญหา/ความคิดเห็นของ Codelab
หากมีปัญหาใดๆ เกี่ยวกับ Codelab นี้ โปรดค้นหาปัญหาของคุณก่อนยื่น ลิงก์สำหรับค้นหาและสร้างปัญหาใหม่
ทรัพยากรการย้ายข้อมูล
ดูลิงก์ไปยังโฟลเดอร์ที่เก็บสำหรับโมดูล 18 (START) และโมดูล 19 (FINISH) ได้ในตารางด้านล่าง
Codelab | Python 2 | Python 3 |
(ไม่มี) | ||
โมดูล 19 (Codelab นี้) | (เหมือนกับ Python 2 ยกเว้น app3.yaml เว้นแต่คุณจะอัปเดต app.yaml ตามที่ระบุข้างต้น) |
ข้อมูลอ้างอิงออนไลน์
ด้านล่างนี้คือแหล่งข้อมูลที่เกี่ยวข้องกับบทแนะนำนี้
คิวงานของ App Engine
- ภาพรวมคิวงานของ App Engine
- ภาพรวมการดึงคิวงานของ App Engine
- แอปตัวอย่างแบบเต็มของคิวการดึงคิวงานของ App Engine
- การสร้างพุลคิวงาน
- วิดีโอเปิดตัวพุลคิวงาน Google I/O 2011 ( แอปตัวอย่างสำหรับการโหวต)
- ข้อมูลอ้างอิง
queue.yaml
รายการ queue.yaml
กับ Cloud Tasks- พุลคิวไปยังคำแนะนำในการย้ายข้อมูล Pub/Sub
Cloud Pub/Sub
- หน้าผลิตภัณฑ์ Cloud Pub/Sub
- การใช้ไลบรารีของไคลเอ็นต์ Pub/Sub
- ตัวอย่างไลบรารีของไคลเอ็นต์ Python Pub/Sub
- เอกสารประกอบเกี่ยวกับไลบรารีของไคลเอ็นต์ Python Pub/Sub
- สร้างและ จัดการหัวข้อ Pub/Sub
- หลักเกณฑ์การตั้งชื่อหัวข้อ Pub/Sub
- สร้างและ จัดการการสมัครใช้บริการ Pub/Sub
- แอปตัวอย่าง App Engine (แบบยืดหยุ่น) (นำไปทำให้ใช้งานได้ในแบบมาตรฐานด้วย Python 3)
- ที่เก็บของแอปตัวอย่างด้านบน
- การสมัครใช้บริการการดึงข้อมูล Pub/Sub
- การสมัครใช้บริการพุช Pub/Sub
- แอปตัวอย่างพุช App Engine Pub/Sub (Python 3)
- ที่เก็บตัวอย่างพุชของ App Engine Pub/Sub
- ข้อมูลราคา Pub/Sub
- Cloud Tasks หรือ Cloud Pub/Sub (พุชกับพุล)
App Engine NDB และ Cloud NDB (พื้นที่เก็บข้อมูล)
- เอกสาร NDB ของ App Engine
- ที่เก็บ NDB ของ App Engine
- เอกสาร Google Cloud NDB
- ที่เก็บ NDB ของ Google Cloud
- ข้อมูลราคาของ Cloud Datastore
แพลตฟอร์ม App Engine
- เอกสารประกอบของ App Engine
- รันไทม์ของ Python 2 App Engine (สภาพแวดล้อมมาตรฐาน)
- การใช้ไลบรารีในตัวของ App Engine บน Python 2 App Engine
- รันไทม์ของ Python 3 App Engine (สภาพแวดล้อมมาตรฐาน)
- ความแตกต่างระหว่าง Python 2 กับ รันไทม์ของ App Engine (สภาพแวดล้อมมาตรฐาน) 3 รายการ
- คำแนะนำในการย้ายข้อมูล Python 2 ถึง 3 App Engine (สภาพแวดล้อมมาตรฐาน)
- ข้อมูลราคาและโควต้าของ App Engine
- เปิดตัวแพลตฟอร์ม App Engine รุ่นที่ 2 (2018)
- การเปรียบเทียบกับ แพลตฟอร์มรุ่นที่ 2
- การรองรับรันไทม์เดิมในระยะยาว
- ตัวอย่างการย้ายข้อมูลเอกสารประกอบ
- ตัวอย่างการย้ายข้อมูลจากชุมชน
ข้อมูลอื่นๆ เกี่ยวกับระบบคลาวด์
- Python บน Google Cloud Platform
- ไลบรารีของไคลเอ็นต์ Google Cloud Python
- Google Cloud "ฟรีไม่จำกัดเวลา" ระดับ
- Google Cloud SDK (เครื่องมือบรรทัดคำสั่ง
gcloud
) - เอกสารประกอบทั้งหมดของ Google Cloud
วิดีโอ
- สถานีย้ายข้อมูลแบบ Serverless
- การสำรวจแบบ Serverless
- สมัครใช้บริการ Google Cloud Tech
- สมัครใช้บริการ Google Developers
ใบอนุญาต
ผลงานนี้ได้รับอนุญาตภายใต้ใบอนุญาตทั่วไปครีเอทีฟคอมมอนส์แบบระบุแหล่งที่มา 2.0