מעבר מאפליקציית Google App Engine Java ל-Cloud Run באמצעות Docker

1. סקירה כללית

סדרת הקודלאבס הזו (מדריכים מעשיים וברמת התקדמות עצמית) נועדה לעזור למפתחי Java ב-Google App Engine (Standard) לחדש את האפליקציות שלהם באמצעות הדרכה על סדרת העברות. בעזרת השלבים האלה תוכלו לעדכן את האפליקציה כך שתהיה ניידת יותר, ולהחליט לארוז אותה בקונטיינרים ל-Cloud Run, שירות האחווה של App Engine ב-Google Cloud לאירוח קונטיינרים, ושירותים אחרים לאירוח קונטיינרים.

במדריך הזה תלמדו איך לארוז אפליקציה של App Engine בקונטיינר כדי לפרוס אותה בשירות המנוהל של Cloud Run באמצעות קובץ Dockerfile. קובצי Docker הם שיטת הפריסה הכי מעשית להעברה הזו, אבל הם גם מציעים את מספר האפשרויות הגדול ביותר להתאמה אישית של תהליך ה-build.

בנוסף להסבר על השלבים הנדרשים כדי לעבור מ-App Engine ל-Cloud Run, תלמדו גם איך לשדרג אפליקציית Java 8 ב-App Engine ל-Java 17.

אם האפליקציה שאתם רוצים להעביר משתמשת הרבה בשירותים המוגדרים מראש מדור קודם של App Engine או בתכונות ספציפיות אחרות של App Engine, יכול להיות שהמדריך גישה לשירותים המוגדרים מראש של App Engine עבור Java 11/17 יהיה נקודת התחלה טובה יותר מאשר הקודלאב הזה.

כאן אפשר להבין איך

• שימוש ב-Cloud Shell
• הפעלת ממשקי ה-API של Cloud Run,‏ Artifact Registry ו-Cloud Build
• שימוש ב-Docker, ב-Docker Compose וב-Cloud Build כדי ליצור קונטיינרים לאפליקציות
• פריסת קובצי האימג' של הקונטיינרים ב-Cloud Run

מה צריך להכין

• פרויקט ב-Google Cloud Platform עם חשבון פעיל לחיוב ב-GCP והפעלת App Engine
• ידע בעבודה עם פקודות Linux נפוצות
• ידע בסיסי בפיתוח ובפריסה של אפליקציות App Engine
• אפליקציית Servlet של Java 8 שרוצים להעביר ל-Java 17 ולפרוס ב-Cloud Run (זו יכולה להיות אפליקציה ב-App Engine או רק המקור)

סקר

איך תשתמשו במדריך הזה?

לקרוא את המאמר לקרוא את המאמר ולבצע את התרגילים

מה מידת שביעות הרצון שלך מהשימוש ב-Java?

מתחילים בינוניים מתקדמים

מהו הדירוג שלך לגבי חוויית השימוש בשירותי Google Cloud?

מתחילים בינוניים מומחים

2. רקע

מערכות PaaS כמו App Engine ו-Cloud Functions מספקות יתרונות רבים לצוות ולאפליקציה, למשל, מאפשרות למנהלי מערכות ול-DevOps להתמקד בפיתוח פתרונות. בפלטפורמות ללא שרתים, אפשר להגדיל את האפליקציה באופן אוטומטי לפי הצורך, לצמצם אותה לאפס באמצעות חיוב לפי שימוש כדי לשלוט בעלויות ולהשתמש במגוון שפות פיתוח נפוצות.

עם זאת, הגמישות של הקונטיינרים היא גם יתרון משמעותי. היכולת לבחור כל שפה, כל ספרייה וכל תוכנה בינארית מאפשרת לכם ליהנות משני העולמות: הנוחות של שירות ללא שרת והגמישות של קונטיינרים. זהו המהות של Google Cloud Run.

