בחירה של שיטת בידינג שתואמת ל-OCI

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

סקירה כללית על תהליך הבנייה ב-Cloud Foundry

כשמעבירים אפליקציה ל-Cloud Foundry, היא עוברת שלב בנייה שבו קוד המקור עובר קומפילציה על ידי buildpacks של Cloud Foundry v2.

הפלט של תהליך build ב-Cloud Foundry יוצר ארכיון שניתן להפעלה שנקרא droplet. ‫Droplets לא תואמים ישירות למפרט Open Container Initiative‏ (OCI) להפעלת קונטיינרים ב-Cloud Run.

כשמעבירים אפליקציות מ-Cloud Foundry ל-Cloud Run, צריך לשנות את תהליך הפיתוח של האפליקציה כדי ליצור קובצי אימג' של OCI בתקן התעשייה (לפעמים נקראים קובצי אימג' של Docker).

תרשים שמתאר איך נוצרים Droplets של Cloud Foundry

אסטרטגיות ליצירת תמונות שתואמות ל-OCI

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

שינוי אפליקציית Cloud Foundry (העברה והפעלה)

רכיבי הליבה של המערכת האקולוגית של Cloud Foundry (חבילות Buildpack v2,‏ Stemcell וכו') הם קוד פתוח. כלומר, אתם יכולים ליצור מחדש את תהליך יצירת הקונטיינר של האפליקציה על ידי ביצוע ההוראות במדריך שלנו בנושא 'Dockerize' של רכיבי ה-build המרכזיים כדי ליצור קובץ אימג' חדש שתואם ל-OCI.

יתרונות:

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

חסרונות:

  • צינור העיבוד ליצירת קונטיינרים של אפליקציות הוא בניהול עצמי.
  • רכיבי Cloud Foundry ישנים יותר נהנים מתחזוקה ותמיכה מוגבלות.
  • יש עלויות שוטפות של תחזוקת אבטחה, כולל:
    • בנייה מחדש של רכיבי הבנייה באופן קבוע כדי לוודא שמתקבלים תיקוני אבטחה.
    • בנייה מחדש של האפליקציות שעברו 'דוקריזציה' באופן שוטף, כדי להחיל את עדכוני האבטחה מרכיבי ה-build שנבנו מחדש.

שימוש ב-Cloud Native Buildpacks

מפרט Cloud Native Buildpacks (CNB) נוצר כדי לבצע מודרניזציה של המערכת האקולוגית של buildpacks ולאחד אותה. כלים לבנייה שתואמים למפרט CNB פועלים לפי תקנים פתוחים ויוצרים תמונות שתואמות ל-OCI. שלושה ספקי CNB נפוצים הם:

יתרונות:

  • האחריות לתחזוקה של ה-buildpack מוטלת על המפתחים שלו ועל ספקי הפלטפורמות.
  • ‫Buildpacks תומכים בשינוי בסיס של קונטיינרים על קובצי אימג' חדשים, כדי לבצע עדכוני אבטחה מהירים בלי לבנות מחדש את הקונטיינרים של האפליקציה.
  • ‫Buildpacks יוצרים תמונות OCI ניידות.
  • פרויקט CNB נמצא בשלבי פיתוח ב-Cloud Native Computing Foundation (CNCF) ויש לו קהילה פעילה של מפתחים ותורמים.

חסרונות:

  • פערים בפונקציונליות ובהגדרות בין חבילות Buildpack בגרסה 2 לבין חבילות Buildpack בגרסה 3.
  • יכול להיות שפריימוורקים ואינטגרציות שהותקנו בשמכם ב-Java v2 buildpacks לא יהיו זמינים ב-Java CNB buildpack.

שימוש בקובצי Dockerfile בניהול עצמי

אתם יכולים ליצור קובצי Dockerfile חדשים לגמרי כדי להוסיף את האפליקציה שלכם לקונטיינר. במאמר בנושא יצירת קונטיינרים מוסבר על קובצי אימג' של קונטיינרים שמתקבלים על ידי Cloud Run.

יתרונות:

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

חסרונות:

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

המלצות

צוותים שמוגבלים במשאבים ומעוניינים להעביר כמה שיותר אפליקציות צריכים קודם לשקול את אסטרטגיית ההעברה וההפעלה כדי לשנות את Cloud Foundry. אחרי שתעדכנו את האפליקציות כך שיהיו קובצי אימג' שתואמים ל-OCI, מומלץ לשקול שימוש ב-Cloud Native Buildpacks או בקובצי Dockerfile בניהול עצמי.

צוותים שמוכנים לבצע מיגרציה באופן מיידי צריכים לנסות Cloud Native Buildpacks ואז לעבור ל-Dockerfiles בניהול עצמי אם הם צריכים רמה גבוהה של שליטה בסביבה שלהם.

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