نشر عبء عمل Confidential Space باستخدام مجموعات مثيلات مُدارة (MIG) من خلال التوسّع التلقائي والإصلاح الذاتي وتحديثات الصور

1. نظرة عامة

توفّر المساحة الآمنة (CS) بيئة آمنة ومشفّرة ومصدّقة لمعالجة البيانات الحسّاسة. يؤدي الاعتماد على مثيلات الأجهزة الافتراضية المستقلة إلى زيادة النفقات التشغيلية، لأنّ التنسيق اليدوي يفتقر إلى قابلية التوسّع اللازمة للخدمات البالغة الأهمية. بدون التنسيق الآلي، يصبح إجراء تحديثات متزامنة متتالية أو نشر صور جديدة لنظام التشغيل على مجموعة من الأجهزة أمرًا صعبًا من الناحية الفنية وعُرضةً لفترات التوقف.

في هذا الدرس التطبيقي حول الترميز، ستتعلّم كيفية نشر عبء عمل Confidential Space على مجموعة مثيلات مُدارة (MIG). ستتعرّف أيضًا على كيفية تفعيل ميزة الإصلاح الذاتي باستخدام عمليات التحقّق من الصحة، والتوسيع التلقائي استنادًا إلى استخدام وحدة المعالجة المركزية، والتحديثات المتجدّدة لكلّ من صور نظام التشغيل وأحمال العمل.

من المفترض أن تساعدك العمليات الموضّحة في هذا الدرس التطبيقي حول الترميز في إعداد مساحة Confidential Space آمنة وجاهزة للإنتاج من أجل عمليات النشر الطويلة الأمد والمهمة.

ما ستتعلمه

• كيفية إنشاء نموذج آلة افتراضية مخصّص لـ "المساحة الآمنة"
• كيفية استخدام Google Compute Engine وكيفية ضبط مجموعات المثيلات المُدارة ومجموعات المثيلات
• كيفية إنشاء قاعدة جدار الحماية وHealth Check لإصلاح المشاكل تلقائيًا
• كيفية إعداد مجموعة مثيلات مُدارة (MIG) على مستوى المنطقة باستخدام النموذج وعملية التحقّق من الصحة
• كيفية إعداد القياس التلقائي لمجموعة مثيلات مُدارة
• كيفية إعداد تحديثات صور نظام التشغيل بنقرة واحدة باستخدام البرمجة النصية على "مجموعات مثيلات مُدارة" لكلّ من صور أحمال العمل وإصدارات صور نظام التشغيل الجديدة في Confidential Space

المتطلبات

• مشروع Google Cloud تم تفعيل الفوترة فيه
• الإلمام بمحرّرات النصوص وعمليات نشر Docker وكتابة نصوص Bash البرمجية
• تم تثبيت أداة سطر أوامر gcloud ومصادقتها.
• فهم أساسي لخدمات Compute Engine وConfidential Space وإدارة الهوية وإمكانية الوصول وConfidential VMs وتكنولوجيا الحاويات والمستودعات البعيدة وحسابات الخدمة وCloud Run ونظام جدولة المهام في Cloud
• صورة حاوية لعبء عمل "مساحة آمنة" تم إنشاؤها ونقلها إلى Artifact Registry.

2. طريقة عمل ميزة "المساحة الآمنة" مع "المجموعات المتجاهلة للتعريف"

يؤدي استخدام مجموعة مثيلات مُدارة (MIG) لنشر عبء عمل في Confidential Space إلى جعل التطبيق الآمن أكثر قوة وقابلية للتوسيع وأسهل في التشغيل.

