सर्वरलेस और रिएक्ट 2: स्लीट ऑफ़ हैंड एंड नो फ्रॉड

क्या मैं सरल तरीके से AWS (Amazon Web Services) के भीतर क्लाउडलेस सर्वर रहित आर्किटेक्चर के बारे में फ्रंट-एंड डेवलपर्स को बता सकता हूं? क्यों नहीं? आइए AWS React / Redux एप्लिकेशन को रेंडर करते हैं, और फिर AWS लैम्ब्डा के पेशेवरों और विपक्षों के बारे में बात करते हैं।


यह सामग्री सेंट पीटर्सबर्ग में हमारे वसंत होलीज 2018 सम्मेलन से मरीना मिरोनिविच की रिपोर्ट के प्रतिलेख पर आधारित है।

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

सबसे पहले, मुझे सभी क्लाउड प्रौद्योगिकियों में दिलचस्पी है, विशेष रूप से, एडब्ल्यूएस, क्योंकि मैं उत्पादन में बहुत काम करता हूं। लेकिन मैं हर चीज के साथ बने रहने की कोशिश करता हूं।

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

भाग 1. पृष्ठभूमि

Serverless के बारे में बात करने का विचार मुझे लगभग एक साल पहले आया था। मैं फ्रंट-एंड डेवलपर्स के लिए सर्वरलेस के बारे में आसानी से और स्वाभाविक रूप से बात करना चाहता था। ताकि आपको इसका उपयोग करने के लिए किसी अतिरिक्त ज्ञान की आवश्यकता न हो, अब अधिक प्रौद्योगिकियां आपको ऐसा करने की अनुमति देती हैं।

कुछ हद तक, इस विचार का एहसास हुआ - मैंने फ्रंटलैक्स 2017 में सर्वरलेस के बारे में बात की । लेकिन यह पता चला कि 45 मिनट एक सरल और समझने योग्य कहानी के लिए पर्याप्त नहीं है। इसलिए, रिपोर्ट को दो भागों में विभाजित किया गया था, और अब आपके सामने दूसरी "श्रृंखला" है। पहले किसने नहीं देखा - चिंता न करें, यह समझने के लिए दुख नहीं होगा कि नीचे क्या लिखा गया है। जैसा कि सभ्य टीवी शो में होता है, मैं पिछले भाग के सारांश के साथ शुरू करूँगा। फिर मैं स्वयं रस पर आगे बढ़ूंगा - हम रिएक्ट / रिडक्स एप्लिकेशन को प्रस्तुत करेंगे। और अंत में, मैं सिद्धांत रूप में क्लाउड फ़ंक्शंस के पेशेवरों और विपक्षों के बारे में बात करूंगा (विशेष रूप से, एडब्ल्यूएस लंबदा) और उनके साथ और क्या किया जा सकता है। मुझे उम्मीद है कि यह हिस्सा उन सभी के लिए उपयोगी होगा जो पहले से ही एडब्ल्यूएस लंबो से परिचित हैं। सबसे महत्वपूर्ण बात, दुनिया अमेज़ॅन के साथ समाप्त नहीं होती है, तो चलिए बात करते हैं कि क्लाउड फ़ंक्शन के क्षेत्र में और क्या है।

मैं क्या उपयोग करूंगा

एप्लिकेशन रेंडर करने के लिए, मैं कई अमेज़ॅन सेवाओं का उपयोग करूंगा:

1. S3 बादलों में एक फाइल सिस्टम है। वहां हम स्थैतिक संपत्ति का भंडारण करेंगे।
   
2. IAM (उपयोगकर्ताओं और सेवाओं के लिए एक्सेस अधिकार) - संक्षेप में, लेकिन इसका उपयोग पृष्ठभूमि में किया जाएगा ताकि सेवाएं एक-दूसरे के साथ संवाद करें।
   
3. एपीआई गेटवे (साइट तक पहुंचने के लिए URL) - आपको वह URL दिखाई देगा जहां हम अपने लंबो को कॉल कर सकते हैं।
   
4. CloudFormation (परिनियोजन के लिए) - पृष्ठभूमि में अंतर्निहित रूप से उपयोग किया जाएगा।
   
5. AWS लाम्बा - हम इसके लिए यहां आए।
   

सर्वर रहित क्या है और AWS लैम्ब्डा क्या है?

वास्तव में सर्वरलेस एक बड़ा धोखा है, क्योंकि निश्चित रूप से सर्वर हैं: कहीं, यह सब शुरू होता है। लेकिन वहां क्या हो रहा है?

