ऑटोसकेलिंग, ऑटोहीलिंग, और इमेज अपडेट करने की सुविधाओं का इस्तेमाल करके, MIG के साथ कॉन्फ़िडेंशियल स्पेस वर्कलोड डिप्लॉय करना

1. खास जानकारी

कॉन्फ़िडेंशियल स्पेस (सीएस), संवेदनशील डेटा को प्रोसेस करने के लिए सुरक्षित, पुष्टि किया गया, और एन्क्रिप्ट (सुरक्षित) किया गया एनवायरमेंट उपलब्ध कराता है. स्टैंडअलोन वीएम इंस्टेंस पर भरोसा करने से ऑपरेशनल ओवरहेड बढ़ता है. ऐसा इसलिए होता है, क्योंकि मैन्युअल ऑर्केस्ट्रेशन में मिशन क्रिटिकल सेवाओं के लिए ज़रूरी स्केलेबिलिटी नहीं होती. ऑटोमेटेड ऑर्केस्ट्रेशन के बिना, एक साथ रोलिंग अपडेट करना या पूरे फ्लीट में नई ओएस इमेज डिप्लॉय करना तकनीकी तौर पर मुश्किल हो जाता है. साथ ही, इससे डाउनटाइम की समस्या भी हो सकती है.

इस कोडलैब में, आपको मैनेज किए गए इंस्टेंस ग्रुप (एमआईजी) पर Confidential Space वर्कलोड को डिप्लॉय करने का तरीका बताया जाएगा. आपको यह भी पता चलेगा कि हेल्थ चेक, सीपीयू के इस्तेमाल के आधार पर अपने-आप स्केल होने की सुविधा, और ओएस इमेज और वर्कलोड, दोनों के लिए रोलिंग अपडेट का इस्तेमाल करके, ऑटोहीलिंग की सुविधा कैसे चालू करें=.

इस कोडलैब में दिखाई गई प्रोसेस से, आपको मिशन-क्रिटिकल और लंबे समय तक चलने वाले डिप्लॉयमेंट के लिए, प्रोडक्शन के लिए तैयार और सुरक्षित कॉन्फ़िडेंशियल स्पेस सेट अप करने में मदद मिलेगी.

आपको क्या सीखने को मिलेगा

• कॉन्फ़िडेंशियल स्पेस के लिए, खास इंस्टेंस टेंप्लेट बनाने का तरीका.
• Google Compute Engine का इस्तेमाल करने का तरीका और एमआईजी और इंस्टेंस ग्रुप को कॉन्फ़िगर करने का तरीका
• ऑटोहीलिंग के लिए फ़ायरवॉल का नियम और हेल्थ चेक कैसे बनाएं.
• टेंप्लेट और हेल्थ चेक की मदद से, ज़ोनल एमआईजी को कॉन्फ़िगर करने का तरीका.
• एमआईजी के लिए ऑटोस्केलिंग की सुविधा कैसे सेट अप करें.
• MIG पर स्क्रिप्टिंग का इस्तेमाल करके, एक क्लिक में ओएस इमेज अपडेट करने की सुविधा कैसे सेट अप करें. इसका इस्तेमाल, वर्कलोड इमेज के साथ-साथ Confidential Space के लिए ओएस इमेज की नई रिलीज़ के लिए भी किया जा सकता है

आपको इन चीज़ों की ज़रूरत होगी

• बिलिंग की सुविधा वाला Google Cloud प्रोजेक्ट.
• टेक्स्ट एडिटर, Docker डिप्लॉयमेंट, और बैश स्क्रिप्टिंग के बारे में जानकारी होना
• gcloud कमांड-लाइन टूल इंस्टॉल किया गया हो और उसकी पुष्टि की गई हो.
• Compute Engine, Confidential Space, IAM, Confidential VMs, कंटेनर टेक्नोलॉजी, रिमोट रिपॉज़िटरी, सेवा खाते, Cloud Run, और Cloud Scheduler के बारे में बुनियादी जानकारी
• कॉन्फ़िडेंशियल स्पेस के वर्कलोड कंटेनर की इमेज पहले से ही बनाई गई हो और उसे Artifact Registry में पुश किया गया हो.

2. एमआईजी के साथ कॉन्फ़िडेंशियल स्पेस की सुविधा कैसे काम करती है

