การติดตั้งใช้งานเวิร์กโหลด Confidential Space ด้วย MIG โดยใช้การปรับขนาดอัตโนมัติ การซ่อมแซมอัตโนมัติ และการอัปเดตรูปภาพ

1. ภาพรวม

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

ใน Codelab นี้ คุณจะได้เรียนรู้วิธีการติดตั้งใช้งานเวิร์กโหลด Confidential Space ในกลุ่มอินสแตนซ์ที่มีการจัดการ (MIG) นอกจากนี้ คุณยังจะได้เรียนรู้วิธีเปิดใช้การซ่อมแซมอัตโนมัติโดยใช้การตรวจสอบประสิทธิภาพการทำงาน การปรับขนาดอัตโนมัติตามการใช้ CPU และอัปเดตทีละส่วนสำหรับทั้งอิมเมจระบบปฏิบัติการและภาระงาน=

กระบวนการที่แสดงใน Codelab นี้จะช่วยคุณในการตั้งค่า Confidential Space ที่พร้อมใช้งานจริงและปลอดภัยของคุณเองสำหรับการติดตั้งใช้งานที่สำคัญต่อภารกิจและใช้งานเป็นเวลานาน

สิ่งที่คุณจะได้เรียนรู้

วิธีสร้างเทมเพลตอินสแตนซ์เฉพาะสำหรับ Confidential Space
วิธีใช้ Google Compute Engine และวิธีกำหนดค่า MIG และกลุ่มอินสแตนซ์
วิธีกำหนดค่ากฎไฟร์วอลล์และการตรวจสอบประสิทธิภาพการทำงานสำหรับการซ่อมแซมอัตโนมัติ
วิธีกำหนดค่า MIG ระดับโซนด้วยเทมเพลตและการตรวจสอบประสิทธิภาพการทำงาน
วิธีตั้งค่าการปรับขนาดอัตโนมัติสำหรับ MIG
วิธีตั้งค่าการอัปเดตอิมเมจระบบปฏิบัติการด้วยการคลิกเพียงครั้งเดียวโดยใช้การเขียนสคริปต์ใน MIG สำหรับทั้งอิมเมจเวิร์กโหลดและอิมเมจระบบปฏิบัติการใหม่ที่เผยแพร่สำหรับ Confidential Space

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

โปรเจ็กต์ Google Cloud ที่เปิดใช้การเรียกเก็บเงิน
ความคุ้นเคยกับเครื่องมือแก้ไขข้อความ การติดตั้งใช้งาน Docker และการเขียนสคริปต์ Bash
ติดตั้งและตรวจสอบสิทธิ์เครื่องมือบรรทัดคำสั่ง gcloud แล้ว
ความเข้าใจพื้นฐานเกี่ยวกับ Compute Engine, Confidential Space, IAM, Confidential VM, เทคโนโลยีคอนเทนเนอร์, ที่เก็บข้อมูลระยะไกล, บัญชีบริการ, Cloud Run และ Cloud Scheduler
อิมเมจคอนเทนเนอร์ของภาระงาน Confidential Space ที่สร้างและพุชไปยัง Artifact Registry แล้ว

2. วิธีการทำงานของพื้นที่ทำงานลับที่มี MIG

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

ความต้องการด้านความปลอดภัยและการปฏิบัติงานของบริการเวอร์ชันที่ใช้งานจริงจะแบ่งออกเป็น 2 องค์ประกอบอย่างเป็นเหตุเป็นผล Confidential Space มอบความปลอดภัยที่จำเป็นด้วยการเรียกใช้เวิร์กโหลดในสภาพแวดล้อมที่มีการแยกอย่างเข้มงวด เข้ารหัส และรับรองที่เรียกว่าสภาพแวดล้อมการดำเนินการที่เชื่อถือได้ (TEE) ในทางตรงกันข้าม MIG มีความสามารถในการปฏิบัติงานที่จำเป็นต่อการเรียกใช้แอปพลิเคชันที่ปลอดภัยในวงกว้าง ซึ่งคล้ายกับของ Kubernetes MIG ช่วยลดความเสี่ยงที่เกิดจากการเรียกใช้ภาระงานที่สำคัญต่อพันธกิจใน VM เดียว ซึ่งอาจช้าหรือมีแนวโน้มที่จะล้มเหลว การผสมผสานนี้ช่วยให้มั่นใจได้ทั้งการคุ้มครองข้อมูลและความน่าเชื่อถือของระบบ โซลูชันนี้ช่วยให้มั่นใจได้ถึงความพร้อมใช้งานสูงและการซ่อมแซมตัวเอง เนื่องจากภาระงานทำงานใน VM หลายรายการในพูล หาก VM เครื่องใดเครื่องหนึ่งขัดข้อง บริการจะยังคงทำงานได้อย่างเต็มที่เนื่องจากการปรับสมดุลโหลดและอินสแตนซ์ที่เหลือ

