Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

פתרון בעיות שקשורות לבנייה ועוד

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

האם בדקת את יומני ה-build?

כדי לקבל מידע נוסף על שגיאת ה-build, אפשר להשתמש ביומנים של Logging או ביומני build של Cloud Storage. אפשר לראות את היומנים שנכתבו אל stdout או אל stderr באמצעות מסוף Google Cloud ו-CLI של gcloud.

בנייה ידנית נכשלת כי למשתמש אין גישה ליומני בנייה

מוצגת השגיאה הבאה כשמנסים להפעיל build באופן ידני:

AccessDeniedAccess denied. [EMAIL_ADDRESS] does not have storage.objects.get access to the Google Cloud Storage object.

השגיאה הזו מוצגת כי Cloud Build דורש שלמשתמשים שמריצים בנייה ידנית ומשתמשים בדלי ברירת המחדל של יומני Cloud Storage יהיה תפקיד Project Viewer IAM בנוסף לתפקיד Cloud Build Editor. כדי לטפל בשגיאה הזו, אפשר לבצע אחת מהפעולות הבאות:

משתמשים בדלי ברירת המחדל של היומנים ומעניקים למשתמש שמריץ את ה-build את התפקידים Project Viewer ו-Cloud Build Editor. הוראות להענקת ההרשאה הזו מופיעות במאמר הגדרת גישה למשאבי Cloud Build.
יוצרים קטגוריה משלכם ב-Cloud Storage לאחסון יומנים. הוראות מפורטות זמינות במאמר אחסון יומני בנייה בקטגוריה שנוצרה על ידי משתמש.

הגרסאות build נכשלות בגלל הרשאה חסרה של `iam.serviceAccounts.actAs`

השגיאה הבאה מופיעה כשמנסים לפרוס build באמצעות שירות מנוהל כמו Cloud Run או App Engine:

Missing necessary permission iam.serviceAccounts.actAs for [USER] on the service account [SERVICE ACCOUNT]

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

מידע נוסף על חשבונות שירות והרשאות זמין בנושאים הבאים:

שגיאת דחיית הרשאה כשפורסים ב-Cloud Run Functions

כשמנסים להשתמש בפונקציות Cloud Run, מופיעה השגיאה הבאה:

ResponseError: status=[403], code=[Ok], message=[Permission 'cloudfunctions.functions.get' denied]

כדי לפתור את השגיאה הזו, צריך להעניק לחשבון השירות של ה-build את התפקיד 'מפתח פונקציות של Cloud Run'.

הפעלת ה-trigger לבנייה נכשלת בגלל הרשאה חסרה `cloudbuild.builds.create`

כשמריצים טריגר לפיתוח גרסת Build, מופיעה שגיאה שדומה לשגיאה הבאה:

Failed to trigger build: Permission 'cloudbuild.builds.create' denied on resource 'projects/xxxxxxxx' (or it may not exist)

טריגרים של בנייה משתמשים בחשבון שירות כדי ליצור בנייה. השגיאה הזו מציינת שחשבון השירות לא קיבל את הרשאת ה-IAM‏ cloudbuild.builds.create, שנדרשת כדי שחשבון השירות יפעיל טריגר לפיתוח גרסת Build. כדי לפתור את השגיאה הזו, צריך להקצות את תפקיד ה-IAM‏ Cloud Build Service Account לחשבון השירות שצוין על ידי המשתמש או לחשבון השירות שמוגדר כברירת מחדל.

השליחה של ה-Build נכשלה בגלל הרשאות חסרות של סוכן שירות

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

Caller does not have required permission to use project $PROJECT_ID. Grant the caller the roles/serviceusage.serviceUsageConsumer role, or a custom role with the serviceusage.services.use permission, by visiting https://console.developers.google.com/iam-admin/iam/project?project=$PROJECT_ID and then retry. Propagation of the new permission may take a few minutes.

הגורם הקורא בתרחיש הזה הוא סוכן השירות של Cloud Build. כדי לפתור את בעיית ההרשאות הזו, צריך לבצע את השלבים הבאים:

מוודאים שסוכן השירות של Cloud Build קיים. כדי לראות את סוכן השירות של פרויקט מסוים, צריך להיכנס לדף IAM במסוף Google Cloud ולסמן את התיבה הצגת חשבונות שירות שמנוהלים על ידי Google. אם הוא לא קיים, אפשר ליצור אותו על ידי הרצת הפקודה הבאה ב-CLI של gcloud:
```
gcloud beta services identity create --service=cloudbuild.googleapis.com \
    --project=PROJECT_ID
```

