تمت ترجمة هذه الصفحة بواسطة Cloud Translation API‏.

نظرة متعمّقة على Artifact Registry

1. نظرة عامة

Artifact Registry هو أداة مُدارة بالكامل لإدارة الحِزم، كما يوفّر أداة موحّدة لإدارة صور حاويات OCI وحِزم اللغات (مثل Maven وnpm).

يتم دمج "مستودع العناصر" بالكامل مع مجموعة واسعة من خدمات Google Cloud الأخرى، كما هو موضّح في الأمثلة التالية:

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

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

ما ستتعرّف عليه

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

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

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

إعداد البيئة حسب وتيرة الطالب واحتياجاته

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

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

شغِّل الأمر التالي لإنشاء صورة الحاوية وتصنيفها باستخدام مسار سجلّ العناصر الكامل:

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 - Artifact Registry - Repositories (وحدة تحكّم Google Cloud - سجلّ العناصر - المستودعات). افتح مستودع container-example وتأكَّد من توفّر الصورة java-hello-world.

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

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

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

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

docker pull $IMAGE_URI

فهم التبعيات

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

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

gcloud artifacts sbom export --uri $IMAGE_URI

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

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

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

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

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 لإنشاء إصدار جديد من صورة Hello World في Java من خلال تنفيذ الأمر التالي في 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 باستخدام ميزة "تفويض البرامج الثنائي"

مع توفّر مسار الإدراج في 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 في 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 - Repositories (مستودعات سجلّ العناصر) ولاحظ مستودع Maven الذي تم إنشاؤه حديثًا باسم java-repo. إذا نقرت عليه، ستلاحظ أنّه فارغ في الوقت الحالي.

إعداد المصادقة في مستودع العناصر

استخدِم الأمر التالي لتعديل الموقع المعروف لـ "بيانات اعتماد التطبيق التلقائية" (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 - سجلّ العناصر - المستودعات. انقر على java-repo وتأكَّد من توفّر العنصر الثنائي helloworld:

9. تهانينا!

تهانينا، لقد أكملت دورة codelab.

المحتوى الذي سبق لك تغطيته

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

تنظيف

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

gcloud projects delete $PROJECT_ID