हम एक फ़ंक्शन लिख रहे हैं, और यह फ़ंक्शन सर्वर पर चलता है। बेशक, यह न केवल उस तरह से शुरू होता है, बल्कि किसी प्रकार के कंटेनर में भी होता है। और, वास्तव में, सर्वर पर कंटेनर में इस फ़ंक्शन को लैंबडा कहा जाता है।


लंबोदर के मामले में, हम सर्वर के बारे में भूल सकते हैं। मैं यह भी कहूंगा: जब आप लंबोदा फ़ंक्शन लिखते हैं, तो उनके बारे में सोचना हानिकारक है। हम लैंबडा के साथ काम नहीं करते हैं जिस तरह से हम सर्वर के साथ करते हैं।

लंबोदर को कैसे तैनात किया जाए

एक तार्किक प्रश्न उठता है: अगर हमारे पास सर्वर नहीं है, तो हम इसे कैसे तैनात करते हैं? सर्वर पर एसएसएच है, हमने कोड अपलोड किया, इसे लॉन्च किया - सब कुछ ठीक है। लंबोदर का क्या करें?

विकल्प 1. हम इसे तैनात नहीं कर सकते।

कंसोल में AWS ने हमारे लिए एक अच्छा और सौम्य IDE बनाया, जहाँ हम आ सकते हैं और वहीं फंक्शन लिख सकते हैं।



यह अच्छा है, लेकिन बहुत एक्स्टेंसिबल नहीं है।

विकल्प 2. हम एक ज़िप बना सकते हैं और इसे कमांड लाइन से डाउनलोड कर सकते हैं

हम ज़िप फ़ाइल कैसे बनाते हैं?

zip -r build/lambda.zip index.js [node_modules/] [package.json]

यदि आप node_modules का उपयोग करते हैं, तो यह सब एक संग्रह में ज़िपित हो जाता है।
इसके अलावा, इस पर निर्भर करता है कि आप एक नया फ़ंक्शन बना रहे हैं या यदि आपके पास पहले से ही ऐसा फ़ंक्शन है, तो आप या तो करते हैं

aws lambda create-function...

या

aws lambda update-function-code...

क्या समस्या है? सबसे पहले, AWS सीएलआई जानना चाहता है कि क्या कोई फ़ंक्शन बनाया जा रहा है या यदि आपके पास पहले से ही एक है। ये दो अलग-अलग टीमें हैं। यदि आप न केवल कोड, बल्कि इस फ़ंक्शन की कुछ विशेषताओं को भी अपडेट करना चाहते हैं, तो समस्याएं शुरू होती हैं। इन आदेशों की संख्या बढ़ रही है, और आपको एक निर्देशिका के साथ बैठना होगा और सोचना होगा कि किस कमांड का उपयोग करना है।

हम इसे बेहतर और आसान बना सकते हैं। इसके लिए हमारे पास चौखटे हैं।

AWS लाम्बा चौखटे

ऐसे कई ढांचे हैं। यह मुख्य रूप से AWS CloudFormation है, जो AWS CLI के साथ मिलकर काम करता है। CloudFormation आपकी सेवाओं का वर्णन करने वाली एक Json फ़ाइल है। आप उन्हें एक JSON फ़ाइल में वर्णित करते हैं, तो AWS CLI के माध्यम से "निष्पादित करें" कहते हैं, और यह स्वचालित रूप से आपके लिए AWS सेवा में सब कुछ बना देगा।

लेकिन इस तरह के एक सरल कार्य के लिए अभी भी कुछ प्रदान करना मुश्किल है। यहां प्रवेश सीमा बहुत बड़ी है - आपको यह पढ़ने की आवश्यकता है कि क्लाउडफ़ॉर्मेशन की संरचना क्या है, आदि।

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

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

ज़प्पा केवल पायथन के लिए लिखा गया था। और मैं कुछ और महत्वाकांक्षी चाहता हूं। और यहाँ टेराफॉर्म और मेरा सर्वरलेस प्रेम आता है।

सर्वरलेस बहुत बड़े CloudFormation के बीच में कहीं है, जो लगभग सब कुछ कर सकता है, और ये बेहद विशिष्ट फ्रेमवर्क हैं। इसमें लगभग सब कुछ तैनात किया जा सकता है, लेकिन यह सब करना अभी भी काफी आसान है। इसमें बहुत हल्का वाक्यविन्यास भी है।

टेराफॉर्म कुछ हद तक, CloudFormation का एक एनालॉग है। टेराफ़ॉर्म एक खुला स्रोत है, इसमें आप सब कुछ - अच्छी तरह से, या लगभग सब कुछ तैनात कर सकते हैं। और जब AWS सेवाएं बनाता है, तो आप वहां कुछ नया जोड़ सकते हैं। लेकिन यह बड़ा और जटिल है।

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

