הערכת אפליקציות Java לצורך מודרניזציה

בדף הזה מוסבר איך להשתמש ב-Google Cloud Modernization Hub בGoogle Cloud מסוף כדי להעריך אפליקציות Java ארגוניות לצורך העברה ל-Linux containerization ומודרניזציה לגרסאות Java Long-Term Support‏ (LTS) בפלטפורמות שונות (כמו Java 17 או Java 21) ב- Google Cloud.

הרבה אפליקציות Java ארגוניות מסתמכות על ממשקי API מדור קודם של Java EE, על הגדרות קנייניות של שרת אפליקציות (כמו WebLogic,‏ WebSphere או JBoss) או על ספריות מיושנות של צד שלישי שמונעות פריסה ישירה למאגרי Linux. הערכה אוטומטית ב-Modernization Hub מנתחת את קוד המקור, מזהה חסימות להעברה, מעריכה את התאימות של התלות ב-Maven או ב-Gradle וממליצה על נתיבי שינוי מבנה ל-Cloud Run או ל-Google Kubernetes Engine.

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

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

  • מעבר לפלטפורמה של קונטיינרים ב-Linux: צריך לזהות תלות ספציפית בסביבה (כמו גישה למערכת קבצים מקומית, ספריות JNI או ממשקי API של שרת אפליקציות קנייני) לפני שמכניסים אפליקציות לקונטיינרים ל-Cloud Run או ל-GKE.
  • שדרוג גרסאות של Java runtime: הערכת המאמץ והפערים בתאימות במהלך מעבר מ-Java 8 או מ-Java 11 לגרסאות LTS מודרניות של Java (Java 17 או Java 21), או מעבר מ-Java EE ‏ (javax.*) ל-Jakarta EE ‏(jakarta.*).
  • פירוק ארכיטקטורות מונוליתיות: גילוי רכיבי EJB עם צימוד הדוק, ברוקרים של הודעות JMS או פריסות מונוליתיות של WAR ו-EAR שנדרש לבצע בהן שינוי מבנה למיקרו-שירותים מקוריים בענן או לאפליקציות Spring Boot.

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

לפני שמתחילים עבודת הערכה של Java במסוף, צריך להפעיל את ממשקי ה-API הנדרשים, לוודא שיש לכם את ההרשאות הנדרשות בממשק לניהול הזהויות והרשאות הגישה (IAM) בפרויקט, לרשום קטגוריה של הגדרות סביבת העבודה ולהעלות את ארכיון קוד המקור ל-Cloud Storage.

הפעלת ממשקי ה-API הנדרשים

כדי להשתמש ב-Modernization Hub, צריך להפעיל את ממשקי ה-API הנדרשים של השירות Google Cloudבפרויקט:

gcloud services enable \
    aiplatform.googleapis.com \
    artifactregistry.googleapis.com \
    cloudbuild.googleapis.com \
    cloudresourcemanager.googleapis.com \
    compute.googleapis.com \
    logging.googleapis.com \
    storage.googleapis.com \
    --project=PROJECT_ID

מחליפים את PROJECT_ID במזהה הפרויקט ב- Google Cloud .

התפקידים הנדרשים

כדי להריץ הערכה, צריך הרשאות IAM שונות לשתי זהויות באמצעות Cloud Build ו-Gemini Enterprise Agent Platform:

  • משתמש מאומת במסוף (שמפעיל את העבודה וניגש לדליים):
    • אדמין לניהול נפח האחסון (roles/storage.admin)
    • משתמש בחשבון שירות (roles/iam.serviceAccountUser)
    • עריכה ב-Cloud Build (roles/cloudbuild.builds.editor)
  • חשבון שירות ייעודי (להפעלת מאגר ההערכה):
    • משתמש ב-Agent Platform (roles/aiplatform.user)
    • משתמש באובייקטים באחסון (roles/storage.objectUser) או אדמין לניהול נפח האחסון (roles/storage.admin)

