diff --git a/.github/workflows/es-spellcheck.yml b/.github/workflows/es-spellcheck.yml index 2243a24e10..0ecb8ac3bd 100644 --- a/.github/workflows/es-spellcheck.yml +++ b/.github/workflows/es-spellcheck.yml @@ -29,6 +29,6 @@ jobs: set -o errexit diff content/es/.wordlist.txt <(LC_ALL= sort -f content/es/.wordlist.txt) - name: GitHub Spellcheck Action - uses: rojopolis/spellcheck-github-actions@0.42.0 + uses: rojopolis/spellcheck-github-actions@0.45.0 with: config_path: content/es/.spellcheck.yml diff --git a/.github/workflows/spellcheck.yml b/.github/workflows/spellcheck.yml index 3691d61469..a6b318de8d 100644 --- a/.github/workflows/spellcheck.yml +++ b/.github/workflows/spellcheck.yml @@ -25,4 +25,4 @@ jobs: - uses: actions/checkout@v4 - name: GitHub Spellcheck Action - uses: rojopolis/spellcheck-github-actions@0.42.0 + uses: rojopolis/spellcheck-github-actions@0.45.0 diff --git a/content/bn/application-programming-interface.md b/content/bn/application-programming-interface.md index 88b4a0883d..00957ed924 100644 --- a/content/bn/application-programming-interface.md +++ b/content/bn/application-programming-interface.md @@ -5,10 +5,20 @@ category: প্রযুক্তি tags: ["স্থাপত্য", "মৌলিক", ""] --- -একটি API হল কম্পিউটার প্রোগ্রামগুলির একে অপরের সাথে যোগাযোগ করার একটি উপায়। মানুষ যেমন একটি ওয়েব পৃষ্ঠার মাধ্যমে একটি ওয়েবসাইটের সাথে যোগাযোগ করে, তেমনি একটি API কম্পিউটার প্রোগ্রামগুলিকে একে অপরের সাথে যোগাযোগ করতে দেয়। মানুষের মিথস্ক্রিয়া থেকে ভিন্ন, API-গুলির সীমাবদ্ধতা রয়েছে তাদের থেকে কী জিজ্ঞাসা করা যায় এবং কী করা যায় না। ইন্টারঅ্যাকশনের সীমাবদ্ধতা প্রোগ্রামগুলির মধ্যে স্থিতিশীল এবং কার্যকরী যোগাযোগ তৈরি করতে সহায়তা করে। +একটি API হল কম্পিউটার প্রোগ্রামগুলির একে অপরের সাথে যোগাযোগ করার একটি উপায়। +মানুষ যেমন একটি ওয়েব পৃষ্ঠার মাধ্যমে একটি ওয়েবসাইটের সাথে যোগাযোগ করে, তেমনি একটি API কম্পিউটার প্রোগ্রামগুলিকে একে অপরের সাথে যোগাযোগ করতে দেয়। +মানুষের মিথস্ক্রিয়া থেকে ভিন্ন, API-গুলির সীমাবদ্ধতা রয়েছে তাদের থেকে কী জিজ্ঞাসা করা যায় এবং কী করা যায় না। +ইন্টারঅ্যাকশনের সীমাবদ্ধতা প্রোগ্রামগুলির মধ্যে স্থিতিশীল এবং কার্যকরী যোগাযোগ তৈরি করতে সহায়তা করে। ## এটা যেসব সমস্যাতে দৃষ্টিপাত করে -অ্যাপ্লিকেশনগুলি আরও জটিল হয়ে উঠলে, ছোট কোড পরিবর্তনগুলি অন্যান্য কার্যকারিতার উপর কঠোর প্রভাব ফেলতে পারে। অ্যাপ্লিকেশনগুলিকে তাদের কার্যকারিতার জন্য একটি মডুলার পদ্ধতি অবলম্বন করতে হবে যদি তারা একই সাথে বৃদ্ধি এবং স্থিতিশীলতা বজায় রাখতে পারে। API ছাড়া, অ্যাপ্লিকেশনগুলির মধ্যে মিথস্ক্রিয়া করার জন্য একটি কাঠামোর অভাব রয়েছে। একটি শেয়ার্ড ফ্রেমওয়ার্ক ছাড়া, অ্যাপ্লিকেশনগুলির জন্য [স্কেল(scale)](/bn/scalability/) এবং একীভূত করা চ্যালেঞ্জিং। + +অ্যাপ্লিকেশনগুলি আরও জটিল হয়ে উঠলে, ছোট কোড পরিবর্তনগুলি অন্যান্য কার্যকারিতার উপর কঠোর প্রভাব ফেলতে পারে। +অ্যাপ্লিকেশনগুলিকে তাদের কার্যকারিতার জন্য একটি মডুলার পদ্ধতি অবলম্বন করতে হবে যদি তারা একই সাথে বৃদ্ধি এবং স্থিতিশীলতা বজায় রাখতে পারে। +API ছাড়া, অ্যাপ্লিকেশনগুলির মধ্যে মিথস্ক্রিয়া করার জন্য একটি কাঠামোর অভাব রয়েছে। +একটি শেয়ার্ড ফ্রেমওয়ার্ক ছাড়া, অ্যাপ্লিকেশনগুলির জন্য [স্কেল(scale)](/bn/scalability/) এবং একীভূত করা চ্যালেঞ্জিং। ## এটা কিভাবে সাহায্য করে -APIগুলি কম্পিউটার প্রোগ্রাম বা অ্যাপ্লিকেশনগুলিকে একটি সংজ্ঞায়িত এবং বোধগম্য পদ্ধতিতে তথ্য আদান-প্রদান এবং আদান-প্রদান করার অনুমতি দেয়। তারা আধুনিক অ্যাপ্লিকেশনের জন্য বিল্ডিং ব্লক এবং তারা ডেভেলপারদের অ্যাপ্লিকেশন একত্রিত করার একটি উপায় প্রদান করে থাকে। যখনই আপনি [মাইক্রসার্ভিস(microservices)](/bn/microservices/) একসাথে কাজ করার কথা শুনেন, আপনি অনুমান করতে পারেন যে তারা একটি API এর মাধ্যমে ইন্টারঅ্যাক্ট করে। + +APIগুলি কম্পিউটার প্রোগ্রাম বা অ্যাপ্লিকেশনগুলিকে একটি সংজ্ঞায়িত এবং বোধগম্য পদ্ধতিতে তথ্য আদান-প্রদান এবং আদান-প্রদান করার অনুমতি দেয়। +তারা আধুনিক অ্যাপ্লিকেশনের জন্য বিল্ডিং ব্লক এবং তারা ডেভেলপারদের অ্যাপ্লিকেশন একত্রিত করার একটি উপায় প্রদান করে থাকে। +যখনই আপনি [মাইক্রসার্ভিস(microservices)](/bn/microservices-architecture/) একসাথে কাজ করার কথা শুনেন, আপনি অনুমান করতে পারেন যে তারা একটি API এর মাধ্যমে ইন্টারঅ্যাক্ট করে। \ No newline at end of file diff --git a/content/bn/chaos-engineering.md b/content/bn/chaos-engineering.md index b61f15bc51..6c8ccb45f4 100644 --- a/content/bn/chaos-engineering.md +++ b/content/bn/chaos-engineering.md @@ -9,7 +9,7 @@ tags: ["পদ্ধতি", "", ""] ## এটা যেসব সমস্যাতে দৃষ্টিপাত করে -[SRE (Site reliability engineering)](/bn/site-reliability-engineering/) এবং [DevOps](/bn/devops/) অনুশীলনে, প্রোডাক্টের স্থিতিস্থাপকতা (resiliency) এবং [নির্ভরযোগ্যতা (reliability)](/bn/reliability/) বাড়ানোর কৌশলের উপর ফোকাস করে। পর্যাপ্ত পরিষেবার মান নিশ্চিত করার সময়, একটি সিস্টেমের ব্যর্থতা সহ্য করার ক্ষমতা সাধারণত সফ্টওয়্যার ডেভেলপমেন্টে খুব প্রয়োজনীয়। এমন বেশ কয়েকটি দিক জড়িত যা একটি অ্যাপ্লিকেশনের আউটেজের দিকে নিয়ে যেতে পারে, যেমন অবকাঠামো (infrastructure), প্ল্যাটফর্ম (platform), বা ([মাইক্রোসার্ভিস-ভিত্তিক (microservices)](/bn/microservices/)) অ্যাপ্লিকেশনের অন্যান্য চলমান অংশ। প্রোডাকশন পরিবেশে নতুন ফিচারগুলির খুব তাড়াতাড়ি একের পর এক স্থাপনের ফলে ডাউনটাইম (downtime) হওয়ার সম্ভাবনা বেড়ে যায় এবং একটি গুরুতর ঘটনাও ঘটতে পারে — যা ব্যবসার জন্য যথেষ্ট পরিণতিপূর্ণ। +[SRE (Site reliability engineering)](/bn/site-reliability-engineering/) এবং [DevOps](/bn/devops/) অনুশীলনে, প্রোডাক্টের স্থিতিস্থাপকতা (resiliency) এবং [নির্ভরযোগ্যতা (reliability)](/bn/reliability/) বাড়ানোর কৌশলের উপর ফোকাস করে। পর্যাপ্ত পরিষেবার মান নিশ্চিত করার সময়, একটি সিস্টেমের ব্যর্থতা সহ্য করার ক্ষমতা সাধারণত সফ্টওয়্যার ডেভেলপমেন্টে খুব প্রয়োজনীয়। এমন বেশ কয়েকটি দিক জড়িত যা একটি অ্যাপ্লিকেশনের আউটেজের দিকে নিয়ে যেতে পারে, যেমন অবকাঠামো (infrastructure), প্ল্যাটফর্ম (platform), বা ([মাইক্রোসার্ভিস-ভিত্তিক (microservices)](/bn/microservices-architecture/)) অ্যাপ্লিকেশনের অন্যান্য চলমান অংশ। প্রোডাকশন পরিবেশে নতুন ফিচারগুলির খুব তাড়াতাড়ি একের পর এক স্থাপনের ফলে ডাউনটাইম (downtime) হওয়ার সম্ভাবনা বেড়ে যায় এবং একটি গুরুতর ঘটনাও ঘটতে পারে — যা ব্যবসার জন্য যথেষ্ট পরিণতিপূর্ণ। ## এটা কিভাবে সাহায্য করে diff --git a/content/bn/cloud-native-apps.md b/content/bn/cloud-native-apps.md index 24696395bd..3ec46491c8 100644 --- a/content/bn/cloud-native-apps.md +++ b/content/bn/cloud-native-apps.md @@ -13,7 +13,7 @@ tags: ["অ্যাপ্লিকেশন", "মৌলিক", ""] ## এটা যেসব সমস্যাতে দৃষ্টিপাত করে ঐতিহ্যগতভাবে, অন-প্রিমিস পরিবেশগুলি মোটামুটি পছন্দসই উপায়ে গণনা সংস্থান সরবরাহ করে। -প্রতিটি ডেটাসেন্টারের(data-center) পরিষেবা ছিল যা নির্দিষ্ট পরিবেশে অ্যাপ্লিকেশনগুলিকে [শক্তভাবে সংযুক্ত](/bn/tightly-coupled-architectures/) করে, +প্রতিটি ডেটাসেন্টারের(data-center) পরিষেবা ছিল যা নির্দিষ্ট পরিবেশে অ্যাপ্লিকেশনগুলিকে [শক্তভাবে সংযুক্ত](/bn/tightly-coupled-architecture/) করে, প্রায়শই [ভার্চুয়াল মেশিন (Virtual Machine)](/bn/virtual-machine/) এবং পরিষেবার মতো অবকাঠামোর(infrastructure) জন্য ম্যানুয়াল প্রভিশনিংয়ের(manual provisioning) উপর অনেক বেশি নির্ভর করে। যার ফল স্বরূপ, ডেভেলপার এবং তাদের অ্যাপ্লিকেশনগুলিকে সেই নির্দিষ্ট ডেটা সেন্টারে সীমাবদ্ধ করে। ক্লাউডের জন্য ডিজাইন করা হয়নি এমন অ্যাপ্লিকেশনগুলি ক্লাউড পরিবেশের স্থিতিস্থাপকতা এবং স্কেলিং(scaling) ক্ষমতার সুবিধা নিতে পারে না। diff --git a/content/bn/container-orchestration.md b/content/bn/container-orchestration.md index 73ca03c628..3d60166928 100644 --- a/content/bn/container-orchestration.md +++ b/content/bn/container-orchestration.md @@ -4,7 +4,7 @@ status: Completed category: ধারণা --- -[কন্টেইনার](/bn/container/) অর্কেস্ট্রেশন বলতে বোঝায় গতিশীল পরিবেশে কন্টেইনারাইজড অ্যাপ্লিকেশনের জীবনচক্র পরিচালনা এবং স্বয়ংক্রিয়করণ করাকে । +[কন্টেইনার](/bn/container/) অর্কেস্ট্রেশন বলতে বোঝায় গতিশীল পরিবেশে [কন্টেইনারাইজড](/bn/containerization/) অ্যাপ্লিকেশনের জীবনচক্র পরিচালনা এবং স্বয়ংক্রিয়করণ করাকে । এটি একটি কন্টেইনার অর্কেস্ট্রেটরের (বেশিরভাগ ক্ষেত্রে, [কুবারনেটিস](/bn/kubernetes)) মাধ্যমে কার্যকর করা হয় , যা স্থাপনা (deployments), [অটো-স্কেলিং](/bn/auto-scaling/) , অটো-হিলিং এবং পর্যবেক্ষণকে সক্ষম করে। অর্কেস্ট্রেশন একটি রূপক অর্থে : অর্কেস্ট্রেশন টুল একজন মিউজিক পরিচালকের মতো কন্টেইনারগুলোকে পরিচালনা করে, যা নিশ্চিত করে প্রতিটি কন্টেইনারের (বা সঙ্গীতশিল্পীর) যা করা উচিত । diff --git a/content/bn/containerization.md b/content/bn/containerization.md index fc466e6118..797e210a1f 100644 --- a/content/bn/containerization.md +++ b/content/bn/containerization.md @@ -5,11 +5,10 @@ category: প্রযুক্তি tags: ["অ্যাপ্লিকেশন", "", ""] --- -কন্টেইনারাইজেশন হল একটি প্রক্রিয়া যা একটি অ্যাপ্লিকেশন এবং এর সংশ্লিষ্ট জিনিসসমূহকে একটি কন্টেইনার ইমেজ (Container Image) এ বান্ডিল করার প্রক্রিয়া। কন্টেইনার নির্মাণ প্রক্রিয়ার জন্য [ওপেন কন্টেইনার ইনিশিয়েটিভ](https://opencontainers.org) (OCI) মান মেনে চলা প্রয়োজন। যতক্ষণ না একটি কন্টেইনার ইমেজ এই স্ট্যান্ডার্ড মেনে চলে, যে কোন কন্টেইনারাইজেশন টুল ই ব্যবহার করা হয় তা চিন্তার বিষয় নয়। - +কন্টেইনারাইজেশন হলো অ্যাপ্লিকেশন কোডের প্যাকেজিং প্রক্রিয়া যার মধ্যে লাইব্রেরি এবং কোড চালানোর জন্য প্রয়োজনীয় নির্ভরতাগুলোও থাকে একটি একক লাইটওয়েট এক্সিকিউটেবল ফাইলে -যাকে [কন্টেইনার ইমেজ](/bn/container-image/) বলা হয়। ## এটা যেসব সমস্যাতে দৃষ্টিপাত করে -কনটেইনারগুলি প্রচলিত হওয়ার আগে, সংস্থাগুলি যেকোনো [বেয়ার-মেটাল মেশিন (bare-metal machine)](/bn/bare_metal_machine/) এর একাধিক অ্যাপ্লিকেশন তৈরি করার জন্য ভার্চুয়াল মেশিনের (VM) উপর নির্ভর করত। ভিএমগুলি পাত্রের তুলনায় উল্লেখযোগ্যভাবে বড় এবং যার ফলে এটি চালানোর জন্য একটি হাইপারভাইজার প্রয়োজন।যেহেতু এই বৃহৎ ভিএম টেমপ্লেটগুলির স্টোরেজ, ব্যাকআপ এবং স্থানান্তরের কাজ করে, এ কারণে ভিএম টেমপ্লেট তৈরি করাও একটি ধীর প্রক্রিয়া। অতিরিক্তভাবে, ভিএমগুলি যদি [অপরিবর্তনশীলতা (immutability)](/bn/immutable-infrastructure//) নীতি লঙ্ঘন করে, তবে এটি কনফিগারেশন ড্রিফটে ভুগতে পারে। +[কনটেইনারগুলি](/bn/container/) প্রচলিত হওয়ার আগে, সংস্থাগুলি যেকোনো [বেয়ার-মেটাল মেশিন (bare-metal machine)](/bn/bare_metal_machine/) এর একাধিক অ্যাপ্লিকেশন তৈরি করার জন্য [ভার্চুয়াল মেশিনের (VM)](/bn/virtual-machine/) উপর নির্ভর করত। ভিএমগুলি পাত্রের তুলনায় উল্লেখযোগ্যভাবে বড় এবং যার ফলে এটি চালানোর জন্য একটি হাইপারভাইজার প্রয়োজন।যেহেতু এই বৃহৎ ভিএম টেমপ্লেটগুলির স্টোরেজ, ব্যাকআপ এবং স্থানান্তরের কাজ করে, এ কারণে ভিএম টেমপ্লেট তৈরি করাও একটি ধীর প্রক্রিয়া। অতিরিক্তভাবে, ভিএমগুলি যদি [অপরিবর্তনশীলতা (immutability)](/bn/immutable-infrastructure//) নীতি লঙ্ঘন করে, তবে এটি কনফিগারেশন ড্রিফটে ভুগতে পারে। ## এটা কিভাবে সাহায্য করে diff --git a/content/bn/continuous-delivery.md b/content/bn/continuous-delivery.md index 9975604380..3b9897d970 100644 --- a/content/bn/continuous-delivery.md +++ b/content/bn/continuous-delivery.md @@ -7,7 +7,7 @@ tags: ["পদ্ধতি", "অ্যাপ্লিকেশন", ""] ক্রমাগত বিতরণ (continuous delivery), প্রায়ই CD হিসাবে সংক্ষিপ্ত, অনুশীলনের একটি সেট যেখানে কোডের পরিবর্তনগুলি স্বয়ংক্রিয়ভাবে একটি গ্রহণযোগ্য পরিবেশে স্থাপন করা হয় (অথবা, ক্রমাগত স্থাপনার (continuous deployment) ক্ষেত্রে, উৎপাদনে)। স্থাপনার (deployment) আগে সফ্টওয়্যারটি (software) পর্যাপ্তভাবে পরীক্ষা করা হয়েছে তা নিশ্চিত করার জন্য CD অত্যন্ত গুরুত্বপূর্ণভাবে প্রক্রিয়াগুলি অন্তর্ভুক্ত করে এবং প্রয়োজন মনে হলে পরিবর্তনগুলি রোলব্যাক (rollback) করার একটি উপায় প্রদান করে। -ক্রমাগত একীকরণ (continuous integration) (CI) ক্রমাগত বিতরণের (continuous delivery) প্রথম পদক্ষেপ +[ক্রমাগত একীকরণ (continuous integration)](/bn/continuous-integration/) (CI) ক্রমাগত বিতরণের (continuous delivery) প্রথম পদক্ষেপ (অর্থাৎ, পরিবর্তনগুলি পরীক্ষা এবং স্থাপনের আগে পরিষ্কারভাবে একত্রিত করতে হবে)। ## এটা যেসব সমস্যাতে দৃষ্টিপাত করে diff --git a/content/bn/devops.md b/content/bn/devops.md index 15b1fc384b..af1d8748a2 100644 --- a/content/bn/devops.md +++ b/content/bn/devops.md @@ -9,7 +9,7 @@ tags: ["পদ্ধতি", "", ""] ## এটা যেসব সমস্যাতে দৃষ্টিপাত করে -ঐতিহ্যগতভাবে, জটিল সংস্থা [শক্তভাবে মিলিত(Tightly coupled architectures)](/bn/tightly-coupled-architectures/) ও [মনোলিথিক অ্যাপস(Monolithic apps)](/bn/monolithic-apps/) এর কাজ সাধারণত একাধিক দলের মধ্যে খণ্ডিত ছিল । এটি অসংখ্য হ্যান্ডঅফ এবং দীর্ঘ পরবর্তী সময় নেয়। প্রতিবার যখনই একটি উপাদান বা আপডেট প্রস্তুত ছিল, এটি পরবর্তী দলের জন্য একটি সারিতে স্থাপন করা হয়েছিল। যেহেতু ব্যক্তিরা কেবলমাত্র প্রকল্পের একটি ছোট অংশে কাজ করেছিল, এই পদ্ধতির ফলে মালিকানার অভাব দেখা দেয়। তাদের লক্ষ্য ছিল পরবর্তী দলের কাছে কাজটি পৌঁছে দেওয়া, গ্রাহকের কাছে সঠিক কার্যকারিতা সরবরাহ না করা যাকে অগ্রাধিকারগুলির একটি স্পষ্ট বিভ্রান্তি হিসেবে বলা যায়। +ঐতিহ্যগতভাবে, জটিল সংস্থা [শক্তভাবে মিলিত(Tightly coupled architectures)](/bn/tightly-coupled-architecture/) ও [মনোলিথিক অ্যাপস(Monolithic apps)](/bn/monolithic-apps/) এর কাজ সাধারণত একাধিক দলের মধ্যে খণ্ডিত ছিল । এটি অসংখ্য হ্যান্ডঅফ এবং দীর্ঘ পরবর্তী সময় নেয়। প্রতিবার যখনই একটি উপাদান বা আপডেট প্রস্তুত ছিল, এটি পরবর্তী দলের জন্য একটি সারিতে স্থাপন করা হয়েছিল। যেহেতু ব্যক্তিরা কেবলমাত্র প্রকল্পের একটি ছোট অংশে কাজ করেছিল, এই পদ্ধতির ফলে মালিকানার অভাব দেখা দেয়। তাদের লক্ষ্য ছিল পরবর্তী দলের কাছে কাজটি পৌঁছে দেওয়া, গ্রাহকের কাছে সঠিক কার্যকারিতা সরবরাহ না করা যাকে অগ্রাধিকারগুলির একটি স্পষ্ট বিভ্রান্তি হিসেবে বলা যায়। কোডটি শেষ পর্যন্ত আসার সময় পর্যন্ত, এটি এত বেশি ডেভেলপারের মধ্য দিয়ে গিয়েছিল, এত সারিতে অপেক্ষা করেছিল যে কোডটি কাজ না করলে সমস্যার উৎস খুঁজে বের করা কঠিন ছিল। ডেভওপস এই পদ্ধতিকে উল্টো করে দেয়। diff --git a/content/bn/loosely-coupled-architecture.md b/content/bn/loosely-coupled-architecture.md index 2be17a067f..caf910b1e2 100644 --- a/content/bn/loosely-coupled-architecture.md +++ b/content/bn/loosely-coupled-architecture.md @@ -5,7 +5,7 @@ category: বৈশিষ্ট্য tags: ["মৌলিক", "স্থাপত্য", "বৈশিষ্ট্য"] --- -শিথিল সংযোজিত স্থাপত্য হল সেই ধরনের স্থাপত্যশৈলী যেখানে প্রতিটি পৃথক উপাদান স্বাধীনভাবে তৈরি হয় ([ দৃঢ় সংবদ্ধ স্থাপত্য শৈলীর](/bn/tightly-coupled-architectures/) ঠিক বিপরীত )| অনেক সময় এর প্রতিটি উপাদানকে [মাইক্রোসার্ভিসেস আর্কিটেকচার](/bn/microservices-architecture/) হিসেবে চিহ্নিত করা যায় +শিথিল সংযোজিত স্থাপত্য হল সেই ধরনের স্থাপত্যশৈলী যেখানে প্রতিটি পৃথক উপাদান স্বাধীনভাবে তৈরি হয় ([ দৃঢ় সংবদ্ধ স্থাপত্য শৈলীর](/bn/tightly-coupled-architecture/) ঠিক বিপরীত )| অনেক সময় এর প্রতিটি উপাদানকে [মাইক্রোসার্ভিসেস আর্কিটেকচার](/bn/microservices-architecture/) হিসেবে চিহ্নিত করা যায় যেগুলি এমনভাবে তৈরি করা হয় যাতে তা অন্য আরও বিভিন্ন পরিষেবার ব্যবহৃত হতে পারে, এই শৈলীটি সাধারণত দৃঢ় সংবদ্ধ শৈলী তুলনায় অনেক ধীর কিন্তু এর অনেকগুলি সুবিধা আছে বিশেষত অ্যাপ্লিকেশন স্কেল হিসেবে। শিথিল শৈলী দলগুলিকে তাদের বৈশিষ্ট্য উন্নয়নে, স্থাপনে এবং স্বাধীনভাবে স্কেল করার অনুমতি দেয় যার ফলে প্রতিষ্ঠান খুব দ্রুত পৃথক উপাদানের সঙ্গে সংযোগ স্থাপন করতে পারে| Application development অনেক গতিশীল হয় এবং দলগুলি তাদের সামর্থ্য অনুসারে নির্দিষ্ট প্রযুক্তির প্রতি দৃষ্টি নিবদ্ধ রেখে তৈরি হতে পারে। diff --git a/content/bn/microservices-architecture.md b/content/bn/microservices-architecture.md index 3f6a9741f7..7be904240d 100644 --- a/content/bn/microservices-architecture.md +++ b/content/bn/microservices-architecture.md @@ -5,14 +5,14 @@ category: প্রযুক্তি tags: ["স্থাপত্য", "মৌলিক", ""] --- -অ্যাপ্লিকেশন ডেভেলপমেন্টে (Application Development) একটি আধুনিক পন্থা হলো মাইক্রোসার্ভিস (Microservice), যা ক্লাউড নেটিভ (Cloud Native) প্রযুক্তির সুবিধা নেয়। যেখানে আধুনিক অ্যাপ্লিকেশনগুলি, যেমন নেটফ্লিক্স(netflix) একটি একক অ্যাপ এর মত দেখায় কিন্তু এটি আসলে অনেকগুলি ছোট ছোট সার্ভিসের একত্রিত রূপ, সবগুলি একে অপরের সাথে আবদ্ধ ভাবে কাজ করে চলেছে। এই ক্ষেত্রে, কোনো অ্যাপ এর একটি একক পেজ যা আমাদের search, authenticate এবং ভিডিও দেখতে অনুমতি দেয় তা আসলে অনেকগুলি ছোট ছোট সার্ভিস দ্বারা চালিত হয়, যেখানে এক একটি সার্ভিস এক একটি বৈশিষ্ট্য সামলায়। সংক্ষেপে, মাইক্রোসার্ভিস বলতে একটি এপ্লিকেশন আর্কিটেকচার প্যাটার্ন (Application Architecture Pattern) কে বোঝানো হয় যা [মনোলিথিক এপ্লিকেশন (Monolithic Application)](/bn/monolithic_apps/) এর থেকে স্বাভাবিকত বিপরীত। +অ্যাপ্লিকেশন ডেভেলপমেন্টে (Application Development) একটি আধুনিক পন্থা হলো মাইক্রোসার্ভিস (Microservice), যা ক্লাউড নেটিভ (Cloud Native) প্রযুক্তির সুবিধা নেয়। যেখানে আধুনিক অ্যাপ্লিকেশনগুলি, যেমন নেটফ্লিক্স(netflix) একটি একক অ্যাপ এর মত দেখায় কিন্তু এটি আসলে অনেকগুলি ছোট ছোট সার্ভিসের একত্রিত রূপ, সবগুলি একে অপরের সাথে আবদ্ধ ভাবে কাজ করে চলেছে। এই ক্ষেত্রে, কোনো অ্যাপ এর একটি একক পেজ যা আমাদের search, authenticate এবং ভিডিও দেখতে অনুমতি দেয় তা আসলে অনেকগুলি ছোট ছোট সার্ভিস দ্বারা চালিত হয়, যেখানে এক একটি সার্ভিস এক একটি বৈশিষ্ট্য সামলায়। সংক্ষেপে, মাইক্রোসার্ভিস বলতে একটি এপ্লিকেশন আর্কিটেকচার প্যাটার্ন (Application Architecture Pattern) কে বোঝানো হয় যা [মনোলিথিক এপ্লিকেশন (Monolithic Application)](/bn/monolithic-apps/) এর থেকে স্বাভাবিকত বিপরীত। ## এটা যেসব সমস্যাতে দৃষ্টিপাত করে -মাইক্রোসার্ভিসেস হল মনোলিথিক এপ্লিকেশনের দ্বারা জাহির করা চ্যালেঞ্জগুলির প্রতি একটি উত্তর। স্বাভাবিকভাবে, একটি অ্যাপ্লিকেশনের বিভিন্ন অংশকে আলাদা আলাদা ভাবে বড় ([scaled](/bn/scalability/)) করতে হবে। উদাহরণস্বরূপ, একটি অনলাইন দোকানের বিক্রি থেকে প্রোডাক্ট ভিউস বেশি হয়, যার মানে বিক্রির থেকে আমাদের প্রোডাক্ট ভিউস ফাংশনালিটির অনেকগুলি চলমান দৃষ্টান্ত (running instance) প্রয়োজন হয়। একটি মনোলিথিক অ্যাপ্লিকেশনে, আলাদা আলাদাভাবে এই ছোট ছোট যুক্তি বা কোড গুলির সঞ্চার করা সম্ভব নয়। যদি প্রোডাক্ট ভিউস ফাংশনকে আলাদা ভাবে বড়ো করে তোলা না যায় তাহলে আমাদের পুরো সফটওয়্যারটিকে ডুপ্লিকেট করে তার আরো চলমান দৃষ্টান্ত তৈরি করতে হবে, প্রত্যেকটি কম্পনেন্ট সহকারে যা সম্পদের একটি অদক্ষ ব্যবহার। মনোলিথিক অ্যাপ্লিকেশনগুলি ডেভেলোপারদের ডিজাইন পিটফলে (design pitfall) পড়া সহজ করে তোলে। যেহেতু সমস্ত কোড এক জায়গায় রয়েছে, সেই কোডটিকে শক্তভাবে জোড়া দেওয়া [(tightly coupled)](/bn/tightly_coupled_architectures/) সহজ এবং উদ্বেগের বিচ্ছেদের নীতি প্রয়োগ করা আরও কঠিন। মনোলিথিকের জন্য প্রায়ই ডেভেলপারদের উৎপাদনশীল (productive) হওয়ার আগে পুরো কোডবেস বোঝার প্রয়োজন হয়। +মাইক্রোসার্ভিসেস হল মনোলিথিক এপ্লিকেশনের দ্বারা জাহির করা চ্যালেঞ্জগুলির প্রতি একটি উত্তর। স্বাভাবিকভাবে, একটি অ্যাপ্লিকেশনের বিভিন্ন অংশকে আলাদা আলাদা ভাবে বড় ([scaled](/bn/scalability/)) করতে হবে। উদাহরণস্বরূপ, একটি অনলাইন দোকানের বিক্রি থেকে প্রোডাক্ট ভিউস বেশি হয়, যার মানে বিক্রির থেকে আমাদের প্রোডাক্ট ভিউস ফাংশনালিটির অনেকগুলি চলমান দৃষ্টান্ত (running instance) প্রয়োজন হয়। একটি মনোলিথিক অ্যাপ্লিকেশনে, আলাদা আলাদাভাবে এই ছোট ছোট যুক্তি বা কোড গুলির সঞ্চার করা সম্ভব নয়। যদি প্রোডাক্ট ভিউস ফাংশনকে আলাদা ভাবে বড়ো করে তোলা না যায় তাহলে আমাদের পুরো সফটওয়্যারটিকে ডুপ্লিকেট করে তার আরো চলমান দৃষ্টান্ত তৈরি করতে হবে, প্রত্যেকটি কম্পনেন্ট সহকারে যা সম্পদের একটি অদক্ষ ব্যবহার। মনোলিথিক অ্যাপ্লিকেশনগুলি ডেভেলোপারদের ডিজাইন পিটফলে (design pitfall) পড়া সহজ করে তোলে। যেহেতু সমস্ত কোড এক জায়গায় রয়েছে, সেই কোডটিকে শক্তভাবে জোড়া দেওয়া [(tightly coupled)](/bn/tightly-coupled-architecture/) সহজ এবং উদ্বেগের বিচ্ছেদের নীতি প্রয়োগ করা আরও কঠিন। মনোলিথিকের জন্য প্রায়ই ডেভেলপারদের উৎপাদনশীল (productive) হওয়ার আগে পুরো কোডবেস বোঝার প্রয়োজন হয়। ## এটা কিভাবে সাহায্য করে -কার্যকারিতা(functionality) কে বিভিন্ন মাইক্রোসার্ভিসে আলাদা করে স্বাধীনভাবে স্থাপন, আপডেট এবং দক্ষতা মিশ্রিত করা সহজ। বিভিন্ন দলকে একটি বৃহত্তর অ্যাপ্লিকেশনের ছোট অংশে ফোকাস করার অনুমতি দিয়ে সংস্থার বাকি অংশকে নেতিবাচকভাবে প্রভাবিত না করে তাদের অ্যাপে কাজ করা সহজ হয়। যেখানে মাইক্রোসার্ভিস বহু সমস্যা সমাধান করে, এটি আবার অপারেশনাল ওভারহেডও (operational overhead) তৈরি করে - যে জিনিসগুলি আপনাকে স্থাপন করতে হবে এবং মাত্রার ক্রম অনুসারে বৃদ্ধিতে নজর রাখতে হবে এবং আরও অনেক কিছু। অনেক [ক্লাউড নেগেটিভ প্রযুক্তির](/bn/cloud_native_tech/) উদ্দেশ্যই হলো মাইক্রোসার্ভিস স্থাপন এবং পরিচালনা সহজ করা। +কার্যকারিতা(functionality) কে বিভিন্ন মাইক্রোসার্ভিসে আলাদা করে স্বাধীনভাবে স্থাপন, আপডেট এবং দক্ষতা মিশ্রিত করা সহজ। বিভিন্ন দলকে একটি বৃহত্তর অ্যাপ্লিকেশনের ছোট অংশে ফোকাস করার অনুমতি দিয়ে সংস্থার বাকি অংশকে নেতিবাচকভাবে প্রভাবিত না করে তাদের অ্যাপে কাজ করা সহজ হয়। যেখানে মাইক্রোসার্ভিস বহু সমস্যা সমাধান করে, এটি আবার অপারেশনাল ওভারহেডও (operational overhead) তৈরি করে - যে জিনিসগুলি আপনাকে স্থাপন করতে হবে এবং মাত্রার ক্রম অনুসারে বৃদ্ধিতে নজর রাখতে হবে এবং আরও অনেক কিছু। অনেক [ক্লাউড নেগেটিভ প্রযুক্তির](/bn/cloud-native-tech/) উদ্দেশ্যই হলো মাইক্রোসার্ভিস স্থাপন এবং পরিচালনা সহজ করা। + ---- diff --git a/content/bn/observability.md b/content/bn/observability.md index d9e8b2341d..7f9b74542d 100644 --- a/content/bn/observability.md +++ b/content/bn/observability.md @@ -9,7 +9,7 @@ tags: ["বৈশিষ্ট্য", "", ""] এটি ব্যবহারকারীদের এই বাহ্যিক আউটপুটগুলি থেকে একটি সিস্টেমের অবস্থা বুঝতে এবং (সংশোধনমূলক) পদক্ষেপ নিতে দেয়। কম্পিউটার সিস্টেমগুলো পরিমাপ করা হয় নিম্ন-স্তরের সংকেত যেমন সিপিইউ সময়, মেমরি, ডিস্ক স্পেস এবং উচ্চ-স্তরের এবং ব্যবসায়িক সংকেতগুলো পর্যবেক্ষণ করে যার মধ্যে রয়েছে এপিআই প্রতিক্রিয়া সময়, ত্রুটি, প্রতি সেকেন্ডে লেনদেন ইত্যাদি । -এই পর্যবেক্ষণযোগ্য সিস্টেমগুলো **পর্যবেক্ষণ** করা হয় (বা মনিটর করা হয়) বিশেষ টুলসের মাধ্যমে, তথাকথিত পর্যবেক্ষণের টুল। এই টুলগুলির একটি তালিকা [ক্লাউড নেটিভ ল্যান্ডস্কেপের পর্যবেক্ষণ বিভাগে](https://landscape.cncf.io/card-mode?category=observability-and-analysis&grouping=category) দেখা যেতে পারে। +এই পর্যবেক্ষণযোগ্য সিস্টেমগুলো **পর্যবেক্ষণ** করা হয় (বা মনিটর করা হয়) বিশেষ টুলসের মাধ্যমে, তথাকথিত পর্যবেক্ষণের টুল। এই টুলগুলির একটি তালিকা [ক্লাউড নেটিভ ল্যান্ডস্কেপের পর্যবেক্ষণ বিভাগে](https://landscape.cncf.io/?group=projects-and-products&view-mode=card#observability-and-analysis--observability) দেখা যেতে পারে। পর্যবেক্ষণযোগ্য সিস্টেমগুলো তাদের অপারেটরদের কাছে অর্থপূর্ণ, কার্যকরী ডেটা প্রদান করে, তাদের অনুকূল ফলাফল (দ্রুত ঘটনার প্রতিক্রিয়া, বিকাশকারীর উৎপাদনশীলতা (developer productivity) বৃদ্ধি) এবং কম পরিশ্রম এবং ডাউনটাইম অর্জন করতে দেয়। diff --git a/content/bn/search.md b/content/bn/search.md index cb936b816f..6ce97e476d 100644 --- a/content/bn/search.md +++ b/content/bn/search.md @@ -1,4 +1,4 @@ --- title: অনুসন্ধান ফলাফল -layout: অনুসন্ধান +layout: search --- diff --git a/content/bn/security-chaos-engineering.md b/content/bn/security-chaos-engineering.md index 40f3769bf2..b77cb02154 100644 --- a/content/bn/security-chaos-engineering.md +++ b/content/bn/security-chaos-engineering.md @@ -17,4 +17,4 @@ tags: ["নিরাপত্তা", "পদ্ধতি", ""] এর লক্ষ্য "অজানার অজানা" উন্মোচন করা এবং সিস্টেমে আস্থা তৈরি করা, সাইবার স্থিতিস্থাপকতা বৃদ্ধি এবং পর্যবেক্ষণযোগ্যতা উন্নত করা। ইঞ্জিনিয়ারিং দলগুলি ধীরে ধীরে জটিল অবকাঠামো, প্ল্যাটফর্ম এবং ডিসট্রিবিউটেড সিস্টেমের মধ্যে নিরাপত্তা উদ্বেগের (security concerns) জন্য বোঝাপড়ার উন্নতি ঘটাবে। SCE সমগ্র পণ্যের সাইবার স্থিতিস্থাপকতা উন্নত করে, লুকানো নিরাপত্তা সমস্যাগুলি উন্মোচন করে, ক্লাসিক্যাল ব্লাইন্ড স্পটগুলিকে উন্মোচন করে, এবং গুরুত্বপূর্ণ প্রান্তের ক্ষেত্রে (critical edge cases) দলগুলিকে প্রস্তুত করে৷ -এই পদ্ধতি SREs, [DevOps](/bn/devops/) এবং [DevSecOps](/bn/devsecops/) ইঞ্জিনিয়ারদের সিস্টেমে আস্থা তৈরি করতে, সাইবার স্থিতিস্থাপকতা বাড়াতে এবং পর্যবেক্ষণযোগ্যতা উন্নত করতে সাহায্য করে। +এই পদ্ধতি [SREs](/site-reliability-engineering/), [DevOps](/bn/devops/) এবং [DevSecOps](/bn/devsecops/) ইঞ্জিনিয়ারদের সিস্টেমে আস্থা তৈরি করতে, সাইবার স্থিতিস্থাপকতা বাড়াতে এবং পর্যবেক্ষণযোগ্যতা উন্নত করতে সাহায্য করে। diff --git a/content/bn/zero-trust-architecture.md b/content/bn/zero-trust-architecture.md index 764c0708ca..6559bce461 100644 --- a/content/bn/zero-trust-architecture.md +++ b/content/bn/zero-trust-architecture.md @@ -5,12 +5,12 @@ category: ধারণা tags: ["নিরাপত্তা", "", ""] --- -জিরো ট্রাস্ট আর্কিটেকচার আইটি সিস্টেমের ডিজাইন এবং বাস্তবায়নের জন্য একটি নির্ধারিত পন্থা যেখানে 'ট্রাস্ট'(বিশ্বাস) সম্পূর্ণরূপে উপেক্ষা করা হয়। এই পন্থার মূল নীতি হল "বিশ্বাস নয়,সর্বদা যাচাই করা",ডিভাইস বা সিস্টেম,সিস্টেমের অন্যান্য অংশের সাথে যোগাযোগ করার সময় সর্বদা নিজেকে প্রথমে যাচাই করে। বর্তমানে অনেক নেটওয়ার্কে,কর্পোরেট নেটওয়ার্কের মধ্যে থাকা সিস্টেম এবং ডিভাইসগুলি অবাধে একটি অন্যটির সাথে যোগাযোগ করতে পারে কারণ সিস্টেম এবং ডিভাইসগুলি কর্পোরেট নেটওয়ার্ক পরিধির বিশ্বস্ত সীমার মধ্যে আবদ্ধ থাকে। অন্যদিকে জিরো ট্রাস্ট আর্কিটেকচার বিপরীত পদ্ধতি অবলম্বন করে যেখানে নেটওয়ার্ক পরিধির মধ্যেই সিস্টেমের অংশগুলি কোন যোগাযোগ স্থাপনের জন্য প্রথমে যাচাইকরণ পর্যায় অতিক্রম করে। +জিরো ট্রাস্ট আর্কিটেকচার আইটি সিস্টেমের ডিজাইন এবং বাস্তবায়নের জন্য একটি নির্ধারিত পন্থা যেখানে 'ট্রাস্ট'(বিশ্বাস) সম্পূর্ণরূপে উপেক্ষা করা হয়। এই পন্থার মূল নীতি হল "বিশ্বাস নয়, সর্বদা যাচাই করা", ডিভাইস বা সিস্টেম, সিস্টেমের অন্যান্য অংশের সাথে যোগাযোগ করার সময় সর্বদা নিজেকে প্রথমে যাচাই করে। বর্তমানে অনেক নেটওয়ার্কে, কর্পোরেট নেটওয়ার্কের মধ্যে থাকা সিস্টেম এবং ডিভাইসগুলি অবাধে একটি অন্যটির সাথে যোগাযোগ করতে পারে কারণ সিস্টেম এবং ডিভাইসগুলি কর্পোরেট নেটওয়ার্ক পরিধির বিশ্বস্ত সীমার মধ্যে আবদ্ধ থাকে। অন্যদিকে জিরো ট্রাস্ট আর্কিটেকচার বিপরীত পদ্ধতি অবলম্বন করে যেখানে নেটওয়ার্ক পরিধির মধ্যেই সিস্টেমের অংশগুলি কোন যোগাযোগ স্থাপনের জন্য প্রথমে যাচাইকরণ পর্যায় অতিক্রম করে। ## এটা যেসব সমস্যাতে দৃষ্টিপাত করে -চিরাচরিত বিশ্বাস ভিত্তিক পদ্ধতি অনুসারে যেখানে সিস্টেম এবং ডিভাইসগুলি কর্পোরেট নেটওয়ার্কের পরিধির মধ্যে থাকে,অনুমান করা হয় যে,যেহেতু বিশ্বাস আছে,সেহেতু কোন সমস্যা নেই। অবশ্য,জিরো ট্রাস্ট আর্কিটেকচার স্বীকার করে যে বিশ্বাস(ট্রাস্ট) একটি দুর্বলতা। এখন ঘটনাচক্রে,এক আক্রমণকারী যদি একটি বিশ্বস্ত ডিভাইসের অ্যাক্সেস পায় তাহলে আক্রমণকারী "বিশ্বস্ত" নেটওয়ার্ক পরিধির মধ্যে থাকায় সিস্টেমটি আক্রমণের জন্য ঝুঁকিপূর্ণ হয়ে পড়ে এবং আক্রমণকারী সমগ্র সিস্টেম জুড়ে পার্শ্বীয়ভাবে স্থান পরিবর্তনে (move laterally) সক্ষম হয়,এইসব নির্ভর করে ডিভাইসে থাকা বিশ্বাস-মাত্রা এবং ডিভাইসে দেওয়া অ্যাক্সেসের ওপর। একটি জিরো ট্রাস্ট আর্কিটেকচারে,বিশ্বাসকে উপেক্ষা করা হয়,তাই আক্রমণের পৃষ্ঠ হ্রাস পায় ফলে,একজন আক্রমণকারীকে সিস্টেমের আরো অভ্যন্তরে যাওয়ার আগে যাচাইকরণ করাতে বাধ্য করা হয়। +চিরাচরিত বিশ্বাস ভিত্তিক পদ্ধতি অনুসারে যেখানে সিস্টেম এবং ডিভাইসগুলি কর্পোরেট নেটওয়ার্কের পরিধির মধ্যে থাকে, অনুমান করা হয় যে, যেহেতু বিশ্বাস আছে, সেহেতু কোন সমস্যা নেই। অবশ্য, জিরো ট্রাস্ট আর্কিটেকচার স্বীকার করে যে বিশ্বাস(ট্রাস্ট) একটি দুর্বলতা। এখন ঘটনাচক্রে, এক আক্রমণকারী যদি একটি বিশ্বস্ত ডিভাইসের অ্যাক্সেস পায় তাহলে আক্রমণকারী "বিশ্বস্ত" নেটওয়ার্ক পরিধির মধ্যে থাকায় সিস্টেমটি আক্রমণের জন্য ঝুঁকিপূর্ণ হয়ে পড়ে এবং আক্রমণকারী সমগ্র সিস্টেম জুড়ে পার্শ্বীয়ভাবে স্থান পরিবর্তনে (move laterally) সক্ষম হয়, এইসব নির্ভর করে ডিভাইসে থাকা বিশ্বাস-মাত্রা এবং ডিভাইসে দেওয়া অ্যাক্সেসের ওপর। একটি জিরো ট্রাস্ট আর্কিটেকচারে, বিশ্বাসকে উপেক্ষা করা হয়, তাই আক্রমণের পৃষ্ঠ হ্রাস পায় ফলে, একজন আক্রমণকারীকে সিস্টেমের আরো অভ্যন্তরে যাওয়ার আগে যাচাইকরণ করাতে বাধ্য করা হয়। ## এটি কিভাবে সাহায্য করে -জিরো ট্রাস্ট আর্কিটেকচার পন্থার প্রধান সুবিধা হল এটি আক্রমণ পৃষ্ঠকে হ্রাস করে,নিরাপত্তা বৃদ্ধি করে। কর্পোরেট সিস্টেম থেকে বিশ্বাস অপসারণ করার ফলে নিরাপত্তা গেটের সংখ্যা এবং শক্তি বৃদ্ধি পায় যা একজন আক্রমণকারীকে অতিক্রম করতে হয় সিস্টেমের অন্যান্য অংশগুলিতে অ্যাক্সেস পাওয়ার জন্য। +জিরো ট্রাস্ট আর্কিটেকচার পন্থার প্রধান সুবিধা হল এটি আক্রমণ পৃষ্ঠকে হ্রাস করে, নিরাপত্তা বৃদ্ধি করে। কর্পোরেট সিস্টেম থেকে বিশ্বাস অপসারণ করার ফলে নিরাপত্তা গেটের সংখ্যা এবং শক্তি বৃদ্ধি পায় যা একজন আক্রমণকারীকে অতিক্রম করতে হয় সিস্টেমের অন্যান্য অংশগুলিতে অ্যাক্সেস পাওয়ার জন্য। diff --git a/content/en/style-guide/_index.md b/content/en/style-guide/_index.md index bab8303e7b..239ec4a183 100644 --- a/content/en/style-guide/_index.md +++ b/content/en/style-guide/_index.md @@ -26,7 +26,7 @@ Additionally, it follows the following rules: ## Audience The Glossary is written for technical *and* non-technical audiences. -Please explain definitions in simple terms, and don’t assume technical knowledge. More about this is below in [Definition](#definition). +Please explain definitions in simple terms, and don’t assume technical knowledge. More about this is below in [Definition](#definition) and the [Sign Language Style Guide](#sign-language-style-guide). ## Minimum viable definition @@ -164,6 +164,8 @@ Additionally, it uses a real-world example comparing network challenges in a mic to wifi problems (something anyone using a laptop can understand). Where possible, try to make that connection. + + #### Start with a Google or Word doc We recommend starting with a Google or Word doc, letting it sit for a few days, and revisiting it. @@ -176,6 +178,90 @@ More about that in the [How To Contribute](/contribute/) doc. Before getting started, please read some published Glossary terms to get a feeling for the level of detail and difficulty and when examples are appropriate. + + +## Sign Language Video Style Guide {#sign-language-style-guide} + +If you are contributing a sign language video, please follow these guidelines to ensure our videos are clear, informative, and accessible to a wide audience (Including hearing community members). + + +### Technical equipment + +All you need is a high-resolution camera and a stand. A modern smartphone should be enough. + + +### Recording Setup + + + +* **Lighting:** Use frontal lighting to ensure your face and hands are well-lit. + + +* **Background:** Record in front of a flat, solid background to avoid distractions from the signing. Ensure no distracting decorations are included. + + +* **Dress Code:** Wear a solid, single-color top (no prints) that contrasts with your skin tone. + + +* **Camera Position:** Ensure that your head to your elbows are visible on the screen, and position the camera at eye level. The camera should be perpendicular to the background so that it appears straight, not slanted. + + +* **Signing Space:** Use as much space as possible to ensure you have full signing space while sitting or standing. + + +* **Sound:** Mute the microphone (input audio) when possible to avoid involuntary background noise. + +### Signing + + + +* **Clarity and Accuracy:** Record the sign twice from a frontal orientation, signing slowly enough for non-signers to see and mimic it. Demonstrating signs from the side is unnecessary unless it adds clarity. + + +* **Facial Expression:** Use relaxed or neutral facial expressions. Mouthing or making grimaces is strongly discouraged. Maintain eye contact with the camera if possible. + + +* **Frequency:** Only one sign is needed for each video, as playback can be looped. Repeating the sign in a video is unnecessary. + + +* **Duration:** The total length of the video should not exceed 7 seconds. + + +* **Fingerspelling:** Use sign language for the word as much as possible. Fingerspelling is the last resort, commonly reserved for abbreviated or short words. + + +* **Posture:** Maintain a frontal orientation with eyes facing the camera while signing. Demonstrating signs using side orientation is unnecessary. When at rest, arms should be down with hands relaxed. + +### Tips + + + +* **Save storage space:** Please remember the shorter the video, the smaller the file would be. The faster it will upload. + + +* **Mistakes are good:** Keep the recording running while making several attempts. It is more likely you will find a good clip in between tries, and you can trim the unwanted parts. This is more efficient than making multiple recordings with one sign attempt in each. + + +* **Videos Examples:** Please refer to the [CNCF Glossary: Cloud Native Signs](https://www.youtube.com/playlist?list=PLj6h78yzYM2PDlYnmfpRfKgcgBMb34kb5) playlist for examples. + +### Post-Production + + + +* **Editing:** If necessary, trim the beginning and the end of the video. + + +* **Label:** At a minimum, the filename of the video should contain the glossary term of the sign before uploading. For example, kubernetes.mp4. + + +* **Audio:** Remove the audio track entirely, if possible. + + +* **Upload:** Share the video on the #glossary-sign-language Slack channel and ask for feedback. If approved, the Sign Language Glossary leads will help you upload the video to the CNCF Playlist. Please do not upload the videos to your personal YouTube as YouTube could potentially remove duplicate videos from all accounts using the same videos (to prevent monetizing abuse) as CNCF uses YouTube to upload final videos. + + +* **Video upload on CNCF playlist:** Share the video on the #glossary-sign-language Slack channel and ask for feedback. If approved, the Sign Language Glossary leads will help you upload the video to the CNCF Playlist. + ## The review process: What to expect Please note that we are currently only three maintainers doing this in their spare time. 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/content/ru/self-healing.md b/content/ru/self-healing.md new file mode 100644 index 0000000000..e19a126ffc --- /dev/null +++ b/content/ru/self-healing.md @@ -0,0 +1,11 @@ +--- +title: Самовосстанавливающаяся система +status: Completed +category: property +tags: ["infrastructure", "property"] +--- +Самовосстанавливающаяся система способна восстанавливаться после определённых типов сбоев без участия человека. +В ней есть цикл «сближения» или «контроля», который проактивно следит за состоянием системы и +сравнивает его с состоянием, которое изначально хотели получить операторы. +Если состояния отличаются (например, запущено меньше инстансов приложения, чем хотелось бы), +цикл внесёт коррективы (например, запустит новые инстансы). diff --git a/i18n/bn.toml b/i18n/bn.toml index 49e637d803..b6a8ee6f7d 100644 --- a/i18n/bn.toml +++ b/i18n/bn.toml @@ -28,7 +28,7 @@ other = "ট্যাগ" [ui_search_by_tags] other = "ট্যাগ দ্বারা ব্রাউজ করুন" [ui_tags_intro] -other = "আমরা শব্দকোষ পদগুলোকে শ্রেণীবদ্ধ করেছি । ট্যাগ দ্বারা পদগুলো ব্রাউজ করতে ফিল্টার ব্যবহার করুন ।" +other = "আমরা শব্দকোষ পদগুলোকে শ্রেণীবদ্ধ করেছি। ট্যাগ দ্বারা পদগুলো ব্রাউজ করতে ফিল্টার ব্যবহার করুন।" [ui_or_search_by_tags] other = "...অথবা ট্যাগ দ্বারা ব্রাউজ করুন" [ui_select_all] 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]