شراء حساب جوجل كلاود: إنشاء مثيل لنشر Docker اعتمادًا على GCP Artifact Registry وGKE

لقد عانى معظم الأصدقاء الذين لعبوا السحابة الأصلية وقذفوا K8s من ألم "توزيع مرآة الحاويات" و "نشر الكتلة".

عادة ما تكون عملية البناء الذاتي التقليدية على النحو التالي: بعد كتابة الكود محليًا ، قم بتعبئته في صورة مرآة لـ Docker ، ثم دفعه إلى Harbor أو Docker Hub خاص مفتوح المصدر. بعد ذلك ، عليك الحفاظ على قسيمة السحب الخاصة بعقدة K8s بنفسك. بمجرد انتهاء صلاحية الشهادة ، ستبلغ مجموعة GKE (محرك Google Kubernetes) عن الجنون

ImagePullBackOff

خطأ سحري (فشل سحب المرآة). ناهيك عن أن مستودع المرآة ومجموعة الحوسبة ليسا في نفس غرفة الكمبيوتر ، عند سحب عدة غيغابايت من صور المرآة الكبيرة عبر المنطقة ، فإن رسوم تدفق الشبكة العامة المرتفعة وبطء تأخير السحب المجنون.

في المنظومة الحديثة لجوجل كلاود (GCP)، توجد مجموعة فضية مرجعية على مستوى المؤسسات، تُعدّ بمثابة نموذج يُدرَّس في الكتب المدرسية:

استخدم Artifact Registry لإدارة موارد الحاويات، بالتكامل مع GKE لتنفيذ جدولة تلقائية بالكامل لتوجيه الحاويات.

تكمن قمّة كلاهما في عدم القابلية للهزيمة

التكامل الطبيعي للصلاحيات على المستوى الأساسي (استنادًا إلى نظام إدارة الهوية والأذونات-IAM)

. لا تحتاج إلى إعداد أي أسرار K8s معقّدة؛ إذ يمكن لعقد GKE، بعرض نطاق داخلي آمن فائق السرعة، سحب الصور في غضون ثوانٍ وإكمال التحديثات المتدرجة.

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

المرحلة الأولى: التفكيك العميق ، التسليم السحابي الأصلي "نموذج العالم ثلاثي الأبعاد"

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

محطة الحاويات: مكتبة المنتجات الخاصة من الجيل الجديد من GCP (التي تحل محل GCR القديمة بالكامل). يُعنى بتخزين إصدارات صور Docker التي قمت بحزمها، كما يضمّ ميزة فحص الثغرات الأمنية على مستوى الشركات التقنية الكبرى مثل جوجل.

محرك الحوسبة (مجموعة GKE): خدمة K8s التي تستضيفها Google. لا تحتاج إلى إدارة عقدة Master السفلية ، فأنت تحتاج فقط إلى إخباره من خلال ملف YAML المعلن: "أريد تشغيل 3 نسخ من حاوية الويب" ، وسوف يساعدك تلقائيًا في الحفاظ على الاستقرار في الخلفية.

بوابة الأمان (دور IAM): هذا هو المفتاح لتمكين الربط دون استخدام مفاتيح. سنربط عقدة GKE بتعريف خدمة محدد (Service Account)، مما يمنحها افتراضيًا صلاحيات قراءة الصور من سجل الوحدات البرمجية (Artifact Registry).

المرحلة الثانية: الإعداد البيئي-فتح أراضي البنية التحتية على GCP

يرجى التأكد من أنك قمت بتثبيته وتهيئته محليًا

حسنًا

جي كلاود

واجهة سطر الأوامر (أداة سطر أوامر جوجل كلاود) ومحرّك دوكر.

1. تفعيل واجهة برمجة التطبيقات الأساسية (الخطوة الأولى في الاستكشاف)

أطرق هذا السطر من الأوامر في المحطة الطرفية لتنشيط جميع محركات Google Cloud الأساسية التي نستخدمها:

باش

Gcloud services enabl artifactregistry.googleapis.com e container.googleapis.com

2. إنشاء مستودع مرآة خاص

