🧑🏿‍🤝‍🧑🏾 🐪 🚷 فب سيرلس 😦 🤴🏻 🏟️

عشية إطلاق دورة Backend PHP Developer ، كان لدينا درس تقليدي مفتوح . هذه المرة تعرفنا على مفهوم Serverless ، وتحدثنا عن تنفيذه في AWS ، وناقشنا مبادئ التشغيل والتجميع والإطلاق ، وقمنا أيضًا ببناء PHP TG-bot بسيط على أساس AWS Lambda.

محاضر - ألكساندر براخين ، المدير التنفيذي لشركة ويستوينج في روسيا.

رحلة قصيرة في التاريخ

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

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

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

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

إذا أخذنا معك جهازًا افتراضيًا قياسيًا ، فسيبدو مثل هذا:

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

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

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

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

سحابة التكنولوجيا

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

"عندما أسمع شخصًا يتحدث عن السحابة على أنها رصاصة سحرية لجميع مشكلات الحوسبة ، استبدل بصمت كلمة" سحابة "بكلمة" مهرج "وأواصل ابتسامة تشبه زن".
ايمي الغنية

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

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

Serverless و FaaS (وظيفة كخدمة)

Serverless هي طريقة شابة إلى حد ما لتشغيل البرامج النصية في السحب ، على سبيل المثال ، AWS (من حيث AWS ، يتم تنفيذ الخادم في Lambda). * أساليب AaS المدرجة في الهرم أعلاه مألوفة بالفعل: IaaS (EC2 ، VDS) ، PaaS (الاستضافة المشتركة) ، SaaS (Office 365 ، Tilda). لذلك ، Serverless هو تنفيذ نهج FaaS. يتمثل هذا النهج في تزويد المستخدم بمنصة جاهزة لتطوير وإطلاق وإدارة وظائف معينة دون الحاجة إلى الإعداد الذاتي والتهيئة.

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

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

لديك فقط رمز ، أنت تعمل في نموذج عديمي الجنسية ، ليس لديك أي ولاية. لنفس العالم من PHP ، هذا يعني ، على سبيل المثال ، أنه يمكنك نسيان آلية الجلسة القياسية. من حيث المبدأ ، يمكنك بناء Serverless الخاص بك ، ومؤخرا على Habré كان هناك مقال حول هذا الموضوع .

الفكرة الرئيسية لـ Serverless هي أن البنية التحتية لا تحتاج إلى دعم من الفريق. كل شيء يقع على عاتق المنصة ، والتي تدفع مقابلها في الواقع. من السلبيات - أنت لا تتحكم في بيئة التنفيذ ولا تعرف أين يتم تنفيذ ما.

لذلك بدون خادم:

لا يعني الغياب الفعلي للخادم ؛
ليس قاتل virtualoks و Docker.
لا الضجيج هنا والآن.
يجب أن يتم دفع Serverless بوعي وعمد. على سبيل المثال ، إذا كنت بحاجة إلى اختبار فرضية بسرعة دون إشراك نصف الفريق. حتى تحصل على وظيفة كخدمة. سوف تستجيب الوظيفة لبعض الأحداث ، وحيث أن هناك رد فعل على الأحداث ، يجب استدعاء هذه الأحداث بواسطة شيء - ولهذا ، هناك العديد من المشغلات في نفس AWS.

ميزات FaaS:

البنية التحتية لا تتطلب التكوين ؛
نموذج الحدث "خارج الصندوق" ؛
عديم الجنسية؛
التحجيم سهل للغاية ويتم تنفيذه تلقائيًا وفقًا لاحتياجات المستخدم.

AWS لامدا

تطبيق FaaS الأول والمتاح للجمهور هو AWS Lambda. إذا كانت الأطروحة ، فإن لديها الميزات التالية:
- متاح منذ عام 2014 ؛
- يدعم خارج الصندوق Java و Node.js و Python و Go ووقت التشغيل المخصص ؛
- نحن ندفع مقابل:
عدد المكالمات
مهلة.
AWS لامدا: لماذا هو مطلوب:
التخلص منها. أنت تدفع فقط للوقت الذي يتم فيه تشغيل الخدمة.
السرعة. لامدا نفسها ترتفع وتعمل بسرعة كبيرة.
الوظيفة. لدى Lambda العديد من الميزات للتكامل مع خدمات AWS.
الأداء. وضع امدا صعب جدا. بالتوازي ، يمكن تنفيذها حسب المنطقة من 1000 إلى 3000 نسخة بحد أقصى. وإذا رغبت في ذلك ، يمكن زيادة هذا الحد عن طريق الكتابة في الدعم.