นอกจากนี้ MIG ยังใช้การตรวจสอบประสิทธิภาพการทำงานที่กำหนดค่าได้เพื่อตรวจสอบสถานะการทำงานของ VM อย่างต่อเนื่อง หากพบว่าอินสแตนซ์ไม่สมบูรณ์ MIG จะแทนที่อินสแตนซ์นั้นด้วย VM ใหม่ที่สมบูรณ์โดยอัตโนมัติ จึงรับประกันการทำงานอย่างต่อเนื่อง

นอกจากนี้ MIG ยังมอบความสามารถในการปรับขนาดที่มีประสิทธิภาพสำหรับผู้ใช้ด้วยฟีเจอร์การปรับขนาดอัตโนมัติ ความสามารถนี้ช่วยให้คุณจัดการความจุได้โดยอัตโนมัติโดยไม่ต้องดำเนินการด้วยตนเอง ซึ่งตอบโจทย์ความต้องการในการเพิ่มหรือนำความจุออกได้อย่างยืดหยุ่นตามการใช้งาน

สุดท้ายนี้ MIG ช่วยให้การอัปเดตแบบไม่มีการหยุดทำงานผ่านการอัปเดตแบบต่อเนื่อง ข้อดีที่สำคัญคือความสามารถในการ "อัปเกรดได้ในคลิกเดียว" สำหรับอิมเมจระบบปฏิบัติการ Confidential Space พื้นฐานหรืออิมเมจคอนเทนเนอร์ของแอปพลิเคชัน (หรือทั้ง 2 อย่าง) โดยไม่ทำให้บริการหยุดทำงาน MIG จะจัดการการเปลี่ยนแปลงนี้โดยค่อยๆ แทนที่อินสแตนซ์เก่าด้วยอินสแตนซ์ใหม่ที่ใช้รูปภาพที่อัปเดตแล้ว เพื่อให้มั่นใจว่าอินสแตนซ์จะพร้อมใช้งานอย่างต่อเนื่องตลอดการติดตั้งใช้งาน โปรดทราบว่าแอปพลิเคชันของคุณอาจต้องเข้ากันได้แบบย้อนหลังเพื่อรองรับการอัปเกรดแบบค่อยเป็นค่อยไปประเภทนี้

3. การตั้งค่าทรัพยากรระบบคลาวด์

ก่อนเริ่มต้น

ตั้งค่าโปรเจ็กต์ Google Cloud ดูข้อมูลเพิ่มเติมเกี่ยวกับการสร้างโปรเจ็กต์ที่อยู่ในระบบคลาวด์ Google ได้ที่ Codelab"ตั้งค่าและไปยังโปรเจ็กต์ Google แรกของคุณ" คุณดูรายละเอียดเกี่ยวกับวิธีดึงข้อมูลรหัสโปรเจ็กต์และวิธีที่รหัสโปรเจ็กต์แตกต่างจากชื่อโปรเจ็กต์และหมายเลขโปรเจ็กต์ได้ที่หัวข้อการสร้างและการจัดการโปรเจ็กต์
เปิดใช้การเรียกเก็บเงินสำหรับโปรเจ็กต์
ใน Cloud Shell ของโปรเจ็กต์ Google โปรเจ็กต์ใดโปรเจ็กต์หนึ่ง ให้ตั้งค่าตัวแปรสภาพแวดล้อมของโปรเจ็กต์ที่จำเป็นตามที่แสดงด้านล่าง

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

เปิดใช้ Confidential Computing API และ API ต่อไปนี้สำหรับโปรเจ็กต์

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

