diff --git a/.github/ISSUE_TEMPLATE/new-term.yml b/.github/ISSUE_TEMPLATE/new-term.yml index 309ddcdccd..cfa1ff353a 100644 --- a/.github/ISSUE_TEMPLATE/new-term.yml +++ b/.github/ISSUE_TEMPLATE/new-term.yml @@ -34,7 +34,7 @@ body: required: true - label: The term has not already been declined in the past. [(shift+click to check)](https://github.com/cncf/glossary/issues?q=is%3Aissue+is%3Aclosed+label%3A%22triage%2Fnot+accepted%22) required: false - - label: The term does not already exist in the [glossary](https://glossary.cncf.io). + - label: The term does not already exist in the [glossary](https://glossary.cncf.io) as a completed term, nor does it exist in [this directory](https://github.com/cncf/glossary/tree/main/content/en) as an incomplete term. (If the status of the term is `Feedback Appreciated`, consider updating the term.) required: true - label: I understand that maintainers will assess if the term should be part of the Glossary. (Please be patient) required: true diff --git a/.github/settings.yml b/.github/settings.yml index 8fe8d27afa..8b03379c72 100644 --- a/.github/settings.yml +++ b/.github/settings.yml @@ -168,9 +168,6 @@ collaborators: - username: huats permission: push - - username: fydrah - permission: push - - username: Krast76 permission: push @@ -180,6 +177,9 @@ collaborators: - username: guillaumebernard84 permission: push + - username: seb-835 + permission: push + # l10n ur approvers - username: Saim-Safdar permission: push @@ -210,6 +210,9 @@ collaborators: - username: naonishijima permission: push + - username: Okabe-Junya + permission: push + - username: yuichi-nakamura permission: push @@ -217,7 +220,7 @@ collaborators: - username: aliok permission: push - - username: halil-bugol + - username: symys permission: push - username: rwxdash @@ -445,10 +448,10 @@ branches: # fr approvers users: - huats - - fydrah - Krast76 - sestegra - guillaumebernard84 + - seb-835 teams: [] enforce_admins: null required_linear_history: null @@ -503,6 +506,7 @@ branches: - inductor - kaitoii11 - naonishijima + - Okabe-Junya - yuichi-nakamura teams: [] enforce_admins: null @@ -520,7 +524,7 @@ branches: # tr approvers users: - aliok - - halil-bugol + - symys - rwxdash - eminalemdar teams: [] diff --git a/.github/workflows/check-links.yml b/.github/workflows/check-links.yml new file mode 100644 index 0000000000..4a116080d1 --- /dev/null +++ b/.github/workflows/check-links.yml @@ -0,0 +1,18 @@ +name: Links + +on: + pull_request: + +jobs: + build-and-check-links: + name: CHECK LINKS + runs-on: ubuntu-latest + steps: + - uses: actions/checkout@v4 + - uses: actions/setup-node@v4 + with: + node-version-file: .nvmrc + cache: npm + cache-dependency-path: package.json + - run: npm install --omit=optional + - run: npm run check:links diff --git a/.github/workflows/es-spellcheck.yml b/.github/workflows/es-spellcheck.yml index f066a1a8b3..0012a44df8 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.35.0 + uses: rojopolis/spellcheck-github-actions@0.38.0 with: config_path: content/es/.spellcheck.yml diff --git a/.github/workflows/post-outdated-content-report.yaml b/.github/workflows/post-outdated-content-report.yaml index 34ede7f1af..c45ece5079 100644 --- a/.github/workflows/post-outdated-content-report.yaml +++ b/.github/workflows/post-outdated-content-report.yaml @@ -50,7 +50,7 @@ jobs: # - name: Download output # uses: actions/download-artifact@v3 - name: Download output - uses: dawidd6/action-download-artifact@v3 + uses: dawidd6/action-download-artifact@v6 with: github_token: ${{secrets.GITHUB_TOKEN}} workflow: check-outdated-content.yaml @@ -144,7 +144,7 @@ jobs: echo "The end of report" >> report.md - name: Create an issue from the report - uses: peter-evans/create-issue-from-file@v4 + uses: peter-evans/create-issue-from-file@v5 with: title: "[${{ env.L10N_CODE }}] A report to track and reflect updates of English content" content-filepath: report.md diff --git a/.github/workflows/spellcheck.yml b/.github/workflows/spellcheck.yml index 7ff4752ef5..6c6751a2ce 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.35.0 + uses: rojopolis/spellcheck-github-actions@0.38.0 diff --git a/.gitignore b/.gitignore index 410a3b8e40..665996ea17 100644 --- a/.gitignore +++ b/.gitignore @@ -1,9 +1,12 @@ -public/ -resources/ -node_modules/ -.hugo_build.lock .DS_Store +.hugo_build.lock +/public +/resources +node_modules/ +package-lock.json +pagefind +tmp/ # Local Netlify folder .netlify diff --git a/.htmltest.yml b/.htmltest.yml new file mode 100644 index 0000000000..e9ba71ab06 --- /dev/null +++ b/.htmltest.yml @@ -0,0 +1,8 @@ +# cSpell:ignore pagefind regexs +DirectoryPath: public +# IgnoreDirectoryMissingTrailingSlash: true # FIXME +IgnoreInternalEmptyHash: true # FIXME +IgnoreDirs: + - ^(bn|de|es|hi|it|ko|pt.*?|ru|tr|ur|zh.*?)/ +IgnoreURLs: # list of regexs of paths or URLs to be ignored + - ^/pagefind diff --git a/.nvmrc b/.nvmrc new file mode 100644 index 0000000000..b009dfb9d9 --- /dev/null +++ b/.nvmrc @@ -0,0 +1 @@ +lts/* diff --git a/CODEOWNERS b/CODEOWNERS index f801193341..43c8de63eb 100644 --- a/CODEOWNERS +++ b/CODEOWNERS @@ -35,8 +35,8 @@ /i18n/es.toml @raelga @ramrodo @electrocucaracha @krol3 @92nqb # Approvers for French contents -/content/fr/ @huats @fydrah @Krast76 @sestegra @guillaumebernard84 -/i18n/fr.toml @huats @fydrah @Krast76 @sestegra @guillaumebernard84 +/content/fr/ @huats @Krast76 @sestegra @guillaumebernard84 @seb-835 +/i18n/fr.toml @huats @Krast76 @sestegra @guillaumebernard84 @seb-835 # Approvers for Hindi contents /content/hi/ @Garima-Negi @jayesh-srivastava @abhay-raj19 @aj11anuj @kumarankit999 @bishal7679 @@ -47,8 +47,8 @@ /i18n/it.toml @fsbaraglia @ugho16 @annalisag-spark @sistella # Approvers for Japanese contents -/content/ja/ @inductor @naonishijima @kaitoii11 @yuichi-nakamura -/i18n/ja.toml @inductor @naonishijima @kaitoii11 @yuichi-nakamura +/content/ja/ @inductor @naonishijima @kaitoii11 @yuichi-nakamura @Okabe-Junya +/i18n/ja.toml @inductor @naonishijima @kaitoii11 @yuichi-nakamura @Okabe-Junya # Approvers for Korean contents /content/ko/ @seokho-son @jihoon-seo @yunkon-kim @@ -63,8 +63,8 @@ /i18n/ru.toml @shurup @kirkonru @tym83 # Approvers for Turkish contents -/content/tr/ @aliok @halil-bugol @rwxdash @eminalemdar -/i18n/tr.toml @aliok @halil-bugol @rwxdash @eminalemdar +/content/tr/ @aliok @symys @rwxdash @eminalemdar +/i18n/tr.toml @aliok @symys @rwxdash @eminalemdar # Approvers for Urdu contents /content/ur/ @Saim-Safdar @waleed318 @@ -75,5 +75,5 @@ /i18n/zh-cn.toml @hanyuancheung @Jacob953 @Rocksnake @Submarinee # Approvers for Traditional Chinese contents -/content/zh-tw/ @pichuang @ydFu @hwchiu @johnlinp -/i18n/zh-tw.toml @pichuang @ydFu @hwchiu @johnlinp +/content/zh-tw/ @tico88612 @ydFu @hwchiu @johnlinp +/i18n/zh-tw.toml @tico88612 @ydFu @hwchiu @johnlinp diff --git a/LOCALIZATION.md b/LOCALIZATION.md index 07917a2af4..d19816a145 100644 --- a/LOCALIZATION.md +++ b/LOCALIZATION.md @@ -57,26 +57,31 @@ Open a PR with the localization initiation following this example: https://githu To add a new language to the site, modify [config.toml](https://github.com/cncf/glossary/blob/main/config.toml#L54) (Note: localization teams should use their assigned development branch for this). -The `[languages]` block of `config.toml` is used to set the language. For instance, `[languages.en]` stands for English and `[languages.ko]` for Korean language configuration. Go to the `[languages]` block in `config.toml` and add a new block for your language-specific configuration. For instance, the Korean localization team added its `[languages.ko]` block after the `[languages.en]` block. +The `[languages]` block of `config.toml` is used to set the language. For instance, `[languages.en]` stands for English and `[languages.ko]` for Korean language configuration. Go to the `[languages]` block in `config.toml` and find a place for your new localization: + + - The English language always stays first. + - Other languages are sorted based on the alphabetized English translation of their names (see how currently existing localizations are ordered as an example). + - Each localization is written in its own language followed by the English translation in parentheses — e.g., `한국어 (Korean)`. + - The `weight` parameter in the config is used for sorting (`1` is for English, `2` is for the alphabetically first language, `3` is for the second one, and so on). + +For instance, you're adding a new block for the Korean localization. You calculated its weight as 8. Find the language block with `weight = 7` and add your new block afterwards: - Example of `New language block for /config.toml` ```diff [languages] - [languages.en] - title = "Cloud Native Glossary" - description = "The CNCF Cloud Native Glossary Project is intended to be used as a reference for common terms used when talking about cloud native applications." - languageName ="English" - # Weight used for sorting. - weight = 1 + ... + weight = 7 +[languages.ko] +title = "클라우드 네이티브(Cloud Native) 용어집" +description = "CNCF 클라우드 네이티브 용어집 프로젝트는 클라우드 네이티브 애플리케이션에 대한 대화를 나눌 때 공통의 용어를 참조하여 사용하도록 하는 목적을 가지고 있다." - +languageName ="한국어(Korean)" + +languageName = "한국어 (Korean)" +contentDir = "content/ko" - +weight = 2 + +weight = 8 ``` +Since the `weight` values should always be kept consistent, please **remember to increment the weights** of all the languages following your newly added localization. + #### 3-2. Adding a file for site strings `i18n/.toml` sets up language-specific site strings. diff --git a/Makefile b/Makefile new file mode 100644 index 0000000000..85ae00b701 --- /dev/null +++ b/Makefile @@ -0,0 +1,49 @@ +HTMLTEST_DIR=tmp +HTMLTEST?=htmltest # Specify as make arg if different +HTMLTEST_ARGS?=--skip-external + +# Use $(HTMLTEST) in PATH, if available; otherwise, we'll get a copy +ifeq (, $(shell which $(HTMLTEST))) +override HTMLTEST=$(HTMLTEST_DIR)/bin/htmltest +ifeq (, $(shell which $(HTMLTEST))) +GET_LINK_CHECKER_IF_NEEDED=get-link-checker +endif +endif + +check-links: $(GET_LINK_CHECKER_IF_NEEDED) + $(HTMLTEST) $(HTMLTEST_ARGS) + +clean: + rm -rf $(HTMLTEST_DIR) public/* resources + +get-link-checker: + rm -Rf $(HTMLTEST_DIR)/bin + curl https://htmltest.wjdp.uk | bash -s -- -b $(HTMLTEST_DIR)/bin + +serve: + npx hugo server \ + --disableFastRender \ + --buildDrafts \ + --buildFuture \ + --ignoreCache + --printI18nWarnings \ + --printMemoryUsage \ + --printPathWarnings \ + --printUnusedTemplates \ + --templateMetrics \ + --templateMetricsHints \ + --gc + +production-build: + npm run get:submodule + npx hugo --minify + npx -y pagefind --site public + +preview-build: + git submodule update --init --recursive + npx hugo \ + --baseURL $(DEPLOY_PRIME_URL) \ + --buildDrafts \ + --buildFuture \ + --minify + npx -y pagefind --site public diff --git a/README.md b/README.md index f3da6caeb1..c5fbfd84bc 100644 --- a/README.md +++ b/README.md @@ -13,19 +13,19 @@ If you'd like to help with the glossary we'd love to have your contributions! Pl ## Acknowledgements The Cloud Native Glossary was initiated by the CNCF Marketing Committee -(Business Value Subcommittee) and includes contributions from -[Catherine Paganini](https://www.linkedin.com/in/catherinepaganini/en/), -[Chris Aniszczyk](https://www.linkedin.com/in/caniszczyk/), -[Daniel Jones](https://www.linkedin.com/in/danieljoneseb/?originalSubdomain=uk), -[Jason Morgan](https://www.linkedin.com/in/jasonmorgan2/), -[Katelin Ramer](https://www.linkedin.com/in/katelinramer/), -[Mike Foster](https://www.linkedin.com/in/mfosterche/?originalSubdomain=ca), -and many more contributors. +(Business Value Subcommittee) and includes contributions from +[Catherine Paganini](https://www.linkedin.com/in/catherinepaganini/en/), +[Chris Aniszczyk](https://www.linkedin.com/in/caniszczyk/), +[Daniel Jones](https://www.linkedin.com/in/danieljoneseb/?originalSubdomain=uk), +[Jason Morgan](https://www.linkedin.com/in/jasonmorgan2/), +[Katelin Ramer](https://www.linkedin.com/in/katelinramer/), +[Mike Foster](https://www.linkedin.com/in/mfosterche/?originalSubdomain=ca), +and many more contributors. For a complete contributor list, please refer to [this GitHub page](https://github.com/cncf/glossary/graphs/contributors). -The Glossary is maintained by +The Glossary is maintained by [Seokho Son](https://www.linkedin.com/in/seokho-son/), -[Noah Ispas](https://www.linkedin.com/in/noah-ispas-0665b42a/), +[Noah Ispas](https://www.linkedin.com/in/noah-ispas-0665b42a/), [Jihoon Seo](https://www.linkedin.com/in/jihoon-seo/), [Nate W.](https://www.linkedin.com/in/nate-double-u/), and [Jorge Castro](https://www.linkedin.com/in/jorge-castro2112/). @@ -43,13 +43,11 @@ All code contributions are under the Apache 2.0 license. Documentation is distri To improve the Cloud Native Glossary site itself, install a local copy with these instructions. Note you must have [npm](https://www.npmjs.com/) and [Hugo](https://gohugo.io/) installed. -``` +```sh git clone https://github.com/cncf/glossary.git -cd glossary -git submodule update --init --recursive npm install ``` -You can then run the site using `npm run serve` (select "[Hugo]"). +You can then run the site using `npm run serve` (select "[Hugo]"). To have the site run locally with a functioning local search, run `npm run serve:with-pagefind`. [![Open in GitHub Codespaces](https://github.com/codespaces/badge.svg)](https://github.com/codespaces/new?repo=cncf/glossary) diff --git a/assets/js/search.js b/assets/js/search.js new file mode 100644 index 0000000000..42250f4e94 --- /dev/null +++ b/assets/js/search.js @@ -0,0 +1,43 @@ +/* +Copyright 2018 Google LLC + +Licensed under the Apache License, Version 2.0 (the "License"); +you may not use this file except in compliance with the License. +You may obtain a copy of the License at + + https://www.apache.org/licenses/LICENSE-2.0 + +Unless required by applicable law or agreed to in writing, software +distributed under the License is distributed on an "AS IS" BASIS, +WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. +See the License for the specific language governing permissions and +limitations under the License. +*/ + +(function($) { + + 'use strict'; + + var Search = { + init: function() { + $(document).ready(function() { + $(document).on('keypress', '.td-search-input', function(e) { + if (e.keyCode !== 13) { + return + } + + var query = $(this).val(); + var searchPage = $(this).data('search-page') + "?q=" + query; + document.location = searchPage; + + return false; + }); + + }); + }, + }; + + Search.init(); + + +}(jQuery)); diff --git a/assets/scss/_search.scss b/assets/scss/_search.scss index 11748925a9..50bb155ab8 100644 --- a/assets/scss/_search.scss +++ b/assets/scss/_search.scss @@ -100,3 +100,14 @@ } } + +.pagefind-ui__result-link { + color: $link-color !important; +} +.pagefind-ui__search-clear { + padding-left: 20px !important; + padding-right: 20px !important; +} +#search { + margin-top: 40px; +} diff --git a/config.toml b/config.toml index 147a46f848..d43244d07c 100644 --- a/config.toml +++ b/config.toml @@ -33,16 +33,16 @@ blog = "/:section/:year/:month/:day/:slug/" ## Configuration for BlackFriday markdown parser: https://github.com/russross/blackfriday [blackfriday] -plainIDAnchors = true -hrefTargetBlank = true angledQuotes = false +hrefTargetBlank = true latexDashes = true +plainIDAnchors = true # Image processing configuration. [imaging] -resampleFilter = "CatmullRom" -quality = 75 anchor = "smart" +quality = 75 +resampleFilter = "CatmullRom" [services] [services.googleAnalytics] @@ -53,8 +53,8 @@ anchor = "smart" [languages] [languages.en] +languageName = "English" title = "Cloud Native Glossary" -languageName ="English" # Weight used for sorting. weight = 1 [languages.en.params] @@ -68,104 +68,127 @@ description = "The CNCF Cloud Native Glossary Project is intended to be used as #time_format_default = "02.01.2006" #time_format_blog = "02.01.2006" +[languages.bn] +contentDir = "content/bn" +languageName = "বাংলা (Bengali)" +title = "ক্লাউড নেটিভ শব্দকোষ" +weight = 2 +[languages.bn.params] +description = "CNCF ক্লাউড নেটিভ শব্দকোষ প্রকল্পটি ক্লাউড নেটিভ অ্যাপ্লিকেশন সম্পর্কে কথা বলার সময় ব্যবহৃত সাধারণ পদগুলির জন্য একটি রেফারেন্স হিসাবে ব্যবহার করার উদ্দেশ্যে।" + +[languages.fr] +contentDir = "content/fr" +languageName = "Français (French)" +title = "Glossaire Cloud Native" +weight = 3 +[languages.fr.params] +description = "Le projet de Glossaire CNCF Cloud Native a pour objectif de référencer les termes courants utilisés dans les différentes applications Cloud Natives." + +[languages.de] +contentDir = "content/de" +languageName = "Deutsch (German)" +title = "Cloud Native Glossar" +weight = 4 +[languages.de.params] +description = "Das CNCF Cloud Native Glossar soll als Referenz für gängige Begriffe dienen, die im Zusammenhang mit Cloud Native Anwendungen verwendet werden." [languages.hi] -title = "क्लाउड नेटिव शब्दावली" -languageName ="हिन्दी (Hindi)" contentDir = "content/hi" -weight = 2 +languageName = "हिन्दी (Hindi)" +title = "क्लाउड नेटिव शब्दावली" +weight = 5 [languages.hi.params] description = "CNCF क्लाउड नेटिव शब्दावली परियोजना का उद्देश्य क्लाउड नेटिव एप्लिकेशन के बारे में बात करते समय प्रयोग किए जाने वाले सामान्य शब्दों के संदर्भ के रूप में उपयोग किया जाना है।" -[languages.pt-br] -title = "Glossário Cloud Native" -languageName = "Português" -contentDir = "content/pt-br" -weight = 3 -[languages.pt-br.params] -description = "O Projeto CNCF Glossário Cloud Native se destina a ser usado como uma referência para termos comuns usados ao falar sobre aplicações nativas de nuvem." - [languages.it] -title = "Glossario Cloud Native" -languageName = "Italiano" contentDir = "content/it" -weight = 4 +languageName = "Italiano (Italian)" +title = "Glossario Cloud Native" +weight = 6 [languages.it.params] description = "Il progetto del Glossario CNCF Cloud Native è pensato per essere un riferimento per i termini comuni, usati nell'ambito delle applicazioni cloud native." +[languages.ja] +contentDir = "content/ja" +languageName = "日本語 (Japanese)" +title = "クラウドネイティブ用語集" +weight = 7 +[languages.ja.params] +description = "CNCF クラウドネイティブ用語集プロジェクトは、クラウドネイティブアプリケーションについて話すときに使われる一般的な用語のリファレンスとして使用することを目的としています。" + [languages.ko] -title = "클라우드 네이티브(Cloud Native) 용어집" -languageName ="한국어 (Korean)" contentDir = "content/ko" -weight = 5 +languageName = "한국어 (Korean)" +title = "클라우드 네이티브(Cloud Native) 용어집" +weight = 8 [languages.ko.params] description = "CNCF 클라우드 네이티브 용어집 프로젝트는 클라우드 네이티브 애플리케이션을 주제로 대화를 나눌 때 참조할 수 있는 공통의 용어 제공을 목표로 한다." -[languages.es] -title = "Cloud Native Glosario" -languageName ="Español (Spanish)" -contentDir = "content/es" -weight = 6 -[languages.es.params] -description = "El proyecto de CNCF Cloud Native Glosario pretende ser usado como una referencia para los terminos comunes usados cuando se habla acerca de las aplicaciones nativas para la nube." +[languages.pt-br] +contentDir = "content/pt-br" +languageName = "Português (Portuguese)" +title = "Glossário Cloud Native" +weight = 9 +[languages.pt-br.params] +description = "O Projeto CNCF Glossário Cloud Native se destina a ser usado como uma referência para termos comuns usados ao falar sobre aplicações nativas de nuvem." + +[languages.ru] +contentDir = "content/ru" +languageName = "Русский (Russian)" +title = "Глоссарий Cloud Native" +weight = 10 +[languages.ru.params] +description = "Глоссарий Cloud Native — справочник по общим терминам, имеющим отношение к нативным облачным приложениям и технологиям. Разрабатывается фондом CNCF." [languages.zh-cn] -title = "Cloud Native(云原生) Glossary" -languageName ="简体中文 (Simplified Chinese)" contentDir = "content/zh-cn" -weight = 7 +languageName = "简体中文 (Simplified Chinese)" +title = "Cloud Native(云原生) Glossary" +weight = 11 [languages.zh-cn.params] description = "CNCF 云原生 Glossary 项目旨在用作讨论云原生应用程序时常用术语的参考" -[languages.bn] -title = "ক্লাউড নেটিভ শব্দকোষ" -languageName = "বাংলা (Bengali)" -contentDir = "content/bn" -weight = 8 -[languages.bn.params] -description = "CNCF ক্লাউড নেটিভ শব্দকোষ প্রকল্পটি ক্লাউড নেটিভ অ্যাপ্লিকেশন সম্পর্কে কথা বলার সময় ব্যবহৃত সাধারণ পদগুলির জন্য একটি রেফারেন্স হিসাবে ব্যবহার করার উদ্দেশ্যে।" +[languages.es] +contentDir = "content/es" +languageName = "Español (Spanish)" +title = "Cloud Native Glosario" +weight = 12 +[languages.es.params] +description = "El proyecto de CNCF Cloud Native Glosario pretende ser usado como una referencia para los terminos comunes usados cuando se habla acerca de las aplicaciones nativas para la nube." -[languages.de] -title = "Cloud Native Glossar" -languageName ="Deutsch" -contentDir = "content/de" -weight = 9 -[languages.de.params] -description = "Das CNCF Cloud Native Glossar soll als Referenz für gängige Begriffe dienen, die im Zusammenhang mit Cloud Native Anwendungen verwendet werden." +[languages.zh-tw] +contentDir = "content/zh-tw" +languageName = "繁體中文 (Traditional Chinese)" +title = "Cloud Native(雲端原生) Glossary" +weight = 13 +[languages.zh-tw.params] +description = "CNCF 雲端原生 Glossary 專案旨在用作討論雲端原生應用程式時常用術語的參考" + +[languages.tr] +title = "Cloud Native Sözlüğü" +languageName ="Türkçe (Turkish)" +contentDir = "content/tr" +weight = 14 +[languages.tr.params] +description = "CNCF Cloud Native Sözlüğü projesi, cloud native uygulamalardan bahsederken kullanılan yaygın terimler için bir referans olarak kullanılmak üzere tasarlanmıştır." [languages.ur] -title = "کلاؤڈ کی مقامی لغت" -languageName ="اردو (Urdu)" contentDir = "content/ur" -weight = 10 +languageName = "اردو (Urdu)" +title = "کلاؤڈ کی مقامی لغت" +weight = 15 [languages.ur.params] description = "CNCF کلاؤڈ کی مقامی لغت کا مقصد کلاؤڈ مقامی ایپلی کیشنز کے بارے میں بات کرتے وقت استعمال ہونے والی عام اصطلاحات کے حوالے کے طور پر استعمال کرنا ہے۔" -[languages.fr] -title = "Glossaire Cloud Native" -languageName ="Français (French)" -contentDir = "content/fr" -weight = 11 -[languages.fr.params] -description = "Le projet de Glossaire CNCF Cloud Native a pour objectif de référencer les termes courants utilisés dans les différentes applications Cloud Natives." - -[languages.zh-tw] -title = "Cloud Native(雲端原生) Glossary" -languageName ="繁體中文 (Traditional Chinese)" -contentDir = "content/zh-tw" -weight = 12 -[languages.zh-tw.params] -description = "CNCF 雲端原生 Glossary 專案旨在用作討論雲端原生應用程式時常用術語的參考" - [markup] - [markup.goldmark] - [markup.goldmark.renderer] - unsafe = true - [markup.highlight] - # See a complete list of available styles at https://xyproto.github.io/splash/docs/all.html - style = "tango" - # Uncomment if you want your chosen highlight style used for code blocks without a specified language - # guessSyntax = "true" +[markup.goldmark] +[markup.goldmark.renderer] +unsafe = true +[markup.highlight] +# See a complete list of available styles at https://xyproto.github.io/splash/docs/all.html +style = "tango" +# Uncomment if you want your chosen highlight style used for code blocks without a specified language +# guessSyntax = "true" # Everything below this are Site Params @@ -184,13 +207,13 @@ images = ["images/cncf-glossary-social.jpg"] # This menu appears only if you have at least one [params.versions] set. version_menu = "Releases" -# Flag used in the "version-banner" partial to decide whether to display a +# Flag used in the "version-banner" partial to decide whether to display a # banner on every page indicating that this is an archived version of the docs. # Set this flag to "true" if you want to display the banner. archived_version = false # The version number for the version of the docs represented in this doc set. -# Used in the "version-banner" partial to display a version number for the +# Used in the "version-banner" partial to display a version number for the # current doc set. version = "0.0" @@ -208,10 +231,10 @@ github_repo = "https://github.com/cncf/glossary" # Uncomment this if you have a newer GitHub repo with "main" as the default branch, # or specify a new value if you want to reference another branch in your GitHub links -github_branch= "main" +github_branch = "main" # Google Custom Search Engine ID. Remove or comment out to disable search. -gcs_engine_id = "eda0239a7d3fd0d90" +# gcs_engine_id = "eda0239a7d3fd0d90" # Enable Algolia DocSearch algolia_docsearch = false @@ -242,15 +265,15 @@ footer_about_disable = true [params.ui.feedback] enable = true # The responses that the user sees after clicking "yes" (the page was helpful) or "no" (the page was not helpful). -yes = 'Thank you! Please let us know if you have any suggestions.' no = 'Thanks for your feedback. Please tell us how we can improve.' +yes = 'Thank you! Please let us know if you have any suggestions.' # Adds a reading time to the top of each doc. -# If you want this feature, but occasionally need to remove the Reading time from a single page, +# If you want this feature, but occasionally need to remove the Reading time from a single page, # add "hide_readingtime: true" to the page's front matter [params.ui.readingtime] enable = false [taxonomies] -tag = "tags" category = "categories" +tag = "tags" diff --git a/content/bn/_TEMPLATE.md b/content/bn/_TEMPLATE.md index 534be65b3a..ab58fffc86 100644 --- a/content/bn/_TEMPLATE.md +++ b/content/bn/_TEMPLATE.md @@ -4,14 +4,16 @@ status: Feedback Appreciated category: ধারণা --- -## এটা কি - -এটি ধারণার একটি দ্রুত সারাংশ । +ধারণার দ্রুত সারাংশ এবং এটি কী। ## এটা যেসব সমস্যাতে দৃষ্টিপাত করে -এটি যে সমস্যার সমাধান করছে তার কয়েকটি লাইন। +এটি যে সমস্যাটি সমাধান করে তা সংজ্ঞায়িত করুন। আদর্শহবে, আপনি যে শব্দটি সংজ্ঞায়িত করছেন তা উল্লেখ করবেন না। ## এটা কিভাবে সাহায্য করে -জিনিসটি কীভাবে সমস্যার সমাধান করে তার কয়েকটি লাইন। +বর্ণনা করুন কিভাবে শব্দটি উপরে বর্ণিত সমস্যার সমাধান করে। + +## সম্পর্কিত পদ + +সম্পর্কিত শব্দকোষ পদ যোগ করুন (যদি প্রযোজ্য হয়) । diff --git a/content/bn/_index.md b/content/bn/_index.md index daee43d421..dd6104aeb3 100644 --- a/content/bn/_index.md +++ b/content/bn/_index.md @@ -5,23 +5,55 @@ status: Completed # ক্লাউড নেটিভ শব্দকোষ -ক্লাউড নেটিভ শব্দকোষ হল CNCF বিজনেস ভ্যালু সাবকমিটি (BVS) এর নেতৃত্বে একটি প্রকল্প। এর লক্ষ্য হল ক্লাউড নেটিভ ধারণাগুলিকে পরিষ্কার এবং সহজ ভাষায় ব্যাখ্যা করা কোনো পূর্বের প্রযুক্তিগত জ্ঞানের প্রয়োজন ছাড়াই।[আপনি এখানে (ইংরেজিতে) PDF সংস্করণ দেখতে বা ডাউনলোড করতে পারেন।](https://github.com/cncf/glossary/blob/main/cloudnative-glossary.pdf) +ক্লাউড নেটিভ শব্দকোষের লক্ষ্য হলো ক্লাউড নেটিভ স্পেসকে ( যা এর জটিলতার জন্য কুখ্যাত ) সহজতর করে বোঝার জন্য লোকেদের জন্য, +শুধুমাত্র প্রযুক্তিবিদদের জন্যই নয়, ব্যবসার দিকের লোকদের জন্যও। +এটি অর্জন করার জন্য, আমরা সরলতার উপর ফোকাস করি (যেমন, বাজওয়ার্ড থেকে মুক্ত সহজ ভাষা, প্রযুক্তি ব্যবহার করে যে কেউ এর সাথে সম্পর্কিত হতে পারে এমন উদাহরণ, অপ্রয়োজনীয় বিবরণ বাদ দিয়ে)। +শব্দকোষ হল CNCF বিজনেস ভ্যালু সাবকমিটি (BVS) এর নেতৃত্বে একটি প্রকল্প। + +

মানুষ একটি Kubecon উপস্থাপনা দেখছেন

## অবদান -ক্লাউড নেটিভ শব্দকোষে পরিবর্তন, সংযোজন এবং উন্নতির পরামর্শ দেওয়ার জন্য সবাইকে আমন্ত্রণ জানানো হয়েছে। আমরা এই ভাগ করা অভিধানের বিকাশ এবং উন্নতির জন্য CNCF দ্বারা পরিচালিত একটি সম্প্রদায়-চালিত প্রক্রিয়া নিযুক্ত করি। এই শব্দকোষটি ক্লাউড নেটিভ প্রযুক্তির আশেপাশে একটি ভাগ করা শব্দভাণ্ডার সংগঠিত করার জন্য একটি বিক্রেতা-নিরপেক্ষ প্ল্যাটফর্ম প্রদান করে৷ প্রজেক্টের উদ্দেশ্য এবং চার্টার মেনে চলা সকল অংশগ্রহণকারীদের থেকে অবদানকে স্বাগত জানানো হয়। +ক্লাউড নেটিভ শব্দকোষে পরিবর্তন, সংযোজন এবং উন্নতির পরামর্শ দেওয়ার জন্য সকলেই আমন্ত্রিত। +আমরা এই ভাগ করা অভিধানের বিকাশ এবং উন্নতির জন্য CNCF দ্বারা পরিচালিত একটি সম্প্রদায়-চালিত প্রক্রিয়া নিযুক্ত করি। +এই শব্দকোষটি ক্লাউড নেটিভ প্রযুক্তি জুড়ে একটি ভাগ করা শব্দভাণ্ডার সংগঠিত করার জন্য একটি বিক্রেতা-নিরপেক্ষ প্ল্যাটফর্ম প্রদান করে৷ +প্রজেক্টের উদ্দেশ্য এবং সনদ মেনে চলা সকল অংশগ্রহণকারীদের থেকে অবদানকে স্বাগত জানানো হয়। -যে কেউ একটি অবদান করতে ইচ্ছুক একটি GitHub সমস্যা(issue) জমা দিতে বা একটি পুল অনুরোধ (pull request) তৈরি করতে পারেন. অনুগ্রহ করে নিশ্চিত করুন যে আপনি [শৈলী নির্দেশিকা](/bn/style-guide/) অনুসরণ করছেন, [কীভাবে অবদান রাখবেন](/bn/contribute/) ডকটি পড়ুন এবং CNCF স্ল্যাকের #glossary চ্যানেলে যোগদান করুন। এছাড়াও যারা তাদের মাতৃভাষায় শব্দকোষ অনুবাদ করতে সাহায্য করতে চান তাদের জন্য একটি #glossary-localizations চ্যানেল রয়েছে। +যে অবদান করতে ইচ্ছুক, একটি GitHub সমস্যা (issue) জমা দিতে বা একটি পুল অনুরোধ (pull request) তৈরি করতে পারেন। +অনুগ্রহ করে নিশ্চিত করুন যে আপনি [শৈলী নির্দেশিকা](/bn/style-guide/) অনুসরণ করছেন, [কীভাবে অবদান রাখবেন](/bn/contribute/) ডকটি পড়ুন এবং CNCF স্ল্যাকের #glossary চ্যানেলে যোগদান করুন। +এছাড়াও যারা তাদের মাতৃভাষায় শব্দকোষ অনুবাদ করতে সাহায্য করতে চান তাদের জন্য একটি #glossary-localizations চ্যানেল রয়েছে। ## স্বীকৃতি -ক্লাউড নেটিভ শব্দকোষটি CNCF মার্কেটিং কমিটি (ব্যবসায়িক মূল্য উপকমিটি)দ্বারা সূচিত হয়েছিল এবং এতে অবদানকারী হিসেবে রয়েছে [Catherine Paganini](https://www.linkedin.com/in/catherinepaganini/en/), [Chris Aniszczyk](https://www.linkedin.com/in/caniszczyk/), -[Daniel Jones](https://www.linkedin.com/in/danieljoneseb/?originalSubdomain=uk), [Jason Morgan](https://www.linkedin.com/in/jasonmorgan2/), [Katelin Ramer](https://www.linkedin.com/in/katelinramer/), [Mike Foster](https://www.linkedin.com/in/mfosterche/?originalSubdomain=ca) এবং আরও অনেকে। একটি সম্পূর্ণ অবদানকারী তালিকার জন্য, অনুগ্রহ করে [এই GitHub পৃষ্ঠা](https://github.com/cncf/glossary/graphs/contributors) দেখুন। - -শব্দকোষটি পরিচালিত হয় [Catherine Paganini](https://www.linkedin.com/in/catherinepaganini/en/), [Jason Morgan](https://www.linkedin.com/in/jasonmorgan2/), [Jihoon Seo](https://www.linkedin.com/in/jihoon-seo/), [Noah Ispas](https://www.linkedin.com/in/noah-ispas-0665b42a/), এবং [Seokho Son](https://www.linkedin.com/in/seokho-son/) দ্বারা । - -ক্লাউড নেটিভ ভোকাবুলারির বাংলা স্থানীয়করণের সূচনা [Bengali localization team](https://cloud-native.slack.com/archives/C02UG2WGXQQ) দ্বারা করা হয়েছে এবং এতে অন্তর্ভুক্ত রয়েছে [MD Shahriyar Al Mustakim Mitul](https://www.linkedin.com/in/md-shahriyar-al-mustakim-mitul-9084b31a0/), [MD Ikramul Kayes](https://www.linkedin.com/in/md-ikramul-kayes-753674214/), [Umme Abira Azmary](https://www.linkedin.com/in/umme-abira-azmary-68404a1bb/) এবং আরও অনেক অবদানকারী। +ক্লাউড নেটিভ শব্দকোষটি CNCF মার্কেটিং কমিটি (বিজনেস ভ্যালু সাবকমিটি) দ্বারা সূচিত হয়েছিল এবং এতে অবদানকারী হিসেবে রয়েছে +[Catherine Paganini](https://www.linkedin.com/in/catherinepaganini/en/), +[Chris Aniszczyk](https://www.linkedin.com/in/caniszczyk/), +[Daniel Jones](https://www.linkedin.com/in/danieljoneseb/?originalSubdomain=uk), +[Jason Morgan](https://www.linkedin.com/in/jasonmorgan2/), +[Katelin Ramer](https://www.linkedin.com/in/katelinramer/), +[Mike Foster](https://www.linkedin.com/in/mfosterche/?originalSubdomain=ca) +এবং আরও অনেকে। +একটি সম্পূর্ণ অবদানকারী তালিকার জন্য, অনুগ্রহ করে [এই GitHub পৃষ্ঠা](https://github.com/cncf/glossary/graphs/contributors) দেখুন। + +শব্দকোষটি পরিচালিত হয় +[Seokho Son](https://www.linkedin.com/in/seokho-son/), +[Noah Ispas](https://www.linkedin.com/in/noah-ispas-0665b42a/), +[Jihoon Seo](https://www.linkedin.com/in/jihoon-seo/), +[Nate W.](https://www.linkedin.com/in/nate-double-u/)), +এবং [Jorge Castro](https://www.linkedin.com/in/jorge-castro2112/) দ্বারা । + +[Catherine Paganini](https://www.linkedin.com/in/catherinepaganini/en/), +এবং [Jason Morgan](https://www.linkedin.com/in/jasonmorgan2/) +ইমেরিটাস রক্ষণাবেক্ষণকারী, এবং আমরা গভীরভাবে কৃতজ্ঞ +বছরের পর বছর ধরে তাদের অমূল্য অবদানের জন্য। + +ক্লাউড নেটিভ ভোকাবুলারির বাংলা স্থানীয়করণের সূচনা [Bengali localization team](https://cloud-native.slack.com/archives/C02UG2WGXQQ) দ্বারা করা হয়েছে +এবং এতে অন্তর্ভুক্ত রয়েছে [MD Shahriyar Al Mustakim Mitul](https://www.linkedin.com/in/mitul-shahriyar/), +[Asem Hamid](https://www.linkedin.com/in/asemhamid/), +[Sajib Adhikary](https://www.linkedin.com/in/sajibadhi/) +এবং আরও অনেক অবদানকারী। ## লাইসেন্স -সমস্ত কোড অবদান Apache 2.0 লাইসেন্সের অধীনে। ডকুমেন্টেশন CC BY 4.0 এর অধীনে বিতরণ করা হয়। +সমস্ত কোড অবদান Apache 2.0 লাইসেন্সের অধীনে। +ডকুমেন্টেশন CC BY 4.0 এর অধীনে বিতরণ করা হয়। diff --git a/content/bn/abstraction.md b/content/bn/abstraction.md index a37c310bb3..26dd0e5789 100644 --- a/content/bn/abstraction.md +++ b/content/bn/abstraction.md @@ -2,7 +2,7 @@ title: অ্যাবস্ট্রাকশন (Abstraction) status: Completed category: বৈশিষ্ট্য -tags: ["fundamental", "", ""] +tags: ["মৌলিক", "", ""] --- কম্পিউটিং এর প্রেক্ষাপটে, অ্যাবস্ট্রাকশন অথবা বিমূর্ততা হল এক ধরনের উপস্থাপনা যেখানে সাধারণ ব্যবহারকারী এবং [সেবা](/bn/service/) ভোগকারীদের (কম্পিউটার প্রোগ্রাম অথবা মানুষ) কাছ থেকে সিস্টেমের জটিল এবং অপ্রয়োজনীয় বিষয়গুলি লুকিয়ে রাখা হয়, এভাবে সিস্টেমকে খুব সিম্পল ভাবে উপস্থাপন করা হয় ফলে সিস্টেমকে বুঝতেও সুবিধা হয়। একটি ভালো উদাহরণ হল আপনার ল্যাপটপের অপারেটিং সিস্টেম (OS)। এটি আপনার কম্পিউটার কিভাবে কাজ করে তার সমস্ত বিবরণ বিমূর্ত করে। আপনার সিপিইউ মেমোরি অথবা প্রোগ্রামগুলোকে কিভাবে পরিচালনা করতে হয় সে সম্পর্কে কিছু জানার দরকার নেই, আপনি শুধু আপনার অপারেটিং সিস্টেম চালান এবং আপনার OS নিজেই এই জটিল বিষয়গুলো পরিচালনা করে। OS কিভাবে কাজগুলো হ্যান্ডেল করে করে তা আপনার জানার দরকার নেই এবং সমস্ত বিবরণ এই OS "পর্দা" বা বিমূর্ততার পিছনে লুকানো রয়েছে। diff --git a/content/bn/agile-software-development.md b/content/bn/agile-software-development.md index bf799d2bcc..e64ea0e851 100644 --- a/content/bn/agile-software-development.md +++ b/content/bn/agile-software-development.md @@ -2,11 +2,9 @@ title: অ্যাজাইল সফটওয়্যার ডেভেলপমেন্ট (Agile Software Development) status: Completed category: ধারণা -tags: ["methodology", "", ""] +tags: ["পদ্ধতি", "", ""] --- -## এটা কি - এটি একটি অনুশীলনের সেট যা পুনরাবৃত্তিমূলক বিকাশ চক্র এবং স্ব-সংগঠিত দলের উপর জোর স্থাপন করে। জলপ্রপাতের মতো প্রজেক্টগুলির বিপরীতে যেখানে একটি প্রজেক্টের সুবিধা কেবল প্রজেক্টের শেষেই পাওয়া যায়, অ্যাজাইল সফটওয়্যার ডেভলপমেন্ট দৃষ্টিপাত করে কিভাবে একটি ক্রমাগত, ক্রমবর্ধমান মূল্য সরবরাহ করতে পারা যায় এবং দৃষ্টিপাত করে যেন প্রক্রিয়াটি নিজের বিবর্তনীয় উন্নতির উপর দৃষ্টি নিবদ্ধ করে। ## এটা যেসব সমস্যাতে দৃষ্টিপাত করে diff --git a/content/bn/api-gateway.md b/content/bn/api-gateway.md index 3861466767..eaa6887766 100644 --- a/content/bn/api-gateway.md +++ b/content/bn/api-gateway.md @@ -2,11 +2,9 @@ title: API গেটওয়ে(API Gateway) status: Completed category: প্রযুক্তি -tags: ["networking", "", ""] +tags: ["নেটওয়ার্কিং", "", ""] --- -## এটা কি - একটি [API](/bn/application-programming-interface/) গেটওয়ে হল একটি টুল যা অনন্য অ্যাপ্লিকেশন APIগুলিকে একত্রিত করে এবং সেগুলিকে এক জায়গায় উপলব্ধ করে। এটি সংস্থাগুলিকে মূল ফাংশনগুলি সরানোর অনুমতি দেয়, diff --git a/content/bn/application-programming-interface.md b/content/bn/application-programming-interface.md index 771d67f113..88b4a0883d 100644 --- a/content/bn/application-programming-interface.md +++ b/content/bn/application-programming-interface.md @@ -2,10 +2,9 @@ title: অ্যাপ্লিকেশান প্রোগ্রামিং ইন্টারফেস (API) status: Completed category: প্রযুক্তি -tags: ["architecture", "fundamental", ""] +tags: ["স্থাপত্য", "মৌলিক", ""] --- -## এটা কি একটি API হল কম্পিউটার প্রোগ্রামগুলির একে অপরের সাথে যোগাযোগ করার একটি উপায়। মানুষ যেমন একটি ওয়েব পৃষ্ঠার মাধ্যমে একটি ওয়েবসাইটের সাথে যোগাযোগ করে, তেমনি একটি API কম্পিউটার প্রোগ্রামগুলিকে একে অপরের সাথে যোগাযোগ করতে দেয়। মানুষের মিথস্ক্রিয়া থেকে ভিন্ন, API-গুলির সীমাবদ্ধতা রয়েছে তাদের থেকে কী জিজ্ঞাসা করা যায় এবং কী করা যায় না। ইন্টারঅ্যাকশনের সীমাবদ্ধতা প্রোগ্রামগুলির মধ্যে স্থিতিশীল এবং কার্যকরী যোগাযোগ তৈরি করতে সহায়তা করে। ## এটা যেসব সমস্যাতে দৃষ্টিপাত করে diff --git a/content/bn/auto-scaling.md b/content/bn/auto-scaling.md new file mode 100644 index 0000000000..411c0b25ae --- /dev/null +++ b/content/bn/auto-scaling.md @@ -0,0 +1,28 @@ +--- +title: অটোস্কেলিং (Autoscaling) +status: Completed +category: সম্পত্তি +tags: ["অবকাঠামো", "", ""] +--- + +অটোস্কেলিং হলো সাধারণত একটি সিস্টেমের কম্পিউটিং রিসোর্সগুলোর পরিপ্রেক্ষিতে স্বয়ংক্রিয়ভাবে [স্কেল](/bn/scalability/) ক্ষমতা। +অটোস্কেলিং সিস্টেমের সাহায্যে, ব্যবহারকারী চাহিদা অনুযায়ী রিসোর্স স্কেল করতে এবং প্রয়োজনের সময় স্বয়ংক্রিয়ভাবে রিসোর্সগুলো যোগ করতে পারে। +অটোস্কেলিং প্রক্রিয়া পরিবর্তনশীল এবং মেমোরি বা প্রক্রিয়া সময়ের মতো বিভিন্ন মেট্রিক্সের উপর ভিত্তি করে স্কেল করার জন্য কনফিগারযোগ্য। +ক্লাউড পরিষেবাগুলো সাধারণত অটোস্কেলিং এর মাধ্যমে পরিচালিত হয় +কারণ বেশিরভাগ অন-প্রিমাইজ ডিপ্লোয়মেন্টের চেয়ে এটিতে আরও বেশি বাস্তবায়ন করার ব্যবস্থা রয়েছে। + +পূর্বে, সিস্টেমের অবকাঠামো এবং অ্যাপ্লিকেশনগুলোকে আর্কিটেক্ট করা হয়েছিল সিস্টেমের সর্বোচ্চ ব্যবহার বিবেচনা করার মাধ্যমে। +এই স্থাপনার দ্বারা রিসোর্সগুলো কম ব্যবহার হচ্ছিল এবং ভোক্তাদের চাহিদা পরিবর্তন করার জন্য স্থিতিস্থাপক ছিল। +এই স্থিতিস্থাপকতা ফলে ব্যবসায় উচ্চ খরচ ছিল এবং অতিরিক্ত চাহিদা দেখা দিলেই ব্যবসা বন্ধ হয়ে যাচ্ছিল। + +ক্লাউড, [ভারচুয়ালাইজিং](/bn/virtualization/), and [কন্টেইনারাইজিং](/bn/containerization/) অ্যাপ্লিকেশন এবং তাদের নির্ভরতা ব্যবহার করে, +সংস্থাগুলো ব্যবহারকারীর চাহিদা অনুযায়ী অ্যাপ্লিকেশন তৈরি করতে পারে। +এটি অ্যাপ্লিকেশন চাহিদা নিরীক্ষণ করতে পারে এবং স্বয়ংক্রিয়ভাবে এসব অ্যাপ্লিকেশন স্কেল করতে পারে, যার ফলে এট ব্যবহারকারীদের সর্বোত্তম অভিজ্ঞতা প্রদান করে। +যেমন প্রতি শুক্রবার সন্ধ্যায় Netflix-এর দর্শক সংখ্যা বৃদ্ধি পায়। +স্বয়ংক্রিয়ভাবে আউট করার অর্থ হল গতিশীলভাবে আরও রিসোর্স যোগ করা: উদাহরণস্বরূপ, +আরও ভিডিও স্ট্রিমিংয়ের অনুমতি দেয় এমন সার্ভারের সংখ্যা বৃদ্ধি করা এবং একবার ব্যবহার স্বাভাবিক হয়ে গেলে আবার স্কেল করা। + +## সম্পর্কিত পদ + +* [অনুভূমিক স্কেলিং](/bn/horizontal-scaling/) +* [উল্লম্ব স্কেলিং](/bn/vertical-scaling/) diff --git a/content/bn/auto_scaling.md b/content/bn/auto_scaling.md deleted file mode 100644 index 967b12c326..0000000000 --- a/content/bn/auto_scaling.md +++ /dev/null @@ -1,12 +0,0 @@ ---- -title: অটোস্কেলিং (Autoscaling) -status: Completed -category: সম্পত্তি -tags: ["infrastructure", "", ""] ---- - -অটোস্কেলিং হল সাধারণত একটি সিস্টেমের কম্পিউটিং রিসোর্সগুলির পরিপ্রেক্ষিতে স্বয়ংক্রিয়ভাবে [স্কেল](/bn/scalability/) ক্ষমতা। অটোস্কেলিং সিস্টেমের সাহায্যে, ব্যবহারকারী চাহিদা অনুযায়ী রিসোর্স স্কেল করতে এবং প্রয়োজনের সময় স্বয়ংক্রিয়ভাবে রিসোর্সগুলি যোগ করতে পারে। অটোস্কেলিং প্রক্রিয়া পরিবর্তনশীল এবং মেমোরি বা প্রক্রিয়া সময়ের মতো বিভিন্ন মেট্রিক্সের উপর ভিত্তি করে স্কেল করার জন্য কনফিগারযোগ্য। ক্লাউড পরিষেবাগুলি সাধারণত অটোস্কেলিং এর মাধ্যমে পরিচালিত হয় কারণ বেশিরভাগ অন-প্রিমাইজ ডিপ্লোয়মেন্টের চেয়ে এটিতে আরও বেশি বাস্তবায়ন করার ব্যবস্থা রয়েছে। - -পূর্বে, সিস্টেমের অবকাঠামো এবং অ্যাপ্লিকেশনগুলিকে আর্কিটেক্ট করা হয়েছিল সিস্টেমের সর্বোচ্চ ব্যবহার বিবেচনা করার মাধ্যমে। এই স্থাপনার দ্বারা রিসোর্সগুলি কম ব্যবহার হচ্ছিল এবং ভোক্তাদের চাহিদা পরিবর্তন করার জন্য স্থিতিস্থাপক ছিল। এই স্থিতিস্থাপকতা ফলে ব্যবসায় উচ্চ খরচ ছিল এবং অতিরিক্ত চাহিদা দেখা দিলেই ব্যবসা বন্ধ হয়ে যাচ্ছিল। - -ক্লাউড, [ভারচুয়ালাইজিং](/bn/virtualization/), and [কন্টেইনারাইজিং](/bn/containerization/) অ্যাপ্লিকেশন এবং তাদের নির্ভরতা ব্যবহার করে, সংস্থাগুলি ব্যবহারকারীর চাহিদা অনুযায়ী অ্যাপ্লিকেশন তৈরি করতে পারে। এটি অ্যাপ্লিকেশন চাহিদা নিরীক্ষণ করতে পারে এবং স্বয়ংক্রিয়ভাবে এসব অ্যাপ্লিকেশন স্কেল করতে পারে, যার ফলে এট ব্যবহারকারীদের সর্বোত্তম অভিজ্ঞতা প্রদান করে। যেমন প্রতি শুক্রবার সন্ধ্যায় Netflix-এর দর্শক সংখ্যা বৃদ্ধি পায়। স্বয়ংক্রিয়ভাবে আউট করার অর্থ হল গতিশীলভাবে আরও সংস্থান যোগ করা: উদাহরণস্বরূপ, আরও ভিডিও স্ট্রিমিংয়ের অনুমতি দেয় এমন সার্ভারের সংখ্যা বৃদ্ধি করা এবং একবার ব্যবহার স্বাভাবিক হয়ে গেলে আবার স্কেল করা। diff --git a/content/bn/bare-metal-machine.md b/content/bn/bare-metal-machine.md index 8237c1666b..f501c584ac 100644 --- a/content/bn/bare-metal-machine.md +++ b/content/bn/bare-metal-machine.md @@ -2,33 +2,31 @@ title: বেয়ার মেটাল মেশিন (Bare Metal Machine) status: Completed category: প্রযুক্তি -tags: ["infrastructure", "", ""] +tags: ["অবকাঠামো", "", ""] --- -## এটা কি - -বেয়ার মেটাল(bare metal) বলতে একটি ভৌত ​​কম্পিউটারকে বোঝায়, আরও নির্দিষ্টভাবে একটি সার্ভার, যার একটি এবং শুধুমাত্র একটি অপারেটিং সিস্টেম রয়েছে। +বেয়ার মেটাল(bare metal) বলতে একটি ফিজিক্যাল ​​কম্পিউটারকে বোঝায়, আরও নির্দিষ্টভাবে একটি সার্ভার, যার একটি এবং শুধুমাত্র একটি অপারেটিং সিস্টেম রয়েছে। আধুনিক কম্পিউটিংয়ে পার্থক্যটি গুরুত্বপূর্ণ কারণ বেশিরভাগ সার্ভারগুলোই [ভার্চুয়াল মেশিন](/bn/virtual-machine/)। -একটি ভৌত ​​সার্ভার(physical server) সাধারণত শক্তিশালী হার্ডওয়্যার অন্তর্নির্মিত একটি মোটামুটি বড় কম্পিউটার। -[ভার্চুয়ালাইজেশন](/bn/virtualization/) ছাড়া একটি অপারেটিং সিস্টেম ইনস্টল করা এবং সরাসরি শারীরিক হার্ডওয়্যারে অ্যাপ্লিকেশনটি চালানো কে, -"বেয়ার মেটাল"("bare metal") এ চলমান হিসাবে উল্লেখ করা হয়। +একটি ফিজিক্যাল ​​সার্ভার সাধারণত শক্তিশালী হার্ডওয়্যার অন্তর্নির্মিত একটি মোটামুটি বড় কম্পিউটার। +[ভার্চুয়ালাইজেশন](/bn/virtualization/) ছাড়া একটি অপারেটিং সিস্টেম ইনস্টল করা এবং সরাসরি ফিজিক্যাল হার্ডওয়্যারে অ্যাপ্লিকেশনটি চালানো কে, +"বেয়ার মেটাল" এ চলমান হিসাবে উল্লেখ করা হয়। ## এটা যেসব সমস্যাতে দৃষ্টিপাত করে একটি অপারেটিং সিস্টেমকে একটি ফিজিক্যাল কম্পিউটারের সাথে যুগল করাই হলো কম্পিউটিং এর আসল প্যাটার্ন(pattern)। -শারীরিক কম্পিউটারের সমস্ত সংস্থান সরাসরি অপারেটিং সিস্টেমে উপলব্ধ এবং কোন ভার্চুয়ালাইজেশন(virtualization) স্তর উপস্থিত না থাকার ফলে, + ফিজিক্যাল কম্পিউটারের সমস্ত সংস্থান সরাসরি অপারেটিং সিস্টেমে উপলব্ধ এবং কোন ভার্চুয়ালাইজেশন(virtualization) স্তর উপস্থিত না থাকার ফলে, হার্ডওয়্যারে অপারেটিং সিস্টেম নির্দেশাবলী অনুবাদ করার জন্য কোন কৃত্রিম বিলম্ব নেই। ## এটা কিভাবে সাহায্য করে -একটি কম্পিউটারের সমস্ত গণনা সংস্থান একটি একক অপারেটিং সিস্টেমে উত্সর্গ করে, +একটি কম্পিউটারের সমস্ত কম্পিউটিং রিসোর্স একটি একক অপারেটিং সিস্টেমে উৎসর্গ করে, আপনি অপারেটিং সিস্টেমে সম্ভাব্য সর্বোত্তম কর্মক্ষমতা প্রদান করতে পারেন। -আপনার যদি এমন একটি ওয়ার্কলোড(workload) চালানোর প্রয়োজন হয় যাতে অবশ্যই হার্ডওয়্যার সংস্থানগুলিতে অত্যন্ত দ্রুত অ্যাক্সেস থাকতে হবে, -বেয়ার মেটাল(bare metal) সঠিক সমাধান হতে পারে। +আপনার যদি এমন একটি ওয়ার্কলোড চালানোর প্রয়োজন হয় যাতে অবশ্যই হার্ডওয়্যার রিসোর্সগুলোতে অত্যন্ত দ্রুত অ্যাক্সেস থাকতে হবে, +বেয়ার মেটাল সঠিক সমাধান হতে পারে। [ক্লাউড নেটিভ অ্যাপস](/bn/cloud-native-apps/) প্রসঙ্গে আমরা সাধারণত [স্কেলিং](/bn/scalability/)(scaling) এর পরিপ্রেক্ষিতে পারফরম্যান্সের কথা চিন্তা করি, -যা [অনুভূমিক স্কেলিং](/bn/horizontal-scaling/)(horizontal-scaling) (আপনার রিসোর্স পুলে(resource pool) আরও মেশিন যোগ করা) দ্বারা পরিচালিত হতে পারে। -কিন্তু কিছু ওয়ার্কলোডস-এর(workloads) [উল্লম্ব স্কেলিং](/bn/vertical-scaling/) (একটি বিদ্যমান শারীরিক মেশিনে আরও শক্তি যোগ করা) -এবং একটি অত্যন্ত দ্রুত শারীরিক হার্ডওয়্যার(hardware) এর প্রয়োজন হতে পারে যে ক্ষেত্রে বেয়ার মেটাল(bare metal) ভালো উপযুক্ত। -শারীরিক হার্ডওয়্যার(hardware) এবং হার্ডওয়্যার ড্রাইভারগুলির(hardware drivers) সাথে তাল মিলিয়ে বেয়ার মেটাল(bare metal) যে কোন কাজ সম্পন্ন করতে সহায়তা করার অনুমতি দেয়। +যা [অনুভূমিক স্কেলিং](/bn/horizontal-scaling/)(horizontal-scaling) (আপনার রিসোর্স পুলে আরও মেশিন যোগ করা) দ্বারা পরিচালিত হতে পারে। +কিন্তু কিছু ওয়ার্কলোডস-এর [উল্লম্ব স্কেলিং](/bn/vertical-scaling/) (একটি বিদ্যমান ফিজিক্যাল মেশিনে আরও শক্তি যোগ করা) +এবং একটি অত্যন্ত দ্রুত ফিজিক্যাল হার্ডওয়্যার(hardware) এর প্রয়োজন হতে পারে যে ক্ষেত্রে বেয়ার মেটাল ভালো উপযুক্ত। + ফিজিক্যাল হার্ডওয়্যার এবং হার্ডওয়্যার ড্রাইভারগুলোর সাথে তাল মিলিয়ে বেয়ার মেটাল যে কোন কাজ সম্পন্ন করতে সহায়তা করার অনুমতি দেয়। diff --git a/content/bn/blue-green-deployment.md b/content/bn/blue-green-deployment.md index acfed03708..f49f1b2208 100644 --- a/content/bn/blue-green-deployment.md +++ b/content/bn/blue-green-deployment.md @@ -2,11 +2,9 @@ title: নীল সবুজ স্থাপনা (Blue Green Deployment) status: Completed category: ধারণা -tags: ["methodology", "application", ""] +tags: ["পদ্ধতি", "অ্যাপ্লিকেশন", ""] --- -## এটা কি - ন্যূনতম ডাউনটাইম সহ চলমান কম্পিউটার সিস্টেম আপডেট করার জন্য নীল-সবুজ স্থাপনা একটি কৌশল। অপারেটর দুটি পরিবেশ বজায় রাখে, যা "নীল" এবং "সবুজ" নামে ডাকা হয়। একটি প্রোডাকশন ট্র্যাফিক পরিবেশন করে (সংস্করণটি যেটি সেই সময় ব্যবহারকারীরা ব্যবহার করেন), যখন অন্যটি আপডেট করা হয়। diff --git a/content/bn/canary-deployment.md b/content/bn/canary-deployment.md index 7660de240b..4be488a1cd 100644 --- a/content/bn/canary-deployment.md +++ b/content/bn/canary-deployment.md @@ -2,11 +2,9 @@ title: ক্যানারি ডিপ্লয়মেন্ট (Canary Deployment) status: Completed category: ধারণা -tags: ["methodology", "application", ""] +tags: ["পদ্ধতি", "অ্যাপ্লিকেশন", ""] --- -## এটা কি - ক্যানারি ডিপ্লয়মেন্ট হল একটি স্থাপনার কৌশল যা দুটি পরিবেশ দিয়ে শুরু হয়: একটি লাইভ ট্র্যাফিক সহ এবং অন্যটিতে লাইভ ট্র্যাফিক ছাড়াই আপডেট করা কোড রয়েছে৷ ট্র্যাফিকটি ধীরে ধীরে অ্যাপ্লিকেশনটির আসল সংস্করণ থেকে আপডেট হওয়া সংস্করণে স্থানান্তরিত হয়। diff --git a/content/bn/chaos-engineering.md b/content/bn/chaos-engineering.md index d3ca48f467..b61f15bc51 100644 --- a/content/bn/chaos-engineering.md +++ b/content/bn/chaos-engineering.md @@ -2,11 +2,9 @@ title: কেওস ইঞ্জিনিয়ারিং (Chaos Engineering) status: Completed category: ধারণা -tags: ["methodology", "", ""] +tags: ["পদ্ধতি", "", ""] --- -## এটা কি - কেওস ইঞ্জিনিয়ারিং (Chaos Engineering) বা CE হল [ডিস্ট্রিবিউটেড সিস্টেমে (distributed system)](/bn/distributed-systems/) পরীক্ষা করার শৃঙ্খলা যাতে কোলাহলপূর্ণ এবং অপ্রত্যাশিত পরিস্থিতি সহ্য করার জন্য সিস্টেমে ক্ষমতা তৈরি হয়। ## এটা যেসব সমস্যাতে দৃষ্টিপাত করে diff --git a/content/bn/client-server-architecture.md b/content/bn/client-server-architecture.md index 4021dca0c5..fbfe624015 100644 --- a/content/bn/client-server-architecture.md +++ b/content/bn/client-server-architecture.md @@ -2,11 +2,9 @@ title: ক্লায়েন্ট-সার্ভার স্থাপত্য (Client-Server Architecture) status: Completed category: ধারণা -tags: ["architecture", "", ""] +tags: ["স্থাপত্য", "", ""] --- -## এটা কি - একটি ক্লায়েন্ট-সার্ভার স্থাপত্য (Client-Server Architecture), যুক্তি (বা কোড) যা একটি অ্যাপ্লিকেশন তৈরি করে তা দুই বা ততোধিক উপাদানের মধ্যে বিভক্ত হয়ঃ একটি ক্লায়েন্ট যে কাজ করতে বলে (যেমন আপনার ওয়েব ব্রাউজারে চলমান জিমেইল ওয়েব অ্যাপ্লিকেশন), diff --git a/content/bn/cloud-computing.md b/content/bn/cloud-computing.md index 68aca3d72b..b8c6969612 100644 --- a/content/bn/cloud-computing.md +++ b/content/bn/cloud-computing.md @@ -2,11 +2,9 @@ title: ক্লাউড কম্পিউটিং (Cloud Computing) status: Completed category: ধারণা -tags: ["infrastructure", "fundamental", ""] +tags: ["অবকাঠামো", "মৌলিক", ""] --- -## এটা কি - ক্লাউড কম্পিউটিং হল এমন একটি মডেল যা ইন্টারনেটের মাধ্যমে চাহিদা অনুযায়ী CPU, নেটওয়ার্ক এবং ডিস্ক ক্ষমতার মতো গণনা বিষয়ক কাজ(compute) করার সংস্থান সরবরাহ করে। ক্লাউড কম্পিউটিং এর মাধ্যমে ব্যবহারকারীরা নিজেদের শারীরিক অবস্থান থেকে ক্লাউডে থেকে প্রবেশ করতে পারে এবং প্রয়োজন অনুযায়ী ব্যবহার করতে পারে। ক্লাউড সুবিধা প্রদানকারী সংস্থাসমূহ যেমন AWS, GCP, Azure, DigitalOcean এবং অন্যান্য সকলেই তৃতীয় পক্ষ অর্থাৎ ব্যবহারকারীদের একাধিক ভৌগলিক অবস্থান থেকে ভাড়ার মাধ্যমে কম্পিউটিং বিষয়ক কাজ করার সুবিধা প্রদান করে। ## এটা যেসব সমস্যাতে দৃষ্টিপাত করে diff --git a/content/bn/cloud-native-apps.md b/content/bn/cloud-native-apps.md index 2b66ca48df..24696395bd 100644 --- a/content/bn/cloud-native-apps.md +++ b/content/bn/cloud-native-apps.md @@ -2,11 +2,9 @@ title: ক্লাউড নেটিভ অ্যাপস (Cloud Native Apps) status: Completed category: ধারণা -tags: ["application", "fundamental", ""] +tags: ["অ্যাপ্লিকেশন", "মৌলিক", ""] --- -## এটা কি - ক্লাউড নেটিভ অ্যাপ্লিকেশনগুলি বিশেষভাবে [ক্লাউড কম্পিউটিং (Cloud Computing)](/bn/cloud-computing/)-এ উদ্ভাবনের সুবিধা নেওয়ার জন্য ডিজাইন করা হয়েছে। এই অ্যাপ্লিকেশনগুলি তাদের নিজ নিজ ক্লাউড আর্কিটেকচারের সাথে সহজেই একত্রিত হয়, ক্লাউডের সংস্থান এবং [স্কেলিং](/bn/scalability/) ক্ষমতার সুবিধা নিয়ে থাকে। এটি ক্লাউড কম্পিউটিং দ্বারা চালিত অবকাঠামোতে(infrastructure) উদ্ভাবনের সুবিধা গ্রহণকারী অ্যাপ্লিকেশনগুলিকেও বোঝায়। diff --git a/content/bn/cloud-native-security.md b/content/bn/cloud-native-security.md index 7cdd1b639f..8551e18d5b 100644 --- a/content/bn/cloud-native-security.md +++ b/content/bn/cloud-native-security.md @@ -2,11 +2,9 @@ title: ক্লাউড নেটিভ নিরাপত্তা (Cloud Native Security) status: Completed category: ধারণা -tags: ["security", "", ""] +tags: ["নিরাপত্তা", "", ""] --- -## এটা কি - ক্লাউড নেটিভ সিকিউরিটি এমন একটি পদ্ধতি যা [ক্লাউড নেটিভ অ্যাপ্লিকেশন](/bn/cloud-native-apps/) এ নিরাপত্তা তৈরি করে। এটি নিশ্চিত করে যে নিরাপত্তা উন্নয়ন থেকে উৎপাদন পর্যন্ত সমগ্র অ্যাপ্লিকেশন জীবনচক্রের অংশ। ক্লাউড নেটিভ সিকিউরিটি ক্লাউড নেটিভ এনভায়রনমেন্টের বিবরণ, যথা দ্রুত কোড পরিবর্তন এবং অত্যন্ত ক্ষণস্থায়ী অবকাঠামোর সাথে খাপ খাওয়ানোর সময় প্রথাগত নিরাপত্তা মডেলের মতো একই মান নিশ্চিত করতে চায়। ক্লাউড নেটিভ নিরাপত্তা [DevSecOps](/bn/devsecops/) নামক অনুশীলনের সাথে অত্যন্ত সম্পর্কিত। ## এটা যেসব সমস্যাতে দৃষ্টিপাত করে diff --git a/content/bn/cloud-native-tech.md b/content/bn/cloud-native-tech.md index 7885837b86..775e5ce325 100644 --- a/content/bn/cloud-native-tech.md +++ b/content/bn/cloud-native-tech.md @@ -2,11 +2,9 @@ title: ক্লাউড নেটিভ প্রযুক্তি (Cloud Native Technology) status: Completed category: ধারণা -tags: ["fundamental", "", ""] +tags: ["মৌলিক", "", ""] --- -## এটা কি - ক্লাউড নেটিভ টেকনোলজি, ক্লাউড নেটিভ স্ট্যাক হিসেবেও উল্লেখ করা হয়, [ক্লাউড নেটিভ অ্যাপ্লিকেশন](/bn/cloud-native-apps/) তৈরি করতে ব্যবহৃত প্রযুক্তি। সরকারী, প্রাইভেট এবং হাইব্রিড ক্লাউডের মতো আধুনিক, গতিশীল পরিবেশে মাপযোগ্য অ্যাপ্লিকেশনগুলি তৈরি এবং চালানোর জন্য সংস্থাগুলিকে সক্ষম করে, তারা 'ক্লাউডের প্রতিশ্রুতি' বজায় রাখে এবং ক্লাউড কম্পিউটিং সুবিধাগুলি তাদের সম্পূর্ণরূপে লাভ করে। ক্লাউড কম্পিউটিং এবং কন্টেইনার, সার্ভিস মেশ, মাইক্রোসার্ভিসেস এবং অপরিবর্তনীয় অবকাঠামোর ক্ষমতাকে কাজে লাগানোর জন্য গ্রাউন্ড আপ থেকে ডিজাইন করা হয়েছে এই পদ্ধতির উদাহরণ। ## এটা যেসব সমস্যাতে দৃষ্টিপাত করে diff --git a/content/bn/cluster.md b/content/bn/cluster.md index 49c43c53e2..a653bac56d 100644 --- a/content/bn/cluster.md +++ b/content/bn/cluster.md @@ -2,11 +2,9 @@ title: ক্লাস্টার (Cluster) status: Completed category: ধারণা -tags: ["infrastructure", "fundamental", ""] +tags: ["অবকাঠামো", "মৌলিক", ""] --- -## এটা কি - একটি ক্লাস্টার হল কম্পিউটার বা অ্যাপ্লিকেশনগুলির একটি গ্রুপ যা একটি সাধারণ লক্ষ্যে একসাথে কাজ করে। ক্লাউড নেটিভ কম্পিউটিং প্রসঙ্গে, শব্দটি প্রায়শই কুবারনেটে প্রয়োগ করা হয়। একটি Kubernetes ক্লাস্টার হল পরিষেবাগুলির একটি সেট (বা কাজের চাপ) যা তাদের নিজস্ব পাত্রে চলে, সাধারণত বিভিন্ন মেশিনে। এই সমস্ত [কন্টেইনারাইজড(Containerized)](/bn/containerization/) পরিষেবাগুলির সংগ্রহ, একটি নেটওয়ার্কের মাধ্যমে সংযুক্ত, একটি ক্লাস্টার প্রতিনিধিত্ব করে। ## এটা যেসব সমস্যাতে দৃষ্টিপাত করে diff --git a/content/bn/container-image.md b/content/bn/container-image.md index 0f03cac749..5ff6eb9f70 100644 --- a/content/bn/container-image.md +++ b/content/bn/container-image.md @@ -5,8 +5,6 @@ category: ধারণা tags: ["", "", ""] --- -## এটা কি - একটি কন্টেইনার ইমেজ হল একটি অপরিবর্তনীয়, স্ট্যাটিক ফাইল যাতে একটি [কন্টেইনার](/bn/container/) তৈরির নির্ভরতা থাকে। এই নির্ভরতাগুলির মধ্যে একটি একক এক্সিকিউটেবল (single executable) বাইনারি ফাইল, সিস্টেম লাইব্রেরি, সিস্টেম টুলস, এনভায়রনমেন্ট ভেরিয়েবল এবং অন্যান্য প্রয়োজনীয় প্ল্যাটফর্ম সেটিংস অন্তর্ভুক্ত থাকতে পারে। কন্টেইনার ইমেজ একটি অ্যাপ্লিকেশনের [কন্টেইনারাইজেশন](/bn/containerization/) থেকে আসে এবং সাধারণত কন্টেইনার রেজিস্ট্রিতে সংরক্ষণ করা হয়, যেখানে সেগুলি ডাউনলোড করা যায় এবং একটি কন্টেইনার রানটাইম ইন্টারফেস (সিআরআই) ব্যবহার করে একটি বিচ্ছিন্ন প্রক্রিয়া হিসাবে চালানো যায়। একটি কন্টেইনার ইমেজ ফ্রেমওয়ার্ককে অবশ্যই ওপেন কন্টেইনার ইনিশিয়েটিভ (OCI) দ্বারা সংজ্ঞায়িত স্ট্যান্ডার্ড স্কিমা অনুসরণ করতে হবে। ## এটা যেসব সমস্যাতে দৃষ্টিপাত করে diff --git a/content/bn/container-orchestration.md b/content/bn/container-orchestration.md new file mode 100644 index 0000000000..73ca03c628 --- /dev/null +++ b/content/bn/container-orchestration.md @@ -0,0 +1,22 @@ +--- +title: কন্টেইনার অর্কেস্ট্রেশন (Container Orchestration) +status: Completed +category: ধারণা +--- + +[কন্টেইনার](/bn/container/) অর্কেস্ট্রেশন বলতে বোঝায় গতিশীল পরিবেশে কন্টেইনারাইজড অ্যাপ্লিকেশনের জীবনচক্র পরিচালনা এবং স্বয়ংক্রিয়করণ করাকে । +এটি একটি কন্টেইনার অর্কেস্ট্রেটরের (বেশিরভাগ ক্ষেত্রে, [কুবারনেটিস](/bn/kubernetes)) মাধ্যমে কার্যকর করা হয় , যা স্থাপনা (deployments), [অটো-স্কেলিং](/bn/auto-scaling/) , অটো-হিলিং এবং পর্যবেক্ষণকে সক্ষম করে। +অর্কেস্ট্রেশন একটি রূপক অর্থে : +অর্কেস্ট্রেশন টুল একজন মিউজিক পরিচালকের মতো কন্টেইনারগুলোকে পরিচালনা করে, যা নিশ্চিত করে প্রতিটি কন্টেইনারের (বা সঙ্গীতশিল্পীর) যা করা উচিত । + +## এটা যেসব সমস্যাতে দৃষ্টিপাত করে + +সাধারণত বড় স্কেলে [মাইক্রোসার্ভিস](/bn/microservices-architecture/), নিরাপত্তা, এবং নেটওয়ার্ক কমিউনিকেশন পরিচালনা এবং [ডিস্ট্রিবিউটেড সিস্টেমগুলো](/bn/distributed-systems/) (যদি অসম্ভব নাও হয়) ম্যানুয়ালি পরিচালনা করা কঠিন । +কন্টেইনার অর্কেস্ট্রেশন ব্যবহারকারীদের এই সমস্ত পরিচালনার কাজগুলোকে স্বয়ংক্রিয় করতে দেয় । + +## এটা কিভাবে সাহায্য করে + +কন্টেইনার অর্কেস্ট্রেশন টুল ব্যবহারকারীদের একটি সিস্টেমের অবস্থা নির্ধারণ করতে দেয়। +প্রথমে, তারা ঘোষণা করে যে এটি কেমন হওয়া উচিত (যেমন, x কন্টেইনার, y পড, ইত্যাদি)। +অর্কেস্ট্রেশন টুলটি তখন স্বয়ংক্রিয়ভাবে অবকাঠামো পর্যবেক্ষণ করবে এবং যদি এটি তার ঘোষিত অবস্থা থেকে বিচ্যুত হয় তাহলে সংশোধন করবে (যেমন, একটি কন্টেইনার ক্র্যাশ হলে নতুন আরেকটি কন্টেইনার দেওয়া হবে ) । +এই স্বয়ংক্রিয়তা প্রকৌশল দলের অনেকগুলো অত্যন্ত ম্যানুয়াল এবং জটিল অপারেশনাল কাজকে সহজ করে , যার মধ্যে রয়েছে প্রভিশনিং, স্থাপনা, স্কেলিং (উপরে ও নিচে), নেটওয়ার্কিং, লোড ব্যালেন্সিং এবং অন্যান্য কার্যক্রম । diff --git a/content/bn/container.md b/content/bn/container.md index f7ceed0507..f0d169e5ff 100644 --- a/content/bn/container.md +++ b/content/bn/container.md @@ -2,11 +2,9 @@ title: কন্টেইনার (Container) status: Completed category: প্রযুক্তি -tags: ["application", "fundamental", ""] +tags: ["অ্যাপ্লিকেশন", "মৌলিক", ""] --- -## এটা কি - একটি কন্টেইনার একটি কম্পিউটারের অপারেটিং সিস্টেম দ্বারা পরিচালিত সম্পদ এবং সক্ষমতার সীমাবদ্ধতা সহ একটি চলমান প্রক্রিয়া। কন্টেইনার প্রক্রিয়ার জন্য উপলব্ধ ফাইলগুলি একটি কন্টেইনার চিত্র (Container image) হিসাবে প্যাকেজ করা হয়। কনটেইনারগুলি একই মেশিনে একে অপরের সংলগ্ন সঞ্চালিত হয়, তবে সাধারণত অপারেটিং সিস্টেম পৃথক কন্টেইনার প্রক্রিয়াগুলিকে একে অপরের সাথে ইন্টারঅ্যাক্ট করতে বাধা দেয়। ## এটা যেসব সমস্যাতে দৃষ্টিপাত করে @@ -17,4 +15,4 @@ tags: ["application", "fundamental", ""] কনটেইনারগুলি একই অপারেটিং সিস্টেম এবং এর মেশিন সংস্থানগুলি ভাগ করে, অপারেটিং সিস্টেমের সংস্থান ওভারহেড ছড়িয়ে দেয় এবং শারীরিক মেশিনের দক্ষ ব্যবহার তৈরি করে। এই ক্ষমতা শুধুমাত্র সম্ভব কারণ কন্টেইনারগুলি সাধারণত একে অপরের সাথে যোগাযোগ করতে সক্ষম হতে সীমিত। এটি একই শারীরিক মেশিনে আরও অনেক অ্যাপ্লিকেশন চালানোর অনুমতি দেয়। -তবে সীমাবদ্ধতা আছে। যেহেতু কন্টেইনারগুলি একই অপারেটিং সিস্টেম শেয়ার করে, তাই প্রক্রিয়াগুলি বিকল্পগুলির তুলনায় কম নিরাপদ বলে বিবেচিত হতে পারে৷ ধারকদেরও ভাগ করা সম্পদের সীমা প্রয়োজন। সম্পদের নিশ্চয়তা দিতে, প্রশাসকদের অবশ্যই মেমরি এবং সিপিইউ ব্যবহার সীমাবদ্ধ এবং সীমিত করতে হবে যাতে অন্যান্য অ্যাপ্লিকেশনগুলি খারাপভাবে কাজ না করে। \ No newline at end of file +তবে সীমাবদ্ধতা আছে। যেহেতু কন্টেইনারগুলি একই অপারেটিং সিস্টেম শেয়ার করে, তাই প্রক্রিয়াগুলি বিকল্পগুলির তুলনায় কম নিরাপদ বলে বিবেচিত হতে পারে৷ ধারকদেরও ভাগ করা সম্পদের সীমা প্রয়োজন। সম্পদের নিশ্চয়তা দিতে, প্রশাসকদের অবশ্যই মেমরি এবং সিপিইউ ব্যবহার সীমাবদ্ধ এবং সীমিত করতে হবে যাতে অন্যান্য অ্যাপ্লিকেশনগুলি খারাপভাবে কাজ না করে। diff --git a/content/bn/containerization.md b/content/bn/containerization.md index 12ddb7e70e..fc466e6118 100644 --- a/content/bn/containerization.md +++ b/content/bn/containerization.md @@ -2,11 +2,9 @@ title: কন্টেইনারাইজেশন (Containerization) status: Completed category: প্রযুক্তি -tags: ["application", "", ""] +tags: ["অ্যাপ্লিকেশন", "", ""] --- -## এটা কি - কন্টেইনারাইজেশন হল একটি প্রক্রিয়া যা একটি অ্যাপ্লিকেশন এবং এর সংশ্লিষ্ট জিনিসসমূহকে একটি কন্টেইনার ইমেজ (Container Image) এ বান্ডিল করার প্রক্রিয়া। কন্টেইনার নির্মাণ প্রক্রিয়ার জন্য [ওপেন কন্টেইনার ইনিশিয়েটিভ](https://opencontainers.org) (OCI) মান মেনে চলা প্রয়োজন। যতক্ষণ না একটি কন্টেইনার ইমেজ এই স্ট্যান্ডার্ড মেনে চলে, যে কোন কন্টেইনারাইজেশন টুল ই ব্যবহার করা হয় তা চিন্তার বিষয় নয়। ## এটা যেসব সমস্যাতে দৃষ্টিপাত করে diff --git a/content/bn/containers-as-a-service.md b/content/bn/containers-as-a-service.md index 1cf27057b8..17ee4258c1 100644 --- a/content/bn/containers-as-a-service.md +++ b/content/bn/containers-as-a-service.md @@ -2,11 +2,9 @@ title: কন্টেইনার এজ এ সার্ভিস (Containers as a Service) status: Deprecated category: প্রযুক্তি -tags: ["platform", "", ""] +tags: ["প্ল্যাটফর্ম", "", ""] --- -## এটা কি - কন্টেইনার এজ এ সার্ভিস (CaaS) হল একটি ক্লাউড পরিষেবা যা অ্যাপগুলি পরিচালনা এবং স্থাপনে সহায়তা করে [ধারক](/bn/container/)-ভিত্তিক [বিমূর্ততা](/bn/abstraction) ব্যবহার করে। এই পরিষেবাটি প্রাঙ্গনে(on-premises) বা ক্লাউডে স্থাপন করা যেতে পারে। diff --git a/content/bn/continuous-delivery.md b/content/bn/continuous-delivery.md index 162cdb2df5..9975604380 100644 --- a/content/bn/continuous-delivery.md +++ b/content/bn/continuous-delivery.md @@ -2,11 +2,9 @@ title: ক্রমাগত বিতরণ (Continuous Delivery) (CD) status: Completed category: ধারণা -tags: ["methodology", "application", ""] +tags: ["পদ্ধতি", "অ্যাপ্লিকেশন", ""] --- -## এটা কি - ক্রমাগত বিতরণ (continuous delivery), প্রায়ই CD হিসাবে সংক্ষিপ্ত, অনুশীলনের একটি সেট যেখানে কোডের পরিবর্তনগুলি স্বয়ংক্রিয়ভাবে একটি গ্রহণযোগ্য পরিবেশে স্থাপন করা হয় (অথবা, ক্রমাগত স্থাপনার (continuous deployment) ক্ষেত্রে, উৎপাদনে)। স্থাপনার (deployment) আগে সফ্টওয়্যারটি (software) পর্যাপ্তভাবে পরীক্ষা করা হয়েছে তা নিশ্চিত করার জন্য CD অত্যন্ত গুরুত্বপূর্ণভাবে প্রক্রিয়াগুলি অন্তর্ভুক্ত করে এবং প্রয়োজন মনে হলে পরিবর্তনগুলি রোলব্যাক (rollback) করার একটি উপায় প্রদান করে। ক্রমাগত একীকরণ (continuous integration) (CI) ক্রমাগত বিতরণের (continuous delivery) প্রথম পদক্ষেপ diff --git a/content/bn/continuous-deployment.md b/content/bn/continuous-deployment.md index 91aa57af1e..fb41b82799 100644 --- a/content/bn/continuous-deployment.md +++ b/content/bn/continuous-deployment.md @@ -2,11 +2,9 @@ title: ক্রমাগত স্থাপনা (Continuous Deployment (CD)) status: Completed category: ধারণা -tags: ["application", "methodology", ""] +tags: ["অ্যাপ্লিকেশন", "পদ্ধতি", ""] --- -## এটা কি - ক্রমাগত স্থাপনা (Continuous Deployment), প্রায়ই CD হিসাবে সংক্ষেপে, সরাসরি উৎপাদনে সমাপ্ত সফ্টওয়্যার (software) স্থাপনের মাধ্যমে [ক্রমাগত বিতরণ (Continuous Delivery)](/bn/continuous-delivery/) থেকে এক ধাপ এগিয়ে যায়। ক্রমাগত স্থাপনা (CD) [ক্রমাগত একীকরণ (Continuous Integration)](/bn/continuous-integration/) (CI) এর সাথে হাত মিলিয়ে যায় এবং প্রায়ই CI/CD হিসাবে উল্লেখ করা হয়। একটি প্রদত্ত অ্যাপ্লিকেশনে পরিবর্তনগুলি বৈধ কিনা তা CI প্রক্রিয়া পরীক্ষা করে এবং CD প্রক্রিয়া স্বয়ংক্রিয়ভাবে একটি প্রতিষ্ঠানের পরিবেশের মাধ্যমে পরীক্ষা থেকে উৎপাদন পর্যন্ত কোডের পরিবর্তনগুলি স্থাপন করে। diff --git a/content/bn/continuous-integration.md b/content/bn/continuous-integration.md index 725918ff0b..ac9e578eb4 100644 --- a/content/bn/continuous-integration.md +++ b/content/bn/continuous-integration.md @@ -2,11 +2,9 @@ title: ক্রমাগত একীকরণ (Continuous Integration) (CI) status: Completed category: ধারণা -tags: ["application", "methodology", ""] +tags: ["অ্যাপ্লিকেশন", "পদ্ধতি", ""] --- -## এটা কি - ক্রমাগত একীকরণ (Continuous integration), প্রায়ই CI হিসাবে সংক্ষেপে, যতটা সম্ভব নিয়মিত কোড পরিবর্তনগুলিকে একীভূত করার অনুশীলন। CI হল [ক্রমাগত বিতরণ (Continuous Delivery)](/bn/continuous-delivery/) (CD) এর পূর্বশর্ত। ঐতিহ্যগতভাবে, CI প্রক্রিয়া শুরু হয় যখন কোড পরিবর্তনগুলি একটি উৎস নিয়ন্ত্রণ ব্যবস্থার (Git, Mercurial, বা Subversion) প্রতি প্রতিশ্রুতিবদ্ধ হয় এবং একটি CD সিস্টেমের দ্বারা গ্রাস করার জন্য প্রস্তুত একটি পরীক্ষিত আর্টিফ্যাক্ট দিয়ে শেষ হয়। diff --git a/content/bn/contribute/_index.md b/content/bn/contribute/_index.md index 1ace3aba8e..c59ec4bc71 100644 --- a/content/bn/contribute/_index.md +++ b/content/bn/contribute/_index.md @@ -7,125 +7,219 @@ menu: weight: 10 --- -ক্লাউড নেটিভ শব্দকোষের(glossary) সমস্ত বিষয়বস্তু এই Github Repo সংরক্ষণ করা হয়েছে। আপনি সেখানে [issues](https://github.com/cncf/glossary/issues), [PRs](https://github.com/cncf/glossary/pulls) এবং শব্দকোষ(glossary) সম্পর্কে [আলোচনার](https://github.com/cncf/glossary/discussions) একটি তালিকা পাবেন। +## স্বাগত -তিনটি উপায়ে আপনি অবদান রাখতে পারেন: +ক্লাউড নেটিভ শব্দকোষ অবদানকারী গাইডে স্বাগতম, এবং আপনার আগ্রহের জন্য আপনাকে ধন্যবাদ। +আপনি এই প্রকল্পে অবদান রাখতে পারেন এমন অনেক উপায় রয়েছে, যা আমরা এখানে বিস্তারিতভাবে কভার করব: -1) [একটি বিদ্যমান সমস্যা নিয়ে কাজ করুন](#work-on-an-existing-issue) -2) [নতুন শর্তাদি প্রস্তাব করুন](#propose-new-terms) +1) [বিদ্যমান সমস্যা নিয়ে কাজ করুন](#work-on-an-existing-issue) +2) [নতুন শর্তাবলী প্রস্তাব](#propose-new-terms) 3) [বিদ্যমানগুলি আপডেট করুন](#update-an-existing-term) -4) [শব্দকোষ অনুবাদে সাহায্য করুন](#help-translate-the-glossary) +4) [শব্দকোষ অনুবাদে সাহায্য করুন](#help-localize-the-glossary) + +## CNCF শব্দকোষ ওভারভিউ + +এই শব্দকোষের লক্ষ্য হল ক্লাউড নেটিভ স্পেসকে সহজ করা — যা এর জটিলতার জন্য কুখ্যাত — এবং এইভাবে এটিকে মানুষের কাছে আরও সহজগম্য করে তোলা। + +ক্লাউড নেটিভ শব্দকোষের বিষয়বস্তু [এই GitHub repo](https://github.com/cncf/glossary) সংরক্ষণ করা হয় +যেখানে আপনি [সমস্যার](https://github.com/cncf/glossary/issues) একটি তালিকা পাবেন, অনুরোধের ([PRs](https://github.com/cncf/glossary/pulls)) +এবং শব্দকোষ সম্পর্কে [আলোচনা](https://github.com/cncf/glossary/discussions) পাবেন। + +## কে অবদান রাখতে পারেন? + +আপনি কীভাবে এই প্রকল্পে অংশগ্রহণ করতে পারেন তা নির্ভর করে আপনার ক্লাউড নেটিভ দক্ষতার স্তরের উপর। +জটিল ধারণাগুলি সরলীকরণের জন্য বিষয়টির গভীর জ্ঞান প্রয়োজন। +অতএব, নতুন শর্তাবলী অবদান রাখতে, আপনাকে অবশ্যই সেগুলিতে দক্ষ হতে হবে। +অবদানকারীরা সাধারণত প্রকৌশলী যারা কিছু সময়ের জন্য এই প্রযুক্তিগুলির সাথে কাজ করেছেন বা শিক্ষাবিদ যারা ক্লাউড নেটিভের উপর মনোনিবেশ করেন। + +এই জ্ঞানের প্রয়োজন কারণ জটিল ধারণাগুলিকে সহজ শব্দে ব্যাখ্যা করা সত্যিই_ কঠিন। এবং যদিও হজমযোগ্য, ব্যবহারকারী-বান্ধব ফলাফল সহজ বলে মনে হতে পারে, ক্লাউড নেটিভ বিশেষজ্ঞদের মধ্যে কঠোর পরিশ্রম এবং সহযোগিতার মাধ্যমে কাঙ্ক্ষিত সহজ ফলাফল অর্জন করা। + +আপনি যদি ক্লাউড-নেটিভ বিশেষজ্ঞ না হন তাও অবদান রাখতে চান, তাহলে আমরা একজন বিশেষজ্ঞের সাথে টিম আপ করার পরামর্শ দিই। +একবার বিশেষজ্ঞ আত্মবিশ্বাসী হন যে শব্দটি সঠিকভাবে ধারণাটিকে বর্ণনা করে, তাহলে আপনি আপনার প্রথম শব্দকোষ অবদানের জন্য প্রস্তুত। + +স্থানীয়করণের প্রচেষ্টা হল যেখানে অন্য ভাষায় দক্ষ নতুনরা শব্দকোষে মূল্যবান অবদান রাখতে পারে। +ইংরেজিতে বিদ্যমান দৃঢ় সংজ্ঞা সহ, কম অভিজ্ঞ অবদানকারীরা একটি টার্গেট ভাষায় স্থানীয়করণ করতে পারেন। আপনি একটি বিদ্যমান স্থানীয়করণ দলে যোগ দিতে পারেন বা একটি নতুন দল তৈরি করতে পারেন৷ কিভাবে শুরু করবেন তা জানতে এই গাইডের [শব্দকোষ স্থানীয়করণে সাহায্য করুন](#help-localize-the-glossary) বিভাগটি পড়ুন। + +## শুরু করার আগে + +আপনার শব্দকোষ অবদানকারীর যাত্রা শুরু করার আগে, নিম্নলিখিত পদক্ষেপগুলি সম্পূর্ণ করতে ভুলবেন না: + +1. একটি [GitHub অ্যাকাউন্ট](https://docs.github.com/en/get-started/signing-up-for-github/signing-up-for-a-new-github-account) তৈরি করুন, যদি আপনি ইতিমধ্যে না থাকে। +2. [কন্ট্রিবিউটর লাইসেন্স চুক্তিতে](https://docs.linuxfoundation.org/lfx/easycla/v2-current/contributors) (CLA) স্বাক্ষর করুন। +3. [আপনার প্রতিশ্রুতি স্বাক্ষর যাচাই করুন](https://docs.github.com/en/authentication/managing-commit-signature-verification/about-commit-signature-verification) +4. [সতর্ক মোড] সক্ষম করুন(https://docs.github.com/en/authentication/managing-commit-signature-verification/displaying-verification-statuses-for-all-of-your-commits#about-vigilant-mode) আপনার প্রতিশ্রুতিতে "যাচাইকৃত" স্থিতি প্রদর্শন করতে আপনার GitHub অ্যাকাউন্টে। + +## সর্বোত্তম অনুশীলন {#best-practices} + +পর্যালোচনা প্রক্রিয়া সহজতর করার জন্য, অনুগ্রহ করে [অর্থবোধক লাইন বিরতি](https://sembr.org/) ব্যবহার করুন (যেমন, প্রতি বাক্যে এক লাইন)। +আমরা এই [মার্কডাউন চিট শীট](https://www.markdownguide.org/cheat-sheet/) চেক করার পরামর্শ দিই +GitHub-এ মার্কডাউন টেক্সট সঠিকভাবে ফরম্যাট করতে (যেমন, হাইপারলিঙ্ক, বোল্ড, ইটালিক)। +এবং .md ফাইলের নামকরণ করার সময়, শব্দগুলিকে আলাদা করতে এবং বন্ধনী এড়াতে স্পেসের পরিবর্তে অনুগ্রহ করে ছোট হাতের অক্ষর এবং হাইফেন ব্যবহার করুন। + +## স্টাইল গাইড + +নথি বিন্যাস এবং লেখার জন্য আমাদের নির্দেশিকা বুঝতে এবং অবদান প্রক্রিয়াকে আরও দক্ষ করে তুলতে আমাদের [স্টাইল নির্দেশিকা](/bn/style-guide/) পড়ুন। ## শব্দকোষ সম্প্রদায়ে যোগ দিন! {#join-the-glossary-community} -আপনি যদি নিয়মিত অবদান রাখতে চান তবে আমাদের মাসিক শব্দকোষ ওয়ার্কিং গ্রুপ মিটিংয়ে যোগদানের কথা বিবেচনা করুন। আপনি [CNCF ক্যালেন্ডার](https://www.cncf.io/calendar/) এ মিটিংয়ের বিশদ বিবরণ পেতে পারেন। এছাড়াও আপনি CNCF Slack-এ আমাদের [#glossary](https://cloud-native.slack.com/archives/C02TX20MQBB) চ্যানেলে রক্ষণাবেক্ষণকারী এবং সহযোগী অবদানকারীদের সাথে সংযোগ করতে পারেন — আমরা আপনার সাথে দেখা করতে চাই! +আপনি যদি নিয়মিত অবদান রাখতে চান তবে আমাদের মাসিক শব্দকোষ ওয়ার্কিং গ্রুপ মিটিংয়ে যোগদানের কথা বিবেচনা করুন। +আপনি [CNCF ক্যালেন্ডার](https://www.cncf.io/calendar/) এ মিটিংয়ের বিশদ বিবরণ পাবেন। +এছাড়াও আপনি CNCF স্ল্যাকে (slack) আমাদের [#glossary](https://cloud-native.slack.com/archives/C02TX20MQBB) চ্যানেলে রক্ষণাবেক্ষণকারী এবং সহযোগী অবদানকারীদের সাথে সংযোগ করতে পারেন +— আমরা আপনার সাথে দেখা করতে চাই! + +## বিদ্যমান সমস্যা নিয়ে কাজ করুন {#work-on-an-existing-issue} + +উপলব্ধ সমস্যাগুলির একটি তালিকা খুঁজতে [Glossary GitHub repo issue](https://github.com/cncf/glossary/issues) এ যান। +সমস্যাগুলি ফিল্টার করতে আপনি লেবেলগুলি (labels) ব্যবহার করতে পারেন (যেমন, ইংরেজি ভাষা (English language), সাহায্যের প্রয়োজন (help needed), ভাল প্রথম সমস্যা (good first issue))। -## একটি বিদ্যমান সমস্যা নিয়ে কাজ করুন {#work-on-an-existing-issue} +![সমস্যা এবং লেবেল](/images/how-to/issue-and-labels.png) -[Glossary GitHub repository issues](https://github.com/cncf/glossary/issues) এ যান। সেখানে আপনি সমস্ত সমস্যার একটি তালিকা দেখতে পাবেন। আপনি লেবেল দ্বারা ফিল্টার করতে পারেন (যেমন বাংলা ভাষা, সাহায্যের প্রয়োজন(help needed), প্রথম ভাল সমস্যা(good first issue)। মনে রাখবেন যে এটি করার জন্য আপনার একটি GitHub অ্যাকাউন্টের প্রয়োজন হবে। +নিশ্চিত করুন যে আপনি যে শব্দটি নির্বাচন করেছেন তা ইতিমধ্যে কাউকে বরাদ্দ করা হয়নি। +উদাহরণস্বরূপ, এখানে আপনি দেখতে পাচ্ছেন যে প্রথম তিনটি পদ উপলব্ধ রয়েছে যখন চতুর্থটি ইতিমধ্যেই বরাদ্দ করা হয়েছে৷ -![ইস্যু এবং লেবেল](/images/how-to/issue-and-labels.png) +![একটি মেয়াদ নির্ধারণ](/images/how-to/howto-04.png) -নিশ্চিত করুন যে আপনি যে পদ/শব্দটিতে আগ্রহী তা ইতিমধ্যেই কাউকে বরাদ্দ করা হয়নি। এখানে আপনি দেখতে পাচ্ছেন যে প্রথম তিনটি পদ/শব্দ উপলব্ধ রয়েছে যখন পরবর্তী মেয়াদ ইতিমধ্যেই বরাদ্দ করা হয়েছে৷ +একবার আপনি কাজ করার জন্য একটি শব্দ নির্বাচন করলে, সমস্যাটির বিষয়ে মন্তব্য করুন। -![একটি শব্দ বরাদ্দ করা](/images/how-to/howto-04.png) +![একটি সমস্যা দাবি করা](/images/how-to/claiming-an-issue.png) -একবার আপনি এমন একটি শব্দ খুঁজে পেলেন যেটিতে আপনি কাজ করতে চান, ইস্যুতে(issue) বলুন। এটি ক্লিক করুন এবং একটি মন্তব্য যোগ করুন. +উপরন্তু, CNCF স্ল্যাক (slack) ওয়ার্কস্পেসের (workspace) [#glossary](https://cloud-native.slack.com/archives/C02TX20MQBB) চ্যানেলে রক্ষণাবেক্ষণকারীদের অবহিত করুন এবং +ট্যাগ করুন _@iamnoah_, _@nate-double-u_, _@Seokho Son_, _@Jihoon Seo_, এবং/অথবা _@castrojo_ যাতে তারা এটি মিস না করে। -![একটি সমস্যা(issue) দাবি করা](/images/how-to/claiming-an-issue.png) +পরবর্তী পদক্ষেপের জন্য, অনুগ্রহ করে [একটি নতুন শব্দ জমা দেওয়া (একটি PR তৈরি করুন)](#submitting-a-new-term) বিভাগটি পড়ুন। -এছাড়াও, অনুগ্রহ করে CNCF Slack-এর [#glossary](https://cloud-native.slack.com/archives/C02TX20MQBB) চ্যানেলে যোগ দিন এবং রক্ষণাবেক্ষণকারীদের জানান যে আপনি একটি নতুন শব্দের জন্য একটি সমস্যা উত্থাপন করেছেন (আদর্শভাবে) , ট্যাগ করুন _@Catherine Paganini_, _@jmo_, _@Seokho Son_, _@Jihoon Seo_, এবং/অথবা _@iamnoah_ যাতে তারা এটি মিস না করে)। মনে রাখবেন যে আপনি একবারে শুধুমাত্র একটি মেয়াদ দাবি করতে পারেন। আপনি যদি একাধিক শর্তে কাজ করতে চান, অনুগ্রহ করে পরেরটি দাবি করার আগে একটি শেষ করুন। +**দ্রষ্টব্য**: রক্ষণাবেক্ষণকারীরা আপনাকে এটি বরাদ্দ করার পরে আপনি একটি সমস্যা নিয়ে কাজ শুরু করতে পারেন। +আপনি একটি সময়ে শুধুমাত্র একটি শব্দ দাবি করতে পারবেন. +ক্রমিক ভাবে একাধিক শব্দে কাজ করার জন্য, পরেরটি দাবি করার আগে আপনাকে অবশ্যই একটি শব্দ সম্পূর্ণ করতে হবে। -একবার তারা এটি আপনাকে বরাদ্দ করলে, আপনি এটিতে কাজ শুরু করতে পারেন। পরবর্তী ধাপগুলির জন্য, অনুগ্রহ করে [একটি নতুন শব্দ জমা দেওয়া (একটি পিআর তৈরি করা)](#submitting-a-new-term) বিভাগটি পড়ুন। +## প্রপস-এ নতুন শব্দ {#propose-new-terms} -## নতুন শর্তাবলী প্রস্তাব করুন {#propose-new-terms} +আপনি অন্যদের জন্য একটি নতুন শব্দ প্রস্তাব করতে পারেন বা নিজে একটি নতুন সংজ্ঞা তৈরি করতে পারেন৷ +যেভাবেই হোক, আপনি শুরু করবেন [একটি সমস্যা তৈরি করে](#creating-an-issue)। +শব্দকোষে যোগ করার জন্য, প্রতিটি নতুন শব্দ অবশ্যই [CNCF এর ক্লাউড নেটিভ সংজ্ঞা](https://github.com/cncf/toc/blob/main/DEFINITION.md) পূরণ করতে হবে। +শুধুমাত্র ব্যতিক্রমগুলি হল ক্লাউড নেটিভ ধারণাগুলি বোঝার জন্য প্রয়োজনীয় মৌলিক পদ। -আপনি অন্যদের জন্য একটি নতুন শব্দ প্রস্তাব করতে পারেন বা নিজে একটি নতুন সংজ্ঞা তৈরি করতে পারেন৷ যেভাবেই হোক, আপনি একটি সমস্যা তৈরি করে শুরু করবেন। +নীচে গিটহাবের সাথে অপরিচিত লোকেদের জন্য একটি ধাপে ধাপে নির্দেশিকা রয়েছে৷ +**যদি আপনি একজন GitHub Pro** হন, তাহলে অনুগ্রহ করে নিম্নলিখিত বিষয়গুলি সম্পর্কে যথেষ্ট তথ্য সংগ্রহ করতে এই নির্দেশিকাটি স্ক্যান করুন: -যারা এখনও GitHub এর সাথে পরিচিত নন তাদের জন্য নীচে একটি ধাপে ধাপে নির্দেশিকা। **আপনি যদি একজন GitHub Pro** হন, তাহলে অনুগ্রহ করে _করুন_ যাতে আপনি আমাদের ইস্যু টেমপ্লেট, উপযুক্ত নামকরণ প্রথা ব্যবহার করেন, স্ল্যাকের উপর একটি পিআর দাবি করেন (অন্যথায় আমরা এটি মিস করতে পারি), এবং কোথায় পাবেন তা নিশ্চিত করতে দ্রুত দেখুন ফাইল টেমপ্লেট। এবং অনুগ্রহ করে শুরু করার আগে [স্টাইল গাইড](/bn/style-guide/) পড়া নিশ্চিত করুন — ধন্যবাদ! +1. সমস্যা এবং নতুন পদগুলির জন্য টেমপ্লেটগুলি সনাক্ত করা৷ +2. দাবি সংক্রান্ত সমস্যা। +3. [বানান পরীক্ষা](#spell-check) ব্যর্থতা সমাধান করা৷ ### একটি সমস্যা তৈরি করা {#creating-an-issue} [Glossary GitHub repo](https://github.com/cncf/glossary/issues) সমস্যাগুলিতে যান এবং "নতুন সমস্যা" এ ক্লিক করুন। -![সমস্যা(issues)](/images/how-to/howto-01.png) +![সমস্যা (issues)](/images/how-to/howto-01.png) -আপনি বিভিন্ন ধরনের টেমপ্লেট দেখতে পাবেন। ইংরেজিতে একটি নতুন শব্দ প্রস্তাব করতে, "একটি নতুন শব্দ যোগ করার অনুরোধ (ডিফল্ট: ইংরেজি) নির্বাচন করুন৷ +টেমপ্লেটের তালিকা থেকে "একটি নতুন শব্দ (ইংরেজি) যোগ করার অনুরোধ" নির্বাচন করুন। -![টেমপ্লেট(template)](/images/how-to/english-issue-template-new.png) +![টেমপ্লেট](/images/how-to/english-issue-template.jpg) -আপনি যে শব্দটি প্রস্তাব করছেন তা যোগ করুন, নীচের দুটি প্রশ্নের উত্তর দিন এবং "নতুন সমস্যা জমা দিন" টিপুন। আপনি যদি শুধু একটি নতুন শব্দ প্রস্তাব করেন, আপনি সম্পন্ন! এটিতে কাজ করতে, পরবর্তী পদক্ষেপগুলি অনুসরণ করুন৷ +আপনি যে শব্দটি প্রস্তাব করছেন তা যোগ করুন, প্রশ্নের উত্তর দিন, বাক্সে টিক চিহ্ন দিন এবং "নতুন সমস্যা জমা দিন (Submit new issue)" টিপুন। +আপনি যদি শুধুমাত্র একটি নতুন শব্দ প্রস্তাব করছেন, আপনি সম্পন্ন! আপনি যদি সংজ্ঞা নিয়ে কাজ করতে চান তবে পড়তে থাকুন। -### আপনার সমস্যা এর পরবর্তী ধাপ {#triaging-your-issue} +### আপনার সমস্যা triaging {#triaging-your-issue} -এর পরে, রক্ষণাবেক্ষণকারীরা সমস্যাটি সমাধান করবে। এর অর্থ হল শব্দটি শব্দকোষের অংশ হওয়া উচিত কিনা তা তারা মূল্যায়ন করবে (দ্রষ্টব্য, প্রতিটি পদকে সংযুক্ত করা হবে না। শর্তাবলী প্রতিষ্ঠিত হওয়া উচিত এবং ব্যাপকভাবে ব্যবহৃত ক্লাউড নেটিভ টার্মস)। +এর পরে, রক্ষণাবেক্ষণকারীরা সমস্যাটি সমাধান করবে। +এর মানে তারা মূল্যায়ন করবে যে শব্দটি শব্দকোষের অংশ হওয়া উচিত কিনা। +প্রতিটি পদে ভর্তি হবে না। শব্দকোষে অন্তর্ভুক্ত করার জন্য, সেগুলিকে প্রতিষ্ঠিত করতে হবে এবং ব্যাপকভাবে ব্যবহৃত ক্লাউড নেটিভ ধারণাগুলি ব্যবহার করতে হবে৷ -অনুগ্রহ করে রক্ষণাবেক্ষণকারীদের জানান যে আপনি স্ল্যাকে একটি মেয়াদ জমা দিয়েছেন কারণ তারা অন্যথায় এটি মিস করতে পারে। আদর্শভাবে, ট্যাগ করুন _@Catherine Paganini_, _@jmo_, _@Seokho Son_, _@Jihoon Seo_ অথবা _@iamnoah_। যদি শব্দটি অনুমোদিত হয় এবং আপনি এটিতে কাজ করতে চান তবে তারা এটি আপনাকে বরাদ্দ করবে। - -মনে রাখবেন যে আপনি একবারে শুধুমাত্র একটি মেয়াদ দাবি করতে পারেন। আপনি যদি একাধিক শর্তে কাজ করতে চান, অনুগ্রহ করে পরেরটি দাবি করার আগে একটি শেষ করুন। +অনুগ্রহ করে রক্ষণাবেক্ষণকারীদের স্ল্যাক (slack) এ জানান এবং ট্যাগ (tag) করুন _@iamnoah_, _@nate-double-u_, _@Seokho Son_, _@Jihoon Seo_, এবং _@castrojo_ যে একটি নতুন শব্দ প্রস্তাব করেছেন যাতে তারা এটা মিস না করে। +আপনি যদি সংজ্ঞা নিয়ে কাজ করতে চান তবে রক্ষণাবেক্ষণকারীদের জানান এবং তারা এটি আপনাকে বরাদ্দ করবে। ### একটি নতুন পদ জমা দেওয়া (একটি PR তৈরি করা) {#submitting-a-new-term} -শুরু করার আগে, অনুগ্রহ করে [শৈলী নির্দেশিকা](/bn/style-guide/) পড়ুন — এটি পিছনে এবং পিছনে ছোট করতে সাহায্য করবে। শৈলী নির্দেশিকাতে যেমন বলা হয়েছে, আমরা একটি Google বা Word ডক দিয়ে শুরু করার সুপারিশ করি। +আমাদের [শৈলী নির্দেশিকা](/bn/style-guide/) এ যেমন বলা হয়েছে, আমরা একটি Google বা Word ডক দিয়ে শুরু করার সুপারিশ করি। -শব্দটি জমা দেওয়ার জন্য প্রস্তুত হয়ে গেলে, সামগ্রীতে যান (কোডের অধীনে)… +শব্দটি জমা দেওয়ার জন্য প্রস্তুত হয়ে গেলে, সামগ্রীতে যান (<>কোডের অধীনে)… -![content](/images/how-to/howto-05.png) +![বিষয়বস্তু](/images/how-to/howto-05.png) -…তারপর "en" (বা আপনি যে ভাষার জন্য জমা দিচ্ছেন)… +…তারপর "en" (ইংরেজির জন্য) অথবা আপনি যে ভাষার জন্য অবদান রাখছেন তার প্রথম দুটি অক্ষর... ![ভাষা ফোল্ডার](/images/how-to/howto-06.png) -…এবং _TEMPLATE.md নির্বাচন করুন +…এবং `_TEMPLATE.md` নির্বাচন করুন -![টেমপ্লেট](/images/how-to/howto-07.png) +![টেমপ্লেট (template)](/images/how-to/howto-07.png) কন্টেন্ট কপি করুন... ![কন্টেন্ট কপি](/images/how-to/howto-08.png) -…এবং "en" ফোল্ডারে ফিরে যান। "ফাইল যোগ করুন" টিপুন এবং "নতুন ফাইল তৈরি করুন" নির্বাচন করুন। +…এবং "en" ফোল্ডারে ফিরে যান। "ফাইল যোগ করুন (Add file)" ক্লিক করুন এবং "নতুন ফাইল তৈরি করুন (Create new file)" নির্বাচন করুন। ![নতুন ফাইল তৈরি করুন](/images/how-to/howto-09.png) -URL-এ শব্দের নাম যোগ করুন (কোনও ক্যাপিটালাইজেশন এবং স্পেস নেই) এবং শেষে .md (দ্রষ্টব্য: যদি আপনার পূর্বরূপ কাজ না করে, আপনি সম্ভবত শেষে .md যোগ করতে ভুলে গেছেন)। এখন নিচের টেমপ্লেট কন্টেন্ট পেস্ট করুন। ফাইলটিতে আপনার সংজ্ঞাটি অনুলিপি করুন এবং পেস্ট করুন। মনে রাখবেন GitHub টেক্সট ফরম্যাট করতে মার্কডাউন ব্যবহার করে (যেমন, হাইপারলিঙ্ক, বোল্ড, ইটালিক)। অনুগ্রহ করে এই [মার্কডাউন চিট শীট](https://www.markdownguide.org/cheat-sheet/) দেখুন। আপনি যেভাবে মার্কডাউন ব্যবহার করেছেন তা যাচাই করতে, "প্রিভিউ" এ যান। +[সর্বোত্তম অনুশীলন](#best-practices) বিভাগে বর্ণিত URL-এ শব্দটির নাম যোগ করুন। +নামের শেষে .md এক্সটেনশন যোগ করুন (এই এক্সটেনশনটি ছাড়া আপনি আপনার ফাইলের পূর্বরূপ দেখতে পারবেন না)। +এখন নীচের বিভাগে টেমপ্লেট সামগ্রী পেস্ট করুন। ফাইলটিতে আপনার সংজ্ঞার পাঠ্যটি অনুলিপি করুন এবং পেস্ট করুন। +আপনি [সর্বোত্তম অনুশীলন](#best-practices) বিভাগে বর্ণিত মার্কডাউন ব্যবহার করেছেন তা যাচাই করতে, "প্রিভিউ (Preview)" এ ক্লিক করুন। -![চূড়ান্ত মেয়াদ](/images/how-to/howto-10.png) +![শব্দ চূড়ান্ত করা](/images/how-to/howto-10.png) -আপনি যখন জমা দিতে প্রস্তুত তখন নিচে স্ক্রোল করুন এবং নতুন কমিট ফাইলের নাম দিন। আপনি এখন আপনার নিজের শাখায় শব্দটি কমিট করতে চলেছেন। একটি PR জমা দেওয়ার জন্য আরও একটি ধাপ প্রয়োজন৷ "নতুন ফাইল কমিট" টিপুন এবং... +নিচে স্ক্রোল করুন এবং নতুন কমিট ফাইলের নাম দিন। আপনি যখন জমা দিতে প্রস্তুত তখন "নতুন ফাইল কমিট করুন (Commit new file)" টিপুন +এবং… -![নতুন ফাইল কমিট](/images/how-to/howto-11.png) +![নতুন ফাইল কমিট (commit new file)](/images/how-to/howto-11.png) -…এখন আপনি একটি PR তৈরি করছেন: +… আপনি এখন একটি নতুন PR তৈরি করতে প্রস্তুত: -![একটি PR তৈরি করুন](/images/how-to/howto-12.png) +![একটি pr তৈরি করুন](/images/how-to/howto-12.png) -আপনার এখন "পুল রিকোয়েস্ট" এর অধীনে আপনার PR দেখতে হবে। +একবার আপনি "পুল রিকোয়েস্ট তৈরি করুন (Create pull request)" বোতাম টিপলে আপনার পিআর "পুল রিকোয়েস্ট (Pull requests)" ট্যাবে দৃশ্যমান হবে। -![prs](/images/how-to/howto-13.png) +![PRs](/images/how-to/howto-13.png) -## একটি বিদ্যমান টার্ম আপডেট করুন {#update-an-existing-term} +## একটি বিদ্যমান শব্দ আপডেট করুন {#update-an-existing-term} -একটি বিদ্যমান শব্দ আপডেট করতে, আপনি হয় একটি সমস্যার মাধ্যমে একটি পরিবর্তনের পরামর্শ দিতে পারেন বা এগিয়ে যান এবং একটি পুল অনুরোধ (PR) জমা দিয়ে সরাসরি শব্দটি আপডেট করতে পারেন৷ +একটি বিদ্যমান শব্দ আপডেট করতে, আপনি একটি সমস্যা তৈরি করে পরিবর্তনের অনুরোধ করতে পারেন +অথবা পরিবর্তনগুলি নিজে কাজ করুন এবং একটি PR জমা দিন। -### একটি সমস্যার মাধ্যমে একটি পরিবর্তনের অনুরোধ করুন {#request-a-change-via-an-issue} +### একটি সমস্যা (issue) মাধ্যমে একটি পরিবর্তন অনুরোধ {#request-a-change-via-an-issue} -আপনি যদি একটি শব্দের সাথে একটি সমস্যা ফ্ল্যাগ করতে চান কিন্তু কীভাবে এটি নিজেই ঠিক করতে চান না জানেন, তাহলে "সমস্যা প্রতিবেদন করুন" এ ক্লিক করুন৷ +আপনি যদি একটি শব্দের সাথে একটি সমস্যা ফ্ল্যাগ করতে চান, আপনি CNCF শব্দকোষ ওয়েবপৃষ্ঠার "ইস্যু রিপোর্ট করুন (Report issue)" বিকল্পটি ব্যবহার করতে পারেন। +আপনি যে ধারণাটি পতাকাঙ্কিত করতে চান তার CNCF পৃষ্ঠায় নিজেকে সনাক্ত করুন এবং "ইস্যু রিপোর্ট করুন (Report issue)" এ ক্লিক করুন। +এটি স্বয়ংক্রিয়ভাবে আপনার জন্য একটি সমস্যা খুলবে -![রিপোর্ট সমস্যা](/images/how-to/howto-14.png) +![রিপোর্ট সমস্যা (Report issue)](/images/how-to/howto-14.png) -এটি সরাসরি একটি সমস্যা খুলবে। কোন পরিবর্তন প্রয়োজন এবং কেন তা বিস্তারিতভাবে বলুন। জমা দিন, এবং যে এটা. +আপনার পরামর্শ বর্ণনা করুন এবং কেন তারা প্রয়োজন. জমা দিন, এবং যে এটি। -![সমস্যার জমা দিন](/images/how-to/howto-15.png) +![সমস্যা জমা দিন (submit issue)](/images/how-to/howto-15.png) -### একটি টার্ম সরাসরি আপডেট করুন {#update-a-term-directly} +### সরাসরি একটি শব্দ আপডেট করুন {#update-a-term-directly} -একটি শব্দ সরাসরি পরিবর্তন করতে, "এই পৃষ্ঠাটি সম্পাদনা করুন" এ যান। +একটি শব্দ সংশোধন করতে এবং আপনার পরামর্শ জমা দিতে, "এই পৃষ্ঠাটি সম্পাদনা করুন (Edit this page)" এ ক্লিক করুন। ![এই পৃষ্ঠাটি সম্পাদনা করুন](/images/how-to/howto-16.png) -এটি শব্দের GitHub পৃষ্ঠা খুলবে। আপনার পরিবর্তন করুন এবং একটি পিআর জমা দিন। বিশদ বিবরণের জন্য অনুগ্রহ করে উপরে "একটি নতুন শব্দ জমা দেওয়া" দেখুন (মার্কডাউন সম্পর্কে কথা বলা বিভাগে যান)। +এটি শব্দের GitHub পৃষ্ঠা খুলবে। আপনার পরিবর্তন করুন এবং একটি PR তৈরি করুন। +অনুগ্রহ করে উপরের [সর্বোত্তম অনুশীলন](#best-practices) বিভাগটি দেখুন +এবং আপনি আমাদের নির্দেশিকা অনুসরণ করেন তা নিশ্চিত করতে আমাদের [স্টাইল গাইড](/bn/style-guide/) পড়ুন। + +## শব্দকোষ স্থানীয়করণে সাহায্য করুন {#help-localize-the-glossary} + +শব্দকোষটিকে একটি টার্গেট ভাষায় স্থানীয়করণে সহায়তা করতে, অনুগ্রহ করে CNCF স্ল্যাক ওয়ার্কস্পেসে (slack workspace) [#glossary-localizations](https://cloud-native.slack.com/archives/C02N2RGFXDF) চ্যানেলে যোগ দিন এবং আমাদের একটি বার্তা পাঠান। +আপনি হয় একটি বিদ্যমান দলে যোগ দিতে পারেন বা একটি নতুন দল তৈরি করতে পারেন৷ +(এতে কী লাগে তা দেখতে, আমাদের [স্থানীয়করণ নির্দেশিকা](https://github.com/cncf/glossary/blob/main/LOCALIZATION.md) পড়ুন)। +অনুগ্রহ করে সেই দলের অবদান প্রক্রিয়ার সুনির্দিষ্ট তথ্য সংগ্রহ করতে লক্ষ্য ভাষার **কীভাবে অবদান রাখবেন (How to contribute)** নির্দেশিকা পড়ুন। + +## বানান যাচাই {#spell-check} + +বানান পরীক্ষা ব্যর্থ হওয়ার দুটি প্রধান কারণ রয়েছে: + +- PR-এ ভুল বানান রয়েছে। +- PR-এ এমন শব্দ রয়েছে যা শব্দ তালিকায় নিবন্ধিত নয়। + +তালিকায় নতুন শব্দ যোগ করতে, এই পদক্ষেপগুলি অনুসরণ করুন: + +1. আপনার PR-এ, "wordlist.txt" ফাইলটি সন্ধান করুন। +2. "এই ফাইলটি সম্পাদনা করুন (Edit this file)" এ ক্লিক করুন এবং অনুপস্থিত শব্দগুলিকে বর্ণানুক্রমিক (alphabetic) ক্রমে যুক্ত করুন৷ +3. একটি প্রতিশ্রুতি বার্তা যোগ করুন এবং "সাইন অফ করুন এবং পরিবর্তনগুলি প্রস্তাব করুন (Sign off and propose changes)" নির্বাচন করুন। + +**দ্রষ্টব্য**: বানান পরীক্ষা অক্ষর-সংবেদনশীল। -## শব্দকোষ অনুবাদ করতে সাহায্য করুন {#help-translate-the-glossary} -আপনার মাতৃভাষায় শব্দকোষটি অনুবাদ করতে সাহায্য করতে, অনুগ্রহ করে CNCF Slack-এ #glossary-localizations চ্যানেলে যোগ দিন এবং আমাদের জানান। আপনি হয় একটি বিদ্যমান দলে যোগ দিতে পারেন বা একটি নতুন দল তৈরি করতে পারেন (এটি কী নেয় তা দেখতে, চেক আউট করুন বা [স্থানীয়করণ গাইড](https://github.com/cncf/glossary/blob/main/LOCALIZATION.md))। এছাড়াও আমাদের মাসিক শব্দকোষ ওয়ার্কিং গ্রুপ মিটিং যোগদান করুন. আপনি [CNCF ক্যালেন্ডার](https://www.cncf.io/calendar/) এ মিটিংয়ের বিশদ বিবরণ পেতে পারেন। আমরা সেখানে আপনার সাথে দেখা করার জন্য উন্মুখ! +**আমরা [The Good Docs Project](https://thegooddocsproject.dev/) থেকে টেমপ্লেটের ভিত্তিতে এই নির্দেশিকা আপডেট করেছি।** diff --git a/content/bn/data-center.md b/content/bn/data-center.md index 3ce45d3263..08ad17ac35 100644 --- a/content/bn/data-center.md +++ b/content/bn/data-center.md @@ -1,29 +1,29 @@ --- title: তথ্য কেন্দ্র (Data center) -status: Feedback Appreciated -category: প্রযুক্তি -tags: ["infrastructure", "", ""] +status: Completed +category: প্রযুক্তি +tags: ["অবকাঠামো","মৌলিক"] --- -## এটা কি - একটি তথ্য কেন্দ্র হল একটি বিশেষ ভবন বা সুবিধা যা বিশেষভাবে হাউজ কম্পিউটার, প্রায়শই সার্ভারগুলির জন্য ডিজাইন করা হয়। -তথ্য কেন্দ্রগুলি উচ্চ-গতির ইন্টারনেট লাইনের সাথে সংযুক্ত থাকে, -বিশেষ করে তথ্য কেন্দ্রের ক্ষেত্রে [ক্লাউড কম্পিউটিং](bn/cloud-computing/) উপর নির্ভর করে। -বিভিন্ন ধরণের ঘটনাগুলির ক্ষেত্রেও তথ্য কেন্দ্র গুলোর ভবন রয়েছে পরিষেবা বজায় রাখার জন্য সরঞ্জাম রয়েছে, -যেমন বিদ্যুৎ বিভ্রাটের সময় বিদ্যুৎ সরবরাহ করতে জেনারেটর, পাশাপাশি কম্পিউটার দ্বারা উত্পাদিত অতিরিক্ত তাপ মোকাবেলা করার জন্য শক্তিশালী শীতাতপ নিয়ন্ত্রণ ব্যবস্থা। +তথ্য কেন্দ্রগুলি উচ্চ-গতির ইন্টারনেট লাইনের সাথে সংযুক্ত থাকে, বিশেষ করে তথ্য কেন্দ্রের ক্ষেত্রে [ক্লাউড কম্পিউটিং](bn/cloud-computing/) উপর নির্ভর করে। +বিভিন্ন ধরণের ঘটনাগুলির ক্ষেত্রেও তথ্য কেন্দ্র গুলোর ভবন রয়েছে পরিষেবা বজায় রাখার জন্য সরঞ্জাম রয়েছে, যেমন বিদ্যুৎ বিভ্রাটের সময় বিদ্যুৎ সরবরাহ করতে জেনারেটর, পাশাপাশি কম্পিউটার দ্বারা উত্পাদিত অতিরিক্ত তাপ মোকাবেলা করার জন্য শক্তিশালী শীতাতপ নিয়ন্ত্রণ ব্যবস্থা। ## এটা যেসব সমস্যাতে দৃষ্টিপাত করে -প্রতিটি ব্যবসা প্রতিষ্ঠান, যেখানে তারা অবস্থিত, সেখানে নিজস্ব সার্ভার সরঞ্জাম হোস্ট করার পরিবর্তে -তথ্য কেন্দ্র এসব প্রতিষ্ঠান এবং ব্যক্তিদের বড় পরিসরে তথ্য ব্যবস্থাপনার বিশেষ জ্ঞান এবং দক্ষতা ব্যবহার করতে অনুমতি দেয় -এর মানে হল শক্তি সরবরাহ , অগ্নি প্রযুক্তি , শীতাতপ নিয়ন্ত্রণ, উচ্চ গতির ইন্টারনেট সংযোগ নিয়ে চিন্তা করতে হবে না। +1990 এর দশকের শেষের দিকে ডেটাসেন্টারগুলো প্রচলিত হওয়ার আগে, 1990 এর দশকের শেষের দিকে ডেটাসেন্টারগুলো প্রচলিত হওয়ার আগে, সেখানে প্রধানত পৃথক কম্পিউটারগুলো ছিল নির্দিষ্ট কাজ করার জন্য অথবা ব্যক্তিরা তাদের কাজ করার জন্য সেগুলো ব্যবহার করত। + +কিন্তু কম্পিউটারে সীমিত সম্পদ (ডিস্ক, র‍্যাম এবং সিপিই) রয়েছে। +এর মানে হলো যে সেগুলোতে চলমান অ্যাপ্লিকেশনগুলোরও একই কঠিন সীমাবদ্ধতা রয়েছেে , ফলে এটি যত ধরণের অ্যাপ্লিকেশনগুলো চালাতে পারে তাকে সীমিত করে । +ডেটাসেন্টারগুলোর আগে, অ্যাপ্লিকেশনটির স্কেল যে কম্পিউটারে চলছিল তার ধারণক্ষমতার উপর সীমাবদ্ধ ছিল। +কিন্তু আপনি যদি Gmail বা Netflix (অ্যাপ, আপনার ফোন বা কম্পিউটারে থাকা ইউজার ইন্টারফেস নয়) এর মতো স্কেলের অ্যাপের কথা চিন্তা করেন, তাহলে তাদের যেকোন একটি কম্পিউটারের চেয়ে বেশি কম্পিউটিং ক্ষমতা প্রয়োজন। +এবং এখানেই আসে ডেটাসেন্টারের কাজ । ## এটা কিভাবে সাহায্য করে -ক্লাউড কম্পিউটিংয়ের জন্য, তথ্য কেন্দ্র গুলি অত্যন্ত গুরুত্বপূর্ণ। -যেহেতু চাহিদার [স্কেল](bn/scalability/) অনুযায়ী সংস্থান এবং অবকাঠামোর ব্যবস্থা করা যেতে পারে, -ব্যবসাপ্রতিষ্ঠানগুলি কম্পিউটিং সংস্থানগুলির জন্য পূর্বাভাস এবং সম্ভাব্যভাবে কম রিসোর্সিং বা অতিরিক্ত অর্থ প্রদান সম্পর্কে চিন্তা না করেই একটি তথ্য কেন্দ্র এ ক্লাউড কম্পিউটিং সংস্থান ভাড়া নিতে পারে। -যেহেতু সারা বিশ্বে তথ্য কেন্দ্র সেন্টার রয়েছে, -এটি ভৌগোলিকভাবে চাহিদার কাছাকাছি সংস্থান সরবরাহের অনুমতি দেয় -সত্যিকারের সরঞ্জাম আনা এবং সরঞ্জাম সেট আপ না করে। +বিভিন্ন সার্ভার সংযুক্ত করে, ব্যবহারকারীরা একটি [ডিস্ট্রিবিউটেড সিস্টেম](/bn/distributed-systems/) তৈরি করতে পারে যা "সুপার কম্পিউটার" এর মত কাজ করে। +যেহেতু আমরা বেশ কয়েকটি মেশিনের শক্তি একত্রিত করছি, আমরা এখন অনেক বড় অ্যাপ চালাতে পারি বা অনেক বেশি শক্তিশালী কম্পিউটেশনাল কাজগুলো প্রক্রিয়া করতে পারি। +ডেটাসেন্টারগুলো আমাদের দৈনিক ভিত্তিতে ব্যবহার করা বেশিরভাগ অ্যাপ্লিকেশনগুলোকে শক্তি দেয়। + +[পাবলিক ক্লাউডস](/bn/cloud-computing/) হলো ডেটাসেন্টার যা তাদের ক্লায়েন্টদের ধারণক্ষমতা ভাড়া দেয়। +বিগত বছরগুলোতে, আমরা দেখেছি এন্টারপ্রাইজ-মালিকানাধীন ডেটাসেন্টার থেকে ক্লাউডে অ্যাপ্লিকেশনগুলোকে সরানো হয়েছে । diff --git a/content/bn/database-as-a-service.md b/content/bn/database-as-a-service.md index c0f82ab730..9b253f6b9b 100644 --- a/content/bn/database-as-a-service.md +++ b/content/bn/database-as-a-service.md @@ -6,8 +6,6 @@ draft: true tags: ["", "", ""] --- -## এটা কি - ডেটবেস-এজ-এ-সার্ভিস (DBaaS) হল একটি "[ক্লাউড](/bn/cloud_computing/)" অপারেটর (সর্বজনীন বা ব্যক্তিগত) দ্বারা পরিচালিত একটি পরিষেবা যেটি অ্যাপ্লিকেশন টিমের প্রয়োজন ছাড়াই অ্যাপ্লিকেশনগুলিকে সমর্থন করে৷ ঐতিহ্যগত ডাটাবেস প্রশাসন ফাংশন সঞ্চালন. diff --git a/content/bn/debugging.md b/content/bn/debugging.md index 46fe2ca9ee..511e294687 100644 --- a/content/bn/debugging.md +++ b/content/bn/debugging.md @@ -3,11 +3,9 @@ title: ডিবাগিং (Debugging) status: Deprecated category: ধারণা draft: true -tags: ["application", "methodology", ""] +tags: ["অ্যাপ্লিকেশন", "পদ্ধতি", ""] --- -## এটা কি - ডিবাগিং হল কম্পিউটার প্রোগ্রাম, সফ্টওয়্যার, বা সিস্টেম থেকে পছন্দসই ফলাফল পেতে বাগগুলি (বা ত্রুটিগুলি) খুঁজে বের করার এবং সমাধান করার প্রক্রিয়া বা কার্যকলাপ। একটি বাগ হল একটি ত্রুটি বা একটি সমস্যা যা ভুল বা অপ্রত্যাশিত ফলাফলের দিকে পরিচালিত করে। @@ -27,4 +25,4 @@ tags: ["application", "methodology", ""] এখানেই বিভিন্ন ডিবাগিং কৌশল এবং সরঞ্জামগুলি কাজে আসে৷ লগ, ট্রেস এবং মেট্রিক্সের বিশ্লেষণ, উদাহরণস্বরূপ, সরাসরি উৎপাদনে ডিবাগ করার জন্য ব্যবহার করা হয়। ডেভেলপাররা ইন্টারেক্টিভ ডিবাগিং ব্যবহার করে রানটাইমে কোডের মধ্য দিয়ে যেতে পারে যখন সম্পর্কিত এক্সিকিউশন প্রসঙ্গ বিশ্লেষণ করে। -একবার তারা ব্যর্থতার উৎস সনাক্ত করার পরে, তারা কোডটি সংশোধন করে এবং একটি বাগ ফিক্স বা প্যাচ তৈরি করে। \ No newline at end of file +একবার তারা ব্যর্থতার উৎস সনাক্ত করার পরে, তারা কোডটি সংশোধন করে এবং একটি বাগ ফিক্স বা প্যাচ তৈরি করে। diff --git a/content/bn/devops.md b/content/bn/devops.md index fbc917e659..15b1fc384b 100644 --- a/content/bn/devops.md +++ b/content/bn/devops.md @@ -2,11 +2,9 @@ title: ডেভওপস (DevOps) status: Completed category: ধারণা -tags: ["methodology", "", ""] +tags: ["পদ্ধতি", "", ""] --- -## এটা কি - ডেভওপস হল একটি পদ্ধতি যেখানে দলগুলি অ্যাপ্লিকেশন ডেভেলপমেন্ট থেকে প্রোডাকশন অপারেশন পর্যন্ত সম্পূর্ণ প্রক্রিয়ার পরিচালনা করে থাকে। এটি সাধারণ প্রযুক্তি থেকে উচ্চ পর্যায় রয়েছে এবং সাধারণ ধরন থেকে আলাদা হয়। ডেভওপস প্রকৌশলীদের দলদের জন্য আহ্বান করে যারা ছোট উপাদানগুলিতে কাজ করে (একটি সম্পূর্ণ বৈশিষ্ট্যের বিপরীতে), হ্যান্ডঅফগুলি হ্রাস করে – যা সাধারণ ভুলের কারন। ## এটা যেসব সমস্যাতে দৃষ্টিপাত করে diff --git a/content/bn/devsecops.md b/content/bn/devsecops.md index 286f745958..f6bb61b9f2 100644 --- a/content/bn/devsecops.md +++ b/content/bn/devsecops.md @@ -2,11 +2,9 @@ title: ডেভসেকঅপ্স (DevSecOps) status: Completed category: ধারণা +tags: ["পদ্ধতি", "নিরাপত্তা", ""] --- - -## এটা কি - ডেভসেকঅপ্স (DevSecOps) শব্দটি উন্নয়ন, কর্মক্ষম, এবং নিরাপত্তা দায়িত্বের সাংস্কৃতিক একীকরণকে বোঝায়। এটি ডেভেলপার এবং অপারেশনাল ওয়ার্কফ্লোতে ন্যূনতম কোনও ব্যাঘাত না করে সুরক্ষা অগ্রাধিকারগুলি অন্তর্ভুক্ত করতে ডেভঅপ্স [(DevOps)](/bn/devops/) পদ্ধতির প্রসারিত করে৷ ডেভঅপ্স-এর মতো, ডেভসেকঅপ্স হল একটি সাংস্কৃতিক পরিবর্তন, যা গৃহীত প্রযুক্তির দ্বারা ঠেলে দেওয়া হয়, অনন্য গ্রহণের পদ্ধতি সহ। diff --git a/content/bn/digital-certificate.md b/content/bn/digital-certificate.md new file mode 100644 index 0000000000..48b39ec47d --- /dev/null +++ b/content/bn/digital-certificate.md @@ -0,0 +1,22 @@ +--- +title: ডিজিটাল সার্টিফিকেট +status: Feedback Appreciated +category: প্রযুক্তি +tags: ["নিরাপত্তা"] +--- + +একটি (ডিজিটাল) সার্টিফিকেট ( যা প্রায়শই একটি পাবলিক কীসার্টিফিকেট(public key), বা SSL সার্টিফিকেট হিসাবেও উল্লেখ করা হয় ) একটি ডিজিটাল নথি যা নেটওয়ার্কের মাধ্যমে সুরক্ষিত যোগাযোগে সহায়তা করতে ব্যবহৃত হয়। +সার্টিফিকেটগুলো আমাদের জানতে দেয় যে আমরা যে নির্দিষ্ট সত্তার সাথে যোগাযোগ করছি তারা সেটাই যা নিজেকে দাবি করে । +আমরা যে ডেটা প্রেরণ এবং গ্রহণ করি তা এনক্রিপ্ট করে তারা আমাদের যোগাযোগগুলো প্রাইভেট কিনা তা নিশ্চিত করে । + +## এটা যেসব সমস্যাতে দৃষ্টিপাত করে + +যখন ডিভাইসগুলো একটি নেটওয়ার্কের মাধ্যমে যোগাযোগ করে তখন কোন নির্দিষ্ট গ্যারান্টি নেই যে একটি নির্দিষ্ট ডিভাইসটি যা নিজেকে দাবি করে । +উপরন্তু, আমরা গ্যারান্টি দিতে পারি না যে কোনো দুইটি ডিভাইসের মধ্যে ট্র্যাফিক কোনো তৃতীয় পক্ষ দ্বারা বাধাপ্রাপ্ত হবে না। +ফলস্বরূপ, যেকোনো যোগাযোগ সম্ভাব্যভাবে বাধাপ্রাপ্ত হতে পারে , ব্যবহারকারীর নাম এবং পাসওয়ার্ডের মতো সংবেদনশীল তথ্যের সাথে আপস করতে হতে পারে । + +## এটা কিভাবে সাহায্য করে + +আধুনিক ইমেল ক্লায়েন্ট যারা সার্টিফিকেট ব্যবহার করে তারা আপনাকে অবহিত করতে পারে যদি একজন প্রেরকের পরিচয় সঠিক হয়, যেমন ওয়েব ব্রাউজার (আপনার ওয়েব ব্রাউজারের এড্রেস বারের সামনে ছোট্ট লকটি লক্ষ্য করুন)। +অন্য দিকে, সার্টিফিকেট ইন্টারনেটে সত্তার মধ্যে যোগাযোগ এনক্রিপ্ট করতে ব্যবহার করা যেতে পারে। +তারা একটি এনক্রিপশন কৌশল সরবরাহ করে যা এটিকে প্রকৃতপক্ষে প্রায় অসম্ভব করে তোলে ডেটা পড়ার ক্ষেত্রে , তাদের জন্য যারা যোগাযোগে বাধা দান করতে আসে । diff --git a/content/bn/distributed-apps.md b/content/bn/distributed-apps.md index 58acc50701..229c8973f4 100644 --- a/content/bn/distributed-apps.md +++ b/content/bn/distributed-apps.md @@ -1,23 +1,27 @@ --- -title: বিতরিত অ্যাপ্লিকেশন (Distributed Apps) +title: ডিস্ট্রিবিউটেড অ্যাপ্লিকেশন (Distributed Apps) status: Completed category: ধারণা +tags: ["স্থাপত্য", "", ""] --- -## এটা কি - -একটি বিতরিত অ্যাপ্লিকেশন হল একটি অ্যাপ্লিকেশন যেখানে কার্যকারিতা একাধিক ছোট স্বাধীন অংশে বিভক্ত হয়। -বিতরিত অ্যাপ্লিকেশনগুলি সাধারণত পৃথক [মাইক্রোসার্ভিসগুলির](/bn/microservices-architecture/) সমন্বয়ে গঠিত হয় যা বিস্তৃত অ্যাপ্লিকেশনের মধ্যে বিভিন্ন উদ্বেগ পরিচালনা করে। -একটি ক্লাউড নেটিভ পরিবেশে, পৃথক উপাদানগুলি সাধারণত একটি [ক্লাস্টারে](/bn/cluster/) [পাত্র(container)](/bn/container/) হিসাবে চালিত হয়। +একটি ডিস্ট্রিবিউটেড অ্যাপ্লিকেশন হল একটি অ্যাপ্লিকেশন যেখানে কার্যকারিতা একাধিক ছোট স্বাধীন অংশে বিভক্ত হয়। +ডিস্ট্রিবিউটেড অ্যাপ্লিকেশনগুলো সাধারণত পৃথক [মাইক্রোসার্ভিসগুলোর](/bn/microservices-architecture/) সমন্বয়ে গঠিত হয় + যা বিশাল অ্যাপ্লিকেশনের মধ্যে বিভিন্ন উদ্বেগ পরিচালনা করে। +একটি ক্লাউড নেটিভ পরিবেশে, পৃথক উপাদানগুলি সাধারণত একটি [ক্লাস্টারে](/bn/cluster/) [কন্টেইনার](/bn/container/) হিসাবে চালিত হয়। ## এটা যেসব সমস্যাতে দৃষ্টিপাত করে -একটি একক কম্পিউটারে চলমান একটি অ্যাপ্লিকেশন ব্যর্থতার একক পয়েন্ট উপস্থাপন করে - যদি সেই কম্পিউটারটি ব্যর্থ হয়, অ্যাপ্লিকেশনটি অনুপলব্ধ হয়ে যায়। -বিতরিত অ্যাপ্লিকেশনগুলি প্রায়শই [মনোলিথিক অ্যাপ্লিকেশনের](/bn/monolithic-apps/) বিপরীতে থাকে। একটি মনোলিথিক অ্যাপ স্কেল করা কঠিন হতে পারে কারণ বিভিন্ন উপাদান স্বাধীনভাবে স্কেল করা যায় না। -তারা বৃদ্ধির সাথে সাথে ডেভেলপারএর গতিতেও টেনে আনতে পারে কারণ আরও ডেভেলপারদের একটি ভাগ করা কোডবেসে কাজ করতে হবে যার অগত্যা ভালভাবে সংজ্ঞায়িত সীমানা নেই। +একটি একক কম্পিউটারে চলমান একটি অ্যাপ্লিকেশন ব্যর্থতার একক পয়েন্ট উপস্থাপন করে - যদি সেই কম্পিউটারটি ব্যর্থ হয়, অ্যাপ্লিকেশনটি অপ্রাপ্য হয়ে যায়। +ডিস্ট্রিবিউটেড অ্যাপ্লিকেশনগুলো প্রায়শই [মনোলিথিক অ্যাপ্লিকেশনের](/bn/monolithic-apps/) বিপরীতে থাকে। +একটি মনোলিথিক অ্যাপ স্কেল করা কঠিন হতে পারে কারণ বিভিন্ন উপাদান স্বাধীনভাবে স্কেল করা যায় না। +তারা বৃদ্ধির সাথে সাথে ডেভেলপারের গতিতেও টেনে আনতে পারে +কারণ আরও ডেভেলপারদের একটি ভাগ করা কোডবেসে কাজ করতে হবে যার বাধ্যতামূলকভাবে সংজ্ঞায়িত সীমানা নেই। ## এটা কিভাবে সাহায্য করে -একটি অ্যাপ্লিকেশনকে বিভিন্ন অংশে বিভক্ত করার সময় এবং সেগুলিকে অনেক জায়গায় চালানোর সময়, সামগ্রিক সিস্টেম আরও ব্যর্থতা সহ্য করতে পারে। -এটি একটি অ্যাপ্লিকেশনকে একটি একক অ্যাপ্লিকেশন উদাহরণের জন্য উপলব্ধ নয় এমন স্কেলিং বৈশিষ্ট্যগুলির সুবিধা নিতে দেয়, যেমন [অনুভূমিকভাবে স্কেল](/bn/horizontal-scaling/) করার ক্ষমতা। -তবে এটি একটি খরচে আসে: জটিলতা বৃদ্ধি এবং অপারেশনাল ওভারহেড - আপনি এখন একটি অ্যাপের পরিবর্তে প্রচুর অ্যাপ্লিকেশন উপাদান চালাচ্ছেন। +একটি অ্যাপ্লিকেশনকে বিভিন্ন অংশে বিভক্ত করার সময় এবং সেগুলোকে অনেক জায়গায় চালানোর সময়, সামগ্রিক সিস্টেম আরও ব্যর্থতা সহ্য করতে পারে। +এটি একটি অ্যাপ্লিকেশনকে একটি একক অ্যাপ্লিকেশন উদাহরণের জন্য উপলব্ধ নয় এমন স্কেলিং বৈশিষ্ট্যগুলোর সুবিধা নিতে দেয়, + যেমন [অনুভূমিকভাবে স্কেল](/bn/horizontal-scaling/) করার ক্ষমতা। +তবে এটি একটি খরচ নিয়ে আসে; বৃদ্ধি করে জটিলতা এবং অপারেশনাল ওভারহেড + - কারণ আপনি এখন একটি অ্যাপের পরিবর্তে প্রচুর অ্যাপ্লিকেশন উপাদান চালাচ্ছেন। diff --git a/content/bn/distributed-systems.md b/content/bn/distributed-systems.md index 064da9d532..4bab7c7d9c 100644 --- a/content/bn/distributed-systems.md +++ b/content/bn/distributed-systems.md @@ -1,20 +1,21 @@ --- -title: বিতরিত সিস্টেম (Distributed System) +title: ডিস্ট্রিবিউটেড সিস্টেম (Distributed System) status: Completed category: ধারণা +tags: ["স্থাপত্য", "", ""] --- -## এটা কি - -একটি বিতরিত সিস্টেম হল একটি নেটওয়ার্কের সাথে সংযুক্ত স্বায়ত্তশাসিত কম্পিউটিং উপাদানগুলির একটি সংগ্রহ যা ব্যবহারকারীদের কাছে একটি একক সুসংগত সিস্টেম হিসাবে প্রদর্শিত হয়। -সাধারণত [নোড](/bn/nodes/) হিসাবে উল্লেখ করা হয়, এই উপাদানগুলি হার্ডওয়্যার ডিভাইস (যেমন কম্পিউটার, মোবাইল ফোন) বা সফ্টওয়্যার প্রক্রিয়া হতে পারে। -নোডগুলি একটি সাধারণ লক্ষ্য অর্জনের জন্য প্রোগ্রাম করা হয় এবং সহযোগিতা করার জন্য, তারা নেটওয়ার্কে বার্তা বিনিময় করে। +একটি ডিস্ট্রিবিউটেড সিস্টেম হলো একটি নেটওয়ার্কের সাথে সংযুক্ত স্বায়ত্তশাসিত কম্পিউটিং উপাদানগুলোর একটি সংগ্রহ +যা ব্যবহারকারীদের কাছে একটি একক সুসংগত সিস্টেম হিসাবে প্রদর্শিত হয়। +সাধারণত [নোড](/bn/nodes/) হিসাবে উল্লেখ করা হয়, এই উপাদানগুলো হার্ডওয়্যার ডিভাইস (যেমন কম্পিউটার, মোবাইল ফোন) বা সফ্টওয়্যার প্রক্রিয়া হতে পারে। +নোডগুলো একটি সাধারণ লক্ষ্য অর্জনের জন্য প্রোগ্রাম করা হয় এবং সহযোগিতা করার জন্য, তারা নেটওয়ার্কে বার্তা বিনিময় করে। ## এটা যেসব সমস্যাতে দৃষ্টিপাত করে অনেক আধুনিক অ্যাপ্লিকেশন আজ এত বড় যে তাদের পরিচালনা করার জন্য সুপার কম্পিউটারের প্রয়োজন হবে। জিমেইল বা নেটফ্লিক্সের কথা ভাবুন। সম্পূর্ণ অ্যাপ্লিকেশন হোস্ট করার জন্য কোনো একক কম্পিউটার যথেষ্ট শক্তিশালী নয়। -একাধিক কম্পিউটার সংযোগ করে, গণনার শক্তি প্রায় সীমাহীন হয়ে যায়। ডিস্ট্রিবিউটেড কম্পিউটিং ছাড়া, আজকে আমরা অনেক অ্যাপ্লিকেশন উপর নির্ভরশীল হওয়া সম্ভব হবে না। +একাধিক কম্পিউটার সংযোগ করে, কম্পিউট শক্তি প্রায় সীমাহীন হয়ে যায়। +ডিস্ট্রিবিউটেড কম্পিউটিং ছাড়া, আজকে আমরা অনেক অ্যাপ্লিকেশন উপর নির্ভরশীল হওয়া সম্ভব হবে না। ঐতিহ্যগতভাবে, সিস্টেমগুলি উল্লম্বভাবে [স্কেল](/bn/scalability/) করবে। আপনি যখন একটি পৃথক মেশিনে আরও সিপিউ (CPU) বা মেমরি যোগ করেন তখনই। @@ -23,8 +24,8 @@ category: ধারণা ## এটা কিভাবে সাহায্য করে -বিতরিত সিস্টেমগুলি [ অনুভূমিক স্কেলিং](/bn/horizontal-scaling/) করার অনুমতি দেয় (যেমন যখনই প্রয়োজন হয় সিস্টেমে আরও নোড যোগ করা) | +ডিস্ট্রিবিউটেড সিস্টেমগুলো [ অনুভূমিক স্কেলিং](/bn/horizontal-scaling/) করার অনুমতি দেয় (যেমন যখনই প্রয়োজন হয় সিস্টেমে আরও নোড যোগ করা) | এটি স্বয়ংক্রিয়ভাবে একটি সিস্টেমকে কাজের চাপ বা সম্পদ খরচে হঠাৎ বৃদ্ধি পরিচালনা করার অনুমতি দেয়। একটি নন-ডিস্ট্রিবিউটেড সিস্টেম ব্যর্থতার ঝুঁকিতে নিজেকে প্রকাশ করে কারণ যদি একটি মেশিন ব্যর্থ হয়, পুরো সিস্টেম ব্যর্থ হয়। -একটি বিতরিত সিস্টেম এমনভাবে ডিজাইন করা যেতে পারে যে, এমনকি কিছু মেশিন নিচে গেলেও, সামগ্রিক সিস্টেম একই ফলাফল তৈরি করতে কাজ চালিয়ে যেতে পারে। +একটি ডিস্ট্রিবিউটেড সিস্টেম এমনভাবে ডিজাইন করা যেতে পারে যে, এমনকি কিছু মেশিন নিচে গেলেও, সামগ্রিক সিস্টেম একই ফলাফল তৈরি করতে কাজ চালিয়ে যেতে পারে। diff --git a/content/bn/ebpf.md b/content/bn/ebpf.md new file mode 100644 index 0000000000..4caad31212 --- /dev/null +++ b/content/bn/ebpf.md @@ -0,0 +1,43 @@ +--- +title: ইবিপিএফ(eBPF) +status: Completed +category: প্রযুক্তি +tags: ["স্থাপত্য", " নেটওয়ার্কিং", "নিরাপত্তা"] + +--- + +ইবিপিএফ(eBPF) , বা বর্ধিত বার্কলে প্যাকেট ফিল্টার (extended Berkeley Packet Filter), এমন একটি প্রযুক্তি যা কার্নেলের সোর্স কোড পরিবর্তন না করে বা লিনাক্স কার্নেল মডিউল লোড না করেই লিনাক্স সিস্টেমের কার্নেল স্পেসে ছোট, স্যান্ডবক্সড প্রোগ্রাম বা স্ক্রিপ্ট চালানোর অনুমতি দেয়। + +একটি লিনাক্স সিস্টেমে দুইটি স্পেস আছে : কার্নেল এবং ইউজার স্পেস। +কার্নেল অপারেটিং সিস্টেমের কোর এর প্রতিনিধিত্ব করে এবং +এটি একমাত্র অংশ যার কাছে হার্ডওয়্যারের সীমাহীন অ্যাক্সেস রয়েছে । + +অ্যাপ্লিকেশনগুলো ইউজার স্পেসে থাকে, এবং যখন তাদের উচ্চতর অনুমতির প্রয়োজন হয়, +তারা কার্নেলের কাছে একটি রিকোয়েস্ট পাঠায়। +যে অ্যাপ্লিকেশনগুলোর জন্য আরও ফ্লেক্সিবিলিটি প্রয়োজন, যেমন সরাসরি হার্ডওয়্যার অ্যাক্সেসের জন্য, +কার্নেলটিকে "লিনাক্স কার্নেল মডিউল" পদ্ধতির মাধ্যমে প্রসারিত করা যেতে পারে। +এই পদ্ধতিটি কার্নেলের ডিফল্ট কার্যকারিতা প্রসারিত করে, +অ্যাপ্লিকেশনগুলোকে অন্তর্নিহিত উপাদানগুলোতে গভীরতর অ্যাক্সেসের অনুমতি দেয়। +যাইহোক, এই পদ্ধতিটি নিরাপত্তা ঝুঁকিও নিয়ে আসে, যা ইবিপিএফকে একটি আকর্ষণীয় বিকল্প করে তোলে । + +## এটা যেসব সমস্যাতে দৃষ্টিপাত করে + +সাধারণত, অ্যাপ্লিকেশনগুলো ইউজার স্পেসে চলে এবং যদি অ্যাপ্লিকেশনটির কার্নেল থেকে কিছু সুবিধার প্রয়োজন হয় (যেমন, কিছু হার্ডওয়্যার অ্যাক্সেস করার জন্য), +এটি তথাকথিত "সিস্টেম কল" এর মাধ্যমে কার্নেল থেকে এটির জন্য অনুরোধ করে। +বেশিরভাগ ক্ষেত্রে, এই পদ্ধতিটি ঠিক কাজ করে। যাইহোক, এমন কিছু উদাহরণ রয়েছে যেখানে ডেভেলপারদের নিম্ন-স্তরের সিস্টেম অ্যাক্সেসের জন্য আরও ফ্লেক্সিবিলিটি প্রয়োজন। +পর্যবেক্ষণযোগ্যতা, নিরাপত্তা এবং নেটওয়ার্কিং ফিচারগুলো এর ভালো উদাহরণ। +এটি অর্জন করতে, আমরা লিনাক্স কার্নেল মডিউল ব্যবহার করতে পারি, কার্নেল সোর্স কোড পরিবর্তন না করেই কার্নেল বেস প্রসারিত করতে পারি। +যদিও লিনাক্স কার্নেল মডিউল ব্যবহার করার সুবিধা রয়েছে, এটি নিরাপত্তা ঝুঁকিও নিয়ে আসে। +যেহেতু তারা কার্নেল স্পেসের মধ্যে কাজ করে, লিনাক্স কার্নেল মডিউলগুলো কার্নেলটি ক্র্যাশ করতে পারে এবং যখন কার্নেলটি ক্র্যাশ হয়, তখন পুরো মেশিনটির ক্ষেত্রেও তাই হয়। +অতিরিক্তভাবে, কার্নেল মডিউলগুলোর কাছে অতিরিক্ত সুবিধা এবং সিস্টেম রিসোর্সগুলোর সরাসরি অ্যাক্সেস রয়েছে। এবং এটি সঠিকভাবে সুরক্ষিত না করা হলে, আক্রমণকারীরা এগুলোকে কাজে লাগাতে পারে । + +## এটা কিভাবে সাহায্য করে + +ইবিপিএফ লিনাক্স কার্নেল মডিউলের তুলনায় ব্যবহারকারী-সংজ্ঞায়িত প্রোগ্রামগুলো চালানোর জন্য আরও নিয়ন্ত্রিত এবং ধারণকৃত পরিবেশ প্রদান করে। +এটি কার্নেলের মধ্যে একটি স্যান্ডবক্সযুক্ত পরিবেশে চলে, আইসোলেশন প্রদান করে এবং ঝুঁকি হ্রাস করে। +যদি একটি ইবিপিএফ প্রোগ্রামে একটি দুর্বলতা বা ত্রুটি পাওয়া যায়, তবে এর প্রভাব সাধারণত স্যান্ডবক্সযুক্ত পরিবেশে সীমাবদ্ধ থাকে। +তাছাড়া, একটি ইবিপিএফ প্রোগ্রাম কার্নেলে চলা শুরু করার আগে, এটিকে কিছু যাচাইকরণ পাস করতে হবে। +যাচাইকারী উপাদান সম্ভাব্য নিরাপত্তা লঙ্ঘনের জন্য ইবিপিএফ প্রোগ্রাম চেক করে, +যেমন সীমার বাইরে মেমরি অ্যাক্সেস, অসীম লুপ, এবং অননুমোদিত কার্নেল ফাংশন। +এইভাবে, এটি নিশ্চিত করে যে প্রোগ্রামটি একটি অসীম লুপে প্রবেশ করবে না এবং কার্নেল ক্র্যাশ ঘটাবে না । +এই নিরাপত্তা নিয়ন্ত্রণগুলো ইবিপিএফকে লিনাক্স কার্নেল মডিউলের তুলনায় লিনাক্স কার্নেলে অ্যাপ্লিকেশন চালানোর জন্য একটি অধিক নিরাপদ বিকল্প করে তোলে। diff --git a/content/bn/edge-computing.md b/content/bn/edge-computing.md index 087c3f7ace..bd0887de04 100644 --- a/content/bn/edge-computing.md +++ b/content/bn/edge-computing.md @@ -1,11 +1,9 @@ --- title: এজ কম্পিউটিং (Edge Computing) status: Completed -category: ধারণা +category: প্রযুক্তি --- -## এটা কি - এজ কম্পিউটিং হল একটি [বিতরণ সিস্টেম](/bn/distributed-systems/) পদ্ধতি যা প্রাথমিক ডেটা সেন্টার থেকে ডেটা উৎসে কিছু স্টোরেজ এবং কম্পিউটিং ক্ষমতা স্থানান্তর করে। সংগৃহীত ডেটা স্থানীয়ভাবে গণনা করা হয় (যেমন, একটি কারখানার মেঝেতে,একটি দোকানে বা একটি শহর জুড়ে) প্রক্রিয়াকরণ (processing) এবং বিশ্লেষণের জন্য কেন্দ্রীভূত ডেটা সেন্টারে পাঠানোর পরিবর্তে। এই স্থানীয় প্রক্রিয়াকরণ ইউনিট বা ডিভাইসগুলি সিস্টেমের প্রান্তের (edge) প্রতিনিধিত্ব করে,যেখানে ডেটা সেন্টার হল এর কেন্দ্র। প্রান্তে গণনা করা আউটপুট পরবর্তী প্রক্রিয়াকরণের জন্য প্রাথমিক ডেটা সেন্টারে ফেরত পাঠানো হয়। এজ কম্পিউটিংয়ের উদাহরণগুলির মধ্যে রয়েছে হাতের কব্জির গ্যাজেট বা কম্পিউটার যা ট্র্যাফিক প্রবাহ বিশ্লেষণ করে। ## এটা যেসব সমস্যাতে দৃষ্টিপাত করে diff --git a/content/bn/event-driven-architecture.md b/content/bn/event-driven-architecture.md index 505b40d31f..1ccbdd5617 100644 --- a/content/bn/event-driven-architecture.md +++ b/content/bn/event-driven-architecture.md @@ -2,11 +2,9 @@ title: ঘটনা-চালিত স্থাপত্য (Event-Driven Architecture) status: Completed category: ধারণা -tags: ["architecture", "", ""] +tags: ["স্থাপত্য", "", ""] --- -## এটা কি - ঘটনা চালিত স্থাপত্য হল একটি সফ্টওয়্যার স্থাপত্য যা ঘটনা তৈরি, প্রক্রিয়াকরণ এবং ব্যবহারকে প্রচার করে। একটি ঘটনা হল একটি অ্যাপ্লিকেশনের অবস্থার পরিবর্তন। উদাহরণস্বরূপ, একটি রাইড-শেয়ারিং অ্যাপে রাইডের প্রশংসা করা একটি ঘটনার প্রতিনিধিত্ব করে৷ diff --git a/content/bn/event-streaming.md b/content/bn/event-streaming.md index 861fc9689f..7c15e271ca 100644 --- a/content/bn/event-streaming.md +++ b/content/bn/event-streaming.md @@ -2,11 +2,9 @@ title: ঘটনা প্রবাহ ( Event Streaming ) status: Completed category: ধারণা -tags: ["methodology", "networking", ""] +tags: ["পদ্ধতি", " নেটওয়ার্কিং", ""] --- -## এটা কি - ঘটনা প্রবাহ হল এমন একটি পদ্ধতি যেখানে সফ্টওয়্যার একটি অ্যাপ্লিকেশন থেকে অন্য অ্যাপ্লিকেশনে ঘটনার তথ্য পাঠায় যাতে তারা কী করছে তা অবিরতভাবে যোগাযোগ করতে পারে। অন্য সমস্ত পরিষেবাতে যা করে তা সম্প্রচার করে এমন একটি পরিষেবার চিত্র নিন৷ একটি পরিষেবা দ্বারা নেওয়া প্রতিটি কার্যকলাপকে একটি ঘটনা হিসাবে উল্লেখ করা হয়, তাই ঘটনা প্রবাহ। diff --git a/content/bn/firewall.md b/content/bn/firewall.md index d43839a012..ccee670aeb 100644 --- a/content/bn/firewall.md +++ b/content/bn/firewall.md @@ -6,8 +6,6 @@ category: প্রযুক্তি tags: ["", "", ""] --- -## এটা কি - ফায়ারওয়াল হল এমন একটি সিস্টেম যা নির্দিষ্ট নিয়মের ভিত্তিতে নেটওয়ার্ক ট্র্যাফিক ফিল্টার করে। ফায়ারওয়ালগুলি হার্ডওয়্যার, সফ্টওয়্যার বা দুটির সংমিশ্রণ হতে পারে। diff --git a/content/bn/function-as-a-service.md b/content/bn/function-as-a-service.md index e075838139..5e384ce66d 100644 --- a/content/bn/function-as-a-service.md +++ b/content/bn/function-as-a-service.md @@ -1,12 +1,10 @@ --- title: ফাংশন-এজ়-এ-সার্ভিস (Function as a Service) (FaaS) status: Completed -category: প্রযুক্তিবিদ্যা -tags: ["infrastructure", "", ""] +category: প্রযুক্তি +tags: ["অবকাঠামো", "", ""] --- -## এটা কি - ফাংশন-এজ়-এ-সার্ভিস একটি পরিষেবা হিসাবে ফাংশন (FaaS) হল এক প্রকার [সার্ভারলেস](/bn/serverless/) [ক্লাউড কম্পিউটিং](/bn/cloud-computing/) [সর্বিস](/bn/service/) যা ইভেন্টের প্রতিক্রিয়ায় কোড চালানোর অনুমতি দেয় diff --git a/content/bn/gitops.md b/content/bn/gitops.md index f6adaee5f6..316247bbcd 100644 --- a/content/bn/gitops.md +++ b/content/bn/gitops.md @@ -2,11 +2,9 @@ title: গিটঅপস (GitOps) status: Feedback Appreciated category: ধারণা -tags: ["methodology", "", ""] +tags: ["পদ্ধতি", "", ""] --- -## এটা কি - গিটঅপস (GitOps) হল [শেয়ার করা নীতির (shared principles)](https://opengitops.dev/) উপর ভিত্তি করে সর্বোত্তম অনুশীলনের একটি সেট, যা একটি ওয়ার্কফ্লোতে প্রয়োগ করা হয় যা সফ্টওয়্যার এজেন্টের উপর নির্ভর করে যা একটি গিট রিপোজিটরিতে ঘোষিত সিস্টেমের (declared system) অবস্থা বা কনফিগারেশনের পুনর্মিলন (reconcile) করতে স্বয়ংক্রিয়করণে সক্ষম করে। এই সফ্টওয়্যার এজেন্ট এবং অনুশীলনগুলি একটি সমন্বিত কর্মপ্রবাহ (cohesive workflow) চালানোর জন্য ব্যবহৃত হয় যা গিট-এর মতো একটি সোর্স কন্ট্রোল ব্যবস্থাকে "সত্যের একক উৎস" হিসাবে ব্যবহার করে এবং এই অনুশীলনটিকে অ্যাপ্লিকেশন, অবকাঠামো এবং অপারেশনাল পদ্ধতিতে প্রসারিত করে। ## এটা যেসব সমস্যাতে দৃষ্টিপাত করে @@ -15,4 +13,4 @@ tags: ["methodology", "", ""] ## এটা কিভাবে সাহায্য করে -GitOps একটি দৃষ্টান্ত যা একটি অ্যাপ্লিকেশন এবং ক্লাউড সিস্টেম অবকাঠামো পরিচালনা করতে সাহায্য করার জন্য একটি কর্মপ্রবাহে প্রয়োগ করা যেতে পারে। এটি সংস্থাগুলিকে বিভিন্ন সুবিধা প্রদান করে যেমন উন্নত সমন্বয়, স্বচ্ছতা, স্থিতিশীলতা, এবং একটি সিস্টেমের নির্ভরযোগ্যতা। একটি ক্লোজ লুপে ক্রিয়াকলাপ নিশ্চিত করে যে একটি সিস্টেমের বর্তমান লাইভ স্টেটটি গিট রিপোজিটরিতে নির্দিষ্ট করা কাঙ্ক্ষিত টার্গেট স্টেটের সাথে মেলে। \ No newline at end of file +GitOps একটি দৃষ্টান্ত যা একটি অ্যাপ্লিকেশন এবং ক্লাউড সিস্টেম অবকাঠামো পরিচালনা করতে সাহায্য করার জন্য একটি কর্মপ্রবাহে প্রয়োগ করা যেতে পারে। এটি সংস্থাগুলিকে বিভিন্ন সুবিধা প্রদান করে যেমন উন্নত সমন্বয়, স্বচ্ছতা, স্থিতিশীলতা, এবং একটি সিস্টেমের নির্ভরযোগ্যতা। একটি ক্লোজ লুপে ক্রিয়াকলাপ নিশ্চিত করে যে একটি সিস্টেমের বর্তমান লাইভ স্টেটটি গিট রিপোজিটরিতে নির্দিষ্ট করা কাঙ্ক্ষিত টার্গেট স্টেটের সাথে মেলে। diff --git a/content/bn/horizontal-scaling.md b/content/bn/horizontal-scaling.md index 68adef9108..2c0945aa6d 100644 --- a/content/bn/horizontal-scaling.md +++ b/content/bn/horizontal-scaling.md @@ -2,11 +2,9 @@ title: অনুভূমিক স্কেলিং (Horizontal Scaling) status: Completed category: ধারণা -tags: ["infrastructure", "", ""] +tags: ["অবকাঠামো", "", ""] --- -## এটা কি - অনুভূমিক স্কেলিং হল এমন একটি কৌশল যেখানে আরও [নোড](/bn/nodes/) যোগ করে একটি সিস্টেমের ক্ষমতা বৃদ্ধি করা হয়। স্বতন্ত্র নোডগুলিতে আরও গণনা সংস্থান যোগ করার বিপরীতে (পরবর্তীটি [উল্লম্ব স্কেলিং](/bn/vertical-scaling/) নামে পরিচিত)। ধরা যাক, আমাদের 4GB RAM এর একটি সিস্টেম আছে এবং এর ক্ষমতা 16GB RAM-তে বাড়াতে চাই, diff --git a/content/bn/hypervisor.md b/content/bn/hypervisor.md index 575ce08cef..97e1c789d3 100644 --- a/content/bn/hypervisor.md +++ b/content/bn/hypervisor.md @@ -2,11 +2,9 @@ title: হাইপারভাইজার (Hypervisor) status: Feedback Appreciated category: প্রযুক্তি -tags: ["application", "", ""] +tags: ["অ্যাপ্লিকেশন", "", ""] --- -## এটা কি - একটি হাইপারভাইজার [বেয়ার মেটাল মেশিন (bare metal machine)](/bn/bare-metal-machine/) সম্পদ (সিপিইউ (CPU), স্মৃতি (Memory), অন্তর্জাল (Network) এবং সঞ্চয়স্থান (Storage)) এর সুবিধা গ্রহণ করে [ভার্চুয়ালাইজেশন (virtualization)](/bn/virtualization/) সক্ষম করে, সেগুলিকে উপ-অংশে ভাগ করে এবং অন্তর্নিহিত হোস্ট (host) তার কর্মক্ষমতা সীমাতে না পৌঁছা পর্যন্ত [ভার্চুয়াল মেশিন (Virtual Machine (VM))](/bn/virtual-machine/) তৈরি করার জন্য সেই অনুযায়ী সংস্থান বরাদ্দ করে। ## এটা যেসব সমস্যাতে দৃষ্টিপাত করে diff --git a/content/bn/idempotence.md b/content/bn/idempotence.md index 5ff8b33d23..23d35d781b 100644 --- a/content/bn/idempotence.md +++ b/content/bn/idempotence.md @@ -1,8 +1,8 @@ --- title: অক্ষমতা (Idempotence) status: Completed -category: সম্পত্তি -tags: ["property", "", ""] +category: বৈশিষ্ট্য +tags: ["বৈশিষ্ট্য", "", ""] --- গণিত বা কম্পিউটার বিজ্ঞানে, অক্ষমতা এমন একটি প্রক্রিয়াকে বর্ণনা করে যা সর্বদা একই ফলাফলের দিকে নিয়ে যায়, diff --git a/content/bn/immutable-infrastructure.md b/content/bn/immutable-infrastructure.md index fda630e401..57fbeba582 100644 --- a/content/bn/immutable-infrastructure.md +++ b/content/bn/immutable-infrastructure.md @@ -1,8 +1,8 @@ --- title: অপরিবর্তনীয় পরিকাঠামো (Immutable Infrastructure) status: Completed -category: সম্পত্তি -tags: ["infrastructure", "property", ""] +category: বৈশিষ্ট্য +tags: ["অবকাঠামো", "বৈশিষ্ট্য", ""] --- অপরিবর্তনীয় অবকাঠামো বলতে কম্পিউটার অবকাঠামো বোঝায় diff --git a/content/bn/infrastructure-as-a-service.md b/content/bn/infrastructure-as-a-service.md index 306d6688aa..388631f344 100644 --- a/content/bn/infrastructure-as-a-service.md +++ b/content/bn/infrastructure-as-a-service.md @@ -2,12 +2,9 @@ title: পরিষেবা হিসেবে পরিকাঠামো (Infrastructure as a service) status: Completed category: ধারণা -tags: ["infrastructure", "", ""] +tags: ["অবকাঠামো", "", ""] --- - -## এটা কি - পরিষেবা হিসেবে পরিকাঠামো অথবা IaaS হল একটি [ক্লাউড কম্পিউটিং](/bn/cloud-computing/) পরিষেবার আদল যেটি Pay as you go এর আদলে [ফিজিক্যাল](/bn/bare-metal-machine/) অথবা [ভার্চুয়ালাইজড](/bn/virtualization/) কম্পিউট, স্টোরেজ এবং প্রয়োজনে নেটওয়ার্ক রিসোর্স প্রদান করে। ক্লাউড প্রদানকারীরা হার্ডওয়্যার এবং সফটওয়্যার এর মালিক হন এবং পরিচালনা করেন যা গ্রাহকদের জন্য সরকারি ,ব্যক্তিগত কিংবা হাইব্রিড ক্লাউড স্থাপনায় উপলব্ধ। ## এটা যেসব সমস্যাতে দৃষ্টিপাত করে diff --git a/content/bn/infrastructure-as-code.md b/content/bn/infrastructure-as-code.md index 241a957ace..9f0b3bc069 100644 --- a/content/bn/infrastructure-as-code.md +++ b/content/bn/infrastructure-as-code.md @@ -2,11 +2,9 @@ title: কোড হিসেবে পরিকাঠামো (Infrastructure as Code) status: Completed category: ধারণা -tags: ["infrastructure", "methodology", ""] +tags: ["অবকাঠামো", "পদ্ধতি", ""] --- -## এটা কি - কোড হিসেবে পরিকাঠামো হল, অবকাঠামোর সংজ্ঞা এক বা একধিক ফাইল হিসেবে সংরক্ষণ করার অনুশীলন। এটি প্রথাগত মডেলকে প্রতিস্থাপন করে যেখানে পরিকাঠামোকে একটি পরিষেবা হিসেবে মানবিকভাবে প্রতিবিধান করা হয় সাধারণত সেল স্ক্রিপ্ট বা অন্যান্য কনফিগারেশন উপাদানের মাধ্যমে। ## এটা যেসব সমস্যাতে দৃষ্টিপাত করে diff --git a/content/bn/ingress.md b/content/bn/ingress.md new file mode 100644 index 0000000000..dbb4bd44fa --- /dev/null +++ b/content/bn/ingress.md @@ -0,0 +1,30 @@ +--- +title: ইনগ্রেস(Ingress) +status: Completed +category: প্রযুক্তি +tags: ["মৌলিক"] +--- + +একটি ইনগ্রেস হলো এক গুচ্ছ নিয়মাবলি যা বাইরে থেকে একটি কন্টেইনারে অথবা একটি ক্লাস্টারে চলমান কন্টেইনারগুলোর একটি গ্রুপের মধ্যে ইন্টারনেট ট্র্যাফিক পরিচালনা করতে সহায়তা করে। +এটি দুইটি উপাদান নিয়ে গঠিত: ইনগ্রেস রিসোর্স এবং ইনগ্রেস কন্ট্রোলার। +ইনগ্রেস রিসোর্স হলো একটি কনফিগারেশন ফাইল যা অন্যান্য ম্যানিফেস্ট ফাইলের সাথে থাকে এবং অ্যাডমিনদের বাহ্যিক ট্রাফিক রাউটিং কনফিগার করতে দেয়। +ইনগ্রেস কন্ট্রোলার হলো ওয়েব সার্ভার প্রযুক্তি যা প্রকৃতপক্ষে ইনগ্রেস রিসোর্সের কনফিগারেশন অনুযায়ী ট্র্যাফিকের রাউটিং করে। + +## এটা যেসব সমস্যাতে দৃষ্টিপাত করে + +ক্লাউড নেটিভ ওয়েব অ্যাপ্লিকেশানগুলো একাধিক পরিষেবা নিয়ে গঠিত এবং প্রায়শই, ব্যবহারকারীদের তাদের ব্রাউজার ব্যবহার করে দেখার জন্য সেই [পরিষেবাসমূহকে](/bn/service/) ইন্টারনেটে অ্যাক্সেসযোগ্য হতে হয় ৷ +এই অ্যাপ্লিকেশন চালানোর জন্য [কুবারনেটিস](/bn/kubernetes/) ব্যবহার করার সময় এই পরিষেবাসমূহ ব্যবহারকারীদের অ্যাক্সেসযোগ্য করে তুলতে, আমাদের প্রতিটি অ্যাপ্লিকেশন পরিষেবাকে বাইরের বিশ্বের কাছে প্রকাশ করতে হবে। +সবচেয়ে সহজ উপায় হলো একটি কুবারনেটিস লোড ব্যালেন্সার পরিষেবা ব্যবহার করা। +কিন্তু এই ধরনের পরিষেবা তৈরি করার ফলে অন্তর্নিহিত অবকাঠামোতে একটি নতুন উপাদান তৈরি হয়। +এটি মাথার উপর শুধুমাত্র নতুন খরচ এবং ব্যবস্থাপনা নিয়ে আসে না, সাথে প্রতিটি নতুন তৈরি লোড ব্যালেন্সারের নিজস্ব বাহ্যিক আইপি ঠিকানাও থাকে। +যা একটি খারাপ ব্যবহারকারীর অভিজ্ঞতার দিকে নিয়ে যায়, কারণ একজন ব্যবহারকারী হিসাবে, আমরা একটি অ্যাপ্লিকেশন অ্যাক্সেস করার জন্য ভিন্ন ভিন্ন URL ব্রাউজ করতে চাই না। + +## এটা কিভাবে সাহায্য করে + +একটি ইনগ্রেস রিসোর্স আপনাকে কনফিগার করতে দেয় যে কীভাবে ট্র্যাফিক ব্যালেন্সড এবং রুট করা যায় একটি অ্যাপ্লিকেশনের পরিষেবাসমূহে। +ইনগ্রেস কন্ট্রোলার একটি ইউআরএল (www.example-url.com) এর মাধ্যমে একটি একক এন্ট্রি পয়েন্ট প্রকাশ করে এবং বিভিন্ন ইউআরএল পাথের (www.example-url.com/path) উপর ভিত্তি করে প্রকৃত রাউটিং এবং ব্যালেন্সিং করে। +একটি ইনগ্রেস কন্ট্রোলার হলো এমন একটি উপাদান যা ক্লাস্টারের মধ্যে চলে এবং ইনগ্রেস রিসোর্সে সংজ্ঞায়িত নিয়মগুলো ব্যাখ্যা করে। +এটি ক্লাস্টার অপারেটরদের উপর নির্ভর করে যেখানে ওয়েব অ্যাপটি Nginx, Traefik, HAProxy ইত্যাদির মতো সম্ভাব্য প্রযুক্তির সেট থেকে একটি নির্দিষ্ট ইনগ্রেস কন্ট্রোলার বেছে নিতে কাজ করে। +ফলে এখন, যদি একটি অ্যাপ্লিকেশন একাধিক পরিষেবা নিয়ে গঠিত হয়, তখন ব্যবহারকারী একটি মাত্র URL ব্যবহার করে এটি অ্যাক্সেস করতে পারবেন । +এটি অবকাঠামো স্তরে অসংখ্য পৃথক লোড ব্যালেন্সারের প্রয়োজনীয়তা দূর করে এবং প্রতিটি পরিষেবার জন্য ফায়ারওয়াল এবং লোড ব্যালেন্সারের নিয়মগুলোর কনফিগারেশন সহজ করে। +ট্র্যাফিক রাউটিং এবং কনফিগারেশন পরিচালনার কেন্দ্রীকরণের মাধ্যমে, ইনগ্রেস সুবিন্যস্ত স্কেলেবিলিটি প্রদান করে, রিসোর্সের ব্যবহার অপ্টিমাইজ করে, খরচ কমায় এবং একটি ক্লাস্টারে চলমান অ্যাপ্লিকেশনগুলোর সামগ্রিক ব্যবস্থাপনার উন্নতি করে। diff --git a/content/bn/kubernetes.md b/content/bn/kubernetes.md index 415d3e7c38..0f47b84169 100644 --- a/content/bn/kubernetes.md +++ b/content/bn/kubernetes.md @@ -1,25 +1,33 @@ --- title: কুবারনেটিস (Kubernetes) -status: Completed +status: Completed category: প্রযুক্তি -tags: ["infrastructure", "fundamental", ""] +tags: ["অবকাঠামো", "মৌলিক", ""] --- -## এটা কি +কুবারনেটিস (Kubernetes), প্রায়ই K8s হিসাবে সংক্ষিপ্ত হয়, একটি ওপেন-সোর্স কন্টেইনার অর্কেস্ট্রেটর । + যা আধুনিক অবকাঠামোতে [কন্টেইনারাইজড (containerized)](/bn/container/) অ্যাপ্লিকেশনের জীবনচক্রকে স্বয়ংক্রিয় করে , এটি একটি "ডেটাসেন্টার অপারেটিং সিস্টেম" হিসাবে কাজ করে যা একটি [ডিস্ট্রিবিউটেড সিস্টেম](/bn/distributed-systems/) জুড়ে অ্যাপ্লিকেশনগুলোকে পরিচালনা করে। -কুবারনেটিস (Kubernetes), প্রায়ই K8s হিসাবে সংক্ষিপ্ত হয়, একটি ওপেন-সোর্স কন্টেইনার অর্কেস্ট্রেটর যা আধুনিক পরিকাঠামোতে [কন্টেইনারাইজড (containerized)](/bn/container/) অ্যাপ্লিকেশনের জীবনচক্রকে স্বয়ংক্রিয় করে। এটি একটি ডেটা সেন্টারের অপারেটিং সিস্টেমের মতো, যা অংশ-বিভাগিত সিস্টেম (Distributed System) জুড়ে চলমান অ্যাপ্লিকেশনগুলিকে পরিচালনা করে (ঠিক যেমন আপনার ল্যাপটপের OS আপনার অ্যাপগুলি পরিচালনা করে) ‍। +কুবারনেটিস একটি [ক্লাস্টারের](/bn/cluster.md) [নোড](/bn/nodes/) জুড়ে [কন্টেইনারের](/bn/container/) সময়সূচী নির্ধারণ করে , কন্টেইনারাইজড অ্যাপ্লিকেশনগুলো চালানোর জন্য বিভিন্ন ধরনের অবকাঠামো রিসোর্স (infrustructure resources) যেমন- লোড ব্যালেন্সার (Load Balancer), ক্রমাগত স্টোরেজ (Persistance Storage) ইত্যাদি একত্রিত করে। -কুবারনেটিস একটি [ক্লাস্টারের](cluster.md) নোড জুড়ে কন্টেইনারের সময়সূচী নির্ধারণ করে। এটিতে বিভিন্ন ধরনের ইনফ্রাস্টাকচার কনস্টাক্টস (infrustructure contructs)(যেমন- প্রিমিটিভস (primitives)), কোনো অ্যাপ্লিকেশনের ইনস্টেন্স, লোড ব্যালেন্সার (Load Balancer), পারসিস্টেন্ট স্টোরেজ (Persistance Storage) এবং অন্যান্য সার্ভিস একত্রিত করে অ্যাপ্লিকেশন বানানো হয়। - -কুবারনেটিস অটোমেশন (Automation) এবং এক্সটেনসিবিলিটি (Extensibility) সক্ষম করে এবং ব্যবহারকারীদেরকে পুনর্গঠনযোগ্য ও ঘোষণামূলকভাবে অ্যাপ্লিকেশন স্থাপন করতে দেয়। কুবারনেটিস ইকোসিস্টেমের সফ্টওয়্যার প্রডাক্ট এবং প্রজেক্টগুলি, কুবারনেটিস [এপিআই (API)](/bn/application-programming-interface/) প্রসারিত করার জন্য সেই অটোমেশন এবং এক্সটেনসিবিলিটির সুবিধা নেয়। কুবারনেটিসের অটোমেশনকে ব্যবহার করে, কুবারনেটিসের টুলসগুলিকে আরও অ্যাক্সেসযোগ্য করে তোলা হয় অভিজ্ঞ কুবারনেটিস অনুশীলনকারীদের কাছে। +কুবারনেটিস অটোমেশন (Automation) এবং সম্প্রসারণযোগ্যতা (Extensibility) সক্ষম করে এবং ব্যবহারকারীদেরকে পুনর্গঠনযোগ্য ও ঘোষণামূলকভাবে (নীচে দেখুন) অ্যাপ্লিকেশন স্থাপন করতে দেয়। +কুবারনেটিস এর [এপিআই (API)](/bn/application-programming-interface/) মাধ্যমে প্রসারণযোগ্য (extensible), অভিজ্ঞ কুবারনেটিস অনুশীলনকারীদের তাদের প্রয়োজন অনুযায়ী এর স্বয়ংক্রিয়তার সক্ষমতা লাভ করতে দেয়। ## এটা যেসব সমস্যাতে দৃষ্টিপাত করে -ইনফ্রাস্ট্রাকচার অটোমেশন (Infrastructure automation) এবং ঘোষণামূলক কনফিগারেশন ম্যানেজমেন্ট (Declarative Configuration Management) দীর্ঘকাল ধরে একটি গুরুত্বপূর্ণ ধারণা, এবং [ক্লাউড কম্পিউটিং](/bn/cloud-computing/) জনপ্রিয়তা অর্জন করায় এটি আরও বেশি চাপে পড়ে। কম্পিউট রিসোর্সের (compute resources) চাহিদা বৃদ্ধি পাওয়ায় কম সংখ্যক ইন্জিনিয়ারের সাথে সার্ভিস প্রদান করতে সংস্থাগুলি চাপ অনুভব করে, এবং এটি পূরণের জন্য নতুন প্রযুক্তি এবং কাজের পদ্ধতিরই প্রয়োজন হয়। উপরন্তু, ক্লাউড কম্পিউটিং-এর (Cloud computing) জনপ্রীয়তা কন্টেনারাইজেশনের (Containerization) সাথে যুক্ত ছিল এবং যে সংস্থাগুলি ঐতিহ্যগত ইনফ্রাস্ট্রাকচারকে (Traditional infrastructure), অটোমেট করতে ব্যস্ত ছিল তাদেরই কনফিগারেশন (Configuration) এবং ডিপ্লয়মেন্ট (Deployment) অটোমেশন করার জন্য একটি প্রক্রিয়ার প্রয়োজন পরে। +ইনফ্রাস্ট্রাকচার অটোমেশন (Infrastructure automation) এবং ঘোষণামূলক কনফিগারেশন ম্যানেজমেন্ট (Declarative Configuration Management) দীর্ঘকাল ধরে একটি গুরুত্বপূর্ণ ধারণা, এবং [ক্লাউড কম্পিউটিং](/bn/cloud-computing/) জনপ্রিয়তা অর্জন করায় এটি আরও বেশি চাপে পড়ে। +কম্পিউট রিসোর্সের (compute resources) চাহিদা বৃদ্ধি পাওয়ায় কম সংখ্যক ইন্জিনিয়ারের সাথে সার্ভিস প্রদান করতে সংস্থাগুলো চাপ অনুভব করে, এবং এটি পূরণের জন্য নতুন প্রযুক্তি এবং কাজের পদ্ধতিরই প্রয়োজন হয়। ## এটা কিভাবে সাহায্য করে -ঐতিহ্যগতভাবে ইনফ্রাস্ট্রাকচার এস কোড (Traditional infrastructure as code) টুলসগুলির মতোই একই রকম পদ্ধতিতে কুবারনেটিসও অটোমেশনে সাহায্য করে কিন্তু কুবারনেটিসে ভার্চুয়াল বা ফিজিক্যাল মেশিনের তুলনায় কনফিগারেশন ড্রিফ্টে (Configuration Drift) বেশি প্রতিরোধী কন্টেইনারগুলির সাথে কাজ করার সুবিধা রয়েছে। -কুবারনেটিস ঘোষণামূলকভাবে (declaratively) কাজ করে, যার মানে হল অপারেটররা কীভাবে কিছু করতে হবে সে সম্পর্কে নির্দেশনা প্রদান করার পরিবর্তে তারা যা করতে চায় সেটা সাধারণত ম্যানিফেস্ট (Manifest) ফাইল (যেমন YAML) হিসাবে বর্ণনা করে; কুবারনেটিস নিজে থেকেই "কিভাবে" করতে হবে সেটার যত্ন নেয়। এর ফলে কুবারনেটিস ইনফ্রাস্ট্রাকচার এস কোডের (Infrastructure as code) সাথে অত্যন্ত সামঞ্জস্যপূর্ণ। +প্রথাগত [কোড হিসাবে পরিকাঠামো](/bn/infrastructure-as-code/) টুলের মতো, কুবারনেটস অটোমেশনে সাহায্য করে তবে এতে কন্টেইনারগুলোর সাথে কাজ করার সুবিধা রয়েছে। +কনটেইনারগুলো [ভার্চুয়াল](/bn/virtual-machine/) বা ফিজিক্যাল মেশিনের তুলনায় কনফিগারেশন ড্রিফটের জন্য বেশি প্রতিরোধী। + +উপরন্তু, কুবারনেটিস ঘোষণামূলকভাবে (declaratively) কাজ করে, যার মানে হল অপারেটররা কীভাবে কিছু করতে হবে সে সম্পর্কে নির্দেশনা প্রদান করার পরিবর্তে তারা বর্ণনা করে — সাধারণত ম্যানিফেস্ট (Manifest) ফাইল (যেমন YAML) হিসাবে — অবকাঠামোটি কেমন হওয়া উচিত। +কুবারনেটিস নিজে থেকেই "কিভাবে" করতে হবে সেটার যত্ন নেয়। +এর ফলে কুবারনেটিস 'কোড হিসাবে পরিকাঠামো' (Infrastructure as code) এর সাথে অত্যন্ত সামঞ্জস্যপূর্ণ। -কুবারনেটিস নিজেও নিজের নিরাময় (self-heal) করে। এর মানে হল যে কুবারনেটিস নিশ্চিত করে ক্লাস্টারের প্রকৃত অবস্থা সর্বদা অপারেটরের পছন্দসই অবস্থার সাথে মেলে। কুবারনেটিস কোনো বিচ্যুতি সনাক্ত করলে, একটি কুবারনেটিস কন্ট্রোলার (Kubernetes Controller) কাজে নামে এবং সেটিকে ঠিক করে। সুতরাং এটি যে ইনফ্রাস্ট্রাকচার (Infrastructure) ব্যবহার করে তা ক্রমাগত পরিবর্তীত হতে পারে, তাই কুবারনেটিস ক্রমাগত স্বয়ংক্রিয়ভাবে পরিবর্তিত হতে থাকে এবং নিশ্চিত করে এটি যাতে পছন্দসই অবস্থার সাথে মেলে। +কুবারনেটিস নিজেও নিজের নিরাময় (self-heal) করে। +এর মানে হল যে কুবারনেটিস নিশ্চিত করে ক্লাস্টারের প্রকৃত অবস্থা সর্বদা অপারেটরের পছন্দসই অবস্থার সাথে মেলে। +কুবারনেটিস কোনো বিচ্যুতি শনাক্ত করলে, একটি কুবারনেটিস কন্ট্রোলার (Kubernetes Controller) কাজে নামে এবং সেটিকে ঠিক করে। +যদিও এটি যে অবকাঠামো (Infrastructure) ব্যবহার করে তা ক্রমাগত পরিবর্তীত হতে পারে, তাই কুবারনেটিস ক্রমাগত স্বয়ংক্রিয়ভাবে পরিবর্তিত হতে থাকে এবং নিশ্চিত করে এটি যাতে পছন্দসই অবস্থার সাথে মেলে। diff --git a/content/bn/load-balancer.md b/content/bn/load-balancer.md index ecc4a1f954..39c9fc2bfb 100644 --- a/content/bn/load-balancer.md +++ b/content/bn/load-balancer.md @@ -2,11 +2,9 @@ title: লোড ব্যালেন্সার (Load Balancer) status: Feedback Appreciated category: ধারণা -tags: ["infrastructure", "networking", ""] +tags: ["অবকাঠামো", "নেটওয়ার্কিং", ""] --- -## এটা কি - একটি লোড ব্যালেন্সার এমন একটি টুল যা একটি অ্যাপ্লিকেশনের একাধিক ইন্সটেন্স এর (instance) মধ্যে আগত অনুরোধগুলি (incoming requests) দক্ষতার সাথে বিতরণ করে। উদাহরণস্বরূপ একটি [মাইক্রোসার্ভিস](/bn/microservices-architecture/) আর্কিটেকচার নিন, যেখানে প্রতিটি পরিষেবা [অনুভূমিকভাবে স্কেল করা (Horizontal Scaling)](/bn/horizontal-scaling/) যেতে পারে। একটি লোড ব্যালেন্সার একটি স্কেলড মাইক্রোসার্ভিসের সামনে বসে এবং নিশ্চিত করে যেন একটি ইন্সটেন্সই বেশিরভাগ অনুরোধগুলি না পায়। ## এটা যেসব সমস্যাতে দৃষ্টিপাত করে @@ -15,4 +13,4 @@ tags: ["infrastructure", "networking", ""] ## এটা কিভাবে সাহায্য করে -লোড ব্যালেন্সারগুলি গতিশীলভাবে (dynamically) সমস্ত আগত অনুরোধগুলি একাধিক পরিষেবার মধ্যে বিতরণ করে, নিশ্চিত করে যে যখন অন্য পরিষেবাগুলো কেবল কয়েকটি বা কিছুই পায় না তখন কেউ একাই পরিষেবার সিংহভাগ যেন না পায়। সংক্ষেপে, এটি একটি সংজ্ঞায়িত স্কিমা অনুসরণ করে একাধিক পরিষেবা জুড়ে লোড ছড়িয়ে দেয় (অর্থাৎ, সমানভাবে বা শতাংশ-ভিত্তিক)। লোড ব্যালেন্সার একটি অ্যাপ্লিকেশনের সামগ্রিক কর্মক্ষমতা এবং শেষ পর্যন্ত ব্যবহারকারীর অভিজ্ঞতার জন্য অপরিহার্য। \ No newline at end of file +লোড ব্যালেন্সারগুলি গতিশীলভাবে (dynamically) সমস্ত আগত অনুরোধগুলি একাধিক পরিষেবার মধ্যে বিতরণ করে, নিশ্চিত করে যে যখন অন্য পরিষেবাগুলো কেবল কয়েকটি বা কিছুই পায় না তখন কেউ একাই পরিষেবার সিংহভাগ যেন না পায়। সংক্ষেপে, এটি একটি সংজ্ঞায়িত স্কিমা অনুসরণ করে একাধিক পরিষেবা জুড়ে লোড ছড়িয়ে দেয় (অর্থাৎ, সমানভাবে বা শতাংশ-ভিত্তিক)। লোড ব্যালেন্সার একটি অ্যাপ্লিকেশনের সামগ্রিক কর্মক্ষমতা এবং শেষ পর্যন্ত ব্যবহারকারীর অভিজ্ঞতার জন্য অপরিহার্য। diff --git a/content/bn/loosely-coupled-architecture.md b/content/bn/loosely-coupled-architecture.md index 9663d06b53..2be17a067f 100644 --- a/content/bn/loosely-coupled-architecture.md +++ b/content/bn/loosely-coupled-architecture.md @@ -1,8 +1,8 @@ --- title: শিথিল সংযোজিত স্থাপত্য (Loosely Coupled Architecture) status: Completed -category: ধারণা -tags: ["fundamental", "architecture", "property"] +category: বৈশিষ্ট্য +tags: ["মৌলিক", "স্থাপত্য", "বৈশিষ্ট্য"] --- শিথিল সংযোজিত স্থাপত্য হল সেই ধরনের স্থাপত্যশৈলী যেখানে প্রতিটি পৃথক উপাদান স্বাধীনভাবে তৈরি হয় ([ দৃঢ় সংবদ্ধ স্থাপত্য শৈলীর](/bn/tightly-coupled-architectures/) ঠিক বিপরীত )| অনেক সময় এর প্রতিটি উপাদানকে [মাইক্রোসার্ভিসেস আর্কিটেকচার](/bn/microservices-architecture/) হিসেবে চিহ্নিত করা যায় diff --git a/content/bn/managed-services.md b/content/bn/managed-services.md index cddf8faf52..5934663124 100644 --- a/content/bn/managed-services.md +++ b/content/bn/managed-services.md @@ -6,8 +6,6 @@ category: প্রযুক্তি tags: ["", "", ""] --- -## এটা কি - একটি ম্যানাজ্ড পরিষেবা হল একটি সফ্টওয়্যার অফার যেখানে অপারেশন এবং পরিচালনা তৃতীয় পক্ষ দ্বারা যত্ন নেওয়া হয়। উদাহরণগুলির মধ্যে একটি পরিষেবা অফার হিসাবে ডেটাবেস অন্তর্ভুক্ত রয়েছে যেমন Amazon-এর RDS বা Datadog-এর মতো একটি বাহ্যিক পর্যবেক্ষণ পরিষেবা৷ diff --git a/content/bn/microservices-architecture.md b/content/bn/microservices-architecture.md index 9f88b50ee9..3f6a9741f7 100644 --- a/content/bn/microservices-architecture.md +++ b/content/bn/microservices-architecture.md @@ -2,11 +2,9 @@ title: মাইক্রোসার্ভিসেস আর্কিটেকচার (Microservices Architecture) status: Completed category: প্রযুক্তি -tags: ["architecture", "fundamental", ""] +tags: ["স্থাপত্য", "মৌলিক", ""] --- -## এটা কি - অ্যাপ্লিকেশন ডেভেলপমেন্টে (Application Development) একটি আধুনিক পন্থা হলো মাইক্রোসার্ভিস (Microservice), যা ক্লাউড নেটিভ (Cloud Native) প্রযুক্তির সুবিধা নেয়। যেখানে আধুনিক অ্যাপ্লিকেশনগুলি, যেমন নেটফ্লিক্স(netflix) একটি একক অ্যাপ এর মত দেখায় কিন্তু এটি আসলে অনেকগুলি ছোট ছোট সার্ভিসের একত্রিত রূপ, সবগুলি একে অপরের সাথে আবদ্ধ ভাবে কাজ করে চলেছে। এই ক্ষেত্রে, কোনো অ্যাপ এর একটি একক পেজ যা আমাদের search, authenticate এবং ভিডিও দেখতে অনুমতি দেয় তা আসলে অনেকগুলি ছোট ছোট সার্ভিস দ্বারা চালিত হয়, যেখানে এক একটি সার্ভিস এক একটি বৈশিষ্ট্য সামলায়। সংক্ষেপে, মাইক্রোসার্ভিস বলতে একটি এপ্লিকেশন আর্কিটেকচার প্যাটার্ন (Application Architecture Pattern) কে বোঝানো হয় যা [মনোলিথিক এপ্লিকেশন (Monolithic Application)](/bn/monolithic_apps/) এর থেকে স্বাভাবিকত বিপরীত। ## এটা যেসব সমস্যাতে দৃষ্টিপাত করে diff --git a/content/bn/monolithic-apps.md b/content/bn/monolithic-apps.md index 9178d8ae39..8dc63812a4 100644 --- a/content/bn/monolithic-apps.md +++ b/content/bn/monolithic-apps.md @@ -2,10 +2,9 @@ title: মনোলিথিক অ্যাপ (Monolithic Apps) status: Completed category: ধারণা +tags: ["স্থাপত্য", "মৌলিক", ""] --- -## এটা কি - একটি মনোলিথিক অ্যাপ্লিকেশন একটি একক স্থাপনযোগ্য (deployable) প্রোগ্রামে সমস্ত কার্যকারিতা ধারণ করে। একটি অ্যাপ্লিকেশন তৈরি করার সময় এটি প্রায়শই শুরু করার সবচেয়ে সরল এবং সহজ পদ্ধতি। যাইহোক, একবার অ্যাপ্লিকেশন জটিলতায় বৃদ্ধি পেলে, মনোলিথগুলি বজায় রাখা কঠিন হয়ে উঠতে পারে। একই কোডবেসে আরও বেশি ডেভেলপার কাজ করার সাথে সাথে বিরোধপূর্ণ পরিবর্তনের সম্ভাবনা এবং ডেভেলপারদের মধ্যে আন্তঃব্যক্তিক যোগাযোগের প্রয়োজনীয়তা বৃদ্ধি পায়। diff --git a/content/bn/multitenancy.md b/content/bn/multitenancy.md index a4dfbd152c..33e815baa7 100644 --- a/content/bn/multitenancy.md +++ b/content/bn/multitenancy.md @@ -1,12 +1,10 @@ --- title: বহু মালিকানা (Multitenancy) status: Completed -category: সম্পত্তি -tags: ["architecture", "property", ""] +category: বৈশিষ্ট্য +tags: ["স্থাপত্য", "বৈশিষ্ট্য", ""] --- -## এটা কি - বহু মালিকানা (multitenancy) (বা মাল্টি-টেনেন্সি (multi-tenancy)) একটি একক সফ্টওয়্যার (software) ইনস্টলেশনকে (installation) বোঝায় যা একাধিক ভাড়াটেদের পরিষেবা দেয়। ভাড়াটে হল একজন ব্যবহারকারী, অ্যাপ্লিকেশন (application), বা ব্যবহারকারী/অ্যাপ্লিকেশনের একটি গোষ্ঠী যারা তাদের নিজস্ব ডেটা সেটে (data set) কাজ করার জন্য সফ্টওয়্যারটি (software) ব্যবহার করে। এই ভাড়াটেরা ডেটা ভাগ করে না (যদি না মালিকের দ্বারা স্পষ্টভাবে নির্দেশ দেওয়া হয়) এবং এমনকি একে অপরের বিষয়ে সচেতন নাও হতে পারে। diff --git a/content/bn/mutual-transport-layer-security.md b/content/bn/mutual-transport-layer-security.md index 6558f471eb..b23e499319 100644 --- a/content/bn/mutual-transport-layer-security.md +++ b/content/bn/mutual-transport-layer-security.md @@ -2,11 +2,9 @@ title: পারস্পরিক পরিবহন স্তর নিরাপত্তা (Mutual Transport Layer Security) status: Completed category: ধারণা -tags: ["security", "", ""] +tags: ["নিরাপত্তা", "নেটওয়ার্কিং", ""] --- -## এটা কি - মিউচুয়াল টিএলএস (এমটিএলএস) একটি প্রযুক্তি যা দুটি [পরিষেবা](/bn/service/) এর মধ্যে প্রেরিত বার্তাগুলি প্রমাণীকরণ এবং এনক্রিপ্ট করতে ব্যবহৃত হয়। মিউচুয়াল টিএলএস একটি [ট্রান্সপোর্ট লেয়ার সিকিউরিটি](/bn/transport-layer-security/) (টিএলএস) প্রোটোকল কিন্তু, শুধুমাত্র একটি সংযোগের পরিচয় যাচাই করার পরিবর্তে উভয় পক্ষকেই যাচাই করে। diff --git a/content/bn/nodes.md b/content/bn/nodes.md index 026e3f665f..0f7cec82dd 100644 --- a/content/bn/nodes.md +++ b/content/bn/nodes.md @@ -2,11 +2,9 @@ title: নোড (Nodes) status: Completed category: ধারণা -tags: ["infrastructure", "fundamental", ""] +tags: ["অবকাঠামো", "মৌলিক", ""] --- -## এটা কি - একটি নোড হল এমন একটি কম্পিউটার, যা অন্য কম্পিউটার বা নোডগুলির সহযোগিতায় একটি সাধারণ কাজ সম্পাদন করে। উদাহরণস্বরূপ আপনার ল্যাপটপ, মোডেম এবং প্রিন্টারকে ধরা যেতে পারে। এই ডিভাইসগুলো আপনার ওয়াইফাই নেটওয়ার্কের মাধ্যমে সংযোগ স্থাপন করে এবং একত্রে কাজ করে, প্রতিটি একটি নোডের প্রতিনিধিত্ব করে। [ক্লাউড কম্পিউটিং](/bn/cloud-computing/) এ, একটি নোড হতে পারে একটি ফিজিক্যাল কম্পিউটার, [ভার্চুয়াল মেশিন](/bn/virtual-machine/) নামে পরিচিত একটি ভার্চুয়াল কম্পিউটার বা একটি [কন্টেনার](/bn/container/)। ## এটা যেসব সমস্যাতে দৃষ্টিপাত করে diff --git a/content/bn/observability.md b/content/bn/observability.md index d513ea77be..d9e8b2341d 100644 --- a/content/bn/observability.md +++ b/content/bn/observability.md @@ -2,20 +2,15 @@ title: পর্যবেক্ষণযোগ্যতা (Observability) status: Completed category: ধারণা -tags: ["property", "", ""] +tags: ["বৈশিষ্ট্য", "", ""] --- -## এটা কি +পর্যবেক্ষণযোগ্যতা (Observability) হলো একটি সিস্টেমের বৈশিষ্ট্য যা ডিগ্রীকে সংজ্ঞায়িত করে যেখানে সিস্টেমটি কার্যযোগ্য অন্তর্দৃষ্টি (actionable insights) তৈরি করতে পারে। +এটি ব্যবহারকারীদের এই বাহ্যিক আউটপুটগুলি থেকে একটি সিস্টেমের অবস্থা বুঝতে এবং (সংশোধনমূলক) পদক্ষেপ নিতে দেয়। -পর্যবেক্ষণযোগ্যতা (Observability) হল পর্যবেক্ষণের অধীনে থাকা সিস্টেম থেকে সংকেতগুলির উপর ভিত্তি করে ক্রমাগত কার্যযোগ্য সূক্ষ্মদর্শিতা (continuous actionable insights) তৈরি এবং আবিষ্কার করার ক্ষমতা। অন্য কথায়, পর্যবেক্ষণযোগ্যতা ব্যবহারকারীদের বাহ্যিক আউটপুট থেকে একটি সিস্টেমের অবস্থা বুঝতে এবং (সংশোধনমূলক) পদক্ষেপ নিতে দেয়। +কম্পিউটার সিস্টেমগুলো পরিমাপ করা হয় নিম্ন-স্তরের সংকেত যেমন সিপিইউ সময়, মেমরি, ডিস্ক স্পেস এবং উচ্চ-স্তরের এবং ব্যবসায়িক সংকেতগুলো পর্যবেক্ষণ করে যার মধ্যে রয়েছে এপিআই প্রতিক্রিয়া সময়, ত্রুটি, প্রতি সেকেন্ডে লেনদেন ইত্যাদি । +এই পর্যবেক্ষণযোগ্য সিস্টেমগুলো **পর্যবেক্ষণ** করা হয় (বা মনিটর করা হয়) বিশেষ টুলসের মাধ্যমে, তথাকথিত পর্যবেক্ষণের টুল। এই টুলগুলির একটি তালিকা [ক্লাউড নেটিভ ল্যান্ডস্কেপের পর্যবেক্ষণ বিভাগে](https://landscape.cncf.io/card-mode?category=observability-and-analysis&grouping=category) দেখা যেতে পারে। -## এটা যেসব সমস্যাতে দৃষ্টিপাত করে +পর্যবেক্ষণযোগ্য সিস্টেমগুলো তাদের অপারেটরদের কাছে অর্থপূর্ণ, কার্যকরী ডেটা প্রদান করে, তাদের অনুকূল ফলাফল (দ্রুত ঘটনার প্রতিক্রিয়া, বিকাশকারীর উৎপাদনশীলতা (developer productivity) বৃদ্ধি) এবং কম পরিশ্রম এবং ডাউনটাইম অর্জন করতে দেয়। -কম্পিউটার সিস্টেমগুলি নিম্ন-স্তরের সংকেতগুলি যেমন CPU সময়, মেমরি, ডিস্ক স্পেস এবং উচ্চ-স্তরের এবং ব্যবসায়িক সংকেত, API প্রতিক্রিয়া সময়সহ, ত্রুটি, প্রতি সেকেন্ডে লেনদেন, ইত্যাদি সহ পরিমাপ করা হয়। - -একটি সিস্টেমের পর্যবেক্ষণযোগ্যতা তার অপারেটিং এবং উন্নয়ন খরচের উপর একটি উল্লেখযোগ্য প্রভাব ফেলে। -পর্যবেক্ষণযোগ্য সিস্টেমগুলি তাদের অপারেটরদের কাছে অর্থপূর্ণ, কার্যকরী ডেটা প্রদান করে, তাদের অনুকূল ফলাফল (দ্রুত ঘটনার প্রতিক্রিয়া, বিকাশকারীর উৎপাদনশীলতা (developer productivity) বৃদ্ধি) এবং কম পরিশ্রম এবং ডাউনটাইম অর্জন করতে দেয়। - -## এটা কিভাবে সাহায্য করে - -বুঝতে হবে যে শুধু অধিক তথ্যই আরও পর্যবেক্ষণযোগ্য সিস্টেমে তৈরি করে না। আদতে, কখনও কখনও, একটি সিস্টেম দ্বারা উৎপণ্য তথ্যের পরিমাণ অ্যাপ্লিকেশন দ্বারা উৎপণ্য কোলাহল থেকে মূল্যবান আকাঙ্ক্ষণীয় সংকেত সনাক্ত করা কঠিন করে তুলতে পারে। সঠিক সিদ্ধান্ত নেওয়ার জন্য পর্যবেক্ষণযোগ্যতার প্রয়োজন সঠিক সময়ে সঠিক ডাটা, সঠিক ভোক্তার জন্য (মানুষ অথবা সফ্টওয়্যারের অংশ)। \ No newline at end of file +ফলস্বরূপ, একটি সিস্টেম কতটা পর্যবেক্ষণযোগ্য তা এর অপারেটিং এবং বিকাশের খরচগুলোকে উল্লেখযোগ্যভাবে প্রভাবিত করবে। diff --git a/content/bn/platform-as-a-service.md b/content/bn/platform-as-a-service.md index eb804ec0f2..f03aa0836d 100644 --- a/content/bn/platform-as-a-service.md +++ b/content/bn/platform-as-a-service.md @@ -3,11 +3,9 @@ title: পরিষেবা হিসাবে একটি প্ল্যা status: Deprecated category: প্রযুক্তি draft: true -tags: ["fundamental", "platform", ""] +tags: ["মৌলিক", "প্ল্যাটফর্ম", ""] --- -## এটা কি - পরিষেবা হিসাবে একটি প্ল্যাটফর্ম, বা পিএএএস, হলো অ্যাপ্লিকেশন ডেভেলপমেন্ট টিমগুলিকে তাদের অ্যাপ্লিকেশনগুলি স্থাপন এবং চালানোর জন্য একটি বাহ্যিক প্ল্যাটফর্ম। হিরোকু, ক্লাউড ফাউন্ড্রি, অ্যাপ ইঞ্জিন পিএএএস অফারগুলির উদাহরণ। diff --git a/content/bn/pod.md b/content/bn/pod.md new file mode 100644 index 0000000000..045ee4ade1 --- /dev/null +++ b/content/bn/pod.md @@ -0,0 +1,30 @@ +--- +title: পড (Pod) +status: Completed +category: ধারণা +tags: ["অবকাঠামো", "মৌলিক", ""] +--- + +একটি [কুবারনেটিস (Kubernetes)](/bn/kubernetes/) পরিবেশের মধ্যে, একটি পড সবচেয়ে মৌলিক স্থাপনযোগ্য ইউনিট হিসাবে কাজ করে । +এটি কন্টেইনারাইজড অ্যাপ্লিকেশন স্থাপন এবং পরিচালনার জন্য একটি অপরিহার্য বিল্ডিং ব্লক হিসেবে প্রতিনিধিত্ব করে। +প্রতিটি পড একটি একক অ্যাপ্লিকেশনের দৃষ্টান্ত ধারণ করে এবং এক বা একাধিক [কন্টেইনার](/bn/container/) ধারণ করে রাখতে পারে। +কুবারনেটিস একটি বৃহত্তর স্থাপনার অংশ হিসাবে পডগুলো পরিচালনা করে এবং প্রয়োজন অনুসারে পডগুলো [উল্লম্বভাবে](/bn/vertical-scaling/) বা [অনুভূমিকভাবে](/bn/horizontal-scaling/) স্কেল করতে পারে। + +## এটা যেসব সমস্যাতে দৃষ্টিপাত করে + +যদিও কন্টেইনারগুলো সাধারণত স্বাধীন ইউনিট হিসাবে কাজ করে যা একটি নির্দিষ্ট কাজের চাপ পরিচালনা এবং নিয়ন্ত্রণ করে, +তবুও এমন কিছু ক্ষেত্রে রয়েছে যখন কন্টেইনারগুলোকে সম্মিলিতভাবে যোগাযোগ এবং নিয়ন্ত্রণ করতে হয়। + +যদি এই পরস্পর ঘনিষ্ঠভাবে সম্পর্কিত কন্টেইনারগুলোর প্রত্যেকটি পৃথকভাবে পরিচালিত করা হয়, তাহলে এটি অপ্রয়োজনীয় ব্যবস্থাপনার কাজগুলো তৈরি করবে। +উদাহরণস্বরূপ, অপারেটরকে বারবার সংশ্লিষ্ট কন্টেইনারগুলোর স্থান নির্ধারণ করতে হবে যাতে তারা একসাথে থাকে। +এবং যদিও এই পরস্পর সম্পর্কিত কন্টেইনারগুলোর জীবনচক্রগুলোকে সিঙ্ক্রোনাইজ ( একই সময় ঘটানো) করা প্রয়োজন, তবুও তখন সেগুলোকে শুধুমাত্র পৃথকভাবে পরিচালনা করা যাবে। + +## এটা কিভাবে সাহায্য করে + +পড কন্টেইনারগুলোকে ঘনিষ্ঠভাবে আবদ্ধ করে একটি ইউনিটে নিয়ে আসে, ফলে কন্টেইনার অপারেশনগুলো উল্লেখযোগ্যভাবে সহজতর হয়ে হয়। +উদাহরণস্বরূপ, অতিরিক্ত কার্যকারিতা যোগ করতে বা গ্লোবাল কনফিগারেশন সেট আপ করতে প্রায়শই প্রধান কন্টেইনারের পাশাপাশি গৌণ কন্টেইনার ব্যবহার করা হয়। +উদাহরণগুলোর মধ্যে অন্তর্ভুক্ত রয়েছে এমন কন্টেইনার যা অনুপ্রবেশ করে এবং মূল কন্টেইনারে মৌলিক সেটিংস (settings) প্রয়োগ করে, +_সাইডকার_ (কন্টেইনার) যা প্রধান কন্টেইনারের জন্য নেটওয়ার্ক ট্র্যাফিক রাউটিং পরিচালনা করে [ দেখুন [সার্ভিস মেশ (Service Mesh)](/bn/service-mesh/) ] , +অথবা প্রতিটি কন্টেইনারের সাথে সংযুক্ত লগ সংগ্রহকারী কন্টেইনারগুলো । + +মেমরি এবং সিপিইউ বরাদ্দকরণ করা যেতে পারে হয় একটি পড স্তরে ( যা ভিতরের কন্টেইনারগুলোকে সহজ উপায়ে রিসোর্সেস ভাগাভাগি করতে দেয়) অথবা প্রতি কন্টেইনারে। diff --git a/content/bn/policy-as-code.md b/content/bn/policy-as-code.md index d3d58fb44c..a71d551354 100644 --- a/content/bn/policy-as-code.md +++ b/content/bn/policy-as-code.md @@ -2,12 +2,10 @@ title: কোড হিসাবে নীতি (Policy as Code) status: Completed category: ধারণা -tags: ["methodology", "", ""] +tags: ["পদ্ধতি", "", ""] draft: --- -## এটা কি - কোড হিসাবে নীতি (PaC ) হলো মেশিন-পাঠযোগ্য এবং প্রক্রিয়াযোগ্য আকারে এক বা একাধিক ফাইল হিসাবে নীতিগুলির সংজ্ঞা সংরক্ষণের অনুশীলন। এটি ঐতিহ্যগত মডেলকে প্রতিস্থাপন করে যেখানে নীতিগুলি পৃথক নথিতে মানব-পাঠযোগ্য আকারে নথিভুক্ত করা হতো। diff --git a/content/bn/portability.md b/content/bn/portability.md index 4af70292f0..cd48515437 100644 --- a/content/bn/portability.md +++ b/content/bn/portability.md @@ -1,8 +1,8 @@ --- title: বহনযোগ্যতা (Portability) status: Completed -category: সম্পত্তি -tags: ["fundamental", "property", ""] +category: বৈশিষ্ট্য +tags: ["মৌলিক", "বৈশিষ্ট্য", ""] --- বহনযোগ্যতা হল একটি সফ্টওয়্যার বৈশিষ্ট্য এবং পুনঃব্যবহারযোগ্যতার একটি রূপ যা নির্দিষ্ট অপারেটিং পরিবেশে "আটকে যাওয়া" এড়াতে সাহায্য করে । diff --git a/content/bn/reliability.md b/content/bn/reliability.md index 5e047bfa63..4b5dc2a5cd 100644 --- a/content/bn/reliability.md +++ b/content/bn/reliability.md @@ -1,8 +1,8 @@ --- title: নির্ভরযোগ্যতা (Reliability) status: Completed -category: সম্পত্তি -tags: ["fundamental", "property", ""] +category: বৈশিষ্ট্য +tags: ["মৌলিক", "বৈশিষ্ট্য", ""] --- diff --git a/content/bn/role-based-access-control.md b/content/bn/role-based-access-control.md new file mode 100644 index 0000000000..54915c5fec --- /dev/null +++ b/content/bn/role-based-access-control.md @@ -0,0 +1,23 @@ +--- +title: রোল-বেসড অ্যাক্সেস কন্ট্রোল (আরবিএসি) [Role-Based Access Control (RBAC)] +status: Completed +category: ধারণা +tags: ["নিরাপত্তা"] +--- + +রোল-বেসড অ্যাক্সেস কন্ট্রোল (আরবিএসি) হলো একটি টিম বা বৃহত্তর সংস্থার মধ্যে ব্যবহারকারীদের ভূমিকার উপর ভিত্তি করে সিস্টেম, নেটওয়ার্ক বা রিসোর্সগুলোতে তাদের অ্যাক্সেস পরিচালনা করার একটি নিরাপত্তা পদ্ধতি। +আরবিএসি আইটি অ্যাডমিনিস্ট্রেটরদেরকে সমস্ত ব্যবহারকারীদের জন্য একটি নির্দিষ্ট কাজের ফাংশন সহ অ্যাক্সেসের প্রয়োজনীয় স্তর শনাক্ত করার এবং সেই ব্যবহারকারীদের একটি পূর্বনির্ধারিত অনুমতির সেট সহ একটি ভূমিকা অর্পণ করার ক্ষমতা দেয়৷ । +আরবিএসি ব্যবহার করে সংস্থাগুলো তাদের কর্মচারীদের তাদের ভূমিকা এবং দায়িত্ব অনুসারে বিভিন্ন স্তরের অ্যাক্সেস সরবরাহ করে থাকে । + +## এটা যেসব সমস্যাতে দৃষ্টিপাত করে + +আরবিএসি টিমের সদস্যরা এবং অ্যাপ্লিকেশনগুলো অ্যাক্সেস করতে পারে এমন রিসোর্সগুলো নিয়ন্ত্রণ করার চ্যালেঞ্জ মোকাবেলা করে +(সেইসাথে তারা যে কাজগুলো সম্পাদন করতে পারে) বিশেষ করে যখন অ্যাপ্লিকেশন এবং দলের সদস্যদের সংখ্যা বৃদ্ধি পেতে থাকে । +অ্যাডমিনিস্ট্রেটরদেরকে অবশ্যই নিশ্চিত করতে হবে যে প্রতিটি ব্যবহারকারীর কাছে তাদের প্রয়োজনীয় রিসোর্সগুলো অ্যাক্সেস করার জন্য সঠিক অনুমতি রয়েছে । +এই কাজটি কষ্টকর এবং ত্রুটিপূর্ণ হয়ে উঠতে পারে যদি না কাঠামোগত অ্যাক্সেস নিয়ন্ত্রণ ব্যবস্থা থাকে । + +## এটা কিভাবে সাহায্য করে + +আরবিএসি আইটি টিমগুলোকে একটি গ্রুপের সমস্ত ব্যবহারকারীর জন্য অনুমতিগুলোকে সহজে একযোগে পরিচালনা করার ক্ষমতা প্রদান করে অথবা একটি ভূমিকা বরাদ্দ বা সরিয়ে দেওয়ার মাধ্যমে একটি পৃথক ব্যবহারকারীর অ্যাক্সেস স্তরে দ্রুত সামঞ্জস্য করার ক্ষমতা দেয় ৷ +এটি সংবেদনশীল ডেটা রক্ষা করে এবং নিশ্চিত করে যে কর্মীরা শুধুমাত্র তাদের কাজের দায়িত্বগুলোর জন্য প্রয়োজনীয় তথ্য অ্যাক্সেস করতে পারে এবং কাজগুলো সম্পাদন করতে পারে । +সামগ্রিকভাবে, আরবিএসি অ্যাক্সেস ম্যানেজমেন্ট উন্নত করে, নিরাপত্তা জোরদার করে এবং সংস্থাগুলোর মধ্যে অপারেশনাল দক্ষতা বাড়ায় । diff --git a/content/bn/runtime.md b/content/bn/runtime.md new file mode 100644 index 0000000000..e82760742b --- /dev/null +++ b/content/bn/runtime.md @@ -0,0 +1,36 @@ +--- +title: রানটাইম (Runtime) +status: Completed +category: ধারণা +tags: ["অ্যাপ্লিকেশন"] +--- + +সাধারণত একটি রানটাইম সফ্টওয়্যারের একটি অংশকে কার্যকর করে। +এটি অন্তর্নিহিত অপারেটিং সিস্টেমের একটি [অ্যাবস্ট্রাকশন](/bn/abstraction/) যা প্রোগ্রামের কমান্ডগুলোকে অপারেটিং সিস্টেমের জন্য নিজ নিজ কাজে অনুবাদ করে দেয়। + +[ক্লাউড নেটিভের](/cloud-native-apps/) প্রসঙ্গে, _রানটাইম_ বলতে সাধারণত কন্টেইনার রানটাইমকে বোঝায়। +একটি কন্টেইনার রানটাইম বিশেষভাবে [ওপেন কন্টেইনার ইনিশিয়েটিভ](https://opencontainers.org/) এর নির্দেশনাকে বাস্তবায়ন করে যাতে ভিন্ন ভিন্ন [কন্টেইনার অর্কেস্ট্রেশন](/bn/container-orchestration/) প্রযুক্তির মাঝে সামঞ্জস্যপূর্ণ পরিচালনা নিশ্চিত করা যায়। + +## এটা যেসব সমস্যাতে দৃষ্টিপাত করে + +একটি কন্টেইনার রানটাইমের অ্যাবস্ট্রাকশন ছাড়া, অ্যাপ্লিকেশনটিকে প্রতিটি অপারেটিং সিস্টেমের সমস্ত মেকানিক্সের সাথে মোকাবিলা করতে হবে, যা অ্যাপটি চালানোর জটিলতা বৃদ্ধি করবে। + +## এটা কিভাবে সাহায্য করে + +কন্টেইনার রানটাইমগুলো কন্টেইনার অর্কেস্ট্রেটর যেমন [কুবারনেটিসের](/bn/kubernetes) একটি প্রয়োজনীয় উপাদান। +তারা কন্টেইনারের জীবনচক্র পরিচালনা করে, যা প্রধানত তিনটি কাজ করে। +প্রথমত, এটি নির্ধারণ করে যে কীভাবে কন্টেইনার চিত্রগুলো নির্দিষ্ট করা যায় এবং কীভাবে রানটাইম সেগুলোকে পুনরুদ্ধার করতে পারে। +দ্বিতীয়ত, তারা কীভাবে এই ছবিগুলো আনপ্যাক করা, স্তরযুক্ত করা , মাউন্ট করা এবং কার্যকর করা যায় তা পরিচালনা করে। +অতঃপর, রানটাইমগুলো এই সমস্ত অপারেটিং সিস্টেম-স্তরের ক্রিয়াগুলোর যত্ন নেওয়ার মাধ্যমে হার্ডওয়্যার রিসোর্সগুলো পরিচালনা করে। +এর মধ্যে রয়েছে সম্পদ বরাদ্দ এবং বিচ্ছিন্ন করা। +সময়ের সাথে সাথে, বিভিন্ন কন্টেইনার রানটাইম পণ্যগুলো বিকশিত হয়, +যা ওসিআই স্পেসিফিকেশনের দিকে নিয়ে যায়, যা কন্টেইনার রানটাইমের জন্য আদর্শ হয়ে উঠেছে। + +এই স্ট্যান্ডার্ডটি প্রবর্তন করার মাধ্যমে শেষ ব্যবহারকারীদের যেকোনও ওসিআই-অনুগত রানটাইমকে যেকোনও ওসিআই-অনুগত কন্টেইনার অর্কেস্ট্রেটরের সাথে একত্রিত করতে দেয় (যেমন কুবারনেটিস) + +## সম্পর্কিত পদ + +- [ক্লাউড নেটিভ](https://glossary.cncf.io/bn/cloud-native-apps/) +- [কন্টেইনারাইজেশন](https://glossary.cncf.io/bn/containerization/) +- [কন্টেইনার অর্কেস্ট্রেশন](https://glossary.cncf.io/bn/container-orchestration/) +- [মাইক্রোসার্ভিসেস আর্কিটেকচার](https://glossary.cncf.io/bn/microservices-architecture/) diff --git a/content/bn/scalability.md b/content/bn/scalability.md index 305140379b..1ef80dc529 100644 --- a/content/bn/scalability.md +++ b/content/bn/scalability.md @@ -1,8 +1,8 @@ --- title: মাপযোগ্যতা (Scalability) status: Completed -category: সম্পত্তি -tags: ["fundamental", "property", ""] +category: বৈশিষ্ট্য +tags: ["মৌলিক", "বৈশিষ্ট্য", ""] --- মাপযোগ্যতা বলতে বোঝায় একটি সিস্টেম কতটা ভালোভাবে বৃদ্ধি করতে পারে। সিস্টেমের যা করা উচিত তা করার ক্ষমতাকে এটি বৃদ্ধি করে। diff --git a/content/bn/security-chaos-engineering.md b/content/bn/security-chaos-engineering.md index 818858f73e..40f3769bf2 100644 --- a/content/bn/security-chaos-engineering.md +++ b/content/bn/security-chaos-engineering.md @@ -2,11 +2,9 @@ title: নিরাপত্তা বিশৃঙ্খলা ইঞ্জিনিয়ারিং (Security Chaos Engineering) status: Completed category: ধারণা -tags: ["security", "methodology", ""] +tags: ["নিরাপত্তা", "পদ্ধতি", ""] --- -## এটা কি - নিরাপত্তা বিশৃঙ্খলা ইঞ্জিনিয়ারিং অথবা SCE [বিশৃঙ্খলা ইঞ্জিনিয়ারিং](/bn/chaos-engineering/) এর উপর ভিত্তি করে একটি নিয়মানুবর্তিতা। কোলাহলপূর্ণ এবং দূষিত পরিস্থিতি সহ্য করার জন্য সিস্টেমের ক্ষমতার উপর আস্থা তৈরি করতে SCE একটি ডিসট্রিবিউটেড সিস্টেমে সক্রিয় নিরাপত্তা পরীক্ষা করে (proactive security experimentation)। নিরাপত্তা বিশৃঙ্খলা ইঞ্জিনিয়াররা এটি অর্জন করতে বৈজ্ঞানিক পদ্ধতি লুপ ব্যবহার করে, যার মধ্যে রয়েছে স্থির-স্থিতি (steady-state), হাইপোথিসিস, ক্রমাগত যাচাইকরণ, শিক্ষামূলক অভিজ্ঞতা (lesson learned) এবং প্রশমন (mitigation) বাস্তবায়ন। ## এটা যেসব সমস্যাতে দৃষ্টিপাত করে @@ -19,4 +17,4 @@ tags: ["security", "methodology", ""] এর লক্ষ্য "অজানার অজানা" উন্মোচন করা এবং সিস্টেমে আস্থা তৈরি করা, সাইবার স্থিতিস্থাপকতা বৃদ্ধি এবং পর্যবেক্ষণযোগ্যতা উন্নত করা। ইঞ্জিনিয়ারিং দলগুলি ধীরে ধীরে জটিল অবকাঠামো, প্ল্যাটফর্ম এবং ডিসট্রিবিউটেড সিস্টেমের মধ্যে নিরাপত্তা উদ্বেগের (security concerns) জন্য বোঝাপড়ার উন্নতি ঘটাবে। SCE সমগ্র পণ্যের সাইবার স্থিতিস্থাপকতা উন্নত করে, লুকানো নিরাপত্তা সমস্যাগুলি উন্মোচন করে, ক্লাসিক্যাল ব্লাইন্ড স্পটগুলিকে উন্মোচন করে, এবং গুরুত্বপূর্ণ প্রান্তের ক্ষেত্রে (critical edge cases) দলগুলিকে প্রস্তুত করে৷ -এই পদ্ধতি SREs, [DevOps](/bn/devops/) এবং [DevSecOps](/bn/devsecops/) ইঞ্জিনিয়ারদের সিস্টেমে আস্থা তৈরি করতে, সাইবার স্থিতিস্থাপকতা বাড়াতে এবং পর্যবেক্ষণযোগ্যতা উন্নত করতে সাহায্য করে। \ No newline at end of file +এই পদ্ধতি SREs, [DevOps](/bn/devops/) এবং [DevSecOps](/bn/devsecops/) ইঞ্জিনিয়ারদের সিস্টেমে আস্থা তৈরি করতে, সাইবার স্থিতিস্থাপকতা বাড়াতে এবং পর্যবেক্ষণযোগ্যতা উন্নত করতে সাহায্য করে। diff --git a/content/bn/self healing.md b/content/bn/self-healing.md similarity index 92% rename from content/bn/self healing.md rename to content/bn/self-healing.md index 90f1142271..0625dd08b0 100644 --- a/content/bn/self healing.md +++ b/content/bn/self-healing.md @@ -1,8 +1,8 @@ --- title: স্ব নিরাময়(Self Healing) status: Completed -category: সম্পত্তি -tags: ["infrastructure", "property"] +category: বৈশিষ্ট্য +tags: ["অবকাঠামো", "বৈশিষ্ট্য"] --- একটি স্ব-নিরাময় ব্যবস্থা কোনও মানুষের হস্তক্ষেপ ছাড়াই নির্দিষ্ট ধরণের ব্যর্থতা থেকে পুনরুদ্ধার করতে সক্ষম। diff --git a/content/bn/serverless.md b/content/bn/serverless.md index 3bf75fb628..ff9f3c6763 100644 --- a/content/bn/serverless.md +++ b/content/bn/serverless.md @@ -2,11 +2,9 @@ Title: সার্ভারহীন (Serverless) Status: Completed Category: প্রযুক্তি -tags: ["architecture", "", ""] +tags: ["স্থাপত্য", "", ""] --- -## এটা কি - সার্ভারলেস হল একটি ক্লাউড নেটিভ ডেভেলপমেন্ট মডেল যা ডেভেলপারদের সার্ভার পরিচালনা না করেই অ্যাপ্লিকেশন তৈরি এবং চালানোর অনুমতি দেয়। এখনও সার্ভারহীনে সার্ভার আছে, কিন্তু তারা অ্যাপ ডেভেলপমেন্ট থেকে [বিমূর্ত](/bn/abstraction/)(abstracted) দূরে। একজন ক্লাউড প্রদানকারী (cloud provider) সার্ভার পরিকাঠামোর প্রভিশনিং, রক্ষণাবেক্ষণ এবং [স্কেলিং](/bn/scalability/) এর রুটিন কাজ পরিচালনা করে। ডেভেলপাররা তাদের কোড কেবল স্থাপনের (deployment) জন্য [কন্টেইনার](/bn/container/) এ প্যাকেজ করতে পারে। একবার স্থাপন করা হয়ে গেলে, সার্ভারহীন অ্যাপগুলি চাহিদার (demand) প্রতি সাড়া দেয় এবং প্রয়োজন অনুসারে স্বয়ংক্রিয়ভাবে সার্ভারের ক্ষমতা বাড়ায় এবং কমায়। পাবলিক ক্লাউড প্রদানকারীদের সার্ভারহীন অফারগুলি সাধারণত একটি ইভেন্ট-চালিত (event-driven) এক্সিকিউশন মডেলের মাধ্যমে চাহিদা অনুযায়ী পরিমাপ করা হয়। ফলস্বরূপ, যখন একটি সার্ভারহীন ফাংশন নিষ্ক্রিয় বসে থাকে, তখন এটির জন্য কিছু খরচ হয় না। ## এটা যেসব সমস্যাতে দৃষ্টিপাত করে @@ -15,4 +13,4 @@ tags: ["architecture", "", ""] ## এটা কিভাবে সাহায্য করে -অন্যদিকে, সার্ভারহীন আর্কিটেকচারের ক্ষেত্রে, বিপরীতে, অ্যাপগুলি শুধুমাত্র প্রয়োজন অনুযায়ী চালু করা হয়। যখন একটি ইভেন্ট অ্যাপ কোড চালানোর জন্য ট্রিগার করে, তখন পাবলিক ক্লাউড প্রদানকারী ডাইনামিকভাবে সেই কোডের জন্য সম্পদ (resources) বরাদ্দ করে। কোডটি কার্যকর করা শেষ হলে ব্যবহারকারী অর্থ প্রদান বন্ধ করে দেয়। খরচ এবং দক্ষতাবৃদ্ধি সুবিধা ছাড়াও, সার্ভারলেস ডেভেলপারদের অ্যাপ স্কেলিং এবং সার্ভার প্রভিশনিংয়ের সাথে যুক্ত রুটিন এবং ছোট কাজ থেকে মুক্ত করে। সার্ভারহীন, রুটিন কাজ যেমন অপারেটিং সিস্টেম এবং ফাইল সিস্টেম পরিচালনা, নিরাপত্তা প্যাচ, লোড ব্যালেন্সিং, ক্যাপাসিটি ম্যানেজমেন্ট, স্কেলিং, লগিং এবং মনিটরিং সবই ক্লাউড সেবা প্রদানকারীর কাছে ছেড়ে দেয়। \ No newline at end of file +অন্যদিকে, সার্ভারহীন আর্কিটেকচারের ক্ষেত্রে, বিপরীতে, অ্যাপগুলি শুধুমাত্র প্রয়োজন অনুযায়ী চালু করা হয়। যখন একটি ইভেন্ট অ্যাপ কোড চালানোর জন্য ট্রিগার করে, তখন পাবলিক ক্লাউড প্রদানকারী ডাইনামিকভাবে সেই কোডের জন্য সম্পদ (resources) বরাদ্দ করে। কোডটি কার্যকর করা শেষ হলে ব্যবহারকারী অর্থ প্রদান বন্ধ করে দেয়। খরচ এবং দক্ষতাবৃদ্ধি সুবিধা ছাড়াও, সার্ভারলেস ডেভেলপারদের অ্যাপ স্কেলিং এবং সার্ভার প্রভিশনিংয়ের সাথে যুক্ত রুটিন এবং ছোট কাজ থেকে মুক্ত করে। সার্ভারহীন, রুটিন কাজ যেমন অপারেটিং সিস্টেম এবং ফাইল সিস্টেম পরিচালনা, নিরাপত্তা প্যাচ, লোড ব্যালেন্সিং, ক্যাপাসিটি ম্যানেজমেন্ট, স্কেলিং, লগিং এবং মনিটরিং সবই ক্লাউড সেবা প্রদানকারীর কাছে ছেড়ে দেয়। diff --git a/content/bn/service discovery.md b/content/bn/service-discovery.md similarity index 98% rename from content/bn/service discovery.md rename to content/bn/service-discovery.md index 8de75de1ec..a5cdfbd8e4 100644 --- a/content/bn/service discovery.md +++ b/content/bn/service-discovery.md @@ -2,12 +2,9 @@ title: সার্ভিস ডিসকভারি (Service Discovery) status: Completed category: ধারণা -tags: ["networking", "", ""] +tags: ["নেটওয়ার্কিং", "", ""] --- - -## এটা কি? - সার্ভিস ডিসকভারি হল পৃথক দৃষ্টান্ত খোঁজার প্রক্রিয়া যা একটি পরিষেবা তৈরি করে। একটি সার্ভিস ডিসকভারি সরঞ্জাম বিভিন্ন নোড বা শেষ পয়েন্টগুলির (endponint) হিসেব রাখে যা একটি পরিষেবা তৈরি করে। diff --git a/content/bn/service-mesh.md b/content/bn/service-mesh.md index 91809070cf..47bcf9c19a 100644 --- a/content/bn/service-mesh.md +++ b/content/bn/service-mesh.md @@ -2,6 +2,7 @@ title: সার্ভিস মেশ (Service Mesh) status: Completed category: প্রযুক্তি +tags: ["নেটওয়ার্কিং", "", ""] --- ## এটা কি diff --git a/content/bn/service-proxy.md b/content/bn/service-proxy.md index b2edfdd7fa..a70ce8b26c 100644 --- a/content/bn/service-proxy.md +++ b/content/bn/service-proxy.md @@ -2,10 +2,9 @@ title: সার্ভিস প্রক্সি (Service Proxy) status: Completed category: প্রযুক্তি +tags: ["নেটওয়ার্কিং", "", ""] --- -## এটা কি? - একটি সার্ভিস প্রক্সি একটি প্রদত্ত পরিষেবাতে ([service](/bn/service/)) বা সেখান থেকে ট্র্যাফিককে বাধা দেয়, এতে কিছু যুক্তি প্রয়োগ করে, তারপর সেই ট্র্যাফিকটিকে অন্য পরিষেবাতে অগ্রস্থ করে। এটি মূলত একটি "গো-বিটুইন (go-between)" হিসাবে কাজ করে যা নেটওয়ার্ক ট্র্যাফিক সম্পর্কে তথ্য সংগ্রহ করে এবং/অথবা এটিতে নিয়ম প্রয়োগ করে। ## এটা যেসব সমস্যাতে দৃষ্টিপাত করে diff --git a/content/bn/service.md b/content/bn/service.md index e883a5ee09..4d445e5768 100644 --- a/content/bn/service.md +++ b/content/bn/service.md @@ -2,7 +2,7 @@ title: পরিষেবা (Service) status: Completed category: ধারণা -tags: ["application", "fundamental", ""] +tags: ["অ্যাপ্লিকেশন", "মৌলিক", ""] --- দয়া করে মনে রাখবেন যে আইটি (IT)-তে, পরিষেবার একাধিক অর্থ রয়েছে। diff --git a/content/bn/shift-left.md b/content/bn/shift-left.md index 160961b0c6..2036dfd635 100644 --- a/content/bn/shift-left.md +++ b/content/bn/shift-left.md @@ -2,11 +2,9 @@ title: শিফট লেফট (Shift Left) status: Completed category: ধারণা -tags: ["methodology", "", ""] +tags: ["পদ্ধতি", "", ""] --- -## এটা কি - লেফট শিফটে লেফট একটি সফ্টওয়্যার ডেভেলপমেন্ট জীবনচক্রের প্রাথমিক পর্যায়গুলি বোঝায়, সফটওয়্যার জীবনচক্রকে এমন একটি লাইন হিসাবে বিবেচনা করো যেখানে পর্যায়গুলি বাম থেকে ডানে সম্পাদিত হয়। শিফট লেফট হ'ল সফ্টওয়্যার ডেভেলপমেন্ট জীবনচক্রের প্রথম দিকে পরীক্ষা, নিরাপত্তা বা অন্যান্য উন্নয়ন অনুশীলন বাস্তবায়নের অনুশীলন, শেষের দিকে না করে। diff --git a/content/bn/site-reliability-engineering.md b/content/bn/site-reliability-engineering.md index 0d4dff1708..48a117cf39 100644 --- a/content/bn/site-reliability-engineering.md +++ b/content/bn/site-reliability-engineering.md @@ -2,11 +2,9 @@ title: সাইট নির্ভরযোগ্যতা প্রকৌশল (Site Reliability Engineering) status: Completed category: ধারণা -tags: ["methodology", "", ""] +tags: ["পদ্ধতি", "", ""] --- -## এটা কি - সাইট রিলাইবিলিটি ইঞ্জিনিয়ারিং বা এসআরই এমন একটি শৃঙ্খলা যা অপারেশন এবং সফ্টওয়্যার ইঞ্জিনিয়ারিংকে একত্রিত করে। পরবর্তীটি বিশেষত অবকাঠামো এবং অপারেশন সমস্যাগুলিতে প্রয়োগ করা হয়। অর্থাৎ, পণ্য এর বৈশিষ্ট্য তৈরির পরিবর্তে, সাইট নির্ভরযোগ্যতা প্রকৌশলীরা অ্যাপ্লিকেশন চালানোর জন্য সিস্টেম তৈরি করে। diff --git a/content/bn/software-as-a-service.md b/content/bn/software-as-a-service.md index a9c4241615..249f93f213 100644 --- a/content/bn/software-as-a-service.md +++ b/content/bn/software-as-a-service.md @@ -2,11 +2,9 @@ Title: সফ্টওয়্যার এজ এ সার্ভিস(Software as a Service)(SaaS) Status: Deprecated Category: প্রযুক্তি -tags: ["fundamental", "platform", ""] +tags: ["মৌলিক", "প্ল্যাটফর্ম", ""] --- -## এটা কি - সফ্টওয়্যার এজ এ সার্ভিস (SaaS) ব্যবহারকারীদের ইন্টারনেটের মাধ্যমে ক্লাউড-ভিত্তিক পরিষেবাগুলির সাথে সংযোগ হতে এবং ব্যবহার করতে দেয়৷ সাধারণ উদাহরণ হল ইমেইল, ক্যালেন্ডারিং এবং অফিস টুল (যেমন Gmail, Amazon Web Services, GitHub, Slack)। সফ্টওয়্যার এজ এ সার্ভিস (SaaS) সম্পূর্ণ সফ্টওয়্যার সেবা প্রদান করে যা ব্যবহারকারী পে-এজ-ইউ-গো (Pay-as-you-go) অর্থাৎ যতটুকু সেবা গ্রহণ করা হবে ঠিক ততটুকুর অর্থ প্রদান এই ভিত্তিতে ব্যবহার করেন। সমস্ত অপারেশন এবং রক্ষণাবেক্ষণের কাজ এবং অ্যাপ্লিকেশন ডেটা পরিষেবা প্রদানকারী দ্বারা পরিচালিত হয়। ## এটা যেসব সমস্যাতে দৃষ্টিপাত করে diff --git a/content/bn/stateful-apps.md b/content/bn/stateful-apps.md index 86447f8b59..17806ca4f4 100644 --- a/content/bn/stateful-apps.md +++ b/content/bn/stateful-apps.md @@ -1,21 +1,16 @@ --- title: স্টেটফুল অ্যাপস (Stateful Apps) status: Completed -category: ধারণা -tags: ["fundamental", "application", " "] +category: বৈশিষ্ট্য +tags: ["মৌলিক", "অ্যাপ্লিকেশন", "বৈশিষ্ট্য"] --- -## এটা কি +যখন আমরা স্টেটফুল (এবং [স্টেটলেস](/bn/stateless-apps/)) অ্যাপগুলো সম্পর্কে বলি, +স্টেট বলতে মূলত এমন ডেটাকে বুঝাই যা কোন অ্যাপ সচল রাখার জন্য সংরক্ষণ করতে হয়। +উদাহরণস্বরূপ যেকোনো ধরনের অনলাইন শপ যা আপনার কার্টকে সংরক্ষন করে রাখে একটি স্টেটফুল অ্যাপ। -যখন আমরা স্টেটফুল (এবং স্টেটলেস) অ্যাপগুলি সম্পর্কে বলি, -স্টেট বলতে মূলত এমন ডেটাকে বুঝাই যা কোন অ্যাপ সচল রাখার জন্য সংরক্ষণ করতে হয়। উদাহরণস্বরূপ যেকোনো ধরনের অনলাইন শপ যা আপনার কার্টকে সংরক্ষন করে রাখে একটি স্টেটফুল অ্যাপ। +আজকাল আমাদের ব্যবহার করা অধিকাংশ অ্যাপ্লিকেশন কমপক্ষে আংশিকভাবে স্টেটফুল । যদিও ক্লাউড নেটিভ পরিবেশে, +স্টেটফুল অ্যাপস একটি চ্যালেঞ্জ। এর কারণ হলো [ক্লাউড নেটিভ অ্যাপগুলো](/bn/cloud-native-apps) খুব গতিশীল। +এগুলোকে উপরে এবং নীচে স্কেল করা যেতে পারে, রিস্টার্ট করা যেতে পারে , চারপাশে সরানো যেতে পারে কিন্তু তবুও তাদের স্টেট অ্যাক্সেস যোগ্য হওয়া দরকার। - -## এটা যেসব সমস্যাতে দৃষ্টিপাত করে - -একটি অ্যাপ্লিকেশন ব্যবহারের জন্য সাধারনত একাধিক অনুরোধের প্রয়োজন। যেমন অনলাইন ব্যাংকিং করতে, প্রথমে আপনার পাসওয়ার্ড দিয়ে আপনার প্রমাণীকরণ(authentication) করতে হবে(অনুরোধ # 1), তারপরে আপনি আপনার বন্ধুকে অর্থ স্থানান্তর করতে পারেন(অনুরোধ # 2), এবং অবশেষে, আপনি স্থানান্তরের বিবরণ দেখতে চাইবেন(অনুরোধ # 3)। সঠিকভাবে প্রক্রিয়াটি কাজ করতে, প্রতিটি পদক্ষেপের পূর্ববর্তী পদক্ষেপগুলি এবং ব্যাংকের প্রত্যেকের অ্যাকাউন্টের স্টেট মনে রাখতে হবে। আজকাল আমাদের ব্যবহার করা অধিকাংশ অ্যাপ্লিকেশন কমপক্ষে আংশিকভাবে স্টেটফুল, কারণ এগুলি ব্যবহারকারীর অভিজ্ঞতা উন্নয়ন করার জন্য ব্যাবহারকারির পছন্দনীয় বিষয়গুলো এবং সেটিংস জমা করে রাখে। - - -## এটা কিভাবে সাহায্য করে - -স্টেটফুল অ্যাপ্লিকেশনের স্টেট সংরক্ষণ করার কয়েকটি উপায় রয়েছে। সবচেয়ে সহজ উপায়টি হল স্টেট মেমোরিতে রাখা এবং কোথাও সংরক্ষণ না করা। এই প্রক্রিয়ার প্রধান সমস্যা হল, অ্যাপ্লিকেশনটি পুনরায় চালু করলে সমস্ত স্টেট হারিয়ে যাবে। এটি প্রতিরোধ করতে, স্টেটটি স্থানীয়ভাবে(ডিস্কে) বা ডাটাবেস সিস্টেমে সংরক্ষণ করা হয়। +অতএব, স্টেটফুল অ্যাপগুলোর এমন কিছু স্টোরেজ প্রয়োজন যা ডাটাবেসের মতো যে কোনও জায়গা থেকে অ্যাক্সেসযোগ্য। diff --git a/content/bn/stateless-apps.md b/content/bn/stateless-apps.md index b0ebc0b3ae..3a7d070af7 100644 --- a/content/bn/stateless-apps.md +++ b/content/bn/stateless-apps.md @@ -1,18 +1,15 @@ --- title: স্টেটলেস অ্যাপস (Stateless Apps) -status: Feedback Appreciated -category: প্রযুক্তি -tags: ["fundamental", "application", ""] +status: Completed +category: বৈশিষ্ট্য +tags: ["মৌলিক", "অ্যাপ্লিকেশন", "বৈশিষ্ট্য"] --- -## এটা কি +স্টেটলেস অ্যাপ্লিকেশনগুলো অনুরোধগুলোকে এমনভাবে প্রক্রিয়া করে যেন প্রতিটি অনুরোধই প্রথম বার পাঠানো হয়েছে। +অ্যাপটি ব্যবহারকারীর আগের ইন্টারঅ্যাকশন বা ব্যবহারকারীর সেশন ডেটা "মনে রাখে না"। +পূর্ববর্তী ইন্টারঅ্যাকশন থেকে ডেটাকে স্টেট হিসাবে উল্লেখ করা হয় এবং যেহেতু সেই ডেটা কোথাও সংরক্ষণ করা হয় না, এই অ্যাপগুলো স্টেটলেস। +এখানে একটি উদাহরণ দেওয়া হলো: +আপনি যখন একটি সার্চ ইঞ্জিন ব্যবহার করেন, এবং সেই অনুসন্ধানটি বাধাগ্রস্ত হয় (যেমন, উইন্ডোটি বন্ধ হয়ে যায়), সেই অনুসন্ধান ফলাফলগুলো হারিয়ে যায় । +তখন আপনাকে সব শুরু করতে হবে। -একটি স্টেটলেস অ্যাপ্লিকেশান সার্ভারে কোনও ক্লায়েন্ট সেশন (স্টেট) ডেটা সংরক্ষণ করে না যেখানে অ্যাপ্লিকেশনটি থাকে৷ প্রতিটি সেশন সঞ্চালিত হয় যেন এটি প্রথমবার ছিল এবং প্রতিক্রিয়াগুলি পূর্ববর্তী সেশনের ডেটার উপর নির্ভর করে না এবং প্রতিটি স্বল্পমেয়াদী অনুরোধ প্রক্রিয়া করার জন্য মুদ্রণ পরিষেবা, CDN (কন্টেন্ট ডেলিভারি নেটওয়ার্ক) বা ওয়েব সার্ভারগুলি ব্যবহার করার কার্যকারিতা প্রদান করে৷ উদাহরণস্বরূপ, কেউ সার্চ ইঞ্জিনে একটি প্রশ্ন অনুসন্ধান করছে এবং এন্টার বাটনে টিপেছে। কোনো কারণে এই সার্চিং অপারেশন ব্যাহত বা বন্ধ হয়ে গেলে, আপনাকে পুনরায় সার্চ করতে হবে কারণ আপনার পূর্ববর্তী সেশনের ডেটা সংরক্ষণ করা হয় না। - -## এটা যেসব সমস্যাতে দৃষ্টিপাত করে - -স্টেটলেস অ্যাপ্লিকেশনগুলো স্থিতিস্থাপকতার (resiliency) সমস্যা মোকাবেলা করে, কারণ একটি [ক্লাস্টার](/bn/cluster/) জুড়ে বিভিন্ন পড স্বাধীনভাবে কাজ করতে পারে, যদিও একই সময়ে একাধিক অনুরোধ তাদের কাছে আসে। যদি কোন সমস্যা হয়, আপনি সহজেই অ্যাপ্লিকেশনটি পুনরায় চালু করতে পারেন এবং এটি অল্প বা কোন ডাউনটাইম ছাড়াই তার প্রাথমিক অবস্থায় ফিরে আসবে। যেমন, স্টেটলেস অ্যাপ্লিকেশনের সুবিধার মধ্যে রয়েছে স্থিতিস্থাপকতা (resiliency), নমনীয়তা (elasticity) এবং উচ্চ প্রাপ্যতা (high availability)। তবে, আমাদের বর্তমানে ব্যবহার করা বেশিরভাগ অ্যাপ্লিকেশন অন্তত আংশিকভাবে [stateful](/bn/stateful-apps/), যেহেতু তারা ব্যবহারকারীর অভিজ্ঞতা উন্নত করতে ব্যবহারকারীর পছন্দ এবং সেটিংসের মতো জিনিস সংরক্ষণ করে। - -## এটা কিভাবে সাহায্য করে - -মোটকথা, একটি স্টেটলেস অ্যাপ্লিকেশনে আপনার ক্লাস্টারের জন্য দায়ী একমাত্র জিনিস হল কোড এবং অন্যান্য স্ট্যাটিক সামগ্রী, যা এটিতে হোস্ট করা হচ্ছে। এটাই স্টেটলেস অ্যাপস, পডটি মুছে ফেলার পরে কোনও ডেটাবেস পরিবর্তন করা হয়নি, কোনও লেখা নেই এবং কোনও ফাইল অবশিষ্ট নেই৷ স্টেটলেস [কন্টেইনার](/bn/container/) স্থাপন করা সহজ, এবং আপনাকে স্থায়ী স্টোরেজ (persistent storage) ভলিউমগুলিতে কন্টেইনার ডেটা সংরক্ষণের বিষয়ে চিন্তা করতে হবে না। আপনাকে ডেটা ব্যাক আপ করার বিষয়েও চিন্তা করতে হবে না। \ No newline at end of file +অন্যদিকে, যে অ্যাপ্লিকেশনগুলো অনুরোধগুলোকে প্রক্রিয়া করার সময় পূর্ববর্তী ইন্টারঅ্যাকশনগুলোকে বিবেচনা করে তাদের [স্টেটফুল অ্যাপস](/bn/stateful-apps/) বলা হয়। diff --git a/content/bn/style-guide/_index.md b/content/bn/style-guide/_index.md index 21a40034c2..24fc20c02c 100644 --- a/content/bn/style-guide/_index.md +++ b/content/bn/style-guide/_index.md @@ -9,14 +9,15 @@ menu: এই শৈলী নির্দেশিকা আপনাকে শব্দকোষের শ্রোতা, সংজ্ঞা কাঠামো, প্রয়োজনীয় বিশদ স্তর এবং কীভাবে একটি সামঞ্জস্যপূর্ণ শৈলী বজায় রাখতে হয় তা বুঝতে সাহায্য করবে। -ক্লাউড নেটিভ শব্দকোষ CNCF সংগ্রহস্থলের [ডিফল্ট স্টাইল গাইড](https://github.com/cncf/foundation/blob/master/style-guide.md) অনুসরণ করে। উপরন্তু, এটি নিম্নলিখিত নিয়ম অনুসরণ করে: +ক্লাউড নেটিভ শব্দকোষ CNCF সংগ্রহস্থলের [ডিফল্ট স্টাইল গাইড](https://github.com/cncf/foundation/blob/master/style-guide.md) অনুসরণ করে। +উপরন্তু, এটি নিম্নলিখিত নিয়ম অনুসরণ করে: 1. সহজ, সহজলভ্য ভাষা ব্যবহার করুন, প্রযুক্তিগত শব্দবাক্য এবং বাজওয়ার্ড এড়িয়ে চলুন 2. [কথ্যভাষা এড়িয়ে চলুন](https://en.wikipedia.org/wiki/Colloquialism) 3. [আক্ষরিক এবং কংক্রিট ভাষা ব্যবহার করুন](https://guidetogrammar.org/grammar/composition/abstract.htm) 4. [সংকোচন বাদ দিন](https://en.wikipedia.org/wiki/Contraction_(grammar)) 5. [প্যাসিভ ভয়েস অল্প ব্যবহার করুন](https://www.ef.com/ca/english-resources/english-grammar/passive-voice/) -6. [একটি ইতিবাচক আকারে বাক্যাংশের বিবৃতিগুলিকে লক্ষ্য করুন](https://examples.yourdictionary.com/positive-sentence-examples.html) +6. [একটি ইতিবাচক আকারে বাক্যাংশের বিবৃতিগুলোকে লক্ষ্য করুন](https://examples.yourdictionary.com/positive-sentence-examples.html) 7. [কোটেশনের বাইরে কোনো বিস্ময় চিহ্ন নেই](https://www.grammarly.com/blog/exclamation-mark/) 8. অতিরঞ্জিত করবেন না 9. পুনরাবৃত্তি এড়িয়ে চলুন @@ -24,7 +25,17 @@ menu: ## শ্রোতা -শব্দকোষটি প্রযুক্তিগত এবং অ-প্রযুক্তিগত দর্শকদের জন্য লেখা। অনুগ্রহ করে নিশ্চিত করুন যে সংজ্ঞাগুলি সহজ ভাষায় ব্যাখ্যা করা হয়েছে এবং প্রযুক্তিগত জ্ঞান গ্রহণ করবেন না। আরো যে সংজ্ঞা অধীনে নিচে রয়েছে । +শব্দকোষটি প্রযুক্তিগত *এবং* অ-প্রযুক্তিগত দর্শকদের জন্য লেখা। +অনুগ্রহ করে নিশ্চিত করুন যে সংজ্ঞাগুলো সহজ ভাষায় ব্যাখ্যা করা হয়েছে এবং প্রযুক্তিগত জ্ঞান গ্রহণ করবেন না। এই সম্পর্কে আরো নিচে [সংজ্ঞায়](#সংজ্ঞা) দেখুন । + +## ন্যূনতম কার্যকর সংজ্ঞা + +ক্লাউড নেটিভ শব্দগুলো যে কেউ বুঝতে পারে তার জন্য আমরা এটিকে সহজ করার লক্ষ্য রাখি। +যেমন, আমরা সরলতার উপর ফোকাস করি। +একটি *ন্যূনতম কার্যকর সংজ্ঞা* প্রদান করার সময় উদাহরণ সহ স্পষ্ট, সহজ ভাষা ব্যবহার করুন যাতে যে কেউ প্রযুক্তি ব্যবহার করে এ সম্পর্কে বুঝতে পারে । +আমরা কনটেক্স এবং উদাহরণগুলো সংরক্ষণ করতে চাই না ( সর্বোপরি, এই জিনিসগুলো পাঠককে ধারণাটি বুঝতে সাহায্য করে ) তবে এটি বোঝার জন্য যদি একটি টেকনিক্যাল ডিটেলস প্রয়োজন না হয় তবে আমরা এটি এড়িয়ে যাব৷ +আমাদের লক্ষ্য জিনিসগুলোকে অতিরিক্ত জটিল করা নয়। পাঠক মৌলিক ধারণাটি বুঝতে পারলে, অন্যান্য রিসোর্সগুলো তাদের আরও গভীরে যেতে করতে সহায়তা করবে। + সেই অংশটি এই শব্দকোষের আওতার বাইরে। ## সংজ্ঞা টেমপ্লেট @@ -37,9 +48,6 @@ status: category: --- - -## এটা কি - প্রযুক্তি বা ধারণার একটি দ্রুত সারাংশ। ## এটা যেসব সমস্যাতে ফোকাস করে @@ -63,15 +71,15 @@ title: সংজ্ঞা টেমপ্লেট ### Status -শিরোনাম লেবেলের পরে **status** লেবেল আসবে। স্থিতি লেবেল নির্দেশ করে যে সংজ্ঞাগুলি পুঙ্খানুপুঙ্খভাবে যাচাই করা হয়েছে বা আরও প্রচেষ্টার প্রয়োজন আছে কিনা। +Title লেবেলের পরে **status** লেবেল আসবে। স্থিতি লেবেল নির্দেশ করে যে সংজ্ঞাগুলি পুঙ্খানুপুঙ্খভাবে যাচাই করা হয়েছে বা আরও প্রচেষ্টার প্রয়োজন আছে কিনা। বৈধ মান হল: -- সম্পন্ন -- প্রতিক্রিয়া প্রশংসিত -- শুরু না +- Completed +- Feedback Appreciated +- Not Started -আপনি সর্বদা একটি সম্পূর্ণ সংজ্ঞার বিরুদ্ধে একটি issue খুলতে পারেন। একটি সংজ্ঞা প্রবাহিত হওয়ার সময়, এটির স্থিতি Feedback Appreciated এ পরিবর্তিত হবে। +আপনি সর্বদা একটি সম্পূর্ণ সংজ্ঞার বিরুদ্ধে একটি issue খুলতে পারেন। একটি সংজ্ঞা পরিবর্ধিত হওয়ার সময়, এটির স্টেটাস *Feedback Appreciated* এ পরিবর্তিত হবে। মনে রাখবেন যে আমাদের বৈধ স্টেটাস মান স্থানীয়করণ করা উচিত নয়। ```md --- @@ -79,54 +87,103 @@ title: সংজ্ঞা টেমপ্লেট status: Feedback Appreciated ``` -### Category +### Tags + +**Tag** লেবেল status লেবেল এর পরে আসে । +ট্যাগগুলো যাতে অর্থবহ হয় এবং ব্যবহারকারীর জন্য এইভাবে সহায়ক হয়, আমরা সেগুলোকে আক্ষরিক অর্থে ব্যবহার করব। +অনেকগুলো ট্যাগ প্রয়োগ করা শুধুমাত্র এর অর্থকে মিশ্রিত করবে ৷ +এর একটি ব্যতিক্রম হল `মৌলিক` ট্যাগ, যা নির্দেশ করে এই শব্দটি অন্যান্য ক্লাউড নেটিভ ধারণাগুলো বোঝার জন্য প্রয়োজন; বেশিরভাগ পদে সম্ভবত একটি ট্যাগ থাকবে। + +**দ্রষ্টব্য**: অনুগ্রহ করে শুধুমাত্র নতুন ট্যাগ প্রবর্তন করুন যদি রক্ষণাবেক্ষণকারীদের দ্বারা অনুমোদিত হয়। যখন আপনি একটি এন্ট্রিতে ট্যাগ যোগ করেন, নিশ্চিত করুন যে সেগুলো নীচে তালিকাভুক্ত হিসাবে ঠিক বানান করা হয়েছে (একবচন, কোনো টাইপিং সমস্যা নেই)। -**Category** লেবেলটি স্ট্যাটাস লেবেলের পরে আসবে। এর মান নিম্নলিখিত মানগুলির মধ্যে একটি হওয়া উচিত: +বর্তমান ট্যাগগুলো হলো : -- প্রযুক্তি -- সম্পত্তি -- ধারণা +- অ্যাপ্লিকেশন +- স্থাপত্য +- মৌলিক +- অবকাঠামো +- পদ্ধতি +- নেটওয়ার্কিং +- বৈশিষ্ট্য +- নিরাপত্তা ```md --- title: সংজ্ঞা টেমপ্লেট status: Feedback Appreciated -category: ধারণা +tags: ["ট্যাগ 1", "ট্যাগ 2", ""] --- ``` ### সংজ্ঞা -#### তিনটি উপশিরোনাম +#### দুইটি উপশিরোনাম -**প্রযুক্তি** এবং **ধারণা** বিভাগের সংজ্ঞায় তিনটি উপশিরোনাম রয়েছে: +**প্রযুক্তি** এবং **ধারণা** বিভাগের সংজ্ঞায় একটি দ্রুত সারাংশ এবং দুইটি উপশিরোনাম রয়েছে: -- **এটা কি**: আমরা যে বিষয়ে কথা বলছি তার একটি সংক্ষিপ্ত এবং স্পষ্ট ধারণা প্রদান করুন। -- **এটা যেসব সমস্যাতে ফোকাস করে**: সমস্যাটির উপর ফোকাস করুন, সমাধানের দিকে নয় (যা পরবর্তী বিভাগে আসে)। আসলে, সংজ্ঞায়িত শব্দটি উল্লেখ করা এড়িয়ে চলুন। সমস্যাটি আমাদের সেই জিনিসটির প্রয়োজন কিসের উপর তাতে আলোকপাত করে । -- **এটা কিভাবে সাহায্য কর** : এখন, মেয়াদে ফিরে আসুন। এটি কিভাবে উপরে বর্ণিত সমস্যার সমাধান করে? +- (দ্রুত সারাংশ) আমরা যে বিষয়ে কথা বলছি তার একটি সংক্ষিপ্ত এবং স্পষ্ট ধারণা প্রদান করুন। +- **এটা যেসব সমস্যাতে ফোকাস করে**: সমস্যাটির উপর ফোকাস করুন, সমাধানের দিকে নয় (যা পরবর্তী বিভাগে আসে)। + সংজ্ঞায়িত শব্দটি উল্লেখ করা এড়িয়ে চলুন। সমস্যাটি আমাদের সেই জিনিসটির প্রয়োজন কিসের উপর তাতে আলোকপাত করে । +- **এটা কিভাবে সাহায্য কর** : এখন, শব্দে ফিরে আসুন। এটি কিভাবে উপরে বর্ণিত সমস্যার সমাধান করে? মনে রাখবেন **বৈশিষ্ট্য**-এর আলাদা বিভাগের প্রয়োজন নেই। একটি সংজ্ঞা যথেষ্ট হবে। -#### জিনিসগুলি সহজ রাখুন +পর্যালোচনা সহজ করতে অনুগ্রহ করে **অর্থবোধক লাইন বিরতি** (প্রতি লাইনে একটি বাক্য) ব্যবহার করুন। + +#### গুণমান ই প্রধান + +মার্জড হলে, আপনার জমা দেওয়া হবে সেই শব্দের জন্য অফিসিয়াল CNCF সংজ্ঞা (যতক্ষণ না অন্য কেউ এটিকে উন্নত করে)। +CNCF-এর উচ্চ মান পূরণ করে এমন একটি শব্দ তৈরি করতে তাড়াহুড়ো করা যাবে না—গুণমানের জন্য সময় এবং প্রচেষ্টা লাগে। + +**আপনার গবেষণা করুন**: এমনকি যদি আপনি আত্মবিশ্বাসী হন যে আপনি শব্দটি জানেন, যাচাই করুন আপনি এটি ঠিক পেয়েছেন। +আমরা প্রায়শই সংস্থাগুলোতে একটি নির্দিষ্ট উপায়ে শব্দগুলো ব্যবহার করি যা সম্পূর্ণ চিত্রটি প্রতিফলিত নাও করতে পারে। +গবেষণা করার সময়, বিশেষ করে যখন আপনি শব্দটির সাথে 100% পরিচিত নন, একাধিক রিসোর্স ব্যবহার করুন। +অনেক সংজ্ঞা একতরফা, বিশেষ করে যদি একজন বিক্রেতা দ্বারা প্রদান করা হয়। +শব্দকোষে অবশ্যই বিক্রেতা-নিরপেক্ষ, বিশ্বব্যাপী স্বীকৃত সংজ্ঞা থাকতে হবে। + +**চুরি করবেন না**: একই নিয়ম শব্দকোষের ক্ষেত্রে অন্য যেকোনো গুরুতর প্রকাশনার ক্ষেত্রে প্রযোজ্য। +অন্য লোকেদের কাজ কপি এবং পেস্ট করবেন না যদি না আপনি এটিকে উদ্ধৃত করেন এবং তাদের সাথে অবদান রাখেন। +আপনি যদি একটি সংজ্ঞার একটি নির্দিষ্ট অংশ পছন্দ করেন, আপনার নিজের শব্দে এটি ব্যাখ্যা করুন। + +**রেফারেন্স অথরিটেটিভ রিসোর্স**: যখন সম্ভব, প্রজেক্ট ডক্সের মতো অথরিটেটিভ রিসোর্সগুলোর সাথে লিঙ্ক করুন। +মনে রাখবেন যে আমরা বিক্রেতাদের দ্বারা তৈরি কনটেন্টের সাথে লিঙ্ক করতে পারি না। + +#### জিনিসগুলো সহজ রাখুন -শব্দকোষের লক্ষ্য **জটিল ধারণাগুলিকে সহজ শব্দে ব্যাখ্যা করা** — এটি একটি আশ্চর্যজনকভাবে কঠিন কাজ যা সম্ভবত একাধিক সংশোধন করতে পারে। আপনার সংজ্ঞা খসড়া করার সময় সর্বদা দর্শকদের কথা মাথায় রাখুন। শিল্পের শর্তাবলী এবং বাজওয়ার্ডগুলি ব্যবহার করা এড়িয়ে চলুন - আপনি সম্ভবত তাদের কাছে ফিরে যেতে পারবেন এবং স্বয়ংক্রিয়ভাবে সংশোধন করতে হবে। +শব্দকোষের লক্ষ্য **জটিল ধারণাগুলোকে সহজ শব্দে ব্যাখ্যা করা** — এটি একটি আশ্চর্যজনকভাবে কঠিন কাজ যা সম্ভবত একাধিক সংশোধন করতে পারে। +আপনার সংজ্ঞা খসড়া করার সময় সর্বদা দর্শকদের কথা মাথায় রাখুন। +শিল্পের শর্তাবলী এবং বাজওয়ার্ডগুলো ব্যবহার করা এড়িয়ে চলুন - আপনি সম্ভবত তাদের কাছে ফিরে যেতে পারবেন এবং স্বয়ংক্রিয়ভাবে সংশোধন করতে হবে। উপযুক্ত হলে, **বাস্তব-জগতের উদাহরণ** ব্যবহার করুন যা পাঠকদের (বিশেষ করে অ-প্রযুক্তিগত) আরও ভালোভাবে বুঝতে সাহায্য করে কখন এবং কেন আপনি যে ধারণাটি ব্যাখ্যা করছেন তা প্রাসঙ্গিক। আপনার সংজ্ঞায় ব্যবহৃত হলে, সর্বদা **বিদ্যমান শব্দকোষের শর্তাবলীর সাথে লিঙ্ক করুন** (শুধুমাত্র প্রথম উল্লেখ হাইপারলিঙ্ক করা উচিত)। -**উদাহরণ**: [পরিষেবা মেশ সংজ্ঞা](/service-mesh/) এর “এটি কী” বিভাগটি একবার দেখুন। এটি মাইক্রোসার্ভিস, পরিষেবা, নির্ভরযোগ্যতা এবং পর্যবেক্ষণযোগ্যতার সংজ্ঞাগুলির সাথে লিঙ্ক করে। উপরন্তু, এটি একটি মাইক্রোসার্ভিসেস পরিবেশে নেটওয়ার্ক চ্যালেঞ্জের তুলনা করে একটি বাস্তব-বিশ্বের উদাহরণ ব্যবহার করে (এমন কিছু যা অ-প্রযুক্তিগত লোকেরা সম্পর্কিত হতে পারে না) ওয়াইফাই সমস্যার (যা কেউ ল্যাপটপ ব্যবহার করে বুঝতে পারে)সাথে । যেখানে সম্ভব, সেই সংযোগটি তৈরি করার চেষ্টা করুন। +**উদাহরণ**: [পরিষেবা মেশ সংজ্ঞা](/bn/service-mesh/) এর দ্রুত সারাংশ বিভাগটি একবার দেখুন। +এটি মাইক্রোসার্ভিস, পরিষেবা, নির্ভরযোগ্যতা এবং পর্যবেক্ষণযোগ্যতার সংজ্ঞাগুলোর সাথে লিঙ্ক করে। +উপরন্তু, এটি একটি মাইক্রোসার্ভিসেস পরিবেশে নেটওয়ার্ক চ্যালেঞ্জের তুলনা করে একটি বাস্তব-বিশ্বের উদাহরণ ব্যবহার করে (এমন কিছু যা অ-প্রযুক্তিগত লোকেরা সম্পর্কিত হতে পারে না) +ওয়াইফাই সমস্যার (যা কেউ ল্যাপটপ ব্যবহার করে বুঝতে পারে) সাথে । +যেখানে সম্ভব, সেই সংযোগটি তৈরি করার চেষ্টা করুন। #### একটি Google বা Word ডক দিয়ে শুরু করুন -আমরা একটি Google বা Word ডক দিয়ে শুরু করার পরামর্শ দিই, এটিকে কয়েক দিনের জন্য বসতে দিন এবং আবার দেখার জন্য। এটি আপনাকে বাক্যাংশ বা অভিব্যক্তিগুলি ধরতে দেয় যা একটি সহজ এবং আরও অ্যাক্সেসযোগ্য উপায়ে শব্দ করা যেতে পারে। এছাড়াও, PR জমা দেওয়ার আগে একটি বানান পরীক্ষা চালানো নিশ্চিত করুন। +আমরা একটি Google বা Word ডক দিয়ে শুরু করার পরামর্শ দিই, এটিকে কয়েক দিনের জন্য থাকতে দিন এবং বার বার দেখার জন্য। +এটি আপনাকে বাক্যাংশ বা অভিব্যক্তিগুলি ধরতে দেয় যা একটি সহজ এবং আরও অ্যাক্সেসযোগ্য উপায়ে শব্দ করা যেতে পারে। +এছাড়াও, PR জমা দেওয়ার আগে একটি বানান পরীক্ষা চালানো নিশ্চিত করুন। -একটি মেয়াদে কাজ করার সময় অন্য কেউ PR জমা না দেয় তা নিশ্চিত করতে, একটি সমস্যা দাবি করা (বা একটি তৈরি করুন) এবং এটি আপনাকে বরাদ্দ করা হয়েছে তা নিশ্চিত করুন। [কীভাবে অবদান রাখতে হয়](/bn/contribute/) ডক-এ আরও কিছু আছে যা দেখতে পারেন । +একটি শব্দে কাজ করার সময় অন্য কেউ PR জমা না দেয় তা নিশ্চিত করতে, একটি issue দাবি করা (বা একটি তৈরি করুন) এবং এটি আপনাকে বরাদ্দ করা হয়েছে তা নিশ্চিত করুন। +[কীভাবে অবদান রাখতে হয়](/bn/contribute/) ডক-এ আরও কিছু আছে যা দেখতে পারেন । -শুরু করার আগে, অনুগ্রহ করে কিছু প্রকাশিত শব্দকোষের পদ পড়ুন যাতে বিশদ এবং অসুবিধার মাত্রা এবং উদাহরণগুলি বোঝা যায়। +শুরু করার আগে, অনুগ্রহ করে কিছু প্রকাশিত শব্দকোষের পদ পড়ুন +যাতে ডিটেল এবং অসুবিধার মাত্রা এবং উদাহরণগুলো বোঝা যায়। ## পর্যালোচনা প্রক্রিয়া: কি আশা করা যায় -দয়া করে মনে রাখবেন যে আমরা বর্তমানে শুধুমাত্র তিনজন রক্ষণাবেক্ষণকারী তাদের অবসর সময়ে এটি করে। মাঝে মাঝে, আমরা দ্রুত শর্তাবলী পর্যালোচনা করতে সক্ষম হব; অন্যান্য অনুষ্ঠানে, এটি কিছুটা সময় নিতে পারে — আমরা আপনার ধৈর্যের প্রশংসা করি। আপনার যদি কোনো প্রশ্ন থাকে, তাহলে অনুগ্রহ করে #glossary Slack চ্যানেলে আমাদের সাথে যোগাযোগ করুন (কোথায় এবং কীভাবে এটি খুঁজে পাবেন, অনুগ্রহ করে আমাদের [কীভাবে অবদান রাখবেন](/bn/contribute/) ডকটি দেখুন । +দয়া করে মনে রাখবেন যে আমরা বর্তমানে শুধুমাত্র কয়েকজন রক্ষণাবেক্ষণকারী তাদের অবসর সময়ে এটি করে। +মাঝে মাঝে, আমরা দ্রুত শর্তাবলী পর্যালোচনা করতে সক্ষম হব; অন্যান্য অনুষ্ঠানে, এটি কিছুটা সময় নিতে পারে — আমরা আপনার ধৈর্যের আশা করি। +আপনার যদি কোনো প্রশ্ন থাকে, তাহলে অনুগ্রহ করে #glossary Slack চ্যানেলে আমাদের সাথে যোগাযোগ করুন +(কোথায় এবং কীভাবে এটি খুঁজে পাবেন, অনুগ্রহ করে আমাদের [কীভাবে অবদান রাখবেন](/bn/contribute/) ডকটি দেখুন । -আমাদের লক্ষ্য হল শব্দকোষ সর্বোত্তম সম্ভাব্য সম্পদ। একবার আপনি একটি PR জমা দিলে, আমরা এক বা একাধিক সংশোধনের জন্য জিজ্ঞাসা করতে পারি। হতাশ হবেন না — এটি অনেক PR -এর ক্ষেত্রে। সেই সব নিশ্চিত করবে যে আপনার অবদান একটি সত্যিকারের দরকারী সংজ্ঞা হয়ে উঠবে যা সারা বিশ্বের পাঠকদের দ্বারা পঠিত হবে। +আমাদের লক্ষ্য হলো শব্দকোষ সর্বোত্তম সম্ভাব্য রিসোর্স হোক । +একবার আপনি একটি PR জমা দিলে, আমরা এক বা একাধিক সংশোধনের জন্য জিজ্ঞাসা করতে পারি। +হতাশ হবেন না — এটি অনেক PR -এর ক্ষেত্রে। +সেই সব নিশ্চিত করবে যে আপনার অবদান একটি সত্যিকারের দরকারী সংজ্ঞা হয়ে উঠবে যা সারা বিশ্বের পাঠকদের দ্বারা পঠিত হবে। diff --git a/content/bn/tightly-coupled-architectures.md b/content/bn/tightly-coupled-architectures.md index 40cfcb33ba..3b77c4b6be 100644 --- a/content/bn/tightly-coupled-architectures.md +++ b/content/bn/tightly-coupled-architectures.md @@ -1,8 +1,8 @@ --- title: শক্তভাবে সংযোজিত স্থাপত্য (Tightly Coupled Architectures) status: Completed -category: সম্পত্তি -tags: ["fundamental", "architecture", "property"] +category: বৈশিষ্ট্য +tags: ["মৌলিক", "স্থাপত্য", "বৈশিষ্ট্য"] --- শক্তভাবে সংযোজিত স্থাপত্য হল সেই ধরনের একটি স্থাপত্য শৈলী যেখানে বেশ কয়েকটি অ্যাপ্লিকেশন উপাদান পরস্পর নির্ভরশীল diff --git a/content/bn/transport-layer-security.md b/content/bn/transport-layer-security.md index e67afff8a3..3aae39870a 100644 --- a/content/bn/transport-layer-security.md +++ b/content/bn/transport-layer-security.md @@ -1,12 +1,10 @@ --- title: ট্রান্সপোর্ট লেয়ার সিকিউরিটি (Transport Layer Security ) status: Completed -category: সম্পত্তি -tags: ["security", "networking", ""] +category: ধারণা +tags: ["নিরাপত্তা", "নেটওয়ার্কিং", ""] --- -## এটা কি - ট্রান্সপোর্ট লেয়ার সিকিউরিটি (TLS) হল একটি প্রোটোকল যা একটি নেটওয়ার্কের মাধ্যমে যোগাযোগের বর্ধিত নিরাপত্তা প্রদানের জন্য ডিজাইন করা হয়েছে। এটি ইন্টারনেটের মাধ্যমে পাঠানো ডেটার নিরাপদ ডেলিভারি নিশ্চিত করে, সম্ভাব্য পর্যবেক্ষণ এবং/অথবা ডেটার পরিবর্তন এড়ানো। diff --git a/content/bn/version-control.md b/content/bn/version-control.md index 7c4e690f49..65abee9f65 100644 --- a/content/bn/version-control.md +++ b/content/bn/version-control.md @@ -3,11 +3,9 @@ title: সংস্করণ নিয়ন্ত্রণ (Version control) status: Deprecated category: প্রযুক্তি draft: true -tags: ["methodology", "", ""] +tags: ["পদ্ধতি", "", ""] --- -## এটা কি - উত্স নিয়ন্ত্রণ (বা সংস্করণ নিয়ন্ত্রণ) হল একটি নথিতে পরিবর্তনগুলি ট্র্যাকিং এবং পরিচালনা করার অনুশীলন। এটি এমন একটি সিস্টেম যা সময়ের সাথে সাথে একটি ফাইল বা ফাইলের সেটে পরিবর্তন রেকর্ড করে যাতে আপনি পরে নির্দিষ্ট সংস্করণগুলি স্মরণ করতে পারেন। diff --git a/content/bn/vertical-scaling.md b/content/bn/vertical-scaling.md index 9e1ed6103b..ed1139bf4d 100644 --- a/content/bn/vertical-scaling.md +++ b/content/bn/vertical-scaling.md @@ -2,11 +2,9 @@ title: উল্লম্ব স্কেলিং (Vertical Scaling) status: Completed category: ধারণা -tags: ["infrastructure", "", ""] +tags: ["অবকাঠামো", "", ""] --- -## এটা কি - উল্লম্ব স্কেলিং, যা "উপর এবং নিচে স্কেলিং" নামেও পরিচিত, একটি কৌশল যেখানে কাজের চাপ বাড়ার সাথে সাথে পৃথক [নোড](/bn/nodes/) এ CPU এবং মেমরি যোগ করার মাধ্যমে একটি সিস্টেমের ক্ষমতা বৃদ্ধি করা হয়। ধরা যাক, আপনার কাছে 4GB RAM এর একটি কম্পিউটার আছে এবং এর ক্ষমতা 16GB RAM-এ বাড়াতে চান, diff --git a/content/bn/virtual-machine.md b/content/bn/virtual-machine.md index 7e51bcf201..ab6be99664 100644 --- a/content/bn/virtual-machine.md +++ b/content/bn/virtual-machine.md @@ -1,12 +1,10 @@ --- title: ভার্চুয়াল মেশিন (Virtual Machine) status: Completed -category: প্রযুক্তিবিদ্যা -tags: ["fundamental", "infrastructure", ""] +category: প্রযুক্তি +tags: ["মৌলিক", "অবকাঠামো", ""] --- -## এটা কি - ভার্চুয়াল মেশিন (Virtual Machine) হল একটি কম্পিউটার যার অপারেটিং সিস্টেম একটি নির্দিষ্ট হার্ডওয়্যারের সাথে আবদ্ধ নয়। একটি ফিজিক্যাল কম্পিউটারে, একাধিক ভার্চুয়াল কম্পিউটার বানাতে ভার্চুয়াল মেশিনগুলি ভার্চুয়ালাইজেশনের (Virtualization) উপর নির্ভরশীল। এই বিচ্ছেদটি সংস্থা এবং পরিকাঠামো প্রদানকারীদের অন্তর্নিহিত হার্ডওয়্যারকে প্রভাবিত না করে সহজেই ভার্চুয়াল মেশিন তৈরি এবং ধ্বংস করতে দেয়। ## এটা যেসব সমস্যাতে দৃষ্টিপাত করে diff --git a/content/bn/virtualization.md b/content/bn/virtualization.md index 523426e133..aef0c8b98a 100644 --- a/content/bn/virtualization.md +++ b/content/bn/virtualization.md @@ -2,30 +2,30 @@ title: ভার্চুয়ালাইজেশন (Virtualization) status: completed category: প্রযুক্তি -tags: ["fundamental", "infrastructure", "methodology"] +tags: ["মৌলিক", "অবকাঠামো", "পদ্ধতি"] --- -## এটা কি ভার্চুয়ালাইজেশন, ক্লাউড নেটিভ কম্পিউটিং প্রসঙ্গে, -একটি শারীরিক কম্পিউটার নেওয়ার প্রক্রিয়াকে বোঝায়, কখনও কখনও একটি সার্ভার বলা হয়, +একটি ফিজিক্যাল কম্পিউটার নেওয়ার প্রক্রিয়াকে বোঝায়, কখনও কখনও একটি সার্ভার বলা হয়, এবং এটি একাধিক বিচ্ছিন্ন অপারেটিং সিস্টেম চালানোর অনুমতি দেয়। সেই বিচ্ছিন্ন অপারেটিং সিস্টেম এবং তাদের ডেডিকেটেড কম্পিউট রিসোর্স (সিপিইউ, মেমরি এবং নেটওয়ার্ক) -ভার্চুয়াল মেশিন বা ভিএম হিসাবে উল্লেখ করা হয়। +ভার্চুয়াল মেশিন বা ভিএম (VM) হিসাবে উল্লেখ করা হয়। যখন আমরা একটি [ভার্চুয়াল মেশিন](/bn/virtual-machine/) সম্পর্কে কথা বলি, তখন আমরা একটি সফ্টওয়্যার-সংজ্ঞায়িত কম্পিউটারের কথা বলছি। -এমন কিছু যা দেখতে এবং একটি বাস্তব কম্পিউটারের মতো কাজ করে কিন্তু অন্যান্য ভার্চুয়াল মেশিনের সাথে হার্ডওয়্যার ভাগ করছে৷ +এমন কিছু দেখতে যা একটি বাস্তব কম্পিউটারের মতো কাজ করে, কিন্তু অন্যান্য ভার্চুয়াল মেশিনের সাথে হার্ডওয়্যার ভাগ করে৷ [ক্লাউড কম্পিউটিং](/bn/cloud-computing/) প্রাথমিকভাবে ভার্চুয়ালাইজেশন প্রযুক্তি দ্বারা চালিত। উদাহরণ হিসেবে, আপনি AWS থেকে একটি "কম্পিউটার" লিজ দিতে পারেন - সেই কম্পিউটারটি আসলে একটি VM। ## এটা যেসব সমস্যাতে দৃষ্টিপাত করে -ভার্চুয়ালাইজেশন শারীরিক হার্ডওয়্যার ব্যবহারের উন্নতি সহ বেশ কয়েকটি সমস্যার সমাধান করে -একই ফিজিক্যাল মেশিনে আরও অ্যাপ চালানোর অনুমতি দিয়ে -নিরাপত্তার জন্য একে অপরের থেকে বিচ্ছিন্ন থাকা অবস্থায়। +ভার্চুয়ালাইজেশন নিরাপত্তার জন্য একে অপরের থেকে বিচ্ছিন্ন থেকে একই অবস্থায় ফিজিক্যাল মেশিনে +আরও অ্যাপ চালানোর অনুমতি দেয় এবং +ফিজিক্যাল হার্ডওয়্যার ব্যবহারের উন্নতি সহ বেশ কয়েকটি সমস্যার সমাধান করে। -## এটা কিভাবে সাহায্য করে -ভার্চুয়াল মেশিনে চলমান অ্যাপগুলির কোন সচেতনতা নেই যে তারা একটি শারীরিক কম্পিউটার ভাগ করছে। -ভার্চুয়ালাইজেশন ডেটাসেন্টার ব্যবহারকারীদের মিনিটের মধ্যে একটি নতুন "কম্পিউটার" (ওরফে একটি ভিএম) স্পিন করতে দেয় -একটি ডেটাসেন্টারে একটি নতুন কম্পিউটার যোগ করার শারীরিক সীমাবদ্ধতার বিষয়ে চিন্তা না করে। +## এটা কিভাবে সাহায্য করে + +ভার্চুয়াল মেশিনে চলমান অ্যাপগুলির কোন সচেতনতা নেই, যে তারা একটি ফিজিক্যাল কম্পিউটার ভাগ করছে। +ভার্চুয়ালাইজেশন ডেটাসেন্টার ব্যবহারকারীদের একটি নতুন "কম্পিউটার" (ওরফে একটি VM) মিনিটের মধ্যে একটি ডেটাসেন্টারে +একটি নতুন কম্পিউটার যোগ করার ফিজিক্যাল সীমাবদ্ধতার বিষয়ে চিন্তা না করে স্পিন আপ করতে দেয়৷ ভিএমগুলি ব্যবহারকারীদের একটি নতুন ভার্চুয়াল কম্পিউটার পেতে সময় বাড়াতে সক্ষম করে। diff --git a/content/bn/zero-trust-architecture.md b/content/bn/zero-trust-architecture.md index 7599e4fc8d..764c0708ca 100644 --- a/content/bn/zero-trust-architecture.md +++ b/content/bn/zero-trust-architecture.md @@ -1,11 +1,10 @@ --- title: জিরো ট্রাস্ট আর্কিটেকচার (Zero Trust Architecture) status: Completed -category: নিরাপত্তা -tags: ["security", "", ""] +category: ধারণা +tags: ["নিরাপত্তা", "", ""] --- -## এটি কি জিরো ট্রাস্ট আর্কিটেকচার আইটি সিস্টেমের ডিজাইন এবং বাস্তবায়নের জন্য একটি নির্ধারিত পন্থা যেখানে 'ট্রাস্ট'(বিশ্বাস) সম্পূর্ণরূপে উপেক্ষা করা হয়। এই পন্থার মূল নীতি হল "বিশ্বাস নয়,সর্বদা যাচাই করা",ডিভাইস বা সিস্টেম,সিস্টেমের অন্যান্য অংশের সাথে যোগাযোগ করার সময় সর্বদা নিজেকে প্রথমে যাচাই করে। বর্তমানে অনেক নেটওয়ার্কে,কর্পোরেট নেটওয়ার্কের মধ্যে থাকা সিস্টেম এবং ডিভাইসগুলি অবাধে একটি অন্যটির সাথে যোগাযোগ করতে পারে কারণ সিস্টেম এবং ডিভাইসগুলি কর্পোরেট নেটওয়ার্ক পরিধির বিশ্বস্ত সীমার মধ্যে আবদ্ধ থাকে। অন্যদিকে জিরো ট্রাস্ট আর্কিটেকচার বিপরীত পদ্ধতি অবলম্বন করে যেখানে নেটওয়ার্ক পরিধির মধ্যেই সিস্টেমের অংশগুলি কোন যোগাযোগ স্থাপনের জন্য প্রথমে যাচাইকরণ পর্যায় অতিক্রম করে। diff --git a/content/de/search.md b/content/de/search.md new file mode 100644 index 0000000000..d9a4d5beef --- /dev/null +++ b/content/de/search.md @@ -0,0 +1,4 @@ +--- +title: Search Results +layout: search +--- \ No newline at end of file diff --git a/content/en/application-programming-interface.md b/content/en/application-programming-interface.md index ccb2c70396..137e68ffb1 100644 --- a/content/en/application-programming-interface.md +++ b/content/en/application-programming-interface.md @@ -21,4 +21,4 @@ Without a shared framework, it is challenging for applications to [scale](/scala APIs allow computer programs or applications to interact and share information in a defined and understandable manner. They are the building blocks for modern applications and they provide developers with a way to integrate applications together. -Whenever you hear about [microservices](/microservices/) working together, you can infer that they interact via an API. +Whenever you hear about [microservices](/microservices-architecture/) working together, you can infer that they interact via an API. diff --git a/content/en/chaos-engineering.md b/content/en/chaos-engineering.md index 99bc528637..f44589853a 100644 --- a/content/en/chaos-engineering.md +++ b/content/en/chaos-engineering.md @@ -15,7 +15,7 @@ techniques to increase product resiliency and [reliability](/reliability/). A system's ability to tolerate failures while ensuring adequate service quality is typically a software development requirement. There are several aspects involved that could lead to outages of an application, -like infrastructure, platform or other moving parts of a ([microservice](/microservices/)-based) application. +like infrastructure, platform or other moving parts of a ([microservice](/microservices-architecture/)-based) application. High-frequency deployment of new features to the production environment can result in a high probability of downtime and a critical incident — with considerable consequences to the business. diff --git a/content/en/cloud-computing.md b/content/en/cloud-computing.md index e8152f93fd..f92f709649 100644 --- a/content/en/cloud-computing.md +++ b/content/en/cloud-computing.md @@ -5,17 +5,21 @@ category: concept tags: ["infrastructure", "fundamental", ""] --- -Cloud computing offers compute resources like CPU, network, and disk capabilities on-demand over the internet, allowing users to access and use computing power in a remote physical location. -We generally differentiate between private and public cloud, depending on whether the cloud infrastructure is exclusively dedicated to an organization or shared for open public services. +Cloud computing offers CPU power, storage, and network capabilities over the internet, +enabling scalable and flexible access to resources across global data centers. +It spans private clouds, dedicated to single organizations for security and control, +and public clouds, open for widespread use, optimizing cost and scalability. ## Problem it addresses -Organizations traditionally faced two main challenges when attempting to expand computing power. -They could either acquire, support, and design (new) facilities to host their physical servers and network or expand and maintain existing ones. -Cloud computing solves that challenge by allowing organizations to outsource some of their computing needs. +Traditionally, organizations needing more computing capacity had to choose between costly investments in new server facilities or upgrades to existing infrastructure, a slow and resource-heavy process. ## How it helps -Cloud providers allow organizations to rent compute resources on-demand and pay for usage, delivering two key benefits. -First, organizations can focus on their product or service without waiting, planning, and spending resources on new physical infrastructure. And second, they can simply [scale](/scalability/) on-demand as needed. -Cloud computing allows organizations to adopt as much or as little infrastructure as they need. +Organizations can use cloud computing to rent computing resources on demand without the burden of managing physical infrastructure. +This strategy has two main advantages: +- It removes the delays and expenses of establishing new infrastructure so organizations can concentrate on their core business. +- Organizations can [scale](https://github.com/ronitblenz/glossary/blob/cloud_computing/content/en/scalability.md) their resources up or down based on demand, aligning infrastructure with business needs. +Thus, cloud computing provides an efficient way for organizations to access necessary infrastructure flexibly and economically without excess commitment. + +--- diff --git a/content/en/cloud-native-apps.md b/content/en/cloud-native-apps.md index 513bb17102..d57bcdcc9d 100644 --- a/content/en/cloud-native-apps.md +++ b/content/en/cloud-native-apps.md @@ -14,7 +14,7 @@ Cloud native applications today include apps that run in a cloud provider’s da ## Problem it addresses Traditionally, on-premise environments provided compute resources in a fairly bespoke way. -Each datacenter had services that [tightly coupled](/tightly-coupled-architectures/) applications to specific environments, +Each datacenter had services that [tightly coupled](/tightly-coupled-architecture/) applications to specific environments, often relying heavily on manual provisioning for infrastructure, like [virtual machines](/virtual-machine/) and services. This, in turn, constrained developers and their applications to that specific datacenter. Applications that weren't designed for the cloud couldn't take advantage of a cloud environment’s resiliency and scaling capabilities. diff --git a/content/en/container-orchestration.md b/content/en/container-orchestration.md index 504cdec363..124d2dce82 100644 --- a/content/en/container-orchestration.md +++ b/content/en/container-orchestration.md @@ -4,19 +4,19 @@ status: Completed category: Concept --- -[Container](/container/) orchestration refers to managing and automating the lifecycle of containerized applications in dynamic environments. -It's executed through a container orchestrator (in most cases, [Kubernetes](/kubernetes)), which enables deployments, (auto)scaling, auto-healing, and monitoring. +[Container](/container/) orchestration refers to managing and automating the lifecycle of [containerized](/containerization/) applications in dynamic environments. +It's executed through a container orchestrator (in most cases, [Kubernetes](/kubernetes/)), which enables deployments, (auto)scaling, auto-healing, and monitoring. Orchestration is a metaphor: -The orchestration tool conducts containers like a music conductor, ensuring every container (or musician) does what it should. +The orchestration tool conducts containers like a music conductor, ensuring every container (or musician) does what it should. -## Problem it addresses +## Problem it addresses -Managing [microservices](/microservices), security, and network communication at scale — and [distributed systems](/distributed-systems) in general — is hard, if not impossible, to manage manually. -Container orchestration allows users to automate all these management tasks. +Managing [microservices](/microservices-architecture/), security, and network communication at scale — and [distributed systems](/distributed-systems/) in general — is hard, if not impossible, to manage manually. +Container orchestration allows users to automate all these management tasks. ## How it helps -Container orchestration tools allow users to determine a system's state. +Container orchestration tools allow users to determine a system's state. First, they declare how it should look like (e.g., x containers, y pods, etc.). -The orchestration tool will then automatically monitor the infrastructure and correct it if its state deviates from the declared one (e.g., spin up a new container if one crashes). +The orchestration tool will then automatically monitor the infrastructure and correct it if its state deviates from the declared one (e.g., spin up a new container if one crashes). This automation simplifies many of the engineering teams' otherwise highly manual and complex operational tasks, including provisioning, deployment, scaling (up and down), networking, load balancing, and other activities. diff --git a/content/en/containerization.md b/content/en/containerization.md index 60b01eefe3..c4514feba4 100644 --- a/content/en/containerization.md +++ b/content/en/containerization.md @@ -5,13 +5,10 @@ category: Technology tags: ["application", "", ""] --- -Containerization is the process of bundling an application and its dependencies into a container image. -The container build process requires adherence to the [Open Container Initiative](https://opencontainers.org) (OCI) standard. -As long as the output is a container image that adheres to this standard, which containerization tool is used doesn't matter. - +Containerization is the process of packaging of application code including libraries and dependencies required to run the code into a single lightweight executable—called [container image](/container-image/). ## Problem it addresses -Before containers became prevalent, organizations relied on virtual machines (VMs) to +Before [containers](/container/) became prevalent, organizations relied on [virtual machines](/virtual-machine/) (VMs) to orchestrate multiple applications on a single [bare-metal machine](/bare-metal-machine/). VMs are significantly larger than containers and require a hypervisor to run. Due to the storage, backup, and transfer of these larger VM templates, creating the VM templates is also slow. diff --git a/content/en/continuous-delivery.md b/content/en/continuous-delivery.md index 9cec1a23d8..ca9afe0788 100644 --- a/content/en/continuous-delivery.md +++ b/content/en/continuous-delivery.md @@ -10,8 +10,9 @@ in which code changes are automatically deployed into an acceptance environment (or, in the case of continuous deployment, into production). CD crucially includes procedures to ensure that software is adequately tested before deployment and provides a way to rollback changes if deemed necessary. -Continuous integration (CI) is the first step towards continuous delivery -(i.e., changes have to merge cleanly before being tested and deployed). +[Continuous integration](/continuous-integration/) (CI) is the first step towards +continuous delivery (i.e., changes have to merge cleanly before being tested and +deployed). ## Problem it addresses @@ -26,7 +27,7 @@ deploying more changes at once and increasing the risk that something goes wrong CD strategies create a fully automated path to production that tests and deploys the software using various deployment strategies such as [canary](/canary-deployment/) or [blue-green](/blue-green-deployment/) releases. -This allows developers to deploy code frequently, giving them peace of mind that the new revision has been tested. +This allows developers to deploy code frequently, giving them peace of mind that the new revision has been tested. ## Related terms diff --git a/content/en/devops.md b/content/en/devops.md index 271e0147fb..d1169cefd4 100644 --- a/content/en/devops.md +++ b/content/en/devops.md @@ -11,7 +11,7 @@ DevOps calls for groups of engineers that work on small components (versus an en ## Problem it addresses -Traditionally, in complex organizations with [tightly-coupled](/tightly-coupled-architectures/) [monolithic apps](/monolithic-apps/), +Traditionally, in complex organizations with [tightly-coupled](/tightly-coupled-architecture/) [monolithic apps](/monolithic-apps/), work was generally fragmented between multiple groups. This led to numerous handoffs and long lead times. Each time a component or update was ready, it was placed in a queue for the next team. diff --git a/content/en/distributed-apps.md b/content/en/distributed-apps.md index ccf00e69bf..5933765e93 100644 --- a/content/en/distributed-apps.md +++ b/content/en/distributed-apps.md @@ -6,7 +6,7 @@ tags: ["architecture", "", ""] --- A distributed application is an application where the functionality is broken down into multiple smaller independent parts. -Distributed applications are usually composed of individual [microservices](/microservices/) +Distributed applications are usually composed of individual [microservices](/microservices-architecture/) that handle different concerns within the broader application. In a cloud native environment, the individual components typically run as [containers](/container/) on a [cluster](/cluster/). diff --git a/content/en/ebpf.md b/content/en/ebpf.md index a35f9be2f0..d927b8638d 100644 --- a/content/en/ebpf.md +++ b/content/en/ebpf.md @@ -1,7 +1,8 @@ --- title: eBPF status: Completed -category: architecture +category: Technology +tags: ["architecture", "networking", "security"] --- eBPF, or extended Berkeley Packet Filter, is a technology that allows small, sandboxed programs or scripts to run in the kernel space of a Linux system without having to change the kernel's source code or load Linux kernel modules. diff --git a/content/en/edge-computing.md b/content/en/edge-computing.md index a8c291df1e..a00bf0ebcb 100644 --- a/content/en/edge-computing.md +++ b/content/en/edge-computing.md @@ -4,7 +4,7 @@ status: Completed category: Technology --- -Edge computing is a [distributed system](/distributed-systems/) approach that shifts some storage and computing capacity from the primary data center to the data source. +Edge computing is a [distributed system](/distributed-systems/) approach that shifts some storage and computing capacity from the primary [data center](/data-center/) to the data source. The gathered data is computed locally (e.g., on a factory floor, in a store, or throughout a city) rather than sent to a centralized data center for processing and analysis. These local processing units or devices represent the system's edge, whereas the data center is its center. The output computed at the edge is then sent back to the primary data center for further processing. diff --git a/content/en/firewall.md b/content/en/firewall.md index 1fb551763d..f89f39b02c 100644 --- a/content/en/firewall.md +++ b/content/en/firewall.md @@ -13,7 +13,7 @@ Firewalls can be hardware, software, or a combination of the two. By default, a network will allow anyone to enter and depart as long as they follow the network's routing rules. Because of this default behavior, securing a network is challenging. -For example, in a [microservices](/microservices/)-based banking app, the services communicate with one another +For example, in a [microservices](/microservices-architecture/)-based banking app, the services communicate with one another by transmitting highly sensitive financial data through their network. A malicious actor may infiltrate the network, intercept communication, and do damage if there was no firewall in place. diff --git a/content/en/function-as-a-service.md b/content/en/function-as-a-service.md index 55cca7034a..61550110b8 100644 --- a/content/en/function-as-a-service.md +++ b/content/en/function-as-a-service.md @@ -5,30 +5,24 @@ category: Technology tags: ["infrastructure", "", ""] --- -Function as a Service (FaaS) is a type of [serverless](/serverless/) [cloud computing](/cloud-computing/) [service](/service/) -that allows executing code in response to events -without maintaining the complex infrastructure -typically associated with building and launching [microservices](/microservices/) applications. -With FaaS, users manage only functions and data while the cloud provider manages the application. -This allows developers to get the functions they need without paying for services when code isn’t running. +Function as a Service (FaaS) is a cloud computing model that provides a platform for executing event-triggered functions, allowing for automatic scaling without manual intervention. +At its essence, FaaS enables the deployment of individual functions that are activated by specific events, operate on a short-term basis, and then shut down, ensuring resources are not wasted. +This model supports an [autoscaling](/auto-scaling/) feature, enabling a function instance to be initiated per request and terminated post-execution, emphasizing its stateless nature. +Consequently, FaaS platforms can implement a true pay-as-you-go billing approach, eliminating costs when functions are dormant, distinguishing it from other models like [Platform as a Service (PaaS)](/platform-as-a-service/), which require continuous resource availability. ## Problem it addresses -In a traditional on-premises scenario, a business manages and maintains its own data center. -The business must invest in servers, storage, software, and other technologies -and potentially hire an IT staff or contractors to purchase, manage, and upgrade all the equipment and licenses. -The data center has to be built to meet peak demand, even when workloads decline and those resources stand idle. -Conversely, if the business grows quickly, the IT department might struggle to keep up. -Under a standard [Infrastructure-as-a-Service (IaaS)](/infrastructure-as-a-service/) cloud computing model, -users pre-purchase capacity units, meaning you pay a public cloud provider for always-on server components to run your apps. -It’s the user’s responsibility to scale up server capacity during times of high demand -and scale down when that capacity is no longer needed. -The cloud infrastructure necessary to run an app is active even when the app isn’t being used. +Traditionally, businesses have relied on maintaining on-premises data centers, necessitating substantial investment in hardware, software, and personnel. +This setup demands resources to be scaled to peak demand, resulting in underutilized assets during downtime. +Moreover, rapid business growth can overwhelm IT capabilities, leading to operational inefficiencies. +In contrast, [Infrastructure-as-a-Service (IaaS)](/infrastructure-as-a-service/) models, while offering cloud-based solutions, still place the onus of scaling resources on the user, requiring payment for continuous server availability irrespective of actual usage. ## How it helps -FaaS gives developers an [abstraction](/abstraction/) for running web applications in response to events without managing servers. -For example, uploading a file could trigger custom code that transcodes the file into various formats. -FaaS infrastructure will auto-scale the code for heavy use, -and the developer does not have to spend any time or resources building the code for [scalability](/scalability/). -Billing is based on computation time alone, which means businesses do not have to pay when the functions are not in use. +FaaS gives developers an [abstraction](/abstraction/) for running web applications in response to events, eliminating the need to manage server infrastructure. +For example, an action such as uploading a file could trigger custom code that transcodes the file into various formats. +The FaaS infrastructure automatically adjusts resources to match demand, freeing developers from the complexities of coding for [scalability](/scalability/). +Charges apply solely for the duration of computation, ensuring no costs accrue when functions are inactive. + +For more information, refer to the [Serverless](/serverless/) glossary entry. +Although "serverless" and "FaaS" are often used as interchangeable terms, they embody distinct concepts. \ No newline at end of file diff --git a/content/en/ingress.md b/content/en/ingress.md index a12ddda629..eaab61d4e5 100644 --- a/content/en/ingress.md +++ b/content/en/ingress.md @@ -15,14 +15,14 @@ The ingress controller is the web server technology that actually performs the r Cloud Native web applications consist of multiple services, and often, those [services](/service/) need to be accessible over the internet for users to visit using their browser. To make these services user accessible while using [Kubernetes](/kubernetes/) to run this application, we need to expose each application service to the outside world. The most straightforward way would be to use a Kubernetes Load Balancer Service. -Creating such a Kubernetes Load Balancer Service results in a new component on the underlying infrastructure. +But creating such a service results in a new component on the underlying infrastructure. This not only introduces new costs and management overhead, but each newly created Load Balancer has its own external IP address. This leads to a bad user experience, because as a user, we don’t want to browse different URLs to access an application. ## How it helps An Ingress resource allows you to configure how traffic is balanced and routed to an application’s services. -The ingress controller is a web server that allows for a single entry point through a URL (www.example-url.com) and does the actual routing and balancing based on different URL paths (www.example-url.com/path). +The ingress controller exposes a single entry point through a URL (www.example-url.com) and does the actual routing and balancing based on different URL paths (www.example-url.com/path). An Ingress controller is a component that runs within the cluster and interprets the rules defined in the Ingress resource. It is up to the cluster operators where the web app runs to choose a specific Ingress controller from a set of possible technologies like Nginx, Traefik, HAProxy, etc. So now, if an application consists of multiple services, the user can access it using a single URL. diff --git a/content/en/load-balancer.md b/content/en/load-balancer.md index 861dd4033d..89a8ca6b23 100644 --- a/content/en/load-balancer.md +++ b/content/en/load-balancer.md @@ -6,7 +6,7 @@ tags: ["infrastructure", "networking", ""] --- A load balancer is a tool that efficiently distributes incoming requests among multiple instances of an application. -Take a [microservice](/microservices/) architecture for example, where each service can be [scaled horizontally](/horizontal-scaling/). +Take a [microservice](/microservices-architecture/) architecture for example, where each service can be [scaled horizontally](/horizontal-scaling/). A load balancer sits in front of a scaled microservice and ensures that no one instance gets the bulk of the requests. Load balancers can be software or hardware-based. diff --git a/content/en/loosely-coupled-architecture.md b/content/en/loosely-coupled-architecture.md index 8244d14332..0bccb3a1d9 100644 --- a/content/en/loosely-coupled-architecture.md +++ b/content/en/loosely-coupled-architecture.md @@ -5,15 +5,15 @@ category: Property tags: ["fundamental", "architecture", "property"] --- -Loosely coupled architecture is an architectural style -where the individual components of an application are built independently from one another -(the opposite paradigm of [tightly coupled architectures](/tightly-coupled-architectures/)). -Each component, sometimes referred to as a [microservice](/microservices/), is built to perform a specific function -in a way that can be used by any number of other services. -This pattern is generally slower to implement than tightly coupled architecture +Loosely coupled architecture is an architectural style +where the individual components of an application are built independently from one another +(the opposite paradigm of [tightly coupled architectures](/tightly-coupled-architecture/)). +Each component, sometimes referred to as a [microservice](/microservices-architecture/), is built to perform a specific function +in a way that can be used by any number of other services. +This pattern is generally slower to implement than tightly coupled architecture but has a number of benefits, particularly as applications scale. -Loosely coupled applications allow teams to develop features, deploy, and scale independently, -which allows organizations to iterate quickly on individual components. -Application development is faster and teams can be structured around their competency, -focusing on their specific application. +Loosely coupled applications allow teams to develop features, deploy, and scale independently, +which allows organizations to iterate quickly on individual components. +Application development is faster and teams can be structured around their competency, +focusing on their specific application. diff --git a/content/en/microservices-architecture.md b/content/en/microservices-architecture.md index 9badc03ad0..81c11b5117 100644 --- a/content/en/microservices-architecture.md +++ b/content/en/microservices-architecture.md @@ -5,31 +5,31 @@ tags: ["architecture", "fundamental", ""] --- A microservices architecture is an architectural approach that breaks applications into individual independent (micro)[services](/service/), with each service focused on a specific functionality. -These services work together closely, appearing to the end user as a single entity. -Take Netflix as an example. -Its interface allows you to access, search, and preview videos. +These services work together closely, appearing to the end user as a single entity. +Take Netflix as an example. +Its interface allows you to access, search, and preview videos. These capabilities are likely powered by smaller services that each handle one functionality, e.g., authentication, search, and running previews in your browser. This architectural approach allows developers to push out new features or update functionality much faster than if they were all tightly coupled, such as in a [monolithic application](/monolithic-apps/) (more to that below). ## Problem it addresses -Applications are made up of different parts, each responsible for a specific capability. -Demand for a particular functionality will not necessarily increase or decrease with demand for other app parts. -Going back to our Netflix example. -Let's say that after a big marketing campaign, Netflix experiences a big spike in signups, but streaming has remained more or less stable in the early hours of the day. -The surge in signups demands more signup capacity. -Traditionally (monolithic approach), the entire app would have to be [scaled](/scalability/) to accommodate the increase — a very inefficient use of resources. +Applications are made up of different parts, each responsible for a specific capability. +Demand for a particular functionality will not necessarily increase or decrease with demand for other app parts. +Going back to our Netflix example. +Let's say that after a big marketing campaign, Netflix experiences a big spike in signups, but streaming has remained more or less stable in the early hours of the day. +The surge in signups demands more signup capacity. +Traditionally (monolithic approach), the entire app would have to be [scaled](/scalability/) to accommodate the increase — a very inefficient use of resources. -Monolithic architectures also make it easy for developers to succumb to design pitfalls. -Because all the code is in one place, it is easier to make that code [tightly coupled](/tightly-coupled-architectures/) and harder to enforce the principle of separation of concerns. -Monoliths also often require developers to understand the entire codebase before deploying any changes. -Microservices architecture is a response to these challenges. +Monolithic architectures also make it easy for developers to succumb to design pitfalls. +Because all the code is in one place, it is easier to make that code [tightly coupled](/tightly-coupled-architecture/) and harder to enforce the principle of separation of concerns. +Monoliths also often require developers to understand the entire codebase before deploying any changes. +Microservices architecture is a response to these challenges. ## How it helps -Separating functionality into different microservices makes them easier to deploy, update, and scale independently. -It also allows different teams to work simultaneously on a small part of a bigger application without inadvertently negatively impacting the rest of the app. -While a microservices architecture solves many problems, it also creates operational overhead — the things you need to deploy and keep track of increase by order of magnitude. +Separating functionality into different microservices makes them easier to deploy, update, and scale independently. +It also allows different teams to work simultaneously on a small part of a bigger application without inadvertently negatively impacting the rest of the app. +While a microservices architecture solves many problems, it also creates operational overhead — the things you need to deploy and keep track of increase by order of magnitude. Many [cloud-native technologies](/cloud-native-tech/) aim to make microservices easier to deploy and manage. diff --git a/content/en/monolithic-apps.md b/content/en/monolithic-apps.md index c0bc6de7c7..db8b617754 100644 --- a/content/en/monolithic-apps.md +++ b/content/en/monolithic-apps.md @@ -13,7 +13,7 @@ the likelihood of conflicting changes and the need for interpersonal communicati ## Problem it Addresses -Devolving an application into [microservices](/microservices/) increases its operational overhead +Devolving an application into [microservices](/microservices-architecture/) increases its operational overhead — there are more things to test, deploy, and keep running. Early in a product’s lifecycle, it may be advantageous to defer this complexity and build a monolithic application until the product is determined successful. diff --git a/content/en/mutual-transport-layer-security.md b/content/en/mutual-transport-layer-security.md index 9e50ae05bf..3f6cb98a7b 100644 --- a/content/en/mutual-transport-layer-security.md +++ b/content/en/mutual-transport-layer-security.md @@ -11,7 +11,7 @@ instead of validating the identity of just one connection, both sides are valida ## Problem it addresses -[Microservices](/microservices/) communicate over a network and, +[Microservices](/microservices-architecture/) communicate over a network and, just like your wifi network, communication in transit over that network can be hacked. mTLS ensures that no unauthorized party can listen in on or impersonate legitimate requests. diff --git a/content/en/observability.md b/content/en/observability.md index c7baf913ba..013f26c883 100644 --- a/content/en/observability.md +++ b/content/en/observability.md @@ -9,7 +9,7 @@ Observability is a system property that defines the degree to which the system c It allows users to understand a system's state from these external outputs and take (corrective) action. Computer systems are measured by observing low-level signals such as CPU time, memory, disk space, and higher-level and business signals, including API response times, errors, transactions per second, etc. -These observable systems are **observed** (or monitored) through specialized tools, so-called observability tools. A list of these tools can be viewed in the [Cloud Native Landscape's observability section](https://landscape.cncf.io/card-mode?category=observability-and-analysis&grouping=category). +These observable systems are **observed** (or monitored) through specialized tools, so-called observability tools. A list of these tools can be viewed in the [Cloud Native Landscape's observability section](https://landscape.cncf.io/?group=projects-and-products&view-mode=card#observability-and-analysis--observability). Observable systems yield meaningful, actionable data to their operators, allowing them to achieve favorable outcomes (faster incident response, increased developer productivity) and less toil and downtime. diff --git a/content/en/platform-as-a-service.md b/content/en/platform-as-a-service.md index 47bbd94501..df16098a7c 100644 --- a/content/en/platform-as-a-service.md +++ b/content/en/platform-as-a-service.md @@ -11,7 +11,7 @@ Heroku, Cloud Foundry, App Engine are examples of PaaS offerings. ## Problem it addresses -To take advantage of cloud native patterns like [microservices](/microservices/) or [distributed applications](/distributed-apps/), +To take advantage of cloud native patterns like [microservices](/microservices-architecture/) or [distributed applications](/distributed-apps/), operations teams and developers need to be able to offload a significant amount of operations and maintenance work. These include tasks like provisioning infrastructure, handling [service discovery](/service-discovery/) and load balancing, and [scaling](/scalability/) applications. diff --git a/content/en/security-chaos-engineering.md b/content/en/security-chaos-engineering.md index 0affd08570..3d6dcc9b9b 100644 --- a/content/en/security-chaos-engineering.md +++ b/content/en/security-chaos-engineering.md @@ -29,5 +29,5 @@ Engineering teams will progressively improve the understanding for security conc within complex infrastructure, platforms, and distributed systems. SCE improves the cyber resiliency of the entire product, uncovers hidden security issues, exposes the classical blind spots, and prepares teams for critical edge cases. -This approach helps SREs, [DevOps](/devops/) and [DevSecOps](/devsecops/) engineers +This approach helps [SREs](/site-reliability-engineering/), [DevOps](/devops/) and [DevSecOps](/devsecops/) engineers create confidence in the system, increase cyber resiliency and improve observability. diff --git a/content/en/serverless.md b/content/en/serverless.md index c3fd0841db..17a824a49c 100644 --- a/content/en/serverless.md +++ b/content/en/serverless.md @@ -5,29 +5,28 @@ Category: Technology tags: ["architecture", "", ""] --- -Serverless is a cloud native development model that allows developers to -build and run applications without having to manage servers. -While servers do still exist within the serverless paradigm, they are [abstracted](/abstraction/) away from the application development process. -A cloud provider handles the routine work of provisioning, maintaining, and [scaling](/scalability/) the server infrastructure. -Developers can conveniently package their code into [containers](/container/) for deployment. -Once deployed, serverless apps respond to demand and automatically scale up and down as needed. -Serverless offerings from public cloud providers are usually metered on-demand through an event-driven execution model. -Consequently, when a serverless function is in an idle state, there are no associated costs. + +Serverless Computing [abstracts](/abstraction/) servers away from the user. +Operational management falls to the service provider, including handling physical machines and VM provisioning. +Service providers can be public cloud entities or internal IT departments serving their development teams. +These providers offer user interfaces such as SDKs, CLIs, or OCI-compliant runtimes, focusing on code and deployment tasks. +Charges are based on a pay-per-use model. +[Scaling](/scalability/) and resource provisioning for computing, storage, or networking are automatically adjusted based on application demand without user intervention. +A serverless platform provider consolidates resources to serve multiple users on a single physical machine, ensuring isolation through virtualization, especially with [VMs](/virtual-machine/). + +Serverless is a comprehensive term encompassing services with these attributes, extending from [Platform-as-a-Service (PaaS)](/platform-as-a-service/) to [Software-as-a-Service (SaaS)](/software-as-a-service/). ## Problem it addresses -Under a standard [Infrastructure-as-a-Service (IaaS)](/infrastructure-as-a-service/) [cloud computing](/cloud-computing/) model, -users pre-purchase units of capacity, meaning you pay a public cloud provider for always-on server components to run your apps. -It’s the user’s responsibility to scale up server capacity during times of high demand and -to scale down when that capacity is no longer needed. -The cloud infrastructure required to operate an application remains active even when the application is not in use. +In traditional [Infrastructure-as-a-Service (IaaS)](/infrastructure-as-a-service/) [cloud computing](/cloud-computing/) models, users commit to a predefined capacity, resulting in charges for continuous server availability regardless of actual use. +Responsibility for adjusting server capacity to meet fluctuating demands falls on the user, maintaining active infrastructure even during idle periods. ## How it helps -Contrasting with traditional approaches, the serverless architecture launches applications only when they are needed. -When an event triggers app code to run, the public cloud provider dynamically allocates resources for that code. -The user stops paying when the code finishes executing. -In addition to the cost and efficiency benefits, -serverless frees developers from routine and menial tasks associated with app scaling and server provisioning. -With serverless, routine tasks such as managing the operating system and file system, security patches, -load balancing, capacity management, scaling, logging, and monitoring are all offloaded to a cloud services provider. +Serverless architecture introduces a more efficient approach, activating services solely upon demand. +This model ensures dynamic resource allocation by a cloud provider, eliminating costs for unused services. +Beyond financial and operational efficiencies, serverless technology relieves developers of the burdens of scaling applications and managing server infrastructure. +Tasks such as operating system maintenance, security updates, load balancing, capacity planning, and monitoring are delegated to the cloud provider, streamlining the development process. + +Refer to the [Function-as-a-Service (FaaS)](/function-as-a-service/) glossary entry for more information. +Although "serverless" and "FaaS" are often used as interchangeable terms, they embody distinct concepts. diff --git a/content/en/service-mesh.md b/content/en/service-mesh.md index 31309f07ce..edc67cac2a 100644 --- a/content/en/service-mesh.md +++ b/content/en/service-mesh.md @@ -5,7 +5,7 @@ category: technology tags: ["networking", "", ""] --- -In a [microservices](/microservices/) world, apps are broken down into multiple smaller [services](/service/) that communicate over a network. +In a [microservices](/microservices-architecture/) world, apps are broken down into multiple smaller [services](/service/) that communicate over a network. Just like your wifi network, computer networks are intrinsically unreliable, hackable, and often slow. Service meshes address this new set of challenges by managing traffic (i.e., communication) between services and adding [reliability](/reliability/), [observability](/observability/), and security features uniformly across all services. diff --git a/content/en/service.md b/content/en/service.md index 0aff4c4721..d0edc8e2f2 100644 --- a/content/en/service.md +++ b/content/en/service.md @@ -9,4 +9,4 @@ Please note that in IT, service has multiple meanings. In this definition, we'll focus on the more traditional one: service as in microservice. How or even if services differ from microservices is nuanced and different people may have different opinions. For a high-level definition, we'll treat them as the same. -Please refer to the [microservices](/microservices/) definition. +Please refer to the [microservices](/microservices-architecture/) definition. diff --git a/content/en/stateful-apps.md b/content/en/stateful-apps.md index a59499c64e..4412df8f9e 100644 --- a/content/en/stateful-apps.md +++ b/content/en/stateful-apps.md @@ -5,12 +5,12 @@ category: Property tags: ["fundamental", "application", "property"] --- -When we speak of stateful (and [stateless](/stateless-apps/)) apps, -state refers to any data the app needs to store to function as designed. -Any kind of online shop that remembers your cart is a stateful app for example. +When we speak of stateful (and [stateless](/stateless-apps/)) apps, +state refers to any data the app needs to store to function as designed. +Any kind of online shop that remembers your cart is a stateful app for example. -Today, most applications we use are at least partly stateful. In cloud native environments though, -stateful apps are a challenge. This is because [cloud native apps](/cloud-native-apps) are very dynamic. +Today, most applications we use are at least partly stateful. In cloud native environments though, +stateful apps are a challenge. This is because [cloud native apps](/cloud-native-apps/) are very dynamic. They can be scaled up and down, restarted, and moved around but still need to be able to access their state. Therefore, stateful apps needs some kind of storage that is accessible from anywhere, like databases. diff --git a/content/en/tightly-coupled-architectures.md b/content/en/tightly-coupled-architecture.md similarity index 91% rename from content/en/tightly-coupled-architectures.md rename to content/en/tightly-coupled-architecture.md index d639b07a8a..f96691fac6 100644 --- a/content/en/tightly-coupled-architectures.md +++ b/content/en/tightly-coupled-architecture.md @@ -1,5 +1,5 @@ --- -title: Tightly Coupled Architectures +title: Tightly Coupled Architecture status: Completed category: Property tags: ["fundamental", "architecture", "property"] @@ -14,7 +14,7 @@ They also tend to require coordinated rollouts of components which can become a drag on developer productivity. Tightly coupled application architectures are a fairly traditional way of building applications. -While not necessarily consistent with all the best practices of [microservice](/microservices/) development +While not necessarily consistent with all the best practices of [microservice](/microservices-architecture/) development they can be useful in specific circumstances. They tend to be faster and simpler to implement and much like [monolithic applications](/monolithic-apps/) they can speed up the initial development cycle. diff --git a/content/en/virtual-machine.md b/content/en/virtual-machine.md index 1f27483723..b819a5083f 100644 --- a/content/en/virtual-machine.md +++ b/content/en/virtual-machine.md @@ -31,4 +31,4 @@ VMs allow you to use your existing physical hardware resources better by placing multiple virtual machines on a single physical machine. Not bound to a particular physical machine, VMs are also more resilient than physical machines. When a physical machine needs to go offline, -the VMs running on it can be moved to another machine with little to no downtime +the VMs running on it can be moved to another machine with little to no downtime. \ No newline at end of file diff --git a/content/en/webassembly.md b/content/en/webassembly.md new file mode 100644 index 0000000000..da15a5f2ad --- /dev/null +++ b/content/en/webassembly.md @@ -0,0 +1,23 @@ +--- +title: WebAssembly +status: Completed +category: Concept +tags: ["Application", "", ""] +--- + +WebAssembly (often abbreviated as Wasm) is a binary instruction format designed as a portable target for compiling high-level languages like C, C++, Rust, and others. It enables deployment on the web for client-side and server-side applications. +It is a low-level bytecode format that can be executed in a virtual machine, typically integrated into web browsers. While initially developed for the web, Web Assembly is a Universal Runtime and sees applications in non-web environments such as IoT and edge devices. + +## Problem it addresses + +For many years, the LAMP (Linux Apache MySQL PHP) stack was the template for web-based applications. Later, Javascript became the king of front-end application development and node. js based applications became the norm. As the technology around the web evolved, it heavily favored interpreted languages, which are typically less performant than compiled languages, even with technological advancements. +While JavaScript has improved over the years, it still faces performance limitations when executing computationally intensive tasks. +Interpreted languages that are compiled at runtime often see performance and functionality issues as the code is executed across different environments. Conversely, compiled binaries typically run the same as long as they've compiled correctly. However, historically, a compiled binary has been less suited for the web environment. + +## How it helps + +WebAssembly provides a low-level binary format that can be executed at near-native speeds, enabling web applications to perform complex computations efficiently. +It allows developers to build web applications by leveraging their existing skills in languages like C, C++, Rust, and others. +This opens up new possibilities and allows developers to reuse existing codebases and libraries. +Also, WebAssembly modules can run consistently across different browsers, operating systems, and devices, reducing the need for platform-specific code. +Overall, WebAssembly addresses performance limitations, language restrictions, code portability, security concerns, code size, and loading time issues, providing a more robust and flexible environment for web application development. diff --git a/content/es/.wordlist.txt b/content/es/.wordlist.txt index e7892aec55..6470a3a8b9 100644 --- a/content/es/.wordlist.txt +++ b/content/es/.wordlist.txt @@ -1,4 +1,5 @@ -add +accionables +Add Agreement Amazon an @@ -22,6 +23,7 @@ bare based becoming Benavides +Berkeley blob blue branch @@ -32,6 +34,7 @@ BVS BY CaaS calendar +call Canary CAPEX Carol @@ -49,6 +52,7 @@ CI cifrada CLA Client +CLIs Cloud clúster clústeres @@ -95,6 +99,7 @@ directly Docs draft Dropbox +eBPF edit ej empoderen @@ -113,6 +118,7 @@ externalizar FaaS faltantes Feedback +Filter Finance Firewall first @@ -161,6 +167,7 @@ Jones Kafka Katelin Kubernetes +Landscape Language laptop Layer @@ -188,6 +195,7 @@ Microsoft Mike mitigarse monitorea +monitoreados monitorean monitorear monitoreará @@ -215,8 +223,11 @@ on-premises Open PaaS PaC +packet Paganini platform +Pod +pods Política portable pr @@ -235,6 +246,7 @@ PRs pull Quiceno Ramer +RBAC RDS relevantes Reliability @@ -248,6 +260,7 @@ SaaS Salesforce SCE scripts +SDK search Secure security @@ -263,7 +276,7 @@ sobreescriba Sockets Spanish spell -SRE +sre SSL stack Started @@ -275,6 +288,7 @@ submitting subrúbricas Subversion supercomputadoras +system tags TCP technology diff --git a/content/es/_TEMPLATE.md b/content/es/_TEMPLATE.md index 7d9cca042e..116f461eee 100644 --- a/content/es/_TEMPLATE.md +++ b/content/es/_TEMPLATE.md @@ -4,8 +4,6 @@ status: Feedback Appreciated category: Concepto --- -## ¿Qué es? - Resumen rápido del concepto y qué es. ## Problema que aborda diff --git a/content/es/agile-software-development.md b/content/es/agile-software-development.md index 8c1a9e18b8..1c41cb1f5e 100644 --- a/content/es/agile-software-development.md +++ b/content/es/agile-software-development.md @@ -2,11 +2,9 @@ title: Desarrollo ágil de software status: Completed category: Concepto -tags: ["methodology", "", ""] +tags: ["metodología", "", ""] --- -## ¿Qué es? - Un conjunto de prácticas que enfatizan el ciclo de desarrollo iterativo y equipos auto-organizados. En contraste con proyectos tradicionales en cascada donde el valor se genera solo al final del proyecto, el desarrollo ágil de software se enfoca en una entrega incremental y continua de valor y diff --git a/content/es/api-gateway.md b/content/es/api-gateway.md index 44ed31f42a..c6de249e3b 100644 --- a/content/es/api-gateway.md +++ b/content/es/api-gateway.md @@ -2,11 +2,9 @@ title: API Gateway status: Completed category: Tecnología -tags: ["networking", "", ""] +tags: ["redes", "", ""] --- -## ¿Qué es? - Un [API](/es/application-programming-interface/) gateway es una herramienta que concentra aplicaciones APIs únicas, centralizando a todas en un solo lugar. Esto permite a las organizaciones mover funciones clave, diff --git a/content/es/application-programming-interface.md b/content/es/application-programming-interface.md index 870c665765..d00bc44bcc 100644 --- a/content/es/application-programming-interface.md +++ b/content/es/application-programming-interface.md @@ -2,11 +2,9 @@ title: Interfaz de programación de aplicaciones (API) status: Completed category: Tecnología -tags: ["architecture", "fundamental", ""] +tags: ["arquitectura", "fundamento", ""] --- -## ¿Qué es? - Una API es una manera en la que los programas de computadoras interactúan entre sí. Tal como los humanos interactúan con un sitio web a través de la página web, una API permite a los programas de las computadoras interactuar entre sí. A diferencia de las interacciones humanas, las APIs tienen limitaciones en lo que se le puede preguntar o no a las mismas. diff --git a/content/es/auto-scaling.md b/content/es/auto-scaling.md index 90469bd970..7196b39343 100644 --- a/content/es/auto-scaling.md +++ b/content/es/auto-scaling.md @@ -2,7 +2,7 @@ title: Autoescalado status: Completed category: Propiedad -tags: ["infrastructure", "", ""] +tags: ["infraestructura", "", ""] --- El autoescalado es la habilidad de un sistema para [escalar](/es/scalability) automáticamente, en términos de recursos computacionales. diff --git a/content/es/bare-metal-machine.md b/content/es/bare-metal-machine.md index 2e1e12e18a..ce2ca14214 100644 --- a/content/es/bare-metal-machine.md +++ b/content/es/bare-metal-machine.md @@ -2,11 +2,9 @@ title: Máquina Bare Metal status: Completed category: Tecnología -tags: ["infrastructure", "", ""] +tags: ["infraestructura", "", ""] --- -## ¿Qué es? - Bare metal se refiere a una computadora física, más específicamente un servidor, que tiene un solo sistema operativo. La distinción es importante en la informática moderna porque muchos, si no es que la mayoría, de los servidores son [máquinas virtuales](/es/virtual-machine/). Un servidor físico suele ser una computadora bastante grande con un potente hardware incorporado. diff --git a/content/es/blue-green-deployment.md b/content/es/blue-green-deployment.md index 1f74ff98b1..4566a7807c 100644 --- a/content/es/blue-green-deployment.md +++ b/content/es/blue-green-deployment.md @@ -2,11 +2,9 @@ title: Despliegue Blue Green status: Completed category: Concepto -tags: ["methodology", "application", ""] +tags: ["metodología", "aplicación", ""] --- -## ¿Qué es? - El despliegue Blue green es una estrategia para actualizar los sistemas informáticos en ejecución con un tiempo de inactividad mínimo. El operador mantiene dos entornos, llamados "blue" y "green". Uno sirve el tráfico de producción (la versión que todos los usuarios usan actualmente), mientras que el otro está actualizado. diff --git a/content/es/canary-deployment.md b/content/es/canary-deployment.md index 1d37772b56..b9c6c9da4d 100644 --- a/content/es/canary-deployment.md +++ b/content/es/canary-deployment.md @@ -2,11 +2,9 @@ title: Canary Deployment status: Completed category: Concepto -tags: ["methodology", "application", ""] +tags: ["metodología", "aplicación", ""] --- -## ¿Qué es? - Canary deployment es una estrategia de despliegue que comienza con dos entornos: uno con tráfico y otro que contiene el código actualizado sin tráfico. El tráfico se traslada gradualmente de la versión original de la aplicación a la versión actualizada. diff --git a/content/es/chaos-engineering.md b/content/es/chaos-engineering.md index 9d1b81606a..fb1d5953ff 100644 --- a/content/es/chaos-engineering.md +++ b/content/es/chaos-engineering.md @@ -2,11 +2,9 @@ title: Ingeniería del Caos status: Completed category: Concepto -tags: ["methodology", "", ""] +tags: ["metodología", "", ""] --- -## ¿Qué es? - Ingeniería del Caos o CE (Chaos Engineering) es la disciplina de experimentación sobre un [Sistema Distribuido](/es/distributed-systems/) en producción para construir confianza en la capacidad del sistema para soportar condiciones inesperadas y turbulentas. diff --git a/content/es/client-server-architecture.md b/content/es/client-server-architecture.md index f2c719c701..40d340426c 100644 --- a/content/es/client-server-architecture.md +++ b/content/es/client-server-architecture.md @@ -2,11 +2,9 @@ title: Arquitectura Cliente-Servidor status: Completed category: Concepto -tags: ["architecture", "fundamental", ""] +tags: ["arquitectura", "fundamento", ""] --- -## ¿Qué es? - En una arquitectura cliente-servidor, la lógica (o código) que constituye una aplicación se divide en dos o más componentes: un cliente que solicita trabajo por hacer (por ejemplo, la aplicación web Gmail que se ejecuta en su navegador web), diff --git a/content/es/cloud-computing.md b/content/es/cloud-computing.md index a02a604dd0..74a70e4501 100644 --- a/content/es/cloud-computing.md +++ b/content/es/cloud-computing.md @@ -2,11 +2,9 @@ title: Computación en la Nube status: Completed category: Concepto -tags: ["infrastructure", "fundamental", ""] +tags: ["infraestructura", "fundamento", ""] --- -## ¿Qué es? - La computación en la nube es un modelo que ofrece recursos informáticos como capacidades de CPU, red y disco bajo demanda a través de Internet. La computación en la nube brinda a los usuarios la capacidad de acceder y utilizar el poder de cómputo en una ubicación física remota. Los proveedores de la nube como AWS, GCP, Azure, DigitalOcean y otros ofrecen a terceros diff --git a/content/es/cloud-native-apps.md b/content/es/cloud-native-apps.md index 2a18d38a1e..de59c39583 100644 --- a/content/es/cloud-native-apps.md +++ b/content/es/cloud-native-apps.md @@ -2,11 +2,9 @@ title: Aplicaciones Nativas para la Nube status: Completed category: Concepto -tags: ["application", "fundamental", ""] +tags: ["aplicación", "fundamento", ""] --- -## ¿Qué es? - Las aplicaciones nativas para la nube están diseñadas específicamente para aprovechar las innovaciones en [computación en la nube](/es/cloud_computing/). Estas aplicaciones se integran fácilmente con sus respectivas arquitecturas en la nube, aprovechando los recursos de la nube y las capacidades de [escalado](/es/scalability/). diff --git a/content/es/cloud-native-security.md b/content/es/cloud-native-security.md index 7236d145b5..c4499c376c 100644 --- a/content/es/cloud-native-security.md +++ b/content/es/cloud-native-security.md @@ -2,11 +2,9 @@ title: Seguridad Nativa para la Nube status: Completed category: Concepto -tags: ["security", "", ""] +tags: ["seguridad", "", ""] --- -## ¿Qué es? - La seguridad nativa para la nube es un enfoque que crea seguridad en las [aplicaciones nativas para la nube](/es/cloud-native-apps/). Garantiza que la seguridad sea parte de todo el ciclo de vida de la aplicación, desde el desarrollo hasta la producción. La seguridad nativa para la nube busca garantizar los mismos estándares que los modelos de seguridad tradicionales diff --git a/content/es/cloud-native-tech.md b/content/es/cloud-native-tech.md index 5bc8fe8be0..82ab678600 100644 --- a/content/es/cloud-native-tech.md +++ b/content/es/cloud-native-tech.md @@ -5,8 +5,6 @@ category: Concepto tags: ["fundamental", "", ""] --- -## ¿Qué es? - Las tecnologías nativas para la nube, también denominadas como stack nativo para la nube, son las tecnologías que se utilizan para crear [aplicaciones nativas para la nube](/es/cloud-native-apps/). Estas tecnologías permiten a las organizaciones crear y ejecutar aplicaciones escalables en entornos modernos y dinámicos diff --git a/content/es/cluster.md b/content/es/cluster.md index 8c99be929a..a161812388 100644 --- a/content/es/cluster.md +++ b/content/es/cluster.md @@ -2,11 +2,9 @@ title: Clúster status: Completed category: Concepto -tags: ["infrastructure", "fundamental", ""] +tags: ["infraestructura", "fundamento", ""] --- -## ¿Qué es? - Un clúster es un grupo de ordenadores o aplicaciones que trabajan juntos hacia un objetivo común. En el contexto de computación nativa en la nube, el término es aplicado con mayor frecuencia a [Kubernetes](/es/kubernetes/). Un clúster de Kubernetes es un conjunto de servicios (o cargas de trabajo) que son ejecutadas en sus propios contenedores, normalmente en ordenadores diferentes. diff --git a/content/es/container-image.md b/content/es/container-image.md index 82b0158cb2..4cbade92a9 100644 --- a/content/es/container-image.md +++ b/content/es/container-image.md @@ -5,8 +5,6 @@ category: Concepto tags: ["", "", ""] --- -## ¿Qué es? - Una imagen es un fichero estático e inmutable que contiene las dependencias para la creación de un [contenedor](/es/container/). Estas dependencias pueden incluir un archivo binario ejecutable, librerías del sistema, herramientas del sistema, variables de entorno y otras configuraciones de plataforma necesarias. diff --git a/content/es/container-orchestration.md b/content/es/container-orchestration.md index 6bee1f67b0..70dbd33b2b 100644 --- a/content/es/container-orchestration.md +++ b/content/es/container-orchestration.md @@ -4,8 +4,6 @@ status: Completed category: Concepto --- -## ¿Qué es? - La orquestación de [contenedores](/es/container/) se refiere al manejo y automatización del ciclo de vida de una aplicación contenedorizada en ambientes dinámicos. Es ejecutada a través de un orquestador de contenedores (por lo general, [Kubernetes](/es/kubernetes)), el cual ofrece despliegues, autoescalado, auto reparación y monitoreo. La orquestación es metafórica: diff --git a/content/es/container.md b/content/es/container.md index 0e9013bca2..b95f5c0c58 100644 --- a/content/es/container.md +++ b/content/es/container.md @@ -2,11 +2,9 @@ title: Contenedores status: Completed category: Tecnología -tags: ["application", "fundamental", ""] +tags: ["aplicación", "fundamento", ""] --- -## ¿Qué es? - Un contenedor es un proceso en ejecución con restricciones de recursos y capacidades administrado por el sistema operativo de una computadora. Los archivos disponibles del contenedor se empaquetan como una imagen de contenedor. Los contenedores se ejecutan uno al lado del otro en la misma máquina, diff --git a/content/es/containerization.md b/content/es/containerization.md index cd1863989d..2a99fd5130 100644 --- a/content/es/containerization.md +++ b/content/es/containerization.md @@ -2,11 +2,9 @@ title: Contenerización status: Completed category: Tecnología -tags: ["application", "", ""] +tags: ["aplicación", "", ""] --- -## ¿Qué es? - La contenerización es el proceso que consiste en empaquetar una aplicación y sus dependencias en una imagen de contenedor. La construcción del contenedor requiere del seguimiento del estándar [Open Container Initiative](https://opencontainers.org) (OCI). Mientras la salida de este proceso sea un contenedor de imagen que se adhiera a dicho estándar, la herramienta de contenerización usada no es relevante. diff --git a/content/es/containers-as-a-service.md b/content/es/containers-as-a-service.md index 99ddbc1f4c..d6bbbec20b 100644 --- a/content/es/containers-as-a-service.md +++ b/content/es/containers-as-a-service.md @@ -3,11 +3,9 @@ title: Contenedores como Servicio status: Deprecated category: Tecnología draft: true -tags: ["platform", "", ""] +tags: ["plataforma", "", ""] --- -## ¿Qué es? - Contenedores como Servicio (CaaS, por sus siglas en inglés _containers as a service_) es un servicio en la nube que ayuda a administrar e implementar aplicaciones mediante la [abstracción](/es/abstraction/) basada en [contenedores](/es/container/). Este servicio se puede implementar en las instalaciones o en la nube. diff --git a/content/es/continuous-delivery.md b/content/es/continuous-delivery.md index 1d633c99c4..76292d2048 100644 --- a/content/es/continuous-delivery.md +++ b/content/es/continuous-delivery.md @@ -2,11 +2,9 @@ title: Entrega Continua (CD) status: Completed category: Concepto -tags: ["methodology", "application", ""] +tags: ["metodología", "aplicación", ""] --- -## ¿Qué es? - La entrega continua, a menudo abreviada como CD, es un conjunto de prácticas en las que los cambios de código se despliegan automáticamente en un entorno de aceptación (o, en el caso de despliegue continuo, en producción). diff --git a/content/es/continuous-deployment.md b/content/es/continuous-deployment.md index b7a79e4bef..eb7f0ad2aa 100644 --- a/content/es/continuous-deployment.md +++ b/content/es/continuous-deployment.md @@ -2,11 +2,9 @@ title: Despliegue Continuo (CD) status: Completed category: Concepto -tags: ["application", "methodology", ""] +tags: ["aplicación", "metodología", ""] --- -## ¿Qué es? - El despliegue continuo, a menudo abreviado como CD (por sus siglas en inglés _Continuous Deployment_), va un paso más allá que la [entrega continua](/es/continuous-delivery/) desplegando software finalizado directamente en producción. El despliegue continuo (CD) es comúnmente asociado con la [integración continua](/es/continuous-integration/) (CI), diff --git a/content/es/continuous-integration.md b/content/es/continuous-integration.md index 5993e39b05..02d54ccb22 100644 --- a/content/es/continuous-integration.md +++ b/content/es/continuous-integration.md @@ -2,11 +2,9 @@ title: Integración Continua (CI) status: Completed category: Concepto -tags: ["application", "methodology", ""] +tags: ["aplicación", "metodología", ""] --- -## ¿Qué es? - Integración continua, o por sus siglas en ingles CI, es la práctica de integrar cambios en el código lo más frecuente posible. CI es un requisito para la [entrega continua](/es/continuous-delivery/) (CD). Tradicionalmente, el proceso de CI comienza cuando se envían los cambios en el código hacia un sistema de control de versiones (Git, Mercurial, o Subversion) diff --git a/content/es/contribute/_index.md b/content/es/contribute/_index.md index cc9ad66180..7c9600670f 100644 --- a/content/es/contribute/_index.md +++ b/content/es/contribute/_index.md @@ -69,6 +69,8 @@ Antes de concluir la creación del pull request (PR), necesita firmar el [Contri También necesitará [verificar la firma de su commit](https://docs.github.com/en/authentication/managing-commit-signature-verification/about-commit-signature-verification) y activar el [modo vigilante](https://docs.github.com/en/authentication/managing-commit-signature-verification/displaying-verification-statuses-for-all-of-your-commits#about-vigilant-mode) en GitHub para comprobar el origen de su commit y mostrar el estado "verified". +![Verificar firma del commit](/images/how-to/verifying-signature.png) + ## Proponer nuevos términos {#propose-new-terms} Puede proponer un nuevo término para que otros trabajen en él o crear una nueva definición usted mismo. @@ -136,6 +138,9 @@ Copie el contenido… ![copiar contenido](/images/how-to/howto-08.png) Cambie de branch a "dev-es", regrese a la carpeta /content/ y seleccione "es". + +![cambiar de branch](/images/content/es/switch-branch.png) + Presione "Add file" y seleccione "Create new file." ![crear un archivo nuevo](/images/how-to/howto-09.png) @@ -182,7 +187,7 @@ Esto abrirá directamente un issue. Explique qué cambio es necesario y por qué Para cambiar un término directamente, vaya a "Editar esta página". -![edit this page](/images/how-to/howto-16.png) +![editar esta página](/images/how-to/howto-16.png) Esto abrirá la página del término en GitHub. Realice sus cambios y envíe un PR. Consulte "Envío de un nuevo término" (más arriba en este documento) para obtener una descripción mas detallada (salte a la sección que habla acerca de markdown). @@ -211,4 +216,3 @@ Para poder añadir nuevas palabras a la lista en español, siga los siguientes p Nótese que las palabras están en orden alfabético, le pedimos encarecidamente mantenga este orden. La revisión ortográfica ignora el uso de mayúsculas y minúsculas. - diff --git a/content/es/data-center.md b/content/es/data-center.md index a55d5dcebc..d5c6aef54e 100644 --- a/content/es/data-center.md +++ b/content/es/data-center.md @@ -2,11 +2,9 @@ title: Centro de Datos status: Completed category: Tecnología -tags: ["infrastructure", "fundamental", ""] +tags: ["infraestructura", "fundamento", ""] --- -## ¿Qué es? - Un centro de datos es un edificio diseñado específicamente para almacenar computadoras, habitualmente referidas como servidores. Estos centros de datos suelen estar conectados a líneas de Internet de alta velocidad, especialmente en el caso de los centros de datos para [computación en la nube](/es/cloud-computing/). Las edificaciones donde se alojan los centros de datos poseen equipamiento para mantener el servicio incluso en caso de fuerza mayor, como generadores para proveer energía durante apagones y aire acondicionado para la dispersión del calor generado por los servidores. diff --git a/content/es/database-as-a-service.md b/content/es/database-as-a-service.md index 99eaf4c4b8..588b824909 100644 --- a/content/es/database-as-a-service.md +++ b/content/es/database-as-a-service.md @@ -6,8 +6,6 @@ draft: true tags: ["", "", ""] --- -## ¿Qué es? - Base de Datos como Servicio (DBaaS, por sus siglas en inglés _data base as a service_) es un servicio en la [nube](/es/cloud-computing/) (pública o privada) que soporta aplicaciones sin necesidad de que el equipo de desarrollo ejecute tareas tradicionales de administración de base de datos. DBaaS permite a los desarrolladores de aplicaciones a utilizar bases de datos sin ser expertos o diff --git a/content/es/debugging.md b/content/es/debugging.md index 564f70fdf9..47eb7047ee 100644 --- a/content/es/debugging.md +++ b/content/es/debugging.md @@ -2,11 +2,9 @@ title: Depuración status: Completed category: concepto -tags: ["application", "methodology", ""] +tags: ["aplicación", "metodología", ""] --- -## ¿Qué es? - La depuración es el proceso o actividad de encontrar y resolver bugs (o errores) de programas, software o sistemas informáticos para obtener el resultado deseado. Un bug es un defecto o un problema que conduce a resultados incorrectos o inesperados. diff --git a/content/es/devops.md b/content/es/devops.md index 9659c6a75e..ffa5d5cde0 100644 --- a/content/es/devops.md +++ b/content/es/devops.md @@ -2,11 +2,9 @@ title: DevOps status: Completed category: Concepto -tags: ["methodology", "", ""] +tags: ["metodología", "", ""] --- -## ¿Qué es? - DevOps es una metodología en la que los equipos son dueños de todo el proceso, desde el desarrollo de la aplicación hasta las operaciones en producción, de ahí el término DevOps. Va más allá de implementar un conjunto de tecnologías y requiere un cambio completo en la cultura y los procesos. DevOps requiere grupos de ingenieros que trabajen en componentes pequeños (en lugar de una función completa), reduciendo las transferencias, una fuente común de errores. diff --git a/content/es/devsecops.md b/content/es/devsecops.md index aad44d24cd..0d8617fcaa 100644 --- a/content/es/devsecops.md +++ b/content/es/devsecops.md @@ -2,11 +2,9 @@ title: DevSecOps status: Completed category: Concepto -tags: ["methodology", "security", ""] +tags: ["metodología", "seguridad", ""] --- -## ¿Qué es? - El término DevSecOps se refiere a una fusión cultural de las responsabilidades operativas, de desarrollo y de seguridad. Este concepto extiende el enfoque [DevOps](/es/devops/) para incluir prioridades de seguridad con una interrupción mínima o nula en el flujo de trabajo operativo y de desarrollo. diff --git a/content/es/digital-certificate.md b/content/es/digital-certificate.md index 8a2e2840fb..f0e14d1282 100644 --- a/content/es/digital-certificate.md +++ b/content/es/digital-certificate.md @@ -2,11 +2,9 @@ title: Certificado Digital status: Feedback Appreciated category: Tecnología -tags: ["security", "", ""] +tags: ["seguridad", "", ""] --- -## ¿Qué es? - Un certificado (digital), también conocido como certificado de clave pública o certificado SSL(Secure Sockets Layer), es un documento digital utilizado para ayudar a proteger las comunicaciones que ocurren a través de la red. Los certificados nos permiten conocer la entidad en particular con la que nos estamos comunicando y si es quien dice ser. También nos permiten asegurarnos de que nuestras comunicaciones sean privadas al cifrar los datos que enviamos y recibimos. diff --git a/content/es/distributed-apps.md b/content/es/distributed-apps.md index 684f9d84ca..69c43a547d 100644 --- a/content/es/distributed-apps.md +++ b/content/es/distributed-apps.md @@ -2,11 +2,9 @@ title: Aplicaciones Distribuidas status: Completed category: Concepto -tags: ["architecture", "", ""] +tags: ["arquitectura", "", ""] --- -## ¿Qué es? - Una aplicación distribuida es una aplicación en la que la funcionalidad se divide en múltiples partes independientes más pequeñas. Las aplicaciones distribuidas suelen estar formadas por componentes individuales llamados [microservicios](/es/microservices/) que se ocupan de diferentes responsabilidades dentro de una aplicación más extensa. diff --git a/content/es/distributed-systems.md b/content/es/distributed-systems.md index 7717ecd254..b00517f4dd 100644 --- a/content/es/distributed-systems.md +++ b/content/es/distributed-systems.md @@ -2,11 +2,9 @@ title: Sistema Distribuido status: Completed category: Concepto -tags: ["architecture", "", ""] +tags: ["arquitectura", "", ""] --- -## ¿Qué es? - Un sistema distribuido es una colección de elementos computacionales autónomos conectados entre sí a través de una red que se muestra a los usuarios como un sistema único coherente. Conocidos generalmente como [nodos](/es/nodes/), estos elementos pueden ser dispositivos de hardware (por ejemplo, computadoras o teléfonos móviles) o procesos de software. diff --git a/content/es/ebpf.md b/content/es/ebpf.md new file mode 100644 index 0000000000..ced1fdca64 --- /dev/null +++ b/content/es/ebpf.md @@ -0,0 +1,40 @@ +--- +title: eBPF +status: Completed +category: Tecnología +tags: ["arquitectura", "redes", "seguridad"] +--- + +eBPF, o "extended Berkeley Packet Filter", es una tecnología que permite a pequeños programas o scripts aislados ejecutarse en el espacio del kernel de un sistema Linux sin necesidad de cambiar el código fuente ni cargar módulos al kernel Linux. + +Un sistema Linux tiene dos espacios: el de kernel y el de usuario. +El kernel representa el sistema operativo y es la única parte +con acceso ilimitado al hardware. + +Las aplicaciones quedan en el espacio de usuario y, cuando necesitan permisos más elevados, +envían una solicitud al kernel. +Para aplicaciones que requieren más flexibilidad, como el acceso directo al hardware, +el kernel puede ser extendido mediante lo que se conoce como el enfoque de "módulos +del kernel Linux". Este enfoque amplía la funcionalidad predeterminada del kernel, +permitiendo a las aplicaciones un acceso más profundo a los componentes básicos. +Sin embargo, este enfoque también introduce riesgos de seguridad, lo que hace que eBPF sea una alternativa atractiva. + +## Problema que soluciona +Típicamente, las aplicaciones se ejecutan en el espacio de usuario y, si la aplicación requiere algunos privilegios del kernel (por ejemplo, para acceder a algún hardware), +lo solicita al kernel a través de una llamada al sistema conocida como "system call". +En la mayoría de los casos, este enfoque funciona bien. Sin embargo, hay casos en los que los desarrolladores requieren más flexibilidad para acceder al sistema a nivel bajo. +La observabilidad, la seguridad y las redes son buenos ejemplos. +Para lograrlo, podemos utilizar módulos del kernel Linux, ampliando la base del kernel sin modificar el código principal del kernel. +Si bien hay beneficios en el uso de módulos del kernel Linux, también introduce riesgos de seguridad. +Como operan dentro del espacio del kernel, los módulos del kernel Linux pueden hacer que el kernel falle y, cuando el kernel falla, también lo hace toda la máquina. +Además, los módulos del kernel tienen privilegios elevados y acceso directo a los recursos del sistema. Y si no están adecuadamente aseguradas, los atacantes pueden explotarlas. + +## ¿Cómo ayuda? +eBPF proporciona un entorno más controlado y contenido para ejecutar programas definidos por el usuario que los módulos del kernel Linux. +Se ejecuta en un entorno aislado dentro del kernel, proporcionando aislamiento y mitigando riesgos. +Si se explota una vulnerabilidad o defecto en un programa eBPF, su impacto generalmente se limita al entorno aislado. +Además, antes de que un programa eBPF pueda comenzar a ejecutarse en el kernel, debe pasar por algunas verificaciones. +El componente verificador verifica el programa eBPF en busca de posibles violaciones de seguridad, +como el acceso a memoria fuera de límites, ciclos infinitos y funciones del kernel no autorizadas. +De esta manera, asegura que el programa no entre en un ciclos infinitos y provoque un fallo del kernel. +Estos controles de seguridad hacen que eBPF sea una opción más segura para ejecutar aplicaciones en el kernel Linux que los módulos del kernel Linux. \ No newline at end of file diff --git a/content/es/edge-computing.md b/content/es/edge-computing.md index 92aae64b61..da634ea8a7 100644 --- a/content/es/edge-computing.md +++ b/content/es/edge-computing.md @@ -4,8 +4,6 @@ status: Completed category: Tecnología --- -## ¿Qué es? - Computación en el borde es un tipo de [sistema distribuido](/es/distributed-systems/) en el que una parte del procesamiento y almacenamiento de información se realiza en el origen de los datos. Esta información generada es procesada localmente (por ejemplo en una fábrica, en un negocio o a través de una ciudad) en vez de ser enviada a un centro de datos centralizado para procesamiento y análisis. Luego el resultado de ese procesamiento local es enviado al centro de datos principal para un procesamiento final. diff --git a/content/es/event-driven-architecture.md b/content/es/event-driven-architecture.md index 77dca52dc0..7c0219380f 100644 --- a/content/es/event-driven-architecture.md +++ b/content/es/event-driven-architecture.md @@ -2,11 +2,9 @@ title: Arquitectura Basada en Eventos status: Completed category: Concepto -tags: ["architecture", "", ""] +tags: ["arquitectura", "", ""] --- -## ¿Qué es? - La arquitectura basada en eventos es una arquitectura de software que promueve la creación, procesamiento y consumo de eventos. Un evento es cualquier cambio en el estado de una aplicación. Por ejemplo, solicitar un viaje en una aplicación de viajes compartidos es un evento. diff --git a/content/es/event-streaming.md b/content/es/event-streaming.md index c44e37e062..d6aece74b9 100644 --- a/content/es/event-streaming.md +++ b/content/es/event-streaming.md @@ -2,11 +2,9 @@ title: Transmisión de eventos status: Completed category: Concepto -tags: ["methodology", "networking", ""] +tags: ["metodología", "redes", ""] --- -## ¿Qué es? - La transmisión de eventos es un enfoque en el que el software envía datos de eventos de una aplicación a otra para comunicar continuamente lo que esta haciendo. Imagine un servicio transmitiendo todo lo que hace a todos los demás servicios. Cada actividad realizada por un servicio se denomina evento, por lo tanto, transmisión de eventos. diff --git a/content/es/firewall.md b/content/es/firewall.md index b86c570772..206fe9036b 100644 --- a/content/es/firewall.md +++ b/content/es/firewall.md @@ -6,8 +6,6 @@ category: Tecnología tags: ["", "", ""] --- -## ¿Qué es? - Un Firewall es un sistema que filtra tráfico de red basándose en reglas específicas. Los Firewall pueden ser hardware, software o una combinación de ambos. diff --git a/content/es/function-as-a-service.md b/content/es/function-as-a-service.md index 1d133acc6c..198e25a682 100644 --- a/content/es/function-as-a-service.md +++ b/content/es/function-as-a-service.md @@ -2,11 +2,9 @@ title: Función como Servicio (FaaS) status: Completed category: Tecnología -tags: ["infrastructure", "", ""] +tags: ["infraestructura", "", ""] --- -## ¿Qué es? - La Función como Servicio (FaaS según sus siglas en Inglés) es un tipo de [servicio](/es/service/) [sin servidor](/es/serverless/) en la [computación en la nube](/es/cloud-computing/) que permite ejecutar código como respuesta a ciertos eventos sin necesidad de mantener infraestructura compleja diff --git a/content/es/gitops.md b/content/es/gitops.md index 4e8001ad11..f4fad92e03 100644 --- a/content/es/gitops.md +++ b/content/es/gitops.md @@ -2,11 +2,9 @@ title: GitOps status: Feedback Appreciated category: Concepto -tags: ["methodology", "", ""] +tags: ["metodología", "", ""] --- -## ¿Qué es? - GitOps es un conjunto de buenas prácticas basadas en unos [principios comunes](https://opengitops.dev/), aplicados a un flujo de trabajo que depende de agentes de software que de forma automática reconcilian las configuraciones o el estado de un sistema respecto al estado o las configuraciones declaradas en un repositorio git. diff --git a/content/es/horizontal-scaling.md b/content/es/horizontal-scaling.md index e60817d65b..568c13177c 100644 --- a/content/es/horizontal-scaling.md +++ b/content/es/horizontal-scaling.md @@ -2,11 +2,9 @@ title: Escalado horizontal status: Completed category: Concepto -tags: ["infrastructure", "", ""] +tags: ["infraestructura", "", ""] --- -## ¿Qué es? - Escalado horizontal es una técnica donde la capacidad del sistema es incrementada agregando más [nodos](/es/nodes) en vez de agregar más recursos computacionales a nodos individuales (conocido como [escalado vertical](/es/vertical-scaling/)). Como ejemplo, digamos que tenemos un sistema con 4 GB de memoria y queremos incrementar su capacidad a 16 GB, diff --git a/content/es/hypervisor.md b/content/es/hypervisor.md index c26fe40012..969dd95f6f 100644 --- a/content/es/hypervisor.md +++ b/content/es/hypervisor.md @@ -2,11 +2,9 @@ title: Hipervisor status: Feedback Appreciated category: Tecnología -tags: ["application", "", ""] +tags: ["aplicación", "", ""] --- -## ¿Qué es? - Un hipervisor utiliza el concepto de [virtualización](/es/virtualization/) aprovechando los recursos de la llamada [máquina bare metal](/es/bare-metal-machine/) (CPU, memoria, recursos de red, y almacenamiento), dividiéndolos en partes más pequeñas, diff --git a/content/es/idempotence.md b/content/es/idempotence.md index 11446027c7..4a8c597dfc 100644 --- a/content/es/idempotence.md +++ b/content/es/idempotence.md @@ -2,7 +2,7 @@ title: Idempotencia status: Completed category: Propiedad -tags: ["property", "", ""] +tags: ["propiedad", "", ""] --- En matemáticas o informática, la idempotencia describe una operación que siempre conduce al mismo resultado, diff --git a/content/es/immutable-infrastructure.md b/content/es/immutable-infrastructure.md index f15bbd5a57..76246193f2 100644 --- a/content/es/immutable-infrastructure.md +++ b/content/es/immutable-infrastructure.md @@ -2,7 +2,7 @@ title: Infraestructura inmutable status: Completed category: Propiedad -tags: ["infrastructure", "property", ""] +tags: ["infraestructura", "propiedad", ""] --- Infraestructura inmutable se refiere a la infraestructura informática diff --git a/content/es/infrastructure-as-a-service.md b/content/es/infrastructure-as-a-service.md index c4345b5919..dd2aaf0c8c 100644 --- a/content/es/infrastructure-as-a-service.md +++ b/content/es/infrastructure-as-a-service.md @@ -2,11 +2,9 @@ title: Infraestructura como Servicio (IaaS) status: Completed category: Tecnología -tags: ["infrastructure", "", ""] +tags: ["infraestructura", "", ""] --- -## ¿Qué es? - Infraestructura como Servicio, o IaaS, es un modelo de servicio de [computación en la nube](/es/cloud_computing/) que ofrece recursos de cómputo, almacenamiento y red mediante servidores [físicos](/es/bare_metal_machine/) o [virtualizados](/es/virtualization/) suministrados bajo demanda en un modelo de pago por uso. diff --git a/content/es/infrastructure-as-code.md b/content/es/infrastructure-as-code.md index f69a34e09e..853e42120d 100644 --- a/content/es/infrastructure-as-code.md +++ b/content/es/infrastructure-as-code.md @@ -2,11 +2,9 @@ title: Infraestructura como Código (IaC) status: Completed category: Concepto -tags: ["infrastructure", "methodology", ""] +tags: ["infraestructura", "metodología", ""] --- -## ¿Qué es? - Infraestructura como código es una práctica para almacenar la definición de la infraestructura en uno o varios archivos. Esto reemplaza el modelo tradicional dónde la infraestructura como servicio es aprovisionado de forma manual, por lo general usando scripts con la consola u otras herramientas de configuración. diff --git a/content/es/kubernetes.md b/content/es/kubernetes.md index 948e60378d..23aa10bc78 100644 --- a/content/es/kubernetes.md +++ b/content/es/kubernetes.md @@ -2,11 +2,9 @@ title: Kubernetes status: Completed category: Tecnología -tags: ["infrastructure", "fundamental", ""] +tags: ["infraestructura", "fundamento", ""] --- -## ¿Qué es? - Kubernetes, comúnmente abreviado como K8s, es un orquestador de contenedores de código abierto. Automatiza el ciclo de vida de las aplicaciones contenedorizadas en infraestructuras modernas, funcionando como un "sistema operativo en un Centro de Datos" que administra las aplicaciones ejecutándose en [sistemas distribuidos](/es/distributed-systems/). diff --git a/content/es/load-balancer.md b/content/es/load-balancer.md index 437cb7d564..7010968d76 100644 --- a/content/es/load-balancer.md +++ b/content/es/load-balancer.md @@ -2,11 +2,9 @@ title: Balanceador de Carga status: Feedback Appreciated category: Concepto -tags: ["infrastructure", "networking", ""] +tags: ["infraestructura", "redes", ""] --- -## ¿Qué es? - Un balanceador de carga es una herramienta que distribuye eficientemente las solicitudes entrantes entre varias instancias de una aplicación. Tome una arquitectura de [microservicio](/es/microservices/) como ejemplo, donde cada servicio se puede [escalar horizontalmente](/es/horizontal-scaling/). Un balanceador de carga se encuentra frente a un microservicio escalado y garantiza que ninguna instancia reciba la mayor parte de las solicitudes. diff --git a/content/es/loosely-coupled-architecture.md b/content/es/loosely-coupled-architecture.md index 0f5ad10170..428680ccd7 100644 --- a/content/es/loosely-coupled-architecture.md +++ b/content/es/loosely-coupled-architecture.md @@ -2,7 +2,7 @@ title: Arquitectura débilmente acoplada status: Completed category: Propiedad -tags: ["fundamental", "architecture", "property"] +tags: ["fundamento", "arquitectura", "propiedad"] --- diff --git a/content/es/managed-services.md b/content/es/managed-services.md index 6589e71032..40e1d82edd 100644 --- a/content/es/managed-services.md +++ b/content/es/managed-services.md @@ -5,8 +5,6 @@ category: Tecnología tags: ["", "", ""] --- -## ¿Qué es? - Un servicio administrado es una solución de software en la que las operaciones y gestión son manejadas por un tercero. Algunos ejemplos incluyen Bases de Datos como Servicio como Amazon RDS o un servicio de monitoreo externo como Datadog. diff --git a/content/es/microservices-architecture.md b/content/es/microservices-architecture.md index a5c172bc2b..22015e56ab 100644 --- a/content/es/microservices-architecture.md +++ b/content/es/microservices-architecture.md @@ -1,11 +1,9 @@ --- title: Arquitectura de Microservicios status: Completed -tags: ["architecture", "fundamental", ""] +tags: ["arquitectura", "fundamento", ""] --- -## ¿Qué es? - Una arquitectura de microservicios es un enfoque arquitectónico que divide las aplicaciones en (micro)[servicios](/es/service/) individuales e independientes, donde cada servicio se centra en una funcionalidad específica. Estos servicios trabajan juntos estrechamente, apareciendo ante el usuario final como una sola entidad. Tomemos Netflix como ejemplo. diff --git a/content/es/monolithic-apps.md b/content/es/monolithic-apps.md index 4a3c27aee0..da126644a7 100644 --- a/content/es/monolithic-apps.md +++ b/content/es/monolithic-apps.md @@ -2,11 +2,9 @@ title: Aplicaciones monolíticas status: Completed category: Concepto -tags: ["architecture", "fundamental", ""] +tags: ["arquitectura", "fundamento", ""] --- -## ¿Qué es? - Una aplicación monolítica contiene toda la funcionalidad en un único programa desplegable. Suele ser el punto de partida más sencillo y fácil a la hora de crear una aplicación. Sin embargo, una vez que la aplicación crece en complejidad, los monolitos pueden ser difíciles de mantener. diff --git a/content/es/multitenancy.md b/content/es/multitenancy.md index 7b9b9ccd81..99d70433f7 100644 --- a/content/es/multitenancy.md +++ b/content/es/multitenancy.md @@ -2,11 +2,9 @@ title: Tenencia Múltiple (multitenancy) status: Feedback Appreciated category: Propiedad -tags: ["architecture", "property", ""] +tags: ["arquitectura", "propiedad", ""] --- -## ¿Qué es? - Tenencia Múltiple (o multitenancy) se refiere a una única instalación de software que sirve a varios inquilinos. Un inquilino es un usuario, una aplicación o un grupo de usuarios/aplicaciones que utilizan el software para operar con su propio conjunto de datos. Estos inquilinos no comparten datos (a menos que el propietario explícitamente se lo indique) e incluso pueden no ser conscientes unos de otros. diff --git a/content/es/mutual-transport-layer-security.md b/content/es/mutual-transport-layer-security.md index f6b688746b..026b266b13 100644 --- a/content/es/mutual-transport-layer-security.md +++ b/content/es/mutual-transport-layer-security.md @@ -2,11 +2,9 @@ title: Seguridad mutua de capa de transporte (mTLS) status: Completed category: Concepto -tags: ["security", "networking", ""] +tags: ["seguridad", "redes", ""] --- -## ¿Qué es? - La seguridad mutua de capa de transporte (mTLS en Inglés) es una técnica utilizada para autenticar y codificar mensajes enviados entre dos [servicios](/es/service). mTLS es el protocolo de [Seguridad de capa de transporte](/es/transport-layer-security/) (TLS) estándar pero, en vez de validar la identidad de solo una conexión, se validan ambos lados. diff --git a/content/es/nodes.md b/content/es/nodes.md index 0b08b09c9b..e7f69a1e6e 100644 --- a/content/es/nodes.md +++ b/content/es/nodes.md @@ -2,11 +2,9 @@ title: Nodos status: Completed category: Tecnología -tags: ["infrastructure", "fundamental", ""] +tags: ["infraestructura", "fundamento", ""] --- -## ¿Qué es? - Un nodo es un servidor que trabaja en conjunto a otros servidores, o nodos, para realizar una tarea común. Toma tu laptop, el módem y la impresora como ejemplo. Están conectados a través de tu red wifi comunicándose y colaborando, cada uno representa un nodo. diff --git a/content/es/observability.md b/content/es/observability.md index c4faa3b600..bf98b136f9 100644 --- a/content/es/observability.md +++ b/content/es/observability.md @@ -2,23 +2,15 @@ title: Observabilidad status: Completed category: Concepto -tags: ["property", "", ""] +tags: ["propiedad", "", ""] --- -## ¿Qué es? +La observabilidad es una propiedad del sistema que define el grado en que el sistema puede generar conocimientos accionables. +Permite a los usuarios comprender el estado de un sistema a partir de estas salidas externas y tomar medidas (correctivas). -La observabilidad es la capacidad de generar y descubrir continuamente información procesable basada en señales del sistema bajo observación. -En otras palabras, la observabilidad permite a los usuarios comprender el estado de un sistema a partir de su salida externa y así tomar medidas (correctivas). +Los sistemas informáticos se miden observando señales de bajo nivel como el tiempo de CPU, la memoria, el espacio en disco y señales de nivel superior y empresariales, incluidos los tiempos de respuesta de la API, errores, transacciones por segundo, etc. +Estos sistemas observables son **observados** (o monitoreados) a través de herramientas especializadas, llamadas herramientas de observabilidad. Una lista de estas herramientas se puede ver en la [Sección de observabilidad de Cloud Native Landscape](https://landscape.cncf.io/?group=projects-and-products&view-mode=card#observability-and-analysis--observability). -## Problema que aborda +Los sistemas observables proporcionan datos significativos y accionables a sus operadores, lo que les permite lograr resultados favorables (respuesta más rápida a incidentes, aumento de la productividad del desarrollador) y menos trabajo manual y tiempo de inactividad. -Los sistemas informáticos se miden mediante la observación de señales de bajo nivel, como el tiempo de CPU, la memoria, el espacio en disco y las señales comerciales y de nivel superior, incluidos los tiempos de respuesta de API, errores, transacciones por segundo, etc. - -La observabilidad de un sistema tiene un impacto significativo en su costo operativo. -Los sistemas observables brindan datos significativos y procesables a sus operadores, lo que les permite lograr resultados favorables (respuesta más rápida a incidentes, mayor productividad del desarrollador) y menos trabajo y tiempo de inactividad. - -## ¿Cómo ayuda? - -Es esencial entender que más información no necesariamente significa que en un sistema sea más observable. -De hecho, a veces, la cantidad de información generada por un sistema puede dificultar la identificación de señales de salud valiosas debido al ruido generado por la aplicación. -La observabilidad requiere los datos correctos en el momento correcto para que el consumidor correcto (humano o pieza de software) tome las decisiones correctas. +Por consiguiente, cuán observable sea un sistema esto afectará significativamente sus costos operativos y de desarrollo. \ No newline at end of file diff --git a/content/es/platform-as-a-service.md b/content/es/platform-as-a-service.md index 3aa3116f6b..95f5083713 100644 --- a/content/es/platform-as-a-service.md +++ b/content/es/platform-as-a-service.md @@ -2,11 +2,9 @@ title: Plataforma como Servicio (PaaS) status: Deprecated category: Tecnología -tags: ["fundamentals", "platform", ""] +tags: ["fundamentos", "plataforma", ""] --- -## ¿Qué es? - Una plataforma como servicio, o PaaS, es una plataforma externa usada por los equipos de desarrollo de aplicaciones para desplegar y correr sus aplicaciones. Heroku, Cloud Foundry y App Engine son ejemplos de ofertas de PaaS. @@ -22,3 +20,4 @@ el manejo del [descubrimiento de servicios](/es/service-discovery/) y balanceo d Una solución PaaS ofrece herramientas de infraestructura comunes, a los desarrolladores de aplicaciones de forma totalmente automatizada. Permite que los desarrolladores puedan comprender y preocuparse menos por la infraestructura y así dedicar mas tiempo en escribir código de la aplicación. También proporciona cierta supervisión y [observabilidad](/es/observability/) para ayudar a los equipos de aplicaciones a garantizar que sus aplicaciones estén en buen estado. + diff --git a/content/es/pod.md b/content/es/pod.md new file mode 100644 index 0000000000..a362a8e6c9 --- /dev/null +++ b/content/es/pod.md @@ -0,0 +1,31 @@ +--- +title: Pod +status: Completed +category: Concepto +tags: ["infraestructura", "fundamento", ""] +--- + +Dentro de un entorno de [Kubernetes](/es/kubernetes/), un Pod actúa como la unidad más básica desplegable. +Representa un bloque de construcción esencial para desplegar y administrar aplicaciones contenedorizadas. +Cada Pod contiene una única instancia de la aplicación y puede albergar uno o más [contenedores](/es/container/). +Kubernetes administra los Pods como parte de un despliegue más grande y puede escalar los Pods [vertical](/es/vertical-scaling/) u [horizontalmente](/es/horizontal-scaling/) según sea necesario. + +## Problema que aborda + +Mientras los contenedores generalmente actúan como unidades independientes que ejecutan y controlan una carga de trabajo en particular, +hay casos en los que los contenedores necesitan interactuar y ser controlados de manera estrechamente acoplada. + +Si cada uno de estos contenedores estrechamente relacionados se administrara individualmente, se generarían tareas de gestión redundantes. +Por ejemplo, el operador tendría que determinar repetidamente la ubicación de los contenedores relacionados para asegurarse que permanezcan juntos. +Y aunque los ciclos de vida de estos contenedores relacionados necesitan estar sincronizados, solo se pueden administrar individualmente. + + +## ¿Cómo ayuda? + +Los Pods agrupan contenedores estrechamente vinculados en una única unidad, lo que simplifica significativamente las operaciones de contenedores. +Por ejemplo, los contenedores auxiliares a menudo se suelen utilizar junto con el contenedor principal para agregar funcionalidades adicionales o configurar aspectos globales. +Ejemplos de esto incluyen contenedores que inyectan y aplican configuraciones básicas al contenedor principal, +_sidecar_ (contenedores auxiliares) que manejan el enrutamiento del tráfico de red para el contenedor principal (ver [malla de servicios](/es/service-mesh/)) +o contenedores que recolectan registros en conjunto con cada contenedor. + +La asignación de memoria y CPU se puede definir a nivel de Pod, permitiendo a los contenedores internos a compartir recursos de forma flexible, o bien se puede definir por contenedor individualmente. diff --git a/content/es/policy-as-code.md b/content/es/policy-as-code.md index 67eaa47d08..06b36317fc 100644 --- a/content/es/policy-as-code.md +++ b/content/es/policy-as-code.md @@ -2,12 +2,10 @@ title: Política como código (PaC) status: Feedback Appreciated category: Concepto -tags: ["methodology", "", ""] +tags: ["metodología", "", ""] draft: true --- -## ¿Qué es? - Política como código es la práctica de almacenar la definición de políticas en uno o más archivos de manera que se pueda procesar y sea legible por máquina. Esto reemplaza el modelo tradicional en el que las políticas se documentan en forma legible por humanos, en documentos separados. diff --git a/content/es/portability.md b/content/es/portability.md index 92b848bad1..6036134b45 100644 --- a/content/es/portability.md +++ b/content/es/portability.md @@ -2,7 +2,7 @@ title: Portabilidad status: Completed category: Propiedad -tags: ["fundamental", "property", ""] +tags: ["fundamento", "propiedad", ""] --- La portabilidad es una característica del software, siendo una forma de reutilización que ayuda a evitar el "bloqueo" de ciertos entornos operativos, diff --git a/content/es/reliability.md b/content/es/reliability.md index 3d8a482430..e610db91a8 100644 --- a/content/es/reliability.md +++ b/content/es/reliability.md @@ -2,7 +2,7 @@ title: Fiabilidad status: Completed category: Propiedad -tags: ["fundamental", "property", ""] +tags: ["fundamento", "propiedad", ""] --- Desde una perspectiva nativa a la nube, fiabilidad se refiere a qué tan bien un sistema responde ante las fallas. diff --git a/content/es/role-based-access-control.md b/content/es/role-based-access-control.md new file mode 100644 index 0000000000..c22409807c --- /dev/null +++ b/content/es/role-based-access-control.md @@ -0,0 +1,24 @@ +--- +title: Control de Acceso Basado en Roles (RBAC) +status: Completed +category: Concepto +--- + +El control de acceso basado en roles (RBAC, por sus siglas en inglés) es un método para regular el acceso al sistema y los recursos en función de los roles individuales de los usuarios dentro de una organización. +Cada función laboral tiene un rol y permisos específicos. +Por ejemplo, un miembro del equipo de marketing puede tener permiso para ver las ventas en proceso (permiso de *lectura*), pero no se le permitirá editarlas (permiso de *escritura*). +Ventas y marketing tienen diferentes permisos según sus roles, de ahí el control de acceso basado en roles, y lo mismo se aplica a los roles dentro de los equipos de ingeniería. + +## Problema que aborda + +Gestionar individualmente los permisos de acceso de múltiples usuarios a través de diversos recursos y datos del sistema puede ser complejo. +Después de todo, es probable que cada usuario necesite acceder a un conjunto diferente de recursos. +Supongamos que una organización tiene 500 desarrolladores (usuarios) y 300 recursos con diferentes niveles de permisos (lectura, escritura y sin acceso). El administrador debe asegurarse de que cada usuario tenga los permisos correctos para los 300 recursos. +RBAC simplifica el proceso al proporcionar un control de acceso predefinido basado en grupos de roles. + + +## ¿Cómo ayuda? + +RBAC proporciona un control detallado sobre los permisos de usuario dentro de los sistemas de software. +Dependiendo de sus roles, los miembros del equipo pueden modificar una sección, solo verla o no tener acceso en absoluto. +Esta asignación detallada de permisos permite que los miembros del equipo con diferentes roles trabajen en el mismo sistema al mismo tiempo que se minimizan los riesgos. diff --git a/content/es/scalability.md b/content/es/scalability.md index 75a698cd7c..e078688727 100644 --- a/content/es/scalability.md +++ b/content/es/scalability.md @@ -2,7 +2,7 @@ title: Escalabilidad status: Completed category: Propiedad -tags: ["fundamental", "property", ""] +tags: ["fundamento", "propiedad", ""] --- La escalabilidad se refiere a que tan bien puede crecer un sistema. diff --git a/content/es/security-chaos-engineering.md b/content/es/security-chaos-engineering.md index 2308389ed3..7e6c802597 100644 --- a/content/es/security-chaos-engineering.md +++ b/content/es/security-chaos-engineering.md @@ -2,11 +2,9 @@ title: Seguridad en Ingeniería del Caos status: Completed category: Concepto -tags: ["security", "methodology", ""] +tags: ["seguridad", "metodología", ""] --- -## ¿Qué es? - Seguridad en Ingeniería del Caos, o SCE en Inglés, es una disciplina basada en la [Ingeniería del Caos](/es/chaos-engineering/). SCE ejecuta experimentos de seguridad de manera proactiva en un sistema distribuido para aportar confianza en la capacidad del sistema de soportar condiciones maliciosas o turbulentas. diff --git a/content/es/self-healing.md b/content/es/self-healing.md index 78812fb9b4..1da5550149 100644 --- a/content/es/self-healing.md +++ b/content/es/self-healing.md @@ -2,7 +2,7 @@ title: Recuperación Automática status: Completed category: Propiedad -tags: ["infrastructure", "property"] +tags: ["infraestructura", "propiedad"] --- Un sistema de reparación automática puede resolver ciertos tipos de fallos sin requerir intervención humana. diff --git a/content/es/serverless.md b/content/es/serverless.md index 2bd5aa79e8..0981102d63 100644 --- a/content/es/serverless.md +++ b/content/es/serverless.md @@ -2,33 +2,31 @@ Title: Sin servidor (Serverless) Status: Completed Category: Tecnología -tags: ["architecture", "", ""] +tags: ["arquitectura", "", ""] --- -## ¿Qué es? -Sin servidor (Serverless) es un modelo de desarrollo nativo en la nube que ayuda a los desarrolladores a -crear y ejecutar aplicaciones sin tener que mantener servidores. -Hay servidores en el modelo sin servidor, pero han sido [abstraídos](/es/abstraction/) del proceso de desarrollo. -Un proveedor de nube se encarga del aprovisionamiento, mantenimiento y [escalamiento](/es/scalability/) de la infraestructura de servidores. -Luego los desarrolladores pueden empacar su código en [contenedores](/es/containers/) para el despliegue. -Una vez desplegado el código, las aplicaciones sin servidor satisfacen la demanda y escalan automáticamente según sea necesario. -La modalidad sin servidor en proveedores de nube públicas usualmente es una medida bajo demanda a través de un modelo de ejecución basado en eventos. -Como resultado, cuando una función sin servidor está inutilizada, no representa costo alguno. +La computación sin servidor [abstrae](/es/abstraction/) los servidores del usuario. +La gestión operativa recae en el proveedor de servicios, incluido el manejo de máquinas físicas y el aprovisionamiento de Máquinas Virtuales. +Los proveedores de servicios pueden ser entidades de nube pública o departamentos de TI internos que prestan servicios a sus equipos de desarrollo. +Estos proveedores ofrecen interfaces de usuario como SDK, CLIs o tiempos de ejecución compatibles con OCI, centrándose en el código y las tareas de implementación. +Los cargos se basan en un modelo de pago por uso. +El [escalado](/es/scalability/) y el aprovisionamiento de recursos para cómputo, almacenamiento o redes, se ajustan automáticamente en función de la demanda de la aplicación sin intervención del usuario. +Un proveedor de plataforma sin servidor consolida recursos para atender a múltiples usuarios en una única máquina física, garantizando el aislamiento mediante la virtualización, especialmente con [Máquinas Virtuales](/es/virtual-machine/). + +Sin servidor (Serverless) es un término integral que abarca servicios con estos atributos y se extiende desde [Plataforma como Servicio (PaaS)](/es/platform-as-a-service/) hasta [Software como Servicio (SaaS)]( /es/software-as-a-service/). ## Problema que aborda -En un modelo de [Infraestructura como Servicio](/es/infrastructure-as-a-service/), -los usuarios compran unidades de cómputo o capacidad de forma anticipada, es decir, se paga a un proveedor de nube pública por componentes de servidores de ejecución continua para las aplicaciones. -Es responsabilidad del usuario luego aumentar la capacidad de cómputo durante periodos de alta demanda y -reducirla cuando ya no sea necesaria. -La infraestructura en la nube necesaria para ejecutar una aplicación está activa incluso cuando la aplicación no está en uso. +En los modelos tradicionales de [Infraestructura como Servicio (IaaS)](/es/infrastructure-as-a-service/), [computación en la nube](/es/cloud-computing/), los usuarios se comprometen a una capacidad predefinida, lo que genera cargos por disponibilidad del servidor independientemente del uso real. +La responsabilidad de ajustar la capacidad del servidor para satisfacer las demandas fluctuantes recae en el usuario, manteniendo la infraestructura activa incluso durante los períodos de inactividad. ## ¿Cómo ayuda? -En contraste, con la arquitectura sin servidor las aplicaciones son ejecutadas solo cuando es necesario. -Cuando un evento llama a una aplicación a ejecutarse, el proveedor de nube pública garantiza dinámicamente una serie de recursos para que se ejecute dicho código. -Además del beneficio de costo y eficiencia, -el modelo sin servidor libera a los desarrolladores de las tareas rutinarias asociadas al escalado y aprovisionamiento de servidores. -Con el modelo sin servidor, las tareas rutinarias como mantenimiento de los sistemas operativos y sistemas de archivos, parches de seguridad, -balanceo de carga, manejo de capacidad, escalado, auditoría y monitoreo pasan a estar en manos del proveedor de servicios de nube. \ No newline at end of file +La arquitectura sin servidor introduce un enfoque más eficiente, activando servicios únicamente según demanda. +Este modelo garantiza la asignación dinámica de recursos por parte de un proveedor de nube, eliminando costos por servicios no utilizados. +Más allá de la eficiencia financiera y operativa, la tecnología sin servidor alivia a los desarrolladores de la carga de escalar aplicaciones y administrar la infraestructura de servidores. +Tareas como el mantenimiento del sistema operativo, las actualizaciones de seguridad, el equilibrio de carga, la capacidad de planificación y el monitoreo se delegan al proveedor de la nube, lo que agiliza el proceso de desarrollo. + +Consulta la entrada del glosario [Función como Servicio (FaaS)](/es/function-as-a-service/) para obtener más información. +Aunque "sin servidor" y "FaaS" se utilizan a menudo como términos intercambiables, incorporan conceptos distintos. diff --git a/content/es/service-discovery.md b/content/es/service-discovery.md index 9b41d9f866..2980a2bc24 100644 --- a/content/es/service-discovery.md +++ b/content/es/service-discovery.md @@ -2,11 +2,9 @@ title: Descubrimiento de Servicio status: Completed category: Concepto -tags: ["networking", "", ""] +tags: ["redes", "", ""] --- -## ¿Qué es? - El descubrimiento de servicio es el proceso de identificar instancias individuales que pertenecen a un mismo servicio. Una herramienta de descubrimiento de servicio mantiene una lista de varios nodos o aplicaciones que componen un servicio. diff --git a/content/es/service-mesh.md b/content/es/service-mesh.md index 756d674528..75c1f09620 100644 --- a/content/es/service-mesh.md +++ b/content/es/service-mesh.md @@ -2,11 +2,9 @@ title: Malla de Servicios (Service Mesh) status: Completed category: Tecnología -tags: ["networking", "", ""] +tags: ["redes", "", ""] --- -## ¿Qué es? - En un mundo de [arquitectura de microservicios](/es/microservices-architecture/), las aplicaciones se dividen en múltiples [servicios](/es/service/) que se comunican a través de una red. Al igual que las redes de wifi, las redes de computadoras son poco confiables, proclives a ser atacadas y en muchos casos lentas. Las mallas de servicios (Service meshes) afrontan estos nuevos desafíos mediante el manejo de tráfico (por ejemplo la comunicación) entre servicios y diff --git a/content/es/service-proxy.md b/content/es/service-proxy.md index fe15d0498d..d4b429ecb7 100644 --- a/content/es/service-proxy.md +++ b/content/es/service-proxy.md @@ -2,11 +2,9 @@ title: Servicio de Proxy status: Completed category: Tecnología -tags: ["networking", "", ""] +tags: ["redes", "", ""] --- -## ¿Qué es? - Un servicio de Proxy intercepta tráfico desde o hacia un [servicio](/es/service/) determinado, aplicando algún tipo de lógica predefinida y luego envía ese tráfico hacia otro servicio. En esencia actúa como un agente intermedio que recolecta información referente al tráfico de red y/o aplica reglas al mismo. diff --git a/content/es/service.md b/content/es/service.md index 38861764c8..934435bfa7 100644 --- a/content/es/service.md +++ b/content/es/service.md @@ -2,7 +2,7 @@ title: Servicio status: Completed category: Concepto -tags: ["application", "fundamental", ""] +tags: ["aplicación", "fundamento", ""] --- Es importante señalar que en TI, el término 'servicio' tiene diversos significados. diff --git a/content/es/shift-left.md b/content/es/shift-left.md index 5ad727778a..2ff012b7d7 100644 --- a/content/es/shift-left.md +++ b/content/es/shift-left.md @@ -2,11 +2,9 @@ title: Shift Left status: Completed category: Concepto -tags: ["methodology", "", ""] +tags: ["metodología", "", ""] --- -## ¿Qué es? - El Desplazamiento a la Izquierda (Shift Left) se refiere a las etapas anteriores en un ciclo de vida de desarrollo de software, pensando en el ciclo de vida como una línea donde las etapas se ejecutan de izquierda a derecha. Shift Left es la práctica de implementar pruebas, seguridad u otras prácticas de desarrollo diff --git a/content/es/site-reliability-engineering.md b/content/es/site-reliability-engineering.md index c5e402cdec..aeb51fa57a 100644 --- a/content/es/site-reliability-engineering.md +++ b/content/es/site-reliability-engineering.md @@ -2,11 +2,9 @@ title: Site Reliability Engineering status: Completed category: Concepto -tags: ["methodology", "", ""] +tags: ["metodología", "", ""] --- -## ¿Qué es? - Site Reliability Engineering o SRE es una disciplina que combina operaciones e ingeniería de software. Este último se aplica a problemas de infraestructura y operaciones, específicamente. Es decir, en lugar de crear características del producto, los ingenieros de confiabilidad del sitio crean sistemas para ejecutar aplicaciones. diff --git a/content/es/software-as-a-service.md b/content/es/software-as-a-service.md index 33fdc3e663..bc87d13317 100644 --- a/content/es/software-as-a-service.md +++ b/content/es/software-as-a-service.md @@ -3,11 +3,9 @@ Title: Software como Servicio (SaaS) Status: Deprecated Category: Tecnología draft: true -tags: ["fundamental", "platform", ""] +tags: ["fundamento", "plataforma", ""] --- -## ¿Qué es? - El software como servicio (SaaS) permite a los usuarios conectarse y utilizar servicios basados en la nube a través de Internet. Los ejemplos comunes son el correo electrónico, el calendario y las herramientas de oficina (como Gmail, Amazon Web Servicios, GitHub, Slack). SaaS proporciona soluciones de software completas mediante pago por uso. diff --git a/content/es/stateful-apps.md b/content/es/stateful-apps.md index 7066d0e34e..d892503c6a 100644 --- a/content/es/stateful-apps.md +++ b/content/es/stateful-apps.md @@ -2,11 +2,9 @@ title: Aplicaciones con estado status: Completed category: Concepto -tags: ["fundamental", "application", ""] +tags: ["fundamento", "aplicación", ""] --- -## ¿Qué es? - Cuando hablamos de aplicaciones con estado (y [sin estado](/es/stateless-apps/)), éste estado se refiere a cualquier dato que la aplicación necesita almacenar para funcionar. Por ejemplo, cualquier tipo de tienda en línea que recuerda tu carro de compras es una aplicación con estado. diff --git a/content/es/stateless-apps.md b/content/es/stateless-apps.md index f165008603..cca280434b 100644 --- a/content/es/stateless-apps.md +++ b/content/es/stateless-apps.md @@ -2,11 +2,9 @@ title: Aplicaciones sin estado status: Feedback Appreciated category: Tecnología -tags: ["fundamental", "application", ""] +tags: ["fundamento", "aplicación", ""] --- -## ¿Qué es? - Una aplicación sin estado o independiente al estado, es la que no guarda ningún dato de sesión del cliente (estado) en el servidor donde la aplicación vive. Cada sesión del usuario se maneja como si fuese la primera vez y las respuestas no son dependientes de datos de la sesión anterior y brinda funcionalidad para usar servicios de impresión, Red de Distribución de Contenido (CDN, Content Delivery Network) o servidores web diff --git a/content/es/style-guide/_index.md b/content/es/style-guide/_index.md index 5a3cc74f5e..00de7c0bad 100644 --- a/content/es/style-guide/_index.md +++ b/content/es/style-guide/_index.md @@ -48,8 +48,6 @@ status: category: --- -## ¿Qué es? - Un breve resumen de la tecnología o concepto. ## Problema que aborda @@ -99,14 +97,14 @@ Exceptuando "fundamental", que simplemente indica que el término referido es vi Las etiquetas existentes son: -- application -- architecture -- fundamental -- infrastructure -- methodology -- networking -- property -- security +- aplicación +- arquitectura +- fundamento +- infraestructura +- metodología +- redes +- propiedad +- seguridad ```md --- diff --git a/content/es/tightly-coupled-architectures.md b/content/es/tightly-coupled-architectures.md index 45be3e472b..3cc69b8be0 100644 --- a/content/es/tightly-coupled-architectures.md +++ b/content/es/tightly-coupled-architectures.md @@ -2,7 +2,7 @@ title: Arquitecturas fuertemente acopladas status: Completed category: Propiedad -tags: ["fundamental", "architecture", "property"] +tags: ["fundamental", "arquitectura", "propiedad"] --- La arquitectura fuertemente acoplada es un tipo de arquitectura donde los componentes individuales de la aplicación son interdependientes diff --git a/content/es/transport-layer-security.md b/content/es/transport-layer-security.md index e2eb11a350..1ef23841f0 100644 --- a/content/es/transport-layer-security.md +++ b/content/es/transport-layer-security.md @@ -2,12 +2,9 @@ title: Transport Layer Security (TLS) status: Completed category: Concept -tags: ["security", "networking", ""] +tags: ["seguridad", "redes", ""] --- -## ¿Qué es? - -Transport Layer Security (TLS) es un protocolo diseñado para proporcionar mayor seguridad a la comunicación a través de una red. Garantiza la entrega segura de los datos enviados a través de Internet, evitando posibles seguimientos y/o alteraciones de los datos. Este protocolo es muy utilizado en aplicaciones como mensajería, correo electrónico, etc. diff --git a/content/es/version-control.md b/content/es/version-control.md index c6adf97264..150e2c972f 100644 --- a/content/es/version-control.md +++ b/content/es/version-control.md @@ -3,11 +3,9 @@ title: Control de versiones status: Deprecated category: Tecnología draft: true -tags: ["methodology", "", ""] +tags: ["metodología", "", ""] --- -## ¿Qué es? - El control de versiones (o control de fuente) es la práctica de rastrear y gestionar los cambios en un documento. Es un sistema que registra cambios en un archivo o conjunto de archivos a lo largo del tiempo, de manera que puedas recuperar versiones específicas más adelante. diff --git a/content/es/vertical-scaling.md b/content/es/vertical-scaling.md index 20adb766c8..3fe0ec73bf 100644 --- a/content/es/vertical-scaling.md +++ b/content/es/vertical-scaling.md @@ -2,11 +2,9 @@ title: Escalado Vertical status: Completed category: Concepto -tags: ["infrastructure", "", ""] +tags: ["infraestructura", "", ""] --- -## ¿Qué es? - El escalado vertical, también conocido como "agregar y reducir", es una técnica donde la capacidad de un sistema es incrementada agregando CPU y memoria a [nodos](/es/nodes/) individuales a medida que la carga de trabajo aumenta. Digamos que tenemos una computadora con 4GB de RAM y quisiéramos aumentar su capacidad a 16 GB de RAM, diff --git a/content/es/virtual-machine.md b/content/es/virtual-machine.md index de6ea04c7a..ebc2f18fe1 100644 --- a/content/es/virtual-machine.md +++ b/content/es/virtual-machine.md @@ -2,11 +2,9 @@ title: Máquina Virtual status: Completed category: Tecnología -tags: ["fundamental", "infrastructure", ""] +tags: ["fundamento", "infraestructura", ""] --- -## ¿Qué es? - Una máquina virtual (VM según sus siglas en Inglés) es una computadora y su sistema operativo no relacionados a un hardware específico. Las máquinas virtuales utilizan el método de [virtualización](/es/virtualization/) que crea múltiples computadoras virtuales dentro una sola computadora física. diff --git a/content/es/virtualization.md b/content/es/virtualization.md index 33b43c9f4b..b0c80cbfa3 100644 --- a/content/es/virtualization.md +++ b/content/es/virtualization.md @@ -2,11 +2,9 @@ title: Virtualización status: completed category: Tecnología -tags: ["fundamental", "infrastructure", "methodology"] +tags: ["fundamento", "infraestructura", "metodología"] --- -## ¿Qué es? - La virtualización, en el contexto de la computación nativa para la nube, refiere al proceso de tomar una computadora física, algunas veces llamada servidor, y permitirle ejecutar múltiples sistemas operativos aislados. diff --git a/content/es/zero-trust-architecture.md b/content/es/zero-trust-architecture.md index b7b1d96e41..5cc6f36d06 100644 --- a/content/es/zero-trust-architecture.md +++ b/content/es/zero-trust-architecture.md @@ -2,11 +2,9 @@ title: Arquitectura de Confianza Cero status: Completed category: Concepto -tags: ["security", "", ""] +tags: ["seguridad", "", ""] --- -## ¿Qué es? - La arquitectura de confianza cero se refiere a un enfoque del diseño y la implementación de sistemas informáticos donde la confianza se elimina por completo. El principio fundamental de "nunca confiar, siempre verificar" implica que los dispositivos o sistemas, al comunicarse con otros componentes, siempre deben verificarse a sí mismos antes de hacerlo. Hoy en día, en muchas redes corporativas, los sistemas y dispositivos internos pueden comunicarse libremente entre sí, ya que se encuentran dentro del límite de confianza del perímetro de dichas redes. diff --git a/content/fr/container-orchestration.md b/content/fr/container-orchestration.md index 578c6c8407..b13cc4b2f2 100644 --- a/content/fr/container-orchestration.md +++ b/content/fr/container-orchestration.md @@ -4,14 +4,14 @@ status: Completed category: Concept --- -L'orchestration de [Conteneurs](/fr/container/) fait référence à la gestion et à l'automatisation du cycle de vie d'applications conteneurisées au sein d'environnements dynamiques. -Réalisée à l'aide d'un orchestrateur de conteneurs (la plupart du temps, [Kubernetes](/fr/kubernetes)), elle permet les déploiements, le passage à l'échelle (automatique), (l'auto-)remédiation et le monitoring. +L'orchestration de [Conteneurs](/fr/container/) fait référence à la gestion et à l'automatisation du cycle de vie d'applications [conteneurisées](/fr/containerization/) au sein d'environnements dynamiques. +Réalisée à l'aide d'un orchestrateur de conteneurs (la plupart du temps, [Kubernetes](/fr/kubernetes/)), elle permet les déploiements, le passage à l'échelle (automatique), (l'auto-)remédiation et le monitoring. L'orchestration est une métaphore: L'outil d'orchestration dirige les conteneurs tel un chef d'orchestre, s'assurant que chaque conteneur (ou musicien) fait ce qu'il doit faire. ## Problème auquel il répond -Gérer manuellement des [microservices](/fr/microservices-architecture), la sécurité, et la communication réseaux à grande échelle — et des [systèmes distribués](/fr/distributed-systems) en général — est compliqué, pour ne pas dire impossible. +Gérer manuellement des [microservices](/fr/microservices-architecture/), la sécurité, et la communication réseaux à grande échelle — et des [systèmes distribués](/fr/distributed-systems/) en général — est compliqué, pour ne pas dire impossible. L'orchestration de conteneurs permet aux utilisateurs d'automatiser toutes ces tâches de gestion. ## Quelle en est l'utilité diff --git a/content/hi/search.md b/content/hi/search.md new file mode 100644 index 0000000000..d9a4d5beef --- /dev/null +++ b/content/hi/search.md @@ -0,0 +1,4 @@ +--- +title: Search Results +layout: search +--- \ No newline at end of file diff --git a/content/it/search.md b/content/it/search.md new file mode 100644 index 0000000000..d9a4d5beef --- /dev/null +++ b/content/it/search.md @@ -0,0 +1,4 @@ +--- +title: Search Results +layout: search +--- \ No newline at end of file diff --git a/content/ja/_TEMPLATE.md b/content/ja/_TEMPLATE.md new file mode 100644 index 0000000000..f830c85c2f --- /dev/null +++ b/content/ja/_TEMPLATE.md @@ -0,0 +1,19 @@ +--- +title: デフォルトテンプレート +status: Feedback Appreciated +category: コンセプト +--- + +コンセプトとその内容を簡単にまとめます。 + +## 解決すべき問題はなんですか + +解決すべき問題を定義します。理想的には、定義している用語に触れないことです。 + +## どのように役に立つのでしょうか + +その用語が上記の問題にどのように対処しているかを記述します。 + +## 関連する用語はありますか + +関連する用語の追加します(該当する場合) diff --git a/content/ja/_index.md b/content/ja/_index.md new file mode 100755 index 0000000000..cfb97904c7 --- /dev/null +++ b/content/ja/_index.md @@ -0,0 +1,52 @@ +--- +title: "クラウドネイティブ用語集" +status: Completed +--- + +# クラウドネイティブ用語集 + +クラウドネイティブ用語集は、技術者だけでなくビジネスサイドの人々にもわかりやすく伝えることで、複雑なことで有名なクラウドネイティブの領域を、人々にとってよりシンプルにすることを目指しています。そのために、シンプルであること(例:バズワードを使わないシンプルな言葉、テクノロジーを使う人なら誰でも共感できる例、不必要な詳細は省くなど)に重点を置いています。この用語集は、CNCFビジネスバリュー分科会(BVS, Business Value Subcommittee)が主導するプロジェクトです。 + +

People watching a Kubecon presentation

+ +## 貢献 + +クラウドネイティブ用語集の変更、追加、改良を提案することを歓迎します。 +私たちは、共有語彙目録を開発・改良するために、CNCFが管理するコミュニティ主導のプロセスを採用しています。 +この用語集は、クラウドネイティブテクノロジーに関する共有語彙を整理するために、ベンダーニュートラルなプラットフォームを提供します。 +プロジェクトの目的と憲章を遵守するすべての参加者からの投稿を歓迎します。 + + +貢献したい人は、GitHubのissueを提出するか、プルリクエストを作成することができます。 +[スタイルガイド](/ja/style-guide/)に従うことを確認し、[貢献の方法](/ja/contribute/)ドキュメントを読み, CNCF Slackの[#glossary](https://cloud-native.slack.com/archives/C02TX20MQBB) チャンネルに参加してください。 +また、用語集を母国語に翻訳する手伝いをしたい人のために、[#glossary-localizations](https://cloud-native.slack.com/archives/C02N2RGFXDF) チャンネルがあります。 + +## 謝辞 + +クラウドネイティブ用語集は、CNCFマーケティング委員会(ビジネスバリュー分科会)によって始められ、 +[Catherine Paganini](https://www.linkedin.com/in/catherinepaganini/en/), +[Chris Aniszczyk](https://www.linkedin.com/in/caniszczyk/), +[Daniel Jones](https://www.linkedin.com/in/danieljoneseb/?originalSubdomain=uk), +[Jason Morgan](https://www.linkedin.com/in/jasonmorgan2/), +[Katelin Ramer](https://www.linkedin.com/in/katelinramer/), +[Mike Foster](https://www.linkedin.com/in/mfosterche/?originalSubdomain=ca) +その他多くの貢献者による貢献が含まれています。 +全ての貢献者リストについては、[GitHub page](https://github.com/cncf/glossary/graphs/contributors) を参照してください。 + +用語集は +[Seokho Son](https://www.linkedin.com/in/seokho-son/), +[Noah Ispas](https://www.linkedin.com/in/noah-ispas-0665b42a/), +[Jihoon Seo](https://www.linkedin.com/in/jihoon-seo/), +[Nate W.](https://www.linkedin.com/in/nate-double-u/) +そして[Jorge Castro](https://www.linkedin.com/in/jorge-castro2112/)によってメンテナンスされています。 + +[Catherine Paganini](https://www.linkedin.com/in/catherinepaganini/en/), [Jason Morgan](https://www.linkedin.com/in/jasonmorgan2/) +は名誉メンテナーであり、長年にわたる彼らの貴重な貢献に深く感謝しています。 + +クラウドネイティブ用語集の日本語化は、[Kaito Ii](https://github.com/kaitoii11)、[Kohei Ota](https://github.com/inductor)、[Yuichi Nakamura](https://github.com/yuichi-nakamura)、[MItabashi](https://github.com/bashi8128)、[HANABE926](https://github.com/HANABE926)、[Junya Okabe](https://github.com/Okabe-Junya)、[Akira Aiura](https://github.com/A-aiura)、[shizhenhu](https://github.com/shizhenhu)、[Nao Nishijima](https://github.com/naonishijima)の貢献を通じて開始されました。 +クラウドネイティブ用語集の日本語への翻訳とローカライゼーションに興味のある方は、[#glossary-localization-japanese](https://app.slack.com/client/T08PSQ7BQ/C057F81GFUG) チャンネルにご参加ください。 + +## ライセンス + +すべてのコードの貢献はApache 2.0ライセンスに基づいています。 +ドキュメントはCC BY 4.0に基づいて配布されます。 diff --git a/content/ja/abstraction.md b/content/ja/abstraction.md new file mode 100644 index 0000000000..a4c6dda837 --- /dev/null +++ b/content/ja/abstraction.md @@ -0,0 +1,17 @@ +--- +title: 抽象化 +status: Completed +category: プロパティ +tags: ["基礎", "", ""] +--- + +コンピューティングのコンテキストでは、抽象化とは[サービス](/ja/service/)の消費者(消費者はコンピュータープログラムまたは人間)から詳細を隠す表現であり、システムをより一般的にして理解しやすくします。 +良い例は、ラップトップのオペレーティングシステム(OS)です。 +コンピューターがどのように動作するかの詳細を、すべて抽象化します。 +CPUやメモリ、プログラムの扱い方について何も知る必要はなく、OSを操作するだけで細かい部分はOSが処理してくれます。 +これらすべての詳細は、OSの「カーテン」または抽象化の背後に隠されています。 + +通常、システムには複数の抽象化レイヤーがあります。 +これにより、開発が大幅に簡素化されます。 +プログラミングの際、開発者は特定の抽象化レイヤーと互換性のあるコンポーネントを構築するため、非常に異質な可能性があるすべての下層レイヤーの詳細について心配する必要はありません。 +抽象化レイヤーで動作する場合は、内部に何があるかに関係なく、システムでも動作します。 diff --git a/content/ja/agile-software-development.md b/content/ja/agile-software-development.md new file mode 100644 index 0000000000..56d48da7a4 --- /dev/null +++ b/content/ja/agile-software-development.md @@ -0,0 +1,24 @@ +--- +title: アジャイルソフトウェア開発 +status: Completed +category: コンセプト +tags: ["方法論", "", ""] +--- + +アジャイルソフトウェア開発は、繰り返しの開発サイクルと自己組織化チームを重視する一連の実践です。 +プロジェクトの最後にのみ価値が生み出されるウォーターフォール型のプロジェクトとは対照的に、アジャイルソフトウェア開発は、継続的かつ段階的な価値の提供とプロセス自体の進化的な改善に焦点を当てています。 + +## 解決すべき問題はなんですか + +ソフトウェアプロジェクトにおいて、すべての関係者に対して要件を定義し、それを伝え理解させることは、不可能ではないにせよ非常に難しいです。 +しかし、顧客は自分たちのソフトウェアプロジェクトが時間通りに、良い品質で、予算内で、スコープ内で届けられることを望んでいます。 +その循環的な性質により、アジャイルソフトウェア開発は要件に継続的に適応することを可能にします。 +これはウォーターフォール型の戦略とは対照的で、他のすべての状況に適応することをより迅速に行うことができます。 + +## どのように役に立つのでしょうか + +アジャイルソフトウェア開発は、従来の(ウォーターフォール型の)戦略の全てのフェーズを含んでいます。 +これには要件定義、計画、実装、レビュー、テスト、納品などが含まれます。 +最大の違いは、ソフトウェアプロジェクトの全期間がイテレーションに分割され、そのそれぞれが全てのフェーズを含むことです。 +各イテレーションの後、顧客と一緒に作成された価値をレビューし、最終目標に向けて要件を調整することができます。 +さらに、開発チームはプロセス自体を改善するために取るべき行動を振り返ります。 diff --git a/content/ja/api-gateway.md b/content/ja/api-gateway.md new file mode 100644 index 0000000000..f13ab4dcc1 --- /dev/null +++ b/content/ja/api-gateway.md @@ -0,0 +1,22 @@ +--- +title: APIゲートウェイ +status: Completed +category: テクノロジー +tags: ["ネットワーキング", "", ""] +--- + +[API](/ja/application-programming-interface/)ゲートウェイは、いくつかのアプリケーションAPIを集約し、それらを一か所で利用可能にするツールです。 +これにより認証や認可、またはアプリケーション間のリクエスト数を制限するなどの重要な機能を中央管理された場所に集約することができます。 +APIゲートウェイは、(しばしば外部の)APIの利用者に対する共通のインターフェースとして機能します。 + +## 解決すべき問題はなんですか + +外部の利用者にAPIを提供する場合、すべてのアクセスを管理・制御するための一つのエントリーポイントが必要になります。 +さらに、それらのやり取りに機能を適用する必要がある場合、APIゲートウェイを使用するとアプリのコードを変更することなく、すべてのトラフィックに対して一様にそれを適用することができます。 + +## どのように役に立つのでしょうか + +アプリケーション内のさまざまなAPIに対して単一のアクセスポイントを提供するAPIゲートウェイは、組織の横断的なビジネスロジックやセキュリティロジックを一箇所に集中して適用するのを容易にします。 +また、アプリケーションの利用者がすべてのニーズに対して単一のアドレスを通じてアクセスできるようにもします。 +APIゲートウェイは、システム内のすべてのウェブサービスへのリクエストに対して単一のアクセスポイントを提供することで、セキュリティや[オブザーバビリティ](/ja/observability/)などの運用上の懸念を簡素化することができます。 +すべてのリクエストがAPIゲートウェイを通過するため、メトリクス収集、レート制限、認証などの機能を追加するための単一の場所となります。 diff --git a/content/ja/application-programming-interface.md b/content/ja/application-programming-interface.md new file mode 100644 index 0000000000..aaa4fdb074 --- /dev/null +++ b/content/ja/application-programming-interface.md @@ -0,0 +1,24 @@ +--- +title: アプリケーションプログラミングインタフェース(API) +status: Completed +category: テクノロジー +tags: ["アーキテクチャ", "基礎", ""] +--- + +APIは、コンピュータープログラム同士が互いにやり取りする方法です。 +人間がウェブページを介してウェブサイトとやり取りするように、APIはコンピュータープログラムが相互に通信するための手段を提供します。 +人間のやり取りとは異なり、APIには何が要求できるか、あるいはできないかについての制限があります。 +この制限によって、プログラム間で安定的で機能的なコミュニケーションが実現されます。 + +## 解決すべき問題はなんですか + +アプリケーションが複雑になるにつれて、小さなコードの変更が他の機能に大きな影響を及ぼす可能性があります。 +アプリケーションが成長しながらも安定性を維持するために、機能にモジュラーなアプローチを採用する必要があります。 +APIがなければ、アプリケーション同士が相互に通信するための枠組みが不足します。 +共有された枠組みがないと、アプリケーションが[スケール](/ja/scalability/)し、統合することが困難になります。 + +## どのように役に立つのでしょうか + +APIは、コンピュータープログラムやアプリケーションが定義された理解しやすい方法で相互に通信し、情報を共有することを可能にします。 +これは現代のアプリケーションの構成要素であり、開発者にアプリケーションを統合するための方法を提供します。 +[マイクロサービス](/ja/microservices-architecture/)が連携して動作しているのであれば、それはAPIを用いて相互に通信していると推測できます。 diff --git a/content/ja/auto-scaling.md b/content/ja/auto-scaling.md new file mode 100644 index 0000000000..c8b8ffa080 --- /dev/null +++ b/content/ja/auto-scaling.md @@ -0,0 +1,27 @@ +--- +title: オートスケーリング +status: Completed +category: プロパティ +tags: ["インフラストラクチャ", "", ""] +--- + +オートスケーリングとは、システムが自動的に[スケール](/ja/scalability/)する能力のことで、通常はコンピューティングリソースにおいて行われます。 +オートスケーリングシステムでは、必要に応じて自動的にリソースが追加され、変動するユーザーの需要に応じてスケールできます。 +オートスケーリングのプロセスは様々で、メモリーやプロセス時間などの異なるメトリクスに基づいてスケールするように設定可能です。 +マネージドクラウドサービスには通常、オートスケーリング機能が関連しています。 +これは、ほとんどのオンプレミス環境へのデプロイよりも多くのオプションと実装が利用可能であるためです。 + +以前はインフラストラクチャとアプリケーションが、システムのピーク使用量を考慮して設計されていました。 +このアーキテクチャにより、多くのリソースが未使用であり、消費者需要の変化に対して非弾力的でした。 +非弾力性は、ビジネスへの高コストと、過剰な需要によって発生する障害の営業損失を意味します。 + +クラウドを活用し、アプリケーションとその依存関係を[仮想化](/ja/virtualization/)および[コンテナ化](/ja/containerization/)することで、組織はユーザーの需要に応じてスケールするアプリケーションを構築できます。 +彼らはアプリケーションの需要を監視し、自動的にスケールさせ、最適なユーザーエクスペリエンスを提供できます。 +例えば、毎週金曜日の夕方に発生する、Netflixの視聴者数の増加を考えて見てください。 +オートスケールアウトは、動的により多くのリソースを追加することを意味します。 +例えば、ビデオストリーミングのためのサーバー数を増やし、需要が正常化されたらスケールバックすることです。 + +## 関連する用語はありますか + +* [水平スケーリング](/ja/horizontal-scaling/) +* [垂直スケーリング](/ja/vertical-scaling/) diff --git a/content/ja/bare-metal-machine.md b/content/ja/bare-metal-machine.md new file mode 100644 index 0000000000..acd3eb5049 --- /dev/null +++ b/content/ja/bare-metal-machine.md @@ -0,0 +1,25 @@ +--- +title: ベアメタルマシン +status: Completed +category: テクノロジー +tags: ["インフラストラクチャ", "", ""] +--- + +ベアメタルとは物理コンピューターを意味し、具体的にはサーバーのことでありオペレーティングシステムが1つしかないものです。 +最近のコンピューティングでは、サーバーの多くが[仮想マシン](/ja/virtual-machine/)であるため、この区別は重要です。 +物理サーバーは、一般的に強力なハードウェアを内蔵したかなり大型のコンピューターです。 +[仮想化](/ja/virtualization/)せずに、物理ハードウェア上にオペレーティングシステムをインストールし直接アプリケーションを実行することを"ベアメタル"上で実行すると呼ばれます。 + +## 解決すべき問題はなんですか + +1つのオペレーティングシステムと1台の物理コンピューターの組み合わせはコンピューティングの原型です。 +物理コンピューターのすべてのリソースがオペレーティングシステムで直接利用可能であり、仮想化レイヤーが存在しないため、オペレーティングシステムの命令をハードウェアに変換する際に人工的な遅延が発生しません。 + +## どのように役に立つのでしょうか + +コンピューターのすべての計算リソースを単一のオペレーティングシステムに割り当てることで、オペレーティングシステムに最高のパフォーマンスを提供できる可能性があります。 +ハードウェアリソースに極めて高速にアクセスしなければならないワークロードを実行する必要がある場合、ベアメタルが適切なソリューションかもしれません。 + +[クラウドネイティブアプリケーション](/ja/cloud-native-apps/)のコンテキストでは、私たちは一般的にパフォーマンスを、[水平スケーリング](/ja/horizontal-scaling/)(リソースプールにマシンを追加する)で処理できる多数の並行イベントへの[スケーリング](/ja/scalability/)という観点から考えます。 +しかし、ワークロードによっては[垂直スケーリング](/ja/vertical-scaling/)(既存の物理マシンにさらにパワーを追加する)が必要な場合や、極めて高速な物理ハードウェアのレスポンスが必要になる場合はベアメタルが適しています。 +また、ベアメタルにおいては、タスクを達成するために、物理ハードウェアや場合によってはハードウェアドライバをチューニングすることもできます。 diff --git a/content/ja/blue-green-deployment.md b/content/ja/blue-green-deployment.md new file mode 100644 index 0000000000..1f2a3b3142 --- /dev/null +++ b/content/ja/blue-green-deployment.md @@ -0,0 +1,27 @@ +--- +title: ブルーグリーンデプロイメント +status: Completed +category: コンセプト +tags: ["方法論", "アプリケーション", ""] +--- + +ブルーグリーンデプロイメントは、最小限のダウンタイムで稼働中のコンピューターシステムを更新する戦略です。 +オペレーターは、"ブルー"と"グリーン"と呼ばれる2つの環境を維持します。 +一方は本番トラフィックを処理し(現在すべてのユーザーが使用しているバージョン)、もう一方が更新されます。 +アクティブではない(グリーン)環境のテストが終了すると、本番トラフィックは(しばしばロードバランサーを使用して)切り替えられます。 +ブルーグリーンデプロイメントは通常、多くのサービスを含む全環境を一度に切り替えることを意味します。 +紛らわしいことに、時々この用語はシステム内の個々の[サービス](/ja/service/)に関して使用されます。 +このあいまいさを避けるため、個々のコンポーネントを指す場合には"ゼロダウンタイムデプロイメント"という用語が好まれます。 + +## 解決すべき問題はなんですか + +ブルーグリーンデプロイメントは、後方互換性がないために"ロックステップ"で変更する必要があるソフトウェアを更新する際に最小限のダウンタイムを可能にします。 +例えば、ウェブサイトとデータベースから成るオンラインストアの更新を考えます。 +新しいバージョンのデータベースが古いバージョンのウェブサイトと互換性がなく、その逆も同様である場合、ブルーグリーンデプロイメントが適しています。 +このインスタンスでは、両方を同時に変更する必要があります。 +これが本番システムで行われた場合、顧客はダウンタイムに気付くでしょう。 + +## どのように役に立つのでしょうか + +ブルーグリーンデプロイメントは、最小限のダウンタイムで更新する必要がある、クラウドネイティブではないソフトウェアに適した戦略です。 +しかし、その使用は通常レガシーソフトウェアが再設計され、コンポーネントを個別に更新できるようにする必要があるという"臭い"を放ちます。 diff --git a/content/ja/canary-deployment.md b/content/ja/canary-deployment.md new file mode 100644 index 0000000000..2b0a70cb80 --- /dev/null +++ b/content/ja/canary-deployment.md @@ -0,0 +1,28 @@ +--- +title: カナリアデプロイメント +status: Completed +category: コンセプト +tags: ["方法論", "アプリケーション", ""] +--- + +カナリアデプロイメントは、2つの環境から始まるデプロイメント戦略です。 +一つはライブトラフィックがある環境で、もう一つは更新されたコードを含む、ライブトラフィックがない環境です。 +トラフィックは徐々にアプリケーションの元のバージョンから更新されたバージョンへ移行します。 +最初にライブトラフィックの1%を移行し、次に10%、25%と続け、すべてのトラフィックが更新されたバージョンを流れるまで続けます。 +組織は本番環境で新しいバージョンのソフトウェアをテストし、フィードバックを得て、エラーを診断し、必要に応じて安定したバージョンに迅速にロールバックすることができます。 + +「カナリア」という用語は、「炭鉱のカナリア」という慣習に由来します。 +この慣習では、カナリア鳥を炭鉱に連れて行き、鉱夫の安全を確保していました。 +無臭の有害ガスが存在すると、鳥は死んでしまい鉱夫は迅速に避難する必要があることを知りました。 +同様に、更新されたコードに何か問題が発生した場合、ライブトラフィックは元のバージョンに「避難」されます。 + +## 解決すべき問題はなんですか + +テスト戦略をいかに徹底していても、本番環境では常にいくつかのバグが発見されます。 +アプリの100%のトラフィックをあるバージョンから別のバージョンに移行することは、より影響力のある障害につながる可能性があります。 + +## どのように役に立つのでしょうか + +カナリアデプロイメントにより、組織は新しいソフトウェアが実際のシナリオでどのように振る舞うかを、新しいバージョンに大量のトラフィックを移行する前に確認することができます。 +この戦略により、組織はダウンタイムを最小限に抑え、新しいデプロイメントに問題がある場合に迅速にロールバックすることができます。 +また、全体的なユーザーエクスペリエンスに大きな影響を与えることなく、徹底的な本番アプリケーションのテストを可能にします。 diff --git a/content/ja/chaos-engineering.md b/content/ja/chaos-engineering.md new file mode 100644 index 0000000000..011d974a4b --- /dev/null +++ b/content/ja/chaos-engineering.md @@ -0,0 +1,24 @@ +--- +title: カオスエンジニアリング +status: Completed +category: コンセプト +tags: ["方法論", "", ""] +--- + +カオスエンジニアリング(CE)とは、本番環境の[分散システム](/ja/distributed-systems/)に実験する学問分野です。 +分散システムが乱雑で予期せぬ状況に耐えるシステムの能力に対する信頼を築くことを目指します。 + +## 解決すべき問題はなんですか + +[SRE](/ja/site-reliability-engineering/)や[DevOps](/ja/devops/)の実践は、プロダクトの回復力と[信頼性](/ja/reliability/)を高める技術に焦点を当てています。 +システムが障害を許容しつつ適切なサービス品質を保証する能力は、通常のソフトウェア開発の要件です。 +インフラストラクチャ、プラットフォーム、あるいは([マイクロサービス](/ja/microservices-architecture/)ベースの)アプリケーションの他の動作部分のように、アプリケーションの停止につながる可能性のある複数の側面が関与しています。 +本番環境に新機能を高頻度でデプロイすることは、高い確率でダウンタイムと重大なインシデントをもたらし、ビジネスに重大な影響を及ぼす可能性があります。 + +## どのように役に立つのでしょうか + +カオスエンジニアリングは、回復力の要件を満たすための技術です。 +インフラストラクチャ、プラットフォーム、そしてアプリケーションの障害に対する回復力を達成するために使用されます。 +カオスエンジニアは、アプリケーション、インフラストラクチャ、あるいはプラットフォームが自己修復でき障害が顧客に目立った影響を与えないことを検証するために、プロアクティブにランダムな障害を注入するカオス実験を行います。 +カオス実験の目的は、盲点(例えば、モニタリングや自動スケーリング技術)を発見し、重大なインシデントの最中にチーム間のコミュニケーションを改善することです。 +このアプローチは、特に本番環境において、複雑なシステムにおける回復力とチームの自信を高めるのに役立ちます。 diff --git a/content/ja/client-server-architecture.md b/content/ja/client-server-architecture.md new file mode 100644 index 0000000000..673af6b4df --- /dev/null +++ b/content/ja/client-server-architecture.md @@ -0,0 +1,28 @@ +--- +title: クライアントサーバーアーキテクチャ +status: Completed +category: コンセプト +tags: ["アーキテクチャ", "基礎", ""] +--- + +クライアントサーバーアーキテクチャでは、アプリケーションを構築するロジック(あるいはコード)が2つ以上のコンポーネントに分割されます。 +それは作業の実行を要求するクライアント(例えばウェブブラウザで実行されるGmailのウェブアプリケーション)と、その要求を満たす1つ以上のサーバー(例えばクラウド内のGoogleのコンピューターで実行されるメール送信サービス)です。 +この例では、あなたが書いた送信メールは、クライアント(ウェブブラウザで実行されるウェブアプリケーション)によってサーバー(あなたの送信メールを受信者に転送するGmailのコンピューター)へ送られます。 + +これは、(例えばデスクトップアプリケーションのような)すべての作業を一つの場所で行う自己完結型のアプリケーションとは対照的です。 +例えば、Microsoft Wordのようなワードプロセッサープログラムは、あなたのコンピューター上にインストールされ完全にあなたのコンピューター上で実行されます。 + +## 解決すべき問題はなんですか + +クライアントサーバーアーキテクチャは、自己完結型のアプリケーションが抱える、定期的な更新という大きな課題を解決します。 +自己完結型アプリでは、更新のたびにユーザーは最新バージョンをダウンロードしてインストールする必要があります。 +Amazonの商品カタログ全体を、ブラウジングする前に自分のコンピューターにダウンロードすることを想像してみてください! + +## どのように役に立つのでしょうか + +リモートサーバーやサービスでアプリケーションロジックを実装することにより、オペレーターはクライアント側のロジックを変更することなく、それを更新できます。 +これによって更新をより頻繁に行うことができます。 +データをサーバー上に保存することで、多くのクライアントが同じデータを見て共有することができます。 +オンラインのワードプロセッサーを使用することと、従来のオフラインのワードプロセッサーを使用することの違いを考えてみてください。 +前者ではファイルはサーバー側に存在し、他のユーザーがサーバーからダウンロードするだけで共有することができます。 +従来の世界では、ファイルはリムーバブルメディア(フロッピーディスク!)にコピーされ、個別に共有される必要がありました。 diff --git a/content/ja/cloud-computing.md b/content/ja/cloud-computing.md new file mode 100644 index 0000000000..fc3fee0cd2 --- /dev/null +++ b/content/ja/cloud-computing.md @@ -0,0 +1,22 @@ +--- +title: クラウドコンピューティング +status: Completed +category: コンセプト +tags: ["インフラストラクチャ", "基礎", ""] +--- + +クラウドコンピューティングは、CPU、ネットワーク、ディスクなどの計算資源をインターネット上でオンデマンドで提供し、ユーザーは物理的に離れた場所にある計算能力にアクセスし、使用することができるようにします。 +一般に、クラウド基盤が組織専用のものか、オープンな公共サービスのために共有されているかによって、プライベートクラウドとパブリッククラウドに区別されます。 + +## 解決すべき問題はなんですか + +組織は従来、コンピューティングパワーを拡大しようとする際、主に2つの課題に直面していました。 +物理的なサーバーとネットワークをホストするための(新しい)設備を取得、サポート、設計するか、既存の設備を拡張、維持するかです。 +クラウドコンピューティングは、企業がコンピューティングニーズの一部をアウトソースできるようにすることで、この課題を解決しています。 + +## どのように役に立つのでしょうか + +クラウドプロバイダーは、企業がオンデマンドでコンピューティングリソースを借り、使用量に応じて料金を支払うことを可能にし、2つの重要な利点をもたらします。 +第一に、企業は新しい物理的なインフラストラクチャを待つことなく、計画し、リソースを費やすことなく、製品やサービスに集中することができます。 +そして2つ目は、必要に応じてオンデマンドで[拡張](/ja/scalability/)できることです。 +クラウドコンピューティングでは、必要な分だけインフラを導入することができます。 diff --git a/content/ja/cloud-native-apps.md b/content/ja/cloud-native-apps.md new file mode 100644 index 0000000000..828f4faecc --- /dev/null +++ b/content/ja/cloud-native-apps.md @@ -0,0 +1,26 @@ +--- +title: クラウドネイティブアプリケーション +status: Completed +category: コンセプト +tags: ["アプリケーション", "基礎", ""] +--- + +クラウドネイティブアプリケーションは、[クラウドコンピューティング](/ja/cloud-computing/)の技術革新を活用するため特別に設計されています。 +これらのアプリケーションは、それぞれのクラウドアーキテクチャと容易に統合でき、クラウドのリソースと[スケーリング](/ja/scalability/)機能を活用できます。 +また、クラウドコンピューティングによるインフラストラクチャの技術革新を活用するアプリケーションのことも指します。 +今日のクラウドネイティブアプリケーションには、クラウドプロバイダーのデータセンターで実行されるアプリケーションと、オンプレミスのクラウドネイティブプラットフォームで実行されるアプリケーションがあります。 + +## 解決すべき問題はなんですか + +従来、オンプレミス環境では、コンピューティングリソースをかなり特化した方法で提供していました。 +各データセンターは、アプリケーションを特定の環境に[密結合](/ja/tightly-coupled-architecture/)するサービスを持っており、多くの場合、[仮想マシン](/ja/virtual-machine/)やサービスのようなインフラストラクチャの提供は手作業に大きく依存していました。 +その結果、開発者とそのアプリケーションは、特定のデータセンターに制約されることになりました。 +クラウド用に設計されていないアプリケーションは、クラウド環境の耐障害性やスケーリング機能を活用することができません。 +例えば、正しく起動するために手作業が必要なアプリケーションは、自動的にスケーリングすることができず、障害発生時に自動的に再起動することもできません。 + +## どのように役に立つのでしょうか + +クラウドネイティブアプリケーションへの万能な道はありませんが、いくつかの共通点はあります。 +クラウドネイティブアプリケーションは弾力性があり、管理しやすく、それに付随する一連のクラウドサービスによって支援されます。 +さまざまなクラウドサービスによって、高度な[オブザーバビリティ](/ja/observability/)が有効になり、ユーザーは問題が深刻化する前に発見して対処することができます。 +堅牢な自動化と組み合わせることで、エンジニアは最小限の労力で、インパクトの大きい変更を頻繁にかつ予想通りに行うことができます。 diff --git a/content/ja/cloud-native-security.md b/content/ja/cloud-native-security.md new file mode 100644 index 0000000000..5b29362444 --- /dev/null +++ b/content/ja/cloud-native-security.md @@ -0,0 +1,27 @@ +--- +title: クラウドネイティブセキュリティ +status: Completed +category: コンセプト +tags: ["セキュリティ", "", ""] +--- + +クラウドネイティブセキュリティは、セキュリティを[クラウドネイティブアプリケーション](/ja/cloud-native-apps/)に組み込むアプローチです。 +開発から本番に至るまで、アプリケーションのライフサイクル全体にセキュリティが組み込まれていることを保証します。 +クラウドネイティブセキュリティは、従来のセキュリティモデルと同じ基準を保証しつつ、クラウドネイティブ環境の特性、すなわち迅速なコード変更や非常に短命な[^1]インフラストラクチャに適応することを目指します。 +クラウドネイティブセキュリティは、[DevSecOps](/ja/devsecops/)と呼ばれるプラクティスと非常に関係があります。 + +[^1]: 訳注:必要に応じてリソースを動的に拡張したり縮小したりするといった性質を持つ + +## 解決すべき問題はなんですか + +従来のセキュリティモデルは、もはや有効でない多くの前提のもとに構築されていました。 +クラウドネイティブアプリケーションは頻繁に変わり、多数のオープンソースツールやライブラリを使用し、多くの場合ベンダーが管理するインフラストラクチャで実行され、急速なインフラストラクチャの変更に影響を受けることがあります。 +コードレビューや長い品質保証サイクル、ホストベースの脆弱性スキャン、直前のセキュリティレビューは、クラウドネイティブアプリケーションに対応することはできません。 + +## どのように役に立つのでしょうか + +クラウドネイティブセキュリティは、従来のセキュリティモデルから、リリースサイクルのすべての段階でセキュリティが関与するモデルへと移行することにより、アプリケーションを保護する新しい方法を導入します。 +手作業による監査と監視は、大部分が自動スキャンに取って代わられます。 +迅速なコードリリースパイプラインは、コンパイル前にコードの脆弱性をスキャンするツールと統合されます。 +オープンソースライブラリは、信頼できるソースから取得され脆弱性がないか監視されています。 +クラウドネイティブセキュリティモデルは、緩やかな変化ではなく、脆弱性のあるコンポーネントを頻繁に更新したり、インフラストラクチャを定期的に交換したりすることを受け入れます。 diff --git a/content/ja/cloud-native-tech.md b/content/ja/cloud-native-tech.md new file mode 100644 index 0000000000..7218bb5064 --- /dev/null +++ b/content/ja/cloud-native-tech.md @@ -0,0 +1,23 @@ +--- +title: クラウドネイティブテクノロジー +status: Completed +category: コンセプト +tags: ["基礎", "", ""] +--- + +クラウドネイティブテクノロジーは、クラウドネイティブスタックとも呼ばれ、[クラウドネイティブアプリケーション](/ja/cloud-native-apps/)を構築するために使用される技術です。 +これらの技術により、組織がスケーラブルなアプリケーションを、パブリックやプライベート、ハイブリッドクラウドのようなモダンでダイナミックな環境で、[クラウドコンピューティング](/ja/cloud-computing/)の利点を最大限に活用しながら、構築や実行することができます。 +コンテナ、サービスメッシュ、マイクロサービス、イミュータブルインフラストラクチャなど、クラウドコンピューティングの機能を活用するために1から設計されたアプローチです。 + +## 解決すべき問題はなんですか + +クラウドネイティブスタックには多くの異なる技術カテゴリーがあり、様々な課題に対応しています。 +[CNCFクラウドネイティブランドスケープ](https://landscape.cncf.io/)を見ると、いかに多くの異なる領域に触れているかわかると思います。 +しかし高いレベルでは、主に従来のIT運用モデルのマイナス面に取り組んでいます。 +含まれる課題としては、拡張性がありフォールトトレラントな自己修復型アプリケーションの実現が困難であること、リソースの活用が非効率であることなどが挙げられます。 + +## どのように役に立つのでしょうか + +それぞれの技術は特定の問題に対応していますが、全体として、クラウドネイティブテクノロジーは弾力性があり管理可能で観測可能な疎結合のシステムを実現します。 +堅牢な自動化と組み合わせることで、エンジニアは最小限の労力で影響力の大きい変更を頻繁にかつ予測通りに行うことができます。 +クラウドネイティブシステムの望ましい特性は、クラウドネイティブスタックで実現することが容易になりました。 diff --git a/content/ja/cluster.md b/content/ja/cluster.md new file mode 100644 index 0000000000..4d3e73051f --- /dev/null +++ b/content/ja/cluster.md @@ -0,0 +1,26 @@ +--- +title: クラスター +status: Completed +category: コンセプト +tags: ["インフラストラクチャ", "基礎", ""] +--- + +クラスターは、共通の目的に向けて連携して働くコンピューターやアプリケーションのグループです。 +クラウドネイティブコンピューティングの文脈では、この用語は通常[Kubernetes](/ja/kubernetes/)に適用されます。 +Kubernetesクラスターは、通常異なるマシン上でそれぞれのコンテナ内で実行される一連のサービス(あるいはワークロード)です。 +これらすべての[コンテナ化](/ja/containerization/)されたサービスの集合がネットワーク上で接続され、クラスターを形成しています。 + +## 解決すべき問題はなんですか + +単一のコンピューター上で動作するソフトウェアには、単一障害点があります。 +もしそのコンピューターがクラッシュしたり、誰かが誤って電源ケーブルを抜いたりした場合、 +ビジネス上重要なシステムが利用できなくなる可能性があります。 +そのため、モダンなソフトウェアは一般的に[分散アプリケーション](/ja/distributed-apps/)として構築され、クラスターとしてまとめられます。 + +## どのように役に立つのでしょうか + +クラスター化された分散アプリケーションは複数のマシン上で実行され、単一障害点がなくなります。 +しかし、分散システムを構築することは非常に難しいです。 +実際、分散システムはコンピューターサイエンスの中で一つの分野として扱われています。 +グローバルなシステムの必要性と長い年月をかけた試行錯誤が、[クラウドネイティブ技術](/ja/cloud-native-tech/)と呼ばれる新たなタイプの技術スタックの開発につながりました。 +これらの新しい技術は、分散システムの運用と作成を容易にするための構成要素となります。 diff --git a/content/ja/container-orchestration.md b/content/ja/container-orchestration.md new file mode 100644 index 0000000000..635bb40629 --- /dev/null +++ b/content/ja/container-orchestration.md @@ -0,0 +1,22 @@ +--- +title: コンテナオーケストレーション +status: Completed +category: コンセプト +--- + +[コンテナ](/ja/container/)オーケストレーションとは、流動的な環境において、[コンテナ化](/ja/containerization/)されたアプリケーションのライフサイクルを管理し自動化することを指します。 +これはコンテナオーケストレータ(ほとんどの場合は[Kubernetes](/ja/kubernetes/))を通じて実行され、デプロイメント、(自動)スケーリング、自動ヒーリング、モニタリングが可能になります。 +オーケストレーションという言葉は比喩です。 +オーケストレーションツールは、音楽指揮者のようにコンテナを指揮し、すべてのコンテナ(または音楽家)が適切に機能するようにします。 + +## 解決すべき問題は何ですか + +スケールに応じて[マイクロサービス](/ja/microservices-architecture/)、セキュリティ、ネットワーク通信や一般的な[分散システム](/ja/distributed-systems/)を管理することは、手動で行うには難しく、場合によっては不可能です。 +コンテナオーケストレーションにより、これらすべての管理タスクを自動化することができます。 + +## どのように役に立つのでしょうか + +コンテナオーケストレーションツールは、ユーザーがシステムの状態を決定することを可能にします。 +まず、システムがどのようにあるべきかを宣言します(例えばx個のコンテナ、y個のPodなど)。 +その後、オーケストレーションツールは自動的にインフラを監視し、現状が宣言した状態から逸脱した場合には修正します(例えばコンテナがクラッシュした場合に新しいコンテナを立ち上げるなど)。 +この自動化により、プロビジョニング、デプロイメント、スケーリング(増減)、ネットワーキング、ロードバランシングといった、エンジニアリングチームが手作業で行う複雑な運用タスクが大幅に簡素化されます。 diff --git a/content/ja/container.md b/content/ja/container.md new file mode 100644 index 0000000000..23dbe0a35e --- /dev/null +++ b/content/ja/container.md @@ -0,0 +1,28 @@ +--- +title: コンテナ +status: Completed +category: テクノロジー +tags: ["アプリケーション", "基礎", ""] +--- + +コンテナは、コンピューターのオペレーティングシステムがリソースと機能面での制限を管理する、実行中のプロセスです。 +コンテナプロセスで利用可能なファイルは、コンテナイメージとしてパッケージ化されています。 +コンテナは一つのマシン上で同時に実行されますが、通常オペレーティングシステムは別々のコンテナプロセスが互いに干渉するのを防ぎます。 + +## 解決すべき問題は何ですか + +コンテナが利用可能になる前は、アプリケーションを実行するためには別々のマシンが必要でした。 +各マシンはそれぞれのオペレーティングシステムを必要とし、CPU、メモリ、ディスクスペースを消費します。 +これらは全て個々のアプリケーションが動作するために必要なものです。 +さらに、オペレーティングシステムのメンテナンス、アップグレード、起動は大きな手間のかかる作業です。 + +## どのように役に立つのでしょうか + +コンテナはオペレーティングシステムとそのマシンリソースを共有し、オペレーティングシステムのリソースオーバーヘッドを分散させ、物理マシンを効率的に使用します。 +これは通常コンテナが互いに干渉することが制限されているため、実現できます。 +これにより、同じ物理マシン上で多くのアプリケーションを実行することができます。 + +しかし、いくつかの制限もあります。 +コンテナは同じオペレーティングシステムを共有するため、プロセスは代替手段と比べて安全性が低いと考えられます。 +またコンテナは、共有されるリソースへの制限を必要とします。 +リソースを保証するために、管理者はメモリやCPUの使用を制限し、他のアプリケーションのパフォーマンスが低下しないようにする必要があります。 diff --git a/content/ja/containerization.md b/content/ja/containerization.md new file mode 100644 index 0000000000..f0cb04366a --- /dev/null +++ b/content/ja/containerization.md @@ -0,0 +1,26 @@ +--- +title: コンテナ化 +status: Completed +category: テクノロジー +tags: ["アプリケーション", "", ""] +--- + +コンテナ化は、アプリケーションとその依存関係をコンテナイメージにまとめるプロセスです。 +コンテナのビルドプロセスでは、[Open Container Initiative](https://opencontainers.org)(OCI)標準への準拠が必要です。 +出力がこの標準に準拠したコンテナイメージであれば、どのコンテナ化ツールを使用しても問題ありません。 + +## 解決すべき問題は何ですか + +[コンテナ](/ja/container/)が普及する前は、組織は仮想マシン(VM)に依存して、単一の[ベアメタルマシン](/ja/bare-metal-machine/)上で複数のアプリケーションをオーケストレーションしていました。 +VMはコンテナよりも非常に大きく、実行にはハイパーバイザーが必要です。 +これらの大きなVMテンプレートのストレージ、バックアップ、転送により、VMテンプレートの作成もより遅くなります。 +さらに、VMは[不変性](/ja/immutable-infrastructure/)の原則に反する構成ドリフトに悩まされることがあります。 + +## どのように役に立つのでしょうか + +コンテナイメージは(従来のVMとは異なり)軽量です。 +またコンテナ化のプロセスには依存関係のリストが記載されたファイルが必要です。 +このファイルはバージョン管理が可能で、ビルドプロセスを自動化できます。 +これにより組織は他の優先事項に集中でき、自動化されたプロセスがビルドを担当します。 +コンテナイメージは、その厳密な内容と設定に関連付けられた一意の識別子によって保存されます。 +コンテナがスケジュールされ再スケジュールされると、常に初期状態にリセットされるため、構成ドリフトが解消されます。 diff --git a/content/ja/continuous-delivery.md b/content/ja/continuous-delivery.md new file mode 100644 index 0000000000..00739d034b --- /dev/null +++ b/content/ja/continuous-delivery.md @@ -0,0 +1,27 @@ +--- +title: 継続的デリバリー(CD) +status: Completed +category: コンセプト +tags: ["方法論", "アプリケーション", ""] +--- + +継続的デリバリー(しばしばCDと略される)は、コードの変更が自動的に受け入れ環境にデプロイされる(または継続的デプロイメントの場合、本番環境にデプロイされる)一連の実践を指します。 +CDは、ソフトウェアがデプロイメント前に適切にテストされていることを保証する手順を重要視し、必要と判断された場合に変更をロールバックする方法を提供します。 +[継続的インテグレーション(CI)](/ja/continuous-integration/)は継続的デリバリーに向けた最初のステップです(つまり、テストやデプロイがされる前に、変更がうまく統合されなければなりません。) + +## 解決すべき問題は何ですか + +大規模な環境では、[信頼性](/ja/reliability/)の高いアップデートのデプロイが問題となります。 +理想的には、エンドユーザーにより良い価値を提供するために、頻繁にデプロイを行いたいところです。 +しかし、それを手動で行うと変更ごとに高いトランザクションコストが発生します。 +歴史的に、これらのコストを避けるために、組織は頻繁にリリースを行わず、一度に多くの変更をデプロイしてきましたが、これにより何かが間違ってしまうリスクが高まります。 + +## どのように役に立つのでしょうか + +CD戦略は、完全に自動化された本番環境へのパスを作成し、[カナリア](/ja/canary-deployment/)や[ブルーグリーン](/ja/blue-green-deployment/)リリースなどの様々なデプロイメント戦略を使用してソフトウェアをテストしデプロイします。 +これにより、開発者は頻繁にコードをデプロイすることができ、新しいリビジョンがテストされていることを安心して受け入れることができます。 + +## 関連する用語はありますか + +* [継続的インテグレーション](/ja/continuous-integration/) +* [継続的デプロイメント](/ja/continuous-deployment/) diff --git a/content/ja/continuous-deployment.md b/content/ja/continuous-deployment.md new file mode 100644 index 0000000000..4f80dc48ea --- /dev/null +++ b/content/ja/continuous-deployment.md @@ -0,0 +1,27 @@ +--- +title: 継続的デプロイメント(CD) +status: Completed +category: コンセプト +tags: ["アプリケーション", "方法論", ""] +--- + +継続的デプロイメント(しばしばCDと略される)は、完成したソフトウェアを直接本番環境にデプロイするという点で[継続的デリバリー](/ja/continuous-delivery/)より一歩進んでいます。 +継続的デプロイメント(CD)は[継続的インテグレーション](/ja/continuous-integration/)(CI)と密接に関連しており、しばしばCI/CDと呼ばれます。 +CIプロセスは特定のアプリケーションへの変更が有効であるかどうかをテストし、CDプロセスはコードの変更を自動的に組織のテスト環境や本番環境にデプロイします。 + +## 解決すべき問題はなんですか + +新しいソフトウェアバージョンのリリースは、労力がかかりエラーが発生しやすいプロセスです。 +また本番環境でのインシデントを避け、エンジニアが通常の業務時間外に対応する時間を減らすため、組織が頻繁に行わないことも多いです。 +伝統的なソフトウェアデプロイメントモデルでは、ソフトウェアのリリースプロセスが組織の安定性と機能の速度の両方に関するニーズを満たせず、組織を悪循環に陥らせます。 + +## どのように役に立つのでしょうか + +リリースサイクルを自動化し、組織が頻繁に本番環境へのリリースを強制することにより、CDは運用チームに対して、CIが開発チームにもたらした効果を実現します。 +具体的には、運用チームが本番へのデプロイメントの際に煩雑でエラーが発生しやすい部分を自動化するように促し、全体的なリスクを減少させます。 +また組織が本番環境の変更を受け入れ、適応する能力を向上させ、より高い安定性につながります。 + +## 関連する用語はありますか + +* [継続的インテグレーション](/ja/continuous-integration/) +* [継続的デリバリー](/ja/continuous-delivery/) diff --git a/content/ja/continuous-integration.md b/content/ja/continuous-integration.md new file mode 100644 index 0000000000..82e0bdf563 --- /dev/null +++ b/content/ja/continuous-integration.md @@ -0,0 +1,28 @@ +--- +title: 継続的インテグレーション(CI) +status: Completed +category: コンセプト +tags: ["アプリケーション", "方法論", ""] +--- + +継続的インテグレーション(CI)とは、コードの変更を可能な限り定期的に統合することを指します。 +CIは[継続的デリバリー](/ja/continuous-delivery/)(CD)の前提条件です。 +伝統的に、CIのプロセスはバージョンコントロールシステム(GitやMercurial、あるいはSubversion)にコードの変更がコミットされることで開始し、CDシステムで利用できるようになったテスト済みの成果物で終了します。 + +## 解決すべき問題はなんですか + +ソフトウェアシステムはしばしば大規模で複雑であり、多くの開発者が維持や更新をしています。 +システムの異なる部分で並行して作業を行う開発者たちは、意図せずに互いの作業を壊すような矛盾した変更を加えることがあります。 +さらに、同じプロジェクトに複数の開発者が取り組む場合、テストやコード品質の計測といった日常的なタスクは、各開発者によって繰り返される必要があり、時間の無駄になります。 + +## どのように役に立つのでしょうか + +CIソフトウェアは、開発者が変更をコミットするたびに、コードの変更がスムーズにマージできることを自動的に確認します。 +CIサーバーを使用してコードの品質チェック、テスト、さらにはデプロイメントを行うことは、広範囲にわたって一般的に行われる実践です。 +そのため、CIはチーム内の品質管理を具体的に実行する方法となります。 +CIを利用することで、ソフトウェアチームはすべてのコードのコミットを、具体的な失敗か実用的なリリース候補のいずれかにすることができます。 + +## 関連する用語はありますか + +* [継続的デリバリー](/ja/continuous-delivery/) +* [継続的デプロイメント](/ja/continuous-deployment/) diff --git a/content/ja/contribute/_index.md b/content/ja/contribute/_index.md new file mode 100644 index 0000000000..1a7a3a5a5c --- /dev/null +++ b/content/ja/contribute/_index.md @@ -0,0 +1,220 @@ +--- +title: 貢献の方法 +toc_hide: true +status: Completed +menu: + main: + weight: 10 +--- + +## ようこそ + +クラウドネイティブ用語集の貢献ガイドへようこそ。 +このプロジェクトに貢献できる方法はいくつかありますが、ここではその詳細を説明します: + +1) [既存の課題に取り組む](#work-on-an-existing-issue) +2) [新しい用語の提案](#propose-new-terms) +3) [既存の用語を更新する](#update-an-existing-term) +4) [用語集を翻訳する](#help-localize-the-glossary) + +## CNCF用語集レビュー + +この用語集のゴールは、複雑なことで有名なクラウドネイティブの空間をシンプルにすることで、より多くの人に親しんでもらうことです。 + +クラウドネイティブ用語集のコンテンツは[GitHub repo](https://github.com/cncf/glossary) に保存されています。 +ここには、用語集に関する[issues](https://github.com/cncf/glossary/issues), pull request ([PRs](https://github.com/cncf/glossary/pulls)), そして[discussions](https://github.com/cncf/glossary/discussions) のリストがあります。 + +## 誰が貢献できるのか? + +このプロジェクトにどのように参加できるかは、クラウドネイティブの専門知識のレベルによって異なります。 +複雑な概念を簡略化するには、そのトピックに関する深い知識が必要です。 +したがって、新しい用語を寄稿するには、その用語に精通している必要があります。 +貢献者は通常、これらの技術にしばらく携わってきたエンジニアや、クラウドネイティブに焦点を当てたアカデミックの経験者です。 + +複雑な概念を簡単な言葉で説明するのは _本当_ に難しいので、そのノウハウが必要です。そして、消化しやすく、ユーザーフレンドリーな結果は簡単に見えるかもしれませんが、望ましいシンプルさを実現するためには、クラウドネイティブの専門家たちの努力と協力が必要です。 + +もしあなたがまだクラウドネイティブの専門家ではないが、それでも貢献したいのであれば、専門家とチームを組むことをお勧めします。 +その専門家が、その用語がコンセプトを正確に表現していると確信したら、最初の用語集への投稿の準備ができました。 + +翻訳は、他言語に精通した初心者が用語集に貢献できる貴重な場です。 +英語での定義がしっかりしていれば、経験の浅い貢献者でも、用語を目標の言語に翻訳することができます。既存の翻訳チームに参加することも、新しいチームを作ることもできます。このガイドの[用語集の翻訳を支援する](#help-localize-the-glossary)のセクションを読んで、開始方法を学んでください。 + +## 始める前に + +用語集へ貢献する旅を始める前に、必ず以下のステップを完了してください: + +1. [GitHub アカウント](https://docs.github.com/en/get-started/signing-up-for-github/signing-up-for-a-new-github-account)を持っていなければ作成する。 +2. [貢献者ライセンス契約書](https://docs.linuxfoundation.org/lfx/easycla/v2-current/contributors) (CLA)にサインする。 +3. [コミット署名を確認する](https://docs.github.com/en/authentication/managing-commit-signature-verification/about-commit-signature-verification) +4. GitHubアカウントで[警戒モード](https://docs.github.com/en/authentication/managing-commit-signature-verification/displaying-verification-statuses-for-all-of-your-commits#about-vigilant-mode)を有効にすると、コミット時に検証ステータスが表示されます。 + +## ベストプラクティス {#best-practices} + +レビューを容易にするため、[セマンティック改行](https://sembr.org/)を使用してください(例:1文につき1行など)。 +私たちは、GitHubでマークダウンテキストを正しくフォーマットするために、この[マークダウンのチートシート](https://www.markdownguide.org/cheat-sheet/)を確認することをお勧めします(例:ハイパーリンク、ボールド、イタリック)。 +また、.md ファイルに名前をつけるときは、単語を区切るために小文字とスペースではなくハイフンを使い括弧は避けてください。 + +## スタイルガイド + +[スタイルガイド](/ja/style-guide/)を読んで、文書のフォーマットや書き方に関するガイドラインを理解し、投稿プロセスをより効率的にしてください。 + +## 用語集コミュニティに参加する! {#join-the-glossary-community} + +定期的に貢献したい場合は、毎月開催されるGlossary Working Groupのミーティングに参加することを検討してください。 +ミーティングの詳細は、[CNCFカレンダー](https://www.cncf.io/calendar/)で確認できます。 +また、CNCF Slackの[#glossary](https://cloud-native.slack.com/archives/C02TX20MQBB)チャンネルで、メンテナや他の貢献者とつながることもできます。あなたにお会いできるのを楽しみにしています! + +## 既存の課題に取り組む {#work-on-an-existing-issue} + +[用語集のGitHub issues](https://github.com/cncf/glossary/issues)に行くと、利用可能なissueのリストが見つかります。 +ラベル(例:English language、help needed、good first issue)を使って、課題をフィルタリングすることができます。 + +![Issueとラベル](/images/how-to/issue-and-labels.png) + +選択した用語がすでに誰かに割り当てられていないことを確認してください。 +例えば、ここでは、最初の3つの用語は利用可能ですが、4番目の用語はすでに割り当てられていることがわかります。 + +![用語を担当する](/images/how-to/howto-04.png) + +取り組むべき用語を選択したら、そのissueに対してコメントする。 + +![issueを主張する](/images/how-to/claiming-an-issue.png) + +さらに、CNCF Slackの[#glossary](https://cloud-native.slack.com/archives/C02TX20MQBB)チャンネルでメンテナに通知してください、そして +_@Catherine Paganini_, _@Seokho Son_, _@Jihoon Seo_, および/または _@iamnoah_ をタグ付けして、メンテナが見逃さないようにします。 + +次のステップについては、新しい用語の提案(PRの作成)(#submitting-a-new-term)のセクションを参照してください。 + +**備考**: メンテナがissueをあなたに割り当てた後、そのissueに取り組み始めることができます。 +一度に要求できるのは1つの用語のみです。 +複数の用語に対する作業は順次行われ、次の用語を要求する前に用語を完了させる必要があります。 + +## 新しい用語の提案 {#propose-new-terms} + +新しい用語を提案して他の人に取り組んでもらうことも、自分で新しい定義を作ることもできます。 +いずれにせよ、まずは[issueの作成](#creating-an-issue)から始めることになります。 +用語集に追加するには、すべての新しい用語が[CNCFのクラウドネイティブ定義](https://github.com/cncf/toc/blob/main/DEFINITION.md)を満たしている必要があります。 +ただし、クラウドネイティブの概念を理解するために必要な基礎的な用語だけは例外です。 + +以下は、GitHubに不慣れな人のためのステップバイステップガイドです。 +**GitHub Pro**の方は、このガイドに _目を通して_ 、以下のトピックについて十分な情報を集めてください: + +1. issueおよび新しい用語のテンプレートを探す +2. issueを要求する +3. [スペルチェック](#spell-check)の失敗を解決する + +### issueを作成する {#creating-an-issue} + +[用語集のGitHub repo](https://github.com/cncf/glossary/issues)issuesにアクセスして"New issue"をクリックしてください。 + +![issues](/images/how-to/howto-01.png) + +テンプレート一覧から「Request to add a new term (English)」を選択します。 + +![templates](/images/how-to/english-issue-template.jpg) + +提案する単語を追加し、質問に答え、チェックボックスにチェックを入れて、「Submit new issue」を押してください。 +新しい用語を提案するだけなら、これで完了です!定義に取り組みたい場合は、このまま読み進めてください。 + +### issueの優先順位 {#triaging-your-issue} + +次に、メンテナンス担当者はその問題の優先度を決めます。 +つまり、その用語が用語集に含まれるべきかどうかを評価するのです。 +すべての用語が認められるわけではありません。用語集に含めるには、確立された、広く使われているクラウドネイティブコンセプトである必要があります +。 +Slackでメンテナに新しい用語を提案したことを知らせてください。そして _@Catherine Paganini_, _@Seokho Son_, _@Jihoon Seo_, および/また _@iamnoah_ のタグを付けることを忘れないでください。 +もし、あなたがその定義に取り組みたいのであればメンテナに知らせてください。メンテナがあなたをアサインします。 + +### 新しい用語を登録する(PRを作成する) {#submitting-a-new-term} + +[スタイルガイド](/ja/style-guide/)にあるように、GoogleやWordのドキュメントで始めることを強くお勧めします。 + +用語の提出準備が整ったら、「content」へ... + +![content](/images/how-to/howto-05.png) + +...次に、「en(英語の場合)」または貢献する言語の最初の2文字.. + +![language folder](/images/how-to/howto-06.png) + +...そして `_TEMPLATE.md` を選択します。 + +![template](/images/how-to/howto-07.png) + +内容をコピーする... + +![copy content](/images/how-to/howto-08.png) + +...「en」フォルダーに戻ります。「Add file」をクリックし、「Create new file」を選択します。 + +![create new file](/images/how-to/howto-09.png) + +[ベストプラクティス](#best-practices)セクションで説明したURLに、用語の名前を追加します。 +名前の最後に拡張子.mdを追加します(この拡張子がないとファイルをプレビューすることができません)。 +次に、下のセクションにテンプレートの内容を貼り付けます。定義のテキストをコピーして、ファイルに貼り付けてください。 +[ベストプラクティス](#best-practices)のセクションで説明したように、マークダウンを使用したことを確認するために、「Preview」をクリックします。 + +![finalize term](/images/how-to/howto-10.png) + +下にスクロールして、新しいコミットファイルに名前をつけます。提出する準備ができたら、「Commit new file」を押してください。 +そして... + +![commit new file](/images/how-to/howto-11.png) + +...これで新しいPRを作成する準備ができました + +![create a pr](/images/how-to/howto-12.png) + +「Create pull request」ボタンを押すと、「Pull requests」タブにPRが表示されます。 + +![prs](/images/how-to/howto-13.png) + +## 既存の用語を更新する {#update-an-existing-term} + +既存の用語を更新するには、issueを作成して変更を依頼するか、自分で変更を行ってPRを提出します。 + +### issueから変更を依頼する {#request-a-change-via-an-issue} + +用語に関する問題にフラグを立てたい場合は、CNCF用語集ウェブページの「問題を報告する」オプションを使用することができます。 +フラグを立てたいコンセプトのCNCFページで自分の位置を確認し、「Report issue」をクリックします。 +これにより、自動的にあなたのためのissueが開かれます。 + +![report issue](/images/how-to/howto-14.png) + +あなたの提案と、それがなぜ必要なのかを説明してください。送信を押してください、それで終わりです。 + +![submit issue](/images/how-to/howto-15.png) + +### 用語を直接更新する {#update-a-term-directly} + +用語を修正したり、提案を提出したりするには、「Edit this page」をクリックします。 + +![edit this page](/images/how-to/howto-16.png) + +これにより、その用語のGitHubページが開きます。変更を加え、PRを作成してください。 +上記の[ベストプラクティス](#best-practices)セクションを参照し、私たちの[スタイルガイド](/ja/style-guide/)を読んで、私たちのガイドラインに従っていることを確認してください。 + +## 用語集のローカライズを支援する {#help-localize-the-glossary} + +用語集を目的の言語にローカライズするのを手伝うには、CNCF Slackワークスペースの [#glossary-localizations](https://cloud-native.slack.com/archives/C02N2RGFXDF) チャンネルに参加し、私たちにメッセージを送ってください。 +既存のチームに参加することも、新しいチームを作ることもできます。 +(何が必要かは、[ローカリゼーションガイド](https://github.com/cncf/glossary/blob/main/LOCALIZATION.md)を読んでください)。 +チームの貢献プロセスの詳細を収集するために、目的の言語の **How to contribute** ガイドをお読みください。 + +## スペルチェック {#spell-check} + +スペルチェックが失敗する理由は、主に2つあります: + +- PRにスペルミスが含まれている。 +- PRには、単語リストに登録されていない単語が含まれています。 + +新しい単語をリストに追加するには、次の手順に従います: + +1. PRの中に「wordlist.txt」というファイルを見つけます。 +2. 「このファイルを編集する」をクリックし、不足している単語をアルファベット順に追加します。 +3. コミットメッセージを追加し、「サインオフして変更を提案する」を選択します。 + +**注意**:スペルチェックは大文字と小文字を区別しません。 + + +**[The Good Docs Project](https://thegooddocsproject.dev/)のテンプレートに基づき、このガイドを更新しました。** \ No newline at end of file diff --git a/content/ja/contributor-ladder/_index.md b/content/ja/contributor-ladder/_index.md new file mode 100644 index 0000000000..e82a636d9a --- /dev/null +++ b/content/ja/contributor-ladder/_index.md @@ -0,0 +1,101 @@ +--- +title: 貢献者のラダー +toc_hide: true +status: Completed +menu: + main: + weight: 10 +--- + +こんにちは!👋 CNCFクラウドネイティブ用語集プロジェクトへの貢献に関心をお寄せいただきありがとうございます。新しい用語を投稿する、用語集を母国語にローカライズするのを手伝う、または他の人が用語集を始めるのを手助けするなど、このコミュニティのアクティブメンバーになる方法はたくさんあります。このドキュメントでは、プロジェクト内におけるそれぞれの貢献者の役割と、それに伴う責任と権限の概要を説明します。 + +## 1. 貢献者 + +用語集はすべての人のためのものです。このプロジェクトに貢献するだけで、誰でも用語集の貢献者になることができます。すべての貢献者は、[CNCF行動規範](https://github.com/cncf/foundation/blob/main/code-of-conduct.md)に従うことが期待されています。 + +プロジェクトに貢献するには、以下のようなさまざまな方法があります: + +- **コンテンツの貢献者**: 既存の用語を改良したり、新しい用語を投稿する方々 +- **ローカライゼーションの貢献者**: 用語集を他の言語に翻訳するのを手伝ってくれる方 +- **ヘルパー**:GitHubやSlackなど、コミュニティメンバーがサポートを必要としている場所で助ける方 +- **アンバサダー**:多くの人にメッセージを伝え、コミュニティに貢献の仕方やその理由について教えてくれる方 + +貢献者は、複数の役割を持つことも、1つの分野のみに集中することもできます。***これらの貢献はすべて等しく重要であり***、活気あるコミュニティの育成に貢献します。コンテンツとローカライゼーションへの貢献については、[貢献方法](/ja/contribute/)と[スタイルガイド](/ja/style-guide/)を参照してください。 + +## 2. 承認者 + +承認者は、PRに対するフィードバックを提供しPRを承認します。アクティブな投稿者なら誰でも承認者になれます([承認者になる](#承認者になる)を参照)。用語集では、(1)英語用語集の承認者と(2)ローカライズチームの承認者の2つの承認者を区別しています。 + +用語集の承認者には次のことが期待されます: + +- PRが技術的に正確かどうかを確認します +- 貢献者に課題を割り当て、適切なラベルを付けます +- 貢献者にフィードバックを提供し、必要に応じて指導します +- 提出物の校正と編集します + +承認者が上記の職務に興味がなくなったり、遂行できなくなった場合は、メンテナにその旨を伝え辞任すべきです。 + +### 英語用語集の承認者 + +承認者には3つのタイプがあります: + +1) 強力な技術的背景を持つ承認者 +2) 確かな文章力を持つ承認者 +3) 両方に精通した承認者 + +**技術承認者**:しっかりとした英文のライティングスキルがなくても、技術的なバックグラウンドが強力な人なら承認者になれます。ただし、技術的な利点に基づいてPRを承認する場合は、必ず(編集)承認者によるレビューをしなければなりません。 + +**編集者**:編集者は用語を校正し、スタイルガイドに従って簡単な言葉で説明されていることを確認します。用語が大幅に編集されている場合、編集者は意味が変更されていないことを確認するため、技術承認者に再度校閲を依頼しなければなりません。 + +### ローカライゼーションの承認者 + +用語集にはローカライゼーション承認者もいます。この承認者は、ローカライゼーションチーム (用語集を翻訳するチーム) の承認者です。ローカライゼーションの承認者は、自分のチームの承認者の職務のみを行うことができ、PRを専用の開発ブランチにマージすることができます。ローカライゼーションの承認者は、要件を満たせば英語用語集の承認者になることもできます。 + +### 承認者になる + +承認者候補は、高品質のPRを提出し、他の人がPRをマージ可能な状態にするのを支援してきた実績があるべきです。また、タイムゾーンが許せば[用語集ワーキンググループのミーティング](https://www.cncf.io/calendar/)に定期的に出席してください。 + +承認者になるには、興味があることを既存のメンテナーに伝えることから始めましょう。既存のメンテナーはあなたに、彼らの指導のもとでPRを投稿したり、レビューをしたり、その他の仕事をしたり上記の資格を証明するよう求めます。しばらく一緒に仕事をした後、メンテナーはあなたに承認者の資格を与えるかどうかを決定します。この決定は、あなたが示した熟練度と対応能力に基づいて行われます。 + +## 3. メンテナー + +メンテナーもPRをマージすることができます。誰でも用語集のメンテナーになることができます([メンテナーになる](#メンテナーになる)を参照)。メンテナーには、以下のような期待があります: + +- 積極的かつ迅速な承認者であること(上記参照) +- サイトの設定、パーミッション、Issueテンプレート、GitHubワークフローなど、リポジトリのメンテナンスをサポートします +- 用語集のSlackチャンネルを監視し可能な限り協力します +- [用語集ワーキンググループミーティング](https://www.cncf.io/calendar/)に定期的に出席します(タイムゾーンが許せば) + +もしメンテナーが上記の職務に興味がなくなったり、遂行できなくなったりした場合は、名誉メンテナーに移行する必要があります。 + +### メンテナーになる + +メンテナーは、承認者として成功し、質の高いPRを提出してきた実績があるべきです。また、タイムゾーンが許せば用語集ワーキンググループのミーティングに定期的に出席する必要があります。 + +メンテナーになるには、興味があることを既存のメンテナーに伝えることから始めましょう。既存のメンテナーはあなたに、彼らの指導のもとでPRを投稿したり、レビューをしたり、その他の仕事をしたり上記の資格を証明するよう求めます。しばらく一緒に仕事をした後、メンテナーはあなたにメンテナーの地位を与えるかどうかを決定します。この決定は、あなたが示した熟練度と対応能力に基づいて行われます。 + +## 4. コミュニティマネージャー + +コミュニティマネージャーは、有効的で魅力的なコミュニティの育成を支援します。コミュニティメンバーは誰でもコミュニティマネージャーになることができます。コミュニティマネージャーには次のことが求められます: + +- 新しいメンバーを歓迎し、必要な情報が得られるようにします +- コミュニティからの質問に答えたり、手助けできる人を探すのを手伝います +- Slackでの会話をモデレートします + +### コミュニティマネージャーになる + +用語集のコミュニティマネージャーは誰でもなることができます。コミュニティマネージャーは、貢献とローカライゼーションのプロセスをしっかりと理解し、他者との交流や手助けを楽しむことが求められます。コミュニティマネージャーになるには、興味があることを既存のメンテナーに伝えることから始めましょう。オンボード/トライアル期間を経て、メンテナーは実績に基づいてコミュニティマネージャーのステータスを付与するかどうかを決定します。 + +## 非自主的な解任 + +貢献者の非自主的な解任は、責任と要求が満たされない場合に行われます。これには、度重なる活動停止、長期の活動停止、および/または行動規範違反などが含まれます。このプロセスは、コミュニティとその成果物を保護すると同時に、新しい貢献者が参入する機会を開くという意味で重要です。 + +## 退任/名誉職のプロセス + +貢献者のコミットメントレベルが変化した場合、貢献者は退任(貢献者のラダーを下げること[^1])か名誉職(プロジェクトから完全に離れる)かを検討することができます。 + +[^1]: 訳注:例えば、メンテナ―から承認者に貢献レベルを落とす + +## 役職への復帰 + +以前の貢献者の役割に戻ることができる人材がいれば、プロジェクトリーダーはそれを手配し、検討することができます。 diff --git a/content/ja/data-center.md b/content/ja/data-center.md new file mode 100644 index 0000000000..70c83ad330 --- /dev/null +++ b/content/ja/data-center.md @@ -0,0 +1,25 @@ +--- +title: データセンター +status: Completed +category: テクノロジー +tags: ["インフラストラクチャ", "基礎", ""] +--- + +データセンターはコンピューター(その多くはサーバー)を収容するために設計された特別な建物または施設です。 +これらのデータセンターが[クラウドコンピューティング](/ja/cloud-computing/)に重点を置いている場合、高速なインターネット回線に接続される傾向があります。 +データセンターが入っている建物には、停電時に電力を供給する発電機や、発熱するコンピューターを冷却する強力な空調機など、停電が発生した場合でもサービスを維持できる設備が備えられています。 + +## 解決すべき問題は何ですか + +1990年代後半にデータセンターが普及するまでは、主に特定の業務プロセスを実行するための専用のコンピューターであり、または個人が作業を行うためにコンピューターが使用されていました。 +ただし、コンピューターのリソース(ハードディスク、メモリ、CPU)は限られているため、その上で実行されるアプリケーションには厳しい制約があり、実行できるアプリケーションの種類が制限されます。 +データセンターが普及する前は、アプリケーションの規模が実行されているコンピューターの容量によって制限されていました。 +しかし、GmailやNetflixのような大規模なアプリケーション(携帯電話やコンピューターのユーザーインターフェースではなくサーバーサイドアプリ)について考えてみると、1 台のコンピューターが提供できる能力よりも多くのコンピューティング能力が必要になります。 +そこでデータセンターが登場します。 + +## どのように役に立つのでしょうか + +ユーザーはさまざまなサーバーに接続することで、「スーパーコンピューター」のように機能する[分散システム](/ja/distributed-systems/)を構築できます。 +複数のマシンの能力を統合しているため、より大規模なサーバーサイドアプリや業務プロセスを実行したり、より強力な計算タスクを処理したりできるようになりました。 +私たちが日常的に使用するほとんどのアプリケーションがデータセンターで実行されています。 +[パブリッククラウド](/ja/cloud-computing/)はクライアントにコンピューターリソースを貸し出すデータセンターです。ここ数年、企業所有のデータセンターからパブリッククラウドへ移行している事例が多数あります。 diff --git a/content/ja/devops.md b/content/ja/devops.md new file mode 100644 index 0000000000..fb9c6d9ccc --- /dev/null +++ b/content/ja/devops.md @@ -0,0 +1,26 @@ +--- +title: DevOps +status: Completed +category: コンセプト +tags: ["方法論", "", ""] +--- + +DevOpsは、アプリケーション開発から本番運用までの全過程をチームが所有する方法論で、それゆえDevOpsと呼ばれます。 +これは一連の技術を実装することを超えて、文化やプロセスの完全な変革を必要とします。 +DevOpsは、(全体の機能ではなく)小さなコンポーネントに取り組むエンジニアのグループを求め、エラーの一般的な原因である引き渡しの回数を減らします。 + +## 解決すべき問題はなんですか + +従来、[密結合な](/ja/tightly-coupled-architecture/)[モノリシックアプリ](/ja/monolithic-apps/)を持つ複雑な組織では、通常、作業は複数のグループ間で断片化されていました。 +これにより多くの引き渡しと長いリードタイムが発生しました。 +コンポーネントやアップデートが準備できるたびに、それは次のチームのキューに置かれました。 +個々の担当者はプロジェクトの一部分のみを扱うため、このアプローチは所有権の欠如につながりました。 +彼らの目標は、作業を次のグループに渡すことであり、顧客に適切な機能を提供することではありませんでした。 +これは明らかな優先順位のずれです。 + +コードが最終的に本番環境に入る頃には、多くの開発者を経由し、多くのキューで待機していたため、コードが動作しない場合の問題の原因を追跡するのが難しくなりました。 +DevOpsはこのアプローチを根本から覆します。 + +## どのように役に立つのでしょうか + +アプリケーションの全ライフサイクルを一つのチームが担当することで、引き渡しを最小限に抑え、本番環境へデプロイする際のリスクを減少させ、チームが本番環境でのコードのパフォーマンスにも責任を持つことでコード品質が向上し、より多くの自律性と所有権により従業員の満足度も高まります。 diff --git a/content/ja/devsecops.md b/content/ja/devsecops.md new file mode 100644 index 0000000000..9e7b259e54 --- /dev/null +++ b/content/ja/devsecops.md @@ -0,0 +1,23 @@ +--- +title: DevSecOps +status: Completed +category: コンセプト +tags: ["方法論", "セキュリティ", ""] +--- + +DevSecOpsという用語は、開発、運用、およびセキュリティの責任の文化的統合を指します。 +これは、開発と運用のワークフローを最小限に乱すことなく、セキュリティの優先順位を含むように[DevOps](/ja/devops/)アプローチを拡張します。 +DevOpsと同様に、DevSecOpsは採用された技術によって推進される文化的変革であり、独自の適用方法があります。 + +## 解決すべき問題はなんですか + +DevOpsの実践には、[継続的インテグレーション](/ja/continuous-integration/)、[継続的デリバリー](/ja/continuous-delivery/)、および[継続的デプロイメント](/ja/continuous-deployment/)が含まれ、アプリケーションの開発とリリースサイクルを加速します。 +残念ながら、自動化されたリリースプロセスが組織のすべてのステークホルダーを適切に表現できない場合には、既存の問題を悪化させる可能性があります。 +セキュリティのニーズを考慮せずに構築された新しいソフトウェアを迅速にリリースするプロセスは、組織のセキュリティ態勢を低下させる可能性があります。 + +## どのように役に立つのでしょうか + +DevSecOpsは、チームのサイロを壊し、安全な自動化されたワークフローの作成を促進することに焦点を当てています。 +セキュリティアプリケーションを選択する際、組織は開発者を支援する自動化されたCI/CDワークフローとポリシーの施行を活用する必要があります。 +障害物になることではなく、セキュリティポリシーを施行しつつ、ユーザーにプロジェクトを前進させる方法に関する正確な情報を提供することが目標です。 +適切に実装された場合、組織はより良いチームコミュニケーションを得て、セキュリティ事故と関連コストを減らすことができます。 diff --git a/content/ja/distributed-apps.md b/content/ja/distributed-apps.md new file mode 100644 index 0000000000..5205b2199b --- /dev/null +++ b/content/ja/distributed-apps.md @@ -0,0 +1,27 @@ +--- +title: 分散アプリケーション +status: Completed +category: コンセプト +tags: ["アーキテクチャ", "", ""] +--- + +分散アプリケーションは、機能が複数の独立したより小さな要素に分割されたアプリケーションです。 +分散アプリケーションは通常、広範なアプリケーション内で異なる機能を担う個々の[マイクロサービス](/ja/microservices-architecture/)から構成されます。 +クラウドネイティブ環境において、個々のコンポーネントは[クラスター](/ja/cluster/)内の[コンテナ](/ja/container/)として実行されます。 + +## 解決すべき問題はなんですか + +単一のコンピューター上で動作している単一のアプリケーションは単一障害点となります。 +もしそのコンピューターが故障した場合、そのアプリケーションは利用できなくなります。 +分散アプリケーションは、しばしば[モノリシックアプリケーション](/ja/monolithic-apps/)と比較されます。 +モノリシックアプリケーションは、様々なコンポーネントが独立してスケールできないために、スケールが難しい場合があります。 +さらに、それらは成長するにつれて開発者の速度の妨げになることもあります。 +なぜなら、より多くの開発者が明確に定義された境界を持つとはかぎらない共有のコードベースで作業する必要があるからです。 + +## どのように役に立つのでしょうか + +単一のアプリケーションを異なる部分に分割し、それらを多くの場所で実行すると、システム全体としてはより障害を許容できるようになります。 +また、単一のアプリケーションでは利用できなかったスケーリング機能を活用できるようになります。 +つまり、[水平スケーリング](/ja/horizontal-scaling/)ができるようになります。 +しかしながら、これには複雑さの増加と運用のオーバーヘッドによるコストがかかります。 +こうして、単一のアプリケーションではなく多くのアプリケーションのコンポーネントを実行することになります。 diff --git a/content/ja/distributed-systems.md b/content/ja/distributed-systems.md new file mode 100644 index 0000000000..77fc176b62 --- /dev/null +++ b/content/ja/distributed-systems.md @@ -0,0 +1,30 @@ +--- +title: 分散システム +status: Completed +category: コンセプト +tags: ["アーキテクチャ", "", ""] +--- + +分散システムは、ネットワーク上で接続された自立型のコンピューティング要素の集合であり、ユーザーから見ると1つの統一されたシステムとして見えます。 +一般的には[ノード](/ja/nodes/)と言われるこれらの要素は、ハードウェアデバイス(例: コンピューターや携帯電話)やソフトウェアのプロセスです。 +ノードは共通の目標を達成するためにプログラムされており、連携するためにネットワーク上でメッセージを交換します。 + +## 解決すべき問題はなんですか + +現代の多くのアプリケーションは、運用するのにスーパーコンピューターが必要になるほど大規模です。 +GmailやNetflixを考えてみて下さい。 +単一のコンピューターでは、アプリケーション全体を提供するのに十分な性能がありません。 +複数のコンピューターを接続することで、計算能力はほとんど無制限になります。 +分散コンピューティングなしでは、今日、我々が頼りにしている多くのアプリケーションは実現できないでしょう。 + +従来、システムは垂直に[スケール](/ja/scalability/)するものでした。 +これは、個々のマシンにCPUやメモリを追加するときのことを指します。 +垂直スケーリングには時間がかかり、ダウンタイムを必要とし、また、すぐに限界に達します。 + +## どのように役に立つのでしょうか + +分散システムは[水平スケーリング](/ja/horizontal-scaling/)(例えば、必要に応じてシステムにノードを追加すること)を可能にします。 +これは自動化できるため、システムは急激なワークロードやリソース消費の増加に対応できるようになります。 + +分散システムでないシステムは、1台のマシンが故障するとシステム全体が故障するというリスクにさらされます。 +分散システムは、いくつかのマシンがダウンしたとしても、システム全体としては同じ結果を返し続けるように設計することができます。 diff --git a/content/ja/ebpf.md b/content/ja/ebpf.md new file mode 100644 index 0000000000..402b3fef11 --- /dev/null +++ b/content/ja/ebpf.md @@ -0,0 +1,37 @@ +--- +title: eBPF +status: Completed +category: テクノロジー +tags: ["アーキテクチャ", "ネットワーキング", "セキュリティ"] +--- + +eBPF (extended Berkeley Packet Filter)は、Linuxカーネルのソースコードを修正したりカーネルモジュールを導入したりすることなく、サンドボックス化された小さなプログラムやスクリプトをLinuxシステムのカーネル空間で実行できる技術です。 + +Linuxシステムには2種類の空間があります。カーネル空間とユーザー空間です。 +カーネルはOSのコアにあたり、ハードウェアに無制限でアクセスできる唯一の部分です。 + +アプリケーションはユーザー空間で動作し、高位の権限が必要な場合にカーネルへ要求を送ります。 +ハードウェアへの直接アクセスなど、より柔軟性を必要とするアプリケーションについては、「Linuxカーネルモジュール」として知られるアプローチでカーネルを拡張することができます。 +このアプローチによりカーネルの標準機能は拡張され、アプリケーションは基礎となる要素へより深くアクセスできるようになります。 +しかしこのアプローチはセキュリティリスクももたらすため、eBPFが魅力的な代替となります。 + +## 解決すべき問題はなんですか + +一般的に、アプリケーションはユーザー空間で動作し、アプリケーションがカーネルから(例えばハードウェアへのアクセスなどの)権限を要求するときは、いわゆる「システムコール」を介して要求します。 +多くの場合、このアプローチはうまく働きますが、低水準なシステムに対するより柔軟なアクセスを開発者が必要とする場合があります。 +オブザーバビリティ、セキュリティやネットワーク機能はこういった場合の良い例です。 +この実現のため、Linuxカーネルモジュールを使ってカーネルのソースコードを修正することなくカーネルの基礎を拡張することができます。 +Linuxカーネルモジュールの使用には利点もありますが、セキュリティリスクももたらします。 +Linuxカーネルモジュールはカーネル空間の内部で動作するため、カーネルをクラッシュさせる可能性があり、カーネルがクラッシュするということは機器全体もクラッシュすることになります。 +加えて、カーネルモジュールは特権を持ち、システムリソースに直接アクセスします。 +もし適切に保護されていない場合、攻撃者は攻撃のためカーネルモジュールを悪用できてしまいます。 + +## どのように役に立つのでしょうか + +eBPFはユーザー定義プログラムの実行環境として、Linuxカーネルモジュールよりも制御、制限された環境を提供します。 +eBPFプログラムはカーネル内のサンドボックス化された環境で動作することで、隔離を提供しリスクを低減します。 +もしeBPFプログラム中の脆弱性や欠陥が悪用されたとしても、一般的にその影響はサンドボックス化された環境に抑えられます。 +さらに、eBPFプログラムがカーネル内で動作を開始する前に、プログラムはいくつかの検証を通る必要があります。 +検証器は、範囲外メモリーアクセス、無限ループや承認されていないカーネル関数の使用といった潜在的な安全違反がないかeBPFプログラムを確認します。 +このようにして、プログラムが無限ループに入り、カーネルをクラッシュさせないことを確かにします。 +これらの安全制御によって、Linuxカーネル内でアプリケーションを動かすための選択肢としてeBPFはLinuxカーネルモジュールよりも安全なものになっています。 diff --git a/content/ja/edge-computing.md b/content/ja/edge-computing.md new file mode 100644 index 0000000000..0474496b28 --- /dev/null +++ b/content/ja/edge-computing.md @@ -0,0 +1,28 @@ +--- +title: エッジコンピューティング +status: Completed +category: テクノロジー +--- + +エッジコンピューティングは、ストレージと計算能力の一部を主要なデータセンターからデータソースに移行する[分散システム](/ja/distributed-systems/)のアプローチです。 +収集されたデータは、中央のデータセンターで処理や分析されるのではなく、ローカルに(例えば工場内や店内、あるいは街の全域にわたって)計算されます。 +これらのローカル処理ユニットやデバイスがシステムのエッジを表し、データセンターがその中心です。 +エッジで計算された出力は、さらなる処理のために主要なデータセンターに送信されます。 +エッジコンピューティングの例には、リストバンド型ガジェットや交通量を分析するためのコンピューターが含まれます。 + +## 解決すべき問題はなんですか + +この10年間で、私たちはエッジデバイス(例えば携帯電話、スマートウォッチ、センサー)の増加を目の当たりにしてきました。 +場合によっては、リアルタイムデータ処理は単なる便利な機能ではなく、非常に重要です。 +自動運転を行う車を考えてみてください。 +車のセンサーが取得したデータが、適切な反応をするために車両へ送り返される前に、データセンターで処理される必要があると考えてみてください。 +このネットワークの遅延は致命的になり得ます。 +これは極端な例ですが、ほとんどのユーザーはすぐにフィードバックを提供できないスマートデバイスを使いたいとは思わないでしょう。 + +## どのように役に立つのでしょうか + +上述した通り、エッジデバイスが有用であるためには、ユーザーにほぼリアルタイムのフィードバックを提供する必要があります。 +そのために少なくとも一部の処理と分析をローカルで行います。 +これはデータセンターからデータが生成される場所、つまりエッジデバイスに一部のストレージと処理リソースを移動させることで達成されます。 +処理済みおよび未処理のデータはその後、さらなる処理とストレージのためにデータセンターに送信されます。 +要するに、効率と速度がエッジコンピューティングの主要な推進力です。 diff --git a/content/ja/event-driven-architecture.md b/content/ja/event-driven-architecture.md new file mode 100644 index 0000000000..b09a86f164 --- /dev/null +++ b/content/ja/event-driven-architecture.md @@ -0,0 +1,24 @@ +--- +title: イベント駆動アーキテクチャ +status: Completed +category: コンセプト +tags: ["アーキテクチャ", "", ""] +--- + +イベント駆動アーキテクチャは、イベントの作成、処理、および消費を促進するソフトウェアアーキテクチャです。 +イベントとは、アプリケーションの状態に対する任意の変更を指します。 +例えば、ライドシェアリングアプリで乗車を依頼することは、イベントを代表しています。 +このアーキテクチャは、イベントがそのソース(乗車を要求するアプリ)から望ましいレシーバー(近くの利用可能なドライバーのアプリ)へ適切にルーティングされる構造を作り出します。 + +## 解決すべき問題はなんですか + +より多くのデータがリアルタイムになるにつれて、イベントがキャプチャされ、イベントリクエストを処理する必要がある適切な[サービス](/ja/service/)へ正確にルーティングされる信頼性の高い方法を見つけることがますます困難になります。 +イベントを処理する従来の方法は、メッセージが適切にルーティングされたか、あるいは実際に送信または受信されたかを保証する方法がないことがしばしばあります。 +アプリケーションがスケールするにつれて、イベントをオーケストレーションすることがより困難になります。 + +## どのように役に立つのでしょうか + +イベント駆動アーキテクチャは、すべてのイベントのためのセントラルハブ(例えばKafka)を確立します。 +次に、イベントプロデューサー(ソース)とコンシューマー(レシーバー)を定義し、セントラルハブがイベントの流れを保証します。 +このアーキテクチャは、サービス同士が疎結合のまま、イベントがプロデューサーからコンシューマーに適切にルーティングされることを保証します。 +プロデューサーは、通常はHTTPプロトコルによって受信イベントを取り、イベント情報をルーティングします。 diff --git a/content/ja/event-streaming.md b/content/ja/event-streaming.md new file mode 100644 index 0000000000..32fb7334ee --- /dev/null +++ b/content/ja/event-streaming.md @@ -0,0 +1,30 @@ +--- +title: イベントストリーミング +status: Completed +category: コンセプト +tags: ["方法論", "ネットワーキング", ""] +--- + +イベントストリーミングは、ソフトウェアが一つのアプリケーションから別のアプリケーションにイベントデータを送信し、何をしているかを継続的に通信するアプローチです。 +あるサービスが行うすべてのことを他のすべてのサービスにブロードキャストする様子を想像してください。 +サービスによって行われる各活動はイベントと呼ばれ、これがイベントストリーミングの由来です。 +たとえば、NASDAQは毎秒、株価と商品価格の更新を受け取ります。 +特定の株式セットを監視するアプリケーションを動かすとしたら、その情報をほぼリアルタイムで受け取りたいでしょう。 +Yahoo! Financeは、NASDAQから引っ張ってきたデータを引用し、その情報(またはイベント)を購読するアプリケーションに送信(またはストリーム)する[API](/ja/application-programming-interface/)を提供しています。 +送信されるデータおよびそのデータ(株価)の変化がイベントであり、それらをアプリケーションに配信するプロセスがイベントストリーミングです。 + +## 解決すべき問題はなんですか + +従来、Yahoo! Financeは単一のTCPリクエストを使用していました。 +これは、イベントごとに接続を確立する必要があるため、非常に非効率的です。 +データがよりリアルタイム性を帯びるにつれて、そのような解決策をスケーリングすることは非効率的になります。 +接続を一度開いてイベントが流れるようにすることは、リアルタイム収集として理想的です。 +生成されるデータの量は指数関数的に増加しており、それに伴いデータの状態は絶えず変動しています。 +開発者とユーザーは、そのデータをほぼリアルタイムで見ることができる必要があります。 + +## どのように役に立つのでしょうか + +イベントストリーミングにより、データの変更をソースから受信者に通信できます。 +情報を要求するためにサービスが待つ代わりに、サービスはそのすべてのイベント(または活動)を継続的にストリームします。 +情報がどうなるかについては関心を持ちません。 +必要なことを行い、それをブロードキャストするだけで、他のどのサービスとも完全に独立しています。 diff --git a/content/ja/function-as-a-service.md b/content/ja/function-as-a-service.md new file mode 100644 index 0000000000..5d0445e655 --- /dev/null +++ b/content/ja/function-as-a-service.md @@ -0,0 +1,29 @@ +--- +title: Function as a Service (FaaS) +status: Completed +category: テクノロジー +tags: ["インフラストラクチャ", "", ""] +--- + +Function as a Service (FaaS)は、[サーバーレス](/ja/serverless/)、[クラウドコンピューティング](/ja/cloud-computing/)、[サービス](/ja/service/)の一種であり、イベントによってコードを実行することを可能にします。 +これは通常、[マイクロサービス](/ja/microservices-architecture/)アプリケーションの構築や立ち上げに関連する、複雑なインフラストラクチャのメンテナンスを必要としません。 +FaaSを使用すると、ユーザーは関数とデータのみを管理し、クラウドプロバイダーがアプリケーションを管理します。 +これにより、開発者はコードが実行されていないときにサービスの費用を支払うことなく、必要な機能を得ることができます。 + +## 解決すべき問題はなんですか + +従来のオンプレミスシナリオでは、企業は自社のデータセンターの管理や維持をします。 +企業はサーバー、ストレージ、ソフトウェア、その他の技術に投資し、ITスタッフや請負業者を雇ってすべての機器やライセンスの購入、管理、更新を行う必要があります。 +データセンターは、作業負荷が減少しリソースがアイドリング状態の時期があるにも関わらず、ピーク需要に対応できるように建設されなければなりません。 +逆にビジネスが急速に成長する場合、IT部門は追いつくのに苦労するかもしれません。 +標準的な[Infrastructure-as-a-Service (IaaS)](/ja/infrastructure-as-a-service/)クラウドコンピューティングモデルでは、ユーザーは事前に容量ユニットを購入します。 +つまりアプリを実行するために、サーバーコンポーネントを常時起動させ、それに対する支払いをパブリッククラウドプロバイダーに行います。 +需要が高まる時にサーバー容量を増やし、その容量が不要になった時に減らすのはユーザーの責任です。 +アプリが使用されていないときでも、そのアプリを実行するためのクラウドインフラは稼働しています。 + +## どのように役に立つのでしょうか + +FaaSはサーバーを管理することなく、イベントに応じてウェブアプリケーションを実行するための[抽象化](/ja/abstraction/)を開発者に提供します。 +例えば、ファイルのアップロードがそのファイルを様々な形式にトランスコードするカスタムコードのトリガーとなるかもしれません。 +FaaSのインフラストラクチャは、頻繁に使用するコードを自動的にスケールアップし、開発者は[スケーラビリティ](/ja/scalability/)のためのコード構築に時間やリソースを費やす必要がありません。 +課金は計算時間のみに基づいているため、機能が使用されていない時には企業は支払いをする必要がありません。 diff --git a/content/ja/horizontal-scaling.md b/content/ja/horizontal-scaling.md new file mode 100644 index 0000000000..8c028c0aba --- /dev/null +++ b/content/ja/horizontal-scaling.md @@ -0,0 +1,33 @@ +--- +title: 水平スケーリング +status: Completed +category: コンセプト +tags: ["インフラストラクチャ", "", ""] +--- + +水平スケーリングは、より多くのノードを追加することでシステムの処理能力を向上させる手法です。 +個別の[ノード](/ja/nodes/)により多くの計算リソースを追加する手法とは異なります(後者は[垂直スケーリング](/ja/vertical-scaling/)として知られています)。 +たとえば、RAM容量4GBのシステムを持っていて、そのRAMを16GBに増やしたい場合、水平スケーリングはRAM 16GBのシステムに切り替えるのではなく、RAM 4GBのマシン4台で対応します。 + +このアプローチは、新しいインスタンスまたは[ノード](/ja/nodes/)を追加することで、負荷をより効果的に分散し、アプリケーションのパフォーマンスを向上させます。 +簡単に言えば、個別のサーバーの処理能力を強化することではなく、個別のサーバーの負荷を減らすことを目指しています。 + +## 解決すべき問題はなんですか + +アプリケーションに対する需要がそのアプリケーションインスタンスの現在の処理能力を超えた場合、システムに処理能力を[スケール](/ja/scalability/)する(処理能力を向上させる)方法が必要になります。 + +システムにノードを追加する(水平スケーリング)か、既存のノードにより多くの計算リソースを追加する(垂直スケーリング)かのいずれかが可能です。 + +## どのように役に立つのでしょうか + +水平スケーリングにより、アプリケーションは基礎となるクラスターが提供する限界までスケールすることができます。 + +システムにより多くのインスタンスを追加することで、アプリケーションはより多くのリクエストを処理することができます。 + +例えば、1つのノードが1秒あたり1,000リクエストを処理できるとすると、ノードを1つ追加するごとに、システム全体で1秒あたり処理できる総リクエストが約1,000リクエスト増えることになります。 +これにより、アプリケーションは特定のノードの処理能力を強化することなく、より多くの処理を同時に行うことができます。 + +## 関連する用語はありますか + +* [垂直スケーリング](/ja/vertical-scaling/) +* [オートスケーリング](/ja/auto-scaling/) diff --git a/content/ja/idempotence.md b/content/ja/idempotence.md new file mode 100644 index 0000000000..6c93011170 --- /dev/null +++ b/content/ja/idempotence.md @@ -0,0 +1,9 @@ +--- +title: 冪等性 +status: Completed +category: プロパティ +tags: ["プロパティ", "", ""] +--- + +数学やコンピューターサイエンスにおいて、冪等性とは、何度実行しても常に同じ結果になる操作を指します。 +パラメーターが同じであれば、冪等な操作を複数回実行しても、追加の効果はありません。 diff --git a/content/ja/immutable-infrastructure.md b/content/ja/immutable-infrastructure.md new file mode 100644 index 0000000000..95d329c03b --- /dev/null +++ b/content/ja/immutable-infrastructure.md @@ -0,0 +1,18 @@ +--- +title: イミュータブルインフラストラクチャ +status: Completed +category: プロパティ +tags: ["インフラストラクチャ", "プロパティ", ""] +--- + +イミュータブルインフラストラクチャとは、一度デプロイされると変更することができないコンピューターインフラストラクチャ([仮想マシン](/ja/virtual-machine/)や[コンテナ](/ja/container/)、ネットワーク機器)を指します。 +これは許可されていない変更を自動的に上書きするプロセスや、最初から変更を許可しないシステムによって強制されます。 +コンテナはイミュータブルインフラストラクチャの良い例です。 +なぜならコンテナに永続的な変更を加えるには、新しいバージョンのコンテナを作成するか、イメージから既存のコンテナを再度作成するしかないからです。 + +許可されていない変更の防止や特定により、イミュータブルインフラストラクチャはセキュリティリスクの特定と軽減を容易にします。 +このようなシステムの運用ははるかに簡単になります。 +なぜなら、管理者がそれについての前提を立てやすくなるためです。 +結局のところ、誰も間違いを犯していないことや、伝え忘れた変更を行っていないことが分かっています。 +イミュータブルインフラストラクチャは[Infrastructure as Code](/ja/infrastructure-as-code/)と密接に関連しており、インフラストラクチャを作成するために必要なすべての自動化がバージョン管理(たとえばGit)されています。 +この不変性とバージョン管理の組み合わせにより、システムへのすべての許可された変更に対して、耐久性のある監査ログが存在します。 diff --git a/content/ja/infrastructure-as-a-service.md b/content/ja/infrastructure-as-a-service.md new file mode 100644 index 0000000000..390aaf3c33 --- /dev/null +++ b/content/ja/infrastructure-as-a-service.md @@ -0,0 +1,25 @@ +--- +title: Infrastructure as a Service (IaaS) +status: Completed +category: テクノロジー +tags: ["インフラストラクチャ", "", ""] +--- + +Infrastructure as a service (IaaS)は、[クラウドコンピューティング](/ja/cloud-computing/)のサービスモデルの一つであり、[物理的](/ja/bare-metal-machine/)または[仮想化](/ja/virtualization/)されたコンピューティングリソース、ストレージ、ネットワークリソースをオンデマンドで提供し、従量課金モデルに基づいて利用できます。 +クラウドプロバイダーはハードウェアとソフトウェアを所有、運用し、これらをパブリック、プライベート、またはハイブリッドクラウドの形態で消費者に提供します。 + +## 解決すべき問題はなんですか + +従来のオンプレミス環境では、組織はコンピューティングリソースの有効活用にしばしば苦労していました。 +データセンターは、1%の時間しか必要とされない、潜在的なピーク需要に対応するために構築されなければなりません。 +需要が低い時期には、これらのコンピューティングリソースはアイドル状態になります。 +また、予想を超えるワークロードが発生した場合、処理するためのコンピューティングリソースが不足します。 +このようなスケーラビリティの欠如は、コストの増加とリソースの非効率的な使用につながります。 + +## どのように役に立つのでしょうか + +IaaSを利用することで、組織はアプリケーション用のコンピューティングリソースやデータセンターのスペースを購入し、維持する必要がなくなります。 +オンデマンドインフラを使用することで、必要に応じてコンピューティングリソースをレンタルし、[CAPEX](https://ja.wikipedia.org/wiki/資本的支出)と呼ばれる大規模な資本支出を延期しながら、スケールアップあるいはスケールダウンする柔軟性を得ることができます。 + +IaaSは、新しいアプリケーションを実験したり試したりする際の初期コストを削減し、インフラストラクチャを迅速に展開する施設を提供します。 +クラウドプロバイダーは、開発者が実験し革新するために役立つ、開発あるいはテスト環境にとって優れた選択肢です。 diff --git a/content/ja/infrastructure-as-code.md b/content/ja/infrastructure-as-code.md new file mode 100644 index 0000000000..29e9df4f2d --- /dev/null +++ b/content/ja/infrastructure-as-code.md @@ -0,0 +1,22 @@ +--- +title: Infrastructure as Code (IaC) +status: Completed +category: コンセプト +tags: ["インフラストラクチャ", "方法論", ""] +--- + +Infrastructure as Codeは、インフラストラクチャの定義を一つあるいは複数のファイルで保存する実践を指します。 +これは、通常はシェルスクリプトや他の設定ツールを用いたInfrastructure as a Serviceを手動でプロビジョニングする従来のモデルに代わるものです。 + +## 解決すべき問題はなんですか + +クラウドネイティブな方法でアプリケーションを構築するには、インフラストラクチャを使い捨てできるようにし、かつ再現可能にする必要があります。 +また自動化された繰り返し可能な方法で、人の手が介入することなくオンデマンドに[スケール](/ja/scalability/)する必要があります。 +手動でのプロビジョニングは、[クラウドネイティブアプリケーション](/ja/cloud-native-apps/)の応答性とスケーラビリティを満たすことができません。 +手動でのインフラストラクチャの変更は再現不可能で、すぐにスケールの限界に達し、設定ミスのエラーを引き起こします。 + +## どのように役に立つのでしょうか + +サーバー、ロードバランサー、サブネットのようなデータセンターのリソースをコードとして表現することで、インフラチームはすべての設定について単一の正しい情報源を持つことができます。 +また、[CI](/ja/continuous-integration/)/[CD](/ja/continuous-delivery/)パイプラインでデータセンターを管理することができます。 +これにより、バージョン管理とデプロイメント戦略を実装することができます。 diff --git a/content/ja/ingress.md b/content/ja/ingress.md new file mode 100644 index 0000000000..f2e5e2582b --- /dev/null +++ b/content/ja/ingress.md @@ -0,0 +1,31 @@ +--- +title: Ingress +status: Completed +category: テクノロジー +tags: ["基礎"] +--- + +Ingressは、クラスター内で動作するコンテナあるいはコンテナ群への外部からのインターネットトラフィックを管理するためのルールセットです。 +これにはIngressリソースとIngressコントローラーという二つの要素があります。 +Ingressリソースは、他のマニフェストファイルと共に存在する設定ファイルで、管理者が外部からのトラフィックのルーティングを設定することを可能にします。 +Ingressコントローラーは、実際にIngressリソースの設定に従ってトラフィックをルーティングするウェブサーバー技術です。 + +## 解決すべき問題は何ですか + +クラウドネイティブのウェブアプリケーションは複数のサービスで構成されており、しばしば、それらの[サービス](/ja/service/)は、ブラウザを使用してユーザーがインターネット経由でアクセスする必要があります。 +これらのサービスをユーザーがアクセスできるようにしながら、このアプリケーションを実行するために[Kubernetes](/ja/kubernetes/)を使用する場合、各アプリケーションサービスを全世界に向けて公開する必要があります。 +最も簡単な方法は、KubernetesのLoad Balancer Serviceを使用することです。 +しかし、このようなサービスを作成すると、基盤となるインフラストラクチャ上に新たなコンポーネントが生まれます。 +これは新しいコストと管理のオーバーヘッドを導入するだけでなく、新しく作成された各ロードバランサーには独自の外部IPアドレスがあります。 +これは悪いユーザーエクスペリエンスにつながります。 +なぜならユーザーは、アプリケーションにアクセスするために異なるURLをブラウズしたくないからです。 + +## どのように役に立つのでしょうか + +Ingressリソースを使用すると、アプリケーションのサービスへのトラフィックのバランスとルーティング方法を設定できます。 +Ingressコントローラーは、URLを通じて単一のエントリポイント(例: www.example-url.com)を公開し、異なるURLパス(例: www.example-url.com/path)に基づいて実際のルーティングとバランシングを行います。 +Ingressコントローラーは、クラスター内で動作するコンポーネントであり、Ingressリソースで定義されたルールを解釈します。 +ウェブアプリが動作するクラスターの運用者が、Nginx、Traefik、HAProxyなどの使用可能な技術セットから特定のIngressコントローラーを選択することができます。 +それにより、アプリケーションが複数のサービスで構成されている場合、ユーザーは単一のURLを使用してアクセスできます。 +これは、インフラストラクチャレベルで数多くの個別のロードバランサーが不要になり、各サービスのファイアウォールとロードバランサーのルールの設定が容易になります。 +トラフィックのルーティングと設定の取り扱いを一元化することで、Ingressはスケーラビリティの効率化を提供し、リソース利用を最適化し、コストを削減し、クラスター内で実行されるアプリケーションの全体的な管理のしやすさを向上させます。 diff --git a/content/ja/kubernetes.md b/content/ja/kubernetes.md new file mode 100644 index 0000000000..5d86d43844 --- /dev/null +++ b/content/ja/kubernetes.md @@ -0,0 +1,35 @@ +--- +title: Kubernetes +status: Completed +category: テクノロジー +tags: ["インフラストラクチャ", "基礎", ""] +--- + +Kubernetesは、しばしばK8sと略される、オープンソースのコンテナオーケストレーターです。 +Kubernetesは、モダンなインフラストラクチャ上でコンテナ化されたアプリケーションのライフサイクルを自動化し、[分散システム](/ja/distributed-systems/)全体でアプリケーションを管理するデータセンターのオペレーティングシステムとして機能します。 + +Kubernetesは、[クラスター](/ja/cluster/)内の[ノード](/ja/nodes/)にまたがって[コンテナ](/ja/container/)をスケジュールし、ロードバランサーや永続ストレージなど、いくつかのインフラストラクチャリソースを束ねてコンテナ化されたアプリケーションを実行します。 + +Kubernetesは自動化と拡張性を実現し、ユーザーが宣言的に(以下参照)かつ再現可能な方法でアプリケーションをデプロイできるようにします。 +Kubernetesは[API](/ja/application-programming-interface/)を介して拡張可能であり、経験豊富なKubernetesの専門家が自分たちのニーズに応じて拡張することができます。 + +## 解決すべき問題はなんですか + +インフラストラクチャの自動化と宣言的な設定の管理は長い間重要な概念でしたが、[クラウドコンピューティング](/ja/cloud-computing/)が人気になるにつれて、その重要性がさらに増していきました。 +計算機リソースへの需要が増加し、組織がより少ないエンジニアでより多くの運用機能を提供する必要が生じる中、その需要に応えるためには新しい技術や作業方法が求められています。 + +## どのように役に立つのでしょうか + +従来の[Infrastracture as Code](/ja/infrastructure-as-code/)ツールと同様にKubernetesは自動化を支援しますが、コンテナを用いて動作するという利点があります。 +コンテナは[仮想マシン](/ja/virtual-machine/)や物理マシンよりも設定のずれに対する耐性があります。 + +さらにKubernetesは宣言的に動作します。 +つまり、オペレータがマシンに何かを行う方法を指示するのではなく、インフラストラクチャがどのようにあるべきかを記述します。 +これは通常、マニフェストファイル(例えばYAML)として記述されます。 +その後、Kubernetesが実行方法の詳細を管理します。 +これにより、KubernetesはInfrastracture as Codeと非常に互換性が高くなっています。 + +またKubernetesは[セルフヒーリング](/ja/self-healing/)を行います。 +セルフヒーリングによって、クラスターの実際の状態は、常にオペレータの望む状態と一致します。 +Kubernetesがマニフェストファイルで記述された内容と異なる点を検出した場合、Kubernetesコントローラーがそれを修正します。 +Kubernetesが使用するインフラストラクチャは絶えず変化しているかもしれませんが、Kubernetesは常に自動的に変化に適応し、望ましい状態と一致するように保証します。 diff --git a/content/ja/loosely-coupled-architecture.md b/content/ja/loosely-coupled-architecture.md new file mode 100644 index 0000000000..800e0c6c6d --- /dev/null +++ b/content/ja/loosely-coupled-architecture.md @@ -0,0 +1,14 @@ +--- +title: 疎結合アーキテクチャ +status: Completed +category: プロパティ +tags: ["基礎", "アーキテクチャ", "プロパティ"] +--- + +疎結合アーキテクチャは、アプリケーションの構成要素それぞれが互いに独立して構築されるようなアーキテクチャです(その逆は[密結合アーキテクチャ](/ja/tightly-coupled-architecture/)と呼ばれます)。 +[マイクロサービス](/ja/microservices-architecture/)とよく呼ばれる個々の構成要素は、その他多くのサービスから利用できるような方法で、特定の機能を果たすよう構築されます。 +疎結合アーキテクチャは密結合アーキテクチャより一般的に実装が遅くなりますが、特にアプリケーションがスケールする際に多くの利点があります。 + +アプリケーションが疎結合だと、チームは独立して機能開発、デプロイ、スケールすることが可能です。 +よって組織は個々の構成要素における開発サイクルを素早く反復することができます。 +アプリケーション開発はより速くなり、チームは能力に基づいて構成され、特定のアプリケーションに注力することができます。 diff --git a/content/ja/microservices-architecture.md b/content/ja/microservices-architecture.md new file mode 100644 index 0000000000..5d36331ab9 --- /dev/null +++ b/content/ja/microservices-architecture.md @@ -0,0 +1,34 @@ +--- +title: マイクロサービスアーキテクチャ +status: Completed +tags: ["インフラストラクチャ", "基礎", ""] +--- + +マイクロサービスアーキテクチャは、アプリケーションを個々の独立した(マイクロ)[サービス](/ja/service/)に分割するアーキテクチャ手法で、各サービスは特定の機能に焦点を当てています。 +これらのサービスは密接に連携して動作し、エンドユーザーには単一のエンティティとして見えます。 +例として、Netflix を考えてみます。そのインターフェイスは、ビデオへのアクセス、検索、プレビューが可能です。 +これらの機能は、ブラウザでの認証、検索、プレビューの実行など、それぞれ一つの機能を扱う小さなサービスによって実現されている可能性が高いです。 + +このアーキテクチャ手法により、[モノリシックアプリケーション](/ja/monolithic-apps/)(以下に詳細あり)のようにすべてが密接に結合している場合よりも、開発者は新機能を迅速に導入したり機能を更新したりすることができます。 + +## 解決すべき問題はなんですか + +アプリケーションは、さまざまなパーツで構成され、それぞれが特定の能力を担当します。 +特定の機能に対する需要は、アプリケーションの他のパーツに対する需要と連動して必ず増減するわけではありません。 +Netflix の例に戻りましょう。 +例えば、大規模なマーケティングキャンペーンの後で、Netflix の契約者数が急増したが、その日の早い時間帯におけるストリーミングは概ね安定しているとします。 +契約者数の急増は、平常時より多くのキャパシティを要求します。 +伝統的な手法(モノリシックアプローチ)の場合では、増加に対応するためにアプリ全体を[スケールアップ](/ja/scalability/)する必要がありました。 +これは非常に非効率的なリソースの使い方です。 + +また、モノリシックアーキテクチャは、開発者が設計の落とし穴に陥りやすくするものです。 +すべてのコードが一か所にあるため、そのコードが[密結合](/ja/tightly-coupled-architecture/)になりやすく、関心の分離の原則を適用することが難しくなります。 +さらに、多くの場合、モノリスはデプロイする前にコードベース全体を理解する必要性を生じさせます。 +マイクロサービスアーキテクチャは、こうした課題への対応策です。 + +## どのように役に立つのでしょうか + +機能を異なるマイクロサービスに分離することにより、それらを独立してデプロイ、アップデート、スケールすることが容易になります。 +また、意図せずアプリケーションの他のパーツに悪影響を与えることなく、大きなアプリケーションの一部に対して複数のチームが同時に作業することを可能にします。 +マイクロサービスアーキテクチャは多くの問題を解決しますが、デプロイして追跡する必要があるものが桁違いに増えるため、運用上のオーバーヘッドも発生させます。 +多くの[クラウドネイティブテクノロジー](/ja/cloud-native-tech/)は、マイクロサービスのデプロイと管理を容易にすることを目指しています。 diff --git a/content/ja/monolithic-apps.md b/content/ja/monolithic-apps.md new file mode 100644 index 0000000000..eed64ed8a0 --- /dev/null +++ b/content/ja/monolithic-apps.md @@ -0,0 +1,22 @@ +--- +title: モノリシックアプリケーション +status: Completed +category: コンセプト +tags: ["アーキテクチャ", "基礎"] +--- + +モノリシックアプリケーションは単独で配置できるプログラムにすべての機能を格納しており、アプリケーションを開発する時に最も簡単かつ手軽な出発点とされています。 +しかし、アプリケーションが複雑になると、モノリスのメンテナンスが難しくなることがあります。 +また、同じコードベースで作業する開発者が増えるため、変更が競合したり、開発者の間で直接コミュニケーションを取る必要性が高まります。 + +## 解決すべき問題はなんですか + +アプリケーションを[マイクロサービス](/ja/microservices-architecture/)に移行するとテスト、デプロイ、実行などの運用オーバーヘッドが増加します。 +そのため、製品ライフサイクルの初期段階には製品を複雑化させる物は先送り、製品が成功したと判断されるまでモノリシックアプリーケーションで設計することが有利な場合もあります。 + +## どのように役に立つのでしょうか + +適切に設計されたモノリスはアプリケーションを起動して実行する最も簡単な方法であるため、簡潔さを維持できます。 +モノリシックアプリーケーションがビジネス的に価値があると証明されれば、アプリケーションを分割し、マイクロサービス化させる事も可能です。 +価値が証明される前に技術的努力を費やし、マイクロサービス基盤でアプリケーションを開発することは早計である可能性があります。 +アプリケーションが価値を生まなければ、その努力も無駄になるためです。 diff --git a/content/ja/multitenancy.md b/content/ja/multitenancy.md new file mode 100644 index 0000000000..f65ced6090 --- /dev/null +++ b/content/ja/multitenancy.md @@ -0,0 +1,34 @@ +--- +title: マルチテナンシー +status: Completed +category: プロパティ +tags: ["アーキテクチャ", "プロパティ", ""] +--- + +マルチテナンシーとは、複数のテナントにサービスを提供する単一のソフトウェアインストールを指します。 +テナントとは、自身のデータセットでソフトウェアを利用するユーザー、アプリケーション、あるいはそれらのグループのことです。 +これらのテナントは(所有者による明示的な指示がある場合を除いて)データを共有せず、互いの存在を意識することもありません。 + +テナントは、1人の独立したユーザーで1つのログインIDを持つほど小さくなり得ます。 +例えば、個人の生産性を高めるソフトウェアを考えてみてください。 +あるいは、何千ものログインIDを持つ企業全体ほど大きくもなり得ます。 +これらは、それぞれが独自の権限を持ちつつも多方面で相互に関連しています。 +マルチテナントソフトウェアの例には、Google Mail、Google Docs、Microsoft Office 365、Salesforce CRM、Dropboxなどがあり、完全または部分的にマルチテナントソフトウェアとして分類されます。 + +## 解決すべき問題はなんですか + +マルチテナンシーがなければ、各テナントに専用のソフトウェアインストールが必要になります。 +これはリソース利用とメンテナンスの労力を増加させ、最終的にはソフトウェアコストを増加させます。 + +## どのように役に立つのでしょうか + +マルチテナントソフトウェアは、各テナントに分離された環境(作業データ、設定、認証情報リストなど)を提供し、同時に複数のテナントにサービスを提供します。 +テナントの観点から見れば、各々が専用のソフトウェアインストールを持っているように見えますが、実際にはすべてが1つを共有しています。 +これはソフトウェアをサーバー上で実行し、テナントがインターフェイスおよび/あるいは[API](/ja/application-programming-interface/)を通じてネットワーク経由で接続できるようにすることで実現されます([クライアントサーバーアーキテクチャ](/ja/client-server-architecture/)も参照)。 +マルチテナントソフトウェアを使用すると、テナントはお互いに影響を与えることなく定義された制御された方法でのみ、1つのインストールのリソースを共有することができます。 +ソフトウェア提供者側の結果としてのリソース節約は、テナントに渡されユーザーにとってのソフトウェアコストを大幅に削減することができます(改めてウェブベースのEメールやドキュメントエディターを考えてみてください)。 + +## 関連する用語はありますか + +マルチテナンシーはSaaSと同義ではありません。 +しかし、SaaSがマルチテナントであることは非常に一般的であり、その主要な利点の1つとしてマルチテナンシーを特徴づけることがあります。 diff --git a/content/ja/mutual-transport-layer-security.md b/content/ja/mutual-transport-layer-security.md new file mode 100644 index 0000000000..821f7bed45 --- /dev/null +++ b/content/ja/mutual-transport-layer-security.md @@ -0,0 +1,22 @@ +--- +title: 相互TLS認証(mTLS) +status: Completed +category: コンセプト +tags: ["セキュリティ", "ネットワーキング", ""] +--- + +相互TLS認証(mTLS)は、2つの[サービス](/ja/service/)間で送信されるメッセージを認証し、暗号化するために使用される技術です。 +相互TLS認証は、標準の[Transport Layer Security](/ja/transport-layer-security/) (TLS)プロトコルですが、一方の接続元だけを検証するのではなく、その両方が検証されます。 + +## 解決すべき問題はなんですか + +[マイクロサービス](/ja/microservices-architecture/)はネットワーク上で通信します。 +そして、あなたのWi-Fiネットワークのように、そのネットワーク上での通信はハッキングされる可能性があります。 +mTLSは、関係者以外が盗聴したり、正当なリクエストになりすましたりすることを防ぎます。 + +## どのように役に立つのでしょうか + +mTLSは、クライアントとサーバー間の双方向のトラフィックが安全で信頼できることを保証します。 +また、ネットワークやアプリケーションにログインするユーザーのための追加のセキュリティ層を提供します。 +これは例えばIoTデバイスのように、ログインプロセスを行わずに接続するクライアントデバイスからの接続も検証します。 +オンパス攻撃、スプーフィング攻撃、クレデンシャルスタッフィング、ブルートフォース攻撃などの攻撃は、mTLSによって防ぐことができます。 diff --git a/content/ja/nodes.md b/content/ja/nodes.md new file mode 100644 index 0000000000..0db4e3e783 --- /dev/null +++ b/content/ja/nodes.md @@ -0,0 +1,25 @@ +--- +title: ノード +status: Completed +category: コンセプト +tags: ["インフラストラクチャ", "基礎", ""] +--- + +ノードとは、他のコンピューター、つまり他のノードと協力して共通のタスクを達成するコンピューターのことです。 +例えばあなたのラップトップ、モデム、プリンターを考えてみてください。 +これらはすべてあなたのWi-Fiネットワークを介して接続されており、通信し協力しており、それぞれが一つのノードを表しています。 +[クラウドコンピューティング](/ja/cloud-computing/)において、ノードは物理的なコンピューターであったり、仮想コンピューター、つまり[VM](/ja/virtual-machine/)(バーチャルマシン)であったり、または[コンテナ](/ja/container/)であることもあります。 + +## 解決すべき問題はなんですか + +アプリケーションは1台のマシン上で動作させることができます(そして実際に多くのアプリケーションがそうしています)が、それにはいくつかのリスクが伴います。 +具体的には、基盤となるシステムの故障がアプリケーションの中断を引き起こすことです。 +これに対処するために、開発者たちは[分散アプリケーション](/ja/distributed-apps/)を作り始めました。 +これは、各プロセスがそれぞれのノード上で動作します。 +それゆえ、ノードはアプリやプロセスを実行し、共通の目標を達成するために協力するノードの[クラスター](/ja/cluster/)、またはグループの一部として機能します。 + +## どのように役に立つのでしょうか + +ノードはクラスタに割り当てることができる計算上の明確な違いがある単位(メモリ、CPU、ネットワーク)を提供します。 +[クラウドネイティブ](/ja/cloud-native-tech/)プラットフォームやアプリでは、ノードは作業を行うことができる単一のユニットを表します。 +理想的には個々のノードには区別がなく、特定のタイプのあるノードは、同じタイプの他のノードと区別がつかないものとされます。 diff --git a/content/ja/observability.md b/content/ja/observability.md new file mode 100644 index 0000000000..284191f6ad --- /dev/null +++ b/content/ja/observability.md @@ -0,0 +1,18 @@ +--- +title: オブザーバビリティ(可観測性) +status: Completed +category: コンセプト +tags: ["プロパティ", "", ""] +--- + +オブザーバビリティとは、システムが実用的な洞察をどの程度出力できるかを決める性質のことを指します。 +オブザーバビリティにより、ユーザーはシステム外部への出力を元にそのシステムの状態を理解し、(是正)措置を取ることが可能になります。 + +コンピューターシステムは、CPU時間・メモリ・ディスク容量といった低水準のシグナルや、APIの応答時間・エラー数・秒間トランザクション数などを含む高水準でビジネスに直結するシグナルを観測することで評価されます。 +可観測なシステムは、いわゆるオブザーバビリティツールと言われる専門のツールで**観測**(もしくは監視)されます。 +オブザーバビリティツールの一覧は[クラウドネイティブ ランドスケープのオブザーバビリティセクション](https://landscape.cncf.io/?group=projects-and-products&view-mode=card#observability-and-analysis--observability)で見られます。 + +可観測なシステムは、有意義かつ実用的なデータを運用者に提供し、運用者が(インシデントへのより素早い対応や開発者の生産性向上といった)好ましい結果を出すことを可能にします。 +システムのダウンタイムとともに、手間のかかる手作業での仕事も少なくなります。 + +結果として、システムの運用コストと開発コストは、そのシステムがどれだけ可観測なのかに大きく影響を受けるでしょう。 diff --git a/content/ja/pod.md b/content/ja/pod.md new file mode 100644 index 0000000000..cd59eb2447 --- /dev/null +++ b/content/ja/pod.md @@ -0,0 +1,28 @@ +--- +title: Pod +status: Completed +category: コンセプト +tags: ["インフラストラクチャ", "基礎", ""] +--- + +[Kubernetes](/ja/kubernetes/)環境の中では、Podは最も基本的なデプロイ可能ユニットとして機能します。 +これはコンテナ化されたアプリケーションをデプロイし、管理するための基本的な構成要素を表しています。 +各Podには単一のアプリケーションインスタンスが含まれ、一つ以上の[コンテナ](/ja/container/)を保持することができます。 +Kubernetesは、より大規模なDeploymentの一部としてPodを管理し、必要に応じてPodを[垂直スケーリング](/ja/vertical-scaling/)または[水平スケーリング](/ja/horizontal-scaling/)することができます。 + +## 解決すべき問題はなんですか + +コンテナは一般的に、特定のワークロードを実行し制御する独立した単位として機能しますが、コンテナが密接に相互作用し、適切に連携して制御される必要がある場合もあります。 + +これらの密接に関連するコンテナがそれぞれ個別に管理される場合、冗長な管理作業が発生します。 +たとえば、オペレーターは関連するコンテナの配置を繰り返し判断し、それらが一緒に保たれるようにしなければなりません。 +また、これらの関連するコンテナのライフサイクルは同期される必要がありますが、個別にしか管理できません。 + +## どのように役に立つのでしょうか + +Podは密接に関連するコンテナを単一のユニットにまとめることで、コンテナ操作を大幅に簡素化します。 +たとえば、補助的なコンテナは、追加機能を提供したり、グローバルな設定を行うために主コンテナと一緒に使用されることがよくあります。 +これには、基本設定を主コンテナに注入して適用するコンテナ、 _sidecar_ (コンテナ)であり、主コンテナのためのネットワークトラフィックルーティングを処理する([サービスメッシュ](/ja/service-mesh/)を参照)、あるいは各コンテナと連動してログを収集するコンテナなどが含まれます。 + +メモリとCPUの割り当ては、Podレベルで定義することも、コンテナごとに定義することもできます。 +Podレベルで定義すると、内部のコンテナがリソースを柔軟に共有できます。 diff --git a/content/ja/policy-as-code.md b/content/ja/policy-as-code.md new file mode 100644 index 0000000000..9a5155db20 --- /dev/null +++ b/content/ja/policy-as-code.md @@ -0,0 +1,23 @@ +--- +title: Policy as Code (PaC) +status: Completed +category: コンセプト +tags: ["方法論", "", ""] +--- + +Policy as Codeは、ポリシー定義を機械的に読み取り可能かつ処理可能な形式で、1つ以上のファイルに保存する方法です。 +これは、別々の文書に人間が読める形式でポリシーが文書化されていた従来の方式を置き換えます。 + +## 解決すべき問題はなんですか + +アプリケーションやインフラストラクチャの構築には、しばしば組織が定義した多数のポリシーにより制約が課されます。 +たとえば、シークレット情報をソースコードへの埋め込むことを禁止するセキュリティポリシーや、スーパーユーザー権限でコンテナの実行を禁止するポリシー、あるいは特定の地理的位置以外にデータを保存することを禁止するポリシーなどがあります。 +開発者やレビュアーにとって、アプリケーションやインフラストラクチャが文書化されたポリシーに従っているかを手動で確認することは非常に労力がかかり、エラーも発生しやすいです。 +手動のプロセスでは、クラウドネイティブアプリケーションの応答性やスケールの要件を満たせません。 + +## どのように役に立つのでしょうか + +コードを通じてポリシーを記述することは、再現性を持たせることができ、手動で行う場合と比べてエラーが減少します。 +Policy as Codeの他の利点は、コードがGitのようなバージョン管理システムで管理できることです。 +Gitは変更履歴を作成し、これはなにかが期待通りに機能しない際にとりわけ役に立ちます。 +これにより、誰が変更を行ったのかを確認し、以前のバージョンに戻すことが可能になります。 diff --git a/content/ja/portability.md b/content/ja/portability.md new file mode 100644 index 0000000000..4136bd9895 --- /dev/null +++ b/content/ja/portability.md @@ -0,0 +1,14 @@ +--- +title: ポータビリティ(可搬性) +status: Completed +category: プロパティ +tags: ["基礎", "プロパティ", ""] +--- + +ソフトウェアの特性であるポータビリティは、再利用性の一つの形態です。 +クラウドプロバイダー、オペレーティングシステムやベンダーなどの特定の運用環境へのロックインを避けるのに役立ちます。 + +伝統的に、ソフトウェアは特定の環境(例えばAWSやLinux)向けに構築されがちです。 +一方、ポータブルなソフトウェアは、大規模な作業を必要とせずに、異なる運用環境で機能します。 +アプリケーションがポータブルであるとは、新しい環境に適応させるために要求される労力が合理的な範囲内であることを指します。 +「ポートする」というフレーズは、ソフトウェアを修正しそれを異なるコンピューターシステム上で動作可能にすることを意味します。 diff --git a/content/ja/reliability.md b/content/ja/reliability.md new file mode 100644 index 0000000000..9c415eeee8 --- /dev/null +++ b/content/ja/reliability.md @@ -0,0 +1,11 @@ +--- +title: 信頼性 +status: Completed +category: プロパティ +tags: ["基礎", "プロパティ", ""] +--- + +クラウドネイティブの観点から見ると、信頼性とはシステムが障害にどれだけうまく対応するかを指します。 +インフラストラクチャが変化し、個々のコンポーネントが故障しても動作し続ける[分散システム](/ja/distributed-systems/)があれば、それは信頼性があります。 +一方で、容易に故障し、運用者が手動で介入して動作を維持する必要がある場合、それは信頼性がないです。 +[クラウドネイティブアプリケーション](/ja/cloud-native-apps/)の目標は、本質的に信頼性の高いシステムを構築することです。 diff --git a/content/ja/role-based-access-control.md b/content/ja/role-based-access-control.md new file mode 100644 index 0000000000..4c5131b023 --- /dev/null +++ b/content/ja/role-based-access-control.md @@ -0,0 +1,21 @@ +--- +title: ロールベースアクセス制御(RBAC) +status: Completed +category: コンセプト +tags: ["セキュリティ", "", ""] +--- + +ロールベースアクセス制御(RBAC)は、チームあるいはより大きな組織内での個々のロールに基づいてシステムやネットワーク、リソースへのアクセスを管理するセキュリティ方法です。 +RBACは、管理者に特定の職務を持つすべてのユーザーに必要なアクセスレベルを割り当て、事前に定義された一連の権限を持つ役割をそれらのユーザーに割り当てる権限を与えます。 +組織はRBACを利用して、従業員ごとの役割と責任に合わせた、さまざまなレベルのアクセスを提供します。 + +## 解決すべき問題はなんですか + +RBACは、特にアプリケーションとチームメンバーの数が増えるにつれて、チームメンバーやアプリケーションがアクセスできるリソース、および彼らが実行できる操作を制御するという課題に対処します。 +管理者は、各ユーザーがアクセスする必要があるリソースに対して正しい権限を持っていることを確認する必要がありますが、これは構造化されたアクセス制御メカニズムがなければ煩雑で間違いが生じやすい作業になります。 + +## どのように役に立つのでしょうか + +RBACは、ITチームにグループ内のすべてのユーザーの権限を同時に簡単に管理したり、役割を割り当てたり削除することで、個々のユーザーのアクセスレベルをすばやく調整する能力を提供します。 +これにより、機密データを保護し従業員が職務に必要な情報のみにアクセスし、行動できるようにします。 +結果として、RBACはアクセス管理やセキュリティを強化し、組織内の運用効率を向上させます。 diff --git a/content/ja/runtime.md b/content/ja/runtime.md new file mode 100644 index 0000000000..2c4bae31e8 --- /dev/null +++ b/content/ja/runtime.md @@ -0,0 +1,37 @@ +--- +title: ランタイム +status: Completed +category: コンセプト +tags: ["アプリケーション", "", ""] +--- + +一般的に、ランタイムはソフトウェアの一部を実行します。 +これは、プログラムのコマンドをオペレーティングシステムのアクションに変換する、下層レイヤーとなるオペレーティングシステムの[抽象化](/ja/abstraction/)です。 + +[クラウドネイティブ](/ja/cloud-native-apps/)の文脈では、_ランタイム_ は一般的にコンテナランタイムを指します。 +コンテナランタイムは、[Open Container Initiative](https://opencontainers.org/)の仕様を具体的に実装します。 +これは異なるコンテナオーケストレーション技術の間で一貫した取り扱いを保証するためです。 + +## 解決すべき問題はなんですか + +コンテナランタイムの抽象化がなければ、アプリケーションは各オペレーティングシステムのすべての技術を取り扱う必要があります。 +結果としてアプリの実行の複雑さが増します。 + +## どのように役に立つのでしょうか + +コンテナランタイムは、Kubernetesのようなコンテナオーケストレーターに必要なコンポーネントです。 +これらは主に3つのことを行う、コンテナライフサイクルを処理します。 +まずコンテナイメージがどのように指定され、ランタイムがそれらをどのように取得するかを定義します。 +次にこれらのイメージがどのように展開、レイヤー化、マウント、実行されるかを扱います。 +さらにランタイムは、これらのオペレーティングシステムレベルのアクションの面倒を見ることで、ハードウェアリソースを管理します。 +これにはリソースの割り当てと隔離が含まれます。 +時間が経つにつれて、さまざまなコンテナランタイム製品が進化し、OCIの仕様がコンテナランタイムの標準となりました。 + +この標準を導入することにより、エンドユーザーは任意のOCIに準拠したランタイムを、任意のOCIに準拠したコンテナオーケストレーター(例えばKubernetes)と組み合わせることができます。 + +## 関連する用語はありますか + +- [クラウドネイティブ](https://glossary.cncf.io/ja/cloud-native-apps/) +- [コンテナ化](https://glossary.cncf.io/ja/containerization/) +- [コンテナオーケストレーション](https://glossary.cncf.io/ja/container-orchestration/) +- [マイクロサービスアーキテクチャ](https://glossary.cncf.io/ja/microservices-architecture/) diff --git a/content/ja/scalability.md b/content/ja/scalability.md new file mode 100644 index 0000000000..af919c5aaf --- /dev/null +++ b/content/ja/scalability.md @@ -0,0 +1,21 @@ +--- +title: スケーラビリティ +status: Completed +category: コンセプト +tags: ["基礎","プロパティ" , ""] +--- + +スケーラビリティは、システムがどれだけ拡張できるのかを示す特性を指します。 + +この特性により、システムが行うべき任意の処理に対して、その処理能力を増強することが可能となります。 + +例として、[Kubernetes](/ja/kubernetes/)[クラスタ](/ja/cluster/)は、[コンテナ化](/ja/containerization/)されたアプリの数を増減することでスケールしますが、そのスケーラビリティはいくつかの要素に依存します。 +[ノード](/ja/nodes/)の数、各ノードが処理できる[コンテナ](/ja/container/)の数、コントロールプレーンがサポート可能なレコードとオペレーションの規模と関係しています。 + +スケーラブルなシステムは、キャパシティの追加を容易に行えます。 + +私たちはスケーリングアプローチを2種類に分類します。 +[水平スケーリング](/ja/horizontal-scaling/)では、増加した負荷を処理するためにより多くのノードを追加します。 +一方で、[垂直スケーリング](/ja/vertical-scaling/)では、個々のノードがより多くのトランザクションを実行するために性能向上します(例えば、個別のマシンにより多くのメモリやCPUを追加すること)。 + +スケーラブルなシステムは、容易に変更することができ、ユーザーのニーズに応えることができます。 diff --git a/content/ja/search.md b/content/ja/search.md new file mode 100644 index 0000000000..d9a4d5beef --- /dev/null +++ b/content/ja/search.md @@ -0,0 +1,4 @@ +--- +title: Search Results +layout: search +--- \ No newline at end of file diff --git a/content/ja/security-chaos-engineering.md b/content/ja/security-chaos-engineering.md new file mode 100644 index 0000000000..06b2f4edbc --- /dev/null +++ b/content/ja/security-chaos-engineering.md @@ -0,0 +1,26 @@ +--- +title: セキュリティカオスエンジニアリング +status: Completed +category: コンセプト +tags: ["セキュリティ", "方法論", ""] +--- + +セキュリティカオスエンジニアリング(SCE)は、[カオスエンジニアリング](/ja/chaos-engineering/)に基づく規律です。 +SCEは、分散システムに対して積極的なセキュリティ実験を行い、乱雑や悪意のある条件に耐えるシステムの能力に信頼を築くために行われます。 +セキュリティカオスエンジニアは、定常状態、仮説、継続的検証、学習した教訓、および緩和の実施を含む科学的方法のループを使用してこれを達成します。 + +## 解決すべき問題はなんですか + +[サイト信頼性エンジニア](/ja/site-reliability-engineering/)(SRE)とサイバーセキュリティエンジニアの主な優先事項は、できるだけ早くサービスを復旧させ、ゼロダウンタイムを目指してビジネスへの影響を最小限に抑えることです。 +SREおよびサイバーセキュリティエンジニアは、障害発生前および障害発生後のインシデント状況の両方に対処します。 +ほとんどのセキュリティ問題は、迅速に発見および修正が難しく、アプリケーションやシステムの機能に影響を与えます。 +さらに、セキュリティインシデントは、開発フェーズ中に発見するのが通常難しいものです。 + +## どのように役に立つのでしょうか + +セキュリティカオスエンジニアリングは、[オブザーバビリティ](/ja/observability/)とサイバーレジリエンスの実践を中心に構築されています。 +これは「未知の未知」を明らかにし、システムに自信を持ち、サイバーレジリエンスを向上させ、オブザーバビリティを改善することを目指しています。 + +エンジニアリングチームは、複雑なインフラストラクチャ、プラットフォーム、および分散システム内のセキュリティ問題に関する理解を徐々に向上させます。 +SCEは、製品全体のサイバーレジリエンスを改善し、隠されたセキュリティ問題を明らかにし、典型的な盲点を露呈し、チームを重要なエッジケースに備えさせます。 +このアプローチは、SRE、[DevOps](/ja/devops/)、および[DevSecOps](/ja/devsecops/)エンジニアが、システムに自信を持ち、サイバーレジリエンスを向上させ、オブザーバビリティを改善するのに役立ちます。 diff --git a/content/ja/self-healing.md b/content/ja/self-healing.md new file mode 100644 index 0000000000..33caf6a44e --- /dev/null +++ b/content/ja/self-healing.md @@ -0,0 +1,10 @@ +--- +title: 自己修復 +status: Completed +category: プロパティ +tags: ["インフラストラクチャ", "プロパティ"] +--- + +自己修復システムは、人の手の介入なしに特定のタイプの障害から回復することができます。 +このシステムには「収束」あるいは「制御」するループがあり、システムの実際の状態を積極的に確認して、運用者が初めに望んだ状態と比較します。 +もし違いがある(例えば、望まれているよりも実行中のアプリケーションのインスタンスが少ない)場合、修正するための行動を行います(例えば、新しいインスタンスを起動します)。 diff --git a/content/ja/serverless.md b/content/ja/serverless.md new file mode 100644 index 0000000000..8f708a7309 --- /dev/null +++ b/content/ja/serverless.md @@ -0,0 +1,30 @@ +--- +Title: サーバーレス +Status: Completed +Category: テクノロジー +tags: ["アーキテクチャ", "", ""] +--- + +サーバーレスは、開発者がサーバーの管理を気にすることなくアプリケーションの構築と実行を可能にするクラウドネイティブの開発モデルです。 +サーバーレスパラダイム内にサーバーは存在しますが、アプリケーション開発プロセスから[抽象化](/ja/abstraction/)されています。 +クラウドプロバイダーがサーバーインフラのプロビジョニング、維持、および[スケーリング](/ja/scalability/)の日常的な作業を処理します。 +開発者は、デプロイのためにコードを[コンテナ](/ja/container/)に便利にパッケージできます。 +一度デプロイされると、サーバーレスアプリは需要に応じて自動的にスケールアップおよびダウンします。 +パブリッククラウドプロバイダーからのサーバーレスの提供は通常、イベント駆動型の実行モデルによってオンデマンドで課金されます。 +その結果、サーバーレス機能がアイドル状態にあるとき、関連するコストは発生しません。 + +## 解決すべき問題はなんですか + +標準的な[Infrastructure as a Service (IaaS)](/ja/infrastructure-as-a-service/)の[クラウドコンピューティング](/ja/cloud-computing/)モデルでは、 +ユーザーはキャパシティの単位を事前に購入します。 +つまり、アプリを実行するために常時稼働するサーバーコンポーネントの料金をパブリッククラウドプロバイダーに支払うことになります。 +高需要時にサーバーのキャパシティをスケールアップしたり、キャパシティが必要なくなったときにスケールダウンしたりするのは、ユーザーの責任です。 +アプリケーションが使用されていないときであっても、アプリケーションを運用するために必要なクラウドインフラストラクチャーはアクティブなままです。 + +## どのように役に立つのでしょうか + +従来のアプローチとは対照的に、サーバーレスアーキテクチャは必要なときにのみアプリケーションを起動します。 +イベントがアプリコードの実行をトリガーすると、パブリッククラウドプロバイダーは、そのコードのためのリソースを動的に割り当てます。 +コードの実行が終了すると、ユーザーは支払いを停止します。 +コストと効率の利点に加えて、サーバーレスは開発者をアプリのスケーリングとサーバーのプロビジョニングに関連する日常的で単調なタスクから解放します。 +サーバーレスを使用すると、オペレーティングシステムとファイルシステムの管理、セキュリティパッチ、ロードバランシング、キャパシティ管理、スケーリング、ログ、監視などの日常的なタスクは、すべてクラウドサービスプロバイダーに委ねられます。 diff --git a/content/ja/service-discovery.md b/content/ja/service-discovery.md new file mode 100644 index 0000000000..9ba47c96e5 --- /dev/null +++ b/content/ja/service-discovery.md @@ -0,0 +1,21 @@ +--- +title: サービスディスカバリー +status: Completed +category: コンセプト +tags: ["ネットワーキング", "", ""] +--- + +サービスディスカバリーはサービスを構成する個々のインスタンスを見つけるプロセスです。 +サービスディスカバリーツールは、サービスを構成するさまざまなノードやエンドポイントを追跡します。 + +## 解決すべき問題はなんですか + +クラウドネイティブアーキテクチャは、動的かつ流動的で常に変化しています。 +[コンテナ化](/ja/containerization/)されたアプリケーションは、その寿命の中で複数回起動と停止をする可能性があります。 +起動や停止が起きるたびに新しいアドレスを持つことになり、それを見つけたい任意のアプリケーションは、新しい位置情報を提供するツールを必要とします。 + +## どのように役に立つのでしょうか + +サービスディスカバリーは、ネットワーク内のアプリケーションを追跡し、必要な時にお互いを見つけられるようにします。 +そして、個々のサービスを識別し見つけるための共通の場所を提供します。 +サービスディスカバリーエンジンはデータベースのようなツールで、どのようなサービスが存在し、それらをどのように配置するかについての情報を保存します。 diff --git a/content/ja/service-mesh.md b/content/ja/service-mesh.md new file mode 100644 index 0000000000..3bfb41fd4a --- /dev/null +++ b/content/ja/service-mesh.md @@ -0,0 +1,24 @@ +--- +title: サービスメッシュ +status: Completed +category: テクノロジー +tags: ["ネットワーキング", "", ""] +--- + +[マイクロサービス](/ja/microservices-architecture/)の世界では、アプリケーションは複数の小さな[サービス](/ja/service/)に分割され、それらがネットワークを介して通信します。 +あなたのWi-Fiネットワークのように、コンピューターネットワークは本質的には信頼性が低く、ハッキングされやすく、しばしば遅いものです。 +サービスメッシュは、サービス間のトラフィック(すなわち通信)を管理することによって、この新しい課題に対処します。 +サービスメッシュは、すべてのサービスにわたって[信頼性](/ja/reliability/)、[オブザーバビリティ](/ja/observability/)、およびセキュリティ機能を均一に追加します。 + +## 解決すべき問題はなんですか + +マイクロサービスアーキテクチャに移行したことで、エンジニアは数百、場合によっては数千ものサービスを扱うようになり、それらすべてが相互に通信を必要としています。 +つまり、ネットワーク上で大量のトラフィックが行き交っています。 +その上、個々のアプリケーションは、必須の要件をサポートするために通信を暗号化する必要があるかもしれません。 +あるいは運用チームに共通のメトリクスを提供する必要があるかもしれませんし、問題の診断に役立つ、トラフィックに関する詳細な洞察を提供する必要があるかもしれません。 +これらの機能が個々のアプリケーションに組み込まれている場合、それぞれがチーム間の摩擦を引き起こし、新機能の開発を遅らせる原因となります。 + +## どのように役に立つのでしょうか + +サービスメッシュは、コードの変更を必要とせずに、クラスタ全体のすべてのサービスに対して、信頼性、オブザーバビリティ、およびセキュリティ機能を均一に追加します。 +サービスメッシュが登場する前は、その機能をすべての個々のサービスに組み込む必要があり、バグや技術的負債の潜在的な原因となっていました。 diff --git a/content/ja/service-proxy.md b/content/ja/service-proxy.md new file mode 100644 index 0000000000..689a35f202 --- /dev/null +++ b/content/ja/service-proxy.md @@ -0,0 +1,27 @@ +--- +title: サービスプロキシ +status: Completed +category: テクノロジー +tags: ["ネットワーキング", "", ""] +--- + +サービスプロキシは、特定の[サービス](/ja/service/)への、あるいはそこからのトラフィックをインターセプトします。 +そして、それに対して何らかのロジックを適用した後、そのトラフィックを別のサービスに転送します。 +これは、ネットワークトラフィックに関する情報を収集したり、ルールを適用したりする仲介者として機能します。 + +## 解決すべき問題はなんですか + +サービス間のコミュニケーション(通称: ネットワークトラフィック)を追跡し、それを変換したりリダイレクトしたりするためには、データを収集する必要があります。 +従来、データ収集とネットワークトラフィック管理を行うコードは、各アプリケーション内に組み込まれていました。 + +## どのように役に立つのでしょうか + +サービスプロキシにより、この機能を外部化することができます。 +もはやアプリ内に組み込む必要はありません。 +代わりに、プラットフォームレイヤー(アプリが実行される場所)に組み込まれるようになりました。 + +サービス間のゲートキーパーとして、プロキシはどのような種類のコミュニケーションが行われているかについての洞察を提供します。 +その洞察に基づき、特定のリクエストをどこに送るかを決定したり、完全に拒否したりします。 + +プロキシは重要なデータを収集し、ルーティングを管理します(トラフィックをサービス間で均等に分散させたり、一部のサービスが故障した場合には再ルーティングしたり)。 +また、接続を暗号化し、コンテンツをキャッシュします(リソース消費を減らします)。 diff --git a/content/ja/service.md b/content/ja/service.md new file mode 100644 index 0000000000..268a7f4fc3 --- /dev/null +++ b/content/ja/service.md @@ -0,0 +1,12 @@ +--- +title: サービス +status: Completed +category: コンセプト +tags: ["アプリケーション", "基礎", ""] +--- + +ITの分野において、サービスという言葉には複数の意味があります。 +この定義では、より伝統的な意味でのサービス、つまりマイクロサービスとしてのサービスに焦点を当てます。 +サービスがマイクロサービスとどのように異なるのかは微妙であり、人によって異なる意見を持つかもしれません。 +高レベルの定義としては、これらを同じものとして扱います。 +[マイクロサービス](/ja/microservices-architecture/)の定義を参照してください。 diff --git a/content/ja/shift-left.md b/content/ja/shift-left.md new file mode 100644 index 0000000000..99dc2a3695 --- /dev/null +++ b/content/ja/shift-left.md @@ -0,0 +1,29 @@ +--- +title: シフトレフト +status: Completed +category: コンセプト +tags: ["方法論", "", ""] +--- + +シフトレフトの「レフト」はソフトウェア開発ライフサイクルのより初期のステージを指します。 +ライフサイクルをステージが左から右へと実行される線と考えます。 +シフトレフトは、テストやセキュリティなどの開発プラクティスをソフトウェア開発ライフサイクルの終盤ではなく、早い段階で実施することです。 + +もともとはテストプロセスを早い段階で行うことを指していましたが、現在ではセキュリティやデプロイなど、ソフトウェア開発や[DevOps](/ja/devops/)の他の側面にも適用されることがあります。 + +## 解決すべき問題はなんですか + +セキュリティ問題や、バグ、ソフトウェアの欠陥は開発サイクルの後期やデプロイ後に発見された場合、とりわけソフトウェアが既に本番環境へデプロイされていた場合、修正はより難しく高コストになる可能性があります。 + +## どのように役に立つのでしょうか + +ソフトウェア開発におけるシフトレフトの考え方を適用することで、チームは開発ライフサイクル全体を通してテストやセキュリティを実装することができます。 +テストとセキュリティに対する責任はソフトウェアエンジニアから品質保証、運用まで開発チーム全体にわたって共有さるものであるため、誰もがアプリケーションの安定性とセキュリティを担保する役割を果たします。 + +加えて、シフトレフトは継続的な改善を可能とし、ウォーターフォール開発よりも[アジャイル](/ja/agile-software-development/)開発により実践されます。 +チームは小さな改善を繰り返し行い、より早い段階で問題を特定することができます。 +このアプローチにより、エンジニアは設計とアーキテクチャフェーズにおいて、セキュリティと安全な開発プラクティスを適用することが可能になります。 +開発サイクル全体を通してテストを行うことは、ソフトウェアのリリース前に必要となるテスト時間を短縮します。 + +多数のソフトウェアツールやSaaSソリューションは、これらのプラクティスを左にシフトすることを支援します。 +ただし、シフトレフトはチーム内のプロセスの改善や文化の改革を通しても実践することができます。 diff --git a/content/ja/site-reliability-engineering.md b/content/ja/site-reliability-engineering.md new file mode 100644 index 0000000000..4ef5b48248 --- /dev/null +++ b/content/ja/site-reliability-engineering.md @@ -0,0 +1,24 @@ +--- +title: サイト信頼性エンジニアリング(SRE) +status: Completed +category: コンセプト +tags: ["方法論", "", ""] +--- + +サイト信頼性エンジニアリング(SRE: Site Reliability Engineering)は、オペレーションとソフトウェアエンジニアリングを組み合わせた分野です。 +後者では、特にインフラストラクチャとオペレーションの問題に応用されます。 +つまり製品機能を構築する代わりに、サイト信頼性エンジニアは、アプリケーションを実行するためのシステムを構築します。 +[DevOps](/ja/devops/)との類似点がありますが、DevOpsがコードを本番環境に導入することに焦点を当てているのに対し、SREは本番環境で実行中のコードが適切に機能することを保証します。 + +## 解決すべき問題はなんですか + +アプリケーションを[高い信頼性](/ja/reliability/)で実行するためには、パフォーマンスモニタリング、アラート、デバッグ、トラブルシューティングなど、複数の機能が必要です。 +これらがなければ、システムオペレーターは問題に対応するだけで、積極的にそれらを回避しようとすることはできません。 +— ダウンタイムは時間の問題となるだけです。 + +## どのように役に立つのでしょうか + +SREのアプローチは、基盤となるシステムを継続的に改善することで、ソフトウェア開発プロセスのコスト、時間、労力を最小限に抑えます。 +システムは、インフラストラクチャとアプリケーションコンポーネントを継続的に測定し監視します。 +何か問題が発生した場合、システムはサイト信頼性エンジニアにいつ、どこで、どのように修正するかを指摘します。 +このアプローチを用いて運用タスクを自動化することで、高度に[スケーラブル](/ja/scalability/)で信頼性の高いソフトウェアシステムを作成するのに役立ちます。 diff --git a/content/ja/stateful-apps.md b/content/ja/stateful-apps.md new file mode 100644 index 0000000000..85654945fc --- /dev/null +++ b/content/ja/stateful-apps.md @@ -0,0 +1,16 @@ +--- +title: ステートフルアプリケーション +status: Completed +category: プロパティ +tags: ["基礎", "アプリケーション", "プロパティ"] +--- + +ステートフル(および[ステートレス](/ja/stateless-apps/))アプリについて話すとき、ステートとは、アプリが設計通りに機能するために必要なあらゆるデータを指します。 +例えば、カートの情報を保存しているオンラインショップなどはステートフルアプリです。 + +今日、私たちが使用するほとんどのアプリケーションは少なくとも部分的にステートフルです。 +しかし、クラウドネイティブ環境では、ステートフルアプリは難しいです。 +これは、[クラウドネイティブアプリ](/ja/cloud-native-apps/)が非常に動的だからです。 +これらはスケーリング、再起動、別の場所への移動が可能ですが、それでもそのステートにアクセスできる必要があります。 + +そのため、ステートフルアプリには、データベースのようにどこからでもアクセス可能な何らかのストレージが必要です。 diff --git a/content/ja/stateless-apps.md b/content/ja/stateless-apps.md new file mode 100644 index 0000000000..fccdd09069 --- /dev/null +++ b/content/ja/stateless-apps.md @@ -0,0 +1,14 @@ +--- +title: ステートレスアプリケーション +status: Completed +category: プロパティ +tags: ["基礎", "アプリケーション", "プロパティ"] +--- + +ステートレスアプリケーションは、送信される各リクエストをそれが初めて送信されたかのように処理します。 +このアプリは以前の相互通信やユーザーセッションデータを覚えていません。 +以前の相互通信からのデータはステートと呼ばれ、そのデータがどこにも保存されていないため、これらのアプリはステートレスです。 +例を挙げると、検索エンジンを使用していて、その検索が中断された場合(例えばウィンドウを閉じた場合)その検索結果は失われます。 +最初からやり直す必要があります。 + +一方、以前の相互通信を考慮しながらリクエストを処理するアプリケーションは[ステートフルアプリケーション](/ja/stateful-apps/)と呼ばれます。 diff --git a/content/ja/style-guide/_index.md b/content/ja/style-guide/_index.md new file mode 100644 index 0000000000..bd6082bba1 --- /dev/null +++ b/content/ja/style-guide/_index.md @@ -0,0 +1,184 @@ +--- +title: スタイルガイド +toc_hide: true +status: Completed +menu: + main: + weight: 10 +--- + +このスタイルガイドは、用語集の読者、定義の構造、必要な詳細度、一貫したスタイルを維持する方法について理解するのに役立ちます。 + +クラウドネイティブ用語集は、CNCFリポジトリの[デフォルトスタイルガイド](https://github.com/cncf/foundation/blob/master/style-guide.md)に従っています。 +さらに、以下のルールにも従っています: + +1. 専門用語や流行語は避け、シンプルでわかりやすい言葉を使う。 +2. [口語を避ける](https://en.wikipedia.org/wiki/Colloquialism) +3. [書き言葉や具体的な言葉を使う](https://guidetogrammar.org/grammar/composition/abstract.htm) +4. [前置詞と冠詞の縮約を含めない](https://en.wikipedia.org/wiki/Contraction_(grammar)) +5. [受動態は慎重に使う](https://www.ef.com/ca/english-resources/english-grammar/passive-voice/) +6. [肯定形でのフレーズを目指す](https://examples.yourdictionary.com/positive-sentence-examples.html) +7. [引用符以外の感嘆符を使用しない](https://www.grammarly.com/blog/exclamation-mark/) +8. 誇張しないこと +9. 繰り返しを避ける +10. 簡潔であること + +## 読者 + +用語集は、技術者および技術者以外の読者を対象として書かれています。 +技術的な知識を前提とせず、定義が簡単な言葉で説明されていることを確認してください。詳しくは、以下の定義をご覧ください。 + +## 最小限の定義 + +私たちの目標は、クラウドネイティブの用語を誰でも本当に簡単に理解できるようにすることです。 +そのため、シンプルであることに重点を置いています。 +つまり、テクノロジーを使っている人なら誰でも共感できるような例を用いて、明確でシンプルな言葉を使うということです(詳しくは後述します)。また、少なくとも技術的な観点からは、最小限の定義を提供します。 +文脈や例を節約するつもりはありません。結局のところ、それらは読者がコンセプトを理解するのに役立ちますが、技術的な詳細が理解に必要でない場合は、それを省略します。 +目標は、物事を複雑にし過ぎないことです。読者が基本的なコンセプトを理解したら、他のリソースでより深く掘り下げることができるようにします。その部分はこの用語集の範囲外です。 + +## 定義のテンプレート + +各用語はマークダウンファイルに格納され、このテンプレートに従います: + +```md +--- +title: +status: +category: +--- + +技術やコンセプトの簡単な要約。 + +## 解決すべき問題はなんですか + +取り組んでいる問題について数行。 + +## どのように役に立つのでしょうか + +それがどのように問題を解決するのか数行。 +``` + +### タイトル + +**タイトル** ラベルは、常に定義レイアウトの先頭に位置し、その値はタイトルケースであるべきです。 + +```md +--- +title: Definition Template +``` + +### 状態 + +**状態** ラベルは、タイトルラベルの後に表示されます。状態ラベルは、定義が十分に吟味されているか、より多くの努力を必要とするかを示します。 + +有効な値は以下の通りです: + +- Completed(完了) +- Feedback Appreciated(フィードバックが必要です) +- Not Started(未着手) + +完了した定義に対して、いつでもissueを開くことができます。定義が流動的な場合、そのステータスは*Feedback Appreciated*に変更されます。 + +```md +--- +title: Definition Template +status: Feedback Appreciated +``` + +### タグ + +ステータスラベルの後に、**タグ** ラベルが続きます。 +タグが意味を持ち、結果としてユーザーの役に立つためには、タグを厳密な意味で使うことになります。 +多くのタグを付けると、その意味が薄れるだけです。 +他のクラウドネイティブの概念を理解するために必要な用語であることを示すfundamental(基礎)を除き、ほとんどの用語のタグは1つだけとなる可能性があります。 + +**注意**: 管理者の承認がない限り、新しいタグを導入しないでください。エントリにタグを追加する場合は、以下のリストにあるように正確に綴るようにしてください(単数形、タイプミスなし)。 + +現在のタグは以下の通りです: + +- application(アプリケーション) +- architecture(アーキテクチャ) +- fundamental(基礎) +- infrastructure(インフラストラクチャー) +- methodology(方法論) +- networking(ネットワーキング) +- property(プロパティ) +- security(セキュリティ) + +```md +--- +title: Definition Template +status: Feedback Appreciated +tags: ["tag 1"], ["tag 2"] +--- +``` + +### 定義 + +#### 2つの副題 + +**テクノロジー** と **コンセプト** のカテゴリの定義には、簡単な概要と2つの副題があります: + +- (簡単な概要) : 私たちが話していることについて、短く明確な概要を提供します。 +- **解決すべき問題はなんですか** : 問題に焦点を当て、解決策(それは次のセクションで出てきます)には触れないようにします。 + 実際、定義されている用語に言及するのは避けましょう。問題は、私たちがそのモノを必要とするようになった **きっかけ** に焦点を当てます。 +- **どのように役に立つのでしょうか** : さて、その用語に戻りましょう。その用語は、上記の問題にどのように対処するのでしょうか? + +なお、**プロパティ**は別項目を必要としません。定義で十分です。 + +レビューを容易にするために、**セマンティック改行**(1行に1文)を使ってください。 + +#### 品質を最優先する + +マージされると、あなたの投稿がその用語の公式なCNCF定義となります(他の誰かが改良するまで)。 +CNCFの高い基準を満たす用語の作成は、急ぐことはできません - 品質には時間と努力が必要です。 + +**よく調べてください**:その用語を知っていると自信があっても、正しく理解できているかどうか確認してください。 +私たちはしばしば、組織の中で用語を特定の方法で使用しますが、それは全体像を反映していないかもしれません。 +特に、その用語に100%精通しているわけではない場合、複数のリソースを使用して調査してください。 +特にベンダーが提供する場合、多くの定義が一方的なものである。 +用語集には、ベンダーニュートラルで、世界的に認められた定義が含まれていなければなりません。 + +**盗作はしないこと**:用語集には、他の真面目な出版物と同じルールが適用されます。 +引用して寄稿している場合を除き、他人の著作物をコピー&ペーストしてはいけません。 +定義の特定の部分が気に入った場合は、自分の言葉で言い換えてください。 + +**権威あるリソースを参照する**:可能であれば、プロジェクトのドキュメントなどの権威あるリソースにリンクしてください。 +ベンダーが開発したコンテンツへのリンクはできませんのでご注意ください。 + +#### シンプルであること + +用語集は、**複雑な概念を簡単な言葉で説明する**ことを目的としていますが、これは意外と難しい作業で、何度も改訂が必要になります。 +定義を作成する際には、常に読者を念頭に置いてください。 +業界用語や流行語の使用は避けてください。きっと、つい見返してしまい、自動修正が必要になるかもしれません。 + +適切な場合は、読者(特に非技術者)が、説明しているコンセプトが *いつ*、*なぜ* 関連しているのかをより理解しやすくするために、**実例** を使用します。 + +定義で使用する場合は、必ず **既存の用語集にリンクしてください** (最初の言及のみハイパーリンクする必要があります)。 + +**例**:[サービスメッシュの定義](/ja/service-mesh/)の概要セクションを見てみましょう。 +マイクロサービス、サービス、信頼性、観測可能性の定義とリンクしています。 +さらに、マイクロサービス環境におけるネットワークの課題(非技術者が共感できないもの)と無線LANの問題(ノートパソコンを使っている人なら理解できるもの)を比較した実例を用いています。可能な限り、そのつながりを作るようにしてください。 + +#### Google や Word のドキュメントから始める + +GoogleやWordのドキュメントから始めて、数日置いてから、もう一度見直してみることをお勧めします。 +そうすることで、よりシンプルでわかりやすい表現ができるフレーズや表現をキャッチすることができます。 +また、PRを提出する前に、必ずスペルチェックを行いましょう。 + +ある用語に取り組んでいるときに、他の人がPRを提出しないようにするには、issueを要求し(または作成し)、そのissueが自分に割り当てられるようにする必要があります。 +詳しくは、[貢献の仕方](/ja/contribute/) ドキュメントをご覧ください。 + +始める前に、詳細や難易度、例文が適切に感じるか公開されている用語集をいくつか読んでください。 + +## レビュープロセス:期待されること + +現在、私たちは3人のメンテナンス担当者だけが、余暇を利用してこの作業を行っていることにご注意ください。 +時には、すぐに用語の見直しができることもありますが、時間がかかることもあります。 +ご不明な点がございましたら、Slackの#glossaryチャンネルでお問い合わせください。 +(チャンネルがある場所と方法については、[貢献の仕方](/ja/contribute/) ドキュメントを参照してください)。 + +私たちの目標は、用語集が可能な限り最高のリソースとなるようにすることです。 +あなたがPRを提出すると、私たちは1つまたは複数の修正をお願いすることがあります。 +挫折しないでください、多くのPRでそうなっています。 +このようなやり取りと私たちの協力によって、あなたの投稿が、世界中の読者に読まれ、参照される、本当に役立つ定義になることを保証します。 diff --git a/content/ja/tightly-coupled-architecture.md b/content/ja/tightly-coupled-architecture.md new file mode 100644 index 0000000000..a25b35e2d3 --- /dev/null +++ b/content/ja/tightly-coupled-architecture.md @@ -0,0 +1,16 @@ +--- +title: 密結合アーキテクチャ +status: Completed +category: プロパティ +tags: ["基礎", "アーキテクチャ", "プロパティ"] +--- + +密結合アーキテクチャは、アプリケーション構成要素の多くが互いに依存しているようなアーキテクチャを指します +(その逆は[疎結合アーキテクチャ](/ja/loosely-coupled-architecture/)と呼ばれます)。 +密結合であることは、ある構成要素に対する変更がその他の構成要素に影響を与えうることを意味します。 +一般的に、密結合アーキテクチャはより疎結合なアーキテクチャと比較して簡単に実装できますが、カスケード障害と呼ばれる連鎖的な障害に対してシステムがより弱くなる可能性があります。 +また、しばしば構成要素を協調してロールアウトする必要が生じるため、開発者の生産性に対する足かせとなる可能性があります。 + +密結合なアプリケーションアーキテクチャはかなり古典的なアプリケーション構築方法です。 +[マイクロサービス](/ja/microservices-architecture/)開発のベストプラクティス全てには必ずしも整合しませんが、密結合アーキテクチャは特定の場合に有用です。 +密結合アーキテクチャでの開発は、実装がより簡潔で早くなる傾向があり、[モノリシックアプリケーション](/ja/monolithic-apps/)とよく似て初期開発サイクルを加速させる可能性があります。 diff --git a/content/ja/transport-layer-security.md b/content/ja/transport-layer-security.md new file mode 100644 index 0000000000..ae86ea7dae --- /dev/null +++ b/content/ja/transport-layer-security.md @@ -0,0 +1,23 @@ +--- +title: Transport Layer Security (TLS) +status: Completed +category: コンセプト +tags: ["セキュリティ", "ネットワーキング", ""] +--- + +Transport Layer Security (TLS)は、ネットワーク上での通信のセキュリティを高めるために設計されたプロトコルです。 +インターネット上で送信されるデータの安全な配信を保証し、データの監視や改ざんを避けることができます。 +このプロトコルは、メッセージングや電子メールなどのアプリケーションで幅広く使用されています。 + +## 解決すべき問題はなんですか + +TLSがないと、日常的なブラウジング、電子メールでのやりとり、オンラインチャット、ビデオ会議などの機密情報が、転送中に他者によって簡単に追跡され変更される可能性があります。 +サーバーとクライアントアプリケーションがTLSをサポートすることで、それらの間で転送されるデータが暗号化され、第三者によって閲覧されないことが保証されます。 + +## どのように役に立つのでしょうか + +TLSは、ネットワーク上でデータを転送する際のセキュリティを提供するために、さまざまな符号化技術を組み合わせて使用します。 +TLSにより、例えばウェブブラウザと銀行サイトのように、クライアントアプリケーションとサーバーとの間の暗号化された接続が可能になります。 +また、クライアントアプリケーションが呼び出すサーバーを正確に識別できるようになるため、クライアントが不正なサイトと通信するリスクが減少します。 +これにより、TLSを使用してアプリケーション間で転送されるデータを第三者が閲覧し、監視することができなくなります。 +結果として、クレジットカード番号、パスワード、位置情報などの機密および個人情報が保護されます。 diff --git a/content/ja/vertical-scaling.md b/content/ja/vertical-scaling.md new file mode 100644 index 0000000000..ef02d070cc --- /dev/null +++ b/content/ja/vertical-scaling.md @@ -0,0 +1,28 @@ +--- +title: 垂直スケーリング +status: Completed +category: コンセプト +tags: ["インフラストラクチャ", "", ""] +--- + +垂直スケーリング(「スケールアップおよびスケールダウン」とも呼ばれる)は、個別の[ノード](/ja/nodes/)にCPUとメモリを追加することでシステムの処理能力を強化する方法です。 +例えば、4GB RAMのコンピューターを持っていて、その容量を16GB RAMに増やしたい場合、垂直スケーリングすることは、16GB RAMシステムに切り替えることを意味します。 +(別のスケーリングアプローチについては、[水平スケーリング](/ja/horizontal-scaling/)を参照してください。) + +## 解決すべき問題はなんですか + +アプリケーションへの需要が現在のアプリケーションインスタンスの処理能力を超えると、システムに処理能力を強化する方法が必要です。 +既存のノードにさらなる計算リソースを追加する(垂直スケーリング)か、システムにより多くのノードを追加する(水平スケーリング)ことができます。 +[スケーラビリティ](/ja/scalability/)は、競争力、効率、評判、品質に貢献します。 + +## どのように役に立つのでしょうか + +垂直スケーリングは、アプリケーションのコードを変更せずにサーバーの処理能力を変更することができます。 +一方で、水平スケーリングの場合、アプリケーションがスケールするために複製可能でなければなりません。 +コードの変更が必要になる可能性もあります。 +垂直スケーリングは、計算リソースを追加することで既存のアプリケーションの処理能力を強化し、アプリケーションがより多くのリクエストを処理し、より多くの作業を同時に行うことを可能にします。 + +## 関連する用語はありますか + +* [水平スケーリング](/ja/horizontal-scaling/) +* [オートスケーリング](/ja/auto-scaling/) diff --git a/content/ja/virtual-machine.md b/content/ja/virtual-machine.md new file mode 100644 index 0000000000..776ac92c76 --- /dev/null +++ b/content/ja/virtual-machine.md @@ -0,0 +1,24 @@ +--- +title: 仮想マシン +status: Completed +category: テクノロジー +tags: ["基礎", "インフラストラクチャ", ""] +--- + +仮想マシン(VM)とは、特定のハードウェアに縛られないコンピューターとそのオペレーティングシステムのことです。 +VMは、1台の物理コンピューターを複数の仮想コンピューターに分割する[仮想化](/ja/virtualization/)に依存しています。 +この分割は、組織やインフラプロバイダーに、下層のハードウェアに影響を与えることなく、VMを簡単に作成、破棄することを可能にします。 + +## 解決すべき問題はなんですか + +仮想マシンは仮想化を利用しています。[ベアメタル](/ja/bare-metal-machine/)マシンは単一のオペレーティングシステムに縛られているので、マシンのリソースをどれだけ使えるかはある程度制限されます。また、オペレーティングシステムも単一の物理マシンに縛られているので、その可用性はハードウェアに直結します。 +物理マシンがメンテナンスやハードウェア故障によりオフラインになると、オペレーティングシステムもオフラインになります。 + +## どのように役に立つのでしょうか + +オペレーティングシステムと物理マシンとの直接的な関係を取り除くことで、プロビジョニングの時間やハードウェア利用率、弾力性といったベアメタルマシンが抱えるいくつかの問題を解決することができます。 + +新しいハードウェアの購入やインストール、あるいはそれをサポートするための設定が必要ないため、新しいコンピューターのプロビジョニングの時間が劇的に短縮されます。 +VMは、1台の物理マシン上に複数の仮想マシンを配置することで、既存の物理ハードウェアリソースをより有効に活用できます。 +特定の物理マシンに縛られないため、VMは物理マシンよりも耐障害性に優れています。 +物理マシンがオフラインになる必要がある場合、その上で稼働しているVMを、ほとんどない、あるいは全く停止時間なしで別のマシンに移動させることができます。 diff --git a/content/ja/virtualization.md b/content/ja/virtualization.md new file mode 100644 index 0000000000..782838fa04 --- /dev/null +++ b/content/ja/virtualization.md @@ -0,0 +1,25 @@ +--- +title: 仮想化 +status: completed +category: テクノロジー +tags: ["基礎", "インフラストラクチャ", "方法論"] +--- + +クラウドネイティブコンピューティングにおける仮想化とは、 +サーバーとも呼ばれる物理コンピューターを確保し、その上で複数の隔離されたオペレーティングシステムを動かせるようにするプロセスを指します。 +そういった隔離されたオペレーティングシステムとそれらに割り当てられた計算資源(CPU、メモリ、ネットワーク)は、仮想マシンやVMと呼ばれます。 +[仮想マシン](/ja/virtual-machine/)はソフトウェア的に作り出されたコンピューターを意味します。 +仮想マシンは実際のコンピューターのように見えたり動作したりしますが、他の仮想マシンとハードウェアを共有しています。 +[クラウドコンピューティング](/ja/cloud-computing/)は主に仮想化技術の恩恵を受け提供されています。 +例えば、AWSで作成し使用できる「コンピューター」は実際のところはVMです。 + +## 解決すべき問題はなんですか + +仮想化によって、我々は多くの課題に対処することができます。 +例えば、仮想化によって同じ物理的なハードウェア上により多くのアプリケーションを互いに隔離しつつ動かすことができるので、セキュリティを保ったまま物理マシンの使用率を改善することができます。 + +## どのように役に立つのでしょうか + +仮想マシン上で動作しているアプリケーションは、お互いが物理的なコンピューターを共有していることを意識しません。 +また、データセンター利用者は仮想化によって新たなコンピューター(すなわちVM)を数分以内に起動できるようになります。 +その際に新しいコンピューターをデータセンターに追加する際の物理的な制約を気にする必要はありません。 diff --git a/content/ja/zero-trust-architecture.md b/content/ja/zero-trust-architecture.md new file mode 100644 index 0000000000..f8cc5db2d7 --- /dev/null +++ b/content/ja/zero-trust-architecture.md @@ -0,0 +1,24 @@ +--- +title: ゼロトラストアーキテクチャ +status: Completed +category: コンセプト +tags: ["セキュリティ", "", ""] +--- + +ゼロトラストアーキテクチャは、ITシステムの設計と実装において信頼を完全に取り除くアプローチを推奨します。 +その核心の原則は「決して信頼せず、常に検証する」であり、デバイスやシステムは、システムの他のコンポーネントと通信する際に常に事前に自分自身を検証します。 +今日の多くのネットワークは、企業ネットワークの信頼された境界内にあるため、システムやデバイスは互いに自由に通信することができます。 +ゼロトラストアーキテクチャは、ネットワークの境界内にあっても、システム内のコンポーネントは通信する前に検証しなければならないという正反対のアプローチを取ります。 + +## 解決すべき問題はなんですか + +伝統的な信頼ベースのアプローチでは、企業ネットワークの境界内に存在するシステムやデバイスに対して、信頼があるため問題がないという前提があります。 +しかし、ゼロトラストアーキテクチャは、その信頼が脆弱性になると認識しています。 +攻撃者が信頼されたデバイスへのアクセスを獲得した場合、そのデバイスに与えられている信頼のレベルとアクセスに依存してシステムは攻撃に対して脆弱になります。 +なぜなら、攻撃者は信頼されたネットワークの境界内におり、システム内を横断的に移動することができるからです。 +ゼロトラストアーキテクチャでは、信頼が取り除かれるため攻撃者はシステム内をさらに横断する前に検証を強いられ、結果としてアタックサーフェスが縮小します。 + +## どのように役に立つのでしょうか + +ゼロトラストアーキテクチャを採用することで、主な利点としてセキュリティが向上し、アタックサーフェスが縮小します。 +企業システムから信頼を取り除くことで、攻撃者がシステムの他の領域へアクセスするために通過しなければならないセキュリティゲートの数と強度が増加します。 diff --git a/content/ko/search.md b/content/ko/search.md new file mode 100644 index 0000000000..d9a4d5beef --- /dev/null +++ b/content/ko/search.md @@ -0,0 +1,4 @@ +--- +title: Search Results +layout: search +--- \ No newline at end of file diff --git a/content/pt-br/agile-software-development.md b/content/pt-br/agile-software-development.md index 20b2fba19c..5576bd1da4 100644 --- a/content/pt-br/agile-software-development.md +++ b/content/pt-br/agile-software-development.md @@ -5,8 +5,6 @@ category: conceito tags: ["metodologia", "", ""] --- -## O que é - Um conjunto de práticas que enfatizam ciclos de desenvolvimento iterativo e equipes auto-organizadas. Em contraste com projetos do tipo cascata, onde o valor é gerado apenas no final de um projeto, o desenvolvimento ágil de software se concentra em uma entrega incremental e contínua de valor e na melhoria evolutiva do próprio processo. ## Problema relacionado diff --git a/content/pt-br/api-gateway.md b/content/pt-br/api-gateway.md index 39461ee6ca..1025e0d52f 100644 --- a/content/pt-br/api-gateway.md +++ b/content/pt-br/api-gateway.md @@ -5,8 +5,6 @@ category: conceito tags: ["redes", "", ""] --- -## O que é - Um gateway de [API](/pt-br/application-programming-interface/) é uma ferramenta que agrega aplicações APIs exclusivas, tornando-as todas disponíveis em um só lugar. Ele permite que as organizações movam funções importantes, como autenticação e autorização ou limitação do número de solicitações entre aplicativos, para um local com gerenciamento centralizado. Um gateway de API funciona como uma interface comum para consumidores de API (geralmente externos). ## Problema relacionado diff --git a/content/pt-br/application-programming-interface.md b/content/pt-br/application-programming-interface.md index c931469757..23c368521a 100644 --- a/content/pt-br/application-programming-interface.md +++ b/content/pt-br/application-programming-interface.md @@ -5,8 +5,6 @@ category: tecnologia tags: ["arquitetura", "fundamento", ""] --- -## O que é - Uma API (interface de programação de aplicações - do inglês: applications protocol interface) é um modo como programas de computador interagem uns com os outros. Assim como humanos interagem com um site através de uma página web, uma API permite que programas de computador interajam uns com os outros. Ao contrário das interações humanas, as APIs possuem limitações sobre o que pode e o que não pode ser solicitado a elas. Essa interação limitada ajuda a criar uma comunicação estável e funcional entre programas. ## Problema relacionado diff --git a/content/pt-br/bare-metal-machine.md b/content/pt-br/bare-metal-machine.md index a5db620aae..5ec52bb3b7 100644 --- a/content/pt-br/bare-metal-machine.md +++ b/content/pt-br/bare-metal-machine.md @@ -5,8 +5,6 @@ category: tecnologia tags: ["infraestrutura", "", ""] --- -## O que é - Bare metal refere-se a um computador físico, mais especificamente um servidor, que tem um, e apenas um sistema operacional. A distinção é importante na computação moderna porque muitos, se não a maioria, servidores são [máquinas virtuais](/virtual-machine/). Um servidor físico geralmente é um computador com grande capacidade e com hardware embutido. Instalar um sistema operacional e executar aplicativos diretamente nesse hardware físico, sem [virtualização](/virtualization/), é conhecido como executar em “bare metal”. ## Problema relacionado diff --git a/content/pt-br/blue-green-deployment.md b/content/pt-br/blue-green-deployment.md index 92ab741946..972cb63888 100644 --- a/content/pt-br/blue-green-deployment.md +++ b/content/pt-br/blue-green-deployment.md @@ -5,8 +5,6 @@ category: conceito tags: ["metodologia", "aplicação", ""] --- -## O que é - O Blue-green deployment é uma estratégia para atualizar os sistemas de computador em execução com o mínimo de tempo de indisponibilidade. O operador mantém dois ambientes, chamados "blue" e "green". Um atende ao tráfego de produção (a versão que os usuários estão usando atualmente), enquanto o outro é atualizado. Depois que o teste é concluído no ambiente inativo (green), o tráfego de produção é redirecionado (geralmente com o uso de um baleanceador de carga - load balancer). Observe que blue-green deployment geralmente significa alternar os ambientes por completo, abrangendo muitos serviços, todos de uma vez. Confusamente, às vezes o termo é usado em relação a serviços individuais em um sistema. Para evitar essa ambiguidade, o termo "zero-downtime deployment" é preferido quando se refere a componentes individuais. diff --git a/content/pt-br/canary-deployment.md b/content/pt-br/canary-deployment.md index b8719cc0b9..d6e7326855 100644 --- a/content/pt-br/canary-deployment.md +++ b/content/pt-br/canary-deployment.md @@ -5,8 +5,6 @@ category: conceito tags: ["metodologia", "aplicação", ""] --- -## O que é - Implantação Canário é uma estratégia de implantação que começa com dois ambientes: um com tráfego e outro contendo o código atualizado sem tráfego. O tráfego é gradualmente movido da versão original do aplicativo para a versão atualizada. Pode começar movendo 1% do tráfego, depois 10%, 25% e assim por diante, até que tudo esteja passando pela versão atualizada. As organizações podem testar a nova versão do software em produção, obter feedback, diagnosticar erros e reverter rapidamente para a versão estável, se necessário. O termo "canário" refere-se à prática do "canário em uma mina de carvão", onde aves canárias foram levadas para minas de carvão para manter os mineiros seguros. Se gases nocivos inodoros estivessem presentes, o pássaro morreria e os mineiros sabiam que tinham que evacuar rapidamente. Da mesma forma, se algo der errado com o código atualizado, o tráfego será "evacuado" de volta à versão original. diff --git a/content/pt-br/chaos-engineering.md b/content/pt-br/chaos-engineering.md new file mode 100644 index 0000000000..fb40e38e04 --- /dev/null +++ b/content/pt-br/chaos-engineering.md @@ -0,0 +1,16 @@ +--- +title: Engenharia do Caos +status: Completed +category: conceito +tags: ["metodologia"] +--- + +A Engenharia do Caos, ou CE, é a disciplina de experimentar em um [sistema distribuído](/pt-br/distributed-systems/) em produção para construir confiança na capacidade do sistema de resistir a condições turbulentas e inesperadas. + +## Problema relacionado + +As práticas de [SRE](/pt-br/site-reliability-engineering/) e [DevOps](/pt-br/devops/)focam em técnicas para aumentar a resiliência e [confiabilidade](/pt-br/reliability/) do produto. A capacidade de um sistema de tolerar falhas enquanto garante qualidade de serviço adequada é tipicamente um requisito de desenvolvimento de software. Existem vários aspectos envolvidos que podem levar a falhas de um aplicativo, como infraestrutura, plataforma ou outras partes móveis de um aplicativo baseado em [microserviços](/pt-br/microservices/). A implantação frequente de novos recursos no ambiente de produção pode aumentar a probabilidade de tempo de inatividade e um incidente crítico — com consequências consideráveis para o negócio. + +## Como ajuda + +A engenharia do caos é uma técnica para atender aos requisitos de resiliência. É usada para alcançar resiliência contra falhas de infraestrutura, plataforma e aplicativo. Engenheiros de caos usam experimentos de caos para injetar proativamente falhas aleatórias e verificar se um aplicativo, infraestrutura ou plataforma pode se recuperar automaticamente e se a falha não pode afetar perceptivelmente os clientes. Os experimentos de caos visam descobrir pontos cegos (por exemplo, técnicas de monitoramento ou de escalonamento automático) e melhorar a comunicação entre equipes durante incidentes críticos. Essa abordagem ajuda a aumentar a resiliência e a confiança da equipe em sistemas complexos, especialmente em produção. diff --git a/content/pt-br/client-server-architecture.md b/content/pt-br/client-server-architecture.md index fb210b4c20..104fde0c35 100644 --- a/content/pt-br/client-server-architecture.md +++ b/content/pt-br/client-server-architecture.md @@ -5,8 +5,6 @@ category: conceito tags: ["arquitetura", "fundamento", ""] --- -## O que é - Em uma arquitetura cliente-servidor (client-server), a lógica (ou código) que compõe uma aplicação é dividida entre dois ou mais componentes: O Cliente, que solicita uma função a ser executada (por exemplo, o site do Gmail sendo executado no seu navegador) e um ou mais servidores que atendam essa requisição (por exemplo, o serviço "enviar-email" executado nos computadores do Google na nuvem). Neste exemplo, os e-mails que você escreve são enviandos pelo cliente (aplicação web sendo executada no seu navegador) para o servidor (computadores do Gmail, que encaminham seus e-mails para os destinatários). Isso contrasta com aplicativos independentes (como aplicativos de desktop) que fazem todo o trabalho em um só lugar. Por exemplo, um programa de processamento de texto como o Microsoft Word pode ser instalado e executado inteiramente em seu computador. diff --git a/content/pt-br/cloud-computing.md b/content/pt-br/cloud-computing.md index e35ef8d78a..d2f31411c9 100644 --- a/content/pt-br/cloud-computing.md +++ b/content/pt-br/cloud-computing.md @@ -5,7 +5,6 @@ category: conceito tags: ["infraestrutura", "fundamento", ""] --- -## O que é Computação em nuvem é um modelo que oferece recursos computacionais, como CPU, rede e disco, sob demanda através da internet. A computação em nuvem permite que usuários acessem e usem poder computacional a partir de um local físico remoto. Provedores de nuvem, como AWS, GCP, Azure, Digital Ocean e outros, oferecem a terceiros a capacidade de alugar acesso a recursos computacionais em múltiplas localizações geográficas. ## Problema relacionado diff --git a/content/pt-br/cloud-native-apps.md b/content/pt-br/cloud-native-apps.md index b736317ab8..c1c2223e7d 100644 --- a/content/pt-br/cloud-native-apps.md +++ b/content/pt-br/cloud-native-apps.md @@ -5,8 +5,6 @@ category: conceito tags: ["aplicação", "fundamento", ""] --- -## O que é - As aplicações nativas em nuvem são projetadas especificamente para aproveitar as inovações em [computação em nuvem](/pt-br/cloud-computing/). Essas aplicações se integram facilmente às suas respectivas arquiteturas de nuvem, aproveitando, assim, os recursos e o [dimensionamento](/scalability/) da nuvem. Também se refere a aplicativos que aproveitam as inovações da infraestrutura impulsionadas pela computação em nuvem. Hoje, as aplicações nativas em nuvem incluem aplicativos que são executados tanto em datacenter de um provedor de nuvem pública, quanto em plataformas de nuvens privadas. ## Problema relacionado diff --git a/content/pt-br/cloud-native-security.md b/content/pt-br/cloud-native-security.md index 80d1f180a8..7bef2fa710 100644 --- a/content/pt-br/cloud-native-security.md +++ b/content/pt-br/cloud-native-security.md @@ -5,8 +5,6 @@ category: conceito tags: ["segurança", "", ""] --- -## O que é - A segurança nativa da nuvem é uma abordagem que transforma a segurança em [aplicações nativas em nuvem](/pt-br/cloud-native-apps/). Isso garante que a segurança faça parte de todo o ciclo de vida do aplicativo, desde o desenvolvimento até a produção. A segurança nativa da nuvem busca garantir os mesmos padrões que os modelos de segurança tradicionais, enquanto se adapta aos detalhes dos ambientes nativos da nuvem, ou seja, mudanças rápidas de código e infraestrutura altamente efêmera. A segurança nativa da nuvem está altamente relacionada à prática chamada [DevSecOps](/devsecops/). ## Problema relacionado diff --git a/content/pt-br/cloud-native-tech.md b/content/pt-br/cloud-native-tech.md index 064edfa49d..71c1367b55 100644 --- a/content/pt-br/cloud-native-tech.md +++ b/content/pt-br/cloud-native-tech.md @@ -5,8 +5,6 @@ category: conceito tags: ["fundamento", "", ""] --- -## O que é - As tecnologias nativas da nuvem, também conhecidas como a *stack* nativa da nuvem, são as tecnologias usadas para criar [aplicativos nativos da nuvem](/pt-br/cloud-native-apps/). Essas tecnologias permitem que as organizações criem e executem aplicações escaláveis em ambientes modernos e dinâmicos, tais como as nuvens públicas, privadas e híbridas, ao mesmo tempo em que aproveitam ao máximo os benefícios da [computação em nuvem](/pt-br/cloud-computing/). Eles são projetados desde o início para explorar os recursos de computação em nuvem e contêineres, serviços em malha, microsserviços e infraestrutura imutável exemplificam essa abordagem. ## Problema relacionado diff --git a/content/pt-br/cluster.md b/content/pt-br/cluster.md index 37b67c8a40..e48d2c4b92 100644 --- a/content/pt-br/cluster.md +++ b/content/pt-br/cluster.md @@ -5,8 +5,6 @@ category: conceito tags: ["infraestrutura", "fundamento", ""] --- -## O que é - Um cluster é um grupo de máquinas ou aplicações que trabalham juntos para um objetivo comum. No contexto da computação nativa em nuvem, o termo é mais frequentemente aplicado ao Kubernetes. Um cluster Kubernetes é um conjunto de serviços (ou cargas de trabalho) executados em seus próprios contêineres, geralmente em máquinas diferentes. O conjunto de todos esses serviços [contêinerizados](/pt-br/containerization/), conectados em uma rede, representam um cluster. ## Problema relacionado diff --git a/content/pt-br/container.md b/content/pt-br/container.md index 0022db3387..3f85ebd715 100644 --- a/content/pt-br/container.md +++ b/content/pt-br/container.md @@ -5,8 +5,6 @@ category: tecnologia tags: ["aplicação", "fundamento", ""] --- -## O que é - Um contêiner é um processo em execução com restrições de recursos e capacidade gerenciadas pelo sistema operacional. Os arquivos disponíveis para o processo de contêiner são empacotados como uma imagem de contêiner. Os contêineres são executados um ao lado do outro na mesma máquina, mas normalmente o sistema operacional impede que os processos de contêiner separados interajam entre si. ## Problema relacionado diff --git a/content/pt-br/containerization.md b/content/pt-br/containerization.md index 3f67bf45bf..a24b1d7a43 100644 --- a/content/pt-br/containerization.md +++ b/content/pt-br/containerization.md @@ -5,8 +5,6 @@ category: tecnologia tags: ["aplicação", "", ""] --- -## O que é - A conteinerização é o processo de agrupar uma aplicação e suas dependências em uma imagem de contêiner. O processo de criação do contêiner requer adesão ao padrão [Open Container Initiative](https://opencontainers.org) (OCI). Desde que a saída seja uma imagem de contêiner que atenda a esse padrão, a ferramenta de conteinerização usada não importa. ## Problema relacionado diff --git a/content/pt-br/continuous-delivery.md b/content/pt-br/continuous-delivery.md index a0df9395f2..68641127d1 100644 --- a/content/pt-br/continuous-delivery.md +++ b/content/pt-br/continuous-delivery.md @@ -5,8 +5,6 @@ category: conceito tags: [metodologia", "aplicação", ""] --- -## O que é - A entrega contínua, muitas vezes conhecida como CD, é um conjunto de práticas nas quais as alterações de código são implantadas automaticamente em um ambiente de aceitação (ou, no caso de implantação contínua, na produção). A entrega contínua inclui procedimentos cruciais para garantir que o software seja testado adequadamente antes da implantação e fornecer uma maneira de reverter as alterações, se necessário. A integração contínua (CI) é o primeiro passo para a entrega contínua (ou seja, as alterações precisam se fundir de forma limpa antes de serem testadas e implantadas). ## Problema relacionado diff --git a/content/pt-br/continuous-deployment.md b/content/pt-br/continuous-deployment.md index cec0ebfb24..187666e6b5 100644 --- a/content/pt-br/continuous-deployment.md +++ b/content/pt-br/continuous-deployment.md @@ -5,8 +5,6 @@ category: conceito tags: ["aplicação", "metodologia", ""] --- -## O que é - Implantação contínua (continuous deployment - CD), vai um passo além da entrega contínua ao implantar o software finalizado diretamente na produção. A implantação contínua anda de mãos dadas com a [entrega contínua](/pt-br/continuous-delivery/) e é frequentemente referida como _CI/CD_. O processo de CI testa se as alterações feitas em um determinado aplicativo são válidas, e o processo de CD implanta automaticamente as mudanças de código através dos ambientes de uma organização, desde teste até a produção. ## Problema relacionado diff --git a/content/pt-br/continuous-integration.md b/content/pt-br/continuous-integration.md index 4b56ac2c8a..6e05490e63 100644 --- a/content/pt-br/continuous-integration.md +++ b/content/pt-br/continuous-integration.md @@ -5,8 +5,6 @@ category: conceito tags: ["aplicação", "metodologia", ""] --- -## O que é - A integração contínua (continuous integration - CI), é a prática de integrar mudanças de código da maneira mais regular possível. A integração contínua é um pré-requisito para a [entrega contínua](/pt-br/continuous-delivery/). Tradicionalmente, o processo de integração contínua começa quando as alterações do código são confirmadas em um sistema de controle de código-fonte (Git, Mercurial ou Subversion) e termina com o artefato testado e pronto para ser consumido por um sistema de entrega contínua. ## Problema relacionado diff --git a/content/pt-br/data-center.md b/content/pt-br/data-center.md index c25916748a..1e1cbc1a6d 100644 --- a/content/pt-br/data-center.md +++ b/content/pt-br/data-center.md @@ -5,8 +5,6 @@ category: tecnologia tags: ["infraestrutura", "", ""] --- -## O que é - Um *data center* é um edifício ou uma instalação especializada e projetada especificamente para abrigar computadores, na maioria das vezes servidores. Os *data centers* tendem a ser conectados a linhas dedicadas de internet de alta velocidade, especialmente no caso de *data centers* focados em [computação em nuvem](/pt-br/cloud-computing/). Os *data centers* também possuem equipamentos para manter o serviço em caso de eventos inesperados, como geradores para fornecer energia durante interrupções, bem como um poderoso ar-condicionado para lidar com o calor residual produzido pelos computadores. ## Problema relacionado diff --git a/content/pt-br/debugging.md b/content/pt-br/debugging.md index 94154fb178..5389f5c82b 100644 --- a/content/pt-br/debugging.md +++ b/content/pt-br/debugging.md @@ -5,8 +5,6 @@ category: conceito tags: ["aplicação", "metodologia", ""] --- -## O que é - Debugging é o processo ou atividade de encontrar e resolver bugs (ou erros) de programas de computador, software ou sistemas para obter o resultado desejado. Um bug é um defeito ou um problema que leva a resultados incorretos ou inesperados. diff --git a/content/pt-br/devops.md b/content/pt-br/devops.md index 0e913e144a..cb00ae1fab 100644 --- a/content/pt-br/devops.md +++ b/content/pt-br/devops.md @@ -5,8 +5,6 @@ category: conceito tags: ["metodologia", "", ""] --- -## O que é - DevOps é uma metodologia em que times são responsáveis por todo o processo desde o desenvolvimento da aplicação até a operação em produção, por isso o nome DevOps (Dev e Ops). Esta metodologia vai além da implementação de um conjunto de tecnologias, requer uma mudança profunda na cultura e nos processos. Além disso, DevOps orienta que o trabalho dos times seja focado em pequenos componentes (ao invés de uma funcionalidade completa), diminuindo as tranferências de responsabilidade ( _handoffs_ ), que são uma fonte comum de erros. diff --git a/content/pt-br/devsecops.md b/content/pt-br/devsecops.md index d462367c11..f9eef28ee4 100644 --- a/content/pt-br/devsecops.md +++ b/content/pt-br/devsecops.md @@ -5,8 +5,6 @@ category: conceito tags: ["metodologia", "segurança", ""] --- -## O que é - O termo DevSecOps refere-se a uma fusão cultural das responsabilidades de desenvolvimento, operação e de segurança. Ele estende a abordagem [DevOps](/pt-br/devops/) para incluir prioridades de segurança com interrupção mínima ou nenhuma no fluxo de trabalho operacional e do desenvolvedor. Assim como o DevOps, o DevSecOps é uma mudança cultural, impulsionada pelas tecnologias adotadas, com métodos de adoção exclusivos. diff --git a/content/pt-br/distributed-apps.md b/content/pt-br/distributed-apps.md index 7d1504a4bf..c109881c7b 100644 --- a/content/pt-br/distributed-apps.md +++ b/content/pt-br/distributed-apps.md @@ -5,8 +5,6 @@ category: conceito tags: ["arquitetura", "", ""] --- -## O que é - Uma aplicação distribuída é uma aplicação em que a funcionalidade é dividida em várias partes menores independentes. As aplicações distribuídas geralmente são compostas de [microsserviços](/microservices/) individuais que lidam com diferentes preocupações dentro da aplicação mais ampla. diff --git a/content/pt-br/distributed-systems.md b/content/pt-br/distributed-systems.md index 38fb84b1a3..a35af56fd7 100644 --- a/content/pt-br/distributed-systems.md +++ b/content/pt-br/distributed-systems.md @@ -5,8 +5,6 @@ category: conceito tags: ["arquitetura", "", ""] --- -## O que é - Um sistema distribuído é uma coleção de elementos de computação autônomos conectados por uma rede que aparece para os usuários como um único sistema coerente. Geralmente referidos como [nós](/pt-br/nodes/), esses componentes podem ser dispositivos de hardware (por exemplo, computadores, telefones móveis) ou processos de software. Os nós são programados para alcançar um objetivo comum e, para colaborar, eles trocam mensagens pela rede. ## Problema relacionado diff --git a/content/pt-br/edge-computing.md b/content/pt-br/edge-computing.md new file mode 100644 index 0000000000..0af831d026 --- /dev/null +++ b/content/pt-br/edge-computing.md @@ -0,0 +1,19 @@ +--- +title: Edge Computing +status: Completed +category: Tecnologia +--- + +A computação de borda é um modelo de [sistema distribuído](/pt-br/distributed-systems) que transfere parte da capacidade de armazenamento e processamento do [*data center*](/pt-br/data-center) principal para as fontes de dados. +Os dados coletados são processados localmente (por exemplo, em uma fábrica, em uma loja ou em toda uma cidade) em vez de serem enviados para um *data center* centralizado para processamento e análise. +Essas unidades ou dispositivos de processamento locais representam a borda do sistema, enquanto o *data center* é o seu centro. +A saída processada na borda é então enviada de volta para o *data center* principal para processamento adicional. +Exemplos de computação de borda incluem dispositivos vestíveis ou computadores que analisam o fluxo de tráfego. + +## Problema relacionado + +Na última década, vimos um aumento significativo nos dispositivos de borda (por exemplo, telefones celulares, relógios inteligentes ou sensores). Em alguns casos, o processamento de dados em tempo real não é apenas um recurso agradável de se ter, mas vital. Pense nos carros autônomos. Agora imagine se os dados dos sensores do carro tivessem que ser transferidos para um *data center* para processamento antes de serem enviados de volta para o veículo para que ele possa reagir adequadamente. A latência de rede inerente poderia ser fatal. Embora este seja um exemplo extremo, a maioria dos usuários não gostaria de usar um dispositivo inteligente que não pode fornecer feedback instantâneo. + +## Como ajuda + +Como descrito acima, para que os dispositivos de borda sejam úteis, eles devem fazer pelo menos parte do processamento e análise localmente para fornecer feedback quase em tempo real aos usuários. Isso é alcançado transferindo alguns recursos de armazenamento e processamento do *data center* para onde os dados são gerados: o dispositivo de borda. Os dados processados e não processados são posteriormente enviados para o *data center* para processamento e armazenamento adicionais. Em resumo, eficiência e velocidade são os principais impulsionadores da computação de borda. diff --git a/content/pt-br/event-driven-architecture.md b/content/pt-br/event-driven-architecture.md index 7353efe1da..d05c8cf117 100644 --- a/content/pt-br/event-driven-architecture.md +++ b/content/pt-br/event-driven-architecture.md @@ -5,8 +5,6 @@ category: conceito tags: ["arquitetura", "", ""] --- -## O que é - A arquitetura orientada por Eventos é uma arquitetura de software que promove a criação, o processamento, e o consumo de eventos. Um evento é qualquer alteração no estado de uma aplicação ou sistema. Por exemplo, solicitar uma corrida em um aplicativo de transporte representa um evento. diff --git a/content/pt-br/event-streaming.md b/content/pt-br/event-streaming.md index e09b1141ea..80c1348707 100644 --- a/content/pt-br/event-streaming.md +++ b/content/pt-br/event-streaming.md @@ -5,8 +5,6 @@ category: conceito tags: ["metodologia", "rede", ""] --- -## O que é - O streaming de eventos é uma abordagem em que o software envia dados de eventos de uma aplicação para outra para comunicar continuamente o que eles estão fazendo. Imagine um serviço transmitindo tudo o que faz para todos os outros serviços. Cada atividade realizada por um serviço é referida como um evento, portanto, streaming de evento. diff --git a/content/pt-br/firewall.md b/content/pt-br/firewall.md index e03dd0f300..2788f5d0f3 100644 --- a/content/pt-br/firewall.md +++ b/content/pt-br/firewall.md @@ -5,8 +5,6 @@ category: tecnologia tags: ["descontinuado", "", ""] --- -## O que é - Um firewall é um sistema que filtra o tráfego de rede com base em regras especificadas. Firewalls podem ser hardware, software ou uma combinação dos dois. ## Problema relacionado diff --git a/content/pt-br/function-as-a-service.md b/content/pt-br/function-as-a-service.md index bfa3647336..b2d45c1a18 100644 --- a/content/pt-br/function-as-a-service.md +++ b/content/pt-br/function-as-a-service.md @@ -5,8 +5,6 @@ category: Tecnologia tags: ["infraestrutura", "", ""] --- -## O que é - Função como um Serviço, (FaaS - Function as a Service ), é um tipo de [serviço](/pt-br/service/) de [computação em nuvem](/pt-br/cloud-computing/) [sem servidor](/pt-br/serverless/) que permite a execução de código em resposta a eventos sem manter a complexa infraestrutura normalmente associado à criação e lançamento de aplicações de [microsserviços](/microservices/). Com FaaS, os usuários gerenciam apenas funções e dados enquanto o provedor de nuvem gerencia a aplicação. diff --git a/content/pt-br/infrastructure-as-a-service.md b/content/pt-br/infrastructure-as-a-service.md index 46b1739756..7c2c26aba8 100644 --- a/content/pt-br/infrastructure-as-a-service.md +++ b/content/pt-br/infrastructure-as-a-service.md @@ -5,8 +5,6 @@ category: tecnologia tags: ["infraestrutura", "", ""] --- -## Como é - Infraestrutura como serviço, ou IaaS, é um modelo de serviço de [computação em nuvem](/pt-br/cloud-computing/) que oferece máquinas [físicas](/pt-br/bare-metal-machine/) ou [virtualizadas](/pt-br/virtualization/), armazenamento e recursos de rede sob demanda em um modelo pague conforme o uso. Os provedores de nuvem possuem e operam o hardware e o software, disponíveis para os consumidores em implantações de nuvem pública, privada ou híbrida. diff --git a/content/pt-br/infrastructure-as-code.md b/content/pt-br/infrastructure-as-code.md index 81d56c371b..280e31111b 100644 --- a/content/pt-br/infrastructure-as-code.md +++ b/content/pt-br/infrastructure-as-code.md @@ -5,8 +5,6 @@ category: conceito tags: ["infraestrutura", "metodologia", ""] --- -## O que é - Infraestrutura como código é a prática de armazenar a definição da infraestrutura como um ou mais arquivos. Isso substitui o modelo tradicional em que a infraestrutura como serviço era provisionada manualmente, geralmente por meio de scripts shell ou outras ferramentas de configuração. ## Problema relacionado diff --git a/content/pt-br/kubernetes.md b/content/pt-br/kubernetes.md index 1079e28308..51254ecbd1 100644 --- a/content/pt-br/kubernetes.md +++ b/content/pt-br/kubernetes.md @@ -5,8 +5,6 @@ category: tecnologia tags: ["infraestrutura", "fundamental", ""] --- -## O que é - Kubernetes, normalmente abreviado como K8s, é um orquestrador de contêineres de código aberto. Ele automatiza o ciclo de vida de aplicações em contêineres em infraestruturas modernas, funciona como um "sistema operacional de datacenter" que gerencia aplicativos em um [sistema distribuído](/distributed-systems/). diff --git a/content/pt-br/microservices.md b/content/pt-br/microservices.md index 4aefb95ad1..d7f69152f2 100644 --- a/content/pt-br/microservices.md +++ b/content/pt-br/microservices.md @@ -5,8 +5,6 @@ category: conceito tags: ["arquitetura", "", ""] --- -## O que é - Os microsserviços têm uma abordagem moderna para o desenvolvimento de aplicações que aproveita as tecnologias nativas da nuvem. Embora as aplicações modernas, como a Netflix, pareçam ser uma única aplicação, elas são na verdade uma coleção de serviços menores - todos trabalhando em colaboração. Por exemplo, uma única página que permite acessar, pesquisar e visualizar vídeos provavelmente é alimentada por serviços menores que lidam com um aspecto (por exemplo, pesquisa, autenticação e execução de visualizações no seu navegador). diff --git a/content/pt-br/monolithic-apps.md b/content/pt-br/monolithic-apps.md index 83d73a9aba..141d80d60d 100644 --- a/content/pt-br/monolithic-apps.md +++ b/content/pt-br/monolithic-apps.md @@ -5,8 +5,6 @@ category: conceito tags: ["arquitetura", "", ""] --- -## O que é - Uma aplicação monolítica contém todas as funcionalidades em um único programa. Este é muitas vezes o lugar mais simples e fácil para começar ao fazer uma aplicação. No entanto, uma vez que a aplicação cresce em complexidade, os monólitos podem se tornar difíceis de manter. diff --git a/content/pt-br/nodes.md b/content/pt-br/nodes.md index a63eaef0b0..63e82a99c6 100644 --- a/content/pt-br/nodes.md +++ b/content/pt-br/nodes.md @@ -5,8 +5,6 @@ category: conceito tags: ["infraestrutura", "fundamento", ""] --- -## O que é - Um nó é um computador que trabalha em conjunto com outros computadores, ou nós, para realizar uma tarefa comum. Pegue seu laptop, modem e impressora, por exemplo. Eles estão todos conectados pela sua rede wifi se comunicando e colaborando, cada um representando um nó. diff --git a/content/pt-br/observability.md b/content/pt-br/observability.md index 5a33f18482..ab0ddf1bf2 100644 --- a/content/pt-br/observability.md +++ b/content/pt-br/observability.md @@ -5,8 +5,6 @@ category: conceito tags: ["metodologia", "aplicação", "infraestrutura"] --- -## O que é - Observabilidade é a capacidade de gerar e descobrir continuamente insights acionáveis com base em sinais do sistema sob observação. Em outras palavras, a observabilidade permite que os usuários entendam o estado de um sistema a partir de sua saída externa e tome ação (corretiva). diff --git a/content/pt-br/platform-as-a-service.md b/content/pt-br/platform-as-a-service.md index 18e5546183..e834ad317f 100644 --- a/content/pt-br/platform-as-a-service.md +++ b/content/pt-br/platform-as-a-service.md @@ -5,8 +5,6 @@ category: tecnologia tags: ["descontinuado", "", ""] --- -## O que é - Plataforma como serviço, ou PaaS, é uma plataforma externa para equipes de desenvolvimento de aplicações implantarem e executarem suas aplicações. Heroku, Cloud Foundry, App Engine são exemplos de ofertas de PaaS. ## Problema relacionado diff --git a/content/pt-br/search.md b/content/pt-br/search.md new file mode 100644 index 0000000000..d9a4d5beef --- /dev/null +++ b/content/pt-br/search.md @@ -0,0 +1,4 @@ +--- +title: Search Results +layout: search +--- \ No newline at end of file diff --git a/content/pt-br/serverless.md b/content/pt-br/serverless.md index cb6293b05e..8d563dcb69 100644 --- a/content/pt-br/serverless.md +++ b/content/pt-br/serverless.md @@ -5,8 +5,6 @@ Category: tecnologia tags: ["arquitetura", "", ""] --- -## O que é - Serverless é um modelo de desenvolvimento nativo na nuvem que permite que desenvolvedores criem aplicações sem que seja necessário gerenciar servidores. Ainda existem servidores no modelo serverless, mas eles são [abstraídos](/pt-br/abstraction/) do desenvolvimento. Um provedor de computação em nuvem se encarrega do provisionamento, manutenção e [escala](/scalability/) da infraestrutura de servidores. Desenvolvedores podem simplesmente carregar o código em [contêineres](/pt-br/container/) para implantação. Uma vez implantadas, aplicações serverless respondem automaticamente à demanda, escalando para cima e para baixo conforme necessário. O preço cobrado por provedores de computação em nuvem para funções serverless geralmente é realizada com base na sua utilização sob demanda. Como resultado disto, quando uma função serverless não está em execução ela não tem custo algum. ## Problema relacionado diff --git a/content/pt-br/shift-left.md b/content/pt-br/shift-left.md index 163f8fe7f4..b1f54746ae 100644 --- a/content/pt-br/shift-left.md +++ b/content/pt-br/shift-left.md @@ -5,8 +5,6 @@ category: conceito tags: ["metodologia", "", ""] --- -## O que é - Esquerda em Shift Left se refere aos estágios iniciais no ciclo de desenvolvimento de software, pensando no ciclo como uma linha onde os estágios são executados da esquerda para a direita. Shift left é a prática de implementar testes, segurança ou outras práticas de desenvolvimento diff --git a/content/pt-br/site-reliability-engineering.md b/content/pt-br/site-reliability-engineering.md index 317a1c2e03..d86e063667 100644 --- a/content/pt-br/site-reliability-engineering.md +++ b/content/pt-br/site-reliability-engineering.md @@ -5,8 +5,6 @@ category: conceito tags: ["metodologia", "", ""] --- -## O que é - Engenharia de Confiabilidade de Sites (do inglês *Site Reliability Engineering* - SRE) é uma disciplina que combina operações e engenharia de software. Este último é aplicado especificamente a problemas de infraestrutura e operações. Ou seja, em vez de criar recursos do produto, os Engenheiros de Confiabilidade criam sistemas para rodar aplicativos. Existem semelhanças com o DevOps, mas enquanto o DevOps se concentra em colocar o código em produção, o SRE garante que o código em execução na produção funcione corretamente. ## Problema relacionado diff --git a/content/pt-br/software-as-a-service.md b/content/pt-br/software-as-a-service.md index d74aa4b0c1..d77530e1a2 100644 --- a/content/pt-br/software-as-a-service.md +++ b/content/pt-br/software-as-a-service.md @@ -5,8 +5,6 @@ Category: tecnologia tags: ["descontinuado", "", ""] --- -## O que é - O Software como Serviço (do inglês *Software as a service* - SaaS) permite que os usuários se conectem e usem serviços baseados em nuvem. Exemplos comuns são as ferramentas de e-mail, de calendário e de escritório (como Gmail, Amazon Web Services, GitHub, Slack). O SaaS fornece soluções completas de software com base de pagamento conforme o uso. Todas as tarefas de operações e manutenção, e dados do aplicativo, são tratadas pelo provedor de serviços. ## Problema relacionado diff --git a/content/pt-br/stateful-apps.md b/content/pt-br/stateful-apps.md index 07032e792f..456a76957f 100644 --- a/content/pt-br/stateful-apps.md +++ b/content/pt-br/stateful-apps.md @@ -5,8 +5,6 @@ category: conceito tags: ["fundamento", "aplicação", ""] --- -## O que é - Quando falamos das aplicações stateful e stateless, nos referimos a todos os dados que a aplicação precisa armazenar para funcionar como projetada. Qualquer tipo de loja online que lembre do seu carrinho é uma aplicação stateful, por exemplo. ## Problema relacionado diff --git a/content/pt-br/stateless-apps.md b/content/pt-br/stateless-apps.md index 0b48896079..d8470edcfb 100644 --- a/content/pt-br/stateless-apps.md +++ b/content/pt-br/stateless-apps.md @@ -5,8 +5,6 @@ category: tecnologia tags: ["fundamento", "aplicação", ""] --- -## O que é - Um aplicação stateless não salva nenhum dado de sessão do cliente no servidor onde a aplicação está. Cada sessão é realizada como se fosse a primeira vez e as respostas não dependem de dados de uma sessão anterior e fornecem funcionalidade para usar os serviços de impressão, rede de entrega de conteúdo ou os servidores web para processar todas as requisições de curto prazo. Por exemplo, alguém está pesquisando uma pergunta no mecanismo de pesquisa e pressionou o Enter. Caso a operação de pesquisa seja interrompida ou fechada por algum motivo, você terá que iniciar uma nova, pois não há dados salvos para sua requisição anterior. ## Problema relacionado diff --git a/content/pt-br/style-guide/_index.md b/content/pt-br/style-guide/_index.md index 116aa40a91..a2eb73458d 100644 --- a/content/pt-br/style-guide/_index.md +++ b/content/pt-br/style-guide/_index.md @@ -37,7 +37,6 @@ status: category: --- -## What it is Um breve resumo da tecnologia ou conceito. diff --git a/content/pt-br/transport-layer-security.md b/content/pt-br/transport-layer-security.md index 7aa7f484bd..56d26afb28 100644 --- a/content/pt-br/transport-layer-security.md +++ b/content/pt-br/transport-layer-security.md @@ -5,8 +5,6 @@ category: conceito tags: ["segurança", "rede", ""] --- -## O que é - Transport Layer Security (TLS) é um protocolo projetado para fornecer maior segurança à comunicação através de uma rede. Garante a entrega segura de dados enviados pela Internet, evitando possíveis monitoramentos e/ou alterações dos dados. Este protocolo é amplamente utilizado em aplicações como mensagens, e-mail, etc. ## Problema relacionado diff --git a/content/pt-br/version-control.md b/content/pt-br/version-control.md index 5ff30a6530..aadc07b203 100644 --- a/content/pt-br/version-control.md +++ b/content/pt-br/version-control.md @@ -5,8 +5,6 @@ category: tecnologia tags: ["descontinuado", "", ""] --- -## O que é - O controle de código (ou controle de versão) é a prática de rastrear e gerenciar alterações de um documento. É um sistema que registra alterações de um arquivo ou conjunto de arquivos ao longo do tempo para que você possa recuperar versões específicas mais tarde. ## Problema relacionado diff --git a/content/pt-br/vertical-scaling.md b/content/pt-br/vertical-scaling.md index 818af3e37c..422ba03045 100644 --- a/content/pt-br/vertical-scaling.md +++ b/content/pt-br/vertical-scaling.md @@ -5,8 +5,6 @@ category: conceito tags: ["infraestrutura", "", ""] --- -## O que é - O escalonamento vertical, também conhecido como "escalonamento para cima e para baixo", é uma técnica em que a capacidade de um sistema adiciona CPU e memória aos [nós](/nodes/) individuais à medida que a carga de trabalho aumenta. Digamos que você tenha um computador de 4GB de RAM e queira aumentar sua capacidade para 16GB de RAM, escalar verticalmente significa mudar para um sistema de 16GB de RAM. (Consulte [escalonamento horizontal](/horizontal-scaling/) para obter uma abordagem de dimensionamento diferente.) ## Problema relacionado diff --git a/content/pt-br/virtual-machine.md b/content/pt-br/virtual-machine.md index 44a23ba6d4..0982fd2842 100644 --- a/content/pt-br/virtual-machine.md +++ b/content/pt-br/virtual-machine.md @@ -5,8 +5,6 @@ category: tecnologia tags: ["fundamento", "infraestrutura", ""] --- -## O que é - Uma máquina virtual ou VM (do inglês "Virtual Machine") é a inexistência de vínculo de um computador e seu sistema operacional a um hardware específico. As VMs dependem da [virtualização](/pt-br/virtualization/) para transformar um único computador físico em vários computadores virtuais. Essa separação permite que organizações e provedores de infraestrutura criem e destruam facilmente VMs sem afetar o hardware fisicamente. ## Problema relacionado diff --git a/content/pt-br/virtualization.md b/content/pt-br/virtualization.md index 8c37647c1e..175d5e47d2 100644 --- a/content/pt-br/virtualization.md +++ b/content/pt-br/virtualization.md @@ -5,8 +5,6 @@ category: tecnologia tags: ["fundamento", "infraestrutura", "metodologia"] --- -## O que é - A virtualização, no contexto da computação nativa da nuvem, refere-se ao processo de pegar um computador físico, às vezes chamado de servidor, e permitir que ele execute vários sistemas operacionais isolados. Esses sistemas operacionais isolados e seus recursos de computação dedicados (CPU, memória e rede) são chamados de máquinas virtuais ou VMs (do inglês "Virtual Machine"). Quando falamos de uma máquina virtual, estamos falando de um computador definido por software. Algo que parece e age como um computador real, mas está compartilhando hardware com outras máquinas virtuais. Por exemplo, você pode alugar um "computador" da AWS - esse computador na verdade é uma VM. ## Problema relacionado diff --git a/content/pt-br/zero-trust-architecture.md b/content/pt-br/zero-trust-architecture.md index c482304e6e..282d08d18c 100644 --- a/content/pt-br/zero-trust-architecture.md +++ b/content/pt-br/zero-trust-architecture.md @@ -5,8 +5,6 @@ category: conceito tags: ["segurança", "", ""] --- -## O que é - A arquitetura de confiança zero (do inglês "Zero trust architecture") prescreve uma abordagem para o projeto e implementação de sistemas de TI onde a confiança é completamente removida. O princípio central é "nunca confie, sempre verifique", dispositivos ou sistemas em si, enquanto se comunicam com outros componentes de um sistema, sempre se verificam antes de fazê-lo. Atualmente, em muitas redes, dentro da rede corporativa, os sistemas e dispositivos internos podem se comunicar livremente uns com os outros, pois estão dentro do perímetro confiável da rede corporativa. A arquitetura de confiança zero adota a abordagem oposta, que, embora dentro do perímetro da rede, os componentes dentro do sistema primeiro precisam passar pela verificação antes que qualquer comunicação seja feita. ## Problema relacionado diff --git a/content/ru/_TEMPLATE.md b/content/ru/_TEMPLATE.md new file mode 100644 index 0000000000..20c4c7c0ab --- /dev/null +++ b/content/ru/_TEMPLATE.md @@ -0,0 +1,19 @@ +--- +title: Шаблон для определений +status: Feedback Appreciated +category: concept +--- + +Краткое и четкое описание того, о чем идет речь. + +## Какую проблему решает + +Проблема, которую решает описываемая технология. Старайтесь не использовать термин, которому вы даете определение. В этом разделе необходимо сфокусироваться на предпосылках, которые стали причиной появления описываемой технологии или концепции. + +## Как именно решает проблему + +Здесь можно вернуться к самому термину и объяснить, как именно он помогает решить описанную в предыдущем пункте проблему. + +## Связанные термины + +Добавьте сюда другие релевантные термины из глоссария (если они есть). diff --git a/content/ru/_index.md b/content/ru/_index.md new file mode 100644 index 0000000000..ff626548f7 --- /dev/null +++ b/content/ru/_index.md @@ -0,0 +1,60 @@ +--- +title: "Глоссарий Cloud Native" +status: Completed +--- + +# Глоссарий Cloud Native + +Глоссарий Cloud Native преназначен для того, чтобы в сфере cloud native, сложность которой уже стала притчей во языцех, было легче разобраться не только IT-специалистам, но и представителям бизнеса. +Именно поэтому мы делаем упор на простоту (доступный язык, свободный от заковыристых терминов; примеры, которые понятны любому человеку с базовым пониманием технологий; отказ от лишних подробностей). +Работа над глоссарием ведется под руководством подкомитета CNCF по деловой ценности (Business Value Subcommittee, BVS). + +

Зрители смотрят презентацию на KubeCon

+ +## Внести свой вклад + +Приглашаем всех желающих поучаствовать в развитии «Глоссария Cloud Native», его дополнении и улучшении. +Процесс разработки единой терминологии и ее совершенствования управляется сообществом и регулируется CNCF. +Глоссарий придерживается принципа независимости от конкретных вендоров и ставит своей целью создание словаря-справочника по нативным облачным технологиям. +Приветствуется любое участие при условии, что оно соответствует целям и уставу проекта. + +Все желающие могут открыть Issue на GitHub или создать Pull Request. +Для этого необходимо предварительно ознакомиться с документом [Как внести свой вклад](/ru/contribute/) и присоединиться к каналу [#glossary](https://cloud-native.slack.com/archives/C02TX20MQBB) в рабочем пространстве CNCF в Slack. +Кроме того, важно убедиться, что предлагаемые правки соответствуют [Руководству по стилю](/ru/style-guide/). +Для тех, кто хочет поучаствовать в переводе глоссария на родной язык, существует канал [#glossary-localizations](https://cloud-native.slack.com/archives/C02N2RGFXDF) (для русского языка — [#glossary-localization-russian](https://cloud-native.slack.com/archives/C05G46RMQTX)). + +## Благодарности + +Глоссарий Cloud Native создан по инициативе маркетингового комитета CNCF (подкомитет по бизнес-ценностям) при участии +[Catherine Paganini](https://www.linkedin.com/in/catherinepaganini/en/), +[Chris Aniszczyk](https://www.linkedin.com/in/caniszczyk/), +[Daniel Jones](https://www.linkedin.com/in/danieljoneseb/?originalSubdomain=uk), +[Jason Morgan](https://www.linkedin.com/in/jasonmorgan2/), +[Katelin Ramer](https://www.linkedin.com/in/katelinramer/), +[Mike Foster](https://www.linkedin.com/in/mfosterche/?originalSubdomain=ca), +и многих других авторов. +Полный список участников проекта можно найти на [отдельной странице](https://github.com/cncf/glossary/graphs/contributors) на GitHub. + +Хранителями глоссария являются: +- [Seokho Son](https://www.linkedin.com/in/seokho-son/); +- [Noah Ispas](https://www.linkedin.com/in/noah-ispas-0665b42a/); +- [Jihoon Seo](https://www.linkedin.com/in/jihoon-seo/); +- [Nate W.](https://www.linkedin.com/in/nate-double-u/); +- [Jorge Castro](https://www.linkedin.com/in/jorge-castro2112/). + +[Catherine Paganini](https://www.linkedin.com/in/catherinepaganini/en/) +и [Jason Morgan](https://www.linkedin.com/in/jasonmorgan2/) +являются Почетными Хранителями, и мы глубоко признательны +за их неоценимый вклад в развитие проекта на протяжении многих лет. + +Русскоязычная локализация глоссария Cloud Native была инициирована +усилиями команды Russian Localization Team, изначальный состав которой +сформировали [Кирилл Кононович](https://github.com/kirkonru), +[Тимур Тукаев](https://github.com/tym83) и [Дмитрий Шурупов](https://www.linkedin.com/in/shurupov/). +Со временем свой вклад в локализацию внесли и другие контрибьюторы, +которым мы очень благодарны и всегда рады в канале [#glossary-localization-russian](https://cloud-native.slack.com/archives/C05G46RMQTX). + +## Лицензия + +Весь код публикуется на условиях лицензии Apache 2.0. +Документация распространяется на условиях лицензии CC BY 4.0. diff --git a/content/ru/abstraction.md b/content/ru/abstraction.md new file mode 100644 index 0000000000..f1a9a32d0e --- /dev/null +++ b/content/ru/abstraction.md @@ -0,0 +1,23 @@ +--- +title: Абстракция +status: Completed +category: Property +tags: ["fundamental", "", ""] +--- + +В контексте вычислительной техники абстракция — это представление, +которое скрывает специфику реализации от потребителя [сервисов](/service/) +(потребителем является компьютерная программа или человек), +делая систему более простой и понятной. +Хороший пример — операционная система (ОС) компьютера. +Она абстрагирует все тонкости работы компьютера. +Пользователю не нужно ничего знать о процессоре, памяти и работе с программами: +он просто управляет операционной системой, а та разбирается со всеми нюансами. +Все они скрыты за «занавесом» ОС или абстракцией. + +Системы, как правило, имеют несколько уровней абстракции. +Это значительно упрощает разработку. +При программировании разработчики создают компоненты, совместимые с определенным уровнем абстракции, +и не заботятся о том, как та или иная функциональность реализована на нижележащих уровнях. +Достаточно того, что эти компоненты работают с определенным уровнем абстракции. +А то, что у него скрыто «под капотом», не имеет значения. diff --git a/content/ru/agile-software-development.md b/content/ru/agile-software-development.md new file mode 100644 index 0000000000..e15f9bcc62 --- /dev/null +++ b/content/ru/agile-software-development.md @@ -0,0 +1,26 @@ +--- +title: Гибкий подход к разработке программного обеспечения (Agile) +status: Completed +category: concept +tags: ["methodology", "", ""] +--- + +Набор практик, в которых особое внимание уделяется итеративным циклам разработки и самоорганизующимся командам. +В отличие от каскадной (waterfall) модели, в которой ценность проявляется только в самом конце проекта, +agile-разработка ПО ориентирована на непрерывное и инкрементное получение ценности +и эволюционное совершенствование самого процесса. + +## Какую проблему решает + +Определить, понять и донести требования до всех заинтересованных сторон в программном проекте очень сложно, если вообще возможно. +Тем не менее, заказчики хотят, чтобы их программные проекты выполнялись в срок, с хорошим качеством, в рамках бюджета и с соблюдением требований. +Благодаря своей цикличности, agile-разработка ПО позволяет непрерывно адаптировать требования +и быстрее приспосабливаться к любым другим обстоятельствам (в отличие от каскадных стратегий). + +## Как именно решает проблему + +Agile-разработка программного обеспечения содержит все фазы традиционных (каскадных) стратегий, +такие как проработка требований, планирование, реализация, анализ, тестирование и поставка. +Самое большое отличие заключается в том, что весь период работы над программным проектом разбивается на итерации, каждая из которых содержит все эти этапы. +По окончании каждой итерации заказчик анализирует созданную ценность и корректирует требования для достижения конечной цели. +Кроме того, команда разработчиков проводит ретроспективный анализ того, какие действия необходимо предпринять для улучшения самого процесса. diff --git a/content/ru/api-gateway.md b/content/ru/api-gateway.md new file mode 100644 index 0000000000..cb8d6a4791 --- /dev/null +++ b/content/ru/api-gateway.md @@ -0,0 +1,29 @@ +--- +title: Шлюз API +status: Completed +category: technology +tags: ["networking", "", ""] +--- + +Шлюз [API](/application-programming-interface/) объединяет уникальные API-интерфейсы различных приложений, делая их доступными в одном месте. +Он позволяет перенести ключевые функции, такие как аутентификация, авторизация +и лимитирование количества запросов между приложениями, +в централизованно управляемое место. +Шлюз API выступает единым интерфейсом для (часто внешних) пользователей API. + +## Какую проблему решает + +Делая API доступными для внешних потребителей, логично позаботиться и о единой точке входа — +она облегчит управление и позволит контролировать, кто и когда подключается к API. +Кроме того, шлюз API позволяет расширять имеющуюся функциональность, +единообразно обрабатывая весь проходящий трафик (благодаря этому, не нужно вносить изменения в код приложения). + +## Как именно решает проблему + +Создавая единую точку доступа к различным API в приложении, +API-шлюзы облегчают организациям применение бизнес-логики или политик безопасности, собирая их в одном месте. +Теперь приложения-потребители могут обращаться на единый адрес со всеми своими запросами. +Шлюз API упрощает решение задач эксплуатации — например, в области безопасности и [наблюдаемости](/observability/), — +предоставляя единую точку доступа для запросов ко всем веб-сервисам в системе. +Поскольку все запросы проходят через API-шлюз, его удобно использовать для добавления таких функций, +как сбор метрик, ограничение частоты запросов и авторизация. diff --git a/content/ru/application-programming-interface.md b/content/ru/application-programming-interface.md new file mode 100644 index 0000000000..9245108507 --- /dev/null +++ b/content/ru/application-programming-interface.md @@ -0,0 +1,24 @@ +--- +title: Программный интерфейс приложения (API) +status: Completed +category: technology +tags: ["architecture", "fundamental", ""] +--- + +API определяет способ взаимодействия компьютерных программ друг с другом. +Подобно тому, как люди взаимодействуют с веб-сайтом через веб-страницу, API позволяет компьютерным программам взаимодействовать друг с другом. +Но в отличие от общения людей друг с другом, API налагают ограничения на то, какие запросы к ним посылать можно, а какие нельзя. +Ограничение на взаимодействие позволяет создать устойчивую и функциональную связь между программами. + +## Какую проблему решает + +С ростом сложности приложений небольшие изменения в коде могут кардинально повлиять на другие их функциональные возможности. +Для того чтобы приложения могли одновременно расти и оставаться стабильными, необходимо использовать модульный подход к их функциональности. +API как раз выступают в качестве основы для взаимодействия между приложениями. +Без такой единой и общей базы приложениям было бы сложно [масштабироваться](/scalability/) и интегрироваться. + +## Как именно решает проблему + +API позволяют компьютерным программам или приложениям взаимодействовать и обмениваться информацией в четко определенной и понятной форме. +Они выступают строительными блоками для современных программ и предоставляют разработчикам возможность интегрировать приложения друг с другом. +Слышали о совместной работе [микросервисов](/microservices/)? В большинстве случаев они взаимодействуют именно через API. diff --git a/content/ru/auto-scaling.md b/content/ru/auto-scaling.md new file mode 100644 index 0000000000..b18aa652e5 --- /dev/null +++ b/content/ru/auto-scaling.md @@ -0,0 +1,31 @@ +--- +title: Автомасштабирование +status: Completed +category: property +tags: ["infrastructure", "", ""] +--- + +Автомасштабирование — это способность системы автоматически [масштабироваться](/scalability/), как правило, в контексте вычислительных ресурсов. +При автомасштабировании ресурсы по мере необходимости автоматически добавляются — в соответствии с меняющимися потребностями пользователей. +Автомасштабирование может производиться на основе различных метрик, таких как память или время выполнения процесса. +Автомасштабирование обычно ассоциируется с облачными managed-сервисами, поскольку те предлагают больше опций и реализаций этой функции, +чем традиционные «физические» (on-premise) виды инфраструктуры. + +Ранее инфраструктура и приложения проектировались с учетом пиковой загрузки системы. +Такой подход означал, что значительное количество ресурсов недоиспользуется, +а сама система не может гибко реагировать на изменение количества пользователей и их потребностей. +Такая неэластичность приводила к росту затрат и потерям от перебоев в работе во время большого наплыва пользователей, +когда ресурсов системы просто не хватало на всех. + +Используя облачные технологии, [виртуализацию](/virtualization/) и [контейнеризацию](/ru/containerization/) приложений и их зависимостей, +организации могут создавать приложения, которые масштабируются в соответствии с потребностями пользователей. +Они могут отслеживать загруженность приложений и автоматически масштабировать их, обеспечивая оптимальный пользовательский опыт. +Хорошим примером являются сервисы потокового видео вроде Netflix — в пятницу вечером все они сталкиваются +со значительным увеличением зрительской аудитории и, как следствие, ростом нагрузки на серверы. +Автомасштабирование позволяет динамически добавлять дополнительные ресурсы: например, увеличивать количество серверов, +транслирующих видео, и возвращать ресурсы в исходное состояние после нормализации потребления. + +## Связанные термины + +* [Горизонтальное масштабирование](/horizontal-scaling/) +* [Вертикальное масштабирование](/vertical-scaling/) diff --git a/content/ru/bare-metal-machine.md b/content/ru/bare-metal-machine.md new file mode 100644 index 0000000000..c43feac436 --- /dev/null +++ b/content/ru/bare-metal-machine.md @@ -0,0 +1,32 @@ +--- +title: Bare metal-компьютер +status: Completed +category: technology +tags: ["infrastructure", "", ""] +--- + +Под компьютером типа bare metal («голое железо») понимается физический компьютер, а точнее — сервер, +на котором установлена одна и только одна операционная система. +Это различие важно, поскольку многие, если не большинство, серверов являются [виртуальными машинами](/virtual-machine/). +Физический сервер — это, как правило, достаточно серьезный компьютер с мощным аппаратным обеспечением. +Установка операционной системы и запуск приложений непосредственно на физическом оборудовании, +без [виртуализации](/virtualization/), называется работой на «голом железе». + +## Какую проблему решает + +В вычислительной технике изначально применялся подход, в котором на один компьютер устанавливалась только одна операционная система. +В этом случае все ресурсы физического компьютера были доступны операционной системе напрямую +и отсутствовала искусственная задержка при передаче инструкций ОС к аппаратному обеспечению, связанная со слоем виртуализации. + +## Как именно решает проблему + +Обеспечивая единственной операционной системе доступ ко всем ресурсам компьютера, +вы в теории гарантируете, что ее производительность будет максимальной. +«Голое железо» отлично подходит для рабочих нагрузок, которым требуется быстрый доступ к аппаратным ресурсам. + +В контексте [нативных облачных приложений](/ru/cloud-native-apps/) +производительность обычно рассматривается с точки зрения [масштабирования](/scalability/) до большого числа одновременных событий (процессов, операций). +Помогает в этом [горизонтальное масштабирование](/horizontal-scaling/) (добавление новых машин в пул ресурсов). +Однако для некоторых рабочих нагрузок может потребоваться [вертикальное масштабирование](/vertical-scaling/) (увеличение мощности существующей физической машины) и/или чрезвычайно быстрый отклик физического аппаратного обеспечения. В этом случае лучше использовать «голое железо». +Кроме того, подход на основе «голого железа» позволяет подстраивать аппаратное обеспечение +(а в некоторых случаях и его драйверы) под конкретные задачи. diff --git a/content/ru/blue-green-deployment.md b/content/ru/blue-green-deployment.md new file mode 100644 index 0000000000..9af797a6c0 --- /dev/null +++ b/content/ru/blue-green-deployment.md @@ -0,0 +1,31 @@ +--- +title: Сине-зеленое развертывание +status: Completed +category: concept +tags: ["methodology", "application", ""] +--- + +Сине-зеленое развертывание — стратегия обновления работающих компьютерных систем с минимальным временем простоя. +Оператор использует два окружения: «синее» и «зеленое». +Одно из них обслуживает production-трафик (в нем работает текущая версия, с которой взаимодействуют пользователи), а другое в это время обновляется. +После успешного завершения тестирования «зеленого» окружения (с новой версией) +production-трафик переключается на него (часто с помощью балансировщика нагрузки). +Отметим, что в этой стратегии окружения обычно переключаются сразу со всеми [сервисами](/service/). +Однако иногда этот термин используется по отношению к отдельным сервисам в системе. +Чтобы избежать подобной двусмысленности, для отдельных компонентов предпочтительно +использовать термин «развертывание с нулевым временем простоя» _(zero-downtime deployment)_. + +## Какую проблему решает + +Сине-зеленые развертывания позволяют свести к минимуму время простоя при обновлении программного обеспечения, +разные версии которого несовместимы (т. е. когда приходится обновлять сразу все компоненты). +Например, сине-зеленое развертывание отлично подойдет для интернет-магазина, состоящего из сайта и базы данных. +Предположим, что базу даных необходимо обновить, однако ее новая версия несовместима со старой версией сайта, и наоборот. +В этом случае необходимо сразу обновить и сайт, и базу данных. +Если это делать на живой production-системе, клиенты заметят перебои в работе. + +## Как именно решает проблему + +Сине-зеленое развертывание — подходящая стратегия для ненативного облачного ПО, которое необходимо обновлять с минимальным временем простоя. +Необходимость в этой стратегии обычно намекает на то, что программное обеспечение нуждается в перепроектировании, +в результате которого его компоненты можно было бы обновлять по отдельности. diff --git a/content/ru/canary-deployment.md b/content/ru/canary-deployment.md new file mode 100644 index 0000000000..2ca8513794 --- /dev/null +++ b/content/ru/canary-deployment.md @@ -0,0 +1,31 @@ +--- +title: Канареечное развертывание +status: Completed +category: concept +tags: ["methodology", "application", ""] +--- + +Стратегия канареечных развертываний _(canary deployments)_ начинается с двух окружений: +одно из них уже обслуживает пользователей, другое — содержит обновленный код (но пока без трафика). +Трафик постепенно переключается с исходной, старой версии приложения на новую. +Начинают обычно с минимального процента (например, с 1%) и постепенно увеличивают долю трафика, +которая поступает в новую версию, пока та не достигнет 100%. +Такая стратегия позволяет протестировать новую версию ПО в production, получить обратную связь, +диагностировать ошибки и при необходимости быстро откатиться к старой стабильной версии. + +Сам термин происходит от старой практики, когда канарейки помогали выявлять опасные газы в шахтах. +Если в шахте были вредные газы, не имеющие запаха, птица погибала, и шахтеры понимали, что необходимо срочно эвакуироваться. +То же самое справедливо и для канареечных развертываний: если окажется, что с новым кодом что-то не так, +можно сразу откатиться на старую версию. + +## Какую проблему решает + +Какой бы тщательной ни была стратегия тестирования, в процессе эксплуатации всегда обнаруживаются те или иные ошибки. +Переключение сразу всего трафика с одной версии приложения на другую может привести к масштабным сбоям. + +## Как именно решает проблему + +Канареечные развертывания позволяют увидеть, как новое программное обеспечение поведет себя в реальных условиях, +прежде чем направлять на него весь трафик. +Такая стратегия помогает минимизировать время простоя и быстро откатиться назад в случае возникновения проблем с новым развертыванием. +Также она позволяет проводить более глубокое тестирование production-приложений, не оказывая существенного влияния на пользовательский опыт. diff --git a/content/ru/chaos-engineering.md b/content/ru/chaos-engineering.md new file mode 100644 index 0000000000..d7764df6c5 --- /dev/null +++ b/content/ru/chaos-engineering.md @@ -0,0 +1,30 @@ +--- +title: Хаос-инженерия +status: Completed +category: concept +tags: ["methodology", "", ""] +--- + +Хаос-инженерия (_chaos engineering_, CE) — подход, при котором над [распределенной](/distributed-systems/) production-системой проводятся различные эксперименты, +цель которых — убедиться, что она способна противостоять турбулентным и неожиданным ситуациям. + +## Какую проблему решает + +Практики [SRE](/site-reliability-engineering/) и [DevOps](/ru/devops/) концентрируются на +методах повышения отказоустойчивости и надежности систем. +Способность системы выдерживать сбои, обеспечивая при этом надлежащее качество обслуживания, +как правило, является одним из требований при разработке программного обеспечения. +Перебои в работе (основанного на [микросервисах](/microservices/)) приложения могут быть связаны с различными аспектами: +инфраструктурой, платформой и другими компонентами, которые могут изменяться. +Частое развертывание новых функций в production-окружении повышает вероятность критического инцидента +и простоя со значительными негативными последствиями для бизнеса. + +## Как именно решает проблему + +Хаос-инженерия помогает удовлетворить требования к живучести систем. +Она используется для проверки устойчивости инфраструктуры, платформ и приложений к сбоям. +В рамках хаос-экспериментов в систему вводятся случайные «поломки», чтобы проверить, способны ли приложение, +инфраструктура или платформа самовосстанавливаться, и убедиться, что сбой не оказывает значимое негативное влияние на потребителей. +Хаос-эксперименты направлены на выявление «слепых зон» (например, в мониторинге или при автомасштабировании) +и на улучшение коммуникаций между командами во время критических инцидентов. +Такой подход позволяет повысить отказоустойчивость сложных систем (в том числе production-уровня) и уверенность команд в них. diff --git a/content/ru/client-server-architecture.md b/content/ru/client-server-architecture.md new file mode 100644 index 0000000000..ab1534edc8 --- /dev/null +++ b/content/ru/client-server-architecture.md @@ -0,0 +1,35 @@ +--- +title: Архитектура клиент-сервер +status: Completed +category: concept +tags: ["architecture", "fundamental", ""] +--- + +В клиент-серверной архитектуре логика (или код), составляющая приложение, распределяется между двумя или более компонентами: +клиентом, запрашивающим выполнение некой работы +(например, веб-приложение Gmail, работающее в браузере), +и одним или несколькими серверами, удовлетворяющими этот запрос +(например, сервис отправки почты, работающий на компьютерах Google в облаке). +В этом примере исходящие письма отправляются клиентом (веб-приложением, работающим в браузере) +на сервер (компьютеры Gmail, которые пересылают их получателям). + +Этот подход отличается от автономных приложений (например, десктопных), которые выполняют всю работу в одном месте. +Например, текстовый процессор Microsoft Word может быть установлен на персональный компьютер и работать только на нем. + +## Какую проблему решает + +Архитектура клиент-сервер решает серьезную проблему, с которой сталкиваются автономные приложения: регулярное обновление. +Чтобы обновить автономное приложение, пользователям необходимо загрузить и установить последнюю версию. +А теперь представьте, что для просмотра каталога товаров Amazon вам необходимо сначала загрузить его себе на компьютер! + +## Как именно решает проблему + +Когда логика приложения реализована на удаленном сервере или в сервисе, операторы могут обновлять ее, +не меняя логику на стороне клиента. +Поэтому обновления можно производить гораздо чаще. +Хранение данных на сервере позволяет различным клиентам видеть одни и те же данные и совместно их использовать. +Рассмотрим разницу между онлайновым текстовым процессором и традиционным офлайновым, который работает на локальном компьютере. +В первом случае ваши файлы находятся на стороне сервера и +могут быть доступны другим пользователям, которые просто скачивают их с сервера. +Во втором случае (когда Интернет не был доступен повсеместно) файлы приходилось копировать +на съемные носители (дискеты!) и передавать каждому пользователю по отдельности. diff --git a/content/ru/cloud-computing.md b/content/ru/cloud-computing.md new file mode 100644 index 0000000000..90dd18a945 --- /dev/null +++ b/content/ru/cloud-computing.md @@ -0,0 +1,22 @@ +--- +title: Облачные вычисления +status: Completed +category: concept +tags: ["infrastructure", "fundamental", ""] +--- + +Облачные вычисления _(cloud computing)_ — собирательное название систем, которые предоставляют вычислительные ресурсы (процессорные, сетевые и дисковые) по запросу через сеть Интернет. В результате пользователи получают доступ к вычислительным мощностям, которые физически расположены в совершенно другом, удаленном месте. +Обычно облака подразделяются на приватные и публичные в зависимости от того, предназначена ли облачная инфраструктура для одной организации или используется множеством открытых публичных сервисов совместно. + +## Какую проблему решает + +Классически существовало два способа, которыми организации могли увеличить свои вычислительные мощности. +Они могли либо приобретать, поддерживать и проектировать (новые) объекты для размещения своих физических серверов и сетей, либо расширять существующие. +Облачные вычисления решают эту проблему, позволяя организациям привлекать сторонние ресурсы для удовлетворения своих вычислительных потребностей. + +## Как именно решает проблему + +Облачные провайдеры позволяют организациям арендовать вычислительные ресурсы по требованию и платить непосредственно за их использование. У такого подхода есть два ключевых преимущества. +Во-первых, организации могут сконцентрироваться на разработке своего продукта или услуги, не дожидаясь доступности новой инфраструктуры. Им больше не нужно тратить время и деньги на проектирование и строительство инфраструктурных объектов. +Во-вторых, они могут просто [масштабировать](/scalability/) ресурсы по мере необходимости. +Облачные вычисления позволяют использовать ровно столько ресурсов, сколько необходимо. diff --git a/content/ru/cloud-native-apps.md b/content/ru/cloud-native-apps.md new file mode 100644 index 0000000000..9da063d085 --- /dev/null +++ b/content/ru/cloud-native-apps.md @@ -0,0 +1,28 @@ +--- +title: Нативные облачные приложения +status: Completed +category: concept +tags: ["application", "fundamental", ""] +--- + +Нативные облачные (cloud native) приложения специально спроектированы для того, чтобы извлечь максимальную пользу из достижений в сфере [облачных вычислений](/cloud-computing/). +Такие приложения легко интегрируются с различными видами облачных архитектур, +используя облачные ресурсы и их способность к [масштабированию](/scalability/). +Также этот термин применяется и по отношению к приложениям, которые используют новейшие наработки в области инфраструктуры, вызванные развитием облачных вычислений. +К нативным облачным приложениям относят приложения, которые работают в центрах обработки данных облачных провайдеров и на локальных (on-premise) платформах, предназначенных для работы с облаками. + +## Какую проблему решает + +Традиционно локальные среды предоставляли уникальные, отличные друг от друга и несовместимые вычислительные ресурсы. +В каждом центре обработки данных имелись сервисы, которые [жестко привязывали](/tightly-coupled-architectures/) приложения к конкретным окружениям и чаще всего подразумевали, что инфраструктура (например, [виртуальные машины](/virtual-machine/) и различные сервисы) подготавливается вручную. +Из-за этого разработчики и их приложения зависели и были привязаны к конкретному центру обработки данных. +Приложения, которые не были специально разработаны для облачных сред, не могли полноценно задействовать преимущества облачных вычислений — отказоустойчивость и возможности по масштабированию. +Например, приложения, для корректного запуска которых требуется ручное вмешательство, не могут автоматически масштабироваться +и автоматически перезапускаться в случае сбоя. + +## Как именно решает проблему + +Хотя не существует универсального рецепта для создания нативных облачных приложений, у таких приложений все же есть некоторые общие черты. +Нативные облачные приложения обладают высокой отказоустойчивостью, ими удобно управлять, а кроме того, с ними может взаимодействовать целый набор сопутствующих облачных сервисов. +Так, различные облачные сервисы обеспечивают отличную [наблюдаемость](/observability/), позволяя обнаруживать и оперативно устранять проблемы еще до того, как они станут критическими. +А в сочетании с мощной автоматизацией такие сервисы дают инженерам возможность вносить в проект необходимые важные изменения регулярно, с высокой частотой и предсказуемо — причем без лишних хлопот. diff --git a/content/ru/cloud-native-security.md b/content/ru/cloud-native-security.md new file mode 100644 index 0000000000..e6561b0b47 --- /dev/null +++ b/content/ru/cloud-native-security.md @@ -0,0 +1,32 @@ +--- +title: Нативная облачная безопасность +status: Completed +category: concept +tags: ["security", "", ""] +--- + +Нативная облачная безопасность — подход, при котором безопасность встраивается в [нативные облачные приложения](/ru/cloud-native-apps/). +В его рамках безопасность становится частью всего жизненного цикла приложения: от разработки до production. +Нативная облачная безопасность сред направлена на обеспечение тех же стандартов, что и традиционные модели безопасности, +но при этом адаптирована к особенностям облачных окружений, +а именно: быстрым изменениям кода и крайне быстро изменяющейся инфраструктуре. +Нативная облачная безопасность тесно связана с практикой, известной как [DevSecOps](/ru/devsecops/). + +## Какую проблему решает + +Традиционные модели безопасности строились с учетом ряда допущений, которые больше не актуальны. +Нативные облачные приложения часто меняются, используют большое количество инструментов и библиотек с открытым исходным кодом, +работают в инфраструктуре, контролируемой вендором, и подвержены быстрым изменениям инфраструктуры. +Ревизии кода, длительные циклы обеспечения качества, сканирование уязвимостей на хостах +и проверки безопасности в самый последний момент не соответствуют потребностям нативных облачных приложений. + +## Как именно решает проблему + +Нативная облачная безопасность — новый подход к защите приложений, +предполагающий переход от традиционных моделей безопасности к таким, +в которых процессы обеспечения безопасности включены в каждый этап релизного цикла. +Ручные аудиты и проверки в значительной степени заменяются автоматизированным сканированием. +Пайплайны быстрого релиза кода интегрированы с инструментами, которые сканируют код на наличие уязвимостей до его компиляции. +Библиотеки с открытым исходным кодом берутся из надежных источников и отслеживаются на предмет наличия уязвимостей. +Вместо того чтобы замедлять изменения, модель нативной облачной безопасности способствует им, +постоянно обновляя уязвимые компоненты или следя за тем, чтобы инфраструктура регулярно обновлялась. diff --git a/content/ru/cloud-native-tech.md b/content/ru/cloud-native-tech.md new file mode 100644 index 0000000000..e5d96a9787 --- /dev/null +++ b/content/ru/cloud-native-tech.md @@ -0,0 +1,30 @@ +--- +title: Нативная облачная технология +status: Completed +category: Concept +tags: ["fundamental", "", ""] +--- + +Нативные облачные (cloud native) технологии, также называемые нативным облачным стеком, — +это технологии, которые используются для создания [нативных облачных приложений](/ru/cloud-native-apps/). +Эти технологии позволяют компаниям создавать и запускать масштабируемые приложения в современных и динамичных средах, +таких как публичные, приватные и гибридные облака, +максимально используя сильные стороны [облачных вычислений](/cloud-computing/). +Они изначально разрабатываются для максимального использования преимуществ облачных вычислений. Пример реализации такого подхода — контейнеры, service mesh, микросервисы и неизменяемая (immutable) инфраструктура. + +## Какую проблему решает + +Нативный облачный стек включает в себя множество различных технологий, призванных дать ответ на самые разные вызовы. +Если взглянуть на многообразие приложений в [CNCF Cloud Native Landscape](https://landscape.cncf.io/), +можно увидеть, как много различных областей они охватывают. +Но по сути они решают единый базовый набор задач — +устраняют недостатки традиционных моделей эксплуатации в ИТ. +Примеры таких вызовов: трудности создания масштабируемых, отказоустойчивых, способных восстанавливаться самостоятельно приложений, +неэффективное использование ресурсов и др. + +## Как именно решает проблему + +Хотя каждая технология решает свою специфическую задачу, +в совокупности нативный облачный стек позволяет создавать слабосвязанные системы, устойчивые к внешним воздействиям, с хорошей управляемостью и наблюдаемостью. +В сочетании с надежной автоматизацией они позволяют инженерам вносить серьезные изменения часто и с предсказуемым результатом — причем такой результат достигается минимальными усилиями. +Необходимых параметров при создании нативных облачных систем легче всего достичь именно с помощью соответствующего нативного облачного стека. diff --git a/content/ru/cluster.md b/content/ru/cluster.md new file mode 100644 index 0000000000..877424546b --- /dev/null +++ b/content/ru/cluster.md @@ -0,0 +1,26 @@ +--- +title: Кластер +status: Completed +category: Concept +tags: ["infrastructure", "fundamental", ""] +--- + +Кластер — группа компьютеров или приложений, которые объединены общей целью и работают совместно. +В контексте нативных облачных вычислений этот термин чаще всего применяется к [Kubernetes](/ru/kubernetes/). +Кластер Kubernetes — это набор сервисов (или рабочих нагрузок), каждый из которых выполняется в собственном контейнере (и обычно на разных машинах). +Совокупность всех этих [контейнеризованных](/ru/containerization/) сервисов, соединенных по сети, представляет собой кластер. + +## Какую проблему решает + +Программное обеспечение, работающее на одном компьютере, представляет собой единую точку отказа: +если этот компьютер сломается или кто-то случайно отключит его питание, +критически важная для бизнеса система может быть выведена из строя. +Именно поэтому современное программное обеспечение, как правило, строится в виде [распределенных приложений](/distributed-apps/), объединенных в кластеры. + +## Как именно решает проблему + +Распределенные приложения, объединенные в кластеры, работают на множестве вычислительных машин, что позволяет избежать появления единой точки отказа. +Однако создавать распределенные системы непросто. +На самом деле этим вопросам посвящена отдельная дисциплина в области компьютерных наук. +Потребность в глобальных системах и годы проб и ошибок привели к созданию нового типа технологического стека — [нативных облачных технологий](/ru/cloud-native-tech/). +Эти новые технологии выступают строительными блоками, которые облегчают эксплуатацию и упрощают создание распределенных систем. diff --git a/content/ru/container-image.md b/content/ru/container-image.md new file mode 100644 index 0000000000..4142003242 --- /dev/null +++ b/content/ru/container-image.md @@ -0,0 +1,27 @@ +--- +title: Образ контейнера +status: Feedback Appreciated +category: concept +tags: ["", "", ""] +--- + +Образ контейнера — это неизменяемый статический файл, содержащий зависимости, необходимые для создания [контейнера](/ru/container/). +Эти зависимости могут включать один исполняемый бинарный файл, +системные библиотеки, системные инструменты, переменные окружения и другие необходимые настройки и компоненты платформы. +Образы контейнеров создаются в ходе [контейнеризации](/ru/containerization/) приложения и обычно хранятся в реестрах контейнеров (container registry), +откуда их можно скачать и запустить в виде изолированного процесса с помощью интерфейса исполнения для контейнеров (Container Runtime Interface, CRI). +Фреймворк, с помощью которого создается образ контейнера, должен соответствовать стандарту, определенному Open Container Initiative (OCI). + +## Какую проблему решает + +Традиционно серверы настраиваются под конкретное окружение, и затем на них развертываются приложения. +Любое несоответствие конфигурации окружений — большая проблема, которая часто приводит к простоям или неудачным развертываниям. +Окружение приложения должно быть повторяемым и строго определенным, +в противном случае возрастает вероятность возникновения ошибок, связанных с окружением. +Если окружение настроено с ошибками или не должным образом, [горизонтальное](/horizontal-scaling/) и [вертикальное](/vertical-scaling/) масштабирование приложений становится проблематичным. + +## Как именно решает проблему + +Образы контейнеров содержат приложение со всеми его runtime-зависимостями, например, с сервером приложения. +Это позволяет добиться повторяемости и воспроизводимости в любых окружениях, включая компьютер разработчика. +Образы контейнеров могут использоваться для запуска необходимого количества контейнеров, что облегчает [масштабирование](/scalability/). diff --git a/content/ru/container-orchestration.md b/content/ru/container-orchestration.md new file mode 100644 index 0000000000..1a2bdf0b37 --- /dev/null +++ b/content/ru/container-orchestration.md @@ -0,0 +1,23 @@ +--- +title: Оркестрация контейнеров +status: Completed +category: Concept +--- + +Под оркестрацией [контейнеров](/ru/container/) понимается автоматизация жизненного цикла контейнеризованных приложений в динамических средах и управление им. +Она осуществляется с помощью оркестратора контейнеров (чаще всего — [Kubernetes](/ru/kubernetes)), который отвечает за развертывание, (авто)масштабирование, автовосстановление и мониторинг. +Оркестрация — это метафора: +инструмент оркестрации управляет контейнерами так же, как дирижер — музыкой, следя за тем, чтобы каждый контейнер (музыкант) делал то, что должен. + +## Какую проблему решает + +Вручную управлять [микросервисами](/microservices), обеспечивать безопасность и контролировать сетевое взаимодействие на больших масштабах (как и вообще управлять [распределенными системами](/distributed-systems)) +сложно, а подчас и невозможно. +Оркестрация контейнеров позволяет автоматизировать задачи по управлению ими. + +## Как именно решает проблему + +Инструменты для оркестрации контейнеров позволяют пользователям задавать состояние системы. +На начальном этапе они определяют, как система должна выглядеть (например, X контейнеров, Y подов и т. д.). +Затем инструмент оркестрации начинает автоматически отслеживать состояние инфраструктуры и при возникновении отклонений приводить его к описанному на первом этапе состонию (например, при сбое одного контейнера запускается другой). +Такая автоматизация упрощает выполнение многих сложных задач эксплуатации (которые в противном случае выполнялись бы вручную), включая выделение ресурсов, развертывание, масштабирование (вверх и вниз), работу с сетью, балансировку нагрузки и другие действия. diff --git a/content/ru/container.md b/content/ru/container.md new file mode 100644 index 0000000000..f02f3bfabd --- /dev/null +++ b/content/ru/container.md @@ -0,0 +1,32 @@ +--- +title: Контейнер +status: Completed +category: technology +tags: ["application", "fundamental", ""] +--- + +Контейнер — это запущенный процесс, работающий под управлением операционной системы компьютера, ограниченный в ресурсах и возможностях. +Файлы, доступные такому процессу, упаковываются в так называемый образ контейнера. +Контейнеры работают рядом друг с другом на одной и той же машине, +при этом операционная система, как правило, не позволяет контейнерам напрямую взаимодействовать. + +## Какую проблему решает + +До появления контейнеров для запуска приложений требовались отдельные машины. +На каждой машине устанавливалась операционная система, которая потребляла ресурсы процессора и памяти, а также дисковое пространство +— и все это для работы одного единственного приложения. +Кроме того, приходилось тратить значительные ресурсы на обслуживание, обновление и запуск самой операционной системы. + +## Как именно решает проблему + +Контейнеры совместно используют одну и ту же операционную систему и работающее под ее управлением железо. +Другими словами, вместо множества копий ОС используется лишь одна: +ресурсы, потребляемые операционной системой, делятся сразу на множество контейнеров. +Тем самым обеспечивается эффективное использование памяти, процессора и дискового пространства. +Такая совместная работа контейнеров возможна только потому, что они, как правило, не могут напрямую взаимодействовать. +Это позволяет запускать на одной физической машине гораздо больше приложений. + +Однако есть и ограничения. +Подход, когда множество контейнеров используют одну и ту же операционную систему, потенциально более опасен, чем другие варианты. +Кроме того, контейнерам необходимо задавать ограничения на использование общих ресурсов. +Администратор должен ограничивать использование памяти и процессора — это позволяет гарантировать, что остальные приложения не столкнутся с нехваткой ресурсов. diff --git a/content/ru/containerization.md b/content/ru/containerization.md new file mode 100644 index 0000000000..699ee38fd9 --- /dev/null +++ b/content/ru/containerization.md @@ -0,0 +1,28 @@ +--- +title: Контейнеризация +status: Completed +category: Technology +tags: ["application", "", ""] +--- + +Контейнеризация — это упаковка приложения и всех необходимых зависимостей в [образ контейнера](/container-image/). +Процесс сборки контейнера должен соответствовать стандарту [Open Container Initiative](https://opencontainers.org) (OCI). +Если на выходе получается образ контейнера, соответствующий этому стандарту, то не важно, какое именно средство контейнеризации использовалось. + +## Какую проблему решает + +До того как контейнеры получили широкое распространение, для запуска множества приложений на одном [«железном»](/bare-metal-machine/) (bare-metal) сервере использовались виртуальные машины. +Однако виртуальные машины гораздо «тяжелее» контейнеров, и для их работы необходим гипервизор. +Создание шаблонизированных решений на базе виртуальных машин затруднено необходимостью хранения, резервного копирования и передачи больших объемов данных. +Кроме того, одна из болей виртуальных машин — появляющиеся со временем изменения в конфигурации, которые нарушают принцип [неизменяемости](/immutable-infrastructure/). + +## Как именно решает проблему + +От традиционных виртуальных машин образы контейнеров отличаются гораздо меньшими размерами, +а для самого процесса контейнеризации нужен только файл со списком зависимостей. +Изменения в этом файле можно отслеживать в системе контроля версий, а процесс сборки — автоматизировать, +что позволяет организации сосредоточиться на других важных задачах. +У каждого образа контейнера есть уникальный идентификатор, +привязанный к его содержимому и конфигурации. +При планировании (размещении на узлы) и перепланировании контейнеры всегда +сбрасываются до исходного состояния, что исключает расхождения в конфигурации. diff --git a/content/ru/continuous-delivery.md b/content/ru/continuous-delivery.md new file mode 100644 index 0000000000..0294520efb --- /dev/null +++ b/content/ru/continuous-delivery.md @@ -0,0 +1,36 @@ +--- +title: Непрерывная доставка (CD) +status: Completed +category: concept +tags: ["methodology", "application", ""] +--- + +Непрерывная доставка (Continuous Delivery), часто сокращенно называемая CD, — это набор практик, +при которых изменения кода автоматически развертываются в приемочное окружение +— или, в случае непрерывного развертывания, в production. +CD обязательно включает процедуры, обеспечивающие адекватное тестирование программного обеспечения +перед развертыванием, и предоставляет возможность отката изменений при необходимости. +Непрерывная интеграция — первый шаг на пути к непрерывной доставке: +т.е. сначала должен успешно завершиться процесс внесения изменений (merging), и только после этого можно переходить к тестированию и развертыванию. + +## Какую проблему решает + +Развертывание [надежных](/reliability/) обновлений становится глобальной проблемой. +В идеале частота развертываний должна быть высокой — так востребованные функции будут быстрее попадать к конечным пользователям. +Однако выполнение этих операций вручную влечет значительные трудозатраты при каждом изменении. +Исторически сложилось так, что для того, чтобы избежать этих трудозатрат, организации выпускали новые релизы реже, +проводя больше изменений за один раз. В результате увеличивался риск того, что что-то пойдет не так. + +## Как именно решает проблему + +Стратегии CD позволяют выстроить полностью автоматизированный путь до стадии production, +в рамках которого ПО тестируется и развертывается с использованием различных методов развертывания, +таких как [канареечные](/canary-deployment/) или [сине-зеленые](/blue-green-deployment/) релизы. +Это позволяет разработчикам развертывать код с высокой частотой и быть уверенными в том, что новая ревизия прошла все этапы тестирование. +Как правило, в стратегиях CD используется trunk-based-разработка, при которой в основную ветку постоянно вносятся небольшие изменения кода +(в отличие от запросов на слияние (pull requests) и фич-веток (feature branching)). + +## Связанные термины + +* [Непрерывная интеграция](/ru/continuous-integration/) +* [Непрерывное развертывание](/ru/continuous-deployment/) diff --git a/content/ru/continuous-deployment.md b/content/ru/continuous-deployment.md new file mode 100644 index 0000000000..8f41995897 --- /dev/null +++ b/content/ru/continuous-deployment.md @@ -0,0 +1,33 @@ +--- +title: Непрерывное развертывание (CD) +status: Completed +category: concept +tags: ["application", "methodology", ""] +--- + +Непрерывное развертывание (Continuous Deployment, CD) развивает идеи [непрерывной доставки](/ru/continuous-delivery/), +позволяя выкладывать готовое программное обеспечение непосредственно в production. +Непрерывное развертывание (CD) идет рука об руку с [непрерывной интеграцией](/ru/continuous-integration/) (CI), поэтому обычно их объединяют в единый процесс CI/CD. +CI помогает убедиться, что изменения, внесенные в код приложения, работают как и было задумано, +а CD автоматически развертывает приложение в целевые окружения (от тестовых до production). + +## Какую проблему решает + +Выпуск новых версий программного обеспечения может быть трудоемким процессом и сопровождаться ошибками. +Поэтому многие организации стараются уменьшить количество релизов, чтобы избежать инцидентов в production +и сократить время, в течение которого инженеры должны оставаться на связи (в т. ч. в нерабочие часы). +Традиционные модели развертывания программного обеспечения приводят к тому, что организации попадают в порочный круг, +в котором процесс выпуска программного обеспечения не отвечает потребностям организации +ни в контексте стабильности, ни в контексте скорости реализации новых функций. + +## Как именно решает проблему + +Автоматизируя релизный цикл и заставляя организации чаще развертывать ПО в production, +CD делает для команд эксплуатации то же самое, что CI для команд разработки. +То есть автоматизирует этапы развертывания ПО в production, сокращая вероятность ошибок и негативных последствий и снижая общий риск. +Кроме того, организации привыкают к частым изменениям в production и лучше к ним адаптируются, что повышает стабильность. + +## Связанные термины + +* [Непрерывная интеграция](/ru/continuous-integration/) +* [Непрерывная доставка](/ru/continuous-delivery/) diff --git a/content/ru/continuous-integration.md b/content/ru/continuous-integration.md new file mode 100644 index 0000000000..a77a1ece63 --- /dev/null +++ b/content/ru/continuous-integration.md @@ -0,0 +1,31 @@ +--- +title: Непрерывная интеграция (CI) +status: Completed +category: concept +tags: ["application", "methodology", ""] +--- + +Непрерывная интеграция (Continuous Integration, CI) — это практика, при которой правки внедряются в код как можно чаще. +CI является предварительным условием для [непрерывной доставки](/ru/continuous-delivery/) (CD). +Процесс CI традиционно начинается с внесения правок в код в системе контроля исходного кода (Git, Mercurial или Subversion) +и заканчивается получением протестированной сборки, готовой к использованию CD-системой. + +## Какую проблему решает + +Программные системы часто бывают большими и сложными, их поддерживает и обновляет множество разработчиков. +Работая параллельно над разными частями системы, +эти разработчики могут вносить такие изменения, которые будут приводить к конфликтам, и непреднамеренно «портить» работу смежных команд. +Кроме того, если над одним проектом работает несколько разработчиков, то все рутинные задачи, +такие как тестирование и оценка качества кода, приходится повторять каждому из них. А это ведет к потере времени. + +## Как именно решает проблему + +Программное обеспечение для CI автоматически следит за тем, чтобы изменения, которые вносятся в код, сразу и четко интегрировались в него после каждого коммита, сделанного разработчиком. +Использование CI-сервера для проверки качества кода, запуска тестов и даже развертывания является довольно распространенной практикой. +Таким образом, CI-сервер становится одиним из неотъемлемых инструментов для контроля качества в командах разработчиков. +CI позволяет командам разработчиков перевести каждый коммит либо к отклоненным коммитам, либо к готовым кандидатам на релиз. + +## Связанные термины + +* [Непрерывная доставка](/ru/continuous-delivery/) +* [Непрерывное развертывание](/ru/continuous-deployment/) diff --git a/content/ru/contribute/_index.md b/content/ru/contribute/_index.md new file mode 100644 index 0000000000..426aef5787 --- /dev/null +++ b/content/ru/contribute/_index.md @@ -0,0 +1,225 @@ +--- +title: Как внести свой вклад +toc_hide: true +status: Completed +menu: + main: + weight: 10 +--- + +## Добро пожаловать + +Добро пожаловать в руководство по работе над Глоссарием Cloud Native. Благодарим за проявленный интерес! +Поучаствовать в развитии проекта можно разными способами: + +1) [Поработать над существующим Issue](#work-on-an-existing-issue) +2) [Предложить новое определение](#propose-new-terms) +3) [Дополнить существующее определение](#update-an-existing-term) +4) [Локализовать глоссарий](#help-localize-the-glossary) + +## Общие сведения о глоссарии CNCF + +Цель этого глоссария — упростить знакомство с нативными облачными (cloud native) технологиями, которые печально известны своей сложностью и запутанностью, и сделать их более доступными для пользователей. + +Материалы Глоссария Cloud Native хранятся в [репозитории на GitHub](https://github.com/cncf/glossary). +В нем вы найдете список [Issues](https://github.com/cncf/glossary/issues), Pull Request'ов ([PRs](https://github.com/cncf/glossary/pulls)) и +[обсуждений](https://github.com/cncf/glossary/discussions), касающихся глоссария. + +## Кто может внести свой вклад? + +Ваш конкретное участие в этом проекте определяется компетенцией в области cloud native-технологий. +Упрощение сложных понятий требует глубоких познаний по теме. +Поэтому, чтобы добавлять новые термины, вы должны прекрасно в них разбираться. +Обычно авторами выступают инженеры, которые работали с облачными технологиями и хорошо их знают, или представители научного сообщества, специализирующиеся на нативных облачных технологиях. + +Богатый опыт просто необходим, потому что объяснить сложные понятия доступным языком бывает _очень_ непросто. Может показаться, что создать простое и понятное определение достаточно легко. На самом деле это не так: конечная простота является результатом напряженной работы и сотрудничества многих экспертов по cloud native-технологиям. + +Если вы не специалист, но все же хотите помочь, рекомендуем объединиться с кем-то из экспертов. +Как только он убедится, что определение хорошо раскрывает концепцию, можно переходить к непосредственной работе с файлами глоссария. + +Чтобы внести свой вклад в глоссарий, необязательно иметь энциклопедические знания в какой-либо из областей. +При наличии подготовленных экспертами определений на английском языке от локализаторов требуется лишь уверенное владение английским и родным языком. Можно присоединиться к существующей команде локализации или создать новую. Чтобы узнать, с чего начать, ознакомьтесь с разделом [Помощь в локализации глоссария](#help-localize-the-glossary) этого руководства. + +## Перед началом работы + +Перед началом работы обязательно выполните следующие шаги: + +1. Создайте [учетную запись на GitHub'е](https://docs.github.com/en/get-started/signing-up-for-github/signing-up-for-a-new-github-account), если у вас ее еще нет. +2. Подпишите [Лицензионное соглашение с контрибьютором (Contributor License Agreement)](https://docs.linuxfoundation.org/lfx/easycla/v2-current/contributors) (CLA). +3. Проверьте [подпись к коммитам](https://docs.github.com/en/authentication/managing-commit-signature-verification/about-commit-signature-verification). +4. Включите [режим vigilant](https://docs.github.com/en/authentication/managing-commit-signature-verification/displaying-verification-statuses-for-all-of-your-commits#about-vigilant-mode) в GitHub-аккаунте: ваши коммиты будут помечаться статусом `Verified`. + +## Лучшие практики {#best-practices} + +Чтобы облегчить рецензирование, используйте [смысловой перенос строк](https://sembr.org/) (одна строка на предложение). +Рекомендуем ознакомиться со [шпаргалкой по Markdown](https://www.markdownguide.org/cheat-sheet/), чтобы правильно форматировать md-текст на GitHub'е (например, [гиперссылка](#best-practices), **жирный шрифт**, *курсив*). +При именовании файлов .md используйте строчные буквы, дефисы вместо пробелов для разделения слов и избегайте скобок. + +## Руководство по стилю + +[Руководство по стилю](/ru/style-guide/) содержит требования к форматированию и содержанию документов, а также советы о том, как повысить эффективность работы. + +## Присоединяйтесь к сообществу Глоссария! {#join-the-glossary-community} + +Регулярным контрибьюторам рекомендуем присоединиться к Рабочей группе по глоссарию (ее заседания проходят ежемесячно). +График встреч можно найти в [календаре CNCF](https://www.cncf.io/calendar/). +Также можно пообщаться с хранителями и соавторами в Slack-канале CNCF [#glossary](https://cloud-native.slack.com/archives/C02TX20MQBB) +— мы будем рады знакомству с вами! + +## Работа над существующим Issue {#work-on-an-existing-issue} + +Список открытых Issues можно найти в [репозитории глоссария на GitHub'е](https://github.com/cncf/glossary/issues). +Отфильтровать их можно с помощью лейблов (например, English language, help needed, good first issue). + +![Issue и лейблы](/images/how-to/issue-and-labels.png) + +Убедитесь, что выбранный вами термин ни за кем не закреплен. +Например, на скриншоте ниже первые три термина доступны, в то время как четвертый закреплен за автором. + +![Термин занят](/images/how-to/howto-04.png) + +Выбрав термин, отпишитесь в его Issue: + +![Закрепление Issue](/images/how-to/claiming-an-issue.png) + +Сообщите хранителям в канале [#glossary](https://cloud-native.slack.com/archives/C02TX20MQBB) в рабочем пространстве CNCF в Slack, +призвав _@iamnoah_, _@nate-double-u_, _@Seokho Son_, _@Jihoon Seo_ и/или _@castrojo_, чтобы они наверняка увидели ваше уведомление. + +Дальнейшие шаги описаны в разделе [Создание нового термина (открываем PR)](#submitting-a-new-term). + +**Примечание**: работу над Issue можно начинать после того, как хранители закрепят его за вами. +Можно работать только над одним термином за раз. +Работа ведется последовательно: завершаете один, после чего переходите к следующему. + +## Предложить новый термин {#propose-new-terms} + +Можно предложить новый термин и дождаться, пока другие авторы сформулируют для него определение, или написать определение самостоятельно. +В любом случае начать следует с [создания Issue](#creating-an-issue). +Чтобы претендовать на добавление в глоссарий, каждый новый термин должен отвечать [определению для cloud native-терминов, сформулированному CNCF](https://github.com/cncf/toc/blob/main/DEFINITION.md). +Единственным исключением являются фундаментальные термины, необходимые для описания базовых концепций cloud native-технологий. + +Ниже приведено пошаговое руководство для тех, кто не знаком с GitHub'ом. +**Опытным пользователям GitHub'а** также _рекомендуем_ ознакомиться с ним, чтобы получить общее представление о том: + +1. Как и где искать шаблоны для Issues и новых терминов. +2. Как закрепить Issue за собой. +3. Как решать проблемы с [проверкой орфографии](#spell-check) failures. + +### Как создать Issue {#creating-an-issue} + +Перейдите в [репозиторий глоссария на GitHub'е](https://github.com/cncf/glossary/issues) и нажмите "New issue". + +![Список Issues](/images/how-to/howto-01.png) + +Выберите "Request to add a new term (English)" (Запрос на добавление нового термина на английском языке) из списка шаблонов. + +**Примечание**: пока новые термины принимаются только на английском языке. +Если у вас есть идея для нового определения, но вы затрудняетесь переложить ее на английский язык, +свяжитесь с хранителями русской версии в канале [#glossary-localization-russian](https://cloud-native.slack.com/archives/C05G46RMQTX) — мы поможем. + +![Шаблоны](/images/how-to/english-issue-template.jpg) + +Добавьте свой термин, ответьте на вопросы, поставьте галочки и нажмите "Submit new issue". +Если вы просто предлагаете новый термин, больше ничего делать не нужно. Если вы хотите поработать над определением, продолжайте читать. + +### Триаж Issue {#triaging-your-issue} + +Далее хранители проведут триаж Issue. +А именно, решат, стоит ли включать термин в глоссарий. +Принимаются далеко не все термины: чтобы попасть в глоссарий, они должны устояться в мире cloud native-технологий и широко там использоваться. + +Сообщите хранителям в Slack'е о новом термине (позовите _@iamnoah_, _@nate-double-u_, _@Seokho Son_, _@Jihoon Seo_ и/или _@castrojo_). +Если вы хотите поработать над определением, сообщите об этом хранителям, и они закрепят термин за вами. + +### Отправка нового термина (создаем PR) {#submitting-a-new-term} + +Как указано в [Руководстве по стилю](/ru/style-guide/), настоятельно рекомендуется начинать с документа в Google или в Word. + +Когда термин будет готов к отправке, перейдите в директорию content (на вкладке <>code)… + +![Директория "content"](/images/how-to/howto-05.png) + +…затем в "en" (для английского языка) или в директорию языка локализации… + +![Директория с языками](/images/how-to/howto-06.png) + +…и выберите `_TEMPLATE.md` + +![Template](/images/how-to/howto-07.png) + +Скопируйте его содержимое…… + +![Копировать содержимое](/images/how-to/howto-08.png) + +…и вернитесь в папку "en" или языка локализации. Нажмите "Add file" и выберите "Create new file". + +![Создать новый файл](/images/how-to/howto-09.png) + +Включите название термина в URL, как описано в разделе [Лучшие практики](#best-practices). +Добавьте к нему расширение .md (без этого расширения будет невозможно предварительно просмотреть файл). +Теперь вставьте шаблон в поле с содержимым файла. Скопируйте и вставьте текст определения в файл. +Чтобы проверить markdown-код на соответствие требованиям из раздела [Лучшие практики](#best-practices), нажмите "Preview". + +![Завершение работы с термином](/images/how-to/howto-10.png) + +Прокрутите вниз и введите описание коммита. Затем нажмите "Commit new file" и… + +![Делаем коммит](/images/how-to/howto-11.png) + +…перейдите к созданию PR'а. Добавьте его описание и нажмите на "Create pull request": + +![Создаем PR](/images/how-to/howto-12.png) + +После этого PR должен появиться на вкладке "Pull requests". + +![Вкладка "Pull requests"](/images/how-to/howto-13.png) + +## Изменение существующего термина {#update-an-existing-term} + +Чтобы отредактировать существующий термин, можно создать Issue и описать в нем желаемые изменения, +либо внести правки самостоятельно и оформить их в виде PR'а. + +### Запросить изменения с помощью Issue {#request-a-change-via-an-issue} + +Чтобы сообщить о проблеме с термином, можно воспользоваться опцией "Сообщить о проблеме" на странице Глоссария CNCF. +Перейдите на страницу с соответствующим термином и нажмите "Сообщить о проблеме". +Автоматически откроется форма для создания Issue: + +![Сообщить о проблеме](/images/how-to/howto-14.png) + +Опишите свои предложения и объясните, почему они необходимы. Нажмите "Submit new issue". + +![Открыть Issue](/images/how-to/howto-15.png) + +### Изменить термин напрямую {#update-a-term-directly} + +Чтобы изменить термин и внести свои предложения, нажмите "Редактировать страницу". + +![Редактировать страницу](/images/how-to/howto-16.png) + +Откроется страница термина на GitHub'е. Внесите свои правки и создайте PR. +Обратитесь к разделу [Лучшие практики](#best-practices) выше и ознакомьтесь с [Руководством по стилю](/ru/style-guide/), чтобы убедиться, что следуете рекомендациям. + +## Помощь в локализации глоссария {#help-localize-the-glossary} + +Чтобы помочь в локализации глоссария на целевой язык, присоединитесь к каналу [#glossary-localizations](https://cloud-native.slack.com/archives/C02N2RGFXDF) в рабочем пространстве CNCF в Slack'е и дайте нам знать. +Можно войти в существующую команду или создать новую (чтобы узнать, что для этого нужно, прочитайте [Руководство по локализации](https://github.com/cncf/glossary/blob/main/LOCALIZATION.md)). +Пожалуйста, ознакомьтесь с руководством [Как внести свой вклад](/ru/contribute/) на целевом языке, чтобы узнать об особенностях работы соответствующей команды. + +## Проверка орфографии {#spell-check} + +Проверка орфографии может завершиться неудачей по двум основным причинам: + +- PR содержит орфографические ошибки. +- PR содержит слова, которые не зарегистрированы в списке слов. + +Чтобы добавить новые слова в список, выполните следующие действия: + +1. В вашем PR найдите файл "wordlist.txt". +2. Нажмите "Отредактировать этот файл" ("Edit this file") и добавьте недостающие слова в алфавитном порядке. +3. Добавьте сообщение коммита и выберите "Подписать и предложить изменения" ("Sign off and propose changes"). + +**Примечание**: при проверке орфографии регистр (строчные/прописные буквы) во внимание не принимается. + + +**Это руководство было обновлено на основе шаблонов из проекта [The Good Docs Project](https://thegooddocsproject.dev/).** diff --git a/content/ru/devops.md b/content/ru/devops.md new file mode 100644 index 0000000000..272ce4333f --- /dev/null +++ b/content/ru/devops.md @@ -0,0 +1,32 @@ +--- +title: DevOps +status: Completed +category: concept +tags: ["methodology", "", ""] +--- + +DevOps — это методология, в рамках которой команды отвечают за весь процесс от разработки приложения (**DEV**elopment) +его эксплуатации (**OP**eration**S**) в production. Отсюда и название DevOps. +Методология DevOps выходит за рамки внедрения набора технологий и требует полного пересмотра культуры и процессов. +DevOps предполагает наличие групп инженеров, которые работают над небольшими независимыми компонентами, а не над крупным функциональным блоком, в котором такие компоненты были бы тесно связаны, +позволяя сократить случаи передачи ответственности за компонент от одной команды к другой — а это нередко влечет за собой появление ошибок. + +## Какую проблему решает + +Традиционно в крупных организациях с [тесно связанными](/tightly-coupled-architectures/) [монолитными приложениями](/monolithic-apps/) +работа, как правило, была разделена между несколькими группами. +Это приводило к необходимости часто передавать задачи друг другу и длительным срокам выполнения работ. +Каждый раз, когда компонент или обновление были готовы, они помещались в бэклог следующей команды. +Поскольку каждый инженер работал только над небольшой частью проекта, было сложно сказать, кто и за что отвечает. +В итоге каждая команда стремилась просто выполнить свою часть работы и передать проект следующей команде, а не реализовать функции, необходимые заказчику (или пользователю) — +то есть наблюдался явный конфликт приоритетов. + +К тому времени, когда код, наконец, попадал в production, он проходил через такое количество разработчиков и команд, +что при возникновении любой проблемы было крайне трудно отследить ее источник. +DevOps кардинально изменил этот подход. + +## Как именно решает проблему + +Когда одна команда отвечает за весь жизненный цикл приложения, это позволяет свести к минимуму необходимость передавать ответственность от одной команды к другой, +снизить риски при развертывании в production и повысить качество кода (поскольку команды также отвечают за его работу в production). +Кроме того, растет общая удовлетворенность сотрудников от работы, поскольку они ощущают себя более самостоятельными и видят свое влияние на проект и ответственность за общий результат. diff --git a/content/ru/devsecops.md b/content/ru/devsecops.md new file mode 100644 index 0000000000..b7d0286023 --- /dev/null +++ b/content/ru/devsecops.md @@ -0,0 +1,28 @@ +--- +title: DevSecOps +status: Completed +category: concept +tags: ["methodology", "security", ""] +--- + +Термин DevSecOps означает слияние компетенций в области разработки (**DEV**elopment), безопасности (**SEC**urity) и эксплуатации (**OP**eration**S**) на уровне культуры. +Он добавляет в подход [DevOps](/ru/devops/) приоритеты в области безопасности — причем так, +чтобы минимально вмешиваться в процессы разработки и эксплуатации. +Как и DevOps, DevSecOps — это некий культурный сдвиг, который форсируется как самим фактом внедрения новых технологий, так и специфическими методами их внедрения. + +## Какую проблему решает + +Практики DevOps включают [непрерывную интеграцию](/ru/continuous-integration/) и [непрерывное развертывание](/ru/continuous-deployment/). +Кроме того, они ускоряют цикл разработки и релизный цикл приложений. +К сожалению, если автоматизация релизов не учитывает интересы всех заинтересованных сторон (стейкхолдеров) внутри организации, она может усугубить существующие проблемы. +А быстрый выпуск нового программного обеспечения без учета требований безопасности может усугубить проблемы с безопасностью на уровне всей компании. + +## Как именно решает проблему + +DevSecOps фокусируется на устранении командной разобщенности и способствует созданию безопасных автоматизированных рабочих процессов. +При выборе приложений для обеспечения безопасности организации должны использовать преимущества +автоматизированных процессов CI/CD и контроля за соблюдением политик, которые расширяют возможности, полномочия и статус разработчиков. +Цель практик DevSecOps — не блокировать работу инженеров, а обеспечивать следование политикам безопасности, +в то же время предоставляя техническим командам точную и подробную информацию о том, как правильно развивать проект. +При правильном внедрении организация получает более эффективное взаимодействие в коллективе, +снижает количество инцидентов, связанных с безопасностью, и вызванные ими расходы. diff --git a/content/ru/ebpf.md b/content/ru/ebpf.md new file mode 100644 index 0000000000..5c9e696631 --- /dev/null +++ b/content/ru/ebpf.md @@ -0,0 +1,44 @@ +--- +title: eBPF +status: Completed +category: Technology +tags: ["architecture", "networking", "security"] +--- + +Технология eBPF (англ. extended Berkley Packet Filter — расширенный фильтр пакетов Беркли) +позволяет небольшим программам или скриптам запускаться в пространстве ядра ОС Linux +без необходимости изменять код ядра или загружать модули ядра. + +В ОС Linux есть два пространства: пространство ядра (kernel space) и пространство пользователя (user space). +Ядро представляет основу операционной системы и имеет неограниченный доступ к аппаратному обеспечению. + +Приложения находятся в пространстве пользователя. +Когда возникает необходимость в привилегированном доступе, приложения отправляют запрос к ядру. +Для приложений, требующих большей свободы действий, например, прямого доступа к аппаратному обеспечению, +ядро может быть расширено за счёт модулей ядра Linux. +Такой подход расширяет функциональность ядра, доступную по умолчанию, открывая приложениям доступ к более низкоуровневым компонентам. +Однако расширение ядра с помощью модулей влечет за собой риски и потенциально снижает безопасность, что делает eBPF привлекательной альтернативой. + +## Какую проблему решает + +Как правило, приложения работают в пространстве пользователя. +Если возникает необходимость в привилегированном доступе (например, к аппаратному обеспечению), +приложение отправляет запрос к ядру. такой запрос называется «системный вызов». +В большинстве случает такой подход прекрасно работает. +Однако бывают ситуации, когда разработчики нуждаются в более низкоуровневом доступе к системе. +Такие ситуации, как правило, связаны с наблюдаемостью (observability), безопасностью и работой с сетью. +Использование модулей ядра Linux позволяет решить вышеупомянутую проблему без изменения исходного кода ядра. +К сожалению, у этого подхода есть не только плюсы, но и минусы (в первую очередь, связанные с безопасностью). +Модули ядра работают в пространстве ядра. Это означает, что сбой модуля неминуемо приводит к сбою ядра и, как следствие, падению всей системы. +Кроме того, модули ядра наделены повышенными привилегиями и имеют прямой доступ к системным ресурсам. Если не обеспечить должную защиту, этими свойствами модулей могут воспользоваться злоумышленники. + +## Как именно решает проблему + +В отличие от модулей ядра, eBPF позволяет запускать пользовательские программы в более контролируемой и ограниченной среде. +eBPF-программа работает в «песочнице» внутри ядра. Тем самым обеспечивается необходимая изоляция и снижаются риски. +Даже если в eBPF-программе обнаружится уязвимость или какой-то изъян, их воздействие ограничится «песочницей». +Более того, прежде чем программа сможет запуститься внутри ядра, она должна пройти процесс верификации. +Верификатор проверяет eBPF-программу на наличие потенциально небезопасного кода: например, доступ к памяти за пределами выделенного буфера, бесконечные циклы и неавторизованный доступ к функциям ядра. +Верификация гарантирует, что eBPF-программа не войдет в бесконечный цикл и не приведет к сбою ядра. +Такие меры безопасности делают eBPF более надежным вариантом запуска приложений в ядре по сравнению с модулями ядра Linux. + diff --git a/content/ru/kubernetes.md b/content/ru/kubernetes.md new file mode 100644 index 0000000000..b6d1f3c034 --- /dev/null +++ b/content/ru/kubernetes.md @@ -0,0 +1,36 @@ +--- +title: Kubernetes +status: Completed +category: technology +tags: ["infrastructure", "fundamental", ""] +--- + +Kubernetes (часто сокращается до K8s) — это система для управления контейнерами (т. н. оркестратор) с открытым исходным кодом. +Kubernetes автоматизирует жизненный цикл контейнеризированных приложений в современных инфраструктурах, выступая в качестве «операционной системы для центров обработки данных», которая управляет приложениями в [распределенных системах](/distributed-systems/). + +Kubernetes планирует (т. е. распределяет) [контейнеры](/ru/container/) по [узлам](/nodes/) [кластера](/cluster/), попутно обеспечивая их различными инфраструктурными ресурсами: например, балансировщиками нагрузки, постоянным хранилищем и т. д., которые необходимы для запуска контейнеризованных приложений. + +Kubernetes также обеспечивает автоматизацию и расширяемость, позволяя пользователям использовать декларативность (см. ниже) и обеспечивать воспроизводимость в процессе развертывания приложений. +[API](/application-programming-interface/) Kubernetes позволяет опытным пользователям расширять и дополнять его возможности по автоматизации в соответствии со своими потребностями. + +## Какую проблему решает + +Автоматизация инфраструктуры и декларативное управление конфигурацией уже давно занимают важное место в IT, но с ростом популярности [облачных вычислений](/cloud-computing/) их актуальность возросла еще сильнее. + +Спрос на вычислительные ресурсы постоянно увеличивается, а компании стараются сделать труд инженеров максимально эффективным, чтобы оптимизировать ФОТ. Новые технологии и методы работы как раз призваны удовлетворить обе эти потребности. + +## Как именно решает проблему + +Как и традиционные инструменты или подходы, например, [инфраструктура как код (IaC)](/infrastructure-as-code/), Kubernetes помогает автоматизировать процессы, но у него есть и серьезное преимущество перед ними — использование контейнеров. + +Контейнеры более устойчивы к накапливающимся со временем изменениям в конфигурации, нежели [виртуальные](/virtual-machine/) или физические машины. + +Кроме того, Kubernetes работает декларативно, то есть пользователь не указывает компьютеру, что и как нужно сделать, а лишь описывает желаемое конечное состояние инфраструктуры (обычно в виде файлов-манифестов на языке YAML). +Все остальное Kubernetes берет на себя. +Таким образом, Kubernetes в высшей степени совместим с подходом «инфраструктура как код». + +В Kubernetes также встроена функция [самовосстановления](/self-healing/). + +Фактическое состояние кластера всегда стремится к тому состоянию, которое описал оператор. +Когда Kubernetes обнаруживает отклонение от файлов манифеста, в дело вступает контроллер Kubernetes, который устраняет это отклонение. +Инфраструктура, с которой работает Kubernetes, может в любой момент измениться, однако оркестратор постоянно и автоматически адаптируется к изменениям, следя за тем, чтобы фактическое состояние кластера всегда соответствовало желаемому состоянию. diff --git a/content/ru/style-guide/_index.md b/content/ru/style-guide/_index.md new file mode 100644 index 0000000000..38e6e580ed --- /dev/null +++ b/content/ru/style-guide/_index.md @@ -0,0 +1,191 @@ +--- +title: Руководство по стилю +toc_hide: true +status: Completed +menu: + main: + weight: 10 +--- + +Это руководство по стилю поможет вам разобраться в целевой аудитории глоссария, структуре определений, стиле и требуемом уровне детализации. + +Глоссарий Cloud Native придерживается [стандартного руководства по стилю репозитория CNCF](https://github.com/cncf/foundation/blob/master/style-guide.md). +Кроме того, он следует перечисленным ниже правилам: + +1. Используйте простой, доступный язык; избегайте технического жаргона и «модных» словечек. +2. [Избегайте разговорного стиля](https://ru.wikipedia.org/wiki/%D0%A0%D0%B0%D0%B7%D0%B3%D0%BE%D0%B2%D0%BE%D1%80%D0%BD%D1%8B%D0%B9_%D1%81%D1%82%D0%B8%D0%BB%D1%8C). +3. [Повествование должно быть последовательным и конкретным](https://guidetogrammar.org/grammar/composition/abstract.htm). +4. [Избегайте сокращений](https://ru.wikipedia.org/wiki/%D0%A1%D1%82%D1%8F%D0%B6%D0%B5%D0%BD%D0%B8%D0%B5). +5. [Старайтесь не использовать страдательный залог](https://ru.wikipedia.org/wiki/%D0%97%D0%B0%D0%BB%D0%BE%D0%B3_(%D0%BB%D0%B8%D0%BD%D0%B3%D0%B2%D0%B8%D1%81%D1%82%D0%B8%D0%BA%D0%B0)). +6. [Стремитесь формулировать предложения в позитивной форме](https://examples.yourdictionary.com/positive-sentence-examples.html). +7. [Не используйте восклицательные знаки (допустимы только в цитатах)](https://www.grammarly.com/blog/exclamation-mark/). +8. Не преувеличивайте. +9. Избегайте повторов. +10. Будьте лаконичны. + +## Целевая аудитория + +Глоссарий предназначен как для специалистов, так и для людей, *не знакомых* с предметной областью. +Пожалуйста, объясняйте термины простыми словами и не предполагайте наличия технических знаний у читателя. Подробнее об этом — ниже в разделе [Определение](#definition). + +## Минимальное жизнеспособное определение + +Мы стремимся к тому, чтобы любой человек мог легко разобраться в нативных облачных (cloud native) терминах. +Поэтому уделяем особое внимание простоте. +Используйте доступный язык с примерами, понятными каждому, кто использует технологию, одновременно сопровождая его *минимальным необходимым набором технических подробностей*. +Не стоит экономить на контексте и примерах — в конце концов, они помогают читателю разобраться в той или иной концепции, — но если технические подробности не нужны для понимания, их лучше опустить. +Не переусложняйте материал. Достаточно, чтобы читатель понял основную идею. При необходимости он сможет обратиться к другим ресурсам за подробностями. +Мы не ставим перед собой цель превратить читателя в эксперта — это выходит за рамки данного глоссария. + +## Шаблон определения + +Каждый термин глоссария хранится в markdown-файле и следует определенному шаблону: + +```md +--- +title: +status: +category: +--- + +## Описание + +Краткое описание технологии или концепции. + +## Проблема + +Несколько строк о проблеме. + +## Решение + +Несколько строк о том, как данная технология решает проблему, описанную выше. +``` + +### Title + +Лейбл **title** всегда должен находиться в верхней части шаблона определения, а его значение соответствовать формату для заголовков. + +```md +--- +title: Definition Template +``` + +### Status + +Лейбл **status** идет после лейбла title. Он помогает понять, на какой стадии находится работа над определением. + +Допустимые значения: + +- Completed (Завершена) +- Feedback Appreciated (Приветствуется обратная связь) +- Not Started (Еще не начиналась) + +При этом всегда можно открыть Issue и внести правки в определение, работа над которым уже завершена. Все определения, над которыми ведется работа, имеют статус *Feedback Appreciated* (Приветствуется обратная связь). + +```md +--- +title: Definition Template +status: Feedback Appreciated +``` + +### Теги + +После лейбла status идет лейбл **tag**. +Ставьте только необходимые теги — это поможет сделать всю систему тегов осмысленной и, следовательно, полезной для читателя. +Применение слишком большого количества тегов только ослабит их смысловое значение. +Исключением является тег `Fundamental` — он указывает, что термин необходим для понимания других облачных концепций; при этом для большинства терминов, скорее всего, будет достаточно одного тега. + +**Примечание**: Пожалуйста, вводите новые теги только после одобрения хранителями. Добавляя теги к определению, убедитесь, что они написаны именно так, как указано ниже (в единственном числе, без опечаток). + +В настоящее время поддерживаются следующие теги: + +- Application +- Architecture +- Fundamental +- Infrastructure +- Methodology +- Networking +- Property +- Security + +```md +--- +title: Definition Template +status: Feedback Appreciated +tags: ["tag 1", "tag 2", ""] +--- +``` + +### Определение {#definition} + +#### Три раздела + +Определения **технологий** и **концепций** включают три раздела: + +- **Описание**. Краткое и четкое описание того, о чем идет речь. +- **Проблема**. Сосредоточьтесь на проблеме, а не на решении (его приберегите для следующего раздела). + Избегайте упоминать термин, для которого дается определение. Фокусируйтесь на предпосылках, которые привели к разработке описываемой технологии/концепции. +- **Решение**. Теперь можно вернуться к самому термину. Как именно он помогает решить проблему, описанную выше? + +Обратите внимание, что **характеристики/свойства** не требуют отдельных разделов. Краткого определения будет достаточно. + +Для облегчения рецензирования используйте **смысловые переносы строк** (одно предложение на строку). + +#### Качество имеет первостепенное значение + +Если PR будет принят, ваше описание станет официальным определением CNCF для этого термина (пока кто-то другой не дополнит его). +Все определения должны соответствовать высоким стандартам CNCF — подходите к работе над ними размеренно, без спешки, ведь качество требует времени и усилий. + +**Изучите все досконально.** Даже если вы уверены, что хорошо разбираетесь в предметной области, проверьте, правильно ли понимаете значение термина. +Нередко бывает так, что оно оказывается искажено, не отражает всей сути или подразумевается совсем не то, что говорится. +При изучении вопроса — особенно если вы не знакомы с термином на все 100% — пользуйтесь различными ресурсами. +Многие определения носят односторонний характер, особенно если даются вендором. +Определения в глоссарии должны быть независимыми от конкретного вендора и принятыми во всем мире. + +**Не занимайтесь плагиатом.** К глоссарию применяются те же правила, что и к любой другой серьезной публикации. +Не копируйте чужую работу (если только вы не цитируете ее с указанием автора). +Если вам понравилось чье-либо определение, перефразируйте его своими словами. + +**Ссылайтесь на авторитетные источники.** По возможности указывайте ссылки на надежные ресурсы, такие как проектная документация, запросы на обсуждение (RFD), стандарты и т.п. +Обратите внимание, что нельзя ссылаться на материалы, публикуемые вендорами. + +#### Стремитесь к простоте + +Цель глоссария — **объяснять сложные понятия простыми словами**. Это на удивление непростая задача. Определения, скорее всего, будут неоднократно пересматриваться и дополняться. +Составляя их, всегда помните о целевой аудитории. +Старайтесь не использовать отраслевые жаргонизмы и "модные" словечки — избавиться от них иногда непросто, и приходится делать над собой усилие в поисках альтернатив. + +Когда это уместно, используйте **примеры из реальной жизни**. Они помогут читателям (особенно неспециалистам) лучше понять, *почему* идея, которую вы объясняете, актуальна. + +Если в определении используются термины из глоссария, **всегда ссылайтесь на них** (добавляйте гиперссылку только в первое упоминание). + +**Пример**: посмотрите на раздел "Описание" в [определении сервис-меша](/service-mesh/). +В нем приведены ссылки на такие термины, как `микросервис`, `сервис`, `надежность` и `наблюдаемость`. +Кроме того, используется реальный пример, проводящий параллель между сетевыми проблемами в среде микросервисов (то, с чем не сталкиваются рядовые пользователи) и проблемами с Wi-Fi-подключением (то, что доступно и понятно любому пользователю ноутбука). +По возможности старайтесь приводить подобные примеры. + +#### Начинайте с документа в Google Docs или в Word + +Мы рекомендуем начать с документа в Google Docs или в Word. Запишите в него определение и свои мысли и оставьте их на несколько дней "дозревать". +Это поможет найти более простые и понятные формулировки. +Кроме того, обязательно проверьте орфографию перед тем, как открыть PR. + +Чтобы никто другой случайно не принял PR, пока вы работаете над ним, попросите закрепить Issue за собой (или создайте его при необходимости). +Подробнее об этом — в документе [Как внести свой вклад](/ru/contribute/). + +Прежде чем приступить к работе, ознакомьтесь с несколькими терминами из глоссария, +чтобы получить представление о детализации и сложности описания, +а также о том, когда уместно приводить примеры. + +## Процесс рассмотрения: чего ожидать + +Обратите внимание, что в настоящее время сопровождением глоссария занимаются всего три человека, которые делают это в свободное от основной работы время. +В некоторых случаях определения рассматриваются быстро, в других процесс может занять некоторое время — пожалуйста, наберитесь терпения. +Если у вас возникли вопросы, свяжитесь с нами в Slack-канале #glossary или в канале локализации +(о том, где и как их найти, читайте в документе [Как внести свой вклад](/ru/contribute/)). + +Наша цель — сделать Глоссарий Cloud Native передовым ресурсом. +После того, как вы отправите PR, мы можем попросить вас внести в него несколько правок. +Не расстраивайтесь — это обычная практика при совместной работе; так происходит со многими PR'ами. +Общие усилия и открытое обсуждение помогут создать идеальное определение. +Наградой за проделанную работу для вас станет благодарность читателей по всему миру. diff --git a/content/tr/_index.md b/content/tr/_index.md new file mode 100644 index 0000000000..0030835913 --- /dev/null +++ b/content/tr/_index.md @@ -0,0 +1,41 @@ +--- +title: "Cloud Native Sözlüğü" +status: Completed +--- + +# Cloud Native Sözlüğü + +Cloud Native Sözlüğü, karmaşıklığı ile ünlü olan cloud native alanının yalnızca teknoloji uzmanları için değil, herkes için anlaşılabilir olmasını hedeflemektedir. Basitliğe odaklanan sözlük, CNCF Business Value Subcommittee (BVS) tarafından yönetilen bir projedir. + +

Kubecon sunumu izleyen insanlar

+ +## Katkıda Bulunma + +Cloud Native Sözlüğü, ekleme, değişiklik veya iyileştirme yaparak katkıda bulunmak isteyen herkese açıktır. Paylaşılan sözlüğün iyileştirilmesi ve geliştirilmesi için CNCF tarafından yönetilen topluluk odaklı bir süreç benimsenmiştir. Bu sözlük, cloud native teknolojileri çerçevesinde ortak bir kelime dağarcığı oluşturmak amacıyla şirketlerden bağımsız bir platform sağlar. Projenin amacına ve tüzüğüne bağlı kalan tüm katılımcıların katkıları memnuniyetle karşılanmaktadır. + +Katkıda bulunmak isteyen herkes, bir GitHub issue veya pull request oluşturabilir. Lütfen [Stil Kılavuzu](/tr/style-guide/)'nu inceleyip takip ettiğinizden, [Nasıl Katkı Yapabilirim?](/tr/contribute/) dokümanını okuduğunuzdan, [CNCF'in Slack topluluğuna](https://communityinviter.com/apps/cloud-native/cncf) katıldığınızdan ve [#glossary](https://cloud-native.slack.com/archives/C02TX20MQBB) kanalına dahil olduğunuzdan emin olun. Ayrıca Cloud Native Sözlüğü'nü kendi ana diline çevirmek isteyenler için [#glossary-localizations](https://cloud-native.slack.com/archives/C02N2RGFXDF) isimli bir kanal da bulunmaktadır. Türkçe çeviriye katkıda bulunmak için [#glossary-localizations-turkish](https://cloud-native.slack.com/archives/C05ATBGLHJ7) kanalına dahil olabilirsiniz. + +## Teşekkürler + +Cloud Native Sözlüğü, CNCF Pazarlama Komitesi (Business Value Subcommittee) tarafından başlatılmıştır ve +[Catherine Paganini](https://www.linkedin.com/in/catherinepaganini/en/), +[Chris Aniszczyk](https://www.linkedin.com/in/caniszczyk/), +[Daniel Jones](https://www.linkedin.com/in/danieljoneseb/), +[Jason Morgan](https://www.linkedin.com/in/jasonmorgan2/), +[Katelin Ramer](https://www.linkedin.com/in/katelinramer/), +[Mike Foster](https://www.linkedin.com/in/mfosterche/) +ve daha pek çok kişinin katkılarını içermektedir. +Katkıda bulunanların tam listesini [bu GitHub sayfasından](https://github.com/cncf/glossary/graphs/contributors) görebilirsiniz. + +Projenin Türkçe yerelleştirilmesi +[Ali Ok](https://www.linkedin.com/in/aliok/), +[Halil Bugöl](https://www.linkedin.com/in/halilbugol/), +[Batuhan Apaydın](https://www.linkedin.com/in/bthnapydin/), +[Emin Alemdar](https://www.linkedin.com/in/emin-alemdar/), +[Şeyma Demir](https://www.linkedin.com/in/seymademir/) +ve [Oğuzhan Özdemir](https://www.linkedin.com/in/aoguzhanozdemir) tarafından yürütülmektedir. + +## Lisans + +Tüm kod katkıları Apache 2.0 lisansı kapsamındadır. +Dokümantasyon CC BY 4.0 altında dağıtılmaktadır. diff --git a/content/tr/abstraction.md b/content/tr/abstraction.md new file mode 100644 index 0000000000..94bd40418a --- /dev/null +++ b/content/tr/abstraction.md @@ -0,0 +1,16 @@ +--- +title: Soyutlama +status: Completed +category: Nitelik +tags: ["temel kavram", "", ""] +--- + +Bilişimde soyutlama (abstraction), bir hizmet kullanıcısından (bu bir program veya insan olabilir) ayrıntıları gizleyip, bir sistemi daha genelleyici ve kolay anlaşılır hale getiren bir temsildir. +Bilgisayarlarımızın işletim sistemi buna iyi bir örnektir; bilgisayarın nasıl çalıştığına dair tüm ayrıntıları soyutlar. +İşlemci, bellek ve programların nasıl yönetildiği hakkında bir şey bilmenize gerek yoktur. +Yapılması gereken sadece işletim sistemini çalıştırmaktır, detaylarla işletim sistemi ilgilenir. +Tüm bu detaylar işletim sistemi "perdesi" ya da diğer adıyla soyutlamanın arkasına gizlenmiştir. + +Tipik olarak sistemler birden fazla soyutlama katmanına sahiptir ve bu durum geliştirmeyi büyük ölçüde basitleştirir. +Programlama esnasında geliştiriciler, belirli bir soyutlama katmanıyla uyumlu bileşenler oluştururlar ve bunu yaparlarken farklı yapıdaki temel özellikler hakkında endişelenmelerine de gerek yoktur. +Arka planda ne olursa olsun, soyutlama katmanıyla çalışıyorsa sistemle birlikte de çalışacaktır. diff --git a/content/tr/agile-software-development.md b/content/tr/agile-software-development.md new file mode 100644 index 0000000000..1a4f599a28 --- /dev/null +++ b/content/tr/agile-software-development.md @@ -0,0 +1,26 @@ +--- +title: Çevik Yazılım Geliştirme +status: Completed +category: concept +tags: ["yöntem", "", ""] +--- + +## Nedir + +Çevik yazılım geliştirme, tekrarlayan geliştirme döngülerini ve kendi kendini organize eden ekipleri vurgulayan bir dizi uygulamadır. +Değerin yalnızca projenin sonunda üretildiği şelale tarzı projelerin aksine, çevik yazılım geliştirme, +değerin sürekli ve kademeli olarak sunulmasına ve sürecin kendisinin evrimsel olarak gelişimine odaklanır. + +## Hangi Sorunları Çözer + +Bir yazılım projesindeki tüm paydaşlar için  gereksinimleri tanımlamak, iletmek ve anlamak imkansız olmasa da çok zordur. +Yine de müşteriler yazılım projelerinin zamanında, iyi kalitede, bütçe ve kapsama uygun olarak teslim edilmesini isterler. +Döngüsel doğasıyla çevik yazılım geliştirme, şelale tarzı stratejilerin aksine gereksinimlerin sürekli uyarlanması +ve diğer tüm koşullara daha hızlı adaptasyonu sağlar.  + +## Nasıl Yardımcı Olur + +Çevik yazılım geliştirme, gereksinim mühendisliği, planlama, uygulama, gözden geçirme, test etme ve teslim etme gibi geleneksel stratejilerin (şelale tarzı) tüm aşamalarını içerir. +En büyük fark, bir yazılım projesinin tüm zaman diliminin, her biri tüm bu aşamaları içeren tekrarlara bölünmesidir. +Her tekrardan sonra, yaratılan değer müşteri ile birlikte gözden geçirilebilir ve gereksinimler hedefe doğru ayarlanabilir. +Ek olarak, geliştirme ekibi sürecin kendisini iyileştirmek için hangi adımların atılacağını geriye dönük olarak inceler. diff --git a/content/tr/api-gateway.md b/content/tr/api-gateway.md new file mode 100644 index 0000000000..cfc6f155ca --- /dev/null +++ b/content/tr/api-gateway.md @@ -0,0 +1,18 @@ +--- +title: API Geçidi +status: Completed +category: Teknoloji +tags: ["ağ", "", ""] +--- + +## Nedir + +[API](../application-programming-interface/) geçidi, benzersiz uygulama API’lerini bir araya toplayarak hepsinin tek bir yerde kullanılabilir olmasını sağlayan bir araçtır. Organizasyonların kimlik doğrulama, yetkilendirme ve istek sayısını sınırlandırma gibi temel işlevlerin merkezi bir konumdan yönetilmesini sağlar. Bir API geçidi, API tüketicilerine yönelik ortak bir arayüz işlevi görür. + +## Hangi Sorunları Çözer + +API’leri harici kullanıcıların kullanımına sunuyorsanız tüm erişimi yönetmek ve kontrol etmek için tek bir giriş noktası istersiniz. Ayrıca bu etkileşimlere işlevsellik uygulamaya ihtiyaç duyuyorsanız bir API geçidi, uygulamada kod değişikliği gerektirmeden trafiğe eşit şekilde uygulamanızı sağlar. + +## Nasıl Yardımcı Olur + +Bir uygulamadaki çeşitli API’ler için tek bir erişim noktası sağlayan API geçitleri, organizasyonların birbiriyle kesişen iş veya güvenlik mantığını merkezi bir konumdan uygulamasını kolaylaştırır. Ek olarak API’ler uygulama tüketicilerin ihtiyaçları için tek bir adrese başvurmalarına olanak sağlar. API geçidi, sistemdeki tüm web servislerine yönelik istekler için tek bir erişim noktası sağlayarak güvenlik ve gözlemlenebilirlik gibi işlemsel kaygıları basitleştirir. Tüm istekler API geçidi üzerinden geçtiği için metrik toplama, hız sınırlama ve yetkilendirme gibi işlevlerin eklenebileceği tek bir yer sunar. \ No newline at end of file diff --git a/content/tr/application-programming-interface.md b/content/tr/application-programming-interface.md new file mode 100644 index 0000000000..82d38ae02d --- /dev/null +++ b/content/tr/application-programming-interface.md @@ -0,0 +1,21 @@ +--- + +title: Uygulama Geliştirme Arayüzü (API) +status: Completed +category: Teknoloji +tags: ["mimari", "temel kavram", ""] +--- + +## Nedir + +API, bilgisayar programlarının birbirleriyle etkileşime girmesinin bir yoludur. İnsanların bir web sitesiyle web sayfası aracılığıyla etkileşime girmesi gibi bilgisayar programları API aracılığıyla birbirleriyle etkileşime girer. İnsan etkileşimlerinin aksine, API’lerin kendilerinden ne istenip ne istenmeyeceği konusunda sınırlamaları vardır. Bu sınırlamalar, programlar arasındaki iletişimin istikrarlı ve işlevsel olmasına yardımcı olur. + +## Hangi Sorunları Çözer + +Uygulamalar karmaşıklaştıkça küçük kod değişikliklerinin diğer işlevler üzerinde ciddi etkileri olabilir. Uygulamalar hem büyüyüp hem de istikrarlarını sürdürebilmeleri için modüler bir yaklaşıma ihtiyaç duyarlar. API’ler olmadan, uygulamalar arasındaki etkileşim için yapı eksikliği söz konusudur. Paylaşılan bir yapı olmadan uygulamaların ölçeklenebilmesi ve entegre edilmesi zordur. + +## Nasıl Yardımcı Olur + +API’ler, bilgisayar programlarının veya uygulamaların etkileşime girmesine ve tanımlanmış ve anlaşılır biçimde bilgi paylaşımına izin verir. Modern uygulamaların yapı taşlarıdır ve geliştiricilere uygulamaları birbirlerine entegre etme yolu sağlar. Mikroservislerin birlikte çalıştığını duyduğunuzda, bunların bir API aracılığıyla etkileşime girdiği sonucunu çıkarabilirsiniz. + + diff --git a/content/tr/blue-green-deployment.md b/content/tr/blue-green-deployment.md new file mode 100644 index 0000000000..019d01b979 --- /dev/null +++ b/content/tr/blue-green-deployment.md @@ -0,0 +1,30 @@ +--- +title: Blue Green Deployment +status: Completed +category: concept +tags: ["yöntem", "uygulama", ""] +--- + +## Nedir + +Blue green deployment, çalışan bilgisayar sistemlerini minimum sistem kesintisiyle güncellemeye yönelik bir stratejidir. Operatör, “blue” ve “green” olarak adlandırılan iki ortamın devamlılığını sağlar. +Biri canlı trafiğe hizmet ederken (tüm kullanıcıların o an kullandığı sürüm), diğeri güncellenir. +Aktif olmayan (green) ortamda testler tamamlandıktan sonra, canlı trafiğe geçilir (genellikle bir yük dengeleyici kullanarak). +Blue-green deployment genellikle birçok servisten oluşan tüm ortamların tek seferde değiştirilmesi anlamına gelir. +Kafa karıştırıcı bir şekilde, bu terim bazen bir sistem içindeki tekil servisler için de kullanılmaktadır. +Bu belirsizliği önlemek için, tekil bileşenlere atıfta bulunurken sıfır sistem kesintili dağıtım (zero-downtime deployment) terimi tercih edilmelidir. + + +## Hangi Sorunları Çözer + +Blue-green deployment, geriye dönük uyumluluk eksikliği nedeniyle “birbirine bağlı olarak” değiştirilmesi gereken yazılımları güncellerken minimum sistem kesintisi sağlar. +Örneğin, bir web sitesi ve güncellenmesi gereken bir veritabanından oluşan bir çevrimiçi mağaza için blue-green deployment uygun olacaktır. +Ancak, veritabanının yeni sürümü web sitesinin eski sürümüyle çalışmaz veya bunun tersi de geçerlidir. +Bu durumda, her ikisinin de aynı anda değiştirilmesi gerekir. +Eğer bu canlı ortamda yapılsaydı, müşteriler sistem kesintisini fark ederdi. + + +## Nasıl Yardımcı Olur + +Blue-green deployment, minimum sistem kesintisiyle güncellenmesi gereken cloud native olmayan yazılımlar için uygun bir stratejidir. +Bununla birlikte, kullanımı eski yazılımın bileşenlerinin ayrı ayrı güncellenebilmesi için yeniden tasarlanması gerektiğinin bir göstergesidir. diff --git a/content/tr/canary-deployment.md b/content/tr/canary-deployment.md new file mode 100644 index 0000000000..a5ec8e5386 --- /dev/null +++ b/content/tr/canary-deployment.md @@ -0,0 +1,28 @@ +--- +title: Canary Deployment +status: Completed +category: concept +tags: ["yöntem", "uygulama", ""] +--- + +## Nedir + +Canary deployment, biri canlı trafiğe sahip orijinal kodu diğeri ise canlı trafik olmadan güncellenmiş kodu içeren iki ortamla başlayan bir dağıtım stratejisidir. +Trafik, uygulamanın orijinal sürümünden güncellenmiş sürümüne kademeli olarak taşınır. +Canlı trafiğin %1’ini taşıyarak başlanabilir, sonrasında %10, %25 gibi kademeli artışlarla tüm trafik güncellenmiş sürümde çalışana kadar böyle devam edilebilir. +Organizasyonlar yazılımın yeni sürümünü üretimde test edebilir, geri bildirim alabilir, hataları teşhis edebilir ve gerekirse hızlı bir şekilde kararlı sürüme geri dönebilir. + +“Canary” terimi, madencileri güvende tutmak için kanaryaların kömür madenine götürüldüğü “kömür madenindeki kanarya” uygulamasına atıfta bulunmaktadır. +Bu uygulamada eğer kokusuz, zararlı gazlar ortamda mevcut ise kanarya ölür ve madenciler hızlı bir şekilde madeni tahliye etmeleri gerektiğini bilirler. +Benzer şekilde, güncellenen kodda bir sorun çıkarsa, canlı trafik orijinal sürüme geri aktarılır. + +## Hangi Sorunları Çözer + +Test stratejisi ne kadar kapsamlı olursa olsun, üretimde her zaman bazı hatalar bulunur. +Trafiğin %100’ünü bir uygulamanın bir sürümünden diğerine kaydırmak daha etkili hatalara neden olabilir. + +## Nasıl Yardımcı Olur + +Canary deployment, organizasyonların büyük ölçekte trafiği yeni sürüme taşımadan önce yazılımın gerçekte oluşabilecek senaryolarda nasıl davrandığını görmelerini sağlar. +Bu strateji, organizasyonların sistem kesintisini en aza indirmesini ve yeni dağıtımla ilgili sorunlar olması durumunda hızla önceki sürüme geri dönmesini sağlar. +Ayrıca, genel kullanıcı deneyimi üzerinde önemli bir etkisi olmadan derinlemesine üretim uygulaması testine olanak tanır. diff --git a/content/tr/client-server-architecture.md b/content/tr/client-server-architecture.md new file mode 100644 index 0000000000..15f7043cc8 --- /dev/null +++ b/content/tr/client-server-architecture.md @@ -0,0 +1,27 @@ +--- +title: İstemci-Sunucu Mimarisi +status: Completed +category: concept +tags: ["mimari", "temel kavram", ""] +--- + +## Nedir + +İstemci-sunucu mimarisinde, bir uygulamayı oluşturan mantık (veya kod) iki veya daha fazla bileşen arasında bölünür. +Bunlar, işin yapılmasını isteyen bir istemci (örn. web tarayıcınızda çalışan Gmail web uygulaması) ve bu isteği karşılayan bir veya daha fazla sunucudur (örn. Google’ın buluttaki bilgisayarlarında çalışan “e-posta gönder” servisi). +Bu örnekte, yazdığınız e-postalar istemci (web tarayıcınızda çalışan uygulaması) tarafından bir sunucuya (Gmail’in giden e-postalarınızı alıcılarına ileten bilgisayarları) gönderilir. + +Bu, tüm işi tek bir yerde yapan bağımsız uygulamaların (masaüstü uygulamaları gibi) tersidir. +Örneğin, Microsoft Word gibi bir kelime işleme programı bilgisayarınıza kurulabilir ve tamamen bilgisayar üzerinden çalıştırılabilir. + +## Hangi Sorunları Çözer + +İstemci-sunucu mimarisi, bağımsız uygulamaların karşılaştığı büyük bir zorluğu çözer: düzenli güncellemeler. +Bağımsız bir uygulamada, kullanıcıların her güncelleme için en son sürümü indirip yüklemesi gerekir. +Göz atabilmek için Amazon’un tüm ürün kataloğunu kendi bilgisayarınıza indirmek zorunda kaldığınızı hayal edin! + +## Nasıl Yardımcı Olur + +Uygulama mantığını uzak bir sunucu ya da serviste uygulayarak, operatörler istemci tarafındaki mantığı değiştirmeye gerek kalmadan bunu güncelleyebilirler. +Bu, güncellemelerin çok daha sık yapılabileceği anlamına gelir. Verilerin sunucuda depolanması, birçok istemcinin aynı verileri görmesini ve paylaşmasını sağlar. +Çevrimdışı bir kelime işleme programına kıyasla çevrimiçi bir kelime işleme programı kullanmak arasındaki farkı düşünün. Çevrimiçi programda, dosyalarınız sunucu tarafında bulunur ve bunları sunucudan indiren diğer kullanıcılarla paylaşılabilir. Oysa geçmişte, dosyaların çıkarılabilir medyaya (disketlere!) kopyalanması ve onun aracılığıyla paylaşılması gerekiyordu. diff --git a/content/tr/cloud-computing.md b/content/tr/cloud-computing.md new file mode 100644 index 0000000000..544be345b4 --- /dev/null +++ b/content/tr/cloud-computing.md @@ -0,0 +1,19 @@ +--- +title: Bulut Bilişim +status: Completed +category: Kavram +tags: ["altyapı", "temel kavram", ""] +--- + +## Nedir + +Bulut bilişim, internet üzerinden isteğe bağlı olarak CPU, ağ ve disk kapasiteleri gibi bilişim kaynaklarının sunulduğu, kullanıcıların uzaktaki fiziksel bir konumda bilgi işlem gücüne erişebildiği ve kullanabildiği bir hizmettir. +Genellikle, bulut altyapısının bir organizasyona ayrılmış olup olmadığına veya genele açık hizmetlerde paylaşılıp paylaşılmadığına bağlı olarak, özel veya genel bulut şeklinde bir ayrım yapılır. + +## Hangi Sorunları Çözer + +Organizasyonlar, bilgi işlem gücünü genişletmeye çalışırken geleneksel olarak iki temel zorlukla karşılaşır. Ya fiziksel sunucularını ve ağlarını barındırmak için yeni tesisler satın alır ve tasarlarlar, ya da mevcut tesislerini genişletip desteklerler. Bulut bilişim, organizasyonların bilgi işlem ihtiyaçlarının bir kısmını dış kaynak olarak kullanma imkanı tanıyarak bu zorluğu çözer. + +## Nasıl Yardımcı Olur + +Bulut sağlayıcıları, organizasyonların isteğe bağlı olarak bilişim kaynaklarını kiralama ve kullanımı için ödeme yapmasına izin vererek iki önemli avantaj sağlar. İlk olarak, organizasyonlar yeni fiziksel altyapı için beklemek, planlamak ve kaynak harcamak zorunda kalmadan ürün veya hizmetlerine odaklanabilirler. İkincisi, ihtiyaç duyuldukça talep üzerine kolayca ölçekleme imkanı elde ederler. Bulut bilişim, organizasyonların ihtiyaçlarına göre istedikleri kadar altyapıyı kullanmalarına olanak tanır. diff --git a/content/tr/cloud-native-apps.md b/content/tr/cloud-native-apps.md new file mode 100644 index 0000000000..c60f0ea3ce --- /dev/null +++ b/content/tr/cloud-native-apps.md @@ -0,0 +1,23 @@ +--- +title: Cloud Native Uygulamalar +status: Completed +category: Kavram +tags: ["uygulama", "temel kavram", ""] +--- + +Cloud native uygulamaları, [bulut bilişimdeki](/cloud-computing/) yeniliklerden yararlanmak için özel olarak tasarlanmıştır. +Bu uygulamalar, bulutun kaynaklarından ve [ölçeklendirme](/scalability/) yeteneklerinden yararlanarak kendi bulut mimarileriyle kolayca entegre olurlar. +Ayrıca, bulut bilişim tarafından yönlendirilen altyapıdaki yeniliklerden yararlanan uygulamaları da ifade eder. +Günümüzde cloud native uygulamaları, bir bulut sağlayıcısının veri merkezinde ve şirket içi cloud native platformlarında çalışan uygulamaları içerir. + +## Hangi Sorunları Çözer + +Geleneksel olarak, şirket içi ortamlar bilişim kaynaklarını oldukça kişiye özel bir şekilde sağlardı. +Her veri merkezi, genellikle [sanal makineler](/virtual-machine/) ve servisler gibi altyapı için büyük ölçüde manuel tedariğe dayanan, uygulamaları belirli ortamlara [sıkı bir şekilde bağlayan servislere](/tightly-coupled-architectures/) sahipti. +Bu da geliştiricileri ve uygulamalarını belirli bir veri merkeziyle sınırlıyordu. +Bulut için tasarlanmayan uygulamalar, bir bulut ortamının esnekliğinden ve ölçeklendirme yeteneklerinden yararlanamıyordu. +Örneğin, doğru şekilde başlatmak için manuel müdahale gerektiren uygulamalar otomatik olarak ölçeklenemez ve bir arıza durumunda otomatik olarak yeniden başlatılamaz. + +## Nasıl Yardımcı Olur + +Cloud native uygulamalarına giden yolların "herkese uygun" olmasa da, bazı ortak yönleri vardır. Cloud native uygulamalar esnektir, yönetilebilir ve kendilerine eşlik eden bulut hizmetleri paketi tarafından desteklenir. Çeşitli bulut hizmetleri, kullanıcıların sorunları büyümeden önce tespit etmesini ve ele almasını sağlayan yüksek derecede [gözlemlenebilirlik](/observability/) sağlar. Etkin otomasyonla birleştiğinde, mühendislerin yüksek etkili değişiklikleri sık sık, öngörülebilir bir şekilde ve minimum zahmetle yapmalarına olanak tanır. diff --git a/content/tr/cloud-native-security.md b/content/tr/cloud-native-security.md new file mode 100644 index 0000000000..33218cd193 --- /dev/null +++ b/content/tr/cloud-native-security.md @@ -0,0 +1,16 @@ +--- +title: Cloud Native Security +status: Completed +category: concept +tags: ["güvenlik", "", ""] +--- +Cloud Native güvenliği, güvenliği Cloud Native uygulamalara entegre eden bir yaklaşımdır. Güvenliğin geliştirmeden üretime kadar tüm uygulama yaşam döngüsünün bir parçası olmasını sağlar. Cloud Native güvenliği, hızlı kod değişiklikleri ve son derece geçici altyapı gibi cloud native ortamlarının özelliklerine uyum sağlamaya çalışırken geleneksel güvenlik modelleriyle aynı standartları sağlamayı amaçlamaktadır. Cloud native güvenliği, DevSecOps (development, security, operations) adındaki yöntemle büyük ölçüde alakalıdır. + +## Hangi Problemi Çözer +Geleneksel güvenlik modelleri artık geçerli olmayan bir dizi varsayımla oluşturulmuştur. Cloud Native uygulamalar sık sık değişir, çok sayıda açık kaynak araç ve kütüphaneler kullanır, genellikle sunucu tarafından kontrol edilen altyapıda çalıştırılır ve hızlı altyapı değişikliklerine maruz kalır.. Kod gözden geçirmeleri, uzun kalite güvence döngüleri, ana bilgisayar tabanlı güvenlik açığı taraması ve son dakikada güvenlik için gözden geçirmeler, cloud native uygulamalarıyla ölçeklenemez. + + +## Nasıl Yardımcı Olur +Cloud Native güvenliği, geleneksel güvenlik modellerinden yayın döngüsünün her adımında güvenliğin dahil olduğu bir modele geçiş yaparak uygulamaları koruyan yeni bir çalışma yöntemi sunar. Elle denetim ve kontrollerin yerini büyük ölçüde otomatik taramalar alır. Hızlı kod yayınlama işlem hatları, kodu derlemeden önce güvenlik açıklarına karşı tarayan araçlarla entegre edilmiştir. Açık kaynak kütüphaneler güvenilir kaynaklardan alınır ve güvenlik açıkları izlenir. Cloud Native güvenlik modeli, değişimi yavaşlatmak yerine, sık sık güncellenen hassas bileşenleri veya altyapının düzenli olarak değişiminin sağlanmasını benimser. + + diff --git a/content/tr/cloud-native-tech.md b/content/tr/cloud-native-tech.md new file mode 100644 index 0000000000..f8a99ca67d --- /dev/null +++ b/content/tr/cloud-native-tech.md @@ -0,0 +1,25 @@ +--- +title: Cloud Native Teknolojisi +status: Completed +category: Kavram +tags: ["temel kavram", "", ""] +--- + +## Nedir + +Cloud native yığını olarak da adlandırılan cloud native teknolojileri, cloud native uygulamaları oluşturmak için kullanılan teknolojilerdir. +Bu teknolojiler kuruluşlar için genel, özel ve hibrit bulut ortamları gibi modern ve dinamik ortamlarda ölçeklenebilir uygulamalar oluşturmaya ve çalıştırmaya olanak tanırken [bulut bilişimin](/tr/cloud-computing/) yararlarını en üst düzeye çıkarırlar. +Bulut bilişimin yeteneklerinden yararlanmak için sıfırdan tasarlanmışlardır ve konteynerler, servis ağları, mikro servisler ve sabit altyapı bu yaklaşımın örnekleridir. + +## Hangi Sorunları Çözer + +Cloud native yığını, zorlukların çeşidini adresleyen birçok farklı teknoloji kategorisine sahiptir. +[CNCF Cloud Native Landscape’e](https://landscape.cncf.io/) baktığınızda ne kadar farklı alana temas ettiğini görebilirsiniz. +Ancak genel olarak bahsedecek olursak cloud native teknolojileri, bir ana zorluk kümesini ele almaktadır; geleneksel BT işletim modellerinin olumsuz yönleri. +Bu zorluk kümesi, ölçeklenebilir, arızalanırsa bile çalışmaya devam edebilen, kendi kendini onaran uygulamalar oluşturma güçlüklerinin yanı sıra kaynakların verimsiz kullanımını içermektedir. + +## Nasıl Yardımcı Olur + +Her teknoloji çok spesifik bir sorun üzerine giderken, bir grup olarak cloud native teknolojileri dayanıklı, yönetilebilir ve gözlemlenebilir olan gevşek bağlı sistemlere olanak tanır. +Sağlam otomasyon ile birleştirildiğinde, mühendislerin minimum çabayla öngörülebilir ve sık sık yüksek etkili değişiklikler yapmasına imkan tanır. +Cloud native sistemlerinin kullanılmak istenen özelliklerine cloud native yığınıyla ulaşmak daha kolaydır. diff --git a/content/tr/cluster.md b/content/tr/cluster.md new file mode 100644 index 0000000000..29349e649c --- /dev/null +++ b/content/tr/cluster.md @@ -0,0 +1,20 @@ +--- +title: Küme (Cluster) +status: Completed +category: Concept +tags: ["altyapı", "temel kavram", ""] +--- + +## Nedir + +Küme, ortak bir amaç doğrultusunda birlikte çalışan bir grup bilgisayar ve uygulamadır. Cloud native bilişimi bağlamında "küme" kavramı çoğunlukla Kubernetes için kullanılır. Kubernetes kümesi, genellikle farklı makinelerde olacak şekilde, kendi konteynerlerini kullanarak çalışan bir dizi servisten (veya iş yükünden) oluşur. Bir ağ üzerinden bağlanan tüm bu konteynerli servisler bir kümeyi temsil eder. + + +## Hangi Sorunları Çözer + +Tek bir bilgisayarda çalışan yazılım tek bir hata noktasına sahiptir. Eğer bilgisayar çöker veya birisi yanlışlıkla güç kablosunu çıkarırsa, iş açısından kritik önem taşıyan bazı sistemler çalışmayı durdurabilir. Bu sebeple modern yazılımlar genellikle kümeler halinde gruplandırılarak dağıtık uygulamalar şeklinde oluşturulur. + + +## Nasıl Yardımcı Olur + +Küme olarak düzenlenmiş, dağıtık uygulamalar birden fazla makinede çalışarak tek bir güvenlik açığı/arıza noktasını ortadan kaldırır. Fakat bu yapıyı oluşturmak gerçekten zordur. Aslına bakılırsa, bu başlı başına bir bilgisayar bilimi alanıdır. Global sistemlere duyulan ihtiyaç ve yıllarca süren deneme yanılma, yeni bir teknoloji yığınının geliştirilmesine yol açmış oldu: Cloud Native teknolojileri. Bu yeni teknolojiler, dağıtık sistemlerin oluşturulmasını ve işleyişini kolaylaştıran yapı taşlarıdır. diff --git a/content/tr/container-orchestration.md b/content/tr/container-orchestration.md new file mode 100644 index 0000000000..632b7574e0 --- /dev/null +++ b/content/tr/container-orchestration.md @@ -0,0 +1,23 @@ +--- +title: Konteyner Orkestrasyonu +status: Completed +category: Concept +--- + +## Nedir + +[Konteyner](/container/) orkestrasyonu, dinamik ortamlarda konteynerleştirilmiş uygulamaların yaşam döngüsünün yönetilmesi ve otomasyonunu ifade eder. +Bu genellikle bir konteyner orkestratörü aracılığıyla gerçekleştirilir (çoğu durumda Kubernetes) ve bu da yük çalıştırmayı, (otomatik) ölçeklendirmeyi, otomatik iyileştirmeyi ve takip etmeyi olanaklı kılar. +Orkestrasyon bir metafordur: orkestrasyon aracı, her bir konteynerin (veya müzisyenin) yapması gerekeni yaptığından emin olarak adeta bir müzik şefi gibi davranır. + +## Hangi Sorunları Çözer + +Mikroservisleri, güvenliği ve ağ iletişimini geniş ölçekte yönetmek ve genel olarak da dağıtık sistemleri elle yönetmek çok zor bir iştir; hatta belki de imkansızdır. +Konteyner orkestrasyonu, kullanıcıların tüm bu yönetim görevlerini otomatikleştirmelerine olanak sağlar. + +## Nasıl Yardımcı Olur + +Konteyner orkestrasyon araçları, kullanıcıların bir sistemin durumu hakkında karar vermesine olanak tanır. +İlk olarak, nasıl görünmesi gerektiğini (örneğin, X/Y/Z konteynerleri, N adet pod vb.) belirtirler. +Ardından, orkestrasyon aracı altyapıyı otomatik olarak izler ve durumu belirtilenden farklı ise düzeltir (örneğin, bir konteyner çöktüyse yeni bir konteyner oluşturur). +Bu otomasyon, mühendislik ekiplerinin aksi takdirde oldukça manuel ve karmaşık olan kaynak tahsisi, yük çalıştırma, ölçeklendirme (yukarı ve aşağı), ağ tanımlama ve yük dengeleme gibi operasyonel görevlerini basitleştirir. diff --git a/content/tr/container.md b/content/tr/container.md new file mode 100644 index 0000000000..60187e2eac --- /dev/null +++ b/content/tr/container.md @@ -0,0 +1,34 @@ +--- +title: Konteynerler +status: Completed +category: technology +tags: ["uygulama", "temel kavram", ""] +--- + +## Nedir + +Konteyner, bir bilgisayarın işletim sistemi tarafından yönetilen, kaynak ve yetenek kısıtlamalarına sahip, çalışan bir işlemdir. +Konteyner işlemi içerisinde erişilebilir olan dosyalar konteyner imajı olarak paketlenmiştir. +Konteynerler aynı makinede birbirlerine bitişik olarak çalışır, +ancak genellikle işletim sistemi ayrı konteyner işlemlerinin birbiriyle etkileşime girmesini engeller. + +## Hangi Sorunları Çözer + +Konteynerler öncesinde, her uygulamayı çalıştırmak için ayrı makineler gerekirdi. +Tek bir uygulamanın çalışması için kullanılan her makine CPU, bellek ve disk alanı gerektiren +kendi işletim sistemine de ihtiyaç duymaktadır. +Buna ek olarak işletim sisteminin bakımı, yükseltilmesi ve başlatılması da bir diğer önemli zahmet kaynağıdır. + +## Nasıl Yardımcı Olur + +Konteynerler aynı işletim sistemini ve bu işletim sisteminin üzerinde durduğu makinenin kaynaklarını paylaşarak +işletim sisteminin kaynak yükünü dağıtır ve fiziksel makinenin verimli kullanımını sağlar. +Bu davranış, konteynerlerin birbirleriyle etkileşime girebilmelerinin genellikle sınırlı olması nedeniyle mümkündür +ve aynı fiziksel makinede birden fazla uygulamanın çalıştırılmasına olanak tanır. + +Ancak limitler de mevcuttur. +Konteynerler aynı işletim sistemini paylaştığı için, işlemlerin alternatiflere göre daha az güvenli olduğu düşünülebilir. +Konteynerler aynı zamanda paylaşılan kaynaklar üzerinde de sınırlamalar gerektirir. +Kaynakları doğru yönetmek için sistem yöneticilerinin veya geliştiricilerin, +konteynerin bellek ve CPU kullanımını kısıtlaması ve sınırlandırması gerekir. +Böylece, işletim sistemindeki diğer işlemler ve uygulamaların performansı kötü yönde etkilenmemiş olur. diff --git a/content/tr/containerization.md b/content/tr/containerization.md new file mode 100644 index 0000000000..4d0dc3ea99 --- /dev/null +++ b/content/tr/containerization.md @@ -0,0 +1,32 @@ +--- +title: Konteynerleştirme +status: Completed +category: Teknoloji +tags: ["uygulama", "", ""] +--- + +## Nedir + +Konteynerleştirme, bir uygulamayı ve bağımlılıklarını bir konteyner imajına paketleme sürecidir. +Konteyner oluşturma süreci, [Open Container Initiative](https://opencontainers.org/) (OCI) standardına uygun olmayı gerektirir. +Bu standarta uygun bir konteyner imajı üretiliyorsa, hangi konteynerleştirme aracının kullanıldığı önemli değildir. + +## Hangi Sorunları Çözer + +Konteynerler yaygınlaşmadan önce, organizasyonlar tek bir bare-metal (fiziksel bilgisayar) +makinede birden fazla uygulamayı düzenlemek için sanal makineleri (VM'ler) kullanırdı. +VM'ler, konteynerlardan önemli ölçüde daha büyüktürler ve çalıştırmak için bir hipervizöre ihtiyaç duyarlar. +Bu büyük VM şablonlarının depolanması, yedeklenmesi ve transfer edilmesi gerektiğinden, VM şablonlarının oluşturulması da yavaştır. +Ayrıca, VM'ler yapılandırma sapması yaşayabilir ve bu, değiştirilemezlik ilkesine aykırıdır. + +## Nasıl Yardımcı Olur + +Konteyner imajları hafiftir (geleneksel VM'lerin aksine) ve +konteynerleştirme süreci bir bağımlılık listesi içeren bir dosya gerektirir. +Bu dosya sürüm kontrolüne tabi tutulabilir ve imaj oluşturma süreci otomatikleştirilebilir. +Bu sayede, otomatik süreçler bu imaj oluşturma işiyle ilgilendiği +için organizasyonlar diğer önceliklere odaklanabilir. +Bir konteyner imajı, içeriğine ve yapılandırmasına +tam olarak bağlı olan benzersiz bir tanımlayıcı ile saklanır. +Konteynerler planlandığında ve yeniden planlandığında +her zaman başlangıç durumlarına sıfırlanır, bu da yapılandırma sapmasını ortadan kaldırır. diff --git a/content/tr/continuous-delivery.md b/content/tr/continuous-delivery.md new file mode 100644 index 0000000000..fcdd3e89ef --- /dev/null +++ b/content/tr/continuous-delivery.md @@ -0,0 +1,29 @@ +--- +title: Sürekli Teslimat (CD) +status: Completed +category: concept +tags: ["yöntem", "uygulama", ""] +--- + +## Nedir + +Genellikle CD olarak kısaltılan sürekli teslimat (continuous delivery), +kod değişikliklerinin otomatik olarak bir kabul ortamına dağıtıldığı (veya sürekli dağıtım (continuous deployment) +durumunda üretime otomatik olarak dağıtıldığı) bir dizi uygulamadır. +CD, yazılımın dağıtımdan önce yeterince test edilmesini sağlayacak kritik prosedürleri içerir ve +gerektiğinde değişiklikleri geri almak için bir yol sunar. +Sürekli entegrasyon (continuous integration - CI), sürekli teslimata yönelik ilk adımdır (yani, değişiklikler test edilmeden ve dağıtılmadan önce temiz bir şekilde birleştirilmelidir). + +## Hangi Sorunları Çözer + +Güvenilir güncellemelerin dağıtımı büyük ölçeklerde bir sorun haline gelir. +İdeal koşullarda, son kullanıcılara daha iyi ürün sunmak için daha sık dağıtım yapmalıyız. +Ancak, bunu manuel olarak yapmak, her değişiklik için yüksek işlem maliyetleri anlamına gelir. +Geçmişte, bu maliyetlerden kaçınmak için organizasyonlar daha az sıklıkta ürünlerini piyasaya sürerek bir kerede daha fazla değişiklik dağıtmış ve bir şeylerin yanlış gitme riskini arttırmıştır. + +## Nasıl Yardımcı Olur + +CD stratejileri, canary veya blue-green sürümleri gibi çeşitli dağıtım stratejileri kullanarak yazılımı test eden ve +dağıtan tamamen otomatik bir üretim yolu oluşturur. +Bu, geliştiricilerin kodu sık sık dağıtmasına olanak tanıyarak yeni revizyonun test edildiğinden emin olmalarını sağlar. Tipik olarak, CD stratejilerinde feature branching veya pull request aksine gövde tabanlı geliştirme (trunk-based development) kullanılır. + diff --git a/content/tr/continuous-deployment.md b/content/tr/continuous-deployment.md new file mode 100644 index 0000000000..934072df3a --- /dev/null +++ b/content/tr/continuous-deployment.md @@ -0,0 +1,24 @@ +--- +title: Sürekli Dağıtım (CD) +status: Completed +category: concept +tags: ["uygulama", "yöntem", ""] +--- + +## Nedir + +Genellikle CD olarak kısaltılan sürekli dağıtım (continuous deployment), tamamlanmış yazılımı doğrudan üretime dağıtarak sürekli teslimattan (continuous delivery) bir adım daha ileri gider. +Sürekli dağıtım (CD), sürekli entegrasyon (CI) ile birlikte ele alınır ve genellikle CI/CD olarak adlandırılır. +CI süreci, uygulamada yapılan değişikliklerin geçerli olup olmadığını test eder ve CD süreci, kod değişikliklerini bir organizasyonun testten üretime, tüm ortamlarına otomatik olarak dağıtır. + +## Hangi Sorunları Çözer + +Yeni yazılım sürümlerinin yayınlanması yoğun emek gerektiren ve hata yapmaya yatkın bir süreç olabilir. +Bu aynı zamanda organizasyonların üretim kazalarından kaçınmak ve mühendislerin normal çalışma saatleri dışında çalışmaları gereken zamanı azaltmak için nadiren yapmak isteyecekleri bir şeydir. +Geleneksel yazılım dağıtım modelleri, organizasyonları yazılım yayınlama sürecinin hem istiktar hem de yeni özellik yayınlama hızı konusundaki kurumsal ihtiyaçları karşılayamadığı bir kısır döngü içinde bırakır. + +## Nasıl Yardımcı Olur + +Yayınlama döngüsünü otomatikleştirerek ve organizasyonları üretime daha sık sürüm yayınlamaya zorlayarak CD, CI’ın geliştirme ekipleri için yaptığını operasyon ekipleri için yapar. +Özellikle, operasyon ekiplerini ürün dağıtımlarının sancılı ve hataya yatkın kısımlarını otomatikleştirmeye zorlayarak genel riski azaltır. +Ayrıca organizasyonları ürün değişikliklerini kabul etme ve bunlara uyum sağlama konusunda daha iyi hale getirir, bu da daha yüksek istikrar sağlar. diff --git a/content/tr/continuous-integration.md b/content/tr/continuous-integration.md new file mode 100644 index 0000000000..7935badf4a --- /dev/null +++ b/content/tr/continuous-integration.md @@ -0,0 +1,24 @@ +--- +title: Sürekli Entegrasyon (CI) +status: Completed +category: concept +tags: ["uygulama", "yöntem", ""] +--- + +## Nedir + +Genellikle CI olarak kısaltılan sürekli entegrasyon (continuous integration), kod değişikliklerini mümkün olduğunca düzenli olarak entegre etme uygulamasıdır. +CI, sürekli teslimat (continuous delivery - CD) için ilk adımdır. +CI süreci, kod değişikliklerinin bir kaynak kontrol sistemine (Git, Mercurial veya Subversion) gönderilmesiyle başlar ve test edilmiş bir yapının CD sistemi tarafından  kullanılmaya hazır hale gelmesiyle sona erer.** + +## Hangi Sorunları Çözer + +Yazılım sistemleri genellikle çok sayıda geliştiricinin bakımını ve güncellemesini yaptığı büyük ve karmaşık yapılardır. Sistemin farklı bölümleri üzerinde paralel olarak çalışan geliştiriciler, birbiriyle çelişen değişiklikler yapabilir ve istemeden birbirlerinin çalışmalarını bozabilirler. +Ayrıca, aynı proje üzerinde birden fazla geliştirici çalıştığında, kod kalitesini test etme ve hesaplama gibi günlük görevlerin her bir geliştirici tarafından tekrarlanması gerekir. Bu da zaman kaybına yol açar. ** + +## Nasıl Yardımcı Olur + +CI yazılımı, geliştirici bir değişiklik yaptığında kod değişikliklerinin doğru bir şekilde birleşip birleşmediğini otomatik olarak kontrol eder. +CI sunucusunu kullanarak kod kalite kontrolü, testler ve hatta dağıtımlar yapmak oldukça yaygın bir uygulamadır. +Böylece, ekipler arasında kalite kontrolün somut bir uygulaması haline gelir. +CI, yazılım ekiplerinin her kod gönderiminin somut bir hata ya da uygulanabilir bir sürüm adayına dönüşmesini sağlar. diff --git a/content/tr/contribute/_index.md b/content/tr/contribute/_index.md new file mode 100644 index 0000000000..949b5d4ec9 --- /dev/null +++ b/content/tr/contribute/_index.md @@ -0,0 +1,240 @@ +--- +title: Nasıl katkı yapabilirim? +toc_hide: true +status: Completed +menu: + main: + weight: 10 +--- + +## Merhaba + +Cloud Native Sözlüğü katkı rehberine hoşgeldiniz. İlginiz için teşekkür ederiz. +Detaylıca anlatacağımız şekilde, katkı yapmanın birkaç yolu var: + +1) [Mevcut bir issue üzerinde çalışma](#work-on-an-existing-issue) +2) [Yeni terimler önerme](#propose-new-terms) +3) [Mevcut terimleri güncelleme](#update-an-existing-term) +4) [Sözlüğü kendi dilinize çevirme](#help-localize-the-glossary) + +## Cloud Native Sözlüğü'ne genel bakış + +Bu sözlüğün amacı, karmaşıklığı ile ünlü olan Cloud Native alanını sadeleştirmek ve herkese daha erişilebilir hale getirmektir. + +Cloud Native Sözlüğü'nün içeriğinin tutulduğu [bu GitHub repository](https://github.com/cncf/glossary)'sinde, sözlük hakkında +[issue'lar](https://github.com/cncf/glossary/issues), pull request'ler ([PRs](https://github.com/cncf/glossary/pulls)) +ve [tartışmalar](https://github.com/cncf/glossary/discussions) bulabilirsiniz. + +## Kimler katkı yapabilir? + +Nasıl katkıda bulunabileceğiniz, Cloud Native alanındaki bilgi seviyenize bağlıdır. +Karmaşık kavramları sadeleştirmek, konu hakkında oldukça derin bir bilgi seviyesi gerektirir. +Dolayısıyla, yeni terimler önermek için o terimler hakkında uzman olmanız gerekir. +Katkı yapanlar genellikle bu teknolojilerle bir süre çalışmış olan mühendisler veya Cloud Native'e odaklanmış akademisyenlerdir. + +Karmaşık kavramları sade kelimeler ile açıklamak _gerçekten çok zor_ olduğu için, bu bilgi birikimi gereklidir. Ayrıca, kolay anlaşılabilir ve kullanıcı dostu sonuçlar elde etmek kolay gibi görünse de, arzu edilen sadelik ancak Cloud Native uzmanlarının sıkı çalışması ve işbirliği ile başarılabilir. + +Eğer bir Cloud Native uzmanı değilseniz fakat katkıda bulunmak istiyorsanız, bir uzmanla takım olmanızı tavsiye ederiz. Uzman, terimin kavramı tam olarak tarif ettiğinden emin olduğunda, ilk Sözlük katkınıza hazırsınız demektir. + +Başka bir dilde yeterliliğe sahip olan kişiler, yerelleştirme çabalarına katılarak Sözlük'e değerli katkı yapabilirler. +Bu yeni başlayanlar için de uygundur. İngilizce'deki oturmuş tanımlar ile, daha az tecrübeli kişiler başka bir dile yerelleştirme yapabilirler. Siz de, mevcut olan yerelleştirme takımlarına katılabilir veya yeni bir tane başlatabilirsiniz. Bu rehberin "[Sözlüğü yerelleştirmemize yardım edin](#help-localize-the-glossary)" kısmını okuyarak nasıl başlayacağınızı öğrenebilirsiniz. + +**Türkçe yerelleştirme ekibi** + +Türkçe yerelleştirme ekibi olarak katkılarınızı bekliyoruz! + +Ekibimiz herkesin katılımına açık. + +Türkçe yerelleştirme ekibi olarak her türden katılımcıya yönelik görevlerimiz bulunmakta. + +CNCF Sözlüğü yerelleştirmesine yardımcı olarak: + +- Açık kaynağa katkı yapmak için iyi bir başlangıç şansı edebilirsiniz. Açık kaynak katkı süreçlerine giriş yapıp, topluluk işleyişi hakkında fikir sahibi olabilirsiniz. +- Türkiye'den başka Cloud Native ile ilgilenen kişiler ile bağlantı kurabilirsiniz. +- CNCF topluluğu hakkında fikir edinebilirsiniz. +- Türk yazılım ve teknoloji topluluğuna fayda sağlayabilirsiniz. + +Ekibimiz şeffaf ve açık bir şekilde çalışmakta. + +Katılmak için bize CNCF Slack'inde, [#glossary-localization-turkish](https://cloud-native.slack.com/archives/C05ATBGLHJ7) kanalında selam verebilir ve katılım talimatlarını görebilirsiniz. + +## Başlamadan Önce + +Sözlük katkı serüveninize başlamadan önce, aşağıdaki adımları tamamladığınızdan emin olun: + +1. Eğer yoksa, Bir [GitHub hesabı](https://docs.github.com/en/get-started/signing-up-for-github/signing-up-for-a-new-github-account) oluşturun. +2. [Katılımcı Lisans Sözleşmesi](https://docs.linuxfoundation.org/lfx/easycla/v2-current/contributors)ni (Contributor License Agreement - CLA) imzalayın. +3. [Commit imzanızı doğrulayın](https://docs.github.com/en/authentication/managing-commit-signature-verification/about-commit-signature-verification) +4. Commit'lerinizde "Onaylandı" göstergesini göstermek için GitHub hesabınızda [farkındalık modunu](https://docs.github.com/en/authentication/managing-commit-signature-verification/displaying-verification-statuses-for-all-of-your-commits#about-vigilant-mode) açın. + +## Örnek Uygulamalar {#best-practices} + +Gözden geçirme sürecini kolaylaştırmak için, lütfen [anlama bağlı satır sonları](https://sembr.org/) kullanın (örn: bir satırda bir cümle). +GitHub'da Markdown metinlerini doğru bir şekilde biçimlendirmek (örn: bağlantı, kalın, italik) için bu [Markdown kopya kağıdına](https://www.markdownguide.org/cheat-sheet/) bakmanızı tavsiye ederiz. +Ayrıca, .md dosyalarına isim verirken, lütfen parantezlerden kaçının, sadece küçük harfler kullanın ve boşluk yerine tire (-) kullanın. + + +## Stil Kılavuzu + +Katkı sürecini daha verimli hale getirmek için, biçimlendirme ve belge yazımını anlatan [Stil Kılavuzumuzu](/tr/style-guide/) okuyun. + +## Sözlük topluluğuna katılın! {#join-the-glossary-community} + +Eğer düzenli olarak katkı yapmak istiyorsanız, aylık Sözlük Çalışma Grubu toplantılarımıza katılmayı değerlendirebilirsiniz. +[CNCF Takviminde](https://www.cncf.io/calendar/), toplantı detaylarını bulabilirsiniz. +Ayrıca, CNCF Slack'inde [#glossary](https://cloud-native.slack.com/archives/C02TX20MQBB) kanalından da geliştiriciler ve katkı verenler ile de iletişime geçebilirsiniz. Sizinle tanışmayı çok isteriz! + +## Mevcut bir issue üzerinde çalışma {#work-on-an-existing-issue} + +Sözlük GitHub repository'sinden [issue'lara](https://github.com/cncf/glossary/issues) bakın. Etiketleri (örn. Turkish language, help needed, good first issue) kullanarak filtreleme yapabilirsiniz. + +![Issue and labels](/images/how-to/issue-and-labels.png) + +Seçtiğiniz issue'nun başkasına atanmadığından emin olun. Örneğin, burada ilk 3 issue'nun müsait olduğunu ama 4.'nün başkasına atanmış olduğunu görebilirsiniz. + +![assigning a term](/images/how-to/howto-04.png) + +Bir issue seçtikten sonra, yorum yazın. + +![Claiming an issue](/images/how-to/claiming-an-issue.png) + +Bunlara ek olarak, CNCF Slack’indeki [#glossary](https://cloud-native.slack.com/archives/C02TX20MQBB) kanalında, proje geliştiricilerine haber verin. +_@Catherine Paganini_, _@Seokho Son_, _@Jihoon Seo_ ve _@iamnoah_ kullanıcılarını da, görmelerinden emin olmak için mesajınızda etiketleyin. + +Sonraki adımlar için, lütfen [Yeni bir terim gönderme (PR oluşturma)](#submitting-a-new-term) kısmına bakın. + +**Note**: Seçtiğiniz issue üzerinde proje geliştiricileri issue'yu size atadıktan sonra çalışabilirsiniz. +Aynı anda sadece tek bir terim issue'yu talep edebilirsiniz. +Birden çok terim üzerinde çalışacaksanız, bunları sırasıyla yapmanız gerekiyor. + +## Yeni terimler önerme {#propose-new-terms} + +Başkalarının üzerinde çalışması için veya kendiniz tanımını oluşturmak için bir terim önerebilirsiniz. +Her iki durumda da, bir [issue oluşturarak](#creating-an-issue) işe başlamalısınız. +Sözlük'e eklenmek için, her terimin [CNCF'in cloud native tanımına](https://github.com/cncf/toc/blob/main/DEFINITION.md) uygun olması gerekmektedir +Bu kuralın istisnası, sadece Cloud Native kavramlarını anlamak için kullanılan temel terimler olabilir. + +Aşağıda, GitHub ile aşınalığı olmayanlar için bir adım adım kılavuz bulunmaktadır. +**GitHub hakkında tecrübeli olsanız bile**, lütfen şu konular hakkında bilgi sahibi olmak için bu _kılavuza gözatın_: + +1. Issue'lar ve yeni terimler için şablonların yerini belirleme. +2. İssue talep etme. +3. [İmla kontrolü](#spell-check) hatalarını çözme. + +### Yeni bir issue oluşturma {#creating-an-issue} + +[Sözlük GitHub repository'sindeki](https://github.com/cncf/glossary/issues) "Issues" kısmına gidin ve Yeni Issue ("New issue") düğmesine basın. + +![issues](/images/how-to/howto-01.png) + +Şablonlardan, "Request to add a new term (English)" seçeneğini seçin. + +![templates](/images/how-to/english-issue-template.jpg) + +Önerdiğiniz terimi yazın, soruları cevaplayın, kutuları işaretleyin ve "Submit new issue" butonuna basın. +Eğer sadece bir terim öneriyorsanız, işiniz bu kadar! Eğer terimin tanımının üzerinde çalışmak istiyorsanız, okumaya devam edin. + +### Oluşturduğunuz terimin tasnifi {#triaging-your-issue} + +Sonrasında, sözlük proje geliştiricileri, oluşturduğunuz issue'yu tasnif edecekler. +Yani, terimin sözlüğün bir parçası olup olmayacağını değerlendirecekler. +Her terim önerisi kabul edilmeyebilir. Sözlüğe eklenecek terimlerin, oturmuş ve yaygın olarak kullanılan Cloud Native kavramları olması gerekiyor. + +Lütfen, proje geliştiricilerlerine Slack üzerinden yeni bir terim önerdiğinizi bildirin ve _@Catherine Paganini_, _@Seokho Son_, _@Jihoon Seo_, and/or _@iamnoah_ kullanıcılarını mesajınızda etiketleyin. +Eğer terimin tanımı üzerinde çalışmak istiyorsanız, issue'yu size atamaları için proje geliştiricilerlerine haber verin. + +### Yeni bir terim gönderme (PR oluşturma) {#submitting-a-new-term} + +[Stil Kılavuzunda](/tr/style-guide/) açıklandığı gibi, bir Google Docs veya Word belgesi ile başlamanızı tavsiye ediyoruz. + +Terim göndermeye hazır olduğunda, "content" klasörüne gidin. + +![content](/images/how-to/howto-05.png) + +…sonra "en" (İngilizce için) veya dilinizin ilk iki harfi. + +![language folder](/images/how-to/howto-06.png) + +… `_TEMPLATE.md dosyasını seçin. + +![template](/images/how-to/howto-07.png) + +İçeriği kopyalayın. + +![copy content](/images/how-to/howto-08.png) + +…ve "en" klasörüne geri gidin. "Add file" düğmesine basın ve "Create new file" seçeneğini seçin. + +![create new file](/images/how-to/howto-09.png) + +Adres kısmına, [Örnek Uygulamalar](#best-practices) kısmında bahsedildiği gibi isim yazın. +Dosya isminin sonuna .md uzantısını ekleyin (bu uzantı olmadan dosyanızın önizlemesini göremezsiniz). +Önceden kopyaladığınız içeriği şimdi aşağıya yapıştırın. Teriminizin tanımını artık yerine koyabilirsiniz. +Oluşturduğunuz Markdown içeriğini kontrol etmek için, [Örnek Uygulamalar](#best-practices) kısmında bahsedildiği üzere, "Preview" düğmesine basın. + +![finalize term](/images/how-to/howto-10.png) + +Aşağıya inin ve commit mesajı yazın. "Commit new file" düğmesine basın +ve… + +![commit new file](/images/how-to/howto-11.png) + +… artık bir PR göndermeye hazırsınız: + +![create a pr](/images/how-to/howto-12.png) + +"Create pull request" düğmesine bastığınızda, gönderdiğiniz PR "Pull requests" sekmesinde görünecek. + +![prs](/images/how-to/howto-13.png) + +## Mevcut bir terimi değiştirme {#update-an-existing-term} + +Mevcut bir terimi değiştirmek için, bir issue oluşturarak istekte bulunabilir veya değişiklikleri +kendiniz yaparak bir PR gönderebilirsiniz. + +### Issue oluşturarak değişiklik isteme {#request-a-change-via-an-issue} + +Eğer bir terimdeki bir sorunu haber vermek isterseniz, CNCF Sözlük sayfalarındaki "Sorun Bildir" seçeneğini kullanabilirsiniz. +Sorun bildirmek istediğiniz sayfaya gidin ve "Sorun Bildir" linkine basın. +Bu sizin için otomatik olarak bir issue oluşturma formu dolduracaktır. + +![report issue](/images/how-to/howto-14.png) + +Önerilerinizi ve sebeplerini tarif edin ve "Submit" düğmesine basın. + +![submit issue](/images/how-to/howto-15.png) + +### Bir terimi doğrudan değiştirme {#update-a-term-directly} + +Bir terimi değiştirip önerilerinizi bildirmek için, "Bu Sayfayı Düzenle" linkine basın. + +![edit this page](/images/how-to/howto-16.png) + +Terimin GitHub sayfası açılacaktır. Değişikliklerinizi yapın ve bir PR oluşturun. +Lütfen kurallarımıza uyduğunuzdan emin olmak için [Örnek Uygulamalar](#best-practices) kısmına bakın +ve [Stil Kılavuzu](/tr/style-guide/) kısmını okuyun. + +## Sözlüğü yerelleştirmemize yardım edin {#help-localize-the-glossary} + +Sözlüğü yerelleştirmemize yardımcı olmak için, lütfen CNCF Slack'indeki [#glossary-localizations](https://cloud-native.slack.com/archives/C02N2RGFXDF) kanalına katılın ve bize bir mesaj gönderin. +Mevcut bir ekibe katılabilir veya yeni bir ekip kurabilirsiniz +(gereklilikler için [Localization Guide](https://github.com/cncf/glossary/blob/main/LOCALIZATION.md) belgesini okuyun). +Ekibin katkı sürecinin detaylarını öğrenmek için, lütfen katkı yapmak istediğiniz dildeki **"Nasıl katkı yapabilirim?"** kılavuzunu okuyun. + +## İmla kontrolü {#spell-check} + +İmla kontrolünün (spell check) hata vermesinin iki sebebi olabilir: + +- Gönderdiğiniz PR imla hataları barındırıyor olabilir. +- Gönderdiğiniz PR kelime listesinde kayıtlı olmayan bazı kelimeler barındırıyor olabilir. + +Kelime listesine yeni kelimeler eklemek için: + +1. PR'ınızda, "wordlist.txt" dosyasını bulun. +2. "Edit this file" düğmesine basın ve eksik kelimeleri alfabetik sıraya uyacak şekilde ekleyin +3. Bir commit mesajı yazın ve "Sign off and propose changes" düğmesine basın. + +**Not**: İmla kontrolü büyük-küçük harf duyarsız yapılmaktadır. + + +**Bu kılavuz [The Good Docs Project](https://thegooddocsproject.dev/) projesindeki şablonlar ile oluşturulmuştur.** diff --git a/content/tr/data-center.md b/content/tr/data-center.md new file mode 100644 index 0000000000..f50ffc621b --- /dev/null +++ b/content/tr/data-center.md @@ -0,0 +1,27 @@ +--- +title: Veri Merkezi +status: Completed +category: Technology +tags: ["altyapı", "temel kavram", ""] +--- + +## Nedir + +Veri merkezi, çoğunlukla sunucular olmak üzere bilgisayarları barındırmak üzere tasarlanmış bina veya tesistir. +Veri merkezleri, özellikle bulut bilişime odaklandıklarında, yüksek hızlı internet hatlarına bağlanma eğilimindedirler. +Veri merkezlerini barındıran binalar, kesintiler sırasında güç sağlayan jeneratörler ve bilgisayarları serin tutan güçlü klimalar dahil olmak üzere olumsuz şartlarda bile hizmeti sürdürecek şekilde donatılmıştır.  + +## Hangi Sorunları Çözer + +Veri merkezleri 1990’ların sonunda yaygınlaşmadan önce, çoğunlukla belirli görevleri olan veya bireylerin işlerini yapmak için kullanılan kişisel bilgisayarlar vardı. + +Ancak bilgisayarların sınırlı kaynakları vardır (disk, RAM ve CPU). Bu, üzerlerinde çalıştırılacak uygulamaların aynı kısıtlamalara sahip olduğu ve çalıştırılabilecek uygulama türlerinin sınırlandığı anlamına gelir. +Veri merkezlerinden önce, uygulamanın ölçeği üzerinde çalıştığı bilgisayarın kapasitesi ile sınırlıydı. +Ancak Gmail ya da Netflix gibi büyük ölçekli uygulamaları düşünürseniz (telefonunuzda ya da bilgisayarınızda kullandığınız kullanıcı arayüzü değil, uygulamanın kendisini düşünün), bunların herhangi bir bilgisayarın sağlayabileceği bilgi işlem kapasitesinden daha fazlasına ihtiyaçları vardır. İşte bu noktada veri merkezleri devreye giriyor. + +## Nasıl Yardımcı Olur + +Kullanıcılar çeşitli sunucuları birbirine bağlayarak bir “süper bilgisayar” gibi çalışan dağıtık bir sistem oluşturabilirler. +Birkaç makinenin gücü bir araya getirildiği için artık çok daha büyük uygulamalar çalıştırılabilir veya çok daha güçlü hesaplama görevleri gerçekleştirilebilir. Veri merkezleri günlük olarak kullandığımız çoğu uygulamaya güç sağlar.  + +Genel bulutlar, müşterilerine kapasite kiralayan veri merkezleridir. Son yıllarda, kurumsal veri merkezlerinden buluta doğru bir geçiş gözlenmektedir. diff --git a/content/tr/distributed-apps.md b/content/tr/distributed-apps.md new file mode 100644 index 0000000000..0789e375a7 --- /dev/null +++ b/content/tr/distributed-apps.md @@ -0,0 +1,26 @@ +--- +title: Dağıtık Uygulamalar +status: Completed +category: concept +tags: ["mimari", "", ""] +--- + +## Nedir + +Dağıtık uygulama, işlevselliğin birden fazla küçük, bağımsız parçaya bölündüğü bir uygulamadır. +Dağıtık uygulamalar genellikle daha büyük bir uygulama içinde farklı sorunları ele alan tekil mikro servislerden oluşur. Cloud native ortamında, tekil bileşenler genellikle bir küme üzerinde konteyner olarak çalışır. + +## Hangi Sorunları Çözer + +Tek bir bilgisayar üzerinde çalışan uygulama tek bir hata noktasına sahiptir. +Eğer bu bilgisayar arızalanırsa, uygulama kullanılamaz hale gelir. +Dağıtık uygulamalar genellikle monolitik uygulamalarla karşılaştırılır. +Bileşenler bağımsız olarak ölçeklendirilemediği için monolitik bir uygulamanın ölçeklendirilmesi daha zor olabilir. +Ayrıca, daha fazla geliştiricinin sınırları iyi tanımlanmamış ortak bir kod temeli üzerinde çalışması gerektiğinden, monolitik bir uygulama büyüdükçe geliştiricinin hızı üzerinde bir engel haline gelebilir. + +## Nasıl Yardımcı Olur + +Uygulamayı farklı parçalara bölüp birçok yerde çalıştırırken sistemin bütünü daha fazla arızayı tolere edebilir. +Ayrıca, uygulamanın yatay ölçeklendirme yeteneğinden yararlanmasını sağlar. +Ancak bunun bir bedeli vardır: uygulamada artan karmaşıklık ve operasyonel ek yük. +Bu tarz bir dizaynda tek bir uygulama yerine çok sayıda uygulama bileşeni çalıştırırsınız. diff --git a/content/tr/distributed-systems.md b/content/tr/distributed-systems.md new file mode 100644 index 0000000000..c09022d0d7 --- /dev/null +++ b/content/tr/distributed-systems.md @@ -0,0 +1,27 @@ +--- +title: Dağıtık Sistemler +status: Completed +category: concept +tags: ["mimari", "", ""] +--- + +## Nedir + +Dağıtık sistem, kullanıcılara tek bir sistem olarak görünen, bir ağ üzerinden birbirine bağlanan otonom bilgi işlem ögeleri topluluğudur. +Genel olarak düğüm olarak adlandırılan bu bileşenler, donanım cihazları ya da yazılım süreçleri olabilir. +Düğümler ortak bir hedefe ulaşmak için programlanır ve birlikte çalışmak için ağ üzerinden bilgi alışverişinde bulunurlar. + +## Hangi Sorunları Çözer + +Günümüzde çok sayıda modern uygulama, çalıştırmak için süper bilgisayarlara ihtiyaç duyacak kadar büyüktür. +Gmail ya da Netflix uygulamalarını düşünün. Hiçbir bilgisayar tüm uygulamayı barındıracak kadar güçlü değildir. +Birden fazla bilgisayarın birbirine bağlanmasıyla bilgi işlem gücü neredeyse sınırsız hale gelir. +Dağıtık bilgi işlem olmadan, bugün kullandığımız birçok uygulama mümkün olmazdı.  + +Geleneksel olarak sistemler dikey olarak ölçeklendirilir. Bu, tek bir makineye daha fazla işlemci veya bellek eklediğiniz durumu belirtir. Ancak dikey ölçeklendirme zaman alıcıdır, sistem kesintisi gerektirir ve kapasitesine hızla ulaşır. + +## Nasıl Yardımcı Olur + +Dağıtık sistemler yatay ölçeklendirmeye (örneğin, gerektiğinde sisteme daha fazla düğüm eklenmesi) olanak tanır. Bu, bir sistemin iş yükü veya kaynak tüketimindeki ani artışı idare etmesine olanak tanıyacak şekilde otomatikleştirilebilir.  + +Dağıtık olmayan bir sistem kendini arıza risklerine karşı savunmasız bırakır çünkü bir makine arızalanırsa tüm sistem arızalanır. Dağıtık bir sistem buna önlem olarak tasarlanabilir. Böylece bazı makineler arızalansa bile sistemin tamamı aynı sonucu üretmek için çalışmaya devam edebilir. diff --git a/content/tr/event-driven-architecture.md b/content/tr/event-driven-architecture.md new file mode 100644 index 0000000000..707a1e8ab4 --- /dev/null +++ b/content/tr/event-driven-architecture.md @@ -0,0 +1,26 @@ +--- +title: Olaya Dayalı Mimari +status: Completed +category: concept +tags: ["mimari", "", ""] +--- + +## Nedir + +Olaya dayalı mimari, olayların üretilmesini, işlenmesini ve kullanılmasını destekleyen bir yazılım mimarisidir. +Olay, bir uygulamanın durumunda meydana gelen herhangi bir değişikliktir. +Örneğin, bir araç paylaşım uygulamasında araç çağırmak bir olayı temsil eder. +Bu mimari, olayların kaynaklarından (yolculuk talebinde bulunan uygulama) istenen alıcılara (yakınlardaki uygun sürücülerin uygulamaları) düzgün bir şekilde yönlendirilebileceği bir yapı oluşturur. + +## Hangi Sorunları Çözer + +Daha fazla veri gerçek zamanlı hale geldikçe, olayların yakalanmasını ve olay isteklerini işlemesi gereken uygun hizmete yönlendirilmesini sağlamak için güvenilir yollar bulmak giderek zorlaşır. +Olayları ele almaya yönelik geleneksel yöntemlerde, mesajların uygun şekilde yönlendirildiğini veya gerçekten gönderildiğini ya da alındığını garanti etmenin bir yolu yoktur. +Uygulamalar büyümeye başladıkça, olayları organize etmek daha zor hale gelir. + +## Nasıl Yardımcı Olur + +Olaya dayalı mimariler, tüm olaylar için bir ana merkez oluşturur (örneğin Kafka). +Sonrasında olay üreticilerini (kaynak) ve olay tüketicilerini (alıcı) tanımlarsınız ve ana olay merkezi olayların akışının gerçekleştirilmesini garanti eder. +Bu mimari, hizmetlerin ayrık kalmasını ve olayların üreticiden tüketiciye düzgün şekilde yönlendirilmesini sağlar. +Üretici, genellikle HTTP protokolü ile gelen olayı alır ve olay bilgisini yönlendirir. diff --git a/content/tr/infrastructure-as-code.md b/content/tr/infrastructure-as-code.md new file mode 100644 index 0000000000..ac9bf45518 --- /dev/null +++ b/content/tr/infrastructure-as-code.md @@ -0,0 +1,27 @@ +--- +title: Kod Olarak Altyapı (IaC) +status: Completed +category: concept +tags: ["altyapı", "yöntem", ""] +--- + +## Nedir + +Kod olarak altyapı _(Infrastructure as Code - IaC)_, altyapı tanımının bir veya daha fazla dosya olarak saklanması uygulamasıdır. +Bu, servis olarak altyapının _(Infrastructure as a Service - IaaS)_ genellikle +bir shell script veya diğer yapılandırma araçları aracılığıyla manuel olarak oluşturulduğu geleneksel modelin yerini alır. + +## Hangi Sorunları Çözer + +Uygulamaları bulut tabanlı bir şekilde geliştirmek, altyapının tek kullanımlık ve tekrarlanabilir olmasını gerektirir. +Ayrıca bu uygulamaların insan müdahalesine gerek kalmadan, ihtiyaca bağlı olarak otomatik +ve tekrarlanabilir bir şekilde ölçeklendirilmesi gerekir. +Altyapı kaynaklarının manuel olarak oluşturulması, bulut tabanlı uygulamaların yanıt verme ve ölçeklendirme gereksinimlerini karşılayamaz. +Manuel altyapı değişiklikleri tekrarlanamaz, hızla ölçek sınırlarına ulaşır ve yanlış yapılandırma hatalarına neden olur. + +## Nasıl Yardımcı Olur + +Sunucular, yük dengeleyiciler ve alt ağlar gibi veri merkezi kaynaklarının kod olarak temsil edilmesi, +altyapı ekiplerinin tüm yapılandırmalar için tek bir doğruluk kaynağına sahip olmalarını sağlar +ve aynı zamanda versiyon kontrolü ve dağıtım stratejilerini uygulayarak veri merkezlerini +bir CI/CD hattında yönetmelerine olanak tanır. diff --git a/content/tr/kubernetes.md b/content/tr/kubernetes.md new file mode 100644 index 0000000000..0dcfe46ef9 --- /dev/null +++ b/content/tr/kubernetes.md @@ -0,0 +1,35 @@ +--- +title: Kubernetes +status: Completed +category: technology +tags: ["altyapı", "temel kavram", ""] +--- + +## Nedir + +Kubernetes, genellikle K8s olarak kısaltılan, açık kaynaklı bir konteyner orkestratörüdür. +Modern altyapılarda konteynerleştirilmiş uygulamaların yaşam döngüsünü otomatikleştirir ve bir "veri merkezi işletim sistemi" olarak işlev görerek uygulamaları dağıtık bir sistem üzerinde yönetir. + +Kubernetes, [konteynerleri](../container/) bir [küme](../cluster/) içindeki [düğümler](../nodes/) üzerine planlar ve yük dengeleyici ve kalıcı depolama gibi birkaç altyapı kaynağını bir araya getirerek konteynerleştirilmiş uygulamaları çalıştırır. + +Kubernetes, kullanıcıların uygulamaları bildirimsel (aşağıya bakınız) ve tekrarlanabilir bir şekilde dağıtmalarına olanak tanıyan bir otomasyon ve genişletilebilirlik sağlar. +Kubernetes, [API’si](../application-programming-interface/) aracılığıyla genişletilebilir, bu da tecrübeli Kubernetes kullanıcılarının kendi ihtiyaçlarına göre otomasyon yeteneklerinden faydalanmalarına olanak tanır. + +## Hangi Sorunları Çözer + +Altyapı otomasyonu ve bildirimsel yapılandırma yönetimi uzun süredir önemli kavramlar idi, ancak [bulut bilişim](../cloud-computing/) popülerlik kazandıkça daha önemli hale geldiler. +Bilişim kaynaklarına olan talep arttıkça ve organizasyonlar daha az mühendisle daha fazla operasyonel yeteneğe sahip olmak zorunda kalırken, bu talebi karşılamak için yeni teknolojilere ve çalışma yöntemlerine ihtiyaç duyulmaktadır. + +## Nasıl Yardımcı Olur + +Geleneksel [kod olarak altyapı](../infrastructure-as-code/) (IaC) araçlarına benzer şekilde, Kubernetes de otomasyona yardımcı olur. Ancak konteynerlerle çalışma avantajına sahiptir. +Konteynerler, sanal veya fiziksel makinelere göre, yapılandırma sapmasına daha dayanıklıdır. + +Ayrıca, Kubernetes bildirimsel olarak çalışır, yani operatörler bir şeyi nasıl yapılacağının talimatını vermek yerine altyapının nasıl görünmesi gerektiğini açıklarlar (genellikle manifest dosyaları örneğin, YAML dosyası, olarak). +Kubernetes ardından "nasıl" ile ilgilenir. +Bu, Kubernetes'in kod olarak altyapı (IaC) ile son derece uyumlu olmasına neden olur. + +Kubernetes aynı zamanda kendi kendini iyileştirir. +Kümenin gerçek durumu her zaman operatörün istenen durumuyla eşleşir. +Kubernetes, manifest dosyalarında tanımlanan şeyden sapma algıladığında, bir Kubernetes denetleyicisi devreye girer ve bunu düzeltir. +Kubernetes'in kullandığı altyapı sürekli değişebilir, ancak Kubernetes daima ve otomatik olarak değişikliklere adapte olur ve istenen durumla eşleştiğinden emin olur. diff --git a/content/tr/microservices-architecture.md b/content/tr/microservices-architecture.md new file mode 100644 index 0000000000..6a418c108f --- /dev/null +++ b/content/tr/microservices-architecture.md @@ -0,0 +1,37 @@ +--- +title: Mikroservis Mimarisi +status: Completed +tags: ["altyapı", "temel kavram", ""] +--- + +## Nedir + +Mikroservis mimarisi, uygulamaları birbirinden bağımsız (mikro)servislere ayıran, her bir servisin belirli bir işlevselliğe odaklandığı bir mimari yaklaşımdır. +Bu servisler birbirleriyle yakın bir şekilde çalışır ve kullanıcıya tek bir sistem gibi görünür. +Netflix'i bir örnek olarak alalım. +Arayüzü, videolara erişim, arama ve önizleme yapmanıza izin verir. +Bu yetenekler muhtemelen tarayıcınızda oturum açma, arama ve önizleme çalıştırmak gibi belirli kabiliyetleri ele alan daha küçük servisler tarafından desteklenmektedir. + +Bu mimari yaklaşım, geliştiricilere yeni özellikleri hızlı bir şekilde yayınlama veya işlevselliği güncelleme olanağı tanır, bu da tümüyle birbirine sıkıca bağlı olan monolitik (aşağıda anlatılıyor) bir uygulama durumunda mümkün olmazdı. + +## Hangi Sorunları Çözer + +Uygulamalar, her biri belirli bir kabiliyetten sorumlu farklı parçalardan oluşur. +Belirli bir işlevsellik için talep, diğer uygulama parçalarına olan talep ile aynı oranda artmayabilir veya azalmayabilir. +Netflix örneğimize geri dönelim. +Diyelim ki büyük bir pazarlama kampanyasının ardından Netflix, kayıtlarda büyük bir artış yaşadı, ancak günün erken saatlerinde yayınlanan içerikler nispeten sabit kaldı. +Kayıtlardaki bu artış, daha fazla kayıt kabiliyeti kapasitesi gerektirir. +Geleneksel olarak (monolitik yaklaşım), artışı karşılamak için tüm uygulamanın ölçeklendirilmesi gerekecekti. Bu da oldukça verimsiz bir kaynak kullanımı anlamına gelirdi. + +Monolitik mimariler ayrıca geliştiricilerin tasarım hatalarına düşmesini kolaylaştırır. +Çünkü tüm kod aynı yerde bulunur, bu kodu sıkıca bağlamak daha kolay hale gelir ve sorumlulukların ayrılma prensibini uygulamak daha zorlaşır. +Monolitler genellikle geliştiricilere herhangi bir değişiklik yapmadan önce tüm kod tabanını anlamalarını gerektirir. +Mikroservis mimarisi, bu zorluklara bir yanıttır. + + +## Nasıl Yardımcı Olur + +İşlevsellik farklı mikroservislere ayırmak, bunları bağımsız bir şekilde dağıtmayı, güncellemeyi ve ölçeklendirmeyi kolaylaştırır. +Ayrıca farklı ekiplerin daha büyük bir uygulamanın küçük bir bölümünde aynı anda çalışmasına izin verir, böylece uygulamanın geri kalan kısmını yanlışlıkla olumsuz etkileme riskini azaltır. +Mikroservis mimarisi birçok sorunu çözerken, operasyonel ek iş yükü de yaratır. Böylece dağıtmanız ve izlemeniz gereken şeyler büyük ölçüde artar. +Birçok [bulut-tabanlı teknoloji](../cloud-native-tech/), mikroservisleri daha kolay dağıtmayı ve yönetmeyi amaçlar. diff --git a/content/tr/mutual-transport-layer-security.md b/content/tr/mutual-transport-layer-security.md new file mode 100644 index 0000000000..2c8c72d88a --- /dev/null +++ b/content/tr/mutual-transport-layer-security.md @@ -0,0 +1,17 @@ +--- +title: Mutual Transport Layer Security (mTLS) +status: Completed +category: Concept +tags: ["güvenlik", "ağ", ""] +--- + +Karşılıklı TLS (mTLS), iki servis arasında gönderilen mesajların kimliğini doğrulamak ve şifrelemek için kullanılan bir tekniktir. mTLS, TLS protokolüdür ama yalnızca bir bağlantının kimliğini doğrulamak yerine her iki tarafınki de doğrulanır. + +## Hangi Problemi Çözer + +Mikroservisler bir ağ üzerinden iletişim kurar ve tıpkı kablosuz ağınız gibi ağ üzerinden yapılan iletişim de saldırıya uğrayabilir. mTLS, yetkisiz tarafların meşru istekleri dinleyememesini veya taklit edememesini sağlar. +mTLS ensures that no unauthorized party can listen in on or impersonate legitimate requests. + +## Nasıl Yardımcı Olur + +mTLS, bir ağda veya uygulamalarda oturum açan kullanıcılar için ek bir güvenlik katmanı sağlayarak istemci ve sunucu arasındaki trafiğin her iki yönde de güvenli ve güvenilir olmasını sağlar. Ayrıca nesnelerin interneti (IoT) cihazları gibi oturum açma sürecini takip etmeyen istemci cihazlarıyla olan bağlantıları da doğrular. Yol üzerindeki saldırılar, kimlik sahtekarlığı saldırıları, kimlik bilgileri doldurma, kaba kuvvet saldırıları vb. saldırılar mTLS tarafından önlenebilir. diff --git a/content/tr/nodes.md b/content/tr/nodes.md new file mode 100644 index 0000000000..ae8f594e1c --- /dev/null +++ b/content/tr/nodes.md @@ -0,0 +1,28 @@ +--- +title: Düğümler (Nodes) +status: Completed +category: Concept +tags: ["altyapı", "temel kavram", ""] +--- + +## Nedir + +Bir düğüm, ortak bir görevi gerçekleştirmek için diğer bilgisayarlar veya düğümlerle birlikte çalışan bir bilgisayardır. +Örneğin, dizüstü bilgisayarınız, modeminiz ve yazıcınızı düşünün. +Hepsi wifi ağınız üzerinden bağlıdır, iletişim kurar ve işbirliği yapar; her biri bir düğümü temsil eder. +[Bulut bilişimde](../cloud-computing/) bir düğüm, fiziksel bir bilgisayar, +sanal bir bilgisayar (VM) ve hatta bir [konteyner](../container/) olabilir. + +## Hangi Sorunları Çözer + +Bir uygulama tek bir makinede çalışabilir (ve birçok uygulama bunu yapar), ancak bununla bazı riskler beraberinde gelir. +Özellikle, temel sistemdeki bir arıza uygulamayı bozabilir. +Geliştiriciler bu sorunu çözmek için, her işlemin kendi düğümünde çalıştığı dağıtılmış uygulamalar oluşturmaya başladılar. +Bu nedenle, düğümler, bir araya gelerek ortak bir hedefe ulaşmak için bir [küme](../cluster/) veya grup oluşturan uygulamaları veya işlemleri çalıştırırlar. + +## Nasıl Yardımcı Olur + +Bir düğüm, bir kümeye atanabilen belirgin bir bilişim kaynağı (bellek, işlemci, ağ) sunar. +[Cloud native](../cloud-native-tech/) bir platformda veya uygulamada bir düğüm, işi gerçekleştirebilen tek bir birimi temsil eder. +İdeal olarak, her bir düğüm, belirli bir türdeki herhangi +bir diğer düğümden ayırt edilemeyecek şekilde farklılık göstermez. diff --git a/content/tr/observability.md b/content/tr/observability.md new file mode 100644 index 0000000000..f65a15523c --- /dev/null +++ b/content/tr/observability.md @@ -0,0 +1,18 @@ +--- +title: Gözlemlenebilirlik +status: Completed +category: Concept +tags: ["özellik", "", ""] +--- + +Gözlemlenebilirlik, sistemin işlemeye uygun sezgiler üretebilme derecesini tanımlayan bir sistem özelliğidir. +Kullanıcılara sistemin durumunu bu harici çıktılardan anlama ve (düzeltici) önlemler alma imkanı sağlar. + + +Bilgisayar sistemleri, CPU zamanı, bellek, disk alanı gibi düşük seviyeli sinyalleri ve API yanıt süreleri, hata sayısı, saniyede işlem sayısı gibi daha yüksek seviyeli ve işle ilgili sinyalleri gözlemleyerek ölçülür. +Bu gözlemlenebilir sistemler, özel araçlar, yine bu alana özgü olarak adlandırılan gözlemlenebilirlik araçları aracılığıyla **gözlemlenir** (ya da izlenir). +Bu araçların bir listesine [Cloud Native Landscape'in gözlemlenebilirlik bölümü](https://landscape.cncf.io/card-mode?category=observability-and-analysis&grouping=category)nden ulaşabilirsiniz. + +Gözlemlenebilir sistemler, operatörlerine anlamlı ve işlemeye uygun veriler sağlayarak olumlu sonuçlara ulaşmalarını (problemlere daha hızlı yanıt verme, artan geliştirici üretkenliği) ve uğraş zamanları ile kesinti sürelerini azaltmalarını sağlar. + +Sonuç olarak, bir sistemin ne kadar gözlemlenebilir olduğu, işletme ve geliştirme maliyetlerini önemli ölçüde etkileyecektir. diff --git a/content/tr/reliability.md b/content/tr/reliability.md new file mode 100644 index 0000000000..ee32def90e --- /dev/null +++ b/content/tr/reliability.md @@ -0,0 +1,12 @@ +--- +title: Güvenilirlik +status: Completed +category: property +tags: ["temel kavram", "özellik", ""] +--- + +Cloud native perspektifinden bakıldığında güvenilirlik, bir sistemin arızalara ne kadar iyi yanıt verdiğini ifade eder. Altyapı değiştikçe ve tekil bileşenler arızalandıkça çalışmaya devam eden dağıtık bir sistemimiz varsa, +bu sistem güvenilirdir. +Öte yandan, sistem kolayca arızalanıyorsa ve operatörlerin sistemi çalışır durumda tutmak için +manuel olarak müdahale etmesi gerekiyorsa, bu sistem güvenilir değildir. +Cloud native uygulamaların amacı, doğası gereği güvenilir sistemler oluşturmaktır. diff --git a/content/tr/search.md b/content/tr/search.md new file mode 100644 index 0000000000..d9a4d5beef --- /dev/null +++ b/content/tr/search.md @@ -0,0 +1,4 @@ +--- +title: Search Results +layout: search +--- \ No newline at end of file diff --git a/content/tr/site-reliability-engineering.md b/content/tr/site-reliability-engineering.md new file mode 100644 index 0000000000..6939df90ad --- /dev/null +++ b/content/tr/site-reliability-engineering.md @@ -0,0 +1,30 @@ +--- +title: Site Güvenilirlik Mühendisliği (SRE) +status: Completed +category: concept +tags: ["yöntem", "", ""] +--- + +## Nedir + +Site Güvenilirlik Mühendisliği / Site Reliability Engineering (SRE), operasyon ve yazılım mühendisliğini bir araya getiren bir disiplindir. +Özetle, yazılım mühendisliğinin altyapı ve operasyon işlerine uygulanmasıdır. +SRE mühendisleri ürün özellikleri geliştirmek yerine, uygulamaları çalıştırmak için sistemler oluştururlar. +DevOps ile benzerlikleri vardır, ancak DevOps kodu üretim ortamına taşımaya odaklanırken, +SRE canlı ortamda çalışan kodun düzgün çalışmasını sağlar. + +## Hangi Sorunları Çözer + +Uygulamaların güvenilir bir şekilde çalışmasını sağlamak, performans izleme, uyarı sistemleri kullanma, hata ayıklama +ve sorun giderme gibi bir dizi yetenek gerektirir. +Bunlar olmadan, sistem operatörleri etkin ve öngörülü olarak sorunları önlemeye çalışmak yerine sadece çıkan +sorunları çözmeye uğraşırlar. +Bu durumda da bir sistem kesintisi yaşanması sadece bir an meselesi haline gelir. + +## Nasıl Yardımcı Olur + +SRE yaklaşımı, temel sistemleri sürekli olarak iyileştirerek yazılım geliştirme sürecinin maliyetini, +zamanını ve çabasını en aza indirir. +Sistem sürekli olarak altyapı ve uygulama bileşenlerini ölçer ve izler. +Bir şey yanlış gittiğinde sistem, SRE mühendislerine sorunu nerede, ne zaman ve nasıl düzelteceklerini gösterir. +Bu yaklaşım, operasyonel görevleri otomatize ederek yüksek ölçekli ve güvenilir yazılım sistemleri oluşturmaya yardımcı olur. diff --git a/content/tr/stateful-apps.md b/content/tr/stateful-apps.md new file mode 100644 index 0000000000..f643c6b4a8 --- /dev/null +++ b/content/tr/stateful-apps.md @@ -0,0 +1,17 @@ +--- +title: Durum Bilgisine Sahip Uygulamalar +status: Completed +category: concept +tags: ["temel kavram", "uygulama", ""] +--- + +Durum bilgisine sahip (stateful) ve durum bilgisine sahip olmayan (stateless) uygulamalardan bahsettiğimizde durum (state), uygulamanın tasarlandığı gibi çalışması için saklaması gereken verileri ifade eder. +Örneğin, alışveriş sepetinizi hatırlayan herhangi bir çevrimiçi mağaza durum bilgisi olan bir uygulamadır. + +Günümüzde kullandığımız çoğu uygulama en azından kısmen durum bilgisine sahip uygulamalardır. +Ancak cloud native ortamlarında durum bilgisine sahip uygulamalar zorluk oluşturur. +Bunun nedeni cloud native uygulamalarının çok dinamik olmasıdır. +Cloud native uygulamalar ölçeklendirilebilir, yeniden başlatılabilir ve yer değiştirebilirler. +Ancak yine de durumlarına erişebilmeleri gerekir. + +Bu yüzden, durum bilgisine sahip uygulamalar, veritabanları gibi her yerden erişilebilen bir tür depolama alanına ihtiyaç duyarlar. diff --git a/content/tr/style-guide/_index.md b/content/tr/style-guide/_index.md new file mode 100644 index 0000000000..923ed0608b --- /dev/null +++ b/content/tr/style-guide/_index.md @@ -0,0 +1,185 @@ +--- +title: Stil Kılavuzu +toc_hide: true +status: Completed +menu: + main: + weight: 10 +--- + +Bu stil kılavuzu, Sözlük hedef kitlesini, tanım yapısını, gerekli ayrıntı düzeyini ve tutarlı bir stili nasıl koruyacağınızı anlamanıza yardımcı olacaktır. + +Cloud Native Sözlüğü, CNCF repository’sinin [varsayılan stil kılavuzunu](https://github.com/cncf/foundation/blob/master/style-guide.md) takip eder. Bunlara ek olarak, aşağıdaki kurallara uyar: + +1. Teknik jargon ve moda sözcüklerden kaçınarak basit ve erişilebilir bir dil kullanın +2. [Gündelik konuşma dilinden](https://tr.wikipedia.org/wiki/G%C3%BCnl%C3%BCk_dil) kaçının +3. Mecazi olmayan, somut bir dil kullanın +4. Kısaltmalardan kaçının +5. [Edilgen dili](https://sozluk.gov.tr/?/edilgen+fiil) idareli kullanın +6. İfadeleri olumlu bir biçimde ifade etmeyi hedefleyin +7. Alıntılar dışında ünlem işaretini kullanmayın +8. Abartılı bir dil kullanmayın +9. Tekrardan kaçının +10. Kısa ve öz olun + +## Hedef Kitle + +Sözlük, teknik ve teknik olmayan herkes için yazılmıştır. Lütfen tanımları basit terimlerle açıklayın ve okuyucunun teknik bilgiye sahip olduğunu varsaymayın. +Konu ile ilgili daha fazla bilgi aşağıda [Tanım](#tanım) bölümünde yer almaktadır. + +## Asgari geçerli tanım + +Cloud Native terimlerini herkesin anlamasını kolaylaştırmayı amaçlıyoruz. +Bu sebeple sadeliğe odaklanıyoruz. +En azından teknik açıdan geçerli *asgari bir tanım* sağlarken, teknolojiyi kullanan herkesin ilişkilendirebileceği örneklerle açık ve basit bir dil kullanın. +Bağlam ve örneklerden tasarruf etmek istemiyoruz - sonuçta bunlar okuyucunun kavramı anlamasına yardımcı oluyor - ancak, kavramı anlamak için teknik bir ayrıntıyı anlatmak gerekmiyorsa, bu ayrıntıyı es geçebiliriz. +Burada amaç, işleri olduğundan daha fazla bir karışıklığa getirmemek. +Okuyucu, temel fikri anladığında başka kaynakları kullanarak konu hakkında daha detaylı bilgi edinebilir. +Bu kısım, sözlüğün kapsamının dışında kalmaktadır. + +## Tanım şablonu + +Her sözlük terimi bir markdown dosyasında tutulur ve aşağıdaki şablonu takip eder: + +```md +--- +title: +status: +category: +--- + +## Nedir + +Teknoloji veya konseptin hızlı bir özeti. + +## Hangi Sorunları Çözer + +Ele aldığı sorunla ilgili birkaç satır. + +## Nasıl Yardımcı Olur + +Bu kavramın sorunu nasıl çözdüğüne dair birkaç satır. +``` + +### Başlık + +**Title** etiketi bir tanım düzeninin her zaman en üstünde bulunur ve karşılık değeri başlık biçiminde yazılmalıdır. + +```md +--- +title: Tanım Şablonu +``` + +### Durum + +**Status** etiketi, title etiketinden sonra gelir. Bu etiket, tanımı tamamlamak için gereken eforu belirtir. + +Geçerli değerleri şunlardır: + +- Completed (Tamamlandı) +- Feedback Appreciated (Geribildirim memnun eder) +- Not Started (Başlanmadı) + +Tamamlanmış bir tanım için her zaman yeni bir issue açabilirsiniz. Bir tanım değişim halindeyken, durumu *Feedback Appreciated* şeklinde değiştirilecektir. + +```md +--- +title: Tanım Şablonu +status: Feedback Appreciated +``` + +### Etiketler + +**Tag** etiketi, **status** etiketinin hemen sonrasında gelir. +Bu etiketlerin anlamlı ve kullanıcıya yardımcı olabilmesi için, etiketleri tam anlamlarıyla ve yeterince kullanıyoruz. +Gereğinden fazla etiket kullanımı, etiketi amacından uzaklaştıracaktır. +Bu konudaki tek istisna, `fundamental` etiketidir. +Bu etiket, bulunduğu kavramın diğer cloud native kavramlarını anlayabilmek için gerekli olduğu anlamını taşır. +Diğer birçok terim, büyük çoğunlukla tek etikete sahip olacaktır. + +**Not**: Proje geliştiricileri tarafından onaylanmadıkça yeni etiket kullanmayınız. Bir sayfaya etiket eklediğinizde, etiketi doğru yazdığınızdan emin olunuz. Etiketler, tekil şekilde kullanılmalıdır. + +Var olan etiketler aşağıdaki gibidir: + +- application +- architecture +- fundamental +- infrastructure +- methodology +- networking +- property +- security + +```md +--- +title: Tanım Şablonu +status: Feedback Appreciated +tags: ["tag 1", "tag 2", ""] +--- +``` + +### Tanım + +#### Üç alt başlık + +**Teknoloji** ve **konsept** kategorisindeki tanımlarda üç alt başlık mevcuttur: + +- **Nedir**: Konu hakkında kısa ve açık bir genel özet verin. +- **Hangi Sorunları Çözer**: Çözüme değil, probleme odaklanın. Çözüm bir sonraki bölümde olacaktır. Tanımlanan terimden bahsetmekten kaçının. Bahsettiğimiz problemler, *nelerin* bizi tanımladığımız kavrama ulaştırdığına odaklanın. +- **Nasıl Yardımcı Olur**: Şimdi, tanımladığımız terime dönerek yukarıda bahsettiğimiz problemleri nasıl ele aldığından bahsedin. + +Özelliklerin ayrı bölümler gerektirmediğini unutmayın. Bir tanım yeterli olacaktır. + +İncelemeyi kolaylaştırmak için lütfen satır başına bir cümle, yani [anlama bağlı satır sonları](https://sembr.org/) kullanmaya gayret gösterin. + +#### Kalite her şeyden önemli + +Gönderiminiz birleştirilirse, o terim için resmi CNCF tanımı olacaktır (ta ki, başka biri onu geliştirene kadar). +CNCF'nin yüksek standartlarını karşılayan bir terim oluşturmak aceleye getirilemez; kalite zaman ve çaba gerektirir. + +**Araştırmanızı yapın**. Terimi bildiğinizden emin olsanız bile, doğru anladığınızdan emin olun. +Kuruluşlar içinde, terimleri genellikle resmin tamamını yansıtmayabilecek bir şekilde kullanırız. +Araştırma yaparken, özellikle terime %100 aşina değilseniz birden çok kaynak kullanın. +Pek çok tanım, özellikle bir şirket tarafından sağlanıyorsa, tek taraflıdır. Sözlük satıcıdan bağımsız, dünya çapında kabul görmüş tanımlar içermelidir. + +**İntihal yapmayın**. Diğer ciddi yayınlar için geçerli olan aynı kurallar Sözlük için de geçerlidir. +Alıntı yapmadığınız ve onlara katkıda bulunmadığınız sürece başkalarının çalışmalarını kopyalayıp yapıştırmayın. +Bir tanımın belirli bir bölümünü beğendiyseniz, onu kendi sözcüklerinizle açıklayın. + +**Yetkili kaynakları referans verin**. Mümkün olduğunca, proje belgeleri gibi yetkili kaynaklara bağlantı verin. +Şirketler tarafından geliştirilen içeriklere bağlantı veremeyeceğimizi unutmayın. + +#### Basit tutun + +Sözlük, **karmaşık kavramları basit sözcüklerle açıklamayı** amaçlar; bu, muhtemelen birden fazla revizyon gerektirecek, şaşırtıcı derecede zor bir iştir. +Tanımınızı hazırlarken daima hedef kitleyi aklınızda bulundurun. +Sektör terimlerini ve moda sözcükleri kullanmaktan kaçının; kendinizi bunlara dönerken yakalayabilir ve farklı terimler aramak için kendinizi eğitmeniz gerekebilir. + +Uygun olduğunda, okuyucuların (özellikle teknik olmayanların) açıkladığınız fikrin *ne zaman* ve *neden* alakalı olduğunu daha iyi anlamalarına yardımcı olacak **gerçek dünyadan örnekler** kullanın. + +Tanımınızda kullanıldığında, her zaman **mevcut sözlük terimlerine bağlantı verin** (yalnızca ilk bahsedilen yerde bağlantı verilmelidir). + +#### Bir Google veya Word belgesi ile başlayın + +Bir Google Docs veya Word belgesiyle başlamanızı, birkaç gün bekletmenizi ve yeniden gözden geçirmenizi öneririz. +Bu yöntem, daha basit ve erişilebilir bir şekilde ifade edilebilecek cümleleri veya ifadeleri yakalamanıza olanak tanır. +Ayrıca, bir PR göndermeden önce bir yazım denetimi yaptığınızdan emin olun. + +Bir dönem üzerinde çalışırken başka bir kimsenin PR göndermediğinden emin olmak için bir issue talep edin (veya bir tane oluşturun) ve size atanmasını isteyin. +[Nasıl Katkıda Bulunulur](/tr/contribute/) belgesinde bununla ilgili daha fazla bilgi bulabilirsiniz. + +Başlamadan önce, ayrıntı düzeyi, zorluk düzeyi ve örneklerin ne zaman uygun olduğu konusunda bir fikir edinmek için lütfen yayınlanmış bazı Sözlük terimlerini okuyun. + +## İnceleme süreci: Ne beklemeli? + +Lütfen boş zamanlarında bu işi yapan kısıtlı sayıda geliştiriciler olduğumuzu unutmayın. +Zaman zaman kavramları hızlı bir şekilde gözden geçirebiliriz; diğer durumlarda ise bu biraz zaman alabilir. +Sabrınız için teşekkür ederiz. +Herhangi bir sorunuz olursa, lütfen [#glossary](https://cloud-native.slack.com/archives/C02TX20MQBB) Slack kanalından, +Türkçe çeviriler için ise [#glossary-localizations-turkish](https://cloud-native.slack.com/archives/C05ATBGLHJ7) kanalından, +bizimle iletişime geçin (nerede ve nasıl bulacağınız için lütfen [Nasıl Katkıda Bulunulur](/tr/contribute/) belgemize bakın). + +Hedefimiz, Sözlüğün mümkün olan en iyi kaynak olmasıdır. +Bir PR gönderdikten sonra, bir veya daha fazla revizyon isteyebiliriz. +Hayal kırıklığına uğramayın - birçok PR için durum budur. +Bu gidip gelmeler ve işbirliğimiz, katkınızın dünyanın her yerindeki okuyucular tarafından okunan ve atıfta bulunulan faydalı bir tanım olmasını sağlayacaktır. diff --git a/content/tr/transport-layer-security.md b/content/tr/transport-layer-security.md new file mode 100644 index 0000000000..a05cee2993 --- /dev/null +++ b/content/tr/transport-layer-security.md @@ -0,0 +1,16 @@ +--- +title: Transport Layer Security (TLS) +status: Completed +category: Concept +tags: ["güvenlik", "ağ", ""] +--- + +TLS, bir ağ üzerindeki iletişimin güvenliğini yükseltmeyi sağlayan bir protokoldür. İnternet üzerinden gönderilen verinin güvenli teslim edilmesini sağlayarak gözlenip değiştirilmesini önler. Mesajlaşma, e-posta gibi uygulamalarda yaygın olarak kullanılan bir protokoldür. + +## Hangi Sorunları Çözer + +TLS olmadan tarama alışkanlıkları, e-posta yazışmaları, çevrimiçi sohbetler ve konferans çağrıları gibi hassas bilgiler, iletişim sırasında başkaları tarafından kolaylıkla takip edilebilir ve değiştirilebilir. Sunucu ve istemci uygulamalarının TLS’yi desteklemesini sağlamak, aralarında iletilen verilerin şifrelenmesini ve üçüncü şahıslar tarafından görüntülenememesini sağlar. + +## Nasıl Yardımcı Olur + +TLS, verileri ağ üzerinden iletirken güvenlik sağlayan kodlama tekniklerinin bir kombinasyonunu kullanır. TLS, istemci uygulaması ile sunucu arasında şifreli bağlantıya izin verir. Örneğin; bir web tarayıcısı ve bir bankacılık sitesi gibi… Ayrıca istemci uygulamalarının aradıkları sunucuyu kesin olarak tanımlamasına da olanak tanır, bu da istemcinin sahte bir siteyle iletişime geçme riskini azaltır. Bu, uygulamalar arasında TLS kullanarak iletilen kredi kartı, numaralar, şifreler, konum vb. hassas ve özel bilgileri koruyan verileri üçüncü tarafların görememesini ve izleyememesini sağlar. diff --git a/content/tr/virtualization.md b/content/tr/virtualization.md new file mode 100644 index 0000000000..ff67a00724 --- /dev/null +++ b/content/tr/virtualization.md @@ -0,0 +1,30 @@ +--- +title: Sanallaştırma +status: completed +category: technology +tags: ["temel kavram", "altyapı", "yöntem"] +--- + +Cloud native bilişimi bağlamında sanallaştırma, +bazen sunucu olarak da adlandırılan fiziksel bir bilgisayarın +birden fazla yalıtılmış işletim sistemi çalıştırmasına imkan sağlayan süreci ifade eder. +Bu yalıtılmış işletim sistemleri ve bu sistemler için ayrılmış bilişim kaynakları (işlemci, bellek, ve ağ), +sanal makineler (Virtual Machines) veya VM’ler olarak adlandırılır. +Bir [sanal makine](#)den bahsettiğimizde, yazılım ile tanımlanmış bir bilgisayardan bahsediyoruz. +Bu, gerçek bir bilgisayar gibi görünen ve davranan ancak donanımı diğer sanal makinelerle paylaşan bir şeydir. +[Bulut bilişim](/tr/cloud-computing/), aslında sanallaştırma teknolojisi tarafından desteklenmektedir. +Örnek olarak, AWS'den bir "bilgisayar" kiralayabilirsiniz; bu bilgisayar aslında bir VM'dir. + +## Hangi Sorunları Çözer + +Sanallaştırma, aynı fiziksel makinede birden fazla uygulamanın +güvenlik amacıyla birbirinden yalıtılmış halde çalışmasına izin vererek +donanım kullanımının iyileştirilmesi de dahil olmak üzere bir dizi sorunu giderir. + + +## Nasıl Yardımcı Olur + +Sanal makinelerde çalışan uygulamalar, fiziksel bir bilgisayarı paylaştıklarının farkında değildir. +Sanallaştırma aynı zamanda veri merkezi kullanıcılarının, veri merkezine yeni bir bilgisayar eklemenin +fiziksel kısıtlamaları konusunda endişelenmeden yeni bir "bilgisayar"ı (diğer adıyla VM) +birkaç dakika içinde çalıştırmasına olanak tanır. diff --git a/content/ur/search.md b/content/ur/search.md new file mode 100644 index 0000000000..d9a4d5beef --- /dev/null +++ b/content/ur/search.md @@ -0,0 +1,4 @@ +--- +title: Search Results +layout: search +--- \ No newline at end of file diff --git a/content/zh-cn/search.md b/content/zh-cn/search.md new file mode 100644 index 0000000000..d9a4d5beef --- /dev/null +++ b/content/zh-cn/search.md @@ -0,0 +1,4 @@ +--- +title: Search Results +layout: search +--- \ No newline at end of file diff --git a/content/zh-tw/search.md b/content/zh-tw/search.md new file mode 100644 index 0000000000..d9a4d5beef --- /dev/null +++ b/content/zh-tw/search.md @@ -0,0 +1,4 @@ +--- +title: Search Results +layout: search +--- \ No newline at end of file diff --git a/i18n/bn.toml b/i18n/bn.toml index 225cc1fb3a..49e637d803 100644 --- a/i18n/bn.toml +++ b/i18n/bn.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] diff --git a/i18n/es.toml b/i18n/es.toml index 838b843740..2e25ffc3a3 100644 --- a/i18n/es.toml +++ b/i18n/es.toml @@ -26,7 +26,7 @@ other = "Etiqueta" [ui_tags] other = "Etiquetas" [ui_search_by_tags] -other = "Browse by Tags" +other = "Navegar por Etiquetas" [ui_tags_intro] other = "Hemos clasificado los términos del glosario. Utiliza los filtros para buscar términos por etiqueta." [ui_or_search_by_tags] diff --git a/i18n/ja.toml b/i18n/ja.toml new file mode 100644 index 0000000000..ed7e51c80b --- /dev/null +++ b/i18n/ja.toml @@ -0,0 +1,87 @@ + + +# UI strings. Buttons and similar. + +[ui_pager_prev] +other = "前へ" + +[ui_pager_next] +other = "次へ" + +[ui_read_more] +other = "続きを読みます" + +[ui_search] +other = "サイト検索…" + +# Used in sentences such as "Posted in News" +[ui_in] +other = "に" + +# Phrases for tags +[ui_see_all_tags] +other = "全てのタグを見ます" +[ui_tag] +other = "Tag" +[ui_tags] +other = "Tags" +[ui_search_by_tags] +other = "タグで閲覧します" +[ui_tags_intro] +other = "用語集の用語を分類しています。フィルターを使って、タグごとに用語を閲覧することができます。" +[ui_or_search_by_tags] +other = "...またはタグで閲覧します" +[ui_select_all] +other = "全てを選択します" +[ui_deselect_all] +other = "全ての選択を解除します" + +# Footer text +[footer_all_rights_reserved] +other = "All Rights Reserved" + +[footer_privacy_policy] +other = "プライバシーポリシー" + +[footer_hub_button_text] +other = "全てのCNCFサイト" + +# Post (blog, articles etc.) +[post_byline_by] +other = "によって" +[post_created] +other = "作成されました" +[post_last_mod] +other = "最終更新日" +[post_edit_this] +other = "このページを編集します" +[post_create_child_page] +other = "子ページを作成します" +[post_create_issue] +other = "issueを報告します" +[post_create_project_issue] +other = "プロジェクトissueを作成します" +[post_posts_in] +other = "内の投稿" +[post_reading_time] +other = "読んだ時間(分)" + +# Print support +[print_printable_section] +other = "このセクションの複数ページ印刷用ビューです" +[print_click_to_print] +other = "印刷する場合はこちらをクリックしてください" +[print_show_regular] +other = "このページの通常の表示に戻ります" +[print_entire_section] +other = "セクション全体をプリントします" + +# Feedback section +[feedback_title] +other = "フィードバック" +[feedback_question] +other = "このページは役に立ちましたか?" +[feedback_answer_yes] +other = "はい" +[feedback_answer_no] +other = "いいえ" diff --git a/i18n/ru.toml b/i18n/ru.toml new file mode 100644 index 0000000000..fae8370519 --- /dev/null +++ b/i18n/ru.toml @@ -0,0 +1,87 @@ + + +# UI strings. Buttons and similar. + +[ui_pager_prev] +other = "Пред." + +[ui_pager_next] +other = "След." + +[ui_read_more] +other = "Подробнее" + +[ui_search] +other = "Поиск по сайту" + +# Used in sentences such as "Posted in News" +[ui_in] +other = "в" + +# Phrases for tags +[ui_see_all_tags] +other = "Смотреть все теги" +[ui_tag] +other = "Тег" +[ui_tags] +other = "Теги" +[ui_search_by_tags] +other = "Фильтр по тегам" +[ui_tags_intro] +other = "Термины глоссария разбиты по категориям. Используйте фильтры для просмотра терминов по тегам." +[ui_or_search_by_tags] +other = "фильтр по тегам" +[ui_select_all] +other = "Выбрать все" +[ui_deselect_all] +other = "Отменить выбор" + +# Footer text +[footer_all_rights_reserved] +other = "Все права защищены" + +[footer_privacy_policy] +other = "Политика конфиденциальности" + +[footer_hub_button_text] +other = "Все сайты CNCF" + +# Post (blog, articles etc.) +[post_byline_by] +other = "Автор" +[post_created] +other = "Создано" +[post_last_mod] +other = "Последнее изменение" +[post_edit_this] +other = "Редактировать страницу" +[post_create_child_page] +other = "Создать дочернюю страницу" +[post_create_issue] +other = "Сообщить об ошибке" +[post_create_project_issue] +other = "Создать Issue" +[post_posts_in] +other = "Публикации в" +[post_reading_time] +other = "минут(ы)" + +# Print support +[print_printable_section] +other = "Это многостраничный печатный вид данного раздела." +[print_click_to_print] +other = "Распечатать" +[print_show_regular] +other = "Вернуться к обычному виду" +[print_entire_section] +other = "Распечатать весь раздел" + +# Feedback section +[feedback_title] +other = "Обратная связь" +[feedback_question] +other = "Полезна ли эта страница?" +[feedback_answer_yes] +other = "Да" +[feedback_answer_no] +other = "Нет" diff --git a/i18n/tr.toml b/i18n/tr.toml new file mode 100644 index 0000000000..31f8a6e115 --- /dev/null +++ b/i18n/tr.toml @@ -0,0 +1,87 @@ + + +# UI strings. Buttons and similar. + +[ui_pager_prev] +other = "Önceki" + +[ui_pager_next] +other = "Sonraki" + +[ui_read_more] +other = "Daha fazla" + +[ui_search] +other = "Sitede ara…" + +# Used in sentences such as "Posted in News" +[ui_in] +other = "içinde" + +# Phrases for tags +[ui_see_all_tags] +other = "Tüm etiketleri gör" +[ui_tag] +other = "Etiket" +[ui_tags] +other = "Etiketler" +[ui_search_by_tags] +other = "Etiketlere gözat" +[ui_tags_intro] +other = "Sözlük terimlerini etiketledik. Filtreleri kullanarak terimleri etiketlere göre listeleyebilirsiniz." +[ui_or_search_by_tags] +other = "...veya etiketlere bak" +[ui_select_all] +other = "Tümünü seç" +[ui_deselect_all] +other = "Seçimi bırak" + +# Footer text +[footer_all_rights_reserved] +other = "Bütün haklar saklıdır" + +[footer_privacy_policy] +other = "Gizlilik Politikası" + +[footer_hub_button_text] +other = "Tüm CNCF siteleri" + +# Post (blog, articles etc.) +[post_byline_by] +other = "tarafından" +[post_created] +other = "oluşturuldu" +[post_last_mod] +other = "Son düzenleme" +[post_edit_this] +other = "Bu sayfayı düzenle" +[post_create_child_page] +other = "Alt sayfa oluştur" +[post_create_issue] +other = "Sorun bildir" +[post_create_project_issue] +other = "Proje sorunu bildir" +[post_posts_in] +other = "Şu kategorideki gönderiler: " +[post_reading_time] +other = "dakikalık okuma" + +# Print support +[print_printable_section] +other = "Şu anda bu kısmın birden çok sayfalı yazdırılabilir görünümünü görüyorsun." +[print_click_to_print] +other = "Yazdırmak için buraya tıkla" +[print_show_regular] +other = "Sayfanın normal görünümüne dön" +[print_entire_section] +other = "Tüm kısmı yazdır" + +# Feedback section +[feedback_title] +other = "Geri bildirim" +[feedback_question] +other = "Bu sayfa faydalı mıydı?" +[feedback_answer_yes] +other = "Evet" +[feedback_answer_no] +other = "Hayır" diff --git a/layouts/_default/baseof.html b/layouts/_default/baseof.html index 63711ab6c6..a55909d01a 100644 --- a/layouts/_default/baseof.html +++ b/layouts/_default/baseof.html @@ -4,6 +4,12 @@ {{ partial "head.html" . }} + {{ if hugo.IsProduction }} + + + + {{ end }}
{{ partial "navbar.html" . }}
diff --git a/layouts/_default/content.html b/layouts/_default/content.html index 85cb48e4b6..c900d77e70 100644 --- a/layouts/_default/content.html +++ b/layouts/_default/content.html @@ -1,4 +1,4 @@ -
+

{{ .Title }}

{{ with .Params.description }}
{{ . | markdownify }}
{{ end }}