Mô-đun 11: Di chuyển từ Google App Engine sang Cloud Functions

1. Tổng quan

Loạt lớp học lập trình Serverless Migration Station (hướng dẫn thực hành theo tốc độ của riêng bạn) và các video liên quan nhằm giúp các nhà phát triển Google Cloud không máy chủ hiện đại hoá các ứng dụng của họ bằng cách hướng dẫn họ thực hiện một hoặc nhiều quy trình di chuyển, chủ yếu là chuyển từ các dịch vụ cũ. Làm như vậy sẽ giúp ứng dụng của bạn dễ dàng di chuyển hơn, đồng thời mang đến cho bạn nhiều lựa chọn và sự linh hoạt hơn, cho phép bạn tích hợp và truy cập vào nhiều sản phẩm trên đám mây hơn, cũng như dễ dàng nâng cấp lên các bản phát hành ngôn ngữ mới hơn. Mặc dù ban đầu tập trung vào những người dùng Cloud sớm nhất, chủ yếu là các nhà phát triển App Engine (môi trường tiêu chuẩn), nhưng loạt bài này đủ rộng để bao gồm các nền tảng không máy chủ khác như Cloud Functions và Cloud Run, hoặc ở những nơi khác nếu có thể.

Có những trường hợp bạn không có "toàn bộ ứng dụng" để yêu cầu tài nguyên của App Engine hoặc Cloud Run. Nếu mã của bạn chỉ bao gồm một vi dịch vụ hoặc hàm đơn giản, thì Cloud Functions có thể phù hợp hơn. Lớp học lập trình này hướng dẫn bạn cách di chuyển các ứng dụng App Engine đơn giản (hoặc chia các ứng dụng lớn thành nhiều vi dịch vụ) và triển khai chúng vào Cloud Functions, một nền tảng không máy chủ khác được tạo riêng cho các trường hợp sử dụng như thế này.

Bạn sẽ tìm hiểu cách

  • Sử dụng Cloud Shell
  • Bật Google Cloud Translation API
  • Xác thực các yêu cầu API
  • Chuyển đổi một ứng dụng App Engine nhỏ để chạy trên Cloud Functions
  • Triển khai mã của bạn lên Cloud Functions

Bạn cần có

Khảo sát

Bạn sẽ sử dụng hướng dẫn này như thế nào?

Chỉ đọc Đọc và hoàn thành bài tập

Bạn đánh giá thế nào về trải nghiệm của mình với Python?

Người mới bắt đầu Trung cấp Thành thạo

Bạn đánh giá thế nào về trải nghiệm khi sử dụng các dịch vụ của Google Cloud?

Người mới bắt đầu Trung cấp Thành thạo

2. Thông tin khái quát

Các hệ thống PaaS như Google App Engine và Cloud Functions mang lại nhiều tiện ích cho người dùng. Những nền tảng không máy chủ này giúp nhóm kỹ thuật của bạn tập trung vào việc tạo ra các giải pháp kinh doanh thay vì mất thời gian tìm hiểu các nền tảng để sử dụng và xác định lượng phần cứng cần thiết. Các ứng dụng có thể tự động mở rộng quy mô khi cần, giảm quy mô xuống 0 với mô hình thanh toán theo mức sử dụng để kiểm soát chi phí và hỗ trợ nhiều ngôn ngữ phát triển phổ biến hiện nay.

Tuy nhiên, mặc dù việc phát triển ứng dụng web toàn diện hoặc các phần phụ trợ phức tạp cho ứng dụng di động rất phù hợp với App Engine, nhưng thường thì các nhà phát triển chủ yếu cố gắng đưa một số chức năng lên mạng, chẳng hạn như cập nhật nguồn cấp tin tức hoặc lấy điểm số mới nhất của trận đấu loại trực tiếp của đội nhà. Mặc dù có logic mã cho cả hai trường hợp, nhưng không trường hợp nào có vẻ là "ứng dụng" hoàn chỉnh đòi hỏi sức mạnh của App Engine. Đây là lúc Cloud Functions phát huy tác dụng.

