סקירה מפורטת של Artifact Registry

1. סקירה כללית

‫Artifact Registry הוא כלי לניהול חבילות שמנוהל באופן מלא, והוא מספק כלי מאוחד לניהול קובצי אימג' של קונטיינרים וחבילות שפה (כמו Maven ו-npm) של OCI.

‫Artifact Registry משולב באופן מלא עם מגוון רחב של שירותים אחרים של Google Cloud, כמו בדוגמאות הבאות:

‫Cloud Build יכול להעלות ישירות ארטיפקטים של תמונות ל-Artifact Registry.
‫Cloud Deploy יכול לפרוס את התמונות של Artifact Registry ישירות לסביבות שונות של זמן ריצה.
הוא מספק תמונות לזמני הריצה של הקונטיינרים, כמו Cloud Run ו-GKE, ומאפשר יכולות מתקדמות של אופטימיזציה של הביצועים, כמו סטרימינג של תמונות.
Artifact Registry יכול לשמש כנקודת זיהוי ל-Artifact Analysis, כדי לעקוב באופן רציף אחרי פגיעויות מוכרות.
ב-Cloud IAM אפשר לנהל הרשאות גישה לארטיפקטים בצורה עקבית ומפורטת.

בשיעור ה-Lab הזה תלמדו על הרבה מהתכונות האלה באמצעות מדריך מעשי.

מה תלמדו

מהם יעדי הלמידה של שיעור ה-Lab הזה?

יצירת מאגרים שונים עבור מאגרי תגים וחבילות שפה
יצירה ושימוש בתמונות של קונטיינרים באמצעות Artifact Registry
שימוש ב-Artifact Registry כדי לנתח את מצב האבטחה והתוכן של הארטיפקטים
הגדרה ושימוש ב-Artifact Registry ליחסי תלות של Java Maven

2. הגדרה ודרישות

הגדרת סביבה בקצב עצמי

נכנסים ל-מסוף Google Cloud ויוצרים פרויקט חדש או משתמשים בפרויקט קיים. אם עדיין אין לכם חשבון Gmail או Google Workspace, אתם צריכים ליצור חשבון.

שם הפרויקט הוא השם המוצג של הפרויקט הזה למשתתפים. זו מחרוזת תווים שלא נמצאת בשימוש ב-Google APIs. תמיד אפשר לעדכן את המיקום.
מזהה הפרויקט הוא ייחודי לכל הפרויקטים ב-Google Cloud ואי אפשר לשנות אותו אחרי שהוא מוגדר. מסוף Cloud יוצר באופן אוטומטי מחרוזת ייחודית, ובדרך כלל לא צריך לדעת מה היא. ברוב ה-Codelabs, תצטרכו להפנות למזהה הפרויקט (בדרך כלל מסומן כ-PROJECT_ID). אם אתם לא אוהבים את המזהה שנוצר, אתם יכולים ליצור מזהה אקראי אחר. אפשר גם לנסות שם משתמש משלכם ולבדוק אם הוא זמין. אי אפשר לשנות את ההגדרה הזו אחרי השלב הזה, והיא תישאר לאורך הפרויקט.
לידיעתכם, יש ערך שלישי, מספר פרויקט, שחלק מממשקי ה-API משתמשים בו. במאמרי העזרה מפורט מידע נוסף על שלושת הערכים האלה.

בשלב הבא, תצטרכו להפעיל את החיוב במסוף Cloud כדי להשתמש במשאבי Cloud או בממשקי API של Cloud. השלמת ה-codelab הזה לא תעלה לכם הרבה, אם בכלל. כדי להשבית את המשאבים ולמנוע חיובים נוספים אחרי שתסיימו את המדריך הזה, תוכלו למחוק את המשאבים שיצרתם או למחוק את הפרויקט. משתמשים חדשים ב-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

קבלת קוד המקור

קוד המקור של שיעור ה-Lab הזה נמצא בארגון GoogleCloudPlatform ב-GitHub. משכפלים אותו באמצעות הפקודה שלמטה.

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

3. העלאה של קובצי אימג' של קונטיינרים

יצירת מאגר Docker ב-Artifact Registry

