Google आपकी पसंदीदा भाषा में कॉन्टेंट का अनुवाद करने के लिए, एआई टेक्नोलॉजी का इस्तेमाल करता है. एआई से मिले अनुवादों में गलतियां हो सकती हैं.

Artifact Registry के बारे में ज़्यादा जानकारी

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

Artifact Registry, पूरी तरह से मैनेज किया जाने वाला पैकेज मैनेजर है. यह OCI कंटेनर इमेज और लैंग्वेज पैकेज (जैसे, Maven और npm) को मैनेज करने के लिए एक यूनीफ़ाइड टूल उपलब्ध कराता है.

Artifact Registry को Google Cloud की कई अन्य सेवाओं के साथ इंटिग्रेट किया गया है. जैसे, यहां दिए गए उदाहरणों में:

Cloud Build, इमेज आर्टफ़ैक्ट को सीधे Artifact Registry में अपलोड कर सकता है.
Cloud Deploy, Artifact Registry की इमेज को सीधे तौर पर अलग-अलग रनटाइम एनवायरमेंट में डिप्लॉय कर सकता है.
यह Cloud Run और GKE जैसे कंटेनर रनटाइम को इमेज उपलब्ध कराता है. साथ ही, परफ़ॉर्मेंस ऑप्टिमाइज़ेशन की बेहतर सुविधाएं चालू करता है. जैसे, इमेज स्ट्रीमिंग.
Artifact Registry, आर्टफ़ैक्ट विश्लेषण के लिए एक पहचान बिंदु के तौर पर काम कर सकता है. इससे, ज्ञात जोखिमों की लगातार निगरानी की जा सकती है.
Cloud IAM, आर्टफ़ैक्ट के ऐक्सेस और अनुमतियों को लगातार और बेहतर तरीके से कंट्रोल करने की सुविधा देता है.

इस लैब में, आपको इन सुविधाओं के बारे में जानकारी मिलेगी. साथ ही, आपको इन्हें इस्तेमाल करने का तरीका भी बताया जाएगा.

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

इस लैब के लर्निंग ऑब्जेक्टिव क्या हैं?

कंटेनर और भाषा पैकेज के लिए अलग-अलग रिपॉज़िटरी बनाना
Artifact Registry की मदद से कंटेनर इमेज बनाना और उनका इस्तेमाल करना
Artifact Registry का इस्तेमाल करके, अपने आर्टफ़ैक्ट की सुरक्षा से जुड़ी स्थिति और कॉन्टेंट का विश्लेषण करना
Java Maven डिपेंडेंसी के लिए, Artifact Registry को कॉन्फ़िगर करना और उसका इस्तेमाल करना

2. सेटअप और ज़रूरी शर्तें

अपनी स्पीड से एनवायरमेंट सेट अप करना

Google Cloud Console में साइन इन करें और नया प्रोजेक्ट बनाएं या किसी मौजूदा प्रोजेक्ट का फिर से इस्तेमाल करें. अगर आपके पास पहले से कोई Gmail या Google Workspace खाता नहीं है, तो आपको एक खाता बनाना होगा.

प्रोजेक्ट का नाम, इस प्रोजेक्ट में हिस्सा लेने वाले लोगों के लिए डिसप्ले नेम होता है. यह एक वर्ण स्ट्रिंग है, जिसका इस्तेमाल Google API नहीं करते हैं. इसे कभी भी अपडेट किया जा सकता है.
प्रोजेक्ट आईडी, सभी Google Cloud प्रोजेक्ट के लिए यूनीक होता है. साथ ही, इसे बदला नहीं जा सकता. Cloud Console, अपने-आप एक यूनीक स्ट्रिंग जनरेट करता है. आम तौर पर, आपको इससे कोई फ़र्क़ नहीं पड़ता कि यह क्या है. ज़्यादातर कोडलैब में, आपको अपने प्रोजेक्ट आईडी (आम तौर पर PROJECT_ID के तौर पर पहचाना जाता है) का रेफ़रंस देना होगा. अगर आपको जनरेट किया गया आईडी पसंद नहीं है, तो आपके पास कोई दूसरा रैंडम आईडी जनरेट करने का विकल्प होता है. इसके अलावा, आपके पास अपना नाम आज़माने का विकल्प भी है. इससे आपको पता चलेगा कि वह नाम उपलब्ध है या नहीं. इस चरण के बाद, इसे बदला नहीं जा सकता. यह प्रोजेक्ट की अवधि तक बना रहता है.
आपकी जानकारी के लिए बता दें कि एक तीसरी वैल्यू भी होती है, जिसे प्रोजेक्ट नंबर कहते हैं. इसका इस्तेमाल कुछ एपीआई करते हैं. इन तीनों वैल्यू के बारे में ज़्यादा जानने के लिए, दस्तावेज़ देखें.

