From 8c3a26457ac876b9c9ce688c68a7682a5ad7db01 Mon Sep 17 00:00:00 2001 From: tym83 <6355522@gmail.com> Date: Tue, 26 Dec 2023 07:04:09 +0500 Subject: [PATCH] Review initial Russian content Apply suggestions from code review Co-authored-by: Dmitry Shurupov Signed-off-by: Kirill Kononovich <41591254+kirkonru@users.noreply.github.com> Apply suggestions from code review Update content/ru/_TEMPLATE.md Redo section names Delete first section header - continuous-delivery.md Signed-off-by: Kirill Kononovich <41591254+kirkonru@users.noreply.github.com> --- content/ru/_TEMPLATE.md | 12 ++++----- content/ru/_index.md | 12 ++++----- content/ru/cloud-native-apps.md | 36 +++++++++++++-------------- content/ru/cloud-native-tech.md | 28 ++++++++++----------- content/ru/container-orchestration.md | 18 ++++++-------- content/ru/container.md | 30 +++++++++++----------- content/ru/containerization.md | 28 ++++++++++----------- content/ru/continuous-delivery.md | 24 ++++++++---------- content/ru/continuous-deployment.md | 22 ++++++++-------- content/ru/continuous-integration.md | 25 ++++++++----------- content/ru/devops.md | 28 ++++++++++----------- content/ru/devsecops.md | 30 +++++++++++----------- content/ru/kubernetes.md | 34 ++++++++++++------------- content/ru/style-guide/_index.md | 2 +- 14 files changed, 152 insertions(+), 177 deletions(-) diff --git a/content/ru/_TEMPLATE.md b/content/ru/_TEMPLATE.md index 018f003932..20c4c7c0ab 100644 --- a/content/ru/_TEMPLATE.md +++ b/content/ru/_TEMPLATE.md @@ -4,18 +4,16 @@ status: Feedback Appreciated category: concept --- -## Описание - Краткое и четкое описание того, о чем идет речь. -## Проблема +## Какую проблему решает -Проблема, которую решает описываемая технология. Избегайте упоминать термин, для которого дается определение. В этом разделе необходимо сфокусироваться на предпосылках, которые привели к разработке данной технологии/концепции. +Проблема, которую решает описываемая технология. Старайтесь не использовать термин, которому вы даете определение. В этом разделе необходимо сфокусироваться на предпосылках, которые стали причиной появления описываемой технологии или концепции. -## Решение +## Как именно решает проблему -Здесь можно вернуться к самому термину. Как он помогает решить проблему, описанную выше? +Здесь можно вернуться к самому термину и объяснить, как именно он помогает решить описанную в предыдущем пункте проблему. ## Связанные термины -Добавьте связанные термины из глоссария (если такие имеются). +Добавьте сюда другие релевантные термины из глоссария (если они есть). diff --git a/content/ru/_index.md b/content/ru/_index.md index bc27d9cf8c..1c50d6f1b1 100644 --- a/content/ru/_index.md +++ b/content/ru/_index.md @@ -5,23 +5,23 @@ status: Completed # Глоссарий Cloud Native -Глоссарий Cloud Native помогает разобраться в облачном пространстве (которое печально известно своей сложностью) не только IT-специалистам, но также представителям бизнеса и всем интересующимся. -Для этого мы делаем упор на простоту (доступный язык, свободный от модных словечек; примеры, которые понятны любому человеку с базовыми представлениями о технологиях; отказ от лишних подробностей). +Глоссарий Cloud Native преназначен для того, чтобы в сфере cloud native, сложность которой уже стала притчей во языцех, было легче разобраться не только IT-специалистам, но и представителям бизнеса. +Именно поэтому мы делаем упор на простоту (доступный язык, свободный от заковыристых терминов; примеры, которые понятны любому человеку с базовым пониманием технологий; отказ от лишних подробностей). Работа над глоссарием ведется под руководством подкомитета CNCF по деловой ценности (Business Value Subcommittee, BVS).

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

