ย้ายข้อมูลจาก App Engine Memcache ไปยัง Cloud Memorystore (โมดูล 13)

1. ภาพรวม

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

วัตถุประสงค์ของ Codelab นี้คือแสดงให้นักพัฒนาซอฟต์แวร์ Python 2 App Engine ทราบวิธีย้ายข้อมูลจาก App Engine Memcache ไปยัง Cloud Memorystore (สำหรับ Redis) นอกจากนี้ ยังมีการย้ายข้อมูลโดยนัยจาก App Engine ndb ไปยัง Cloud NDB แต่ครอบคลุมอยู่ใน Codelab ของโมดูล 2 เป็นหลัก ให้ดูข้อมูลเพิ่มเติมแบบทีละขั้นตอน

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

  • ตั้งค่าอินสแตนซ์ Cloud Memorystore (จาก Cloud Console หรือเครื่องมือ gcloud)
  • ตั้งค่าเครื่องมือเชื่อมต่อการเข้าถึง VPC แบบ Cloud Serverless (จาก Cloud Console หรือเครื่องมือ gcloud)
  • ย้ายข้อมูลจาก App Engine Memcache ไปยัง Cloud Memorystore
  • ใช้การแคชด้วย Cloud Memorystore ในแอปตัวอย่าง
  • ย้ายข้อมูลจาก App Engine ndb ไปยัง Cloud NDB

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

แบบสำรวจ

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

โปรดอ่านเท่านั้น อ่านและทำแบบฝึกหัด

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

มือใหม่ ระดับกลาง ผู้ชำนาญ

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

มือใหม่ ระดับกลาง ผู้ชำนาญ

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

Codelab นี้จะสาธิตวิธีย้ายข้อมูลแอปตัวอย่างจาก App Engine Memcache (และ NDB) ไปยัง Cloud Memorystore (และ Cloud NDB) กระบวนการนี้เกี่ยวข้องกับการแทนที่ทรัพยากร Dependency ในบริการแบบรวมของ App Engine ซึ่งทำให้แอปพกพาสะดวกยิ่งขึ้น คุณสามารถเลือกที่จะใช้ App Engine ต่อไปหรือลองเปลี่ยนไปใช้ทางเลือกอื่นที่อธิบายก่อนหน้านี้

การย้ายข้อมูลนี้ต้องใช้ความพยายามมากขึ้นเมื่อเทียบกับการย้ายข้อมูลอื่นๆ ในซีรีส์นี้ สิ่งที่แนะนำให้ใช้แทน App Engine Memcache คือ Cloud Memorystore ซึ่งเป็นบริการแคชในระบบคลาวด์ที่มีการจัดการครบวงจร Memorystore รองรับเครื่องมือแคชแบบโอเพนซอร์สยอดนิยมทั้ง Redis และ Memcached โมดูลการย้ายข้อมูลนี้ใช้ Cloud Memorystore สำหรับ Redis ดูข้อมูลเพิ่มเติมได้ในภาพรวม Memorystore และ Redis

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

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

บทแนะนำนี้มีขั้นตอนสำคัญดังต่อไปนี้

  1. การตั้งค่า/งานล่วงหน้า
  2. ตั้งค่าบริการแคช
  3. อัปเดตไฟล์การกำหนดค่า
  4. อัปเดตแอปพลิเคชันหลัก

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

เตรียมโปรเจ็กต์ที่อยู่ในระบบคลาวด์

เราขอแนะนำให้ใช้โปรเจ็กต์เดียวกันกับที่คุณใช้สำหรับทำ Codelab ของโมดูล 12 ให้เสร็จสิ้น หรือคุณจะสร้างโปรเจ็กต์ใหม่หรือนำโปรเจ็กต์อื่นที่มีอยู่มาใช้ใหม่ก็ได้ Codelab ทุกรายการในชุดนี้จะมี "START" (โค้ดพื้นฐานที่จะเริ่มต้น) และ "FINISH" (แอปที่ย้ายข้อมูลแล้ว) รหัส FINISH จัดเตรียมไว้ให้เพื่อให้คุณเปรียบเทียบวิธีแก้ปัญหากับบริการของเราได้ในกรณีที่คุณพบปัญหา คุณสามารถย้อนกลับไปใช้ START ได้ทุกเมื่อหากเกิดข้อผิดพลาด จุดตรวจเหล่านี้ออกแบบมาเพื่อให้แน่ใจว่าคุณประสบความสำเร็จในการเรียนรู้วิธีดำเนินการย้ายข้อมูล

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

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

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

โฟลเดอร์ START ควรมีไฟล์ต่อไปนี้

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

หากคุณเริ่มต้นจากเวอร์ชัน Python 2 คุณจะเห็นไฟล์ appengine_config.py และอาจเป็นโฟลเดอร์ lib หากคุณทำ Codelab ของโมดูล 12 เสร็จสมบูรณ์

ทำให้แอปโมดูล 12 ใช้งานได้ (ใหม่)

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

  1. ทำความคุ้นเคยกับเครื่องมือบรรทัดคำสั่ง gcloud (หากจำเป็น)
  2. (อีกครั้ง) ทำให้โค้ดโมดูล 12 ใช้งานได้ใน App Engine (หากจำเป็น)

ผู้ใช้ Python 2 ควรลบและติดตั้งโฟลเดอร์ lib อีกครั้งด้วยคำสั่งต่อไปนี้

rm -rf ./lib; pip install -t lib -r requirements.txt

ตอนนี้ทุกคน (ผู้ใช้ Python 2 และ 3) ควรอัปโหลดโค้ดไปยัง App Engine ด้วยคำสั่งนี้

gcloud app deploy

