מאגרי Artifact Registry וירטואליים מאפשרים לכם לגשת לארטיפקטים באותו פורמט בכמה מאגרי upstream דרך נקודת קצה אחת. מאגרים וירטואליים יכולים לפשט את הגדרת הלקוח, לאפשר פתרון בטוח יותר של יחסי תלות ולעזור למנוע התקפות של בלבול ביחסי תלות.
במאמר יצירת מאגרים וירטואליים מוסבר איך יוצרים מאגר וירטואלי. המכסות והמגבלות של Artifact Registry חלות על מאגרים וירטואליים.
איך פועלים מאגרי מידע וירטואליים
מאגרים וירטואליים משמשים כנקודת גישה יחידה להורדה, להתקנה או לפריסה של ארטיפקטים באותו פורמט ממאגרים במעלה הזרם. מאגר במעלה הזרם יכול להיות מאגר רגיל או מאגר מרוחק של Artifact Registry.
תרחישים לדוגמה ויתרונות
- הגדרת לקוח פשוטה יותר
למשימות שדורשות רק גישת קריאה למאגרים, צריך להגדיר רק מאגר אחד ב-Artifact Registry כדי לגשת לפריטי מידע שמאוחסנים בכמה מאגרים במעלה הזרם.
לדוגמה:
- מאגר וירטואלי של חבילות Maven יכול להציג חבילות Java פרטיות ממאגר רגיל של Artifact Registry, וחבילות Java ציבוריות ממאגר מרוחק ששומר במטמון חבילות ציבוריות מ-Maven Central.
- מאגר וירטואלי יכול לספק חבילות Python פרטיות מכמה מאגרים סטנדרטיים במעלה הזרם שנמצאים בבעלות של צוותים שונים. לכל צוות יש גישת כתיבה למאגר המידע במעלה הזרם, אבל הוא מוריד חבילות מצוותים אחרים באמצעות המאגר הווירטואלי.
- פתרון בטוח יותר של תלויות
אתם יכולים להקצות עדיפות למאגרים במעלה הזרם כדי לקבל יותר שליטה על המאגר ש-Artifact Registry בוחר כשארטיפקט מבוקש נמצא ביותר ממאגר אחד במעלה הזרם.
חלק מהכלים, כמו הכלי Python
pip, לא מספקים דרך לשלוט בסדר החיפוש כשמוגדרים בלקוח מאגרים פרטיים וציבוריים. ההגדרה הזו חשופה להתקפה מסוג בלבול בתלות, שבה מישהו מעלה גרסה חדשה של חבילה עם קוד פגום למאגר ציבורי כדי להטעות לקוחות ולגרום להם לבחור בגרסה הפגומה.כדי לצמצם את הסיכון הזה, אפשר להשתמש במאגרי מידע וירטואליים ומרוחקים ביחד:
- יוצרים מאגר מרוחק שישמש כשרת proxy למאגר הציבורי.
- יצירת מאגר סטנדרטי לחבילות הפרטיות שלכם.
- יוצרים מאגר וירטואלי שמוגדר לתת עדיפות למאגר הרגיל אם גרסה של אותה חבילה קיימת בשני המאגרים.
- מגדירים את הכלים לניהול חבילות וכלים אחרים כך שיקראו רק מהמאגר הווירטואלי, כדי שהלוגיקה של הלקוח לא תהיה מעורבת בבחירת המאגר.
כדי לקרוא על שיטות מומלצות אחרות לניהול תלות, אפשר לעיין במאמר בנושא ניהול תלות.
איך מאגרים וירטואליים בוחרים מאגר במעלה הזרם
לכל מאגר במעלה הזרם צריך להיות סדר עדיפות מוגדר. העדיפות היא מספר שלם שפועל כמשקל, ולא כדירוג. כלומר, מאגרי קוד עם ערך עדיפות מספרי גבוה יותר מקבלים עדיפות על פני מאגרי קוד עם ערכי עדיפות נמוכים יותר.
כשמבקשים ארטיפקט שנמצא בכמה מאגרי מידע במעלה הזרם, Artifact Registry משתמש בלוגיקת התעדוף הבאה:
- המאגר עם הערך הגבוה ביותר מקבל עדיפות. לדוגמה, הערך
10נחשב לעדיפות גבוהה יותר מהערך1. - אם לכמה מאגרי מידע במעלה הזרם יש אותה עדיפות, אפשר להציג את הארטיפקט מכל אחד מהמאגרים האלה.
מומלץ גם לכלול בבקשה את גרסת פריט המידע שנוצר. כך הלקוח מחזיר את המאגר במעלה הזרם עם העדיפות הגבוהה ביותר שמכיל את גרסת פריט המידע שביקשתם. אם לא מציינים את גרסת פריט המידע, יכול להיות שהלקוח יחזיר את הגרסה העדכנית של פריט המידע, בלי קשר לעדיפות של המאגר.
כשמגדירים לקוח ישירות כדי לחפש במאגר וירטואלי ובמאגרים נוספים, יכול להיות שהלקוח עדיין יוריד פריטי מידע שנוצר ממאגרים מחוץ ל-Artifact Registry.לדוגמה, אם מגדירים את הכלי pip של Python כדי לחפש ב-PyPI ובמאגר וירטואלי, יכול להיות שהחבילה תורד ישירות מ-PyPI כי pip תמיד יבחר את הגרסה העדכנית של החבילה, בלי קשר למאגר שממנו היא מגיעה. אם pip מוגדר לחפש רק במאגר הווירטואלי, תוכלו לשלוט בעדיפות של כל המאגרים במעלה הזרם, כולל מאגר מרוחק במעלה הזרם שמשמש כשרת proxy ל-PyPI.
פורמטים נתמכים של מאגרי מידע
אפשר ליצור מאגרים וירטואליים לפורמטים הבאים של מאגרי Artifact Registry:
חבילות שפה:
חבילות של מערכת ההפעלה:
אם אתם משתמשים חדשים ב-Artifact Registry, תוכלו להיעזר במדריכים למתחילים כדי ללמוד איך להגדיר מאגרים סטנדרטיים לפורמטים האלה.
מגבלות
בנוסף למכסות ולהגבלות של Artifact Registry, למאגרים וירטואליים יש את המגבלות הבאות:
- מאחר שמאגרי נתונים וירטואליים לא שומרים נתונים, הם יופיעו ריקים כשמריצים את
gcloud artifacts docker images listוכשמציגים את מאגר הנתונים במסוף Google Cloud . - מאגרי upstream רגילים של Artifact Registry צריכים להיות באותו אזור או באותו מספר אזורים כמו המאגר הווירטואלי, אבל הם יכולים להיות בפרויקטים שונים של Google Cloud .
מאגרי Maven וירטואליים לא מאפשרים להגדיר את מדיניות הגרסה ל-snapshot או ל-release.
מאגרי Apt ו-Yum במעלה הזרם חייבים להיות מאגרים רגילים של Artifact Registry.
מאגרי Apt ו-Yum רגילים מעדכנים את אינדקס החבילות באופן אסינכרוני אחרי שחבילה מיובאת, מועלית או נמחקת. במאגרים קטנים, יצירת האינדקס מחדש יכולה להימשך כמה שניות. במאגרים גדולים יותר, יכול להיות שהתהליך יימשך כמה דקות או יותר. אחרי שההוספה לאינדקס מסתיימת, השינוי במאגר גלוי ללקוחות Apt ו-Yum.
מצבים אחרים של מאגרים
מצבי המאגר האחרים הם:
- רגיל: מצב ברירת המחדל של המאגר. אתם מעלים או מפרסמים פריטי מידע שנוצר, כמו חבילות פרטיות, ישירות למאגרים רגילים. אפשר להוריד ישירות ממאגרים רגילים נפרדים, אבל גישה לקבוצות של מאגרים באמצעות מאגר וירטואלי מפשטת את הגדרת הכלים.
- מרוחק: מאגר שמשמש כפרוקסי למקור במעלה הזרם על ידי שמירת חבילות במטמון ב-Artifact Registry אחרי שהן מורדות מהמקור במעלה הזרם בפעם הראשונה. בפעם הבאה שתבקשו את אותה גרסת חבילה, Artifact Registry יספק את העותק שנשמר במטמון.
- מחבר (תצוגה מקדימה): מאגר שפועל כשרת proxy למקור במעלה הזרם, אבל לא שומר במטמון פריטי מידע שנוצרו בתהליך פיתוח התוכנה ב-Artifact Registry. במקום זאת, כל הבקשות נשלחות למקור במעלה הזרם. מאגרי מחברים שימושיים אם אתם צריכים יכולת ביקורת מלאה של המקור במעלה הזרם, או אם יש לכם כללי מדיניות שמונעים שמירת פריטים בקובץ שמור.