Cloud Functions dùng để triển khai đoạn mã nhỏ:

  • Không phải là một phần của toàn bộ ứng dụng
  • Không cần thiết trong toàn bộ ngăn xếp phát triển
  • Nằm trong một ứng dụng hoặc một phần phụ trợ của ứng dụng di động tập trung vào một việc

Bạn cũng có thể dùng Cloud Functions để chia một ứng dụng lớn, nguyên khối thành nhiều vi dịch vụ, mỗi dịch vụ dùng một cơ sở dữ liệu chung, chẳng hạn như Cloud Firestore hoặc Cloud SQL. Và nếu muốn vùng chứa chức năng hoặc vi dịch vụ của bạn được chứa trong vùng chứa và thực thi mà không cần máy chủ trên Cloud Run, bạn cũng có thể làm như vậy.

Ứng dụng mẫu App Engine mà chúng tôi đã giới thiệu trong hầu hết các hướng dẫn di chuyển là một ứng dụng ngắn có chức năng cơ bản, hoạt động tốt trong Cloud Functions. Trong hướng dẫn này, bạn sẽ tìm hiểu cách sửa đổi ứng dụng đó để chạy trên Cloud Functions. Theo quan điểm của App Engine, vì các hàm đơn giản hơn toàn bộ ứng dụng, nên trải nghiệm bắt đầu của bạn sẽ dễ dàng (và nhanh hơn) và nói chung là ít "chi phí" hơn. Quá trình di chuyển này có các bước sau:

  • Thiết lập/Công việc chuẩn bị
  • Xoá tệp cấu hình
  • Sửa đổi tệp ứng dụng

3. Thiết lập/Công việc chuẩn bị

Lớp học lập trình này bắt đầu với phiên bản Python 3 của ứng dụng mẫu Module 2 Cloud NDB App Engine vì Cloud Functions không hỗ trợ Python 2. Trước tiên, hãy thiết lập dự án, lấy mã, sau đó triển khai ứng dụng cơ sở để xác nhận rằng chúng ta đang bắt đầu bằng mã hoạt động.

1. Thiết lập dự án

Nếu đã hoàn thành lớp học lập trình Mô-đun 2 (và chuyển sang Python 3), bạn nên sử dụng lại chính dự án (và mã) đó. Ngoài ra, bạn có thể tạo một dự án hoàn toàn mới hoặc sử dụng lại một dự án hiện có khác. Đảm bảo dự án có một tài khoản thanh toán đang hoạt động và đã bật dịch vụ App Engine.

2. Tải ứng dụng mẫu cơ sở

Một trong những điều kiện tiên quyết của lớp học lập trình này là bạn phải có một ứng dụng mẫu Module 2 đang hoạt động. Nếu không có, hãy hoàn thành một trong hai hướng dẫn được liên kết ở trên trước khi tiếp tục ở đây. Nếu đã quen thuộc với nội dung của lớp học lập trình này, bạn có thể bắt đầu bằng cách lấy mã của Mô-đun 2 bên dưới.

Cho dù bạn sử dụng mã của mình hay của chúng tôi, mã Python 3 của Mô-đun 2 sẽ là nơi chúng ta BẮT ĐẦU. Lớp học lập trình Mô-đun 11 này sẽ hướng dẫn bạn từng bước, kết thúc bằng đoạn mã tương tự như đoạn mã trong thư mục kho lưu trữ Mô-đun 11 (FINISH).

Thư mục của các tệp BẮT ĐẦU Mô-đun 2 Python 3 (của bạn hoặc của chúng tôi) sẽ có dạng như sau:

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

3. (Triển khai lại) Ứng dụng cơ sở

