יצירת מאגרים מ-GitLab Enterprise Edition ברשת פרטית

ב-Cloud Build אתם יכולים ליצור טריגרים כדי ליצור גרסאות build ממאגרים שמתארחים ב-GitLab Enterprise Edition. כך תוכלו להריץ גרסאות build בתגובה לאירועים כמו דחיפות של commit או בקשות מיזוג שמשויכות למאגר שלכם ב-GitLab Enterprise Edition.

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

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

  • מפעילים את ממשקי ה-API של Cloud Build,‏ Secret Manager,‏ Compute Engine ו-Service Networking, אם הם עדיין לא מופעלים.

    התפקידים שנדרשים כדי להפעיל ממשקי API

    כדי להפעיל ממשקי API, צריך את ההרשאה serviceusage.services.enable. אם אתם יצרתם את הפרויקט, סביר להניח שכבר יש לכם את ההרשאה הזו דרך התפקיד "בעלים" (roles/owner). אחרת, אתם יכולים לקבל את ההרשאה הזו דרך התפקיד "אדמין בממשק 'שימוש בשירות'" (roles/serviceusage.serviceUsageAdmin). איך מקצים תפקידים?

    הפעלת ממשקי ה-API

פיתוח מאגרים מ-GitLab Enterprise Edition ברשת פרטית

אם אפשר לגשת למכונה של GitLab Enterprise Edition רק ברשת VPC, צריך להגדיר שירות של Service Directory וליצור באמצעות מאגרים פרטיים. הפרויקט שמכיל את רשת ה-VPC יכול להיות שונה מהפרויקט שמכיל את השירות של Service Directory. כדי לוודא שאפשר להגיע למכונה לפני שיוצרים טריגרים, צריך לפעול לפי ההוראות הבאות:

  1. מפעילים את Service Directory API.

  2. מוודאים שיש לכם את התפקיד אדמין IAM בפרויקט בפרויקטGoogle Cloud שבו אתם רוצים ליצור את השירות של "ספריית השירותים". במאמר הגדרת הגישה למשאבים של Cloud Build מוסבר איך נותנים תפקידים ב-IAM.

  3. כדי להגדיר שירות ב-Service Directory:

    1. מגדירים מרחב שמות לפרויקט ב- Google Cloud .

      האזור שאתם מציינים במרחב השמות חייב להיות זהה לאזור שאתם מציינים בחיבור למארח של Cloud Build.

    2. מגדירים שירות במרחב השמות.

    3. מגדירים נקודת קצה לשירות הרשום.

      כשמגדירים נקודת קצה, חובה להשתמש בכתובת IP פנימית ולציין מספר יציאת HTTPS כדי ש-Cloud Build יוכל להגיע לשירות.

    מידע נוסף על הגדרת הגישה לרשת פרטית זמין במאמר הגדרת הגישה לרשת פרטית. בנוסף, Service Directory מספק שילוב עם שירותים כמו מאזני עומסים ו-Google Kubernetes Engine ‏(GKE). למידע נוסף, קראו את המאמר סקירה כללית של Service Directory ואיזון עומסים או סקירה כללית של Service Directory ל-GKE.

  4. נותנים לסוכן השירות של Cloud Build גישה ל-Service Directory:

    export PROJECT_NUMBER=$(gcloud projects describe PROJECT_ID --format="value(projectNumber)")
export CLOUD_BUILD_SERVICE_AGENT="service-$PROJECT_NUMBER@gcp-sa-cloudbuild.iam.gserviceaccount.com"
gcloud projects add-iam-policy-binding  PROJECT_ID_CONTAINING_SERVICE_DIRECTORY \
   --member="serviceAccount:$CLOUD_BUILD_SERVICE_AGENT" \
   --role="roles/servicedirectory.viewer"

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫PROJECT_ID הוא מזהה הפרויקט ב-Cloud Build.
    • ‫PROJECT_ID_CONTAINING_SERVICE_DIRECTORY הוא המזהה של הפרויקט ב-Google Cloud שמכיל את Service Directory.

  5. נותנים לסוכן השירות של Cloud Build גישה למשאב של רשת ה-VPC:

    export PROJECT_NUMBER=$(gcloud projects describe PROJECT_ID --format="value(projectNumber)")
