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

۱. مرور کلی

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

این آموزش به شما آموزش می‌دهد که چگونه یک برنامه App Engine را برای استقرار در سرویس کاملاً مدیریت‌شده Cloud Run با استفاده از Dockerfile، کانتینرایز کنید. Dockerfileها کاربردی‌ترین روش استقرار برای این مهاجرت هستند، اما بیشترین گزینه‌ها را نیز برای سفارشی‌سازی فرآیند ساخت شما ارائه می‌دهند.

علاوه بر آموزش مراحل لازم برای انتقال از App Engine به Cloud Run، نحوه ارتقاء یک برنامه Java 8 App Engine به Java 17 را نیز خواهید آموخت.

اگر برنامه‌ای که قصد مهاجرت به آن را دارید، از سرویس‌های همراه قدیمی App Engine یا سایر ویژگی‌های خاص App Engine استفاده زیادی می‌کند، راهنمای Accessing App Engine bundled Services for Java 11/17 می‌تواند نقطه شروع بهتری نسبت به این codelab باشد.

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

  • از پوسته ابری استفاده کنید
  • فعال کردن رابط‌های برنامه‌نویسی Cloud Run، Artifact Registry و Cloud Build
  • کانتینرایز کردن برنامه شما با استفاده از داکر، داکر و کلود بیلد
  • تصاویر کانتینر خود را در Cloud Run مستقر کنید

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

نظرسنجی

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

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

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

تازه کار متوسط ماهر

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

تازه کار متوسط ماهر

۲. پیشینه

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

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

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

در این آزمایشگاه کد، نحوه ساخت و استقرار کانتینرها را خواهید آموخت. یاد خواهید گرفت که چگونه برنامه خود را با Dockerfile کانتینری کنید، از پیکربندی 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 مراجعه کنید:

  1. نصب/آشنایی مجدد با رابط خط فرمان gcloud
  2. رابط خط فرمان gcloud را برای پروژه خود با gcloud init مقداردهی اولیه کنید.
  3. پروژه App Engine را با gcloud app create ایجاد کنید
  4. برنامه نمونه را در App Engine مستقر کنید 
./mvnw package appengine:deploy -Dapp.projectId=$PROJECT_ID
  1. تأیید کنید که برنامه بدون مشکل در 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 پایبند می‌ماند تا تفاوت‌ها در رفتار پیش‌فرض پس از مهاجرت به حداقل برسد.

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

اگرچه 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

اگرچه می‌توان برنامه خود را از یک war به صورت containerize درآورد، اما اگر برنامه خود را به عنوان یک JAR اجرایی بسته‌بندی کنید، این کار آسان‌تر می‌شود. این کار به پیکربندی زیادی نیاز ندارد، به خصوص برای پروژه‌هایی که از Maven به عنوان ابزار ساخت استفاده می‌کنند - زیرا jar packaging رفتار پیش‌فرض است.

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

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

از آنجایی که از این به بعد روی 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 Build اطلاع دهید که چگونه کانتینر برنامه خود را بسازد. با این روش کانتینرسازی، به یک فایل پیکربندی ساخت جداگانه (cloudbuild.yaml) نیازی نیست. می‌توانیم به سادگی یک Dockerfile حداقلی را به عنوان نقطه شروع تعریف کنیم:

از گرفتگی-تمورین

فایل JAR_ARG=فایل JAR_باید_به_عنوان_ساخت_مشخص_شود_ARG

کپی کردن فایل app.jar از ${JAR_FILE}

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

این dockerfile نسخه uber-jar سرویس spring boot شما را در یک لایه واحد قرار می‌دهد. این ساده‌ترین رویکرد برای کانتینرسازی Dockerfile است، اما دارای تعدادی ایراد است، به خصوص هنگام مقایسه زمان‌های مکرر که در آن وابستگی‌ها نسبتاً پایدار هستند. نگرانی‌هایی مانند این دلیل پیشرفته‌تر در نظر گرفته شدن این روش کانتینرسازی است. با این حال، از جنبه مثبت، نوشتن dockerfile خودتان کنترل کاملی بر روی تصویر پایه شما و دسترسی به مزایای عملکرد نوشتن یک تصویر با دقت لایه‌بندی شده ارائه می‌دهد.

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

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

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

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

مقادیر placeholder در دستور بالا را با مقادیر زیر جایگزین کنید:

  • مکان: موقعیت منطقه‌ای یا چندمنطقه‌ای مخزن شما.
  • PROJECT_ID: شناسه پروژه ابری شما.
  • مخزن: نام مخزن ثبت آثار باستانی شما.
  • IMAGE_NAME: نام تصویر کانتینر شما.

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

در پایان این کدنویسی، برنامه شما باید مشابه برنامه موجود در پوشه mod4-migrate-to-cloud-run باشد.

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

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

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

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

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

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

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

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

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

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

منابع مهاجرت

منابع آنلاین

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

موتور برنامه

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

ویدیوها

مجوز

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