שיטות מומלצות להאצת תהליכי בנייה

בדף הזה מפורטות שיטות מומלצות להאצת תהליכי בנייה ב-Cloud Build.

פיתוח קונטיינרים יעילים יותר

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

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

מידע נוסף זמין במאמר יצירת קונטיינרים רזים יותר.

שימוש בקובץ אימג' של Docker ששמור במטמון

הדרך הכי קלה להגדיל את המהירות של יצירת קובץ אימג' של Docker היא לציין קובץ אימג' ששמור במטמון שאפשר להשתמש בו בגרסאות build עתידיות. אפשר לציין את קובץ האימג' שנשמר במטמון על ידי הוספת הארגומנט --cache-from לקובץ התצורה של ה-build. כך תנחו את Docker לבצע את ה-build באמצעות קובץ האימג' הזה כמקור מטמון.

כל קובץ אימג' של Docker מורכב משכבות מוערמות. השימוש ב---cache-from גורם לבנייה מחדש של כל השכבות מהשכבה שהשתנתה ועד לסוף הבנייה. לכן, השימוש ב---cache-from לא מועיל אם משנים שכבה בשלבים המוקדמים של בניית Docker.

מומלץ להשתמש תמיד ב---cache-from לבניית האפליקציות, אבל חשוב לזכור את ההערות הבאות:

  • כדי להשתמש במטמון, צריך קובץ אימג' של Docker שנבנה בעבר.
  • אפשר להשתמש ב---cache-from רק לבניית Docker, ולא לבנייה של כלים שיוצרים סוגים אחרים של ארטיפקטים.
  • צריך לאחזר את התמונה שנשמרה במטמון ממאגר, מה שיכול להאריך את זמן הבנייה.

בשלבים הבאים מוסבר איך לבצע build באמצעות אימג' ששמור במטמון:

YAML

  1. בקובץ התצורה של ה-build, מוסיפים הוראות ל:

    • שולפים את התמונה שנשמרה במטמון מ-Artifact Registry. בשלב ה-build‏ docker pull, המשתנה entrypoint מוגדר לערך bash, כך שאפשר להריץ את הפקודה ולהתעלם מהשגיאה שמוחזרת. ההגדרה הזו נדרשת כשיוצרים תמונה בפעם הראשונה, ואין ל-docker pull תמונה קיימת שאפשר לשלוף.

    • מוסיפים ארגומנט --cache-from כדי להשתמש בתמונה הזו לבנייה מחדש.

      steps:
- name: 'gcr.io/cloud-builders/docker'
  entrypoint: 'bash'
  args: ['-c', 'docker pull ${_LOCATION}-docker.pkg.dev/$PROJECT_ID/${_REPOSITORY}/${_IMAGE}:latest || exit 0']
- name: 'gcr.io/cloud-builders/docker'
  args: [
            'build',
            '-t', '${_LOCATION}-docker.pkg.dev/$PROJECT_ID/${_REPOSITORY}/${_IMAGE}:latest',
            '--cache-from', '${_LOCATION}-docker.pkg.dev/$PROJECT_ID/${_REPOSITORY}/${_IMAGE}:latest'
            '.'
        ]
images: ['${_LOCATION}-docker.pkg.dev/$PROJECT_ID/${_REPOSITORY}/${_IMAGE}:latest']

  2. יוצרים את קובץ האימג' באמצעות הגדרות ה-build הקודמות:

    gcloud builds submit --config cloudbuild.yaml .

