نظرة متعمّقة على 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 نقطة رصد لخدمة Artifact Analysis من أجل المراقبة المستمرة للثغرات الأمنية المعروفة.
توفّر Cloud IAM تحكّمًا متسقًا ودقيقًا في الوصول إلى العناصر والأذونات.

سيرشدك هذا التمرين المعملي إلى العديد من هذه الميزات في شكل برنامج تعليمي عملي.

ما ستتعلمه

ما هي أهداف التعلّم من هذا الدرس التطبيقي؟

إنشاء مستودعات مختلفة للحاويات وحِزم اللغات
إنشاء صور حاويات واستخدامها مع Artifact Registry
استخدام Artifact Registry لتحليل وضع الأمان ومحتوى العناصر
ضبط Artifact Registry واستخدامه لملفات Java Maven التابعة

2. الإعداد والمتطلبات

إعداد البيئة بوتيرة ذاتية

سجِّل الدخول إلى Google Cloud Console وأنشِئ مشروعًا جديدًا أو أعِد استخدام مشروع حالي. إذا لم يكن لديك حساب على Gmail أو Google Workspace، عليك إنشاء حساب.

اسم المشروع هو الاسم المعروض للمشاركين في هذا المشروع. وهي سلسلة أحرف لا تستخدمها Google APIs. ويمكنك تعديلها في أي وقت.
رقم تعريف المشروع هو معرّف فريد في جميع مشاريع 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

الحصول على رمز المصدر

يتوفّر الرمز المصدر لهذا المختبر في مؤسسة GoogleCloudPlatform على GitHub. استنسِخه باستخدام الأمر أدناه.

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

3- نقل صور الحاويات

إنشاء مستودع Docker على Artifact Registry

كما ذكرنا سابقًا، تتيح خدمة 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. إذا نقرت عليه، يمكنك ملاحظة أنّه فارغ في الوقت الحالي.

ضبط مصادقة Docker في Artifact Registry

عند الاتصال بـ Artifact Registry، يجب توفير بيانات الاعتماد من أجل منح إذن الوصول. بدلاً من إعداد بيانات اعتماد منفصلة، يمكن ضبط Docker لاستخدام بيانات اعتماد gcloud بسلاسة.

من Cloud Shell، شغِّل الأمر التالي لضبط Docker على استخدام Google Cloud CLI للمصادقة على الطلبات إلى Artifact Registry في المنطقة us-central1:

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

إذا كان الأمر سيطلب تأكيدًا لتغيير إعدادات Docker في Cloud Shell، اضغط على Enter.

استكشاف التطبيق النموذجي

يتم توفير نموذج تطبيق في مستودع git الذي نسخته في خطوة سابقة. انتقِل إلى دليل Java وراجِع الرمز البرمجي للتطبيق.

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

يحتوي المجلد على مثال لتطبيق Java يعرض صفحة ويب بسيطة: بالإضافة إلى ملفات مختلفة غير ذات صلة بهذا التمرين العملي، يحتوي المجلد على الرمز المصدر ضمن المجلد src، وملف Dockerfile سنستخدمه لإنشاء صورة حاوية.

إنشاء صورة الحاوية

قبل أن تتمكّن من تخزين صور الحاويات في Artifact Registry، عليك إنشاء صورة.

نفِّذ الأمر التالي لإنشاء صورة الحاوية ووضع علامة عليها باستخدام مسار 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 - المستودعات. افتح المستودع container-example وتأكَّد من وجود الصورة java-hello-world.

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

4. فحص صور الحاويات

بعد أن أرسلت صورتك الأولى إلى مستودع container-example، يمكننا إلقاء نظرة عليها بمزيد من التفصيل. في علامة التبويب "الإصدارات"، انقر على الإصدار الذي أنشأناه للتو. لعرض الصورة بتفاصيل أكثر:

يكون زر النسخ العلوي مفيدًا بشكل خاص لأنّه يوفّر طريقة سهلة للوصول إلى معرّف الموارد المنتظم (URI) المؤهَّل بالكامل لنسخة الصورة هذه، بما في ذلك تجزئة SHA. يمكن بعد ذلك استخدام معرّف الموارد المنتظم هذا لجلب إصدار صورة معيّن أو كمرجع صورة في عملية نشر Kubernetes أو خدمة Cloud Run. لاختبار معرّف الموارد المنتظم (URI) الخاص بالصورة، يمكنك تنفيذ الأمر التالي في Cloud Shell:

docker pull $IMAGE_URI

فهم الاعتماديات

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

إذا دقّقت النظر، ستلاحظ أنّ معلومات قائمة SBOM لم تتم تعبئتها بعد. لملء بيان صحة البرامج (SOM) الخاص بالعنصر، يمكنك تنفيذ الأمر التالي في Cloud Shell باستخدام معرّف الموارد المنتظم (URI) المؤهَّل بالكامل للصورة والذي يمكننا نسخه من شريط التنقّل في أعلى الصفحة.

gcloud artifacts sbom export --uri $IMAGE_URI

بعد إعادة تحميل الصفحة، ستتضمّن الآن رابطًا إلى قائمة BOM التي تم إنشاؤها تلقائيًا والمخزّنة في Cloud Storage. إذا كنت تعتمد على قوائم المواد البرمجية (SBOM) لصورك، يمكنك إنشاء قوائم المواد البرمجية تلقائيًا للنتائج وجعل عملية الإنشاء جزءًا من مسار CI/CD.

استكشاف الثغرات الأمنية في الصور

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

إنشاء مستودع افتراضي

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

لتبسيط الاستخدام وإخفاء المستودعات الأساسية خلف طبقة تجريدية، يمكنك إنشاء مستودع افتراضي في 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

بعد انتهاء عملية النشر، سيظهر عنوان URL الذي تم إنشاؤه تلقائيًا والذي يمكنك من خلاله الوصول إلى خدمتك.

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

إذا فتحت عنوان URL هذا في علامة تبويب متصفّح جديدة، من المفترض أن تظهر لك الرسالة "Hello World" التي تشير إلى نجاح العملية.

7. تعزيز أمان سلسلة التوريد

بعد أن تم نشر صورة الحاوية، قد يكون الوقت مناسبًا للنظر في كيفية تعزيز سلسلة الإمداد الشاملة. في القسم السابق، تعرّفنا على كيفية تقديم تحليل الحاويات في Artifact Registry لإحصاءات حول المكتبات والتراخيص المستخدَمة في الصورة. ومع ذلك، لا يزال بإمكان الجهات المسيئة إدخال محتوى ضارّ في صورتك على طول سلسلة الإمداد. في هذا القسم، سنتعرّف على كيفية استخدام إطار عمل SLSA لتقديم شهادة مصادقة لنتائج الإنشاء، والاستفادة من التواقيع المشفرة للنتائج نفسها لضمان إمكانية نشر النتائج الموثوق بها فقط في وقت تشغيل Cloud Run.

شهادة اعتماد SLSA باستخدام Cloud Build

يوفّر إطار عمل SLSA مستويات مختلفة من الأدلة على عناصر سلسلة الإمداد. قد تبدو المواصفات والتنفيذ أمرًا شاقًا للوهلة الأولى، ولكن مع Cloud Build، يصبح إنشاء شهادة SLSA بسيطًا مثل إضافة مواصفات cloudbuild.yaml مع ضبط requestedVerifyOption على VERIFIED.

بالنسبة إلى تطبيقنا، يمكننا تنفيذ الأمر التالي في Cloud Shell لإنشاء ملف cloudbuild.yaml في المجلد helloworld.

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 جديدة تنشئ إصدارًا جديدًا من صورة Java Hello World من خلال تنفيذ الأمر التالي في Cloud Shell.

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

