1. סקירה כללית
מטרת סדרת המדריכים הזו (מדריכים מעשיים בקצב אישי) היא לעזור למפתחי Google App Engine (רגיל) ב-Java לחדש את האפליקציות שלהם, על ידי הדרכתם לאורך סדרה של העברות. בעזרת השלבים הבאים תוכלו לעדכן את האפליקציה שלכם כך שתהיה יותר ניידת, ולהחליט אם ליצור אותם בקונטיינרים עבור Cloud Run, השירות האחיות של Google Cloud לאירוח קונטיינרים עבור App Engine ושירותים אחרים לאירוח קונטיינרים.
במדריך הזה תלמדו איך ליצור קונטיינרים של אפליקציית App Engine לפריסה בשירות Cloud Run שמנוהל באמצעות Jib. בעזרת Jib אפשר ליצור תמונות ב-Docker, פלטפורמה ידועה בתחום לפיתוח, משלוח והפעלה של אפליקציות בקונטיינרים.
בנוסף ללמד אתכם את השלבים הנדרשים כדי לעבור מ-App Engine ל-Cloud Run, תלמדו גם איך לשדרג אפליקציית Java 8 App Engine ל-Java 17.
אם האפליקציה שלך עושה שימוש נרחב בשירותים בחבילה מדור קודם של App Engine או בתכונות אחרות של App Engine, מומלץ לעבור מהשירותים השונים הכלולים בחבילה או להחליף את התכונות לפני המעבר ל-Cloud Run. אם דרוש לך זמן נוסף כדי לבדוק את אפשרויות ההעברה שלך, או שברצונך להמשיך להשתמש בינתיים בשירותים הכלולים בחבילה, תוכלו להמשיך לגשת לשירותים בחבילה של App Engine עבור Java 11/17 כשתשדרגו לסביבת זמן ריצה חדשה יותר. כשהאפליקציה תהיה יותר ניידת, כדאי לחזור אל Codelab הזה כדי ללמוד איך להחיל את ההוראות באפליקציה.
כאן אפשר להבין איך
- שימוש ב-Cloud Shell
- הפעלת ממשקי ה-API של Cloud Run, Artifact Registry ו-Cloud Build
- יצירת קונטיינרים לאפליקציה באמצעות Jib ו-Cloud Build
- פריסת קובצי אימג' של קונטיינרים ב-Cloud Run
מה צריך להכין
- פרויקט ב-Google Cloud Platform עם חשבון פעיל לחיוב ב-GCP ומופעל ב-App Engine
- ידע בעבודה עם פקודות Linux נפוצות
- ידע בסיסי פיתוח ופריסה של אפליקציות App Engine
- אפליקציית שרת Java 8 שרוצים להעביר ל-Java 17 ולפרוס אותה ב-Cloud Run (האפליקציה יכולה להיות ב-App Engine או רק המקור)
סקר
איך תשתמשו במדריך הזה?
איזה דירוג מגיע לחוויה שלך עם Java?
איזה דירוג מגיע לדעתך לחוויית השימוש שלך בשירותי Google Cloud?
2. רקע
מערכות Platform as a Service (PaaS) כמו App Engine ו-Cloud Functions מספקות לצוות ולאפליקציה שלכם אפשרויות נוחות רבות, כמו האפשרות לאפשר ל-SysAdmins ול-Devops להתמקד בפיתוח פתרונות. בעזרת פלטפורמות ללא שרת, האפליקציה שלך יכולה להרחיב את הפעילות באופן אוטומטי לפי הצורך, להקטין את הערך לאפס באמצעות חיוב בתשלום לפי שימוש כדי לשלוט בעלויות ולהשתמש במגוון שפות פיתוח נפוצות.
עם זאת, הגמישות של קונטיינרים גם מעניינת. בזכות היכולת לבחור בכל שפה, בכל ספרייה ובכל תוכנה בינארית, הקונטיינרים מאפשרים לכם ליהנות משני העולמות: הנוחות של עבודה ללא שרת (serverless) יחד עם הגמישות של קונטיינרים. זה המטרה של Cloud Run.
ה-Codelab הזה לא כולל לימוד איך להשתמש ב-Cloud Run. נמצא במסמכי התיעוד של Cloud Run. המטרה כאן היא שתלמדו איך ליצור קונטיינרים של אפליקציית App Engine בשביל Cloud Run (או שירותים אחרים שמתארחים בקונטיינר). יש כמה דברים שכדאי לדעת לפני שממשיכים, בעיקר שחוויית המשתמש שלכם תהיה שונה מעט.
ב-Codelab הזה תלמדו איך לפתח ולפרוס קונטיינרים. נסביר לכם איך:
- יצירת קונטיינרים לאפליקציה באמצעות Jib
- מעבר מהגדרת 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 מבוססת-Java 8 שמבוססת על Servlet, שמיועדת לפריסה ב-App Engine. יש לפעול לפי ההוראות ב-README שמסבירות איך להכין את האפליקציה הזו לפריסה של App Engine.
3. (אופציונלי) פריסת אפליקציה בסיסית
השלב הבא נדרש רק אם ברצונך לוודא שהאפליקציה פועלת ב-App Engine לפני המעבר ל-Cloud Run.
יש לעיין בשלבים שבקובץ README.md:
- התקנה או היכרות מחדש עם ה-CLI של
gcloud
- אתחול ה-CLI של gcloud לפרויקט עם
gcloud init
- יצירת פרויקט App Engine עם
gcloud app create
- פריסת האפליקציה לדוגמה ב-App Engine
./mvnw package appengine:deploy -Dapp.projectId=$PROJECT_ID
- אישור שהאפליקציה פועלת ב-App Engine ללא בעיות
4. יצירת מאגר של Artifact Registry
לאחר יצירת הקונטיינרים של האפליקציה, יהיה צורך במקום כלשהו כדי לדחוף ולאחסן את התמונות. מומלץ להשתמש ב-Artifact Registry כדי לעשות את זה ב-Google Cloud.
יוצרים את המאגר בשם 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, מומלץ להמשיך לגשת לשירותים האלה ולשדרג לסביבת זמן הריצה החדשה. ה-Codelab הזה מדגים נתיב העברה לאפליקציות שכבר משתמשות בשירותים עצמאיים, או שסביר להניח שאפשר להגדיר אותן מחדש כדי לעשות זאת.
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, תודיע לפלאגין המהדר (compiler) על כך שאתם רוצים לגשת לתכונות השפה של Java 17 ושאתם רוצים שהמחלקות הידור יהיו תואמות ל-Java 17 JVM.
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 יטמיע שרת Tomcat כברירת מחדל, אבל הדוגמה הזו לא תכלול ארטיפקט הזה ויישאר עם Jetty כדי למזער את ההבדלים בהתנהגות ברירת המחדל לאחר ההעברה. אנחנו יכולים גם להגדיר שגרסת Jetty תהיה תואמת לגרסה ש-App Engine מספקת.
<properties>
<java.version>17</java.version>
<maven.compiler.source>17</maven.compiler.source>
<maven.compiler.target>17</maven.compiler.target>
<jetty.version>9.4.46.v20220331</jetty.version>
</properties>
3. הגדרת מגף קפיץ
ניתן לבצע באתחול הקפוא את שרת ה-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
אומנם אפשר ליצור קונטיינרים לאפליקציה באמצעות Jib שמתחילים ממלחמה, אבל קל יותר לארוז את האפליקציה כקובץ JAR להפעלה. לא יהיה צורך בהגדרות מיוחדות, במיוחד בפרויקטים שמשתמשים ב-Maven ככלי build, כי שיטת ברירת המחדל היא אריזה של צנצנות.
מסירים את התג 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 Run ישירות מקוד המקור. זאת אפשרות מצוינת שמשתמשת ב-Cloud Build מאחורי הקלעים כדי לספק חוויית פריסה מעשית. נעסוק בפריסות מקור במודולים מאוחרים יותר.
לחלופין, אם דרושה לך יותר שליטה באופן שבו האפליקציה פרוסה, אפשר להשיג את זה באמצעות הגדרה של קובץ cloudbuild.yaml
שמפרט במפורש את שלבי ה-build הרצויים:
1. הגדרה של קובץ cloudbuild.yaml
יוצרים את קובץ cloudbuild.yaml
הבא באותה רמה שבה נמצא ה-pom.xml
:
steps:
# Test your build
- name: maven:eclipse-temurin
entrypoint: mvn
args: ["test"]
# Build with Jib
- name: maven:eclipse-temurin
entrypoint: mvn
args: [ "compile", "com.google.cloud.tools:jib-maven-plugin:3.2.1:build", "-Dimage=northamerica-northeast1-docker.pkg.dev/PROJECT_ID/migration/visitors:jib"]
# Deploy to Cloud Run
- name: 'gcr.io/google.com/cloudsdktool/cloud-sdk'
entrypoint: gcloud
args: [ 'run', 'deploy', 'visitors', '--image', 'northamerica-northeast1-docker.pkg.dev/PROJECT_ID/migration/visitors:jib', '--region', 'northamerica-northeast1', '--allow-unauthenticated']
אחרי שנודיע ל-Cloud Build לבצע את השלבים הבאים, הוא:
- הרצת הבדיקות באמצעות
./mvnw test
- יוצרים, דוחפים ומתייגים את התמונה ב-ArtifactRegistry באמצעות Jib.
- פריסת האימג' ב-Cloud Run באמצעות
gcloud run deploy
שימו לב: ‘visitors'
מסופק ל-Cloud Run כשם השירות הרצוי. הדגל –allow-unauthenticated
מאפשר למשתמשים להיכנס לאפליקציית האינטרנט ללא צורך באימות. חשוב להחליף את הפרויקט PROJECT_ID במזהה הפרויקט בקובץ cloudbuild.yaml
.
בשלב הבא, מוסיפים את קישורי מדיניות ה-IAM הבאים כדי לאפשר לחשבון השירות של Cloud Build ל-Artifact Registry:
export PROJECT_ID=$(gcloud config list --format 'value(core.project)')
export PROJECT_NUMBER=$(gcloud projects describe $PROJECT_ID --format="value(projectNumber)" )
gcloud projects add-iam-policy-binding $PROJECT_ID \
--member=serviceAccount:$PROJECT_NUMBER@cloudbuild.gserviceaccount.com \
--role=roles/run.admin \
--project=$PROJECT_ID
gcloud iam service-accounts add-iam-policy-binding $PROJECT_NUMBER-compute@developer.gserviceaccount.com \
--member=serviceAccount:$PROJECT_NUMBER@cloudbuild.gserviceaccount.com \
--role roles/iam.serviceAccountUser --project=$PROJECT_ID
2. הפעלת תהליך ה-build
עכשיו, אחרי שיידעתם את Cloud Build לגבי שלבי ה-build הרצויים, אתם מוכנים לפריסה בלחיצה אחת.
מריצים את הפקודה הבאה:
gcloud builds submit
בסיום התהליך, קובץ האימג' של הקונטיינר נוצר, נשמר ב-Artifact Registry ופרוס ב-Cloud Run.
בסוף שיעור ה-Codelab הזה, האפליקציה שלך אמורה להיראות זהה לזו שב-java17-and-cloud-run/finish.
זהו, אתה מוכן! העברתם בהצלחה אפליקציית Java 8 App Engine אל Java 17 ו-Cloud Run, ועכשיו אתם מבינים טוב יותר את העבודה הכרוכה במעבר ובחירה בין אפשרויות האירוח.
6. סיכום/ניקוי
מזל טוב, שדרגת, שדרגת את הקונטיינרים, העברת את האפליקציה שלך וסיימת את המדריך הזה!
השלב הבא הוא לקבל מידע נוסף על תכונות האבטחה של CI/CD ושרשרת האספקה של תוכנות שנמצאות בהישג יד, שאפשר לפרוס באמצעות Cloud Build:
- יצירת שלבים בהתאמה אישית ל-build באמצעות Cloud Build
- יצירה וניהול של טריגרים ליצירת build
- שימוש בסריקה לפי דרישה בצינור עיבוד הנתונים של Cloud Build
אופציונלי: ניקוי ו/או השבתה של השירות
אם פרסתם את האפליקציה לדוגמה ב-App Engine במהלך המדריך הזה, זכרו להשבית את האפליקציה כדי למנוע חיובים. כשתהיו מוכנים לעבור ל-Codelab הבא, תוכלו להפעיל אותו מחדש. למרות שהאפליקציות של App Engine מושבתות, תנועת הגולשים לא תצברו חיובים. עם זאת, ייתכן שאפשר יהיה לחייב את השימוש ב-Datastore אם הוא יחרוג מהמכסה החינמית שלו, לכן צריך למחוק מספיק נתונים כדי לא לחרוג מהמגבלה הזו.
מצד שני, אם אתם לא מתכוונים להמשיך בהעברות ואתם רוצים למחוק הכול לגמרי, תוכלו למחוק את השירות או להשבית את הפרויקט לחלוטין.
7. מקורות מידע נוספים
בעיות/משוב על Codelabs עם מודול ההעברה של App Engine
אם נתקלתם בבעיות ב-Codelab הזה, צריך קודם לחפש את הבעיה לפני השליחה. קישורים לחיפוש וליצירת בעיות חדשות:
מקורות מידע בנושא העברה
- אפשרויות העברה לביטול קיבוץ של שירותי מנוע חיפוש של אפליקציות
- הגדרת טריגרים לפיתוח גרסת Build ל-Cloud Build
- מידע נוסף על מעבר ל-Java 11/17
מקורות מידע אונליין
בהמשך מופיעים משאבים מקוונים שעשויים להיות רלוונטיים למדריך זה:
App Engine
- מסמכי התיעוד של App Engine
- מידע על תמחור ומכסות של App Engine
- השוואה ראשונה ל- פלטפורמות דור שני
- תמיכה לטווח ארוך בסביבות זמני ריצה מדור קודם
מידע אחר בענן
- "חינם תמיד" ב-Google Cloud שכבה
- Google Cloud CLI (
gcloud
CLI) - כל משאבי העזרה של Google Cloud
סרטונים
- תחנת העברה ללא שרת (serverless)
- קמפיינים ללא שרת (serverless)
- הרשמה למינוי Google Cloud Tech
- הרשמה ל-Google Developers
רישיון
היצירה הזו בשימוש ברישיון Creative Commons Attribution 2.0 גנרי.