הדרישות לאריזת האפליקציה

בדף הזה מתוארות הדרישות לאריזת אפליקציית Kubernetes, והנחיות לעמידה בדרישות האלה.

חבילת האפליקציה היא חבילה של קובצי תצורה וקובצי אימג' של קונטיינרים שנפרסים באשכולות Kubernetes של המשתמשים. כדי לתמוך בפריסת האפליקציה ב-Google Kubernetes Engine מהמסוף Google Cloud , חבילת ה-APK של האפליקציה צריכה לכלול קונטיינר פריסה. קונטיינר הפריסה דוחף את קובצי התצורה ואת מטא-נתונים מוצגים אל Kubernetes API.

חבילת APK מאפשרת למשתמשי Google Cloud :

  • איך מוצאים את האפליקציה בקטלוג של Cloud Marketplace
  • פריסת האפליקציה באשכול GKE או GKE Enterprise באמצעות מסוף Google Cloud
  • אינטראקציה עם האפליקציה הפועלת באמצעות מסוף Google Cloud

בנוסף לתמיכה בפריסה באמצעות מסוף Google Cloud , החבילה צריכה לכלול שלבים למשתמשים לפריסת האפליקציה באמצעות ממשק שורת פקודה (CLI), באמצעות כלים כמו kubectl או Helm.

דוגמאות לחבילות אפליקציות זמינות במאגר GitHub של פתרונות Google Click to Deploy. המאגר מכיל חבילות לאפליקציות פופולריות בקוד פתוח, כמו WordPress ו-Elasticsearch.

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

  • מוודאים שהגדרתם את הסביבה Google Cloud .
  • יוצרים מאגר Git ציבורי לקובצי ההגדרות, למדריך למשתמש ולמשאבים אחרים להפעלת האפליקציה. אפשר לארח את המאגר אצל ספק כמו GitHub או Cloud Source Repositories, או בשרת שלכם. מומלץ להשתמש במאגר ייעודי לכל מוצר שאתם מפיצים.

סקירה כללית

האפליקציה צריכה לעמוד בדרישות הבאות:

  • מאגר ה-Git חייב להכיל קובץ LICENSE, שכולל את רישיון הקוד הפתוח של המאגר.

  • מאגר ה-Git שלכם חייב להכיל קובץ הגדרה שפורס את האפליקציה. קובץ ההגדרה יכול להיות מניפסט Kubernetes YAML או תרשים Helm.

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

    דרישות ההגדרה

  • האפליקציה שלכם צריכה לפעול בצמתים באמצעות מעבד x86.

  • אם רוצים שהאפליקציה תהיה תואמת ל-Istio, כדאי לעיין במגבלות על אשכולות שמריצים Istio.

  • אם האפליקציה שלכם היא מסחרית (לא BYOL), היא צריכה לדווח על השימוש שלה ל-Google, כדי שהלקוחות שלכם יחויבו בצורה מדויקת. מומלץ לשלב את האפליקציה עם הסוכן לחיוב לפי שימוש, ששולח דוחות שימוש ל-Google.

    הדרישות לשילוב סוכן החיוב

  • אתם צריכים להעלות את כל קובצי האימג' בקונטיינרים של האפליקציה שלכם למאגר ב-Artifact Registry או ב-Container Registry. במאגר צריך להיות גם תמונה של מפיץ, שמעבירה את הגדרות האפליקציה ל-Kubernetes API כשהמשתמשים פורסים את האפליקציה ממסוף Google Cloud .

    דרישות ליצירת תמונות של אפליקציות

  • חובה לכלול בדיקות שילוב לאפליקציה.

    דרישות תהליך האימות

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

    דרישות למדריך למשתמש

הדרישות להגדרה

אתם יכולים לספק את ההגדרה שלכם כמניפסט של Kubernetes או כתרשים Helm.

