Menghubungkan Cloud Spanner dengan Autopilot GKE

1. Pengantar

Cloud Spanner adalah layanan database relasional yang skalabel secara global dan terkelola sepenuhnya, yang menyediakan transaksi ACID dan semantik SQL tanpa mengorbankan performa dan ketersediaan tinggi.

Autopilot GKE adalah mode operasi di GKE tempat Google mengelola konfigurasi cluster Anda, termasuk node, penskalaan, keamanan, dan setelan lainnya yang telah dikonfigurasi sebelumnya untuk mengikuti praktik terbaik. Misalnya, GKE Autopilot mengaktifkan Workload Identity untuk mengelola izin layanan.

Tujuan lab ini adalah untuk memandu Anda dalam proses menghubungkan beberapa layanan backend yang berjalan di GKE Autopilot ke database Cloud Spanner.

Di lab ini, pertama-tama Anda akan menyiapkan project dan meluncurkan Cloud Shell. Kemudian, Anda akan men-deploy infrastruktur menggunakan Terraform.

Setelah selesai, Anda akan berinteraksi dengan Cloud Build dan Cloud Deploy untuk melakukan migrasi skema awal untuk database Game, men-deploy layanan backend, lalu men-deploy workload.

Layanan dalam codelab ini sama dengan codelab Memulai Pengembangan Game Cloud Spanner. Melakukan codelab tersebut bukanlah persyaratan agar layanan dapat berjalan di GKE dan terhubung ke Spanner. Namun, jika Anda ingin mengetahui detail lebih lanjut tentang detail layanan yang berfungsi di Spanner, silakan lihat.

Dengan workload dan layanan backend berjalan, Anda dapat mulai menghasilkan beban dan mengamati cara layanan bekerja sama.

Terakhir, Anda akan membersihkan resource yang dibuat di lab ini.

Yang akan Anda build

Sebagai bagian dari lab ini, Anda akan:

• Menyediakan infrastruktur menggunakan Terraform
• Membuat skema database menggunakan proses Migrasi Skema di Cloud Build
• Men-deploy empat layanan backend Golang yang memanfaatkan Workload Identity untuk terhubung ke Cloud Spanner
• Deploy empat layanan workload yang digunakan untuk menyimulasikan beban layanan backend.

Yang akan Anda pelajari

• Cara menyediakan pipeline GKE Autopilot, Cloud Spanner, dan Cloud Deploy menggunakan Terraform
• Cara Workload Identity memungkinkan layanan di GKE meniru identitas akun layanan untuk mengakses izin IAM agar dapat berfungsi dengan Cloud Spanner
• Cara membuat beban mirip produksi di GKE dan Cloud Spanner menggunakan Locust.io

Yang Anda butuhkan

• Project Google Cloud yang terhubung ke akun penagihan.
• Browser web, seperti Chrome atau Firefox.

2. Penyiapan dan persyaratan

Membuat project

Peringatan: Codelab ini akan membuat perubahan pada project Anda. Sebaiknya siapkan project khusus untuk codelab ini.

Jika belum memiliki Akun Google (Gmail atau Google Apps), Anda harus membuatnya. Login ke konsol Google Cloud Platform ( console.cloud.google.com) dan buat project baru.

Jika Anda sudah memiliki project, klik menu pull-down pilihan project di kiri atas konsol:

dan klik 'NEW PROJECT' tombol dalam dialog yang dihasilkan untuk membuat project baru:

Jika belum memiliki project, Anda akan melihat dialog seperti ini untuk membuat project pertama:

Dialog pembuatan project berikutnya memungkinkan Anda memasukkan detail project baru:

Ingat project ID yang merupakan nama unik di semua project Google Cloud (maaf, nama di atas telah digunakan dan tidak akan berfungsi untuk Anda!) Project ID tersebut selanjutnya akan dirujuk di codelab ini sebagai PROJECT_ID.

Selanjutnya, jika Anda belum melakukannya, Anda harus mengaktifkan penagihan di Developers Console untuk menggunakan resource Google Cloud dan mengaktifkan Cloud Spanner API.

Menjalankan melalui codelab ini tidak akan menghabiskan biaya lebih dari beberapa dolar, tetapi bisa lebih jika Anda memutuskan untuk menggunakan lebih banyak resource atau jika Anda membiarkannya berjalan (lihat bagian "pembersihan" di akhir dokumen ini). Harga Google Cloud Spanner didokumentasikan di sini, dan Autopilot GKE didokumentasikan di sini.

Pengguna baru Google Cloud Platform memenuhi syarat untuk mendapatkan uji coba gratis senilai $300, yang menjadikan codelab ini sepenuhnya gratis.

Penyiapan Cloud Shell

Meskipun Google Cloud dan Spanner dapat dioperasikan dari jarak jauh menggunakan laptop Anda, dalam codelab ini, kita akan menggunakan Google Cloud Shell, lingkungan command line yang berjalan di Cloud.

