सर्वरहित php

बैकएंड PHP डेवलपर कोर्स के शुभारंभ की पूर्व संध्या पर , हमारे पास एक पारंपरिक खुला सबक था । इस बार हम सर्वरलेस अवधारणा से परिचित हुए, AWS में इसके कार्यान्वयन के बारे में बात की, ऑपरेशन, असेंबली और लॉन्च के सिद्धांतों पर चर्चा की, और AWS लैम्ब्डा पर आधारित एक साधारण PHP TG-bot का भी निर्माण किया।

लेक्चरर - अलेक्जेंडर Pryakhin , Westwing रूस के सीटीओ।

इतिहास में एक संक्षिप्त भ्रमण

हमें ऐसी ज़िंदगी कैसे मिली कि सर्वरलेस कंप्यूटिंग दिखाई दी? बेशक, वे न केवल इस तरह दिखाई दिए, बल्कि मौजूदा वर्चुअलाइजेशन प्रौद्योगिकियों के एक तार्किक निरंतरता बन गए।

हम आमतौर पर क्या करते हैं? उदाहरण के लिए, एक प्रोसेसर। आप मेमोरी के कुछ क्षेत्रों को हाइलाइट करके और कुछ उपयोगकर्ताओं के लिए सुलभ और दूसरों के लिए दुर्गम बनाकर भी मेमोरी को वर्चुअल कर सकते हैं। आप एक वीपीएन नेटवर्क को वर्चुअलाइज कर सकते हैं। और इसी तरह।

वर्चुअलाइजेशन अच्छा है क्योंकि हम संसाधनों का बेहतर उपयोग करते हैं और उत्पादकता बढ़ाते हैं। लेकिन इसके नुकसान भी हैं, उदाहरण के लिए, एक समय में संगतता समस्याएं थीं। हालांकि, व्यावहारिक रूप से कोई भी आर्किटेक्चर नहीं है जो आधुनिक आभासी मशीनों के साथ असंगत होगा।

अगला ऋण यह है कि हम अमूर्तता की एक अतिरिक्त परत जोड़ते हैं, एक हाइपरविजर जोड़ते हैं, अपने आप से एक आभासी मशीन जोड़ते हैं, और निश्चित रूप से, हम थोड़ी गति खो सकते हैं। सर्वर का उपयोग कुछ जटिल है।

यदि हम आपके साथ एक मानक वर्चुअल मशीन लेते हैं, तो यह कुछ इस तरह दिखाई देगी:

सबसे पहले, हमारे पास एक लोहे का सर्वर है, और दूसरी बात, ऑपरेटिंग सिस्टम जिस पर हमारा हाइपरवाइजर स्पिन करेगा। और इस सब सामान के ऊपर, हमारी आभासी मशीनें घूम रही हैं, जिसमें एक अतिथि ओएस, लाइब्रेरी और एप्लिकेशन हैं। यदि आप तार्किक रूप से सोचते हैं, तो हम अतिथि ओएस की उपस्थिति में कुछ ओवरहेड देखते हैं, क्योंकि वास्तव में हम अतिरिक्त संसाधन खर्च करते हैं।

मैं ओवरहेड समस्या को कैसे हल कर सकता हूं? वर्चुअल मशीनों को मना करना और मुख्य ऑपरेटिंग सिस्टम के शीर्ष पर एक कंटेनर प्रबंधन प्रणाली डालना। बेशक, अब सबसे लोकप्रिय प्रणाली डॉकर इंजन है। फिर कंटेनर के अंदर पुस्तकालय ऑपरेटिंग सिस्टम के मेजबान कर्नेल का उपयोग करेंगे।

इस तरह, हम ओवरहेड को हटा देते हैं, लेकिन डॉकर आदर्श भी नहीं है, और इसकी अपनी समस्याएं और कार्य विशेषताएं हैं जो हर किसी को पसंद नहीं हैं।

