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

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

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

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

הפלט של תהליך 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 באופן שגרתי כדי לוודא שאתם מקבלים תיקוני אבטחה.
    • בנייה מחדש באופן שוטף של האפליקציות שעברו 'דוקריזציה' כדי להחיל את עדכוני האבטחה מרכיבי ה-build שנבנו מחדש.

שימוש ב-Cloud Native Buildpacks

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

יתרונות:

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

חסרונות:

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

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

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

יתרונות:

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

חסרונות:

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

המלצות

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

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

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