कॉन्फ़िडेंशियल स्पेस के वर्कलोड को डिप्लॉय करने के लिए मैनेज किए गए इंस्टेंस ग्रुप (एमआईजी) का इस्तेमाल करने से, सुरक्षित ऐप्लिकेशन ज़्यादा मज़बूत, आसानी से बढ़ाया जा सकने वाला, और इस्तेमाल में आसान हो जाता है.

सुरक्षा और ऑपरेशन से जुड़ी प्रोडक्शन सेवा की ज़रूरतों को, इन दोनों कॉम्पोनेंट के बीच तार्किक रूप से बांटा जाता है. कॉन्फ़िडेंशियल स्पेस, ज़रूरी सुरक्षा उपलब्ध कराता है. इसके लिए, यह वर्कलोड को एक अलग, एन्क्रिप्ट (सुरक्षित) किए गए, और प्रमाणित एनवायरमेंट में चलाता है. इसे ट्रस्टेड एक्ज़ीक्यूशन एनवायरमेंट (टीईई) कहा जाता है. इसके उलट, एमआईजी, Kubernetes की तरह ही बड़े पैमाने पर सुरक्षित ऐप्लिकेशन चलाने के लिए ज़रूरी ऑपरेशनल सुविधाएं उपलब्ध कराते हैं. एमआईजी, किसी एक वीएम पर मिशन-क्रिटिकल वर्कलोड चलाने से जुड़े जोखिमों को कम करते हैं. ऐसा इसलिए, क्योंकि एक वीएम धीमा हो सकता है या उसमें गड़बड़ी हो सकती है. इन दोनों को साथ में इस्तेमाल करने से, डेटा को सुरक्षित रखने और सिस्टम को भरोसेमंद बनाने में मदद मिलती है. इस समाधान से ज़्यादा उपलब्धता और अपने-आप ठीक होने की सुविधा मिलती है. ऐसा इसलिए होता है, क्योंकि वर्कलोड एक पूल में मौजूद कई वीएम पर चलता है. अगर कोई वीएम क्रैश हो जाता है, तो लोड बैलेंसिंग और बचे हुए इंस्टेंस की वजह से सेवा पूरी तरह से काम करती रहती है.

इसके अलावा, MIG, वीएम की चालू स्थिति को लगातार मॉनिटर करने के लिए कॉन्फ़िगर की जा सकने वाली हेल्थ चेक का इस्तेमाल करते हैं. अगर किसी इंस्टेंस में कोई समस्या मिलती है, तो एमआईजी उसे अपने-आप एक नए और सही वीएम से बदल देता है. इससे यह पक्का होता है कि इंस्टेंस लगातार काम करता रहे.

एमआईजी, ऑटोसकेलिंग की सुविधा के साथ उपयोगकर्ताओं के लिए बेहतर स्केलेबिलिटी भी उपलब्ध कराते हैं. इस सुविधा की मदद से, मैन्युअल तरीके से कार्रवाई किए बिना क्षमता को अपने-आप मैनेज किया जा सकता है. साथ ही, इस्तेमाल के आधार पर क्षमता को आसानी से जोड़ा या हटाया जा सकता है.

आखिर में, MIG, रोलिंग अपडेट की मदद से बिना किसी रुकावट के अपडेट करने की सुविधा देते हैं. इसका एक मुख्य फ़ायदा यह है कि Confidential Space OS की इमेज या ऐप्लिकेशन की कंटेनर इमेज (या दोनों) को " एक क्लिक में अपग्रेड" किया जा सकता है. इसके लिए, सेवा को बंद करने की ज़रूरत नहीं पड़ती. एमआईजी, इस बदलाव को मैनेज करता है. इसके लिए, वह पुराने इंस्टेंस को धीरे-धीरे नए इंस्टेंस से बदलता है. नए इंस्टेंस में अपडेट की गई इमेज दिखती है. इससे यह पक्का होता है कि डिप्लॉयमेंट के दौरान, इमेज लगातार उपलब्ध रहे. ध्यान दें कि इस तरह के क्रमिक अपग्रेड के लिए, आपके ऐप्लिकेशन को पिछले वर्शन के साथ काम करने वाला होना चाहिए.

3. क्लाउड रिसॉर्स सेट अप करना

शुरू करने से पहले