כמו שצוין קודם, Artifact Registry תומך בפורמטים שונים של מאגרי מידע שמאפשרים לכם לנהל קובצי אימג' של קונטיינרים וחבילות שפה. האינטראקציות עם סוגים שונים של מאגרי ארטיפקטים מוגדרות במפרטים והן סטנדרטים מקובלים. לדוגמה, הבקשות לתלות ב-Maven שונות מהבקשות לתלות ב-Node.

כדי לתמוך במפרטי API של ארטיפקטים ספציפיים, 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, לוחצים על Authorize (אישור).

עוברים אל מסוף Google Cloud – 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 – Repositories. פותחים את מאגר container-example ומוודאים שקובץ האימג' java-hello-world נמצא שם.

לוחצים על התמונה ומסתכלים על התמונה שתויגה בתווית tag1. הפעלנו סריקה אוטומטית של תמונות באמצעות השירות containerscanning.googleapis.com, ולכן אפשר לראות שהסריקה של נקודות החולשה פועלת או שכבר הסתיימה. אחרי שהבדיקה מסתיימת, אפשר לראות את מספר נקודות החולשה שזוהו בגרסה הזו של התמונה. בקטע הבא נסביר על נקודות חולשה ועל תובנות אחרות לגבי ארטיפקטים.

4. בדיקת קובצי אימג' של קונטיינרים

עכשיו, אחרי שדחפתם את התמונה הראשונה למאגר container-example, אפשר לבדוק אותה בפירוט. בכרטיסייה Versions (גרסאות), לוחצים על הגרסה שיצרנו. כדי לראות את התמונה בפירוט רב יותר:

כפתור ההעתקה העליון שימושי במיוחד כי הוא מספק דרך קלה לגשת ל-URI המלא של התמונה, כולל הגיבוב SHA, של גרסת התמונה הזו. אחר כך אפשר להשתמש ב-URI הזה כדי לשלוף גרסה ספציפית של תמונה או כהפניה לתמונה ב-Kubernetes Deployment או ב-Cloud Run Service. כדי לבדוק את ה-URI של התמונה, אפשר להריץ את הפקודה הבאה ב-Cloud Shell:

docker pull $IMAGE_URI

הסבר על יחסי תלות

בכרטיסייה 'תלויות' בחלק העליון אפשר לראות את כל התלויות שזוהו בתמונה. שימו לב: הרשימה כוללת את התלויות ברמת השפה וברמת מערכת ההפעלה. אפשר גם לראות את רישיונות התוכנה שמצורפים לכל אחת מהתלויות.

אם תתבוננו מקרוב, תראו שפרטי ה-SBOM עדיין לא הוזנו. כדי לאכלס את ה-SOM של הארטיפקט, אפשר להריץ את הפקודה הבאה ב-Cloud Shell באמצעות ה-URI המוגדר במלואו של התמונה שאפשר להעתיק מסרגל הניווט בחלק העליון.

gcloud artifacts sbom export --uri $IMAGE_URI

אחרי רענון הדף, הוא יכלול קישור ל-SBOM שנוצר אוטומטית ומאוחסן ב-Cloud Storage. אם אתם מסתמכים על SBOMs לתמונות שלכם, כדאי ליצור באופן אוטומטי SBOMs לארטיפקטים שלכם ולהפוך את היצירה לחלק מצינור ה-CI/CD שלכם.

בדיקת נקודות חולשה בתמונות

כשלוחצים על הכרטיסייה 'פגיעויות' בחלק העליון של התצוגה, אפשר לראות את כל הפגיעויות שזוהו בתמונה. בנוסף לסיכום של נקודות החולשה בחלק העליון, אפשר לראות את הרשימה המלאה של נקודות החולשה בטבלה שבתחתית. כל שורה מקושרת ל-CVE bulletin, ומצוינת בה רמת החומרה והחבילה שממנה היא הגיעה. במקרים של נקודות חולשה שקיים תיקון עבורן, המאמר גם מספק הוראות לעדכון התלות כדי לתקן את נקודת החולשה.

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 ולראות שקובץ ה-image של nginx שנשמר במטמון מספק עכשיו את אותם דוחות תלות ונקודות חולשה שראינו לגבי קובץ ה-image שבניתם בעצמכם.

יצירת מאגר וירטואלי

