टाइम फॉर मी टू फ्लाई... रेंडर करने के लिए

, जिसे नीचे दिखाया गया है, प्रौद्योगिकी के अधिकांश पहलुओं पर लागू किया जा सकता है: गार्टनर प्रचार चक्र जैसे-जैसे नए नवाचार अपने-अपने चक्र में प्रवेश करते हैं, वैसे-वैसे अपेक्षाएँ अंततः साकार होती जाती हैं - जिससे कुछ हद तक अपनाने की ओर अग्रसर होता है। प्रत्येक नवाचार का लक्ष्य उत्पादकता के उस स्तर तक पहुंचना है जहां उपभोक्ताओं ने निर्धारित किया है कि नवाचार को अपनाने का प्रतिफल ज्ञात जोखिमों से कहीं अधिक है। इसी समय, एक ऐसा बिंदु आता है जहां उत्पादकता का पठार कम होने लगता है, जिससे उस नवाचार से दूर पलायन होता है। एक सरल उदाहरण (या बीपर्स) होगा, जो मोबाइल फोन/उपकरणों के उत्पादकता के पठार तक पहुंचने से पहले आम थे। पेजर प्रौद्योगिकीविदों के रूप में, हम उत्पादकता के पठार को बढ़ाने वाली सुविधाओं, रूपरेखाओं, उत्पादों या सेवाओं को वितरित करने का प्रयास करते हैं। जो हम उपयोग करते हैं उनके लिए भी यही सच है। हाल ही में, मुझे ऐसा लगा कि मेरा वर्तमान होस्टिंग प्लेटफ़ॉर्म उत्पादकता के पठार से गिरने लगा है। वास्तव में, एक मुझे आश्चर्यचकित कर दिया कि क्या यह अन्य विकल्पों पर विचार करने का समय है। हालिया घोषणा ने चूँकि मेरे पास PaaS का उपयोग करने का एक सकारात्मक अनुभव था, इसलिए मैं यह देखना चाहता था कि मैं कितनी आसानी से अपने एक हरोकू एप्लिकेशन को परिवर्तित कर सकता हूँ, PostgreSQL को अपना सकता हूँ, और रेंडर में माइग्रेट कर सकता हूँ। मैं इस दो-भाग की श्रृंखला में उस यात्रा का वर्णन कर रहा हूँ: Render भाग 1: हम अपनी बैकएंड सेवाओं (स्प्रिंग बूट और ClearDB MySQL) को माइग्रेट करने पर ध्यान केंद्रित करेंगे। भाग 2: हम अपने फ्रंटएंड एंगुलर क्लाइंट को पोर्ट करने और माइग्रेट करने पर ध्यान केंद्रित करेंगे। मैंने रेंडर क्यों चुना यदि आपने रेंडर के बारे में पहले कभी नहीं सुना है, तो मेरे पिछले कुछ प्रकाशनों को देखें: रेंडर पास के साथ DevOps पर जीरो टाइम बिताएं द परफेक्ट क्लाउड: AWS, GCP और Azure ऑल-इन-वन उद्देश्य-संचालित माइक्रोसर्विस डिज़ाइन एक दिन में अपना स्टार्टअप आइडिया लॉन्च करें मैंने आसानी से अपने माइक्रोसर्विसेज ऐप को स्केल करने के लिए रेंडर का उपयोग कैसे किया मुझे रेंडर के बारे में जो रोमांचक लगता है वह यह है कि वे उत्पादकता के पठार को पहचानने वाले गोद लेने वालों के लिए सक्रिय रूप से एक ठोस समाधान प्रदान करते हुए ज्ञान की ढलान पर चढ़ना जारी रखते हैं। जैसा कि मैंने अपने लेखों में उल्लेख किया है, रेंडर एक "शून्य DevOps" वादा प्रदान करता है। यह पूरी तरह से मेरी जरूरतों के अनुरूप है क्योंकि मेरे पास DevOps कार्यों पर ध्यान केंद्रित करने का समय नहीं है। हेरोकू प्लेटफॉर्म में कई चीजें हैं जो मुझे पसंद नहीं हैं: दैनिक पुनरारंभ के कारण मेरी एक सेवा के लिए अप्रत्याशित डाउनटाइम हुआ। एंट्री-लेवल (मुझे वास्तव में जरूरत है) हरोकू पर पोस्टग्रेज प्रति माह चार घंटे डाउनटाइम की अनुमति देता है। मूल्य निर्धारण स्तर, उपभोक्ता दृष्टिकोण से, अच्छी तरह से स्केल नहीं करते हैं। मूल्य निर्धारण के दृष्टिकोण से, मैं अपने सभी एप्लिकेशन और सेवाओं को हेरोकू से रेंडर में माइग्रेट करने के बाद महत्वपूर्ण लागत बचत देखने की उम्मीद कर रहा हूं। और आश्चर्यजनक बात यह है कि मुझे उस कीमत के लिए बेहतर मेमोरी और सीपीयू मिल रहा है, रैखिक स्केलिंग के साथ क्योंकि मेरे एप्लिकेशन पदचिह्न को बढ़ने की जरूरत है। एकल सेवा परिवर्तित करना जैसा कि मैंने ऊपर उल्लेख किया है, यह दो-भाग की श्रृंखला का एक भाग है, और मैं इस लेख में सेवा स्तर पर ध्यान केंद्रित करूँगा। मैं जिस सेवा में कनवर्ट करना चाहता हूं उसमें निम्नलिखित विशेषताएं हैं: स्प्रिंग बूट रेस्टफुल एपीआई सेवा हेरोकू क्लाउडएएमक्यूपी (रैबिटएमक्यू) संदेश ब्रोकर Heroku ClearDB (MySQL) डेटाबेस (एकल स्कीमा) ओक्टा एकीकरण Render PaaS की तरफ, नई सर्विस डिजाइन इस तरह दिखेगी: रेंडर वेब सर्विस होस्टिंग स्प्रिंग बूट रेस्टफुल एपीआई सर्विस (डॉकर के माध्यम से) रैबिटएमक्यू संदेश ब्रोकर की मेजबानी करने वाली निजी सेवा प्रस्तुत करें (डॉकर के माध्यम से) कई स्कीमाओं के मौजूद होने की क्षमता के साथ रेंडर पोस्टग्रेज ओक्टा एकीकरण नीचे दो पारिस्थितिक तंत्रों की साथ-साथ तुलना की गई है: रूपांतरण के लिए हमले की मेरी उच्च स्तरीय योजना इस प्रकार है: रूपांतरण के लिए हेरोकू तैयार करें आरंभ करने से पहले, सभी मौजूदा हेरोकू सेवाओं को में रखने की अनुशंसा की जाती है। यह किसी भी उपभोक्ता को एप्लिकेशन या सेवाओं तक पहुंचने से प्रतिबंधित करेगा। रखरखाव मोड जबकि स्रोत कोड को पहले से ही बैकअप और गिट-आधारित रिपॉजिटरी में संग्रहीत किया जाना चाहिए, यह सुनिश्चित करना एक अच्छा विचार है कि डेटाबेस बैकअप सफलतापूर्वक बनाया गया है। हेरोकू सेवाओं का रूपांतरण रूपांतरण के दृष्टिकोण से, मेरे पास कनवर्ट करने के लिए दो आइटम थे: स्वयं सेवा और ClearDB (MySQL) डेटाबेस। मेरी स्प्रिंग बूट रेस्टफुल सेवा के रूपांतरण में अधिक काम शामिल नहीं था। वास्तव में, मैं अपने के लिए उपयोग किए गए दृष्टिकोण का लाभ उठाने में सक्षम था। पिछले प्रोजेक्ट डेटाबेस के लिए, मुझे MySQL से PostgreSQL में बदलने की आवश्यकता थी। मेरा लक्ष्य रेंडर के उपयोग आसानी से हेरोकू पोस्टग्रेज को रेंडर पोस्टग्रेज में माइग्रेट करने के लिए करना था, लेकिन मुझे पहले MySQL से पोस्टग्रेएसक्यूएल में बदलने की जरूरत थी। हरोकू माइग्रेटर का प्रारंभ में, मैंने पथ शुरू किया, जो डेटाबेस रूपांतरण के लिए एक सामान्य दृष्टिकोण प्रतीत होता था। हालाँकि, मेरे M1-चिप मैकबुक प्रो का उपयोग करने से कुछ अप्रत्याशित समस्याएँ पैदा हुईं। pgloader इसके बजाय, मैंने MySQL को PostgreSQL में बदलने के लिए का उपयोग करने का विकल्प चुना। अधिक जानकारी के लिए, कृपया नीचे " " अनुभाग देखें। NMIG डेटाबेस रूपांतरण से हाइलाइट्स रेंडर में सेवाएं बनाएं डॉकर के अंदर चल रहे डेटाबेस और स्प्रिंग बूट रेस्टफुल सेवा को परिवर्तित करने के बाद, अगला कदम स्प्रिंग बूट रेस्टफुल एपीआई सेवा के लिए रेंडर वेब सेवा बनाना था। यह सेवा बनाने, इसे एक नाम देने और GitLab में मेरे कोड के लिए उपयुक्त रिपॉजिटरी की ओर इशारा करने जितना आसान था। चूँकि मुझे एक RabbitMQ सेवा की भी आवश्यकता थी, इसलिए मैंने रेंडर पर चलने वाली RabbitMQ निजी सेवा बनाने के लिए पालन किया। इसमें उन संदेशों को बनाए रखने के लिए डिस्क संग्रहण की एक छोटी मात्रा स्थापित करना शामिल है जिन्हें संसाधित नहीं किया गया है। इन निर्देशों का अंत में, मैंने स्प्रिंग बूट रेस्टफुल एपीआई सेवा और रैबिटएमक्यू संदेश ब्रोकर दोनों के लिए रेंडर डैशबोर्ड में आवश्यक बनाए। पर्यावरण चर सेवाओं को प्रारंभ और मान्य करें अगला कदम मेरी सेवाओं को शुरू करना था। एक बार जब वे चल रहे थे और मेरे पोस्टमैन संग्रह का उपयोग करके एपीआई को मान्य किया गया था, तो मैंने नए रेंडर सेवा स्थान को इंगित करने के लिए अपने क्लाइंट एप्लिकेशन को अपडेट किया। एक बार जब सब कुछ ठीक हो गया और चल रहा था, तो मेरा रेंडर डैशबोर्ड नीचे दिखाए गए अनुसार दिखाई दिया: अगले कदम इस बिंदु पर जो कुछ बचा था, वह अभी भी हरोकू पर चल रहे डेटाबेस को हटाना था और हेरोकू पारिस्थितिकी तंत्र से माइग्रेट की गई सेवाओं को हटाना था। हरोकू का उपयोग करते समय, किसी भी समय मैंने अपने सेवा भंडार की मास्टर शाखा में कोड विलय कर दिया, कोड स्वचालित रूप से तैनात किया गया था, बशर्ते मैंने अपने स्रोत भंडार में इस्तेमाल किया। हेरोकू को तैनात करने के लिए गिटलैब सीआई/सीडी का हालाँकि, रेंडर के साथ स्रोत फ़ाइल रिपॉजिटरी में कोड जोड़ने की कोई आवश्यकता नहीं है। मुझे केवल सेवा के लिए रेंडर डैशबोर्ड में बिल्ड एंड डिप्लॉय ब्रांच को निर्दिष्ट करने की आवश्यकता है: मुझे Zero DevOps का वादा बहुत पसंद है। डेटाबेस रूपांतरण से हाइलाइट्स ऊपर दिए गए चरणों का पालन करके, हेरोकू से रेंडर में रूपांतरण सुचारू और सफल रहा। मेरे लिए सबसे बड़ी चुनौती डेटा का रूपांतरण था। उच्च स्तर पर, यह ज्यादातर मेरे मैकबुक प्रो के टर्मिनल से निष्पादित आदेशों की एक श्रृंखला के लिए उबला हुआ है। सबसे पहले, मैंने डॉकर के माध्यम से एक स्थानीय पोस्टग्रेज उदाहरण शुरू किया: docker run --publish 127.0.0.1:5432:5432 --name postgres -e POSTGRES_PASSWORD=dbo -d postgres अगला, मैंने निम्नलिखित कमांड (या pgAdmin) का उपयोग करके "उदाहरण" नामक एक डेटाबेस बनाया: createdb example Heroku पर चल रहे मेरे ClearDB (MYSQL) उदाहरण को स्थानीय रूप से चल रहे Postgres डेटाबेस के उदाहरण में बदलने के लिए, मैंने उपयोग किया, जो एक Node.js- आधारित डेटाबेस रूपांतरण उपयोगिता है। NMIG का NMIG को स्थापित करने के बाद, मैंने डेटाबेस एंडपॉइंट जानकारी और क्रेडेंशियल्स के साथ config.json फ़ाइल सेट की, और फिर मैं भागा: /path/to/nmig$ npm start इसके बाद, मैंने निम्न आदेश का उपयोग कर डेटा को फ़ाइल में बैक अप लिया: pg_dump -Fc --no-acl --no-owner -h localhost -U postgres example > example.dump AWS में एक हस्ताक्षरित URL बनाने की परेशानी से गुजरने के बजाय, मैंने सिर्फ क्लाइंट का उपयोग Heroku पर एक नए बनाए गए पोस्टग्रेज इंस्टेंस में बैकअप आयात करने के लिए किया। pgAdmin पोस्टग्रेज इंस्टेंस के चलने और डेटा के सत्यापन के साथ, मैंने रेंडर पास पर । तब मुझे बस इतना करना था कि निम्नलिखित कमांड जारी करें: एक नया पोस्टग्रेज डेटाबेस बनाया pg_restore --verbose --no-acl --no-owner -d postgres://username:password@hostname.zone-postgres.render.com/example example.dump रास्ते में सीखे गए सबक हेरोकू से रेंडर में मेरे रूपांतरण को देखते हुए, यहां कुछ सबक हैं जो मैंने सीखे हैं: डीएसटी ऑफ़सेट को शामिल करने के लिए दिनांक/समय मान को अपडेट करने वाले पोस्टग्रेस डेटाबेस के साथ मुझे मामूली समस्या थी। यह मेरे मूल डेटाबेस डिज़ाइन के साथ एक समस्या हो सकती है, लेकिन मैं इसे पास करना चाहता था। मेरे मामले में, प्रभावित स्तंभ का उपयोग केवल दिनांक मानों के लिए किया जाता है, जो मेरे लिए नहीं बदला। मैंने अपनी एक तालिका में END नाम का एक डेटाबेस कॉलम शामिल किया, जिससे समस्या तब हुई जब या तो पोस्टग्रेज या हाइबरनेट ने एक मूल क्वेरी वापस करने का प्रयास किया। सेवा ने END कॉलम नाम देखा और इसे SQL कीवर्ड के रूप में इंजेक्ट किया। मैंने इस समस्या को ठीक करने के लिए बस कॉलम का नाम बदल दिया, जिसे मुझे पहले स्थान पर नहीं करना चाहिए था। रेंडर के साथ, मुझे RabbitMQ सेवा को एक निजी सेवा बनाने की आवश्यकता थी क्योंकि वेब सेवा विकल्प अपेक्षित पोर्ट को उजागर नहीं करता है। हालाँकि, इस दृष्टिकोण के साथ, मैंने RabbitMQ व्यवस्थापक इंटरफ़ेस तक पहुँचने की क्षमता खो दी, क्योंकि निजी सेवाएँ बाहरी रूप से सामने नहीं आती हैं। ऐसा लगता है कि इस संबोधित करने के लिए रेंडर योजनाएँ हैं। सुविधा अनुरोध को कुल मिलाकर, ये छोटी-छोटी बाधाएँ रेंडर में माइग्रेट करने के मेरे निर्णय को प्रभावित करने के लिए पर्याप्त नहीं थीं। निष्कर्ष गार्टनर के उत्पादकता के पठार का सबसे महत्वपूर्ण पहलू उत्पाद, रूपरेखा या सेवाएं प्रदान करना है जो उपभोक्ताओं को फलने-फूलने और उनके लक्ष्यों को पूरा करने की अनुमति देता है। उत्पादकता का पठार आकर्षक या फैशनेबल होने का इरादा नहीं है - एक रूपक अर्थ में। जब मैंने इस निष्कर्ष को रेंडर में एक डेवलपर एडवोकेट एड के साथ साझा किया, तो उनकी प्रतिक्रिया कुछ ऐसी थी जिसे मैं साझा करना चाहता था: "रेंडर स्पष्ट रूप से 'फैशनेबल' बनने की कोशिश नहीं कर रहा है।" हम आश्चर्यजनक और भरोसेमंद बनने की कोशिश कर रहे हैं।" एड की प्रतिक्रिया मेरे साथ गहराई से प्रतिध्वनित हुई और मुझे उस समय की याद दिला दी जब मेरे मुझे बताया कि मेरा कोड उनके लिए "उबाऊ" था। उनकी टिप्पणी मुझे मिली सबसे बड़ी तारीफ साबित हुई। आप और अधिक पढ़ सकते हैं। पूर्व सहयोगी ने यहां प्रौद्योगिकी के किसी भी पहलू में, किस प्रदाता को चुनने का निर्णय हमेशा आपकी तकनीकी स्थिति से मेल खाना चाहिए। यदि आप अनिश्चित हैं, तो गार्टनर प्रचार चक्र एक महान संदर्भ बिंदु है, और आप उनकी सेवा की सदस्यता के साथ आरंभ कर सकते हैं। यहां मैं निम्नलिखित मिशन वक्तव्य पर केंद्रित रहा हूं, जो मुझे लगता है कि किसी भी आईटी पेशेवर पर लागू हो सकता है: "अपनी बौद्धिक संपदा के मूल्य को बढ़ाने वाली सुविधाओं/कार्यक्षमता को वितरित करने पर अपना समय केंद्रित करें। बाकी सभी चीजों के लिए लीवरेज फ्रेमवर्क, उत्पाद और सेवाएं।" - जे वेस्टर जब मैं Render PaaS पारिस्थितिकी तंत्र को देखता हूं, तो मुझे एक समाधान दिखाई देता है जो मेरे प्रचार चक्र वरीयता के भीतर रहते हुए मेरे मिशन कथन का पालन करता है। जो बात चीजों को बेहतर बनाती है वह यह है कि मैं अपनी व्यक्तिगत आउट-ऑफ-पॉकेट लागतों में 44% बचत देखने की पूरी उम्मीद करता हूं - इससे भी अधिक क्योंकि मेरी सेवाओं को लंबवत रूप से स्केल करने की आवश्यकता है। होस्टिंग समाधानों पर विचार करने वालों के लिए, मैं समीक्षा और विश्लेषण के लिए प्रदाताओं की सूची में रेंडर जोड़ने की सलाह देता हूं। आप अनुसरण करके निःशुल्क शुरुआत कर सकते हैं। इस लिंक का इस सीरीज का दूसरा भाग रोमांचक होगा। मैं प्रदर्शित करूंगा कि एंगुलर में लिखे अपने स्टैटिक क्लाइंट के लिए भुगतान करने से कैसे नेविगेट करें और Vue या Svelte का उपयोग करके रेंडर की मुफ्त स्टेटिक साइट्स सेवा का लाभ उठाएं। मैं कौन सा ढांचा चुनूंगा ... और क्यों? आपका दिन वाकई बहुत अच्छा हो!