ההגדרות צריכות לעמוד בדרישות הבאות:

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

  • ההגדרה שלכם צריכה לפרוס משאב מותאם אישית מסוג Application. משאב האפליקציה מכיל את המידע שהמשתמשים רואים כשהם פורסים את האפליקציה שלהם דרך ממשק המשתמש של Cloud Marketplace.

    משאב האפליקציה הוא משאב בהתאמה אישית שמצטברים בו רכיבי Kubernetes שמשויכים לאפליקציה, והוא מאפשר למשתמשים לנהל את המשאבים האלה כקבוצה.

    מידע על יצירת משאב Application ודוגמאות זמין במאגר GitHub של Application.

  • בהגדרה שלכם צריך להשתמש בפרמטרים שאפשר להחליף, באמצעות envsubst או כדגלים.

    צריך להיות אפשר להחליף את הפרמטרים הבאים:

    • מרחב שמות: כל המשאבים בהגדרה צריכים להיות שייכים למרחב שמות אחד. משתמשים ב-Cloud Marketplace מגדירים את מרחב השמות הזה כשהם פורסים את האפליקציה שלכם. מומלץ להימנע מקידוד קשיח של מרחבי שמות במניפסטים, כדי שהמשאבים שאתם מציינים ייצרו במרחב השמות שהמשתמשים בוחרים. לפעמים מרחבי שמות מופיעים גם בתוך הגדרות של משאבים, למשל כשמפנים אל ServiceAccount בתוך RoleBinding. כל הפניה כזו חייבת להיות פרמטרית.

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

    • קובצי אימג' בקונטיינר: כל הפניה לקובץ אימג', למשל ב-PodSpec, צריכה להיות ניתנת להחלפה, כדי ש-Cloud Marketplace יוכל לבטל אותן ולהפנות לקובצי אימג' שפורסמו ב-Artifact Registry שלנו. היא גם מאפשרת ללקוחות להחליף תמונות שעברו שינוי.

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

      מידע נוסף על פרמטרים של הגדרות זמין ב-GitHub.

  • צריך להיות אפשר לפרוס את האפליקציה באמצעות כלים בצד הלקוח. לדוגמה, אם משתמשים ב-Helm, הפריסה צריכה לפעול עם הדגל --client-only של שורת הפקודה.

הגבלות על אשכולות עם Istio

אם רוצים שה-API יהיה תואם ל-Istio, צריך לעיין במגבלות שמתוארות בקטע הזה. סקירה כללית על Istio זמינה במאמר מה זה Istio?.

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

  • אם הפודים מריצים פקודות של kubectl שמשתמשות בכתובת ה-IP של האשכול, יכול להיות שהפקודות ייכשלו.

  • אם האפליקציה משתמשת בתקשורת מבוססת-IP או בתקשורת בין פודים, יכול להיות ששלב יצירת האשכול ייכשל.

  • יכול להיות שהחיבורים החיצוניים לשירותים של צד שלישי, כמו מאגרי חבילות של מערכת הפעלה, ייחסמו. לקוחות צריכים להגדיר תעבורת נתונים יוצאת (egress) ב-Istio כדי לאפשר גישה לשירותים חיצוניים.

מומלץ להגדיר חיבורים נכנסים באמצעות Istio Gateway, במקום באמצעות משאבי LoadBalancer או Ingress.

אם אתם משתמשים ב-Helm להגדרה, צריך להשתמש במאפיין x-google-marketplace ISTIO_ENABLED בסכימה של תמונת הפריסה. אם הנכס הזה הוא true, כלי הפריסה צריך לשנות את הפריסה, למשל להמתין עד ש-Istio sidecar יהיה מוכן.

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

הדרישות לשילוב סוכן החיוב

אם אתם מוכרים אפליקציה מסחרית, מומלץ לשלב את האפליקציה עם הסוכן לחיוב לפי שימוש (UBB).

הסוכן מטפל באימות ובדיווח לנקודת הקצה של Google לדיווח על שימוש: Service Control API. אחרי ששולח מודל התמחור, צוות Cloud Marketplace יוצר שירות לאפליקציה כדי לדווח על השימוש בה, ומדדי חיוב למדידת השימוש.

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

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