Các bước chuẩn bị còn lại mà bạn cần thực hiện ngay:

  1. Làm quen lại với công cụ dòng lệnh gcloud
  2. Triển khai lại ứng dụng mẫu bằng gcloud app deploy
  3. Xác nhận rằng ứng dụng chạy trên App Engine mà không gặp vấn đề

Sau khi thực hiện thành công các bước đó, bạn đã sẵn sàng chuyển đổi thành Cloud Function.

4. Xoá tệp cấu hình

Tệp app.yaml là một cấu phần phần mềm App Engine không được dùng với Cloud Functions, vì vậy, hãy xoá tệp này ngay. Nếu bạn không thực hiện hoặc quên thực hiện việc này, thì cũng không có vấn đề gì vì Cloud Functions không sử dụng nó. Đó là thay đổi duy nhất về cấu hình vì requirements.txt vẫn giống như trong Phụ lục 2.

Nếu bạn cũng đang chuyển một ứng dụng Python 2 App Engine sang Python 3, hãy xoá appengine_config.py và thư mục lib (nếu có). Đây là những cấu phần phần mềm App Engine không được dùng trong thời gian chạy Python 3.

5. Sửa đổi tệp ứng dụng

Chỉ có một tệp ứng dụng, main.py, vì vậy, mọi thay đổi cần thiết để chuyển sang Cloud Functions đều diễn ra trong tệp này.

Nhập

Vì chúng ta chỉ làm việc với các hàm nên không cần đến khung ứng dụng web. Tuy nhiên, để thuận tiện, khi các Cloud Functions dựa trên Python được gọi, chúng sẽ tự động được truyền một đối tượng yêu cầu để mã của bạn sử dụng khi cần. (Nhóm Cloud Functions đã chọn đối tượng này làm đối tượng Yêu cầu Flask được truyền đến hàm của bạn.)

Vì các khung web không thuộc phạm vi của Cloud Functions, nên không có nội dung nhập từ Flask trừ phi ứng dụng của bạn sử dụng các tính năng khác của Flask. Đây thực sự là trường hợp của chúng ta vì quá trình kết xuất mẫu vẫn diễn ra sau khi chuyển đổi thành một hàm, tức là vẫn cần gọi flask.render_template(), do đó, cần nhập hàm này từ Flask. Không có khung web nghĩa là bạn không cần tạo thực thể một ứng dụng Flask, vì vậy hãy xoá app = Flask(__name__). Mã của bạn sẽ có dạng như sau, trước và sau khi áp dụng các thay đổi:

TRƯỚC:

from flask import Flask, render_template, request
from google.cloud import ndb

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

SAU:

from flask import render_template
from google.cloud import ndb

ds_client = ndb.Client()

Nếu phụ thuộc vào đối tượng ứng dụng (app) hoặc bất kỳ cơ sở hạ tầng khung web nào khác, bạn cần giải quyết tất cả các phần phụ thuộc đó, tìm ra các giải pháp thay thế phù hợp hoặc xoá hoàn toàn việc sử dụng các phần phụ thuộc đó hoặc tìm các proxy. Chỉ khi đó, bạn mới có thể chuyển đổi mã của mình thành một Cloud Function. Nếu không, bạn nên tiếp tục sử dụng App Engine hoặc chuyển ứng dụng của mình vào vùng chứa cho Cloud Run

Cập nhật chữ ký hàm trình xử lý chính

Sau đây là những thay đổi bắt buộc trong chữ ký hàm:

  1. Flask không còn được dùng sau khi chuyển đổi ứng dụng thành một Cloud Function, vì vậy, hãy xoá các trình trang trí tuyến đường.
  2. Cloud Functions tự động truyền đối tượng Flask Request dưới dạng một tham số, vì vậy, hãy tạo một biến cho đối tượng đó. Trong ứng dụng mẫu, chúng ta sẽ gọi nó là request.
  3. Bạn phải đặt tên cho Cloud Functions đã triển khai. Trình xử lý chính của chúng tôi được đặt tên thích hợp là root() trong App Engine để mô tả chức năng của trình xử lý đó (trình xử lý ứng dụng gốc). Là một Cloud Function, việc sử dụng tên đó sẽ ít hợp lý hơn. Thay vào đó, chúng ta sẽ triển khai Cloud Functions có tên là visitme, vì vậy, hãy dùng tên đó làm tên của hàm Python. Tương tự, trong Mô-đun 4 và 5, chúng ta cũng đặt tên cho dịch vụ Cloud Run là visitme.