समझने की मुख्य बात यह है कि डॉकर और वर्चुअल मशीन अलग-अलग दृष्टिकोण हैं, और उन्हें समान करने की कोई आवश्यकता नहीं है। डॉकटर एक माइक्रोवेरेटिव नहीं है जिसके साथ आप वर्चुअल मशीन की तरह काम कर सकते हैं, क्योंकि कंटेनर उसके लिए है और कंटेनर है। लेकिन कंटेनर हमें निरंतर वितरण के लिए लचीलापन और एक पूरी तरह से अलग दृष्टिकोण प्रदान करने की अनुमति देता है, जब हम उत्पादन को चीजें वितरित करते हैं और समझते हैं कि वे पहले से ही परीक्षण और काम कर रहे हैं।

क्लाउड तकनीक

वर्चुअलाइजेशन के आगे विकास के साथ, क्लाउड प्रौद्योगिकियों का विकास भी शुरू हुआ। यह एक अच्छा समाधान है, लेकिन अभी यह ध्यान देने योग्य है कि बादल एक चांदी की गोली नहीं हैं और सभी बीमारियों के लिए रामबाण नहीं हैं। यहाँ कोई मदद नहीं कर सकता लेकिन एक प्रसिद्ध उद्धरण याद दिलाता है:

"जब मैं किसी को सभी कंप्यूटिंग समस्याओं के लिए एक जादू-बुलेट के रूप में क्लाउड को टैप करते हुए सुनता हूं, तो मैं चुपचाप" क्लाउड "को" जोकर "के साथ बदल देता हूं और ज़ेन जैसी मुस्कान के साथ आगे बढ़ता हूं।"
अमीर अमीर

हालांकि, मध्यम आकार की कंपनियों के लिए जो भारी वित्तीय इंजेक्शन के बिना एक निश्चित स्तर की सेवा और दोष सहिष्णुता प्राप्त करना चाहते हैं, बादल काफी विकल्प हैं। और कई कंपनियों के लिए, अपने डेटा केंद्र को एक ही SLA के साथ रखना क्लाउड में परोसे जाने की तुलना में बहुत अधिक महंगा होगा। इसके अलावा, हम अपनी आवश्यकताओं के लिए बादलों का उपयोग कर सकते हैं, क्योंकि वे माउस के कुछ ही क्लिक में कुछ चीजें प्रदान करते हैं, जो बहुत सुविधाजनक है। उदाहरण के लिए, कुछ ही क्लिक में वर्चुअल मशीन या नेटवर्क को उठाने की क्षमता।
हां, प्रतिबंध हैं, उदाहरण के लिए, 152 वां संघीय कानून विदेश में व्यक्तिगत डेटा के भंडारण पर प्रतिबंध लगाता है, इसलिए वही अमेज़ॅन ऑडिट के दौरान हमारे लिए उपयुक्त नहीं होगा। वेंडर-लॉक के बारे में मत भूलना। कई क्लाउड समाधान एक दूसरे के लिए पोर्ट नहीं करते हैं, हालांकि समान S3- संगत स्टोरेज अधिकांश प्रदाताओं द्वारा समर्थित है।

बादल हमें संकीर्ण ध्यान केंद्रित ज्ञान के बिना सेवा के विभिन्न स्तरों को प्राप्त करने का अवसर प्रदान करते हैं। जितना कम ज्ञान आपको चाहिए, उतना ही हम चुकाएंगे। नीचे दिए गए आंकड़े में, आप पिरामिड को देख सकते हैं, जहां, नीचे से, क्लाउड का उपयोग करते समय तकनीकी ज्ञान की आवश्यकताओं में कमी प्रदर्शित होती है:

सर्वर रहित और आघात (एक सेवा के रूप में कार्य)

सर्वरलेस बादलों में स्क्रिप्ट को चलाने के लिए एक काफी युवा तरीका है, उदाहरण के लिए, जैसे एडब्ल्यूएस (एडब्ल्यूएस के संदर्भ में, सर्वर को लैम्ब्डा में लागू किया गया है)। * ऊपर पिरामिड पर सूचीबद्ध एएएस दृष्टिकोण पहले से ही परिचित हैं: आईएएएस (ईसी 2, वीडीएस), पाएस (साझा होस्टिंग), सास (ऑफिस 365, तिल्दा)। इसलिए, सर्वरलेस, एफएएएस दृष्टिकोण का कार्यान्वयन है। और यह दृष्टिकोण उपयोगकर्ता को स्वयं-तैयारी और कॉन्फ़िगरेशन की आवश्यकता के बिना निश्चित कार्यक्षमता के विकास, लॉन्च और प्रबंधन के लिए एक तैयार मंच प्रदान करने में शामिल है।