לקוחות רוכשים את האפליקציה ב-Cloud Marketplace כדי לקבל רישיון, שמצורף לאפליקציה בזמן הפריסה.

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

  • הלקוח ביטל את המינוי.

  • יכול להיות שהלקוח השבית בטעות את ערוץ הדיווח. לדוגמה, יכול להיות שהלקוחות יסירו את הסוכן בטעות או יגדירו אותו בצורה שגויה, או שהרשת תמנע מהסוכן לגשת לנקודת הקצה של הדיווח של Google.

מומלץ לפעול לפי השיטות המומלצות לדיווח על השימוש ולטיפול במקרים שבהם Google לא מקבלת נתוני שימוש והלקוחות לא מחויבים.

שילוב של סוכן החיוב

אפשר לשלב את הסוכן כקונטיינר sidecar, שפועל באותו Pod כמו האפליקציה, או באמצעות ה-SDK.

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

בגישת ה-SDK, צריך לקמפל את הסוכן או לקשר אותו לקובץ הבינארי של האפליקציה. ה-SDK מוטמע באופן מקורי ב-Go, עם קשירות ל-Python.

באופן כללי, הגישה של sidecar דורשת פחות מאמץ לשילוב, בעוד שערכת ה-SDK חזקה יותר מפני השבתה מקרית.

שלבים מפורטים לביצוע השילוב מופיעים בקובץ ה-README במאגר GitHub של Usage-based Billing Agent. כדי לראות דוגמה להטמעה, אפשר לעיין במאגרי האפליקציות והכלים.

פרטי הכניסה לדיווח על השימוש

הסוכן לחיוב צריך פרטי כניסה שיאפשרו לו לשלוח דוחות שימוש ל-Google. ‫Cloud Marketplace יוצר את פרטי הכניסה האלה כשמשתמשים פורסים את האפליקציה מ-Cloud Marketplace, ומוודא שהם קיימים כ-Secret במרחב השמות של Kubernetes לפני פריסת האפליקציה. השם של הסוד הזה מועבר לאפליקציה כמאפיין הסכימה REPORTING_SECRET schema.

דוגמה למניפסט שמשתמש בסוד הדיווח מופיעה בדוגמה לאפליקציית WordPress ב-GitHub.

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

entitlement-id

מזהה שמייצג את הסכמת הלקוח לרכישת התוכנה ולשימוש בה.

consumer-id

מזהה שמשויך לזכאות ומועבר ל-Google Service Control API יחד עם דוחות השימוש.

reporting-key

מפתח ה-JSON של חשבון השירות ב-Google Cloud שמשמש לאימות ב-Google Service Control API.

אם המוצר שלכם כולל רכיב SaaS בנוסף לאפליקציה, אתם יכולים להגדיר שרכיב ה-SaaS יבדוק מעת לעת את התוקף של מזהי הזכאות באמצעות שירות הרכש של Cloud Marketplace. כדי לקבל גישה לשירות הרכש, צריך לפנות ל-Partner Engineer.

מידע על פרמטרים אחרים שמועברים לאפליקציה מופיע בהמשך הקטע במאמר בנושא פרמטרים שמועברים לאפליקציה.

דרישות לפיתוח קובצי אימג' של קונטיינרים

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

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

אם תמונת האפליקציה שלכם תלויה בתמונת בסיס, כמו Debian, או בתמונת זמן ריצה של שפה, כמו Python או OpenJDK, מומלץ מאוד להשתמש באחת מתמונות הקונטיינר המאושרות של Cloud Marketplace. כך תוכלו לוודא שתמונת הבסיס שלכם תתעדכן בזמן, במיוחד כשמדובר בתיקוני אבטחה.