Mesin virtual berbasis Debian ini memuat semua alat pengembangan yang akan Anda perlukan. Layanan ini menawarkan direktori beranda tetap sebesar 5 GB dan beroperasi di Google Cloud, sehingga sangat meningkatkan performa dan autentikasi jaringan. Ini berarti bahwa semua yang Anda perlukan untuk codelab ini adalah browser (ya, ini berfungsi di Chromebook).

1. Untuk mengaktifkan Cloud Shell dari Konsol Cloud, cukup klik Aktifkan Cloud Shell (hanya perlu waktu beberapa saat untuk melakukan penyediaan dan terhubung ke lingkungan).

Setelah terhubung ke Cloud Shell, Anda akan melihat bahwa Anda sudah diautentikasi dan project sudah ditetapkan ke PROJECT_ID.

gcloud auth list

Output perintah

Credentialed accounts:
 - <myaccount>@<mydomain>.com (active)

Catatan: Alat command line gcloud sudah diinstal lebih dulu di Cloud Shell. Untuk mengetahui informasi selengkapnya, baca ringkasan alat command line gcloud.

gcloud config list project

Output perintah

[core]
project = <PROJECT_ID>

Jika, untuk beberapa alasan, project belum disetel, cukup jalankan perintah berikut:

gcloud config set project <PROJECT_ID>

Mencari PROJECT_ID Anda? Periksa ID yang Anda gunakan di langkah-langkah penyiapan atau cari di dasbor Cloud Console:

Cloud Shell juga menetapkan beberapa variabel lingkungan secara default, yang mungkin berguna saat Anda menjalankan perintah di masa mendatang.

echo $GOOGLE_CLOUD_PROJECT

Output perintah

<PROJECT_ID>

Catatan: Saat Anda menjalankan gcloud di mesin Anda sendiri, setelan konfigurasi akan disimpan di seluruh sesi. Namun di Cloud Shell, Anda perlu menyetelnya untuk setiap sesi atau sambungan ulang baru.

Mendownload kode

Di Cloud Shell, Anda dapat mendownload kode untuk lab ini:

git clone https://github.com/cloudspannerecosystem/spanner-gaming-sample.git

Output perintah

Cloning into 'spanner-gaming-sample'...
*snip*

Codelab ini didasarkan pada rilis v0.1.3, jadi periksa tag tersebut:

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

Output perintah

Switched to a new branch 'v0.1.3-branch'

Sekarang, tetapkan direktori kerja saat ini sebagai variabel lingkungan DEMO_HOME. Hal ini akan memudahkan navigasi saat Anda mengerjakan berbagai bagian codelab.

export DEMO_HOME=$(pwd)

Ringkasan

Pada langkah ini, Anda telah menyiapkan project baru, mengaktifkan Cloud Shell, dan mendownload kode untuk lab ini.

Berikutnya

Selanjutnya, Anda akan menyediakan infrastruktur menggunakan Terraform.

3. Menyediakan infrastruktur

Ringkasan

Setelah project Anda siap, sekarang saatnya menjalankan infrastruktur. Hal ini mencakup networking VPC, Cloud Spanner, GKE Autopilot, Artifact Registry untuk menyimpan image yang akan berjalan di GKE, pipeline Cloud Deploy untuk layanan backend dan workload, dan terakhir, akun layanan serta hak istimewa IAM agar dapat menggunakan layanan tersebut.

Banyak sekali. Untungnya, Terraform bisa menyederhanakan penyiapannya. Terraform adalah model "Infrastructure as Code" yang memungkinkan kita untuk menentukan apa yang kita butuhkan untuk project ini dalam serangkaian ‘.tf' . Hal ini menyederhanakan penyediaan infrastruktur.

Anda tidak harus terbiasa dengan Terraform untuk menyelesaikan codelab ini. Namun, jika Anda ingin melihat apa yang dilakukan beberapa langkah selanjutnya, Anda dapat melihat semua hal yang dibuat dalam file ini yang berada di direktori infrastructure:

• vpc.tf
• backend_gke.tf
• spanner.tf
• artifact_registry.tf
• pipelines.tf
• iam.tf

Mengonfigurasi Terraform

Di Cloud Shell, Anda akan beralih ke direktori infrastructure dan melakukan inisialisasi Terraform:

cd $DEMO_HOME/infrastructure
terraform init

Output perintah

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.

Selanjutnya, konfigurasi Terraform dengan menyalin terraform.tfvars.sample dan mengubah nilai project. Variabel lainnya juga dapat diubah, tetapi hanya project yang harus diubah agar sesuai dengan lingkungan Anda.

cp  terraform.tfvars.sample terraform.tfvars
# edit gcp_project using the project environment variable
sed -i "s/PROJECT/$GOOGLE_CLOUD_PROJECT/" terraform.tfvars

Catatan: Dengan menggunakan variabel default, infrastruktur akan di-deploy di region us-central1.