הדרכה על השימוש ב-Cloud Run לא נכללת בקודלאב הזה. מידע נוסף זמין במסמכי התיעוד של Cloud Run. המטרה של המדריך הזה היא להכיר לכם את האופן שבו מעבירים לאריזות קונטיינר אפליקציות של App Engine ל-Cloud Run (או שירותים אחרים שמתארחים בקונטיינרים). לפני שממשיכים, חשוב לדעת כמה דברים, בעיקר שהחוויה של המשתמשים תהיה שונה במקצת.

ב-Codelab הזה תלמדו איך לפתח ולפרוס קונטיינרים. תלמדו איך להעביר את האפליקציה לקונטיינרים באמצעות קובץ Dockerfile, איך לעבור מהגדרות App Engine ואיך להגדיר שלבי build ל-Cloud Build (אופציונלי). כדי לעשות זאת, תצטרכו להפסיק להשתמש בתכונות מסוימות שספציפיות ל-App Engine. אם אתם מעדיפים לא לפעול לפי הנתיב הזה, עדיין תוכלו לשדרג לסביבת זמן ריצה של Java 11/17 תוך שמירה על האפליקציות ב-App Engine.

3. הגדרה/עבודה מוקדמת

1. הגדרת פרויקט

במדריך הזה תשתמשו באפליקציה לדוגמה ממאגר appengine-java-migration-samples בפרויקט חדש לגמרי. מוודאים שלפרויקט יש חשבון פעיל לחיוב.

אם אתם מתכוונים להעביר אפליקציית App Engine קיימת ל-Cloud Run, תוכלו להשתמש באפליקציה הזו במקום זאת.

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

gcloud services enable artifactregistry.googleapis.com cloudbuild.googleapis.com run.googleapis.com

2. הורדת אפליקציית דוגמה

מעתיקים את האפליקציה לדוגמה במחשב שלכם או ב-Cloud Shell, ולאחר מכן עוברים לתיקייה baseline.

הדוגמה היא אפליקציית Datastore מבוססת-Servlet של Java 8, שמיועדת לפריסה ב-App Engine. פועלים לפי ההוראות במסמך README כדי להכין את האפליקציה לפריסה ב-App Engine.

3. (אופציונלי) פריסת אפליקציה בסיסית

השלב הבא נדרש רק אם ברצונך לוודא שהאפליקציה פועלת ב-App Engine לפני המעבר ל-Cloud Run.

פועלים לפי השלבים שמפורטים בקובץ README.md:

1. התקנה או היכרות מחדש עם ה-CLI של gcloud
2. אתחול ה-CLI של gcloud לפרויקט באמצעות gcloud init
3. יצירת פרויקט App Engine עם gcloud app create
4. פריסת האפליקציה לדוגמה ב-App Engine

./mvnw package appengine:deploy -Dapp.projectId=$PROJECT_ID

5. מוודאים שהאפליקציה פועלת ב-App Engine ללא בעיות

4. יצירת מאגר ב-Artifact Registry

אחרי שמעבירים את האפליקציה לקונטיינרים, צריך מקום שבו אפשר לדחוף ולשמור את קובצי האימג'. הדרך המומלצת לעשות זאת ב-Google Cloud היא באמצעות Artifact Registry.

יוצרים את המאגר בשם migration באמצעות gcloud באופן הבא:

gcloud artifacts repositories create migration --repository-format=docker \
--description="Docker repository for the migrated app" \
--location="northamerica-northeast1"

הערה: המאגר הזה משתמש בפורמט docker, אבל יש כמה סוגים של מאגרים זמינים.

בשלב הזה, יש לכם את אפליקציית App Engine הבסיסית, והפרויקט ב-Google Cloud מוכן להעברה ל-Cloud Run.

4. שינוי קובצי אפליקציה

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

1. שדרוג ל-Java 17

אם האפליקציה שלכם מבוססת על Java 8, כדאי לשדרג לגרסה מתקדמת יותר של LTS, כמו 11 או 17, כדי לעמוד בקצב של עדכוני האבטחה ולקבל גישה לתכונות חדשות של השפה.

קודם כול צריך לעדכן את המאפיינים ב-pom.xml כך שיכללו את הרכיבים הבאים:

<properties>
    <java.version>17</java.version>
    <maven.compiler.source>17</maven.compiler.source>
    <maven.compiler.target>17</maven.compiler.target>