เมื่อติดตั้งใช้งานสำเร็จแล้ว ให้ยืนยันว่าแอปมีลักษณะและการทำงานเหมือนกับแอปในโมดูล 12 ซึ่งเป็นเว็บแอปที่ติดตามการเข้าชม โดยแคชการเข้าชมให้กับผู้ใช้รายเดียวกันเป็นเวลา 1 ชั่วโมง

dfe56a02ae59ddd8.png

เนื่องจากการเข้าชมล่าสุดจะถูกแคชไว้ การรีเฟรชหน้าควรจะโหลดได้เร็วพอสมควร

4. ตั้งค่าบริการแคช

Cloud Memorystore ไม่ใช่แบบ Serverless ต้องมีอินสแตนซ์ ซึ่งในกรณีนี้มีไฟล์ Redis อยู่ Memorystore เป็นผลิตภัณฑ์ระบบคลาวด์แบบสแตนด์อโลนและไม่มีรุ่นฟรี ซึ่งแตกต่างจาก Memcache ตรงที่แนะนำให้ตรวจสอบข้อมูลราคา Memorystore สำหรับ Redis ก่อนดำเนินการต่อ เราขอแนะนำให้ใช้ทรัพยากรน้อยที่สุดในการปฏิบัติงาน เพื่อลดค่าใช้จ่ายสำหรับแบบฝึกหัดนี้ ซึ่งได้แก่ ระดับบริการพื้นฐานและความจุ 1 GB

อินสแตนซ์ Memorystore อยู่ในเครือข่ายที่แตกต่างจากแอป (อินสแตนซ์) ในแอป App Engine ของคุณ จึงเป็นเหตุผลที่ต้องสร้างเครื่องมือเชื่อมต่อการเข้าถึง VPC แบบ Serverless เพื่อให้ App Engine เข้าถึงทรัพยากร Memorystore ได้ หากต้องการลดค่าใช้จ่าย VPC ให้เลือกประเภทอินสแตนซ์ (f1-micro) และจำนวนอินสแตนซ์ขั้นต่ำที่จะขอ (ขอแนะนำเป็นขั้นต่ำ 2 สูงสุด 3) นอกจากนี้ โปรดดูหน้าข้อมูลราคา VPC

เราจะให้คำแนะนำดังกล่าวซ้ำเพื่อลดค่าใช้จ่าย เนื่องจากเราจะแนะนำคุณตลอดขั้นตอนการสร้างทรัพยากรที่จำเป็นแต่ละรายการ นอกจากนี้ เมื่อสร้างทรัพยากร Memorystore และ VPC ใน Cloud Console คุณจะเห็นเครื่องคำนวณราคาสำหรับแต่ละผลิตภัณฑ์ที่มุมขวาบน ซึ่งจะแสดงค่าใช้จ่ายรายเดือนโดยประมาณ (ดูภาพประกอบด้านล่าง) ค่าเหล่านี้จะปรับโดยอัตโนมัติหากคุณเปลี่ยนตัวเลือก นี่คือสิ่งที่คุณควรเห็นโดยประมาณ:

7eb35ebf7248c010.png

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

เมื่อแหล่งข้อมูลทั้ง 2 รายการออนไลน์แล้ว คุณจะเพิ่มข้อมูลที่เกี่ยวข้องใน app.yaml เพื่อให้แอปเข้าถึงแคชได้ นอกจากนี้ คุณยังดูคู่มือ Python 2 หรือ Python 3 ในเอกสารอย่างเป็นทางการได้ด้วย คู่มือการแคชข้อมูลในหน้าการย้ายข้อมูล Cloud NDB ( Python 2 หรือ Python 3) ก็ควรอ้างอิงเช่นกัน

สร้างอินสแตนซ์ Cloud Memorystore

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

  • เลือกระดับบริการต่ำสุด ได้แก่ พื้นฐาน (ค่าเริ่มต้นของคอนโซล: "มาตรฐาน", ค่าเริ่มต้น gcloud คือ "พื้นฐาน")
  • เลือกปริมาณพื้นที่เก็บข้อมูลน้อยที่สุดคือ 1 GB (ค่าเริ่มต้นของคอนโซลคือ 16 GB, ค่าเริ่มต้น gcloud คือ 1 GB)
  • โดยทั่วไปแล้ว ซอฟต์แวร์เวอร์ชันใดก็ได้ที่ใหม่ที่สุดจะต้องใช้ทรัพยากรมากที่สุด แต่เราไม่แนะนำให้เลือกเวอร์ชันที่เก่าที่สุดเช่นกัน เวอร์ชันที่สองล่าสุดในปัจจุบันคือเวอร์ชัน Redis 5.0 (ค่าเริ่มต้นของคอนโซลคือ 6.x)

เมื่อคำนึงถึงการตั้งค่าเหล่านั้นแล้ว ส่วนถัดไปจะแนะนำขั้นตอนการสร้างอินสแตนซ์จาก Cloud Console หากต้องการดำเนินการจากบรรทัดคำสั่ง ให้ข้ามไปข้างหน้า

จาก Cloud Console

ไปที่หน้า Cloud Memorystore ใน Cloud Console (ระบบอาจแจ้งให้คุณป้อนข้อมูลสำหรับการเรียกเก็บเงิน) หากยังไม่ได้เปิดใช้ Memorystore คุณจะได้รับข้อความแจ้งให้เปิดใช้ดังนี้

68318997e3105db6.png

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

63547aa575838a36.png

หน้านี้จะมีแบบฟอร์มสำหรับกรอกการตั้งค่าที่คุณต้องการเพื่อสร้างอินสแตนซ์ Memorystore

b77d927287fdf4c7.png

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

จากบรรทัดคำสั่ง