ใน Cloud Shell ของโปรเจ็กต์ Google Cloud ให้โคลน Confidential Space Codelab Github Repository แล้วใช้คำสั่งด้านล่างเพื่อรับสคริปต์ที่เหมาะสมซึ่งจำเป็นต่อการทำ Codelab นี้ให้เสร็จสมบูรณ์

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

เปลี่ยนไดเรกทอรีเป็นไดเรกทอรีสคริปต์สำหรับ Codelab กลุ่มอินสแตนซ์

cd confidential-space/codelabs/mig_cs_codelab/scripts

อัปเดตบรรทัดรหัสโปรเจ็กต์ใน config_env.sh ให้ตรงกับรหัสของโปรเจ็กต์ที่คุณเลือก
ตั้งค่าตัวแปรที่มีอยู่ก่อนแล้ว ลบล้างชื่อทรัพยากรโดยใช้ตัวแปรต่อไปนี้

คุณตั้งค่าตัวแปรต่อไปนี้ได้โดยใช้ชื่อทรัพยากรระบบคลาวด์ที่มีอยู่ หากตั้งค่าตัวแปรไว้ ระบบจะใช้ทรัพยากรระบบคลาวด์ที่มีอยู่ซึ่งสอดคล้องกันจากโปรเจ็กต์ หากไม่ได้ตั้งค่าไว้ ชื่อทรัพยากรระบบคลาวด์จะมาจากสคริปต์ config_env.sh

เรียกใช้สคริปต์ config_env.sh เพื่อตั้งชื่อตัวแปรที่เหลือสำหรับโปรเจ็กต์นี้เป็นค่าตามรหัสโปรเจ็กต์สำหรับชื่อทรัพยากร

source config_env.sh

เพิ่มสิทธิ์สำหรับโปรเจ็กต์ คุณเพิ่มสิทธิ์ได้โดยทำตามรายละเอียดในหน้าเว็บให้บทบาท IAM

คุณจะต้องมีสิทธิ์ต่อไปนี้สำหรับโปรเจ็กต์นี้

ผู้เขียน Artifact Registry
ผู้ดูแลระบบเครื่องจัดตารางเวลาระบบคลาวด์
Agent บริการ Compute
ผู้ใช้เวิร์กโหลด Confidential Computing
ผู้เขียนบันทึก
นักพัฒนาซอฟต์แวร์ Cloud Run
ผู้เรียกใช้ Cloud Run

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'

ดู test_workload.py

ยืนยันเอาต์พุตของภาระงานโดยตรวจสอบซอร์สโค้ด ซึ่งควรจะพิมพ์เวอร์ชันปัจจุบันของภาระงาน
เมื่อเราพุชภาระงานไปยัง CS เป็นครั้งแรกและตรวจสอบเอาต์พุต เราควรเห็น "เวอร์ชัน A" พิมพ์ออกมา

4. การตั้งค่าภาระงาน

ก่อนอื่นคุณจะต้องสร้างอิมเมจ Docker สำหรับเวิร์กโหลดที่ใช้ใน Codelab นี้ เวิร์กโหลดเป็นสคริปต์ง่ายๆ ที่พิมพ์เวอร์ชันของเวิร์กโหลดที่คุณกำลังเรียกใช้ โดยจะพิมพ์ว่ากำลังเริ่มภาระงาน จากนั้นจะพิมพ์เวอร์ชันของภาระงาน พักเป็นเวลา 5 วินาที แล้วพิมพ์ว่าภาระงานเสร็จสิ้นแล้ว

ขั้นตอนการสร้างเวิร์กโหลด

เรียกใช้ create_workload.sh เพื่อสร้างปริมาณงาน สคริปต์นี้จะทำสิ่งต่อไปนี้

สร้าง Artifact Registry ที่โปรเจ็กต์เป็นเจ้าของซึ่งจะเผยแพร่เวิร์กโหลด
สร้างโค้ดและแพ็กเกจในอิมเมจ Docker ดูข้อมูลเพิ่มเติมได้ที่การกำหนดค่า Dockerfile ที่เกี่ยวข้อง
เผยแพร่อิมเมจ Docker ไปยัง Artifact Registry ที่โปรเจ็กต์เป็นเจ้าของ
ให้สิทธิ์อ่านแก่บัญชีบริการ <your service account name> สำหรับรีจิสทรีที่เก็บอาร์ติแฟกต์ <artifact registry repo name>