export CLOUD_BUILD_SERVICE_AGENT="service-$PROJECT_NUMBER@gcp-sa-cloudbuild.iam.gserviceaccount.com"
gcloud projects add-iam-policy-binding PROJECT_ID_CONTAINING_NETWORK_RESOURCE \
   --member="serviceAccount:$CLOUD_BUILD_SERVICE_AGENT" \
   --role="roles/servicedirectory.pscAuthorizedService"

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫PROJECT_ID הוא מזהה הפרויקט ב-Cloud Build.
    • ‫PROJECT_ID_CONTAINING_NETWORK_RESOURCE הוא המזהה של הפרויקט ב-Google Cloud שמכיל את משאב הרשת.

  6. להשתמש במאגרים פרטיים כדי להריץ את ה-builds. אם לא יצרתם מאגר פרטי, קראו את המאמר יצירת מאגר פרטי חדש.

  7. כדי ליצור טריגר של GitLab Enterprise Edition, פועלים לפי ההוראות במאמר יצירת טריגר של GitLab Enterprise Edition, כדי ליצור מאגרים שמתארחים במכונה של GitLab Enterprise Edition.

    אם אתם כוללים אישור חתימה עצמית או אישור פרטי כשאתם מחברים את המארח של GitLab Enterprise Edition ל-Cloud Build, אתם חייבים להגדיר את ה-URI של המארח בתור השם החלופי של הבעלים (SAN) של האישור.

הטריגר של GitLab Enterprise Edition יפעיל עכשיו באופן אוטומטי גרסאות build במכונה של GitLab Enterprise Edition, בהתאם להגדרות האישיות שלכם.

שימוש ב-Service Directory כדי להגיע למארחים מחוץ ל- Google Cloud

ב-Service Directory נעשה שימוש בטווח כתובות ה-IP‏ 35.199.192.0/19 כדי להתחבר למארח מחוץ ל- Google Cloud. אתם צריכים להוסיף את הטווח הזה לרשימת ההיתרים בחומת האש. בנוסף, צריך להגדיר את הרשת הפרטית כך שתנתב את הטווח הזה דרך החיבור של Cloud VPN או Cloud Interconnect.

אם החיבור שלכם משתמש ב-Cloud Router, אתם יכולים להגדיר את החיבור כך שיעביר את הטווח לרשת הפרטית שלכם.

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

שימוש ב-Cloud Load Balancing כדי להגיע למארחים מחוץ ל- Google Cloud

אם הגדרת הרשת לא מאפשרת לנתב את טווח כתובות ה-IP של ספריית השירותים 35.199.192.0/19 אל Cloud VPN או Cloud Interconnect, אתם יכולים ליצור מאזן עומסים באמצעות Cloud Load Balancing שמפנה את התנועה למארח.

כשיוצרים את נקודת הקצה של Service Directory, חשוב להשתמש בכתובת ה-IP של כלל ההעברה של מאזן העומסים, במקום בכתובת ה-IP של המארח. כשיוצרים את נקודת הקצה, אפשר להשתמש במאזן עומסים פנימי מסוג HTTPS או במאזן עומסים פנימי מסוג פרוטוקול העברת נתונים מבוקרת (TCP).

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

  • כדי להגיע למארח, צריך רק קבוצת נקודות קצה (NEG) של רשת קישוריות היברידית.
  • מאזן העומסים של TCP לא דורש את המפתח הפרטי הלא מוצפן של אישור ה-SSL.
  • בהגדרת Cloud VPN צריך להשתמש ב-Cloud Router עם ניתוב דינמי גלובלי. אם ב-Cloud VPN שלכם נעשה שימוש בניתוב סטטי, אתם יכולים להשתמש בשרת proxy שמשתמש ב-Cloud Service Mesh במקום זאת. מידע נוסף זמין במאמר הגדרת שירותי קצה (edge) של רשת לפריסות היברידיות.

מידע נוסף על יצירת מאזן עומסים מסוג HTTPS זמין במאמר הגדרת מאזן עומסים פנימי של אפליקציות (ALB) עם קישוריות היברידית. מידע נוסף על יצירת מאזן עומסים ב-TCP זמין במאמר הגדרה של מאזן עומסי רשת אזורי פנימי בשרת proxy עם קישוריות היברידית.

שיתוף נתונים

הנתונים שנשלחים ל-GitLab Enterprise Edition מ-Cloud Build עוזרים לכם לזהות טריגרים לפי שם ולראות את תוצאות ה-build במאגרים של GitLab Enterprise Edition.

הנתונים הבאים משותפים בין Cloud Build לבין GitLab Enterprise Edition:

  • Google Cloud מזהה הפרויקט
  • שם הטריגר

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