कल्पना करें कि आपके पास एक मशीन है जो दस्तावेजों की रात प्रसंस्करण में लगी हुई है, 00:00 से 6:00 तक कार्य कर रही है, और बाकी घंटों के दौरान यह बेकार है। सवाल यह है कि दिन के दौरान इसके लिए भुगतान क्यों करें? और कुछ और के लिए मुफ्त संसाधनों का उपयोग क्यों नहीं करते? अनुकूलन की यह इच्छा और आप जो वास्तव में उपयोग करते हैं, उस पर केवल पैसा खर्च करने की इच्छा, और एफएएएस के उद्भव के लिए नेतृत्व किया।

सर्वर रहित कोड निष्पादित करने के लिए एक संसाधन है और इससे अधिक कुछ नहीं। इसका मतलब यह नहीं है कि हमारी स्क्रिप्ट के पीछे कोई सर्वर नहीं है - यह है, लेकिन हम, वास्तव में, कोई विशेष रूप से आवंटित संसाधन नहीं है, जिस पर हमारा लैंबडा लॉन्च किया जाएगा। जब हम अपनी स्क्रिप्ट चलाते हैं, तो इसके तहत माइक्रो-इन्फ्रास्ट्रक्चर तुरंत सामने आता है, और यह सिद्धांत रूप में आपकी समस्या नहीं है - आप केवल सोचते हैं कि आपके पास कोड निष्पादित है, और आपको कुछ और सोचने की ज़रूरत नहीं है।
यह निश्चित रूप से, आपके कोड के विकास के लिए एक निश्चित दृष्टिकोण की आवश्यकता है। उदाहरण के लिए, आप इस वातावरण में कुछ भी स्टोर नहीं कर सकते हैं, आपको सब कुछ बाहर निकालने की आवश्यकता है। यदि यह डेटा है, तो एक बाहरी डेटाबेस की आवश्यकता है, यदि यह एक लॉग है, तो एक बाहरी लॉग सेवा, यदि यह एक फ़ाइल है, तो एक बाहरी फ़ाइल भंडारण है। सौभाग्य से, कोई भी सर्वर रहित प्रदाता बाहरी सिस्टम से जुड़ने की क्षमता प्रदान करता है।

आपके पास केवल कोड है, आप स्टेटलेस प्रतिमान में काम करते हैं, आपके पास कोई राज्य नहीं है। PHP की इसी दुनिया के लिए, इसका मतलब है, उदाहरण के लिए, कि आप मानक सत्र तंत्र के बारे में भूल सकते हैं। सिद्धांत रूप में, आप अपना सर्वर रहित भी बना सकते हैं, और हाल ही में हैबे पर इस विषय पर एक लेख था।

सर्वरलेस का मुख्य विचार यह है कि बुनियादी ढांचे को टीम से समर्थन की आवश्यकता नहीं है। सब कुछ मंच के कंधों पर पड़ता है, जिसके लिए आप वास्तव में पैसा देते हैं। Minuses की - आप निष्पादन पर्यावरण को नियंत्रित नहीं करते हैं और यह नहीं जानते हैं कि क्या किया जाता है।

तो सर्वरहित:

• सर्वर की भौतिक अनुपस्थिति का मतलब नहीं है;
• virtualoks और Docker का हत्यारा नहीं;
• यहाँ और अभी प्रचार नहीं।
  सर्वरलेस को जानबूझकर और जानबूझकर धकेल दिया जाना चाहिए। उदाहरण के लिए, यदि आपको आधी टीम को शामिल किए बिना एक परिकल्पना को जल्दी से परखने की आवश्यकता है। तो आपको एक सेवा के रूप में फंक्शन मिलता है। फ़ंक्शन कुछ घटनाओं का जवाब देगा, और चूंकि घटनाओं पर प्रतिक्रिया होती है, इसलिए इन घटनाओं को किसी चीज़ से बुलाया जाना चाहिए - इसके लिए, उसी AWS में कई ट्रिगर हैं।

