بيع حساب Google Cloud: استخدم GCP Cloud Run لنشر تطبيقات الويب بدون خادم لمدة 5 دقائق (Serverless)

كمطور أو مهندس معماري ، عادة ما أكتب تطبيق ويب ممتاز (سواء كان Node.js أو Python Flask أو Go أو Java Spring Boot) ، غالبًا ما يكون الشيء الأكثر مقاومة هو عدم تغيير الأخطاء ، ولكن

النشر

.

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

في بيئة Google Cloud(GCP ، Google Cloud) ، هناك ضربة كبيرة لخفض الأبعاد تم إنشاؤها خصيصًا لتحرير الإنتاجية وتطويرها ، تسمى

Cloud Run

.

منطقها الأساسي نقي للغاية:

Serverless (بدون خادم) في حاويات

. تحتاج فقط إلى حزم تطبيقك في صورة معكوسة قياسية لـ Docker وإلقائه عليه ، وسوف يبصق لك عنوان URL للشبكة العامة بشهادة HTTPS الخاصة بك ، وموازنة التحميل العالمية الخاصة بك ، والتلسكوب المرن التلقائي الخاص بك في غضون 5 دقائق.

الأكثر لا يقهر هو نموذج الفوترة:

الفوترة حسب الطلب بالكامل ، ودعم الانكماش إلى 0(Scale to Zero)

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

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

المرحلة الأولى: التفكيك العميق ، "نموذج العالم البسيط" لـ Cloud Run

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

يتم لحام تدفق البيانات الأساسية للنظام بأكمله بسلاسة بواسطة ثلاثة مكونات أساسية:

قاعدة بيانات الحاويات: محطة الحاويات الخاصة بك. هذا هو الجيل الجديد من مستودع المرآة لـ GCP ، والذي يحل محل GCR القديم. سيتم تعبئة تطبيقاتك في صورة مرآة Docker وتخزينها هنا.

خدمة Cloud Run (Service): Serverless جدولة الدماغ. إنها مسؤولة عن التحديق في المرآة. عندما يكون لدى الشبكة العامة طلب HTTP ، فإنها ستسحب الصورة المتطابقة بسرعة البرق إلى مثال حاوية (Instance) لالتقاط العملاء.

محرك التلسكوب التلقائي (Auto-scaling): حركة المرور الخاصة بك شرطة المرور. إذا بدأ 10000 شخص طلبًا في نفس الوقت ، فسوف يقوم على الفور بسحب عشرات الحاويات في الخلفية لمشاركة الضغط ؛ إذا لم يتمكن أحد من الوصول لعدة دقائق ، فسوف يدمر جميع الحاويات فعليًا.

أدخل 0 التكلفة السكون.

المرحلة الثانية: تمرين عملي-5 دقائق عبر خط التجميع السريع

لنفترض أنك كتبت أحد تطبيقات الويب الأساسية Node.js أو Python محليًا ، وقد قمت بتثبيت أدوات سطر الأوامر Docker و GCP (gcloud CLI) محليًا.

الخطوة 1: "حاويات" من الكود المحلي (Dockerfile)

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

Dockerfile

الوثائق. فيما يلي مثال على أحد أبسط تطبيقات Node.js:

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

FROM node:18-slim

# إعداد دليل العمل

WORKDIR /usr/src/app

# النسخ المتماثل يعتمد على التكوين والتثبيت

COPY package *.json ./

RUN npm install -- only = production

# نسخ رمز الحزمة الكاملة

COPY ..

# منفذ التعرض (ملاحظة: تقوم Cloud Run بحقن متغير بيئة يسمى PORT في الحاوية افتراضيًا ، عادةً 8080)

EXPOSE 8080

# أمر بدء التشغيل ، يجب الاستماع إلى 0.0.0.0

CMD [ "node", "server.js"]

دليل تجنب الحفرة الأساسية: في رمز التطبيق الخاص بك ، لا تكتب مراقبة IP على أنها 127.0.0.1 ، يجب عليك مراقبة 0.0.0.0 ، ويقرأ المنفذ مباشرة متغير البيئة Process. env.PORT. إذا كانت Python ، فسيتم كتابة أمر بدء التشغيل كـ CMD ["gunicorn" ، "-bind" ، "0.0.0.0:8080" ، "min: app"]. إذا كانت المراقبة خاطئة ، فسوف تقوم Cloud Run بالإبلاغ مباشرة عن الخطأ عند بدء التشغيل لأنها لا تستطيع الحصول على استجابة ضربات قلب الحاوية.

الخطوة 2: إنشاء قفص الاتهام في GCP (سجل Artifact)

افتح المحطة الطرفية الخاصة بك ، والاستفادة منها

Gcloud

أمر ببناء مستودع Docker في المنطقة الأقرب إليك. لنفترض أننا نختار منطقة تايوان الصينية (

Asia-east1

) ، اسم معرف المشروع

My-serverless-project

:

Gcloud artifacts repositories create my-docker-repo \

-- Repository-format = docker \

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

-- Description = "My

Serverless App Repo"

الخطوة 3: التعبئة المحلية والدفع على السحابة

استخدم Docker المحلي لتجميع صورة المرآة ، وقم بإحضار مسار مستودع GCP الكامل بالاسم.

محاذاة الشفرة (تكوين شهادة مصادقة Docker):Bashgcloud auth configure-docker asia-east1-docker.pkg.dev

