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

1. نظرة عامة

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

يشرح لك هذا البرنامج التعليمي كيفية إنشاء حاوية لتطبيق App Engine من أجل نشره على خدمة Cloud Run المُدارة بالكامل باستخدام حِزم Buildpack. حِزم Buildpacks هي مشروع CNCF يتيح لك نقل تطبيقك مباشرةً من رمز المصدر إلى صور قابلة للنقل ويمكن تشغيلها على أي سحابة إلكترونية.

بالإضافة إلى تعليمك الخطوات المطلوبة للانتقال من App Engine إلى Cloud Run، ستتعلم أيضًا كيفية ترقية تطبيق Java 8 App Engine إلى Java 17.

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

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

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

المتطلبات

استطلاع

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

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

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

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

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

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

2. الخلفية

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

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

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

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

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

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

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

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

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

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، ننصحك بالترقية إلى إصدار أحدث من الإصدارات المرشّحة للدعم الطويل الأمد، مثل 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 وإعلام المكوّن الإضافي للمجمِّع بأنّك تريد الوصول إلى ميزات لغة Java 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 لتقليل الاختلافات في السلوك التلقائي بعد نقل البيانات.

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. إعدادات التصميم

بعد ذلك، أزِل الإعداد لحزمة تطبيقنا كملف WAR. لن يتطلّب ذلك الكثير من الإعدادات، لا سيما في المشاريع التي تستخدم 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 و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- إنشاء حاويات للتطبيق ونشره

في هذه المرحلة، تكون مستعدًا لنشر تطبيقك على Cloud Run مباشرةً من رمز المصدر. هذا خيار ممتاز يستخدم Cloud Build في الخلفية لتوفير تجربة نشر بدون تدخل من المستخدم. يُرجى العِلم أنّه لاستخدام هذه الميزة، ستحتاج إلى حساب لديه إذن واحد على الأقل من الأذونات التالية، وإلى اتّباع خطوات إعداد البيئة هذه، أو استخدام Cloud Shell:

مع استيفاء هذه المتطلبات الأساسية، ما عليك سوى تشغيل ما يلي من دليل ملفات المصدر:

gcloud run deploy SERVICE --source .

سيُطلب منك تقديم بعض المعلومات أثناء تنفيذ الأمر run deploy، مثل:

  • توفير مكان رمز المصدر
  • تقديم اسم الخدمة
  • تفعيل Cloud Run API
  • اختيار منطقتك

بعد الاستجابة لتلك المطالبات، تبدأ عملية الإنشاء والنشر، والتي تنفذ Cloud Build خلالها ما يلي:

  • ضغط المصدر وحفظه في حزمة تخزين في السحابة الإلكترونية
  • استخدام حِزم إنشاء Cloud Native Computing Foundation في الخلفية لإنشاء صورتك
  • إنشاء سجل لتخزين صورة الحاوية الناتجة (إذا لم تكن موجودة)
  • وإنشاء خدمة Cloud Run لاستضافة تطبيقك (إذا لم تكن متوفّرة)

بعد اكتمال عملية الإنشاء والنشر، من المفترض أن تصلك رسالة توضّح أنّه تم نشر نسخة جديدة وعرضها على 100% من الزيارات.

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

تهانينا، لقد أجريت ترقية لتطبيقك ووضعته في حاوية ونقلته، ما يُنهي هذا الدليل التعليمي.

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

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

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

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

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

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

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

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

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

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

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

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

الفيديوهات

الترخيص

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