แม้ว่าการสร้างอินสแตนซ์ Memorystore จาก Cloud Console จะเป็นข้อมูลที่เห็นได้ชัดเจน แต่บางคนก็เลือกใช้บรรทัดคำสั่งมากกว่า โปรดตรวจสอบว่า gcloud ติดตั้งและเริ่มต้นแล้วก่อนที่จะดำเนินการต่อ

ต้องเปิดใช้ Cloud Memorystore สำหรับ Redis เช่นเดียวกับ Cloud Console ออกคำสั่ง gcloud services enable redis.googleapis.com และรอให้ดำเนินการเสร็จสิ้น ดังตัวอย่างต่อไปนี้

$ gcloud services enable redis.googleapis.com
Operation "operations/acat.p2-aaa-bbb-ccc-ddd-eee-ffffff" finished successfully.

หากเปิดใช้บริการแล้ว การเรียกใช้คำสั่ง (อีกครั้ง) จะไม่ส่งผลข้างเคียง (เชิงลบ) เมื่อเปิดใช้บริการแล้ว เราจะสร้างอินสแตนซ์ Memorystore คำสั่งดังกล่าวมีลักษณะดังนี้

gcloud redis instances create NAME --redis-version VERSION \
    --region REGION --project PROJECT_ID

เลือกชื่อสำหรับอินสแตนซ์ Memorystore ของคุณ ห้องทดลองนี้ใช้ "demo-ms" เป็นชื่อพร้อมกับรหัสโปรเจ็กต์ "my-project" ภูมิภาคของแอปตัวอย่างนี้คือ us-central1 (เหมือนกับ us-central) แต่คุณอาจใช้ภูมิภาคอื่นที่อยู่ใกล้คุณมากกว่าหากกังวลเกี่ยวกับเวลาในการตอบสนอง คุณต้องเลือกภูมิภาคเดียวกับแอป App Engine คุณจะเลือกเวอร์ชัน Redis ใดก็ได้ตามต้องการ แต่เราใช้เวอร์ชัน 5 ตามที่แนะนำก่อนหน้านี้แล้ว จากการตั้งค่าเหล่านั้น นี่คือคำสั่งที่คุณจะออก (พร้อมด้วยเอาต์พุตที่เกี่ยวข้อง)

$ gcloud redis instances create demo-ms --region us-central1 \
    --redis-version redis_5_0 --project my-project

Create request issued for: [demo-ms]
Waiting for operation [projects/my-project/locations/us-central1/operations/operation-xxxx] to complete...done.
Created instance [demo-ms].

gcloud จะใช้ทรัพยากรน้อยที่สุดโดยค่าเริ่มต้น ซึ่งต่างจากค่าเริ่มต้นของ Cloud Console ผลที่ได้คือไม่จำเป็นต้องใช้ระดับบริการและปริมาณพื้นที่เก็บข้อมูลในคำสั่งนั้น การสร้างอินสแตนซ์ Memorystore ใช้เวลาหลายนาที และเมื่อดำเนินการเสร็จแล้ว โปรดจดบันทึกที่อยู่ IP และหมายเลขพอร์ตของอินสแตนซ์ เนื่องจากจะมีการเพิ่มลงใน app.yaml ในไม่ช้า

ยืนยันการสร้างอินสแตนซ์

จาก Cloud Console หรือบรรทัดคำสั่ง

ไม่ว่าจะสร้างอินสแตนซ์จาก Cloud Console หรือบรรทัดคำสั่ง คุณสามารถยืนยันได้ว่าอินสแตนซ์พร้อมใช้งานและพร้อมใช้งานด้วยคำสั่งนี้: gcloud redis instances list --region REGION

นี่คือคำสั่งสำหรับตรวจสอบอินสแตนซ์ในภูมิภาค us-central1 พร้อมกับเอาต์พุตที่คาดไว้ซึ่งแสดงอินสแตนซ์ที่เราเพิ่งสร้างขึ้น

$ gcloud redis instances list --region us-central1
INSTANCE_NAME  VERSION    REGION       TIER   SIZE_GB  HOST         PORT  NETWORK  RESERVED_IP     STATUS  CREATE_TIME
demo-ms        REDIS_5_0  us-central1  BASIC  1        10.aa.bb.cc  6379  default  10.aa.bb.dd/29  READY   2022-01-28T09:24:45

เมื่อระบบขอข้อมูลอินสแตนซ์หรือกำหนดค่าแอป โปรดใช้ HOST และ PORT (ไม่ใช่ RESERVED_IP) ตอนนี้แดชบอร์ด Cloud Memorystore ใน Cloud Console ควรแสดงอินสแตนซ์ต่อไปนี้

c5a6948ec1c056ed.png

จากเครื่องเสมือน Compute Engine

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

สร้างเครื่องมือเชื่อมต่อการเข้าถึง VPC แบบ Serverless

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

  • เลือกจำนวนอินสแตนซ์สูงสุดต่ำสุด: 3 (คอนโซลและค่าเริ่มต้น gcloud: 10)
  • เลือกประเภทเครื่องที่ต้นทุนต่ำสุด: f1-micro (ค่าเริ่มต้นของคอนโซล: e2-micro ไม่มีค่าเริ่มต้น gcloud)

ส่วนถัดไปจะแนะนำการสร้างเครื่องมือเชื่อมต่อจาก Cloud Console โดยใช้การตั้งค่า Cloud VPC ข้างต้น หากต้องการดำเนินการจากบรรทัดคำสั่ง ให้ข้ามไปยังส่วนถัดไป

จาก Cloud Console

ไปที่เครือข่ายระบบคลาวด์ "การเข้าถึง VPC แบบ Serverless" ใน Cloud Console (ระบบอาจแจ้งให้คุณป้อนข้อมูลสำหรับการเรียกเก็บเงิน) หากยังไม่ได้เปิดใช้ API ระบบจะแจ้งให้คุณเปิดใช้ ดังนี้