</properties>

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

2. כולל שרת אינטרנט

יש כמה הבדלים בין App Engine לבין Cloud Run שכדאי לקחת בחשבון כשעוברים ביניהם. הבדל אחד הוא שלמרות שזמן הריצה של Java 8 של App Engine סיפק וניהל שרת Jetty לאפליקציות שהוא מארחים, Cloud Run לא עושה זאת. נשתמש ב-Spring Boot כדי לספק לנו שרת אינטרנט ומאגר Servlet.

מוסיפים את יחסי התלות הבאים:

<dependencies>
<!-- ... -->
   <dependency>
       <groupId>org.springframework.boot</groupId>
       <artifactId>spring-boot-starter-web</artifactId>
       <version>2.6.6</version>
       <exclusions>
           <!-- Exclude the Tomcat dependency -->
           <exclusion>
               <groupId>org.springframework.boot</groupId>
               <artifactId>spring-boot-starter-tomcat</artifactId>
           </exclusion>
       </exclusions>
   </dependency>
   <!-- Use Jetty instead -->
   <dependency>
       <groupId>org.springframework.boot</groupId>
       <artifactId>spring-boot-starter-jetty</artifactId>
       <version>2.6.6</version>
   </dependency>
<!-- ... -->
</dependencies>

Spring Boot מטמיע שרת Tomcat כברירת מחדל, אבל הדוגמה הזו תחרוג מהכלל הזה ותשתמש ב-Jetty כדי לצמצם את ההבדלים בהתנהגות ברירת המחדל אחרי ההעברה.

3. הגדרת Spring Boot

Spring Boot יוכל לעשות שימוש חוזר ב-servlets בלי שינוי, אבל תצטרכו לבצע הגדרות מסוימות כדי לוודא שהם ניתנים לגילוי.

יוצרים את הכיתה MigratedServletApplication.java הבאה בחבילה com.example.appengine:

package com.example.appengine;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.EnableAutoConfiguration;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.boot.web.servlet.ServletComponentScan;

@ServletComponentScan
@SpringBootApplication
@EnableAutoConfiguration
public class MigratedServletApplication {
    public static void main(String[] args) {
        SpringApplication.run(MigratedServletApplication.class, args);
    }
}

שימו לב שהערה @ServletComponentScan נכללת בכך, והיא תבדוק (בחבילת הקוד הנוכחית כברירת מחדל) אם יש @WebServlets, ותהפוך אותם לזמינים כצפוי.

4. אריזה של האפליקציה כקובץ JAR

אפשר להעביר את האפליקציה לקונטיינר מ-war, אבל קל יותר לארוז אותה כקובץ JAR שניתן להפעלה. לא נדרשות הרבה הגדרות, במיוחד בפרויקטים שמשתמשים ב-Maven ככלי build – מכיוון שאריזת jar היא ברירת המחדל.

מסירים את התג packaging מהקובץ pom.xml:

<packaging>war</packaging>

בשלב הבא, מוסיפים את spring-boot-maven-plugin:

<plugins>
<!-- ... -->
  <plugin>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-maven-plugin</artifactId>
    <version>2.6.6</version>
  </plugin>
<!-- ... -->
</plugins>

5. מעבר מההגדרות, מהשירותים ומהיחסי התלות של App Engine

כפי שצוין בתחילת הקודלאב, Cloud Run ו-App Engine נועדו לספק חוויות משתמש שונות. יש תכונות מסוימות ש-App Engine מציע מחוץ לאריזה, כמו השירותים Cron ותור משימות, שצריך ליצור מחדש באופן ידני, וניתן ללמוד עליהן בפירוט במודולים מאוחרים יותר.

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

• מעבר משירותים בחבילה כדי למצוא שירותים עצמאיים מתאימים.
• העברת קובצי תצורה מסוג XML ל-YAML, למשתמשים שעוברים לסביבות זמן ריצה של Java 11/17 תוך שמירה על App Engine.

מעכשיו, הפריסה של Cloud Run מתבצעת, ולכן אפשר להסיר את ה-appengine-maven-plugin:

<plugin>
 <groupId>com.google.cloud.tools</groupId>
 <artifactId>appengine-maven-plugin</artifactId>
 <version>2.4.1</version>
 <configuration>
   <!-- can be set w/ -DprojectId=myProjectId on command line -->
   <projectId>${app.projectId}</projectId>
   <!-- set the GAE version or use "GCLOUD_CONFIG" for an autogenerated GAE version -->
   <version>GCLOUD_CONFIG</version>
 </configuration>
</plugin>

5. אפליקציה בקונטיינר

בשלב הזה אתם מוכנים להורות ל-Cloud Build איך לבנות את הקונטיינר של האפליקציה. בשיטה הזו של ארגון בקונטיינרים, לא נדרש קובץ תצורה נפרד של build‏ (cloudbuild.yaml). אפשר פשוט להגדיר קובץ Dockerfile מינימלי כנקודת התחלה:

FROM eclipse-temurin

ARG JAR_FILE=JAR_FILE_MUST_BE_SPECIFIED_AS_BUILD_ARG

COPY ${JAR_FILE} app.jar

ENTRYPOINT ["Java", "-jar","/app.jar"]

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

2**. מפעילים את תהליך ה-build**

עכשיו, אחרי שסיפקתם ל-Cloud Build את שלבי ה-build הרצויים, אתם מוכנים לפריסה בקליק אחד.

מריצים את הפקודה הבאה:

gcloud builds submit --tag LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY/IMAGE_NAME

מחליפים את הערכים הזמניים לשמירת מקום (placeholder) בפקודה שלמעלה בערכים הבאים:

• LOCATION: המיקום האזורי או המיקום במספר אזורים של המאגר.
• PROJECT_ID: מזהה הפרויקט ב-Cloud.
• REPOSITORY: השם של המאגר ב-Artifact Registry.
• IMAGE_NAME: השם של קובץ האימג' בקונטיינר.

בסיום התהליך, קובץ האימג' בקונטיינר נוצר, מאוחסן ב-Artifact Registry ופורס ב-Cloud Run.

בסיום הקודלאב, האפליקציה שלכם אמורה להיראות כמו זו שבתיקייה mod4-migrate-to-cloud-run.

זהו, אתה מוכן! העברתם בהצלחה אפליקציית Java 8 App Engine ל-Java 17 ול-Cloud Run, ועכשיו אתם מבינים טוב יותר את העבודה הכרוכה במעבר ובחירה בין אפשרויות האירוח.

6. סיכום/ניקוי

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

השלב הבא הוא לקבל מידע נוסף על תכונות האבטחה של CI/CD ושרשרת האספקה של תוכנות שנמצאות בהישג יד, שאפשר לפרוס באמצעות Cloud Build:

• יצירת שלבים בהתאמה אישית ל-build באמצעות Cloud Build
• יצירה וניהול של טריגרים לפיתוח גרסאות build
• שימוש בסריקה על פי דרישה בצינור עיבוד הנתונים של Cloud Build

אופציונלי: ניקוי ו/או השבתה של השירות

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

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

7. מקורות מידע נוספים

בעיות/משוב על מודולים של Codelabs להעברה ל-App Engine

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

• איך מחפשים בעיות
• דיווח על בעיה חדשה או שליחת משוב

מקורות מידע בנושא העברה

• אפשרויות העברה לשירותי App Engine שאינם בחבילה
• הגדרת טריגרים ל-build ב-Cloud Build
• מידע נוסף על מעבר ל-Java 11/17

משאבים באינטרנט

בהמשך מופיעים מקורות מידע באינטרנט שעשויים להיות רלוונטיים למדריך הזה:

App Engine

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

מידע אחר בענן

• רמת 'חינם תמיד' ב-Google Cloud
• Google Cloud CLI‏ (gcloud CLI)
• כל משאבי העזרה של Google Cloud

סרטונים

• תחנת העברה ללא שרת (serverless)
• Serverless Expeditions
• הרשמה ל-Google Cloud Tech
• הרשמה ל-Google Developers

רישיון

היצירה הזו בשימוש ברישיון Creative Commons Attribution 2.0 גנרי.