Men-deploy Workload Confidential Space dengan MIG menggunakan Penskalaan Otomatis, Autohealing, dan Update Image

1. Ringkasan

Confidential Space (CS) menyediakan lingkungan yang aman, terbukti, dan terenkripsi untuk memproses data sensitif. Mengandalkan instance VM mandiri akan menimbulkan overhead operasional, karena orkestrasi manual tidak memiliki skalabilitas yang diperlukan untuk layanan penting. Tanpa orkestrasi otomatis, melakukan update bertahap yang disinkronkan atau men-deploy image OS baru di seluruh inventaris menjadi sulit secara teknis dan rentan terhadap periode nonaktif.

Dalam codelab ini, Anda akan mempelajari cara men-deploy beban kerja Confidential Space di Managed Instance Group (MIG). Anda juga akan mempelajari cara mengaktifkan autohealing menggunakan health check, penskalaan otomatis berdasarkan pemakaian CPU, dan update berkelanjutan untuk image OS dan workload.

Proses yang ditampilkan dalam codelab ini akan membantu Anda menyiapkan Ruang Rahasia yang siap produksi dan aman untuk deployment yang berjalan lama dan penting.

Yang akan Anda pelajari

Cara membuat template instance khusus untuk Confidential Space.
Cara menggunakan Google Compute Engine dan cara mengonfigurasi MIG dan grup instance
Cara membuat aturan firewall dan Health Check untuk autohealing.
Cara mengonfigurasi MIG zonal dengan template dan health check.
Cara menyiapkan penskalaan otomatis untuk MIG.
Cara menyiapkan update image OS sekali klik menggunakan skrip di MIG untuk image beban kerja dan rilis image OS baru untuk Confidential Space

Yang Anda butuhkan

Project Google Cloud yang mengaktifkan penagihan.
Pemahaman tentang editor teks, deployment Docker, dan pembuatan skrip Bash
Alat command line gcloud telah diinstal dan diautentikasi.
Pemahaman dasar tentang Compute Engine, Confidential Space, IAM, Confidential VM, teknologi container, repositori jarak jauh, akun layanan, Cloud Run, dan Cloud Scheduler
Image container beban kerja Confidential Space yang sudah di-build dan dikirim ke Artifact Registry.

2. Cara kerja Ruang Rahasia dengan MIG

Menggunakan Managed Instance Group (MIG) untuk men-deploy workload Confidential Space membuat aplikasi yang aman menjadi lebih tangguh, skalabel, dan mudah dioperasikan.

Kebutuhan keamanan dan operasional layanan produksi dibagi secara logis antara kedua komponen. Confidential Space memberikan keamanan yang diperlukan dengan menjalankan workload di lingkungan yang sangat terisolasi, terenkripsi, dan terverifikasi yang disebut Trusted Execution Environment (TEE). Sebaliknya, MIG menyediakan kemampuan operasional penting yang diperlukan untuk menjalankan aplikasi yang aman dalam skala besar, mirip dengan Kubernetes. MIG menghilangkan risiko yang melekat dalam menjalankan beban kerja penting di satu VM, yang berpotensi lambat atau rentan terhadap kegagalan. Kombinasi ini memastikan perlindungan data dan keandalan sistem. Solusi ini memastikan Ketersediaan Tinggi dan Autohealing karena beban kerja berjalan di beberapa VM dalam satu kumpulan. Jika satu VM mengalami error, layanan akan tetap berfungsi penuh karena load balancing dan keberadaan instance yang tersisa.

Selain itu, MIG menggunakan health check yang dapat dikonfigurasi untuk terus memantau status operasional VM. Jika instance ditemukan tidak responsif, MIG akan otomatis menggantinya dengan VM baru yang responsif, sehingga menjamin operasi yang berkelanjutan.

MIG juga memberikan skalabilitas yang efektif bagi pengguna dengan fitur penskalaan otomatisnya. Kemampuan ini menyediakan cara otomatis untuk mengelola kapasitas tanpa intervensi manual, sehingga memenuhi kebutuhan untuk menambahkan atau menghapus kapasitas secara fleksibel berdasarkan pemanfaatan.