FaaS विशेषताएं:

• बुनियादी ढांचे को कॉन्फ़िगरेशन की आवश्यकता नहीं है;
• "बॉक्स से बाहर" घटना मॉडल;
• राज्यविहीन;
• स्केलिंग बहुत आसान है और उपयोगकर्ता की जरूरतों के अनुसार स्वचालित रूप से किया जाता है।

AWS लाम्बा

पहला और सार्वजनिक रूप से उपलब्ध FaaS कार्यान्वयन AWS लैम्ब्डा है। यदि यह थीसिस है, तो इसकी निम्न विशेषताएं हैं:
- 2014 से उपलब्ध;
- बॉक्स से बाहर का समर्थन करता है जावा, Node.js, पायथन, गो और कस्टम रनटाइम;
- हम इसके लिए भुगतान करते हैं:
कॉल की संख्या;
नेतृत्व समय
AWS लाम्बा: इसकी आवश्यकता क्यों है:
निपटान। आप केवल उस समय के लिए भुगतान करते हैं जब सेवा चल रही होती है।
स्पीड। लैम्ब्डा ही उगता है और बहुत तेजी से काम करता है।
कार्यक्षमता। लैम्ब्डा में AWS सेवाओं के साथ एकीकरण के लिए कई विशेषताएं हैं।
प्रदर्शन। लंबोदर को लगाना बहुत कठिन है। समानांतर में, यह अधिकतम 1000 से 3000 प्रतियों के क्षेत्र के आधार पर किया जा सकता है। और यदि वांछित है, तो समर्थन में लिखकर इस सीमा को बढ़ाया जा सकता है।

हमारे पास एक लैम्ब्डा, एक ऑनलाइन एडिटर, वीपीसी के रूप में एक वर्चुअल कम्प्यूटेशन ग्रिड, लॉगिंग, कोड ही, पर्यावरण चर और ट्रिगर्स का शरीर है जो लैम्बडा का कारण बनता है (वैसे, वर्जनिंग बहुत अच्छी तरह से काम करता है)। इस लेख में उत्कृष्ट लाम्बा शरीर रचना को रेखांकित किया गया है।

कोड या तो शरीर में संग्रहीत किया जाता है (यदि ये बॉक्स से बाहर समर्थित भाषाएं हैं) या परतों में। हमारे पास एक ट्रिगर है जो लैम्ब्डा को कॉल करता है, लैम्ब्डा अस्थायी वातावरण पढ़ता है, उन्हें अपने पास खींचता है और हमारे कोड को निष्पादित करता है:

यदि हमारे पास एक कस्टम रनटाइम है, तो हमें कोड को एक परत में रखना होगा। यदि आपने डॉकर के साथ काम किया है, तो डॉकर परत लंबोदर में परत के समान है - एक प्रकार का अर्ध-भंडार जिसमें हमारी आवश्यक बंधन स्थित है। वहां हमारे पास पर्यावरण की निष्पादन योग्य फ़ाइल है (यदि हम PHP के बारे में बात कर रहे हैं, तो आपको संकलित PHP बाइनरी को पहले से रखना चाहिए), लैम्ब्डा बूटस्ट्रैप फ़ाइल (डिफ़ॉल्ट रूप से स्थित) और सीधे निष्पादित स्क्रिप्ट्स जिसे निष्पादित किया जाएगा।

प्रसव के साथ, सब कुछ इतना रसीला नहीं है:

यही है, हमें कोड के साथ फ़ाइलें लेने की पेशकश की जाती है, इसे ज़िप संग्रह पर अपलोड करें, इसे परत पर अपलोड करें और अपना कोड चलाएं। यह पूरी तरह से शांत है कि यह अमेज़न के आधिकारिक दस्तावेज में पेश किया गया है।