لدينا مجموعة من lambda ، محرر عبر الإنترنت ، VPC كشبكة حساب افتراضية ، تسجيل ، الكود نفسه ، متغيرات البيئة ومشغلات تسبب lambda (بالمناسبة ، تعمل الإصدارات بشكل جيد للغاية). تم توضيح تشريح Lambda الممتاز في هذه المقالة .

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

إذا كان لدينا وقت تشغيل مخصص ، فسيتعين علينا وضع الشفرة في طبقة. إذا كنت تعمل مع Docker ، فإن طبقة Docker تشبه إلى حد بعيد الطبقة في lambda - وهو نوع من المستودع شبه الذي يوجد فيه رابطنا الضروري. يوجد لدينا الملف القابل للتنفيذ للبيئة (إذا كنا نتحدث عن PHP ، فيجب عليك وضع PHP المترجمة مسبقًا) وملف bootstrap lambda (الموجود افتراضيًا) والبرامج النصية التي يتم الاتصال بها مباشرة والتي سيتم تنفيذها.

مع التسليم ، كل شيء ليس وردية جدا:

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

بالطبع ، هذا لا يتوافق مع الحقائق الحديثة ، ورائحة الألفين في الهواء. لحسن الحظ ، قام أشخاص طيبون بتجربة العديد من الأطر وعملها ، لذلك سنستخدم إطار عمل Serverless الذي تم تطويره على Node.js ويتيح لنا إدارة التطبيقات استنادًا إلى AWS Lambda. بالإضافة إلى ذلك ، عندما نتحدث عن النشر والتطوير ، بالطبع ، لا أرغب حقًا في النشر يدويًا ، ولكن هناك رغبة في القيام بشيء مرن وآلي.

لذلك ، نحن بحاجة إلى:
- واجهة سطر الأوامر AWS CLI للعمل مع خدمات AWS ؛
- إطار Serverless الذي سبق ذكره أعلاه (إصدار التطوير مجاني ، ووظائفه كافية للعينين) ؛
- مكتبة Bref ، وهو مطلوب لكتابة التعليمات البرمجية. تم تثبيت هذه المكتبة باستخدام الملحن ، وبالتالي فإن الرمز سيكون متوافقًا مع أي إطار عمل. حل رائع ، لا سيما بالنظر إلى أن AWS Lambda لا يدعم استدعاء البرامج النصية لـ PHP خارج الصندوق.

تخصيص البيئة الخاصة بك و AWS

AWS CLI

لنبدأ بإنشاء حساب وتثبيت AWS CLI. يستند AWS shell console على Python 2.7+ أو 3.4+. بما أن AWS توصي بالإصدار 3 من Python ، فإننا لن نجادل.
الأمثلة أدناه هي لأوبونتو.

sudo apt-get -y install python3-pip

ثم تثبيت مباشرة AWS CLI:

 pip3 install awscli --upgrade --user

التحقق من التثبيت:

 aws --version

تحتاج الآن إلى توصيل AWS CLI بحسابك. يمكنك استخدام اسم المستخدم وكلمة المرور الحاليين ، لكن سيكون من الأفضل إذا قمت بإنشاء مستخدم منفصل من خلال AWS IAM ، مع تعريفه فقط بحقوق الوصول الضرورية. استدعاء التكوين لن يسبب مشاكل:

 aws configure

بعد ذلك ، ستحتاج إلى AWS Secret ومفتاح الوصول AWS. يمكن الحصول عليها في ASW IAM في علامة التبويب "بيانات اعتماد الأمان" (الموجودة على صفحة المستخدم المطلوب). سيساعد زر "إنشاء مفتاح وصول" في إنشاء مفاتيح الوصول. احتفظ بها معك.

لتسجيل روبوت جديد في Telegram ، استخدمBotFather والأمر / newbot. نتيجة لذلك ، سيتم إرجاع الرمز المميز للاتصال بالبوت الخاص بك. قفله أيضا.

إطار خادم

لتثبيت Serverless Framework ، ستحتاج إلى حساب على https://serverless.com/ .
بعد الانتهاء من التسجيل ، سننتقل إلى التثبيت في محطة العمل الخاصة بنا. ستكون Node.js 6 وما فوق مطلوبة.

 sudo apt-get -y install nodejs

لضمان التشغيل الصحيح في بيئتنا ، نتبع الخطوات الموصى بها:

 mkdir ~/.npm-global export PATH=~/.npm-global/bin:$PATH source ~/.profile npm config set prefix '~/.npm-global'

أضف أيضًا:

 ~/.npm-global/bin:$PATH

إلى / الخ / ملف البيئة.
الآن وضع Serverless:

 npm install -g serverless

AWS

