סקירה כללית של מאגר

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

כשיוצרים את המאגרים, צריך להביא בחשבון גם את התהליכים הפנימיים ליצירת פריטי המידע שנוצרים בתהליך פיתוח (Artifact) וגם את השימוש של הצרכנים בפריטים האלה.

פורמטים של מאגרים

כל מאגר משויך לפורמט ספציפי של ארטיפקט. לדוגמה, מאגר Docker מאחסן קובצי אימג' של Docker. אפשר ליצור כמה מאגרי מידע לכל פורמט באותו פרויקט Google Cloud .

מצבי מאגר

יש כמה מצבי מאגר. לכל מצב יש מטרה אחרת, ולכן אי אפשר לשנות את מצב המאגר אחרי שיוצרים אותו.

מאגר רגיל

מאגרים רגילים הם מאגרי Artifact Registry רגילים של הארטיפקטים הפרטיים שלכם. אתם יכולים להעלות ולהוריד ארטיפקטים ישירות למאגרי הארטיפקטים האלה, ולהשתמש ב-Artifact Analysis כדי לסרוק פגיעויות ומטא-נתונים אחרים.

כדי ליצור מאגרי מידע רגילים, פועלים לפי השלבים במאמר יצירת מאגרי מידע רגילים.

מאגר מרוחק

מאגרים מרוחקים הם מאגרים לקריאה בלבד שמשמשים כשרתי proxy לאחסון ארטיפקטים מהמקורות הבאים במעלה הזרם:

  • מאגרי Artifact Registry רגילים.
  • מקורות חיצוניים כמו Docker Hub, ‏ Maven Central, ‏ Python Package Index‏ (PyPI), ‏ Debian או CentOS.

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

מאגרי מידע מרוחקים מפחיתים את זמן האחזור ומשפרים את הזמינות של גרסאות build ופריסות ב- Google Cloud. אפשר גם להשתמש ב-Artifact Analysis כדי לסרוק חבילות שנשמרו במטמון ולחפש בהן נקודות חולשה ומטא-נתונים אחרים.

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

מאגר מחברים (גרסת טרום-השקה)

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

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

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

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

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

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

דוגמה לשימוש במאגר

הדיאגרמה הבאה מציגה אחת מהדרכים האפשריות הרבות לשימוש במאגרי מידע במצבים שונים. בתרשים מוצג תהליך עבודה בשני פרויקטים.Google Cloud בפרויקט פיתוח, מפתחים בונים אפליקציית Java. בפרויקט נפרד של זמן ריצה, עוד build יוצר תמונת קונטיינר עם האפליקציה לפריסה ב-Google Kubernetes Engine.

מאגרי מידע רגילים, וירטואליים ומרוחקים שמשמשים בשני פרויקטים.

  1. בפרויקט הפיתוח, צוות פיתוח ב-Java משתמש ב-Cloud Build כדי ליצור אפליקציית Java.

    • ה-build יכול לבקש יחסי תלות ציבוריים של Java באמצעות המאגר הווירטואלי. המאגר הווירטואלי מציג את התלויות מהמאגר המרוחק, שהוא שרת proxy של מטמון ל-Maven Central.
    • ‫Cloud Build מעלה את החבילה למאגר Maven הרגיל בפרויקט הרכיב.

  2. בפרויקט של זמן הריצה, Cloud Build יוצר קונטיינר לאפליקציית Java.

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

  3. בפרויקט של זמן הריצה, Cloud Build מעלה את קובץ האימג' של הקונטיינר שנבנה למאגר Docker רגיל.

  4. ‫GKE שולף תמונות ממאגר וירטואלי של Docker.

    • מאגר Docker הסטנדרטי שלמעלה מספק תמונות פרטיות, כמו אפליקציית Java בקונטיינר.
    • המאגר המרוחק במעלה הזרם מספק תמונות ש-GKE מבקש מ-Docker Hub.

בדוגמה הזו, כל המאגרים, הבנייה ואשכולות GKE נמצאים באותו אזור. יש יתרונות לשימוש באותו מיקום עבור Google Cloud services כפי שמתואר במאמר מיקום המאגר.

מיקום המאגר

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

שיקולים בקשר למיקום

בקטע הזה מוסבר למה כדאי ליצור מאגר באותו אזור כמו שאר Google Cloud השירותים.

כדי להקטין את זמן האחזור ואת העלויות של תעבורת נתונים יוצאת (egress) מהרשת, אפשר ליצור מאגרי תמונות באותו אזור שבו מריצים את GKE,‏ Cloud Run, ‏ Cloud Build ושירותים אחרים של Google Cloud שיוצרים אינטראקציה עם מאגר התמונות. אין חיוב על תעבורת נתונים יוצאת (egress) מ-Artifact Registry לשירותים אחרים של Google Cloud באותו אזור.