يتم تقسيم احتياجات الأمان والتشغيل لخدمة الإنتاج منطقيًا بين المكوّنين. توفّر ميزة "المساحة الآمنة" الأمان اللازم من خلال تشغيل حجم العمل في بيئة معزولة ومشفّرة ومصدَّقة للغاية تُعرف باسم "بيئة التنفيذ الموثوقة" (TEE). في المقابل، توفّر "مجموعات مثيلات مُدارة" إمكانات التشغيل الأساسية المطلوبة لتشغيل التطبيق الآمن على نطاق واسع، على غرار Kubernetes. تزيل المجموعات المدارة من مثيلات الأجهزة الافتراضية المخاطر الكامنة في تشغيل عبء عمل بالغ الأهمية على جهاز افتراضي واحد، والذي يمكن أن يكون بطيئًا أو عرضة للفشل. يضمن هذا المزيج حماية البيانات وموثوقية النظام. يضمن هذا الحل التوفّر العالي والإصلاح الذاتي لأنّ عبء العمل يتم تنفيذه على عدة أجهزة افتراضية في مجموعة. في حال تعذُّر إحدى الآلات الافتراضية، تظل الخدمة تعمل بكامل طاقتها بسبب موازنة التحميل وتوفُّر النسخ المتبقية.

بالإضافة إلى ذلك، تستخدم المجموعات المُدارة من المثيلات عمليات تحقّق قابلة للإعداد من الصحة لمراقبة الحالة التشغيلية للأجهزة الافتراضية باستمرار. إذا تبيّن أنّ إحدى الآلات الافتراضية غير سليمة، تستبدلها مجموعة مثيلات مُدارة (MIG) تلقائيًا بآلة افتراضية جديدة وسليمة، ما يضمن استمرار التشغيل.

توفّر مجموعات مثيلات مُدارة أيضًا قابلية توسيع فعّالة للمستخدمين من خلال ميزة التوسيع التلقائي. توفّر هذه الإمكانية طريقة تلقائية لإدارة السعة بدون تدخل يدوي، ما يلبي الحاجة إلى إضافة السعة أو إزالتها بمرونة استنادًا إلى الاستخدام.

أخيرًا، تتيح مجموعات مثيلات مُدارة (MIG) إجراء تحديثات بدون توقّف الخدمة من خلال التحديثات المتجدّدة. من المزايا الرئيسية إمكانية " الترقية بنقرة واحدة" لصورة نظام التشغيل الأساسية في Confidential Space أو صورة حاوية التطبيق (أو كليهما)، وكل ذلك بدون التسبّب في أي توقّف للخدمة. تتعامل مجموعة مثيلات مُدارة (MIG) مع هذا التغيير من خلال استبدال المثيلات القديمة تدريجيًا بمثيلات أحدث تعمل بالصورة المُحدَّثة، ما يضمن توفّرها باستمرار طوال عملية النشر. يُرجى العِلم أنّ تطبيقك قد يحتاج إلى أن يكون متوافقًا مع الأنظمة القديمة من أجل إتاحة هذا النوع من الترقية التدريجية.

3- إعداد موارد السحابة

قبل البدء

1. إعداد مشروع على Google Cloud لمزيد من المعلومات حول إنشاء مشروع على Google Cloud، يُرجى الرجوع إلى "درس تطبيقي حول الترميز لإعداد مشروعك الأول على Google واستخدامه". يمكنك الرجوع إلى مقالة إنشاء المشاريع وإدارتها للحصول على تفاصيل حول كيفية استرداد رقم تعريف المشروع وكيفية اختلافه عن اسم المشروع ورقمه.
2. فعِّل الفوترة لمشاريعك.
3. في إحدى مشاريع Google على Cloud Shell، اضبط متغيرات بيئة المشروع المطلوبة كما هو موضّح أدناه.

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

4. فعِّل واجهة Confidential Computing 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

5. في مشروعك على Google Cloud Cloud Shell، استنسِخ مستودع Confidential Space Codelab على GitHub، واستخدِم الأمر أدناه للحصول على النصوص البرمجية المناسبة اللازمة لإكمال هذا الدرس العملي.

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

