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

1. نظرة عامة

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

ستتعرّف على كيفية

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

المتطلبات

استطلاع

كيف ستستخدم هذا الدليل التعليمي؟

قراءته فقط قراءته وإكمال التمارين

كيف تقيّم تجربتك مع Java؟

مبتدئ متوسط متقدّم

ما مدى رضاك عن تجربتك في استخدام خدمات Google Cloud؟

مبتدئ متوسط خبير

2. الخلفية

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

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

إن تعلّم كيفية استخدام Cloud Run ليس ضمن نطاق هذا الدرس التطبيقي حول الترميز، وهو مشمول في مستندات Cloud Run. والهدف من هذه المقالة هو تعريفك على كيفية استخدام حاويات لتطبيقك على 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 المستنِد إلى Servlet في Datastore والمخصّص للنشر على 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 فقط، ننصحك بمواصلة الوصول إلى هذه الخدمات أثناء الترقية إلى نظام التشغيل الجديد. يوضّح هذا الدرس التطبيقي حول الترميز مسار نقل البيانات للتطبيقات التي تستخدم حاليًا خدمات مستقلة أو يمكن إعادة هيكلتها بشكل عملي لإجراء ذلك.

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 لتزويدنا بخادم ويب وحاوية 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>

3. إعداد Spring Boot

على الرغم من أن 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 بدءًا من ملف 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>

5- نقل الإعدادات والخدمات والتبعيات من 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>

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 أثناء هذا الدليل التعليمي، احرص على إيقاف التطبيق لتجنُّب تحصيل رسوم منك. عندما تكون مستعدًا للانتقال إلى دورة codelab التالية، يمكنك إعادة تفعيلها. عندما تكون تطبيقات App Engine غير مفعّلة، لن تتلقّى أي زيارات تؤدي إلى تحصيل رسوم، ولكن قد يتم تحصيل رسوم مقابل استخدام Datastore إذا تجاوز الحصة المجانية، لذا عليك حذف ما يكفي من البيانات لتصبح ضمن هذا الحدّ.

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

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

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

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

مراجع نقل البيانات

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

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

App Engine

معلومات أخرى حول Cloud

الفيديوهات

الترخيص

يخضع هذا العمل للترخيص العام Creative Commons Attribution 2.0.