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
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، وهي بيئة سطر أوامر تعمل في السحابة الإلكترونية.
يتم تحميل هذا الجهاز الافتراضي المستند إلى Debian بجميع أدوات التطوير التي تحتاج إليها. توفّر هذه الخدمة دليلًا رئيسيًا دائمًا بسعة 5 غيغابايت وتعمل في Google Cloud، ما يؤدي إلى تحسين أداء الشبكة والمصادقة بشكل كبير. وهذا يعني أنّ كل ما تحتاجه لهذا الدرس التطبيقي حول الترميز هو متصفّح (نعم، يمكن استخدامه على جهاز Chromebook).
- لتفعيل Cloud Shell من Cloud Console، ما عليك سوى النقر على تفعيل Cloud Shell
(يستغرق توفير البيئة والاتصال بها بضع لحظات فقط).
بعد الاتصال بـ Cloud Shell، من المفترض أن يظهر لك أنّه تمّت المصادقة عليك وأنّ المشروع تمّ ضبطه مسبقًا على PROJECT_ID.
gcloud auth list
ناتج الأمر
Credentialed accounts: - <myaccount>@<mydomain>.com (active)
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>
- أخيرًا، اضبط المنطقة التلقائية وإعدادات المشروع.
gcloud config set compute/zone us-central1-f
يمكنك اختيار مجموعة متنوعة من المناطق المختلفة. لمزيد من المعلومات، يُرجى الاطّلاع على الأقاليم والمناطق.
3- استنساخ مستودع المصدر
نستخدم تطبيقًا موحّدًا حاليًا لموقع إلكتروني وهمي للتجارة الإلكترونية، مع صفحة ترحيب بسيطة وصفحة منتجات وصفحة سجلّ الطلبات. ما علينا سوى استنساخ المصدر من مستودع git، حتى نتمكّن من التركيز على تقسيمه إلى خدمات مصغّرة ونشره على Google Kubernetes Engine (GKE).
نفِّذ الأوامر التالية لاستنساخ مستودع git إلى مثيل Cloud Shell والانتقال إلى الدليل المناسب. سنثبّت أيضًا التبعيات في NodeJS حتى نتمكّن من اختبار التطبيق المتكامل قبل نشره. قد يستغرق تنفيذ هذا النص البرمجي بضع دقائق.
cd ~ git clone https://github.com/googlecodelabs/monolith-to-microservices.git cd ~/monolith-to-microservices ./setup.sh
سيؤدي ذلك إلى استنساخ مستودع Github الخاص بنا، والانتقال إلى الدليل، وتثبيت التبعيات اللازمة لتشغيل تطبيقنا محليًا. قد يستغرق تنفيذ هذا النص البرمجي بضع دقائق.
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
قد يستغرق إنشاء المجموعة عدة دقائق. بعد اكتمال الأمر، نفِّذ الأمر التالي واطّلِع على مثيلات VM الثلاث الخاصة بعُقد العامل في المجموعة:
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 الأولى.
5- نشر بنية متجانسة حالية
بما أنّ تركيز هذا المختبر هو شرح كيفية تقسيم بنية متجانسة إلى خدمات مصغّرة، علينا تشغيل تطبيق ذي بنية متجانسة. نفِّذ النص البرمجي التالي لنشر تطبيق أحادي البنية إلى مجموعة GKE لأغراض هذا المختبر:
cd ~/monolith-to-microservices ./deploy-monolith.sh
الوصول إلى The 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) للتحقّق مما إذا كان بإمكانك الوصول إلى التطبيق المتكامل.
من المفترض أن تظهر لك صفحة الترحيب الخاصة بالموقع الإلكتروني المتكامل تمامًا كما هو موضّح في الصورة أعلاه. صفحة الترحيب هي صفحة ثابتة سيعرضها تطبيق Frontend المصغّر لاحقًا. أصبح بإمكانك الآن تشغيل تطبيقك المتكامل بالكامل على Kubernetes.
6. نقل الطلبات إلى خدمة مصغّرة
بعد أن أصبح لدينا موقعنا الإلكتروني المتكامل الحالي يعمل على GKE، يمكننا البدء في تقسيم كل خدمة إلى خدمة مصغّرة. عادةً، يجب بذل جهد تخطيطي لتحديد الخدمات التي سيتم تقسيمها إلى أجزاء أصغر، وعادةً ما يكون ذلك حول أجزاء معيّنة من التطبيق، مثل مجال النشاط التجاري. لأغراض توضيحية، أنشأنا مثالاً بسيطًا وقسّمنا كل خدمة إلى نطاق النشاط التجاري، أي الطلبات والمنتجات وواجهة المستخدم. تمت عملية نقل الرمز البرمجي، وسنركّز على إنشاء الخدمات ونشرها على Google Kubernetes Engine (GKE).
إنشاء خدمة مصغّرة جديدة للطلبات
الخدمة الأولى التي سنفصلها هي خدمة "الطلبات". سنستخدم قاعدة الرموز البرمجية المنفصلة المقدَّمة وننشئ حاوية Docker منفصلة لهذه الخدمة.
إنشاء حاوية Docker باستخدام Google Cloud Build
بما أنّنا نقلنا قاعدة الرموز البرمجية نيابةً عنك، ستكون خطوتنا الأولى هي إنشاء حاوية Docker لخدمة الطلبات باستخدام Google Cloud Build.
في العادة، عليك اتّخاذ خطوتَين تتضمّنان إنشاء حاوية Docker ونقلها إلى سجلّ لتخزين الصورة التي يمكن لخدمة GKE استردادها منه. ولكن يمكننا تسهيل الأمر، إذ يمكننا استخدام Google Cloud Build لإنشاء حاوية Docker ووضع الصورة في Google Cloud Container Registry باستخدام أمر واحد. يتيح لنا ذلك إصدار أمر واحد لإنشاء صورتنا ونقلها إلى سجلّ الحاويات. للاطّلاع على العملية اليدوية لإنشاء ملف 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 Console. انقر على زر القائمة في أعلى يمين الصفحة وانتقِل للأسفل إلى "الأدوات" (Tools) → "Cloud Build" (إنشاء على السحابة الإلكترونية) وانقر على "السجلّ" (History). يمكنك هنا الاطّلاع على قائمة بجميع الإصدارات السابقة، ويجب أن يكون هناك إصدار واحد فقط أنشأته للتو.
إذا نقرت على رقم تعريف الإصدار، يمكنك الاطّلاع على جميع تفاصيل هذا الإصدار، بما في ذلك ناتج السجلّ.
من صفحة تفاصيل الإصدار، يمكنك عرض صورة الحاوية التي تم إنشاؤها من خلال النقر على اسم الصورة في قسم معلومات الإصدار.
نشر الحاوية على GKE
بعد أن أنشأنا حاوية لموقعنا الإلكتروني وأرسلناها إلى "سجلّ حاويات Google"، حان الوقت لنشرها على Kubernetes.
تمثّل Kubernetes التطبيقات على شكل وحدات Pod، وهي وحدات تمثّل حاوية (أو مجموعة من الحاويات المرتبطة بإحكام). Pod هي أصغر وحدة قابلة للنشر في Kubernetes. في هذا البرنامج التعليمي، لا تحتوي كل وحدة Pod إلا على حاوية الخدمات المصغّرة.
لنشر التطبيقات وإدارتها على مجموعة GKE، عليك التواصل مع نظام إدارة مجموعات Kubernetes. يمكنك إجراء ذلك عادةً باستخدام أداة سطر الأوامر kubectl من داخل Cloud Shell.
أولاً، سننشئ مورد Deployment. تتولّى عملية النشر إدارة نُسخ متعددة من تطبيقك، تُعرف باسم النُسخ المتماثلة، وتجدولها ليتم تشغيلها على العُقد الفردية في مجموعتك. في هذه الحالة، لن يتم تشغيل سوى وحدة Pod واحدة من تطبيقك. تضمن عمليات النشر ذلك من خلال إنشاء ReplicaSet. تكون ReplicaSet مسؤولة عن التأكّد من أنّ عدد النسخ المتماثلة المحدّد يعمل دائمًا.
يتسبّب الأمر kubectl create deployment أدناه في أن ينشئ Kubernetes عملية نشر باسم orders على مجموعتك مع نسخة طبق الأصل 1.
نفِّذ الأمر التالي لنشر تطبيقك:
kubectl create deployment orders --image=gcr.io/${GOOGLE_CLOUD_PROJECT}/orders:1.0.0
التحقّق من عملية النشر
للتحقّق من إنشاء عملية النشر بنجاح، شغِّل الأمر التالي. قد يستغرق ظهور حالة الحزمة على أنّها "قيد التشغيل" بضع لحظات:
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، والوحدة التي يتم تشغيلها. يبدو أنّه تم إنشاء كل شيء بنجاح.
عرض حاوية GKE
لقد نشرنا تطبيقنا على GKE، ولكن ليس لدينا طريقة للوصول إليه خارج المجموعة. بشكلٍ تلقائي، لا يمكن الوصول إلى الحاويات التي تشغّلها على GKE من الإنترنت، لأنّها لا تتضمّن عناوين IP خارجية. يجب أن تعرض تطبيقك بشكل واضح لعدد الزيارات من الإنترنت من خلال مورد خدمة. توفّر الخدمة إمكانية الربط بالشبكة وعناوين IP لوحدات Pod في تطبيقك. ينشئ 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. احفظه للخطوة التالية عندما نغيّر نظامنا المتكامل للإشارة إلى خدمة "الطلبات" الجديدة.
إعادة ضبط البنية المتجانسة
بما أنّنا أزلنا خدمة "الطلبات" من البنية المتكاملة، علينا تعديل البنية المتكاملة للإشارة إلى خدمة "الطلبات" الخارجية الجديدة.
عند تقسيم بنية متكاملة، نزيل أجزاء من الرمز البرمجي من قاعدة رموز برمجية واحدة إلى عدة قواعد وننفّذها بشكل منفصل. بما أنّ الخدمة المصغّرة تعمل على خادم مختلف، لم يعُد بإمكاننا الإشارة إلى عناوين URL الخاصة بالخدمة كمسارات مطلقة، بل نحتاج إلى توجيهها إلى عنوان الخادم الجديد الخاص بخدمة الطلبات المصغّرة. يُرجى العِلم أنّ ذلك سيتطلّب بعض التوقف عن العمل في الخدمة المتكاملة لتعديل عنوان URL لكل خدمة تم فصلها. يجب أخذ ذلك في الاعتبار عند التخطيط لنقل الخدمات المصغّرة والتطبيقات المتكاملة إلى مرحلة الإنتاج أثناء عملية نقل الخدمات المصغّرة.
علينا تعديل ملف الإعداد في نظامنا المتكامل للإشارة إلى عنوان IP الجديد لخدمات الطلبات المصغّرة. استخدِم برنامج nano editor لاستبدال عنوان URL المحلي بعنوان IP الخاص بخدمة Orders المصغّرة الجديدة. نفِّذ الأمر التالي لتعديل
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 الخاص بخدمة Orders المصغّرة ليتطابق مع ما يلي:
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 Build
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
يمكنك التأكّد من أنّ تطبيقك يستهدف الآن خدمة Orders المصغّرة الجديدة من خلال الانتقال إلى تطبيق monolith في المتصفّح ثم إلى صفحة Orders. يجب أن تنتهي جميع معرّفات الطلبات باللاحقة -MICROSERVICE كما هو موضّح أدناه:
7. نقل المنتجات إلى الخدمات المصغّرة
Create New Products Microservice
يمكننا مواصلة تقسيم خدماتنا من خلال نقل خدمة "المنتجات" أولاً. سنتبع العملية نفسها كما في الخطوة السابقة. شغِّل الأوامر التالية لإنشاء حاوية Docker ونشرها وإتاحتها من خلال خدمة Kubernetes.
إنشاء حاوية Docker باستخدام Google Cloud Build
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 للخطوة التالية عندما نعيد ضبط البنية المتكاملة لتشير إلى خدمة Products المصغّرة الجديدة.
إعادة ضبط البنية المتجانسة
استخدِم محرر 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 الخاص بخدمة Product المصغّرة ليتطابق مع ما يلي:
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 من خدمة Products المصغّرة.
بعد ذلك، علينا إعادة إنشاء الواجهة الأمامية المتكاملة وتكرار عملية الإنشاء لإنشاء الحاوية الخاصة بها وإعادة نشرها في مجموعة GKE. نفِّذ الأوامر التالية لإكمال هذه الخطوات:
إعادة إنشاء ملفات إعداد Monolith
npm run build:monolith
إنشاء حاوية Docker باستخدام Google Cloud Build
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
يمكنك التأكّد من أنّ تطبيقك يستهدف الآن خدمة Products المصغّرة الجديدة من خلال الانتقال إلى تطبيق monolith في المتصفّح ثم إلى صفحة Products. يجب أن تكون جميع أسماء المنتجات مسبوقة بـ MS- كما هو موضّح أدناه:
8. نقل الواجهة الأمامية إلى خدمة مصغّرة
الخطوة الأخيرة في عملية نقل البيانات هي نقل رمز الواجهة الأمامية إلى خدمة مصغّرة وإيقاف البنية المتكاملة. بعد إكمال هذه الخطوة، سنكون قد نقلنا بنجاح تطبيقنا المتكامل إلى بنية الخدمات المصغّرة.
إنشاء خدمة مصغّرة جديدة للواجهة الأمامية
لنتبع الإجراء نفسه كما في الخطوتَين الأخيرتَين لإنشاء خدمة مصغّرة جديدة للواجهة الأمامية.
في السابق، عندما أعدنا بناء نظامنا المتكامل، عدّلنا الإعدادات لتشير إلى النظام المتكامل، ولكن الآن علينا استخدام الإعدادات نفسها لخدمة Frontend المصغّرة. نفِّذ الأوامر التالية لنسخ ملفات إعداد عناوين URL الخاصة بالخدمات المصغّرة إلى قاعدة رموز الخدمة المصغّرة للواجهة الأمامية:
cd ~/monolith-to-microservices/react-app cp .env.monolith .env npm run build
بعد إكمال ذلك، سنتبع العملية نفسها كما في الخطوات السابقة. شغِّل الأوامر التالية لإنشاء حاوية Docker ونشرها وإتاحتها من خلال خدمة Kubernetes.
إنشاء حاوية Docker باستخدام Google Cloud Build
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
Delete The Monolith
بعد أن أصبحت جميع خدماتنا تعمل كخدمات مصغّرة، يمكننا حذف تطبيقنا المتكامل. يُرجى العِلم أنّه في عملية نقل البيانات الفعلية، سيستلزم ذلك أيضًا إجراء تغييرات على نظام أسماء النطاقات وغير ذلك من أجل توجيه أسماء النطاقات الحالية إلى الخدمات المصغّرة الجديدة للواجهة الأمامية لتطبيقنا. نفِّذ الأوامر التالية لحذف التطبيق المتكامل:
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 الخارجي لخدمة Frontend المصغّرة، انسخ عنوان IP. انتقِل بمتصفّحك إلى عنوان URL هذا (مثل http://203.0.113.0) للتحقّق مما إذا كان بإمكانك الوصول إلى الواجهة الأمامية. يجب أن يكون موقعك الإلكتروني كما كان قبل تقسيم البنية المتكاملة إلى خدمات مصغّرة.
9- تنظيف
بعد الانتهاء، أسهل طريقة لتنظيف جميع الأنشطة التي تم تنفيذها هي حذف المشروع. يؤدي حذف المشروع إلى حذف جميع الموارد التي تم إنشاؤها في هذا الدرس التطبيقي حول الترميز لضمان عدم حدوث أي رسوم متكررة غير متوقعة. نفِّذ ما يلي في Cloud Shell، حيث يكون PROJECT_ID هو رقم تعريف المشروع الكامل وليس اسم المشروع فقط.
gcloud projects delete [PROJECT_ID]
أكِّد الحذف من خلال إدخال الحرف "Y" عندما يُطلب منك ذلك.
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