5. การตั้งค่าเทมเพลตอินสแตนซ์และ MIG

ขั้นตอนการสร้างเทมเพลตอินสแตนซ์

คุณต้องสร้างเทมเพลตอินสแตนซ์ก่อน เทมเพลตนี้เป็นพิมพ์เขียวที่จำเป็นซึ่งกลุ่มอินสแตนซ์ที่มีการจัดการ (MIG) จะใช้ในการจัดสรรและเรียกใช้เวิร์กโหลดภายใน Confidential Space

เทมเพลตอินสแตนซ์มีความสําคัญเนื่องจากเป็นตัวกําหนดพารามิเตอร์เฉพาะทั้งหมด

ประเภทเครื่อง: ในตัวอย่างนี้ เราใช้ประเภทเครื่อง Confidential VM (เช่น n2d-standard-2) ที่รองรับเทคโนโลยีการประมวลผลแบบเป็นความลับของ AMD SEV (--confidential-compute-type=SEV)
อิมเมจระบบปฏิบัติการ VM: เราใช้โปรเจ็กต์ confidential-space-images และตระกูลอิมเมจ confidential-space-debug เพื่อดึงอิมเมจระบบปฏิบัติการ Confidential Space เวอร์ชันล่าสุด
หมายเหตุ: เราใช้รูปภาพการแก้ไขข้อบกพร่องในคู่มือนี้เพื่อให้การแก้ปัญหาง่ายขึ้น เวอร์ชันแก้ไขข้อบกพร่องจะทำให้ VM ทำงานต่อไปหลังจากที่ภาระงานเสร็จสิ้นและอนุญาตให้เข้าถึง SSH เพื่อทำการทดสอบ ซึ่งแตกต่างจากอิมเมจที่ใช้งานจริง สำหรับการติดตั้งใช้งานจริงโดยใช้ข้อมูลที่ละเอียดอ่อนในโลกแห่งความเป็นจริง คุณต้องเปลี่ยนไปใช้ตระกูลอิมเมจการใช้งานจริง
ข้อมูลอ้างอิงของเวิร์กโหลด: บรรทัดที่ต้องระบุtee-image-referenceในข้อมูลเมตาจะมีอิมเมจคอนเทนเนอร์ที่เฉพาะเจาะจง (เวิร์กโหลดแอปพลิเคชัน) ที่ VM ของ Confidential Space จะเปิดใช้

การตั้งค่านี้ช่วยให้มั่นใจว่า VM ทุกเครื่องที่ MIG สร้างขึ้นจะเป็น Confidential Space ที่กำหนดค่าอย่างถูกต้องและพร้อมที่จะเรียกใช้งานเวิร์กโหลดของคุณ

ขั้นตอนการสร้างกลุ่มอินสแตนซ์ที่มีการจัดการ

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

สคริปต์ create_launch_mig.sh มีวัตถุประสงค์หลัก 3 ประการ ได้แก่

1. สร้าง MIG

คำสั่ง: gcloud compute instance-groups managed create ${CURRENT_MIG_NAME}
วัตถุประสงค์: คำสั่งนี้จะสร้างกลุ่มที่จะจัดการ VM
--size 3: ระบุว่า MIG ควรสร้างและดูแลรักษาอินสแตนซ์ของเวิร์กโหลด 3 รายการในตอนแรก
--template ${TEMPLATE_NAME}: ที่สำคัญคือจะอ้างอิงเทมเพลตอินสแตนซ์ที่สร้างไว้ก่อนหน้านี้ เพื่อให้มั่นใจว่าอินสแตนซ์ทั้ง 3 รายการได้รับการกำหนดค่าเป็น VM ของ Confidential Space ที่เรียกใช้คอนเทนเนอร์เวิร์กโหลด tee-image-reference ที่เฉพาะเจาะจง
--zone ${CURRENT_PROJECT_ZONE}: ระบุตำแหน่งการติดตั้งใช้งานสำหรับอินสแตนซ์

2. ดึงหมายเลขโปรเจ็กต์