e3b9c0651de25e97.png

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

b74b49b9d73b7dcf.png

กรอกแบบฟอร์มโดยใช้การตั้งค่าที่ต้องการต่อไปนี้

6b26b2aafa719f73.png

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

จากบรรทัดคำสั่ง

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

$ gcloud services enable vpcaccess.googleapis.com
Operation "operations/acf.p2-aaa-bbb-ccc-ddd-eee-ffffff" finished successfully.

เมื่อเปิดใช้ API แล้ว ระบบจะสร้างเครื่องมือเชื่อมต่อ VPC ด้วยคำสั่งที่มีลักษณะดังนี้

gcloud compute networks vpc-access connectors create CONNECTOR_NAME \
    --range 10.8.0.0/28 --region REGION --project PROJECT_ID

เลือกชื่อให้กับเครื่องมือเชื่อมต่อ รวมถึงที่อยู่ IP เริ่มต้นของบล็อก /28 CIDR ที่ไม่ได้ใช้ บทแนะนำนี้มีสมมติฐานดังต่อไปนี้

  • รหัสโปรเจ็กต์: my-project
  • ชื่อเครื่องมือเชื่อมต่อ VPC: demo-vpc
  • จำนวนอินสแตนซ์ขั้นต่ำ: 2 (ค่าเริ่มต้น) และจำนวนอินสแตนซ์สูงสุด: 3
  • ประเภทอินสแตนซ์: f1-micro
  • ภูมิภาค: us-central1
  • บล็อก CIDR ของ IPv4: 10.8.0.0/28 (ตามที่แนะนำในคอนโซลระบบคลาวด์)

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

$ gcloud compute networks vpc-access connectors create demo-vpc \
    --max-instances 3 --range 10.8.0.0/28 --machine-type f1-micro \
    --region us-central1  --project my-project

Create request issued for: [demo-vpc]
Waiting for operation [projects/my-project/locations/us-central1/operations/xxx] to complete...done.
Created connector [demo-vpc].

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

ยืนยันการสร้างเครื่องมือเชื่อมต่อ

เมื่อกระบวนการเสร็จสมบูรณ์แล้ว ให้ออกคำสั่ง gcloud ต่อไปนี้ โดยสมมติว่าเป็นภูมิภาค us-central1 เพื่อยืนยันว่าสร้างแล้วและพร้อมใช้งาน

$ gcloud compute networks vpc-access connectors list --region us-central1
CONNECTOR_ID  REGION       NETWORK  IP_CIDR_RANGE  SUBNET  SUBNET_PROJECT  MIN_THROUGHPUT  MAX_THROUGHPUT  STATE
demo-vpc      us-central1  default  10.8.0.0/28                            200             300             READY

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

e03db2c8140ed014.png

จดบันทึกรหัสโปรเจ็กต์ที่อยู่ในระบบคลาวด์ ชื่อเครื่องมือเชื่อมต่อ VPC และภูมิภาค

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

5. อัปเดตไฟล์การกำหนดค่า

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

requirements.txt

ในส่วนนี้ เราจะเพิ่มแพ็กเกจเพื่อรองรับ Cloud Memorystore และ Cloud NDB สำหรับ Cloud Memorystore สำหรับ Redis ก็สามารถใช้ไคลเอ็นต์ Redis มาตรฐานสำหรับ Python (redis) ได้ เนื่องจากไม่มีไลบรารีของไคลเอ็นต์ Cloud Memorystore ตามแต่ละกรณี เพิ่ม redis และ google-cloud-ndb ต่อท้าย requirements.txt โดยเข้าร่วม flask จากโมดูล 12:

flask
redis
google-cloud-ndb

ไฟล์ requirements.txt นี้ไม่มีหมายเลขเวอร์ชันใดๆ ซึ่งหมายความว่าระบบจะเลือกเวอร์ชันล่าสุดไว้ หากเกิดความไม่สามารถทำงานร่วมกัน ให้ระบุหมายเลขเวอร์ชันเพื่อล็อกในเวอร์ชันที่ใช้งานได้

app.yaml

หัวข้อใหม่ที่จะเพิ่ม

รันไทม์ของ Python 2 App Engine ต้องใช้แพ็กเกจของบุคคลที่สามที่เฉพาะเจาะจงเมื่อใช้ Cloud API เช่น Cloud NDB ซึ่งก็คือ grpcio และ setuptools ผู้ใช้ Python 2 ต้องแสดงไลบรารีในตัวในลักษณะนี้พร้อมกับเวอร์ชันที่พร้อมใช้งานใน app.yaml หากยังไม่มีส่วน libraries ให้สร้างส่วนดังกล่าวและเพิ่มไลบรารีทั้ง 2 รายการดังตัวอย่างต่อไปนี้

libraries:
- name: grpcio
  version: latest
- name: setuptools
  version: latest

ขณะย้ายข้อมูลแอปของคุณ แอปอาจมีส่วน libraries อยู่แล้ว หากมี grpcio และ setuptools ขาดหายไป เพียงเพิ่มรายการเหล่านี้ลงในส่วน libraries ที่มีอยู่

ถัดไป แอปตัวอย่างของเราต้องใช้ข้อมูลอินสแตนซ์ Cloud Memorystore และเครื่องมือเชื่อมต่อ VPC ดังนั้นให้เพิ่มส่วนใหม่ 2 ส่วนต่อไปนี้ไปยัง app.yaml โดยไม่คำนึงถึงรันไทม์ของ Python ที่ใช้

env_variables:
    REDIS_HOST: 'YOUR_REDIS_HOST'
    REDIS_PORT: 'YOUR_REDIS_PORT'

