התקנה והגדרה של CLI של אחסון לפרויקטים

בדף הזה מוסבר איך להתקין ולהגדיר את gdcloud CLI כדי לנהל את מאגר האובייקטים כשעובדים עם פרויקטים של Google Distributed Cloud (GDC) עם air gap. הוא כולל הורדה, התקנה והגדרה של הרכיבים וההגדרות שנדרשים כדי להשתמש ביעילות בקטגוריות ובאובייקטים של אחסון בסביבה המבודדת הזו.

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

לפני שמתחילים

כדי להתקין ולהגדיר את ה-CLI של האחסון, צריך לבקש מהאדמין של הארגון ב-IAM את התפקיד אדמין של מדיניות הרשת בארגון (org-network-policy-admin), שמאפשר ליצור, לערוך ולמחוק את מדיניות הרשת בארגון.

הורדת ה-gdcloud CLI

מורידים ופורקים את קובץ הארכיון של ה-gdcloud CLI לפי ההוראות במאמר הורדת ה-gdcloud CLI. אל תשתמשו בקובץ בינארי עצמאי של gdcloud CLI שלא כולל את הספרייה bin/component_bundles/.

התקנת ה-gdcloud CLI

כדי להשתמש בקבוצת הפקודות gdcloud storage, צריך להתקין את הרכיב storage-cli-dependencies מחבילת gdcloud CLI שחולצה:

1. פועלים לפי ההוראות במאמר התקנת ה-gdcloud CLI כדי להוסיף את הספרייה bin של החבילה שחולצה ל-PATH.

2. כדי להתקין את הרכיב storage-cli-dependencies, מריצים את הפקודה הבאה:

   gdcloud components install storage-cli-dependencies
   

   הפקודה הזו מתקינה את storage-cli-dependencies מהספרייה bin/component_bundles/ בחבילת ה-gdcloud CLI שחולצה. אם מריצים את הפקודה הזו מקובץ בינארי עצמאי של gdcloud CLI שאין בו את bin/component_bundles/, הפקודה נכשלת עם השגיאה component_registry.yaml: no such file or directory. כדי לפתור את השגיאה, צריך להוריד ולחלץ חבילה מהורדת ה-gdcloud CLI ולהריץ את bin/gdcloud מספריית החבילה שחולצה.

   מידע נוסף על הפקודה components install זמין במאמר התקנת רכיבים.

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

הגדרת ה-CLI של gdcloud לאחסון אובייקטים

כדי להשתמש ב-gdcloud CLI למאגר אובייקטים, צריך להגדיר את ההגדרות הבאות.

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

   gdcloud config set storage/s3_access_key_id ACCESS_KEY_ID
   

2. מחליפים את SECRET_ACCESS_KEY במפתח הסודי שהתקבל מהסוד בקבלת פרטי כניסה:

   gdcloud config set storage/s3_secret_access_key SECRET_ACCESS_KEY
   

3. מחליפים את CA_BUNDLE_FILE בנתיב לאישור ה-CA. זהו אישור דיגיטלי ששייך לרשות אישורים (CA), ארגון מהימן שמאשר זהויות. אתם יכולים לבקש את חבילת האמון של GDC CA מחבר בקבוצת מפעילי התשתית (IO). מידע נוסף על קבלת אישורי CA של GDC זמין במאמר אחזור חבילות אמון של GDC.

   gdcloud config set storage/s3_custom_ca_certs_file CA_BUNDLE_FILE
   

   הערה: אם אישורי ה-CA של GDC כבר מותקנים בסביבה, אפשר להגדיר את הערך /etc/ssl/certs/ca-certificates.crt

4. מחליפים את ENDPOINT בנקודת הקצה (endpoint) שקיבלתם ממפעיל התשתית (IO):

   gdcloud config set storage/s3_endpoint ENDPOINT
   

   הערה: זוהי נקודת הקצה המלאה שמתחילה ב-https://.

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

   • נקודת קצה (endpoint) של Zone1: נקודת הקצה הזו תמיד מתקבלת על ידי Zone1. אם משתמשים בנקודת הקצה הזו, יש עקביות קריאה בסיום הכתיבה לכל האובייקטים שנכתבו ב-zone1. עם זאת, אם zone1 מושבת, הלקוח צריך לעבור לשימוש ב-zone2 או בנקודת הקצה הגלובלית כדי להמשיך לקרוא או לכתוב בקטגוריה הזו. אם הלקוח מגיע מאשכול משתמשים, נקודת הקצה הזו תהיה נגישה רק מתוך zone1.
   • נקודת קצה (endpoint) של Zone2: נקודת הקצה הזו תמיד מתקבלת על ידי Zone2. אם משתמשים בנקודת הקצה הזו, יש עקביות קריאה בסיום הכתיבה לכל האובייקטים שנכתבו ב-zone2. עם זאת, אם zone2 מושבת, הלקוח צריך לעבור לשימוש בנקודת הקצה של zone1 או בנקודת הקצה הגלובלית כדי להמשיך לקרוא מהקטגוריה הזו או לכתוב אליה. אם הלקוח מגיע מאשכול משתמשים, נקודת הקצה הזו תהיה נגישה רק מתוך zone2.
   • נקודת קצה גלובלית: נקודת הקצה הזו גורמת לניתוב הבקשה לאזור 1 או לאזור 2. האפשרות הזו לא מספקת זיקה לסשן (session affinity), כלומר בקשות שבוצעו באמצעות אותו סשן עשויות להגיע לאזור 1 או לאזור 2. כלומר, אין התחייבות לקריאה אחרי כתיבה לבקשות שנשלחות לנקודת הקצה הגלובלית. נקודת הקצה הגלובלית מספקת יתירות כשל אוטומטית במקרה שאזור מסוים מושבת, כך שהמשתמשים לא צריכים לשנות את נקודות הקצה בעומסי העבודה שלהם, כמו שהיו צריכים לעשות אם היו משתמשים בנקודת הקצה האזורית. בנוסף, אפשר לגשת לנקודת הקצה הזו מאשכולות משתמשים בכל האזורים.

   מריצים את הפקודות הבאות בשרת ה-API לניהול כדי לראות את נקודות הקצה הגלובליות והאזוריות של הקטגוריה, ובוחרים את נקודת הקצה שבה רוצים להשתמש:

   kubectl get buckets BUCKET_NAME -n PROJECT_NAME -o jsonpath="{.status.globalEndpoint}" --kubeconfig MANAGEMENT_API_SERVER
   
   kubectl get buckets BUCKET_NAME -n PROJECT_NAME -o jsonpath="{.status.zonalEndpoints}" --kubeconfig MANAGEMENT_API_SERVER