למרות שאין תשלום על יציאה מאחסון במספר אזורים אל שירותGoogle Cloud באזור תואם, התמחור הזה חל רק על קבוצה מוגבלת של אזורים.

  • בus אזור מרובה, תעבורת נתונים יוצאת (egress) לאזור בארצות הברית, כמו us-central, לא מחויבת, אבל יציאה לאזור בקנדה או באמריקה הדרומית כן מחויבת.
  • במקרה של asia במספר אזורים, תעבורת נתונים יוצאת (egress) לאזורים באסיה כמו asia-northeast1 לא כרוכה בתשלום, אבל תעבורת נתונים יוצאת (egress) לאזורים באוסטרליה כן כרוכה בתשלום.
אפשר להשתמש בהזרמת תמונות רק ב-GKE וב-Managed Service for Apache Spark אם תמונות הקונטיינר מאוחסנות במאגרי Artifact Registry באותו אזור כמו עומסי העבודה, או באזור שמתאים לאזור שבו נמצאים עומסי העבודה. הזרמת תמונות יכולה לקצר משמעותית את זמן האתחול של עומסי עבודה כשמשתמשים בתמונות גדולות יותר של קונטיינרים, כי אפשר להתחיל את עומסי העבודה לפני שהתמונה כולה מורדת.

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

הגבלת מיקומי מאגרים

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

מדיניות בנושא ניקוי

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

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

אם גרסת ארטיפקט תואמת לקריטריונים של מדיניות מחיקה וגם של מדיניות שמירה, מערכת Artifact Registry תחיל את מדיניות השמירה.

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

מדיניות מחיקה מוחקת ארטיפקטים שתואמים לקריטריונים הבאים:

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

    • כל סטטוס של תג: המערכת מתעלמת מהסטטוס של התג ומתייחסת גם לארטיפקטים מתויגים וגם לארטיפקטים לא מתויגים.
    • Tagged (מתויג): רלוונטי רק לארטיפקטים מתויגים.
    • Untagged (לא מתויג): רלוונטי רק לפריטי מידע שנוצרו בתהליך הפיתוח שלא מתויגים.

    פורמטים שלא תומכים בתגים נחשבים ל-untagged. אי אפשר למחוק ארטיפקטים שתויגו במאגרי תגים עם תגים שלא ניתן לשנות.

    מידע נוסף על מצב התג בהקשר של מדיניות ניקוי זמין במאמר בנושא TagState.

אפשר להשתמש בכל אחת מההגדרות הבאות כדי לקבוע את מדיניות המחיקה:

  • Tag prefixes: is a comma-separated list of tag prefixes. לדוגמה, הקידומות test ו-staging יתאימו לתמונות עם התגים testenv ו-staging-1.5. כדי להשתמש בתחיליות של תגים, צריך להגדיר את tagState ל-TAGGED.
    • קידומות של גרסאות: – רשימה מופרדת בפסיקים של קידומות של גרסאות ארטיפקטים. לדוגמה, v1, v2 יתאים לגרסאות v1.5, v2.0alpha ו-v10.2.
  • Package prefixes (קידומות של חבילות): רשימה של קידומות של שמות ארטיפקטים. כדי להזין כמה קידומות, מקישים על Enter או על , בין הקידומות. לדוגמה, red, blue ייצור שתי קידומות, red ו-blue, ויתאים לשמות של ארטיפקטים red-team, redis ו-bluebird.
  • ישן יותר מ: הזמן המינימלי שעבר מאז שגרסת ארטיפקט הועלתה למאגר, שמוגדר כמשך זמן. לדוגמה, 30d הוא 30 יום. אפשר לציין משכי זמן בשניות, בדקות, בשעות או בימים על ידי הוספת s, m, h או d בהתאמה.
  • חדש יותר מ: משך הזמן המקסימלי שעבר מאז שגרסת ארטיפקט הועלתה למאגר, שמוגדר כמשך זמן. לדוגמה, 30d הוא 30 יום.

שימוש במדיניות שמירת נתונים

מדיניות השמירה שומרת ארטיפקטים שתואמים לאותם תנאים כמו מדיניות המחיקה, או מספר מוגדר של הגרסאות האחרונות.

לדוגמה, אם יש מאגר שמכיל את הארטיפקטים הבאים:

IMAGE: us-west1-docker.pkg.dev/my-project/release-xyz-v1
DIGEST: sha256:1b0a26bd07a3d17473d8d8468bea84015e27f87124b2831234581bce13f61370
TAGS:
CREATE_TIME: 2023-06-19T18:59:09
UPDATE_TIME: 2023-06-19T18:59:10

IMAGE: us-west1-docker.pkg.dev/my-project/release-xyz-v2
DIGEST: sha256:6e494387c901caf429c1bf77bd92fb82b33a68c0e19f123456a3ac8d27a7049d
TAGS: latest
CREATE_TIME: 2023-06-19T18:59:09
UPDATE_TIME: 2023-06-19T18:59:09