vpc_access_connector:
    name: projects/PROJECT_ID/locations/REGION/connectors/CONNECTOR

เท่ากับว่าการอัปเดตที่จำเป็นต้องทำเท่านี้ app.yaml ที่อัปเดตแล้วควรมีลักษณะดังนี้

runtime: python27
threadsafe: yes
api_version: 1

handlers:
- url: /.*
  script: main.app

libraries:
- name: grpcio
  version: 1.0.0
- name: setuptools
  version: 36.6.0

env_variables:
    REDIS_HOST: 'YOUR_REDIS_HOST'
    REDIS_PORT: 'YOUR_REDIS_PORT'

vpc_access_connector:
    name: projects/PROJECT_ID/locations/REGION/connectors/CONNECTOR

ด้านล่างนี้คือข้อมูล "ก่อนและหลัง" แสดงการปรับปรุงที่คุณควรใช้กับ app.yaml:

ec2bb027a67debb6.png

*ความแตกต่างของ Python 3

ส่วนนี้เป็นแบบไม่บังคับและเฉพาะในกรณีที่คุณพอร์ตไปยัง Python 3 เท่านั้น ซึ่งคุณจะต้องทำการเปลี่ยนแปลงกับการกำหนดค่า Python 2 ดังต่อไปนี้ ข้ามส่วนนี้หากคุณไม่อัปเกรดในขณะนี้

ไม่ได้ใช้ threadsafe และ api_version สำหรับรันไทม์ของ Python 3 ดังนั้นให้ลบการตั้งค่าทั้ง 2 รายการนี้ รันไทม์ล่าสุดของ App Engine ไม่รองรับไลบรารีของบุคคลที่สามแบบบิวท์อินหรือการคัดลอกไลบรารีที่ไม่มีในตัว ข้อกำหนดเพียงอย่างเดียวสำหรับแพ็กเกจของบุคคลที่สามคือการแสดงแพ็กเกจเหล่านั้นใน requirements.txt ด้วยเหตุนี้คุณลบส่วน libraries ทั้งหมดของ app.yaml ได้

ขั้นตอนถัดไป รันไทม์ของ Python 3 ต้องใช้เว็บเฟรมเวิร์กที่กำหนดเส้นทางของตัวเอง ดังนั้นเราจึงแสดงให้นักพัฒนาแอปเห็นถึงวิธีย้ายข้อมูลจาก Webp2 ไปยัง Flask ในโมดูล 1 ด้วยเหตุนี้ ตัวแฮนเดิลสคริปต์ทั้งหมดจึงต้องเปลี่ยนเป็น auto เนื่องจากแอปนี้ไม่แสดงไฟล์แบบคงที่ จึงเป็นแบบ "ไม่มีจุด" ให้แสดงเครื่องจัดการ (เนื่องจากเป็น auto ทั้งหมด) คุณจึงนำส่วน handlers ทั้งส่วนออกได้ ดังนั้น app.yaml แบบย่อที่ปรับแต่งไว้สำหรับ Python 3 จึงควรถูกตัดให้สั้นลง ดังนี้

runtime: python39

env_variables:
    REDIS_HOST: 'YOUR_REDIS_HOST'
    REDIS_PORT: 'YOUR_REDIS_PORT'

vpc_access_connector:
    name: projects/PROJECT_ID/locations/REGION/connectors/CONNECTOR

สรุปความแตกต่างของ app.yaml เมื่อพอร์ตไปยัง Python 3:

  • ลบการตั้งค่า threadsafe และ api_version
  • ลบส่วน libraries
  • ลบส่วน handlers (หรือเพียง script ตัวแฮนเดิลหากแอปส่งไฟล์แบบคงที่)

แทนที่ค่า

ค่าในส่วนใหม่สำหรับ Memorystore และเครื่องมือเชื่อมต่อ VPC เป็นเพียงตัวยึดตำแหน่ง แทนที่ค่าที่เป็นตัวพิมพ์ใหญ่ (YOUR_REDIS_HOST, YOUR_REDIS_PORT, PROJECT_ID, REGION, CONNECTOR_NAME) เหล่านั้นด้วยค่าที่บันทึกจากเมื่อสร้างทรัพยากรเหล่านั้นก่อนหน้านี้ สำหรับอินสแตนซ์ Memorystore โปรดใช้ HOST (ไม่ใช่ RESERVED_IP) และ PORT ต่อไปนี้คือวิธีบรรทัดคำสั่งด่วนในการรับ HOST และ PORT โดยสมมติว่าชื่ออินสแตนซ์เป็น demo-ms และ REGION คือ us-central1

$ gcloud redis instances describe demo-ms --region us-central1 \
    --format "value(host,port)"
10.251.161.51   6379

หากตัวอย่างที่อยู่ IP ของอินสแตนซ์ Redis คือ 10.10.10.10 โดยใช้พอร์ต 6379 ในโปรเจ็กต์ my-project ซึ่งอยู่ในภูมิภาค us-central1 ที่มีชื่อเครื่องมือเชื่อมต่อ VPC เป็น demo-vpc ส่วนเหล่านี้ใน app.yaml จะมีลักษณะดังนี้

env_variables:
    REDIS_HOST: '10.10.10.10'
    REDIS_PORT: '6379'

vpc_access_connector:
    name: projects/my-project/locations/us-central1/connectors/demo-vpc

สร้างหรืออัปเดต appengine_config.py

เพิ่มการรองรับไลบรารีของบุคคลที่สามในตัว