इसके बाद, आपको Cloud Console में बिलिंग की सुविधा चालू करनी होगी, ताकि Cloud संसाधनों/एपीआई का इस्तेमाल किया जा सके. इस कोडलैब को पूरा करने में ज़्यादा खर्च नहीं आएगा. इस ट्यूटोरियल के बाद बिलिंग से बचने के लिए, संसाधनों को शट डाउन करें. इसके लिए, बनाए गए संसाधनों को मिटाएं या प्रोजेक्ट को मिटाएं. Google Cloud के नए उपयोगकर्ताओं को, 300 डॉलर का क्रेडिट मुफ़्त में आज़माने का प्रोग्राम मिलता है.

gcloud सेट अप करना

Cloud Shell में, अपना प्रोजेक्ट आईडी और प्रोजेक्ट नंबर सेट करें. इन्हें PROJECT_ID और PROJECT_NUMBER वैरिएबल के तौर पर सेव करें.

export PROJECT_ID=$(gcloud config get-value project)
export PROJECT_NUMBER=$(gcloud projects describe $PROJECT_ID --format='value(projectNumber)')

Google की सेवाएं चालू करना

gcloud services enable \
  cloudresourcemanager.googleapis.com \
  run.googleapis.com \
  artifactregistry.googleapis.com \
  containerregistry.googleapis.com \
  containerscanning.googleapis.com \
  binaryauthorization.googleapis.com \
  cloudbuild.googleapis.com

सोर्स कोड पाना

इस लैब का सोर्स कोड, GitHub पर GoogleCloudPlatform संगठन में मौजूद है. नीचे दिए गए कमांड का इस्तेमाल करके इसे क्लोन करें.

git clone https://github.com/GoogleCloudPlatform/java-docs-samples

3. कंटेनर इमेज पुश करना

Artifact Registry पर Docker Repository बनाना

जैसा कि पहले बताया गया है, Artifact Registry अलग-अलग रिपॉज़िटरी फ़ॉर्मैट के साथ काम करता है. इनकी मदद से, कंटेनर इमेज और लैंग्वेज पैकेज मैनेज किए जा सकते हैं. अलग-अलग तरह की आर्टफ़ैक्ट रिपॉज़िटरी के साथ इंटरैक्शन, स्पेसिफ़िकेशन में तय किए जाते हैं. साथ ही, ये व्यापक रूप से इस्तेमाल किए जाने वाले स्टैंडर्ड हैं. उदाहरण के लिए, Maven डिपेंडेंसी के अनुरोध, Node डिपेंडेंसी के अनुरोधों से अलग होते हैं.

किसी खास आर्टफ़ैक्ट एपीआई की खास बातों को पूरा करने के लिए, Artifact Registry को आपके आर्टफ़ैक्ट को उससे जुड़ी रिपॉज़िटरी टाइप में मैनेज करना होगा. नई रिपॉज़िटरी बनाते समय, रिपॉज़िटरी के टाइप के बारे में बताने के लिए --repository-format फ़्लैग पास करें.

Docker इमेज के लिए पहली रिपॉज़िटरी बनाने के लिए, Cloud Shell में यह कमांड चलाएं:

gcloud artifacts repositories create container-example --repository-format=docker \
--location=us-central1 --description="Example Docker repository"

अगर Cloud Shell से अनुमति लेने का प्रॉम्प्ट दिखता है, तो 'अनुमति दें' पर क्लिक करें

Google Cloud Console - Artifact Registry - Repositories पर जाएं और अपनी नई बनाई गई Docker रिपॉज़िटरी container-example को देखें. इस पर क्लिक करने से आपको पता चलेगा कि फ़िलहाल यह खाली है

Artifact Registry के लिए Docker Authentication कॉन्फ़िगर करना

Artifact Registry से कनेक्ट करते समय, ऐक्सेस देने के लिए क्रेडेंशियल ज़रूरी होते हैं. अलग क्रेडेंशियल सेट अप करने के बजाय, Docker को gcloud क्रेडेंशियल का आसानी से इस्तेमाल करने के लिए कॉन्फ़िगर किया जा सकता है.

us-central1 क्षेत्र में Artifact Registry पर अनुरोधों की पुष्टि करने के लिए, Google Cloud CLI का इस्तेमाल करने के लिए Docker को कॉन्फ़िगर करने के लिए, Cloud Shell में यह कमांड चलाएं,

