1. بررسی اجمالی
هدف این سری از نرمافزارهای کد (آموزشهای عملی و خودکار) این است که به توسعهدهندگان جاوا موتور برنامه Google (استاندارد) کمک کند تا برنامههای خود را با هدایت آنها از طریق یک سری مهاجرت مدرنسازی کنند. با دنبال کردن این مراحل، میتوانید برنامهتان را بهروزرسانی کنید تا قابل حملتر باشد و تصمیم بگیرید آنها را برای Cloud Run ، سرویس خواهر میزبانی کانتینر Google Cloud به App Engine و دیگر سرویسهای میزبانی کانتینر، کانتینری کنید.
این آموزش به شما می آموزد که چگونه یک برنامه App Engine را برای استقرار در سرویس کاملاً مدیریت شده Cloud Run با استفاده از Buildpacks کانتینری کنید. Buildpacks یک پروژه CNCF است که به شما امکان می دهد برنامه خود را مستقیماً از کد منبع به تصاویر بسیار قابل حملی که می توانند روی هر ابری اجرا شوند، ببرید.
علاوه بر آموزش مراحل مورد نیاز برای انتقال از App Engine به Cloud Run، همچنین یاد خواهید گرفت که چگونه یک برنامه Java 8 App Engine را به Java 17 ارتقا دهید.
اگر برنامهای که میخواهید مهاجرت کنید از خدمات همراه قدیمی App Engine یا سایر ویژگیهای خاص App Engine استفاده زیادی میکند، راهنمای دسترسی به خدمات همراه App Engine برای Java 11/17 ممکن است مناسبتر از این Codelab باشد.
شما یاد خواهید گرفت که چگونه
- از Cloud Shell استفاده کنید
- APIهای Cloud Run، Artifact Registry و Cloud Build را فعال کنید
- برنامه خود را با استفاده از Buildpacks در Cloud Build محفظه کنید
- تصاویر کانتینر خود را در Cloud Run مستقر کنید
آنچه شما نیاز دارید
- یک پروژه Google Cloud Platform با یک حساب صورتحساب GCP فعال و موتور برنامه فعال است
- دانش کاری دستورات رایج لینوکس
- دانش اولیه توسعه و استقرار برنامه های App Engine
- یک برنامه سرولت جاوا 8 که می خواهید به جاوا 17 منتقل کنید و در Cloud Run مستقر کنید (این می تواند یک برنامه در App Engine یا فقط منبع باشد)
نظرسنجی
چگونه از این آموزش استفاده خواهید کرد؟
تجربه خود را با جاوا چگونه ارزیابی می کنید؟
تجربه خود را در استفاده از خدمات Google Cloud چگونه ارزیابی می کنید؟
2. پس زمینه
سیستمهای PaaS مانند App Engine و Cloud Functions امکانات زیادی را برای تیم و برنامه شما فراهم میکنند، مانند اینکه SysAdmins و Devops را قادر میسازد تا روی راهحلهای ساختن تمرکز کنند. با پلتفرمهای بدون مشکل، برنامه شما میتواند در صورت نیاز، مقیاس خودکار را افزایش دهد، با صورتحساب پرداخت به ازای استفاده، برای کمک به کنترل هزینهها، به صفر کاهش دهد و از انواع زبانهای توسعه رایج استفاده کند.
با این حال، انعطاف پذیری ظروف نیز قانع کننده است. کانتینرها با توانایی انتخاب هر زبان، هر کتابخانه و هر باینری، بهترین هر دو دنیا را به شما می دهند: راحتی بدون سرور و انعطاف پذیری کانتینرها. این همان چیزی است که Google Cloud Run در مورد آن است.
یادگیری نحوه استفاده از Cloud Run در محدوده این کد لبه نیست. که توسط مستندات Cloud Run پوشش داده شده است. هدف در اینجا این است که شما با نحوه کانتینری کردن برنامه App Engine خود برای Cloud Run (یا سایر خدمات میزبان کانتینر) آشنا شوید. چند نکته وجود دارد که باید قبل از حرکت به جلو بدانید، در درجه اول اینکه تجربه کاربری شما کمی متفاوت خواهد بود.
در این کد لبه، نحوه ساخت و استقرار کانتینرها را یاد خواهید گرفت. شما یاد خواهید گرفت که چگونه برنامه خود را با Buildpacks محفظه کنید، از پیکربندی 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 مراجعه کنید:
- نصب/آشنایی مجدد با
gcloud
CLI - gcloud CLI را برای پروژه خود با
gcloud init
راه اندازی کنید - پروژه App Engine را با
gcloud app create
- برنامه نمونه را در App Engine اجرا کنید
./mvnw package appengine:deploy -Dapp.projectId=$PROJECT_ID
- تأیید کنید که برنامه بدون مشکل در 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 میپیوندد تا تفاوتها در رفتار پیشفرض پس از مهاجرت به حداقل برسد.
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. پیکربندی ساخت
در مرحله بعد، پیکربندی بسته بندی برنامه ما را به عنوان یک جنگ حذف کنید. این به پیکربندی زیادی نیاز ندارد، به ویژه برای پروژه هایی که از 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 - باید دوباره به صورت دستی ایجاد شوند و در ماژولهای بعدی با جزئیات بیشتری پوشش داده میشوند.
برنامه نمونه از سرویسهای همراه قدیمی استفاده نمیکند، اما کاربرانی که برنامههایشان استفاده میکنند میتوانند به راهنماهای زیر مراجعه کنند:
- مهاجرت از خدمات همراه برای یافتن خدمات مستقل مناسب.
- انتقال فایلهای پیکربندی XML به YAML ، برای کاربرانی که به زمانهای اجرا جاوا 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. Containerize & Deploy برنامه
در این مرحله شما آماده هستید تا برنامه خود را مستقیماً از کد منبع خود در Cloud Run اجرا کنید. این یک گزینه عالی است که از Cloud Build در پشت صحنه برای ارائه یک تجربه استقرار دستی استفاده می کند. توجه داشته باشید که برای استفاده از این ویژگی یا به یک حساب کاربری با حداقل یکی از مجوزهای زیر نیاز دارید و این مراحل تنظیم محیط را دنبال کرده باشید - یا از Cloud Shell استفاده کنید:
- نقش مالک
- نقش ویرایشگر
- مجموعه ای از نقش های زیر:
- نقش ویرایشگر ساخت ابر
- نقش مدیر رجیستری مصنوع
- نقش مدیر ذخیره سازی
- نقش مدیر Cloud Run
- نقش کاربر حساب سرویس
با وجود این پیش نیازها، به سادگی موارد زیر را از دایرکتوری منبع خود اجرا کنید:
gcloud run deploy SERVICE --source .
در طول دستور run deploy از شما خواسته می شود مواردی مانند:
- ارائه محل کد منبع
- ارائه نام سرویس
- فعال کردن Cloud Run API
- انتخاب منطقه شما
پس از پاسخ به این دستورات، فرآیند ساخت و استقرار آغاز می شود، که در طی آن Cloud Build کارهای زیر را انجام می دهد:
- منبع شما را فشرده و در یک سطل ذخیره سازی ابری ذخیره می کند
- از بستههای ساخت بنیاد محاسباتی Cloud Native در پسزمینه برای ساخت تصویر شما استفاده میکند
- یک رجیستری ایجاد می کند تا تصویر ظرف حاصل را ذخیره کند (اگر قبلاً وجود نداشته باشد)
- و یک سرویس اجرای ابری برای میزبانی برنامه شما ایجاد می کند (اگر قبلاً وجود نداشته باشد)
هنگامی که ساخت و استقرار کامل شد، باید پیامی دریافت کنید که توضیح میدهد یک ویرایش جدید زنده است و 100٪ ترافیک را ارائه میکند.
6. خلاصه/پاکسازی
تبریک میگوییم، شما برنامه خود را ارتقا داده، کانتینر کردهاید، مهاجرت کردهاید، که این آموزش را به پایان میرساند!
از اینجا، گام بعدی کسب اطلاعات بیشتر در مورد ویژگیهای امنیتی زنجیره تامین CI/CD و نرمافزار است که اکنون در دسترس هستند و میتوانید با Cloud Build گسترش دهید:
- ایجاد مراحل ساخت سفارشی با Cloud Build
- ایجاد و مدیریت Build Triggers
- استفاده از اسکن درخواستی در خط لوله ساخت Cloud خود
اختیاری: سرویس را تمیز و/یا غیرفعال کنید
اگر در طول این آموزش، برنامه نمونه را در App Engine نصب کرده اید، به خاطر داشته باشید که برای جلوگیری از تحمیل هزینه ، برنامه را غیرفعال کنید. هنگامی که برای انتقال به کد بعدی آماده شدید، می توانید آن را دوباره فعال کنید. در حالی که برنامههای App Engine غیرفعال هستند، هیچ ترافیکی برای تحمیل هزینه دریافت نمیکنند، اما استفاده از Datastore در صورتی که از سهمیه رایگان خود فراتر رود ممکن است قابل پرداخت باشد، بنابراین به اندازهای حذف کنید که تحت این محدودیت قرار بگیرید.
از طرف دیگر، اگر قصد ندارید مهاجرت را ادامه دهید و می خواهید همه چیز را به طور کامل حذف کنید، می توانید سرویس خود را حذف کنید یا پروژه خود را به طور کامل خاموش کنید .
7. منابع اضافی
مشکلات/بازخورد مربوط به ماژول کدهای ماژول مهاجرت موتور برنامه
اگر مشکلی در این کد لبه پیدا کردید، لطفاً قبل از تشکیل پرونده ابتدا مشکل خود را جستجو کنید. پیوندهایی برای جستجو و ایجاد مسائل جدید:
منابع مهاجرت
- گزینه های مهاجرت برای جداسازی خدمات موتور برنامه
- راه اندازی Build triggers برای Cloud Build
- اطلاعات بیشتر در مورد مهاجرت به جاوا 11/17
منابع آنلاین
در زیر منابع آنلاینی وجود دارد که ممکن است برای این آموزش مرتبط باشد:
موتور برنامه
- مستندات App Engine
- اطلاعات قیمت و سهمیه موتور App
- مقایسه پلت فرم های نسل اول و دوم
- پشتیبانی طولانی مدت از زمان های اجرا قدیمی
سایر اطلاعات Cloud
- لایه Google Cloud "همیشه رایگان".
- Google Cloud CLI (
gcloud
CLI) - تمام اسناد Google Cloud
ویدیوها
- ایستگاه مهاجرت بدون سرور
- اکسپدیشن های بدون سرور
- در Google Cloud Tech مشترک شوید
- در Google Developers مشترک شوید
مجوز
این اثر تحت مجوز Creative Commons Attribution 2.0 Generic مجوز دارد.