ให้เพิ่มการใช้งานไลบรารี grpcio และ setuptools เช่นเดียวกับที่เราทำกับ app.yaml ก่อนหน้านี้ แก้ไข appengine_config.py เพื่อรองรับไลบรารีของบุคคลที่สามในตัว หากคุ้นชิน นั่นเป็นเพราะต้องกลับไปดูโมดูล 2 ด้วยเมื่อย้ายข้อมูลจาก App Engine ndb ไปยัง Cloud NDB การเปลี่ยนแปลงที่จำเป็นคือการเพิ่มโฟลเดอร์ lib ลงในชุดการทำงาน setuptools.pkg_resources ดังนี้

4140b3800694f77e.png

*ความแตกต่างของ Python 3

ส่วนนี้เป็นแบบไม่บังคับและเฉพาะในกรณีที่คุณพอร์ตไปยัง Python 3 เท่านั้น หนึ่งในการเปลี่ยนแปลงต้อนรับของ App Engine รุ่นที่ 2 คือไม่จำเป็นต้องคัดลอกแพ็กเกจของบุคคลที่สาม (บางครั้งเรียกว่า "ผู้ให้บริการ") และอ้างอิงแพ็กเกจของบุคคลที่สามที่มีมาในตัว app.yaml อีกต่อไป ซึ่งหมายความว่าคุณสามารถลบไฟล์ appengine_config.py ทั้งไฟล์ได้

6. อัปเดตไฟล์แอปพลิเคชัน

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

5d043768ba7be742.png

มาเริ่มกันทีละส่วนโดยเริ่มต้นจากด้านบน

อัปเดตการนำเข้า

ส่วนการนำเข้าใน main.py สำหรับโมดูล 12 ใช้ Cloud NDB และ Cloud Tasks การนำเข้ามีดังนี้

ก่อนหน้า:

from flask import Flask, render_template, request
from google.appengine.api import memcache
from google.appengine.ext import ndb

การเปลี่ยนไปใช้ Memorystore ต้องใช้ตัวแปรสภาพแวดล้อมในการอ่าน ซึ่งหมายความว่าเราต้องใช้โมดูล os ของ Python รวมถึง redis ซึ่งเป็นไคลเอ็นต์ Python Redis เนื่องจาก Redis แคชออบเจ็กต์ Python ไม่ได้ ให้กำหนดรายการการเข้าชมล่าสุดโดยใช้ pickle ดังนั้นโปรดนำเข้าด้วย ประโยชน์อย่างหนึ่งของ Memcache คือการจัดเรียงออบเจ็กต์แบบอนุกรมจะเกิดขึ้นโดยอัตโนมัติ ในขณะที่ Memorystore มีความ "DIY" มากกว่า สุดท้าย ให้อัปเกรดจาก App Engine ndb เป็น Cloud NDB โดยแทนที่ google.appengine.ext.ndb ด้วย google.cloud.ndb หลังการเปลี่ยนแปลงเหล่านี้ การนำเข้าควรมีลักษณะดังนี้

หลัง:

import os
import pickle
from flask import Flask, render_template, request
from google.cloud import ndb
import redis

อัปเดตการเริ่มต้น

การเริ่มต้นโมดูล 12 ประกอบด้วยการสร้างอินสแตนซ์ของออบเจ็กต์แอปพลิเคชัน Flask app และการตั้งค่าคงที่สำหรับการแคชเป็นเวลา 1 ชั่วโมง

ก่อน

app = Flask(__name__)
HOUR = 3600

การใช้ Cloud API จำเป็นต้องมีไคลเอ็นต์ ดังนั้นให้สร้างอินสแตนซ์ไคลเอ็นต์ Cloud NDB หลังจาก Flask ทันที จากนั้นให้รับที่อยู่ IP และหมายเลขพอร์ตสำหรับอินสแตนซ์ Memorystore จากตัวแปรสภาพแวดล้อมที่คุณตั้งค่าไว้ใน app.yaml เตรียมข้อมูลให้พร้อม แล้วเริ่มสร้างไคลเอ็นต์ Redis นี่คือลักษณะของโค้ดหลังจากการอัปเดต

หลัง:

app = Flask(__name__)
ds_client = ndb.Client()
HOUR = 3600
REDIS_HOST = os.environ.get('REDIS_HOST', 'localhost')
REDIS_PORT = os.environ.get('REDIS_PORT', '6379')
REDIS = redis.Redis(host=REDIS_HOST, port=REDIS_PORT)

*การย้ายข้อมูล Python 3

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

ข้อแรก เนื่องจาก Memcache เป็นบริการพ่วงแอปของ App Engine การใช้งานในแอป Python 3 จึงต้องใช้ App Engine SDK โดยเฉพาะอย่างยิ่งการรวมแอปพลิเคชัน WSGI (รวมถึงการกำหนดค่าที่จำเป็นอื่นๆ) ดังนี้

ก่อนหน้า:

from flask import Flask, render_template, request
from google.appengine.api import memcache, wrap_wsgi_app
from google.appengine.ext import ndb

app = Flask(__name__)
app.wsgi_app = wrap_wsgi_app(app.wsgi_app)
HOUR = 3600

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

หลัง:

import os
import pickle
from flask import Flask, render_template, request
from google.cloud import ndb
import redis

app = Flask(__name__)
ds_client = ndb.Client()
HOUR = 3600
REDIS_HOST = os.environ.get('REDIS_HOST', 'localhost')
REDIS_PORT = os.environ.get('REDIS_PORT', '6379')
REDIS = redis.Redis(host=REDIS_HOST, port=REDIS_PORT)

สุดท้าย ให้นำการใช้ SDK ออกจาก app.yaml (ลบบรรทัด: app_engine_apis: true) และ requirements.txt (ลบบรรทัด: appengine-python-standard)

ย้ายข้อมูลไปยัง Cloud Memorystore (และ Cloud NDB)

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