gcloud auth configure-docker us-central1-docker.pkg.dev

अगर कमांड से Cloud Shell के Docker कॉन्फ़िगरेशन को बदलने की पुष्टि करने के लिए कहा जाता है, तो Enter दबाएं.

सैंपल ऐप्लिकेशन एक्सप्लोर करना

आपको git रिपॉज़िटरी में एक सैंपल ऐप्लिकेशन मिलेगा. आपने इसे पिछले चरण में क्लोन किया था. जावा डायरेक्ट्री में जाएं और ऐप्लिकेशन कोड की समीक्षा करें.

cd java-docs-samples/run/helloworld/
ls

इस फ़ोल्डर में, Java का एक उदाहरण ऐप्लिकेशन है. यह एक सामान्य वेब पेज रेंडर करता है: इसमें ऐसी कई फ़ाइलें हैं जो इस लैब के लिए काम की नहीं हैं. साथ ही, इसमें src फ़ोल्डर में सोर्स कोड और एक Dockerfile भी है. हम इसका इस्तेमाल कंटेनर इमेज बनाने के लिए करेंगे.

कंटेनर इमेज बनाना

Artifact Registry में कंटेनर इमेज सेव करने से पहले, आपको एक कंटेनर इमेज बनानी होगी.

कंटेनर इमेज बनाने और उसे पूरे आर्टफ़ैक्ट रजिस्ट्री पाथ के साथ टैग करने के लिए, यह कमांड चलाएं:

docker build -t us-central1-docker.pkg.dev/$PROJECT_ID/container-example/java-hello-world:tag1 .

कंटेनर इमेज को Artifact Registry में पुश करना

कंटेनर इमेज को पहले बनाई गई रिपॉज़िटरी में पुश करने के लिए, यह कमांड चलाएं:

docker push us-central1-docker.pkg.dev/$PROJECT_ID/container-example/java-hello-world:tag1

Artifact Registry में इमेज की समीक्षा करना

Google Cloud Console - Artifact Registry - Repositories पर जाएं. container-example रिपॉज़िटरी खोलें और पुष्टि करें कि java-hello-world इमेज मौजूद है.

इमेज पर क्लिक करें और tag1 के तौर पर टैग की गई इमेज को नोट करें. हमने containerscanning.googleapis.com सेवा के ज़रिए, इमेज को अपने-आप स्कैन होने की सुविधा चालू की है. इसलिए, आपको दिखेगा कि जोखिम की आशंका का पता लगाने के लिए स्कैनिंग की सुविधा चालू है या पहले ही पूरी हो चुकी है. स्कैनिंग पूरी होने के बाद, आपको इस इमेज के वर्शन में मिली कमज़ोरियों की संख्या दिखेगी. हम अगले सेक्शन में, जोखिम की संभावनाओं और अन्य आर्टफ़ैक्ट की अहम जानकारी के बारे में जानेंगे.

4. कंटेनर इमेज की जांच करना

आपने अपनी पहली इमेज को container-example रिपॉज़िटरी में पुश कर दिया है. अब हम इसके बारे में ज़्यादा जानकारी देख सकते हैं. वर्शन टैब पर, अभी-अभी बनाए गए वर्शन पर क्लिक करें. इमेज को ज़्यादा जानकारी के साथ दिखाने के लिए:

ऊपर मौजूद 'कॉपी करें' बटन खास तौर पर तब काम आता है, जब आपको इमेज के उस वर्शन का पूरी तरह से क्वालिफ़ाइड इमेज यूआरआई ऐक्सेस करना हो. इसमें SHA-हैश भी शामिल होता है. इसके बाद, इस यूआरआई का इस्तेमाल किसी इमेज के खास वर्शन को पुल करने के लिए किया जा सकता है. इसके अलावा, इसे Kubernetes Deployment या Cloud Run Service में इमेज के रेफ़रंस के तौर पर भी इस्तेमाल किया जा सकता है. इमेज यूआरआई की जांच करने के लिए, Cloud Shell में यह कमांड चलाएं:

docker pull $IMAGE_URI

डिपेंडेंसी के बारे में जानकारी

सबसे ऊपर मौजूद "डिपेंडेंसी" टैब पर जाकर, अपनी इमेज में मिली सभी डिपेंडेंसी देखी जा सकती हैं. ध्यान दें कि इसमें भाषा और ओएस, दोनों लेवल पर डिपेंडेंसी की सूची दी गई है. इसके अलावा, हर डिपेंडेंसी से जुड़े सॉफ़्टवेयर लाइसेंस भी देखे जा सकते हैं.