بعد اكتمال عملية الإنشاء، يمكننا الانتقال إلى واجهة مستخدم Cloud Build في Google Cloud Console وعرض مستوى SLSA الذي حقّقناه من خلال فتح عملية الإنشاء ثم الاطّلاع على "نتائج الإنشاء" ضمن "ملخّص الإنشاء". تحتوي الصورة المعروضة على زر للاطّلاع على "إحصاءات الأمان". عند النقر عليه، سترى شهادة SLSA بالإضافة إلى تقارير الثغرات الأمنية المألوفة التي رأيناها من قبل في واجهة مستخدم Artifact Registry عند إرسال الإصدار المحلي.

يمكن أيضًا استرداد مستند تحديد المصدر الخاص بـ SLSA لصورتنا من خلال تنفيذ الأمر التالي في Cloud Shell:

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

فرض استخدام مستندات المصدر في Cloud Build مع خدمة Binary Authorization

بعد إعداد مسار Cloud Build، ألن يكون من الرائع التأكّد من أنّ جميع الصور التي ننشرها في مرحلة الإنتاج قد تم إنشاؤها باستخدام بيئة الإنشاء القابلة للبرمجة والتكرار هذه؟

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

لتغيير إعدادات Binary Authorization التلقائية لمشروعنا من أجل طلب شهادة مصادقة مضمّنة صادرة عن 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

لنختبر ما إذا تم تطبيق Binary Authorization بشكل صحيح من خلال إعادة نشر الصورة التي تم إنشاؤها محليًا أولاً

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 في Artifact Registry وتحميل حِزم إليه، والاستفادة منها في تطبيقات مختلفة.

إنشاء مستودع حِزم Maven

من Cloud Shell، شغِّل الأمر التالي لإنشاء مستودع لعناصر Java:

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

انقر على "تفويض" إذا ظهر طلب تفويض Cloud Shell

انتقِل إلى Google Cloud Console - Artifact Registry - المستودعات ولاحظ مستودع Maven الذي أنشأته حديثًا باسم java-repo. إذا نقرت عليه، ستلاحظ أنّه فارغ في الوقت الحالي.

إعداد المصادقة في Artifact Repository

استخدِم الأمر التالي لتعديل الموقع المعروف لبيانات الاعتماد التلقائية للتطبيق (ADC) باستخدام بيانات اعتماد حساب المستخدم حتى يتمكّن مساعد بيانات اعتماد Artifact Registry من المصادقة باستخدامها عند الربط بالمستودعات:

gcloud auth login --update-adc

ضبط Maven لخدمة Artifact Registry

نفِّذ الأمر التالي لطباعة إعدادات المستودع التي ستتم إضافتها إلى مشروع Java:

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

افتح ملف pom.xml في "محرِّر Cloud Shell" من خلال تنفيذ الأمر التالي في Cloud Shell من داخل دليل helloworld:

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 إلى Artifact Registry

بعد إعداد Artifact Registry في Maven، يمكنك الآن استخدام Artifact Registry لتخزين ملفات Java JAR لاستخدامها في مشاريع أخرى في مؤسستك.

نفِّذ الأمر التالي لتحميل حزمة Java إلى Artifact Registry:

mvn deploy

التحقّق من حزمة Java في Artifact Registry

انتقِل إلى Cloud Console - Artifact Registry - المستودعات. انقر على java-repo وتأكَّد من توفّر العنصر الثنائي helloworld:

9- تهانينا!

تهانينا، لقد أكملت درس البرمجة.

المواضيع التي تناولناها

إنشاء مستودعات للحاويات وحِزم اللغات
صور الحاويات المُدارة باستخدام Artifact Registry
دمج Artifact Registry مع Cloud Code
ضبط Maven لاستخدام Artifact Registry في عمليات الربط بين حِزم Java

تنظيف

نفِّذ الأمر التالي في Cloud Shell لحذف المشروع بأكمله

gcloud projects delete $PROJECT_ID