ก่อนหน้า:

def store_visit(remote_addr, user_agent):
    'create new Visit entity in Datastore'
    Visit(visitor='{}: {}'.format(remote_addr, user_agent)).put()

def fetch_visits(limit):
    'get most recent visits'
    return Visit.query().order(-Visit.timestamp).fetch(limit)

เพิ่มบล็อก with ds_client.context() ให้กับทั้ง 2 ฟังก์ชัน และใส่การเรียก Datastore ไว้ด้านใน (และเยื้อง) ในกรณีนี้ ไม่จำเป็นต้องทำการเปลี่ยนแปลงใดๆ กับการโทร ดังนี้

หลัง:

def store_visit(remote_addr, user_agent):
    'create new Visit entity in Datastore'
    with ds_client.context():
        Visit(visitor='{}: {}'.format(remote_addr, user_agent)).put()

def fetch_visits(limit):
    'get most recent visits'
    with ds_client.context():
        return Visit.query().order(-Visit.timestamp).fetch(limit)

ต่อไป เราจะมาดูการเปลี่ยนแปลงการแคชกัน นี่คือฟังก์ชัน main() จากโมดูล 12

ก่อนหน้า:

@app.route('/')
def root():
    'main application (GET) handler'
    # check for (hour-)cached visits
    ip_addr, usr_agt = request.remote_addr, request.user_agent
    visitor = '{}: {}'.format(ip_addr, usr_agt)
    visits = memcache.get('visits')

    # register visit & run DB query if cache empty or new visitor
    if not visits or visits[0].visitor != visitor:
        store_visit(ip_addr, usr_agt)
        visits = list(fetch_visits(10))
        memcache.set('visits', visits, HOUR)  # set() not add()

    return render_template('index.html', visits=visits)

Redis มี "get" และ "ตั้งค่า" เช่นเดียวกับ Memcache ที่เราทำคือสลับไลบรารีของไคลเอ็นต์ที่เกี่ยวข้อง ถูกต้องไหม เกือบถูกแล้ว ดังที่กล่าวไว้ก่อนหน้านี้ เราไม่สามารถแคชรายการ Python ที่มี Redis ได้ (เพราะต้องมีการเรียงลำดับก่อน จะมีบางอย่าง Memcache ดูแลโดยอัตโนมัติ) ดังนั้นในการเรียกใช้ set() ให้ "pickle" การเข้าชมลงในสตริงที่มี pickle.dumps() ในทำนองเดียวกัน เมื่อดึงข้อมูลการเข้าชมจากแคช คุณจะต้องยกเลิกการเลือกด้วย pickle.loads() หลัง get() ทันที นี่คือเครื่องจัดการหลักหลังจากทำการเปลี่ยนแปลงเหล่านั้น

หลัง:

@app.route('/')
def root():
    'main application (GET) handler'
    # check for (hour-)cached visits
    ip_addr, usr_agt = request.remote_addr, request.user_agent
    visitor = '{}: {}'.format(ip_addr, usr_agt)
    rsp = REDIS.get('visits')
    visits = pickle.loads(rsp) if rsp else None

    # register visit & run DB query if cache empty or new visitor
    if not visits or visits[0].visitor != visitor:
        store_visit(ip_addr, usr_agt)
        visits = list(fetch_visits(10))
        REDIS.set('visits', pickle.dumps(visits), ex=HOUR)

    return render_template('index.html', visits=visits)

การดําเนินการนี้จะสรุปการเปลี่ยนแปลงที่จําเป็นใน main.py การแปลงการใช้ Memcache ตัวอย่างของแอปเป็น Cloud Memorystore แล้วเทมเพลต HTML และการพอร์ตไปยัง Python 3 ล่ะ

อัปเดตไฟล์เทมเพลต HTML และพอร์ตเป็น Python 3 ไหม

เซอร์ไพรส์! คุณไม่จำเป็นต้องดำเนินการใดๆ เนื่องจากแอปพลิเคชันได้รับการออกแบบมาให้ทำงานในทั้ง Python 2 และ 3 โดยไม่มีการเปลี่ยนแปลงโค้ดหรือไลบรารีความเข้ากันได้ คุณจะพบ main.py เหมือนกันใน "FINISH" ของ mod13a (2.x) และ mod13b (3.x) โฟลเดอร์ เช่นเดียวกับ requirements.txt นอกเหนือจากความแตกต่างของหมายเลขเวอร์ชัน (หากใช้) เนื่องจากอินเทอร์เฟซผู้ใช้ไม่มีการเปลี่ยนแปลง จึงไม่มีการอัปเดตใน templates/index.html เช่นกัน

ทุกอย่างที่จำเป็นต่อการเรียกใช้แอปนี้ใน Python 3 App Engine ดำเนินการเสร็จสมบูรณ์แล้วก่อนหน้านี้ในการกำหนดค่า ระบบนำคำสั่งที่ไม่จำเป็นออกจาก app.yaml แล้ว รวมถึงลบทั้ง appengine_config.py และโฟลเดอร์ lib เนื่องจากไม่มีการใช้งานใน Python 3

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

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

ติดตั้งใช้งานและยืนยันแอปพลิเคชัน

การตรวจสอบครั้งล่าสุดคือการทำให้แอปตัวอย่างใช้งานได้เสมอ นักพัฒนาซอฟต์แวร์ Python 2: ลบและติดตั้ง lib อีกครั้งด้วยคำสั่งด้านล่าง (หากมีทั้ง Python 2 และ 3 ติดตั้งไว้ในระบบ คุณอาจต้องเรียกใช้ pip2 อย่างชัดแจ้งแทน)

rm -rf ./lib
pip install -t lib -r requirements.txt

