1. Giới thiệu
Cloud Spanner là một dịch vụ cơ sở dữ liệu quan hệ, được phân phối toàn cầu, có thể mở rộng theo chiều ngang, được quản lý toàn diện. Dịch vụ này cung cấp các giao dịch ACID và ngữ nghĩa SQL mà không làm giảm hiệu suất và khả năng hoạt động cao.
GKE Autopilot là một chế độ hoạt động trong GKE, trong đó Google quản lý cấu hình cụm của bạn, bao gồm cả các nút, điều chỉnh tỷ lệ, bảo mật và các chế độ cài đặt được định cấu hình sẵn khác nhằm tuân thủ các phương pháp hay nhất. Ví dụ: GKE Autopilot cho phép Workload Identity quản lý quyền sử dụng dịch vụ.
Mục tiêu của phòng thí nghiệm này là hướng dẫn bạn thực hiện quy trình kết nối một số dịch vụ phụ trợ chạy trên GKE Autopilot với cơ sở dữ liệu Cloud Spanner.
Trong phòng thí nghiệm này, trước tiên, bạn sẽ thiết lập một dự án và chạy Cloud Shell. Sau đó, bạn sẽ triển khai cơ sở hạ tầng bằng Terraform.
Khi hoàn tất, bạn sẽ tương tác với Cloud Build và Cloud Deploy để thực hiện quy trình di chuyển giản đồ ban đầu cho cơ sở dữ liệu Trò chơi, triển khai các dịch vụ phụ trợ, sau đó triển khai khối lượng công việc.
Các dịch vụ trong lớp học lập trình này cũng giống như các dịch vụ trong lớp học lập trình Cloud Spanner Bắt đầu phát triển trò chơi. Bạn không bắt buộc phải tham gia lớp học lập trình đó để có thể chạy các dịch vụ trên GKE và kết nối với Spanner. Tuy nhiên, nếu bạn muốn biết thêm chi tiết cụ thể về các dịch vụ hoạt động trên Spanner, hãy xem qua.
Khi tải công việc và các dịch vụ phụ trợ đang chạy, bạn có thể bắt đầu tạo tải và quan sát cách các dịch vụ phối hợp hoạt động.
Cuối cùng, bạn sẽ dọn dẹp các tài nguyên đã tạo trong phòng thí nghiệm này.
Sản phẩm bạn sẽ tạo ra
Trong phòng thí nghiệm này, bạn sẽ:
- Cung cấp cơ sở hạ tầng bằng Terraform
- Tạo giản đồ cơ sở dữ liệu bằng quy trình Di chuyển giản đồ trong Cloud Build
- Triển khai 4 dịch vụ phụ trợ Golang tận dụng Workload Identity để kết nối với Cloud Spanner
- Triển khai 4 dịch vụ tải công việc dùng để mô phỏng tải cho các dịch vụ phụ trợ.
Kiến thức bạn sẽ học được
- Cách cung cấp các quy trình Tự động triển khai của GKE, Cloud Spanner và Triển khai đám mây bằng Terraform
- Cách Workload Identity cho phép các dịch vụ trên GKE có thể mạo danh tài khoản dịch vụ để truy cập vào các quyền IAM để hoạt động với Cloud Spanner
- Cách tạo tải giống như phát hành công khai cho GKE và Cloud Spanner bằng Locust.io
Bạn cần có
2. Thiết lập và yêu cầu
Tạo một dự án
Nếu chưa có Tài khoản Google (Gmail hoặc Google Apps), bạn phải tạo một tài khoản. Đăng nhập vào bảng điều khiển Google Cloud Platform ( console.cloud.google.com) và tạo một dự án mới.
Nếu bạn đã có một dự án, hãy nhấp vào trình đơn kéo xuống để chọn dự án ở phía trên bên trái của bảng điều khiển:
rồi nhấp vào "Dự án MỚI" trong hộp thoại kết quả để tạo một dự án mới:
Nếu chưa có dự án nào, bạn sẽ thấy một hộp thoại như sau để tạo dự án đầu tiên:
Hộp thoại tạo dự án tiếp theo cho phép bạn nhập thông tin chi tiết về dự án mới:
Xin lưu ý rằng mã dự án là tên duy nhất trong tất cả dự án Google Cloud (tên ở trên đã được sử dụng nên sẽ không phù hợp với bạn!). Lớp này sẽ được đề cập sau trong lớp học lập trình này là PROJECT_ID.
Tiếp theo, nếu chưa bật tính năng thanh toán, bạn sẽ phải bật tính năng thanh toán trong Developers Console để có thể sử dụng tài nguyên trên Google Cloud và bật Cloud Spanner API.
Bạn sẽ không mất quá vài đô la khi chạy lớp học lập trình này, nhưng có thể sẽ cao hơn nếu bạn quyết định sử dụng nhiều tài nguyên hơn hoặc nếu bạn để chúng chạy (xem phần "dọn dẹp" ở cuối tài liệu này). Giá của Google Cloud Spanner được nêu tại đây và dịch vụ GKE Autopilot được nêu tại đây.
Người dùng mới của Google Cloud Platform đủ điều kiện nhận 300 USD dùng thử miễn phí. Vì vậy, lớp học lập trình này sẽ hoàn toàn miễn phí.
Thiết lập Cloud Shell
Mặc dù bạn có thể vận hành Google Cloud và Spanner từ xa trên máy tính xách tay, nhưng trong lớp học lập trình này, chúng ta sẽ sử dụng Google Cloud Shell, một môi trường dòng lệnh chạy trong Đám mây.
Máy ảo dựa trên Debian này được tải tất cả các công cụ phát triển mà bạn cần. Dịch vụ này cung cấp thư mục gốc 5 GB ổn định và chạy trong Google Cloud, giúp nâng cao đáng kể hiệu suất và khả năng xác thực của mạng. Tức là tất cả những gì bạn cần để thực hiện lớp học lập trình này là một trình duyệt (vâng, trình duyệt này hoạt động trên Chromebook).
- Để kích hoạt Cloud Shell từ Cloud Console, bạn chỉ cần nhấp vào biểu tượng Kích hoạt Cloud Shell
(chỉ mất vài phút để cấp phép và kết nối với môi trường).
Sau khi kết nối với Cloud Shell, bạn sẽ thấy mình đã được xác thực và dự án đã được đặt thành PROJECT_ID.
gcloud auth list
Kết quả lệnh
Credentialed accounts:
- <myaccount>@<mydomain>.com (active)
gcloud config list project
Kết quả lệnh
[core]
project = <PROJECT_ID>
Nếu vì lý do nào đó mà dự án không được thiết lập, chỉ cần phát hành lệnh sau:
gcloud config set project <PROJECT_ID>
Bạn đang tìm PROJECT_ID? Hãy xem mã nhận dạng bạn đã sử dụng ở các bước thiết lập hoặc tra cứu trong trang tổng quan Cloud Console:
Cloud Shell cũng đặt một số biến môi trường theo mặc định. Điều này có thể hữu ích khi bạn chạy các lệnh sau này.
echo $GOOGLE_CLOUD_PROJECT
Kết quả lệnh
<PROJECT_ID>
Tải mã xuống
Trong Cloud Shell, bạn có thể tải mã cho phòng thí nghiệm này xuống:
git clone https://github.com/cloudspannerecosystem/spanner-gaming-sample.git
Kết quả lệnh
Cloning into 'spanner-gaming-sample'...
*snip*
Lớp học lập trình này dựa trên bản phát hành v0.1.3, vì vậy, hãy kiểm tra thẻ đó:
cd spanner-gaming-sample
git fetch --all --tags
# Check out v0.1.3 release
git checkout tags/v0.1.3 -b v0.1.3-branch
Kết quả lệnh
Switched to a new branch 'v0.1.3-branch'
Bây giờ, hãy đặt thư mục đang làm việc làm biến môi trường demo_HOME. Nhờ đó, bạn có thể điều hướng dễ dàng hơn khi thực hiện các phần khác nhau của lớp học lập trình này.
export DEMO_HOME=$(pwd)
Tóm tắt
Ở bước này, bạn đã thiết lập một dự án mới, kích hoạt Cloud shell và tải mã nguồn cho phòng thí nghiệm này xuống.
Tiếp theo
Tiếp theo, bạn sẽ cung cấp cơ sở hạ tầng bằng Terraform.
3. Cung cấp cơ sở hạ tầng
Tổng quan
Dự án của bạn đã sẵn sàng, đã đến lúc đưa cơ sở hạ tầng vào vận hành. Các dịch vụ này bao gồm kết nối mạng VPC, Cloud Spanner, GKE Autopilot, Artifact Registry để lưu trữ hình ảnh sẽ chạy trên GKE, quy trình Cloud Deploy cho các dịch vụ và tải công việc phụ trợ, cuối cùng là tài khoản dịch vụ và đặc quyền IAM để có thể sử dụng các dịch vụ đó.
Rất nhiều. Nhưng may mắn thay, Terraform có thể đơn giản hoá quá trình thiết lập này. Terraform là một "Cơ sở hạ tầng dưới dạng mã" công cụ cho phép chúng ta chỉ định những gì chúng ta cần cho dự án này trong một loạt các ‘.tf' tệp. Điều này giúp việc cấp phép cơ sở hạ tầng trở nên đơn giản.
Bạn không bắt buộc phải làm quen với Terraform để hoàn thành lớp học lập trình này. Nhưng nếu bạn muốn biết những bước tiếp theo sẽ làm gì, bạn có thể xem tất cả những gì được tạo trong những tệp này nằm trong thư mục cơ sở hạ tầng:
- vpc.tf
- backend_gke.tf
- spanner.tf
- artifact_registry.tf
- pipelines.tf
- iam.tf
Định cấu hình Terraform
Trong Cloud Shell, bạn sẽ thay đổi sang thư mục infrastructure và khởi chạy Terraform:
cd $DEMO_HOME/infrastructure
terraform init
Kết quả lệnh
Initializing the backend...
Initializing provider plugins...
*snip*
Terraform has been successfully initialized!
You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.
If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.
Tiếp theo, hãy định cấu hình Terraform bằng cách sao chép terraform.tfvars.sample rồi sửa đổi giá trị của dự án. Bạn cũng có thể thay đổi các biến khác, nhưng chỉ có thể thay đổi dự án để phù hợp với môi trường.
cp terraform.tfvars.sample terraform.tfvars
# edit gcp_project using the project environment variable
sed -i "s/PROJECT/$GOOGLE_CLOUD_PROJECT/" terraform.tfvars
Cung cấp cơ sở hạ tầng
Bây giờ, đã đến lúc cung cấp cơ sở hạ tầng!
terraform apply
# review the list of things to be created
# type 'yes' when asked
Kết quả lệnh
Plan: 46 to add, 0 to change, 0 to destroy.
Do you want to perform these actions?
Terraform will perform the actions described above.
Only 'yes' will be accepted to approve.
Enter a value: yes
google_project_service.project["container.googleapis.com"]: Creating...
*snip*
Apply complete! Resources: 46 added, 0 changed, 0 destroyed.
Kiểm tra nội dung được tạo
Để xác minh nội dung được tạo, bạn cần kiểm tra các sản phẩm đó trong Cloud Console.
Cloud Spanner
Trước tiên, hãy kiểm tra Cloud Spanner bằng cách chuyển đến trình đơn ba đường kẻ rồi nhấp vào Spanner. Bạn có thể phải nhấp vào "Xem các sản phẩm khác" để tìm tên đó trong danh sách.
Thao tác này sẽ đưa bạn đến danh sách các thực thể Spanner. Nhấp vào thực thể đó và bạn sẽ thấy các cơ sở dữ liệu. Hàm này có dạng như sau:
Chế độ tự động triển khai GKE
Tiếp theo, hãy tìm hiểu GKE bằng cách chuyển đến trình đơn ba đường kẻ rồi nhấp vào Kubernetes Engine => Clusters. Tại đây, bạn sẽ thấy cụm sample-games-gke đang chạy ở chế độ Autopilot.
Artifact Registry
Giờ bạn muốn biết nơi lưu trữ hình ảnh. Hãy nhấp vào trình đơn ba đường kẻ rồi tìm Artifact Registry=>Repositories. Artifact Registry nằm trong phần CI/CD trên trình đơn.
Tại đây, bạn sẽ thấy một sổ đăng ký Docker có tên spanner-game-images. Tạm thời, trường này sẽ trống.
Cloud Deploy
Cloud Deploy là nơi các quy trình được tạo ra để Cloud Build có thể đưa ra các bước xây dựng hình ảnh rồi triển khai hình ảnh đó cho cụm GKE của chúng tôi.
Chuyển đến trình đơn ba đường kẻ rồi tìm Cloud Deploy cũng nằm trong mục CI/CD của trình đơn.
Tại đây, bạn sẽ thấy hai quy trình: một dành cho các dịch vụ phụ trợ và một dành cho khối lượng công việc. Cả hai đều triển khai hình ảnh cho cùng một cụm GKE, nhưng điều này cho phép tách biệt các hoạt động triển khai của chúng tôi.
IAM
Cuối cùng, hãy xem trang IAM trong Cloud Console để xác minh các tài khoản dịch vụ đã được tạo. Chuyển đến trình đơn ba đường kẻ rồi tìm IAM and Admin=>Service accounts. Hàm này có dạng như sau:
Terraform có tổng cộng 6 tài khoản dịch vụ:
- Tài khoản dịch vụ mặc định của máy tính. Lớp học lập trình này không sử dụng thuộc tính này.
- Tài khoản Cloudbuild-cicd được dùng cho các bước Cloud Build và Cloud Deploy.
- 4 "ứng dụng" tài khoản mà các dịch vụ phụ trợ của chúng tôi dùng để tương tác với Cloud Spanner.
Tiếp theo, bạn cần định cấu hình kubectl để tương tác với cụm GKE.
Định cấu hình kubectl
# Name of GKE cluster from terraform.tfvars file
export GKE_CLUSTER=sample-game-gke
# get GKE credentials
gcloud container clusters get-credentials $GKE_CLUSTER --region us-central1
# Check that no errors occur
kubectl get serviceaccounts
Kết quả lệnh
#export GKE_CLUSTER=sample-game-gke
# gcloud container clusters get-credentials $GKE_CLUSTER --region us-central1
Fetching cluster endpoint and auth data.
kubeconfig entry generated for sample-game-gke.
# kubectl get serviceaccounts
NAME SECRETS AGE
default 0 37m
item-app 0 35m
matchmaking-app 0 35m
profile-app 0 35m
tradepost-app 0 35m
Tóm tắt
Tuyệt vời! Bạn có thể cung cấp một phiên bản Cloud Spanner và một cụm GKE Autopilot, tất cả trong một đám mây riêng ảo (VPC) để kết nối mạng riêng.
Ngoài ra, chúng tôi cũng tạo 2 quy trình Cloud Deploy cho các dịch vụ phụ trợ và khối lượng công việc, cũng như một kho lưu trữ Artifact Registry để lưu trữ các hình ảnh đã dựng.
Cuối cùng, các tài khoản dịch vụ đã được tạo và định cấu hình để hoạt động với Workload Identity, vì vậy, các dịch vụ phụ trợ có thể sử dụng Cloud Spanner.
Bạn cũng đã định cấu hình kubectl để tương tác với cụm GKE trong Cloud Shell sau khi triển khai các tải công việc và dịch vụ phụ trợ.
Tiếp theo
Bạn cần xác định giản đồ cơ sở dữ liệu trước khi có thể sử dụng các dịch vụ. Bạn sẽ thiết lập chế độ đó trong bước tiếp theo.
4. Tạo giản đồ cơ sở dữ liệu
Tổng quan
Trước khi có thể chạy các dịch vụ phụ trợ, bạn cần đảm bảo đã có giản đồ cơ sở dữ liệu.
Nếu xem các tệp trong thư mục $DEMO_HOME/schema/migrations từ kho lưu trữ minh hoạ, bạn sẽ thấy một loạt tệp .sql xác định giản đồ của chúng ta. Quá trình này bắt chước một chu trình phát triển trong đó những thay đổi giản đồ được theo dõi trong chính kho lưu trữ và có thể liên kết với một số tính năng của ứng dụng.
Đối với môi trường mẫu này, cờ lê là công cụ giúp áp dụng quá trình di chuyển giản đồ bằng Cloud Build.
Cloud Build
Tệp $DEMO_HOME/schema/cloudbuild.yaml mô tả các bước sẽ thực hiện:
serviceAccount: projects/${PROJECT_ID}/serviceAccounts/cloudbuild-cicd@${PROJECT_ID}.iam.gserviceaccount.com
steps:
- name: gcr.io/cloud-builders/curl
id: fetch-wrench
args: ['-Lo', '/workspace/wrench.tar.gz', 'https://github.com/cloudspannerecosystem/wrench/releases/download/v1.4.1/wrench-1.4.1-linux-amd64.tar.gz' ]
- name: gcr.io/cloud-builders/gcloud
id: migrate-spanner-schema
entrypoint: sh
args:
- '-xe'
- '-c'
- |
tar -xzvf wrench.tar.gz
chmod +x /workspace/wrench
# Assumes only a single spanner instance and database. Fine for this demo in a dedicated project
export SPANNER_PROJECT_ID=${PROJECT_ID}
export SPANNER_INSTANCE_ID=$(gcloud spanner instances list | tail -n1 | awk '{print $1}')
export SPANNER_DATABASE_ID=$(gcloud spanner databases list --instance=$$SPANNER_INSTANCE_ID | tail -n1 | awk '{print $1}')
if [ -d ./migrations ]; then
/workspace/wrench migrate up --directory .
else
echo "[Error] Missing migrations directory"
fi
timeout: 600s
Về cơ bản, có hai bước:
- tải cờ lê xuống không gian làm việc của Cloud Build
- chạy quá trình di chuyển cờ lê
Cần có dự án Spanner, thực thể và biến môi trường cơ sở dữ liệu để cờ lê kết nối với điểm cuối ghi.
Cloud Build có thể thực hiện những thay đổi này vì đang chạy dưới dạng tài khoản dịch vụ cloudbuild-cicd@${PROJECT_ID}.iam.gserviceaccount.com:
serviceAccount: projects/${PROJECT_ID}/serviceAccounts/cloudbuild-cicd@${PROJECT_ID}.iam.gserviceaccount.com
Đồng thời, tài khoản dịch vụ này đã thêm vai trò spanner.databaseUser do Terraform thêm để cho phép tài khoản dịch vụ cập nhậtDDL.
Di chuyển giản đồ
Có 5 bước di chuyển được thực hiện dựa trên các tệp trong thư mục $DEMO_HOME/schema/migrations. Dưới đây là ví dụ về tệp 000001.sql để tạo bảng và chỉ mục players:
CREATE TABLE players (
playerUUID STRING(36) NOT NULL,
player_name STRING(64) NOT NULL,
email STRING(MAX) NOT NULL,
password_hash BYTES(60) NOT NULL,
created TIMESTAMP,
updated TIMESTAMP,
stats JSON,
account_balance NUMERIC NOT NULL DEFAULT (0.00),
is_logged_in BOOL,
last_login TIMESTAMP,
valid_email BOOL,
current_game STRING(36)
) PRIMARY KEY (playerUUID);
CREATE UNIQUE INDEX PlayerAuthentication ON players(email) STORING(password_hash);
CREATE UNIQUE INDEX PlayerName ON players(player_name);
CREATE INDEX PlayerGame ON players(current_game);
Gửi yêu cầu di chuyển giản đồ
Để gửi bản dựng nhằm di chuyển giản đồ, hãy chuyển sang thư mục schema rồi chạy lệnh gcloud sau:
cd $DEMO_HOME/schema gcloud builds submit --config=cloudbuild.yaml
Kết quả lệnh
Creating temporary tarball archive of 8 file(s) totalling 11.2 KiB before compression.
Uploading tarball of [.] to [gs://(project)_cloudbuild/source/(snip).tgz]
Created [https://cloudbuild.googleapis.com/v1/projects/(project)/locations/global/builds/7defe982-(snip)].
Logs are available at [ https://console.cloud.google.com/cloud-build/builds/7defe982-(snip)?project=(snip) ].
gcloud builds submit only displays logs from Cloud Storage. To view logs from Cloud Logging, run:
gcloud beta builds submit
ID: 7defe982-(snip)
CREATE_TIME: (created time)
DURATION: 3M11S
SOURCE: gs://(project)_cloudbuild/source/(snip).tgz
IMAGES: -
STATUS: SUCCESS
Trong kết quả ở trên, bạn sẽ thấy một đường liên kết đến quy trình tạo bản dựng trên đám mây Created. Khi nhấp vào đó, bạn sẽ được chuyển đến bản dựng trong Cloud Console để có thể theo dõi tiến trình của bản dựng cũng như biết chức năng của bản dựng.
Tóm tắt
Trong bước này, bạn đã sử dụng Cloud Build để gửi quá trình di chuyển giản đồ ban đầu đã áp dụng 5 hoạt động DDL khác nhau. Các thao tác này cho biết thời điểm thêm các tính năng cần thiết để thay đổi giản đồ cơ sở dữ liệu.
Trong trường hợp phát triển bình thường, bạn sẽ muốn thực hiện các thay đổi giản đồ tương thích ngược với ứng dụng hiện tại để tránh sự cố ngừng dịch vụ.
Đối với những thay đổi không có khả năng tương thích ngược, bạn nên triển khai các thay đổi đối với ứng dụng và giản đồ theo từng giai đoạn để đảm bảo không có sự cố ngừng dịch vụ.
Tiếp theo
Khi đã có giản đồ, bước tiếp theo là triển khai các dịch vụ phụ trợ!
5. Triển khai các dịch vụ phụ trợ
Tổng quan
Các dịch vụ phụ trợ của lớp học lập trình này là các API REST của golang đại diện cho 4 dịch vụ:
- Hồ sơ: cho phép người chơi đăng ký và xác thực với "trò chơi" mẫu của chúng tôi.
- So khớp: tương tác với dữ liệu người chơi để hỗ trợ chức năng tìm kiếm người chơi, theo dõi thông tin về những trò chơi được tạo và cập nhật số liệu thống kê về người chơi khi trò chơi đóng lại.
- Mặt hàng: cho phép người chơi thu nạp tiền và vật phẩm trong quá trình chơi.
- Tradepost: (Dịch vụ giao dịch): cho phép người chơi mua và bán các mặt hàng trên trang web thương mại
Bạn có thể tìm hiểu thêm về các dịch vụ này trong lớp học lập trình Bắt đầu phát triển trò chơi trên Cloud Spanner. Vì mục đích của chúng tôi, chúng tôi muốn các dịch vụ này chạy trên cụm GKE Autopilot của mình.
Các dịch vụ này phải có khả năng sửa đổi dữ liệu Spanner. Để làm được việc đó, mỗi dịch vụ được tạo một tài khoản dịch vụ cấp cho họ "databaseUser" vai trò.
Workload Identity cho phép tài khoản dịch vụ kubernetes mạo danh dịch vụ của Google Cloud bằng cách làm theo các bước sau trong Terraform:
- Tạo tài nguyên tài khoản dịch vụ Google Cloud (
GSA) của dịch vụ - Chỉ định vai trò databaseUser cho tài khoản dịch vụ đó
- Chỉ định vai trò workloadIdentityUser cho tài khoản dịch vụ đó
- Tạo tài khoản dịch vụ Kubernetes (
KSA) tham chiếu đến tài khoản lên
Một sơ đồ sơ bộ sẽ có dạng như sau:
Terraform đã tạo tài khoản dịch vụ và tài khoản dịch vụ Kubernetes cho bạn. Bạn có thể kiểm tra các tài khoản dịch vụ của Kubernetes bằng kubectl:
# kubectl get serviceaccounts
NAME SECRETS AGE
default 0 37m
item-app 0 35m
matchmaking-app 0 35m
profile-app 0 35m
tradepost-app 0 35m
Cách thức hoạt động của bản dựng như sau:
- Terraform đã tạo một tệp
$DEMO_HOME/backend_services/cloudbuild.yamlcó dạng như sau:
serviceAccount: projects/${PROJECT_ID}/serviceAccounts/cloudbuild-cicd@${PROJECT_ID}.iam.gserviceaccount.com
steps:
#
# Building of images
#
- name: gcr.io/cloud-builders/docker
id: profile
args: ["build", ".", "-t", "${_PROFILE_IMAGE}"]
dir: profile
waitFor: ['-']
- name: gcr.io/cloud-builders/docker
id: matchmaking
args: ["build", ".", "-t", "${_MATCHMAKING_IMAGE}"]
dir: matchmaking
waitFor: ['-']
- name: gcr.io/cloud-builders/docker
id: item
args: ["build", ".", "-t", "${_ITEM_IMAGE}"]
dir: item
waitFor: ['-']
- name: gcr.io/cloud-builders/docker
id: tradepost
args: ["build", ".", "-t", "${_TRADEPOST_IMAGE}"]
dir: tradepost
waitFor: ['-']
#
# Deployment
#
- name: gcr.io/google.com/cloudsdktool/cloud-sdk
id: cloud-deploy-release
entrypoint: gcloud
args:
[
"deploy", "releases", "create", "${_REL_NAME}",
"--delivery-pipeline", "sample-game-services",
"--skaffold-file", "skaffold.yaml",
"--skaffold-version", "1.39",
"--images", "profile=${_PROFILE_IMAGE},matchmaking=${_MATCHMAKING_IMAGE},item=${_ITEM_IMAGE},tradepost=${_TRADEPOST_IMAGE}",
"--region", "us-central1"
]
artifacts:
images:
- ${_REGISTRY}/profile
- ${_REGISTRY}/matchmaking
- ${_REGISTRY}/item
- ${_REGISTRY}/tradepost
substitutions:
_PROFILE_IMAGE: ${_REGISTRY}/profile:${BUILD_ID}
_MATCHMAKING_IMAGE: ${_REGISTRY}/matchmaking:${BUILD_ID}
_ITEM_IMAGE: ${_REGISTRY}/item:${BUILD_ID}
_TRADEPOST_IMAGE: ${_REGISTRY}/tradepost:${BUILD_ID}
_REGISTRY: us-docker.pkg.dev/${PROJECT_ID}/spanner-game-images
_REL_NAME: rel-${BUILD_ID:0:8}
options:
dynamic_substitutions: true
machineType: E2_HIGHCPU_8
logging: CLOUD_LOGGING_ONLY
- Lệnh Cloud Build sẽ đọc tệp này và làm theo các bước được nêu. Đầu tiên, ứng dụng tạo hình ảnh dịch vụ. Sau đó, hàm này sẽ thực thi một lệnh
gcloud deploy create. Thao tác này sẽ đọc tệp$DEMO_HOME/backend_services/skaffold.yaml, tệp này xác định vị trí của mỗi tệp triển khai:
apiVersion: skaffold/v2beta29
kind: Config
deploy:
kubectl:
manifests:
- spanner_config.yaml
- profile/deployment.yaml
- matchmaking/deployment.yaml
- item/deployment.yaml
- tradepost/deployment.yaml
- Cloud Deployment sẽ tuân theo các định nghĩa về tệp
deployment.yamlcủa từng dịch vụ. Tệp triển khai của dịch vụ chứa thông tin để tạo dịch vụ, trong trường hợp này là mộtClusterIP đang chạy trên cổng 80.
" Loại ClusterIP" ngăn các nhóm dịch vụ phụ trợ có IP bên ngoài để chỉ những thực thể có thể kết nối với mạng GKE nội bộ mới có thể truy cập vào các dịch vụ phụ trợ. Người chơi không được truy cập trực tiếp các dịch vụ này vì chúng truy cập và sửa đổi dữ liệu Spanner.
apiVersion: v1
kind: Service
metadata:
name: profile
spec:
type: ClusterIP
selector:
app: profile
ports:
- port: 80
targetPort: 80
Ngoài việc tạo dịch vụ Kubernetes, Cloud Deploy cũng tạo ra quy trình triển khai Kubernetes. Hãy tìm hiểu phần triển khai của dịch vụ profile:
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: profile
spec:
replicas: 2 # EDIT: Number of instances of deployment
selector:
matchLabels:
app: profile
template:
metadata:
labels:
app: profile
spec:
serviceAccountName: profile-app
containers:
- name: profile-service
image: profile
ports:
- containerPort: 80
envFrom:
- configMapRef:
name: spanner-config
env:
- name: SERVICE_HOST
value: "0.0.0.0"
- name: SERVICE_PORT
value: "80"
resources:
requests:
cpu: "1"
memory: "1Gi"
ephemeral-storage: "100Mi"
limits:
cpu: "1"
memory: "1Gi"
ephemeral-storage: "100Mi"
Phần trên cùng cung cấp một số siêu dữ liệu về dịch vụ. Phần quan trọng nhất trong quá trình này là xác định số lượng bản sao sẽ được tạo trong quá trình triển khai này.
replicas: 2 # EDIT: Number of instances of deployment
Tiếp theo, chúng ta sẽ xem tài khoản dịch vụ nào sẽ chạy ứng dụng và hình ảnh nào nên sử dụng. Những kết quả này khớp với tài khoản dịch vụ Kubernetes được tạo từ Terraform và hình ảnh được tạo ở bước Cloud Build.
spec:
serviceAccountName: profile-app
containers:
- name: profile-service
image: profile
Sau đó, chúng ta sẽ chỉ định một số thông tin về các biến mạng và môi trường.
spanner_config là một ConfigMap của Kubernetes chỉ định thông tin về dự án, thực thể và cơ sở dữ liệu cần thiết để ứng dụng kết nối với Spanner.
apiVersion: v1
kind: ConfigMap
metadata:
name: spanner-config
data:
SPANNER_PROJECT_ID: ${project_id}
SPANNER_INSTANCE_ID: ${instance_id}
SPANNER_DATABASE_ID: ${database_id}
ports:
- containerPort: 80
envFrom:
- configMapRef:
name: spanner-config
env:
- name: SERVICE_HOST
value: "0.0.0.0"
- name: SERVICE_PORT
value: "80"
SERVICE_HOST và SERVICE_PORT là các biến môi trường bổ sung mà dịch vụ cần để biết nơi liên kết.
Phần cuối cùng cho GKE biết số lượng tài nguyên cần cho phép mỗi bản sao trong quy trình triển khai này. Đây cũng là phương pháp mà GKE Autopilot sử dụng để mở rộng cụm nếu cần.
resources:
requests:
cpu: "1"
memory: "1Gi"
ephemeral-storage: "100Mi"
limits:
cpu: "1"
memory: "1Gi"
ephemeral-storage: "100Mi"
Với thông tin này, đã đến lúc triển khai các dịch vụ phụ trợ.
Triển khai các dịch vụ phụ trợ
Như đã đề cập, việc triển khai các dịch vụ phụ trợ sử dụng Cloud Build. Tương tự như quá trình di chuyển giản đồ, bạn có thể gửi yêu cầu bản dựng bằng dòng lệnh gcloud:
cd $DEMO_HOME/backend_services gcloud builds submit --config=cloudbuild.yaml
Kết quả lệnh
Creating temporary tarball archive of 66 file(s) totalling 864.6 KiB before compression.
Uploading tarball of [.] to [gs://(project)_cloudbuild/source/(snip).tgz]
Created [https://cloudbuild.googleapis.com/v1/projects/(project)/locations/global/builds/30207dd1-(snip)].
Logs are available at [ https://console.cloud.google.com/cloud-build/builds/30207dd1-(snip)?project=(snip) ].
gcloud builds submit only displays logs from Cloud Storage. To view logs from Cloud Logging, run:
gcloud beta builds submit
ID: 30207dd1-(snip)
CREATE_TIME: (created time)
DURATION: 3M17S
SOURCE: gs://(project)_cloudbuild/source/(snip).tgz
IMAGES: us-docker.pkg.dev/(project)/spanner-game-images/profile:30207dd1-(snip) (+3 more)
STATUS: SUCCESS
Không giống như kết quả của bước schema migration, kết quả của bản dựng này cho biết có một số hình ảnh đã được tạo. Các dữ liệu đó sẽ được lưu trữ trong kho lưu trữ Artifact Registry của bạn.
Kết quả của bước gcloud build sẽ có một đường liên kết đến Cloud Console. Hãy xem các video đó.
Sau khi nhận được thông báo thành công từ Cloud Build, hãy chuyển đến Cloud Deploy rồi đến quy trình sample-game-services để theo dõi tiến trình triển khai.
Sau khi triển khai dịch vụ, bạn có thể kiểm tra kubectl để xem các nhóm trạng thái:
kubectl get pods
Kết quả lệnh
NAME READY STATUS RESTARTS AGE
item-6b9d5f678c-4tbk2 1/1 Running 0 83m
matchmaking-5bcf799b76-lg8zf 1/1 Running 0 80m
profile-565bbf4c65-kphdl 1/1 Running 0 83m
profile-565bbf4c65-xw74j 1/1 Running 0 83m
tradepost-68b87ccd44-gw55r 1/1 Running 0 79m
Sau đó, kiểm tra các dịch vụ để xem ClusterIP hoạt động như thế nào:
kubectl get services
Kết quả lệnh
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
item ClusterIP 10.172.XXX.XXX <none> 80/TCP 84m
kubernetes ClusterIP 10.172.XXX.XXX <none> 443/TCP 137m
matchmaking ClusterIP 10.172.XXX.XXX <none> 80/TCP 84m
profile ClusterIP 10.172.XXX.XXX <none> 80/TCP 84m
tradepost ClusterIP 10.172.XXX.XXX <none> 80/TCP 84m
Bạn cũng có thể chuyển đến giao diện người dùng GKE trong Cloud Console để xem Workloads, Services và ConfigMaps.
Khối lượng công việc
Dịch vụ
ConfigMaps
Tóm tắt
Trong bước này, bạn đã triển khai 4 dịch vụ phụ trợ cho GKE Autopilot. Bạn đã có thể chạy bước Cloud Build và kiểm tra tiến trình trong Cloud Deploy và trên Kubernetes trong Cloud Console.
Bạn cũng đã tìm hiểu cách các dịch vụ này sử dụng Workload Identity để mạo danh một tài khoản dịch vụ có quyền đọc và ghi dữ liệu phù hợp vào cơ sở dữ liệu Spanner.
Các bước tiếp theo
Trong phần tiếp theo, bạn sẽ triển khai các tải công việc.
6. Triển khai khối lượng công việc
Tổng quan
Hiện tại, các dịch vụ phụ trợ đang chạy trên cụm, bạn sẽ triển khai khối lượng công việc.
Bạn có thể truy cập vào các khối lượng công việc từ bên ngoài và có một khối lượng công việc cho từng dịch vụ phụ trợ phục vụ cho lớp học lập trình này.
Những khối lượng công việc này là tập lệnh tạo tải dựa trên Locust, bắt chước các mẫu truy cập thực mà các dịch vụ mẫu này mong đợi.
Dưới đây là các tệp dành cho quá trình tạo Cloud Build:
$DEMO_HOME/workloads/cloudbuild.yaml(do Terraform tạo)$DEMO_HOME/workloads/skaffold.yaml- một tệp
deployment.yamlcho mỗi khối lượng công việc
Các tệp deployment.yaml của khối lượng công việc có vẻ hơi khác so với các tệp triển khai dịch vụ phụ trợ.
Dưới đây là ví dụ từ matchmaking-workload:
apiVersion: v1
kind: Service
metadata:
name: matchmaking-workload
spec:
type: LoadBalancer
selector:
app: matchmaking-workload
ports:
- port: 8089
targetPort: 8089
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: matchmaking-workload
spec:
replicas: 1 # EDIT: Number of instances of deployment
selector:
matchLabels:
app: matchmaking-workload
template:
metadata:
labels:
app: matchmaking-workload
spec:
serviceAccountName: default
containers:
- name: matchmaking-workload
image: matchmaking-workload
ports:
- containerPort: 8089
resources:
requests:
cpu: "500m"
memory: "512Mi"
ephemeral-storage: "100Mi"
limits:
cpu: "500m"
memory: "512Mi"
ephemeral-storage: "100Mi"
Phần trên cùng của tệp xác định dịch vụ. Trong trường hợp này, LoadBalancer sẽ được tạo và khối lượng công việc sẽ chạy trên cổng 8089.
Trình cân bằng tải sẽ cung cấp một IP bên ngoài có thể dùng để kết nối với khối lượng công việc.
apiVersion: v1
kind: Service
metadata:
name: matchmaking-workload
spec:
type: LoadBalancer
selector:
app: matchmaking-workload
ports:
- port: 8089
targetPort: 8089
Phần đầu của phần triển khai là siêu dữ liệu về khối lượng công việc. Trong trường hợp này, chỉ một bản sao đang được triển khai:
replicas: 1
Tuy nhiên, thông số vùng chứa lại khác nhau. Thứ nhất là chúng tôi đang dùng một tài khoản dịch vụ default Kubernetes. Tài khoản này không có đặc quyền đặc biệt nào, vì khối lượng công việc không cần phải kết nối với bất kỳ tài nguyên nào của Google Cloud, ngoại trừ các dịch vụ phụ trợ đang chạy trên cụm GKE.
Điểm khác biệt còn lại là không cần biến môi trường nào cho những tải công việc này. Nhờ đó, quy cách triển khai ngắn hơn.
spec:
serviceAccountName: default
containers:
- name: matchmaking-workload
image: matchmaking-workload
ports:
- containerPort: 8089
Các chế độ cài đặt tài nguyên tương tự như các dịch vụ phụ trợ. Hãy nhớ rằng đây là cách để GKE Autopilot biết cần thiết phải có bao nhiêu tài nguyên để đáp ứng yêu cầu của tất cả các nhóm đang chạy trên cụm.
Hãy tiếp tục và triển khai khối lượng công việc!
Triển khai khối lượng công việc
Giống như trước đây, bạn có thể gửi yêu cầu bản dựng bằng dòng lệnh gcloud:
cd $DEMO_HOME/workloads gcloud builds submit --config=cloudbuild.yaml
Kết quả lệnh
Creating temporary tarball archive of 18 file(s) totalling 26.2 KiB before compression.
Some files were not included in the source upload.
Check the gcloud log [/tmp/tmp.4Z9EqdPo6d/logs/(snip).log] to see which files and the contents of the
default gcloudignore file used (see `$ gcloud topic gcloudignore` to learn
more).
Uploading tarball of [.] to [gs://(project)_cloudbuild/source/(snip).tgz]
Created [https://cloudbuild.googleapis.com/v1/projects/(project)/locations/global/builds/(snip)].
Logs are available at [ https://console.cloud.google.com/cloud-build/builds/0daf20f6-(snip)?project=(snip) ].
gcloud builds submit only displays logs from Cloud Storage. To view logs from Cloud Logging, run:
gcloud beta builds submit
ID: 0daf20f6-(snip)
CREATE_TIME: (created_time)
DURATION: 1M41S
SOURCE: gs://(project)_cloudbuild/source/(snip).tgz
IMAGES: us-docker.pkg.dev/(project)/spanner-game-images/profile-workload:0daf20f6-(snip) (+4 more)
STATUS: SUCCESS
Hãy nhớ kiểm tra nhật ký của Cloud Build và quy trình Cloud Deploy trong Cloud Console để kiểm tra trạng thái. Đối với các tải công việc, quy trình Triển khai đám mây là sample-game-workloads:
Sau khi triển khai xong, hãy kiểm tra trạng thái bằng kubectl trong Cloud Shell:
kubectl get pods
Kết quả lệnh
NAME READY STATUS RESTARTS AGE
game-workload-7ff44cb657-pxxq2 1/1 Running 0 12m
item-6b9d5f678c-cr29w 1/1 Running 0 9m6s
item-generator-7bb4f57cf8-5r85b 1/1 Running 0 12m
matchmaking-5bcf799b76-lg8zf 1/1 Running 0 117m
matchmaking-workload-76df69dbdf-jds9z 1/1 Running 0 12m
profile-565bbf4c65-kphdl 1/1 Running 0 121m
profile-565bbf4c65-xw74j 1/1 Running 0 121m
profile-workload-76d6db675b-kzwng 1/1 Running 0 12m
tradepost-68b87ccd44-gw55r 1/1 Running 0 116m
tradepost-workload-56c55445b5-b5822 1/1 Running 0 12m
Sau đó, hãy kiểm tra các dịch vụ tải công việc để xem LoadBalancer hoạt động như thế nào:
kubectl get services
Kết quả lệnh
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
game-workload LoadBalancer *snip* 35.XX.XX.XX 8089:32483/TCP 12m
item ClusterIP *snip* <none> 80/TCP 121m
item-generator LoadBalancer *snip* 34.XX.XX.XX 8089:32581/TCP 12m
kubernetes ClusterIP *snip* <none> 443/TCP 174m
matchmaking ClusterIP *snip* <none> 80/TCP 121m
matchmaking-workload LoadBalancer *snip* 34.XX.XX.XX 8089:31735/TCP 12m
profile ClusterIP *snip* <none> 80/TCP 121m
profile-workload LoadBalancer *snip* 34.XX.XX.XX 8089:32532/TCP 12m
tradepost ClusterIP *snip* <none> 80/TCP 121m
tradepost-workload LoadBalancer *snip* 34.XX.XX.XX 8089:30002/TCP 12m
Tóm tắt
Bạn hiện đã triển khai tải công việc cho cụm GKE. Những khối lượng công việc này không cần quyền IAM bổ sung và có thể truy cập từ bên ngoài trên cổng 8089 thông qua dịch vụ Loadbalancer.
Các bước tiếp theo
Với các dịch vụ phụ trợ và khối lượng công việc đang chạy, đã đến lúc "chơi" trò chơi!
7. Bắt đầu chơi trò chơi
Tổng quan
Các dịch vụ phụ trợ dành cho "trò chơi" mẫu của bạn hiện đang chạy và bạn cũng có phương tiện để tạo "người chơi" tương tác với các dịch vụ đó bằng các khối lượng công việc.
Mỗi tải công việc sử dụng Locust để mô phỏng tải thực tế dựa trên các API dịch vụ của chúng tôi. Trong bước này, bạn sẽ chạy một số tải công việc để tạo tải trên cụm GKE và trên Spanner, cũng như lưu trữ dữ liệu trên Spanner.
Dưới đây là nội dung mô tả về từng khối lượng công việc:
- Khối lượng công việc
item-generatorlà một khối lượng công việc nhanh chóng để tạo một danh sách game_items mà người chơi có thể thu được trong quá trình "chơi" trò chơi. profile-workloadmô phỏng hoạt động đăng ký và đăng nhập của người chơi.matchmaking-workloadmô phỏng việc người chơi đang xếp hàng để được giao vào trò chơi.game-workloadmô phỏng người chơi nhận được các vật phẩm trong trò chơi và tiền trong quá trình chơi.tradepost-workloadmô phỏng hoạt động bán và mua các vật phẩm của người chơi trên bưu điện.
Lớp học lập trình này sẽ làm nổi bật cụ thể việc chạy item-generator và profile-workload.
Chạy trình tạo mục
item-generator sử dụng điểm cuối của dịch vụ phụ trợ item để thêm game_items vào Spanner. Đây là các mục bắt buộc để game-workload và tradepost-workload hoạt động chính xác.
Bước đầu tiên là lấy IP ngoài của dịch vụ item-generator. Trong Cloud Shell, hãy chạy lệnh sau:
# The external IP is the 4th column of the output
kubectl get services | grep item-generator | awk '{print $4}'
Kết quả lệnh
{ITEMGENERATOR_EXTERNAL_IP}
Bây giờ, hãy mở một thẻ trình duyệt mới và trỏ thẻ này tới http://{ITEMGENERATOR_EXTERNAL_IP}:8089. Bạn sẽ thấy một trang như sau:
Bạn sẽ để users và spawn ở giá trị mặc định là 1. Đối với host, hãy nhập http://item. Nhấp vào các lựa chọn nâng cao rồi nhập 10s cho thời gian chạy.
Cấu hình này sẽ có dạng như sau:
Hãy nhấp vào "Bắt đầu khám phá"!
Số liệu thống kê sẽ bắt đầu xuất hiện cho các yêu cầu được đưa ra trên điểm cuối POST /items. Sau 10 giây, quá trình tải sẽ dừng lại.
Nhấp vào Charts và bạn sẽ thấy một số biểu đồ về hiệu suất của các yêu cầu này.
Bây giờ, bạn muốn kiểm tra xem dữ liệu đã được nhập vào cơ sở dữ liệu Spanner hay chưa.
Để làm việc đó, hãy nhấp vào trình đơn ba đường kẻ rồi chuyển đến "Spanner". Từ trang này, hãy chuyển đến sample-instance và sample-database. Sau đó nhấp vào "Query".
Chúng ta muốn chọn số lượng game_items:
CHỌN COUNT(*) TỪ game_items;
Ở dưới cùng, bạn sẽ thấy kết quả.
Chúng ta không cần nhiều hạt giống game_items. Nhưng giờ đây, những trò chơi đó có sẵn để người chơi nhận được!
Chạy khối lượng công việc của hồ sơ
Với game_items hạt giống của bạn, bước tiếp theo là mời người chơi đăng ký để có thể chơi trò chơi.
profile-workload sẽ sử dụng Lo xảy ra để mô phỏng việc người chơi tạo tài khoản, đăng nhập, truy xuất thông tin hồ sơ và đăng xuất. Tất cả các thao tác này đều kiểm thử các điểm cuối của dịch vụ phụ trợ profile trong một khối lượng công việc thông thường giống như quá trình sản xuất.
Để chạy phương thức này, hãy lấy IP ngoài profile-workload:
# The external IP is the 4th column of the output
kubectl get services | grep profile-workload | awk '{print $4}'
Kết quả lệnh
{PROFILEWORKLOAD_EXTERNAL_IP}
Bây giờ, hãy mở một thẻ trình duyệt mới và trỏ thẻ này tới http://{PROFILEWORKLOAD_EXTERNAL_IP}:8089. Bạn sẽ nhận được trang Châu Âu tương tự như trang trước.
Trong trường hợp này, bạn sẽ sử dụng http://profile cho máy chủ lưu trữ. Và bạn sẽ không chỉ định thời gian chạy trong tuỳ chọn nâng cao. Ngoài ra, hãy chỉ định users là 4 để mô phỏng cùng lúc 4 yêu cầu của người dùng.
Quy trình kiểm thử profile-workload sẽ có dạng như sau:
Hãy nhấp vào "Bắt đầu khám phá"!
Giống như trước đây, số liệu thống kê cho các điểm cuối profile Kiến trúc chuyển trạng thái đại diện (REST) sẽ bắt đầu xuất hiện. Nhấp vào biểu đồ để xem mọi thứ đang hoạt động hiệu quả đến mức nào.
Tóm tắt
Ở bước này, bạn đã tạo một số game_items, sau đó truy vấn bảng game_items bằng giao diện người dùng Truy vấn Spanner trong Cloud Console.
Bạn cũng cho phép người chơi đăng ký chơi trò chơi của bạn và chứng kiến cách Lo Tin có thể tạo ra những tải công việc giống như phát hành công khai cho những dịch vụ phụ trợ của bạn.
Các bước tiếp theo
Sau khi chạy khối lượng công việc, bạn nên kiểm tra tình trạng hoạt động của cụm GKE và thực thể Spanner.
8. Xem xét mức sử dụng GKE và Spanner
Khi dịch vụ hồ sơ đang chạy, đã đến lúc bạn nắm bắt tình hình hoạt động của cụm GKE Autopilot và Cloud Spanner của mình.
Kiểm tra cụm GKE
Chuyển đến cụm Kubernetes. Lưu ý rằng vì bạn đã triển khai các tải công việc và dịch vụ, nên cụm này hiện đã thêm một số thông tin chi tiết về tổng vCPU và bộ nhớ. Không có thông tin này khi cụm không có tải công việc nào.
Bây giờ, hãy nhấp vào cụm sample-game-gke và chuyển sang thẻ khả năng quan sát:
Không gian tên default kubernetes lẽ ra phải vượt qua không gian tên kube-system để sử dụng CPU vì khối lượng công việc và các dịch vụ phụ trợ của chúng tôi chạy trên default. Nếu chưa, hãy đảm bảo profile workload vẫn đang chạy và đợi một vài phút để biểu đồ cập nhật.
Để xem những khối lượng công việc nào đang tốn nhiều tài nguyên nhất, hãy truy cập vào trang tổng quan của Workloads.
Thay vì tập trung vào từng khối lượng công việc riêng lẻ, hãy chuyển thẳng đến thẻ Khả năng quan sát trên trang tổng quan. Bạn sẽ thấy CPU profile và profile-workload đã tăng.
Bây giờ, hãy kiểm tra Cloud Spanner.
Kiểm tra thực thể Cloud Spanner
Để kiểm tra hiệu suất của Cloud Spanner, hãy chuyển đến Spanner rồi nhấp vào thực thể sample-instance và cơ sở dữ liệu sample-game.
Tại đó, bạn sẽ thấy thẻ System Insights (Thông tin chi tiết về hệ thống) trên trình đơn bên trái:
Có nhiều biểu đồ giúp bạn hiểu rõ hiệu suất chung của thực thể Spanner, bao gồm CPU utilization, transaction latency and locking và query throughput.
Ngoài Thông tin chi tiết về hệ thống, bạn có thể xem thêm thông tin chi tiết về khối lượng truy vấn bằng cách xem qua các đường liên kết khác trong phần Khả năng quan sát:
- Thông tin chi tiết về Truy vấn giúp xác định các truy vấn hàng đầu sử dụng tài nguyên trên Spanner.
- Thông tin chi tiết về Giao dịch và khoá giúp xác định các giao dịch có độ trễ cao.
- Key Visibilityr (Trình hiển thị chính) giúp trực quan hóa các quy luật truy cập và có thể giúp theo dõi các điểm tương tác trong dữ liệu.
Tóm tắt
Trong bước này, bạn đã tìm hiểu cách kiểm tra một số chỉ số cơ bản về hiệu suất cho cả GKE Autopilot và Spanner.
Ví dụ: khi khối lượng công việc của hồ sơ đang chạy, hãy truy vấn bảng người chơi để lấy thêm thông tin về dữ liệu đang được lưu trữ ở đó.
Các bước tiếp theo
Tiếp theo, đã đến lúc dọn dẹp!
9. Dọn dẹp
Trước khi dọn dẹp, bạn có thể khám phá những tải công việc khác không có trong danh sách. Cụ thể là matchmaking-workload, game-workload và tradepost-workload.
Khi bạn "phát" xong trò chơi, bạn có thể dọn dẹp sân chơi của mình. Thật may là việc này khá dễ dàng.
Trước tiên, nếu profile-workload vẫn đang chạy trong trình duyệt, hãy kiểm tra và dừng ứng dụng đó:
Làm tương tự cho từng khối lượng công việc mà bạn có thể đã thử nghiệm.
Sau đó, trong Cloud Shell, hãy chuyển đến thư mục cơ sở hạ tầng. Bạn sẽ destroy cơ sở hạ tầng bằng cách sử dụng địa hình:
cd $DEMO_HOME/infrastructure
terraform destroy
# type 'yes' when asked
Kết quả lệnh
Plan: 0 to add, 0 to change, 46 to destroy.
Do you really want to destroy all resources?
Terraform will destroy all your managed infrastructure, as shown above.
There is no undo. Only 'yes' will be accepted to confirm.
Enter a value: yes
*snip*
Destroy complete! Resources: 46 destroyed.
Trong Cloud Console, hãy chuyển đến Spanner, Kubernetes Cluster, Artifact Registry, Cloud Deploy và IAM để xác thực tất cả tài nguyên đã bị xoá.
10. Xin chúc mừng!
Xin chúc mừng! Bạn đã triển khai thành công các ứng dụng golang mẫu trên GKE Autopilot và kết nối các ứng dụng đó với Cloud Spanner bằng Workload Identity!
Ngoài ra, cơ sở hạ tầng này còn được dễ dàng thiết lập và loại bỏ theo cách lặp lại bằng Terraform.
Bạn có thể đọc thêm về các dịch vụ của Google Cloud mà bạn đã tương tác trong lớp học lập trình này:
Tiếp theo là gì?
Giờ đây, khi bạn đã có kiến thức cơ bản về cách GKE Autopilot và Cloud Spanner có thể phối hợp hoạt động, tại sao bạn không tiến hành bước tiếp theo và bắt đầu xây dựng ứng dụng của riêng mình để hoạt động với các dịch vụ này?