בשלב הבא, מקצים את תפקיד ה-IAM‏ roles/cloudbuild.serviceAgent לסוכן השירות של Cloud Build:

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member="serviceAccount:service-PROJECT_NUMBER@gcp-sa-cloudbuild.iam.gserviceaccount.com" \
    --role="roles/cloudbuild.serviceAgent"

כדי לבדוק איזו זהות ב-IAM אחראית לבעיה בהרשאות של סוכן השירות, פועלים לפי השלבים הבאים:

פותחים את Logs Explorer במסוף Google Cloud :

כניסה לדף Logs Explorer

מזינים את הטקסט הבא בשדה השאילתה:

resource.type="project"
log_name="projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Factivity"
"service-PROJECT_NUMBER@gcp-sa-cloudbuild.iam.gserviceaccount.com"

אם מופיעות רשומות ביומן אחרי השימוש בשאילתה הזו, בודקים אם יש רשומות שמסירות הרשאות מסוכן השירות (service-PROJECT_NUMBER@gcp-sa-cloudbuild.iam.gserviceaccount.com). אם כן, בודקים את protoPayload.authenticationInfo.principalEmail ביומן כדי לזהות את זהות ה-IAM שאחראית להסרת ההרשאה או התפקיד roles/cloudbuild.serviceAgent שכולל את ההרשאה שמופיעה בהודעת השגיאה.

הטריגר נכשל עם השגיאה `Couldn't read commit`

השגיאה הבאה מופיעה כשמריצים טריגר לפיתוח גרסת Build:

  Failed to trigger build: Couldn't read commit

הודעה זו מוחזרת מ-Cloud Build אם מנסים להפעיל build באמצעות ענף שלא קיים. בודקים את השמות של הספריות כדי לוודא שהם מאויתים נכון ושאין בהם חוסר עקביות. הוראות להגדרת טריגר מופיעות במאמר יצירה וניהול של טריגרים לבנייה.

אי אפשר ליצור טריגר Pub/Sub

מופיעה השגיאה הבאה כשיוצרים טריגר Pub/Sub:

  Failed to create trigger: Request is prohibited by organization's policy

השגיאה הזו מציינת ש-Pub/Sub API מוגבל בפרויקט שלכם. בפרויקטים שבהם יש הגבלות על Pub/Sub API, היכולת ליצור מינויים מסוג Push מוגבלת. כדי לפתור את הבעיה, אפשר להסיר באופן זמני את Pub/Sub מהשירותים המוגבלים בגבולות גזרה, ליצור את הטריגר ולהגביל שוב את Pub/Sub API.

אי אפשר למשוך או לאחזר ענפים ממאגר פרטי בגלל השגיאה: `fatal: could not read Username`

מופיעה השגיאה הבאה כשמנסים לבצע git pull או git fetch בענף מרוחק ממאגר פרטי:

fatal: could not read Username for '<REMOTE_URL>': No such device or address

השגיאה הזו צפויה במאגרי קוד פרטיים, כי כלי העזר לאישורי גישה ל-Git מוסר בכוונה אחרי השכפול הראשוני של מאגר הקוד. כדי לאחזר ענפים מרוחקים ממאגר פרטי, צריך להגדיר ידנית פרטי הרשאה (אסימוני API, מפתחות SSH) כשלב בבנייה. מידע נוסף על גישה למאגרי GitHub פרטיים

הגרסאות build נכשלות בגלל הרשאת SSH לא תקינה

השגיאה הבאה מופיעה כשמריצים build:

Could not parse ssh: [default]: invalid empty ssh-agent socket, make sure SSH_AUTH_SOCK is set

השגיאה הזו מעידה על בעיה בהרשאת SSH. דוגמה נפוצה היא שגיאת הרשאה של SSH שמתרחשת כשניגשים למאגרי GitHub פרטיים באמצעות Cloud Build. הוראות להגדרת SSH ל-GitHub זמינות במאמר גישה למאגרים פרטיים ב-GitHub.

הגרסה נכשלה בגלל השגיאה `No route to host`

מופיעה השגיאה הבאה או שגיאה דומה כשמריצים build במאגר פרטי:

Unable to connect to the server: dial tcp 192.168.10.XX:<port>: connect: no route to host

‫Cloud Build מפעיל את Cloud builders במכונה הווירטואלית בפרויקט שמנוהל על ידי Google באמצעות קונטיינרים של Docker. לממשק הגישור של Docker (וכתוצאה מכך לקונטיינרים שמחוברים לממשק הזה) מוקצה טווח כתובות IP של 192.168.10.0/24, ולכן אי אפשר לתקשר עם המארחים החיצוניים באותה רשת משנה. כשמקצים את טווחי כתובות ה-IP למשאבים בפרויקטים במהלך ההגדרה של מאגר פרטי, מומלץ לבחור טווח מחוץ ל-192.168.10.0/24. הוראות מפורטות מופיעות במאמר הגדרת הסביבה למאגרי כתובות פרטיים.