बेशक, यह आधुनिक वास्तविकताओं और हवा में दो हजारवें हिस्से की गंध के अनुरूप नहीं है। सौभाग्य से, दयालु लोगों ने कोशिश की और कई रूपरेखाएँ बनाईं, इसलिए हम Node.js पर विकसित सर्वर रहित फ्रेमवर्क का उपयोग करेंगे और हमें AWS लैम्ब्डा पर आधारित अनुप्रयोगों का प्रबंधन करने की अनुमति देंगे। इसके अलावा, जब हम तैनाती और विकास के बारे में बात करते हैं, निश्चित रूप से, मैं वास्तव में मैन्युअल रूप से तैनात नहीं करना चाहता हूं, लेकिन कुछ लचीला और स्वचालित करने की इच्छा है।

तो, हमें इसकी आवश्यकता है:
- एडब्ल्यूएस सीएलआई - एडब्ल्यूएस सेवाओं के साथ काम करने के लिए कमांड लाइन इंटरफ़ेस;
- पहले से ही उल्लेखित सर्वर रहित ढांचा (विकास संस्करण मुक्त है, और इसकी कार्यक्षमता आंखों के लिए पर्याप्त है);
- Bref पुस्तकालय, जो कोड लिखने के लिए आवश्यक है। यह लाइब्रेरी कंपोजर का उपयोग करके स्थापित की गई है, इसलिए कोड किसी भी ढांचे के साथ संगत होगा। एक महान समाधान, विशेष रूप से यह देखते हुए कि AWS लैम्ब्डा बॉक्स से बाहर PHP स्क्रिप्ट को कॉल करने का समर्थन नहीं करता है।

अपने पर्यावरण और AWS को अनुकूलित करें

AWS सीएलआई

आइए एक खाता बनाकर और AWS CLI स्थापित करके शुरू करें। AWS कंसोल शेल पायथन 2.7+ या 3.4+ पर आधारित है। चूंकि AWS पायथन के संस्करण 3 की सिफारिश करता है, हम बहस नहीं करेंगे।
नीचे दिए गए उदाहरण उबंटू के लिए हैं।

sudo apt-get -y install python3-pip 

फिर सीधे AWS CLI स्थापित करें:

 pip3 install awscli --upgrade --user 

स्थापना की जाँच करें:

 aws --version 

अब आपको AWS CLI को अपने खाते से जोड़ना होगा। आप अपने मौजूदा उपयोगकर्ता नाम और पासवर्ड का उपयोग कर सकते हैं, लेकिन बेहतर होगा कि आप AWS IAM के माध्यम से एक अलग उपयोगकर्ता बनाएं, उसे केवल आवश्यक एक्सेस अधिकारों को परिभाषित करें। कॉन्फ़िगरेशन को कॉल करने से समस्याएं नहीं होंगी:

 aws configure 

इसके बाद, आपको AWS सीक्रेट और AWS एक्सेस कुंजी की आवश्यकता होगी। उन्हें "सुरक्षा क्रेडेंशियल" टैब में एएसडब्ल्यू IAM में प्राप्त किया जा सकता है (वांछित उपयोगकर्ता के पृष्ठ पर स्थित)। "एक्सेस कुंजी बनाएँ" बटन पहुँच कुंजी उत्पन्न करने में मदद करेगा। उन्हें अपने पास रखो।

टेलीग्राम में एक नया बॉट रजिस्टर करने के लिए, @BotFather और / newbot कमांड का उपयोग करें। परिणामस्वरूप, आपके बॉट से जुड़ने के लिए आवश्यक टोकन आपको वापस कर दिया जाएगा। इसे भी बंद कर दो।

सर्वरहित ढांचा

सर्वरलेस फ्रेमवर्क को स्थापित करने के लिए, आपको 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 

/ etc / पर्यावरण फ़ाइल के लिए।
अब सर्वर रहित:

 npm install -g serverless 

एडब्ल्यूएस

खैर, यह AWS इंटरफेस पर स्विच करने और एक डोमेन नाम जोड़ने का समय है। हम इसके लिए AWS रूट 53 ज़ोन, DNS रिकॉर्ड और SSL प्रमाणपत्र बनाते हैं।
इसके अलावा, आपको ईएलबी की आवश्यकता है, जिसे हम सेवा ईसी 2 -> लोड बैलेंसर्स में बनाते हैं। वैसे, ईएलबी बनाते समय, आपको विज़ार्ड के सभी चरणों से गुजरने की आवश्यकता होती है, जो बनाए गए प्रमाण पत्र को दर्शाता है।