คำสั่ง: PROJECT_NUMBER=$(gcloud projects describe ${PROJECT_ID} --format="value(projectNumber)")
วัตถุประสงค์: สคริปต์จะดึงรหัสที่เป็นตัวเลขของโปรเจ็กต์ โดยมักจะต้องใช้หมายเลขนี้ในการสร้างบทบาทและสิทธิ์ของบัญชีบริการ โดยเฉพาะอย่างยิ่งสำหรับตัวแทนบริการที่ Google จัดการ

3. ให้สิทธิ์ IAM

คำสั่ง: gcloud projects add-iam-policy-binding --role="roles/compute.serviceAgent"
วัตถุประสงค์: ขั้นตอนนี้จะให้บทบาทตัวแทนบริการ Compute Engine แก่บัญชีบริการของเวิร์กโหลด (${SERVICE_ACCOUNT}) สิทธิ์นี้มีความสำคัญเนื่องจากช่วยให้บัญชีบริการดำเนินการในนามของบริการ Compute Engine ของโปรเจ็กต์ได้ ซึ่งมักจำเป็นสำหรับฟีเจอร์อัตโนมัติของ MIG เช่น การจัดการอินสแตนซ์ การตั้งค่าเครือข่าย และการโต้ตอบกับบริการอื่นๆ ของ Google Cloud

เรียกใช้ create_launch_mig.sh เพื่อสร้างกลุ่มอินสแตนซ์ที่มีการจัดการ

6. ขั้นตอนในการเปิดใช้การซ่อมแซมอัตโนมัติและการปรับขนาดอัตโนมัติ

การตั้งค่าการซ่อมแซมอัตโนมัติ

เราจะตรวจสอบว่าปริมาณงานตอบสนองได้ดีเพื่อให้มั่นใจว่ามีความพร้อมใช้งานสูง หากแอปพลิเคชันหยุดทำงาน MIG ควรแทนที่ VM กฎไฟร์วอลล์สำหรับช่วง IP ต้นทางมีการกำหนดไว้ในเอกสารนี้

# 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}

การตั้งค่าการปรับขนาดอัตโนมัติ

เราจะกำหนดค่ากลุ่มให้ปรับขนาดระหว่าง 1 ถึง 5 อินสแตนซ์โดยอัตโนมัติเพื่อรองรับการเพิ่มขึ้นของการเข้าชม

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. การยืนยันภาระงานและการตั้งค่าการอัปเดตรูปภาพ

ยืนยันเวิร์กโหลด

เมื่อกลุ่มอินสแตนซ์ที่มีการจัดการ (MIG) เปิดใช้ VM แล้ว เราต้องยืนยันว่าเวิร์กโหลด Confidential Space ทำงานอย่างถูกต้อง

ซึ่งทำได้ผ่านคอนโซล Google Cloud หรือบรรทัดคำสั่ง

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

นอกจากนี้ คุณยังตรวจสอบเอาต์พุตพอร์ตอนุกรมของอินสแตนซ์นั้นๆ เพื่อดูบันทึกของเวิร์กโหลดได้ด้วย

# 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

การตั้งค่าการอัปเดตรูปภาพ

ในสภาพแวดล้อมการผลิต คุณต้องอัปเดตกลุ่มอินสแตนซ์ที่มีการจัดการ (MIG) เป็นประจำเพื่อจัดการกับ 2 สถานการณ์ที่แตกต่างกัน ดังนี้

การอัปเดตภาระงาน: การเผยแพร่โค้ดของแอปพลิเคชันเวอร์ชันใหม่ (เช่น การอัปเดต test_workload.py จาก v1 เป็น v2)
การอัปเดตโครงสร้างพื้นฐาน: Google ออกแพตช์ด้านความปลอดภัยหรืออัปเดตสำหรับระบบปฏิบัติการ Confidential Space ที่เป็นพื้นฐาน โปรดทราบว่าแนวทางปฏิบัติแนะนำคือการเลือกรูปภาพ CS ล่าสุดอย่างน้อยเดือนละครั้ง