כדי לקבל את ההרשאות שדרושות להפעלת הערכה ולהרצת קובץ ה-container של הניתוח, צריך לבקש מהאדמין להקצות לכם את תפקידי ה-IAM הבאים בפרויקט:

  • משתמש – ניהול ארכיוני מקור והגדרות של קטגוריות: אדמין לניהול נפח האחסון (roles/storage.admin)
  • משתמש – צירוף חשבון השירות הייעודי לעבודה: משתמש בחשבון השירות (roles/iam.serviceAccountUser)
  • משתמש – שליחת משימות הערכה (cloudbuild.builds.create) ותצוגת יומנים: עריכה ב-Cloud Build‏ (roles/cloudbuild.builds.editor)
  • חשבון שירות – הפעלת מאגר התגים codmod: משתמש בפלטפורמת סוכנים (roles/aiplatform.user)
  • חשבון שירות – קריאת ארכיונים של מקורות וכתיבת דוחות הערכה: משתמש באובייקטים באחסון (roles/storage.objectUser) או אדמין אחסון (roles/storage.admin)

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

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

ההרשאות הנדרשות

כדי להתחיל הערכה ולהריץ את קובץ הניתוח, צריך את ההרשאות הבאות:

  • משתמש (Cloud Storage,‏ Cloud Build ו-IAM):
    • ‫storage.objects.get (כדי להוריד או לקרוא קבצים)
    • ‫storage.objects.list (כדי להציג רשימת קבצים בתוך הקטגוריה)
    • storage.objects.create (כדי להעלות או ליצור קבצים חדשים)
    • ‫storage.objects.update (כדי לשנות את המטא-נתונים של קבצים קיימים)
    • ‫storage.objects.delete (כדי למחוק או להחליף קבצים)
    • storage.buckets.get (צפייה בהגדרות ברמת המאגר)
    • cloudbuild.builds.create (כדי לשלוח משימות הערכה)
    • ‫iam.serviceAccounts.actAs (כדי לצרף את חשבון השירות לעבודה)
  • חשבון שירות (Agent Platform ו-Cloud Storage):
    • ‫aiplatform.endpoints.predict (להרצת ניתוח קוד בעזרת AI)
    • ‫storage.objects.get (כדי לקרוא או להוריד ארכיונים של מקורות)
    • ‫storage.objects.list (כדי להציג רשימה של הקבצים בתיקיית הקלט)
    • ‫storage.objects.create (כדי לכתוב דוחות הערכה)
    • ‫storage.objects.delete (כדי למחוק קבצים זמניים)

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

הגדרת קטגוריה של הגדרות סביבת עבודה

