النقل من تطبيق Google App Engine Java إلى "تشغيل السحابة الإلكترونية باستخدام Jib"

1. نظرة عامة

تهدف هذه السلسلة من الدروس التطبيقية حول الترميز (البرامج التعليمية العملية الذاتية) إلى مساعدة Google App Engine (العادي) لمطوّري Java على تحديث تطبيقاتهم من خلال إرشادهم خلال سلسلة من عمليات نقل البيانات. باتّباع هذه الخطوات، يمكنك تحديث تطبيقك ليصبح أكثر قابلية للنقل وتحديد احتواءه على 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 المجمَّعة في Java 17/11 عند الترقية إلى بيئة تشغيل أحدث. عندما يكون تطبيقك قابلاً للنقل، يمكنك الرجوع إلى هذا الدرس التطبيقي حول الترميز لمعرفة كيفية تطبيق التعليمات على تطبيقك.

ستتعرَّف على كيفية إجراء ما يلي:

  • استخدام Cloud Shell
  • تفعيل واجهات برمجة التطبيقات في Cloud Run و Artifact Registry وCloud Build
  • تغليف تطبيقك في حاويات باستخدام Jib وCloud Build
  • نشر صور الحاوية إلى التشغيل في السحابة الإلكترونية

المتطلبات

استطلاع

كيف ستستخدم هذا البرنامج التعليمي؟

القراءة فقط اقرأها وأكمِل التمارين

كيف تقيّم تجربتك في استخدام Java؟

حديث متوسط بارع

ما هو تقييمك لتجربتك في استخدام خدمات Google Cloud؟

حديث متوسط بارع

2. الخلفية

توفّر أنظمة "النظام الأساسي كخدمة (PaaS)"، مثل App Engine وCloud Functions، العديد من وسائل الراحة لفريقك وتطبيقك، مثل تمكين مسؤولي إدارة النظم وDevops من التركيز على إنشاء الحلول. بفضل عدم استخدام منصات متعددة، يمكن لتطبيقك التوسّع تلقائيًا حسب الحاجة، وتقليل قيمته إلى الصفر باستخدام نظام فوترة الدفع لكل استخدام للمساعدة في التحكّم في التكاليف، واستخدام مجموعة متنوعة من لغات التطوير الشائعة.

ومع ذلك، تُعد مرونة الحاويات مقنعة أيضًا. وبفضل إمكانية اختيار أي لغة وأي مكتبة وأي محتوى ثنائي، تمنحك الحاويات أفضل ما في العالمَين: الراحة بدون خادم إلى جانب مرونة الحاويات. هذا ما تدور حوله خدمة Cloud Run.

إنّ تعلّم كيفية استخدام Cloud Run ليس ضمن نطاق هذا الدرس التطبيقي حول الترميز. المشمولة في مستندات تشغيل Cloud. الهدف هنا هو التعرُّف على كيفية إضافة تطبيق App Engine إلى Cloud Run (أو أي خدمات أخرى تستضيفها الحاوية). هناك بعض الأشياء التي يجب أن تعرفها قبل المضي قدمًا، وهي أن تجربة المستخدم ستكون مختلفة قليلاً في المقام الأول.

في هذا الدرس التطبيقي حول الترميز، ستتعلّم كيفية إنشاء الحاويات ونشرها. وستتعرّف على كيفية:

  • تغليف تطبيقك في حاويات باستخدام Jib
  • نقل البيانات بعيدًا عن إعداد App Engine
  • ويمكنك تحديد خطوات التصميم لخدمة Cloud Build إذا أردت.

ويشمل ذلك التوقف عن استخدام ميزات معيّنة خاصة بـ App Engine. إذا كنت تفضّل عدم اتّباع هذا المسار، سيظل بإمكانك الترقية إلى وقت تشغيل Java الإصدار 11/17 مع الاحتفاظ بتطبيقاتك على App Engine بدلاً من ذلك.

3- الإعداد/التمهيد

1. إعداد المشروع

بالنسبة لهذا البرنامج التعليمي، ستستخدم نموذج تطبيق من مستودع appengine-java-migration-samples في مشروع جديد تمامًا. تأكَّد من أنّ المشروع يتضمّن حساب فوترة نشطًا.

إذا كنت تنوي نقل تطبيق حالي في App Engine إلى تشغيل في السحابة الإلكترونية، يمكنك استخدام هذا التطبيق للمتابعة بدلاً من ذلك.

قم بتشغيل الأمر التالي لتمكين واجهات برمجة التطبيقات اللازمة لمشروعك:

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

2. الحصول على نموذج تطبيق أساسي

استنسِخ نموذج التطبيق إما على جهازك أو من Cloud Shell، ثم انتقِل إلى مجلد baseline.

العينة عبارة عن تطبيق تخزين بيانات يستند إلى Java 8، وهو تطبيق مخزن بيانات يستند إلى سيرفلت مخصص للنشر على App Engine. اتبع التعليمات الواردة في الملف التمهيدي حول كيفية إعداد هذا التطبيق لنشر App Engine.