serverless

मुझे सर्वरहित से प्यार क्यों है?

1. सर्वरलेस में एक सिस्टम है जो आपको प्लगइन्स बनाने की अनुमति देता है। मेरी राय में, यह सब कुछ से मुक्ति है। सर्वरहित - खुला स्रोत। लेकिन खुले स्रोत में कुछ जोड़ना हमेशा आसान नहीं होता है। आपको यह समझने की आवश्यकता है कि मौजूदा कोड में क्या हो रहा है, दिशा-निर्देशों का पालन करें, कम से कम कोडेइस्ट, एक पीआर सबमिट करें, वे इस पीआर के बारे में भूल जाएंगे और यह तीन साल तक धूल इकट्ठा करेगा। परिणामों के अनुसार, आप कांटा, और यह आपके लिए अलग से कहीं होगा। यह सब बहुत स्वस्थ नहीं है। लेकिन जब प्लगइन्स होते हैं, तो सब कुछ सरल होता है। आपको कुछ जोड़ने की ज़रूरत है - आप घुटने पर अपना खुद का छोटा प्लगइन बना रहे हैं। ऐसा करने के लिए, आपको अब यह समझने की आवश्यकता नहीं है कि सर्वरलेस के अंदर क्या हो रहा है (यदि यह एक सुपर-कस्टम प्रश्न नहीं है)। आप बस उपलब्ध एपीआई का उपयोग करते हैं, कहीं न कहीं आप प्लगइन को बचाते हैं या इसे सभी के लिए तैनात करते हैं। और आपके लिए सब कुछ काम करता है। इसके अलावा, पहले से ही प्लगइन्स का एक बड़ा चिड़ियाघर है और जो लोग इन प्लगइन्स को लिखते हैं। यही है, शायद आपके लिए कुछ तय हो चुका है।
   
2. सर्वरलेस स्थानीय रूप से लैम्ब्डा को चलाने में मदद करता है। लैम्ब्डा का बड़ा पर्याप्त ऋण यह है कि AWS ने यह नहीं सोचा था कि हम इसे कैसे डिबग करेंगे और इसका परीक्षण करेंगे। लेकिन सर्वरलेस आपको स्थानीय रूप से सब कुछ चलाने की अनुमति देता है, देखें कि क्या होता है (वह गेटवे एपीआई के साथ मिलकर भी ऐसा करता है)।
   

प्रदर्शन

अब मैं दिखाऊंगा कि यह सब वास्तव में कैसे काम करता है। अगले डेढ़ से दो मिनट में, हम एक ऐसी सेवा बनाने में सक्षम होंगे जो हमारे HTML पेज को प्रस्तुत करेगी।
सबसे पहले, एक नए फ़ोल्डर में, मैं SLS Create टेम्प्लेट चलाता हूं:


mkdir sls-holyjs
cd sls-holyjs
sls create --template aws-nodejs-ecma-script



npm install



सर्वर रहित डेवलपर्स ने हमारी देखभाल की - टेम्प्लेट से सेवाएं बनाना संभव बना दिया। इस मामले में, मैं nodejs-ecma-script टेम्पलेट का उपयोग करता nodejs-ecma-script , जो मेरे लिए कुछ फाइलें बनाएगा, जैसे कि वेबपैक कॉन्फ़िगरेशन, पैकेज.जॉन, कुछ फ़ंक्शन और सर्वर रहित।

ls



मुझे सभी विशेषताओं की आवश्यकता नहीं है। मैं पवित्रों में पहला, दूसरा नाम हटा दूंगा:



मैं थोड़ी सी मेल नहीं खाता हूं। जहां मुझे सभी आवश्यक सेवाओं का विवरण है:



ठीक है, तो मैं उस प्रतिक्रिया को ठीक करूंगा जो फ़ंक्शन देता है:



मैं HTML "हैलो होल्जेस" बनाऊंगा और रेंडरिंग के लिए हैंडल जोड़ूंगा।

अगला:

sls deploy

और वोइला! एक URL है जहाँ मैं सार्वजनिक पहुँच में देख सकता हूँ कि क्या प्रस्तुत किया जा रहा है:



भरोसा है, लेकिन सत्यापित करें। मैं AWS कंसोल पर जाऊंगा और सत्यापित करूंगा कि मैंने एक पवित्र समारोह बनाया है:



जैसा कि आप देख सकते हैं, इसे तैनात करने से पहले, सर्वरलेस इसे वेबपैक का उपयोग करके बनाएगा। इसके अलावा, बाकी बुनियादी ढांचा जो वहां वर्णित है - बनाया जाएगा - एपीआई गेटवे, आदि।

जब मैं इसे निकालना चाहता हूं:

sls remove

Serverless.yml में वर्णित सभी बुनियादी ढांचे को हटा दिया जाएगा।



यदि कोई व्यक्ति यहां वर्णित प्रक्रिया के पीछे है, तो मैं आपको अपनी पिछली रिपोर्ट की समीक्षा करने के लिए आमंत्रित करता हूं।

लंबोदर को स्थानीय स्तर पर चलाएं

मैंने उल्लेख किया है कि लैम्ब्डा को स्थानीय रूप से चलाया जा सकता है। यहां दो लॉन्च विकल्प हैं।

विकल्प 1. हम टर्मिनल में सब कुछ चलाते हैं

हमें वही मिलता है जो हमारा फंक्शन वापस करता है।


sls invoke local -f [fn_name]

विकल्प 2. स्थानीय रूप से सर्वर रहित ऑफ़लाइन लैम्ब्डा लॉन्च करें

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

ऐसा करने के लिए, एक अलग सर्वर रहित-ऑफ़लाइन प्लगइन है जो आपके लैंबडा को कुछ पोर्ट (यह लिखा गया है) पर लॉन्च करेगा, फिर यह टर्मिनल में एक URL प्रदर्शित करेगा जहां आप इसे एक्सेस कर सकते हैं।

sls offline --port 8000 start

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

यह रिपोर्ट के पहले भाग का सारांश था। अब हम मुख्य भाग की ओर बढ़ते हैं।

भाग 2. AWS के साथ प्रतिपादन

नीचे वर्णित परियोजना GitHub पर पहले से ही है। यदि आप रुचि रखते हैं, तो आप वहां कोड डाउनलोड कर सकते हैं।

आइए इसकी शुरुआत करें कि यह कैसे काम करता है।



मान लीजिए कि कोई उपयोगकर्ता है - मैं।

• मैं साइट खोलता हूं।
  
• एक निश्चित URL पर, हम प्रवेश द्वार API तक पहुँचते हैं। मैं यह नोट करना चाहता हूं कि गेटवे एपीआई पहले से ही एक एडब्ल्यूएस सेवा है, हम पहले से ही बादलों में हैं।
  
• गेटवे एपीआई को लंबा कहेंगे।
  
• लैम्ब्डा साइट को रेंडर करेगा, और यह सब ब्राउज़र पर वापस आ जाएगा।
  
• ब्राउज़र रेंडर करना शुरू कर देगा और महसूस करेगा कि कुछ स्थिर फाइलें गायब हैं। फिर वह एस 3 बाल्टी (हमारी फाइल सिस्टम, जहां हम सभी स्टैटिक्स स्टोर करेंगे, एस 3 बाल्टी में आप सब कुछ डाल सकते हैं - फोंट, पिक्चर, सीएसएस, जेएस)।
  
• S3 बाल्टी से डेटा ब्राउज़र में वापस आ जाएगा।
  
• ब्राउज़र पेज को रेंडर करेगा।
  
• सभी लोग खुश हैं।
  

आइए मैंने जो कुछ लिखा है, उसकी थोड़ी कोड समीक्षा करें।

यदि आप GitHub पर जाते हैं, तो आपको निम्न फ़ाइल संरचना दिखाई देगी:

lambda-react
README.md
config
package.json
public
scripts
serverless.yml
src
yarn.lock

यह सब स्वचालित रूप से प्रतिक्रिया / Redux टूल किट में उत्पन्न होता है। वास्तव में, यहाँ हम केवल कुछ फाइलों में रुचि लेंगे और उन्हें थोड़ा सही करना होगा:

• config
  
• package.json
  
• serverless.yml - क्योंकि हम तैनात करेंगे,
  
• src - इसके बिना कहीं नहीं।
  

चलो विन्यास के साथ शुरू करते हैं

सर्वर पर सब कुछ एक साथ करने के लिए, हमें एक और webpack.config जोड़ना होगा:



यदि आप टेम्प्लेट का उपयोग करते हैं तो यह webpack.config आपके लिए पहले से ही जेनरेट हो जाएगा। और वहाँ slsw.lib.entries चर को स्वचालित रूप से प्रतिस्थापित किया जाता है, जो आपके slsw.lib.entries हैंडलर को इंगित करेगा। यदि आप चाहें, तो आप कुछ और निर्दिष्ट करके इसे स्वयं बदल सकते हैं।



