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

1. ภาพรวม

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

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

หากไม่ได้ใช้ Memcache

หากแอปไม่ได้ใช้ App Engine Memcache คุณสามารถข้าม Codelab นี้ หรือทำเป็นแบบฝึกหัดเพื่อให้คุ้นเคยกับการย้ายข้อมูลไปยัง Cloud Memorystore

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

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

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

• โปรเจ็กต์ Google Cloud ที่มีบัญชีสำหรับการเรียกเก็บเงินที่ใช้งานอยู่ (นี่ไม่ใช่ Codelab ฟรี)
• ทักษะ Python ขั้นพื้นฐาน
• มีความรู้พื้นฐานเกี่ยวกับคำสั่ง Linux ทั่วไป
• ความรู้พื้นฐานเกี่ยวกับการพัฒนาและการทําให้แอป App Engine ใช้งานได้
• แอป App Engine ของโมดูลที่ 12 ที่ใช้งานได้ (ทำตาม Codelab ของโมดูลที่ 12 [แนะนำ] หรือคัดลอกแอปของโมดูลที่ 12 จากที่เก็บ)

แบบสำรวจ

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

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

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

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

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

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

2. ฉากหลัง

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

การย้ายข้อมูลนี้ต้องใช้ความพยายามมากกว่าการย้ายข้อมูลอื่นๆ ในชุดนี้ Cloud Memorystore คือบริการแคชบนระบบคลาวด์ที่มีการจัดการครบวงจร ซึ่งเป็นบริการทดแทนที่แนะนำสำหรับ Memcache ของ App Engine Memorystore รองรับเครื่องมือแคชโอเพนซอร์สยอดนิยม 2 รายการ ได้แก่ 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. การตั้งค่า/งานเบื้องต้น

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

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

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

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

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

• เริ่มต้น: แอป Module 12 Python 2 (mod12) หรือ Python 3 (mod12b)
• เสร็จสิ้น: Module 13 Python 2 (mod13a) หรือแอป Python 3 (mod13b)
• ที่เก็บการย้ายข้อมูลทั้งหมด (โคลนหรือดาวน์โหลด ZIP)

โฟลเดอร์ 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 ชั่วโมง

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

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

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

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

ค่าใช้จ่าย: บทแนะนำนี้ไม่ได้ให้บริการฟรี

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

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

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

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

สร้างทรัพยากรทั้งหมดในภูมิภาค App Engine

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

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

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

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

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

จาก Cloud Console

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

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

การอัปเดต Cloud Console

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

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

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

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

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

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

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

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

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

จาก Cloud Console

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

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

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

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

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

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

$ 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

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

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

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

$ 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ต่อไปนี้ (สมมติว่าเป็นภูมิภาค 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

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

จดรหัสโปรเจ็กต์ Cloud, ชื่อเครื่องมือเชื่อมต่อ VPC และภูมิภาค

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

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

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

ส่วนใหม่ที่จะเพิ่ม

รันไทม์ของ App Engine สำหรับ Python 2 ต้องใช้แพ็กเกจของบุคคลที่สามที่เฉพาะเจาะจงเมื่อใช้ 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

*ความแตกต่างของ 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

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

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

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

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

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

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

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

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

ส่วนการนำเข้าใน 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 ต้องอ่านตัวแปรสภาพแวดล้อม ซึ่งหมายความว่าเราต้องใช้โมดูล Python os รวมถึง redis ซึ่งเป็นไคลเอ็นต์ Redis ของ Python เนื่องจาก Redis ไม่สามารถแคชออบเจ็กต์ Python ได้ ให้จัดรูปแบบรายการการเข้าชมล่าสุดโดยใช้ pickle ดังนั้นให้ทำเช่นเดียวกัน ข้อดีอย่างหนึ่งของ Memcache คือการซีเรียลไลซ์ออบเจ็กต์จะเกิดขึ้นโดยอัตโนมัติ ในขณะที่ Memorystore จะเป็นแบบ "ทำเอง" มากกว่า สุดท้าย ให้อัปเกรดจาก 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" และ "set" เช่นเดียวกับ Memcache เราเพียงแค่สลับไลบรารีของไคลเอ็นต์ที่เกี่ยวข้องใช่ไหม เกือบถูกแล้ว ดังที่ได้กล่าวไปก่อนหน้านี้ เราไม่สามารถแคชรายการ Python ด้วย Redis (เนื่องจากต้องมีการซีเรียลไลซ์ก่อน ซึ่ง Memcache จะจัดการให้โดยอัตโนมัติ) ดังนั้นในฟังก์ชัน set() เราจึง "ดอง" การเข้าชมเป็นสตริงด้วย 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

App Engine NDB และ Cloud NDB มีการแคชอัตโนมัติ

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

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

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 ทุกประการ

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

ล้างข้อมูล

ทั่วไป

หากคุณดำเนินการเสร็จแล้วในตอนนี้ เราขอแนะนำให้ปิดใช้แอป App Engine เพื่อไม่ให้มีการเรียกเก็บเงิน อย่างไรก็ตาม หากต้องการทดสอบหรือทดลองเพิ่มเติม แพลตฟอร์ม App Engine มีโควต้าฟรี ดังนั้นตราบใดที่คุณไม่เกินระดับการใช้งานดังกล่าว คุณก็จะไม่ถูกเรียกเก็บเงิน ซึ่งเป็นค่าบริการสำหรับการประมวลผล แต่อาจมีค่าบริการสำหรับบริการ App Engine ที่เกี่ยวข้องด้วย ดังนั้นโปรดดูข้อมูลเพิ่มเติมในหน้าการกำหนดราคา หากการย้ายข้อมูลนี้เกี่ยวข้องกับบริการอื่นๆ ของระบบคลาวด์ ระบบจะเรียกเก็บเงินสำหรับบริการเหล่านั้นแยกต่างหาก ไม่ว่าจะในกรณีใดก็ตาม หากมี ให้ดูส่วน "เฉพาะสำหรับ 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*ation ของคุณ เช่น "us" หากแอปโฮสต์อยู่ในสหรัฐอเมริกา

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

เฉพาะสำหรับ Codelab นี้

บริการที่ระบุไว้ด้านล่างเป็นบริการเฉพาะสำหรับโค้ดแล็บนี้ ดูข้อมูลเพิ่มเติมได้ในเอกสารประกอบของแต่ละผลิตภัณฑ์

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

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

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

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

คำสั่ง 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].

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

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

