इस पेज का अनुवाद Cloud Translation API से किया गया है.

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

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

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

आर्टफ़ैक्ट रजिस्ट्री, Google Cloud की कई सेवाओं के साथ पूरी तरह से इंटिग्रेट है. इनमें ये सेवाएं शामिल हैं:

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

इस लैब में, आपको इनमें से कई सुविधाओं के बारे में, प्रैक्टिकल ट्यूटोरियल के तौर पर जानकारी दी जाएगी.

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

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

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

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

अपने हिसाब से एनवायरमेंट सेट अप करना

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

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

इसके बाद, आपको Cloud के संसाधनों/एपीआई का इस्तेमाल करने के लिए, Cloud Console में बिलिंग की सुविधा चालू करनी होगी. इस कोडलैब को चलाने में ज़्यादा खर्च नहीं होगा. इस ट्यूटोरियल के बाद बिलिंग से बचने के लिए, संसाधनों को बंद किया जा सकता है. इसके लिए, आपके पास बनाए गए संसाधनों को मिटाने या प्रोजेक्ट को मिटाने का विकल्प होता है. 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 डेटा स्टोर करने की जगह बनाना

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

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

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

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

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

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

Artifact Registry में Docker की पुष्टि करने की सुविधा कॉन्फ़िगर करना

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 के डॉकर कॉन्फ़िगरेशन को बदलने के लिए, कमांड से पुष्टि करने के लिए कहा जाए, तो Enter दबाएं.

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

पिछले चरण में क्लोन की गई git रिपॉज़िटरी में, ऐप्लिकेशन का एक सैंपल दिया गया है. java डायरेक्ट्री में जाएं और ऐप्लिकेशन कोड की समीक्षा करें.

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

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

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

आर्टफ़ैक्ट रजिस्ट्री में कंटेनर इमेज सेव करने से पहले, आपको एक आर्टफ़ैक्ट रजिस्ट्री बनानी होगी.

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

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

कंटेनर इमेज को आर्टफ़ैक्ट रजिस्ट्री में पुश करना

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

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

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

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

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

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

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

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

docker pull $IMAGE_URI

डिपेंडेंसी को समझना

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

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

gcloud artifacts sbom export --uri $IMAGE_URI

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

इमेज से जुड़ी जोखिम की आशंकाओं के बारे में जानकारी

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

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

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

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

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

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

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 के डेटा स्टोर करने की जगहों की सूची में एक और डेटा स्टोर करने की जगह दिखेगी:

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

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

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

वर्चुअल रिपॉज़िटरी बनाना

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

आर्टफ़ैक्ट का इस्तेमाल आसान बनाने और आर्टफ़ैक्ट के पीछे मौजूद रिपॉज़िटरी को छिपाने के लिए, 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 के कंटेनर का विश्लेषण करके, इमेज में इस्तेमाल की गई लाइब्रेरी और लाइसेंस के बारे में अहम जानकारी कैसे मिलती है. हालांकि, नुकसान पहुंचाने वाले लोग या ग्रुप अब भी सप्लाई चेन के दौरान, आपकी इमेज में नुकसान पहुंचाने वाला कॉन्टेंट डाल सकते हैं. इस सेक्शन में, हम SLSA फ़्रेमवर्क का इस्तेमाल करके, बिल्ड आर्टफ़ैक्ट के लिए पुष्टि करने का तरीका जानेंगे. साथ ही, हम यह भी जानेंगे कि आर्टफ़ैक्ट के क्रिप्टोग्राफ़िक हस्ताक्षर का इस्तेमाल करके, यह कैसे पक्का किया जा सकता है कि हमारे Cloud Run रनटाइम पर सिर्फ़ भरोसेमंद आर्टफ़ैक्ट ही डिप्लॉय किए जाएं.

Cloud Build की मदद से SLSA की पुष्टि करना

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

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

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 के यूज़र इंटरफ़ेस (यूआई) पर जा सकते हैं. यहां हम अपना बिल्ड खोलकर, एसएलएसए का वह लेवल देख सकते हैं जिसे हमने हासिल किया है. इसके बाद, बिल्ड की खास जानकारी में जाकर, बिल्ड आर्टफ़ैक्ट देखें. वहां दिखने वाली इमेज में, "सुरक्षा की अहम जानकारी" देखने के लिए एक बटन है. इस पर क्लिक करने पर, आपको SLSA की पुष्टि के साथ-साथ, कमज़ोरियों की वे रिपोर्ट भी दिखती हैं जो हमें आर्टफ़ैक्ट रजिस्ट्री के यूज़र इंटरफ़ेस (यूआई) में, लोकल बिल्ड को पुश करते समय दिखी थीं.

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 के सोर्स की पुष्टि करना ज़रूरी है

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 भाषा पैकेज मैनेज करना

इस सेक्शन में, आपको आर्टफ़ैक्ट रजिस्ट्री 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 - आर्टफ़ैक्ट रजिस्ट्री - रिपॉज़िटरी पर जाएं और java-repo नाम की अपनी नई बनाई गई मेवन रिपॉज़िटरी पर ध्यान दें. उस पर क्लिक करने पर, आपको पता चलेगा कि फ़िलहाल यह रिपॉज़िटरी खाली है.

आर्टफ़ैक्ट रिपॉज़िटरी के लिए पुष्टि करने की सुविधा सेट अप करना

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

gcloud auth login --update-adc

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

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

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

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

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>

आर्टफ़ैक्ट रजिस्ट्री में अपना Java पैकेज अपलोड करना

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

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

mvn deploy

आर्टफ़ैक्ट रजिस्ट्री में जावा पैकेज देखना

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

9. बधाई हो!

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

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

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

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

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

gcloud projects delete $PROJECT_ID