نقل موقع إلكتروني متجانس إلى خدمات مصغّرة على Google Kubernetes Engine

1. مقدمة

ما سبب الانتقال من تطبيق متجانس إلى بنية خدمات مصغّرة؟ يؤدي تقسيم التطبيق إلى خدمات مصغّرة إلى المزايا التالية: ينبع معظمها من حقيقة أن الخدمات الدقيقة تكون مقترنة بشكل غير محكم.

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

في ما يلي بعض العيوب عند مقارنتها بألواح متجانسة:

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

في هذا التمرين المعملي، سنشغِّل خدمات مصغّرة في Google Kubernetes Engine (GKE). Kubernetes هي منصة لإدارة الحاويات واستضافتها وتوسيع نطاقها ونشرها. إنّ الحاويات هي وسيلة متنقلة للتغليف وتشغيل الرموز البرمجية. وهي تناسب نمط الخدمات المصغَّرة بشكل جيد، حيث يمكن تشغيل كل خدمة مصغّرة في حاويتها الخاصة.

في هذا التمرين المعملي، سننشر تطبيقًا متجانسًا حاليًا في مجموعة Google Kubernetes Engine، ثم نقسّمه إلى خدمات مصغّرة.

ملاحظة

لمزيد من المعلومات، يُرجى الاطّلاع على الروابط أدناه:

نقل البيانات المجمّعة إلى خدمات مصغّرة (المقالة الكاملة)

أفضل الممارسات المتعلقة بالخدمات المصغّرة

مخطّط بنية لخدماتنا المصغّرة

سنبدأ بتقسيم منصة واحدة إلى ثلاث خدمات مصغّرة، خدمة واحدة في كل مرة. تشمل الخدمات المصغّرة والطلبات والمنتجات والواجهة الأمامية. ننشئ صورة Docker لكل خدمة مصغّرة باستخدام Cloud Build، وهي الصورة التي نقدّمها من داخل Cloud Shell. بعد ذلك، سننشر خدماتنا المصغّرة ونعرضها على Google Kubernetes Engine (GKE) باستخدام نوع خدمة Kubernetes LoadBalancer. وسنفعل ذلك لكل خدمة مع إعادة هيكلة هذه الخدمات في الوقت نفسه من منصتنا الأحادية. خلال هذه العملية، سيتم تشغيل كل من الخدمة الأحادية وخدماتنا المصغَّرة حتى النهاية عندما نتمكّن من حذف هذه الصفحة.

ما ستتعرَّف عليه

• كيفية تقسيم مجموعة Monolith إلى خدمات مصغّرة
• كيفية إنشاء مجموعة Google Kubernetes Engine
• كيفية إنشاء صورة Docker
• طريقة نشر صور Docker في Kubernetes

المتطلبات الأساسية

• حساب Google Cloud Platform به إذن وصول إداري لإنشاء مشاريع أو مشروع بدور "مالك المشروع"
• فهم أساسيات Docker وKubernetes

معلومات إضافية

القرّاء

Kubernetes

نقل البيانات المجمّعة إلى خدمات مصغّرة (المقالة الكاملة)

أفضل الممارسات المتعلقة بالخدمات المصغّرة

2. إعداد البيئة

إعداد بيئة ذاتية

إذا لم يكن لديك حساب Google (Gmail أو Google Apps)، يجب عليك إنشاء حساب. سجِّل الدخول إلى وحدة تحكُّم Google Cloud Platform ( console.cloud.google.com) وأنشئ مشروعًا جديدًا:

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

بعد ذلك، عليك تفعيل الفوترة في Developers Console لاستخدام موارد Google Cloud وتفعيل Container Engine API.

لا ينبغي أن يكلفك هذا الدرس التطبيقي أكثر من بضعة دولارات، ولكن قد تزيد التكاليف إذا قررت استخدام المزيد من الموارد أو إذا تركتها قيد التشغيل (راجع قسم "التنظيف" في نهاية هذا المستند). يمكن الاطّلاع على أسعار Google Kubernetes Engine على هذا الرابط.

المستخدمون الجدد في Google Cloud Platform مؤهّلون للحصول على فترة تجريبية مجانية بقيمة 300 دولار أمريكي.

واجهة Google Cloud Shell