نحن في منطقة تايوان الصينية (

آسيا-شرق1

، تأخير الوصول المحلي منخفض للغاية) قم ببناء مستودع Docker الحصري ، يفترض أن يسمى معرف المشروع

مشروع بلدي-gke-

:

باش

Gcloud-repo \

--تنسيق-المستودع=دوكير

--الموقع=آسيا-شرق1

-- Description = "GKE Production Images Repository"

3. إنشاء مجموعة عقدة GKE مُدارة (في وضع Autopilot)

بالنسبة للشركات الصغيرة والمتوسطة أو الفرق التي لا تريد أن تتعرض للتعذيب بسبب التعديل المعقد لـ K8s ،

يوصى بشدة باختيار وضع Autopilot (الطيار الآلي)

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

باش

Create-auto prod-gke-cluster \

-- = Asia-east1 الموقع

(يستغرق إنشاء مجموعة حوالي 3 ~ 5 دقائق، اشرب فنجان قهوة وانتظر بصبر.

المرحلة الثالثة: التمرين القتالي الفعلي 1-"الحاوية" للرمز المحلي والدفع إلى السحابة

لنفترض أن لديك تطبيق ويب بسيطاً للغاية على جهازك المحلي (سواء كان مكتوباً بلغة Node.js أو Python)، وهو يستمع محلياً إلى

8080

المنفذ.

1-إعداد Dockerfile من فئة الإنتاج الصلب

تحت جذر المشروع ، قم بإنشاء واحدة جديدة

دوكيرفيل

:

دوكيرفيل

# استخدام المرآة الأساسية الرسمية خفيفة الوزن

من أوبونتو:3.18

# تثبيت تبعية وقت التشغيل (خذ Python كمثال)

RUN apk add -- no-cache python3 py3-pip

WORKDIR /app

CO

PY. /تطبيق

# منافذ الأعمال المكشوفة

كشف المنفذ 8080

# إطلاق خدمات الويب

CMD ["python3" ، "-m" ، "http.server" ، "8080"]

2. ربط المفتاح السري: تهيئة مصادقة الهوية بين Docker المحلي وخدمة Google Cloud Platform (GCP)

سيدفع الكثير من الناس التدفق هنا للإبلاغ عن الأخطاء ، لأن Docker لا يعرف مستودع GCP بشكل افتراضي. نحن بحاجة إلى جعل

جي كلاود

حقن بيانات الاعتماد الآمنة مباشرة في ملف Docker المحلي:

باش

Gcloud auth configure-docker asia-east1-docker.pkg.dev

3. تجميع ووضع العلامات ودفع التدفق بقوة

وفقًا للمعايير القياسية لـ Artifact Registry، قم بإعطاء الصورة اسمًا معياريًا يحتوي على مسار سحابي، ثم ارفعها إلى السجل:

باش

# تجميع معبأة في الإصدار v1.0

docker build -t asia-east1-docker.pkg.dev/my-gke-project/gke-repo/my-web-app:v1.0.

# بذل أقصى الجهود لنقل التدفّق إلى السحابة

Docker push asia-east1-docker.pkg.dev/my-gke-project/gke-repo/my-ويب-app:v1.0

بعد الانتهاء من شريط التقدم ، ادخل إلى صفحة سجل Artifact لوحدة تحكم GCP ، وستجد أن الصورة المرآتية مستلقية بثبات على السحابة ، وقد قامت Google تلقائيًا بمسحها بحثًا عن ثغرات في نظام التشغيل في الخلفية.

المرحلة الرابعة: التدريب العملي الثاني-نشر كلاستر GKE باستخدام YAML الإعلاني

تم ترحيل الصورة إلى السحابة، فكيف نجعل GKE يسحبها ويُنشئ منها حاوية (Pod) قادرة فعليًا على تقديم الخدمة؟ في عالم كُوبرنيتِس، لا نكتب أوامر عبر الطرفية، بل نكتب

ملف تكوين YAML

.

اتصل محليًا بمجموعة GKE التي تم بناؤها للتو للحصول على شهادة المصادقة:

باش

Gcluster container get-credentials prod-gke-cluster-الموقع = asia-east1

اسم جديد في المنطقة المحلية

نشر.yaml

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

يانل

إصدار واجهة برمجة التطبيقات: apps/v1

النوع: النشر

البيانات الوصفية:

الاسم: نشر-تطبيق-ويب

التسميات:

التطبيق: ويب-سي

Rvice

المواصفة:

Replicas: 3 # اللحام مع ارتفاع خط الدفاع المتاح: 3 نسخ من الحاوية الدائمة ، كسر سحب تلقائي واحد جديد

المحدد:

مطابقة التصنيفات:

App: ويب-service

قالب:

البيانات الوصفية:

التسميات:

App: ويب-service

المواصفة:

حاويات:

-اسم: حاوية الويب

# يشير بدقة إلى مسار المرآة الذي دفعته للتو إلى سجل Artifact

Image: asia-east1-docker.pkg.dev/my-gke-project/gke-repo/my-ويب-app:v1.0

Ports:

-ContainerPort: 8080

Resources: # مواصفات الموارد المقيدة بشكل صارم لمنع استنزاف المجموعات بواسطة الرموز المارقة

الحدود:

وحدة المعالجة المركزية: "500 ميغا"

الذاكرة: "512Mi"

طلبات:

وحدة المعالجة المركزية: "200 ميغاهرتز"

Memory: "256Mi"

---

إصدار واجهة برمجة التطبيقات: v1

النوع: خدمة

البيانات الوصفية:

Name: ويب-app-lb-service

المواصفة:

النوع: LoadBalancer # اجعل GKE يطلب تلقائيًا من البنية التحتية لشبكة جوجل عنوان IP عالمي للتفريغ المحمي ضد الهجمات لخدمة تحميل التوازن

المحدد:

App: ويب-service

Ports:

-Protocol: TCP

Port: 80 # منفذ بوابة الشبكة العامة الأمامية

TargetPort: 8080 # يتوافق مع المنفذ الحقيقي داخل الحاوية

قم بتنفيذ أمر نشر بنقرة واحدة في المحطة ، ورمي رسم التصميم هذا إلى GKE:

باش

Kubectl apply -f deployment.yaml

المرحلة الخامسة: لحظة مشاهدة المعجزة-التحقق عبر الإنترنت وتمارين الانهيار

بعد النشر ، نستخدم "أوامر عين السماء" الخاصة بـ K8s للتحديق في ولادة البنية التحتية:

باش

Kubectl get p

Ods

سترى 3 خضراء تضيء على الشاشة

Running

حالة Pod.

النقطة المهمة هنا: في هذه العملية ، لم يكن لدينا أي صورة مرتجعة (ImagePullSecret). تعتمد GKE على أذونات IAM الأصلية لسحب الصورة الخاصة في السجل الفني بأمان!

بعد ذلك ، تحقق من بوابة الشبكة الخارجية لموازنة تحميل الشبكة العامة التي خصصتها لنا Google:

باش

Kubectl get service service-app-lb-service

سوف ترى

EXTERNAL-IP

ظهر عنوان IP ثابت لشبكة عامة تشبه الذهب في العمود (مثل

34-120-x

). اكتب عنوان IP هذا في المتصفح ، وافتح صفحة الويب في ثوانٍ ، وأصبحت خدمة الويب السحابية الأصلية مشهورة رسميًا!

"تمرين الذوبان المادي" لمحاكاة بيئة الإنتاج

من أجل تجربة قدرة GKE على الشفاء الذاتي ، ذهبنا عمداً إلى الخلفية للتدمير. قم بحذف إحدى الحاويات (Pod) التي تعمل يدويًا:

باش

Kubectl delete pod ويب-app-deployment-xxxxx-xxxx

في اللحظة التي تم حذفها ، ذهبت لتحديث صفحة الويب والموقع مرة أخرى

لا يوجد أي كارتون أو انقطاع على الإطلاق

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

Kubectl get pods

في ذلك الوقت ، ستجد أن بود جديد تمامًا قد تم سحبه تلقائيًا في غضون ثوانٍ ودخل في حالة صحية. هذه هي القوة الرابحة لـ GKE للحفاظ على ReplicaSet تلقائيًا.

المرحلة السادسة: تاريخ تجنب الدماء والدموع للأعمال السحابية متعددة الجنسيات

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

1. لا تستخدم أبدا

Latest

العلامات (مصدر كل الشرور في إدارة الإصدار)

العديد من الفرق لديها خطط لتوفير المتاعب ، وفي كل مرة يتم فيها تجميع الصورة محليًا

My-ويب-app:latest

يتم دفع علامة التبويب. كما كتب في YAML

Image:. ..: Latest

.

حدثت كارثة: عندما يظهر الرمز عبر الإنترنت Bug ويحتاج إلى التراجع على وجه السرعة ، ستجد أن جميع إصدارات التاريخ قد تم غسلها بواسطة latest. علاوة على ذلك ، تحتوي الطبقة السفلية من K8s على آلية ذاكرة التخزين المؤقت المرآة. إذا وجدت أن هناك بالفعل صورة معكوسة في المنطقة المحلية ، حتى لو دفعت رمزًا جديدًا ، فقد تكون كسولًا لإعادة استخدام المرآة المحلية القديمة مباشرة ، مما يتسبب في عدم إصدار الإصدار الجديد على الإطلاق.

الحل القياسي لـ Dachang: قطع استخدام Latest بحزم. في كل مرة تدفع فيها ، يجب عليك استخدام رقم إصدار دلالي (مثل v1.0 ، v1.1) ، أو

استخدم معرف Git الخاص بك مباشرة. عند إصدار الإصدار الجديد ، قم بتعديل رقم الإصدار في YAML للسماح لـ GKE بإجراء تحديث متجدد مثالي (تحديث التمرير) لتحقيق إصدار بدون توقف للأعمال.

2. الكسر التلقائي (إدارة دورة الحياة)

إذا قام فريق التطوير بتكوين خط تجميع أوتوماتيكي CI/CD (مثل GitHub Actions و GitLab CI) ، فسيقوم كل دمج للرمز تلقائيًا بإنشاء نسخة من عدة غيغابايت لحشو التسجيل الفني. إذا تجاهلت ذلك ، في غضون بضعة أشهر ، سيتم تجميع الآلاف من الصور التاريخية الميتة في المستودع ، ويمكن أن تؤذي فاتورة التخزين السحابية من Google في نهاية الشهر المدير بشكل مباشر.

العمليات الصعبة لتوفير المال: في إعداد مستودع التسجيل الفني ، افتح "سياسات التنظيف".

قاعدة المسح التلقائي للأصول الباردة: قم بتكوين قاعدة: "بالنسبة للمرايا الوسيطة المؤقتة بدون أي علامات (بدون علامات) ، طالما تم إتلافها فعليًا في أكثر من 7 أيام" ؛ أو "بالنسبة للنسخ المتطابق مع علامات الإصدار ، يتم الاحتفاظ فقط بأحدث 20 إصدارًا ، مسح تلقائي قديم". يمكن أن يساعد السماح للنظام بالخروج تلقائيًا في توفير رسوم التخزين الخاملة المرتفعة للأصول السحابية للشركة.

الخلاصة

استنادًا إلى سجل GCP Artifact و GKE لبناء أمثلة النشر السحابية الأصلية ، يكمن جوهر المستوى الصناعي الأساسي في الواقع في ستة عشر كلمة:

نسخة المرآة مقفلة ، لا يوجد تدفق آمن وسحب ، نسخة بيان الحفاظ على الاستقرار ، يتم تنظيف المستودع تلقائيًا

.

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

gcloud services enable container.googleapis.com artifactregistry.googleapis.com

2. إنشاء مستودع صور خاص (Artifact Registry)

نحن في منطقة تايوان الصينية (

آسيا-شرق1

،مع زمن انتقال منخفض للغاية للوصول الداخلي) أنشئ مستودعًا مخصصًا لدوكير، ولنفترض أن معرّف المشروع يُسمى

مشروع-جي-كي-إي-الخاص-بي

:

باش

gcloud artifacts repositories create gke-repo

--تنسيق-المستودع=دوكير

--الموقع=آسيا-شرق1

-Descri

Ption = "GKE Production Images Repository"

3. إنشاء مجموعة عقدة GKE مُدارة (في وضع Autopilot)

بالنسبة للشركات الصغيرة والمتوسطة أو الفرق التي لا ترغب في المعاناة من تعقيدات التحسين الدقيق لمنصة كوبيرنيتس،

يوصى بشدة باختيار وضع Autopilot (الطيار الآلي)

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

باش

gcloud container clusters create-auto prod-gke-cluster \

--الموقع=آسيا-شرق1

(يستغرق إنشاء المجموعة حوالي 3~ 5 دقائق، اشرب فنجان قهوة وانتظر بصبر.

المرحلة الثالثة: التدريب العملي الأول – تحويط الكود المحلي ورفعه إلى السحابة

لنفترض أن لديك تطبيق ويب بسيطاً للغاية على جهازك المحلي (سواء كان مكتوباً بلغة Node.js أو Python)، وهو يستمع محلياً إلى

٨٠٨٠

المنفذ.

1. إعداد Dockerfile احترافي وجاهز للإنتاج

في الدليل الجذر للمشروع، أنشئ ملفًا جديدًا

دوكيرفيل

:

# استخدام الصورة الأساسية الرسمية خفيفة الوزن

من أوبونتو:3.18

# تثبيت اعتمادات وقت التشغيل (على سبيل المثال، باستخدام بايثون)

قم بتشغيل apk add --no-cache python3 py3-pip

دليل العمل /app

COPY. /تطبيق

# منافذ الأعمال المكشوفة

كشف المنفذ 8080

# إطلاق خدمات الويب

CMD ["python3", "-m", "http.server", "8080"]

2. ربط المفتاح السري: تهيئة مصادقة الهوية بين Docker المحلي وخدمة Google Cloud Platform (GCP)

يتعرض كثيرون لظهور أخطاء عند بثّ البيانات هنا، لأن Docker لا يتعرّف افتراضيًا على مستودعات GCP. نحن بحاجة إلى أن نجعل

جي كلاود

قم بإدراج بيانات اعتماد الأمان مباشرةً في ملف تكوين Docker المحلي:

باش

gcloud auth configure-docker asia-east1-docker.pkg.dev

3. تجميع ووضع العلامات ودفع التدفق بقوة

وفقًا للمعايير القياسية لـ Artifact Registry، قم بإعطاء الصورة اسمًا معياريًا يحتوي على مسار سحابي، ثم ارفعها إلى السجل:

باش

# تجميع وحزم المشروع ليصبح بالإصدار v1.0

Docker build -t asia-east1-docker.pkg.dev/my-gke-project/gke-repo/my-web-app:

V1.0.

# بذل أقصى الجهود لنقل التدفّق إلى السحابة

Docker push asia-east1-docker.pkg.dev/my-gke-project/gke-repo/my-ويب-app:v1.0

بعد الانتهاء من شريط التقدم ، ادخل إلى صفحة سجل Artifact لوحدة تحكم GCP ، وستجد أن الصورة المرآتية مستلقية بثبات على السحابة ، وقد قامت Google تلقائيًا بمسحها بحثًا عن ثغرات في نظام التشغيل في الخلفية.

المرحلة الرابعة: التدريب العملي الثاني-نشر كلاستر GKE باستخدام YAML الإعلاني

تم ترحيل الصورة إلى السحابة، فكيف نجعل GKE يسحبها ويُنشئ منها حاوية (Pod) قادرة فعليًا على تقديم الخدمة؟ في عالم كُوبرنيتِس، لا نكتب أوامر عبر الطرفية، بل نكتب

ملف تكوين YAML

.

اتصل محليًا بمجموعة GKE التي تم بناؤها للتو للحصول على شهادة المصادقة:

باش

Gcluster container get-credentials prod-gke-cluster-الموقع = asia-east1

اسم جديد في المنطقة المحلية

نشر.yaml

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

يانل

إصدار واجهة برمجة التطبيقات: apps/v1

النوع: النشر

البيانات الوصفية:

الاسم: نشر-تطبيق-ويب

التسميات:

التطبيق: خدمة الويب

المواصفة:

النسخ: 3 # إعداد خط الدفاع عالي التوافر بشكل دائم: يُبقي 3 نسخ متماثلة من الحاوية، وفي حال تعطّل أحدها، تُستعاد تلقائيًا نسخة جديدة

المحدد:

مطابقة التصنيفات:

التطبيق: خدمة الويب

قالب:

البيانات الوصفية:

التسميات:

التطبيق: خدمة الويب

المواصفة:

حاويات:

-اسم: حاوية الويب

# توجّه بدقة إلى مسار الصورة الذي قمت بإرساله للتو إلى Artifact Registry

صورة: asia-east1-docker.pkg.dev/my-gke-project/gke-repo/my-web-app:v1.0

الرياضة:

-منفذ الحاوية: 8080

Resources: # مواصفات الموارد المقيدة بشكل صارم لمنع الضغط عليها من قبل الرموز المارقة

الكتلة الجافة

الحدود:

وحدة المعالجة المركزية: "500 ميغا"

الذاكرة: "512Mi"

طلبات:

وحدة المعالجة المركزية: "200 ميغاهرتز"

الذاكرة: "256Mi"

---

إصدار واجهة برمجة التطبيقات: v1

النوع: خدمة

البيانات الوصفية:

الاسم: خدمة_مُلَوِّح_تطبيق_الويب

المواصفة:

النوع: LoadBalancer # اجعل GKE يطلب تلقائيًا من البنية التحتية لشبكة جوجل عنوان IP عالمي للتفريغ المحمي ضد الهجمات لخدمة تحميل التوازن

المحدد:

التطبيق: خدمة الويب

الرياضة:

-البروتوكول: TCP

المنفذ: 80 # منفذ البوابة العامة للواجهة الأمامية

المنفذ الهدف: 8080 # يقابل المنفذ الفعلي داخل الحاوية

قم بتنفيذ أمر النشر بخطوة واحدة في الطرفية، ثم اطرح مخطط التصميم هذا إلى GKE:

باش

kubectl apply -f deployment.yaml

المرحلة الخامسة: لحظة مشاهدة المعجزة – التحقق من النشر وإجراء تمارين كسر الأعطال

بعد اكتمال النشر، نستخدم أمر «Tianyan» في K8s لمراقبة ولادة البنية التحتية:

باش

Kubectl get pods

سترى 3 خضراء تضيء على الشاشة

Running

حالة Pod.

النقطة المهمة هنا: في هذه العملية ، لم يكن لدينا أي صورة مرتجعة (ImagePullSecret). تعتمد GKE على أذونات IAM الأصلية لسحب الصورة الخاصة في السجل الفني بأمان!

بعد ذلك، اطلع على البوابة الخارجية لوحدة تحميل الحمولة العامة التي خصصتها لنا جوجل:

باش

Kubectl get service service-app-lb-service

سوف ترى

EXTERNAL-IP

ظهر عنوان IP ثابت لشبكة عامة تشبه الذهب في العمود (مثل

34-120-x

). اكتب عنوان IP هذا في المتصفح ، وافتح صفحة الويب في ثوانٍ ، وأصبحت خدمة الويب السحابية الأصلية مشهورة رسميًا!

تمرين «انصهار الجسد» لمحاكاة بيئة الإنتاج

لتجربة قدرة الاسترداد الذاتي لمنصة GKE، قمنا عمداً بإحداث أعطال في الخلفية. قم بحذف إحدى الحاويات (Pod) التي تعمل يدويًا:

باش

Kubectl delete pod ويب-app-deployment-xxxxx-xxxx

في اللحظة التي تم حذفها ، تذهب مرة أخرى

صفحات جديدة, مواقع الويب

لا يوجد أي كارتون أو انقطاع على الإطلاق

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

kubectl get pods

في ذلك الوقت ، ستجد أن بود جديد تمامًا قد تم سحبه تلقائيًا في غضون ثوانٍ ودخل في حالة صحية. هذه هي القوة الرابحة لـ GKE للحفاظ على ReplicaSet تلقائيًا.

المرحلة السادسة: تاريخ تجنب الدماء والدموع للأعمال السحابية متعددة الجنسيات

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

1. لا تستخدم أبدا

الأحدث

الوسم (منبع الشرور في إدارة الإصدارات)

العديد من الفرق لديها خطط لتوفير المتاعب ، وفي كل مرة يتم فيها تجميع الصورة محليًا

تطبيق-الويب-الخاص-بي:أحدث

يتم دفع علامة التبويب. مكتوب أيضًا في YAML

صورة:. ..: Latest

.

وقوع الكارثة: عندما تظهر عبوة في الشيفرة البرمجية المنشورة عبر الإنترنت وتستدعي التراجع العاجل، ستجد أن جميع الإصدارات السابقة قد حُذِفت بفعل وسم «latest». علاوة على ذلك، يعتمد Kubernetes في طبقته الأساسية على آلية لتخزين الصور المؤقتة؛ فإذا اكتشف وجود صورة باسم «latest» محليًا، فحتى لو قمت بدفع كود جديد، فقد يتغافل عن تحديثها ويستعين مباشرة بالصورة القديمة المخزنة محليًا، مما يؤدي إلى عدم نشر الإصدار الجديد على الإطلاق.

الحل القياسي في الشركات الكبرى: التخلّي بشكل حاسم عن استخدام «latest». في كل مرة تدفع فيها ، يجب عليك استخدام رقم الإصدار الدلالي (مثل v1.0 ، v1.1) ، أو استخدام معرف Git Commit مباشرةً. عند إطلاق إصدار جديد، قم بتحديث رقم الإصدار في ملف YAML لتمكين تحديث تدريجي مثالي (Rolling Update) في GKE، مما يضمن نشر التحديثات دون أي توقف للخدمة.

2. إصلاح عطل تعليق عملية التخلّص التلقائي (إدارة دورة الحياة) في سجل آرتيفاكت

إذا قام فريق التطوير بإعداد سير عمل آلي للتكامل والتسليم المستمرين (مثل GitHub Actions أو GitLab CI)، فسيؤدي كل دمج للشفرة المصدرية تلقائيًا إلى إنشاء صورة بحجم عدة غيغابايتات يتم إرسالها إلى Artifact Registry. إذا تُرك الأمر بلا مبالاة، فبعد بضعة أشهر سيتكدّس في المستودع عشرات الآلاف من الصور النسخية القديمة، وستؤدّي فاتورة تخزين جوجل كلاود نهاية الشهر إلى إيلام صاحب العمل مباشرة.

إجراء اقتصادي صارم: في إعدادات مخزن Artifact Registry، قم بتفعيل «سياسات التنظيف (Cleanup Policies)».

قواعد الحذف التلقائي للأصول غير المستخدمة: يُمكن إعداد قاعدة تنص على ما يلي: “بالنسبة إلى الصور الوسيطة المؤقتة الخالية من أي علامات (غير موسومة)، يتم إتلافها فعليًا فور تجاوز عمرها سبعة أيام”؛ أو “بالنسبة إلى الصور الموسومة بإصدارات، يُحتفظ فقط بأحدث عشرين إصدارًا، بينما تُحذف الإصدارات الأقدم تلقائيًا”. دع النظام يساعدك تلقائيًا على الخروج ، يمكن أن يساعد في توفير الأصول السحابية للشركة

رسوم تخزين خاملة عالية.

الخلاصة

بناء حالة نشر قائمة على السحابة باستخدام GCP Artifact Registry وGKE؛ وتتمثل الجوهرة الأساسية على المستوى الصناعي في ست عشرة كلمة:

قفل إصدار الصورة المرآوية، جرّ البث بأمان دون كلمة مرور، تعهّد بالنسخ الاحتياطي لضمان الاستقرار، وتنظيف تلقائي للمستودع

.

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