این صفحه به‌وسیله ‏Cloud Translation API‏ ترجمه شده است.

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

۱. مرور کلی

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

این آموزش به شما آموزش می‌دهد که چگونه با استفاده از Jib ، یک برنامه App Engine را برای استقرار در سرویس کاملاً مدیریت‌شده Cloud Run، کانتینرایز کنید. با 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 Run، Artifact Registry و Cloud Build
برنامه خود را با استفاده از Jib و Cloud Build کانتینرایز کنید
تصاویر کانتینر خود را در Cloud Run مستقر کنید

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

یک پروژه پلتفرم ابری گوگل با یک حساب پرداخت GCP فعال و App Engine فعال
آشنایی کامل با دستورات رایج لینوکس
دانش پایه در توسعه و استقرار برنامه‌های App Engine
یک برنامه‌ی سرولت جاوا ۸ که می‌خواهید به جاوا ۱۷ منتقل کنید و در Cloud Run مستقر کنید (این می‌تواند یک برنامه در App Engine یا فقط منبع آن باشد)

نظرسنجی

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

فقط تا انتها بخوانید

آن را بخوانید و تمرین‌ها را انجام دهید

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

تازه کار

متوسط

ماهر

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

تازه کار

متوسط

ماهر

۲. پیشینه

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

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

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

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

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

این شامل کنار گذاشتن برخی از ویژگی‌های خاص App Engine می‌شود. اگر ترجیح می‌دهید این مسیر را دنبال نکنید، همچنان می‌توانید به Java 11/17 runtime ارتقا دهید و در عین حال برنامه‌های خود را در App Engine نگه دارید .

۳. تنظیمات/پیش‌پردازش

۱. پروژه راه‌اندازی

برای این آموزش، از یک برنامه نمونه از مخزن appengine-java-migration-samples در یک پروژه کاملاً جدید استفاده خواهید کرد. مطمئن شوید که پروژه دارای یک حساب صورتحساب فعال است.

اگر قصد دارید یک برنامه App Engine موجود را به Cloud Run منتقل کنید، می‌توانید از آن برنامه برای ادامه مسیر استفاده کنید.

برای فعال کردن API های لازم برای پروژه خود، دستور زیر را اجرا کنید:

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

۲. نمونه برنامه پایه را دریافت کنید

برنامه نمونه را یا روی دستگاه خودتان یا روی Cloud Shell کپی کنید، سپس به پوشه پایه بروید.

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

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

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

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

نصب/آشنایی مجدد با رابط خط فرمان gcloud
رابط خط فرمان gcloud را برای پروژه خود با gcloud init مقداردهی اولیه کنید.
پروژه App Engine را با gcloud app create ایجاد کنید
برنامه نمونه را در App Engine مستقر کنید

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

تأیید کنید که برنامه بدون مشکل در App Engine اجرا می‌شود.

۴. یک مخزن رجیستری مصنوعات ایجاد کنید

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

۴. تغییر فایل‌های برنامه

در مواردی که برنامه شما از سرویس‌های همراه قدیمی App Engine، پیکربندی یا سایر ویژگی‌های منحصراً App Engine به شدت استفاده می‌کند، توصیه می‌کنیم هنگام ارتقا به محیط اجرای جدید، به دسترسی به آن سرویس‌ها ادامه دهید . این آزمایشگاه کد، مسیر مهاجرت را برای برنامه‌هایی که از قبل از سرویس‌های مستقل استفاده می‌کنند یا می‌توانند برای انجام این کار بازسازی شوند، نشان می‌دهد.

۱. ارتقا به جاوا ۱۷

اگر برنامه شما با جاوا ۸ اجرا می‌شود، ارتقا به نسخه‌های جدیدتر LTS مانند ۱۱ یا ۱۷ را در نظر بگیرید تا از به‌روزرسانی‌های امنیتی مطلع باشید و به ویژگی‌های جدید زبان دسترسی پیدا کنید.

با به‌روزرسانی ویژگی‌های pom.xml خود شروع کنید تا موارد زیر را شامل شود:

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

این دستور نسخه پروژه را روی ۱۷ تنظیم می‌کند، به افزونه کامپایلر اطلاع می‌دهد که شما می‌خواهید به ویژگی‌های زبان جاوا ۱۷ دسترسی داشته باشید و می‌خواهید کلاس‌های کامپایل شده با JVM جاوا ۱۷ سازگار باشند.

۲. شامل کردن یک وب سرور

تفاوت‌های زیادی بین 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 استفاده می‌کند. همچنین می‌توانیم نسخه 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>

۳. تنظیم فنربندی

اگرچه 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 می‌گردد و آن‌ها را طبق انتظار در دسترس قرار می‌دهد.

۴. بسته‌بندی برنامه به صورت JAR

اگرچه می‌توان برنامه خود را با Jib از یک war کانتینرایز کرد، اما اگر برنامه خود را به عنوان یک 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>

۵. مهاجرت از پیکربندی، سرویس‌ها و وابستگی‌های App Engine

همانطور که در ابتدای کدلاگ ذکر شد، Cloud Run و App Engine برای ارائه تجربیات کاربری متفاوت طراحی شده‌اند. برخی از ویژگی‌هایی که App Engine به صورت پیش‌فرض ارائه می‌دهد - مانند سرویس‌های Cron و Task Queue - باید به صورت دستی دوباره ایجاد شوند و در ماژول‌های بعدی با جزئیات بیشتری به آنها پرداخته خواهد شد.

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

مهاجرت از سرویس‌های همراه به سرویس‌های مستقل مناسب.
انتقال فایل‌های پیکربندی XML به YAML ، برای کاربرانی که به زمان‌های اجرای جاوا ۱۱/۱۷ مهاجرت می‌کنند و در عین حال از 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>

۵. کانتینر کردن برنامه

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

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

۱. یک فایل 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 ‎ اجرا کنید.
با Jib ، تصویر خود را بسازید، ارسال کنید و در رجیستری Artifact تگ کنید
با استفاده از gcloud run deploy ایمیج خود را روی Cloud Run مستقر کنید.

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

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

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

۲. فرآیند ساخت را اجرا کنید

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

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

gcloud builds submit

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

در پایان این آزمایشگاه کد، برنامه شما باید مشابه برنامه موجود در فایل java17-and-cloud-run/finish باشد.

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

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

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

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

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

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

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

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

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

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

منابع مهاجرت

گزینه‌های مهاجرت برای جداسازی سرویس‌های موتور برنامه
راه‌اندازی محرک‌های ساخت برای Cloud Build
اطلاعات بیشتر در مورد مهاجرت به جاوا ۱۱/۱۷

منابع آنلاین

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

موتور برنامه

مستندات موتور برنامه
اطلاعات قیمت‌گذاری و سهمیه‌بندی موتور برنامه
مقایسه پلتفرم‌های نسل اول و دوم
پشتیبانی بلندمدت از ران‌تایم‌های قدیمی

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

ویدیوها

مجوز

این اثر تحت مجوز عمومی Creative Commons Attribution 2.0 منتشر شده است.