เนื่องจากเรากำหนดค่าเทมเพลตอินสแตนซ์ด้วยลิงก์รูปภาพแบบไดนามิก (.../images/family/...) และแท็กคอนเทนเนอร์แบบไดนามิก (:latest) เราจึงจัดการกับสถานการณ์ทั้ง 2 อย่างนี้ได้ด้วยการดำเนินการ "แทนที่แบบต่อเนื่อง" เพียงครั้งเดียว ซึ่งจะช่วยให้กลุ่ม VM ทำงานด้วยสแต็กล่าสุดอยู่เสมอโดยไม่มีการหยุดทำงาน และไม่ต้องสร้างเทมเพลตอินสแตนซ์ใหม่สำหรับการเปลี่ยนแปลงเล็กๆ น้อยๆ ทุกครั้ง

สคริปต์การแทนที่แบบต่อเนื่อง

ในไดเรกทอรี update_images ให้ไปที่ update_images_script.sh สคริปต์นี้จะทริกเกอร์การแทนที่แบบโรลลิ่ง ซึ่งจะค่อยๆ ทำลายและสร้าง VM ทุกเครื่องในกลุ่มขึ้นใหม่

#!/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}"

สำหรับสคริปต์นี้ เราสามารถใช้การแทนที่แทนการรีสตาร์ทได้

รีสตาร์ทจะรีบูตเครื่อง โดยจะเก็บดิสก์ระบบปฏิบัติการที่มีอยู่ไว้ ซึ่งหมายความว่าจะไม่รับแพตช์ระบบปฏิบัติการใหม่
แทนที่จะลบ VM และสร้าง VM ใหม่จากเทมเพลต ซึ่งจะบังคับให้ระบบค้นหาอิมเมจระบบปฏิบัติการ Confidential Space ล่าสุดจากตระกูล รวมถึงดึงอิมเมจคอนเทนเนอร์ "ล่าสุด" จากรีจิสทรี

-max-surge=1: อนุญาตให้ MIG สร้าง VM เพิ่มเติม 1 รายการชั่วคราวเหนือขนาดเป้าหมาย โดยจะเปิด VM ใหม่ (ที่อัปเดตแล้ว) และรอให้ VM นั้นมีประสิทธิภาพดีก่อนที่จะลบ VM เก่า (ล้าสมัย)

–max-unavailable=0: เพื่อให้มั่นใจว่าไม่มีช่วงหยุดทำงาน ซึ่งจะแจ้งให้ MIG ทราบว่าไม่อนุญาตให้ปิดเครื่องใดๆ เว้นแต่จะมีการแทนที่ที่เพิ่มขึ้นสำเร็จแล้ว

สคริปต์การรีสตาร์ทแบบต่อเนื่อง

ในไดเรกทอรี update_images ยังมีสคริปต์อีกรายการหนึ่งชื่อ update_workload_image_script.sh สคริปต์นี้จะทริกเกอร์การรีสตาร์ทแบบต่อเนื่อง ซึ่งเป็นวิธีที่เร็วกว่าและใช้เพื่อรีเฟรชภาระงานโดยเฉพาะ เนื่องจาก Confidential Space ดึงอิมเมจคอนเทนเนอร์จากรีจิสทรีทุกครั้งที่บูต การรีสตาร์ทจึงเพียงพอที่จะอัปเดตแอปพลิเคชันเป็นเวอร์ชัน :latest โดยไม่ต้องเปลี่ยนแปลงโฮสต์พื้นฐาน

#!/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}"

ยืนยันเวิร์กโหลดที่อัปเดต

เราสามารถทดสอบ "การอัปเกรดด้วยคลิกเดียว" ได้โดยจำลองการเปิดตัวแอปพลิเคชันในโลกแห่งความเป็นจริง เราจะแก้ไขโค้ดภาระงาน พุชไปยัง Artifact Registry อัปเดต MIG และยืนยันว่าเวอร์ชันใหม่ทำงานโดยไม่มีการหยุดทำงาน

ขั้นตอนที่ 1: นำเวอร์ชันเวิร์กโหลดใหม่ไปใช้งาน

ก่อนอื่น เราต้องสร้างแอปพลิเคชันเวอร์ชัน "ใหม่"

เปิดไฟล์ test_workload.py ในเครื่อง
เปลี่ยนคำสั่งพิมพ์เวอร์ชันจาก print("Workload Version A") เป็น print("Workload Version B")
สร้างใหม่และพุชอิมเมจคอนเทนเนอร์ไปยัง Artifact Registry โดยเรียกใช้ create_workload.sh โปรดทราบว่าเราจะพุชไปยังแท็กเดียวกัน (:latest)

