פיתוח ובדיקה של אפליקציות Go

בדף הזה מוסבר איך להשתמש ב-Cloud Build כדי ליצור ולבדוק את אפליקציות Go, להעלות את הארטיפקטים ל-Artifact Registry, ליצור מידע על מקורות ולשמור את יומני הבדיקות ב-Cloud Storage.

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

ההוראות בדף הזה מניחות שאתם מכירים את Go. בנוסף:

  • מפעילים את Cloud Build API,‏ Cloud Run API ו-Artifact Registry API.

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

    כדי להפעיל ממשקי API, צריך את תפקיד ה-IAM 'אדמין של Service Usage' (roles/serviceusage.serviceUsageAdmin), שכולל את ההרשאה serviceusage.services.enable. איך מקצים תפקידים

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

  • כדי להריץ את הפקודות gcloud שבדף הזה, צריך להתקין את Google Cloud CLI.
  • מוודאים שהפרויקט שלכם ב-Go מוכן.
  • יש לכם מאגר Go ב-Artifact Registry. אם אין לכם מאגר, אתם יכולים ליצור מאגר חדש.
  • אם רוצים לאחסן יומני בדיקה ב-Cloud Storage, או אם רוצים להשתמש ב-CLI של gcloud כדי להתחיל את ה-build, צריך ליצור קטגוריה ב-Cloud Storage.
  • חשוב לוודא שיש לכם את המזהה של חשבון השירות של זמן הריצה בשביל Cloud Run.

יצירת חשבון שירות מותאם אישית ב-Cloud Build

כדי ליצור חשבון שירות מותאם אישית של Cloud Build, מריצים את הפקודה הבאה ב-CLI של Google Cloud:

  gcloud iam service-accounts create cloud-build-go \
      --description="Build and test Go applications" \
      --display-name="Cloud Build Go" \
      --project="PROJECT_ID"

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

תשתמשו בחשבון השירות הזה כדי ליצור ולבדוק את אפליקציית Go שלכם.

הגדרת הרשאות IAM

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

  1. במסוף Google Cloud , נכנסים לדף Cloud Build Permissions:

    עוברים אל הרשאות

  2. עוברים לתפריט Service account ובוחרים את חשבון השירות של cloud-build-go.

  3. מגדירים את הסטטוס של התפקידים הבאים למופעל:

    • Cloud Run Admin‏ (roles/run.admin): מאפשר ל-Cloud Build לפרוס שירותים חדשים ב-Cloud Run.
    • אדמין לניהול נפח האחסון (roles/storage.admin): מאפשר קריאה וכתיבה מ-Cloud Storage.
    • הרשאת כתיבה ב-Artifact Registry‏ (roles/artifactregistry.writer): מאפשרת שליפת תמונות מ-Artifact Registry וכתיבה ב-Artifact Registry.
    • כותב יומנים (roles/logging.logWriter): מאפשר לכתוב רשומות ביומן ב-Cloud Logging.
    • עריכה ב-Cloud Build‏ (roles/cloudbuild.builds.editor): מאפשרת לחשבון השירות להריץ בנייה.

הגדרת קובצי build של Go

קובץ האימג' הציבורי golang מ-Docker Hub תומך ביצירה באמצעות מודולים של Go. אם משתמשים בקובץ האימג' הזה כשלב build בקובץ ההגדרות של Cloud Build, אפשר להפעיל פקודות go בתוך קובץ האימג'. הארגומנטים שמועברים לשלב הבנייה הזה מועברים ישירות לכלי golang, כך שאפשר להריץ כל פקודה של golang בתמונה הזו.go

בקטע הזה נסביר איך ליצור קובץ תצורת build לדוגמה לאפליקציית Go ממאגר ה-Git ‏cloud-build-samples. קובץ התצורה של ה-build כולל שלבים ליצירת האפליקציה, להוספת בדיקות יחידה, ולאחר שהבדיקות עוברות, לפריסת האפליקציה.

כדי ליצור את אפליקציית Go לדוגמה:

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

    • ‫name: מגדירים את הערך של השדה הזה ל-golang כדי להשתמש בתמונה של golang מ-Docker Hub למשימה.
    • ‫entrypoint: מגדירים את הערך של השדה הזה ל-/bin/bash. כך תוכלו להריץ פקודות bash מרובות שורות ישירות משלב הבנייה.

    • ‫args: השדה args של שלב בנייה מקבל רשימה של ארגומנטים ומעביר אותם לתמונה שאליה יש הפניה בשדה name. בדוגמה הבאה, השדה args מקבל את הארגומנטים של:

      • מריצים את הכלי לעיצוב יומן הבדיקה כדי להוריד את הפלט של יומן הבדיקה.
      • הדפסת הפלט של היומן.
      • תוצאות הבדיקה נשמרות ב-sponge.log.

      • התוצאות מועברות בפורמט sponge.log לקובץ XML של JUNIT. השם של קובץ ה-XML של JUNIT מורכב מהגרסה הקצרה של מזהה הקומיט שמשויך ל-build. בשלב הבא של ה-build, היומנים יישמרו בקובץ הזה ב-Cloud Storage.

        steps:
  # Run tests and save to file
  - name: golang:1.23
    entrypoint: /bin/bash
    args:
      - -c
      - |
        go install github.com/jstemmer/go-junit-report/v2@latest
        2>&1 go test -timeout 1m -v ./... | /go/bin/go-junit-report -set-exit-code -iocopy -out ${SHORT_SHA}_test_log.xml

  2. העלאה אל Artifact Registry: בקובץ ההגדרות, משתמשים בשדה goModules כדי לציין את הנתיב של האפליקציה ואת מאגר Go ב-Artifact Registry:

    # Upload Go module to artifact registry