הגרסה נכשלת עם הודעת השגיאה 'פג תוקף', ולא מוצגים יומנים

הפעלתם או שלחתם בנייה והיא נכשלה, הוצגה השגיאה Expired (תוקף האישור פג) ולא נוצרו יומנים.

בודקים את הדברים הבאים בהגדרות:

הגדרתם ערך נמוך יותר של queueTtl (למשל, 20 שניות).

מגדילים את הערך בסכימה ומריצים שוב את הבנייה. מידע נוסף זמין במאמר queueTtl.
הגעתם למכסה של מספר הבנייות המקבילות.

אפשר לבקש הגדלה של המכסה דרך הדף Quota במסוף Google Cloud . פרטים נוספים זמינים במאמר מכסות ומגבלות.
אתם משתמשים במאגר פרטי ובחרתם במכונה שלא מוגדרת כברירת מחדל.

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

אפשר לנסות לשנות את סוג המכונה.
אתם משתמשים בבריכה פרטית וציינתם טווח כתובות IP לבריכה.

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

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

החיבור למשאב חיצוני נכשל כי לא הופעלה כתובת IP חיצונית

מופיעה השגיאה הבאה כשמתחברים למשאב חיצוני ממאגר פרטי:

 Failed to connect to <external_domain>: Connection timed out

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

שגיאת קלט/פלט (I/O) עקב פסק זמן

השגיאה הבאה מופיעה כשמריצים build:

Timeout - last error: dial tcp IP_ADDRESS: i/o timeout

השגיאה הזו יכולה להתרחש כשניסיון ה-build לגשת למשאבים ברשת פרטית נכשל. כברירת מחדל, ל-builds שמופעלים באמצעות Cloud Build יש גישה למשאבים פרטיים באינטרנט הציבורי, כמו משאבים במאגר או במרשם. עם זאת, ל-builds יש גישה למשאבים ברשת פרטית רק אם משתמשים במאגרי build פרטיים ומגדירים אותם כך שתהיה להם גישה לרשת הפרטית. מידע נוסף זמין במאמר בנושא שימוש ב-Cloud Build ברשת פרטית.

שגיאות לקוח מסוג 4xx

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

**Error**: 404 : Requested entity was not found
**Error**: 404 : Trigger not found
**Error**: 400 : Failed Precondition
**Error**: 403 : Permission denied

כשמופיעה שגיאת לקוח מסוג ‎4xx, כדאי לעיין ביומני הבנייה כדי לראות אם יש בהם מידע נוסף על הסיבה לשגיאה. בין הסיבות הנפוצות לשגיאות בצד הלקוח:

במיקום המקור שציינת אין שינויים חדשים לביצוע, ועץ העבודה נקי. במקרה כזה, צריך לבדוק את המיקום של קוד המקור ולנסות לבנות שוב.
המאגר לא מכיל קובץ הגדרות build. במקרה כזה, צריך להעלות קובץ תצורה של build למאגר ולהריץ את ה-build שוב.
ציינת מזהה טריגר שגוי.
לאחרונה הוספתם מאגר חדש אחרי התקנת אפליקציית GitHub, ול-Cloud Build אין הרשאות גישה למאגר החדש. אם זה המצב, צריך לחבר את המאגר החדש ל-Cloud Build.
צריך להעניק הרשאה נוספת לחשבון השירות של ה-build.

הבנייה נכשלת בגלל הגבלות מכסה

מופיעה השגיאה הבאה, שמציינת שהגרסה נכשלת בגלל הגבלות מכסה באזור מסוים:

Failed to trigger build: generic::failed_precondition: due to quota restrictions, cannot run builds in this region. Please contact support.

כדי להגדיל את המכסות באזור הספציפי הזה, אפשר לפנות אל Cloud Customer Care.

בעיות שקשורות לפסק זמן כששולפים תמונות ממאגר Docker

אחרי שמריצים גרסת build, הודעות השגיאה הבאות של פסק זמן מופיעות ביומן של Cloud Build:

Step #0: Pulling image: python:3.8.16-alpine3.17
Step #0: Error response from daemon: Get "https://registry-1.docker.io/v2/": net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)

Step 1/7 : FROM python:3.8.16-alpine3.17
Get "https://registry-1.docker.io/v2/": dial tcp 34.205.13.154:443: i/o timeout