IMAGE: us-west1-docker.pkg.dev/my-project/release-v2
DIGEST: sha256:6e494387c901caf429c1bf77bd92fb82b33a68c0e19f123456a3ac8d27a7049d
TAGS: latest
CREATE_TIME: 2023-06-19T18:59:09
UPDATE_TIME: 2023-06-19T18:59:09

אם המדיניות Keep most recent versions מוגדרת לשמירת 3 גרסאות של חבילות שתואמות לPackage prefixes: {release-xyz}, רק הגרסאות release-xyz-v1 ו-release-xyz-v2 יישמרו.

מחיקות שמופעלות על ידי מדיניות מחיקה נספרות במכסה של בקשות המחיקה לכל פרויקט ב-Artifact Registry.

במאמר הגדרת מדיניות ניקוי מוסבר איך ליצור מדיניות ניקוי ולהחיל אותה על המאגר.

תמיכה בדומיין gcr.io

‫Artifact Registry תומך באירוח תמונות בדומיין gcr.io. אם אתם עוברים מ-Container Registry ל-Artifact Registry, אתם יכולים להגדיר מאגרי gcr.io ב-Artifact Registry כדי למזער את השינויים באוטומציה ובתהליכי העבודה הקיימים. המאגרים האלה מספקים:

  • הפניה אוטומטית של בקשות לדומיין gcr.io.
  • יצירה של מאגרי gcr.io כשמעבירים בדחיפה את התמונה הראשונה לשם מארח gcr.io, לצורך תאימות להתנהגות של Container Registry.

מידע נוסף זמין במאמר בנושא מעבר למאגרי תמונות עם תמיכה בדומיין gcr.io

מבנה הפרויקט

היררכיית המשאבים היא הדרך שבה אתם מארגנים את המשאבים בפרויקטים של Google Cloud . המבנה שתבחרו תלוי בגורמים כמו דרישות משילות הנתונים, גבולות האמון ומבנה הצוות.

יש שתי גישות כלליות להגדרת המאגרים בארגונים עם כמה פרויקטים.

ריכוז מאגרי נתונים

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

הוא גם יכול לפשט את ההגדרה של מאגרי מידע וירטואליים, כי צריך רק להפעיל ולנהל מופע יחיד של Artifact Registry.

מאגרים ספציפיים לפרויקט

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

בקרת גישה

הגישה למאגרים אפשרית רק עם ההרשאות המתאימות, אלא אם מגדירים את המאגר לגישה ציבורית. אפשר להעניק הרשאות ברמת הפרויקט או ברמת המאגר.

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

  • ‫Artifact Registry נמצא בפרויקט אחר מהשירות שמתקשר איתו.
  • אתם משתמשים בתפקידי IAM בהתאמה אישית עם חשבונות השירות שמוגדרים כברירת מחדל, במקום בתפקיד מוגדר מראש.
  • אתם לא משתמשים בחשבון השירות שמוגדר כברירת מחדל עבור השירות Google Cloud .
  • אתם מגדירים מאגרי מידע וירטואליים. צריך להעניק במפורש לחשבון השירות של Artifact Registry גישה למאגרי מידע במעלה הזרם.

לגבי גורמים אחרים שנדרשת להם גישה למאגרי קוד, האדמין של מאגר הקוד צריך להעניק גישה. כדי לשמור על עקרון האבטחה של הרשאות מינימליות, צריך לתת רק את ההרשאות הנדרשות. לדוגמה:

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

הגבלת הורדות של פריטי מידע שנוצרים בתהליך פיתוח (Artifact)

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

לפרטים על אופן הפעולה של כללי ההורדה, אפשר לעיין בקטע הגבלת ההורדה של ארטיפקטים במאמר 'סקירה כללית על בקרת גישה והגנה על ארטיפקטים'.

הצפנת נתונים

כברירת מחדל, Google Cloud הנתונים מוצפנים באופן אוטומטי כשהם במצב מנוחה באמצעות מפתחות הצפנה שבבעלות ובניהול של Google . אם יש לכם דרישות ספציפיות בנושא תאימות או רגולציה שקשורות למפתחות שמגנים על הנתונים, אתם יכולים ליצור מאגרי נתונים שמוצפנים באמצעות מפתחות הצפנה בניהול הלקוח (CMEK).

ב-Artifact Registry יש גם תמיכה באילוצים של מדיניות הארגון שיכולים לחייב שימוש ב-CMEK כדי להגן על משאבים.

תוויות ותגים

התוויות מאפשרות לארגן משאבים שספציפיים לשירות Google Cloud. ב-Artifact Registry, אפשר להוסיף תוויות למאגרי מידע כדי לקבץ אותם או לסנן את רשימות מאגרי המידע לפי תוויות. לדוגמה, אפשר להשתמש בתוויות כדי לקבץ מאגרי מידע לפי שלב פיתוח או לפי צוות, למטרות אוטומציה או חיוב. מידע נוסף על יצירה ושימוש בתוויות של מאגרי מידע זמין במאמר הוספת תוויות למאגרי מידע.

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

המאמרים הבאים