artifacts:
  goModules:
    - repositoryName: 'repositoryName'
      repositoryLocation: 'location'
      repositoryProjectId: 'projectId'
      sourcePath: 'sourcePath'
      modulePath: 'appPath'
      moduleVersion: 'version'

    מחליפים את הערכים הבאים:

    • ‫repositoryName: השם של מאגר Go ב-Artifact Registry.
    • ‫location: המיקום של המאגר ב-Artifact Registry.
    • ‫projectId: מזהה Google Cloud הפרויקט שמכיל את מאגר Artifact Registry.
    • ‫sourcePath: הנתיב לקובץ go.mod בסביבת העבודה של ה-build.
    • ‫appPath: הנתיב לאפליקציה הארוזה.
    • ‫version: מספר הגרסה של האפליקציה, בפורמט של מספרים ונקודות כמו v1.0.1.

  3. אופציונלי: הפעלת יצירת שיוך מקור

    ‫Cloud Build יכול ליצור מטא נתונים של מקורות build שניתנים לאימות של Supply chain Levels for Software Artifacts‏ (SLSA) כדי לעזור לכם לאבטח את צינור השילוב הרציף שלכם.

    כדי להפעיל את יצירת המקור, מוסיפים את השורה requestedVerifyOption: VERIFIED לקטע options בקובץ ההגדרות.

    אחרי שהבנייה מסתיימת, אפשר לראות את פרטי המאגר ב-Artifact Registry.

    אפשר גם לראות את המטא-נתונים של מקור ה-build ולאמת את המקור.

  4. שמירת יומני בדיקה ב-Cloud Storage: אפשר להגדיר את Cloud Build כך שיאחסן יומני בדיקה ב-Cloud Storage. לשם כך צריך לציין מיקום של קטגוריה קיימת ונתיב ליומני הבדיקה.

    שלב ה-build הבא שומר את יומני הבדיקה ששמרתם בקובץ JUNIT XML בקטגוריה של Cloud Storage:

    # Save test logs to Google Cloud Storage
artifacts:
  objects:
    location: gs://$_BUCKET_NAME/
    paths:
      - ${SHORT_SHA}_test_log.xml

    בקטע הקוד הבא מוצג קובץ התצורה המלא של ה-build עבור השלבים הקודמים:

      steps:
    # Run tests and save to file
    - name: golang:1.23
      entrypoint: /bin/bash
      args:
        - -c
        - |
          go install github.com/jstemmer/go-junit-report/v2@latest
          2>&1 go test -timeout 1m -v ./... | /go/bin/go-junit-report -set-exit-code -iocopy -out ${SHORT_SHA}_test_log.xml

  # Store golang modules in Google Artifact Registry
  artifacts:
    goModules:
      - repositoryName: 'repositoryName'
        repositoryLocation: 'location'
        repositoryProjectId: 'projectId'
        sourcePath: 'sourcePath'
        modulePath: 'appPath'
        moduleVersion: 'version'

  5. מתחילים את הבנייה באמצעות ה-CLI של gcloud או יוצרים טריגר לפיתוח גרסת Build:

    gcloud

    מריצים את הפקודה הבאה, ומשתמשים ב---substitutions כדי לציין את משתני ההחלפה שמשמשים ב-cloudbuild.yaml:

    gcloud builds submit --region=us-west2 --config=cloudbuild.yaml \
    --default-buckets-behavior=REGIONAL_USER_OWNED_BUCKET \
    --service-account=projects/PROJECT_ID/serviceAccounts/cloud-build-go@PROJECT_ID.iam.gserviceaccount.com \
    --substitutions=_AR_REPO_NAME="_AR_REPO_NAME",_BUCKET_NAME="_BUCKET_NAME",SHORT_SHA="SHORT_SHA"

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

    • ‫_AR_REPO_NAME: השם של מאגר Artifact Registry.

    • ‫_BUCKET_NAME: השם של קטגוריית Cloud Storage ליומני בדיקה.

    • ‫SHORT_SHA: מחרוזת טקסט קצרה וכללית, כמו 'manual'. הערכים של SHORT_SHA מאוכלסים באופן אוטומטי בגרסאות build שמופעלות על ידי טריגרים, אבל לא מסופקים כששולחים גרסת build באמצעות ה-CLI של gcloud.

    טריגרים לפיתוח גרסת Build

    פועלים לפי השלבים במאמר יצירת טריגר לפיתוח גרסת Build. בשדה Substitution variables, צריך גם לציין את השם של מאגר Artifact Registry ואת השם של הקטגוריה ב-Cloud Storage ליומני בדיקה.

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