כדי לפתור את השגיאה, מורידים את קובץ האימג' של Docker באמצעות crane וממשיכים לטעינת קובץ האימג' בקובץ האימג' של Docker ב-Cloud Build.

מוסיפים את קטע הקוד הבא לקובץ cloudbuild.yaml.

...
  # Crane runs as a regular user so we need to allow it to access the directory where it saves the image.
  - name: gcr.io/cloud-builders/docker
    args:
    - a+w
    - /workspace
    entrypoint: chmod
  # Use crane to download the image through the proxy
  - name: gcr.io/go-containerregistry/crane
    env: - 'HTTPS_PROXY=HTTPS_PROXY'
    args:
    - pull
    - 'python:3.8.16-alpine3.17'
    - /workspace/image.tar
  # Use docker load to add the image into the local Cloud Build registry
  - name: gcr.io/cloud-builders/docker
    args: [load, --input, "/workspace/image.tar"]
      - .

‫HTTPS_PROXY: הכתובת של ה-proxy ל-HTTP (למשל, https://proxy.example.com:8888/).

אחרי שהתמונה נטענת, השלבים הקיימים של cloudbuid.yaml אמורים לפעול כרגיל, למשל:

...
  - name: python:3.8.16-alpine3.17
    args:
    - echo
    - hello
    entrypoint: bash
  # Or use it internally on a Dockerfile
  - name: gcr.io/cloud-builders/docker
    args:
    - build

שגיאות `Unauthenticated` בשלבים ארוכים של Docker

שלבי בנייה שכוללים פקודת Docker שפועלת יותר משעה (למשל, דחיפה של קובץ אימג' גדול ל-Artifact Registry) עלולים להיכשל עם שגיאת אימות. מערכת Cloud Build מרעננת את טוקני האימות כל שעה, אבל יכול להיות שמערכת Docker לא תזהה את הטוקנים החדשים האלה, וכתוצאה מכך יתעוררו בעיות באימות. אתם יכולים לכתוב אסימון משלכם עם משך חיים מותאם אישית, לשמור אותו בקובץ ולהפנות אליו בפקודות Docker.

גרסאות build בתור במאגר פרטי שמקושר לרשת VPC

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

ניסיון לאשר או לדחות גרסאות build בהמתנה מלפני יותר מחודשיים

אי אפשר לאשר או לדחות גרסאות build בהמתנה שהן בנות יותר מחודשיים. ניסיון לעשות את זה עלול להוביל להודעת שגיאה שנראית כך:

 404, "message": "Requested entity was not
found.", "status": "NOT_FOUND" } }

במקרה כזה, כדאי לנסות לשלוח גרסת build חדשה.

היצירה של מאגר פרטי נכשלה: מאגר העובדים לא מקושר ל-Service Networking API

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

Failed to create private pool private-worker-pool: generic::failed_precondition: network "projects/PROJECT_NAME/global/networks/vpc-scmdev-lab-vpc" is not peered to the Service Networking API; please check your configuration and the documentation for troubleshooting and setting up your pool

כדי שהגרסאות build יוכלו לגשת למשאבים פרטיים מרשת הענן הווירטואלי הפרטי (VPC), צריך להגדיר חיבור בין רשת הענן הווירטואלי הפרטי לבין רשת הענן הווירטואלי הפרטי שבה נמצאים המאגרים הפרטיים. הוראות מפורטות זמינות במאמר בנושא הגדרת חיבור פרטי בין רשת ה-VPC לרשת של בעלים של שירות מנוהל.

יצירת מאגר פרטי נכשלה: אין גישה להגדרת peered_network

אם אתם משתמשים ב-VPC משותף או שמחקתם בעבר את סוכן השירות של Service Networking, יכול להיות שיצירת מאגר פרטי תיכשל עם שגיאה דומה לזו:

generic::permission_denied: cannot access peered_network config.

כדי לפתור את הבעיה, צריך לוודא שסוכן השירות של Service Networking‏ (service-PROJECT_NUMBER@service-networking.iam.gserviceaccount.com) קיים בפרויקט השירות ושיש לו את ההרשאות הנדרשות.

יוצרים את חשבון השירות אם הוא חסר:

gcloud beta services identity create \
    --service=servicenetworking.googleapis.com \
    --project=PROJECT_ID

מקצים לחשבון השירות את התפקיד הנדרש roles/servicenetworking.serviceAgent:

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member="serviceAccount:service-PROJECT_NUMBER@service-networking.iam.gserviceaccount.com" \
    --role="roles/servicenetworking.serviceAgent"

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

איך מנהלים את יומני הבנייה