6. تغيير الدليل إلى دليل البرامج النصية لبرنامج codelab الخاص بمجموعة المثيلات

cd confidential-space/codelabs/mig_cs_codelab/scripts

7. عدِّل سطر رقم تعريف المشروع في ملف config_env.sh ليتوافق مع رقم تعريف المشروع الذي اخترته.
8. اضبط أي متغيرات سبق إنشاؤها. تجاوز أسماء الموارد باستخدام هذه المتغيرات

• يمكنك ضبط المتغيّرات التالية باستخدام أسماء موارد السحابة الإلكترونية الحالية. في حال تم ضبط المتغيّر، سيتم استخدام مراجع السحابة الإلكترونية الحالية المطابقة من المشروع. في حال عدم ضبطها، سيتم الحصول على اسم مورد السحابة الإلكترونية من البرنامج النصي config_env.sh.

9. شغِّل النص البرمجي config_env.sh لضبط أسماء المتغيرات المتبقية لهذا المشروع على قيم استنادًا إلى رقم تعريف المشروع لأسماء الموارد.

source config_env.sh

10. أضِف أذونات للمشروع. يمكن إضافة الأذونات باتّباع التفاصيل الواردة في صفحة الويب الخاصة بمنح دور في "إدارة الهوية وإمكانية الوصول".

ستحتاج إلى الأذونات التالية لهذا المشروع

• كاتب Artifact Registry
• مشرف Cloud Scheduler
• موظف دعم خدمة Compute
• مستخدم أحمال عمل الحوسبة السرية
• كاتب السجلّات
• مطوّر Cloud Run
• 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'

11. الاطّلاع على test_workload.py

• تحقَّق من ناتج وحدة العمل من خلال مراجعة رمز المصدر، إذ من المفترض أن يطبع ببساطة الإصدار الحالي من وحدة العمل.
• عندما ننقل عبء العمل إلى CS للمرة الأولى ونتحقّق من الناتج، من المفترض أن تظهر لنا "الإصدار A" مطبوعة.

4. إعداد "حمل العمل"

عليك أولاً إنشاء صورة Docker لحجم المعالجة المستخدَم في هذا الدرس التطبيقي حول الترميز. حِمل العمل هو نص برمجي بسيط يطبع إصدار حِمل العمل الذي يتم تشغيله حاليًا. ستتم طباعة رسالة تفيد بأنّ عبء العمل قد بدأ، ثم طباعة إصدار عبء العمل، ثم الانتظار لمدة 5 ثوانٍ، ثم طباعة رسالة تفيد بأنّ عبء العمل قد انتهى.

خطوات إنشاء عبء عمل

1. نفِّذ create_workload.sh لإنشاء عبء العمل. يعمل هذا النص البرمجي على:

• ينشئ هذا الأمر مستودع Artifact Registry مملوكًا للمشروع الذي سيتم نشر عبء العمل فيه.
• تنشئ هذه الخطوة الرمز وتجمّعه في صورة Docker. يمكنك الاطّلاع على إعدادات ملف Dockerfile المرتبط للحصول على مزيد من المعلومات.
• ينشر صورة Docker إلى Artifact Registry التي يملكها المشروع
• يمنح حساب الخدمة <your service account name> أذونات القراءة لسجلّ القطع الأثرية <artifact registry repo name>

5- إعداد نموذج آلة افتراضية ومجموعة مثيلات مُدارة

خطوات إنشاء نموذج آلة افتراضية

يجب أولاً إنشاء نموذج آلة افتراضية. هذا النموذج هو المخطط المطلوب الذي ستستخدمه "مجموعة المثيلات المُدارة" (MIG) لتوفير أحمال العمل وتشغيلها ضمن Confidential Space.

يُعدّ نموذج الجهاز الافتراضي ضروريًا لأنّه يحدّد جميع المَعلمات المتخصّصة:

• نوع الجهاز: في هذا المثال، نستخدم نوع جهاز Confidential VM (مثل n2d-standard-2) الذي يتوافق مع تكنولوجيا الحوسبة السرية AMD SEV (--confidential-compute-type=SEV).
• صورة نظام التشغيل للجهاز الافتراضي: نستخدِم مشروع confidential-space-images ومجموعة صور confidential-space-debug للحصول على أحدث صورة لنظام التشغيل في Confidential Space.
• ملاحظة: نستخدم صورة تصحيح الأخطاء في هذا الدليل لتسهيل عملية تحديد المشاكل وحلّها. على عكس صورة الإصدار العلني، يبقي إصدار تصحيح الأخطاء الجهاز الظاهري قيد التشغيل بعد انتهاء عبء العمل ويسمح بالوصول إلى SSH لإجراء الاختبار. بالنسبة إلى عمليات النشر في بيئة الإنتاج التي تستخدم بيانات حساسة من الواقع، عليك التبديل إلى مجموعة صور بيئة الإنتاج.
• مرجع عبء العمل: يحتوي سطر المطلوب tee-image-reference في البيانات الوصفية على صورة الحاوية المحدّدة (عبء عمل تطبيقك) التي سيتم تشغيلها على الجهاز الافتراضي في Confidential Space.

يضمن هذا الإعداد أنّ كل جهاز افتراضي تم إنشاؤه بواسطة مجموعة مثيل مُدارة هو Confidential Space تم إعداده بشكلٍ صحيح وجاهز لتنفيذ عبء العمل.

خطوات إنشاء مجموعة مثيلات مُدارة

تتمثل الخطوة التالية في إنشاء مجموعة مثيلات مُدارة (MIG) باستخدام النموذج الذي حدّدته للتو. تُعدّ مجموعة مثيلات مُدارة (MIG) ضرورية لأنّها تعمل على أتمتة عملية نشر وإدارة وتوسيع نطاق عدة أجهزة افتراضية متطابقة.

يحقّق النص البرمجي create_launch_mig.sh ثلاثة أهداف رئيسية:

1. إنشاء MIG

• الأمر: gcloud compute instance-groups managed create ${CURRENT_MIG_NAME}
• الغرض: ينشئ هذا الأمر المجموعة التي ستدير الأجهزة الافتراضية.
• ‫--size 3: تحدّد هذه السمة أنّ مجموعة مثيلات مُدارة (MIG) يجب أن تنشئ في البداية 3 مثيلات من عبء العمل وتحافظ عليها.
• --template ${TEMPLATE_NAME}: من المهم الإشارة إلى "نموذج الجهاز الافتراضي" الذي تم إنشاؤه سابقًا، ما يضمن ضبط جميع الأجهزة الافتراضية الثلاثة على أنّها أجهزة Confidential Space الافتراضية التي تشغّل حاوية مهام العمل المحدّدة tee-image-reference.
• ‫--zone ${CURRENT_PROJECT_ZONE}: تحدّد هذه السمة موقع النشر للآلات الافتراضية.

2. استرداد رقم المشروع

• الأمر: PROJECT_NUMBER=$(gcloud projects describe ${PROJECT_ID} --format="value(projectNumber)")
• الغرض: يسترد النص البرمجي الرقم التعريفي لمشروعك. وغالبًا ما يكون هذا الرقم مطلوبًا لإنشاء أدوار وأذونات حساب الخدمة، خاصةً لوكلاء الخدمة المُدارة من Google.

3. منح أذونات "إدارة الهوية وإمكانية الوصول"

• الأمر: gcloud projects add-iam-policy-binding --role="roles/compute.serviceAgent"
• الغرض: تمنح هذه الخطوة دور وكيل خدمة Compute Engine لحساب الخدمة الخاص بعبء العمل (${SERVICE_ACCOUNT}). هذا الإذن مهم لأنّه يسمح لحساب الخدمة بالتصرف نيابةً عن خدمة Compute Engine في المشروع، وهو أمر ضروري غالبًا للميزات المبرمَجة في مجموعة مثيلات مُدارة، مثل إدارة المثيلات وإعداد الشبكات والتفاعل مع خدمات 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}