Terakhir, MIG memungkinkan Update Tanpa Periode Nonaktif melalui Update Berkelanjutan. Manfaat utamanya adalah kemampuan "upgrade sekali klik" untuk image OS Confidential Space yang mendasarinya atau image container aplikasi (atau keduanya), tanpa menyebabkan gangguan layanan. MIG mengelola perubahan ini dengan mengganti instance lama secara bertahap dengan instance baru yang menjalankan image yang diupdate, sehingga memastikan ketersediaan yang konstan selama deployment. Perhatikan bahwa aplikasi Anda mungkin harus kompatibel dengan versi lama untuk mendukung jenis upgrade bertahap ini.

3. Menyiapkan Resource Cloud

Sebelum memulai

Siapkan project Google Cloud. Untuk mengetahui informasi selengkapnya tentang cara membuat project Google Cloud, lihat codelab"Menyiapkan dan menjelajahi project Google pertama Anda". Anda dapat melihat membuat dan mengelola project untuk mendapatkan detail tentang cara mengambil project ID dan perbedaannya dengan nama project dan nomor project.
Aktifkan Penagihan untuk project Anda.
Di salah satu Cloud Shell project Google, tetapkan variabel lingkungan project yang diperlukan seperti yang ditunjukkan di bawah.

export  CURRENT_PROJECT_ID=<Google Cloud project id of current project>

Aktifkan Confidential Computing API dan API berikut untuk project Anda.

gcloud config set project $CURRENT_PROJECT_ID
gcloud services enable \
cloudapis.googleapis.com \
container.googleapis.com \
artifactregistry.googleapis.com \
confidentialcomputing.googleapis.com \
compute.googleapis.com \
logging.googleapis.com \
run.googleapis.com \
cloudscheduler.googleapis.com

Di Cloud Shell project Google Cloud Anda, clone Confidential Space Codelab Github Repository, dan gunakan perintah di bawah untuk mendapatkan skrip yang sesuai yang diperlukan untuk menyelesaikan codelab ini.

git clone https://github.com/GoogleCloudPlatform/confidential-space.git

Ubah direktori ke direktori skrip untuk codelab grup instance

cd confidential-space/codelabs/mig_cs_codelab/scripts

Perbarui baris project ID di config_env.sh agar mencerminkan project yang Anda pilih.
Tetapkan variabel yang sudah ada sebelumnya. Ganti nama resource menggunakan variabel ini

Anda dapat menetapkan variabel berikut dengan nama resource cloud yang ada. Jika variabel ditetapkan, resource cloud yang ada dan sesuai dari project akan digunakan. Jika tidak disetel, nama resource cloud akan berasal dari skrip config_env.sh

Jalankan skrip config_env.sh untuk menetapkan nama variabel yang tersisa untuk project ini ke nilai berdasarkan ID project untuk nama resource

source config_env.sh

Tambahkan izin untuk project. Izin dapat ditambahkan dengan mengikuti detail di halaman web pemberian peran IAM.

Anda memerlukan izin berikut untuk project ini

Penulis Artifact Registry
Admin Cloud Scheduler
Compute Service Agent
Pengguna Workload Confidential Computing
Log Writer
Cloud Run Developer
Cloud Run Invoker

gcloud config set project $CURRENT_PROJECT_ID

# Add Artifact Registry Writer role
gcloud projects add-iam-policy-binding $CURRENT_PROJECT_ID --member="serviceAccount:${CURRENT_WORKLOAD_SERVICE_ACCOUNT}" --role='roles/artifactregistry.writer'

# Add Confidential Space Workload Userd
gcloud projects add-iam-policy-binding $CURRENT_PROJECT_ID --member="serviceAccount:${CURRENT_WORKLOAD_SERVICE_ACCOUNT}" --role='roles/confidentialcomputing.workloadUser'

# Add Logging Log Writer
gcloud projects add-iam-policy-binding $CURRENT_PROJECT_ID --member="serviceAccount:${CURRENT_WORKLOAD_SERVICE_ACCOUNT}" --role='roles/logging.logWriter'

# Add Cloud Run Developer
gcloud projects add-iam-policy-binding $CURRENT_PROJECT_ID --member="serviceAccount:${CURRENT_WORKLOAD_SERVICE_ACCOUNT}" --role='roles/run.developer'