हमें नोड ( target: 'node' ) के लिए सब कुछ प्रस्तुत करना होगा। सिद्धांत रूप में, अन्य सभी लोडर एक नियमित रिएक्ट एप्लिकेशन के समान ही रहते हैं।

इसके अलावा package.json को

हम सिर्फ कुछ स्क्रिप्ट जोड़ेंगे - शुरू करें और निर्माण पहले से ही प्रतिक्रिया / Redux के साथ उत्पन्न हुए हैं - कुछ भी नहीं बदलता है। लैम्ब्डा लॉन्च करने के लिए एक स्क्रिप्ट जोड़ें और लैम्ब्डा को तैनात करने के लिए एक स्क्रिप्ट।

serverless.yml

एक बहुत छोटी फ़ाइल - केवल 17 लाइनें, उनमें से सभी नीचे:



इसमें हमारे लिए क्या दिलचस्प है? सबसे पहले, हैंडलर। फ़ाइल का पूरा पथ src/lambda/handler ( src/lambda/handler ) और हैंडलर फ़ंक्शन डॉट के माध्यम से निर्दिष्ट किया गया है।

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

सबसे दिलचस्प src है

यहाँ एक बड़ा रिएक्ट / रिडक्स एप्लिकेशन है (मेरे मामले में यह बहुत बड़ा नहीं है - पेज पर)। अतिरिक्त लैम्ब्डा फ़ोल्डर में वह सब कुछ है जो हमें लैम्बडा को प्रस्तुत करने की आवश्यकता है:



ये 2 फाइलें हैं:



शुरुआत करते हैं हैंडलर से। सबसे महत्वपूर्ण पंक्ति 13 है। यह रेंडरर है, जो बहुत ही लम्बा है जिसे बादलों में बुलाया जाएगा:



जैसा कि आप देख सकते हैं, render () फ़ंक्शन एक वादा लौटाता है, जिसमें से सभी अपवादों को पकड़ा जाना चाहिए। यह लैम्ब्डा की ख़ासियत है, अन्यथा लैम्बडा तुरंत समाप्त नहीं होगा, लेकिन टाइमआउट तक काम करेगा। आपको एक कोड के लिए अतिरिक्त पैसे का भुगतान करना होगा जो पहले ही गिर चुका है। ऐसा होने से रोकने के लिए, आपको लैम्ब्डा को जितनी जल्दी हो सके खत्म करने की आवश्यकता है - सबसे पहले, सभी अपवादों को पकड़ना और संभालना। बाद में हम इस पर वापस आएंगे।

यदि हमारे पास कोई त्रुटि या अपवाद नहीं है, तो हम createResponse फ़ंक्शन को कॉल करते हैं, जिसमें शाब्दिक रूप से पाँच लाइनें होती हैं। हम केवल सभी हेडर जोड़ते हैं ताकि यह ब्राउज़र में सही तरीके से प्रस्तुत हो:



यहाँ सबसे दिलचस्प बात है render फंक्शन, जो हमारे पेज को रेंडर करेगा:



यह फ़ंक्शन रेंडरर.जेएस से हमारे पास आता है। आइये देखते हैं क्या है।

एक आइसोमोर्फिक एप्लिकेशन वहां प्रस्तुत किया गया है। इसके अलावा, यह किसी भी सर्वर पर प्रदान किया जाता है - इससे कोई फर्क नहीं पड़ता कि यह लैम्ब्डा है या नहीं।

मैं आपको इस बारे में विस्तार से नहीं बताऊंगा कि एक आइसोमोर्फिक एप्लिकेशन क्या है, इसे कैसे प्रस्तुत करना है, क्योंकि यह एक पूरी तरह से अलग विषय है, और ऐसे लोग हैं जिन्होंने इसे मुझसे बेहतर बताया है। यहाँ कुछ ट्यूटोरियल दिए गए हैं जिन्हें मैंने कुछ मिनटों में गुगली करके पाया:



यदि आप कोई अन्य रिपोर्ट जानते हैं, तो आप सलाह दे सकते हैं, मैं उन्हें अपने ट्विटर पर लिंक दूंगा।

किसी को नहीं खोने के लिए, मैं सिर्फ ऊपर जाता हूं, बताओ कि वहां क्या हो रहा है।
सबसे पहले, हमें इसे HTML / React / Redux के साथ प्रस्तुत करना होगा।

यह मानक प्रतिक्रिया विधि के माध्यम से किया जाता है -



