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

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

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

הורדה של gdcloud CLI

פועלים לפי ההוראות להורדת ה-CLI של gcloud.

התקנת gdcloud CLI

כדי להשתמש בעץ פקודות האחסון, צריך להתקין את רכיב התלות באחסון.

1. פועלים לפי ההוראות שבמאמר התקנת ה-CLI של gdcloud.

2. כדי להתקין את רכיב יחסי התלות של האחסון, מריצים את הפקודות הבאות:

   gdcloud components install storage-cli-dependencies
   

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

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

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

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

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), ארגון מהימן שמאשר זהויות:

   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://.

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

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

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