# Add Cloud Run Invoker
gcloud projects add-iam-policy-binding $CURRENT_PROJECT_ID --member="serviceAccount:${CURRENT_WORKLOAD_SERVICE_ACCOUNT}" --role='roles/run.invoker'


# Add Cloud Scheduler Admin
gcloud projects add-iam-policy-binding $CURRENT_PROJECT_ID --member="serviceAccount:${CURRENT_WORKLOAD_SERVICE_ACCOUNT}" --role='roles/cloudscheduler.admin'

Lihat test_workload.py

Verifikasi output workload dengan meninjau kode sumber, yang hanya akan mencetak versi workload saat ini
Saat pertama kali mendorong beban kerja ke CS dan memeriksa output, kita akan melihat "version A" dicetak

4. Menyiapkan Workload

Pertama-tama, Anda perlu membuat image Docker untuk beban kerja yang digunakan dalam codelab ini. Beban kerja adalah skrip sederhana yang mencetak versi beban kerja yang sedang Anda jalankan. Program ini akan mencetak bahwa workload sedang dimulai, lalu mencetak versi workload, tidur selama 5 detik, lalu mencetak bahwa workload telah selesai.

Langkah-langkah untuk membuat Beban Kerja

Jalankan create_workload.sh untuk membuat beban kerja. Skrip ini:

Membuat Artifact Registry yang dimiliki oleh Project tempat workload akan dipublikasikan
Membangun kode dan mengemasnya dalam image Docker. Lihat konfigurasi dockerfile terkait untuk mengetahui informasi selengkapnya.
Memublikasikan image Docker ke Artifact Registry yang dimiliki oleh project
Memberikan izin baca untuk akun layanan <nama akun layanan Anda> ke repositori Artifact Registry <nama repositori Artifact Registry>

5. Menyiapkan Template Instance dan MIG

Langkah-Langkah Membuat Template Instance

Anda harus membuat Template Instance terlebih dahulu. Template ini adalah cetak biru yang diperlukan yang akan digunakan Grup Instance Terkelola (MIG) untuk menyediakan dan menjalankan workload Anda dalam Confidential Space.

Template Instance sangat penting karena menentukan semua parameter khusus:

Jenis Mesin: Dalam contoh ini, kita menggunakan jenis mesin Confidential VM (misalnya, n2d-standard-2) yang mendukung teknologi confidential computing AMD SEV (--confidential-compute-type=SEV).
Image OS VM: Kami menggunakan project confidential-space-images dan kelompok image confidential-space-debug untuk menarik image sistem operasi Confidential Space terbaru.
Catatan: Kita menggunakan image debug dalam panduan ini untuk mempermudah pemecahan masalah. Tidak seperti image produksi, versi debug membuat VM tetap berjalan setelah workload Anda selesai dan memungkinkan akses SSH untuk pengujian. Untuk deployment produksi yang menggunakan data sensitif dunia nyata, Anda harus beralih ke kelompok image produksi.
Referensi Workload: Baris wajib tee-image-reference dalam metadata berisi image container tertentu (workload aplikasi Anda) yang akan diluncurkan oleh VM Confidential Space.

Penyiapan ini memastikan setiap VM yang dibuat oleh MIG adalah Confidential Space yang dikonfigurasi dengan benar dan siap untuk menjalankan beban kerja Anda.

Langkah-Langkah Membuat Grup Instance Terkelola

Langkah berikutnya adalah membuat Grup Instance Terkelola (MIG) menggunakan template yang baru saja Anda tentukan. MIG sangat penting karena mengotomatiskan deployment, pengelolaan, dan penskalaan beberapa VM yang identik.

Skrip create_launch_mig.sh mencapai tiga tujuan utama:

1. Buat MIG

Perintah: gcloud compute instance-groups managed create ${CURRENT_MIG_NAME}
Tujuan: Perintah ini membuat grup yang akan mengelola VM Anda.
--size 3: Menentukan bahwa MIG harus membuat dan mempertahankan 3 instance workload Anda pada awalnya.
--template ${TEMPLATE_NAME}: Yang penting, template ini mereferensikan Template Instance yang dibuat sebelumnya, sehingga memastikan ketiga instance dikonfigurasi sebagai VM Confidential Space yang menjalankan container beban kerja tee-image-reference spesifik Anda.
--zone ${CURRENT_PROJECT_ZONE}: Menentukan lokasi deployment untuk instance.