आगे हमें शैलियों को प्रस्तुत करने की आवश्यकता है ताकि हमारी सामग्री को झपकी न आए। यह बहुत तुच्छ कार्य नहीं है। कई npm पैकेज हैं जो इसे हल करते हैं। उदाहरण के लिए, मैंने node-style-loader उपयोग किया, जो styleTag में सब कुछ एक साथ रख styleTag , और फिर आप इसे HTML में पेस्ट कर सकते हैं।



यदि बेहतर पैकेज हैं - यह आपके विवेक पर है।

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


अब मेमने के थोड़ा करीब।

त्रुटि हैंडलिंग करना आवश्यक है। हम सब कुछ पकड़ना चाहते हैं और उनके साथ कुछ करना चाहते हैं, कम से कम लंबोदर के विकास को रोकें। उदाहरण के लिए, मैंने यह promise किया था:



अगला, हमें स्थैतिक फ़ाइलों के लिए अपने URL को स्थानापन्न करना होगा। और इसके लिए हमें यह पता लगाना होगा कि लैम्ब्डा कहाँ चलता है - स्थानीय रूप से या बादलों में कहीं। कैसे पता करें?

हम पर्यावरण चर के माध्यम से ऐसा करेंगे:



…
const bundleUrl = process.env.NODE_ENV === 'AWS' ?
AWS_URL : LOCAL_URL;

एक दिलचस्प सवाल: लैम्ब्डा में पर्यावरण चर कैसे एक साथ मिलते हैं। वास्तव में काफी आसान है। Yml में, आप environment किसी भी चर को पास कर सकते environment । जब यह बंद हो जाएगा, तो वे उपलब्ध होंगे:



खैर, एक बोनस - हम एक लंबोदा तैनात करने के बाद, हम सभी स्थिर संपत्ति तैनात करना चाहते हैं। ऐसा करने के लिए, हमने पहले से ही एक प्लगइन लिखा है जहां आप S3 टोकरी को नामित कर सकते हैं जहां आप कुछ तैनात करना चाहते हैं:


कुल मिलाकर, हमने यह दिखाने के लिए कि यह सब आसान है, लगभग पांच मिनट में एक आइसोमॉर्फिक एप्लिकेशन बनाया।

अब आइए सिद्धांत के बारे में थोड़ा बात करते हैं - लैम्ब्डा के पेशेवरों और विपक्षों।

बुरे से शुरू करते हैं।

विपक्ष लाम्बा कार्यों

ठंड शुरू होने के समय में minuses शामिल हो सकते हैं (या शायद नहीं)। उदाहरण के लिए, Node.js पर लंबोदर के लिए जो हम अभी लिख रहे हैं, ठंड शुरू होने का समय बहुत ज्यादा नहीं है।

नीचे दिया गया ग्राफ ठंड के शुरुआती समय को दर्शाता है। और यह एक बड़ा सौदा हो सकता है, विशेष रूप से जावा और सी # के लिए (नारंगी डॉट्स पर ध्यान दें) - आप यह नहीं चाहते हैं कि कोड को निष्पादित करना शुरू करने के लिए केवल पांच से छह सेकंड लगें।

Node.js के लिए, प्रारंभ समय लगभग शून्य है - 30 - 50 एमएस। बेशक, कुछ के लिए यह एक समस्या भी हो सकती है। लेकिन कार्यों को गर्म किया जा सकता है (हालांकि यह इस रिपोर्ट का विषय नहीं है)। अगर किसी को भी दिलचस्पी है कि इन परीक्षणों को कैसे किया गया, तो acloud.guru में आपका स्वागत है, वे आपको सब कुछ बताएंगे ( लेख में )।



तो डाउनसाइड क्या हैं?

समारोह कोड आकार सीमाएँ

कोड 50 एमबी से कम होना चाहिए। क्या इतने बड़े समारोह को लिखना संभव है? कृपया node_modules के बारे में मत भूलना। यदि आप कुछ कनेक्ट करते हैं, खासकर अगर वहां बाइनरी फाइलें हैं, तो आप ज़िप फ़ाइलों के लिए भी आसानी से 50 एमबी से अधिक जा सकते हैं। मेरे पास ऐसे मामले आए हैं। लेकिन यह देखने का एक अतिरिक्त कारण है कि आप नोड_मॉडल से क्या कनेक्ट कर रहे हैं।

रनटाइम सीमाएँ

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

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



एक छोटी सी टिप्पणी। AWS के लिए, यह अब कोई समस्या नहीं है। उन्होंने पाया कि यह कैसे प्राप्त करें। लेकिन आम तौर पर बोलते हुए, जैसे ही वेब सॉकेट दिखाई देते हैं, लैम्ब्डा आपके लिए कोई समाधान नहीं है। आपको अच्छे पुराने सर्वर पर फिर से स्विच करने की आवश्यकता है।