3. (اختياري) نشر التطبيق الأساسي

ما يلي ضروري فقط إذا كنت تريد التأكّد من أن التطبيق يعمل على App Engine قبل أن ننتقل إلى Cloud Run.

راجع الخطوات في README.md:

  1. تثبيت واجهة سطر الأوامر "gcloud" أو التعرّف عليها من جديد
  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 Registry

بعد تضمين تطبيقك في حاويات، ستحتاج إلى مكان لنشر صورك وتخزينها. الطريقة التي ننصح بها لتنفيذ هذا الإجراء على 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. الترقية إلى Java 17

إذا كان تطبيقك يستخدم Java 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 لتزويدنا بخادم ويب وحاوية serlet.

أضف التبعيات التالية:

<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 كأداة إنشاء، لأنّ تغليف الوعاء هو السلوك التلقائي.

إزالة العلامة 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 وقائمة انتظار المهام، وسيتم تناولها بمزيد من التفاصيل في الوحدات اللاحقة.

لا يستفيد نموذج التطبيق من الخدمات المجمّعة القديمة، ولكن يمكن لمستخدمي تطبيقاتهم الرجوع إلى الأدلة التالية:

بما أنّك ستنشر في 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

في هذه المرحلة، يمكنك نشر تطبيقك يدويًا في 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. أنشِئ صورتك وانشرها وأضِف علامة إليها في سجلّ Artifact باستخدام Jib.
  3. نشر صورتك في Cloud Run باستخدام "gcloud run deploy"

يُرجى ملاحظة أنه يتم توفير ‘visitors' في Cloud Run باعتباره اسم الخدمة المطلوبة. تتيح العلامة –allow-unauthenticated للمستخدمين زيارة تطبيق الويب بدون الحاجة إلى المصادقة. احرص على استبدال PROJECT_ID برقم تعريف مشروعك في cloudbuild.yaml الملف.

بعد ذلك، أضِف التزامات سياسة "إدارة الهوية وإمكانية الوصول" التالية للسماح بحساب خدمة Cloud Build على Artifact Registry:

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 Registry ونشرها على Cloud Run.

في نهاية هذا الدرس التطبيقي، من المفترض أن يظهر تطبيقك بالشكل نفسه في java17-and-cloud-run/finish.

وإلى هنا، فقد تحققت رغبتك! لقد نجحت في نقل تطبيق Java 8 App Engine إلى Java 17 وCloud Run، وأصبح لديك الآن فهم أوضح للعمل المطلوب عند التبديل والاختيار بين خيارات الاستضافة.

6- الملخّص/تنظيف البيانات

تهانينا، لقد تمت ترقية تطبيقك وحاوياته ونقله إلى تطبيقك، وبهذا نكون قد انتهينا من هذا البرنامج التعليمي.

من هنا، تتمثّل الخطوة التالية في التعرّف على المزيد من المعلومات عن ميزات أمان "الوصول إلى الكمبيوتر (CI)/CD و"سلسلة إمداد البرامج" المتاحة الآن والتي يمكنك نشرها من خلال Cloud Build:

اختياري: حذف الخدمة و/أو إيقافها

إذا نشرت نموذج التطبيق على App Engine أثناء هذا البرنامج التعليمي، لا تنسَ إيقاف التطبيق لتجنب تحمل الرسوم. عندما تكون مستعدًا للانتقال إلى الدرس التطبيقي التالي حول الترميز، يمكنك إعادة تفعيله. على الرغم من إيقاف تطبيقات App Engine، لن تتلقّى أي زيارات لفرض رسوم، ومع ذلك قد يكون استخدام تخزين البيانات قابلاً للفوترة إذا تجاوزت حصته المجانية، لذا يجب حذفها بدرجة كافية بحيث تندرج ضمن هذا الحدّ.

من ناحية أخرى، إذا كنت لا تتابع عمليات النقل وأردت حذف كل البيانات بالكامل، يمكنك إما حذف خدمتك أو إيقاف مشروعك بالكامل.

7. مراجع إضافية

المشاكل/الملاحظات في الدروس التطبيقية حول ترميز وحدة نقل بيانات App Engine

إذا وجدت أي مشاكل في هذا الدرس التطبيقي حول الترميز، يُرجى البحث عن مشكلتك أولاً قبل ملء النموذج. روابط للبحث وإنشاء مشاكل جديدة:

موارد نقل البيانات

مراجع على الإنترنت

في ما يلي موارد على الإنترنت قد تكون ذات صلة بهذا البرنامج التعليمي:

محرك التطبيقات

معلومات أخرى عن السحابة الإلكترونية

الفيديوهات

الترخيص

هذا العمل مرخّص بموجب رخصة المشاع الإبداعي 2.0 مع نسب العمل إلى مؤلف عام.