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

1. ภาพรวม

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

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

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

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

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

แบบสำรวจ

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

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

2. ฉากหลัง

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

การย้ายข้อมูลนี้จะช่วยให้คุณทำสิ่งต่อไปนี้ได้

  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. ตั้งค่าโปรเจ็กต์

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

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

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

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

โฟลเดอร์โค้ดของโมดูลที่ 1 ของ START ควรมีเนื้อหาต่อไปนี้

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

หากทำบทแนะนำโมดูลที่ 1 เสร็จแล้ว คุณจะมีโฟลเดอร์ lib ที่มี Flask และทรัพยากร Dependency ของ Flask ด้วย หากไม่มีโฟลเดอร์ 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 ได้ สำหรับผู้ใช้ ndb มาอย่างยาวนาน ทีม Google Cloud ได้สร้างไลบรารีไคลเอ็นต์ Cloud NDB เพื่อสื่อสารกับ Cloud Datastore โดยใช้ได้ทั้ง Python 2 และ 3

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

1. อัปเดต requirements.txt

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

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

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

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

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

จากนี้ไป คุณจะยืดหยุ่นในการดำเนินการขั้นต่อไปได้ เลือกตัวเลือกใดก็ได้ต่อไปนี้

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

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

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

รหัส

(ไม่มี)

Module 2

รหัส

รหัส

ทรัพยากร App Engine

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