ध्यान से देखने पर पता चलता है कि SBOM की जानकारी अभी तक नहीं भरी गई है. अपने आर्टफ़ैक्ट के लिए एसओएम को पॉप्युलेट करने के लिए, Cloud Shell में यह निर्देश चलाएं. इसके लिए, पूरी तरह से क्वालिफ़ाइड इमेज यूआरआई का इस्तेमाल करें. इसे सबसे ऊपर मौजूद ब्रेडक्रंब बार से कॉपी किया जा सकता है.

gcloud artifacts sbom export --uri $IMAGE_URI

पेज को रीफ़्रेश करने के बाद, इसमें Cloud Storage में सेव किए गए, अपने-आप जनरेट हुए SBOM का लिंक दिखेगा. अगर आपको अपनी इमेज के लिए एसबीओएम पर भरोसा है, तो हो सकता है कि आपको अपने आर्टफ़ैक्ट के लिए एसबीओएम अपने-आप जनरेट करने हों. साथ ही, जनरेट करने की प्रोसेस को सीआई/सीडी पाइपलाइन का हिस्सा बनाना हो.

इमेज से जुड़ी सुरक्षा जोखिमों का पता लगाना

व्यू में सबसे ऊपर मौजूद "कमज़ोरियां" टैब पर क्लिक करने से, आपको अपनी इमेज में मिली सभी कमज़ोरियां दिख सकती हैं. सबसे ऊपर, कमियों की खास जानकारी के साथ-साथ, सबसे नीचे मौजूद टेबल में कमियों की पूरी सूची भी देखी जा सकती है. हर लाइन, CVE बुलेटिन से लिंक होती है. इससे, उसकी गंभीरता और उस पैकेज के बारे में पता चलता है जिससे वह शुरू हुआ था. जिन जोखिमों को ठीक किया जा सकता है उनके लिए, यह जोखिम को ठीक करने के लिए डिपेंडेंसी को अपडेट करने के तरीके के बारे में भी निर्देश देता है.

5. वर्चुअल और रिमोट रिपॉज़िटरी

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

Docker Hub के लिए रिमोट रिपॉज़िटरी

Docker Hub, इमेज की एक लोकप्रिय सार्वजनिक रजिस्ट्री है. यह कई ओपन-सोर्स कंटेनर इमेज होस्ट करती है. पब्लिक रिपॉज़िटरी का सीधे तौर पर इस्तेमाल करना आसान है. हालांकि, प्रोडक्शन एनवायरमेंट में इसका इस्तेमाल करने से कई समस्याएं आती हैं. Artifact Registry में रिमोट रिपॉज़िटरी का इस्तेमाल करके, इन समस्याओं को हल किया जा सकता है.

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

Docker Hub के लिए रिमोट रिपॉज़िटरी बनाने के लिए, Cloud Shell में यह निर्देश चलाएं:

gcloud artifacts repositories create dockerhub \
  --repository-format=docker \
  --mode=remote-repository \
  --remote-docker-repo=docker-hub \
  --location=us-central1 \
  --description="Example Remote Repo for Docker Hub"

अब आपको Artifact Registry के डेटा स्टोर करने की जगहों की सूची में एक और डेटा स्टोर करने की जगह दिखेगी:

यह जांचने के लिए कि आपकी रिमोट रिपॉज़िटरी, रिमोट रिपॉज़िटरी को प्रॉक्सी अनुरोध भेज सकती है या नहीं, Cloud Shell में यह कमांड चलाकर nginx इमेज को पुल करें:

docker pull us-central1-docker.pkg.dev/$PROJECT_ID/dockerhub/nginx:stable-alpine

डेटा पुल हो जाने के बाद, Cloud Console में जाकर रिपॉज़िटरी देखी जा सकती है. साथ ही, यह देखा जा सकता है कि कैश मेमोरी में सेव की गई nginx इमेज, अब वही डिपेंडेंसी और जोखिम की आशंका की रिपोर्टिंग दिखा रही है जो आपने खुद बनाई थी.

वर्चुअल डेटाबेस बनाना

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

इस्तेमाल को आसान बनाने और ऐब्स्ट्रैक्शन लेयर के पीछे की रिपॉज़िटरी को छिपाने के लिए, Artifact Registry में वर्चुअल रिपॉज़िटरी बनाई जा सकती है. इसके लिए, Cloud Shell में यह कमांड डालें:

gcloud projects add-iam-policy-binding $PROJECT_ID \
    --member serviceAccount:service-$PROJECT_NUMBER@gcp-sa-artifactregistry.iam.gserviceaccount.com \
    --role roles/artifactregistry.reader

cat <<EOF > /tmp/upstream.json
[{
"id" : "hello-repo",
"repository" : "projects/$PROJECT_ID/locations/us-central1/repositories/container-example",
"priority" : 100
},{
"id" : "dockerhub",
"repository" : "projects/$PROJECT_ID/locations/us-central1/repositories/dockerhub",
"priority" : 101
}]
EOF

gcloud artifacts repositories create all-images \
    --repository-format=docker \
    --mode=virtual-repository \
    --location=us-central1 \
    --upstream-policy-file=/tmp/upstream.json \
    --description="Example Virtual Repo"

अब हम वर्चुअल रिपॉज़िटरी से इमेज को खींच सकते हैं. इसके लिए, हमें इमेज के स्ट्रक्चर को ज़ाहिर करने की ज़रूरत नहीं है. यह पुष्टि करने के लिए कि सब कुछ उम्मीद के मुताबिक काम कर रहा है, Cloud Shell में ये कमांड चलाएं:

docker pull us-central1-docker.pkg.dev/$PROJECT_ID/all-images/java-hello-world:tag1

docker pull us-central1-docker.pkg.dev/$PROJECT_ID/all-images/nginx:stable-alpine

6. Cloud Run पर डिप्लॉय करना

रिपॉज़िटरी और इमेज को सही जगह पर रखने के बाद, अब हम उन्हें डिप्लॉयमेंट में इस्तेमाल कर सकते हैं. इस्तेमाल के उदाहरण को दिखाने और अतिरिक्त इन्फ़्रास्ट्रक्चर को डिप्लॉय करने से बचने के लिए, हम अपने कंटेनर को Cloud Run पर डिप्लॉय करेंगे. आसान तरीके से डिप्लॉयमेंट करने के लिए, Cloud Shell में यह कमांड चलाएं:

gcloud run deploy hello-world \
  --image us-central1-docker.pkg.dev/$PROJECT_ID/all-images/java-hello-world:tag1 \
  --region us-central1 \
  --allow-unauthenticated

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

Deploying container to Cloud Run service [hello-world] in project [my-project] region [us-central1]
OK Deploying... Done.                                                                      
  OK Creating Revision...                                                                  
  OK Routing traffic...
  OK Setting IAM Policy...                                                                    
Done.                                                                                      
Service [hello-world] revision [hello-world-00001-wtc] has been deployed and is serving 100 percent of traffic.
Service URL: https://hello-world-13746229022.us-central1.run.app

उस यूआरएल को नए ब्राउज़र टैब में खोलने पर, आपको "Hello World" मैसेज दिखेगा.

7. सप्लाई चेन की सुरक्षा को बेहतर बनाना

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

Cloud Build की मदद से SLSA अटेस्टेशन

एसएलएसए फ़्रेमवर्क, सप्लाई चेन के आर्टफ़ैक्ट के लिए अलग-अलग लेवल के सबूत उपलब्ध कराता है. पहली नज़र में, स्पेसिफ़िकेशन और उसे लागू करना मुश्किल लग सकता है. हालांकि, Cloud Build की मदद से SLSA अटेस्टेशन बनाना उतना ही आसान है जितना कि cloudbuild.yaml स्पेसिफ़िकेशन बनाना. इसके लिए, requestedVerifyOption को VERIFIED पर सेट करना होता है.

अपने ऐप्लिकेशन के लिए, Cloud Shell में यह कमांड चलाकर, helloworld फ़ोल्डर में cloudbuild.yaml फ़ाइल बनाई जा सकती है.

cat <<EOF > cloudbuild.yaml
steps:
- name: 'gcr.io/cloud-builders/docker'
  args: ['build', '-t', '\$_IMAGE_URI', '.']
- name: 'gcr.io/cloud-builders/docker'
  args: ['push', '\$_IMAGE_URI']
images:
- '\$_IMAGE_URI'
options:
  requestedVerifyOption: VERIFIED
substitutions:
  _IMAGE_URI: us-central1-docker.pkg.dev/$PROJECT_ID/container-example/java-hello-world:latest
EOF

अब हम एक नया Cloud Build जॉब बनाते हैं. यह जॉब, Cloud Shell में नीचे दी गई कमांड चलाकर, Java Hello World इमेज का नया वर्शन बनाता है.