นอกเหนือจากบทแนะนำนี้ โมดูลการย้ายข้อมูลอื่นๆ ที่มุ่งเน้นการย้ายออกจากบริการแบบแพ็กเกจเดิมที่ควรพิจารณา ได้แก่

• โมดูลที่ 2: ย้ายข้อมูลจาก App Engine ndb ไปยัง Cloud NDB
• โมดูล 7-9: ย้ายข้อมูลจากงานแบบพุชของคิวงาน App Engine ไปยัง Cloud Tasks
• โมดูล 12-13: ย้ายข้อมูลจาก Memcache ของ App Engine ไปยัง Cloud Memorystore
• โมดูล 15-16: ย้ายข้อมูลจาก App Engine Blobstore ไปยัง Cloud Storage
• โมดูล 18-19: ย้ายข้อมูลจากคิวงานของ App Engine (งานแบบดึง) ไปยัง Cloud Pub/Sub

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

• ย้ายข้อมูลจาก App Engine ไปยัง Cloud Functions: ดูโมดูลที่ 11
• ย้ายข้อมูลจาก App Engine ไปยัง Cloud Run: ดูโมดูลที่ 4 เพื่อจัดคอนเทนเนอร์แอปด้วย Docker หรือโมดูลที่ 5 เพื่อดำเนินการโดยไม่ต้องใช้คอนเทนเนอร์ ความรู้เกี่ยวกับ Docker หรือ Dockerfile

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

ไม่ว่าคุณจะพิจารณาโมดูลการย้ายข้อมูลใดเป็นโมดูลถัดไป คุณจะเข้าถึงเนื้อหาของ Serverless Migration Station ทั้งหมด (Codelab, วิดีโอ, ซอร์สโค้ด [หากมี]) ได้ที่ที่เก็บแบบโอเพนซอร์ส README ของที่เก็บยังให้คำแนะนำเกี่ยวกับการย้ายข้อมูลที่ควรพิจารณาและ "ลำดับ" ที่เกี่ยวข้องของโมดูลการย้ายข้อมูลด้วย

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

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

ปัญหา/ความคิดเห็นเกี่ยวกับ Codelabs

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

• ค้นหาปัญหา
• ยื่นปัญหา/ความคิดเห็นใหม่

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

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

Codelab	Python 2	Python 3
โมดูล 12	รหัส	รหัส
โมดูล 13 (Codelab นี้)	รหัส	รหัส

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

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

App Engine

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

App Engine NDB และ Cloud NDB

• ภาพรวม NDB ของ App Engine
• การใช้งาน Datastore ของ NDB ใน App Engine
• เอกสารประกอบ NDB ของ Google Cloud
• ที่เก็บ Google Cloud NDB
• ข้อมูลราคาของ Cloud Datastore

Memcache ของ App Engine และ Cloud Memorystore

• ภาพรวม Memcache ของ App Engine
• เอกสารอ้างอิง memcacheApp Engine สำหรับ Python 2
• เอกสารอ้างอิง memcachePython 3 App Engine
• คู่มือการย้ายข้อมูลจาก App Engine memcache ไปยัง Cloud Memorystore
• เอกสารประกอบของ Cloud Memorystore
• เอกสารประกอบของ Cloud Memorystore สำหรับ Redis
• ข้อมูลราคาของ Cloud Memorystore สำหรับ Redis
• เวอร์ชัน Redis ที่ Cloud Memorystore รองรับ
• หน้าแรกของ Cloud Memorystore
• สร้างอินสแตนซ์ Memorystore ใหม่ใน Cloud Console
• หน้าแรกของไคลเอ็นต์ Redis สำหรับ Python
• เอกสารประกอบของไลบรารีของไคลเอ็นต์ Redis สำหรับ Python

VPC ของ Cloud

• เอกสาร VPC ของ Google Cloud
• หน้าแรกของ VPC ใน Google Cloud
• ข้อมูลราคาของ Cloud VPC
• สร้างเครื่องมือเชื่อมต่อการเข้าถึง VPC แบบ Serverless ใหม่ใน Cloud Console

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

• Python ใน Google Cloud Platform
• ไลบรารีของไคลเอ็นต์ Python สำหรับ Google Cloud
• ระดับ "ฟรีตลอด" ของ Google Cloud
• Google Cloud SDK (gcloud เครื่องมือบรรทัดคำสั่ง)
• เอกสารประกอบทั้งหมดของ Google Cloud

ใบอนุญาต

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