التجميع والتعبئة: Bashdocker build -t asia-east1-docker.pkg.dev/my-serverless-project/my-docker-repo/ويب-app: v1.0.

الدفع الكامل: Bashdocker push asia-east1-docker.pkg.dev/my-serverless-project/my-docker-repo/ويب-app:v1.0

بالنظر إلى أن شريط التقدم المألوف على المحطة قد انتهى ، فإن حاويتك مستلقية بثبات على سحابة الأمان الموزعة من Google.

الخطوة 4: أفضل لحظة-تنشيط Cloud Run بنقرة واحدة

العودة إلى الوراء

وحدة تحكم GCP

، ابحث وادخل

كلاود رن

الصفحات.

انقر في الأعلى

”إنشاء خدمة“

، أدخل ساحة معركة التكوين الأساسي:

نشر نسخة منقحة: انقر فوق اختر ، حدد بدقة تطبيق الويب: v1.0 المرآة التي دفعتها للتو.

اسم الخدمة: اسم my-web-service.

المنطقة (المنطقة): يوصى بشدة بالتوافق مع مستودع المرآة ، واختيار asia-east1 (تايوان) ، وتأخير الوصول إلى شبكة الوصول المحلية منخفض للغاية.

التوسيع التلقائي: الحد الأدنى لعدد الحالات: أدخل 0 (افتح التكنولوجيا السوداء دون الوصول إلى المال). أكبر عدد من الأمثلة: أدخل 10 في بداية الاختبار لمنع تجاوز الرسوم بسبب حركة مرور الفرشاة الخبيثة.

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

انقر على الجزء السفلي

“إنشاء”

.

المرحلة الثالثة: التحقق عبر الإنترنت و "البدء البارد" المشهد الحقيقي

بعد النقر على إنشاء ، التحديق في تلك الدائرة الصغيرة على الشاشة. سيقوم Cloud Run تلقائيًا بتكوين موازنة التحميل وتعيين اسم المجال ونفق تشفير SSL لك في الخلفية.

عادة فقط

30 ثانية إلى دقيقة واحدة

، سيتم إضاءة علامة خضراء كبيرة في الجزء العلوي من وحدة التحكم ، وسيتم بصق شكل لك

Ps: //

My-web-service-xxxx-de.a.run.app

الموقع الدائم الرسمي HTTPS.

انقر على هذا الموقع ، تفتح صفحة الويب على الفور! تهانينا ، أصبح تطبيق الويب الخاص بـ Serverless مشهورًا تمامًا.

تجربة داخلية صلبة: ما هو "البدء البارد" ؟

من أجل التحقق من قوة "الانكماش إلى 0" ، يرجى إيقاف تشغيل صفحة الويب ، وترك لوحة المفاتيح بكلتا يديك ، والانتظار بهدوء لمدة 15 دقيقة.

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

نظرًا لعدم وجود أي حالات تعمل ، فإن فاتورتك لا تزال ثابتة تمامًا.

الآن ، انقر مرة أخرى لفتح عنوان URL العام. ستجد أن صفحة الويب لم تفتح في ثوانٍ كما كانت من قبل ، لكنها كانت عالقة قليلاً تقريبًا

1 إلى 2 ثانية

قم بالفرشاة بعد ذلك.

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

المرحلة الرابعة: تاريخ تجنب الدم والدموع في الهيكل التجاري وتعديل مؤشرات المصانع الكبيرة

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

1. "جدار التزامن الزومبي" الذي يدعم قاعدة البيانات الخلفية للانفجار

يشعر العديد من المطورين المبتدئين أنه نظرًا لأن Cloud Run يمكن توسيعه تلقائيًا إلى ما لا نهاية ، فقد قمت بإعداد الحد الأقصى لعدد الحالات إلى 1000. نتيجة لذلك ، بمجرد وصول العرض الترويجي لـ Black Five ، ارتفعت حركة المرور ، وكانت Cloud Run مخصصة للغاية لسحب 500 حاوية في لحظة لالتقاط العملاء.

حدثت كارثة: في لحظة بدء تشغيل 500 حاوية ، تم إطلاق طلب اتصال في نفس الوقت لقاعدة بيانات Cloud SQL العلائقية في الطرف الخلفي. قد يكون الحد الأقصى لعدد الاتصالات في قاعدة بيانات MySQL التقليدية 200 فقط ، ونتيجة لذلك ، تم غسل قاعدة البيانات على الفور وانهارت بسبب حركة المرور المفاجئة ، مما أدى إلى شل العمل العام.

الحل القياسي للمصنع الكبير: أدخل الإعداد المتقدم "الحاوية ، الاتصال ، الأمان" لـ Cloud Run: قم بزيادة "الحد الأقصى للتزامن" من القيمة الافتراضية (مثل تعيين 80 أو حتى 100). هذا يعني أن مثيل الحاوية يسمح بمعالجة 80 طلبًا متزامنًا لـ HTTP في نفس الوقت في نفس الوقت. فقط عندما تكون هذه الحفر الثمانين ممتلئة ، ستسحب Google الحاويات الجديدة. قم بإعداد تجمع اتصال (Connection) أمام قاعدة البيانات الخلفية

Pool) ، أغلق الحد الأقصى للتوسع لحماية الأصول الأساسية الخلفية الهشة.

2. لا أستطيع تحمل "البداية الباردة"

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

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

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

الخلاصة

باستخدام نشر GCP Cloud Run للعب Serverless ، يكمن جوهر المستوى الصناعي الأساسي في ستة عشر كلمة:

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

.

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