बैलेंसर के लिए, आप इसे निम्न आदेश का उपयोग करके 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 का उपयोग करेंगे। जैसा कि पहले उल्लेख किया गया है, इस पुस्तकालय को संगीतकार का उपयोग करके स्थापित किया गया है, इसलिए कोड किसी भी ढांचे के साथ संगत होगा। वैसे, डेवलपर्स ने ब्रेफ को लारवेल और सिम्फनी के साथ उपयोग करने की प्रक्रिया का वर्णन किया है। लेकिन हमारे लिए "नंगे" PHP पर काम करना उचित है - यह सार को बेहतर ढंग से समझने में मदद करेगा।
हम निर्भरता से शुरू करते हैं:

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

हम PHP 7.2 और उच्चतर में लिखेंगे, और टेलीग्राम के साथ एपीआई के लिए यह शेल हमारे लिए उपयुक्त है - https://github.com/TelegramBot/Api । कोड के लिए ही, इसे src डायरेक्टरी में रखा जाएगा।

तो, सर्वर रहित वातावरण एक कंसोल संवाद से गुजर रहा है। एक HTTP एप्लिकेशन की आवश्यकता है, और लैम्ब्डा के दृष्टिकोण से, इसका मतलब यह होगा कि स्क्रिप्ट कॉल को उसी तरह से निष्पादित किया जाएगा जैसे कि नग्नेक्स करता है। PHP-FPM द्वारा व्याख्या की जाएगी। सामान्य तौर पर, यह मानक कंसोल स्क्रिप्ट कॉल की तरह अधिक होता है। यह एक महत्वपूर्ण बिंदु है, क्योंकि इस सुविधा को ध्यान में रखे बिना, हम HTTP के माध्यम से स्क्रिप्ट को कॉल करने में सक्षम नहीं होंगे।
हम बाहर ले:

 vendor/bin/bref init 

संवाद में, "HTTP एप्लिकेशन" आइटम का चयन करें और क्षेत्र को निर्दिष्ट करने के लिए मत भूलना, क्योंकि आवेदन उसी क्षेत्र में काम करना चाहिए जिसमें बैलेंसर काम करता है।
आरंभीकरण के बाद, 2 नई फाइलें दिखाई देंगी:
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} 

अब गैर-स्पष्ट रेखाओं का विश्लेषण करते हैं। हमें ज्यादातर पर्यावरण चर की आवश्यकता होती है। हम डेटाबेस कनेक्शन, बाहरी एपीआई, आदि को हार्डकोड नहीं करना चाहते हैं। यदि हम टेलीग्राम से जुड़ते हैं, तो हमारा अपना टोकन होगा, जो कि बोटफादर से प्राप्त होता है। और इस टोकन को serverless.yml में स्टोर करने की अनुशंसा नहीं की जाती है, इसलिए इसे AWS ssm स्टोरेज में भेजना बेहतर है:

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

वैसे, हम कॉन्फ़िगरेशन में इसका उल्लेख कर रहे हैं।
ये चर पर्यावरण चर के रूप में उपलब्ध हैं, और आप उन्हें getenv फ़ंक्शन का उपयोग करके PHP में एक्सेस कर सकते हैं। अगर हम अपने उदाहरण के बारे में बात करते हैं, तो आइए सादगी के लिए बॉट टोकन को वैश्विक दायरे में रखें। हम एकल फ़ंक्शन के दायरे में टोकन को भी स्थानांतरित कर सकते हैं, और कॉल स्वयं इससे नहीं बदलेगी।

चलो आगे बढ़ते हैं। आइए अब एक साधारण BotApp क्लास बनाएं - यह बॉट के लिए एक प्रतिक्रिया उत्पन्न करने के लिए ज़िम्मेदार होगा और आदेशों का जवाब देगा। टेलीग्राम डेवलपर्स सभी बॉट के लिए / सहायता और / स्टार्ट कमांड के लिए समर्थन जोड़ने की सलाह देते हैं। मस्ती के लिए एक और कमांड जोड़ते हैं। कक्षा खुद काफी सरल है और कॉल फ़ाइल को लोड किए बिना 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 

