diff --git a/content/hi/api-gateway.md b/content/hi/api-gateway.md new file mode 100644 index 0000000000..14b8b8f28a --- /dev/null +++ b/content/hi/api-gateway.md @@ -0,0 +1,24 @@ +--- +title: एपीआई गेटवे (API Gateway) +status: Completed +category: अवधारणा +tags: ["networking", "", ""] +--- + +## यह क्या है + +[एपीआई](/application-programming-interface/) गेटवे एक ऐसा उपकरण है जो अद्वितीय एप्लिकेशन एपीआई को एकत्र करता है, जिससे वे सभी एक ही स्थान पर उपलब्ध हो जाते हैं। +यह संगठनों को प्रमुख कार्यों को स्थानांतरित करने की अनुमति देता है, जैसे प्रमाणीकरण और प्राधिकरण या अनुप्रयोगों के बीच अनुरोधों की संख्या को केंद्रीय रूप से प्रबंधित स्थान पर सीमित करना। +एपीआई गेटवे अक्सर बाहरी उपभोक्ताओं के लिए एक सामान्य इंटरफ़ेस के रूप में कार्य करता है। +## समस्या + +यदि आप बाहरी उपभोक्ताओं के लिए एपीआई उपलब्ध करा रहे हैं, तो आप सभी पहुंच को प्रबंधित और नियंत्रित करने के लिए एक प्रवेश बिंदु चाहते हैं। +इसके अतिरिक्त, यदि आपको उन इंटरैक्शन पर कार्यक्षमता लागू करने की आवश्यकता है, तो एक एपीआई गेटवे आपको बिना किसी ऐप कोड परिवर्तन की आवश्यकता के इसे सभी +ट्रैफ़िक पर समान रूप से लागू करने की अनुमति देता है। + +## समाधान + +एक एप्लिकेशन में विभिन्न एपीआई के लिए एक एकल पहुंच बिंदु प्रदान करना, एपीआई गेटवे संगठनों के लिए एक केंद्रीय स्थान में क्रॉस-कटिंग व्यवसाय या सुरक्षा को लागू करना आसान बनाता है। +वे एप्लिकेशन उपभोक्ताओं को उनकी सभी जरूरतों के लिए एक ही पते पर जाने की अनुमति भी देते हैं। +एक एपीआई गेटवे सिस्टम में सभी वेब सेवाओं के अनुरोधों के लिए एकल पहुंच बिंदु प्रदान करके सुरक्षा और अवलोकन जैसी परिचालन संबंधी चिंताओं को सरल बना सकता है। +जैसा कि सभी अनुरोध एपीआई गेटवे के माध्यम से प्रवाहित होते हैं, यह मेट्रिक्स-एकत्रीकरण, दर-सीमित और प्राधिकरण जैसी कार्यक्षमता जोड़ने के लिए एक ही स्थान प्रस्तुत करते हैं। \ No newline at end of file diff --git a/content/hi/application-programming-interface.md b/content/hi/application-programming-interface.md new file mode 100644 index 0000000000..6686ca5470 --- /dev/null +++ b/content/hi/application-programming-interface.md @@ -0,0 +1,23 @@ +--- +title: एप्लीकेशन प्रोग्रामिंग इंटरफ़ेस (Application Programming Interface) +status: Completed +category: संकल्पना +tags: ["architecture", "fundamental"] +--- + +## यह क्या है + +यह एक एपीआई कंप्यूटर प्रोग्राम के लिए संवाद स्थापित करने का एक माध्यम है। जिस तरह हम एक वेब पेज के माध्यम से एक वेबसाइट के साथ सूचना का आदान-प्रदान करते हैं, +एक एपीआई विभिन्न कंप्यूटर प्रोग्राम को एक दूसरे से सूचना का आदान-प्रदान करने के लिए उपयोग करती है। अंतः मानवीय क्रियाओं के विपरीत, एपीआई की सीमाएँ होती हैं कि उनसे क्या पूछा जा सकता है और क्या नहीं। +सहभागिता के बीच सीमा स्थापित करने से अलग-अलग प्रोग्राम के बीच स्थिर और कार्यात्मक संचार बनाने में मदद मिलती है। + +## समस्या + +जैसे-जैसे एप्लिकेशन अधिक जटिल होते जाते हैं, कोड में छोटे परिवर्तन भी दूसरी कार्यक्षमताओं पर भारी प्रभाव डालने लगते हैं। एप्लीकेशन को उनकी कार्यक्षमता के लिए एक प्रतिरुपक दृष्टिकोण रखने की आवश्यकता होती है, यदि वे एक साथ विकास और स्थिरता बनाए रख सकते हैं। +एपीआई के बिना, एप्लीकेशन के बीच बातचीत के लिए एक रूपरेखा का अभाव रहता है। एक साझा ढांचे के बिना, एप्लीकेशन को [स्केल](/scalability/) और एकीकृत करना चुनौतीपूर्ण है। + +## समाधान + +एपीआई कंप्यूटर प्रोग्राम या एप्लिकेशन को एक निर्धारित और समझने योग्य तरीके से जानकारी साझा करने की अनुमति देता है। ये आधुनिक एप्लीकेशन का एक मूलभूत अंग हैं और ये डेवलपर्स को विभिन्न एप्लीकेशन +को एक साथ एकीकृत करने का एक तरीका प्रदान करता है। जब भी आप एक साथ काम करने वाली [माइक्रोसर्विसेज](/microservices/) के बारे में सुनते हैं, तो आप अनुमान लगा सकते हैं कि वे +एक एपीआई के माध्यम से संवाद करती हैं। diff --git a/content/hi/bare_metal_machine.md b/content/hi/bare-metal-machine.md similarity index 100% rename from content/hi/bare_metal_machine.md rename to content/hi/bare-metal-machine.md diff --git a/content/hi/client_server_architecture.md b/content/hi/client-server-architecture.md similarity index 100% rename from content/hi/client_server_architecture.md rename to content/hi/client-server-architecture.md diff --git a/content/hi/cloud native apps.md b/content/hi/cloud native apps.md new file mode 100644 index 0000000000..dc5d2ca053 --- /dev/null +++ b/content/hi/cloud native apps.md @@ -0,0 +1,30 @@ +--- +title: क्लाउड नेटिव ऐप्स (Cloud Native Apps) +status: Completed +category: अवधारणा +tags: ["application", "fundamental"] +--- + +## यह क्या है + +क्लाउड नेटिव एप्लिकेशन विशेष रूप से [क्लाउड कंप्यूटिंग](/cloud-computing/) में नवीनीकरण का लाभ उठाने के लिए डिज़ाइन किए गए हैं। +ये एप्लिकेशन क्लाउड के संसाधनों और [स्केलिंग](/scalability/) क्षमताओं का लाभ उठाते हुए, अपने संबंधित क्लाउड आर्किटेक्चर के साथ आसानी से एकीकृत होते हैं। +यह उन अनुप्रयोगों को भी संदर्भित करते हैं जो क्लाउड कंप्यूटिंग द्वारा संचालित बुनियादी ढांचे में नवीनीकरण का लाभ उठाते हैं। +क्लाउड नेटिव एप्लिकेशन में आज ऐसे ऐप्स शामिल हैं जो क्लाउड प्रदाता के डेटासेंटर और ऑन-प्रिमाइसेस क्लाउड नेटिव प्लेटफॉर्म पर चलते हैं। + +## समस्या + +परंपरागत रूप से, ऑन-प्रिमाइसेस परिवेशों ने काफी पहले से आरक्षित तरीके से कंप्यूट संसाधन प्रदान किए। +प्रत्येक डेटासेंटर में ऐसी सेवाएँ थीं जो विशिष्ट वातावरणों के लिए [कसकर युग्मित](/tightly-coupled-architectures/) अनुप्रयोग करती थीं, +[वर्चुअल मशीन](/virtual-machine/) और अन्य सेवाऍ जैसी बुनियादी सुविधाओं के लिए अक्सर मैन्युअल प्रावधान पर बहुत अधिक भरोसा किया जाता है। +यह, बदले में, डेवलपर्स और उनके अनुप्रयोगों को उस विशिष्ट डेटासेंटर तक सीमित कर देता है। +क्लाउड के लिए डिज़ाइन नहीं किए गए एप्लिकेशन क्लाउड वातावरण की लचीलाता और स्केलिंग क्षमताओं का लाभ नहीं उठा सकते थे। +उदाहरण के लिए, जिन ऐप्स को सही ढंग से शुरू करने के लिए मैन्युअल हस्तक्षेप की आवश्यकता होती है, वे स्वचालित रूप से स्केल नहीं कर सकते हैं, +ना ही विफलता की स्थिति में उन्हें स्वचालित रूप से पुनरारंभ किया जा सकता है। + +## समाधान + +जबकि क्लाउड नेटिव एप्लिकेशन के लिए कोई एक आकार तभी फिट बैठता है, जब उनमें कुछ समानताएँ हों। +क्लाउड नेटिव ऐप्स लचीले, प्रबंधनीय होते हैं और उनके साथ आने वाली क्लाउड सेवाओं के सुइट द्वारा सहायता प्राप्त होती है। +विभिन्न क्लाउड सेवाएँ उपयोगकर्ताओं को समस्याओं के बढ़ने से पहले उनका पता लगाना और उनका समाधान करने में सक्षम बनाने के साथ साथ [अवलोकन योग्यता](/observability/) की एक उच्च स्तर को सक्षम करती हैं। +मजबूत स्वचालन के साथ संयुक्त, वे इंजीनियरों को न्यूनतम परिश्रम के साथ बार-बार और अनुमानित रूप से उच्च प्रभाव वाले परिवर्तन करने की अनुमति देती हैं। diff --git a/content/hi/cloud-computing.md b/content/hi/cloud-computing.md new file mode 100644 index 0000000000..2713bfc4b6 --- /dev/null +++ b/content/hi/cloud-computing.md @@ -0,0 +1,21 @@ +--- +title: क्लाउड कंप्यूटिंग (cloud computing) +status: Completed +category: अवधारणा +tags: ["infrastructure", "", ""] +--- +## यह क्या है ? +क्लाउड कंप्यूटिंग एक ऐसा मॉडल है जो इंटरनेट पर ऑन-डिमांड सीपीयू, नेटवर्क और डिस्क क्षमताओं जैसे कंप्यूट संसाधन प्रदान करता है। +क्लाउड कंप्यूटिंग उपयोगकर्ताओं को दूरस्थ भौतिक स्थान में कंप्यूटिंग शक्ति तक पहुंचने और उपयोग करने की क्षमता देता है। +क्लाउड प्रदाता जैसे AWS, GCP, Azure, DigitalOcean, और अन्य सभी तृतीय पक्षों की पेशकश करते हैं +एकाधिक भौगोलिक स्थानों में संसाधनों की गणना करने के लिए किराए पर पहुंच की क्षमता। + +## समस्या +कंप्यूटिंग शक्ति के अपने उपयोग का विस्तार करने का प्रयास करते समय संगठनों को परंपरागत रूप से दो मुख्य समस्याओं का सामना करना पड़ा। +वे या तो सुविधाओं का अधिग्रहण, समर्थन, डिजाइन और भुगतान करते हैं अपने भौतिक सर्वर और नेटवर्क को होस्ट करने या उन सुविधाओं का विस्तार और रखरखाव करने के लिए। +क्लाउड कंप्यूटिंग संगठनों को अपनी कंप्यूटिंग जरूरतों के कुछ हिस्से को किसी अन्य संगठन को आउटसोर्स करने की अनुमति देता है। + +## समाधान +क्लाउड प्रदाता संगठनों को ऑन-डिमांड गणना संसाधनों को किराए पर लेने और उपयोग के लिए भुगतान करने की क्षमता प्रदान करते हैं। +यह दो प्रमुख नवाचारों की अनुमति देता है: संगठन समय बर्बाद किए बिना चीजों को आजमा सकते हैं और नए भौतिक बुनियादी ढांचे पर पैसा या संसाधन खर्च कर सकते हैं +और वे आवश्यकतानुसार [स्केल](/scalability/) कर सकते हैं। क्लाउड कंप्यूटिंग संगठनों को अपनी जरूरत के अनुसार अधिक या कम बुनियादी ढांचे को अपनाने की अनुमति देता है। diff --git a/content/hi/cloud-native-security.md b/content/hi/cloud-native-security.md new file mode 100644 index 0000000000..1623f62d0b --- /dev/null +++ b/content/hi/cloud-native-security.md @@ -0,0 +1,32 @@ +--- +title: क्लाउड नेटिव सुरक्षा (Cloud Native Security) +status: completed +category: concept +tags: ["Security"] +--- + +## यह क्या है? + +क्लाउड नेटिव सुरक्षा एक तरीका है, जो क्लाउड नेटिव ऐपस् में सुरक्षा निर्मित करता है। +यह सुनिश्चित करता है कि सुरक्षा विकास से लेकर निर्माण तक संपूर्ण ऐप के जीवनचक्र का हिस्सा बनी रहे। +क्लाउड नेटिव सुरक्षा पारंपरिक सुरक्षा प्रतिरूप के समान मानकों को क्लाउड नेटिव वातावरण के विवरणों, +अर्थात् तेज़ी से कोड परिवर्तन और अत्यधिक अल्पकालिक अवसरंचनाओं को अपनाते हुए सुनिश्चित करने का प्रयास करती है। +क्लाउड नेटिव सुरक्षा [DevSecOps](/devsecops/) नामक अभ्यास से अत्यधिक संबंधित है। + +## समस्या + +पारंपरिक सुरक्षा प्रतिरूप कई मान्यताओं के साथ बनाए गए थे जो अब वैध नहीं हैं। +[क्लाउड नेटिव ऐपस्](/cloud-native-apps/) बार-बार बदलते हैं, बड़ी संख्या में ओपन सोर्स संसाधनों और लाइब्रेरी का उपयोग करते हैं, +अक्सर विक्रेता-नियंत्रित इंफ्रास्ट्रक्चर में चलते हैं, और इस तेज़ बदलाव के अधीन होते हैं। +कोड समीक्षा, लंबे गुणवत्ता आश्वासन चक्र, होस्ट पर आधारित भेद्यता अवलोकन और अंतिम मिनट की +सुरक्षा समीक्षा क्लाउड नेटिव ऐपस् के साथ [स्केल](/scalability/) नहीं की जा सकती हैं। + +## समाधान + +क्लाउड नेटिव सुरक्षा काम करने का एक नया तरीक़ा पेश करती है। यह पारंपरिक सुरक्षा प्रतिरूप को स्थानांतरित करके +ऐपस् की सुरक्षा करती है, जहां रिलीज़ चक्र के हर चरण में सुरक्षा शामिल होती है। +हस्तचालित परीक्षण और जांच को बड़े पैमाने पर स्वचालित स्कैन से बदल दिया गया है। +त्वरित कोड रिलीज़ पाइपलाइन के उन उपकरणों के साथ एकीकृत हैं जो संकलित होने से पहले भेद्यता के लिए कोड की समीक्षा करते हैं। +ओपन सोर्स लाइब्रेरी विश्वसनीय स्रोतों से ली जाती हैं और अरक्षितता के लिए उनकी निगरानी भी की जाती है। +बदलाव को धीमा करने के बजाय एक क्लाउड नेटिव सुरक्षा प्रतिरूप अक्सर अद्यतन किए गए असुरक्षित घटकों द्वारा इसे ग्रहण करती है, और +यह सुनिश्चित करती है कि इंफ्रास्ट्रक्चर को नियमित रूप से बदला जा रहा है। diff --git a/content/hi/container-orchestration.md b/content/hi/container-orchestration.md new file mode 100644 index 0000000000..9fa18a7c6b --- /dev/null +++ b/content/hi/container-orchestration.md @@ -0,0 +1,24 @@ +--- +title: कंटेनर ऑर्केस्ट्रेशन (Container Orchestration) +status: Completed +category: अवधारणा +--- + +## यह क्या है + +[कंटेनर](/container/) ऑर्केस्ट्रेशन का तात्पर्य है गतिशील वातावरण में कंटेनरीकृत एप्लीकेशन के जीवनचक्र को प्रबंधित और स्वचालित करना। +इसे एक कंटेनर ऑर्केस्ट्रेटर (ज्यादातर मामलों में, [कुबेरनेट्स](/kubernetes/)) के माध्यम से एक्सेक्यूटे किया जाता है, जो डिप्लॉयमेंट, (ऑटो) स्केलिंग, ऑटो-हीलिंग और मॉनिटरिंग को सक्षम बनाता है। +ऑर्केस्ट्रेशन एक रूपक है: +ऑर्केस्ट्रेशन टूल एक संगीत संचालक की तरह कंटेनरों का संचालन करता है, यह सुनिश्चित करता है कि प्रत्येक कंटेनर (या संगीतकार) वही करे जो उसे करना चाहिए। + +## समस्या + +[माइक्रोसर्विसेज](/microservices/), सुरक्षा और नेटवर्क संचार को बड़े पैमाने पर प्रबंधित करना - और [वितरित सिस्टम](/distributed-systems/) को सामान्य रूप से प्रबंधित करना - मैन्युअल रूप से प्रबंधित करना असंभव नहीं लेकिन कठिन है। +कंटेनर ऑर्केस्ट्रेशन उपयोगकर्ताओं को इन सभी प्रबंधन कार्यों को स्वचालित करने की अनुमति देता है। + +## समाधान + +कंटेनर ऑर्केस्ट्रेशन टूल उपयोगकर्ताओं को सिस्टम की स्थिति निर्धारित करने की अनुमति देते हैं। +सबसे पहले, वे परिभाषित करते हैं कि यह कैसा दिखना चाहिए (उदाहरण के लिए X कंटेनर, Y पॉड्स, आदि)। +ऑर्केस्ट्रेशन टूल तब स्वचालित रूप से इंफ्रास्ट्रक्चर की निगरानी करेगा और यदि इसकी स्थिति परिभाषित स्थिति से भटकती है तो इसे ठीक कर देगा (उदाहरण के लिए यदि कोई कंटेनर दुर्घटनाग्रस्त हो जाता है तो एक नया कंटेनर स्पिन करें)। +यह स्वचालन कई इंजीनियरिंग टीमों के अन्यथा अत्यधिक मैन्युअल और जटिल परिचालन कार्यों को सरल बनाता है, जिसमें प्रावधान, डिप्लॉयमेंट, स्केलिंग (उप और डाउन), नेटवर्किंग, लोड संतुलन और अन्य गतिविधियां शामिल हैं। diff --git a/content/hi/contribute/_index.md b/content/hi/contribute/_index.md index d59427db3d..ab03e51c64 100644 --- a/content/hi/contribute/_index.md +++ b/content/hi/contribute/_index.md @@ -17,7 +17,8 @@ menu: ## शब्दावली समुदाय में शामिल हों -यदि आप नियमित रूप से योगदान देना चाहते हैं, तो हमारी मासिक शब्दावली कार्य समूह की बैठकों में शामिल होने पर विचार करें। आप CNCF कैलेंडर में मीटिंग विवरण प्राप्त कर सकते हैं। आप [CNCF कैलेंडर](https://www.cncf.io/calendar/) पर हमारे #glossary मेन्टेनेरों और साथी योगदानकर्ताओं से भी जुड़ सकते हैं — हमें आपसे मिलकर खुशी होगी! +यदि आप नियमित रूप से योगदान देना चाहते हैं, तो हमारी मासिक शब्दावली कार्य समूह की बैठकों में शामिल होने पर विचार करें। आप CNCF कैलेंडर में मीटिंग विवरण प्राप्त कर सकते हैं। +आप [CNCF कैलेंडर](https://www.cncf.io/calendar/) पर हमारे [#glossary-localization-hi](https://cloud-native.slack.com/archives/C02PCHEQXK6) के मेन्टेनरों और साथी योगदानकर्ताओं से भी जुड़ सकते हैं — हमें आपसे मिलकर खुशी होगी! ## नए शब्द प्रस्तावित करें @@ -39,9 +40,10 @@ menu: ![नया इशू](/images/how-to/howto-03.png) -कृपया CNCF Slack पर #glossary चैनल से जुड़ें और @Catherine Paganini, @jmo, और @Seokho Son को सुचना दें कि आपने एक इशू जमा कर दी है और उस पर काम करना चाहते हैं। वे आपको वह इशू सौंपेंगे जो अन्य सभी को संकेत देगा कि यह शब्द पहले ही लिया जा चुका है। +कृपया CNCF Slack पर [#glossary-localization-hi](https://cloud-native.slack.com/archives/C02PCHEQXK6) चैनल से जुड़ें और @Garima-Negi, @jayesh-srivastava, @bishal7679, @kumarankit999, @abhay-raj19 या @aj11anuj को सुचना दें कि +आपने एक इशू खोला है और उस पर आप काम करना चाहते हैं। वे आपको वह इशू सौंपेंगे जो अन्य सभी को संकेत देगा कि यह इशू पहले ही लिया जा चुका है। -यहां आप देख सकते हैं कि पहले तीन शब्द उपलब्ध हैं जबकि अगला शब्द किसी को सौंपा गया है। +यहां आप देख सकते हैं कि पहले तीन इशू उपलब्ध हैं जबकि अगला इशू किसी को सौंपा गया है। ![शब्द पे दावा करना](/images/how-to/howto-04.png) diff --git a/content/hi/devsecops.md b/content/hi/devsecops.md new file mode 100644 index 0000000000..a0ad428538 --- /dev/null +++ b/content/hi/devsecops.md @@ -0,0 +1,30 @@ +--- +title: DevSecOps +status: Completed +category: अवधारणा +tags: ["methodology", "", ""] +--- +## यह क्या है + +DevSecOps शब्द विकास, संचालन और सुरक्षा जिम्मेदारियों के सांस्कृतिक विलय को संदर्भित करता है। +यह सुरक्षा प्राथमिकताओं को शामिल करने के लिए डेवलपर और परिचालन कार्यप्रवाह में न्यूनतम या बिना किसी व्यवधान के, [DevOps](/devops/) दृष्टिकोण का विस्तार करता है। +DevOps की तरह, DevSecOps एक सांस्कृतिक बदलाव है, जिसे अपनाई गई तकनीकों द्वारा अद्वितीय अपनाने के तरीकों के साथ आगे बढ़ाया गया है। + +## समस्या + +DevOps प्रथाओं में [निरंतर एकीकरण] (/ निरंतर-एकीकरण /) और [निरंतर परिनियोजन] (/ निरंतर-वितरण /) शामिल हैं +और अनुप्रयोग विकास और रिलीज चक्रों में तेजी लाएं। +दुर्भाग्य से, स्वचालित रिलीज़ प्रक्रियाएं जो प्रतिनिधित्व करने में विफल होती हैं +सभी संगठनात्मक हितधारक पर्याप्त रूप से मौजूदा मुद्दों को बढ़ा सकते हैं। +एक प्रक्रिया जो सुरक्षा आवश्यकताओं पर विचार किए बिना नए सॉफ़्टवेयर को तेज़ी से रिलीज़ करती है +किसी संगठन की सुरक्षा मुद्रा को नीचा दिखा सकता है। + +## समाधान + +DevSecOps टीम साइलो को तोड़ने पर ध्यान केंद्रित करता है और सुरक्षित, स्वचालित वर्कफ़्लोज़ के निर्माण को बढ़ावा देता है। +सुरक्षा अनुप्रयोगों का चयन करते समय, संगठनों को इसका लाभ उठाना चाहिए +स्वचालित CI/CD कार्यप्रवाह और नीति प्रवर्तन जो डेवलपर को सशक्त बनाते हैं। +लक्ष्य अवरोधक बनना नहीं बल्कि सुरक्षा नीतियों को लागू करना है +उपयोगकर्ताओं को अपने प्रोजेक्ट को आगे बढ़ाने के तरीके के बारे में सटीक जानकारी देते हुए। +जब ठीक से लागू किया जाता है, तो एक संगठन बेहतर टीम संचार प्राप्त करेगा और +सुरक्षा दुर्घटनाओं और संबंधित लागतों को कम करें। diff --git a/content/hi/distributed-systems.md b/content/hi/distributed-systems.md new file mode 100644 index 0000000000..e605ce577a --- /dev/null +++ b/content/hi/distributed-systems.md @@ -0,0 +1,32 @@ +--- +title: डिस्ट्रिब्यूटेड सिस्टम (Distributed System) +status: Completed +category: अवधारणा +tags: ["आर्किटेक्चर"] +--- + +डिस्ट्रिब्यूटेड सिस्टम ऑटोनॉमस कंप्यूटिंग तत्वों का एक कलेक्शन है +जो एक नेटवर्क पर जुड़ा हुआ है और उपयोगकर्ताओं को एकल स्पष्ट सिस्टम के रूप में दिखाई देता है। +आम तौर पर [नोड्स](/nodes/) के रूप में संदर्भित, ये भाग हार्डवेयर डिवाइस जैसे - कंप्यूटर, मोबाइल फोन या सॉफ्टवेयर प्रक्रियाएं हो सकते हैं। +नोड्स को एक सामान्य लक्ष्य प्राप्त करने के लिए प्रोग्राम किया जाता है और सहयोग करने के लिए, वे नेटवर्क पर संदेशों का आदान-प्रदान करते हैं। + +## समस्या + +आज अनेक आधुनिक अनुप्रयोग इतने बड़े हो गए हैं कि उन्हें संचालित करने के लिए सुपर कंप्यूटर की आवश्यकता होगी। +जी-मेल या नेटफ्लिक्स के बारे में सोचें। कोई भी कंप्यूटर संपूर्ण एप्लिकेशन को होस्ट करने के लिए पर्याप्त शक्तिशाली नहीं है। +कई कंप्यूटरों को जोड़ने से, गणना शक्ति लगभग असीमित हो जाती है। +डिस्ट्रिब्यूटेड कंप्यूटिंग के बिना, आज जिन कई अनुप्रयोगों पर हम भरोसा करते हैं, वे संभव नहीं होंगे। + +परंपरागत रूप से, सिस्टम लंबवत रूप से [स्केल](/scalability/) होते हैं। +तभी आप किसी व्यक्तिगत मशीन में अधिक सीपीयू या मेमोरी जोड़ पाते हैं। +वर्टिकल स्केलिंग में समय लगता है, इसके लिए डाउनटाइम की आवश्यकता होती है और यह जल्दी ही अपनी सीमा तक पहुंच जाती है। + +## समाधान + +डिस्ट्रिब्यूटेड सिस्टम [होरिजेंटल स्केलिंग](/horizontal-scaling/) की अनुमति देती हैं (उदाहरण के लिए जरूरत के समय सिस्टम में अधिक नोड्स जोड़ना)। +इसे ऑटोमेटिक किया जा सकता है जिससे सिस्टम के कार्यभार या संसाधन की खपत में अचानक हुई वृद्धि को संभालना सरल हो सके। + +एक नॉन-डिस्ट्रिब्यूटेड सिस्टम विफलता के जोखिमों को उजागर करती है क्योंकि यदि एक मशीन विफल हो जाती है, तो पुरा सिस्टम विफल हो जाता है। +एक डिस्ट्रिब्यूटेड सिस्टम को इस तरह से डिज़ाइन किया जा सकता है कि, +भले ही कुछ मशीनें खराब हो जाएं, फिर भी समग्र सिस्टम समान परिणाम देने के लिए काम करना जारी रख सके। + diff --git a/content/hi/edge-computing.md b/content/hi/edge-computing.md new file mode 100644 index 0000000000..78f1d97a72 --- /dev/null +++ b/content/hi/edge-computing.md @@ -0,0 +1,27 @@ +--- +title: एज-कंप्यूटिंग (Edge Computing) +status: Completed +category: प्रौद्योगिकी +--- + +एज-कंप्यूटिंग एक [डिस्ट्रिब्यूटेड सिस्टम](/distributed-systems/) का दृष्टिकोण है, जो कुछ स्टोरेज और कंप्यूटिंग क्षमता को प्राथमिक डेटा केंद्र से डेटा स्रोत में स्थानांतरित करता है। +एकत्रित डेटा की गणना प्रसंस्करण और विश्लेषण के लिए केंद्रीकृत डेटा सेंटर में भेजने के बजाय स्थानीय स्तर पर की जाती है (उदाहरण के लिए, किसी कारखाने के फर्श पर, किसी स्टोर में, या पूरे शहर में)। +ये स्थानीय प्रसंस्करण डिवाइस सिस्टम के एज का प्रतिनिधित्व करते हैं, जबकि डेटा सेंटर इसका केंद्र है। +एज पर गणना किए गए आउटपुट को आगे की प्रक्रिया के लिए प्राथमिक डेटा सेंटर में वापस भेजा जाता है। +एज-कंप्यूटिंग के उदाहरणों में कलाई गैजेट या कंप्यूटर शामिल हैं जो ट्रैफ़िक प्रवाह का विश्लेषण करते हैं। + +## समस्या + +पिछले दशक में, हमने अत्याधुनिक एज-डिवाइस (जैसे, मोबाइल फोन, स्मार्ट घड़ियाँ, या सेंसर) की बढ़ती संख्या देखी है। +कुछ मामलों में, वास्तविक डेटा प्रोसेसिंग न केवल अच्छा है बल्कि महत्वपूर्ण भी है। +आप उदाहरण के तौर पर स्वचलित गाड़ियों के बारे में सोच सकते हैं। +अब कल्पना करें कि कार के सेंसर से डेटा को वाहन में वापस भेजने से पहले प्रसंस्करण के लिए डेटा सेंटर में स्थानांतरित करना होगा ताकि यह उचित रूप से प्रतिक्रिया कर सके। +इसके वजे से अंतर्निहित नेटवर्क में विलंबता घातक हो सकती है। +हालाँकि यह एक अति अधिक उदाहरण है, अधिकांश उपयोगकर्ता तत्काल प्रतिक्रिया प्रदान करने में असमर्थ स्मार्ट डिवाइस का उपयोग नहीं करना चाहेंगे। + +## समाधान + +जैसा कि ऊपर वर्णित है, एज-डिवाइसों के उपयोगी होने के लिए, उन्हें उपयोगकर्ताओं को वास्तविक समय पर प्रतिक्रिया प्रदान करने के लिए प्रसंस्करण और विश्लेषण का कम से कम हिस्सा स्थानीय स्तर पर करना होगा। +यह कुछ स्टोरेज और प्रसंस्करण संसाधनों को डेटा सेंटर से उस स्थान पर स्थानांतरित करके प्राप्त किया जाता है जहां डेटा उत्पन्न होता है: जैसे की एज-डिवाइस। +संसाधित और असंसाधित डेटा को बाद में आगे की प्रक्रिया और स्टोरेज के लिए डेटा सेंटर में भेजा जाता है। +संक्षेप में, कुशलता और गति एज-कंप्यूटिंग के प्राथमिक चालक हैं। diff --git a/content/hi/event-streaming.md b/content/hi/event-streaming.md new file mode 100644 index 0000000000..815b25212b --- /dev/null +++ b/content/hi/event-streaming.md @@ -0,0 +1,25 @@ +--- +title: इवेंट स्ट्रीमिंग (Event Streaming) +status: Completed +category: अवधारणा +tags: ["क्रियाविधि", "नेटवर्किंग", ""] +--- + +## यह क्या है + +इवेंट स्ट्रीमिंग एक ऐसा दृष्टिकोण है जहां सॉफ़्टवेयर इवेंट डेटा को एक एप्लिकेशन से दूसरे एप्लिकेशन में भेजता है ताकि वे लगातार संवाद कर सकें कि वे क्या कर रहे हैं। +एक ऐसी सेवा की कल्पना करें जो अन्य सेवाओं के लिए वह सब कुछ प्रसारित करती है जो वह करती है। किसी सेवा द्वारा की गई प्रत्येक गतिविधि को एक ईवेंट के रूप में संदर्भित किया जाता है, इसलिए इसे इवेंट स्ट्रीमिंग कहा जाता है। उदाहरण के लिए, NASDAQ को हर सेकंड स्टॉक और कमोडिटी प्राइसिंग पर अपडेट मिलता है। यदि आपके पास एक ऐसा एप्लिकेशन है जो स्टॉक के एक विशिष्ट सेट की निगरानी करता है, तो आप लगभग रीयल-टाइम में वह जानकारी प्राप्त करना चाहेंगे। +`Yahoo! Finance` एक [एपीआई](/application-programming-interface/) प्रदान करता है जो NASDAQ से डेटा खींचता है और उनके आवेदन से सूचना (या घटनाओं) को भेजता है (या स्ट्रीम करता है) किसी भी आवेदन के लिए जो इसकी सदस्यता लेता है। भेजे जा रहे डेटा के साथ-साथ उस डेटा में परिवर्तन (स्टॉक की कीमतें) घटनाएँ हैं जबकि उन्हें किसी एप्लिकेशन तक पहुँचाने की प्रक्रिया इवेंट स्ट्रीमिंग है। + + +## समस्या + +परंपरागत रूप से, `Yahoo! Finance` ने एकल टीसीपी अनुरोधों का उपयोग किया था। यह बहुत अक्षम था क्योंकि इसमें प्रत्येक घटना के लिए एक कनेक्शन बनाने की आवश्यकता होती थी| +चूंकि डेटा प्रकृति में अधिक रीयल-टाइम बन जाता है, ऐसे समाधान को स्केल करना अक्षम हो जाता है। एक बार कनेक्शन खोलना और घटनाओं को प्रवाहित होने देना वास्तविक समय संग्रह के लिए आदर्श है।उत्पन्न होने वाले डेटा की मात्रा तेजी से बढ़ रही है और इसके साथ ही डेटा स्थिति निरंतर प्रवाह में है। +डेवलपर्स और उपयोगकर्ताओं को उस डेटा को वास्तविक समय में देखने में सक्षम होना चाहिए। + + +## समाधान + +इवेंट स्ट्रीमिंग डेटा परिवर्तनों को स्रोत से रिसीवर तक संचारित करने की अनुमति देती है। सूचना के अनुरोध के लिए सेवाओं की प्रतीक्षा करने के बजाय, सेवा अपने सभी कार्यक्रमों (या गतिविधियों) को लगातार स्ट्रीम करती है। यह इस बारे में चिंतित नहीं है कि सूचना का क्या होता है। +यह केवल वही करता है जो इसे करने की आवश्यकता होती है और इसे प्रसारित करता है, इस प्रकार यह किसी भी अन्य सेवा से पूरी तरह स्वतंत्र रहता है। diff --git a/content/hi/horizontal-scaling.md b/content/hi/horizontal-scaling.md new file mode 100644 index 0000000000..4288face34 --- /dev/null +++ b/content/hi/horizontal-scaling.md @@ -0,0 +1,35 @@ +--- +title: क्षैतिज स्केलिंग (Horizontal Scaling) +status: completed +category: concept +tags: ["Infrastructure"] +--- + +## यह क्या है + +क्षैतिज स्केलिंग एक ऐसी तकनीक है जिससे एक सिस्टम की क्षमता को अधिक [नोड्स](/nodes/) जोड़कर बढ़ाया जाता है, +बजाय अलग-अलग नोड्स में अधिक कंप्यूट संसाधन जोडे, जिसे [लम्बवत स्केलिंग](/vertical-scaling/) के रूप में जाना जाता है। +मान लीजिए, हमारे पास 4GB RAM की एक प्रणाली है और हम इसकी क्षमता को 16GB RAM तक बढ़ाना चाहते हैं, +इसे क्षैतिज रूप से स्केल करने का मतलब 16GB RAM सिस्टम पर जाने के बजाय 4 x 4GB RAM जोड़ना है। + +यह तरीका कार्यभार को बेहतर ढंग से वितरित करने के लिए नए इंस्टैंस, या [नोड्स](/nodes/) जोड़कर किसी एप्लिकेशन की कार्यक्षमता को बढ़ाता है। +सरल शब्दों में, इसका उद्देश्य व्यक्तिगत सर्वर की क्षमता बढ़ाने के बजाय सर्वर पर आने वाले भार को कम करना है। + +## समस्या + +जैसे ही किसी एप्लिकेशन की मांग उस एप्लिकेशन इंस्टेंस की वर्तमान क्षमता से ज़्यादा बढ़ती है, +हमें सिस्टम को [स्केल](/scalability/) करने के लिए एक तरीक़ा खोजने की आवश्यकता होती है। हम या तो सिस्टम में +अधिक नोड्स (क्षैतिज स्केलिंग) जोड़ सकते हैं या मौजूदा नोड्स (लंबवत स्केलिंग) में अधिक कंप्यूट संसाधन जोड़ सकते हैं। + +## समाधान + +क्षैतिज स्केलिंग एप्लिकेशन्स को अंतर्निहित क्लस्टर द्वारा प्रदान की जाने वाली किसी भी सीमा तक स्केल करने की अनुमति देता है। +सिस्टम में अधिक इन्सटेंसेस जोड़कर, ऐप अधिक संख्या में अनुरोधों को संसाधित कर सकता है। +यदि एक एकल नोड प्रति सेकंड 1,000 अनुरोधों को संभाल सकता है, तो प्रत्येक अतिरिक्त नोड प्रति सेकंड +लगभग 1,000 अनुरोधों की कुल संख्या में वृद्धि कर सकेगा। यह एप्लिकेशन को विशेष रूप से किसी भी नोड की क्षमता बढ़ाने की +आवश्यकता के बिना समवर्ती रूप से अधिक कार्य करने के लिए सक्षम बना देता है। + +## संबंधित परिभाषाएं + +* [लंबवत स्केलिंग](/vertical-scaling/) +* [स्वचालित स्केलिंग](/auto-scaling/) diff --git a/content/hi/idempotence.md b/content/hi/idempotence.md new file mode 100644 index 0000000000..694ceeb568 --- /dev/null +++ b/content/hi/idempotence.md @@ -0,0 +1,9 @@ +--- +title: इडेमपोटेन्स (Idempotence) +status: Completed +category: प्रॉपर्टी +tags: ["प्रॉपर्टी"] +--- + +गणित या कंप्यूटर विज्ञान में, इडेमपोटेन्स एक ऐसे ऑपरेशन का वर्णन करता है जिसका परिणाम हमेशा एक ही होता है, चाहे आप इसे कितनी भी बार निष्पादित करें। +यदि पैरामीटर समान हैं, तो एक इडेमपोटेन्ट ऑपरेशन को कई बार निष्पादित करने से कोई अतिरिक्त प्रभाव नहीं पड़ेगा। diff --git a/content/hi/kubernetes.md b/content/hi/kubernetes.md new file mode 100644 index 0000000000..5b73d13724 --- /dev/null +++ b/content/hi/kubernetes.md @@ -0,0 +1,35 @@ +--- +title: कुबेरनेट्स (Kubernetes) +status: Completed +category: प्रौद्योगिकी +tags: ["infrastructure", "fundamental", ""] +--- + +## यह क्या है + +कुबेरनेट्स, जिसे अक्सर K8s के रूप में संक्षिप्त किया जाता है, एक ओपन सोर्स कंटेनर ऑर्केस्ट्रेटर है। +यह एक "डेटासेंटर ऑपरेटिंग सिस्टम" के रूप में कार्य करते हुए आधुनिक इन्फ्रा़स्ट्रक्चर पर कंटेनरीकृत एप्लीकेशन के जीवनचक्र को स्वचालित करता है जो एक [वितरित प्रणाली](/distributed-systems/) में एप्लीकेशन का प्रबंधन करता है। + +कुबेरनेट्स [कंटेनर](/container/) को [नोड्स](/nodes/) के एक [क्लस्टर](/cluster/) में शेड्युल करता है। कंटेनरीकृत एप्लीकेशन को चलाने के लिए लोड बैलेंसर, सतत (persistent) स्टोरेज, आदि जैसे कई इन्फ्रा़स्ट्रक्चर के संसाधनों को बंडल करता है। + +कुबेरनेट्स स्वचालन और विस्तारणीयता को सक्षम करता है, जिससे उपयोगकर्ता पुनरुत्पादित तरीके से घोषणात्मक रूप से (नीचे देखें) एप्लीकेशन को तैनात कर सकते हैं। +Kubernetes अपने [API](/application-programming-interface/) के माध्यम से एक्स्टेंसिबल है, अनुभवी कुबेरनेट्स चिकित्सकों को उनकी आवश्यकताओं के अनुसार इसकी स्वचालन क्षमताओं का लाभ उठाने की अनुमति देता है। + +## समस्या + +इन्फ्रास्ट्रक्चर ऑटोमेशन और घोषणात्मक कॉन्फ़िगरेशन प्रबंधन लंबे समय से महत्वपूर्ण अवधारणाएं रही हैं, लेकिन [क्लाउड कंप्यूटिंग](/cloud-computing/) ने लोकप्रियता हासिल की है, इसलिए वे अधिक महत्वपूर्ण हो गए हैं। +जैसे-जैसे कम्प्यूट संसाधनों की मांग बढ़ती है और संगठनों को कम इंजीनियरों के साथ अधिक आयोजन करने की क्षमता प्रदान करने की आवश्यकता होती है, उस मांग को पूरा करने के लिए नई तकनीकों और कार्य विधियों की आवश्यकता होती है। + +## समाधान + +पारंपरिक [इन्फ्रास्ट्रक्चर ऐज कोड](/infrastructure-as-code/) टूल्स के समान, कुबेरनेट्स स्वचालन के साथ मदद करता है लेकिन कंटेनरों के साथ काम करने का फायदा है। +[वर्चुअल मशीन](/virtual-machine/) या भौतिक मशीनों की तुलना में कंटेनर कॉन्फ़िगरेशन बहाव के प्रति अधिक प्रतिरोधी होते हैं। + +इसके अतिरिक्त, कुबेरनेट्स घोषणात्मक रूप से काम करता है, जिसका अर्थ है कि ऑपरेटरों को मशीन को निर्देश देने के बजाय कि कुछ कैसे करना है, वे वर्णन करते हैं - आम तौर पर मेनिफेस्ट फाइलों के रूप में (उदाहरण के लिए, YAML) - बुनियादी ढांचा कैसा दिखना चाहिए। +कुबेरनेट्स तब "कैसे" का ख्याल रखता है। +इसके परिणामस्वरूप कुबेरनेट्स इन्फ्रा़स्ट्रक्चर के साथ कोड के रूप में बेहद संगत है। + +कुबेरनेट्स [स्वयं ठीक](/self-healing/) होने की शमता रखता है। +क्लस्टर की वास्तविक स्थिति हमेशा ऑपरेटर की इच्छित स्थिति से मेल खाती है। +यदि कुबेरनेट्स प्रकट फ़ाइलों में वर्णित से विचलन का पता लगाता है, तो कुबेरनेट्स नियंत्रक इसे ठीक करता है। +जबकि कुबेरनेट्स द्वारा उपयोग की जाने वाली अवसंरचना लगातार बदलती रहती है, कुबेरनेट्स लगातार और स्वचालित रूप से परिवर्तनों के अनुकूल यह सुनिश्चित करता है कि यह इच्छित स्थिति से मेल खाता है। diff --git a/content/hi/microservices.md b/content/hi/microservices.md new file mode 100644 index 0000000000..6d56c5e401 --- /dev/null +++ b/content/hi/microservices.md @@ -0,0 +1,18 @@ +--- +title: माइक्रोसर्विसेज(Microservices) +status: Completed +category: संकल्पना +tags : ["आर्किटेक्चर","मौलिक"] +--- + +## यह क्या है + +माइक्रोसर्विसेज अनुप्रयोग विकास के लिए एक आधुनिक दृष्टिकोण है जो क्लाउड नेटिव प्रौद्योगिकियों का लाभ उठाता है। जबकि आधुनिक एप्लिकेशन, जैसे नेटफ्लिक्स, एक ही ऐप प्रतीत होते हैं, वे वास्तव में छोटी सेवाओं का एक संग्रह हैं - सभी एक साथ मिलकर काम कर रहे हैं। उदाहरण के लिए, एक एकल पृष्ठ जो आपको वीडियो तक पहुंचने, खोजने और पूर्वावलोकन करने की अनुमति देता है, संभवतः छोटी सेवाओं द्वारा संचालित होता है जो प्रत्येक इसके एक पहलू को संभालती हैं (जैसे खोज, प्रमाणीकरण और आपके ब्राउज़र में पूर्वावलोकन चलाना)। संक्षेप में, माइक्रोसर्विसेज एक एप्लिकेशन आर्किटेक्चर पैटर्न को संदर्भित करता है जो आमतौर पर अखंड अनुप्रयोगों के विपरीत होता है । + +## समस्या + +माइक्रोसर्विसेज अखंड अनुप्रयोगों द्वारा उत्पन्न चुनौतियों का जवाब है। आम तौर पर, किसी एप्लिकेशन के विभिन्न हिस्सों को अलग-अलग स्केल करने की आवश्यकता होगी । एक ऑनलाइन स्टोर, उदाहरण के लिए, चेकआउट की तुलना में अधिक उत्पाद दृश्य होने जा रहे हैं। इसका मतलब है कि आपको चेकआउट की तुलना में चल रही उत्पाद दृश्य कार्यक्षमता की अधिक प्रतियों की आवश्यकता होगी। एक अखंड अनुप्रयोग में, तर्क के उन अंशों को अलग से तैनात नहीं किया जा सकता है। यदि आप उत्पाद की कार्यक्षमता को अलग-अलग माप नहीं सकते हैं, तो आपको पूरे ऐप को अन्य सभी घटकों के साथ डुप्लिकेट करना होगा जिनकी आपको आवश्यकता नहीं है - संसाधनों का अक्षम उपयोग। अखंड अनुप्रयोग भी डेवलपर्स के लिए डिज़ाइन की कमियों के आगे झुकना आसान बनाते हैं। क्योंकि सभी कोड एक ही स्थान पर हैं, इसलिए उस कोड को कसकर युग्मित करना आसान होता है और चिंताओं को अलग करने के सिद्धांत को लागू करना कठिन है। मोनोलिथ्स की अक्सर आवश्यकता होती है कि डेवलपर्स उत्पादक होने से पहले पूरे कोडबेस को समझें । + +## समाधान + +अलग-अलग माइक्रोसर्विसेज में कार्यक्षमता को अलग करने से उन्हें स्वतंत्र रूप से तैनात करना, अपडेट करना और स्केल करना आसान हो जाता है। अलग-अलग टीमों को एक बड़े एप्लिकेशन के अपने स्वयं के छोटे हिस्से पर ध्यान केंद्रित करने की अनुमति देकर आप बाकी संगठन को नकारात्मक रूप से प्रभावित किए बिना उनके ऐप पर काम करना भी आसान बना देते हैं। जबकि माइक्रोसर्विसेज कई समस्याओं को हल करते हैं, वे ऑपरेशनल ओवरहेड भी बनाते हैं - जिन चीजों को आपको परिनियोजित करने और परिमाण या अधिक के क्रम में वृद्धि का ट्रैक रखने की आवश्यकता होती है। कई क्लाउड-नेटिव तकनीकों का उद्देश्य माइक्रोसर्विसेज को तैनात करना और प्रबंधित करना आसान बनाना है। diff --git a/content/hi/observability.md b/content/hi/observability.md new file mode 100644 index 0000000000..36fccfb6ed --- /dev/null +++ b/content/hi/observability.md @@ -0,0 +1,17 @@ +--- +title: ऑब्जर्वेबिलिटी (Observability) +status: Completed +category: संकल्पना +tags: ["property", "", ""] +--- + +## यह क्या है +अवलोकनीयता अवलोकन के तहत सिस्टम से संकेतों के आधार पर कार्रवाई योग्य अंतर्दृष्टि को लगातार उत्पन्न करने और खोजने की क्षमता है। दूसरे शब्दों में, अवलोकनीयता उपयोगकर्ताओं को बाहरी आउटपुट से सिस्टम की स्थिति को समझने और (सुधारात्मक) कार्रवाई करने की अनुमति देती है। + +## समस्या +कंप्यूटर सिस्टम को निम्न-स्तरीय संकेतों जैसे सीपीयू समय, मेमोरी, डिस्क स्थान, और उच्च-स्तरीय और व्यावसायिक संकेतों को देखकर मापा जाता है, जिसमें एपीआई प्रतिक्रिया समय, त्रुटियां, प्रति सेकंड लेनदेन आदि शामिल हैं। + +किसी प्रणाली की अवलोकनीयता का उसके परिचालन और विकास लागतों पर महत्वपूर्ण प्रभाव पड़ता है। ऑब्जर्वेबल सिस्टम अपने ऑपरेटरों को सार्थक, कार्रवाई योग्य डेटा प्रदान करते हैं, जिससे उन्हें अनुकूल परिणाम (त्वरित घटना प्रतिक्रिया, डेवलपर उत्पादकता में वृद्धि) और कम मेहनत और डाउनटाइम प्राप्त करने की अनुमति मिलती है। + +## समाधान +यह समझना महत्वपूर्ण है कि अधिक जानकारी आवश्यक रूप से अधिक अवलोकन योग्य प्रणाली में परिवर्तित नहीं होती है। वास्तव में, कभी-कभी, सिस्टम द्वारा उत्पन्न जानकारी की मात्रा एप्लिकेशन द्वारा उत्पन्न शोर से मूल्यवान स्वास्थ्य संकेतों की पहचान करना कठिन बना सकती है। अवलोकनीयता के लिए सही निर्णय लेने के लिए सही उपभोक्ता (मानव या सॉफ़्टवेयर का टुकड़ा) के लिए सही समय पर सही डेटा की आवश्यकता होती है। diff --git a/content/hi/security-chaos-engineering.md b/content/hi/security-chaos-engineering.md new file mode 100644 index 0000000000..fe82b30f62 --- /dev/null +++ b/content/hi/security-chaos-engineering.md @@ -0,0 +1,33 @@ +--- +title: सुरक्षा अव्यवस्था इंजीनियरिंग (Security Chaos Engineering) +status: Completed +category: अवधारणा +tags: ["security", "methodology", ""] +--- + +## यह क्या है + +सुरक्षा अव्यवस्था इंजीनियरिंग(SCE) एक ऐसी शाखा है जो की [अव्यवस्था इंजीनियरिंग](/chaos-engineering/) पर आधारित है। +SCE वितरित प्रणाली पर सक्रिय सुरक्षा प्रयोग करता है जिससे प्रणाली की क्षमता में विश्वास बढ़ता है ताकि यह +किसी भी तरह की उपेक्षा या बुरी शर्तों के साथ भी संचालित किया जा सके। सुरक्षा अव्यवस्था इंजीनियर इसे प्राप्त करने के लिए वैज्ञानिक पद्धति लूप का उपयोग करते हैं, +जिसमें स्थिरावस्था, अनुमान, निरंतर सत्यापन, सीखा गया सबक और शमन कार्यान्वयन शामिल होते हैं। + +## समस्या + +[साइट अवारी इंजीनियरों](/site-reliability-engineering/)(SREs) और साइबर सुरक्षा इंजीनियरों के लिए मुख्य प्राथमिकता होती है +शून्य डाउनटाइम प्राप्त करने और व्यावसायिक प्रभाव को कम करने के लक्ष्य के साथ जितनी जल्दी हो सके सेवा बहाल करना। +SREs और साइबर सुरक्षा इंजीनियरों पूर्व-विफलता और उसके बाद के घटनाओं दोनों से सुलझाना करते हैं। +अधिकांश सुरक्षा समस्याओं को तुरंत खोजना और ठीक करना चुनौतीपूर्ण होता हैं, जिससे एप्लिकेशन या सिस्टम की कार्यक्षमता प्रभावित होती हैं। +इसके अतिरिक्त, विकास चरण के दौरान सुरक्षा घटनाओं को उजागर करना आमतौर पर मुश्किल होता है। + +## समाधान + +सुरक्षा अव्यवस्था इंजीनियरिंग [अवलोकनीयता](/observability/) और साइबर प्रतिरोध क्षमता अभ्यासों के आधार पर बनाई गई है। +इसका उद्देश्य "अज्ञात अज्ञात" को उजागर करना और सिस्टम में आत्मविश्वास बनाना है, +साइबर प्रतिरोध क्षमता बढ़ाकर और अवलोकनीयता को सुधारकर। +इंजीनियरिंग टीम धीरे-धीरे सुरक्षा संबंधी चिंताओं के लिए जागरूकता में सुधार करेंगे +जटिल बुनियादी संरचना, प्लेटफॉर्म और वितरित सिस्टमों के अंदर। +एससीई पूरे उत्पाद की साइबर प्रतिरोधकता में सुधार करता है, छिपी सुरक्षा समस्याओं को उजागर करता है, +क्लासिकल ब्लाइंड स्पॉट को उजागर करता है और टीमों को महत्वपूर्ण एज केस के लिए तैयार करता है। +यह दृष्टिकोण [एसआरईएस(SREs)](/site-reliability-engineering/), [डेवऑप्स(DevOps)](/devops/) और [डेवसेकओप्स(DevSecOps)](/devsecops/) इंजीनियरों को सिस्टम में विश्वास बनाने, +साइबर प्रतिरोध क्षमता बढ़ाने और अवलोकनीयता में सुधार करने में मदद करता है। \ No newline at end of file diff --git a/content/hi/self-healing.md b/content/hi/self-healing.md new file mode 100644 index 0000000000..1cba046474 --- /dev/null +++ b/content/hi/self-healing.md @@ -0,0 +1,11 @@ +--- +title: स्व-उपचार (Self Healing) +status: completed +category: property +tags: ["infrastructure", "property"] +--- + +एक स्व-उपचार प्रणाली बिना किसी मानवीय हस्तक्षेप के कुछ प्रकार की विफलताओं से उबरने में सक्षम होती है। +इसमें एक "अभिसरण" या "नियंत्रण" लूप होता है, जो सिस्टम की वास्तविक स्थिति को सक्रिय रूप से देखता है और इसकी तुलना उस स्थिति से करता है जिसे ऑपरेटर शुरू में चाहते थे। +यदि कोई अंतर होता है (उदाहरण के लिए, वांछित से कम एप्लिकेशन के इंस्टेंस चल रहे हैं), तो +यह सुधारात्मक कार्रवाई करेगा (उदाहरण के लिए, नए एप्लीकेशन इंस्टैंस प्रारंभ करन)। \ No newline at end of file diff --git a/content/hi/serverless.md b/content/hi/serverless.md new file mode 100644 index 0000000000..be40b2d47e --- /dev/null +++ b/content/hi/serverless.md @@ -0,0 +1,18 @@ +--- +title: सर्वरलेस (Serverless) +status: Completed +category: प्रौद्योगिकी +tags: ["architecture", "", ""] +--- + +## यह क्या है + +सर्वरलेस एक क्लाउड नेटिव डेवलपमेंट मॉडल है जो डेवलपर्स को सर्वर को प्रबंधित किए बिना एप्लिकेशन बनाने और चलाने की अनुमति देता है। सर्वरलेस में सर्वर अभी भी हैं, लेकिन वे [ऐब्स्ट्रैक्टेड](/hi/abstraction/) ऐप डेवलपमेंट से दूर हैं। एक क्लाउड प्रदाता सर्वर इन्फ्रास्ट्रक्चर के प्रावधान, रखरखाव और [स्केलिंग](/hi/scalability/) के नियमित कार्य को संभालता है। डेवलपर्स डिप्लॉयमेंट के लिए अपने कोड को [कंटेनर](/hi/container/) में पैकेज कर सकते हैं। एक बार डिप्लॉय होने के बाद, सर्वरलेस ऐप्स डिमांड का जवाब देते हैं और आवश्यकतानुसार स्वचालित रूप से ऊपर और नीचे स्केल करते हैं। सार्वजनिक क्लाउड प्रदाताओं से सर्वरलेस पेशकशों को आमतौर पर इवेंट-संचालित निष्पादन मॉडल के माध्यम से ऑन-डिमांड मीटर किया जाता है। नतीजतन, जब कोई सर्वरलेस फ़ंक्शन निष्क्रिय रहता है, तो इसका कुछ भी खर्च नहीं होता है। + +## समस्या + +एक मानक [इन्फ्रास्ट्रक्चर एस सर्विस (IaaS)](/infrastructure-as-a-service/) [क्लाउड कंप्यूटिंग](/cloud-computing/) मॉडल के तहत, उपयोगकर्ता क्षमता की इकाइयों को पूर्व-खरीद करते हैं, जिसका अर्थ है कि आप अपने ऐप्स चलाने के लिए हमेशा-ऑन सर्वर घटकों के लिए सार्वजनिक क्लाउड प्रदाता का भुगतान करते हैं। उच्च मांग के समय सर्वर क्षमता को बढ़ाना और उस क्षमता की आवश्यकता नहीं होने पर इसे कम करना उपयोगकर्ता की जिम्मेदारी है। ऐप को चलाने के लिए आवश्यक क्लाउड इन्फ्रास्ट्रक्चर तब भी सक्रिय रहता है, जब ऐप का उपयोग नहीं किया जा रहा हो। + +## समाधान + +इसके विपरीत, सर्वरलेस आर्किटेक्चर के साथ, ऐप्स केवल आवश्यकतानुसार लॉन्च किए जाते हैं। जब कोई ईवेंट चलने के लिए ऐप कोड को ट्रिगर करता है, तो सार्वजनिक क्लाउड प्रदाता गतिशील रूप से उस कोड के लिए संसाधन आवंटित करता है। कोड निष्पादित होने पर उपयोगकर्ता भुगतान करना बंद कर देता है। लागत और दक्षता लाभों के अलावा, सर्वरलेस डेवलपर्स को ऐप स्केलिंग और सर्वर प्रोविजनिंग से जुड़े नियमित और छोटे कार्यों से मुक्त करता है। सर्वरलेस होने के साथ, नियमित कार्य जैसे ऑपरेटिंग सिस्टम और फ़ाइल सिस्टम का प्रबंधन, सुरक्षा पैच, लोड संतुलन, क्षमता प्रबंधन, स्केलिंग, लॉगिंग और निगरानी सभी क्लाउड सेवा प्रदाता को लोड कर दिए जाते हैं। diff --git a/content/hi/service discovery.md b/content/hi/service discovery.md new file mode 100644 index 0000000000..6078f3bb7f --- /dev/null +++ b/content/hi/service discovery.md @@ -0,0 +1,17 @@ +--- +title: सर्विस डिस्कवरी (Service Discovery) +status: completed +category: अवधारणा +--- + +## यह क्या है + +सर्विस डिस्कवरी एक सेवा बनाने वाले व्यक्तिगत उदाहरणों को खोजने की प्रक्रिया है। एक सर्विस डिस्कवरी टूल, सर्विस बनाने वाले विभिन नोड्स या एंड-पॉइंट्स को ट्रैक करता है। + +## समस्या + +क्लाउड नेटिव आर्किटेक्चर गतिशील और तरल हैं, जिसका अर्थ है कि वे लगातार बदलते रहेते हैं। एक कंटेनरीकृत ऐप संभवतः अपने जीवनकाल में कई बार शुरू और बंद होगा। हर बार ऐसा होने पर, इसका एक नया पता होगा और कोई भी ऐप जो इसे खोजना चाहता है उसे नए स्थान की जानकारी प्रदान करने के लिए एक टूल की आवश्यकता होगी। + +## समाधान + +सर्विस डिस्कवरी नेटवर्क के भीतर ऐप्स का ट्रैक रखती है ताकि जरूरत पड़ने पर वे एक-दूसरे को ढूंढ सकें। यह व्यक्तिगत सेवाओं को खोजने और संभावित रूप से पहचानने के लिए एक सामान्य स्थान प्रदान करता है। सर्विस की खोज करने वाले सर्च-इंजन डेटाबेस-जैसे उपकरण हैं, जो इस बारे में जानकारी संग्रहीत करते हैं कि कौन सी सेवाएँ मौजूद हैं और उनका पता कैसे लगाया जाए। diff --git a/content/hi/service-mesh.md b/content/hi/service-mesh.md new file mode 100644 index 0000000000..7b0a2a6cf5 --- /dev/null +++ b/content/hi/service-mesh.md @@ -0,0 +1,14 @@ +--- +title: सर्विस मेश (Service Mesh) +status: Completed +category: प्रौद्योगिकी +--- + +## यह क्या है +एक [माइक्रोसर्विसेज](/microservices/) दुनिया में, ऐप्स को कई छोटी [सेवाओं](/service/) में विभाजित किया जाता है जो एक नेटवर्क पर संचार करते हैं। आपके वाईफाई नेटवर्क की तरह, कंप्यूटर नेटवर्क आंतरिक रूप से अविश्वसनीय, हैक करने योग्य और अक्सर धीमे होते हैं। सर्विस मेश सेवाओं के बीच ट्रैफ़िक (यानी, संचार) को प्रबंधित करके और [विश्वसनीयता](/reliability/), [अवलोकनशीलता](/observability/), और सुरक्षा सुविधाओं को सभी सेवाओं में समान रूप से जोड़कर चुनौतियों के इस नए सेट का समाधान करता है। + +## समस्या +एक माइक्रोसर्विस आर्किटेक्चर में स्थानांतरित होने के बाद, इंजीनियर अब सैकड़ों, संभवतः हजारों व्यक्तिगत सेवाओं के साथ काम कर रहे हैं, सभी को संवाद करने की आवश्यकता है। इसका मतलब है कि नेटवर्क पर बहुत अधिक ट्रैफ़िक आगे और पीछे जा रहा है। इसके शीर्ष पर, व्यक्तिगत अनुप्रयोगों को नियामक आवश्यकताओं का समर्थन करने के लिए संचार एन्क्रिप्ट करने, संचालन टीमों को सामान्य मीट्रिक प्रदान करने, या मुद्दों का निदान करने में सहायता के लिए यातायात में विस्तृत अंतर्दृष्टि प्रदान करने की आवश्यकता हो सकती है। यदि व्यक्तिगत अनुप्रयोगों में बनाया गया है, तो इनमें से प्रत्येक विशेषता टीमों के बीच घर्षण पैदा करेगी और नई सुविधाओं के विकास को धीमा कर देगी। + +## समाधान +सर्विस मेश कोड परिवर्तन की आवश्यकता के बिना एक क्लस्टर में सभी सेवाओं में समान रूप से विश्वसनीयता, अवलोकन क्षमता और सुरक्षा सुविधाएँ जोड़ते हैं। सर्विस मेश से पहले, उस कार्यक्षमता को हर एक सेवा में एन्कोड किया जाना था, जो बगस और तकनीकी ऋण का संभावित स्रोत बन गया। diff --git a/content/hi/service-proxy.md b/content/hi/service-proxy.md new file mode 100644 index 0000000000..9178a7630e --- /dev/null +++ b/content/hi/service-proxy.md @@ -0,0 +1,28 @@ +--- +title: सर्विस प्रॉक्सी (Service Proxy) +status: Completed +category: टैकनोलजी +tags: ["नेटवर्किंग"] +--- + +सर्विस प्रॉक्सी किसी दिए गए [सर्विस](/service/) से या उससे आने वाले ट्रैफ़िक को रोकता है, +उसमे फिर कुछ नियम लागू करता है, फिर उस ट्रैफ़िक को किसी अन्य सर्विस पर आगे भेजता है। +यह अनिवार्य रूप से एक "मध्यस्थ" के रूप में कार्य करता है जो नेटवर्क ट्रैफ़िक के बारे में जानकारी एकत्र करता है और उस पर नियम लागू करता है। + +## समस्या + +सर्विस से सर्विस संचार (उर्फ नेटवर्क ट्रैफ़िक) का ट्रैक रखने के लिए और +संभावित रूप से इसे परिवर्तित या पुन: निर्देशित करने के लिए, हमें डेटा एकत्र करने की आवश्यकता होती है। +परंपरागत रूप से, डेटा संग्रह और नेटवर्क ट्रैफ़िक प्रबंधन को सक्षम करने वाला कोड प्रत्येक एप्लिकेशन के भीतर एम्बेड किया जाता है। + +## समाधान + +एक सर्विस प्रॉक्सी हमें इस कार्यक्षमता को लागू करने की अनुमति देती है। +अब इसे ऐप्स के भीतर रहने की आवश्यकता नहीं होगी। +इसके बजाय, अब इसे प्लेटफ़ॉर्म की परत (जहां आपके ऐप्स चलते हैं) में एम्बेड किया जायेगा। + +सर्विस के बीच गेटकीपर के रूप में कार्य करते हुए, प्रॉक्सी यह जानकारी प्रदान करती है कि किस प्रकार का संचार हो रहा है। +अपनी निरीक्षण के आधार पर, वे यह निर्धारित करती है कि किसी विशेष अनुरोध को कहां भेजना है या इसे पूरी तरह से अस्वीकार करना है। + +प्रॉक्सी महत्वपूर्ण डेटा एकत्र करती है, रूटिंग का प्रबंधन करती है (सर्विस के बीच ट्रैफ़िक को समान रूप से फैलाना या यदि कुछ सेवाएँ ख़राब हो जाती हैं तो पुनः रूट करना), +इंक्रिप्टेड कनेक्शन, और कैश मैमोरी (संसाधन की खपत को कम करना और आदि)। diff --git a/content/hi/service.md b/content/hi/service.md new file mode 100644 index 0000000000..91e2e1e9b3 --- /dev/null +++ b/content/hi/service.md @@ -0,0 +1,12 @@ +--- +title: सेवा(Service) +status: Completed +category: संकल्पना +tags: ["वास्तुकला", "", ""] +--- + +कृपया ध्यान दें कि आईटी में सेवा के कई अर्थ होते हैं। +हम एक अधिक पारंपरिक अर्थ पर ध्यान केंद्रित करेंगे +यदि सेवाएँ माइक्रोसर्विसेज से भिन्न हैं और वे कैसे भिन्न हैं, यह बारीक है और अलग-अलग लोगों की अलग-अलग राय हो सकती है। +एक उच्च-स्तरीय परिभाषा के लिए, हम उन्हें समान मानेंगे। +कृपया [माइक्रोसर्विसेज](/microservices/) परिभाषा देखें। diff --git a/content/hi/shift-left.md b/content/hi/shift-left.md new file mode 100644 index 0000000000..eba794ab21 --- /dev/null +++ b/content/hi/shift-left.md @@ -0,0 +1,22 @@ +--- +title: शिफ्ट लेफ्ट (Shift Left) +status: Completed +category: concept +--- + +## यह क्या है +शिफ्ट लेफ्ट में "लेफ्ट" सॉफ़्टवेयर विकास जीवनचक्र के पहले चरणों की ओर संकेत करता है, जहां चरणों को बाएं से दाएं दिशा में निष्पादित किया जाता है। शिफ्ट लेफ्ट अभिक्रिया सॉफ़्टवेयर विकास जीवनचक्र के अंतिम चरणों की बजाय, प्रारंभिक चरणों में परीक्षण, सुरक्षा, या अन्य विकास प्रथाओं को संचालित करने की प्रथा है। + +प्रारंभ में परीक्षण की प्रक्रिया को वारंट किया जाता था, लेकिन अब शिफ्ट लेफ्ट को सुरक्षा और डिप्लॉयमेंट जैसे सॉफ़्टवेयर विकास और [डेवओप्स](/devops/), के अन्य पहलुओं में भी लागू किया जा सकता है। + +## समस्या +सुरक्षा समस्याएं, बग और सॉफ़्टवेयर के दोषों को सुधारना और ठीक करना अधिक कठिन और महंगा हो सकता है, अगर उन्हें विकास चक्र के दौरान या डिप्लॉयमेंट के पश्चात खोजा जाता है, विशेषतः अगर सॉफ़्टवेयर पहले से ही उत्पादन में डिप्लॉय हो चुका हो। + +## समाधान +सॉफ़्टवेयर विकास के लिए शिफ्ट लेफ्ट मानसिकता अपनाने से, टीमें विकास जीवनचक्र के दौरान परीक्षण और सुरक्षा को लागू कर सकती हैं। और क्योंकि परीक्षण और सुरक्षा की जिम्मेदारी विकास टीम के सदस्यों के बीच साझा की जाती है — सॉफ़्टवेयर इंजीनियर से क्वालिटी एश्योरेंस और ऑपरेशन तक — तो हर कोई एक आवेदन की स्थिरता और सुरक्षा की सुनिश्चितता में भाग लेता है। + +इसके अलावा, शिफ्ट लेफ्ट ने निरंतर सुधार और विकास के लिए [एजाइल](/agile-software-development/), दृष्टिकोण को अपनाने की संभावना प्रदान की है। टीमें छोटे-छोटे अनुक्रमिक सुधार कर सकती हैं और समस्याओं को पहले ही पहचान सकती हैं। +यह दृष्टिकोण इंजीनियरों को सुरक्षित विकास के अभ्यास को डिजाइन करने और आर्किटेक्चर की अवस्था को अपनाने में सुविधा प्रदान करता है। विकास चक्र के दौरान परीक्षण करने से सॉफ़्टवेयर रिलीज़ से पहले, परीक्षण करने का आवश्यक समय कम हो जाता है। + +कई सॉफ़्टवेयर उपकरण और SaaS समाधान इन प्रथाओं को लेफ्ट शिफ्ट करने में मदद करते हैं। हालांकि, शिफ्ट लेफ्ट को टीम के भीतर सुधारित प्रक्रियाओं और सांस्कृतिक परिवर्तनों के माध्यम से भी लागू किया जा सकता है। + diff --git a/content/hi/tightly-coupled-architecture.md b/content/hi/tightly-coupled-architecture.md new file mode 100644 index 0000000000..166b1da433 --- /dev/null +++ b/content/hi/tightly-coupled-architecture.md @@ -0,0 +1,10 @@ +--- +title: टाइट्ली कपल्ड आर्किटेक्चर (Tightly Coupled Architecture) +status: Completed +category: वास्तुकला +--- + + +टाइट्ली कपल्ड आर्किटेक्चर एक आर्किटेक्चर शैली है जहां कई अनुप्रयोग घटक एक दूसरे पर निर्भर होते हैं (लूज़ली कपल्ड आर्किटेक्चर के विपरीत प्रतिमान)। इसका मतलब यह है कि एक घटक में बदलाव से अन्य घटकों पर असर पड़ने की संभावना है। आम तौर पर अधिक लूज़ली कपल्ड आर्किटेक्चर की तुलना में इसे लागू करना आसान होता है, लेकिन यह सिस्टम को कैस्केडिंग विफलताओं के प्रति अधिक संवेदनशील बना सकता है। उन्हें घटकों के समन्वित रोलआउट की भी आवश्यकता होती है जो डेवलपर उत्पादकता पर दबाव बन सकता है। + +टाइट्ली कपल्ड एप्लिकेशन आर्किटेक्चर अनुप्रयोगों के निर्माण का एक काफी पारंपरिक तरीका है। हालांकि जरूरी नहीं कि वे माइक्रोसर्विस विकास की सभी सर्वोत्तम प्रथाओं के अनुरूप हों, लेकिन वे विशिष्ट परिस्थितियों में उपयोगी हो सकते हैं। वे लागू करने में तेज़ और सरल होते हैं और मोनोलिथिक अनुप्रयोगों की तरह वे प्रारंभिक विकास चक्र को गति दे सकते हैं। \ No newline at end of file diff --git a/content/hi/transport-layer-security.md b/content/hi/transport-layer-security.md new file mode 100644 index 0000000000..88cb51e679 --- /dev/null +++ b/content/hi/transport-layer-security.md @@ -0,0 +1,29 @@ +--- +title: ट्रांसपोर्ट लेयर सिक्योरिटी (Transport Layer Security) +status: Completed +category: अवधारणा +tags: ["सिक्योरिटी", "नेटवर्किंग"] +--- + +## यह क्या है + +ट्रांसपोर्ट लेयर सिक्योरिटी (टीएलएस) एक प्रोटोकॉल है जिसे नेटवर्क पर संचार को बढ़ी हुई सुरक्षा प्रदान करने के लिए डिज़ाइन किया गया है। +यह इंटरनेट पर भेजे गए डेटा की सुरक्षित डिलीवरी सुनिश्चित करता है, +जैसे डेटा की संभावित निगरानी या परिवर्तन से बचाव। +यह प्रोटोकॉल मैसेजिंग, ई-मेल आदि जैसे अनुप्रयोगों में व्यापक रूप से उपयोग किया जाता है। + +## यह किस समस्या का समाधान करता है + +टीएलएस के बिना, ब्राउज़िंग आदतें, ई-मेल पत्रचार, ऑनलाइन चैट और कॉन्फ्रेंसिंग कॉल जैसी संवेदनशील जानकारी +ट्रांसमिशन के दौरान दूसरों द्वारा आसानी से पता लगाई और संशोधित कि जा सकती है। +टीएलएस का समर्थन करने के लिए सर्वर और क्लाइंट एप्लिकेशन को सक्षम या इनेबल करना यह सुनिश्चित करता है, +ता की उनके बीच प्रसारित डेटा गोपित रहे और डेटा तीसरे पक्ष द्वारा देखने योग्य ना हो। + +## यह कैसे मदद करता है + +टीएलएस एन्कोडिंग तकनीकों के जोड़ का उपयोग करता है जो नेटवर्क पर डेटा संचारित करते समय सुरक्षा प्रदान करते हैं। +टीएलएस क्लाइंट एप्लिकेशन और सर्वर, जैसे वेब ब्राउज़र और बैंकिंग साइट के बीच एन्क्रिप्टेड कनेक्शन की अनुमति देता है। +यह क्लाइंट एप्लिकेशन को उस सर्वर की सकारात्मक रूप से पहचान करने की भी अनुमति देता है जिस पर वे कॉल कर रहे हैं, +जिससे ग्राहक द्वारा किसी धोखाधड़ी वाली साइट से बात करने का जोखिम कम हो जाता है। +यह सुनिश्चित करता है कि तीसरे पक्ष में टीएलएस का उपयोग करके अनुप्रयोगों के बीच प्रसारित डेटा को देखने और निगरानी करने में असमर्थ हो। +जो संवेदनशील और निजी जानकारी जैसे क्रेडिट कार्ड नंबर, पासवर्ड, स्थान आदि की सुरक्षा करता है। diff --git a/content/hi/vertical-scaling.md b/content/hi/vertical-scaling.md new file mode 100644 index 0000000000..7f377df1fe --- /dev/null +++ b/content/hi/vertical-scaling.md @@ -0,0 +1,33 @@ +--- +शीर्षक: लंबवत स्केलिंग +status: Completed +श्रेणी: संकल्पना +टैग: ["बुनियादी ढांचा", "", ""] +--- + +## यह क्या है + +वर्टिकल स्केलिंग, जिसे "स्केलिंग अप एंड डाउन" के रूप में भी जाना जाता है, यह एक ऐसी तकनीक है जिसे +कार्यभार बढ़ने पर अलग-अलग [नोड्स](/नोड्स/) में सीपीयू और मेमोरी जोड़कर सिस्टम की क्षमता बढ़ाई जाती है। +मान लीजिए, आपके पास 4GB रैम वाला कंप्यूटर है और आप इसकी क्षमता 16GB रैम तक बढ़ाना चाहते हैं, +इसे लंबवत रूप से स्केल करने का अर्थ है 16GB रैम सिस्टम पर स्विच करना। +(कृपया भिन्न स्केलिंग दृष्टिकोण के लिए [क्षैतिज स्केलिंग](/क्षैतिज-स्केलिंग/) देखें।) + +## यह समस्या का समाधान करता है + +जैसे-जैसे किसी एप्लिकेशन की मांग उस एप्लिकेशन इंस्टेंस की वर्तमान क्षमता से अधिक बढ़ती है, +तो हमें सिस्टम को स्केल करने (क्षमता जोड़ने) का एक तरीका खोजने की जरूरत है। +हम या तो मौजूदा नोड्स में अधिक गणना संसाधन जोड़ सकते हैं (ऊर्ध्वाधर स्केलिंग) +या सिस्टम में अधिक नोड्स ([क्षैतिज स्केलिंग](/क्षैतिज-स्केलिंग/))। +[स्केलेबिलिटी](/स्केलेबिलिटी/) प्रतिस्पर्धात्मकता, दक्षता, प्रतिष्ठा और गुणवत्ता में योगदान करती है। + +## यह कैसे मदद करता है + +वर्टिकल स्केलिंग आपको एप्लिकेशन कोड को बदले बिना अपने सर्वर का आकार बदलने की अनुमति देता है। +यह क्षैतिज स्केलिंग के विपरीत है, जहां ऐप को स्केल करने के लिए प्रतिकृति चाहिए, जहां संभावित रूप से कोड अपडेट की आवश्यकता होती है। +वर्टिकल स्केलिंग से मौजूदा एप्लिकेशन की क्षमता बढ़ाई जा सकती है जैसे कंप्यूट संसाधन जोड़ने से ऐप को अधिक अनुरोधों को संसाधित करने और समवर्ती रूप से अधिक कार्य करने की अनुमति मिलती है। + +## संबंधित शर्तें + +* [क्षैतिज स्केलिंग](/क्षैतिज-स्केलिंग/) +* [ऑटो स्केलिंग](/ऑटो-स्केलिंग/) diff --git a/content/hi/virtualization.md b/content/hi/virtualization.md new file mode 100644 index 0000000000..38c088e547 --- /dev/null +++ b/content/hi/virtualization.md @@ -0,0 +1,22 @@ +--- +title: वर्चुअलाइजेशन (Virtualization) +status: Feedback Appreciated +category: संकल्पना +tags: ["Fundamental", "Infrastructure", "Methodology"] +--- + +## यह क्या है + +क्लाउड नेटिव के संदर्भ में वर्चुअलाइजेशन, एक वर्चुअल कंप्यूटर लेने की प्रक्रिया को संदर्भित करता है, जिसे कभी-कभी सर्वर भी कहा जाता है, और उसे कई पृथक ऑपरेटिंग सिस्टम चलाने की अनुमति देता है। +उन पृथक ऑपरेटिंग सिस्टम और उनके समर्पित कंप्यूट संसाधन (सीपीयू, मेमोरी और नेटवर्क) को वर्चुअल मशीन या 'वीएम' (VM) कहा जाता है। जब हम वर्चुअल मशीन के बारे में बात करते हैं, +तो हम सॉफ्टवेयर-परिभाषित कंप्यूटर के बारे में बात कर रहे होते हैं। यह कुछ ऐसा है जो वास्तविक कंप्यूटर की तरह दिखता और कार्य तो करता है लेकिन अन्य वर्चुअल मशीनों के साथ हार्डवेयर को साझा कर रहा होता है। +क्लाउड कंप्यूटिंग मुख्य रूप से वर्चुअल मशीन की तकनीक द्वारा संचालित होती है। उदाहरण के तौर पर, आप AWS से "कंप्यूटर" किराये पर ले सकते हैं- यह कंप्यूटर वास्तव में एक वर्चुअल मशीन होगा। + +## समस्या +वर्चुअलाइजेशन कई समस्याओं का समाधान करता है, जिसमें सुरक्षा के लिए एक दूसरे से अलग होते हुए भी एक ही भौतिक मशीन पर और अधिक एप्लीकेशन को चलने की अनुमति देकर हार्डवेयर के उपयोग में सुधार भी कर सकते हैं। + +## समाधान + +वर्चुअल मशीन पर चलने वाले विभिन्न एप्लीकेशन को इस बात की कोई जानकारी नहीं होती है कि वे एक भौतिक कंप्यूटर को साझा कर रहीं हैं। वर्चुअलाइजेशन डेटासेंटर के उपयोगकर्ताओं को डेटासेंटर में एक नया +कंप्यूटर को जोड़ने की भौतिक बाधाओं के बारे में चिंता किए बिना, मिनटों में एक नए "कंप्यूटर" (वि एम) को तुरंत शुरू करने की अनुमति देता है। वर्चुअल मशीन उपयोगकर्ताओं को एक नया वर्चुअल कंप्यूटर प्राप्त +करने के लिए लगने वाली समयावधि को घटाने में भी सक्षम बनाता है। diff --git a/content/hi/zero-trust-architecture.md b/content/hi/zero-trust-architecture.md new file mode 100644 index 0000000000..c21ab7e4a9 --- /dev/null +++ b/content/hi/zero-trust-architecture.md @@ -0,0 +1,18 @@ +--- +title: ज़ीरो ट्रस्ट आर्किटेक्चर (Zero Trust Architecture) +status: Completed +category: संकल्पना +tags: ["security", "", ""] +--- + +## यह क्या है + +ज़ीरो ट्रस्ट आर्किटेक्चर IT प्रणाली के डिजाइन और कार्यान्वयन के लिए एक दृष्टिकोण निर्धारित करता है जहां विश्वास पूरी तरह से हटा दिया गया है। मूल सिद्धांत "कभी भरोसा न करें, हमेशा सत्यापित करें", उपकरण या प्रणाली स्वयं, प्रणाली के अन्य घटकों से संचार करते समय, ऐसा करने से पहले हमेशा स्वयं को सत्यापित करें। आज कई नेटवर्क में, निगमित नेटवर्क के भीतर, प्रणाली और उपकरण के अंदर स्वतंत्र रूप से एक दूसरे के साथ संवाद कर सकते हैं क्योंकि वे निगमित नेटवर्क परिधि की विश्वसनीय सीमा के भीतर हैं। ज़ीरो ट्रस्ट आर्किटेक्चर विपरीत दृष्टिकोण लेता है, हालांकि नेटवर्क परिधि के अंदर, किसी भी संचार से पहले प्रणाली के भीतर घटकों को पहले सत्यापन पास करना होगा। + +## समस्या यह संबोधित करता है + +पारंपरिक ट्रस्ट आधारित दृष्टिकोण के साथ जहां प्रणाली और उपकरण जो निगमित नेटवर्क परिधि के भीतर मौजूद हैं, धारणा यह है कि क्योंकि विश्वास है, कोई समस्या नहीं है। हालांकि, ज़ीरो ट्रस्ट आर्किटेक्चर मानता है कि ट्रस्ट एक भेद्यता है। उस घटना में जहां एक हमलावर ने एक विश्वसनीय उपकरण तक पहुंच प्राप्त कर ली है, उस उपकरण को दिए गए भरोसे और पहुंच के स्तर के आधार पर, प्रणाली अब हमले की चपेट में है, क्योंकि हमलावर "विश्वसनीय" नेटवर्क परिधि के भीतर है और पूरे प्रणाली में बाद में स्थानांतरित करने में सक्षम है। ज़ीरो ट्रस्ट आर्किटेक्चर में, विश्वास हटा दिया जाता है, इसलिए हमले की सतह को कम करता है एक हमलावर के रूप में अब पूरे प्रणाली में आगे जाने से पहले सत्यापित करने के लिए मजबूर किया जाता है। + +## यह कैसे मदद करता है + +ज़ीरो ट्रस्ट आर्किटेक्चर को अपनाने से हमले की सतह में कमी के साथ बढ़ी हुई सुरक्षा का प्रमुख लाभ मिलता है। अपने निगमित प्रणाली से विश्वास हटाने से अब सुरक्षा द्वारों की संख्या और ताकत बढ़ जाती है। प्रणाली के अन्य क्षेत्रों तक पहुंच प्राप्त करने के लिए एक हमलावर को गुजरना पड़ता है। diff --git a/i18n/hi.toml b/i18n/hi.toml index c38f9302bc..84182b2a6c 100644 --- a/i18n/hi.toml +++ b/i18n/hi.toml @@ -20,21 +20,21 @@ other = "में" # Phrases for tags [ui_see_all_tags] -other = "See all tags" +other = "सभी टैग को देख़े" [ui_tag] -other = "Tag" +other = "टैग" [ui_tags] -other = "Tags" +other = "टैग्स" [ui_search_by_tags] -other = "Browse by Tags" +other = "टैग द्वारा ब्राउज करें" [ui_tags_intro] -other = "We've categorized the glossary terms. Use the filters to browse terms by tag." +other = "हमने शब्दावली के शब्दों को वर्गीकृत किया है। टैग द्वारा शब्दों को ब्राउज़ करने के लिए फ़िल्टर का उपयोग करें।" [ui_or_search_by_tags] -other = "...or browse by tag" +other = "...या टैग द्वारा ब्राउज़ करें" [ui_select_all] -other = "Select All" +other = "सबका चुनाव करें" [ui_deselect_all] -other = "Deselect All" +other = "सारे चुनाव रद्द करें" # Footer text [footer_all_rights_reserved] @@ -45,7 +45,7 @@ other = "गोपनीयता नीति" [footer_hub_button_text] -other = "All CNCF Sites" +other = "सभी CNCF साइटें" # Post (blog, articles etc.) [post_byline_by]