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. + +### Стать менеджером сообщества + +Любой желающий может стать менеджером сообщества Глоссария. +Менеджеры сообщества должны хорошо разбираться в процессе локализации, а также любить общаться и помогать другим. +Прежде всего расскажите действующим мейнтейнерам о своем желании стать менеджером. +После онбординга/пробного периода мейнтейнеры примут решение о предоставлении статуса менеджера сообщества, основываясь на результатах работы. + +## Принудительное удаление + +Принудительное удаление участника происходит при невыполнении обязанностей и требований, +а также в случае длительных периодов бездействия и/или нарушении кодекса поведения. +Принудительное удаление важно, поскольку защищает сообщество и его результаты, а также открывает возможности для новых контрибьюторов. + +## Снятие с себя полномочий/Почетное участие + +При снижении степени вовлеченности в проект контрибьюторы могут рассмотреть возможность снятия с себя части полномочий (с переходом на менее ответственную роль) или перехода в статус эмерита (полный отказ от участия в проекте). + +## Возвращение к роли + +Если у участника появляется возможность вернуться к прежней роли, лидеры проекта могут организовать и рассмотреть такую возможность. 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/) — дата-центры, предоставляющие вычислительные ресурсы пользователям в аренду. +В последние годы наблюдается переход от корпоративных дата-центров к вычислительным мощностям в облаке. diff --git a/content/ru/digital-certificate.md b/content/ru/digital-certificate.md new file mode 100644 index 0000000000..833728c757 --- /dev/null +++ b/content/ru/digital-certificate.md @@ -0,0 +1,22 @@ +--- +title: Цифровой сертификат +status: Feedback Appreciated +category: technology +tags: ["security", "", ""] +--- + +(Цифровой) сертификат / сертификат открытого ключа / SSL-сертификат — это электронный документ, который используется для безопасного обмена информацией по сети. +Сертификат подтверждает, что объект, с которым происходит коммуникация, действительно тот, за кого себя выдает. +Кроме того, благодаря шифрованию исходящих и входящих данных сертификат гарантирует конфиденциальность обмена информацией. + +## Какую проблему решает + +Когда устройство взаимодействует по сети с другими сущностями, у него нет гарантии, что другое устройство, с которым оно взаимодействует, является тем, за кого себя выдает. +Кроме того, нельзя гарантировать, что трафик между двумя устройствами не перехватит третья сторона. +Следовательно, любая коммуникация потенциально может быть перехвачена, а значит, конфиденциальная информация, например имена пользователей и пароли, может быть скомпрометирована. + +## Как именно решает проблему + +Современные почтовые клиенты, которые используют сертификаты, могут сообщать, верны ли идентификационные данные отправителя. Браузеры тоже это умеют — обратите внимание на замочек слева от адресной строки. +Кроме того, сертификат может применяться для шифрования передачи данных между различными объектами в интернете. +Механизм шифрования в сертификате делает чтение данных практически невозможным для тех, кто сумел их перехватить. 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/). +Однако за это приходится платить: поскольку вместо одного приложения выполняется множество его компонентов, растут сложность и операционные издержки. diff --git a/content/ru/distributed-systems.md b/content/ru/distributed-systems.md new file mode 100644 index 0000000000..62bc5ff7fc --- /dev/null +++ b/content/ru/distributed-systems.md @@ -0,0 +1,29 @@ +--- +title: Распределенная система +status: Completed +category: concept +tags: ["architecture", "", ""] +--- + +Распределенная система — это набор автономных вычислительных элементов, которые соединены по сети и воспринимаются пользователями как единая целостная система. +Эти компоненты, обычно называемые [узлами](/nodes/), могут быть аппаратными устройствами (например, компьютеры, мобильные телефоны) или программными процессами. +Узлы запрограммированы на достижение общей цели и взаимодействуют, обмениваясь сообщениями по сети. + +## Какую проблему решает + +Многие современные приложения настолько крупные, что для их работы потребовались бы суперкомпьютеры. +Вспомните Gmail или Netflix. Ни у одного компьютера не хватит мощности, чтобы разместить на нем целиком такое приложение. +А вот если соединить множество компьютеров, вычислительная мощность становится практически безграничной. +Многие приложения, на которые мы сегодня полагаемся, не могли бы существовать без распределенных вычислений. + +Исторически системы [масштабировались](/scalability/) вертикально. +Это означает, что к отдельной машине добавляется дополнительный процессор или память. +Вертикальное масштабирование занимает много времени, быстро достигает предела и приводит к простою. + +## Как именно решает проблему + +Распределенная система может [масштабироваться горизонтально](/horizontal-scaling/): например, при необходимости в систему добавляются дополнительные узлы. +Этот процесс можно автоматизировать — тогда система сможет справляться с внезапным ростом нагрузки или потребления ресурсов. + +Нераспределенная система подвержена риску сбоев, так как при поломке одной машины выходит из строя вся система. +Распределенную систему можно спроектировать так, чтобы даже при поломке нескольких машин она продолжала работать с тем же результатом. 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/) к источнику данных. +Собранные данные обрабатываются локально (например, на предприятии, в магазине или по всему городу), а не отправляются в централизованный дата-центр для обработки и анализа. +Локальные вычислительные устройства находятся на периферии системы, тогда как дата-центр является её центром. +Затем результаты, полученные на периферии, отправляются в главный ЦОД для дальнейшей обработки. +Показательными примерами подхода являются носимые гаджеты или компьютеры, которые следят за дорожным трафиком и анализируют транспортные потоки. + +## Какую проблему решает + +В последнее десятилетие наблюдается рост числа периферийных устройств (таких как мобильные телефоны, умные часы и всевозможные датчики). +В некоторых случаях обработка данных в реальном времени не просто желательна, а жизненно необходима. +Достаточно вспомнить о самоуправляемых автомобилях. +Представьте, что данные с датчиков автомобиля приходилось бы передавать по сети в ЦОД для обработки, а затем обратно на автомобиль. +Подобная задержка в реакции, очевидно, неприемлема, когда важна каждая секунда. +Хотя это и крайний пример, большинство пользователей не готовы работать с умными устройствами, которые не дают мгновенную обратную связь. + +## Как именно решает проблему + +Как сказано выше, чтобы периферийные устройства были полезными, они должны выполнять хотя бы часть задач по обработке и анализу данных локально, обеспечивая обратную связь почти в реальном времени. +Это достигается за счёт переноса части ресурсов для хранения и обработки данных из ЦОД в место, где эти данные генерируются, то есть периферийное устройство. +Обработанные и необработанные данные затем отправляются в ЦОД для дальнейшей обработки и хранения. +Одним словом, эффективность и скорость — решающие факторы для граничных вычислений. 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-запросы. +Однако это было бы крайне неэффективно, поскольку для каждого события приходилось бы устанавливать отдельное соединение. +Поскольку всё чаще возникает потребность в данных, передаваемых в режиме реального времени, масштабирование такого решения стало бы сложной задачей. +А вот подход, при котором открывается соединение с дальнейшей подпиской на поток событий, уже идеально подходит для сбора данных в реальном времени. +Объём генерируемых данных экспоненциально растёт, а вместе с ним постоянно меняется и состояние данных. Разработчики и пользователи должны иметь возможность видеть эти данные практически в реальном времени. + +## Как именно решает проблему + +Потоковая передача событий позволяет передавать изменения данных от источника к получателю. +Вместо того, чтобы ждать, пока другие сервисы запросят информацию, сервис непрерывно транслирует все произошедшие в нём события (или действия). +При этом сервис не заботится о том, что происходит с отправляемыми им данными. +Он просто выполняет свои задачи и транслирует информацию, оставаясь полностью независимым от любого другого сервиса. 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» часто используются как взаимозаменяемые, однако они воплощают разные понятия. 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/) 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", "", ""] +--- + +В математике или информатике идемпотентность описывает операцию, которая всегда приводит к одному и тому же результату, +независимо от того, сколько раз она выполняется. +Если параметры не меняются, многократное выполнение идемпотентной операции не приводит к каким-либо дополнительным изменениям. 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). +Такое сочетание неизменяемости и контроля версий позволяет +вести долговременный журнал аудита каждого авторизованного изменения в системе. 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 снижает первоначальные затраты на эксперименты или тестирование нового приложения и +предоставляет возможности для быстрого развертывания инфраструктуры. +Облачные провайдеры отлично подходят для создания сред разработки и тестирования, +которые необходимы разработчикам для экспериментирования и внедрения инноваций. 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/), +используя при этом контроль версий и стратегии развертывания. 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 упрощает масштабирование, оптимизирует использование ресурсов, снижает затраты и повышает общую управляемость приложений, работающих в кластере. 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/) стараются упростить процессы развертывания микросервисов и управления ими. 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/) увеличивает операционные издержки, связанные с +тестированием, развертыванием и последующей эксплуатацией. +На ранних этапах жизненного цикла продукта разумно воздержаться от такого усложнения, придерживаясь монолитного подхода до тех пор, +пока продукт не будет признан успешным. + +## Как именно решает проблему + +Хорошо спроектированный монолит соответствует принципам бережливого производства, +являясь самым простым способом разработки и запуска приложения. +Когда монолитное приложение докажет свою полезность для бизнеса, его можно будет разбить на микросервисы. +Разработка микросервисного приложения еще до того, как станет ясно, что оно приносит реальную пользу, может превратиться +в бессмысленную трату ценных инженерных ресурсов. +Если приложение окажется невостребованным, эти дополнительные усилия разработчиков будут потрачены впустую. 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-системы часто проектируются как мультитенантные, а сама мультитенантность рекламируется +как одно из их ключевых преимуществ. 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) и другие. 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/) платформах или приложениях узел — это рабочая единица. +В идеале отдельные узлы недифференцированы, то есть любой узел определенного типа неотличим от любого другого узла того же типа. 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). + +Наблюдаемые системы предоставляют своим операторам содержательные и практические данные, которые позволяют добиваться лучших результатов (быстрее реагировать на инциденты, повышать производительность разработчиков), снижать объемы рутинных операций и сокращать время простоя. + +Таким образом, уровень наблюдаемости системы существенно влияет на её эксплуатационные издержки и затраты на разработку.