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

1. نظرة عامة

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

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

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

المتطلبات

• أن يكون لديك مشروع Google Cloud Platform مع حساب فوترة نشط على Google Cloud Platform وتفعيل App Engine
• المعرفة العملية بأوامر نظام التشغيل Linux الشائعة
• معرفة أساسية بتطوير ونشر تطبيقات App Engine
• تطبيق Java 8 serlet الذي ترغب في نقله إلى Java 17 ونشره في Cloud Run (يمكن أن يكون تطبيقًا على App Engine أو أن يكون مصدرًا فقط)

استطلاع

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

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

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

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

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

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

2. الخلفية

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

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

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

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

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

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

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

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

• الانتقال من الخدمات المجمّعة للعثور على خدمات مستقلة مناسبة
• نقل ملفات إعداد XML إلى لغة ترميز YAML: للمستخدمين الذين ينتقلون إلى بيئات تشغيل Java 11/17 مع مواصلة استخدام App Engine

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

FROM eclipse-temurin

ARG JAR_FILE=JAR_FILE_MUST_BE_SPECIFIED_AS_BUILD_ARG

COPY ${JAR_FILE} app.jar

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

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

2**. تشغيل عملية التصميم**

بعد إبلاغ Cloud Build بخطوات الإنشاء المطلوبة، أصبحت مستعدًا للنشر بنقرة واحدة.

نفِّذ الأمر التالي:

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

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

• LOCATION: وهو موقع المستودع الجغرافي الإقليمي أو المتعدّد المناطق.
• ‫PROJECT_ID: رقم تعريف مشروعك على 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:

• إنشاء خطوات إنشاء مخصّصة باستخدام Cloud Build
• إنشاء "عوامل تشغيل الإنشاء" وإدارتها
• استخدام الفحص عند الطلب في مسار Cloud Build

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

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

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

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

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

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

• البحث عن المشاكل
• إرسال مشكلة أو ملاحظات جديدة

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

• خيارات نقل البيانات لإلغاء تجميع خدمات "محرّك التطبيقات"
• إعداد إنشاء عوامل التشغيل في Cloud Build
• مزيد من المعلومات حول نقل البيانات إلى Java 11/17

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

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

App Engine

• مستندات App Engine
• معلومات أسعار والحصص في App Engine
• مقارنة بين المنصات من الجيل الأول والجيل الثاني
• الدعم على المدى الطويل لوقت التشغيل القديم

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

• المستوى "مجاني دائمًا" في Google Cloud
• Google Cloud CLI (gcloud CLI)
• جميع مستندات Google Cloud

الفيديوهات

• محطة نقل البيانات بدون خادم
• الاستكشافات بدون خادم
• الاشتراك في Google Cloud Tech
• الاشتراك في Google Developers

الترخيص

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