โมดูล 2: ย้ายข้อมูลจาก App Engine ndb ไปยัง Cloud NDB

1. ภาพรวม

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

บทแนะนำนี้จะสอนคุณเกี่ยวกับวิธีย้ายข้อมูลจากไลบรารีของไคลเอ็นต์ ndb (ฐานข้อมูลถัดไป) ในตัวของ App Engine ไปยังไลบรารีไคลเอ็นต์ Cloud NDB

คุณจะได้เรียนรู้วิธีการ

  • ใช้ไลบรารีของ App Engine ndb (หากคุณไม่คุ้นเคยกับ)
  • ย้ายข้อมูลจาก ndb ไปยัง Cloud NDB
  • ย้ายข้อมูลแอปไปยัง Python 3 เพิ่มเติม

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

แบบสำรวจ

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

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

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

ในโมดูล 1 เราได้ย้ายเฟรมเวิร์กเว็บจาก webapp2 ในตัวของ App Engine ไปยัง Flask แล้ว ใน Codelab นี้ เราเลิกใช้บริการในตัวของ App Engine ต่อไปโดยเปลี่ยนจากไลบรารี ndb ของ App Engine ไปใช้ Cloud NDB

เมื่อย้ายข้อมูลเสร็จแล้ว คุณจะสามารถทำสิ่งต่อไปนี้

  1. ย้ายข้อมูลไปยัง Python 3 และรันไทม์ของ App Engine รุ่นถัดไป
  2. ย้ายข้อมูลไปยัง Cloud Datastore (ไลบรารีไคลเอ็นต์สำหรับแอปที่ไม่ใช่ App Engine)
  3. จัดเก็บแอป Python 2 (หรือ 3) และย้ายข้อมูลไปยัง Cloud Run
  4. เพิ่มการใช้คิวงานของ App Engine (พุช) แล้วย้ายข้อมูลไปยัง Cloud Tasks

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

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

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

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

1. สร้างโปรเจ็กต์

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

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

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

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

โฟลเดอร์โค้ด STARTing Module 1 ควรมีเนื้อหาต่อไปนี้

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

หากดูบทแนะนำเกี่ยวกับโมดูล 1 จบแล้ว คุณจะมีโฟลเดอร์ lib ที่มี Flask และทรัพยากร Dependency ด้วย หากไม่มีโฟลเดอร์ lib ให้สร้างโฟลเดอร์ด้วยคำสั่ง pip install -t lib -r requirements.txt เพื่อให้เราทำให้แอปพื้นฐานนี้ใช้งานได้ในขั้นตอนถัดไป หากคุณมีทั้ง Python 2 และ 3 ติดตั้งไว้อยู่แล้ว เราขอแนะนําให้ใช้ pip2 แทน pip เพื่อไม่ให้สับสนกับ Python 3

3. ทำให้แอปโมดูล 1 ใช้งานได้ (อีกครั้ง)

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

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

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

4. อัปเดตไฟล์การกำหนดค่า (เพิ่มไลบรารี Cloud NDB)

บริการในตัวของ App Engine ดั้งเดิมจำนวนมากได้พัฒนาไปสู่ผลิตภัณฑ์ของตนเองและ Datastore ก็เป็นหนึ่งในนั้น ปัจจุบันแอปที่ไม่ใช่ App Engine สามารถใช้ Cloud Datastore ได้ ทีม Google Cloud ได้สร้างไลบรารีไคลเอ็นต์ Cloud NDB เพื่อพูดคุยกับ Cloud Datastore สำหรับผู้ใช้ ndb มาเป็นเวลานาน ใช้ได้กับทั้ง Python 2 และ 3

มาอัปเดตไฟล์การยืนยันเพื่อแทนที่ App Engine ndb ด้วย Cloud NDB จากนั้นแก้ไขแอปพลิเคชันของเรา

1. อัปเดต requirements.txt

ในโมดูล 1 ทรัพยากร Dependency ภายนอกเพียงรายการเดียวสำหรับแอปของเราคือ Flask ต่อไปเราจะเพิ่ม Cloud NDB นี่คือลักษณะของไฟล์ requirements.txt เมื่อจบโมดูล 1

  • ก่อน:
Flask==1.1.2

การย้ายข้อมูลออกจาก App Engine ndb ต้องใช้ไลบรารี Cloud NDB (google-cloud-ndb) ดังนั้นโปรดเพิ่มแพ็กเกจไปยัง requirements.txt

  • หลัง:
Flask==1.1.2
google-cloud-ndb==1.7.1