1. Google Cloud प्रोजेक्ट सेट अप करें. Google Cloud प्रोजेक्ट बनाने के बारे में ज़्यादा जानने के लिए, कृपया "Set up and navigate your first Google project" codelab देखें. प्रोजेक्ट आईडी को वापस पाने का तरीका जानने के लिए, प्रोजेक्ट बनाना और मैनेज करना लेख पढ़ें. साथ ही, यह भी जानें कि प्रोजेक्ट आईडी, प्रोजेक्ट के नाम और प्रोजेक्ट नंबर से कैसे अलग होता है.
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 Repository को क्लोन करें. इसके बाद, इस कोडलैब को पूरा करने के लिए ज़रूरी स्क्रिप्ट पाने के लिए, यहां दिया गया कमांड इस्तेमाल करें.

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

6. डायरेक्ट्री को बदलकर, इंस्टेंस ग्रुप के कोडलैब के लिए स्क्रिप्ट डायरेक्ट्री पर जाएं

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. प्रोजेक्ट के लिए अनुमतियां जोड़ें. अनुमतियां जोड़ने के लिए, किसी IAM भूमिका को अनुमति दें वेबपेज पर दी गई जानकारी का पालन करें.

इस प्रोजेक्ट के लिए, आपके पास ये अनुमतियां होनी चाहिए

• Artifact Registry लेखक
• Cloud Scheduler एडमिन
• Compute Service Agent
• Confidential Computing Workload User
• लॉग राइटर
• 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 देखें

• सोर्स कोड की समीक्षा करके, वर्कलोड के आउटपुट की पुष्टि करें. इसमें वर्कलोड का मौजूदा वर्शन प्रिंट होना चाहिए
• जब हम पहली बार अपने वर्कलोड को सीएस पर पुश करते हैं और आउटपुट की जांच करते हैं, तो हमें "वर्शन A" प्रिंट किया हुआ दिखना चाहिए

4. वर्कलोड सेट अप करना

आपको सबसे पहले, इस कोडलैब में इस्तेमाल किए गए वर्कलोड के लिए Docker इमेज बनानी होगी. वर्कलोड एक सामान्य स्क्रिप्ट है. यह उस वर्कलोड का वर्शन प्रिंट करती है जिसे फ़िलहाल चलाया जा रहा है. यह प्रिंट करेगा कि वर्कलोड शुरू हो रहा है. इसके बाद, वर्कलोड का वर्शन प्रिंट करेगा. फिर, पांच सेकंड तक स्लीप मोड में रहेगा. इसके बाद, यह प्रिंट करेगा कि वर्कलोड खत्म हो गया है.

वर्कलोड बनाने का तरीका

1. वर्कलोड बनाने के लिए, create_workload.sh स्क्रिप्ट चलाएं. यह स्क्रिप्ट:

• यह उस प्रोजेक्ट के मालिकाना हक वाला Artifact Registry बनाता है जहां वर्कलोड पब्लिश किया जाएगा
• यह कोड बनाता है और उसे डॉकर इमेज में पैकेज करता है. ज़्यादा जानकारी के लिए, इससे जुड़ा dockerfile कॉन्फ़िगरेशन देखें.
• यह Docker इमेज को प्रोजेक्ट के मालिकाना हक वाले Artifact Registry में पब्लिश करता है
• इस कमांड से, सेवा खाते <your service account name> को आर्टफ़ैक्ट रजिस्ट्री <artifact registry repo name> के लिए पढ़ने की अनुमतियां मिलती हैं

5. इंस्टेंस टेंप्लेट और एमआईजी सेट अप करना

इंस्टेंस टेंप्लेट बनाने का तरीका

आपको सबसे पहले इंस्टेंस टेंप्लेट बनाना होगा. यह टेंप्लेट, ज़रूरी ब्लूप्रिंट है. मैनेज किया गया इंस्टेंस ग्रुप (एमआईजी), इसका इस्तेमाल कॉन्फ़िडेंशियल स्पेस में आपके वर्कलोड को चालू करने और चलाने के लिए करेगा.

इंस्टेंस टेंप्लेट ज़रूरी है, क्योंकि यह सभी खास पैरामीटर तय करता है:

• मशीन टाइप: इस उदाहरण में, हम Confidential VM मशीन टाइप (जैसे, n2d-standard-2) का इस्तेमाल करते हैं. यह AMD SEV की गोपनीय कंप्यूटिंग टेक्नोलॉजी (--confidential-compute-type=SEV) के साथ काम करता है.
• वीएम ओएस इमेज: हम confidential-space-images प्रोजेक्ट और confidential-space-debug इमेज फ़ैमिली का इस्तेमाल करके, Confidential Space के ऑपरेटिंग सिस्टम की नई इमेज को पुल करते हैं.
• ध्यान दें: इस गाइड में, हम डीबग इमेज का इस्तेमाल करते हैं, ताकि समस्या हल करने में आसानी हो. प्रोडक्शन इमेज के उलट, डीबग वर्शन में वर्कलोड पूरा होने के बाद भी वीएम चालू रहता है. साथ ही, इसमें टेस्टिंग के लिए एसएसएच ऐक्सेस की अनुमति मिलती है. असल दुनिया के संवेदनशील डेटा का इस्तेमाल करके प्रोडक्शन डिप्लॉयमेंट के लिए, आपको प्रोडक्शन इमेज फ़ैमिली पर स्विच करना होगा.
• वर्कलोड का रेफ़रंस: मेटाडेटा में मौजूद ज़रूरी tee-image-reference लाइन में, वह कंटेनर इमेज (आपके ऐप्लिकेशन का वर्कलोड) शामिल होती है जिसे कॉन्फ़िडेंशियल स्पेस वीएम लॉन्च करेगा.

इस सेटअप से यह पक्का होता है कि MIG से बनाया गया हर वीएम, कॉन्फ़िडेंशियल स्पेस के तौर पर सही तरीके से कॉन्फ़िगर किया गया है. साथ ही, यह आपके वर्कलोड को एक्ज़ीक्यूट करने के लिए तैयार है.

मैनेज किए गए इंस्टेंस ग्रुप बनाने का तरीका

अगला चरण, अभी तय किए गए टेंप्लेट का इस्तेमाल करके मैनेज किया गया इंस्टेंस ग्रुप (एमआईजी) बनाना है. एमआईजी ज़रूरी है, क्योंकि यह एक जैसे कई वीएम को डिप्लॉय करने, मैनेज करने, और स्केल करने की प्रोसेस को अपने-आप पूरा करता है.

create_launch_mig.sh स्क्रिप्ट से ये तीन मुख्य काम किए जाते हैं:

1. एमआईजी बनाएं

• निर्देश: gcloud compute instance-groups managed create ${CURRENT_MIG_NAME}
• मकसद: इस कमांड से ऐसा ग्रुप बनता है जो आपके वीएम को मैनेज करेगा.
• --size 3: इससे पता चलता है कि MIG को शुरू में आपके वर्कलोड के तीन इंस्टेंस बनाने और उन्हें बनाए रखने चाहिए.
• --template ${TEMPLATE_NAME}: सबसे अहम बात यह है कि यह पहले बनाए गए इंस्टेंस टेंप्लेट का रेफ़रंस देता है. इससे यह पक्का होता है कि तीनों इंस्टेंस, कॉन्फ़िडेंशियल स्पेस वीएम के तौर पर कॉन्फ़िगर किए गए हैं. ये आपके 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"
• मकसद: इस चरण में, आपके वर्कलोड के सेवा खाते (${SERVICE_ACCOUNT}) को Compute Engine सेवा एजेंट की भूमिका दी जाती है. यह अनुमति इसलिए ज़रूरी है, क्योंकि इससे सेवा खाता, प्रोजेक्ट की Compute Engine सेवा की ओर से कार्रवाई कर सकता है. यह अक्सर MIG की अपने-आप काम करने वाली सुविधाओं के लिए ज़रूरी होता है. जैसे, इंस्टेंस मैनेज करना, नेटवर्किंग सेट अप करना, और Google Cloud की अन्य सेवाओं के साथ इंटरैक्ट करना.

मैनेज किया गया इंस्टेंस ग्रुप बनाने के लिए, create_launch_mig.sh चलाएं.

6. अपने-आप ठीक होने और अपने-आप स्केल होने की सुविधा चालू करने का तरीका

ऑटोहीलिंग की सुविधा सेट अप करना

हम यह पुष्टि करते हैं कि वर्कलोड रिस्पॉन्सिव है, ताकि यह पक्का किया जा सके कि यह हमेशा उपलब्ध रहे. अगर ऐप्लिकेशन फ़्रीज़ हो जाता है, तो MIG को VM को बदलना चाहिए. सोर्स आईपी पतों की सीमाओं के लिए फ़ायरवॉल के नियम, इस दस्तावेज़ में बताए गए हैं.

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