Sau đây là hình ảnh trước và sau khi áp dụng các nội dung cập nhật này:

TRƯỚC:

@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)

SAU:

def visitme(request):
    'main application (GET) handler'
    store_visit(request.remote_addr, request.user_agent)
    visits = fetch_visits(10)
    return render_template('index.html', visits=visits)

Đến đây là hết những nội dung cập nhật cần thiết. Xin lưu ý rằng những thay đổi được thực hiện chỉ ảnh hưởng đến mã "cơ sở hạ tầng" của ứng dụng. Bạn không cần thay đổi mã xử lý ứng dụng cốt lõi và không có chức năng nào của ứng dụng bị thay đổi. Sau đây là hình ảnh minh hoạ những thay đổi đã được thực hiện để minh hoạ điểm này:

668f30e3865b27a9.png

Phát triển và kiểm thử cục bộ

Trong khi App Engine có dev_appserver.py máy chủ phát triển cục bộ, Cloud Functions có Functions Framework. Với khung này, bạn có thể phát triển và kiểm thử cục bộ. Bạn có thể triển khai mã của mình cho Cloud Functions, nhưng cũng có thể triển khai cho các nền tảng điện toán khác như Compute Engine, Cloud Run hoặc thậm chí là các hệ thống đám mây tại chỗ hoặc đám mây kết hợp hỗ trợ Knative. Hãy xem bên dưới để biết thêm các đường liên kết đến Functions Framework.

6. Xây dựng và triển khai

Việc triển khai cho Cloud Functions hơi khác so với App Engine. Vì không có tệp cấu hình nào được dùng bên ngoài requirements.txt, nên bạn phải chỉ định thêm thông tin về mã trên dòng lệnh. Triển khai Cloud Function mới được kích hoạt bằng HTTP chạy trong Python 3.10 bằng lệnh này:

$ gcloud functions deploy visitme --runtime python310 --trigger-http --allow-unauthenticated

Kết quả dự kiến sẽ tương tự như sau:

Deploying function (may take a while - up to 2 minutes)...⠛
For Cloud Build Logs, visit: https://console.cloud.google.com/cloud-build/builds;region=REGION/f5f6fc81-1bb3-4cdb-8bfe?project=PROJECT_ID
Deploying function (may take a while - up to 2 minutes)...done.
availableMemoryMb: 256
buildId: f5f6fc81-1bb3-4cdb-8bfe
buildName: projects/PROJECT_ID/locations/REGION/builds/f5f6fc81-1bb3-4cdb-8bfe
dockerRegistry: CONTAINER_REGISTRY
entryPoint: visitme
httpsTrigger:
  securityLevel: SECURE_OPTIONAL
  url: https://REGION-PROJECT_ID.cloudfunctions.net/visitme
ingressSettings: ALLOW_ALL
labels:
  deployment-tool: cli-gcloud
name: projects/PROJECT_ID/locations/REGION/functions/visitme
runtime: python310
serviceAccountEmail: PROJECT_ID@appspot.gserviceaccount.com
sourceUploadUrl: https://storage.googleapis.com/uploads-853031211983.REGION.cloudfunctions.appspot.com/8c923758-cee8-47ce-8e97-5720a5301c34.zip
status: ACTIVE
timeout: 60s
updateTime: '2022-05-16T18:28:06.153Z'
versionId: '8'

