1. סקירה כללית
Artifact Registry הוא מנהל החבילות המנוהל לחלוטין, שמספק כלי מאוחד לניהול קובצי אימג' בקונטיינרים של OCI וחבילות שפה (כמו Maven ו-npm).
מאגר הארטיפקטים משולב באופן מלא עם מגוון רחב של שירותים אחרים של 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 משתמשים בו. מידע נוסף על כל שלושת הערכים האלה זמין במסמכי העזרה.
- בשלב הבא, כדי להשתמש במשאבים או ב-API של Cloud, תצטרכו להפעיל את החיוב במסוף 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.
כדי לתמוך במפרטי 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, צריך ליצור קובץ אימג'.
מריצים את הפקודה הבאה כדי ליצור את קובץ האימג' בקונטיינר ולתייג אותו בנתיב המלא של מאגר הארטיפקטים:
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 – 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, ומציינת את מידת החומרה שלו ואת החבילה שממנה הוא הגיע. בנקודות חולשה שיש להן תיקון זמין, מפורטות גם הוראות לעדכון יחסי התלות כדי לתקן את נקודת החולשה.
5. מאגרים וירטואליים ומרוחקים
בקטע הקודם השתמשנו במאגר תמונות יחיד כדי לדחוף ולשלוף את התמונות שלנו. הפתרון הזה מתאים מאוד לתרחישי שימוש בקנה מידה קטן, אבל הוא מציב אתגרים במיוחד לארגונים גדולים עם צוותים שונים שזקוקים לעצמאות במאגרים שלהם. לעתים קרובות, צוותים או יחידות עסקיות שונים משתמשים במאגר תמונות משלהם עם הגדרות והרשאות משלהם. כדי לפשט את השימוש בתמונות במאגרים האלה ולהגן על הצרכן מהמבנה הארגוני הבסיסי, Artifact Registry מספק מאגרים וירטואליים שיכולים לצבור משאבים ממספר מאגרים בסיסיים. ארכיטקטורה אפשרית עשויה להיראות כך:
מאגר מרוחק ל-Docker Hub
Docker Hub הוא מרשם ציבורי פופולרי של קובצי אימג', שמארח הרבה קובצי אימג' של קונטיינרים בקוד פתוח. השימוש במאגר הציבורי באופן ישיר הוא פשוט, אבל הוא כרוך בכמה אתגרים בסביבת הייצור, שאפשר להתגבר עליהם באמצעות מאגרים מרוחקים ב-Artifact Registry.
מאגרים מרוחקים מאפשרים להעביר את הבקשות לרשומת המקור באמצעות שרת proxy ולשמור את התמונות במטמון תוך כדי התהליך. כך לא רק מקצרים את זמני ההורדה של התמונות, אלא גם מסירים את התלות בזמן פעולה תקינה של השירות החיצוני, ומאפשרים לכם להחיל את אותן מדיניות אבטחה וגישה שאתם מחילים על התמונות שלכם.
כדי ליצור מאגר מרוחק ל-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:
כדי לבדוק אם המאגר המרוחק יכול להעביר בקשות ל-proxy למאגר המרוחק, מריצים את הפקודה הבאה ב-Cloud Shell כדי למשוך את קובץ האימג' של nginx:
docker pull us-central1-docker.pkg.dev/$PROJECT_ID/dockerhub/nginx:stable-alpine
אחרי שהשלמתם את פעולת ה-pull, תוכלו גם לעיין במאגר במסוף Cloud ולראות שקובץ האימג' של nginx ששמור במטמון מספק עכשיו את אותם דוחות על יחסי תלות ונקודות חולשה שראינו בקובץ האימג' שיצרתם בעצמכם.
יצירת מאגר וירטואלי
אם תפעלו לפי התהליכים שתיארנו עד עכשיו, תוכלו ליצור מספר מאגרים לכל צוות או עסק ולהגדיר בבירור את הבעלות והרשאות ה-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 כדי להוסיף אימות לארטיפקטים של ה-build, ואפילו להשתמש בחתימות קריפטוגרפיות של הארטיפקטים עצמם כדי להבטיח שרק ארטיפקטים מהימנים יוכלו לפרוס בסביבת זמן הריצה של 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 Shell כדי ליצור משימה חדשה ב-Cloud Build שתייצר גרסה חדשה של קובץ האימג' Hello World ב-Java.
gcloud builds submit --substitutions=_IMAGE_URI=us-central1-docker.pkg.dev/$PROJECT_ID/container-example/java-hello-world:cloud-build
אחרי שה-build יושלם, נוכל לעבור לממשק המשתמש של Cloud Build במסוף Google Cloud ולראות את רמת ה-SLSA שהשגנו. לשם כך, פותחים את ה-build ומעיינים ב-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. הוא מאפשר להציב שומר סף מול סביבת זמן הריצה של הקונטיינר, שבודק את קובץ האימג' בקונטיינר ומאמת את קיומו של אימות מהימן. אם לא נמצא אימות, המערכת יוצרת רשומות ביומן הביקורת או חוסמת את הפריסה לגמרי, בהתאם להגדרה.
כדי לשנות את הגדרת ברירת המחדל של 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
כדי ליצור מאגר לארטיפקטים של Java, מריצים את הפקודה הבאה ב-Cloud Shell:
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. מעולה!
כל הכבוד, סיימת את הקודלאב!
מה כבר כיסית
- יצירה של מאגרים לקונטיינרים ולחבילות שפה
- ניהול קובצי אימג' של קונטיינרים באמצעות Artifact Registry
- שילוב של Artifact Registry עם Cloud Code
- הגדרת Maven לשימוש ב-Artifact Registry לצורך ניהול יחסי התלות ב-Java
הסרת המשאבים
כדי למחוק את הפרויקט כולו, מריצים את הפקודה הבאה ב-Cloud Shell:
gcloud projects delete $PROJECT_ID