gcloud builds submit --substitutions=_IMAGE_URI=us-central1-docker.pkg.dev/$PROJECT_ID/container-example/java-hello-world:cloud-build

बिल्ड पूरा होने के बाद, हम Google Cloud Console में Cloud Build के यूज़र इंटरफ़ेस (यूआई) पर जा सकते हैं. इसके बाद, हम अपने बिल्ड को खोलकर और बिल्ड की खास जानकारी में जाकर, बिल्ड आर्टफ़ैक्ट देखकर यह जान सकते हैं कि हमें एसएलएसए का कौन-सा लेवल मिला है. वहां दिखने वाली इमेज में, "सुरक्षा से जुड़ी अहम जानकारी" देखने के लिए एक बटन होता है. इस पर क्लिक करने से, आपको एसएलएसए अटेस्टेशन के साथ-साथ, उन जानी-पहचानी कमज़ोरियों की रिपोर्ट भी दिखती हैं जो हमने पहले Artifact Registry के यूज़र इंटरफ़ेस (यूआई) में देखी थीं. ऐसा तब हुआ था, जब हमने अपनी लोकल बिल्ड को पुश किया था.

Cloud Shell में यह कमांड चलाकर, हमारी इमेज के लिए SLSA का प्रॉवनेंस भी वापस पाया जा सकता है:

gcloud artifacts docker images describe \
"us-central1-docker.pkg.dev/$PROJECT_ID/container-example/java-hello-world:cloud-build" \
 --show-provenance

बाइनरी अनुमति के साथ Cloud Build Provenance की ज़रूरत होती है

Cloud Build पाइपलाइन का इस्तेमाल करके, क्या यह पक्का नहीं किया जा सकता कि प्रोडक्शन में डिप्लॉय की गई सभी इमेज, प्रोग्राम की जा सकने वाली और फिर से बनाई जा सकने वाली बिल्ड एनवायरमेंट का इस्तेमाल करके बनाई गई हों?

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

अपने प्रोजेक्ट के डिफ़ॉल्ट बाइनरी ऑथराइज़ेशन कॉन्फ़िगरेशन को बदलने के लिए, हमें Cloud Run से जारी किए गए बिल्ट-इन अटेस्टेशन की ज़रूरत होगी. इसके लिए, हम Cloud Shell में यह कमांड चलाते हैं:

cat << EOF > /tmp/policy.yaml
defaultAdmissionRule:
  enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
  evaluationMode: REQUIRE_ATTESTATION
  requireAttestationsBy:
  - projects/$PROJECT_ID/attestors/built-by-cloud-build
name: projects/$PROJECT_ID/policy
EOF

gcloud container binauthz policy import /tmp/policy.yaml

यहां अपने कस्टम अटेस्टर्स भी जोड़े जा सकते हैं. हालांकि, यह इस कोडलैब के दायरे से बाहर है. इसे होमवर्क के तौर पर वैकल्पिक गतिविधि के तौर पर छोड़ा गया है.

Cloud Run सेवा पर बाइनरी ऑथराइज़ेशन लागू करने के लिए, हम Cloud Shell में यह कमांड चलाते हैं:

gcloud run services update hello-world \
  --region us-central1 \
  --binary-authorization=default

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

gcloud run deploy hello-world \
  --image us-central1-docker.pkg.dev/$PROJECT_ID/all-images/java-hello-world:tag1 \
  --region us-central1

आपको गड़बड़ी का एक मैसेज मिलेगा. इसमें बताया गया होगा कि इमेज को क्यों डिप्लॉय नहीं किया जा सका. यह मैसेज कुछ इस तरह का होगा:

Image us-central1-docker.pkg.dev/my-project/all-images/java-hello-world@sha256:71eebbf04bf7d1d023e5de5e18f786ea3b8b6411bf64c8def3301c71baca0518 denied by attestor projects/my-project/attestors/built-by-cloud-build: No attestations found that were valid and signed by a key trusted by the attestor

इसलिए, Cloud Run सेवा पर नया वर्शन डिप्लॉय करने के लिए, हमें Cloud Build की मदद से बनाई गई इमेज देनी होगी.

gcloud run deploy hello-world \
  --image us-central1-docker.pkg.dev/$PROJECT_ID/all-images/java-hello-world:cloud-build \
  --region us-central1

इस बार डिप्लॉयमेंट पूरा हो जाना चाहिए. साथ ही, डिप्लॉयमेंट पूरा होने का मैसेज दिखना चाहिए. यह मैसेज, यहां दिए गए मैसेज जैसा होना चाहिए:

Deploying container to Cloud Run service [hello-world] in project [my-project] region [us-central1]
OK Deploying... Done.                                                                      
  OK Creating Revision...                                                                  
  OK Routing traffic...                                                                    
Done.                                                                                      
Service [hello-world] revision [hello-world-00005-mq4] has been deployed and is serving 100 percent of traffic.
Service URL: https://hello-world-13746229022.us-central1.run.app

8. Java Maven लैंग्वेज पैकेज मैनेज करना

इस सेक्शन में, आपको Artifact Registry की Java रिपॉज़िटरी सेट अप करने और उसमें पैकेज अपलोड करने का तरीका बताया जाएगा. साथ ही, अलग-अलग ऐप्लिकेशन में उनका इस्तेमाल करने का तरीका भी बताया जाएगा.

Maven पैकेज रिपॉज़िटरी बनाना

Java आर्टफ़ैक्ट के लिए रिपॉज़िटरी बनाने के लिए, Cloud Shell में यह कमांड चलाएं:

gcloud artifacts repositories create java-repo \
    --repository-format=maven \
    --location=us-central1 \
    --description="Example Java Maven Repo"

अगर Cloud Shell से अनुमति लेने का प्रॉम्प्ट दिखता है, तो 'अनुमति दें' पर क्लिक करें

Google Cloud Console - Artifact Registry - Repositories पर जाएं. आपको java-repo नाम की नई Maven रिपॉज़िटरी दिखेगी. इस पर क्लिक करने से पता चलेगा कि फ़िलहाल यह खाली है.

Artifact Repository के लिए पुष्टि करने की सुविधा सेट अप करना

अपने उपयोगकर्ता खाते के क्रेडेंशियल की मदद से, ऐप्लिकेशन के डिफ़ॉल्ट क्रेडेंशियल (एडीसी) के लिए जानी-पहचानी जगह को अपडेट करने के लिए, इस कमांड का इस्तेमाल करें. इससे, Artifact Registry क्रेडेंशियल हेल्पर, रिपॉज़िटरी से कनेक्ट करते समय इन क्रेडेंशियल का इस्तेमाल करके पुष्टि कर सकता है:

gcloud auth login --update-adc

Artifact Registry के लिए Maven को कॉन्फ़िगर करना

अपने Java प्रोजेक्ट में जोड़ने के लिए, रिपॉज़िटरी कॉन्फ़िगरेशन को प्रिंट करने के लिए, यह कमांड चलाएं:

gcloud artifacts print-settings mvn \
    --repository=java-repo \
    --location=us-central1 | tee config.xml

helloworld डायरेक्ट्री में Cloud Shell से, Cloud Shell Editor में यह निर्देश चलाकर pom.xml खोलें:

cloudshell edit pom.xml

और फ़ाइल में, वापस लाई गई सेटिंग को सही सेक्शन में जोड़ें,

distributionManagement सेक्शन अपडेट करना

<distributionManagement>
   <snapshotRepository>
     <id>artifact-registry</id>
     <url>artifactregistry://us-central1-maven.pkg.dev/<PROJECT>/java-repo</url>
   </snapshotRepository>
   <repository>
     <id>artifact-registry</id>
     <url>artifactregistry://us-central1-maven.pkg.dev/<PROJECT>/java-repo</url>
   </repository>
</distributionManagement>

रिपॉज़िटरी सेक्शन अपडेट करना

 <repositories>
   <repository>
     <id>artifact-registry</id>
     <url>artifactregistry://us-central1-maven.pkg.dev/<PROJECT>/java-repo</url>
     <releases>
       <enabled>true</enabled>
     </releases>
     <snapshots>
       <enabled>true</enabled>
     </snapshots>
   </repository>
 </repositories>

बिल्ड में जाकर, एक्सटेंशन सेक्शन को अपडेट करें

   <extensions>
     <extension>
       <groupId>com.google.cloud.artifactregistry</groupId>
       <artifactId>artifactregistry-maven-wagon</artifactId>
       <version>2.1.0</version>
     </extension>
   </extensions>

