האצת הפיתוח ב-Cloud Code ל-VS Code

כדי להאיץ את הפיתוח המקומי ב-Cloud Code ל-VS Code, כדאי להשתמש בסנכרון קבצים וטעינה מחדש של קבצים, בפריסה אוטומטית בעת שמירה ובמודולים לפיתוח חלקים של אפליקציה בנפרד.

הפעלה של סנכרון קבצים וטעינה מחדש של קבצים

כדי לשפר את היעילות של תהליך העבודה של הפיתוח המקומי ולמנוע את הצורך לבנות מחדש, לפרוס מחדש ולהפעיל מחדש את ה-pods,‏ Cloud Code תומך בהעתקת קבצים שהשתנו למאגר שנפרס. כלומר, כשמבצעים שינויים בקבצים סטטיים ובקבצי קוד מקור, אפשר לראות את השינויים תוך שניות, וכך לקבל משוב מהר יותר.

כשמדובר בקבצים סטטיים (כמו קובצי HTML ו-CSS), התנהגות העתקת הקבצים הזו נקראת סנכרון קבצים.

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

  • ‫Go:‏ ‎*.go
  • ‫Java:‏ ‎*.java, *.kt, *.scala, *.groovy, *.clj
  • ‫NodeJS:‏ ‎*.js, *.mjs, *.coffee, *.litcoffee, *.json

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

כשעובדים עם Buildpacks ככלי הבנייה המועדף, סנכרון קבצים אוטומטי וטעינה מחדש של קבצים מופעלים כברירת מחדל. ב-builders אחרים כמו Docker, אפשר לציין קטע sync בקובץ skaffold.yaml בשביל הארטיפקט שרוצים להתאים אישית.

הגדרת הסנכרון יכולה להיות אחת מהאפשרויות הבאות (לפי סדר העדיפות):

  • ‫auto: Cloud Code מגדיר את הסנכרון באופן אוטומטי. (רק לארטיפקטים של Jib ו-Buildpacks). זוהי הגדרת ברירת המחדל עבור Buildpacks.
  • ‫infer: היעדים של כל קובץ שמשתנה מוסקים מה-builder.
  • ‫manual: צריך לציין את הקבצים בסביבת העבודה המקומית ואת היעד שלהם בקונטיינר הפועל.

בדוגמה הבאה מוצג קטע sync בקובץ skaffold.yaml שמציין סנכרון manual כדי לסנכרן את כל קובצי ה-HTML של /static-html לתיקייה static במאגר:

build:
  artifacts:
    - image: gcr.io/k8s-skaffold/node-example
      context: node
      sync:
        manual:
          - src: 'static-html/*.html'
            dest: static

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

הוספת תכונות חדשות במהלך פיתוח ב-Kubernetes

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

מחזור איטרציה רגיל נראה כך:

  1. מבצעים שינוי בפרויקט. לדוגמה, אם משתמשים באפליקציית Cloud Code Java Guestbook, מוסיפים נקודת קצה חדשה למחלקה FrontendController באופן הבא:

    1. פותחים את הקובץ FrontendController.java מתוך src/main/java/cloudcode/guestbook/frontend ומוסיפים את השורות הבאות:

      @RequestMapping("/greeting")
@ResponseBody
public String greeting(@RequestParam(value="name", defaultValue="World") String name) {
   return String.format("Hello from Kubernetes with IntelliJ, %s!", name);
}

    2. מוסיפים את ההצהרות הנדרשות לייבוא של ההערות החדשות, RequestMapping ו-ResponseBody.

  2. שומרים את השינויים (Ctrl/Cmd+S) או בונים את הפרויקט.

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

  3. כדי לסיים את סשן הפיתוח הרציף, לוחצים על סמל ההפסקה.

    ‫Cloud Code מוחק את כל משאבי Kubernetes שנעשה בהם שימוש במהלך סשן הפיתוח.

פיתוח אפליקציות של מיקרו-שירותים באמצעות הגדרות skaffold.yaml

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

אתם יכולים לפתח ולנפות באגים בחלקים של האפליקציה באופן עצמאי על ידי פיצול האפליקציה למודולים. לדוגמה, Bank of Anthos הוא אפליקציה לדוגמה שמכילה עשרה מיקרו-שירותים. בקובץ skaffold.yaml של הדוגמה, השירותים האלה מקובצים לחמישה מודולים בשמות setup, ‏db, ‏frontend, ‏backend ו-loadgenerator.

הגדרת מודולים ויחסי תלות בהגדרות

כדי להגדיר מודולים ויחסי תלות בהגדרות:

  1. פותחים את הפרויקט שבו רוצים להגדיר את המודולים.

  2. פותחים את הקובץ skaffold.yaml.

  3. אם בקובץ skaffold.yaml יש כמה הגדרות, כדי להפוך הגדרה למודול, מציינים את השורה הבאה:

    metadata:
  name: MODULE_NAME_1

    לדוגמה, במודול db של Bank of Anthos skaffold.yaml מוגדרות פריסות של מסדי נתונים:

    apiVersion: skaffold/v3