## Внести свой вклад -Приглашаем всех желающих поучаствовать в развитии Глоссария Cloud Native, его дополнении и улучшении. -Процесс разработки единого лексикона и его совершенствования управляется сообществом и регулируется CNCF. +Приглашаем всех желающих поучаствовать в развитии «Глоссария Cloud Native», его дополнении и улучшении. +Процесс разработки единой терминологии и ее совершенствования управляется сообществом и регулируется CNCF. Глоссарий придерживается принципа независимости от конкретных вендоров и ставит своей целью создание словаря-справочника по нативным облачным технологиям. Приветствуется любое участие при условии, что оно соответствует целям и уставу проекта. Все желающие могут открыть Issue на GitHub или создать Pull Request. Для этого необходимо предварительно ознакомиться с документом [Как внести свой вклад](/ru/contribute/) и присоединиться к каналу [#glossary](https://cloud-native.slack.com/archives/C02TX20MQBB) в рабочем пространстве CNCF в Slack. Кроме того, важно убедиться, что предлагаемые правки соответствуют [Руководству по стилю](/ru/style-guide/). -Для тех, кто хочет помочь перевести глоссарий на родной язык, существует канал [#glossary-localizations](https://cloud-native.slack.com/archives/C02N2RGFXDF) (для русского языка — [#glossary-localization-russian](https://cloud-native.slack.com/archives/C05G46RMQTX)). +Для тех, кто хочет поучаствовать в переводе глоссария на родной язык, существует канал [#glossary-localizations](https://cloud-native.slack.com/archives/C02N2RGFXDF) (для русского языка — [#glossary-localization-russian](https://cloud-native.slack.com/archives/C05G46RMQTX)). ## Благодарности @@ -33,7 +33,7 @@ status: Completed [Katelin Ramer](https://www.linkedin.com/in/katelinramer/), [Mike Foster](https://www.linkedin.com/in/mfosterche/?originalSubdomain=ca), и многих других авторов. -Полный список участников проекта можно найти на [этой странице](https://github.com/cncf/glossary/graphs/contributors) на GitHub. +Полный список участников проекта можно найти на [отдельной странице](https://github.com/cncf/glossary/graphs/contributors) на GitHub. Хранителями глоссария являются: - [Noah Ispas](https://www.linkedin.com/in/noah-ispas-0665b42a/); diff --git a/content/ru/cloud-native-apps.md b/content/ru/cloud-native-apps.md index f4199def5f..9da063d085 100644 --- a/content/ru/cloud-native-apps.md +++ b/content/ru/cloud-native-apps.md @@ -5,26 +5,24 @@ category: concept tags: ["application", "fundamental", ""] --- -## Описание +Нативные облачные (cloud native) приложения специально спроектированы для того, чтобы извлечь максимальную пользу из достижений в сфере [облачных вычислений](/cloud-computing/). +Такие приложения легко интегрируются с различными видами облачных архитектур, +используя облачные ресурсы и их способность к [масштабированию](/scalability/). +Также этот термин применяется и по отношению к приложениям, которые используют новейшие наработки в области инфраструктуры, вызванные развитием облачных вычислений. +К нативным облачным приложениям относят приложения, которые работают в центрах обработки данных облачных провайдеров и на локальных (on-premise) платформах, предназначенных для работы с облаками. -Нативные облачные (cloud native) приложения специально спроектированы для того, чтобы максимально использовать инновации в области [облачных вычислений](/cloud-computing/). -Эти приложения легко интегрируются с соответствующими облачными архитектурами, -пользуясь ресурсами облака и его способностью к [масштабированию](/scalability/). -Это также относится к приложениям, использующим преимущества инноваций в инфраструктуре, основанной на облачных вычислениях. -Сегодня к нативным облачным приложениям относятся приложения, работающие в центрах обработки данных облачных провайдеров и на локальных (on-premise) платформах, спроектированных для работы с облаком. +## Какую проблему решает -## Проблема +Традиционно локальные среды предоставляли уникальные, отличные друг от друга и несовместимые вычислительные ресурсы. +В каждом центре обработки данных имелись сервисы, которые [жестко привязывали](/tightly-coupled-architectures/) приложения к конкретным окружениям и чаще всего подразумевали, что инфраструктура (например, [виртуальные машины](/virtual-machine/) и различные сервисы) подготавливается вручную. +Из-за этого разработчики и их приложения зависели и были привязаны к конкретному центру обработки данных. +Приложения, которые не были специально разработаны для облачных сред, не могли полноценно задействовать преимущества облачных вычислений — отказоустойчивость и возможности по масштабированию. +Например, приложения, для корректного запуска которых требуется ручное вмешательство, не могут автоматически масштабироваться +и автоматически перезапускаться в случае сбоя. -Традиционно локальные среды предоставляли вычислительные ресурсы достаточно узкоспециализированным образом. -В каждом центре обработки данных имелись сервисы, которые [жестко привязывали](/tightly-coupled-architectures/) приложения к конкретным окружениям, часто в значительной степени опираясь на ручную подготовку инфраструктуры (например, [виртуальных машин](/virtual-machine/) и сервисов). -В свою очередь, это привязывало разработчиков и их приложения к конкретному центру обработки данных. -Приложения, которые не были специально разработаны для облачных сред, не могли воспользоваться их отказоустойчивостью и возможностями масштабирования. -Например, приложения, для корректного запуска которых требуется ручное вмешательство, не могут автоматически масштабироваться, -равно как и автоматически перезапускаться в случае сбоя. +## Как именно решает проблему -## Решение - -Хотя не существует универсального пути к построению нативных облачных приложений, у них все же есть некоторые общие черты. -Нативные облачные приложения устойчивы к внешним воздействиям, управляемы и поддерживаются набором сопутствующих облачных сервисов. -Различные облачные сервисы обеспечивают высокую степень [наблюдаемости](/observability/), позволяя обнаруживать и оперативно устранять проблемы до их разрастания. -В сочетании с надежной автоматизацией они позволяют инженерам часто и предсказуемо вносить важные изменения с минимальными усилиями. +Хотя не существует универсального рецепта для создания нативных облачных приложений, у таких приложений все же есть некоторые общие черты. +Нативные облачные приложения обладают высокой отказоустойчивостью, ими удобно управлять, а кроме того, с ними может взаимодействовать целый набор сопутствующих облачных сервисов. +Так, различные облачные сервисы обеспечивают отличную [наблюдаемость](/observability/), позволяя обнаруживать и оперативно устранять проблемы еще до того, как они станут критическими. +А в сочетании с мощной автоматизацией такие сервисы дают инженерам возможность вносить в проект необходимые важные изменения регулярно, с высокой частотой и предсказуемо — причем без лишних хлопот. diff --git a/content/ru/cloud-native-tech.md b/content/ru/cloud-native-tech.md index 7fc7d2d7d9..e5d96a9787 100644 --- a/content/ru/cloud-native-tech.md +++ b/content/ru/cloud-native-tech.md @@ -5,28 +5,26 @@ category: Concept tags: ["fundamental", "", ""] --- -## Описание - Нативные облачные (cloud native) технологии, также называемые нативным облачным стеком, — -это технологии, используемые для создания [нативных облачных приложений](/ru/cloud-native-apps/). +это технологии, которые используются для создания [нативных облачных приложений](/ru/cloud-native-apps/). Эти технологии позволяют компаниям создавать и запускать масштабируемые приложения в современных и динамичных средах, таких как публичные, приватные и гибридные облака, -максимально используя преимущества [облачных вычислений](/cloud-computing/). -Они изначально разрабатываются для максимального использования возможностей облачных вычислений, и примером такого подхода являются контейнеры, сервис-меши, микросервисы и неизменяемая (immutable) инфраструктура. +максимально используя сильные стороны [облачных вычислений](/cloud-computing/). +Они изначально разрабатываются для максимального использования преимуществ облачных вычислений. Пример реализации такого подхода — контейнеры, service mesh, микросервисы и неизменяемая (immutable) инфраструктура. -## Проблема +## Какую проблему решает -Нативный облачный стек включает в себя множество различных технологий, решающих самые разные задачи. +Нативный облачный стек включает в себя множество различных технологий, призванных дать ответ на самые разные вызовы. Если взглянуть на многообразие приложений в [CNCF Cloud Native Landscape](https://landscape.cncf.io/), можно увидеть, как много различных областей они охватывают. -Но на высоком уровне они решают один базовый набор задач — -устраняют недостатки традиционных моделей эксплуатации ИТ. -Среди этих задач — трудности при создании масштабируемых, отказоустойчивых, самовосстанавливающихся приложений, -а также неэффективное использование ресурсов и др. +Но по сути они решают единый базовый набор задач — +устраняют недостатки традиционных моделей эксплуатации в ИТ. +Примеры таких вызовов: трудности создания масштабируемых, отказоустойчивых, способных восстанавливаться самостоятельно приложений, +неэффективное использование ресурсов и др. -## Решение +## Как именно решает проблему Хотя каждая технология решает свою специфическую задачу, -в совокупности нативные облачные технологии позволяют создавать слабосвязанные системы, устойчивые к внешним воздействиям, управляемые и наблюдаемые. -В сочетании с надежной автоматизацией они позволяют инженерам с минимальными усилиями вносить серьезные изменения часто и с предсказуемым результатом. -Желаемые характеристики нативных облачных систем легче реализовать с помощью соответствующего нативного облачного стека. +в совокупности нативный облачный стек позволяет создавать слабосвязанные системы, устойчивые к внешним воздействиям, с хорошей управляемостью и наблюдаемостью. +В сочетании с надежной автоматизацией они позволяют инженерам вносить серьезные изменения часто и с предсказуемым результатом — причем такой результат достигается минимальными усилиями. +Необходимых параметров при создании нативных облачных систем легче всего достичь именно с помощью соответствующего нативного облачного стека. diff --git a/content/ru/container-orchestration.md b/content/ru/container-orchestration.md index c83d5931b5..1a2bdf0b37 100644 --- a/content/ru/container-orchestration.md +++ b/content/ru/container-orchestration.md @@ -4,22 +4,20 @@ status: Completed category: Concept --- -## Описание - Под оркестрацией [контейнеров](/ru/container/) понимается автоматизация жизненного цикла контейнеризованных приложений в динамических средах и управление им. -Она осуществляется с помощью оркестратора контейнеров (в большинстве случаев это [Kubernetes](/ru/kubernetes)), который отвечает за развертывание, (авто)масштабирование, автовосстановление и мониторинг. +Она осуществляется с помощью оркестратора контейнеров (чаще всего — [Kubernetes](/ru/kubernetes)), который отвечает за развертывание, (авто)масштабирование, автовосстановление и мониторинг. Оркестрация — это метафора: -инструмент оркестрации управляет контейнерами, как дирижер музыкой, следя за тем, чтобы каждый контейнер (музыкант) делал то, что должен. +инструмент оркестрации управляет контейнерами так же, как дирижер — музыкой, следя за тем, чтобы каждый контейнер (музыкант) делал то, что должен. -## Проблема +## Какую проблему решает -Вручную управлять [микросервисами](/microservices), обеспечивать безопасность и контролировать сетевое взаимодействие в больших масштабах (а также управлять [распределенными системами](/distributed-systems) в целом) -сложно, а иногда и невозможно. -Оркестрация контейнеров позволяет автоматизировать все эти управленческие задачи. +Вручную управлять [микросервисами](/microservices), обеспечивать безопасность и контролировать сетевое взаимодействие на больших масштабах (как и вообще управлять [распределенными системами](/distributed-systems)) +сложно, а подчас и невозможно. +Оркестрация контейнеров позволяет автоматизировать задачи по управлению ими. -## Решение +## Как именно решает проблему Инструменты для оркестрации контейнеров позволяют пользователям задавать состояние системы. На начальном этапе они определяют, как система должна выглядеть (например, X контейнеров, Y подов и т. д.). -Затем инструмент оркестрации автоматически отслеживает состояние инфраструктуры и корректирует его при отклонении от заявленного (например, при сбое одного контейнера запускает другой). +Затем инструмент оркестрации начинает автоматически отслеживать состояние инфраструктуры и при возникновении отклонений приводить его к описанному на первом этапе состонию (например, при сбое одного контейнера запускается другой). Такая автоматизация упрощает выполнение многих сложных задач эксплуатации (которые в противном случае выполнялись бы вручную), включая выделение ресурсов, развертывание, масштабирование (вверх и вниз), работу с сетью, балансировку нагрузки и другие действия. diff --git a/content/ru/container.md b/content/ru/container.md index 41c4a07a91..f02f3bfabd 100644 --- a/content/ru/container.md +++ b/content/ru/container.md @@ -5,30 +5,28 @@ category: technology tags: ["application", "fundamental", ""] --- -## Описание - -Контейнер — это процесс, работающий под управлением операционной системы компьютера. -Для него заданы определенные ограничения на ресурсы и возможности, и ОС следит за тем, чтобы эти ограничения соблюдались. -Файлы, доступные процессу, упаковываются в образ контейнера. +Контейнер — это запущенный процесс, работающий под управлением операционной системы компьютера, ограниченный в ресурсах и возможностях. +Файлы, доступные такому процессу, упаковываются в так называемый образ контейнера. Контейнеры работают рядом друг с другом на одной и той же машине, -при этом операционная система, как правило, не позволяет отдельным контейнерам взаимодействовать друг с другом. +при этом операционная система, как правило, не позволяет контейнерам напрямую взаимодействовать. -## Проблема +## Какую проблему решает До появления контейнеров для запуска приложений требовались отдельные машины. -На каждой машине устанавливалась операционная система, которая потребляла ресурсы процессора и памяти, а также дисковое пространство — и все это для работы одного единственного приложения. -Кроме того, приходилось тратить значительные силы на обслуживание, обновление и запуск самой операционной системы. +На каждой машине устанавливалась операционная система, которая потребляла ресурсы процессора и памяти, а также дисковое пространство +— и все это для работы одного единственного приложения. +Кроме того, приходилось тратить значительные ресурсы на обслуживание, обновление и запуск самой операционной системы. -## Решение +## Как именно решает проблему -Контейнеры совместно используют одну и ту же операционную систему и ее машинные ресурсы. +Контейнеры совместно используют одну и ту же операционную систему и работающее под ее управлением железо. Другими словами, вместо множества копий ОС используется лишь одна: ресурсы, потребляемые операционной системой, делятся сразу на множество контейнеров. Тем самым обеспечивается эффективное использование памяти, процессора и дискового пространства. -Такая совместная работа контейнеров возможна только потому, что они, как правило, не могут взаимодействовать друг с другом. -Это позволяет запускать на одной физической машине больше приложений. +Такая совместная работа контейнеров возможна только потому, что они, как правило, не могут напрямую взаимодействовать. +Это позволяет запускать на одной физической машине гораздо больше приложений. Однако есть и ограничения. -Подход, когда множество контейнеров используют одну и ту же операционную систему, потенциально более опасен, чем альтернативные варианты. -Кроме того, для контейнеров приходится задавать ограничения на общие ресурсы. -Лимитировать использование памяти и процессора необходимо для того, чтобы гарантировать, что все приложения смогут корректно функционировать. +Подход, когда множество контейнеров используют одну и ту же операционную систему, потенциально более опасен, чем другие варианты. +Кроме того, контейнерам необходимо задавать ограничения на использование общих ресурсов. +Администратор должен ограничивать использование памяти и процессора — это позволяет гарантировать, что остальные приложения не столкнутся с нехваткой ресурсов. diff --git a/content/ru/containerization.md b/content/ru/containerization.md index 897557987f..699ee38fd9 100644 --- a/content/ru/containerization.md +++ b/content/ru/containerization.md @@ -5,26 +5,24 @@ category: Technology tags: ["application", "", ""] --- -## Описание - -Контейнеризация — это упаковка приложения и его зависимостей в [контейнерный образ](/container-image/). +Контейнеризация — это упаковка приложения и всех необходимых зависимостей в [образ контейнера](/container-image/). Процесс сборки контейнера должен соответствовать стандарту [Open Container Initiative](https://opencontainers.org) (OCI). Если на выходе получается образ контейнера, соответствующий этому стандарту, то не важно, какое именно средство контейнеризации использовалось. -## Проблема +## Какую проблему решает -До того как контейнеры получили широкое распространение, для запуска множества приложений на одном ["железном"](/bare-metal-machine/) (bare-metal) сервере использовались виртуальные машины. -ВМ по своей природе значительно «тяжелее» контейнеров, и для их работы необходим гипервизор. -Создание шаблонизированных решений на базе ВМ затруднено необходимостью хранения, резервного копирования и передачи больших объемов данных. -Кроме того, ВМ могут страдать от появляющихся со временем изменений в конфигурации, что нарушает принцип [неизменяемости](/immutable-infrastructure/). +До того как контейнеры получили широкое распространение, для запуска множества приложений на одном [«железном»](/bare-metal-machine/) (bare-metal) сервере использовались виртуальные машины. +Однако виртуальные машины гораздо «тяжелее» контейнеров, и для их работы необходим гипервизор. +Создание шаблонизированных решений на базе виртуальных машин затруднено необходимостью хранения, резервного копирования и передачи больших объемов данных. +Кроме того, одна из болей виртуальных машин — появляющиеся со временем изменения в конфигурации, которые нарушают принцип [неизменяемости](/immutable-infrastructure/). -## Решение +## Как именно решает проблему -От традиционных ВМ образы контейнеров отличаются гораздо меньшими размерами, -а для контейнеризации требуется лишь файл со списком зависимостей. -Модификации этого файла можно отслеживать в системе контроля версий, а процесс сборки — автоматизировать, -что позволяет организации сосредоточиться на других задачах. -У каждого образа контейнера имеется уникальный идентификатор, +От традиционных виртуальных машин образы контейнеров отличаются гораздо меньшими размерами, +а для самого процесса контейнеризации нужен только файл со списком зависимостей. +Изменения в этом файле можно отслеживать в системе контроля версий, а процесс сборки — автоматизировать, +что позволяет организации сосредоточиться на других важных задачах. +У каждого образа контейнера есть уникальный идентификатор, привязанный к его содержимому и конфигурации. При планировании (размещении на узлы) и перепланировании контейнеры всегда -сбрасываются в исходное состояние, что исключает расхождения в конфигурации. +сбрасываются до исходного состояния, что исключает расхождения в конфигурации. diff --git a/content/ru/continuous-delivery.md b/content/ru/continuous-delivery.md index 7f2f360a08..0294520efb 100644 --- a/content/ru/continuous-delivery.md +++ b/content/ru/continuous-delivery.md @@ -5,31 +5,29 @@ category: concept tags: ["methodology", "application", ""] --- -## Описание - Непрерывная доставка (Continuous Delivery), часто сокращенно называемая CD, — это набор практик, при которых изменения кода автоматически развертываются в приемочное окружение -(или, в случае непрерывного развертывания, в production). +— или, в случае непрерывного развертывания, в production. CD обязательно включает процедуры, обеспечивающие адекватное тестирование программного обеспечения перед развертыванием, и предоставляет возможность отката изменений при необходимости. -Непрерывная интеграция (CI) — первый шаг на пути к непрерывной доставке -(т. е. сначала должен успешно процесс внесения изменений (merging); только после этого можно переходить к тестированию и развертыванию). +Непрерывная интеграция — первый шаг на пути к непрерывной доставке: +т.е. сначала должен успешно завершиться процесс внесения изменений (merging), и только после этого можно переходить к тестированию и развертыванию. -## Проблема +## Какую проблему решает Развертывание [надежных](/reliability/) обновлений становится глобальной проблемой. В идеале частота развертываний должна быть высокой — так востребованные функции будут быстрее попадать к конечным пользователям. Однако выполнение этих операций вручную влечет значительные трудозатраты при каждом изменении. -Исторически сложилось так, что для того, чтобы избежать этих трудозатрат, организации выпускали продукты реже, -внедряя больше изменений за один раз. В результате увеличивался риск того, что что-то пойдет не так. +Исторически сложилось так, что для того, чтобы избежать этих трудозатрат, организации выпускали новые релизы реже, +проводя больше изменений за один раз. В результате увеличивался риск того, что что-то пойдет не так. -## Решение +## Как именно решает проблему -Стратегии CD реализуют полностью автоматизированный путь к production, -в рамках которого ПО тестируется и развертывается с использованием различных стратегий развертывания, +Стратегии CD позволяют выстроить полностью автоматизированный путь до стадии production, +в рамках которого ПО тестируется и развертывается с использованием различных методов развертывания, таких как [канареечные](/canary-deployment/) или [сине-зеленые](/blue-green-deployment/) релизы. -Это позволяет разработчикам развертывать код с высокой частотой, будучи уверенными в том, что новая ревизия прошла тестирование. -Как правило, в стратегиях CD используется trunk-based-разработка, когда небольшие изменения кода часто вносятся в основную ветку +Это позволяет разработчикам развертывать код с высокой частотой и быть уверенными в том, что новая ревизия прошла все этапы тестирование. +Как правило, в стратегиях CD используется trunk-based-разработка, при которой в основную ветку постоянно вносятся небольшие изменения кода (в отличие от запросов на слияние (pull requests) и фич-веток (feature branching)). ## Связанные термины diff --git a/content/ru/continuous-deployment.md b/content/ru/continuous-deployment.md index 958bca7d78..8f41995897 100644 --- a/content/ru/continuous-deployment.md +++ b/content/ru/continuous-deployment.md @@ -5,28 +5,26 @@ category: concept tags: ["application", "methodology", ""] --- -## Описание - Непрерывное развертывание (Continuous Deployment, CD) развивает идеи [непрерывной доставки](/ru/continuous-delivery/), -позволяя размещать готовое программное обеспечение непосредственно в production. -Непрерывное развертывание (CD) идет рука об руку с [непрерывной интеграцией](/ru/continuous-integration/) (CI), поэтому обычно их объединяют в единый CI/CD-процесс. -CI помогает убедиться, что изменения, внесенные в код приложения, работают как задумано, +позволяя выкладывать готовое программное обеспечение непосредственно в production. +Непрерывное развертывание (CD) идет рука об руку с [непрерывной интеграцией](/ru/continuous-integration/) (CI), поэтому обычно их объединяют в единый процесс CI/CD. +CI помогает убедиться, что изменения, внесенные в код приложения, работают как и было задумано, а CD автоматически развертывает приложение в целевые окружения (от тестовых до production). -## Проблема +## Какую проблему решает -Выпуск новых версий программного обеспечения может быть трудоемким и сопряженным с ошибками процессом. -Поэтому многие организации стараются уменьшить количество таких выпусков, чтобы избежать инцидентов в production +Выпуск новых версий программного обеспечения может быть трудоемким процессом и сопровождаться ошибками. +Поэтому многие организации стараются уменьшить количество релизов, чтобы избежать инцидентов в production и сократить время, в течение которого инженеры должны оставаться на связи (в т. ч. в нерабочие часы). Традиционные модели развертывания программного обеспечения приводят к тому, что организации попадают в порочный круг, в котором процесс выпуска программного обеспечения не отвечает потребностям организации -ни в стабильности, ни в скорости реализации новых функций. +ни в контексте стабильности, ни в контексте скорости реализации новых функций. -## Решение +## Как именно решает проблему Автоматизируя релизный цикл и заставляя организации чаще развертывать ПО в production, -CD делает для команд эксплуатации то же самое, что CI — для команд разработки. -А именно, автоматизирует болезненные и склонные к ошибкам этапы развертывания в production, снижая общий риск. +CD делает для команд эксплуатации то же самое, что CI для команд разработки. +То есть автоматизирует этапы развертывания ПО в production, сокращая вероятность ошибок и негативных последствий и снижая общий риск. Кроме того, организации привыкают к частым изменениям в production и лучше к ним адаптируются, что повышает стабильность. ## Связанные термины diff --git a/content/ru/continuous-integration.md b/content/ru/continuous-integration.md index 20a556c2c9..a77a1ece63 100644 --- a/content/ru/continuous-integration.md +++ b/content/ru/continuous-integration.md @@ -5,28 +5,25 @@ category: concept tags: ["application", "methodology", ""] --- -## Описание - -Непрерывная интеграция (Continuous Integration, CI) — это практика, при которой правки принимаются в код с максимальной возможной регулярностью. +Непрерывная интеграция (Continuous Integration, CI) — это практика, при которой правки внедряются в код как можно чаще. CI является предварительным условием для [непрерывной доставки](/ru/continuous-delivery/) (CD). Процесс CI традиционно начинается с внесения правок в код в системе контроля исходного кода (Git, Mercurial или Subversion) -и заканчивается получением протестированного артефакта, готового к использованию CD-системой. +и заканчивается получением протестированной сборки, готовой к использованию CD-системой. -## Проблема +## Какую проблему решает Программные системы часто бывают большими и сложными, их поддерживает и обновляет множество разработчиков. Работая параллельно над разными частями системы, -эти разработчики могут вносить конфликтующие изменения и непреднамеренно "портить" работу друг друга. -Кроме того, если над одним проектом работает несколько разработчиков, то все повседневные задачи, -такие как тестирование и оценка качества кода, приходится повторять каждому из них, что ведет к потере времени. +эти разработчики могут вносить такие изменения, которые будут приводить к конфликтам, и непреднамеренно «портить» работу смежных команд. +Кроме того, если над одним проектом работает несколько разработчиков, то все рутинные задачи, +такие как тестирование и оценка качества кода, приходится повторять каждому из них. А это ведет к потере времени. -## Решение +## Как именно решает проблему -Программное обеспечение CI автоматически следит за тем, чтобы изменения, вносимые в код, -нормально в него интегрировались после каждого коммита, сделанного разработчиком. -Использование CI-сервера для проверки качества кода, запуска тестов и даже развертывания является довольно распространенной практикой, -превращая его в один из неотъемлемых инструментов для контроля качества в командах разработчиков. -CI позволяет командам разработчиков перевести каждый коммит кода либо в разряд провальных, либо в разряд жизнеспособных кандидатов на релиз. +Программное обеспечение для CI автоматически следит за тем, чтобы изменения, которые вносятся в код, сразу и четко интегрировались в него после каждого коммита, сделанного разработчиком. +Использование CI-сервера для проверки качества кода, запуска тестов и даже развертывания является довольно распространенной практикой. +Таким образом, CI-сервер становится одиним из неотъемлемых инструментов для контроля качества в командах разработчиков. +CI позволяет командам разработчиков перевести каждый коммит либо к отклоненным коммитам, либо к готовым кандидатам на релиз. ## Связанные термины diff --git a/content/ru/devops.md b/content/ru/devops.md index 9c83d94f35..272ce4333f 100644 --- a/content/ru/devops.md +++ b/content/ru/devops.md @@ -5,30 +5,28 @@ category: concept tags: ["methodology", "", ""] --- -## Описание +DevOps — это методология, в рамках которой команды отвечают за весь процесс от разработки приложения (**DEV**elopment) +его эксплуатации (**OP**eration**S**) в production. Отсюда и название DevOps. +Методология DevOps выходит за рамки внедрения набора технологий и требует полного пересмотра культуры и процессов. +DevOps предполагает наличие групп инженеров, которые работают над небольшими независимыми компонентами, а не над крупным функциональным блоком, в котором такие компоненты были бы тесно связаны, +позволяя сократить случаи передачи ответственности за компонент от одной команды к другой — а это нередко влечет за собой появление ошибок. -DevOps — это методология, в которой команды отвечают за весь процесс от разработки приложения (**DEV**elopment) -до его эксплуатации (**OP**eration**S**) в production, отсюда и название DevOps. -Она выходит за рамки внедрения набора технологий и требует полного пересмотра культуры и процессов. -DevOps предполагает наличие групп инженеров, которые работают над небольшими компонентами-частями (а не над целой функцией), -что позволяет сократить количество передачи информации между разными людьми, что является распространенным источником ошибок. - -## Проблема +## Какую проблему решает Традиционно в крупных организациях с [тесно связанными](/tightly-coupled-architectures/) [монолитными приложениями](/monolithic-apps/) работа, как правило, была разделена между несколькими группами. Это приводило к необходимости часто передавать задачи друг другу и длительным срокам выполнения работ. -Каждый раз, когда компонент или обновление были готовы, они помещались в очередь для следующей команды. +Каждый раз, когда компонент или обновление были готовы, они помещались в бэклог следующей команды. Поскольку каждый инженер работал только над небольшой частью проекта, было сложно сказать, кто и за что отвечает. -Каждая команда стремилась выполнить свою часть работы и передать проект следующей, а не реализовать функции, нужные заказчику — -наблюдался явный конфликт приоритетов. +В итоге каждая команда стремилась просто выполнить свою часть работы и передать проект следующей команде, а не реализовать функции, необходимые заказчику (или пользователю) — +то есть наблюдался явный конфликт приоритетов. К тому времени, когда код, наконец, попадал в production, он проходил через такое количество разработчиков и команд, -что при возникновении проблемы было крайне трудно отследить ее источник. +что при возникновении любой проблемы было крайне трудно отследить ее источник. DevOps кардинально изменил этот подход. -## Решение +## Как именно решает проблему -Когда одна команда отвечает за весь жизненный цикл приложения, это позволяет свести к минимуму необходимость передавать информацию, +Когда одна команда отвечает за весь жизненный цикл приложения, это позволяет свести к минимуму необходимость передавать ответственность от одной команды к другой, снизить риски при развертывании в production и повысить качество кода (поскольку команды также отвечают за его работу в production). -Кроме того, растет удовлетворенность сотрудников, поскольку те ощущают себя более самостоятельными и причастными к общему делу. +Кроме того, растет общая удовлетворенность сотрудников от работы, поскольку они ощущают себя более самостоятельными и видят свое влияние на проект и ответственность за общий результат. diff --git a/content/ru/devsecops.md b/content/ru/devsecops.md index 780171d909..b7d0286023 100644 --- a/content/ru/devsecops.md +++ b/content/ru/devsecops.md @@ -5,26 +5,24 @@ category: concept tags: ["methodology", "security", ""] --- -## Описание +Термин DevSecOps означает слияние компетенций в области разработки (**DEV**elopment), безопасности (**SEC**urity) и эксплуатации (**OP**eration**S**) на уровне культуры. +Он добавляет в подход [DevOps](/ru/devops/) приоритеты в области безопасности — причем так, +чтобы минимально вмешиваться в процессы разработки и эксплуатации. +Как и DevOps, DevSecOps — это некий культурный сдвиг, который форсируется как самим фактом внедрения новых технологий, так и специфическими методами их внедрения. -Термин DevSecOps означает культурное слияние компетенций в области разработки (**DEV**elopment), безопасности (**SEC**urity) и эксплуатации (**OP**eration**S**). -Он дополняет подход [DevOps](/ru/devops/) приоритетами в области безопасности -с минимальным влиянием на процесс разработки и эксплуатации. -Как и DevOps, DevSecOps — это культурный сдвиг, подталкиваемый новыми технологиями и уникальными методами их внедрения. +## Какую проблему решает -## Проблема +Практики DevOps включают [непрерывную интеграцию](/ru/continuous-integration/) и [непрерывное развертывание](/ru/continuous-deployment/). +Кроме того, они ускоряют цикл разработки и релизный цикл приложений. +К сожалению, если автоматизация релизов не учитывает интересы всех заинтересованных сторон (стейкхолдеров) внутри организации, она может усугубить существующие проблемы. +А быстрый выпуск нового программного обеспечения без учета требований безопасности может усугубить проблемы с безопасностью на уровне всей компании. -Практики DevOps включают [непрерывную интеграцию](/ru/continuous-integration/) и [непрерывное развертывание](/ru/continuous-deployment/) -и ускоряют циклы разработки и выпуска приложений. -К сожалению, автоматизация релизов, не учитывающая интересы всех заинтересованных сторон в организации, может усугубить существующие проблемы. -Быстрый выпуск нового программного обеспечения без учета требований безопасности может негативно сказаться на компании. - -## Решение +## Как именно решает проблему DevSecOps фокусируется на устранении командной разобщенности и способствует созданию безопасных автоматизированных рабочих процессов. При выборе приложений для обеспечения безопасности организации должны использовать преимущества -автоматизированных рабочих CI/CD-процессов и контроля за соблюдением политик, которые расширяют возможности разработчиков. -Цель — не мешать, а следить за соблюдением политик безопасности, -одновременно предоставляя пользователям точную информацию о том, как развивать их проект. +автоматизированных процессов CI/CD и контроля за соблюдением политик, которые расширяют возможности, полномочия и статус разработчиков. +Цель практик DevSecOps — не блокировать работу инженеров, а обеспечивать следование политикам безопасности, +в то же время предоставляя техническим командам точную и подробную информацию о том, как правильно развивать проект. При правильном внедрении организация получает более эффективное взаимодействие в коллективе, -снижает количество ошибок в системе безопасности и связанные с ними затраты. +снижает количество инцидентов, связанных с безопасностью, и вызванные ими расходы. diff --git a/content/ru/kubernetes.md b/content/ru/kubernetes.md index 8c9401bb2f..b6d1f3c034 100644 --- a/content/ru/kubernetes.md +++ b/content/ru/kubernetes.md @@ -5,34 +5,32 @@ category: technology tags: ["infrastructure", "fundamental", ""] --- -## Описание +Kubernetes (часто сокращается до K8s) — это система для управления контейнерами (т. н. оркестратор) с открытым исходным кодом. +Kubernetes автоматизирует жизненный цикл контейнеризированных приложений в современных инфраструктурах, выступая в качестве «операционной системы для центров обработки данных», которая управляет приложениями в [распределенных системах](/distributed-systems/). -Kubernetes (часто используют его сокращенное название K8s) — это система для управления контейнерами (т. н. оркестратор) с открытым исходным кодом. -Она автоматизирует жизненный цикл контейнеризированных приложений в современных инфраструктурах, выступая "операционной системой" на уровне центров обработки данных для управления приложениями в [распределенных системах](/distributed-systems/). +Kubernetes планирует (т. е. распределяет) [контейнеры](/ru/container/) по [узлам](/nodes/) [кластера](/cluster/), попутно обеспечивая их различными инфраструктурными ресурсами: например, балансировщиками нагрузки, постоянным хранилищем и т. д., которые необходимы для запуска контейнеризованных приложений. -Kubernetes планирует (т. е. распределяет) [контейнеры](/ru/container/) на [узлы](/nodes/) [кластера](/cluster/), попутно обеспечивая их различными инфраструктурными ресурсами, такими как балансировщики нагрузки, постоянное хранилище и т. д., необходимыми для запуска контейнеризованных приложений. +Kubernetes также обеспечивает автоматизацию и расширяемость, позволяя пользователям использовать декларативность (см. ниже) и обеспечивать воспроизводимость в процессе развертывания приложений. +[API](/application-programming-interface/) Kubernetes позволяет опытным пользователям расширять и дополнять его возможности по автоматизации в соответствии со своими потребностями. -Kubernetes обеспечивает автоматизацию и расширяемость, позволяя пользователям развертывать приложения декларативным (см. ниже) и воспроизводимым образом. -[API](/application-programming-interface/), встроенный в Kubernetes, позволяет опытным пользователям расширять и дополнять его возможности в соответствии со своими потребностями. +## Какую проблему решает -## Проблема +Автоматизация инфраструктуры и декларативное управление конфигурацией уже давно занимают важное место в IT, но с ростом популярности [облачных вычислений](/cloud-computing/) их актуальность возросла еще сильнее. -Автоматизация инфраструктуры и декларативное управление конфигурацией уже давно занимают центральное место в информационных технологиях. С ростом популярности [облачных вычислений](/cloud-computing/) их актуальность значительно возросла. +Спрос на вычислительные ресурсы постоянно увеличивается, а компании стараются сделать труд инженеров максимально эффективным, чтобы оптимизировать ФОТ. Новые технологии и методы работы как раз призваны удовлетворить обе эти потребности. -Спрос на вычислительные ресурсы постоянно увеличивается. В то же время организации стараются сделать труд инженеров максимально эффективным, чтобы оптимизировать расходы на рабочую силу. Новые технологии и методы работы призваны удовлетворить обе этих потребности. +## Как именно решает проблему -## Решение +Как и традиционные инструменты или подходы, например, [инфраструктура как код (IaC)](/infrastructure-as-code/), Kubernetes помогает автоматизировать процессы, но у него есть и серьезное преимущество перед ними — использование контейнеров. -Как и традиционные инструменты типа [инфраструктура-как-код (IaC)](/infrastructure-as-code/), Kubernetes помогает автоматизировать процессы, а его отличительной чертой и преимуществом является использование контейнеров. +Контейнеры более устойчивы к накапливающимся со временем изменениям в конфигурации, нежели [виртуальные](/virtual-machine/) или физические машины. -Контейнеры более устойчивы к изменяющейся со временем конфигурации, нежели [виртуальные](/virtual-machine/) или физические машины. - -Кроме того, Kubernetes работает декларативно, то есть пользователь не указывает компьютеру, что нужно сделать, а лишь описывает желаемое состояние инфраструктуры (обычно в виде файлов-манифестов на языке YAML). +Кроме того, Kubernetes работает декларативно, то есть пользователь не указывает компьютеру, что и как нужно сделать, а лишь описывает желаемое конечное состояние инфраструктуры (обычно в виде файлов-манифестов на языке YAML). Все остальное Kubernetes берет на себя. -Таким образом, Kubernetes в высшей степени совместим с подходом инфраструктура-как-код. +Таким образом, Kubernetes в высшей степени совместим с подходом «инфраструктура как код». В Kubernetes также встроена функция [самовосстановления](/self-healing/). -Фактическое состояние кластера всегда стремится к состоянию, которое задал оператор. -Когда Kubernetes обнаруживает отклонение от того, что описано в файлах манифеста, в работу вступает контроллер Kubernetes и устраняет его. -Инфраструктура, с которой работает Kubernetes, может в любой момент измениться, однако оркестратор постоянно и автоматически адаптируется к этим изменениям, следя за тем, чтобы состояние кластера всегда соответствовало желаемому. +Фактическое состояние кластера всегда стремится к тому состоянию, которое описал оператор. +Когда Kubernetes обнаруживает отклонение от файлов манифеста, в дело вступает контроллер Kubernetes, который устраняет это отклонение. +Инфраструктура, с которой работает Kubernetes, может в любой момент измениться, однако оркестратор постоянно и автоматически адаптируется к изменениям, следя за тем, чтобы фактическое состояние кластера всегда соответствовало желаемому состоянию. diff --git a/content/ru/style-guide/_index.md b/content/ru/style-guide/_index.md index 36f3d33027..38e6e580ed 100644 --- a/content/ru/style-guide/_index.md +++ b/content/ru/style-guide/_index.md @@ -12,7 +12,7 @@ menu: Глоссарий Cloud Native придерживается [стандартного руководства по стилю репозитория CNCF](https://github.com/cncf/foundation/blob/master/style-guide.md). Кроме того, он следует перечисленным ниже правилам: -1. Используйте простой, доступный язык; избегайте технического жаргона и "модных" словечек. +1. Используйте простой, доступный язык; избегайте технического жаргона и «модных» словечек. 2. [Избегайте разговорного стиля](https://ru.wikipedia.org/wiki/%D0%A0%D0%B0%D0%B7%D0%B3%D0%BE%D0%B2%D0%BE%D1%80%D0%BD%D1%8B%D0%B9_%D1%81%D1%82%D0%B8%D0%BB%D1%8C). 3. [Повествование должно быть последовательным и конкретным](https://guidetogrammar.org/grammar/composition/abstract.htm). 4. [Избегайте сокращений](https://ru.wikipedia.org/wiki/%D0%A1%D1%82%D1%8F%D0%B6%D0%B5%D0%BD%D0%B8%D0%B5).