सामान्य मोड में, सर्वर रहित फ़ाइलों को ज़िप अभिलेखागार में पैक करेगा, एक S3-बकेट बनाएँ जहाँ उन्हें रखना है, फिर लैम्ब्डा से जुड़ा AWS एप्लिकेशन बनाएं या अपडेट करें, और कोड और रनटाइम को एक अलग परत में रखें।

1 लॉन्च के दौरान, गेटवे एपीआई बनाया जाएगा (हमने इसे कॉल टेस्ट करने में आसान बनाने के लिए छोड़ दिया, लेकिन फिर इसे हटाने की सलाह दी जाती है)। आपको एल्ब के माध्यम से लैंबडा कॉल को कॉन्फ़िगर करने की भी आवश्यकता होगी, जिसके लिए हम फ़ंक्शन कंट्रोल विंडो में "ट्रिगर जोड़ें" चुनें और ड्रॉप-डाउन सूची में "एप्लिकेशन लोड बैलेंसर" चुनें। आपको पहले बनाए गए ELB को निर्दिष्ट करने की आवश्यकता होगी, HTTPS के माध्यम से कनेक्शन सेट करें, होस्ट खाली छोड़ दें, और पथ में वह पथ निर्दिष्ट करें जिसे लैंबडा कॉल करेगा (उदाहरण के लिए, / lambda / mytgbot)। नतीजतन, आपका लैम्बडा निर्दिष्ट पथ के साथ URL पर उपलब्ध होगा।

अब आप टेलीग्राम में बॉट के प्रतिक्रिया भाग को पंजीकृत कर सकते हैं ताकि संदेश समझने वाले को संदेश मिल सके। ऐसा करने के लिए, ब्राउज़र में निम्न URL को कॉल करें, लेकिन अपने स्वयं के मापदंडों को इसमें बदलना न भूलें:

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

नतीजतन, एपीआई "ओके" लौटाएगा, जिसके बाद बॉट उपलब्ध हो जाएगा।

स्थानों पर बॉट का परीक्षण

तैनाती से पहले बॉट का परीक्षण किया जा सकता है। तथ्य यह है कि सर्वर रहित फ्रेमवर्क इसके लिए डॉकर कंटेनरों का उपयोग करने वाले स्थानों पर लॉन्च करने का समर्थन करता है। कॉल कमांड:

 sls invoke local --docker -f myFunction 

यह मत भूलो कि हमने पर्यावरण चर का उपयोग किया है, इसलिए कॉल के दौरान उन्हें प्रारूप में भी सेट किया जाना चाहिए:

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

लॉग

डिफ़ॉल्ट रूप से, कॉल आउटपुट को क्लाउडवॉच में लॉग इन किया जाएगा - यह संबंधित लैम्ब्डा फ़ंक्शन के मॉनिटरिंग पैनल में उपलब्ध है। यहां आप PHP की तरफ डंप होने की स्थिति में कॉल ट्रैस पढ़ सकते हैं। इसके अलावा, आप उन्नत निगरानी सेवाओं को कनेक्ट कर सकते हैं, लेकिन उन्हें हर महीने अतिरिक्त कुछ सेंट खर्च होंगे।

कुल मिलाकर

नतीजतन, हमें एक त्वरित, लचीला, स्केलेबल, और अपेक्षाकृत सस्ती समाधान भी मिला। हां, लैम्बडा हमेशा मानक वीएम और कंटेनरों की तुलना में नहीं जीतता है, लेकिन ऐसी परिस्थितियां हैं जब सर्वर रहित एप्लिकेशन जल्दी और कुशलता से "शूट" करने में मदद करता है। और निर्मित बॉट का उदाहरण केवल यह प्रदर्शित करता है।
विषय पर उपयोगी सामग्री:

• Bref प्रलेखन
• लैम्ब्डा सिद्धांत ;
• लैम्ब्डा शरीर रचना ;
• सर्वरहित फ्रेमवर्क
• PHP और AWS लैम्ब्डा पर आधारित सर्वर रहित टेलीग्राम बॉट ।