Menyediakan infrastruktur

Peringatan: Langkah ini akan membuat perubahan pada project Anda. Hal ini dapat menimbulkan konsekuensi yang tidak diinginkan jika Anda menggunakan project yang sudah ada sebelumnya. Sebaiknya siapkan project khusus untuk codelab ini.

Sekarang saatnya untuk menyediakan infrastruktur.

terraform apply
# review the list of things to be created
# type 'yes' when asked

Output perintah

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.

Catatan: Diperlukan waktu beberapa menit untuk menyiapkan infrastruktur sepenuhnya.

Catatan: Anda mungkin mendapatkan catatan tentang default_secret_name Kubernetes yang tidak digunakan lagi. Hal ini aman untuk diabaikan.

Memeriksa apa yang telah dibuat

Untuk memverifikasi apa yang telah dibuat, Anda ingin memeriksa produk di Cloud Console.

Catatan: Resource di bawah mungkin tidak muncul sampai langkah terraform apply selesai.

Cloud Spanner

Pertama, periksa Cloud Spanner dengan membuka menu tiga garis dan mengklik Spanner. Anda mungkin harus mengklik 'Lihat produk lainnya' untuk menemukannya dalam daftar.

Anda akan diarahkan ke daftar instance Spanner. Klik instance dan Anda akan melihat database. Ini akan terlihat seperti berikut:

Catatan: Anda akan melihat bahwa ini adalah instance terperinci yang berjalan di 100 unit pemrosesan (100 PU), dengan konfigurasi regional us-central.

Autopilot GKE

Selanjutnya, periksa GKE dengan membuka menu tiga garis dan mengklik Kubernetes Engine => Clusters. Di sini Anda akan melihat cluster sample-games-gke yang berjalan dalam mode Autopilot.

Catatan: Perhatikan bahwa cluster GKE juga terletak di region us-central. Aplikasi harus berada dekat dengan database untuk mengurangi latensi permintaan.

Artifact Registry

Sekarang Anda ingin melihat di mana gambar akan disimpan. Jadi, klik menu tiga garis dan temukan Artifact Registry=>Repositories. Artifact Registry ada di bagian CI/CD pada menu.

Di sini, Anda akan melihat registry Docker bernama spanner-game-images. Kolom ini akan kosong untuk saat ini.

Cloud Deploy

Cloud Deploy adalah tempat pembuatan pipeline sehingga Cloud Build dapat menyediakan langkah-langkah untuk membangun image dan kemudian men-deploy-nya ke cluster GKE kami.

Buka menu tiga garis dan temukan Cloud Deploy, yang juga ada di bagian CI/CD pada menu.

Di sini Anda akan melihat dua pipeline: satu untuk layanan backend, dan satu untuk beban kerja. Keduanya men-deploy image ke cluster GKE yang sama, tetapi ini memungkinkan pemisahan deployment kami.

IAM

Terakhir, lihat halaman IAM di Konsol Cloud untuk memverifikasi akun layanan yang telah dibuat. Buka menu tiga garis dan temukan IAM and Admin=>Service accounts. Ini akan terlihat seperti berikut:

Total ada enam akun layanan yang dibuat oleh Terraform:

• Akun layanan komputer default. Kode ini tidak digunakan dalam codelab ini.
• Akun cloudbuild-cicd digunakan untuk langkah-langkah Cloud Build dan Cloud Deploy.
• Empat 'aplikasi' akun yang digunakan oleh layanan backend untuk berinteraksi dengan Cloud Spanner.

Berikutnya, Anda perlu mengonfigurasi kubectl untuk berinteraksi dengan cluster GKE.

Mengonfigurasi 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

Output perintah

#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

Catatan: Pemeriksaan penting adalah bahwa kubectl tidak boleh memberikan error apa pun tentang autentikasi.

Ringkasan

Bagus! Anda dapat menyediakan instance Cloud Spanner, cluster GKE Autopilot, semuanya di VPC untuk jaringan pribadi.

Selain itu, dua pipeline Cloud Deploy dibuat untuk layanan backend dan workload, serta sebuah repositori Artifact Registry untuk menyimpan image yang dibangun.

Terakhir, akun layanan dibuat dan dikonfigurasi agar berfungsi dengan Workload Identity, sehingga layanan backend dapat menggunakan Cloud Spanner.

Anda juga telah mengonfigurasi kubectl untuk berinteraksi dengan cluster GKE di Cloud Shell setelah men-deploy layanan backend dan workload.

Berikutnya

Sebelum Anda dapat menggunakan layanan, skema database perlu ditentukan. Anda akan menyiapkannya nanti.

4. Membuat skema database

Ringkasan

Sebelum dapat menjalankan layanan backend, Anda perlu memastikan bahwa skema database sudah diterapkan.