אחרי שיוצרים את קובצי האימג' של האפליקציה, מעבירים אותם בדחיפה למאגר הזמני שיצרתם ב-Artifact Registry או ב-Container Registry כשהגדרתם את הסביבה.

מאגר Artifact Registry או Container Registry צריך להיות במבנה הבא:

  • התמונה הראשית של האפליקציה צריכה להיות בתיקיית השורש של המאגר. לדוגמה, אם מאגר Artifact Registry או Container Registry הוא gcr.io/exampleproject/exampleapp, קובץ האימג' של האפליקציה צריך להיות ב-gcr.io/exampleproject/exampleapp.

  • התמונה של קונטיינר הפריסה צריכה להיות בתיקייה בשם deployer. בדוגמה הקודמת, תמונת הפריסה צריכה להיות ב-gcr.io/exampleproject/exampleapp/deployer.

  • אם האפליקציה משתמשת בתמונות מאגר נוספות, כל תמונה נוספת צריכה להיות בתיקייה משלה מתחת לתמונה הראשית. לדוגמה, אם האפליקציה שלכם דורשת תמונה בגודל proxy, מוסיפים את התמונה ל-gcr.io/exampleproject/exampleapp/proxy.

  • כל התמונות של האפליקציה צריכות להיות מתויגות עם ערוץ ההפצה והגרסה הנוכחית. לדוגמה, אם אתם משיקים את גרסה 2.0.5 בערוץ ההפצה 2.0, צריך לתייג את כל התמונות בתגי 2.0 ו-2.0.5. מידע נוסף על ארגון הגרסאות

  • כל התמונות באפליקציה צריכות לכלול את ההערה הבאה במניפסט התמונות:

    com.googleapis.cloudmarketplace.product.service.name=services/SERVICE_NAME

    מחליפים את SERVICE_NAME בשם השירות של המוצר (לדוגמה, example.endpoints.example-project.cloud.goog). כדי למצוא את שם השירות של המוצר, עוברים לדף סקירה כללית בפורטל של ספק התוכן ובודקים את העמודה שם השירות. מידע נוסף על הערות זמין במאמרי העזרה של Open Container Initiative בנושא הערות ב-GitHub.

לדוגמה, בתמונה הבאה מוצגים המאגרים של Artifact Registry ו-Container Registry עבור אפליקציית Kubernetes‏ Grafana Cluster. ערוץ ההפצה הוא 5.3, והאפליקציה מכילה את קובץ האימג' הראשי של האפליקציה, את קובץ האימג' של כלי הפריסה בתיקייה משלו ואת קובץ האימג' של Debian 9 ב-debian9. כל התמונות במאגר מתויגות באותו טראק, 5.3, ובגרסה של הטראק, 5.3.4. הערך הזה צריך להיות זהה לערך שמופיע בשדה Version (גרסה) של הגדרת המשאב המותאם אישית (CRD) עבור משאב האפליקציה, כפי שמוצהר בכלי הפריסה.

דוגמה למבנה של מאגר Grafana Container Registry

המאגר נמצא בכתובת gcr.io/cloud-marketplace/google/grafana.

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

כדי להעלות את התמונות ל-Artifact Registry או ל-Container Registry, צריך לתייג אותן בשם הרישום ואז להעביר את התמונה בדחיפה באמצעות gcloud. לדוגמה, משתמשים בפקודות הבאות כדי לשלוח את התמונות של example-pro:

docker build -t gcr.io/my-project/example-pro:4.0   # release track 4.0
docker tag gcr.io/my-project/example-pro:4.0 gcr.io/my-project/example-pro:4.0.3  # release version 4.0.3
docker push gcr.io/my-project/example-pro:4.0
docker push gcr.io/my-project/example-pro:4.0.3

הוראות מפורטות לתיוג ולהעלאה של תמונות למאגר זמינות בתיעוד הרלוונטי של Artifact Registry או של Container Registry.

דרישות לגבי מאגר הפריסה

