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

۱. مرور کلی

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

این آموزش به شما آموزش می‌دهد که چگونه با استفاده از Buildpacks، یک برنامه App Engine را برای استقرار در سرویس کاملاً مدیریت‌شده Cloud Run، کانتینرایز کنید. Buildpacks یک پروژه CNCF است که به شما امکان می‌دهد برنامه خود را مستقیماً از کد منبع به تصاویر بسیار قابل حمل که می‌توانند روی هر ابری اجرا شوند، ببرید.

علاوه بر آموزش مراحل لازم برای انتقال از 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
  • برنامه خود را با استفاده از Buildpacks در Cloud Build کانتینرایز کنید
  • تصاویر کانتینر خود را در Cloud Run مستقر کنید

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

نظرسنجی

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

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

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

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

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

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

۲. پیشینه

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

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

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

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

۴. پیکربندی ساخت

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

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

از آنجایی که از این به بعد روی 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 در پشت صحنه برای ارائه یک تجربه استقرار بدون دخالت دست استفاده می‌کند. توجه داشته باشید که برای استفاده از این ویژگی، یا به یک حساب کاربری با حداقل یکی از مجوزهای زیر نیاز دارید و این مراحل راه‌اندازی محیط را دنبال کرده‌اید - یا از Cloud Shell استفاده کنید:

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

gcloud run deploy SERVICE --source .

در طول اجرای دستور deploy، از شما چند مورد پرسیده می‌شود، مانند:

  • ارائه محل کد منبع
  • ارائه نام سرویس
  • فعال کردن API اجرای ابری
  • انتخاب منطقه شما

پس از پاسخ به این درخواست‌ها، فرآیند ساخت و استقرار آغاز می‌شود که طی آن Cloud Build موارد زیر را انجام می‌دهد:

  • فایل منبع شما را فشرده کرده و در یک فضای ذخیره‌سازی ابری ذخیره می‌کند
  • از بسته‌های ساخت بنیاد محاسبات ابری بومی در پس‌زمینه برای ساخت ایمیج شما استفاده می‌کند.
  • یک رجیستری برای ذخیره تصویر کانتینر حاصل ایجاد می‌کند (اگر از قبل وجود نداشته باشد)
  • و یک سرویس ابری برای میزبانی برنامه شما ایجاد می‌کند (اگر از قبل وجود نداشته باشد)

پس از اتمام ساخت و استقرار، باید پیامی دریافت کنید که توضیح می‌دهد نسخه جدید در حال اجرا است و ۱۰۰٪ ترافیک را ارائه می‌دهد.

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

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

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

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

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

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

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

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

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

منابع مهاجرت

منابع آنلاین

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

موتور برنامه

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

ویدیوها

مجوز

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