Jika melihat file dalam direktori $DEMO_HOME/schema/migrations dari repositori demo, Anda akan melihat serangkaian file .sql yang menentukan skema kami. Hal ini meniru siklus pengembangan tempat perubahan skema dilacak di repositori itu sendiri, dan dapat dikaitkan dengan fitur tertentu aplikasi.

Untuk lingkungan contoh ini, kunci pas adalah alat yang akan menerapkan migrasi skema menggunakan Cloud Build.

Cloud Build

File $DEMO_HOME/schema/cloudbuild.yaml menjelaskan langkah-langkah yang akan dilakukan:

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

Pada dasarnya ada dua langkah:

• download kunci pas ke ruang kerja Cloud Build
• jalankan migrasi kunci pas

Variabel lingkungan project, instance, dan database Spanner diperlukan agar kunci pas terhubung ke endpoint tulis.

Cloud Build dapat melakukan perubahan ini karena berjalan sebagai akun layanan cloudbuild-cicd@${PROJECT_ID}.iam.gserviceaccount.com:

serviceAccount: projects/${PROJECT_ID}/serviceAccounts/cloudbuild-cicd@${PROJECT_ID}.iam.gserviceaccount.com

Selain itu, akun layanan ini memiliki peran spanner.databaseUser yang ditambahkan oleh Terraform, yang memungkinkan akun layanan mengupdateDDL.

Migrasi skema

Ada lima langkah migrasi yang dilakukan berdasarkan file dalam direktori $DEMO_HOME/schema/migrations. Berikut adalah contoh file 000001.sql yang membuat tabel dan indeks 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);

Mengirimkan migrasi skema

Untuk mengirimkan build guna melakukan migrasi skema, beralihlah ke direktori schema dan jalankan perintah gcloud berikut:

cd $DEMO_HOME/schema
gcloud builds submit --config=cloudbuild.yaml

Output perintah

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

Catatan: Diperlukan waktu beberapa menit untuk men-deploy migrasi skema

Pada output di atas, Anda akan melihat link ke proses build cloud Created. Jika diklik, Anda akan diarahkan ke build di Cloud Console sehingga Anda dapat memantau progres build dan melihat apa yang dilakukannya.

Catatan: Langkah-langkah untuk migrasi sesuai dengan jumlah file dalam direktori $DEMO_HOME/schema/migrations.

Ringkasan

Pada langkah ini, Anda telah menggunakan Cloud Build untuk mengirimkan migrasi skema awal yang menerapkan 5 operasi DDL berbeda. Operasi ini mewakili saat fitur ditambahkan yang memerlukan perubahan skema database.

Dalam skenario pengembangan normal, Anda perlu membuat perubahan skema agar kompatibel dengan aplikasi saat ini untuk menghindari gangguan.

Untuk perubahan yang tidak kompatibel dengan versi sebelumnya, Anda perlu men-deploy perubahan pada aplikasi dan skema secara bertahap untuk memastikan tidak ada gangguan.

Berikutnya

Setelah skema diterapkan, langkah selanjutnya adalah men-deploy layanan backend.

5. Men-deploy layanan backend

Ringkasan

Layanan backend untuk codelab ini adalah REST API golang yang mewakili empat layanan berbeda:

• Profil: memberi pemain kemampuan untuk mendaftar dan mengautentikasi ke "game" contoh kami.
• Pencarian lawan: berinteraksi dengan data pemain untuk membantu fungsi pencarian lawan, melacak informasi tentang game yang dibuat, dan memperbarui statistik pemain saat game ditutup.
• Item: memungkinkan pemain memperoleh item dan uang game selama bermain game.
• Tradepost: memungkinkan pemain membeli dan menjual item di postingan dagang

Anda dapat mempelajari layanan ini lebih lanjut di codelab Memulai Pengembangan Game Cloud Spanner. Tujuannya, kita ingin layanan ini berjalan di cluster GKE Autopilot.

Layanan tersebut harus dapat mengubah data Spanner. Untuk melakukan itu, setiap layanan memiliki akun layanan yang telah dibuat yang memberinya akses 'databaseUser' peran.

Dengan Workload Identity, akun layanan Kubernetes dapat meniru identitas layanan tersebut akun layanan google cloud dengan mengikuti langkah-langkah berikut di Terraform kami:

• Membuat resource akun layanan Google Cloud (GSA) layanan
• Menetapkan peran databaseUser ke akun layanan tersebut
• Menetapkan peran workloadIdentityUser ke akun layanan tersebut
• Buat akun layanan Kubernetes (KSA) yang merujuk ke GSA

Diagram kasarnya akan terlihat seperti ini:

Catatan: Setiap layanan memiliki GSA dan KSA sendiri untuk memisahkan izin dan mengikuti Prinsip Hak Istimewa Terendah.

Terraform membuat akun layanan dan akun layanan Kubernetes untuk Anda. Anda juga dapat memeriksa akun layanan Kubernetes menggunakan 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

Cara kerja build tersebut adalah sebagai berikut:

• Terraform membuat file $DEMO_HOME/backend_services/cloudbuild.yaml yang terlihat seperti ini:

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

• Perintah Cloud Build membaca file ini dan mengikuti langkah-langkah yang tercantum. Pertama, ia membangun image layanan. Kemudian, ia menjalankan perintah gcloud deploy create. Perintah ini membaca file $DEMO_HOME/backend_services/skaffold.yaml, yang menentukan lokasi setiap file deployment:

apiVersion: skaffold/v2beta29
kind: Config
deploy:
 kubectl:
   manifests:
     - spanner_config.yaml
     - profile/deployment.yaml
     - matchmaking/deployment.yaml
     - item/deployment.yaml
     - tradepost/deployment.yaml

• Cloud Deploy akan mengikuti definisi dari setiap file deployment.yaml layanan. File deployment layanan berisi informasi untuk membuat layanan, yang dalam hal ini adalah clusterIP yang berjalan di port 80.

" Jenis ClusterIP" mencegah pod layanan backend memiliki IP eksternal sehingga hanya entity yang dapat terhubung ke jaringan GKE internal yang dapat mengakses layanan backend. Layanan ini tidak boleh dapat diakses langsung oleh pemain karena mereka mengakses dan mengubah data Spanner.

apiVersion: v1
kind: Service
metadata:
 name: profile
spec:
 type: ClusterIP
 selector:
   app: profile
 ports:
 - port: 80
   targetPort: 80

Contoh: $DEMO_HOME/backend_services/profile/deployment.yaml

Selain membuat layanan Kubernetes, Cloud Deploy juga membuat deployment Kubernetes. Mari kita pelajari bagian deployment layanan 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"

Bagian atas menyediakan beberapa metadata tentang layanan. Bagian terpenting dari hal ini adalah menentukan jumlah replika yang akan dibuat oleh deployment ini.

replicas: 2 # EDIT: Number of instances of deployment

Selanjutnya, kita melihat akun layanan mana yang harus menjalankan aplikasi, dan image mana yang harus digunakan. Ini cocok dengan akun layanan Kubernetes yang dibuat dari Terraform dan image yang dibuat selama langkah Cloud Build.

spec:
  serviceAccountName: profile-app
  containers:
    - name: profile-service
      image: profile

Setelah itu, kita menentukan beberapa informasi tentang variabel lingkungan dan jaringan.

spanner_config adalah Kubernetes ConfigMap yang menentukan informasi project, instance, dan database yang diperlukan agar aplikasi dapat terhubung ke 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}

Catatan: File spanner_config.yaml dihasilkan oleh Terraform berdasarkan files/backend_services/spanner-config.yaml.tpl.

ports:
  - containerPort: 80
envFrom:
  - configMapRef:
    name: spanner-config
env:
  - name: SERVICE_HOST
    value: "0.0.0.0"
  - name: SERVICE_PORT
    value: "80"

SERVICE_HOST dan SERVICE_PORT adalah variabel lingkungan tambahan yang diperlukan oleh layanan untuk mengetahui di mana harus mengikat.

Bagian terakhir memberi tahu GKE berapa banyak resource yang diizinkan untuk setiap replika dalam deployment ini. Inilah yang digunakan GKE Autopilot untuk menskalakan cluster sesuai kebutuhan.

resources:
  requests:
    cpu: "1"
    memory: "1Gi"
    ephemeral-storage: "100Mi"
  limits:
    cpu: "1"
    memory: "1Gi"
    ephemeral-storage: "100Mi"

Dengan informasi ini, kini saatnya men-deploy layanan backend.

Men-deploy layanan backend

Seperti yang telah disebutkan, men-deploy layanan backend menggunakan Cloud Build. Sama seperti migrasi skema, Anda dapat mengirimkan permintaan build menggunakan command line gcloud:

cd $DEMO_HOME/backend_services
gcloud builds submit --config=cloudbuild.yaml

Output perintah

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

Catatan: Diperlukan waktu beberapa menit untuk menyelesaikan build dan deployment.

Berbeda dengan output langkah schema migration, output build ini menunjukkan bahwa ada beberapa gambar yang dibuat. Data tersebut akan disimpan di repositori Artifact Registry Anda.

Output langkah gcloud build akan memiliki link ke Cloud Console. Lihatlah.

Catatan: Meskipun Anda mendapatkan pesan SUCCESS dari Cloud Build, deployment tidak akan selesai sampai pod dijalankan.

Setelah Anda mendapatkan notifikasi keberhasilan dari Cloud Build, buka Cloud Deploy lalu ke pipeline sample-game-services untuk memantau progres deployment.

Setelah layanan di-deploy, Anda dapat memeriksa kubectl untuk melihat pod status:

kubectl get pods

Output perintah

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

Kemudian, periksa layanan untuk melihat cara kerja ClusterIP:

kubectl get services

Output perintah

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

