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

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

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

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

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

הורדה של gdcloud CLI

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

התקנת gdcloud CLI

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

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

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

    gdcloud components install storage-cli-dependencies

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

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

כדי להשתמש ב-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

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

    gdcloud config set storage/s3_endpoint ENDPOINT

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

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

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