प्रति मिनट समानांतर कार्यों की संख्या

आप जिस क्षेत्र में हैं, उसके आधार पर 500 से 3,000 की सीमा है। मेरी राय में, यूरोप में लगभग 500. 3000 संयुक्त राज्य अमेरिका में समर्थित है।

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

एक अनुरोध हमारे पास आता है, और हमें एक लंबोदर मिलता है। जबकि इस मेमने को निष्पादित किया जा रहा है, दो और अनुरोध हमारे पास आते हैं - हम दो और मेमने शुरू करते हैं। लोग हमारी साइट पर आने लगते हैं, अनुरोध प्रकट होते हैं और लंबोदा लॉन्च होते हैं, अधिक से अधिक।



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

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

यदि आपके लिए 3000 अनुरोधों का भार नियमित है, तो आप AWS में लिख सकते हैं और वे सीमा बढ़ा देंगे।

राज्यविहीन

यह आखिरी, फिर से, एक विवादास्पद माइनस है।

स्टेटलेस क्या है? यहाँ सुनहरी मछली के बारे में एक मज़ाक उठता है - वे केवल संदर्भ नहीं रखते हैं:



दूसरी बार कहे जाने वाले मेमने को पहले कॉल के बारे में कुछ नहीं पता।

मैं आपको एक उदाहरण दिखाता हूं। मान लीजिए कि मेरे पास एक सिस्टम है - एक बड़ा ब्लैक बॉक्स। और यह प्रणाली, अन्य बातों के अलावा, एसएमएस भेज सकती है।

उपयोगकर्ता आता है और कहता है: एसएमएस टेम्पलेट नंबर 1 भेजें। और सिस्टम इसे एक वास्तविक डिवाइस पर भेजता है।



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

जांच करने के लिए, हमें यह जानना होगा कि क्या भेजा गया था - हम एक परीक्षण आवेदन के माध्यम से ऐसा करेंगे। यह परिणामों की तुलना और प्रदर्शन करने के लिए बनी हुई है।



लैम्बडा पर ऐसा ही करने की कोशिश करते हैं।

लैंबडा भेजेगा एसएमएस, एसएमएस आएगा ट्वाइलियो



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

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

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



बिंगो!

बहुत शुरुआत में, मैंने कहा कि अगर आपको लैम्ब्डा लिखना है तो आपको सर्वर के बारे में भूलना होगा। मैं ऐसे लोगों से मिला जो नोड.जेएस पर लिखते हैं और सर्वर को व्यक्त करने के लिए उपयोग किए जाते हैं। वे कैश पर निर्भर रहना पसंद करते हैं, और कैश लैम्ब्डा में रहता है। और कभी-कभी, जब वे परीक्षण करते हैं, तो यह काम करेगा, और कभी-कभी नहीं। यह कैसे संभव है?

मान लीजिए हमारे पास एक सर्वर है, और इसमें एक कंटेनर शुरू होता है। कंटेनर लॉन्च करना काफी महंगा ऑपरेशन है। सबसे पहले, आपको इस कंटेनर को बनाने की आवश्यकता है। इसके निर्मित होने के बाद ही, फ़ंक्शन कोड को वहां तैनात किया जाता है और इसे निष्पादित किया जा सकता है। आपके फ़ंक्शन को निष्पादित करने के बाद, कंटेनर को नहीं मारा गया है, क्योंकि AWS का मानना ​​है कि आप इस फ़ंक्शन को फिर से कॉल कर सकते हैं। AWS ने कभी नहीं लिखा कि फ़ंक्शन बंद होने के बाद कंटेनर कितने समय तक रहता है। हमने प्रयोग किए। मेरी राय में, नोड के लिए यह तीन मिनट है, जावा के लिए वे 12-15 मिनट के लिए एक कंटेनर पकड़ सकते हैं। लेकिन इसका मतलब यह है कि जब अगला फ़ंक्शन कहा जाता है, तो इसे उसी कंटेनर में और उसी वातावरण में बुलाया जाएगा। यदि आप कहीं पर नोड कैश का उपयोग करते हैं, तो आप वहां चर बनाते हैं, आदि। - अगर आपने उन्हें साफ नहीं किया, तो वे वहीं रहेंगे। इसलिए अगर आप लंबोदर पर लिखते हैं,फिर आपको सामान्य रूप से कैश के बारे में भूलने की ज़रूरत है, अन्यथा आप अप्रिय स्थितियों में आ सकते हैं। यह कठिन है।