אפשר ליצור מספר מאגרי מידע לכל צוות או עסק באמצעות התהליכים שבהם השתמשנו עד עכשיו, ולהגדיר בבירור את הבעלות וההרשאות ב-IAM לכל מאגר מידע. אנחנו יכולים גם ליצור שרתי proxy למאגרי מידע מרוחקים, כדי שיהיה קל יותר ובטוח יותר לצרוך תמונות של צד שלישי. החיסרון של מספר המאגרים הגדול הזה ברור אם משנים את נקודת המבט לצרכן של התמונות האלה. איך מפתח יכול לדעת באיזה מאגר תמונות עליו להשתמש בפריסה שלו?

כדי לפשט את השימוש במאגרי המידע הבסיסיים ולהסתיר אותם מאחורי שכבת הפשטה, אפשר ליצור מאגר מידע וירטואלי ב-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

ה-framework של SLSA מספק רמות שונות של הוכחות לגבי ארטיפקטים של שרשרת האספקה. במבט ראשון, יכול להיות שהמפרט וההטמעה נראים מאיימים, אבל עם Cloud Build, יצירת אישור SLSA היא פשוטה כמו יצירת מפרט cloudbuild.yaml עם requestedVerifyOption שמוגדר ל-VERIFIED.

כדי ליצור קובץ cloudbuild.yaml בתיקייה helloworld, מריצים את הפקודה הבאה ב-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 חדשה שיוצרת גרסה חדשה של קובץ האימג' 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 ולראות את רמת ה-SLSA שהשגנו. לשם כך, פותחים את הבנייה ומסתכלים על Build Artifacts (פריטי בנייה) בקטע Build Summary (סיכום הבנייה). בתמונה שמוצגת שם יש לחצן שמאפשר לראות את 'תובנות האבטחה'. כשלוחצים עליו, רואים את אישור ה-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 Provenance באמצעות Binary Authorization

אחרי שמגדירים את צינור הנתונים של Cloud Build, כדאי לוודא שכל התמונות שפורסות בסביבת הייצור נוצרו באמצעות סביבת ה-build הניתנת לתכנות ולשחזור.

כאן נכנס לתמונה Binary Authorization. הוא מאפשר לכם להציב שומר סף לפני זמני הריצה של הקונטיינרים, שבודק את קובץ אימג' של קונטיינר ומוודא שקיימת הצהרה מהימנה. אם לא נמצא אישור, המערכת יוצרת רשומות ביומן הביקורת או חוסמת את הפריסה לגמרי, בהתאם להגדרה.

כדי לשנות את הגדרת ברירת המחדל של Binary Authorization בפרויקט שלנו כך שתידרש אימות (attestation) מובנה שהונפק על ידי 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

כמובן שאפשר גם להוסיף כאן גורמים מאמתים (attestors) מותאמים אישית, אבל זה לא חלק מה-Codelab הזה, וזו תרגיל בית אופציונלי.

כדי לאכוף אישור בינארי בשירות 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, לוחצים על Authorize (אישור).

עוברים אל מסוף Google Cloud - Artifact Registry - Repositories (מאגר ארטיפקטים – מאגרי מידע) ורואים את מאגר Maven החדש שנוצר בשם java-repo. אם לוחצים עליו, אפשר לראות שהוא ריק כרגע.

הגדרת אימות ל-Artifact Repository

כדי לעדכן את המיקום המוכר של Application Default Credentials ‏ (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 Editor על ידי הרצת הפקודה הבאה ב-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

 <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 (תוספים) בקטע build (פיתוח)

   <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 כדי לאחסן קובצי JAR של Java לשימוש בפרויקטים אחרים בארגון.

מריצים את הפקודה הבאה כדי להעלות את חבילת Java אל Artifact Registry:

mvn deploy

בדיקת חבילת Java ב-Artifact Registry

עוברים אל Cloud Console - Artifact Registry - Repositories. לוחצים על java-repo ומוודאים שפריט המידע הבינארי helloworld נמצא שם:

9. מעולה!

כל הכבוד, סיימתם את ה-Codelab!

מה נכלל

מאגרי מידע שנוצרו לקונטיינרים ולחבילות שפה
תמונות קונטיינרים מנוהלות באמצעות Artifact Registry
שילוב של Artifact Registry עם Cloud Code
הגדרת Maven לשימוש ב-Artifact Registry ליחסי תלות של Java

הסרת המשאבים

מריצים את הפקודה הבאה ב-Cloud Shell כדי למחוק את כל הפרויקט

gcloud projects delete $PROJECT_ID