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

1. نظرة عامة

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

يُعرِّفك هذا البرنامج التعليمي على كيفية وضع تطبيق App Engine في حاويات للنشر في خدمة Cloud Run المُدارة بالكامل باستخدام ملف Dockerfile. وتعد ملفات Dockerfiles أكثر طرق النشر العملية لعملية النقل هذه، ولكنها توفّر أيضًا أكبر قدر من الخيارات لتخصيص عملية التصميم.

بالإضافة إلى تعليمك الخطوات المطلوبة للانتقال من 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
  • احتواء تطبيقك في حاويات باستخدام Docker و Docker وCloud Build
  • نشر صور الحاوية إلى التشغيل في السحابة الإلكترونية

المتطلبات

استطلاع

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

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

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

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

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

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

2. الخلفية

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

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

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

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

وعلى الرغم من إمكانية تضمين تطبيقك في حاويات بدءًا من الحرب، يصبح من الأسهل تجميع تطبيقك على أنّه ملف 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 Build بكيفية إنشاء حاوية تطبيقك. باستخدام طريقة إنشاء الحاوية هذه، لا يكون مطلوبًا تقديم ملف إعداد منفصل (cloudbuild.yaml). يمكننا ببساطة تعريف ملف Dockerfile صغير كنقطة بداية:

من كسوف تيمورين

ARG JAR_FILE=JAR_FILE_MUST_BE_SPECIFIED_AS_BUILD_ARG

نسخ جرّة app.jar ${JAR_FILE}

ENTRYPOINT ["java", "-jar","/app.jar"]

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

2**. تنفيذ عملية التصميم**

الآن بعد أن أطلعت Cloud Build على خطوات التصميم المطلوبة، أصبحت جاهزًا للنشر بنقرة واحدة.

شغِّل الأمر التالي:

gcloud builds submit --tag LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY/IMAGE_NAME

استبدل قيم العنصر النائب في الأمر أعلاه بما يلي:

  • LOCATION: وهو موقع المستودع الجغرافي الإقليمي أو المتعدّد المناطق.
  • PROJECT_ID: رقم تعريف مشروعك على Google Cloud.
  • REPOSITORY: اسم مستودع Artifact Registry.
  • IMAGE_NAME: اسم صورة الحاوية.

بعد اكتمال العملية، يتم إنشاء صورة الحاوية وتخزينها في Artifact Registry ونشرها على Cloud Run.

في نهاية هذا الدرس التطبيقي، من المفترض أن يظهر تطبيقك بالشكل نفسه الذي يظهر به التطبيق في مجلد mod4-migrate-to-cloud-run.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

الفيديوهات

الترخيص

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