حسنًا ، لقد حان الوقت للتبديل إلى واجهة AWS وإضافة اسم مجال. نقوم بإنشاء منطقة AWS Route 53 ، وسجل DNS ، وشهادة SSL لها.
بالإضافة إلى ذلك ، تحتاج إلى ELB ، الذي نقوم بإنشائه في خدمة EC2 -> Load Balancers. بالمناسبة ، عند إنشاء ELB ، ستحتاج إلى متابعة جميع خطوات المعالج ، مع الإشارة إلى الشهادة التي تم إنشاؤها.

بالنسبة إلى الموازن ، يمكنك إنشائه من خلال AWS CLI باستخدام الأمر التالي:

 aws elb create-load-balancer --load-balancer-name my-load-balancer --listeners "Protocol=HTTP,LoadBalancerPort=80,InstanceProtocol=HTTP,InstancePort=80" "Protocol=HTTPS,LoadBalancerPort=443,InstanceProtocol=HTTP,InstancePort=80,SSLCertificateId=arn:aws:iam::123456789012:server-certificate/my-server-cert" --subnets subnet-15aaab61 --security-groups sg-a61988c3

ستكون هناك حاجة إلى موازن بعد النشر الأول. في هذه الحالة ، تحتاج إلى إرسال طلبات إلى مجالنا إليه. لتنفيذ ذلك ، في إعدادات سجل DNS (الحقل "هدف الاسم المستعار") ، ابدأ في إدخال اسم ELB الذي تم إنشاؤه. نتيجة لذلك ، سترى قائمة منسدلة ، لذلك يبقى تحديد الإدخال المطلوب وحفظه.

اذهب الآن إلى الكود.

كتابة رمز