ऑटोस्केलिंग की सुविधा सेट अप करना

हम ग्रुप को इस तरह कॉन्फ़िगर करेंगे कि ट्रैफ़िक बढ़ने पर, यह एक से पांच इंस्टेंस के बीच अपने-आप स्केल हो जाए.

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. वर्कलोड की पुष्टि करना और इमेज अपडेट सेट अप करना

वर्कलोड की पुष्टि करना

जब मैनेज किया गया इंस्टेंस ग्रुप (एमआईजी), वीएम लॉन्च कर देता है, तब हमें यह पुष्टि करनी होती है कि आपका कॉन्फ़िडेंशियल स्पेस वर्कलोड सही तरीके से चल रहा है.

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

इमेज अपडेट सेट अप करना

प्रोडक्शन एनवायरमेंट में, आपके मैनेज किए गए इंस्टेंस ग्रुप (एमआईजी) को समय-समय पर अपडेट किया जाना चाहिए. इससे दो अलग-अलग स्थितियों को ठीक किया जा सकता है:

1. वर्कलोड अपडेट: अपने ऐप्लिकेशन कोड का नया वर्शन रिलीज़ करना. उदाहरण के लिए, test_workload.py को v1 से v2 पर अपडेट करना.
2. इंफ़्रास्ट्रक्चर से जुड़े अपडेट: Google, Confidential Space के ओएस के लिए सुरक्षा पैच या अपडेट रिलीज़ कर रहा है. ध्यान दें कि हर महीने कम से कम एक बार, सीएस की नई इमेज चुनना सबसे सही तरीका है.

हमने अपने इंस्टेंस टेंप्लेट को डाइनैमिक इमेज लिंक (.../images/family/...) और डाइनैमिक कंटेनर टैग (:latest) के साथ कॉन्फ़िगर किया है. इसलिए, हम "रोलिंग रिप्लेस" ऑपरेशन की मदद से, इन दोनों स्थितियों को मैनेज कर सकते हैं. इससे यह पक्का होता है कि आपके वीएम का फ़्लीट हमेशा बिना किसी डाउनटाइम के, सबसे नए स्टैक पर चल रहा हो. साथ ही, आपको हर छोटे बदलाव के लिए नया इंस्टेंस टेंप्लेट बनाने की ज़रूरत नहीं पड़ती.

रोलिंग रिप्लेस स्क्रिप्ट

डायरेक्ट्री में जाकर, 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}"

इस स्क्रिप्ट के लिए, हम रीस्टार्ट करने के बजाय बदलने की सुविधा का इस्तेमाल कर सकते हैं.

• रीस्टार्ट करें विकल्प चुनने पर, मशीन को सिर्फ़ रीबूट किया जाता है. यह मौजूदा ओएस डिस्क को बनाए रखता है. इसका मतलब है कि यह नए ओएस पैच नहीं लेगा.
• बदलें विकल्प चुनने पर, वीएम मिट जाता है और टेंप्लेट से एक नया वीएम बन जाता है. इससे सिस्टम, परिवार के सदस्यों के लिए उपलब्ध Confidential Space OS की नई इमेज को खोजता है. साथ ही, रजिस्ट्री से "Latest" कंटेनर इमेज को पुल करता है.

–max-surge=1: इससे एमआईजी को, टारगेट साइज़ से एक अतिरिक्त वीएम कुछ समय के लिए बनाने की अनुमति मिलती है. यह एक नई (अपडेट की गई) वीएम बनाता है और पुरानी (आउटडेटेड) वीएम को मिटाने से पहले, उसके ठीक होने का इंतज़ार करता है.

–max-unavailable=0: इससे यह पक्का होता है कि कोई डाउनटाइम नहीं होगा. इससे MIG को यह पता चलता है कि किसी मशीन को तब तक ऑफ़लाइन करने की अनुमति नहीं है, जब तक कि वह पहले से ही किसी मशीन को बदलकर उसे ऑनलाइन न कर दे.

रोलिंग रीस्टार्ट स्क्रिप्ट