JSON

  1. בקובץ התצורה של ה-build, מוסיפים הוראות ל:

    • שולפים את התמונה שנשמרה במטמון מ-Artifact Registry. בשלב ה-build‏ docker pull, המשתנה entrypoint מוגדר לערך bash, כך שאפשר להריץ את הפקודה ולהתעלם מהשגיאה שמוחזרת. ההגדרה הזו נדרשת כשיוצרים תמונה בפעם הראשונה, ואין ל-docker pull תמונה קיימת שאפשר לשלוף.
    • מוסיפים ארגומנט --cache-from כדי להשתמש בתמונה הזו לבנייה מחדש.
    {
    "steps": [
    {
        "name": "gcr.io/cloud-builders/docker",
        "entrypoint": "bash",
        "args": ["-c", "docker pull ${_LOCATION}-docker.pkg.dev/$PROJECT_ID/${_REPOSITORY}/${_IMAGE}:latest || exit 0"]
    },
    {
        "name": "gcr.io/cloud-builders/docker",
        "args": [
            "build",
            "-t",
            "${_LOCATION}-docker.pkg.dev/$PROJECT_ID/${_REPOSITORY}/${_IMAGE}:latest",
            "--cache-from",
            "${_LOCATION}-docker.pkg.dev/$PROJECT_ID/${_REPOSITORY}/${_IMAGE}:latest",
            "."
        ]
    }
    ],
    "images": ["${_LOCATION}-docker.pkg.dev/$PROJECT_ID/${_REPOSITORY}/${_IMAGE}:latest"]
}

    where [IMAGE] is the name of your image.

  2. יוצרים את קובץ האימג' באמצעות הגדרות ה-build הקודמות:

    gcloud builds submit --config cloudbuild.json .

שמירת ספריות במטמון באמצעות Google Cloud Storage

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

בניגוד ל---cache-from, שמתאים רק לבניית Docker, אפשר להשתמש במטמון של Cloud Storage לכל כלי בנייה שנתמך על ידי Cloud Build.

כדי לשמור במטמון ספריות באמצעות Cloud Storage, מבצעים את השלבים הבאים:

YAML

  1. בקובץ הגדרות ה-build, מוסיפים הוראות ל:

    • מעתיקים את התוצאות של build קודם מקטגוריית Cloud Storage.
    • שימוש בתוצאות עבור הגרסה הנוכחית.

    • מעתיקים את התוצאות החדשות בחזרה לקטגוריה.

      steps:
- name: gcr.io/cloud-builders/gcloud
    args: ['storage', 'cp', 'gs://mybucket/results.zip', 'previous_results.zip']
# operations that use previous_results.zip and produce new_results.zip
- name: gcr.io/cloud-builders/gcloud
    args: ['storage', 'cp', 'new_results.zip', 'gs://mybucket/results.zip']

  2. יוצרים את הקוד באמצעות הגדרת ה-build הקודמת:

    gcloud builds submit --config cloudbuild.yaml .

JSON

  1. בקובץ הגדרות ה-build, מוסיפים הוראות ל:

    • מעתיקים את התוצאות של build קודם מקטגוריית Cloud Storage.
    • שימוש בתוצאות עבור הגרסה הנוכחית.

    • מעתיקים את התוצאות החדשות בחזרה לקטגוריה.

      {
    "steps": [
    {
        "name": "gcr.io/cloud-builders/gcloud",
        "args": ["storage", "cp", "gs://mybucket/results.zip", "previous_results.zip"]
    },
    {
        // operations that use previous_results.zip and produce new_results.zip
    },
    {
        "name": "gcr.io/cloud-builders/gcloud",
        "args": ["storage", "cp", "new_results.zip", "gs://mybucket/results.zip"]
    }
    ]
}

  2. יוצרים את הקוד באמצעות הגדרת ה-build הקודמת:

    gcloud builds submit --config cloudbuild.json .

איך להימנע מהעלאה של קבצים מיותרים

כשמפעילים build מטריגר לפיתוח גרסת Build של Cloud Build, ספריית הקוד מועלית לשימוש על ידי Cloud Build.

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

דוגמאות לקבצים שנכללים בדרך כלל בהחרגות:

  • תיעוד וקוד לדוגמה למפתחי פרויקטים
  • קוד פיגום שנוצר, קבצים בינאריים, קובצי *.jar או נכסי אינטרנט שעברו קומפילציה ומשמשים לפיתוח.
  • יחסי תלות של צד שלישי בבעלות ספק לפיתוח מקומי

כדי להכין קובץ .gcloudignore לטיפול במקרים האלה, יוצרים קובץ בתיקיית השורש של הפרויקט עם תוכן כמו:

.git
dist
node_modules
vendor
*.jar

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

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