เมื่อมีการเขียน Codelab นี้ เวอร์ชันที่แนะนำล่าสุดคือ 1.7.1 แต่ requirements.txt ในที่เก็บอาจมีเวอร์ชันใหม่กว่า เราขอแนะนำให้ใช้เวอร์ชันล่าสุดของแต่ละไลบรารี แต่หากใช้ไม่ได้ คุณสามารถย้อนกลับไปใช้เวอร์ชันเก่าได้

ลบโฟลเดอร์ lib หากมี และไม่ได้สร้างโฟลเดอร์ด้านบน ตอนนี้ให้ติดตั้งไลบรารีที่อัปเดต (อีกครั้ง) ด้วยคำสั่ง pip install -t lib -r requirements.txt โดยใช้ pip2 แทน pip ตามความจำเป็น

2. อัปเดต app.yaml

การเพิ่มไลบรารีของไคลเอ็นต์ Google Cloud เช่น google-cloud-ndb มีข้อกำหนดบางอย่าง โดยทั้งหมดเกี่ยวข้องกับการรวม "ในตัว" เอาไว้ด้วย ไลบรารี ซึ่งเป็นแพ็กเกจของบุคคลที่สามที่มีให้ใช้งานในเซิร์ฟเวอร์ของ Google อยู่แล้ว คุณไม่ได้แสดงรายการเหล่านี้ใน requirements.txt และคัดลอกด้วย pip install ข้อกำหนดเพียงอย่างเดียวมีดังนี้

  1. ระบุไลบรารีในตัวใน app.yaml
  2. ชี้ผู้ใช้ให้ไปที่ไลบรารีของบุคคลที่สามที่คัดลอกมาซึ่งพวกเขาอาจใช้งานด้วย (ใน lib)

นี่คือ app.yaml เริ่มต้นจากโมดูล 1

  • ก่อน:
runtime: python27
threadsafe: yes
api_version: 1

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

ตอนนี้ให้เพิ่มบรรทัดต่อไปนี้ลงใน app.yaml เพื่ออ้างอิงคู่แพ็กเกจที่รวมกลุ่มของบุคคลที่สาม: grpcio และ setuptools ในส่วน libraries ใหม่:

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

เหตุผลที่ควรใช้ไลบรารีในตัวเหล่านี้ gRPC เป็นเฟรมเวิร์ก RPC แบบเปิดที่ไลบรารีของไคลเอ็นต์ Google Cloud ทั้งหมดใช้ รวมถึง google-cloud-ndb ไลบรารี grpcio เป็นอะแดปเตอร์ gRPC ของ Python จึงจำเป็น เหตุผลในการรวม setuptools กำลังจะเกิดขึ้นแล้ว

  • หลัง:

จากการเปลี่ยนแปลงข้างต้น 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

3. อัปเดต appengine_config.py

เครื่องมือ pkg_resources ซึ่งเป็นส่วนหนึ่งของไลบรารี setuptools มีไว้เพื่อให้ไลบรารีของบุคคลที่สามในตัวเข้าถึงไลบรารีที่รวมอยู่ในแพ็กเกจได้ อัปเดต appengine_config.py เพื่อใช้ pkg_resources เพื่อชี้ไปยังไลบรารีที่รวมอยู่ใน lib เมื่อทำการเปลี่ยนแปลงนี้เสร็จแล้ว ทั้งไฟล์ควรมีลักษณะดังนี้

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)

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

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

1. การนำเข้า

ดำเนินการสลับการนำเข้าต่อไปนี้ใน main.py

  • ก่อน
from google.appengine.ext import ndb
  • หลัง:
from google.cloud import ndb

บางครั้งการเปลี่ยนแปลงจากไลบรารี App Engine เป็นไลบรารี Google Cloud ก็ซับซ้อนน้อยกว่าอินสแตนซ์นี้ สำหรับบริการในตัวที่กลายเป็นผลิตภัณฑ์ Google Cloud อย่างเต็มรูปแบบ คุณจะนำเข้าแอตทริบิวต์จาก google.cloud แทนที่จะเป็น google.appengine

2. สิทธิ์เข้าถึงพื้นที่เก็บข้อมูล

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

ในทำนองเดียวกัน Cloud NDB กำหนดให้คุณต้องได้รับบริบทของไคลเอ็นต์เพื่อสื่อสารกับ Datastore ก่อนที่คำสั่งของ Datastore ใดๆ จะทำงานได้ ขั้นแรก ให้สร้างไคลเอ็นต์ (ndb.Client()) โดยเพิ่ม ds_client = ndb.Client() ใน main.py หลังจากการเริ่มต้น Flask ดังนี้

app = Flask(__name__)
ds_client = ndb.Client()

คำสั่ง Pythonwith จะใช้เพื่อรับบริบทของออบเจ็กต์เท่านั้น รวมโค้ดบล็อกที่เข้าถึง Datastore ด้วยคำสั่ง with

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

  • ก่อน:

นี่คือโค้ดต้นฉบับที่ไม่มีการจัดการบริบท:

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 (v.to_dict() for v in Visit.query().order(
            -Visit.timestamp).fetch(limit))
  • หลัง:

ตอนนี้ ให้เพิ่ม with ds_client.context(): และย้ายรหัสการเข้าถึงพื้นที่เก็บข้อมูลไปไว้ในบล็อก with:

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 (v.to_dict() for v in Visit.query().order(
                -Visit.timestamp).fetch(limit))

แอปพลิเคชันไดรเวอร์หลักยังคงเหมือนกับสิ่งที่เรามีจากโมดูล 1 เนื่องจากไม่มีโค้ด ndb (หรือ Cloud NDB) ที่นี่

@app.route('/')
def root():
    'main application (GET) handler'
    store_visit(request.remote_addr, request.user_agent)
    visits = fetch_visits(10)
    return render_template('index.html', visits=visits)

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

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

ทำให้แอปพลิเคชันใช้งานได้

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

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

แอปvisitme

ขอแสดงความยินดีที่ Codelab ของโมดูล 2 นี้เสร็จสมบูรณ์ ผ่านเส้นชัยแล้ว เนื่องจากนี่คือการย้ายข้อมูลครั้งสุดท้ายที่แนะนำอย่างยิ่งในซีรีส์นี้ เท่าที่ Datastore จะยังได้รับ

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

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

ไม่บังคับ: ปิดใช้แอป

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

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

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

จากจุดนี้ คุณสามารถดำเนินการในขั้นตอนถัดไปได้อย่างยืดหยุ่น เลือกตัวเลือกใดตัวเลือกหนึ่งต่อไปนี้

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

7. โบนัส: ย้ายข้อมูลไปยัง Python 3

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

ภาพรวม

แม้ว่าการพอร์ตไปยัง Python 3 จะไม่อยู่ในขอบเขตของบทแนะนำของ Google Cloud แต่ส่วนของ Codelab ในส่วนนี้จะช่วยให้นักพัฒนาซอฟต์แวร์เข้าใจความแตกต่างระหว่างรันไทม์ของ Python 3 App Engine ฟีเจอร์เด่นๆ ของรันไทม์รุ่นถัดไปคือการเข้าถึงแพ็กเกจของบุคคลที่สามที่ง่ายขึ้น ไม่จำเป็นต้องระบุแพ็กเกจในตัวใน app.yaml หรือเป็นข้อกำหนดในการคัดลอกหรืออัปโหลดไลบรารีที่ไม่ได้ในตัว แอปเหล่านี้ติดตั้งโดยปริยายจากการแสดงใน requirements.txt

เนื่องจากตัวอย่างของเราเป็นแบบพื้นฐานและ Cloud NDB รองรับ Python 2-3 จึงไม่จำเป็นต้องพอร์ตโค้ดแอปพลิเคชันไปยัง 3.x อย่างชัดเจน แอปทำงานบน 2.x และ 3.x โดยไม่มีการแก้ไข ซึ่งหมายความว่าในกรณีนี้ระบบจะกำหนดค่าเฉพาะการเปลี่ยนแปลงที่จำเป็นเท่านั้น

  1. ลดความซับซ้อนของ app.yaml เพื่ออ้างอิง Python 3 และนำไลบรารีของบุคคลที่สามออก
  2. ลบ appengine_config.py และโฟลเดอร์ lib เนื่องจากไม่จำเป็นต้องใช้แล้ว

นอกเหนือจาก main.py ไฟล์ requirements.txt และ templates/index.html จะไม่มีการเปลี่ยนแปลง

ทำให้ app.yaml ง่ายขึ้น

ก่อน:

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

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

หลัง:

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

ไม่บังคับ: การใช้คำสั่ง handlers

นอกจากนี้ ได้มีการเลิกใช้งานคำสั่ง handlers ซึ่งกำหนดเส้นทางการรับส่งข้อมูลไปยังแอปพลิเคชัน App Engine แล้วด้วย เนื่องจากรันไทม์รุ่นถัดไปคาดหวังให้เว็บเฟรมเวิร์กสามารถจัดการการกำหนดเส้นทางแอปได้ ดังนั้น "สคริปต์สำหรับแฮนเดิล" ทั้งหมด ต้องเปลี่ยนเป็น "auto" เมื่อรวมการเปลี่ยนแปลงจากด้านบน คุณมาถึง app.yaml นี้:

runtime: python38

handlers:
- url: /.*
  script: auto

ดูข้อมูลเพิ่มเติมเกี่ยวกับ script: auto จากหน้าเอกสารประกอบ

กำลังนำคำสั่ง handlers ออก