डायरेक्ट्री 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. अपनी लोकल test_workload.py फ़ाइल खोलें.
2. वर्शन प्रिंट स्टेटमेंट को print("Workload Version A") से बदलकर print("Workload Version B") करें
3. create_workload.sh चलाकर, कंटेनर इमेज को फिर से बनाएं और Artifact Registry में पुश करें. ध्यान दें कि हम उसी टैग (:latest) को पुश कर रहे हैं.

दूसरा चरण: रोलिंग अपडेट लागू करना

पिछले सेक्शन में बनाई गई अपडेट स्क्रिप्ट चलाएं. इससे MIG, हर वीएम को बदलने के लिए मजबूर हो जाएगा. साथ ही, यह :latest से जुड़े नए कंटेनर हैश को पुल करेगा.

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

स्क्रिप्ट पूरी होने का इंतज़ार करें

तीसरा चरण: सीरियल पोर्ट के ज़रिए अपडेट की पुष्टि करना

अपडेट पूरा होने के बाद, हम पुष्टि करते हैं कि नए वीएम, अपडेट किए गए कोड को चला रहे हैं.

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

चौथा चरण: इन्फ़्रास्ट्रक्चर कॉन्फ़िगरेशन की पुष्टि करना (ज़रूरी नहीं)

यह भी पुष्टि की जा सकती है कि आपका इंस्टेंस टेंप्लेट, ओएस और वर्कलोड, दोनों के लिए डाइनैमिक अपडेट पाने के लिए सही तरीके से कॉन्फ़िगर किया गया है या नहीं. इसके लिए, उसके मेटाडेटा की जांच करें.

डाइनैमिक कंटेनर रेफ़रंस देखने के लिए, यह कमांड चलाएं:

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

नतीजा: आपको अपनी कंटेनर इमेज के आखिर में :latest दिखेगा.

• असर: टेंप्लेट, किसी खास हैश के बजाय टैग की ओर इशारा करता है. इसलिए, हर बार रोलिंग-ऐक्शन रिप्लेस करने पर, पहले चरण में पुश किया गया सबसे नया कोड मिल जाता है.

(ज़रूरी नहीं) अपने-आप होने वाले अपडेट

मैन्युअल अपडेट, वर्शन की मुख्य रिलीज़ के लिए फ़ायदेमंद होते हैं. हालांकि, अक्सर आपको यह चाहिए होता है कि आपकी फ्लीट, सुरक्षा से जुड़े नए पैच या नियमित तौर पर डिप्लॉयमेंट बिल्ड को अपने-आप पिक अप कर ले. इसके लिए, किसी व्यक्ति के दखल की ज़रूरत न पड़े.

हम अपनी अपडेट स्क्रिप्ट को Cloud Run जॉब में पैकेज करके, ‘रोलिंग रिप्लेस' प्रोसेस को अपने-आप होने वाली प्रोसेस में बदल सकते हैं. इस कोडलैब के लिए, हम इसे हर 15 मिनट में ट्रिगर करेंगे. प्रोडक्शन एनवायरमेंट में, इसे बहुत कम बार चलाना चाहिए. उपयोगकर्ता की ज़रूरतों के हिसाब से, इसे हर हफ़्ते या हर महीने कॉन्फ़िगर किया जा सकता है.

पहला चरण: अपडेटर स्क्रिप्ट को कंटेनर में रखना

सबसे पहले, हमें 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/ डायरेक्ट्री से update_images_script.sh लेता है.
• इससे एक Docker इमेज बनती है. इसमें Google Cloud SDK और आपकी स्क्रिप्ट शामिल होती है.
• यह इमेज को ${CURRENT_PROJECT_REGION}-docker.pkg.dev/${PROJECT_ID}/${REPOSITORY}/update-script:latest पर पुश करता है.

दूसरा चरण: जॉब को डिप्लॉय और शेड्यूल करना

अब हमें Google Cloud को यह बताना होगा कि इस कंटेनर को समय-समय पर चलाया जाए. हम कंटेनर को एक्ज़ीक्यूट करने के लिए Cloud Run Jobs और इसे ट्रिगर करने के लिए 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 जॉब को सेट अप करता है, ताकि हर 15 मिनट में Cloud Run Job API को हिट किया जा सके.

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

तीसरा चरण: ऑटोमेशन की पुष्टि करना

इसे आज़माने के लिए, आपको 15 मिनट तक इंतज़ार नहीं करना होगा. पाइपलाइन की पुष्टि करने के लिए, शेड्यूलर को तुरंत चलाने के लिए मजबूर किया जा सकता है.