लैम्ब्डा कार्यों के प्लसस

उनमें से कम हैं, लेकिन मुझे वे अधिक सुखद लगते हैं।

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

लंबोदर पर और क्या किया जा सकता है?

मैंने एक काफी मानक उदाहरण दिया - मैंने एक आइसोमोर्फिक एप्लिकेशन को प्रस्तुत करने के बारे में बात की, क्योंकि मूल रूप से वे लैम्बदास को REST API मानते हैं। लेकिन मैं उनके साथ क्या किया जा सकता है इसके कुछ और उदाहरण देना चाहता हूं, सिर्फ आपको विचार और कल्पना के लिए भोजन देना।

सिद्धांत रूप में, लैम्ब्डा पर आप कुछ भी कर सकते हैं ... तारांकन के साथ।

• HTTP Services वह है जिसके बारे में मैं बात कर रहा था। बाकी एपीआई, प्रत्येक समापन बिंदु एपीआई एक लंबोदर है। यह पूरी तरह से मेल खाता है। खासतौर पर यह देखते हुए कि मिडलवेयर बनाने के लिए एंटरप्राइज अक्सर नोड.जे का उपयोग कैसे करता है। हमारे पास जावा है जो सभी लागतों को करता है, फिर हम जेएस पर एक परत लिखते हैं जो अनुरोधों को बहुत आसानी से संभालता है। यह लंबोदर में फिर से लिखा जा सकता है और ठंडा भी होगा।
  
• IoT — , Alexa - -, , .
  
• Chat Bots — , IoT.
  
• Image/Video conversions.
  
• Machine learning.
  
• Batch Jobs — - , Batch Job .
  

अब, अमेज़ॅन, Google, Azure, IBM, Twillio के अलावा, लगभग सभी बड़ी सेवाएँ अपने घर में क्लाउड फ़ंक्शंस लागू करना चाहती हैं। यदि Roskomnadzor सब कुछ ब्लॉक करता है, तो हम अपने गैरेज में एक छोटा सा पसंदीदा सर्वर शुरू करते हैं और अपने क्लाउड कंप्यूटिंग को वहां तैनात करते हैं। ऐसा करने के लिए, हमें खुले स्रोत की आवश्यकता है (सभी और अधिक क्योंकि आपको सेवाओं के लिए भुगतान करना होगा, और खुला स्रोत स्वतंत्र है)। और खुला स्रोत अभी भी खड़ा नहीं है। उन्होंने पहले से ही इस सब के कार्यान्वयन की एक अवास्तविक राशि बना ली है। अब मैं सामने वाले के लिए डरावने शब्द कहूंगा - डोकर स्वार, कुबेरनेट्स - यह सब उस तरह से काम करता है।

सबसे अच्छी बात यह है कि, सबसे पहले, क्लाउड फ़ंक्शंस बस सरल के रूप में रहते हैं। यदि आपके पास AWS या लैम्ब्डा में कार्य हैं, तो उन्हें खुले स्रोत में अनुवाद करना उतना ही आसान है।

सभी घटनाक्रम नीचे सूचीबद्ध नहीं हैं। मैंने सिर्फ एक बड़ा और अधिक दिलचस्प चुना। पूरी सूची बहुत बड़ी है: बहुत सारे स्टार्टअप अब इस विषय पर काम करना शुरू कर रहे हैं:

• लोहे के कार्य
  
• Fnproject
  
• Openfaas
  
• अपाचे OpenWhisk
  
• Kubeless
  
• विखंडन
  
• Funktion
  

मैंने Fnproject की कोशिश की और इस Isomorphic एप्लिकेशन को Fnproject में स्थानांतरित करने और इसे कुबेरनेट कंटेनर के साथ स्थानीय रूप से चलाने के लिए केवल कुछ घंटों का समय बिताया।

यह अभी भी तेजी से स्केलेबल है। आपके पास गेटवे एपीआई का एक गुच्छा होगा (बेशक, बाकी सेवाओं के बिना), लेकिन आपके पास अभी भी एक यूआरएल होगा जो लंबो को कॉल करता है। और वास्तव में, लगभग सभी लोग सर्वर के बारे में भूल सकते हैं, जैसा कि वादा किया गया है, एक व्यक्ति को छोड़कर जो इस ढांचे को तैनात करेगा और इस कुबेरनेट्स ऑर्केस्ट्रेशन को कॉन्फ़िगर करेगा ताकि खुश डेवलपर्स इसे बाद में उपयोग कर सकें।

. HolyJS 2018 Moscow, 24-25 . , Early Bird-.