يمكن إدارة Google Cloud وKubernetes عن بُعد من الكمبيوتر المحمول، ولكن في هذا الدرس التطبيقي حول الترميز، سنستخدم Google Cloud Shell، وهي بيئة سطر أوامر يتم تشغيلها في السحابة الإلكترونية.

هذا الجهاز الافتراضي المستند إلى نظام دبيان محمل بكل أدوات التطوير التي ستحتاج إليها. وتوفّر هذه الشبكة دليلاً رئيسيًا دائمًا بسعة 5 غيغابايت ويتم تشغيله في Google Cloud، ما يحسّن بشكل كبير من أداء الشبكة والمصادقة. وهذا يعني أنّ كل ما ستحتاجه في هذا الدرس التطبيقي حول الترميز هو متصفّح (نعم، يعمل على جهاز Chromebook).

1. لتفعيل Cloud Shell من Cloud Console، ما عليك سوى النقر على تفعيل Cloud Shell (من المفترَض أن تستغرق عملية الإعداد والاتصال بالبيئة بضع دقائق فقط).

بعد الربط بتطبيق Cloud Shell، من المفترض أن يظهر لك أنّه قد تمت مصادقتك وأنّ المشروع سبق أن تم ضبطه على PROJECT_ID.

gcloud auth list

مخرجات الأمر

Credentialed accounts:
 - <myaccount>@<mydomain>.com (active)

ملاحظة: يتم تثبيت أداة سطر الأوامر gcloud مسبقًا في Cloud Shell وستستمتع بالتأكيد بدعمها لإكمال استخدام علامات التبويب. لمزيد من المعلومات، يُرجى الاطّلاع على نظرة عامة على أداة سطر الأوامر gcloud.

gcloud config list project

مخرجات الأمر

[core]
project = <PROJECT_ID>

إذا لم يتم ضبط المشروع لسبب ما، ما عليك سوى إصدار الأمر التالي:

gcloud config set project <PROJECT_ID>

هل تبحث عن PROJECT_ID؟ تحقَّق من المعرّف الذي استخدمته في خطوات الإعداد أو ابحث عنه في لوحة بيانات Cloud Console:

تضبط Cloud Shell أيضًا بعض متغيرات البيئة تلقائيًا، وهو ما قد يكون مفيدًا عند تشغيل الأوامر المستقبلية.

echo $GOOGLE_CLOUD_PROJECT

مخرجات الأمر

<PROJECT_ID>

2. أخيرًا، قم بتعيين تهيئة المنطقة الافتراضية والمشروع.

gcloud config set compute/zone us-central1-f

يمكنك اختيار مجموعة متنوعة من المناطق المختلفة. لمزيد من المعلومات، راجع المناطق المناطق:

ملاحظة: عند تشغيل gcloud على جهازك الخاص، يستمر الاحتفاظ بإعدادات الضبط على مستوى الجلسات. ولكن في Cloud Shell، عليك ضبط هذا الإعداد لكل جلسة جديدة أو إعادة ربط.

3- مستودع مصدر النسخ

نستخدم تطبيقًا موحّدًا حاليًا لموقع ويب وهمي للتجارة الإلكترونية، مع صفحة ترحيب بسيطة وصفحة منتجات وصفحة إلى سجلّ الطلبات. نحتاج فقط إلى استنساخ المصدر من مستودع git لدينا لنركّز على تقسيمه إلى خدمات مصغّرة ونشره في Google Kubernetes Engine (GKE).

شغِّل الأوامر التالية لاستنساخ git repo لمثيل Cloud Shell والتغيير إلى الدليل المناسب. سنقوم أيضًا بتثبيت تبعيات NodeJS حتى نتمكن من اختبار الوحدة النمطية قبل النشر. قد يستغرق تشغيل هذا النص البرمجي بضع دقائق.

cd ~
git clone https://github.com/googlecodelabs/monolith-to-microservices.git
cd ~/monolith-to-microservices
./setup.sh

سيؤدي ذلك إلى استنساخ مستودع جيت هب الخاص بنا، والتغيير إلى الدليل، وتثبيت التبعيات اللازمة لتشغيل تطبيقنا محليًا. قد يستغرق تشغيل هذا النص البرمجي بضع دقائق.

4. إنشاء مجموعة GKE

