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

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

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

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

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

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

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

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

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

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

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

• כדי לאחסן יומני בדיקה ב-Logging, צריך להקצות לחשבון השירות של ה-Build את התפקיד יצירת אובייקטים של אחסון (roles/storage.objectCreator) בקטגוריה של Cloud Storage.

• כדי לאחסן תמונות שנוצרו ב-Artifact Registry, צריך להעניק לחשבון השירות של שירות ה-Build את התפקיד Artifact Registry Writer ‏(roles/artifactregistry.writer).

הוראות להקצאת התפקידים האלה מופיעות במאמר הקצאת תפקיד באמצעות הדף 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. הוספת האפליקציה למאגר: אחרי שמוסיפים את שלב הבנייה כדי לוודא שהבדיקות עברו בהצלחה, אפשר לבנות את האפליקציה. ‫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), צריך לבצע את הפעולות הבאות:

   • משתמשים בשדה images בשלב הבנייה במקום להשתמש בשלב בנייה נפרד Docker push.
   • מוסיפים את requestedVerifyOption: VERIFIED לקטע options בקובץ הגדרות ה-build.

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. מתחילים את הבנייה: באופן ידני או באמצעות טריגרים של בנייה.

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

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

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

• איך צופים בתוצאות של בניית האפליקציה
• איך מאבטחים את הגרסאות
• איך יוצרים אפליקציות Python עצמאיות
• איך משתמשים בתלות פרטית
• איך פותרים בעיות שקשורות לבנייה