यहां आपकी जानकारी के लिए, पूरी फ़ाइल का उदाहरण दिया गया है. <PROJECT> की जगह अपना प्रोजेक्ट आईडी डालना न भूलें.

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
 <modelVersion>4.0.0</modelVersion>
 <groupId>com.example.run</groupId>
 <artifactId>helloworld</artifactId>
 <version>0.0.1-SNAPSHOT</version>
 <packaging>jar</packaging>

 <parent>
   <groupId>com.google.cloud.samples</groupId>
   <artifactId>shared-configuration</artifactId>
   <version>1.2.0</version>
 </parent>
 <dependencyManagement>
   <dependencies>
     <dependency>
       <groupId>org.springframework.boot</groupId>
       <artifactId>spring-boot-dependencies</artifactId>
       <version>${spring-boot.version}</version>
       <type>pom</type>
       <scope>import</scope>
     </dependency>
   </dependencies>
 </dependencyManagement>
 <properties>
   <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
   <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
   <maven.compiler.target>17</maven.compiler.target>
   <maven.compiler.source>17</maven.compiler.source>
   <spring-boot.version>3.2.2</spring-boot.version>
 </properties>
 <dependencies>
   <dependency>
     <groupId>org.springframework.boot</groupId>
     <artifactId>spring-boot-starter-web</artifactId>
   </dependency>
   <dependency>
     <groupId>org.springframework.boot</groupId>
     <artifactId>spring-boot-starter-test</artifactId>
     <scope>test</scope>
   </dependency>
   <dependency>
     <groupId>org.junit.vintage</groupId>
     <artifactId>junit-vintage-engine</artifactId>
     <scope>test</scope>
   </dependency>
   <dependency>
     <groupId>junit</groupId>
     <artifactId>junit</artifactId>
     <scope>test</scope>
   </dependency>
 </dependencies>
 <!-- [START Artifact Registry Config] -->
 <distributionManagement>
   <snapshotRepository>
     <id>artifact-registry</id>
     <url>artifactregistry://us-central1-maven.pkg.dev/<PROJECT>/java-repo</url>
   </snapshotRepository>
   <repository>
     <id>artifact-registry</id>
     <url>artifactregistry://us-central1-maven.pkg.dev/<PROJECT>/java-repo</url>
   </repository>
 </distributionManagement>

 <repositories>
   <repository>
     <id>artifact-registry</id>
     <url>artifactregistry://us-central1-maven.pkg.dev/<PROJECT>/java-repo</url>
     <releases>
       <enabled>true</enabled>
     </releases>
     <snapshots>
       <enabled>true</enabled>
     </snapshots>
   </repository>
 </repositories>
  <build>
   <extensions>
     <extension>
       <groupId>com.google.cloud.artifactregistry</groupId>
       <artifactId>artifactregistry-maven-wagon</artifactId>
       <version>2.2.0</version>
     </extension>
   </extensions>
 <!-- [END Artifact Registry Config] -->

   <plugins>
     <plugin>
       <groupId>org.springframework.boot</groupId>
       <artifactId>spring-boot-maven-plugin</artifactId>
       <version>${spring-boot.version}</version>
       <executions>
         <execution>
           <goals>
             <goal>repackage</goal>
           </goals>
         </execution>
       </executions>
     </plugin>
     <plugin>
       <groupId>com.google.cloud.tools</groupId>
       <artifactId>jib-maven-plugin</artifactId>
       <version>3.4.0</version>
       <configuration>
         <to>
           <image>gcr.io/PROJECT_ID/helloworld</image>
         </to>
       </configuration>
     </plugin>
   </plugins>
 </build>
 </project>

Artifact Registry में अपना Java पैकेज अपलोड करना

Maven में Artifact Registry को कॉन्फ़िगर करने के बाद, अब Artifact Registry का इस्तेमाल करके Java जार सेव किए जा सकते हैं. इससे आपके संगठन के अन्य प्रोजेक्ट में इनका इस्तेमाल किया जा सकेगा.

अपने Java पैकेज को Artifact Registry में अपलोड करने के लिए, यह कमांड चलाएं:

mvn deploy

Artifact Registry में Java पैकेज की जांच करना

Cloud Console - Artifact Registry - Repositories पर जाएं java-repo पर क्लिक करें और देखें कि helloworld बाइनरी आर्टफ़ैक्ट मौजूद है या नहीं:

9. बधाई हो!

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

आपने क्या-क्या कवर किया है

कंटेनर और लैंग्वेज पैकेज के लिए रिपॉज़िटरी बनाई गई हैं
Artifact Registry की मदद से मैनेज की गई कंटेनर इमेज
Cloud Code के साथ Artifact Registry को इंटिग्रेट किया गया हो
Java डिपेंडेंसी के लिए, Artifact Registry का इस्तेमाल करने के लिए Maven को कॉन्फ़िगर किया गया हो

साफ़-सफ़ाई सेवा

पूरे प्रोजेक्ट को मिटाने के लिए, Cloud Shell में यह कमांड चलाएं

gcloud projects delete $PROJECT_ID