Catatan: Layanan backend tidak memiliki IP Eksternal yang ditetapkan untuk mencegah akses luar ke API.

Anda juga dapat membuka UI GKE di Cloud Console untuk melihat Workloads, Services, dan ConfigMaps.

Beban kerja

Layanan

ConfigMaps

Ringkasan

Pada langkah ini, Anda telah men-deploy empat layanan backend ke GKE Autopilot. Anda dapat menjalankan langkah Cloud Build dan memeriksa progresnya di Cloud Deploy dan Kubernetes di Konsol Cloud.

Anda juga telah mempelajari cara layanan ini memanfaatkan Workload Identity untuk meniru identitas akun layanan yang memiliki izin yang tepat untuk membaca dan menulis data ke database Spanner.

Langkah Berikutnya

Di bagian berikutnya, Anda akan men-deploy workload.

6. Men-deploy workload

Ringkasan

Setelah layanan backend berjalan di cluster, Anda akan men-deploy workload.

Beban kerja dapat diakses secara eksternal, dan ada satu workload untuk setiap layanan backend untuk tujuan codelab ini.

Workload ini adalah skrip pembuatan beban berbasis Locust yang meniru pola akses sebenarnya yang diharapkan oleh layanan contoh tersebut.

Ada file untuk proses Cloud Build:

• $DEMO_HOME/workloads/cloudbuild.yaml (dibuat oleh Terraform)
• $DEMO_HOME/workloads/skaffold.yaml
• file deployment.yaml untuk setiap workload

Anda dapat melihat file cloudbuild.yaml dan skaffold.yaml. Layanan backend hampir sama persis dengan layanan backend, hanya saja nama dan direktori image-nya berbeda.

File deployment.yaml workload terlihat sedikit berbeda dari file deployment layanan backend.

Berikut adalah contoh dari 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"

Bagian atas file mendefinisikan layanan. Dalam hal ini, LoadBalancer dibuat, dan beban kerja berjalan pada port 8089.

LoadBalancer akan menyediakan IP eksternal yang dapat digunakan untuk terhubung ke workload.

apiVersion: v1
kind: Service
metadata:
 name: matchmaking-workload
spec:
 type: LoadBalancer
 selector:
   app: matchmaking-workload
 ports:
 - port: 8089
   targetPort: 8089

Bagian atas deployment adalah metadata tentang workload. Dalam hal ini, hanya satu replika yang di-deploy:

replicas: 1 

Namun, spesifikasi container berbeda. Salah satunya, kita menggunakan akun layanan Kubernetes default. Akun ini tidak memiliki hak istimewa khusus, karena beban kerja tidak perlu terhubung ke resource Google Cloud apa pun kecuali layanan backend yang berjalan di cluster GKE.

Perbedaan lainnya adalah tidak ada variabel lingkungan yang diperlukan untuk beban kerja ini. Hasilnya adalah spesifikasi deployment yang lebih pendek.

spec:
  serviceAccountName: default
  containers:
    - name: matchmaking-workload
      image: matchmaking-workload
  ports:
    - containerPort: 8089

Setelan resource mirip dengan layanan backend. Perlu diingat bahwa inilah cara Autopilot GKE mengetahui jumlah resource yang diperlukan untuk memenuhi permintaan semua pod yang berjalan di cluster.

Lanjutkan dan deploy workload.

Men-deploy workload

Sama seperti sebelumnya, Anda dapat mengirimkan permintaan build menggunakan command line gcloud:

cd $DEMO_HOME/workloads
gcloud builds submit --config=cloudbuild.yaml

Output perintah

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

Catatan: Diperlukan waktu beberapa menit untuk menyelesaikan build dan deployment.

Pastikan Anda memeriksa log Cloud Build dan pipeline Cloud Deploy di Konsol Cloud untuk memeriksa statusnya. Untuk workload, pipeline Cloud Deploy adalah sample-game-workloads:

Setelah deployment selesai, periksa statusnya dengan kubectl di Cloud Shell:

kubectl get pods

Output perintah

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

Kemudian, periksa layanan workload untuk melihat cara kerja LoadBalancer:

kubectl get services 

Output perintah

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

Catatan: Tidak seperti layanan backend, beban kerja memiliki alamat IP eksternal yang ditetapkan.

Ringkasan

Anda kini telah berhasil men-deploy workload ke cluster GKE. Workload ini tidak memerlukan izin IAM tambahan dan dapat diakses secara eksternal di port 8089 menggunakan layanan LoadBalancer.

Langkah Berikutnya

Dengan layanan backend dan beban kerja yang sedang berjalan, saatnya untuk "play" game!

7. Mulai mainkan game

Ringkasan

Layanan backend untuk contoh "game" Anda sedang berjalan, dan Anda juga memiliki sarana untuk menghasilkan "pemain" berinteraksi dengan layanan tersebut menggunakan beban kerja.

