From 0a28dc0cd50bb6f023922381161fbd6eb9a3e100 Mon Sep 17 00:00:00 2001 From: Sergey Krymov <77280748+FightingFox@users.noreply.github.com> Date: Sun, 21 Apr 2024 11:45:05 +0300 Subject: [PATCH 01/23] [ru] Localize Datacenter in Russian (#3062) Signed-off-by: Sergey Krymov <77280748+FightingFox@users.noreply.github.com> Signed-off-by: Kirill Kononovich <41591254+kirkonru@users.noreply.github.com> Co-authored-by: Dmitry Shurupov Co-authored-by: Kirill Kononovich <41591254+kirkonru@users.noreply.github.com> --- content/ru/data-center.md | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+) create mode 100644 content/ru/data-center.md diff --git a/content/ru/data-center.md b/content/ru/data-center.md new file mode 100644 index 0000000000..f541fad619 --- /dev/null +++ b/content/ru/data-center.md @@ -0,0 +1,30 @@ +--- +title: Дата-центр +status: Completed +category: Technology +tags: ["infrastructure", "fundamental", ""] +--- + +Дата-центр (центр хранения и обработки данных, ЦОД/ЦХОД) — специализированное здание или помещение, предназначенное для размещения вычислительной техники, чаще всего серверов. +Обычно дата-центры подключаются к высокоскоростным линиям связи с доступом к сети Интернет, особенно если они ориентированы на [облачные вычисления](/ru/cloud-computing/). +Здания, в которых размещаются дата-центры, включают необходимую инфраструктуру для поддержания работоспособности установленного в них оборудования, в том числе электрогенераторы, обеспечивающие питание во время перебоев, и мощные системы вентиляции и кондиционирования, которые охлаждают выделяющие тепло компьютеры. + +## Какую проблему решает + +До широкого распространения дата-центров в конце 1990-х годов компьютеры в основном использовались для решения конкретных задач или обслуживания отдельных пользователей. +Поскольку ресурсы отдельного компьютера (объем жёсткого диска, размер оперативной памяти, частота и количество ядер процессора) лимитированы, ограничены и его возможности +по запуску тех или иных приложений. +То есть до появления дата-центров масштаб приложения ограничивался мощностью компьютера, на котором оно работало. +В то же время для запуска крупных приложений — например, серверной части (не клиента в браузере) Gmail или Netflix, — требуются вычислительные мощности, +значительно превышающие мощности одного компьютера. +Для решения указанной проблемы и предназначены дата-центры. + +## Как именно решает проблему + +Из нескольких серверов создаётся [распределенная система](/distributed-systems/), функционирующая как «суперкомпьютер». +Суммарная производительность совокупности устройств позволяет запускать гораздо более масштабные приложения +и решать более сложные вычислительные задачи. +Работа большинства приложений, используемых нами ежедневно, обеспечивается именно дата-центрами. + +[Публичные облака](/ru/cloud-computing/) — дата-центры, предоставляющие вычислительные ресурсы пользователям в аренду. +В последние годы наблюдается переход от корпоративных дата-центров к вычислительным мощностям в облаке. From be136ba670cd0820bbc9747d61253a7d462190d8 Mon Sep 17 00:00:00 2001 From: Victoria Likhanova <156430352+vickylikh@users.noreply.github.com> Date: Mon, 22 Apr 2024 14:37:06 +0800 Subject: [PATCH 02/23] [ru] Localize digital-certificate.md (#3071) Signed-off-by: Victoria Likhanova <156430352+vickylikh@users.noreply.github.com> Co-authored-by: Kirill Kononovich <41591254+kirkonru@users.noreply.github.com> --- content/ru/digital-certificate.md | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) create mode 100644 content/ru/digital-certificate.md diff --git a/content/ru/digital-certificate.md b/content/ru/digital-certificate.md new file mode 100644 index 0000000000..93d1181a77 --- /dev/null +++ b/content/ru/digital-certificate.md @@ -0,0 +1,22 @@ +--- +title: Digital Certificate +status: Feedback Appreciated +category: technology +tags: ["security", "", ""] +--- + +(Цифровой) сертификат / сертификат открытого ключа / SSL-сертификат — это электронный документ, который используется для безопасного обмена информацией по сети. +Сертификат подтверждает, что объект, с которым происходит коммуникация, действительно тот, за кого себя выдает. +Кроме того, благодаря шифрованию исходящих и входящих данных сертификат гарантирует конфиденциальность обмена информацией. + +## Какую проблему решает + +Когда устройство взаимодействует по сети с другими сущностями, у него нет гарантии, что другое устройство, с которым оно взаимодействует, является тем, за кого себя выдает. +Кроме того, нельзя гарантировать, что трафик между двумя устройствами не перехватит третья сторона. +Следовательно, любая коммуникация потенциально может быть перехвачена, а значит, конфиденциальная информация, например имена пользователей и пароли, может быть скомпрометирована. + +## Как именно решает проблему + +Современные почтовые клиенты, которые используют сертификаты, могут сообщать, верны ли идентификационные данные отправителя. Браузеры тоже это умеют — обратите внимание на замочек слева от адресной строки. +Кроме того, сертификат может применяться для шифрования передачи данных между различными объектами в интернете. +Механизм шифрования в сертификате делает чтение данных практически невозможным для тех, кто сумел их перехватить. From 46f7cdd04b4211523325a1706eb5f5b031fce464 Mon Sep 17 00:00:00 2001 From: Victoria Likhanova <156430352+vickylikh@users.noreply.github.com> Date: Wed, 24 Apr 2024 22:33:02 +0800 Subject: [PATCH 03/23] [ru] Localize distributed-systems.md Signed-off-by: Victoria Likhanova <156430352+vickylikh@users.noreply.github.com> --- content/ru/distributed-systems.md | 29 +++++++++++++++++++++++++++++ 1 file changed, 29 insertions(+) create mode 100644 content/ru/distributed-systems.md diff --git a/content/ru/distributed-systems.md b/content/ru/distributed-systems.md new file mode 100644 index 0000000000..85408d7872 --- /dev/null +++ b/content/ru/distributed-systems.md @@ -0,0 +1,29 @@ +--- +title: Distributed System +status: Completed +category: concept +tags: ["architecture", "", ""] +--- + +Распределенная система — это набор автономных вычислительных элементов, которые соединены по сети и воспринимаются пользователями как единая целостная система. +Эти компоненты, обычно называемые [узлами](/nodes/), могут быть аппаратными устройствами (например, компьютеры, мобильные телефоны) или программными процессами. +Узлы запрограммированы на достижение общей цели и обмениваются сообщениями по сети, чтобы взаимодействовать. + +## Какую проблему решает + +Многие современные приложения настолько крупные, что для их работы потребовались бы суперкомпьютеры. +Вспомните Gmail или Netflix. Ни у одного компьютера не хватит мощности, чтобы разместить на нем целое приложение. +Если соединить множество компьютеров, вычислительная мощность становится практически безграничной. +Многие приложения, на которые мы сегодня полагаемся, не могли бы существовать без распределенных вычислений. + +Обычно системы [масштабируются](/scalability/) вертикально. +Это когда к отдельной машине добавляется дополнительный процессор или память. +Вертикальное масштабирование занимает много времени, требует простоя и быстро достигает предела. + +## Как именно решает проблему + +Распределенная система может [масштабироваться горизонтально](/horizontal-scaling/): например, при необходимости в систему можно добавлять дополнительные узлы. +Это можно автоматизировать, чтобы система справлялась с внезапным ростом нагрузки или потребления ресурсов. + +Нераспределенная система подвержена риску сбоев, так как при поломке одной машины выходит из строя вся система. +Распределенную систему можно спроектировать так, чтобы даже при поломке нескольких машин система продолжала работать с тем же результатом. From ebc73e8419965dbb6eb10faecf896af35faa539f Mon Sep 17 00:00:00 2001 From: Timur Tukaev <90071493+tym83@users.noreply.github.com> Date: Sat, 27 Apr 2024 15:21:25 +0500 Subject: [PATCH 04/23] Update distributed-systems.md A few moments Signed-off-by: Timur Tukaev <90071493+tym83@users.noreply.github.com> --- content/ru/distributed-systems.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/content/ru/distributed-systems.md b/content/ru/distributed-systems.md index 85408d7872..e1ca3d1fea 100644 --- a/content/ru/distributed-systems.md +++ b/content/ru/distributed-systems.md @@ -7,23 +7,23 @@ tags: ["architecture", "", ""] Распределенная система — это набор автономных вычислительных элементов, которые соединены по сети и воспринимаются пользователями как единая целостная система. Эти компоненты, обычно называемые [узлами](/nodes/), могут быть аппаратными устройствами (например, компьютеры, мобильные телефоны) или программными процессами. -Узлы запрограммированы на достижение общей цели и обмениваются сообщениями по сети, чтобы взаимодействовать. +Узлы запрограммированы на достижение общей цели и взаимодействуют, обмениваясь сообщениями по сети. ## Какую проблему решает Многие современные приложения настолько крупные, что для их работы потребовались бы суперкомпьютеры. -Вспомните Gmail или Netflix. Ни у одного компьютера не хватит мощности, чтобы разместить на нем целое приложение. -Если соединить множество компьютеров, вычислительная мощность становится практически безграничной. +Вспомните Gmail или Netflix. Ни у одного компьютера не хватит мощности, чтобы разместить на нем целиком такое приложение. +А вот если соединить множество компьютеров, вычислительная мощность становится практически безграничной. Многие приложения, на которые мы сегодня полагаемся, не могли бы существовать без распределенных вычислений. Обычно системы [масштабируются](/scalability/) вертикально. -Это когда к отдельной машине добавляется дополнительный процессор или память. -Вертикальное масштабирование занимает много времени, требует простоя и быстро достигает предела. +Это означает, что к отдельной машине добавляется дополнительный процессор или память. +Вертикальное масштабирование занимает много времени, быстро достигает предела и приводит к простою. ## Как именно решает проблему Распределенная система может [масштабироваться горизонтально](/horizontal-scaling/): например, при необходимости в систему можно добавлять дополнительные узлы. -Это можно автоматизировать, чтобы система справлялась с внезапным ростом нагрузки или потребления ресурсов. +Этот процесс можно автоматизировать, тогда система сможет справляться с внезапным ростом нагрузки или потребления ресурсов. Нераспределенная система подвержена риску сбоев, так как при поломке одной машины выходит из строя вся система. -Распределенную систему можно спроектировать так, чтобы даже при поломке нескольких машин система продолжала работать с тем же результатом. +Распределенную систему можно спроектировать так, чтобы даже при поломке нескольких машин она продолжала работать с тем же результатом. From 344a9fc3568b2e4e1e33ab9d6b2578e46140750b Mon Sep 17 00:00:00 2001 From: Dmitry Shurupov Date: Fri, 3 May 2024 17:04:16 +0700 Subject: [PATCH 05/23] [ru] Review distributed-systems.md (#3076) Signed-off-by: Dmitry Shurupov --- content/ru/distributed-systems.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/ru/distributed-systems.md b/content/ru/distributed-systems.md index e1ca3d1fea..d3c8396b71 100644 --- a/content/ru/distributed-systems.md +++ b/content/ru/distributed-systems.md @@ -16,14 +16,14 @@ tags: ["architecture", "", ""] А вот если соединить множество компьютеров, вычислительная мощность становится практически безграничной. Многие приложения, на которые мы сегодня полагаемся, не могли бы существовать без распределенных вычислений. -Обычно системы [масштабируются](/scalability/) вертикально. +Исторически системы [масштабировались](/scalability/) вертикально. Это означает, что к отдельной машине добавляется дополнительный процессор или память. Вертикальное масштабирование занимает много времени, быстро достигает предела и приводит к простою. ## Как именно решает проблему -Распределенная система может [масштабироваться горизонтально](/horizontal-scaling/): например, при необходимости в систему можно добавлять дополнительные узлы. -Этот процесс можно автоматизировать, тогда система сможет справляться с внезапным ростом нагрузки или потребления ресурсов. +Распределенная система может [масштабироваться горизонтально](/horizontal-scaling/): например, при необходимости в систему добавляются дополнительные узлы. +Этот процесс можно автоматизировать — тогда система сможет справляться с внезапным ростом нагрузки или потребления ресурсов. Нераспределенная система подвержена риску сбоев, так как при поломке одной машины выходит из строя вся система. Распределенную систему можно спроектировать так, чтобы даже при поломке нескольких машин она продолжала работать с тем же результатом. From 9fff3577debb5b47bcc5d15bd15539efb244fb3d Mon Sep 17 00:00:00 2001 From: Sergey Krymov <77280748+FightingFox@users.noreply.github.com> Date: Thu, 30 May 2024 08:10:52 +0300 Subject: [PATCH 06/23] [ru] Localize Event Streaming in Russian (#3077) Signed-off-by: Sergey Krymov Signed-off-by: Sergey Krymov <77280748+FightingFox@users.noreply.github.com> Signed-off-by: Timur Tukaev <90071493+tym83@users.noreply.github.com> Co-authored-by: Dmitry Shurupov Co-authored-by: Timur Tukaev <90071493+tym83@users.noreply.github.com> Co-authored-by: Kirill Kononovich <41591254+kirkonru@users.noreply.github.com> --- content/ru/event-streaming.md | 29 +++++++++++++++++++++++++++++ 1 file changed, 29 insertions(+) create mode 100644 content/ru/event-streaming.md diff --git a/content/ru/event-streaming.md b/content/ru/event-streaming.md new file mode 100644 index 0000000000..27f0047460 --- /dev/null +++ b/content/ru/event-streaming.md @@ -0,0 +1,29 @@ +--- +title: Потоковая передача событий +status: Completed +category: concept +tags: ["methodology", "networking", ""] +--- + +Потоковая передача событий — это подход, при котором программное обеспечение отправляет данные о событиях одного приложения другому, чтобы поддерживать постоянный обмен информацией об их действиях. +Представьте себе службу, транслирующую всё, что она делает, всем остальным службам. +Каждое действие, выполняемое такой службой, называется событием, отсюда и название «потоковая передача событий». +Например, служба автоматизированных котировок Национальной ассоциации дилеров по ценным бумагам (NASDAQ) каждую секунду публикует свежую информацию о ценах на акции и сырьё. +Вы бы наверняка хотели, чтобы приложение, которое отслеживает стоимость определенного набора акций, обновляло котировки в режиме реального времени. +Yahoo! Finance предоставляет [API](/application-programming-interface/), который извлекает данные из NASDAQ и отправляет (или передает) информацию (или события) в любое приложение, которое на него подписано. +Отправляемые данные, а также изменения в этих данных (например, изменения цен на акции) являются событиями, а процесс их доставки в приложение как раз и представляет собой потоковую передачу событий. + +## Какую проблему решает + +При традиционном подходе Yahoo! Finance мог бы использовать одиночные TCP-запросы. +Однако это было бы крайне неэффективно, поскольку для каждого события приходилось бы устанавливать отдельное соединение. +Поскольку всё чаще возникает потребность в данных, передаваемых в режиме реального времени, масштабирование такого решения стало бы сложной задачей. +А вот подход, при котором открывается соединение с дальнейшей подпиской на поток событий, уже идеально подходит для сбора данных в реальном времени. +Объём генерируемых данных экспоненциально растёт, а вместе с ним постоянно меняется и состояние данных. Разработчики и пользователи должны иметь возможность видеть эти данные практически в реальном времени. + +## Как именно решает проблему + +Потоковая передача событий позволяет передавать изменения данных от источника к получателю. +Вместо того, чтобы ждать, пока другие сервисы запросят информацию, сервис непрерывно транслирует все произошедшие в нём события (или действия). +При этом сервис не заботится о том, что происходит с отправляемыми им данными. +Он просто выполняет свои задачи и транслирует информацию, оставаясь полностью независимым от любого другого сервиса. From 4c356f0872e9ad28b5ce3cb96367949a44cd020c Mon Sep 17 00:00:00 2001 From: Kirill Kononovich <41591254+kirkonru@users.noreply.github.com> Date: Tue, 16 Jul 2024 10:54:18 +0300 Subject: [PATCH 07/23] [ru] Localize idempotence.md Signed-off-by: Kirill Kononovich <41591254+kirkonru@users.noreply.github.com> --- content/ru/idempotence.md | 10 ++++++++++ 1 file changed, 10 insertions(+) create mode 100644 content/ru/idempotence.md diff --git a/content/ru/idempotence.md b/content/ru/idempotence.md new file mode 100644 index 0000000000..7e8216fda5 --- /dev/null +++ b/content/ru/idempotence.md @@ -0,0 +1,10 @@ +--- +title: Идемпотентность +status: Completed +category: Property +tags: ["property", "", ""] +--- + +В математике или информатике идемпотентность описывает операцию, которая всегда приводит к одному и тому же результату, +независимо от того, сколько раз она выполняется. +Если параметры не меняются, многократное выполнение идемпотентной операции не приводит к каким-либо дополнительным изменениям. From 396247b5b586f2fda469f4e295fc9546c58eaab5 Mon Sep 17 00:00:00 2001 From: Irina Titova Date: Fri, 26 Jul 2024 10:09:52 +0300 Subject: [PATCH 08/23] [ru] Translate monolithic-apps.md (#3253) Signed-off-by: Irina Titova Co-authored-by: Kirill Kononovich <41591254+kirkonru@users.noreply.github.com> Co-authored-by: Dmitry Shurupov --- content/ru/monolithic-apps.md | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+) create mode 100644 content/ru/monolithic-apps.md diff --git a/content/ru/monolithic-apps.md b/content/ru/monolithic-apps.md new file mode 100644 index 0000000000..3f705163d4 --- /dev/null +++ b/content/ru/monolithic-apps.md @@ -0,0 +1,28 @@ +--- +title: Монолитные приложения +status: Completed +category: concept +tags: ["architecture", "fundamental", ""] +--- + +В монолитном приложении все его компоненты объединены в единую развертываемую программу. +Зачастую это самый простой и понятый путь на начальном этапе разработки приложения. +Однако по мере усложнения приложения поддерживать монолит становится труднее. +С увеличением числа разработчиков, работающих над одной и той же кодовой базой, возрастает вероятность +конфликтующих изменений, а также увеличивается потребность в коммуникациях. + +## Какую проблему решает + +Разделение приложения на [микросервисы](/microservices-architecture/) увеличивает операционные издержки, связанные с +тестированием, развертыванием и последующей эксплуатацией. +На ранних этапах жизненного цикла продукта разумно воздержаться от такого усложнения, придерживаясь монолитного подхода до тех пор, +пока продукт не будет признан успешным. + +## Как именно решает проблему + +Хорошо спроектированный монолит соответствует принципам бережливого производства, +являясь самым простым способом разработки и запуска приложения. +Когда монолитное приложение докажет свою полезность для бизнеса, его можно будет разбить на микросервисы. +Разработка микросервисного приложения еще до того, как станет ясно, что оно приносит реальную пользу, может превратиться +в бессмысленную трату ценных инженерных ресурсов. +Если приложение окажется невостребованным, эти дополнительные усилия разработчиков будут потрачены впустую. From c6b6e63029648854633958aef6d59ec7837c7b06 Mon Sep 17 00:00:00 2001 From: Irina Titova Date: Wed, 31 Jul 2024 15:07:17 +0300 Subject: [PATCH 09/23] [ru] Translate microservices-architecture.md (#3254) Signed-off-by: Irina Titova Co-authored-by: Kirill Kononovich <41591254+kirkonru@users.noreply.github.com> --- content/ru/microservices-architecture.md | 35 ++++++++++++++++++++++++ 1 file changed, 35 insertions(+) create mode 100644 content/ru/microservices-architecture.md diff --git a/content/ru/microservices-architecture.md b/content/ru/microservices-architecture.md new file mode 100644 index 0000000000..70e2a2c6e4 --- /dev/null +++ b/content/ru/microservices-architecture.md @@ -0,0 +1,35 @@ +--- +title: Микросервисная архитектура +status: Completed +tags: ["architecture", "fundamental", ""] +--- + +Микросервисы — это архитектурный подход к разработке, который разбивает приложение на отдельные и независимые (микро)[сервисы](/service/), каждый из которых отвечает за определенную функциональность. +Эти сервисы тесно взаимодействуют друг с другом и для конечного пользователя выглядят как единое целое. +Возьмем, к примеру, Netflix. +Интерфейс приложения позволяет пользователю входить в учетную запись, искать видео и просматривать их. +За все эти действия, скорее всего, отвечают меньшие по размеру сервисы, каждый из которых фокусируется на одной задаче. +Например, на аутентификации пользователя, поиске видео или его воспроизведении в браузере. + +Данный архитектурный подход позволяет разработчикам внедрять новую функциональность, а также вносить изменения в существующую намного быстрее, чем если бы сервисы были тесно связаны, как в [монолитных приложениях](/ru/monolithic-apps/) (подробнее об этом ниже). + +## Какую проблему решает + +Приложения состоят из разных компонентов, каждый из которых отвечает за определенную функциональность. +Потребность в определенной функциональности не обязательно растет или падает вместе с нагрузкой на другие части приложения. +Вернемся к нашему примеру про Netflix. +Допустим, после успешной маркетинговой кампании на Netflix наблюдается бум регистраций, при этом воспроизведение видео в ранние часы осталось примерно на прежнем уровне. +Всплеск числа регистраций перегружает соответствующий компонент приложения. +В традиционной (монолитной) архитектуре пришлось бы [масштабировать](/scalability/) все приложение, чтобы оно выдержало возросшую нагрузку, а это неэффективно с точки зрения использования ресурсов. + +Монолитная архитектура также повышает риск стать жертвой ловушек проектирования. +Поскольку весь код находится в одном месте, возрастает соблазн сделать его [тесно связанным](/ru/tightly-coupled-architecture/), пренебрегая принципом разделения ответственности. +Кроме того, чтобы вносить какие-либо изменения в монолитное приложения, разработчикам часто приходиться изучать его кодовую базу целиком. +Микросервисная архитектура решает эти проблемы. + +## Как именно решает проблему + +Разделение функциональности на микросервисы упрощает их развертывание, обновление и масштабирование. +Оно также позволяет различным командам одновременно работать над небольшими частями приложения, минимизируя риск непреднамеренного негативного влияния на все приложение. +Микросервисная архитектура решает множество проблем, но платить за это приходится ростом операционных расходов: значительно увеличивается число компонентов, которые необходимо развертывать и поддерживать. +Многие [облачные технологии](/ru/cloud-native-tech/) стараются упростить процессы развертывания микросервисов и управления ими. From 37e55e9630844fa74a6b33e571bc9c8f699e61eb Mon Sep 17 00:00:00 2001 From: Victoria Likhanova <156430352+vickylikh@users.noreply.github.com> Date: Thu, 1 Aug 2024 14:27:09 +0800 Subject: [PATCH 10/23] [ru] Localize distributed-apps.md (#3125) Signed-off-by: Victoria Likhanova <156430352+vickylikh@users.noreply.github.com> Signed-off-by: Kirill Kononovich <41591254+kirkonru@users.noreply.github.com> Co-authored-by: Kirill Kononovich <41591254+kirkonru@users.noreply.github.com> Co-authored-by: Dmitry Shurupov --- content/ru/distributed-apps.md | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) create mode 100644 content/ru/distributed-apps.md diff --git a/content/ru/distributed-apps.md b/content/ru/distributed-apps.md new file mode 100644 index 0000000000..fc69655c98 --- /dev/null +++ b/content/ru/distributed-apps.md @@ -0,0 +1,23 @@ +--- +title: Распределенные приложения +status: Completed +category: concept +tags: ["architecture", "", ""] +--- + +Распределенное приложение — это приложение, функциональность которого разделена на множество более мелких независимых частей. +Распределенные приложения обычно состоят из отдельных [микросервисов](/microservices-architecture/), которые решают различные задачи. +В облачной среде отдельные компоненты, как правило, выполняются в виде [контейнеров](/ru/container/) в [кластере](/ru/cluster/). + +## Какую проблему решает + +Приложение, работающее на одном компьютере, — это единая точка отказа: если этот компьютер выходит из строя, приложение становится недоступным. +Распределенные приложения зачастую противопоставляются [монолитным](/monolithic-apps/). +Монолитное приложение обычно сложнее масштабировать, так как его компоненты невозможно масштабировать независимо друг от друга. +Кроме того, по мере своего роста монолитные приложения все сильнее тормозят разработку, поскольку растет число разработчиков, которым приходится работать над общей кодовой базой, а у нее не всегда есть четко определенные границы. + +## Как именно решает проблему + +Разбивая приложение на части и запуская их на разных машинах, мы повышаем устойчивость системы к сбоям. +Этот подход также позволяет воспользоваться способами масштабирования, которые недоступны приложениям с единственным экземпляром, а именно — [горизонтальным масштабированием](/ru/horizontal-scaling/). +Однако за это приходится платить: поскольку вместо одного приложения выполняется множество его компонентов, растут сложность и операционные издержки. From e99e08bdfa47d696761f5cc999f20f0c7de02b70 Mon Sep 17 00:00:00 2001 From: Irina Titova Date: Fri, 2 Aug 2024 17:09:32 +0300 Subject: [PATCH 11/23] [ru] Translate mutual-transport-layer-security.md (#3255) Signed-off-by: Irina Titova Co-authored-by: Dmitry Shurupov --- content/ru/mutual-transport-layer-security.md | 22 +++++++++++++++++++ 1 file changed, 22 insertions(+) create mode 100644 content/ru/mutual-transport-layer-security.md diff --git a/content/ru/mutual-transport-layer-security.md b/content/ru/mutual-transport-layer-security.md new file mode 100644 index 0000000000..dd6bdc3f22 --- /dev/null +++ b/content/ru/mutual-transport-layer-security.md @@ -0,0 +1,22 @@ +--- +title: Протокол взаимной защиты транспортного уровня (mTLS) +status: Completed +category: Concept +tags: ["security", "networking", ""] +--- + +Протокол взаимной защиты транспортного уровня — это метод, используемый для аутентификации и шифрования сообщений, передаваемых между двумя [сервисами](/service/). +Протокол взаимной защиты транспортного уровня — это расширение стандартного [Протокола защиты транспортного уровня](/transport-layer-security/) (TLS), +но вместо проверки подлинности только одной стороны осуществляется валидация обеих. + +## Какую проблему решает + +[Микросервисы](/microservices-architecture/) взаимодействуют по сети, но этот канал коммуникации может быть взломан аналогично тому, как это происходит с Wi-Fi. +mTLS гарантирует, что неавторизованная сторона не сможет прослушивать канал коммуникации и выполнять несанкционированные действия. + +## Как именно решает проблему + +mTLS гарантирует безопасность и аутентичность для трафика в обоих направлениях между клиентом и сервером, +обеспечивая дополнительный уровень безопасности для пользователей, осуществляющих вход в сеть или приложение. +Он также проверяет соединения с клиентскими устройствами, которые не требуют входа в систему, например, относящимся к категории Интернета вещей (IoT). +mTLS может предотвратить атаки посредника (on-path), спуфинг-атаки, атаки с подстановкой учетных данных, атаки путем полного перебора (brute force) и другие. From b6af1005c5770fb0effef2bcfdbb6ec51a3e9537 Mon Sep 17 00:00:00 2001 From: Kirill Kononovich <41591254+kirkonru@users.noreply.github.com> Date: Sun, 18 Aug 2024 12:29:49 +0300 Subject: [PATCH 12/23] [ru] Localize `Ingress` (#3230) Signed-off-by: Kirill Kononovich <41591254+kirkonru@users.noreply.github.com> Signed-off-by: Timur Tukaev <90071493+tym83@users.noreply.github.com> Co-authored-by: Dmitry Shurupov Co-authored-by: Timur Tukaev <90071493+tym83@users.noreply.github.com> --- content/ru/ingress.md | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+) create mode 100644 content/ru/ingress.md diff --git a/content/ru/ingress.md b/content/ru/ingress.md new file mode 100644 index 0000000000..9d4b60eb8c --- /dev/null +++ b/content/ru/ingress.md @@ -0,0 +1,30 @@ +--- +title: Ingress +status: Completed +category: technology +tags: ["fundamental"] +--- + +Ingress — набор правил, которые помогают управлять интернет-трафиком, поступающим извне в контейнер или группу контейнеров, работающих в кластере. +Он состоит из двух элементов: ресурса Ingress и Ingress-контроллера. +Ресурс Ingress — это конфигурационный файл, который живет вместе с другими файлами манифестов и позволяет администраторам настраивать маршрутизацию внешнего трафика. +Ingress-контроллер — технология веб-сервера, которая маршрутизирует трафик в соответствии с конфигурацией в Ingress-ресурсе. + +## Какую проблему решает + +Нативные облачные веб-приложения состоят из множества сервисов. Часто эти [сервисы](/service/) должны быть доступны через интернет, чтобы пользователи могли обратиться к ним через браузер. +Чтобы сервисы приложения, запущенного в [Kubernetes](/ru/kubernetes/), стали доступными для внешнего мира, необходимо выполнить специальные действия. +Проще всего было бы использовать балансировщик нагрузки Kubernetes. +Но создание такого сервиса означает появление нового компонента в базовой инфраструктуре. +Возникнут дополнительные затраты и накладные расходы на управление. Кроме того, у каждого вновь созданного балансировщика нагрузки будет свой собственный внешний IP-адрес. +Из-за этого пострадают и сами пользователи, поскольку придётся каждый раз вводить новый URL-адрес для доступа к приложению. + +## Как именно решает проблему + +Ресурс Ingress позволяет настроить балансировку и маршрутизацию трафика к сервисам приложения. +Ingress-контроллер открывает единую точку входа через URL (www.example-url.com) и выполняет фактическую маршрутизацию и балансировку, руководствуясь различными URL-путями (www.example-url.com/path). +Ingress-контроллер работает в кластере и интерпретирует правила, определенные в ресурсе Ingress. +Выбор конкретного Ingress-контроллера из существующих технологий (Nginx, Traefik, HAProxy и т. д.) осуществляют сами администраторы кластера, в котором работает веб-приложение. +Подход на базе Ingress обеспечивает доступ к приложению по единому URL, даже если оно состоит из большого числа сервисов. +Это устраняет необходимость запускать множество отдельных балансировщиков нагрузки на уровне инфраструктуры и упрощает настройку правил брандмауэра и балансировщика нагрузки для каждого сервиса. +Централизуя маршрутизацию трафика и управление конфигурацией, Ingress упрощает масштабирование, оптимизирует использование ресурсов, снижает затраты и повышает общую управляемость приложений, работающих в кластере. From 1296c38fda021bc43256e073b59527b95a613d02 Mon Sep 17 00:00:00 2001 From: Irina Titova Date: Fri, 30 Aug 2024 09:06:51 +0300 Subject: [PATCH 13/23] [ru] Localize multitenancy.md (#3272) Signed-off-by: Irina Titova Co-authored-by: Kirill Kononovich <41591254+kirkonru@users.noreply.github.com> Co-authored-by: Dmitry Shurupov --- content/ru/multitenancy.md | 37 +++++++++++++++++++++++++++++++++++++ 1 file changed, 37 insertions(+) create mode 100644 content/ru/multitenancy.md diff --git a/content/ru/multitenancy.md b/content/ru/multitenancy.md new file mode 100644 index 0000000000..3e5e4fa27f --- /dev/null +++ b/content/ru/multitenancy.md @@ -0,0 +1,37 @@ +--- +title: Мультитенантность +status: Completed +category: Property +tags: ["architecture", "property", ""] +--- + +Мультитенантность (или мультиарендность) — это концепция, при которой одна инсталляция программного обеспечения обслуживает несколько арендаторов (тенантов). +Арендатором может быть пользователь, приложение или группа пользователей/приложений, которые работают со своими собственными данными. +Эти арендаторы не обмениваются данными (если только владелец не укажет иное) и могут даже не знать о существовании друг друга. + +Арендатор может быть как отдельным пользователем с одной учетной записью — например, в случае использования программного обеспечения +для решения персональных задач, — так и целой корпорацией с тысячами учетных записей, у каждой из которых свои права доступа, +но при этом они взаимосвязаны между собой множеством способов. +Такие программные средства, как Google Mail, Google Docs, Microsoft Office 365, Salesforce CRM, Dropbox, а также многие другие, +можно отнести к полностью или частично мультитенантному программному обеспечению. + +## Какую проблему решает + +Без мультитенантности каждому арендатору требовалась бы отдельная инсталляция программного обеспечения. +Это увеличивало бы потребление ресурсов и затраты на обслуживание, а в конечном итоге и расходы на программное обеспечение. + +## Как именно решает проблему + +Мультитенантное программное обеспечение предоставляет каждому арендатору изолированную среду (рабочие данные, настройки, список учетных данных и т. д.), +одновременно обслуживая нескольких арендаторов. +С точки зрения арендатора это выглядит как отдельная инсталляция программного обеспечения, хотя на самом деле все они используют одну и ту же. +Для этого программное приложение запускается на сервере, а арендаторам предоставляется возможность подключаться к нему через сеть, +используя пользовательский интерфейс и/или программный ([API](/ru/application-programming-interface/); смотри также [Архитектура клиент-сервер](/ru/client-server-architecture/)). +В мультитенантных программным системах арендаторы делят ресурсы одной инсталляции, не влияя друг на друга +или взаимодействуя только заранее согласованным, контролируемым образом. +Полученная экономия ресурсов на стороне поставщика позволяет значительно снизить расходы на программное обеспечение для пользователей (хорошие примеры — веб-почта или онлайн-редакторы документов). + +## Связанные термины + +Мультитенантность не является синонимом SaaS, хотя SaaS-системы часто проектируются как мультитенантные, а сама мультитенантность рекламируется +как одно из их ключевых преимуществ. From bc9f682367750c2abb765923765292ce9eebf689 Mon Sep 17 00:00:00 2001 From: Victoria Likhanova <156430352+vickylikh@users.noreply.github.com> Date: Tue, 8 Oct 2024 23:50:04 +0800 Subject: [PATCH 14/23] [ru] Localize nodes.md (#3269) Signed-off-by: Victoria Likhanova <156430352+vickylikh@users.noreply.github.com> Signed-off-by: Timur Tukaev <90071493+tym83@users.noreply.github.com> Co-authored-by: Kirill Kononovich <41591254+kirkonru@users.noreply.github.com> Co-authored-by: Dmitry Shurupov Co-authored-by: Timur Tukaev <90071493+tym83@users.noreply.github.com> --- content/ru/nodes.md | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+) create mode 100644 content/ru/nodes.md diff --git a/content/ru/nodes.md b/content/ru/nodes.md new file mode 100644 index 0000000000..78487af7d7 --- /dev/null +++ b/content/ru/nodes.md @@ -0,0 +1,24 @@ +--- +title: Узлы +status: Completed +category: Concept +tags: ["infrastructure", "fundamental", ""] +--- + +Узел (нода) — это вычислительное устройство, которое вместе с другими вычислительными устройствами (узлами) работает над выполнением общей задачи. +Например, ваш ноутбук, модем и принтер общаются друг с другом и взаимодействуют по сети Wi-Fi. +Каждое из этих устройств является отдельным узлом. +В сфере [облачных вычислений](/ru/cloud-computing/) узлом может быть физический компьютер, виртуальный компьютер ([виртуальная машина/ВМ](/virtual-machine/)) или даже [контейнер](/ru/container/). + +## Какую проблему решает + +Приложение может работать на единственной машине (и многие из них так и делают), но это сопряжено с рисками. +А именно, отказ базовой системы нарушит работу приложения. +Чтобы решить эту проблему, разработчики начали создавать [распределенные приложения](/ru/distributed-apps/), в которых каждый процесс выполняется на отдельном узле. +Таким образом, приложения или процессы работают на узлах как часть группы, образуя [кластер](/ru/cluster/)/группу узлов, которые работают вместе для достижения общей цели. + +## Как именно решает проблему + +Узел выступает как самостоятельное вычислительное устройство (с памятью, процессором, сетевым интерфейсом), которое можно включить в кластер. +В [облачных](/ru/cloud-native-tech/) платформах или приложениях узел — это рабочая единица. +В идеале отдельные узлы недифференцированы, то есть любой узел определенного типа неотличим от любого другого узла того же типа. From 56b9b64687548d8db3711b3c09fd932fa13b547d Mon Sep 17 00:00:00 2001 From: Kirill Kononovich <41591254+kirkonru@users.noreply.github.com> Date: Tue, 8 Oct 2024 18:56:52 +0300 Subject: [PATCH 15/23] [ru] Localize `Horizontal scaling` (#3219) Signed-off-by: Kirill Kononovich <41591254+kirkonru@users.noreply.github.com> Co-authored-by: Dmitry Shurupov --- content/ru/horizontal-scaling.md | 37 ++++++++++++++++++++++++++++++++ 1 file changed, 37 insertions(+) create mode 100644 content/ru/horizontal-scaling.md diff --git a/content/ru/horizontal-scaling.md b/content/ru/horizontal-scaling.md new file mode 100644 index 0000000000..3f5e0aab65 --- /dev/null +++ b/content/ru/horizontal-scaling.md @@ -0,0 +1,37 @@ +--- +title: Горизонтальное масштабирование +status: Completed +category: Concept +tags: ["infrastructure", "", ""] +--- + +Горизонтальное масштабирование — это метод, при котором производительность системы увеличивается за счет добавления [узлов](/nodes/). +Этим оно отличается от [вертикального масштабирования](/vertical-scaling/), когда ресурсы добавляются на сами узлы. +Допустим, у нас есть система с 4 ГБ ОЗУ и нужно увеличить ее емкость до 16 ГБ ОЗУ. +При горизонтальном масштабировании мы добавим еще три инстанса (узла) с 4 ГБ ОЗУ вместо того, чтобы увеличивать объем ОЗУ до 16 ГБ на единственном имеющемся инстансе. + +Такой подход позволяет повысить производительность приложения, добавляя новые инстансы или узлы, +чтобы лучше распределить рабочую нагрузку. +Проще говоря, он направлен на снижение нагрузки на сервер, +а не на увеличение мощности отдельного сервера. + +## Какую проблему решает + +По мере роста нагрузки на приложение возникает момент, когда она превышает возможности данного экземпляра приложения. +Чтобы система продолжала стабильно работать, необходимо ее [масштабировать](/scalability/) (увеличить ее ресурсы). +Для этого можно либо добавить больше узлов в систему (горизонтальное масштабирование), +либо увеличить объем вычислительных ресурсов на существующих узлах (вертикальное масштабирование). + +## Как именно решает проблему + +Горизонтальное масштабирование позволяет приложениям масштабироваться до пределов всего кластера. +Добавляя в систему больше экземпляров, мы увеличиваем число запросов, которое может обработать приложение. +Например, если один узел обрабатывает 1 тыс. запросов в секунду, +то два узла будут обрабатывать 2 тыс., три узла — 3 тыс. запросов и т.д. +Это позволяет приложению выполнять больше работы одновременно, +при этом не нужно наращивать производительность какого-либо узла в отдельности. + +## Связанные термины + +* [Вертикальное масштабирование](/vertical-scaling/) +* [Автомасштабирование](/ru/auto-scaling/) From 950b2b7b0dcd3457f09758fc8e8c0f72b966329d Mon Sep 17 00:00:00 2001 From: Kirill Kononovich <41591254+kirkonru@users.noreply.github.com> Date: Tue, 8 Oct 2024 20:47:13 +0300 Subject: [PATCH 16/23] [ru] Localize `Immutable infrastructure` (#3225) Signed-off-by: Kirill Kononovich <41591254+kirkonru@users.noreply.github.com> Co-authored-by: Dmitry Shurupov --- content/ru/immutable-infrastructure.md | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+) create mode 100644 content/ru/immutable-infrastructure.md diff --git a/content/ru/immutable-infrastructure.md b/content/ru/immutable-infrastructure.md new file mode 100644 index 0000000000..3162422be0 --- /dev/null +++ b/content/ru/immutable-infrastructure.md @@ -0,0 +1,25 @@ +--- +title: Неизменяемая инфраструктура +status: Completed +category: property +tags: ["infrastructure", "property", ""] +--- + +Неизменяемая инфраструктура — это компьютерная инфраструктура +([виртуальные машины](/virtual-machine/), [контейнеры](/ru/container/), сетевые устройства), +которую невозможно изменить после развертывания. +Неизменяемость может быть реализована с помощью автоматического процесса, который перезаписывает несанкционированные изменения, или +с помощью системы, которая вообще не позволяет вносить изменения. +Контейнеры — хороший пример неизменяемой инфраструктуры. +Внести в них постоянные изменения можно, только +создав новую версию контейнера или воссоздав существующий контейнер из его образа. + +Предотвращая или выявляя несанкционированные изменения, +неизменяемые инфраструктуры облегчают обнаружение и предотвращение угроз безопасности. +Управлять такой системой гораздо проще, +поскольку администраторам легче предугадывать её поведение. +Ведь они знают, что никто не мог внести в нее изменения (в т.ч. ошибочные), о которых, к тому же, забыл сообщить. +Неизменяемая инфраструктура неразрывно связана с подходом [«инфраструктура как код»](/ru/infrastructure-as-code/) +при котором вся автоматизация, необходимая для создания инфраструктуры, хранится в системе контроля версий (например, Git). +Такое сочетание неизменяемости и контроля версий позволяет +вести долговременный журнал аудита каждого авторизованного изменения в системе. From a19a5d6c9a351f7ad4e69aa0fa8489d041f92581 Mon Sep 17 00:00:00 2001 From: Irina Titova Date: Wed, 9 Oct 2024 04:14:34 +0300 Subject: [PATCH 17/23] [ru] Localize Observability.md (#3302) Signed-off-by: Irina Titova Signed-off-by: Timur Tukaev <90071493+tym83@users.noreply.github.com> Co-authored-by: Kirill Kononovich <41591254+kirkonru@users.noreply.github.com> Co-authored-by: Dmitry Shurupov Co-authored-by: Timur Tukaev <90071493+tym83@users.noreply.github.com> --- content/ru/observability.md | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) create mode 100644 content/ru/observability.md diff --git a/content/ru/observability.md b/content/ru/observability.md new file mode 100644 index 0000000000..38d26220d7 --- /dev/null +++ b/content/ru/observability.md @@ -0,0 +1,17 @@ +--- +title: Наблюдаемость +status: Completed +category: concept +tags: ["property", "", ""] +--- + +Наблюдаемость (observability) — это свойство системы, которое показывает, насколько легко можно получить полезную информацию о её состоянии. +Она позволяет пользователям определить состояние системы по внешним признакам и предпринять (корректирующие) действия. + +Компьютерные системы оцениваются путём наблюдения за низкоуровневыми сигналами, такими как время работы процессора, память, дисковое пространство, а также за высокоуровневыми и бизнес-сигналами, включая время отклика API, ошибки, количество транзакций в секунду и т.д. +**Наблюдение** за такими системами (их мониторинг) ведется с помощью специализированных инструментов, называемых инструментами наблюдаемости. +Список таких инструментов можно найти в [разделе observability на Cloud Native Landscape](https://landscape.cncf.io/?group=projects-and-products&view-mode=card#observability-and-analysis--observability). + +Наблюдаемые системы предоставляют своим операторам содержательные и практические данные, которые позволяют добиваться лучших результатов (быстрее реагировать на инциденты, повышать производительность разработчиков), снижать объемы рутинных операций и сокращать время простоя. + +Таким образом, уровень наблюдаемости системы существенно влияет на её эксплуатационные издержки и затраты на разработку. From a7624f52747d8febedc994c6817301d6898bac41 Mon Sep 17 00:00:00 2001 From: Kirill Kononovich <41591254+kirkonru@users.noreply.github.com> Date: Wed, 9 Oct 2024 04:17:42 +0300 Subject: [PATCH 18/23] [ru] Localize `Infrastructure-as-code` (#3227) Signed-off-by: Timur Tukaev <90071493+tym83@users.noreply.github.com> --- content/ru/infrastructure-as-code.md | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+) create mode 100644 content/ru/infrastructure-as-code.md diff --git a/content/ru/infrastructure-as-code.md b/content/ru/infrastructure-as-code.md new file mode 100644 index 0000000000..d9f5489c6d --- /dev/null +++ b/content/ru/infrastructure-as-code.md @@ -0,0 +1,24 @@ +--- +title: Инфраструктура как код (IaC) +status: Completed +category: concept +tags: ["infrastructure", "methodology", ""] +--- + +Инфраструктура как код (Infrastructure as Code) — подход, при котором описание инфраструктуры хранится в виде одного или нескольких файлов. +Этот подход пришел на смену традиционной модели, в которой инфраструктура как услуга (Infrastructure as a Service) предоставляется вручную, +обычно с помощью shell-скриптов или других инструментов конфигурирования. + +## Какую проблему решает + +Подход к разработке нативных облачных приложений требует, чтобы инфраструктура была одноразовой и воспроизводимой. +Также она должна [масштабироваться](/scalability/) по запросу автоматизированным и воспроизводимым образом, желательно без вмешательства человека. +Ручное управление инфраструктурой не удовлетворяет требованиям к скорости и масштабированию, которые предъявляются к [нативным облачным приложениям](/ru/cloud-native-apps/). +Изменения инфраструктуры, сделанные вручную, не обладают воспроизводимостью, кроме того, они плохо масштабируются и приводят к ошибкам в конфигурации. + +## Как именно решает проблему + +Представляя ресурсы дата-центра (серверы, балансировщики нагрузки, подсети и т. п.) в виде кода, +инфраструктурные команды получают единый источник истины для всех конфигураций и возможность +управлять центром обработки данных с помощью пайплайнов [CI](/ru/continuous-integration/)/[CD](/ru/continuous-delivery/), +используя при этом контроль версий и стратегии развертывания. From a964e80eb18b6e184baf14cb4b774a9f6947d1a1 Mon Sep 17 00:00:00 2001 From: Kirill Kononovich <41591254+kirkonru@users.noreply.github.com> Date: Wed, 9 Oct 2024 04:19:30 +0300 Subject: [PATCH 19/23] [ru] Localize `Contributor ladder` (#3208) Signed-off-by: Timur Tukaev <90071493+tym83@users.noreply.github.com> --- content/ru/contributor-ladder/_index.md | 126 ++++++++++++++++++++++++ 1 file changed, 126 insertions(+) create mode 100644 content/ru/contributor-ladder/_index.md diff --git a/content/ru/contributor-ladder/_index.md b/content/ru/contributor-ladder/_index.md new file mode 100644 index 0000000000..d9162aa717 --- /dev/null +++ b/content/ru/contributor-ladder/_index.md @@ -0,0 +1,126 @@ +--- +title: Роли контрибьюторов +toc_hide: true +status: Completed +menu: + main: + weight: 10 +--- + +Привет! 👋 Спасибо за интерес к участию в проекте CNCF Cloud Native Glossary. +Есть множество способов стать активным участником этого сообщества. +Можно предлагать новые термины, помогать в локализации Глоссария на родной язык или поддерживать и направлять новичков. +В этом документе описаны различные роли контрибьюторов в проекте, а также обязанности и привилегии, которые к ним прилагаются. + +## 1. Контрибьюторы + +Глоссарий открыт для всех. Любой может стать автором Глоссария, просто внеся свой вклад в проект. +При этом все участники должны следовать [Кодексу поведения CNCF](https://github.com/cncf/foundation/blob/main/code-of-conduct-languages/ru.md). + +Поучаствовать в проекте можно разными способами. Можно выступить в качестве: + +- **Автора**: улучшать существующие термины или предлагать новые, +- **Локализатора**: помогать перевести глоссарий на другой язык, +- **Помощника**: помогать другим на GitHub, в Slack или в других местах, где членам сообщества нужна поддержка, +- **Амбассадора**: помогать распространять информацию, объяснять сообществу, как и почему нужно вносить свой вклад. + +Участники могут выполнять сразу несколько ролей или сосредоточиться только на одной. +**Все эти роли одинаково важны** и способствуют процветанию сообщества. +Пожалуйста, обратитесь к разделам [Как внести свой вклад](/ru/contribute/) и [Руководство по стилю](/ru/style-guide/), чтобы подробнее узнать о том, как поучаствовать в проекте. + +## 2. Апруверы + +Апруверы дают обратную связь по PR'ам и одобряют их. Любой активный участник может стать апрувером (см. [Стать апрувером](#стать-апрувером)). +В Глоссарии различают два вида апруверов: (1) апруверы для оригинальной английской версии глоссария и (2) апруверы для команд локализации. + +Апруверы глоссария должны: + +- Проверять PR на техническую точность; +- Закреплять Issues за авторами и навешивать на них соответствующие лейблы; +- Давать контрибьюторам обратную связь и направлять их при необходимости; +- Вычитывать и редактировать материалы. + +Если апрувер более не заинтересован в выполнении вышеперечисленных обязанностей или не может их выполнять, он должен сообщить об этом мейнтейнерам и сложить свои полномочия. + +### Апруверы английской версии Глоссария + +Различают три вида апруверов: + +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. + +### Стать менеджером сообщества + +Любой желающий может стать менеджером сообщества Глоссария. +Менеджеры сообщества должны хорошо разбираться в процессе локализации, а также любить общаться и помогать другим. +Прежде всего расскажите действующим мейнтейнерам о своем желании стать менеджером. +После онбординга/пробного периода мейнтейнеры примут решение о предоставлении статуса менеджера сообщества, основываясь на результатах работы. + +## Принудительное удаление + +Принудительное удаление участника происходит при невыполнении обязанностей и требований, +а также в случае длительных периодов бездействия и/или нарушении кодекса поведения. +Принудительное удаление важно, поскольку защищает сообщество и его результаты, а также открывает возможности для новых контрибьюторов. + +## Снятие с себя полномочий/Почетное участие + +При снижении степени вовлеченности в проект контрибьюторы могут рассмотреть возможность снятия с себя части полномочий (с переходом на менее ответственную роль) или перехода в статус эмерита (полный отказ от участия в проекте). + +## Возвращение к роли + +Если у участника появляется возможность вернуться к прежней роли, лидеры проекта могут организовать и рассмотреть такую возможность. From e8605473b8e34c470ec84f39bf584961ee734105 Mon Sep 17 00:00:00 2001 From: Kirill Kononovich <41591254+kirkonru@users.noreply.github.com> Date: Wed, 9 Oct 2024 20:37:24 +0300 Subject: [PATCH 20/23] [ru] Localize `function-as-a-service` (#3217) Signed-off-by: Kirill Kononovich <41591254+kirkonru@users.noreply.github.com> --- content/ru/function-as-a-service.md | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+) create mode 100644 content/ru/function-as-a-service.md diff --git a/content/ru/function-as-a-service.md b/content/ru/function-as-a-service.md new file mode 100644 index 0000000000..843a4091ee --- /dev/null +++ b/content/ru/function-as-a-service.md @@ -0,0 +1,28 @@ +--- +title: Функция как сервис (FaaS) +status: Completed +category: Technology +tags: ["infrastructure", "", ""] +--- + +Функция как сервис (Function as a Service, FaaS) — модель облачных вычислений, которая предлагает платформу для выполнения функций, инициированных событиями. Она обеспечивает автоматическое масштабирование, не требующее ручного вмешательства. +В сущности FaaS позволяет развёртывать отдельные функции, которые активируются в ответ на определенные события, некоторое (короткое) время работают и отключаются. Тем самым гарантируется, что ресурсы не тратятся впустую. +Модель поддерживает [автоматическое масштабирование](/ru/auto-scaling/), позволяя запускать экземпляр функции по запросу и завершать его после выполнения, что соответствует его stateless-природе. +FaaS-платформы реализуют подход к тарификации по принципу «плати за фактическое использование»: когда функция не работает, она не потребляет ресурсы, экономя деньги. Этим они отличаются от других моделей, таких как [Платформа как услуга](/platform-as-a-service/) (Platform as a Service, PaaS), которые предполагают постоянную доступность ресурсов. + +## Какую проблему решает + +Традиционно компании предпочитали работать с собственными центрами обработки данных, что требовало значительных инвестиций в оборудование, программное обеспечение и персонал. +Такой подход означал, что ЦОД должен был проектироваться под пиковый спрос, а в остальное время его ресурсы использовались лишь частично. +Кроме того, стремительное развитие бизнеса могло опередить возможности ИТ и привести к операционной неэффективности. +С другой стороны, модели вида [Инфраструктура как услуга](/infrastructure-as-a-service/) (Infrastructure as a Service, IaaS), хотя и предлагают облачные решения, все же возлагают бремя масштабирования ресурсов на пользователя, требуя оплаты за постоянную доступность сервера независимо от фактического использования. + +## Как именно решает проблему + +FaaS предоставляет разработчикам [абстракцию](/ru/abstraction/) для запуска веб-приложений в ответ на события, избавляя их от необходимости управлять серверной инфраструктурой. +Например, загрузка файла может запустить кастомный код, который перекодирует файл в различные форматы. +Инфраструктура FaaS автоматически регулирует ресурсы в зависимости от спроса, освобождая разработчиков от необходимости писать код с учетом [масштабируемости](/scalability/) и связанных с этим сложностей. +Плата взимается только за время вычислений: когда функции неактивны, деньги не списываются. + +Для дополнительной информации рекомендуем ознакомиться со статьей глоссария о [бессерверных вычислениях](/serverless/). +Термины «бессерверный» и «FaaS» часто используются как взаимозаменяемые, однако они воплощают разные понятия. From 1c9c9b377ac6b813e52f9583134b8917e19647b5 Mon Sep 17 00:00:00 2001 From: Kirill Kononovich <41591254+kirkonru@users.noreply.github.com> Date: Wed, 9 Oct 2024 20:38:12 +0300 Subject: [PATCH 21/23] [ru] Localize `Infrastructure-as-a-service` (#3226) Signed-off-by: Kirill Kononovich <41591254+kirkonru@users.noreply.github.com> Co-authored-by: Dmitry Shurupov --- content/ru/infrastructure-as-a-service.md | 33 +++++++++++++++++++++++ 1 file changed, 33 insertions(+) create mode 100644 content/ru/infrastructure-as-a-service.md diff --git a/content/ru/infrastructure-as-a-service.md b/content/ru/infrastructure-as-a-service.md new file mode 100644 index 0000000000..f43b43b85f --- /dev/null +++ b/content/ru/infrastructure-as-a-service.md @@ -0,0 +1,33 @@ +--- +title: Инфраструктура как услуга (IaaS) +status: Completed +category: Technology +tags: ["infrastructure", "", ""] +--- + +Инфраструктура как услуга (Infrastructure as a service, IaaS) — это модель [облачных вычислений](/ru/cloud-computing/), при которой +[физические](/ru/bare-metal-machine/) или [виртуализированные](/virtualization/) вычислительные ресурсы, +хранилище и сетевой доступ предоставляются по требованию и оплачиваются по факту потребления. +Облачные провайдеры владеют и управляют аппаратным и программным обеспечением, +а потребители пользуются им в рамках открытых, закрытых или гибридных облачных развертываний. + +## Какую проблему решает + +В классических локальных (on-premises) окружениях организации часто сталкиваются с проблемой эффективного использования вычислительных ресурсов. +Центры обработки данных приходится строить с учетом потенциальной пиковой нагрузки, даже если она бывает лишь в 1 % случаев. +Все остальное время эти вычислительные ресурсы простаивают. +С другой стороны, если рабочая нагрузка превышает прогнозируемый спрос, +возникает острая нехватка вычислительных ресурсов. +Подобные проблемы в масштабируемости приводят к увеличению затрат и неэффективному использованию ресурсов. + +## Как именно решает проблему + +Благодаря IaaS организации могут не тратить средства на покупку и обслуживание вычислительных мощностей для своих приложений. +Инфраструктура, предоставляемая по требованию, позволяет им арендовать вычислительные ресурсы по мере необходимости, +экономя на [капитальных расходах](https://ru.wikipedia.org/wiki/%D0%9A%D0%B0%D0%BF%D0%B8%D1%82%D0%B0%D0%BB%D1%8C%D0%BD%D1%8B%D0%B5_%D1%80%D0%B0%D1%81%D1%85%D0%BE%D0%B4%D1%8B), +и при этом обеспечивает гибкость, связанную с возможностью вертикального масштабирования в обе стороны. + +IaaS снижает первоначальные затраты на эксперименты или тестирование нового приложения и +предоставляет возможности для быстрого развертывания инфраструктуры. +Облачные провайдеры отлично подходят для создания сред разработки и тестирования, +которые необходимы разработчикам для экспериментирования и внедрения инноваций. From b70cb8098709757edfbcee28da5f30356c1b8a3a Mon Sep 17 00:00:00 2001 From: Kirill Kononovich <41591254+kirkonru@users.noreply.github.com> Date: Wed, 9 Oct 2024 20:38:39 +0300 Subject: [PATCH 22/23] [ru] Localize `Edge computing` (#3216) Signed-off-by: Timur Tukaev <90071493+tym83@users.noreply.github.com> Signed-off-by: Kirill Kononovich <41591254+kirkonru@users.noreply.github.com> --- content/ru/edge-computing.md | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) create mode 100644 content/ru/edge-computing.md diff --git a/content/ru/edge-computing.md b/content/ru/edge-computing.md new file mode 100644 index 0000000000..d5aa5dc0b7 --- /dev/null +++ b/content/ru/edge-computing.md @@ -0,0 +1,27 @@ +--- +title: Граничные (edge) вычисления +status: Completed +category: Technology +--- + +*Граничные вычисления* (edge computing), также известные как *периферийные* — это подход к [распределённым системам](/ru/distributed-systems/), при котором часть задач по хранению и обработке данных переносится от основного [центра обработки данных](/ru/data-center/) к источнику данных. +Собранные данные обрабатываются локально (например, на предприятии, в магазине или по всему городу), а не отправляются в централизованный дата-центр для обработки и анализа. +Локальные вычислительные устройства находятся на периферии системы, тогда как дата-центр является её центром. +Затем результаты, полученные на периферии, отправляются в главный ЦОД для дальнейшей обработки. +Показательными примерами подхода являются носимые гаджеты или компьютеры, которые следят за дорожным трафиком и анализируют транспортные потоки. + +## Какую проблему решает + +В последнее десятилетие наблюдается рост числа периферийных устройств (таких как мобильные телефоны, умные часы и всевозможные датчики). +В некоторых случаях обработка данных в реальном времени не просто желательна, а жизненно необходима. +Достаточно вспомнить о самоуправляемых автомобилях. +Представьте, что данные с датчиков автомобиля приходилось бы передавать по сети в ЦОД для обработки, а затем обратно на автомобиль. +Подобная задержка в реакции, очевидно, неприемлема, когда важна каждая секунда. +Хотя это и крайний пример, большинство пользователей не готовы работать с умными устройствами, которые не дают мгновенную обратную связь. + +## Как именно решает проблему + +Как сказано выше, чтобы периферийные устройства были полезными, они должны выполнять хотя бы часть задач по обработке и анализу данных локально, обеспечивая обратную связь почти в реальном времени. +Это достигается за счёт переноса части ресурсов для хранения и обработки данных из ЦОД в место, где эти данные генерируются, то есть периферийное устройство. +Обработанные и необработанные данные затем отправляются в ЦОД для дальнейшей обработки и хранения. +Одним словом, эффективность и скорость — решающие факторы для граничных вычислений. From 91af09ab3e4e4e2888b3ef45a53f560b6599ca2f Mon Sep 17 00:00:00 2001 From: Kirill Kononovich <41591254+kirkonru@users.noreply.github.com> Date: Mon, 14 Oct 2024 13:11:29 +0300 Subject: [PATCH 23/23] Translate titles: Digital certificate and Distributed System (#3324) Signed-off-by: Kirill Kononovich <41591254+kirkonru@users.noreply.github.com> --- content/ru/digital-certificate.md | 2 +- content/ru/distributed-systems.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ru/digital-certificate.md b/content/ru/digital-certificate.md index 93d1181a77..833728c757 100644 --- a/content/ru/digital-certificate.md +++ b/content/ru/digital-certificate.md @@ -1,5 +1,5 @@ --- -title: Digital Certificate +title: Цифровой сертификат status: Feedback Appreciated category: technology tags: ["security", "", ""] diff --git a/content/ru/distributed-systems.md b/content/ru/distributed-systems.md index d3c8396b71..62bc5ff7fc 100644 --- a/content/ru/distributed-systems.md +++ b/content/ru/distributed-systems.md @@ -1,5 +1,5 @@ --- -title: Distributed System +title: Распределенная система status: Completed category: concept tags: ["architecture", "", ""]