2. Fetch Project Number

Perintah: PROJECT_NUMBER=$(gcloud projects describe ${PROJECT_ID} --format="value(projectNumber)")
Tujuan: Skrip mengambil ID numerik project Anda. Nomor ini sering kali diperlukan untuk membuat peran dan izin akun layanan, terutama untuk agen layanan yang dikelola Google.

3. Memberikan Izin IAM

Perintah: gcloud projects add-iam-policy-binding --role="roles/compute.serviceAgent"
Tujuan: Langkah ini memberikan peran Agen Layanan Compute Engine ke Akun Layanan beban kerja Anda (${SERVICE_ACCOUNT}). Izin ini penting karena memungkinkan Akun Layanan bertindak atas nama layanan Compute Engine project—yang sering kali diperlukan untuk fitur otomatis MIG seperti mengelola instance, menyiapkan jaringan, dan berinteraksi dengan layanan Google Cloud lainnya.

Jalankan create_launch_mig.sh untuk membuat grup instance terkelola.

6. Langkah-langkah untuk mengaktifkan Penyembuhan Otomatis dan Penskalaan Otomatis

Menyiapkan Autohealing

Untuk memastikan ketersediaan tinggi, kami memverifikasi bahwa beban kerja responsif. Jika aplikasi berhenti berfungsi, MIG harus mengganti VM. Aturan firewall untuk rentang IP sumber ditentukan dalam dokumen ini.

# 1. Create Health Check (TCP Port 22)
gcloud compute health-checks create tcp ${HEALTH_CHECK_NAME} \
  --port 22 \
  --check-interval 30s \
  --healthy-threshold 1 \
  --timeout 10s \
  --unhealthy-threshold 3 \
  --global

# 2. Allow Health Check Traffic (Firewall)
gcloud compute firewall-rules create allow-health-check \
    --allow tcp:22 \
    --source-ranges 130.211.0.0/22,35.191.0.0/16 \
    --network default \
    --project="${CURRENT_PROJECT_ID}" \ 

# 3. Apply to MIG
gcloud compute instance-groups managed update ${CURRENT_MIG_NAME} \
    --health-check ${HEALTH_CHECK_NAME} \
    --initial-delay 60 \
    --zone ${CURRENT_PROJECT_ZONE}

Menyiapkan Penskalaan Otomatis

Kita akan mengonfigurasi grup agar otomatis menskalakan antara 1 dan 5 instance untuk menangani lonjakan traffic.

gcloud compute instance-groups managed set-autoscaling ${CURRENT_MIG_NAME} \
    --max-num-replicas 5 \
    --target-cpu-utilization 0.80 \
    --cool-down-period 90 \
    --zone ${CURRENT_PROJECT_ZONE}

7. Memverifikasi workload dan Menyiapkan update image

Verifikasi Workload

Setelah Managed Instance Group (MIG) meluncurkan VM, kita perlu memverifikasi bahwa workload Confidential Space Anda berjalan dengan benar.

Anda dapat melakukannya melalui Konsol Google Cloud atau Command Line.

gcloud compute instance-groups managed list-instances ${CURRENT_MIG_NAME} \
    --zone ${CURRENT_PROJECT_ZONE}

Anda juga dapat memeriksa Output Port Serial untuk instance tertentu tersebut guna melihat log workload Anda

# Replace <INSTANCE_NAME> with one of the names from the previous command
gcloud compute instances get-serial-port-output <INSTANCE_NAME> \
    --zone ${CURRENT_PROJECT_ZONE} \
    --port 1

Menyiapkan Pembaruan Gambar

Dalam lingkungan produksi, Grup Instance Terkelola (MIG) Anda harus diperbarui secara rutin untuk menangani dua skenario berbeda:

Pembaruan Beban Kerja: Merilis versi baru kode aplikasi Anda (misalnya, mengupdate test_workload.py dari v1 ke v2).
Update Infrastruktur: Google merilis patch atau update keamanan untuk OS Confidential Space yang mendasarinya. Perhatikan bahwa praktik terbaiknya adalah mengambil gambar CS terbaru setidaknya setiap bulan.

