‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

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

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

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

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

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

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

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

docker pull $IMAGE_URI

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

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

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

gcloud artifacts sbom export --uri $IMAGE_URI

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

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

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

כדי לשנות את הגדרת ברירת המחדל של 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

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

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

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