بعد أن أصبحت بيئة تطوير العمل لديكم، نحتاج إلى مجموعة Kubernetes لنشر المجموعة المتكاملة وخدماتنا المصغَّرة في النهاية. قبل أن نتمكن من إنشاء مجموعة، نحتاج إلى التأكد من تمكين واجهات برمجة التطبيقات المناسبة. شغِّل الأمر التالي لتفعيل واجهة برمجة تطبيقات الحاويات لنتمكّن من استخدام Google Kubernetes Engine:

gcloud services enable container.googleapis.com

نحن الآن جاهزون لإنشاء مجموعتنا. شغِّل الأمر أدناه لإنشاء مجموعة GKE باسم fancy-cluster من 3 عُقد.

gcloud container clusters create fancy-cluster --num-nodes 3

تحذير

إذا ظهرت لك رسالة خطأ تفيد بعدم تحديد المنطقة/المنطقة، يُرجى الاطّلاع على قسم إعداد البيئة للتأكّد من ضبط منطقة الحوسبة التلقائية.

قد يستغرق إنشاء المجموعة عدّة دقائق. بعد اكتمال الأمر، شغِّل الأمر التالي واطّلِع على مثيلات الأجهزة الافتراضية الثلاث في المجموعة:

gcloud compute instances list

إخراج:

NAME                                          ZONE        MACHINE_TYPE   PREEMPTIBLE  INTERNAL_IP  EXTERNAL_IP    STATUS
gke-fancy-cluster-default-pool-ad92506d-1ng3  us-east4-a  n1-standard-1               10.150.0.7   XX.XX.XX.XX    RUNNING
gke-fancy-cluster-default-pool-ad92506d-4fvq  us-east4-a  n1-standard-1               10.150.0.5   XX.XX.XX.XX    RUNNING
gke-fancy-cluster-default-pool-ad92506d-4zs3  us-east4-a  n1-standard-1               10.150.0.6   XX.XX.XX.XX    RUNNING

يمكنك أيضًا الاطّلاع على مجموعة Kubernetes والمعلومات ذات الصلة في وحدة التحكّم في Google Cloud. انقر على زر القائمة في أعلى يمين الشاشة، وانتقِل للأسفل إلى Kubernetes Engine وانقر على "المجموعات". من المفترض أن تظهر لك المجموعة باسم fancy-cluster.

تهانينا! لقد أنشأت للتوّ أول مجموعة لك على Kubernetes.

ملاحظة

إذا كنت تستخدم مجموعة Google Kubernetes Engine حالية أو إذا أنشأت مجموعة من خلال وحدة تحكّم Google Cloud Platform، عليك تشغيل الأمر التالي لاسترداد بيانات اعتماد المجموعة وإعداد أداة سطر أوامر kubectl معها:

gcloud container clusters get-credentials fancy-cluster

إذا سبق لك إنشاء مجموعة باستخدام الأمر "إنشاء" في القائمة أعلاه، فإن هذه الخطوة ليست ضرورية.

5- نشر مجموعة مترابطة حالية

بما أنّ محور تركيز هذا التمرين المعملي يركِّز على تقسيم منصّة مركّبة إلى خدمات مصغّرة، نحتاج إلى تشغيل تطبيق متجانس. شغِّل النص البرمجي التالي لنشر تطبيق موحّد في مجموعة GKE لأغراض هذا التمرين:

cd ~/monolith-to-microservices
./deploy-monolith.sh

الوصول إلى أغنية Monolith

للعثور على عنوان IP الخارجي للتطبيق الأحادي، شغِّل الأمر التالي:

kubectl get service monolith

ينبغي أن تظهر مُخرجات مشابهة لما يلي:

NAME         CLUSTER-IP      EXTERNAL-IP     PORT(S)          AGE
monolith     10.3.251.122    203.0.113.0     80:30877/TCP     3d

ملاحظة: يجب توفير جهاز موازنة الحمل وعنوان IP خارجي لإجراء ذلك، لذا سيستغرق تنفيذ هذه العملية بعض الوقت. إذا كان عنوان IP الخارجي يشير إلى

<pending> يُرجى الانتظار بضع دقائق وإعادة المحاولة.