Karena kita mengonfigurasi Template Instance dengan Link Gambar Dinamis (.../images/family/...) dan Tag Penampung Dinamis (:latest), kita dapat menangani kedua skenario ini dengan satu operasi "Penggantian Bertahap". Hal ini memastikan fleet VM Anda selalu menjalankan stack terbaru tanpa waktu non-operasional dan tanpa mengharuskan Anda membuat Template Instance baru untuk setiap perubahan kecil.

Skrip Penggantian Bergulir

Di direktori update_images, buka update_images_script.sh. Skrip ini memicu Penggantian Berkelanjutan, yang secara bertahap menghancurkan dan membuat ulang setiap VM dalam grup

#!/bin/bash

# Initialize the template
gcloud compute instance-groups managed set-instance-template "${CURRENT_MIG_NAME}" \
--template=projects/"${PROJECT_ID}"/global/instanceTemplates/"${TEMPLATE_NAME}" \
--zone="${CURRENT_PROJECT_ZONE}" \
--project="${PROJECT_ID}"

# Trigger the rolling replace
gcloud compute instance-groups managed rolling-action replace "${CURRENT_MIG_NAME}" \
    --version=template="${TEMPLATE_NAME}" \
    --project="${PROJECT_ID}" \
    --zone="${CURRENT_PROJECT_ZONE}" \
    --max-surge=1 \
    --max-unavailable=0

# Wait for the update to complete
gcloud compute instance-groups managed wait-until --version-target-reached "${CURRENT_MIG_NAME}" \
    --zone="${CURRENT_PROJECT_ZONE}" \
    --project="${PROJECT_ID}"

Untuk skrip ini, kita dapat menggunakan penggantian, bukan memulai ulang.

Mulai Ulang hanya akan memulai ulang komputer. Hal ini mempertahankan disk OS yang ada, yang berarti tidak akan mengambil patch OS baru.
Ganti akan menghapus VM dan membuat VM baru dari template. Tindakan ini akan memaksa sistem untuk mencari OS image Confidential Space terbaru dari kelompoknya serta menarik image container "Terbaru" dari registry.

–max-surge=1: Opsi ini memungkinkan MIG membuat 1 VM tambahan di atas ukuran target Anda untuk sementara. Proses ini meluncurkan VM baru (yang diupdate) dan menunggu hingga VM tersebut dalam kondisi baik sebelum menghapus VM lama (yang sudah tidak berlaku).

–max-unavailable=0: Ini memastikan tidak ada periode nonaktif. MIG akan diberi tahu bahwa MIG tidak diizinkan untuk menghentikan operasi mesin kecuali jika MIG telah berhasil mengganti mesin yang bermasalah.

Skrip Mulai Ulang Bertahap

Di direktori update_images, ada juga skrip lain, yaitu update_workload_image_script.sh. Skrip ini memicu Rolling Restart, yang merupakan metode lebih cepat yang digunakan secara ketat untuk me-refresh workload. Karena Confidential Space menarik image container dari registry setiap kali booting, memulai ulang sudah cukup untuk mengupdate aplikasi Anda ke versi :latest tanpa mengubah host yang mendasarinya.

#!/bin/bash
# Reboots the existing VMs to refresh the container
gcloud compute instance-groups managed rolling-action restart "${CURRENT_MIG_NAME}" \
    --project="${PROJECT_ID}" \
    --zone="${CURRENT_PROJECT_ZONE}" \
    --max-surge=1 \
    --max-unavailable=0

# Wait for the update to complete
gcloud compute instance-groups managed wait-until --stable "${CURRENT_MIG_NAME}" \
    --zone="${CURRENT_PROJECT_ZONE}" \
    --project="${CURRENT_PROJECT_ID}"

Memverifikasi Workload yang Diperbarui

Kita dapat menguji "Upgrade Sekali Klik" dengan menyimulasikan rilis aplikasi dunia nyata. Kita akan mengubah kode workload, mengirimkannya ke Artifact Registry, mengupdate MIG, dan memverifikasi bahwa versi baru berjalan tanpa periode nonaktif.