1. जॉब को तुरंत शुरू करना:

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

2. एक्ज़ीक्यूशन की जांच करें: Cloud Run कंसोल > जॉब पर जाएं. आपको एक नया एक्ज़ीक्यूशन शुरू होता हुआ दिखेगा.
3. एमआईजी की जांच करें: gcloud compute instance-groups managed list-instances ${CURRENT_MIG_NAME} चलाएं. जॉब के रोलिंग अपडेट को ट्रिगर करने पर, आपको RECREATING स्थिति में इंस्टेंस दिखेंगे.

15 मिनट का समय क्यों लगता है? हमने इस कोडलैब के लिए शेड्यूल को */15 * * * * पर सेट किया है, ताकि आपको नतीजे तुरंत दिख सकें. असल प्रोडक्शन एनवायरमेंट में, इसे हर दिन (जैसे, सुबह 3 बजे के लिए 0 3 * * *) या हर हफ़्ते चलाने के लिए बदला जा सकता है.

8. क्लीन अप करें

इस कोडलैब के तहत बनाए गए संसाधनों को हटाने के लिए, cleanup.sh स्क्रिप्ट का इस्तेमाल किया जा सकता है. सफ़ाई की इस प्रोसेस के तहत, ये संसाधन मिटा दिए जाएंगे:

• मैनेज किया गया इंस्टेंस ग्रुप (${CURRENT_MIG_NAME}) और इसके साथ जुड़े वीएम.
• इंस्टेंस टेंप्लेट (${TEMPLATE_NAME}) के बारे में जानकारी.
• हेल्थ चेक और फ़ायरवॉल के नियम (${HEALTH_CHECK_NAME}).
• Artifact Registry रिपॉज़िटरी (${REPOSITORY}).
• सेवा खाता (अगर आपने इस लैब के लिए कोई अलग खाता बनाया है).

अगर आपने एक्सप्लोर कर लिया है, तो कृपया इन निर्देशों का पालन करके अपना प्रोजेक्ट मिटाएं: प्रोजेक्ट बंद करना (मिटाना).

बधाई हो

बधाई हो, आपने कोडलैब पूरा कर लिया है!

आपने मैनेज किए गए इंस्टेंस ग्रुप (एमआईजी) का इस्तेमाल करके, कॉन्फ़िडेंशियल स्पेस के वर्कलोड को सुरक्षित तरीके से स्केल करने का तरीका सीखा. आपने फ़ेल होने की स्थिति से उबरने के लिए अपने-आप ठीक होने की सुविधा, ट्रैफ़िक में अचानक बढ़ोतरी को मैनेज करने के लिए अपने-आप स्केल होने की सुविधा को कॉन्फ़िगर किया है. साथ ही, आपने कॉन्फ़िडेंशियल स्पेस ओएस इमेज और वर्कलोड कंटेनर, दोनों के लिए बिना किसी रुकावट के अपडेट किए हैं.

आगे क्या करना है?

गोपनीय स्पेस के अन्य कोडलैब देखें:

• Confidential Space का इस्तेमाल करके, एमएल मॉडल और बौद्धिक संपत्ति को सुरक्षित करना
• मल्टी-पार्टी कंप्यूटेशन और Confidential Space का इस्तेमाल करके डिजिटल ऐसेट का लेन-देन कैसे करें
• कॉन्फ़िडेंशियल स्पेस की मदद से गोपनीय डेटा का विश्लेषण करना
• सुरक्षित किए गए ऐसे संसाधनों के साथ कॉन्फ़िडेंशियल स्पेस का इस्तेमाल करना जिन्हें क्लाउड सेवा देने वाली कंपनी के साथ सेव नहीं किया जाता है

इस बारे में और पढ़ें

• मॉनिटरिंग मेट्रिक के आधार पर स्केल करना
• क्या आपको अकेलापन महसूस हो रहा है? Confidential computing की मदद से डेटा को सुरक्षित रखना
• GCP में Confidential Computing
• गोपनीय स्पेस: निजता बनाए रखने के साथ मिलकर काम करने की सुविधा का भविष्य
• गोपनीय स्पेस की सुरक्षा से जुड़ी खास जानकारी
• डेटा की निजता को बेहतर बनाना: बड़े पैमाने पर कई पक्षों के साथ गोपनीय तरीके से मिलकर काम करना