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

1. نظرة عامة

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

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

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

المتطلبات

استطلاع

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

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

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

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

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

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

2. الخلفية

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

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

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

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

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

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

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

بما أنّك ستنشر في 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 Build خلف الكواليس لتوفير تجربة نشر سلسة. تجدر الإشارة إلى أنّه من أجل الاستفادة من هذه الميزة، يجب أن يكون لديك حساب يمتلك أحد الأذونات التالية على الأقل، وأن تتبع خطوات إعداد البيئة هذه، أو يمكنك استخدام Cloud Shell:

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

gcloud run deploy SERVICE --source .

ستتم مطالبتك ببعض الأشياء أثناء أمر التشغيل run مثل:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

الفيديوهات

الترخيص

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