Langkah 1: Deploy Versi Workload Baru

Pertama, kita perlu membuat versi "baru" aplikasi Anda.

Buka file test_workload.py lokal Anda.
Ubah pernyataan cetak versi dari print("Workload Version A") menjadi print("Workload Version B")
Bangun ulang dan kirim image container ke Artifact Registry dengan menjalankan create_workload.sh. Perhatikan bahwa kita melakukan push ke tag yang sama (:latest).

Langkah 2: Lakukan Update Bertahap

Jalankan skrip update yang kita buat di bagian sebelumnya. Tindakan ini akan memaksa MIG mengganti setiap VM, dengan menarik hash container baru yang terkait dengan :latest.

# Run your update script
./update_images/update_images_script.sh

Tunggu hingga skrip selesai

Langkah 3: Verifikasi Update via Port Serial

Setelah update selesai, kami memverifikasi bahwa VM baru menjalankan kode yang telah diupdate.

# Replace <INSTANCE_NAME> with one of the names from the previous command
gcloud compute instances get-serial-port-output <INSTANCE_NAME> \
    --zone ${CURRENT_PROJECT_ZONE} \
    --port 1

Mendapatkan nama instance baru:

gcloud compute instance-groups managed list-instances ${CURRENT_MIG_NAME} --zone ${CURRENT_PROJECT_ZONE}

Periksa log:

# Replace <NEW_INSTANCE_NAME> with one of the names of the running VMs
gcloud compute instances get-serial-port-output <NEW_INSTANCE_NAME> \
    --zone ${CURRENT_PROJECT_ZONE} \
    --port 1

Setelah instance berjalan, pilih nama instance dari perintah gcloud sebelumnya untuk melihat port serialnya

Output yang Diharapkan: Anda akan melihat pesan log yang diperbarui, yang mengonfirmasi bahwa deployment berhasil:

... Workload Versi B ...

Langkah 4: Verifikasi Konfigurasi Infrastruktur (Opsional)

Anda juga dapat memverifikasi bahwa Template Instance Anda dikonfigurasi dengan benar untuk menarik update dinamis untuk OS dan Beban Kerja dengan memeriksa metadatanya.

Jalankan perintah berikut untuk melihat referensi container dinamis:

gcloud compute instance-templates describe ${TEMPLATE_NAME} \
    | grep -A 1 tee-image-reference

Hasil: Anda akan melihat image container Anda yang diakhiri dengan :latest.

Implikasi: Karena template mengarah ke tag, bukan hash tertentu, setiap penggantian tindakan bertahap berhasil menarik kode terbaru yang Anda kirimkan pada Langkah 1.

(Opsional) Update Otomatis

Meskipun update manual berguna untuk rilis versi utama, Anda sering kali ingin armada Anda otomatis mendapatkan patch keamanan terbaru atau build deployment reguler tanpa intervensi manusia.

Kita dapat mengotomatiskan proses 'Penggantian Bertahap' dengan mengemas skrip update ke dalam Tugas Cloud Run. Untuk codelab ini, kita akan memicunya setiap 15 menit. Di lingkungan produksi, tugas ini harus dijalankan jauh lebih jarang. Bergantung pada kebutuhan pengguna, mereka dapat mengonfigurasinya setiap minggu atau bulan.

Langkah 1: Masukkan Skrip Pengupdate ke dalam Container

Pertama, kita perlu mengemas update_images_script.sh (yang berisi logika penggantian tindakan bertahap gcloud ...) ke dalam container Docker agar dapat berjalan di cloud.

Kami telah menyiapkan skrip pembantu yang membangun container ini dan mengirimkannya ke Artifact Registry Anda.

Jalankan perintah berikut:

# Build and Push the "Updater" Container
# This packages your update logic into a docker image
./update_images/deploy_docker_script_image.sh

Fungsinya:

Skrip ini mengambil update_images_script.sh dari direktori update_images/.
Tindakan ini akan membuat image Docker yang berisi Google Cloud SDK dan skrip Anda.
Perintah ini akan mengirim image ke ${CURRENT_PROJECT_REGION}-docker.pkg.dev/${PROJECT_ID}/${REPOSITORY}/update-script:latest.

