פיתוח, בדיקה והעברה לקונטיינר של אפליקציות Python

בדף הזה מוסבר איך להגדיר את Cloud Build כדי לבנות, לבדוק, להכניס לקונטיינר ולפרוס אפליקציות Python.

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

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

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

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

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

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

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

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

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

הוראות להקצאת התפקידים האלה מופיעות במאמר הקצאת תפקיד באמצעות הדף IAM.

הגדרת בנייה של Python

בקטע הזה מופיע קובץ תצורה לדוגמה של build לאפליקציית Python. בקובץ יש שלבי build להתקנת דרישות, להוספת בדיקות יחידה, ולבנייה ולפריסה של האפליקציה אחרי שהבדיקות עוברות.

  1. בתיקיית השורש של הפרויקט, יוצרים קובץ הגדרות של Cloud Build בשם cloudbuild.yaml.

  2. התקנת הדרישות: תמונת python מ-Docker Hub מגיעה עם pip שכבר מותקן בה. כדי להתקין יחסי תלות מ-pip, מוסיפים שלב build עם השדות הבאים:

    • ‫name: מגדירים את הערך של השדה הזה ל-python כדי להשתמש בתמונת Python מ-Docker Hub למשימה הזו.
    • ‫entrypoint: הגדרת השדה הזה מבטלת את נקודת הכניסה שמוגדרת כברירת מחדל לתמונה שאליה יש הפניה ב-name. מגדירים את הערך של השדה הזה כ-pip כדי להפעיל את pip כנקודת הכניסה של שלב ה-build ולהריץ פקודות pip.
    • ‫args: השדה args של שלב בנייה מקבל רשימה של ארגומנטים ומעביר אותם לתמונה שאליה יש הפניה בשדה name. מעבירים את הארגומנטים כדי להריץ את הפקודה pip install בשדה הזה. הדגל --user בפקודה pip install מבטיח ששלבי ה-build הבאים יוכלו לגשת למודולים שהותקנו בשלב ה-build הזה.

    בשלב הבנייה הבא מוסיפים ארגומנטים להתקנת הדרישות מקובץ requirements.txt:

    steps:
  # Install dependencies
  - name: python
    entrypoint: pip
    args: ["install", "-r", "requirements.txt", "--user"]

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

    • ‫name: מגדירים את הערך של השדה הזה ל-python כדי להשתמש בתמונת python מ-Docker Hub למשימה.
    • ‫entrypoint: מגדירים את הערך של השדה הזה ל-python כדי להריץ פקודות python.
    • ‫args: מוסיפים את הארגומנטים להרצת הפקודה python pytest.

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

    # Run unit tests
- name: python
  entrypoint: python
  args: ["-m", "pytest", "--junitxml=${SHORT_SHA}_test_log.xml"]

  4. הוספת האפליקציה לקונטיינר: אחרי שמוסיפים את שלב ה-build כדי לוודא שהבדיקות עברו בהצלחה, אפשר לבצע build של האפליקציה. ‫Cloud Build מספק קובץ אימג' של Docker שנבנה מראש, שאפשר להשתמש בו כדי להוסיף את אפליקציית Python לקונטיינר. כדי להוסיף את האפליקציה לקונטיינר, מוסיפים את השדות הבאים בשלב הבנייה:

    • ‫name: מגדירים את הערך של השדה הזה ל-gcr.io/cloud-builders/docker כדי להשתמש בתמונת Docker מוכנה מראש למשימה.
    • ‫args: מוסיפים את הארגומנטים של הפקודה docker build כערכים בשדה הזה.

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

    # Docker Build
- name: 'gcr.io/cloud-builders/docker'
  args: ['build', '-t', 
         'us-central1-docker.pkg.dev/${PROJECT_ID}/${_ARTIFACT_REGISTRY_REPO}/myimage:${SHORT_SHA}', '.']

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

    • ‫name: מגדירים את הערך של השדה הזה ל-gcr.io/cloud-builders/docker כדי להשתמש בתמונה הרשמית של docker לבנייה של המשימה.
    • ‫args: מוסיפים את הארגומנטים לפקודה docker push כערכים של השדה הזה. בכתובת היעד, מזינים את מאגר Docker ב-Artifact Registry שבו רוצים לאחסן את התמונה.

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

    # Docker push to Google Artifact Registry
- name: 'gcr.io/cloud-builders/docker'
  args: ['push',  'us-central1-docker.pkg.dev/${PROJECT_ID}/${_ARTIFACT_REGISTRY_REPO}/myimage:${SHORT_SHA}']

    אופציונלי: אם רוצים ש-Cloud Build ייצור מידע על מקורות של בנייה לפי Supply chain Levels for Software Artifacts‏ (SLSA), צריך לבצע את הפעולות הבאות:

  6. פריסת הקונטיינר ב-Cloud Run: כדי לפרוס את האימג' ב-Cloud Run, מוסיפים שלב בנייה עם השדות הבאים:

    • ‫name: מגדירים את הערך של השדה הזה ל-google/cloud-sdk כדי להשתמש בתמונה של ה-CLI של gcloud להפעלת הפקודה gcloud לפריסת התמונה ב-Cloud Run.
    • ‫args: מוסיפים את הארגומנטים של הפקודה gcloud run deploy כערכים של השדה הזה.

    שלב ה-build הבא פורס את האימג' שנוצר קודם ב-Cloud Run:

    # Deploy to Cloud Run
- name: google/cloud-sdk
  args: ['gcloud', 'run', 'deploy', 'helloworld-${SHORT_SHA}', 
         '--image=us-central1-docker.pkg.dev/${PROJECT_ID}/${_ARTIFACT_REGISTRY_REPO}/myimage:${SHORT_SHA}', 
         '--region', 'us-central1', '--platform', 'managed', 
         '--allow-unauthenticated']

  7. שמירת יומני בדיקה ב-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:
  # Install dependencies
  - name: python
    entrypoint: pip
    args: ["install", "-r", "requirements.txt", "--user"]

  # Run unit tests
  - name: python
    entrypoint: python
    args: ["-m", "pytest", "--junitxml=${SHORT_SHA}_test_log.xml"] 

  # Docker Build
  - name: 'gcr.io/cloud-builders/docker'
    args: ['build', '-t', 
           'us-central1-docker.pkg.dev/${PROJECT_ID}/${_ARTIFACT_REGISTRY_REPO}/myimage:${SHORT_SHA}', '.']

  # Docker push to Google Artifact Registry
  - name: 'gcr.io/cloud-builders/docker'
    args: ['push',  'us-central1-docker.pkg.dev/${PROJECT_ID}/${_ARTIFACT_REGISTRY_REPO}/myimage:${SHORT_SHA}']

  # Deploy to Cloud Run
  - name: google/cloud-sdk
    args: ['gcloud', 'run', 'deploy', 'helloworld-${SHORT_SHA}', 
           '--image=us-central1-docker.pkg.dev/${PROJECT_ID}/${_ARTIFACT_REGISTRY_REPO}/myimage:${SHORT_SHA}', 
           '--region', 'us-central1', '--platform', 'managed', 
           '--allow-unauthenticated']

# Save test logs to Google Cloud Storage
artifacts:
  objects:
    location: gs://${_BUCKET_NAME}/
    paths:
      - ${SHORT_SHA}_test_log.xml
# Store images in Google Artifact Registry 
images:
  - us-central1-docker.pkg.dev/${PROJECT_ID}/${_ARTIFACT_REGISTRY_REPO}/myimage:${SHORT_SHA}

  8. מתחילים את ה-build: באופן ידני או באמצעות טריגרים של build.

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

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

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