ขั้นตอนที่ 2: ดำเนินการอัปเดตแบบต่อเนื่อง

เรียกใช้สคริปต์การอัปเดตที่เราสร้างไว้ในส่วนก่อนหน้า ซึ่งจะบังคับให้ MIG แทนที่ VM ทุกเครื่องโดยดึงแฮชคอนเทนเนอร์ใหม่ที่เชื่อมโยงกับ :latest

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

รอให้สคริปต์ทำงานเสร็จ

ขั้นตอนที่ 3: ยืนยันการอัปเดตผ่านพอร์ตอนุกรม

เมื่อการอัปเดตเสร็จสมบูรณ์ เราจะยืนยันว่า VM ใหม่ใช้โค้ดที่อัปเดตแล้ว

# 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

ดูชื่ออินสแตนซ์ใหม่

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

ตรวจสอบบันทึก:

# 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

เมื่ออินสแตนซ์ทำงานแล้ว ให้เลือกชื่ออินสแตนซ์จากคำสั่ง gcloud ก่อนหน้าเพื่อดูพอร์ตอนุกรม

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

... ภาระงานเวอร์ชัน B ...

ขั้นตอนที่ 4: ยืนยันการกำหนดค่าโครงสร้างพื้นฐาน (ไม่บังคับ)

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

เรียกใช้คำสั่งต่อไปนี้เพื่อดูการอ้างอิงคอนเทนเนอร์แบบไดนามิก

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

ผลลัพธ์: คุณควรเห็นอิมเมจคอนเทนเนอร์ที่ลงท้ายด้วย :latest

ผลที่ตามมา: เนื่องจากเทมเพลตชี้ไปยังแท็ก ไม่ใช่แฮชที่เฉพาะเจาะจง การแทนที่การดำเนินการแบบต่อเนื่องทุกครั้งจึงดึงโค้ดล่าสุดที่คุณพุชในขั้นตอนที่ 1 ได้สำเร็จ

(ไม่บังคับ) การอัปเดตอัตโนมัติ

แม้ว่าการอัปเดตด้วยตนเองจะมีประโยชน์สำหรับการเผยแพร่เวอร์ชันหลัก แต่ในหลายๆ ครั้งคุณก็ต้องการให้กลุ่มเครื่องรับแพตช์ด้านความปลอดภัยล่าสุดหรือการสร้างการติดตั้งใช้งานปกติโดยอัตโนมัติโดยไม่ต้องมีการแทรกแซงจากมนุษย์

เราสามารถทำให้กระบวนการ "การแทนที่แบบต่อเนื่อง" เป็นแบบอัตโนมัติได้โดยการรวมสคริปต์การอัปเดตของเราไว้ในงาน Cloud Run สำหรับ Codelab นี้ เราจะเรียกใช้ทุกๆ 15 นาที ในสภาพแวดล้อมการใช้งานจริง ควรเรียกใช้ฟังก์ชันนี้น้อยครั้งกว่ามาก ผู้ใช้อาจกำหนดค่าเป็นรายสัปดาห์หรือรายเดือน ทั้งนี้ขึ้นอยู่กับความต้องการ

ขั้นตอนที่ 1: สร้างคอนเทนเนอร์สำหรับสคริปต์โปรแกรมอัปเดต

ก่อนอื่น เราต้องแพ็กเกจ update_images_script.sh (ซึ่งมีตรรกะ gcloud ... rolling-action replace) ลงในคอนเทนเนอร์ Docker เพื่อให้สคริปต์ทำงานในระบบคลาวด์ได้

เราได้เตรียมสคริปต์ตัวช่วยที่จะสร้างคอนเทนเนอร์นี้และพุชไปยัง Artifact Registry ของคุณ

เรียกใช้คำสั่งต่อไปนี้

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

การดำเนินการนี้จะทำสิ่งต่อไปนี้

โดยจะใช้ update_images_script.sh จากไดเรกทอรี update_images/
โดยจะสร้างอิมเมจ Docker ที่มี Google Cloud SDK และสคริปต์ของคุณ
โดยจะพุชอิมเมจไปยัง ${CURRENT_PROJECT_REGION}-docker.pkg.dev/${PROJECT_ID}/${REPOSITORY}/update-script:latest