بعد تحديد عنوان IP الخارجي للجهاز الأحادي، انسخ عنوان IP. وجِّه المتصفح إلى عنوان URL هذا (مثل http://203.0.113.0) لمعرفة ما إذا كان يمكن الوصول إلى الصفحة الأحادية أم لا.

ملاحظة

تذكر عنوان IP هذا لأنك ستستمر في استخدامه من الآن فصاعدًا. ويمكنك متى شئت العثور عليه مجددًا باستخدام الأمر نفسه.

يُفترض أن ترى صفحة الترحيب لموقع الويب المتجانس تمامًا مثل الصورة أعلاه. صفحة الترحيب هي صفحة ثابتة سيتم عرضها بواسطة خدمة Frontend المصغّرة لاحقًا. لديك الآن العمل الفني الكامل على Kubernetes.

6- نقل الطلبات إلى الخدمة الصغيرة

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

إنشاء خدمة مصغّرة لطلبات جديدة

أول خدمة سنفصلها هي خدمة الطلبات. سنستخدم قاعدة الرموز المنفصلة المتوفرة وسننشئ حاوية Docker منفصلة لهذه الخدمة.

إنشاء حاوية Docker باستخدام إصدار Google Cloud

بما أننا قد نقلنا قاعدة الرموز نيابةً عنك، ستكون خطوتنا الأولى هي إنشاء حاوية Docker لخدمة "الطلب" باستخدام Google Cloud Build.

عادةً ما يتعين عليك اتخاذ نهج من خطوتين يترتب على إنشاء حاوية Docker وإرسالها إلى قاعدة بيانات المسجّلين لتخزين الصورة كي يتمكّن GKE من سحبها. يمكننا تنفيذ المهام بسهولة أكبر، فيمكننا استخدام Google Cloud Build لإنشاء حاوية Docker ووضع الصورة في سجلّ حاويات Google Cloud باستخدام أمر واحد. يتيح لنا ذلك إصدار أمر واحد لإنشاء صورتنا ونقلها إلى سجلّ الحاوية. لعرض العملية اليدوية لإنشاء ملف Docker وإرساله، يمكنك الانتقال إلى هنا.

ستضغط خدمة Google Cloud Build الملفات من الدليل وتنقلها إلى حزمة على Google Cloud Storage. ستأخذ عملية الإنشاء بعد ذلك جميع الملفات من الحزمة وتستخدم Dockerfile لتشغيل عملية إنشاء Docker. بما أنّنا حدّدنا العلامة --tag مع المضيف على أنّه gcr.io لصورة Docker، سيتم إرسال صورة Docker الناتجة إلى قاعدة بيانات Google Cloud Container Registry.

شغِّل الأوامر التالية لإنشاء حاوية Docker وانشرها إلى Google Container Registry:

cd ~/monolith-to-microservices/microservices/src/orders
gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/orders:1.0.0 .

ستستغرق هذه العملية بضع دقائق، ولكن بعد اكتمالها، ستظهر لك إخراجات في الوحدة الطرفية تشبه ما يلي:

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
ID                                    CREATE_TIME                DURATION  SOURCE                                                                                  IMAGES                              STATUS
1ae295d9-63cb-482c-959b-bc52e9644d53  2019-08-29T01:56:35+00:00  33S       gs://<PROJECT_ID>_cloudbuild/source/1567043793.94-abfd382011724422bf49af1558b894aa.tgz  gcr.io/<PROJECT_ID>/orders:1.0.0  SUCCESS

للاطّلاع على سجلّ الإصدارات أو مشاهدة العملية في الوقت الفعلي، يمكنك الانتقال إلى "وحدة تحكُّم Google Cloud". انقر على زر القائمة في أعلى يمين الشاشة وانتقِل للأسفل إلى "الأدوات" ← Cloud Build (إنشاء السحابة الإلكترونية)، ثم انقر على "السجلّ". يمكنكم هنا الاطّلاع على قائمة بجميع الإصدارات السابقة، ولكن يجب أن يكون هناك إصدار واحد فقط قد أنشأته للتو.

إذا نقرت على معرّف الإصدار، يمكنك الاطّلاع على جميع تفاصيل هذا الإصدار، بما في ذلك ناتج السجلّ.

من صفحة تفاصيل الإصدار، يمكنك الاطّلاع على صورة الحاوية التي تمّ إنشاؤها عن طريق النقر على اسم الصورة في قسم معلومات الإصدار.

نشر الحاوية إلى GKE

بعد أن نقلنا حاويتنا إلى حاويات من Google Container Registry، حان وقت النشر في Kubernetes.

يُمثِّل Kubernetes التطبيقات على أنّها Pods، وهي وحدات تمثّل حاوية (أو مجموعة من الحاويات ذات الاقتران بإحكام). وهي أصغر وحدة قابلة للنشر في Kubernetes. في هذا الدليل التوجيهي، تحتوي كل مجموعة على حاوية الخدمات المصغَّرة فقط.

لنشر التطبيقات وإدارتها على مجموعة GKE، يجب الاتصال بنظام إدارة مجموعات Kubernetes. يمكنك إجراء ذلك عادةً باستخدام أداة سطر الأوامر kubectl من داخل Cloud Shell.

سننشئ أولاً مورد النشر. تدير عملية النشر نسخًا متعددة من تطبيقك تسمى النسخ المكررة، وتحدد موعدًا لتشغيلها على العُقد الفردية في المجموعة. في هذه الحالة، سيتم تشغيل مجموعة واحدة فقط من تطبيقك في عملية النشر. تضمن عمليات النشر ذلك عن طريق إنشاء ReplicaSet. مجموعة ReplicaSet مسؤولة عن التأكد من تشغيل عدد النسخ المتماثلة المحددة دائمًا.

يؤدي الأمر kubectl create deployment أدناه إلى إنشاء Kubernetes لعملية نشر باسم orders على مجموعتك مع نسخة مطابقة 1.

شغّل الأمر التالي لنشر التطبيق:

kubectl create deployment orders --image=gcr.io/${GOOGLE_CLOUD_PROJECT}/orders:1.0.0

ملاحظة

من بين أفضل الممارسات، ننصحك باستخدام ملف YAML للإعلان عن التغيير الذي أجريته على مجموعة Kubernetes (على سبيل المثال، إنشاء عملية نشر أو خدمة أو تعديلها) ونظام التحكّم في المصدر مثل مستودعات GitHub أو Cloud Source لتخزين هذه التغييرات.

اطّلِع على هذه المراجع لمزيد من المعلومات:

عمليات نشر Kubernetes

التحقّق من النشر

للتحقّق من إنشاء عملية النشر بنجاح، شغِّل الأمر التالي، وقد يستغرق تشغيل حالة المجموعة الصغيرة بضع لحظات:

kubectl get all

إخراج:

NAME                            READY   STATUS    RESTARTS   AGE
pod/monolith-779c8d95f5-dxnzl   1/1     Running   0          15h
pod/orders-5bc6969d76-kdxkk     1/1     Running   0          21s
NAME                 TYPE           CLUSTER-IP      EXTERNAL-IP    PORT(S)        AGE
service/kubernetes   ClusterIP      10.39.240.1     <none>         443/TCP        19d
service/monolith     LoadBalancer   10.39.241.130   34.74.209.57   80:30412/TCP   15h
NAME                       READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/monolith   1/1     1            1           15h
deployment.apps/orders     1/1     1            1           21s
NAME                                  DESIRED   CURRENT   READY   AGE
replicaset.apps/monolith-779c8d95f5   1         1         1       15h
replicaset.apps/orders-5bc6969d76     1         1         1       21s

يوضح لنا هذا الناتج عدة أشياء. يمكننا الاطلاع على عملية النشر الحالية، ومجموعة ReplicaSet التي تضم عدد مجموعات اللوحات المطلوبة وهي 1، والمجموعة التجريبية قيد التشغيل. يبدو أنه قد تم إنشاء كل شيء بنجاح.

تلميح مفيد

يمكنك أيضًا الاطّلاع على عمليات نشر Kubernetes عبر وحدة التحكّم إذا انتقلت إلى القائمة في أعلى يمين الشاشة، ثم انتقِل إلى Kubernetes Engine ← Workloads.

إظهار حاوية GKE

لقد نشرنا تطبيقنا على GKE، ولكن لا تتوفّر لدينا طريقة للوصول إليه خارج المجموعة. لا يمكن الوصول إلى الحاويات التي تشغّلها على GKE من الإنترنت بشكل تلقائي، لأنّها لا تتضمّن عناوين IP خارجية. يجب أن تعرض تطبيقك صراحةً للزيارات الواردة من الإنترنت عبر أحد موارد الخدمة. تقدم الخدمة دعمًا للشبكات وبروتوكول IP للوحات تطبيقك. ينشئ GKE عنوان IP خارجيًا وجهاز موازنة الحمل ( يخضع للفوترة) لتطبيقك.

ملاحظة

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

عندما نشرنا خدمة الطلبات الخاصة بنا، استعرضناها على المنفذ 8081 داخليًا من خلال نشر Kubernetes. لعرض هذه الخدمة خارجيًا، نحتاج إلى إنشاء خدمة Kubernetes من النوع LoadBalancer لتوجيه حركة البيانات من المنفذ 80 خارجيًا إلى المنفذ الداخلي 8081 لخدمة الطلبات. شغِّل الأمر التالي لعرض موقعك الإلكتروني على الإنترنت:

kubectl expose deployment orders --type=LoadBalancer --port 80 --target-port 8081

الوصول إلى الخدمة

يعيّن GKE عنوان IP الخارجي لمورد الخدمة، وليس للنشر. إذا أردت معرفة عنوان IP الخارجي الذي وفّره لك GKE في تطبيقك، يمكنك فحص الخدمة باستخدام الأمر kubectl get service:

kubectl get service orders

إخراج:

NAME         CLUSTER-IP      EXTERNAL-IP     PORT(S)          AGE
orders       10.3.251.122    203.0.113.0     80:30877/TCP     3d

بعد تحديد عنوان IP الخارجي لتطبيقك، انسخ عنوان IP. احفظه للخطوة التالية عندما نغير منصتنا الأحادية للإشارة إلى خدمة "الطلبات" الجديدة!

إعادة ضبط Monolith

نظرًا لأننا أزلنا خدمة "الطلبات" (Orders) من الصخرة المنفردة، سيتعين علينا تعديل الصخرة لتوجيهها إلى الخدمة المصغّرة الجديدة للطلبات الخارجية.

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

نحتاج إلى تعديل ملف الإعداد في منصتنا الأحادية للإشارة إلى عنوان IP الجديد للخدمات المصغّرة للطلبات. استخدِم محرِّر النصوص nano لاستبدال عنوان URL المحلي بعنوان IP الخاص بالخدمة المصغّرة الجديدة للطلبات. شغّل الأمر التالي لتعديل

cd ~/monolith-to-microservices/react-app
nano .env.monolith

عندما يفتح المحرر، يُفترض أن يبدو ملفك كما يلي:

REACT_APP_ORDERS_URL=/service/orders
REACT_APP_PRODUCTS_URL=/service/products

استبدِل REACT_APP_ORDERS_URL بالتنسيق الجديد مع استبداله بعنوان IP الخاص بالخدمة المصغّرة في "الطلبات" لكي يتطابق أدناه:

REACT_APP_ORDERS_URL=http://<ORDERS_IP_ADDRESS>/api/orders
REACT_APP_PRODUCTS_URL=/service/products

اضغط على CTRL+O، ثم اضغط على ENTER، ثم اضغط على CTRL+X لحفظ الملف في محرِّر النصوص nano.

يمكنك اختبار خدمتك المصغّرة الجديدة من خلال الانتقال إلى عنوان URL الذي أعددته للتو في هذا الملف. من المفترض أن تعرض صفحة الويب استجابة JSON من الخدمة المصغّرة "الطلبات".

بعد ذلك، سنحتاج إلى إعادة إنشاء الواجهة الأمامية الأحادية وتكرار عملية التصميم لبناء الحاوية المتجانسة وإعادة نشرها في مجموعة GKE. شغّل الأوامر التالية وأكمل هذه الخطوات:

إعادة إنشاء ملفات إعداد Monolith

npm run build:monolith

إنشاء حاوية Docker باستخدام إصدار Google Cloud

cd ~/monolith-to-microservices/monolith
gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:2.0.0 .

نشر الحاوية إلى GKE

kubectl set image deployment/monolith monolith=gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:2.0.0

يمكنك التحقق من وصول تطبيقك الآن إلى الخدمة المصغّرة الجديدة "الطلبات" من خلال الانتقال إلى التطبيق الأساسي في متصفحك والانتقال إلى صفحة "الطلبات". يجب أن تنتهي جميع مُعرّفات الطلب بلاحقة -MICROSERVICE كما هو موضح أدناه:

7. نقل المنتجات إلى الخدمة الصغيرة

إنشاء خدمة مصغّرة لمنتجات جديدة

يمكننا الاستمرار في إبراز خدماتنا من خلال نقل خدمة المنتجات في المرة التالية. سنتبع العملية نفسها التي اتّبعتها في الخطوة السابقة. شغِّل الأوامر التالية لإنشاء حاوية Docker ونشر الحاوية وعرضها من خلال خدمة Kubernetes.

إنشاء حاوية Docker باستخدام إصدار Google Cloud

cd ~/monolith-to-microservices/microservices/src/products
gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/products:1.0.0 .

نشر الحاوية إلى GKE

kubectl create deployment products --image=gcr.io/${GOOGLE_CLOUD_PROJECT}/products:1.0.0

إظهار حاوية GKE

kubectl expose deployment products --type=LoadBalancer --port 80 --target-port 8082

ابحث عن عنوان IP العام لخدمات منتجاتنا بالطريقة نفسها التي تم استخدامها في خدمة الطلبات باستخدام الأمر التالي:

kubectl get service products

إخراج:

NAME         CLUSTER-IP      EXTERNAL-IP     PORT(S)          AGE
products     10.3.251.122    203.0.113.0     80:30877/TCP     3d

احفظ عنوان IP للخطوة التالية عندما نعيد ضبط جهازنا الأحادي للإشارة إلى خدمة "المنتجات" الصغيرة الجديدة.

إعادة ضبط Monolith

استخدِم محرِّر nano لاستبدال عنوان URL المحلي بعنوان IP الخاص بالخدمات المصغَّرة للمنتجات الجديدة:

cd ~/monolith-to-microservices/react-app
nano .env.monolith

عندما يفتح المحرر، يُفترض أن يبدو ملفك كما يلي:

REACT_APP_ORDERS_URL=http://<ORDERS_IP_ADDRESS>/api/orders
REACT_APP_PRODUCTS_URL=/service/products

استبدِل REACT_APP_PRODUCTS_URL بالتنسيق الجديد مع استبداله بعنوان IP الخاص بالخدمة المصغّرة للمنتج ليكون متطابقًا أدناه:

REACT_APP_ORDERS_URL=http://<ORDERS_IP_ADDRESS>/api/orders
REACT_APP_PRODUCTS_URL=http://<PRODUCTS_IP_ADDRESS>/api/products

اضغط على CTRL+O، ثم اضغط على ENTER، ثم اضغط على CTRL+X لحفظ الملف في محرِّر النصوص nano.

يمكنك اختبار خدمتك المصغّرة الجديدة من خلال الانتقال إلى عنوان URL الذي أعددته للتو في هذا الملف. من المفترض أن تعرض صفحة الويب استجابة JSON من خدمة "المنتجات" الصغيرة.

بعد ذلك، سنحتاج إلى إعادة إنشاء الواجهة الأمامية الأحادية وتكرار عملية التصميم لبناء الحاوية المتجانسة وإعادة نشرها في مجموعة GKE. شغّل الأوامر التالية وأكمل هذه الخطوات:

إعادة إنشاء ملفات إعداد Monolith

npm run build:monolith

إنشاء حاوية Docker باستخدام إصدار Google Cloud

cd ~/monolith-to-microservices/monolith
gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:3.0.0 .

نشر الحاوية إلى GKE

kubectl set image deployment/monolith monolith=gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:3.0.0

يمكنك التحقق من وصول تطبيقك الآن إلى خدمة "المنتجات" المصغّرة الجديدة من خلال الانتقال إلى التطبيق الأساسي في متصفحك والانتقال إلى صفحة "المنتجات". يجب أن تبدأ جميع أسماء المنتجات بـ MS- كما هو موضح أدناه:

8. ترحيل الواجهة الأمامية إلى الخدمة المصغَّرة

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

إنشاء خدمة مصغّرة جديدة للواجهة الأمامية

لنتّبع الخطوات نفسها المُتّبعة في آخر خطوتَين لإنشاء خدمة مصغّرة جديدة لواجهة أمامية.

في السابق، عندما أعدنا إنشاء النموذج الأحادي، حدّثنا إعداداتنا للإشارة إلى هذا النموذج الفردي، أمّا الآن نحتاج إلى استخدام الإعدادات نفسها لخدمة الواجهة الأمامية الدقيقة. شغّل الأوامر التالية لنسخ ملفات تهيئة عنوان URL للخدمات المصغّرة إلى قاعدة رموز الخدمة الدقيقة للواجهة الأمامية:

cd ~/monolith-to-microservices/react-app
cp .env.monolith .env
npm run build

بعد اكتمال ذلك، سنتّبع الخطوات نفسها التي اتّبعتها الخطوات السابقة. شغِّل الأوامر التالية لإنشاء حاوية Docker ونشر الحاوية وعرضها من خلال خدمة Kubernetes.

إنشاء حاوية Docker باستخدام إصدار Google Cloud

cd ~/monolith-to-microservices/microservices/src/frontend
gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/frontend:1.0.0 .

نشر الحاوية إلى GKE

kubectl create deployment frontend --image=gcr.io/${GOOGLE_CLOUD_PROJECT}/frontend:1.0.0

إظهار حاوية GKE

kubectl expose deployment frontend --type=LoadBalancer --port 80 --target-port 8080

حذف الصورة الأحادية

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

kubectl delete deployment monolith
kubectl delete service monolith

اختبار عملك

للتأكّد من أنّ كل شيء يعمل، يجب ألا يعمل عنوان IP القديم من الخدمة الأحادية، ومن المفترض أن يستضيف عنوان IP الجديد من خدمة الواجهة الأمامية التطبيق الجديد. للاطّلاع على قائمة بجميع الخدمات وعناوين IP، استخدِم الأمر التالي:

kubectl get services

يجب أن تبدو مخرجاتك مشابهة لما يلي:

NAME         TYPE           CLUSTER-IP      EXTERNAL-IP      PORT(S)        AGE
frontend     LoadBalancer   10.39.246.135   35.227.21.154    80:32663/TCP   12m
kubernetes   ClusterIP      10.39.240.1     <none>           443/TCP        18d
orders       LoadBalancer   10.39.243.42    35.243.173.255   80:32714/TCP   31m
products     LoadBalancer   10.39.250.16    35.243.180.23    80:32335/TCP   21m

بعد تحديد عنوان IP الخارجي للخدمة المصغّرة للواجهة الأمامية، انسخ عنوان IP. وجِّه المتصفح إلى عنوان URL هذا (مثل http://203.0.113.0) للتحقق مما إذا كان يمكن الوصول إلى الواجهة الأمامية. يجب أن يكون موقع الويب الخاص بك مماثلاً لما كان عليه قبل أن نقسم القطعة المجمّعة إلى خدمات مصغّرة!

9. تنظيف

بمجرد الانتهاء من ذلك، فإن أسهل طريقة لتنظيف جميع الأنشطة التي يتم تنفيذها هي حذف المشروع. يؤدي حذف المشروع إلى حذف جميع الموارد التي تم إنشاؤها ضِمن هذا الدرس التطبيقي لضمان عدم تحصيل رسوم متكرّرة غير متوقّعة. نفِّذ ما يلي في Cloud Shell، حيث يكون PROJECT_ID هو رقم تعريف المشروع الكامل وليس اسم المشروع فقط.

gcloud projects delete [PROJECT_ID]

تأكيد الحذف من خلال إدخال "Y" عندما يُطلب منك ذلك.

في حال عدم التأكُّد من رقم تعريف المشروع، يمكن تشغيل gcloud config list | grep project من Cloud Shell للحصول على رقم تعريف المشروع الحالي.

10. تهانينا!

لقد نجحت في تقسيم تطبيقك المتجانس إلى خدمات مصغّرة ونشرته على Google Kubernetes Engine.

الخطوات التالية

يمكنك الاطّلاع على الدروس التطبيقية التالية حول الترميز للحصول على مزيد من المعلومات حول Kubernetes:

• نشر موقعك الإلكتروني وتوسيع نطاقه وتعديله على Google Kubernetes Engine
• إنشاء روبوت Slack باستخدام Node.js على Kubernetes
• التسليم المستمر إلى Kubernetes باستخدام Spinnaker
• تفعيل تطبيق Java على Kubernetes على Google Kubernetes Engine

موارد إضافية

• Docker - https://docs.docker.com/
• Kubernetes: https://kubernetes.io/docs/home/
• Google Kubernetes Engine (GKE) - https://cloud.google.com/kubernetes-engine/docs/
• Google Cloud Build - https://cloud.google.com/cloud-build/docs/
• Google Container Registry - https://cloud.google.com/container-registry/docs/
• نقل البيانات المجمّعة إلى خدمات مصغّرة - https://cloud.google.com/solutions/migrating-a-monolithic-app-to-microservices-gke