Sau khi triển khai hàm, hãy sử dụng URL trong đầu ra triển khai và truy cập vào ứng dụng của bạn. URL có dạng: REGION-PROJECT_ID.cloudfunctions.net/visitme. Kết quả đầu ra phải giống hệt như khi bạn triển khai trước đó cho App Engine:

2732ae9218f011a2.png

Giống như hầu hết các lớp học lập trình và video khác trong loạt bài này, chức năng của ứng dụng không thay đổi. Mục đích là áp dụng một kỹ thuật hiện đại hoá và làm cho ứng dụng hoạt động chính xác như trước đây nhưng được hỗ trợ bởi cơ sở hạ tầng mới hơn, chẳng hạn như di chuyển từ một dịch vụ cũ của App Engine sang sản phẩm độc lập trên đám mây thay thế hoặc, như trong trường hợp của hướng dẫn này, di chuyển một ứng dụng sang một nền tảng không máy chủ khác của Google Cloud.

7. Tóm tắt/Dọn dẹp

Xin chúc mừng bạn đã chuyển đổi ứng dụng App Engine nhỏ này thành một Cloud Function! Một trường hợp sử dụng phù hợp khác: chia một ứng dụng App Engine nguyên khối lớn thành một loạt các vi dịch vụ, mỗi dịch vụ là một Cloud Function. Đây là một kỹ thuật phát triển hiện đại hơn, tạo ra một thành phần "cắm và chạy" hơn (theo kiểu " JAM stack"). Điều này cho phép kết hợp và so khớp, cũng như sử dụng lại mã. Đây là 2 mục tiêu, nhưng một lợi ích khác là các vi dịch vụ này sẽ tiếp tục được gỡ lỗi theo thời gian, tức là mã ổn định và chi phí bảo trì thấp hơn.

Dọn dẹp

Sau khi hoàn thành lớp học lập trình này, bạn có thể tắt ứng dụng App Engine của Mô-đun 2 (tạm thời hoặc vĩnh viễn) để tránh bị tính phí. Nền tảng App Engine có một hạn mức miễn phí, vì vậy bạn sẽ không bị tính phí miễn là bạn vẫn nằm trong cấp sử dụng của hạn mức này. Điều này cũng áp dụng cho Datastore; hãy xem trang thông tin về giá của Cloud Datastore để biết thêm thông tin.

Việc triển khai trên các nền tảng như App Engine và Cloud Functions sẽ phát sinh một khoản chi phí nhỏ cho việc tạo và lưu trữ. Ở một số khu vực, Cloud Build có hạn mức miễn phí riêng, tương tự như Cloud Storage. Các bản dựng sẽ tiêu tốn một phần hạn mức đó. Hãy chú ý đến mức sử dụng bộ nhớ để giảm thiểu chi phí tiềm ẩn, đặc biệt nếu khu vực của bạn không có bậc miễn phí như vậy.

Rất tiếc, Cloud Functions không có tính năng "tắt". Sao lưu mã của bạn và chỉ cần xoá hàm này. Bạn luôn có thể triển khai lại với cùng tên sau này. Tuy nhiên, nếu bạn không tiếp tục với bất kỳ lớp học lập trình nào khác về việc di chuyển và muốn xoá hoàn toàn mọi thứ, hãy tắt các dự án trên Cloud.

Các bước tiếp theo

Ngoài hướng dẫn này, các mô-đun di chuyển khác cần xem xét bao gồm việc tạo vùng chứa cho ứng dụng App Engine của bạn cho Cloud Run. Xem các đường liên kết đến lớp học lập trình Mô-đun 4 và Mô-đun 5:

  • Module 4: Di chuyển sang Cloud Run bằng Docker
  • Đóng gói ứng dụng của bạn vào vùng chứa để chạy trên Cloud Run bằng Docker
  • Quá trình di chuyển này cho phép bạn tiếp tục sử dụng Python 2.
  • Mô-đun 5: Di chuyển sang Cloud Run bằng Cloud Buildpacks
  • Tạo vùng chứa cho ứng dụng để chạy trên Cloud Run bằng Cloud Buildpacks
  • Bạn không cần biết gì về Docker, vùng chứa hoặc Dockerfile.
  • Yêu cầu ứng dụng của bạn đã di chuyển sang Python 3 (Buildpacks không hỗ trợ Python 2)