Setiap beban kerja menggunakan Locust untuk menyimulasikan beban sebenarnya terhadap API layanan kami. Pada langkah ini, Anda akan menjalankan beberapa workload untuk membuat beban di cluster GKE dan Spanner, serta menyimpan data di Spanner.

Berikut adalah deskripsi setiap workload:

• Beban kerja item-generator adalah workload cepat untuk membuat daftar game_items yang dapat diperoleh pemain selama "bermain" game.
• profile-workload menyimulasikan pemain yang mendaftar dan login.
• matchmaking-workload menyimulasikan pemain yang mengantre untuk ditetapkan ke game.
• game-workload menyimulasikan pemain yang mendapatkan game_items dan uang selama bermain game.
• tradepost-workload menyimulasikan pemain yang dapat menjual dan membeli item di postingan perdagangan.

Catatan: Jika Anda ingin mengetahui detail selengkapnya tentang cara kerja generator Locust, lihat codelab Memulai Pengembangan Game Cloud Spanner.

Codelab ini akan menyoroti cara khusus menjalankan item-generator dan profile-workload.

Jalankan item-generator

item-generator menggunakan endpoint layanan backend item untuk menambahkan game_items ke Spanner. Item ini diperlukan agar game-workload dan tradepost-workload berfungsi dengan benar.

Langkah pertama adalah mendapatkan IP eksternal dari layanan item-generator. Di Cloud Shell, jalankan perintah berikut:

# The external IP is the 4th column of the output
kubectl get services | grep item-generator | awk '{print $4}'

Output perintah

{ITEMGENERATOR_EXTERNAL_IP}

Sekarang, buka tab browser baru dan arahkan ke http://{ITEMGENERATOR_EXTERNAL_IP}:8089. Anda akan mendapatkan halaman seperti ini:

Anda akan membiarkan users dan spawn tetap menggunakan nilai default 1. Untuk host, masukkan http://item. Klik opsi lanjutan dan masukkan 10s untuk durasi.

Berikut adalah tampilan konfigurasi seharusnya:

Catatan: Karena workload dan layanan backend berada di cluster GKE yang sama, keduanya dapat menemukan satu sama lain menggunakan resolusi DNS untuk nama layanan tersebut. Itulah sebabnya Anda dapat mereferensikan nama host http://item.

Klik 'Mulai berkerumun'!

Statistik akan mulai muncul untuk permintaan yang dikeluarkan pada endpoint POST /items. Setelah 10 detik, beban akan berhenti.

Klik Charts dan Anda akan melihat beberapa grafik tentang performa permintaan ini.

Sekarang, Anda ingin memeriksa apakah data dimasukkan ke dalam database Spanner.

Untuk melakukannya, klik menu tiga garis dan pilih 'Spanner'. Dari halaman ini, buka sample-instance dan sample-database. Lalu klik 'Query'.

Kita ingin memilih jumlah game_items:

{i>SELECT COUNT<i}(*) FROM game_items;

Di bagian bawah, Anda akan mendapatkan hasilnya.

Catatan: Jumlah persis game_items mungkin tidak cocok. Tidak masalah.

Kami tidak membutuhkan banyak game_items unggulan. Namun, sekarang mereka tersedia untuk diakuisisi oleh pemain!

Menjalankan profil-workload

Dengan unggulan game_items Anda, langkah selanjutnya adalah membuat pemain mendaftar agar dapat bermain game.

profile-workload akan menggunakan Locust untuk menyimulasikan pemain yang membuat akun, login, mengambil informasi profil, dan logout. Semua alat ini menguji endpoint layanan backend profile dalam beban kerja standar seperti produksi.

Untuk menjalankannya, dapatkan IP eksternal profile-workload:

# The external IP is the 4th column of the output
kubectl get services | grep profile-workload | awk '{print $4}'

Output perintah

{PROFILEWORKLOAD_EXTERNAL_IP}

Sekarang, buka tab browser baru dan arahkan ke http://{PROFILEWORKLOAD_EXTERNAL_IP}:8089. Anda akan mendapatkan halaman Locust yang mirip dengan halaman sebelumnya.

Dalam hal ini, Anda akan menggunakan http://profile untuk host. Dan Anda tidak perlu menentukan runtime di opsi lanjutan. Selain itu, tetapkan users menjadi 4, yang akan menyimulasikan 4 permintaan pengguna sekaligus.

Pengujian profile-workload akan terlihat seperti ini:

Klik 'Mulai berkerumun'!

Sama seperti sebelumnya, statistik untuk berbagai endpoint REST profile akan mulai muncul. Klik diagram untuk melihat tampilan seberapa baik performa semuanya.

Catatan: Biarkan profile-workload berjalan. Anda dapat memeriksa performa GKE dan Cloud Spanner di bagian selanjutnya.

Ringkasan

Pada langkah ini, Anda telah membuat beberapa game_items, lalu membuat kueri tabel game_items menggunakan UI Kueri Spanner di Konsol Cloud.