kind: Config
metadata:
  name: db # module defining database deployments
requires:
- configs:
  - setup
build:
  artifacts:
  - image: accounts-db
    context: src/accounts-db
  - image: ledger-db
    context: src/ledger-db
manifests:
  rawYaml:
  - dev-kubernetes-manifests/accounts-db.yaml
  - dev-kubernetes-manifests/ledger-db.yaml
deploy:
  kubectl: {}

  4. אם יש הגדרות שתלויות בהגדרות אחרות שצריך לפרוס לפני שניתן לפרוס את ההגדרה הנוכחית, צריך להוסיף את ההגדרה לתלות. כדי לציין תלות בהגדרות, מוסיפים רשימה של configs לקטע requires בקובץ skaffold.yaml.

    לדוגמה, קובץ skaffold.yaml Bank of Anthos כולל את תלות התצורה setup.

    כדי להגדיר תלות, מוסיפים את השורה הבאה לקובץ skaffold.yaml, כאשר DEPENDENCY_NAME הוא שם התלות.

    requires:
    - configs: DEPENDENCY_NAME

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

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

בניית מודולים ספציפיים והתלויות שלהם

אחרי שמגדירים את המודולים ואת התלות שלהם, אפשר לציין אילו מודולים רוצים להריץ באמצעות Cloud Code בקובץ launch.json.

אם לא מוגדר קובץ launch.json בפרויקט, כשמריצים את הפקודות Cloud Code: Run on Kubernetes או Cloud Code: Debug on Kubernetes, מוצגת בקשה לבחור את המודולים לבנייה:

  1. פותחים את חלונית הפקודות (Ctrl/Cmd+Shift+P) ומריצים את Cloud Code: Run on Kubernetes.
  2. לוחצים על בחירת מודולים.
  3. בוחרים את המודולים שרוצים לפרוס ולוחצים על אישור. כל מודול בנוי עם יחסי התלות שלו.
  4. כשמוצגת בקשה, בוחרים מאגר תמונות ולוחצים על Enter.

אם בפרויקט יש launch.json, פועלים לפי השלבים הבאים כדי לבחור את המודולים לבנייה:

  1. פותחים את הקובץ launch.json של הפרויקט.

  2. עורכים את הגדרות ההפעלה כדי להוסיף את האפשרות skaffoldFlags עם רשימה מופרדת בפסיקים של modules לבנייה. אם לא מציינים את skaffoldFlags, כל המודולים נבנים.

      {
    "name": "Run on Kubernetes",
    "type": "cloudcode.kubernetes",
    "request": "launch",
    "skaffoldConfig": "${workspaceFolder}/skaffold.yaml",
    "skaffoldFlags": {
       "modules": ["MODULE_NAME_2,MODULE_NAME_2"],
    "watch": true,
    "cleanUp": true,
    }
  }

  3. מריצים את הגדרת ההפעלה שערכתם.

פיתוח רציף ב-Kubernetes

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

יעד ההרצה Run on Kubernetes (הרצה ב-Kubernetes) מתחיל את מחזור הפיתוח באשכול Kubernetes. אחרי שמתחילים את מחזור הפיתוח, Cloud Code יוצר אימג' לפרויקט, מתייג אותו, מעלה אותו למאגר שהוגדר ומשתמש ב-kubectl כדי לפרוס את מניפסטים של Kubernetes בפרויקט.

  1. אפשר להתאים אישית את הפריסה באמצעות אפשרויות ההגדרה הזמינות.
  2. אם האפליקציה שלכם מוגדרת לשימוש במודולים, אתם יכולים לבחור מודולים ספציפיים לבנייה או לפריסה.
  3. פותחים את לוח הפקודות (מקישים על Ctrl/Cmd+Shift+P) ומריצים את הפקודה Cloud Code: Run on Kubernetes.
  4. מאשרים אם להשתמש בהקשר הנוכחי של Kubernetes כדי להריץ את האפליקציה (או עוברים להקשר מועדף). מידע נוסף על הגדרת הקשר של Kubernetes זמין במאמר הגדרת התצורה.

  5. אם בחרתם באשכול מרוחק כהקשר, כשתתבקשו, בחרו במאגר תמונות להעלאת התמונות. אם Artifact Registry API מופעל בפרויקט שלכם ויש בו לפחות מאגר אחד של Artifact Registry, תוכלו לעיין במאגר קיים של Artifact Registry ולבחור אותו.

    ‫Cloud Code יוצר את הקונטיינרים, מעביר אותם בדחיפה למאגר, מחיל את ההגדרות של Kubernetes על האשכול וממתין להשקה.

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

תמיכה

כדי לשלוח משוב, לדווח על בעיות ב-GitHub או לשאול שאלה ב-Stack Overflow.