مهاجرت از برنامه Google App Engine Java به Cloud Run با Jib

1. بررسی اجمالی

هدف این سری از نرم‌افزارهای کد (آموزش‌های عملی و خودکار) این است که به توسعه‌دهندگان جاوا موتور برنامه Google (استاندارد) کمک کند تا برنامه‌های خود را با هدایت آن‌ها از طریق یک سری مهاجرت مدرن‌سازی کنند. با دنبال کردن این مراحل، می‌توانید برنامه‌تان را به‌روزرسانی کنید تا قابل حمل‌تر باشد و تصمیم بگیرید آن‌ها را برای 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 برای جاوا 11/17 دسترسی داشته باشید . هنگامی که برنامه شما قابل حمل تر است، به این کد لبه بازگردید تا نحوه اعمال دستورالعمل ها را در برنامه خود بیاموزید.

شما یاد خواهید گرفت که چگونه

  • از Cloud Shell استفاده کنید
  • APIهای Cloud Run، Artifact Registry و Cloud Build را فعال کنید
  • برنامه خود را با استفاده از Jib و Cloud Build محفظه کنید
  • تصاویر کانتینر خود را در Cloud Run مستقر کنید

آنچه شما نیاز دارید

نظر سنجی

چگونه از این آموزش استفاده خواهید کرد؟

فقط از طریق آن را بخوانید آن را بخوانید و تمرینات را کامل کنید

تجربه خود را با جاوا چگونه ارزیابی می کنید؟

تازه کار حد واسط مسلط

تجربه خود را در استفاده از خدمات Google Cloud چگونه ارزیابی می کنید؟

تازه کار حد واسط مسلط

2. پس زمینه

سیستم‌های پلتفرم به‌عنوان سرویس (PaaS) مانند App Engine و توابع ابری، امکانات بسیاری را برای تیم و برنامه‌تان فراهم می‌کنند، مانند اینکه SysAdmins و Devops را قادر می‌سازد تا روی راه‌حل‌های ساختن تمرکز کنند. با پلت‌فرم‌های بدون مشکل، برنامه شما می‌تواند در صورت نیاز، مقیاس خودکار را افزایش دهد، با صورت‌حساب پرداخت به ازای استفاده، برای کمک به کنترل هزینه‌ها، به صفر کاهش دهد و از انواع زبان‌های توسعه رایج استفاده کند.

با این حال، انعطاف پذیری ظروف نیز قانع کننده است. کانتینرها با توانایی انتخاب هر زبان، هر کتابخانه و هر باینری، بهترین هر دو دنیا را به شما می دهند: راحتی بدون سرور و انعطاف پذیری کانتینرها. این همان چیزی است که Cloud Run در مورد آن است.

یادگیری نحوه استفاده از Cloud Run در محدوده این کد لبه نیست. که توسط مستندات Cloud Run پوشش داده شده است. هدف در اینجا این است که شما با نحوه کانتینری کردن برنامه App Engine خود برای Cloud Run (یا سایر خدمات میزبان کانتینر) آشنا شوید. چند نکته وجود دارد که باید قبل از حرکت به جلو بدانید، در درجه اول اینکه تجربه کاربری شما کمی متفاوت خواهد بود.

در این کد لبه، نحوه ساخت و استقرار کانتینرها را یاد خواهید گرفت. شما یاد خواهید گرفت که چگونه:

  • برنامه خود را با Jib محفظه کنید
  • از پیکربندی App Engine خارج شوید
  • و به صورت اختیاری، مراحل ساخت را برای Cloud Build تعریف کنید.

این شامل دور شدن از برخی ویژگی های خاص App Engine است. اگر ترجیح می‌دهید این مسیر را دنبال نکنید، همچنان می‌توانید زمان اجرا را به جاوا 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 کلون کنید، سپس به پوشه خط پایه بروید.

نمونه یک برنامه Datastore مبتنی بر Java 8 است که برای استقرار در App Engine در نظر گرفته شده است. دستورالعمل های موجود در README را در مورد نحوه آماده سازی این برنامه برای استقرار App Engine دنبال کنید.

3. (اختیاری) استقرار برنامه پایه

موارد زیر فقط در صورتی ضروری است که بخواهید قبل از انتقال به Cloud Run تأیید کنید که برنامه در App Engine کار می کند.

به مراحل موجود در README.md مراجعه کنید:

  1. نصب/آشنایی مجدد با gcloud CLI
  2. gcloud CLI را برای پروژه خود با gcloud init راه اندازی کنید
  3. پروژه App Engine را با gcloud app create
  4. برنامه نمونه را در App Engine اجرا کنید
./mvnw package appengine:deploy -Dapp.projectId=$PROJECT_ID
  1. تأیید کنید که برنامه بدون مشکل در App Engine اجرا می شود

4. یک مخزن رجیستری Artifact ایجاد کنید

پس از کانتینر کردن برنامه خود، به جایی برای فشار دادن و ذخیره تصاویر خود نیاز دارید. روش پیشنهادی برای انجام این کار در 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. ارتقاء به جاوا 17

اگر برنامه شما روی جاوا 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 تنظیم می شود، به افزونه کامپایلر اطلاع می دهد که می خواهید به ویژگی های زبان جاوا 17 دسترسی داشته باشید و دوست دارید کلاس های کامپایل شده با Java 17 JVM سازگار باشند.

2. از جمله وب سرور

تعدادی تفاوت بین App Engine و Cloud Run وجود دارد که هنگام حرکت بین آنها باید در نظر گرفته شود. یک تفاوت این است که در حالی که زمان اجرا Java 8 App Engine یک سرور Jetty را برای برنامه هایی که میزبانی می کرد ارائه و مدیریت می کرد، Cloud Run این کار را نمی کند. ما از Spring Boot برای ارائه یک وب سرور و ظرف سرولت به ما استفاده خواهیم کرد.