سوف نستخدم Bref لكتابة الرمز. كما ذكرنا سابقًا ، تم تثبيت هذه المكتبة باستخدام الملحن ، لذلك ستكون الشفرة متوافقة مع أي إطار عمل. بالمناسبة ، قام المطورون بالفعل بوصف عملية استخدام Bref مع Laravel و Symfony . ولكن من المستحسن بالنسبة لنا أن نعمل على PHP "العارية" - وهذا سوف يساعد على فهم أفضل للجوهر.
نبدأ بالتبعيات:

 { "require": { "php": ">=7.2", "bref/bref": "^0.5.9", "telegram-bot/api": "*" }, "autoload": { "psr-4": { "App\": "src/" } } }

سوف نكتب PHP 7.2 وما فوق ، ولعملنا مع Telegram ، تعد هذه الواجهة الخاصة بواجهة برمجة التطبيقات مناسبة لنا - https://github.com/TelegramBot/Api . بالنسبة للرمز نفسه ، سيتم وضعه في دليل src.

لذلك ، فإن بيئة serverless يمر مربع حوار وحدة التحكم. مطلوب تطبيق HTTP ، ومن وجهة نظر Lambda ، سيعني هذا أن مكالمات النص البرمجي سيتم تنفيذها بنفس طريقة تنفيذ Nginx. سيتم تنفيذ التفسير بواسطة PHP-FPM. بشكل عام ، هذا يشبه استدعاء البرنامج النصي القياسي. هذه نقطة مهمة ، لأنه بدون أخذ هذه الميزة في الاعتبار ، لن نتمكن من استدعاء البرامج النصية عبر HTTP.
نقوم بها:

 vendor/bin/bref init

في مربع الحوار ، حدد عنصر "تطبيق HTTP" ولا تنس تحديد المنطقة ، حيث يجب أن يعمل التطبيق في نفس المنطقة التي يعمل فيها الموازن.
بعد التهيئة ، سيظهر ملفان جديدان:
index.php - الملف الذي يسمى
serverless.yml - نشر ملف التكوين.
سيحتاج المجلد .serverless لإضافته على الفور إلى .gitignore (سيظهر بعد المحاولة الأولى للنشر).

بمجرد أن يكون لدينا تطبيق ويب ، سنقوم بإفلات index.php إلى المجلد العمومي ، وسنتحول على الفور إلى serverless.yml. إليك ما قد يبدو عليه في تطبيقنا:

 #  lambda- service: app #    provider: name: aws #   ! region: eu-central-1 #    runtime: provided # ,  bref  1024.         memoryLimit: 256 #   stage: dev #    environment: BOT_TOKEN: ${ssm:/app/bot-token} #  bref plugins: - ./vendor/bref/bref #  Lambda- functions: #       php-api-dev # service-function-stage api: handler: public/index.php description: '' # in seconds (API Gateway has a timeout of 29 seconds) timeout: 28 layers: - ${bref:layer.php-73-fpm} #     API Gateway events: - http: 'ANY /' - http: 'ANY /{proxy+}' #    environment: MY_VARIABLE: ${ssm:/app/my_variable}

الآن دعنا نحلل الخطوط غير الواضحة. نحتاج في الغالب متغيرات البيئة. لا نريد تشفير اتصالات قاعدة البيانات ، واجهات برمجة التطبيقات الخارجية ، وما إلى ذلك. إذا وصلنا إلى Telegram ، فسوف يكون لدينا الرمز المميز الخاص بنا ، والذي يتم استلامه من BotFather. وليس من المستحسن تخزين هذا الرمز المميز في serverless.yml ، لذلك من الأفضل إرساله إلى وحدة تخزين AWS ssm:

 aws ssm put-parameter --region eu-central-1 --name '/app/my_variable' --type String --value '___BOTFATHER'

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

دعنا ننتقل. لنقم الآن بإنشاء فصل BotApp بسيط - سيكون مسؤولاً عن إنشاء استجابة للبوت وسوف يستجيب للأوامر. يوصي مطورو Telegram بإضافة دعم للأوامر / help و / start لجميع برامج الروبوت. دعنا نضيف أمر آخر للمتعة. الفئة نفسها بسيطة للغاية وتجعل من الممكن تطبيق وحدة تحكم أمامية في index.php دون تحميل ملف الاستدعاء نفسه. للحصول على منطق أكثر تعقيدًا ، يجب تطوير البنية وتعقيدها.

 <?php namespace App; use TelegramBot\Api\Client; use Telegram\Bot\Objects\Update; class BotApp { function run(): void{ $token = getenv('BOT_TOKEN'); $bot = new Client($token); //   start $bot->command('start', function ($message) use ($bot) { $answer = ' !'; $bot->sendMessage($message->getChat()->getId(), $answer); }); //    $bot->command('help', function ($message) use ($bot) { $answer = ': /help -  '; $bot->sendMessage($message->getChat()->getId(), $answer); }); //   $bot->command('hello', function ($message) use ($bot) { $answer = '-,  - ,   Serverless '; $bot->sendMessage($message->getChat()->getId(), $answer); }); $bot->run(); } }

وهنا سرد index.php:

 <?php require_once('../vendor/autoload.php'); use App\BotApp; try{ $botApp = new BotApp(); $botApp->run(); } catch (Exception $e){ echo $e->getMessage(); print_r($e->getTrace(), 1); }

قد يبدو غريباً ، لكن كل شيء جاهز لنا لمغادرة الإنتاج. لنقم بذلك عن طريق تشغيل الأمر في المجلد serverless.yml:

 sls deploy

في الوضع العادي ، سيقوم serverless بحزم الملفات في محفوظات zip ، وإنشاء دلو S3 لوضعها ، ثم إنشاء أو تحديث تطبيق AWS المرفق بـ Lambda ، ووضع الكود ووقت التشغيل في طبقة منفصلة.

أثناء الإطلاق الأول ، سيتم إنشاء بوابة API (تركناها لتسهيل اختبار المكالمات ، ولكن بعد ذلك يُنصح بحذفها). ستحتاج أيضًا إلى تهيئة مكالمة Lambda عبر ELB ، حيث نختار "إضافة مشغل" في نافذة التحكم في الوظيفة وحدد "Application Load Balancer" في القائمة المنسدلة. ستحتاج إلى تحديد ELB الذي تم إنشاؤه مسبقًا ، وتعيين الاتصال عبر HTTPS ، وترك المضيف فارغًا ، وفي المسار ، حدد المسار الذي ستدعوه Lambda (على سبيل المثال ، / lambda / mytgbot). نتيجة لذلك ، ستكون Lambda متاحة على عنوان URL بالمسار المحدد.

يمكنك الآن تسجيل جزء الاستجابة من الروبوت في Telegram حتى يفهم المرسِل مكان استلام الرسائل. للقيام بذلك ، اتصل بعنوان URL التالي في المستعرض ، ولكن لا تنسَ استبدال معلماتك به:

 https://api.telegram.org/bot_/setWebhook?url=https://my-elb-host.com/lambda/mytgbot

نتيجة لذلك ، ستُرجع واجهة برمجة التطبيقات "OK" ، وبعد ذلك ستصبح الروبوتات متاحة.

اختبار الروبوت على لغات

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

 sls invoke local --docker -f myFunction

لا تنس أننا استخدمنا متغيرات البيئة ، لذا أثناء المكالمة ، يجب أيضًا ضبطها بالتنسيق:

 sls invoke local --docker -f myFunction --env VAR1=val1

السجلات

افتراضيًا ، سيتم تسجيل إخراج المكالمة في CloudWatch - وهو متاح في لوحة Monitor لوظيفة Lambda المقابلة. هنا يمكنك قراءة آثار المكالمة في حالة حدوث تفريغ على جانب PHP. بالإضافة إلى ذلك ، يمكنك توصيل خدمات المراقبة المتقدمة ، لكنها ستكلف بضعة سنتات إضافية كل شهر.

في المجموع

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

فب سيرلس