إعداد ميزة "القياس التلقائي"

سنضبط المجموعة لتوسيع نطاقها تلقائيًا بين مثيل واحد و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) الأجهزة الافتراضية، علينا التأكّد من أنّ عبء عمل Confidential Space يعمل بشكل صحيح.

يمكنك إجراء ذلك من خلال Google Cloud Console أو سطر الأوامر.

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) بانتظام للتعامل مع سيناريوهَين مختلفَين:

1. تعديلات على أحمال العمل: إصدار نسخة جديدة من الرمز البرمجي لتطبيقك (مثل تعديل test_workload.py من الإصدار 1 إلى الإصدار 2)
2. تحديثات البنية الأساسية: إصدار Google لرمز تصحيح أمان أو تحديث لنظام التشغيل الأساسي في "المساحة الآمنة" يُرجى العِلم أنّ من أفضل الممارسات الحصول على أحدث صورة من "خدمة التوافق" مرة واحدة على الأقل شهريًا.

بما أنّنا ضبطنا "نموذج الجهاز الافتراضي" باستخدام رابط صورة ديناميكي (.../images/family/...) وعلامة حاوية ديناميكية (:latest)، يمكننا التعامل مع كلتا هاتين الحالتين من خلال عملية "استبدال متتابع" واحدة. يضمن ذلك أنّ مجموعة الأجهزة الافتراضية تعمل دائمًا بأحدث حزمة بدون أي وقت تعطل وبدون الحاجة إلى إنشاء "نموذج آلة افتراضية" جديد لكل تغيير بسيط.

The Rolling Replace Script

ضمن الدليل update_images، انتقِل إلى update_images_script.sh. يؤدي هذا النص البرمجي إلى تشغيل استبدال متواصل، ما يؤدي إلى إيقاف كل آلة افتراضية في المجموعة وإعادة إنشائها تدريجيًا.

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

بالنسبة إلى هذا النص البرمجي، يمكننا استخدام "استبدال" بدلاً من "إعادة التشغيل".

• تؤدي عملية إعادة التشغيل إلى إعادة تشغيل الجهاز. ويحتفظ بقرص نظام التشغيل الحالي، ما يعني أنّه لن يختار تصحيحات نظام التشغيل الجديدة.
• يؤدي إجراء استبدال إلى حذف الجهاز الظاهري وإنشاء جهاز جديد من النموذج. يؤدي ذلك إلى إجبار النظام على البحث عن أحدث نسخة نظام تشغيل في "المساحة الآمنة" من العائلة، بالإضافة إلى سحب صورة الحاوية "الأحدث" من السجلّ.

‎--max-surge=1: يتيح ذلك لمجموعة المثيلات المُدارة إنشاء جهاز افتراضي إضافي واحد مؤقتًا فوق الحجم المستهدف. تنشئ هذه السياسة آلة افتراضية جديدة (محدّثة) وتنتظر إلى أن تصبح سليمة قبل أن تحذف آلة افتراضية قديمة (منتهية الصلاحية).

‎–max-unavailable=0: يضمن هذا الخيار عدم توقّف الخدمة. ويشير إلى أنّ غير مسموح بإيقاف أي جهاز إلا إذا تمّت زيادة عدد الأجهزة البديلة بنجاح.

نص إعادة التشغيل المتكرّر

ضمن الدليل update_images، يتوفّر أيضًا نص برمجي آخر باسم update_workload_image_script.sh. يؤدي هذا النص البرمجي إلى تشغيل إعادة التشغيل المتتالية، وهي طريقة أسرع تُستخدم فقط لإعادة تحميل عبء العمل. بما أنّ ميزة "المساحة الآمنة" تسحب صورة الحاوية من السجلّ في كل عملية تشغيل، تكفي إعادة التشغيل لتحديث تطبيقك إلى الإصدار :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: نشر إصدار جديد من عبء العمل