وابستگی های زیر را اضافه کنید:

<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 می‌پیوندد تا تفاوت‌ها در رفتار پیش‌فرض پس از مهاجرت به حداقل برسد. همچنین می‌توانیم نسخه 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. راه اندازی بوت فنری

در حالی که Spring Boot می‌تواند بدون تغییر از سرولت‌های شما مجددا استفاده کند، برای شناسایی نیاز به پیکربندی دارد.

کلاس 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 به عنوان ابزار ساخت استفاده می کنند - زیرا بسته بندی 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 و Task Queue - باید دوباره به صورت دستی ایجاد شوند و در ماژول‌های بعدی با جزئیات بیشتری پوشش داده می‌شوند.

برنامه نمونه از سرویس‌های همراه قدیمی استفاده نمی‌کند، اما کاربرانی که برنامه‌هایشان استفاده می‌کنند می‌توانند به راهنماهای زیر مراجعه کنند:

از آنجایی که از این پس در 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. Containerize Application

در این مرحله می‌توانید به‌طور دستی برنامه خود را مستقیماً از کد منبع خود در Cloud Run اجرا کنید. این یک گزینه عالی است که از Cloud Build در پشت صحنه برای ارائه یک تجربه استقرار دستی استفاده می کند. ما در ماژول‌های بعدی به استقرار منبع با جزئیات بیشتری خواهیم پرداخت.

از طرف دیگر، اگر به کنترل بیشتری بر روی نحوه استقرار برنامه خود نیاز دارید، می توانید با تعریف یک فایل cloudbuild.yaml که به صراحت مراحل ساخت مورد نظر شما را مشخص می کند، به آن دست یابید:

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 بگوییم این مراحل را دنبال کند، این کار انجام می‌شود:

  1. تست های خود را با ./mvnw test اجرا کنید
  2. با Jib تصویر خود را به رجیستری Artifact بسازید، فشار دهید و برچسب بزنید
  3. با gcloud run deploy تصویر خود را در Cloud Run قرار دهید

توجه داشته باشید که 'visitors' به عنوان نام سرویس مورد نظر به Cloud Run ارائه می شود. پرچم –allow-unauthenticated به کاربران امکان می دهد بدون نیاز به احراز هویت از برنامه وب بازدید کنند. مطمئن شوید که PROJECT_ID را با شناسه پروژه خود در فایل cloudbuild.yaml جایگزین کنید .

در مرحله بعد، الزامات خط مشی IAM زیر را اضافه کنید تا به حساب سرویس ساخت ابری اجازه دهید به رجیستری مصنوعات اجازه دهید:

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. فرآیند ساخت را اجرا کنید

اکنون که به Cloud Build در مورد مراحل ساخت مورد نظر اطلاع داده اید، آماده استقرار با یک کلیک هستید.

دستور زیر را اجرا کنید:

gcloud builds submit

پس از اتمام فرآیند، تصویر کانتینر شما ساخته شده، در رجیستری Artifact ذخیره شده و در Cloud Run مستقر شده است.

در انتهای این کد لبه، برنامه شما باید شبیه برنامه java17-and-cloud-run/finish باشد.

و شما آن را دارید! شما با موفقیت یک برنامه Java 8 App Engine را به Java 17 و Cloud Run منتقل کرده‌اید و اکنون درک واضح‌تری از کار انجام شده هنگام تغییر و انتخاب بین گزینه‌های میزبانی دارید.

6. خلاصه/پاکسازی

تبریک می‌گوییم، شما برنامه خود را ارتقا داده، کانتینر کرده‌اید، مهاجرت کرده‌اید، که این آموزش را به پایان می‌رساند!

از اینجا، گام بعدی کسب اطلاعات بیشتر در مورد ویژگی‌های امنیتی زنجیره تامین CI/CD و نرم‌افزار است که اکنون در دسترس هستند و می‌توانید با Cloud Build گسترش دهید:

اختیاری: سرویس را تمیز و/یا غیرفعال کنید

اگر در طول این آموزش، برنامه نمونه را در App Engine نصب کرده اید، به خاطر داشته باشید که برای جلوگیری از تحمیل هزینه ، برنامه را غیرفعال کنید. هنگامی که برای انتقال به کد بعدی آماده شدید، می توانید آن را دوباره فعال کنید. در حالی که برنامه‌های App Engine غیرفعال هستند، هیچ ترافیکی برای تحمیل هزینه دریافت نمی‌کنند، اما استفاده از Datastore در صورتی که از سهمیه رایگان خود فراتر رود ممکن است قابل پرداخت باشد، بنابراین به اندازه‌ای حذف کنید که تحت این محدودیت قرار بگیرید.

از طرف دیگر، اگر قصد ندارید مهاجرت را ادامه دهید و می خواهید همه چیز را به طور کامل حذف کنید، می توانید سرویس خود را حذف کنید یا پروژه خود را به طور کامل خاموش کنید .

7. منابع اضافی

مشکلات/بازخورد مربوط به ماژول کدهای ماژول مهاجرت موتور برنامه

اگر مشکلی در این کد لبه پیدا کردید، لطفاً قبل از تشکیل پرونده ابتدا مشکل خود را جستجو کنید. پیوندهایی برای جستجو و ایجاد مسائل جدید:

منابع مهاجرت

منابع آنلاین

در زیر منابع آنلاینی وجود دارد که ممکن است برای این آموزش مرتبط باشد:

موتور برنامه

سایر اطلاعات Cloud

فیلم های

مجوز

این اثر تحت مجوز Creative Commons Attribution 2.0 Generic مجوز دارد.