ขั้นตอนที่ 2: นำไปใช้งานและกำหนดเวลางาน

ตอนนี้เราต้องบอก Google Cloud ให้เรียกใช้คอนเทนเนอร์นี้เป็นระยะๆ เราใช้ Cloud Run Jobs เพื่อเรียกใช้คอนเทนเนอร์และ Cloud Scheduler เพื่อทริกเกอร์

เรียกใช้สคริปต์การกำหนดค่าการจัดกำหนดการ

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

ภายในสคริปต์: สคริปต์นี้จะดำเนินการที่สำคัญ 2 อย่าง ได้แก่

สร้างงาน Cloud Run: กำหนดงานชื่อ mig-updater-job ที่เรียกใช้คอนเทนเนอร์ที่เราเพิ่งพุช
สร้างทริกเกอร์ของตัวกำหนดเวลา: ตั้งค่างาน Cloud Scheduler เพื่อเรียกใช้ Cloud Run Job API ทุกๆ 15 นาที

# (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}

ขั้นตอนที่ 3: ยืนยันการทำงานอัตโนมัติ

คุณไม่ต้องรอ 15 นาทีเพื่อทดสอบ คุณสามารถบังคับให้ตัวกำหนดเวลารันทันทีเพื่อยืนยันไปป์ไลน์ได้

บังคับเรียกใช้งาน:

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

ตรวจสอบการดำเนินการ: ไปที่คอนโซล Cloud Run > งาน คุณควรเห็นการดำเนินการใหม่เริ่มต้นขึ้น
ตรวจสอบ MIG: เรียกใช้ gcloud compute instance-groups managed list-instances ${CURRENT_MIG_NAME} คุณจะเห็นอินสแตนซ์เข้าสู่สถานะ RECREATING เมื่องานทริกเกอร์การอัปเดตทีละส่วน

ทำไมต้อง 15 นาที เราตั้งค่ากำหนดเวลาเป็น */15 * * * * สำหรับโค้ดแล็บนี้เพื่อให้คุณเห็นผลลัพธ์ได้อย่างรวดเร็ว ในสภาพแวดล้อมการผลิตจริง คุณอาจเปลี่ยนให้ทำงานทุกวัน (เช่น 0 3 * * * สำหรับเวลา 03:00 น.) หรือทุกสัปดาห์

8. ล้าง

สคริปต์การล้างข้อมูล cleanup.sh สามารถใช้เพื่อล้างข้อมูลทรัพยากรที่เราสร้างขึ้นเป็นส่วนหนึ่งของ Codelab นี้ การล้างข้อมูลนี้จะลบทรัพยากรต่อไปนี้

กลุ่มอินสแตนซ์ที่มีการจัดการ (${CURRENT_MIG_NAME}) และ VM พื้นฐาน
เทมเพลตอินสแตนซ์ (${TEMPLATE_NAME})
การตรวจสอบสถานะและกฎไฟร์วอลล์ (${HEALTH_CHECK_NAME})
ที่เก็บของ Artifact Registry (${REPOSITORY})
บัญชีบริการ (หากคุณสร้างบัญชีเฉพาะสำหรับ Lab นี้)

หากสำรวจเสร็จแล้ว โปรดพิจารณาลบโปรเจ็กต์โดยทำตามวิธีการปิด (ลบ) โปรเจ็กต์

ขอแสดงความยินดี

ยินดีด้วย คุณทำ Codelab เสร็จเรียบร้อยแล้ว

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

สิ่งต่อไปที่ควรทำ

ดู Codelab ของ Confidential Space เพิ่มเติมได้ที่

การรักษาความปลอดภัยของโมเดล ML และทรัพย์สินทางปัญญาโดยใช้ Confidential Space
วิธีทำธุรกรรมสำหรับเนื้อหาดิจิทัลด้วยการคำนวณแบบหลายฝ่ายและ Confidential Space
วิเคราะห์ข้อมูลที่เป็นความลับด้วย Confidential Space
ใช้ Confidential Space กับทรัพยากรที่ได้รับการปกป้องซึ่งไม่ได้จัดเก็บไว้กับผู้ให้บริการคลาวด์