ตอนนี้ทั้งนักพัฒนาซอฟต์แวร์ Python 2 และ 3 ควรทำให้แอปของตนใช้งานได้ด้วยสิ่งต่อไปนี้

gcloud app deploy

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

แอปการเข้าชมโมดูล 7

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

ล้างข้อมูล

ทั่วไป

หากดำเนินการเสร็จแล้ว เราขอแนะนำให้คุณปิดใช้แอป 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 Memorystore ต้องมีอินสแตนซ์และไม่มีรุ่นฟรี ดูข้อมูลเพิ่มเติมเกี่ยวกับค่าใช้จ่ายในการใช้งานได้ที่หน้าราคา
  • เครื่องมือเชื่อมต่อการเข้าถึง VPC แบบ Cloud Serverless ต้องใช้อินสแตนซ์และไม่มีรุ่นฟรี ดูข้อมูลเพิ่มเติมเกี่ยวกับค่าใช้จ่ายการใช้งานได้ที่ส่วนในหน้าราคา Cloud VPC
  • Cloud Datastore (Cloud Firestore ในโหมด Datastore) มีรุ่นฟรี ดูข้อมูลเพิ่มเติมได้ที่หน้าราคา

บทแนะนำนี้เกี่ยวข้องกับการใช้ผลิตภัณฑ์ Cloud 4 รายการดังนี้

  • App Engine
  • Cloud Datastore
  • Cloud Memorystore
  • Cloud VPC

ด้านล่างนี้คือคำแนะนำในการปล่อยทรัพยากรเหล่านี้ และเพื่อหลีกเลี่ยง/ลดการเรียกเก็บเงิน

ปิดอินสแตนซ์ Memorystore และเครื่องมือเชื่อมต่อ VPC

ผลิตภัณฑ์เหล่านี้เป็นผลิตภัณฑ์ที่ไม่มีรุ่นฟรี คุณจึงต้องเรียกเก็บเงินทันที หากไม่ปิดโปรเจ็กต์ Cloud (ดูส่วนถัดไป) คุณต้องลบทั้งอินสแตนซ์ Memorystore และเครื่องมือเชื่อมต่อ VPC เพื่อหยุดการเรียกเก็บเงิน นอกจากนี้ คุณยังปล่อยทรัพยากรจาก Cloud Console หรือบรรทัดคำสั่งได้ เช่นเดียวกับตอนที่สร้างทรัพยากรเหล่านี้

จาก Cloud Console

หากต้องการลบอินสแตนซ์ Memorystore ให้กลับไปที่แดชบอร์ด Memorystore แล้วคลิกรหัสอินสแตนซ์ ดังนี้

2b09baf1aa2e0a25.png

เมื่ออยู่ในหน้ารายละเอียดของอินสแตนซ์ดังกล่าวแล้ว ให้คลิก "ลบ" และยืนยัน:

f9d9eb1c1d4c6107.png

หากต้องการลบเครื่องมือเชื่อมต่อ VPC ให้ไปที่แดชบอร์ดของเครื่องมือเชื่อมต่อ และเลือกช่องทำเครื่องหมายข้างเครื่องมือเชื่อมต่อที่คุณต้องการลบ แล้วคลิก "ลบ" และยืนยัน:

ca5fbd9f4c7c9b60.png

จากบรรทัดคำสั่ง

คำสั่ง gcloud คู่ต่อไปนี้จะลบทั้งอินสแตนซ์ Memorystore และเครื่องมือเชื่อมต่อ VPC ตามลำดับ

  • gcloud redis instances delete INSTANCE --region REGION
  • gcloud compute networks vpc-access connectors delete CONNECTOR --region REGION

หากยังไม่ได้ตั้งค่ารหัสโปรเจ็กต์ด้วย gcloud config set project คุณอาจต้องระบุ --project PROJECT_ID หากอินสแตนซ์ Memorystore มีชื่อว่า demo-ms และเครื่องมือเชื่อมต่อ VPC ชื่อ demo-vpc และทั้ง 2 อินสแตนซ์อยู่ในภูมิภาค us-central1 ให้ออกคำสั่งคู่ต่อไปนี้และยืนยัน

$ gcloud redis instances delete demo-ms --region us-central1
You are about to delete instance [demo-ms] in [us-central1].
Any associated data will be lost.

Do you want to continue (Y/n)?

Delete request issued for: [demo-ms]
Waiting for operation [projects/PROJECT/locations/REGION/operations/operation-aaaaa-bbbbb-ccccc-ddddd] to complete...done.
Deleted instance [demo-ms].
$
$ gcloud compute networks vpc-access connectors delete demo-vpc --region us-central1
You are about to delete connector [demo-vpc] in [us-central1].
Any associated data will be lost.

Do you want to continue (Y/n)?

Delete request issued for: [demo-vpc]
Waiting for operation [projects/PROJECT/locations/REGION/operations/aaaaa-bbbb-cccc-dddd-eeeee] to complete...done.
Deleted connector [demo-vpc].

คำขอแต่ละรายการจะใช้เวลาในการเรียกใช้ 2-3 นาที ขั้นตอนเหล่านี้เป็นขั้นตอนที่ไม่บังคับหากคุณเลือกปิดโปรเจ็กต์ 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

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 นี้ โปรดค้นหาปัญหาของคุณก่อนยื่น ลิงก์สำหรับค้นหาและสร้างปัญหาใหม่

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

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

Codelab

Python 2

Python 3

โมดูล 12

รหัส

รหัส

โมดูล 13 (Codelab นี้)

รหัส

รหัส

ข้อมูลอ้างอิงออนไลน์

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

App Engine

App Engine NDB และ Cloud NDB

App Engine Memcache และ Cloud Memorystore

Cloud VPC

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

ใบอนุญาต

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