Langkah 2: Deploy dan Jadwalkan Tugas

Sekarang kita perlu memberi tahu Google Cloud untuk menjalankan container ini secara berkala. Kita menggunakan Cloud Run Jobs untuk mengeksekusi container dan Cloud Scheduler untuk memicunya.

Jalankan skrip konfigurasi penjadwalan:

# Create the Cloud Run Job and the Scheduler Trigger
./create_configs/create_schedule_job.sh

Dalam Skrip: Skrip ini melakukan dua tindakan penting:

Membuat Tugas Cloud Run: Tugas ini menentukan tugas bernama mig-updater-job yang menjalankan container yang baru saja kita kirim.
Membuat Pemicu Scheduler: Pemicu ini menyiapkan tugas Cloud Scheduler untuk memanggil Cloud Run Job API setiap 15 menit.

# (Snippet from create_schedule_job.sh for reference)
# The schedule is set to run every 15 minutes for testing purposes
gcloud scheduler jobs create http ${SCHEDULER_NAME} \
    --schedule "*/15 * * * *" \
    --uri "https://${CURRENT_PROJECT_REGION}-run.googleapis.com/apis/run.googleapis.com/v1/namespaces/${PROJECT_ID}/jobs/${JOB_NAME}:run" \
    --http-method POST \
    --oauth-service-account-email ${SERVICE_ACCOUNT}

Langkah 3: Verifikasi Otomatisasi

Anda tidak perlu menunggu 15 menit untuk mengujinya. Anda dapat memaksa penjadwal untuk segera berjalan guna memverifikasi pipeline.

Jalankan Tugas Secara Paksa:

gcloud scheduler jobs run ${SCHEDULER_NAME} --location ${CURRENT_PROJECT_REGION}

Periksa Eksekusi: Buka konsol Cloud Run > Tugas. Anda akan melihat eksekusi baru dimulai.
Periksa MIG: Jalankan gcloud compute instance-groups managed list-instances ${CURRENT_MIG_NAME}. Anda akan melihat instance memasuki status MEMBUAT ULANG saat tugas memicu update bertahap.

Mengapa 15 Menit? Kita menetapkan jadwal ke */15 * * * * untuk codelab ini sehingga Anda dapat melihat hasilnya dengan cepat. Di lingkungan produksi yang sebenarnya, Anda mungkin mengubahnya agar berjalan setiap hari (misalnya, 0 3 * * * untuk pukul 03.00) atau setiap minggu.

8. Pembersihan

Skrip pembersihan cleanup.sh dapat digunakan untuk membersihkan resource yang telah kita buat sebagai bagian dari codelab ini. Sebagai bagian dari pembersihan ini, resource berikut akan dihapus:

Grup Instance Terkelola (${CURRENT_MIG_NAME}) dan VM yang mendasarinya.
Template Instance (${TEMPLATE_NAME}).
Pemeriksaan Kondisi dan Aturan Firewall (${HEALTH_CHECK_NAME}).
Repositori Artifact Registry (${REPOSITORY}).
Akun Layanan (jika Anda membuat akun khusus untuk lab ini).

Jika Anda sudah selesai menjelajah, pertimbangkan untuk menghapus project Anda dengan mengikuti petunjuk berikut: Menghentikan (menghapus) project.

Selamat

Selamat, Anda berhasil menyelesaikan codelab ini.

Anda telah mempelajari cara menskalakan beban kerja Confidential Space dengan aman menggunakan Managed Instance Groups (MIG). Anda berhasil mengonfigurasi Penyembuhan Otomatis untuk memulihkan dari kegagalan, Penskalaan Otomatis untuk menangani lonjakan traffic, dan melakukan Update Tanpa Downtime untuk image OS Confidential Space dan container Workload.

Apa selanjutnya?

Lihat codelab Confidential Space tambahan:

Mengamankan model ML dan Kekayaan Intelektual menggunakan Confidential Space
Cara melakukan transaksi aset digital dengan komputasi banyak pihak dan Confidential Space
Menganalisis data rahasia dengan Confidential Space
Menggunakan Confidential Space dengan resource yang dilindungi yang tidak disimpan dengan penyedia cloud