רושמים קטגוריה של Cloud Storage ייעודית בדף Modernization Hub > Settings (לדוגמה, gs://PROJECT_ID-modernization-hub) כדי לאחסן את קובצי המצב הבינאריים של סביבת העבודה (dotnet_jobs.pb,‏ java_jobs.pb ו-mainframe_jobs.pb).

בדיקת מגבלות הגודל של בסיס הקוד

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

  • גודל בסיס הקוד המקסימלי: כ-שישה מיליון שורות קוד (LOC) לכל משימת הערכה. אם המאגר שלכם גדול מ-6 מיליון שורות קוד, צריך לפצל את בסיס הקוד למודולים או לשירותים קטנים ועצמאיים יותר לפני ההעלאה.
  • מבנה ארכיון נקי: אל תכללו בקובץ ה-ZIP קבצים בינאריים שעברו קומפילציה, מטמון של חבילות ומטא-נתונים של בקרת גרסאות (כמו target/,‏ build/,‏ bin/,‏ node_modules/ ו-.git/), כדי שרק קובצי המקור והגדרות הבנייה ינותחו.

הכנה והעלאה של ארכיון מקור Java

אורזים את בסיס הקוד של Java כקובץ ZIP שלא כולל פלטים של build, ומעלים את הקובץ לקטגוריה של Cloud Storage בפרויקט.

  1. במכונה המקומית, יוצרים קובץ ZIP של המאגר באחת מהשיטות הבאות:

    • באמצעות Git (מומלץ):

      git archive --format=zip -o repository.zip HEAD

    • באמצעות zip CLI:

      zip -r repository.zip . \
    -x "*.git*" "*/target/*" "*/build/*" "*/bin/*" "*/node_modules/*"

  2. מעלים את קובץ ה-ZIP לקטגוריית היעד ב-Cloud Storage באמצעות Google Cloud CLI:

    gcloud storage cp repository.zip \
    gs://INPUT_BUCKET/codebase/repository.zip

    מחליפים את INPUT_BUCKET בשם של קטגוריית Cloud Storage של היעד.

הפעלת הערכה

כדי להתחיל עבודת הערכה ב-Modernization Hub, פועלים לפי השלבים הבאים:

  1. נכנסים לדף Modernization Hub במסוף.

    כניסה ל-Modernization Hub

  2. בדף הנחיתה, מאתרים את הכרטיס Java Workloads ולוחצים על Start assessment.

  3. בשדה שם המשימה, מזינים שם ייחודי למשימת ההערכה.

  4. בשדה Source code location (מיקום קוד המקור), בוחרים קטגוריה ב-Cloud Storage שמכילה את קוד המקור כקובץ ZIP.

  5. בשדה Report location, בוחרים קטגוריה של Cloud Storage לשמירת דוחות ההערכה שנוצרו.

  6. ברשימה Modernization recipe (מתכון למודרניזציה), בוחרים מתכון למודרניזציה.

  7. ברשימה Location, בוחרים אזור לעבודת ההערכה.

  8. בשדה Service account, בוחרים חשבון שירות ייעודי עם תפקידי ה-IAM הנדרשים שמפורטים בקטע Required roles. המשימה להערכה מופעלת ב-Cloud Build דרך חשבון השירות הזה, שנדרשות לו הרשאות של Agent Platform User ו-Cloud Storage.

  9. לוחצים על יצירת דוח.

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

בדיקת דוח ההערכה

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

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

  1. בטבלה Assessment history (היסטוריית ההערכות) בדף Modernization Hub, מאתרים את עבודת ההערכה.
  2. כשהסטטוס בעמודה סטטוס משתנה להושלם, לוחצים על הורדת הדוח.
  3. בוחרים את פורמט הפלט המועדף:
    • דוח HTML: סיכום אינטראקטיבי שמאפשר לסנן ממשקי API לא תואמים, לבדוק רשימות חסימה של קבצים ולראות הצעות לפתרון.
    • דוח בפורמט Markdown: סיכום מנהלים מעוצב שמתאים לשיתוף עם בעלי עניין ועם ועדות לבדיקת ארכיטקטורה.

בדיקת דוח ההערכה

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

  • ציון התאימות הכולל: אחוז השורות והתלויות בקוד המקור שאפשר להעביר לסביבת זמן הריצה של Java ביעד בלי לבצע שינויים.
  • פירוט של החסימות: תלויות ספציפיות ב-Java מדור קודם או מגבלות סביבתיות שדורשות שינוי מבנה, כמו:
    • שינויים במרחב השמות מ-Java EE ‏ (javax.*) ל-Jakarta EE ‏ (jakarta.*).
    • הוסרו או הוצאו משימוש ממשקי API פנימיים של JDK (כמו חבילות sun.misc.* או מודולים של CORBA).
    • הגדרות או ממשקי API של שרת אפליקציות קנייני (כמו WebLogic,‏ WebSphere או JBoss deployment descriptors).
  • ניתוח יחסי תלות: מלאי מפורט של יחסי תלות קיימים ב-Maven או ב-Gradle, שבו מצוין אם כל ספרייה תומכת בגרסת זמן הריצה של Java או אם נדרש שדרוג.
  • פעולות מומלצות: הצעות לשינויים בקוד, מתכונים לשינוי מבנה הקוד בעזרת AI ונתיבי העברה שנוצרו על ידי codmod כדי להכין את האפליקציה להעברה ל- Google Cloud.

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