הקונטיינר לפריסה, או הפורס, משמש כשלקוחות פורסים את המוצר שלכם מ-Cloud Marketplace. תמונת הפריסה כוללת את חבילת ההגדרות של Kubernetes של האפליקציה ואת כלי הלקוח, כמו kubectl או Helm, שמעבירים את ההגדרות אל Kubernetes API. בדרך כלל, כלי הפריסה צריך להשתמש באותה קבוצה של פקודות משורת הפקודה שמשתמש יפעיל כדי לפרוס את האפליקציה.

כדי ליצור את כלי הפריסה, משתמשים באחד מקובצי האימג' הבסיסיים של קונטיינרים לפריסה מספריית Marketplace של מאגר הכלים:

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

הוראות ליצירת קובץ האימג' של כלי הפריסה זמינות במאמר יצירת כלי לפריסת אפליקציות.

פרמטרים שמועברים לאפליקציה

במאגר התגים של הפריסה צריך להצהיר על פרמטרים שצריך לאסוף מהלקוחות כשהם בוחרים את האפליקציה שלכם. הפרמטרים האלה מועברים למאגר התגים של הפריסה כשהמשתמשים פורסים את האפליקציה.

כדי להגדיר את הפרמטרים האלה, קובץ האימג' של הקונטיינר לפריסה צריך לכלול סכימת JSON בפורמט YAML בנתיב הבא: /data/schema.yaml.

מידע נוסף על יצירת schema.yaml זמין במאמר סכימת כלי הפריסה.

בקשות לאשכולות GPU

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

יכול להיות שהאפליקציה תבקש GPU גנרי של Nvidia או פלטפורמה ספציפית של Nvidia.

דרישות תהליך האימות

האפליקציות מופעלות במערכת האימות שלנו כדי לוודא ש:

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

כדי לפרסם אפליקציה ב-Google Cloud Marketplace, צריך להשיג תוצאות מוצלחות.

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

הדרישות לגבי מדריך למשתמש

מדריך המשתמש צריך לכלול את הפרטים הבאים:

סקירה כללית

  • סקירה כללית של האפליקציה, כולל פונקציות בסיסיות ואפשרויות הגדרה. בקטע הזה צריך להיות גם קישור למוצר שפורסם ב-Cloud Marketplace.

הגדרה חד-פעמית

  • הגדרת כלי לקוח כמו kubectl או Helm, לפי הצורך.
  • התקנת Application CustomResourceDefinition ‏ (CRD), כדי שהאשכול יוכל לנהל את משאב האפליקציה.
  • אם אתם מוכרים אפליקציה מסחרית, אתם צריכים לבצע את השלבים הבאים כדי לקבל ולפרוס סוד של רישיון מ-Cloud Marketplace.

התקנה

  • פקודות לפריסת האפליקציה.
  • העברת פרמטרים זמינה בהגדרות בממשק המשתמש.
  • הצמדת הפניות לתמונות לערכי גיבוב (digest) שלא משתנים.

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

    מידע נוסף על הוספת שדות קלט לכלי הפריסה

שימוש בסיסי

  • מתחברים למסוף Admin (אם רלוונטי).
  • חיבור כלי לקוח והרצת פקודה לדוגמה (אם רלוונטי).
  • שינוי שמות משתמש וסיסמאות.

  • הפעלת כניסה והתקנת אישורי Transport Layer Security (‏TLS), אם רלוונטי.

    מידע נוסף על הפעלת ingress והתקנת אישורי TLS

גיבוי ושחזור

  • מגבה את מצב האפליקציה.
  • שחזור מצב האפליקציה מגיבוי.

עדכונים של תמונות

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

שינוי גודל

  • שינוי גודל האפליקציה (אם רלוונטי).

מחיקה

  • מחיקת האפליקציה.
  • ניקוי משאבים שאולי נשארו ללא בעלים בכוונה, כמו PersistentVolumeClaims.
הקודם
בחירת מודל תמחור
הבא
שליחת האפליקציה אל Google Cloud Marketplace