Anda juga mengizinkan pemain untuk mendaftar ke game Anda dan melihat bagaimana Locust dapat membuat beban kerja seperti produksi terhadap layanan backend Anda.

Langkah Berikutnya

Setelah menjalankan workload, Anda perlu memeriksa perilaku cluster GKE dan instance Spanner.

8. Meninjau penggunaan GKE dan Spanner

Setelah layanan profil berjalan, saatnya untuk melihat perilaku cluster GKE Autopilot dan Cloud Spanner.

Memeriksa cluster GKE

Buka cluster Kubernetes. Perhatikan bahwa karena Anda telah men-deploy workload dan layanan, cluster kini memiliki beberapa detail tentang total vCPU dan memori. Informasi ini tidak tersedia saat tidak ada beban kerja di cluster.

Sekarang, klik cluster sample-game-gke dan beralihlah ke tab kemampuan observasi:

Untuk pemanfaatan CPU, namespace kubernetes default seharusnya telah melampaui namespace kube-system karena workload dan layanan backend kita berjalan pada default. Jika belum, pastikan profile workload masih berjalan dan tunggu beberapa menit agar diagram diperbarui.

Untuk melihat beban kerja apa yang paling banyak menggunakan resource, buka dasbor Workloads.

Daripada membuka setiap workload satu per satu, buka tab Kemampuan observasi di dasbor. Anda akan melihat bahwa CPU profile dan profile-workload telah meningkat.

Sekarang, periksa Cloud Spanner.

Memeriksa instance Cloud Spanner

Untuk memeriksa performa Cloud Spanner, buka Spanner, lalu klik instance sample-instance dan database sample-game.

Dari sana, Anda akan melihat tab System Insights di menu kiri:

Ada banyak diagram di sini untuk membantu Anda memahami performa umum instance Spanner termasuk CPU utilization, transaction latency and locking, dan query throughput.

Selain Insight Sistem, Anda bisa mendapatkan informasi yang lebih mendetail tentang workload kueri dengan melihat link lain di bagian Kemampuan observasi:

• Insight Query membantu mengidentifikasi kueri topN yang memanfaatkan resource di Spanner.
• Insight Transaksi dan Kunci membantu mengidentifikasi transaksi dengan latensi tinggi.
• Key Visualizer membantu memvisualisasikan pola akses dan dapat membantu melacak hotspot dalam data.

Ringkasan

Pada langkah ini, Anda telah mempelajari cara memeriksa beberapa metrik performa dasar untuk GKE Autopilot dan Spanner.

Misalnya, saat beban kerja profil Anda berjalan, buat kueri tabel pemain untuk mendapatkan beberapa informasi selengkapnya tentang data yang disimpan di sana.

Sebelum melanjutkan, luangkan waktu untuk melihat informasi yang tersedia di GKE dan Spanner untuk memahami layanan tersebut.

Langkah Berikutnya

Selanjutnya, saatnya melakukan pembersihan!

9. Pembersihan

Sebelum bersih-bersih, Anda dapat mempelajari beban kerja lain yang tidak dibahas. Khususnya matchmaking-workload, game-workload, dan tradepost-workload.

Setelah selesai "bermain" di dalam game, Anda dapat membersihkan area bermain Anda. Untungnya ini cukup mudah.

Pertama, jika profile-workload masih berjalan di browser, ulangi dan hentikan:

Lakukan hal yang sama untuk setiap beban kerja yang mungkin telah Anda uji.

Kemudian di Cloud Shell, buka folder infrastructure. Anda akan melakukan destroy infrastruktur menggunakan terraform:

cd $DEMO_HOME/infrastructure
terraform destroy
# type 'yes' when asked

Output perintah

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.

Catatan: Diperlukan waktu beberapa menit untuk menghapus infrastruktur sepenuhnya.

Di Konsol Cloud, buka Spanner, Kubernetes Cluster, Artifact Registry, Cloud Deploy, dan IAM untuk memvalidasi semua resource yang telah dihapus.

10. Selamat!

Selamat, Anda telah berhasil men-deploy aplikasi golang sampel di GKE Autopilot dan menghubungkannya ke Cloud Spanner menggunakan Workload Identity.

Sebagai bonus, infrastruktur ini mudah disiapkan dan dihapus secara berulang menggunakan Terraform.

Anda dapat membaca selengkapnya tentang layanan Google Cloud yang berinteraksi dengan Anda di codelab ini:

• Autopilot GKE dan Workload Identity
• Cloud Spanner
• Artifact Registry
• Cloud Build dan Cloud Deploy

Apa langkah selanjutnya?

Setelah memiliki pemahaman dasar tentang bagaimana GKE Autopilot dan Cloud Spanner dapat bekerja sama, mengapa tidak mengambil langkah selanjutnya dan mulai membangun aplikasi Anda sendiri untuk digunakan dengan layanan tersebut?