เนื่องจาก handlers เลิกใช้งานแล้ว คุณสามารถนำทั้งหัวข้อออกได้ด้วย โดยเหลือบรรทัดเดียวคือ app.yaml:

runtime: python38

การดำเนินการนี้จะเปิดเว็บเซิร์ฟเวอร์ Gunicorn WSGI ซึ่งใช้ได้กับแอปพลิเคชันทั้งหมดโดยค่าเริ่มต้น หากคุณคุ้นเคยกับ gunicorn นี่คือคำสั่งที่ลงนามเมื่อเริ่มต้นใช้งานโดยค่าเริ่มต้นด้วย Barebones app.yaml:

gunicorn main:app --workers 2 -c /config/gunicorn.py

ไม่บังคับ: การใช้คำสั่ง entrypoint

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

runtime: python38
entrypoint: python main.py

ตัวอย่างนี้ส่งคำขอให้ใช้เซิร์ฟเวอร์การพัฒนา Flask แทน gunicorn คุณต้องเพิ่มโค้ดที่เริ่มต้นเซิร์ฟเวอร์การพัฒนาในแอปเพื่อเปิดใช้อินเทอร์เฟซ 0.0.0.0 บนพอร์ต 8080 ด้วยการเพิ่มส่วนเล็กๆ นี้ที่ด้านล่างของ main.py

if __name__ == '__main__':
    app.run(host='0.0.0.0', port=8080, debug=True)

ดูข้อมูลเพิ่มเติมเกี่ยวกับ entrypoint จากหน้าเอกสารประกอบ ดูตัวอย่างและแนวทางปฏิบัติแนะนำเพิ่มเติมได้ในเอกสารการเริ่มต้นใช้งาน App Engine แบบมาตรฐาน และเอกสารการเริ่มต้นใช้งาน App Engine แบบยืดหยุ่น

ลบ appengine_config.py และ lib

ลบไฟล์ appengine_config.py และโฟลเดอร์ lib ในการย้ายข้อมูลไปยัง Python 3 App Engine จะซื้อและติดตั้งแพ็กเกจที่ระบุไว้ใน requirements.txt

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

  1. ไม่มีการรวมกลุ่มไลบรารีของบุคคลที่สามที่คัดลอกไว้ (แสดงใน requirements.txt)
  2. ไม่มี pip install ในโฟลเดอร์ lib ซึ่งหมายความว่าไม่มีเครื่องหมายจุด lib ของโฟลเดอร์
  3. ไม่มีข้อมูลไลบรารีของบุคคลที่สามในตัวใน app.yaml
  4. ไม่จำเป็นต้องอ้างอิงแอปไปยังไลบรารีของบุคคลที่สาม ดังนั้นจึงไม่มีไฟล์ appengine_config.py

จำเป็นต้องมีการแสดงไลบรารีของบุคคลที่สามทั้งหมดที่จำเป็นใน requirements.txt

ทำให้แอปพลิเคชันใช้งานได้

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

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

กำลังเตรียมแอปพลิเคชันของคุณ

เมื่อถึงเวลาย้ายข้อมูลแอปพลิเคชันของคุณ คุณจะต้องย้าย main.py และไฟล์แอปพลิเคชันอื่นๆ เป็น 3.x ดังนั้นแนวทางปฏิบัติที่ดีที่สุดคือพยายามทำให้แอปพลิเคชัน 2.x ของคุณ "ใช้ร่วมกันได้" อย่างเต็มที่ ให้มากที่สุด

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

  1. ตรวจสอบว่าการพึ่งพาแอปพลิเคชันทั้งหมดเข้ากันได้กับ 3.x อย่างสมบูรณ์
  2. ตรวจสอบว่าแอปพลิเคชันของคุณทำงานบนเวอร์ชัน 2.6 เป็นอย่างน้อย (ควรเป็น 2.7)
  3. ตรวจสอบว่าแอปพลิเคชันผ่านชุดทดสอบทั้งชุด (และครอบคลุมอย่างน้อย 80%)
  4. ใช้ไลบรารีความเข้ากันได้ เช่น six, Future และ/หรือ Modernize
  5. เรียนรู้เกี่ยวกับความแตกต่าง 2.x หรือ 3.x ที่ใช้ร่วมกันไม่ได้กับคีย์ย้อนหลัง
  6. ทุก I/O มักจะนำไปสู่ความไม่เข้ากันระหว่าง Unicode กับไบต์ของสตริง

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

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

ปัญหา/ข้อเสนอแนะเกี่ยวกับ Codelab ของโมดูลการย้ายข้อมูล App Engine

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

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

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

Codelab

Python 2

Python 3

โมดูล 1

รหัส

(ไม่มี)

โมดูล 2

รหัส

รหัส

ทรัพยากร App Engine

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