Nhiều mô-đun khác tập trung vào việc hướng dẫn nhà phát triển cách di chuyển từ các dịch vụ đi kèm của App Engine sang các dịch vụ thay thế độc lập trên Cloud:

  • Mô-đun 2: di chuyển từ ndb App Engine sang Cloud NDB
  • Các mô-đun 7-9: di chuyển từ các tác vụ đẩy của Hàng đợi tác vụ App Engine sang Cloud Tasks
  • Các mô-đun 12 – 13: di chuyển từ App Engine Memcache sang Cloud Memorystore
  • Các mô-đun 15-16: di chuyển từ Blobstore của App Engine sang Cloud Storage
  • Các mô-đun 18-19: di chuyển từ Hàng đợi tác vụ App Engine (kéo tác vụ) sang Cloud Pub/Sub

Nếu việc tạo vùng chứa đã trở thành một phần trong quy trình phát triển ứng dụng của bạn, đặc biệt là nếu quy trình này bao gồm một quy trình CI/CD (tích hợp liên tục/phân phối liên tục hoặc triển khai liên tục), hãy cân nhắc việc di chuyển sang Cloud Run thay vì Cloud Functions. Hãy xem Mô-đun 4 để đóng gói ứng dụng của bạn bằng Docker hoặc Mô-đun 5 để thực hiện việc này mà không cần đến các vùng chứa, kiến thức về Docker hoặc Dockerfile. Cho dù bạn đang cân nhắc Cloud Functions hay Cloud Run, việc chuyển sang một nền tảng không máy chủ khác là không bắt buộc. Bạn nên cân nhắc các lựa chọn phù hợp nhất cho ứng dụng và trường hợp sử dụng của mình trước khi thực hiện bất kỳ thay đổi nào.

Bất kể bạn cân nhắc mô-đun di chuyển nào tiếp theo, bạn đều có thể truy cập vào tất cả nội dung của Serverless Migration Station (lớp học lập trình, video, mã nguồn [nếu có]) tại kho lưu trữ nguồn mở. README của kho lưu trữ này cũng cung cấp hướng dẫn về những hoạt động di chuyển cần cân nhắc và "thứ tự" liên quan của các Mô-đun di chuyển.

8. Tài nguyên khác

Vấn đề/ý kiến phản hồi về lớp học lập trình mô-đun di chuyển App Engine

Nếu bạn gặp vấn đề với lớp học lập trình này, vui lòng tìm kiếm vấn đề của bạn trước khi báo cáo. Đường liên kết để tìm kiếm và tạo vấn đề mới:

Tài nguyên di chuyển

Bạn có thể tìm thấy đường liên kết đến các thư mục kho lưu trữ cho Mô-đun 8 (BẮT ĐẦU) và Mô-đun 9 (KẾT THÚC) trong bảng bên dưới. Bạn cũng có thể truy cập vào các hướng dẫn này trong kho lưu trữ cho tất cả các hoạt động di chuyển codelab App Engine. Bạn có thể sao chép hoặc tải tệp ZIP xuống.

Lớp học lập trình

Python 3

Mô-đun 2

code

Mô-đun 11

code

Tài nguyên trực tuyến

Dưới đây là các tài nguyên trực tuyến có thể liên quan đến hướng dẫn này:

App Engine

Cloud Functions

Thông tin khác về Cloud

Video

Giấy phép

Tác phẩm này được cấp phép theo giấy phép Ghi công theo Creative Commons 2.0 Chung.