أولاً، علينا إنشاء إصدار "جديد" من تطبيقك.

1. افتح ملف test_workload.py المحلي.
2. غيِّر عبارة طباعة الإصدار من print("Workload Version A") إلى print("Workload Version B")
3. أعِد إنشاء صورة الحاوية وادفعها إلى Artifact Registry من خلال تنفيذ create_workload.sh. يُرجى العِلم أنّنا نرسل إلى العلامة نفسها (:latest).

الخطوة 2: تنفيذ التحديث المتتالي

نفِّذ نص التعديل الذي أنشأناه في القسم السابق. سيؤدي ذلك إلى إجبار مجموعة مثيلات مُدارة (MIG) على استبدال كل جهاز افتراضي، واسترداد تجزئة الحاوية الجديدة المرتبطة بـ :latest.

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

انتظِر إلى أن يكتمل النص البرمجي

الخطوة 3: إثبات صحة التحديث عبر منفذ تسلسلي

بعد اكتمال عملية التحديث، نتحقّق من أنّ الأجهزة الافتراضية الجديدة تشغّل الرمز المعدَّل.

# 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 السابق لعرض منفذ التسلسل الخاص به.

النتيجة المتوقّعة: من المفترض أن تظهر لك رسالة السجلّ المعدَّلة التي تؤكّد نجاح عملية النشر:

... Workload Version B ...

الخطوة 4: التحقّق من إعدادات البنية الأساسية (اختيارية)

يمكنك أيضًا التأكّد من أنّ "نموذج الجهاز الافتراضي" تم إعداده بشكل صحيح لجلب التحديثات الديناميكية لكلّ من نظام التشغيل وعبء العمل من خلال فحص البيانات الوصفية.

نفِّذ الأمر التالي للاطّلاع على مرجع الحاوية الديناميكية:

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

النتيجة: من المفترض أن تظهر صورة الحاوية التي تنتهي بـ ‎ :latest.

• النتيجة: بما أنّ النموذج يشير إلى العلامة وليس إلى قيمة تجزئة معيّنة، فإنّ كل عملية استبدال متكرّرة تجلب بنجاح أحدث رمز أضفته في الخطوة 1.

(اختياري) التحديثات التلقائية

في حين أنّ التحديثات اليدوية مفيدة لإصدارات رقم الإصدار الرئيسي، غالبًا ما تريد أن تتلقّى أسطول أجهزتك تلقائيًا آخر رموز تصحيح الأمان أو إصدارات التفعيل العادية بدون تدخل بشري.

يمكننا تنفيذ عملية "الاستبدال المتتالي" تلقائيًا من خلال تجميع نص برمجي للتحديث في مهمة Cloud Run. في هذا الدرس العملي، سنفعِّلها كل 15 دقيقة. في بيئة الإنتاج، يجب تشغيلها بمعدّل أقل بكثير. واستنادًا إلى احتياجات المستخدم، يمكنه ضبطها على أساس أسبوعي أو شهري.

الخطوة 1: إنشاء حاوية للبرنامج النصي الخاص بأداة التحديث

أولاً، علينا تجميع update_images_script.sh (الذي يحتوي على منطق الاستبدال gcloud ... rolling-action) في حاوية 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 لتنفيذ الحاوية وCloud Scheduler لتشغيلها.

نفِّذ نص برمجة إعدادات الجدولة:

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

داخل النص البرمجي: ينفّذ هذا النص البرمجي إجراءَين مهمَّين:

1. إنشاء مهمة Cloud Run: يحدّد هذا القسم مهمة باسم mig-updater-job تنفّذ الحاوية التي تم تحميلها للتو.
2. إنشاء مشغّل Scheduler: يتم إعداد مهمة Cloud Scheduler لتفعيل واجهة برمجة تطبيقات Cloud Run Job كل 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 دقيقة لاختبارها. يمكنك فرض تشغيل أداة الجدولة على الفور للتحقّق من صحة مسار البيانات.

1. فرض تنفيذ المهمة:

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

2. التحقّق من التنفيذ: انتقِل إلى وحدة تحكّم Cloud Run > المهام. من المفترض أن تظهر لك عملية تنفيذ جديدة تبدأ.
3. التحقّق من مجموعة مثيلات مُدارة (MIG): شغِّل الأمر gcloud compute instance-groups managed list-instances ${CURRENT_MIG_NAME}. ستظهر لك المثيلات التي تنتقل إلى الحالة RECREATING عندما تشغّل المهمة التحديث المتداول.

لماذا 15 دقيقة؟ لقد ضبطنا الجدول على ‎ */15 * * * * في هذا الدرس التطبيقي حول الترميز حتى تتمكّن من الاطّلاع على النتائج بسرعة. في بيئة إنتاج حقيقية، من المحتمل أن تغيّر هذا الإعداد ليتم تنفيذه يوميًا (مثلاً، 0 3 * * * في الساعة 3 صباحًا) أو أسبوعيًا.

8. تنظيف

يمكن استخدام البرنامج النصي cleanup.sh لتنظيف الموارد التي أنشأناها كجزء من هذا الدرس التطبيقي حول الترميز. وكجزء من عملية التنظيف هذه، سيتم حذف الموارد التالية:

• مجموعة مثيلات مُدارة (${CURRENT_MIG_NAME}) وآلاتها الافتراضية الأساسية
• نموذج الجهاز الظاهري (${TEMPLATE_NAME})
• فحص السلامة وقواعد جدار الحماية (${HEALTH_CHECK_NAME})
• مستودع Artifact Registry‏ (${REPOSITORY})
• حساب الخدمة (إذا أنشأت حسابًا مخصّصًا لهذا المختبر)

إذا انتهيت من استكشاف الميزات، يُرجى حذف مشروعك باتّباع التعليمات التالية: إيقاف المشاريع (حذفها).

تهانينا

تهانينا، لقد أكملت الدرس التطبيقي حول الترميز بنجاح.

تعرّفت على كيفية توسيع نطاق أحمال عمل Confidential Space بشكل آمن باستخدام "مجموعات مثيلات مُدارة" (MIG). لقد نجحت في إعداد الإصلاح الذاتي للتعافي من حالات الأعطال، والتوسيع التلقائي للتعامل مع الارتفاعات المفاجئة في عدد الزيارات، وأجريت تحديثات بدون توقّف لكلّ من صورة نظام التشغيل في Confidential Space وحاوية عبء العمل.

ما هي الخطوات التالية؟

اطّلِع على دروس تطبيقية حول الترميز إضافية عن Confidential Space:

• تأمين نماذج تعلُّم الآلة والملكية الفكرية باستخدام خدمة Confidential Space
• كيفية إجراء معاملات الأصول الرقمية باستخدام تقنيتَي Multi-Party Computation وConfidential Space
• تحليل البيانات السرية باستخدام Confidential Space
• استخدام Confidential Space مع موارد محمية غير مخزَّنة لدى مقدّم خدمات السحابة الإلكترونية

Further reading

• توسيع النطاق استنادًا إلى مقاييس المراقبة
• هل تشعر بالعزلة؟ الحوسبة السرية لحلّ المشكلة
• الحوسبة السرية في Google Cloud Platform
• ميزة "مساحة للبيانات السرية": مستقبل التعاون الذي يحافظ على الخصوصية
• نظرة عامة على أمان "مساحة للبيانات السرية"
• تعزيز خصوصية البيانات: التعاون المراعي للخصوصية بين عدة جهات على نطاق واسع