diff --git a/content/documentation/admin/actions/overview.ru.md b/content/documentation/admin/actions/overview.ru.md index 60fb36b2..11a9db3b 100644 --- a/content/documentation/admin/actions/overview.ru.md +++ b/content/documentation/admin/actions/overview.ru.md @@ -21,23 +21,23 @@ weight: 10 | Название | Обязательность | Описание | | ------------------- | -------------- | -------------------------------------------------------------------------------------------| -| Название | **да** | Произвольное название действия. | -| Идентификатор | **да** | Идентификатор действия. Генерируется автоматически из названия. | -| Ресурс | нет | Один или несколько ресурсов, для которых будет доступен запуск действия. | -| Иконка | нет | Иконка, которая отображается в карточке действия. | -| Владелец | нет | Учётная запись пользователя, отвечающего за конфигурацию и работоспособность действия. | -| Команда владелец | нет | Команда, отвечающая за конфигурацию и работоспособность действия. | -| Теги | нет | Теги для классификации и поиска действий. | -| Описание | нет | Описание в Markdown. Отображается при запуске действия или процесса, содержащего действие. | +| Название | Да | Произвольное название действия | +| Идентификатор | Да | Идентификатор действия. Генерируется автоматически из названия | +| Ресурс | Нет | Один или несколько ресурсов, для которых будет доступен запуск действия | +| Иконка | Нет | Иконка, которая отображается в карточке действия | +| Владелец | Нет | Учётная запись пользователя, отвечающего за конфигурацию и работоспособность действия | +| Команда владелец | Нет | Команда, отвечающая за конфигурацию и работоспособность действия | +| Теги | Нет | Теги для классификации и поиска действий | +| Описание | Нет | Описание в Markdown. Отображается при запуске действия или процесса, содержащего действие | ### Конфигурация запроса #### Тип действия -Действие может быть: +Действие может быть следующих типов: -- **Встроенного (BuiltIn)** типа — логика выполнения действия описана внутри платформы. Для встроенных действий необходимо выбрать один из преднастроенных бэкендов. -- Типа **Вебхук (Webhook)** — логика выполнения действия полностью настраивается пользователем. +- «Встроенное (BuiltIn)» — логика выполнения действия описана внутри платформы. Для встроенных действий необходимо выбрать один из преднастроенных бэкендов. +- «Вебхук (Webhook)» — логика выполнения действия полностью настраивается пользователем. #### Параметры перезапуска @@ -55,8 +55,8 @@ weight: 10 Для вебхук-действий доступен выбор формата отправки тела запроса: -- **JSON** (по умолчанию) — тело запроса отправляется в формате JSON с заголовком `Content-Type: application/json`. -- **Form URL Encoded** — тело запроса отправляется в формате `application/x-www-form-urlencoded`. +- JSON (по умолчанию) — тело запроса отправляется в формате JSON с заголовком `Content-Type: application/json`. +- «Form URL Encoded» — тело запроса отправляется в формате `application/x-www-form-urlencoded`. {{< alert level="info" >}} При выборе формата Form URL Encoded тело запроса должно содержать только плоские пары «ключ — значение». Например: @@ -70,20 +70,20 @@ token: {{ .credentials.token }} #### Расширенное логирование -Для вебхук-действий доступна опция **расширенное логирование**, которая включает детальное логирование всех деталей HTTP-запроса и ответа: +Для вебхук-действий доступна опция расширенного логирования, которая включает детальное логирование всех деталей HTTP-запроса и ответа: -- URL запроса, -- HTTP-метод, -- HTTP-заголовки (включая токены), -- Тело запроса, -- Код статуса ответа, -- HTTP-заголовки ответа, -- Тело ответа. +- URL запроса; +- HTTP-метод; +- HTTP-заголовки (включая токены); +- тело запроса; +- код статуса ответа; +- HTTP-заголовки ответа; +- тело ответа. При включённой опции все эти данные записываются в лог выполнения действия. При выключённой опции логирование выполняется в стандартном режиме. {{< alert level="warning" >}} -Включение расширенного логирования может привести к записи конфиденциальной информации (токены, пароли и т.д.) в логи. Используйте эту опцию с осторожностью и только при необходимости отладки. +Включение расширенного логирования может привести к записи конфиденциальной информации (токены, пароли и т. д.) в логи. Используйте эту опцию с осторожностью и только при необходимости отладки. {{< /alert >}} #### Тело запроса @@ -100,7 +100,7 @@ project_id: {{ .property.project_id }} При таком теле запроса выражение `{{ .property.project_id }}` будет заменено на значение параметра `project_id`, введённое пользователем в форме запуска действия. -Для встроенных типов действий параметр «тело запроса» является конфигурацией действия, при этом доступен пример данной конфигурации. +Для встроенных типов действий параметр «Тело запроса» является конфигурацией действия, при этом доступен пример данной конфигурации. ### Пользовательская форма @@ -110,9 +110,9 @@ project_id: {{ .property.project_id }} Для каждого параметра доступны опции: -- **Редактируемый** — позволяет изменить значение параметра при запуске действия. Если опция выключена, значение изменить нельзя. -- **Обязательный** — требует указания значения при запуске действия. -- **Скрытый** — параметр не отображается в пользовательской форме при запуске действия. +- «Редактируемый» — позволяет изменить значение параметра при запуске действия. Если опция выключена, значение изменить нельзя. +- «Обязательный» — требует указания значения при запуске действия. +- «Скрытый» — параметр не отображается в пользовательской форме при запуске действия. Для каждого параметра можно задать значение по умолчанию, которое будет подставляться в форму при запуске. @@ -151,8 +151,8 @@ project_id: {{ .property.project_id }} | Поле | Описание | | ------------------- | ------------------------------------------------------------------------ | -| Источник | Go-шаблон значения. | -| Параметр сущности | Идентификатор параметра сущности в каталоге. | +| Источник | Go-шаблон значения | +| Параметр сущности | Идентификатор параметра сущности в каталоге | Например, при выполнении действия «Создание проекта в GitLab» в поле `response` будет сохранена спецификация созданного проекта: @@ -165,8 +165,8 @@ project_id: {{ .property.project_id }} Если после создания проекта в GitLab нужно сразу заполнить параметр сущности `repository_id`, укажите в правилах обновления: -1. **Источник:** `{{ .response.id }}`. -1. **Параметр сущности:** `repository_id`. +1. Источник: `{{ .response.id }}`. +1. Параметр сущности: `repository_id`. #### Создание связей сущности @@ -174,19 +174,19 @@ project_id: {{ .property.project_id }} | Поле | Описание | | ----------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Ресурс | Любой из двух ресурсов, участвующих в нужной связи ресурсов: по выбранному ресурсу загружается список связей, в которых он указан как родительский или как дочерний. Можно выбрать ресурс сущности, для которой запускается действие, или ресурс другой стороны связи — в списке будет одна и та же связь, если оба ресурса входят в неё. | -| Связь | Связь ресурсов в каталоге: в ней заданы родительский и дочерний ресурсы и роли сущностей при создании связи. По выбранной связи определяется, на какой стороне находится сущность запуска и какое из полей ниже задаёт идентификатор второй сущности из ответа действия. | -| Идентификатор родительской сущности | Go-шаблон для идентификатора родительской сущности в каталоге. | -| Идентификатор дочерней сущности | Go-шаблон для идентификатора дочерней сущности в каталоге. | +| Ресурс | Любой из двух ресурсов, участвующих в нужной связи ресурсов: по выбранному ресурсу загружается список связей, в которых он указан как родительский или как дочерний. Можно выбрать ресурс сущности, для которой запускается действие, или ресурс другой стороны связи — в списке будет одна и та же связь, если оба ресурса входят в неё | +| Связь | Связь ресурсов в каталоге: в ней заданы родительский и дочерний ресурсы и роли сущностей при создании связи. По выбранной связи определяется, на какой стороне находится сущность запуска и какое из полей ниже задаёт идентификатор второй сущности из ответа действия | +| Идентификатор родительской сущности | Go-шаблон для идентификатора родительской сущности в каталоге | +| Идентификатор дочерней сущности | Go-шаблон для идентификатора дочерней сущности в каталоге | #### Обновление учётных данных пользователя -Если включена опция **обновление учётных данных пользователя**, то действие автоматически обновляет учётные данные пользователя в соответствии с правилами обновления. +Если включена опция обновления учётных данных пользователя, то действие автоматически обновляет учётные данные пользователя в соответствии с правилами обновления. | Поле | Описание | | ------------------- | ---------------------------------- | -| Источник | Go-шаблон значения. | -| Тип учётных данных | Тип обновляемых учётных данных. | +| Источник | Go-шаблон значения | +| Тип учётных данных | Тип обновляемых учётных данных | Например, при выполнении действия, которое возвращает новый API-ключ в ответе: @@ -199,12 +199,14 @@ project_id: {{ .property.project_id }} для обновления учётных данных укажите в правилах обновления: -1. **Источник:** `{{ .response.apiKey }}`. -1. **Тип учётных данных:** выберите тип учётных данных, которые будут обновлены. +1. Источник: `{{ .response.apiKey }}`. +1. Тип учётных данных: выберите тип учётных данных, которые будут обновлены. ##### Выбор пользователя для обновления учётных данных -По умолчанию учётные данные обновляются для пользователя, который запустил действие (инициатора). Чтобы обновить учётные данные другого пользователя, включите опцию **обновлять учётные данные конкретного пользователя** и выберите нужного пользователя. +По умолчанию учётные данные обновляются для пользователя, который запустил действие (инициатора). + +Чтобы обновить учётные данные другого пользователя, включите опцию «Обновлять учётные данные конкретного пользователя» и выберите нужного пользователя. #### Обновление хранилища процесса @@ -212,8 +214,8 @@ project_id: {{ .property.project_id }} | Поле | Описание | | ------------------ | ------------------------------------------------------------------------ | -| Источник | Go-шаблон значения. | -| Ключ в хранилище | Ключ, под которым значение сохраняется в хранилище процесса. | +| Источник | Go-шаблон значения | +| Ключ в хранилище | Ключ, под которым значение сохраняется в хранилище процесса | Другие действия в процессе могут читать сохранённое значение через шаблон `{{ .store.key }}`, где `key` — указанный ключ. @@ -223,7 +225,7 @@ project_id: {{ .property.project_id }} #### Условия выполнения -Действие будет выполнено только, если статус сущности соответствует одному из выбранных значений в поле статусов (проверки здоровья сущности). Если ограничения не заданы, это условие не применяется. +Действие будет выполнено, только если статус сущности соответствует одному из выбранных значений в поле статусов. Если ограничения не заданы, это условие не применяется. #### Маскирование полей действия @@ -241,7 +243,7 @@ project_id: {{ .property.project_id }} Если опция включена, то после успешного выполнения действия ответ: -- сохраняется как временный и отображается **только** пользователю, который запустил действие; +- сохраняется как временный и отображается только пользователю, который запустил действие; - удаляется из обычного поля ответа, чтобы он не был доступен другим пользователям. Другие пользователи вместо содержимого ответа будут видеть только зашифрованный временный ответ. @@ -262,13 +264,13 @@ project_id: {{ .property.project_id }} #### Уведомления о подтверждении -При включённом подтверждении можно включить **уведомления**: задать способ уведомления. Если выбрана отправка на URL, указывается адрес webhook, при необходимости отключается проверка TLS-сертификата сервера и добавляются дополнительные HTTP-заголовки запроса. +При включённом подтверждении можно включить уведомления и указать способ отправки. Если выбрана отправка на URL, указывается адрес вебхука, при необходимости отключается проверка TLS-сертификата сервера и добавляются дополнительные HTTP-заголовки запроса. ### Авторизация #### Использовать внешний сервис -Выбор внешних сервисов, для которых может выполняться действие. В случае добавления нескольких внешних сервисов, конкретный можно будет выбрать непосредственно при запуске. +Выбор внешних сервисов, для которых может выполняться действие. В случае добавления нескольких внешних сервисов конкретный можно будет выбрать непосредственно при запуске. #### URL и HTTP-заголовки @@ -290,7 +292,7 @@ project_id: {{ .property.project_id }} #### HTTP-метод -Для действия типа **вебхук** задаётся HTTP-метод исходящего запроса. +Для вебхук-действий задаётся HTTP-метод исходящего запроса. ## Запуски действий @@ -304,7 +306,7 @@ project_id: {{ .property.project_id }} Для каждого запуска действия в базе данных создаётся запись, содержащая полный лог выполнения. -Параметр `actions.logging.enabled` в конфигурационном файле DDP управляет выводом логов запуска в stdout: при значении `true` логи выводятся, при `false` не выводятся. +Параметр `actions.logging.enabled` в конфигурационном файле Deckhouse Development Platform (DDP) управляет выводом логов запуска в stdout: при значении `true` логи выводятся, при `false` не выводятся. {{< alert level="info" >}} Записи с полным логом запуска в базе данных создаются независимо от значения `actions.logging.enabled`. @@ -314,10 +316,10 @@ project_id: {{ .property.project_id }} Для каждого запуска действия создаётся запись со статусом. Возможные статусы: -- **Created** — запись создана, но действие ещё не запускалось. -- **Unapproved** — действие ожидает подтверждения. -- **Running** — действие выполняется. -- **Failed** — действие завершилось с ошибкой. -- **Update failed** — действие выполнено, но обновить параметры сущности не удалось. -- **Success** — действие выполнено успешно. -- **Retrying** — действие завершилось с ошибкой, выполняется повторная попытка запуска. +- «Created» — запись создана, но действие ещё не запускалось. +- «Unapproved» — действие ожидает подтверждения. +- «Running» — действие выполняется. +- «Failed» — действие завершилось с ошибкой. +- «Update failed» — действие выполнено, но обновить параметры сущности не удалось. +- «Success» — действие выполнено успешно. +- «Retrying» — действие завершилось с ошибкой, выполняется повторная попытка запуска. diff --git a/content/documentation/admin/actions/types.ru.md b/content/documentation/admin/actions/types.ru.md index e76a6f34..da1b42fb 100644 --- a/content/documentation/admin/actions/types.ru.md +++ b/content/documentation/admin/actions/types.ru.md @@ -20,13 +20,13 @@ lead: '1' Список полей соответствует официальному API DefectDojo, `/api/v2/engagements`, подробнее — [в документации Defectdojo](https://demo.defectdojo.org/api/v2/oa3/swagger-ui/). -### Учетные данные +### Учётные данные -* **token** — API v2 Key пользователя, от имени которого будет запускаться выполнение действия. +* `token` — API v2 Key пользователя, от имени которого будет запускаться выполнение действия. ## CreateDefectdojoProduct -CreateDefectdojoProduct — создает новый продукт в системе DefectDojo. Действие использует DefectDojo API v2. +CreateDefectdojoProduct — создаёт новый продукт в системе DefectDojo. Действие использует DefectDojo API v2. ### Пример запроса @@ -40,13 +40,13 @@ prod_type: 1 Список полей соответствует официальному API DefectDojo, `/api/v2/products`, подробнее — [в документации Defectdojo](https://demo.defectdojo.org/api/v2/oa3/swagger-ui/). -### Учетные данные +### Учётные данные -* **token** — API v2 Key пользователя, от имени которого будет запускаться выполнение действия. +* `token` — API v2 Key пользователя, от имени которого будет запускаться выполнение действия. ## CreateGitlabBranches -CreateGitlabBranches — создает новые ветки в целевом репозитории. +CreateGitlabBranches — создаёт новые ветки в целевом репозитории. ### Пример запроса @@ -66,19 +66,19 @@ branches: | branches.branch | Да | Название новой ветки | | branches.ref | Да | Название существующей ветки или SHA-хеш коммита | -### Учетные данные +### Учётные данные -* **token** — токен пользователя, от имени которого будет запускаться выполнение действия. +* `token` — токен пользователя, от имени которого будет запускаться выполнение действия. ### Примечание -Для выполнения действия необходимо наличие корректных реквизитов GitLab token. Этот токен передается через механизм учетных данных и используется для аутентификации при вызове GitLab API (HTTP-заголовок `Private-Token`). +Для выполнения действия необходимо наличие корректных реквизитов токена GitLab. Этот токен передаётся через механизм учётных данных и используется для аутентификации при вызове GitLab API (HTTP-заголовок `Private-Token`). Действие осуществляет POST-запрос по URL: `/api/v4/projects/:id/repository/branches`. В случае успешного создания проекта GitLab возвращает информацию о созданных ветках. ## CreateGitlabGroupVariables -CreateGitlabGroupVariables — создает переменные (variables) на уровне группы в GitLab. +CreateGitlabGroupVariables — создаёт переменные (variables) на уровне группы в GitLab. ### Пример запроса @@ -98,19 +98,19 @@ variables: Список полей для переменных соответствует официальному GitLab Group-level Variables API, `/groups/:id/variables`, подробнее — [в документации Gitlab](https://docs.gitlab.com/api/group_level_variables/#create-variable). -### Учетные данные +### Учётные данные -* **token** — токен пользователя, от имени которого будет запускаться выполнение действия. +* `token` — токен пользователя, от имени которого будет запускаться выполнение действия. ### Примечание -Для выполнения действия необходимо наличие корректных реквизитов с GitLab token. Этот токен передается через механизм учетных данных и используется для аутентификации при вызове GitLab API (HTTP-заголовок `Private-Token`). +Для выполнения действия необходимо наличие токена GitLab. Токен передаётся через механизм учётных данных и используется для аутентификации при вызове GitLab API (HTTP-заголовок `Private-Token`). Действие осуществляет POST-запрос по URL: `/api/v4/groups/:id/variables`. ## CreateGitlabMergeRequest -CreateGitlabMergeRequest - создает новый Merge Request (MR) в целевом репозитории. В Merge Request добавляются файлы, хранящиеся в репозитории источнике. Файлы могут содержать переменные, значение которых будет подставлено в момент создания MR. +CreateGitlabMergeRequest — создаёт новый Merge Request (MR) в целевом репозитории. В Merge Request добавляются файлы, хранящиеся в репозитории-источнике. Файлы могут содержать переменные, значение которых будет подставлено в момент создания MR. ### Пример запроса @@ -145,32 +145,32 @@ values: | additionalIgnoreFiles | Нет | Список файлов, содержащих пути для исключения из MR. Заполняется по аналогии с [.templateignore](#templateignore) | - | | values | Нет | Переменные, используемые при шаблонизации, в формате `ключ: значение` | - | -### Учетные данные +### Учётные данные -* **password** — пароль (токен) пользователя, от имени которого будет запускаться выполнение действия. -* **username** — имя пользователя, от которого будет запускаться выполнение действия. +* `password` — пароль (токен) пользователя, от имени которого будет запускаться выполнение действия. +* `username` — имя пользователя, от которого будет запускаться выполнение действия. ### Алгоритм работы Платформа: -1. Клонирует репозиторий-шаблон для генерации MR по его идентификатору (**source_project_id**). Подробнее [о шаблонизации](#детали-работы). +1. Клонирует репозиторий-шаблон для генерации MR по его идентификатору (`source_project_id`). Подробнее [о шаблонизации](#детали-работы). 1. Считывает файл `values.yaml`, хранящийся в корне репозитория, и определяет переменные по умолчанию для шаблонизации. 1. Считывает переменные, передаваемые при запуске действия, и объединяет (merge) их с переменными из `values.yaml`. Приоритет отдаётся переменным, передаваемым при запуске действия. 1. Считывает файл `.templateignore` и определяет директории и файлы, исключаемые из шаблонизации. 1. Рендерит файлы из шаблонов, учитывая `values.yaml` и переданных в действие переменных. -1. Изменяет удалённый (remote) репозиторий на целевой, согласно его ID (**target_project_id**), и выполняет git push в целевую ветку (**source_project_branch**), либо в основную ветку **main**. -1. Создает MR, согласно заданным настройкам, путем отправки POST-запроса в GitLab API. +1. Изменяет удалённый (remote) репозиторий на целевой, согласно его ID (`target_project_id`), и выполняет git push в целевую ветку (`source_project_branch`), либо в основную ветку `main`. +1. Создаёт MR согласно заданным настройкам путём отправки POST-запроса в GitLab API. ### Примечание -Для выполнения действия необходимо наличие корректных реквизитов GitLab token. Этот токен передается через механизм учетных данных и используется для аутентификации при вызове GitLab API (HTTP-заголовок `Private-Token`). +Для выполнения действия необходимо наличие токена GitLab. Токен передаётся через механизм учётных данных и используется для аутентификации при вызове GitLab API (HTTP-заголовок `Private-Token`). Действие осуществляет POST-запрос по URL: `/api/v4/projects/:id/merge_requests`. ## CreateGitlabProject -CreateGitlabProject — создает новый проект в GitLab. Действие осуществляет вызов GitLab API для создания проекта с указанными параметрами, такими как название, путь проекта, описание и другие настройки. Для аутентификации используется GitLab token, который должен быть предоставлен в учетных данных. +CreateGitlabProject — создаёт новый проект в GitLab. Действие осуществляет вызов GitLab API для создания проекта с указанными параметрами, такими как название, путь проекта, описание и другие настройки. Для аутентификации используется GitLab token, который должен быть предоставлен в учётных данных. ### Пример запроса @@ -190,23 +190,23 @@ namespace_id: '0' | name | Да | Название проекта, который будет создан в GitLab | - | | path | Да | URL-совместимый путь проекта. Обычно совпадает с названием, но может отличаться | - | | default_branch | Да | Название ветки, которая будет использоваться по умолчанию, например, «main» | - | -| namespace_id | Да | Идентификатор пространства имен (namespace) в GitLab, в котором будет создан проект | - | +| namespace_id | Да | Идентификатор неймспейса (namespace) в GitLab, в котором будет создан проект | - | | initialize_with_readme | Нет | Флаг, определяющий, нужно ли инициализировать проект с файлом README | false | | description | Нет | Описание проекта, которое будет видно пользователям | - | -### Учетные данные +### Учётные данные -* **token** — токен пользователя, от имени которого будет запускаться выполнение действия. +* `token` — токен пользователя, от имени которого будет запускаться выполнение действия. ### Примечание -Для выполнения действия необходимо наличие корректных реквизитов GitLab token. Токен, содержащий реквизиты, передаётся через механизм учетных данных и используется для аутентификации при вызове GitLab API (HTTP-заголовок `Private-Token`). +Для выполнения действия необходимо наличие токена GitLab. Токен передаётся через механизм учётных данных и используется для аутентификации при вызове GitLab API (HTTP-заголовок `Private-Token`). Действие осуществляет POST-запрос по URL: `/api/v4/projects`, передавая параметры запроса в формате JSON. В случае успешного создания проекта GitLab возвращает данные о вновь созданном проекте. ## CreateGitlabProjectVariables -CreateGitlabProjectVariables — создает переменные на уровне проекта в GitLab. +CreateGitlabProjectVariables — создаёт переменные на уровне проекта в GitLab. ### Пример запроса @@ -226,19 +226,19 @@ variables: Список полей для переменных соответствует официальному GitLab Project-level CI/CD variables API, `/projects/:id/variables`, подробнее — [в документации Gitlab](https://docs.gitlab.com/api/project_level_variables/#create-a-variable). -### Учетные данные +### Учётные данные -* **token** — токен пользователя, от имени которого будет запускаться выполнение действия. +* `token` — токен пользователя, от имени которого будет запускаться выполнение действия. ### Примечание -Для выполнения действия необходимо наличие корректных реквизитов GitLab token. Токен, содержащий реквизиты, передаётся через механизм учетных данных и используется для аутентификации при вызове GitLab API (HTTP-заголовок `Private-Token`). +Для выполнения действия необходимо наличие токена GitLab. Токен передаётся через механизм учётных данных и используется для аутентификации при вызове GitLab API (HTTP-заголовок `Private-Token`). Действие осуществляет POST-запрос по URL: `/api/v4/projects/:id/variables`. ## CreateGitlabProjectWebhook -CreateGitlabProjectWebhook — создает вебхук в проекте GitLab. +CreateGitlabProjectWebhook — создаёт вебхук в проекте GitLab. ### Пример запроса @@ -259,22 +259,22 @@ pipeline_events: true | url | Да | URL-адрес вебхука | | push_events | Да | Запускать вебхук при push в репозиторий | | issues_events | Да | Запускать вебхук при создании Issue | -| merge_request_events | Да | Запускать вебхук при создании Merge rRequest | +| merge_request_events | Да | Запускать вебхук при создании Merge Request | | pipeline_events | Да | Запускать вебхук при запуске Pipeline | -### Учетные данные +### Учётные данные -* **token** — токен пользователя, от имени которого будет запускаться выполнение действия. +* `token` — токен пользователя, от имени которого будет запускаться выполнение действия. ### Примечание -Для выполнения действия необходимо наличие корректных реквизитов GitLab token. Токен, содержащий реквизиты, передаётся через механизм учетных данных и используется для аутентификации при вызове GitLab API (HTTP-заголовок `Private-Token`). +Для выполнения действия необходимо наличие токена GitLab. Токен передаётся через механизм учётных данных и используется для аутентификации при вызове GitLab API (HTTP-заголовок `Private-Token`). Действие осуществляет POST-запрос по URL: `/api/v4/projects/:id/hooks`. ## CreateGitlabTag -CreateGitlabTag — создает новый тег в проекте GitLab. +CreateGitlabTag — создаёт новый тег в проекте GitLab. ### Пример запроса @@ -294,19 +294,19 @@ message: Tag description | ref | Да | Название ветки, тег или SHA-хеш коммита, на который будет ссылаться новый тег | | message | Да | Описание тега | -### Учетные данные +### Учётные данные -* **token** — токен пользователя, от имени которого будет запускаться выполнение действия. +* `token` — токен пользователя, от имени которого будет запускаться выполнение действия. ### Примечание -Для выполнения действия необходимо наличие корректных реквизитов GitLab token. Токен, содержащий реквизиты, передается через механизм учетных данных и используется для аутентификации при вызове GitLab API (HTTP-заголовок `Private-Token`). +Для выполнения действия необходимо наличие токена GitLab. Токен передаётся через механизм учётных данных и используется для аутентификации при вызове GitLab API (HTTP-заголовок `Private-Token`). Действие осуществляет POST-запрос по URL: `/api/v4/projects/:id/repository/tags`. ## CreateGitlabRelease -CreateGitlabRelease — создает релиз GitLab на основе уже существующего тега. +CreateGitlabRelease — создаёт релиз GitLab на основе уже существующего тега. ### Пример запроса @@ -329,13 +329,13 @@ description: | | name | Да | Название релиза, отображаемое в GitLab | | description | Нет | Описание релиза в формате Markdown | -### Учетные данные +### Учётные данные -* **token** — токен пользователя, от имени которого будет запускаться выполнение действия. +* `token` — токен пользователя, от имени которого будет запускаться выполнение действия. ### Примечание -Для выполнения действия необходимо наличие корректных реквизитов GitLab token. Токен, содержащий реквизиты, передается через механизм учетных данных и используется для аутентификации при вызове GitLab API (HTTP-заголовок `Private-Token`). +Для выполнения действия необходимо наличие токена GitLab. Токен передаётся через механизм учётных данных и используется для аутентификации при вызове GitLab API (HTTP-заголовок `Private-Token`). Действие осуществляет POST-запрос по URL: `/api/v4/projects/:id/releases`. @@ -398,10 +398,10 @@ acls: | acls.deny | Нет | Список принципалов (user, group), для которых запрещается правило | - | - | | acls.deny_hosts | Нет | Список хостов, для которых запрещается операция | - | - | -### Учетные данные +### Учётные данные -* **user** — имя пользователя, от которого будет запускаться выполнение действия. -* **password** — пароль пользователя, от имени которого будет запускаться выполнение действия. +* `user` — имя пользователя, от которого будет запускаться выполнение действия. +* `password` — пароль пользователя, от имени которого будет запускаться выполнение действия. ### Список возможных шаблонов @@ -414,7 +414,7 @@ acls: Подробнее — [в документации Kafka](https://kafka.apache.org). -**Topic:** +Topic: * ALL. * ALTER. @@ -426,20 +426,20 @@ acls: * READ. * WRITE. -**Group:** +Group: * ALL. * DELETE. * DESCRIBE. * READ. -**TransactionalID:** +TransactionalID: * ALL. * DESCRIBE. * WRITE. -**Tokens:** +Tokens: * DESCRIBE. @@ -471,10 +471,10 @@ topics: | configs | Да | Конфигурация в формате ключ-значение для создаваемых топиков | Значения приведены [в документации Kafka](https://kafka.apache.org/documentation/#topicconfigs) | | topics | Да | Список названий топиков, которые необходимо создать | - | -### Учетные данные +### Учётные данные -* **user** — имя пользователя, от которого будет запускаться выполнение действия. -* **password** — пароль пользователя, от имени которого будет запускаться выполнение действия. +* `user` — имя пользователя, от которого будет запускаться выполнение действия. +* `password` — пароль пользователя, от имени которого будет запускаться выполнение действия. ## CreateKafkaUsers @@ -508,15 +508,15 @@ users: | users.mechanism | Да | Механизм аутентификации создаваемого пользователя | SCRAM-SHA-256, SCRAM-SHA-512 | | users.iterations | Да | Количество итераций, которые будут применяться для хеширования пароля | От 4096 до 16384 | -### Учетные данные +### Учётные данные -* **user** — имя пользователя, от которого будет запускаться выполнение действия. -* **password** — пароль пользователя, от имени которого будет запускаться выполнение действия. +* `user` — имя пользователя, от которого будет запускаться выполнение действия. +* `password` — пароль пользователя, от имени которого будет запускаться выполнение действия. ## CreateCodeScoringProject CreateCodeScoringProject — создаёт новый проект в системе CodeScoring. -Действие использует CodeScoring API для регистрации проекта с указанными параметрами: название проекта, URL репозитория, ID VCS системы и опция автоматического запуска SCA-анализа после клонирования репозитория +Действие использует CodeScoring API для регистрации проекта с указанными параметрами: название проекта, URL репозитория, ID VCS системы и опция автоматического запуска SCA-анализа после клонирования репозитория. ### Пример запроса @@ -585,12 +585,12 @@ config: | Название | Обязательность | Описание | Возможные значения | |----------|----------------|----------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------| | realm | Да | Realm в Keycloak, где требуется создать клиента | - | -| config | Да | Параметры создаваемого клиента в соответствии со спецификацией ClientRepresentation Keycloak | [Документация](https://www.keycloak.org/docs-api/latest/rest-api/index.html#ClientRepresentation) | +| config | Да | Параметры создаваемого клиента в соответствии со [спецификацией ClientRepresentation Keycloak](https://www.keycloak.org/docs-api/latest/rest-api/index.html#ClientRepresentation) | - | -### Учетные данные +### Учётные данные -* **username** — имя пользователя, от которого будет запускаться выполнение действия. -* **password** — пароль пользователя, от имени которого будет запускаться выполнение действия. +* `username` — имя пользователя, от которого будет запускаться выполнение действия. +* `password` — пароль пользователя, от имени которого будет запускаться выполнение действия. ## CreateKubernetesResource @@ -616,9 +616,9 @@ manifests: |----------------------------|----------------|----------------------------------------------------------------------------------------------------| | manifests | Да | Манифесты Kubernetes, которые будут применены | -### Учетные данные +### Учётные данные -* **token** — токен сервисного аккаунта в Kubernetes. +* `token` — токен сервисного аккаунта в Kubernetes. ## CreateRepositoryFromTemplate @@ -649,33 +649,33 @@ values: | templateRepositoryUrl | Да | URL шаблонного репозитория | - | | targetRepositoryUrl | Да | URL репозитория, который будет создан в результате выполнения действия | - | | values | Да | Переменные, используемые при шаблонизации, в формате `ключ: значение` | - | -| additionalIgnoreFiles | Нет | Список файлов, содержащих пути для для исключения из целевого репозитория. Заполняется по аналогии с [.templateignore](#templateignore) | - | +| additionalIgnoreFiles | Нет | Список файлов, содержащих пути для исключения из целевого репозитория. Заполняется по аналогии с [.templateignore](#templateignore) | - | | sourceTag | Нет | Тег шаблонного репозитория, который будет использоваться при шаблонизации. Если не указан, используется ветка шаблонного репозитория | - | | sourceBranch | Нет | Ветка шаблонного репозитория, которая будет использоваться при шаблонизации | main | | targetBranch | Нет | Ветка целевого репозитория, которая будет создана в результате выполнения действия | main | -### Учетные данные +### Учётные данные -* **password** — пароль (токен) пользователя, от имени которого будет запускаться выполнение действия. -* **username** — имя пользователя, от которого будет запускаться выполнение действия. +* `password` — пароль (токен) пользователя, от имени которого будет запускаться выполнение действия. +* `username` — имя пользователя, от которого будет запускаться выполнение действия. ### Алгоритм работы Платформа: -1. Клонирует шаблонный репозиторий по указанному URL (**templateRepositoryUrl**), используя в качестве ref либо **sourceTag**, либо **sourceBranch**, либо ветку **main**. -1. Считывает файл `values.yaml` хранящийся в корне репозитория и определяет переменные по умолчанию для шаблонизации. -1. Считывает переменные, передаваемые при запуске действия, и делает их merge с переменными из `values.yaml`. Приоритет при merge отдается переменным, передаваемым при запуске действия. +1. Клонирует шаблонный репозиторий по указанному URL (`templateRepositoryUrl`), используя в качестве ref либо `sourceTag`, либо `sourceBranch`, либо ветку `main`. +1. Считывает файл `values.yaml`, хранящийся в корне репозитория, и определяет переменные по умолчанию для шаблонизации. +1. Считывает переменные, передаваемые при запуске действия, и делает их merge с переменными из `values.yaml`. Приоритет при merge отдаётся переменным, передаваемым при запуске действия. 1. Считывает файл `.templateignore` и определяет директории и файлы, исключаемые из шаблонизации. 1. Рендерит из шаблонов файлы, учитывая `values.yaml` и переданные в действие переменные. -1. Изменяет удалённый (remote) репозиторий на целевой (**targetRepositoryUrl**) и делает git push в целевую ветку (**targetBranch**), либо в основную ветку **main**. +1. Изменяет удалённый (remote) репозиторий на целевой (`targetRepositoryUrl`) и делает git push в целевую ветку (`targetBranch`), либо в основную ветку `main`. ### Детали работы Действие поддерживает шаблонизацию имён директорий и файлов. Для этого необходимо в их название добавить выражение в формате [Go template](https://developer.hashicorp.com/nomad/docs/reference/go-template-syntax). -Например директория `src/{{ .module }}/utils` при наличии value **module** со значением **example** будет отрендерена в директорию `src/example/utils` в целевом репозитории. +Например, директория `src/{{ .module }}/utils` при наличии value `module` со значением `example` будет отрендерена в директорию `src/example/utils` в целевом репозитории. -Если после рендеринга из шаблона содержимое файла будет отсутствовать, файл не создаётся. Например файл с содержимым: +Если после рендеринга из шаблона содержимое файла будет отсутствовать, файл не создаётся. Например, файл с содержимым: ```go {{- if .createContent }} @@ -683,7 +683,7 @@ values: {{- end }} ``` -не будет создан, если переменная **createContent** имеет значение **false**. Аналогичным образом, не будут созданы файлы, изначально являющиеся пустыми. +не будет создан, если переменная `createContent` имеет значение `false`. Аналогичным образом, не будут созданы файлы, изначально являющиеся пустыми. При отсутствии переменных для шаблонизации одновременно в файле `values.yaml` и в переменных, передаваемых при запуске действия, рендеринг завершится с ошибкой и целевой репозиторий создан не будет. @@ -704,13 +704,13 @@ createContent: false ### Исключение файлов -Некоторые файлы могут содержать переменные в формате [Go template](https://developer.hashicorp.com/nomad/docs/reference/go-template-syntax), которые необходимо сохранять при рендеринге репозитория из шаблона, например, Helm чарты в директории `helm`. Директория `.git` игнорируется всегда. +Некоторые файлы могут содержать переменные в формате [Go template](https://developer.hashicorp.com/nomad/docs/reference/go-template-syntax), которые необходимо сохранять при рендеринге репозитория из шаблона, например, Helm-чарты в директории `helm`. Директория `.git` игнорируется всегда. Для исключения подобных файлов из механизма рендеринга следует добавить в корень репозитория файл `.templateignore` с соответствующим содержимым. -В **каждой строке** `.templateignore` задаётся одно правило — путь или маска. Если в строке есть `{{`, **вся строка** выполняется как один шаблон Go с теми же переменными и функциями, что при подстановке в **имена** файлов и каталогов (подробнее — [«Как обрабатывается строка правила»](#templateignore-templates)). Если `{{` в строке **нет**, подстановка переменных из `values.yaml` и из запроса действия **не делается**: строка читается как есть и сравнивается с относительным путём на диске, допускаются литералы и символы маски `*` и `**`. +В каждой строке `.templateignore` задаётся одно правило — путь или маска. Если в строке есть `{{`, вся строка выполняется как один шаблон Go с теми же переменными и функциями, что при подстановке в имена файлов и каталогов (подробнее — [«Как обрабатывается строка правила»](#templateignore-templates)). Если `{{` в строке нет, подстановка переменных из `values.yaml` и из запроса действия не делается: строка читается как есть и сравнивается с относительным путём на диске, допускаются литералы и символы маски `*` и `**`. -Пример файла `.templateignore` **только с масками** пути, без шаблонов подстановки, для игнорирования содержимого директорий `helm`, `docs`: +Пример файла `.templateignore` только с масками пути, без шаблонов подстановки, для игнорирования содержимого директорий `helm`, `docs`: ```sh helm/** @@ -721,9 +721,9 @@ docs/** 1. В корне шаблонного репозитория создайте или отредактируйте файл `.templateignore` (по одному правилу на строку). -1. Каждая строка — это **одно** правило: путь от **корня** репозитория. В нём допускаются обычные символы пути и **маски**: звёздочка `*` в имени сегмента, последовательность `**` — для произвольной глубины вложенных каталогов. Платформа сопоставляет относительный путь с маской по встроенным правилам (аналогично распространённым соглашениям для масок в файлах игнорирования в системах контроля версий). +1. Каждая строка — это одно правило: путь от корня репозитория. В нём допускаются обычные символы пути и маски: звёздочка `*` в имени сегмента, последовательность `**` — для произвольной глубины вложенных каталогов. Платформа сопоставляет относительный путь с маской по встроенным правилам (аналогично распространённым соглашениям для масок в файлах игнорирования в системах контроля версий). -1. Чтобы подставить фрагмент пути из `values.yaml` или из поля **values** запроса действия, используйте в строке конструкции **Go template** (`{{ ... }}`). Если в строке есть `{{`, платформа обрабатывает **всю строку от начала до конца** как **один** шаблон Go: нельзя оставить часть строки «простым текстом» и шаблонизировать только середину пути. Примеры — в разделе [«Примеры Go template в `.templateignore`»](#templateignore-go-examples). +1. Чтобы подставить фрагмент пути из `values.yaml` или из поля `values` запроса действия, используйте в строке конструкции Go template (`{{ ... }}`). Если в строке есть `{{`, платформа обрабатывает всю строку от начала до конца как один шаблон Go: нельзя оставить часть строки «простым текстом» и шаблонизировать только середину пути. Примеры — в разделе [«Примеры Go template в `.templateignore`»](#templateignore-go-examples). 1. Пустые строки и строки, начинающиеся с `#`, при разборе файла пропускаются — их можно использовать для комментариев. @@ -766,33 +766,33 @@ charts/*/values.schema.json #### Как обрабатывается строка правила -Переменные для раскрытия правил те же, что объединены из `values.yaml` в корне шаблонного репозитория и из поля **values** в запросе действия (приоритет у **values** в запросе). +Переменные для раскрытия правил те же, что объединены из `values.yaml` в корне шаблонного репозитория и из поля `values` в запросе действия (приоритет у `values` в запросе). -Для **каждой** непустой строки из `.templateignore` или из файла из **additionalIgnoreFiles** платформа делает следующее. +Для каждой непустой строки из `.templateignore` или из файла из `additionalIgnoreFiles` платформа делает следующее. -1. В список правил **всегда** попадает строка **как в файле**, без изменений. Именно её потом сравнивают с путём к файлу в первую очередь — это нужно, когда в именах на диске ещё есть фрагменты вроде `{{ .module }}` до переименования. +1. В список правил всегда попадает строка как в файле, без изменений. Именно её потом сравнивают с путём к файлу в первую очередь — это нужно, когда в именах на диске ещё есть фрагменты вроде `{{ .module }}` до переименования. -1. Если в строке есть `{{`, платформа **один раз** прогоняет **всю** строку через шаблонизатор [Go template](https://developer.hashicorp.com/nomad/docs/reference/go-template-syntax) с теми же возможностями, что при подстановке в **имена** файлов и каталогов (встроенные функции платформы и набор **Sprig**). Если `{{` в строке нет, этот шаг пропускают. +1. Если в строке есть `{{`, платформа один раз прогоняет всю строку через шаблонизатор [Go template](https://developer.hashicorp.com/nomad/docs/reference/go-template-syntax) с теми же возможностями, что при подстановке в имена файлов и каталогов (встроенные функции платформы и набор Sprig). Если `{{` в строке нет, этот шаг пропускают. -1. Если шаг подстановки был и полученный текст **отличается** от строки в файле (включая случай «на выходе пусто»), в список правил **добавляют вторую запись** — уже с этим полученным текстом. Итого из одной строки файла может получиться **две** записи в списке. При проверке пути к файлу смотрят **обе**: достаточно совпадения с **любой** из них — файл попадает под правило. +1. Если шаг подстановки был и полученный текст отличается от строки в файле (включая случай «на выходе пусто»), в список правил добавляют вторую запись — уже с этим полученным текстом. Итого из одной строки файла может получиться две записи в списке. При проверке пути к файлу смотрят обе: достаточно совпадения с любой из них — файл попадает под правило. -Дальше при обходе дерева для каждого пути к файлу вычисляется путь **относительно корня** клонированной копии (с прямыми слешами). Путь сравнивается с каждым правилом: сначала по правилам сопоставления с маской (в том числе с использованием `*` и `**`), при необходимости — по **точному** совпадению строки правила и относительного пути. +Дальше при обходе дерева для каждого пути к файлу вычисляется путь относительно корня клонированной копии (с прямыми слешами). Путь сравнивается с каждым правилом: сначала по правилам сопоставления с маской (в том числе с использованием `*` и `**`), при необходимости — по точному совпадению строки правила и относительного пути. -Так одна строка в файле может задать **два** правила: например, исходное `charts/{{ .name }}/**` (чтобы не трогать путь до переименования каталогов), и раскрытое `charts/billing/**` (чтобы совпадало с путём после подстановки переменных в имена на диске). Поэтому правила работают и «до», и «после» этапа переименования каталогов по шаблону. +Так одна строка в файле может задать два правила: например, исходное `charts/{{ .name }}/**` (чтобы не трогать путь до переименования каталогов), и раскрытое `charts/billing/**` (чтобы совпадало с путём после подстановки переменных в имена на диске). Поэтому правила работают и «до», и «после» этапа переименования каталогов по шаблону. -Если шаблон в строке синтаксически неверен или обращается к отсутствующему полю, раскрытие правил завершается **ошибкой**, и рендер репозитория не продолжается. +Если шаблон в строке синтаксически неверен или обращается к отсутствующему полю, раскрытие правил завершается ошибкой, и рендер репозитория не продолжается. -Поле **additionalIgnoreFiles** в действии задаёт **имена дополнительных файлов** в корне репозитория; в каждом из них — такие же строки-правила, как в `.templateignore`, с тем же раскрытием шаблонов. Но смысл другой: совпавшие пути **убирают из рабочей копии** (каталог или файл удаляют), и делают это **дважды** — в начале и в конце цепочки обработки, чтобы эти объекты не участвовали в дальнейших шагах и не попали в итоговый репозиторий. +Поле `additionalIgnoreFiles` в действии задаёт имена дополнительных файлов в корне репозитория; в каждом из них — такие же строки-правила, как в `.templateignore`, с тем же раскрытием шаблонов. Но смысл другой: совпавшие пути убирают из рабочей копии (каталог или файл удаляют), и делают это дважды — в начале и в конце цепочки обработки, чтобы эти объекты не участвовали в дальнейших шагах и не попали в итоговый репозиторий. -Файл **`.templateignore`** наоборот означает «**не шаблонизировать**»: для совпавших путей платформа **не подставляет** переменные в **содержимое** файлов и **не применяет** к соответствующим каталогам переименование по шаблону в пути. Сами файлы и каталоги при этом **не удаляются** только из‑за записи в `.templateignore` — они остаются в копии, но обрабатываются как обычный текст и обычные имена, без шага шаблонизации. +Файл `.templateignore`, наоборот, означает «не шаблонизировать»: для совпавших путей платформа не подставляет переменные в содержимое файлов и не применяет к соответствующим каталогам переименование по шаблону в пути. Сами файлы и каталоги при этом не удаляются только из‑за записи в `.templateignore` — они остаются в копии, но обрабатываются как обычный текст и обычные имена, без шага шаблонизации. #### Примеры Go template в `.templateignore` -Ниже в каждом примере показаны фрагменты `values.yaml` (или эквивалентные поля в **values** запроса) и строки **`.templateignore`**. Несколько независимых правил задают **несколькими строками** файла: результат одной строки-шаблона — одна строка с маской; перевод строк внутри результата шаблона **не** делит правило на несколько. +Ниже в каждом примере показаны фрагменты `values.yaml` (или эквивалентные поля в `values` запроса) и строки `.templateignore`. Несколько независимых правил задают несколькими строками файла: результат одной строки-шаблона — одна строка с маской; перевод строк внутри результата шаблона не делит правило на несколько. -Имя каталога в правиле берётся из `values.yaml` или из **values** действия: +Имя каталога в правиле берётся из `values.yaml` или из `values` действия: `values.yaml`: @@ -822,7 +822,7 @@ lang: ru apps/{{ .lang }}/messages.yaml ``` -Условное правило **в одной строке** (при `skipGenerated: false` подстановка даёт пустую строку — она всё равно добавляется вторым правилом; исходная строка с `{{` как маска пути обычно не совпадает с путями. При `skipGenerated: true` вторым правилом становится `generated/**`): +Условное правило в одной строке работает следующим образом: при `skipGenerated: false` подстановка даёт пустую строку, которая всё равно добавляется вторым правилом. Исходная строка с `{{` используется как маска пути и обычно не совпадает с реальными путями. При `skipGenerated: true` вторым правилом становится `generated/**`): `values.yaml`: @@ -864,7 +864,7 @@ chartName: wordpress {{ printf "charts/%s/**" .chartName }} ``` -Значение по умолчанию для «пустого» значения — функция **`default`** из набора **Sprig**. Поле в данных должно существовать (иначе при раскрытии сработает `missingkey=error`); для «не задано в YAML» заведите ключ с пустой строкой или используйте условие `if` / `index`: +Значение по умолчанию для «пустого» значения — функция `default` из набора Sprig. Поле в данных должно существовать (иначе при раскрытии сработает `missingkey=error`); для «не задано в YAML» заведите ключ с пустой строкой или используйте условие `if` / `index`: `values.yaml`: @@ -911,7 +911,7 @@ regions: configs/{{ index .regions "primary" }}/bootstrap.yaml ``` -Удаление пробелов в сегменте имени — функция **`trim`** из набора **Sprig**: +Удаление пробелов в сегменте имени — функция `trim` из набора Sprig: `values.yaml`: @@ -942,7 +942,7 @@ variant: canary #### Примеры для `additionalIgnoreFiles` -В спецификации действия перечисляются **имена файлов** в корне репозитория (например, `.ship-ignore`, `.ci-remove`). Формат строк внутри таких файлов тот же: комментарии `#`, пустые строки, маски пути, при необходимости — шаблоны Go в строках. +В спецификации действия перечисляются имена файлов в корне репозитория (например, `.ship-ignore`, `.ci-remove`). Формат строк внутри таких файлов тот же: комментарии `#`, пустые строки, маски пути, при необходимости — шаблоны Go в строках. Файл `.ship-ignore` в шаблоне: @@ -959,7 +959,7 @@ additionalIgnoreFiles: - .ship-ignore ``` -Шаблон в файле для **additionalIgnoreFiles** (удаление каталога, имя из переменных): +Шаблон в файле для `additionalIgnoreFiles` (удаление каталога, имя из переменных): Файл `.env-drop` в корне шаблона: @@ -967,10 +967,10 @@ additionalIgnoreFiles: {{ .obsoleteDir }}/** ``` -При `obsoleteDir: legacy-ui` из **values** после раскрытия в списке удаления окажутся и `{{ .obsoleteDir }}/**`, и `legacy-ui/**` — совпавшие пути будут удалены из копии перед финальными шагами. +При `obsoleteDir: legacy-ui` из `values` после раскрытия в списке удаления окажутся и `{{ .obsoleteDir }}/**`, и `legacy-ui/**` — совпавшие пути будут удалены из копии перед финальными шагами. {{< alert level="info" >}} -Не путайте назначение: **`.templateignore`** оставляет файлы на диске, но отключает для них переименование пути и рендер содержимого; списки из **additionalIgnoreFiles** **удаляют** совпавшие пути из рабочей копии. +Не путайте назначение: `.templateignore` оставляет файлы на диске, но отключает для них переименование пути и рендер содержимого; списки из `additionalIgnoreFiles` удаляют совпавшие пути из рабочей копии. {{< /alert >}} ### Пример структуры директорий шаблонного репозитория @@ -985,7 +985,7 @@ additionalIgnoreFiles: └── .templateignore ``` -Если переменная **example** при рендере репозитория примет значение **new**, то итоговая структура после рендера будет выглядеть следующим образом: +Если переменная `example` при рендере репозитория примет значение `new`, то итоговая структура после рендера будет выглядеть следующим образом: ```sh ├── example-folder-01 @@ -1001,24 +1001,24 @@ additionalIgnoreFiles: ### Локальная отладка -Для локальной отладки шаблонов доступна утилита **ddp-render-dir**. +Для локальной отладки шаблонов доступна утилита `ddp-render-dir`. Утилита: -1. Создает копию исходной директории. +1. Создаёт копию исходной директории. 1. Выполняет рендеринг файлов в этой директории по тем же правилам, что и действие создания репозиториев из шаблонов. Ключи командной строки для запуска: -* **--source-dir** — исходная директория, которую необходимо отрендерить. -* **--target-dir** — директория, в которую будет помещен результат рендеринга. -* **--values** (опционально) — путь к файлу `values.yaml` с переменными, которые будут использоваться при рендеринге. -* **--ignore-files** (опционально) — список файлов, содержащих пути для исключения из целевого репозитория. +* `--source-dir` — исходная директория, которую необходимо отрендерить. +* `--target-dir` — директория, в которую будет помещен результат рендеринга. +* `--values` (опционально) — путь к файлу `values.yaml` с переменными, которые будут использоваться при рендеринге. +* `--ignore-files` (опционально) — список файлов, содержащих пути для исключения из целевого репозитория. ## CreateSonarqubeProject CreateSonarqubeProject — создаёт новый проект в SonarQube. -Действие использует SonarQube Web API для создания проекта с указанными параметрами, такими как ключ (project key), название проекта, главная ветка, параметры определения нового кода (new code definition) и видимость проекта. Аутентификация осуществляется с использованием SonarQube token, который должен быть передан в учетных данных. +Действие использует SonarQube Web API для создания проекта с указанными параметрами, такими как ключ (project key), название проекта, главная ветка, параметры определения нового кода (new code definition) и видимость проекта. Аутентификация осуществляется с использованием SonarQube token, который должен быть передан в учётных данных. ### Пример запроса @@ -1042,9 +1042,9 @@ visibility: public | newCodeDefinitionValue | Нет | Значение для определения «нового кода» (например, количество дней, если тип - NUMBER_OF_DAYS) | - | - | | visibility | Нет | Видимость проекта | private, public | private | -### Учетные данные +### Учётные данные -* **token** — токен Sonarqube с типом User Token, сгенерированный пользователем, от имени которого будет запускаться выполнение действия. +* `token` — токен Sonarqube с типом User Token, сгенерированный пользователем, от имени которого будет запускаться выполнение действия. ## CreateVaultSecret @@ -1071,18 +1071,18 @@ secrets: | secrets.key | Да | Название (идентификатор) секрета | | - | | secrets.value | Да | Значение секрета | | - | -### Учетные данные +### Учётные данные -* **token** — Vault-токен, который имеет необходимые права для создания секретов. +* `token` — Vault-токен, который имеет необходимые права для создания секретов. ### Примечание -**allow_update** – определяет поведение действия при создании или обновлении секрета: +`allow_update` — определяет поведение действия при создании или обновлении секрета: -- `false` (по умолчанию) – действие завершается с ошибкой, если секрет уже существует; -- `true` – создаётся новая версия секрета со значениями, переданными в действии; -- `merge` – обновляются или создаются только те ключи секрета, которые указаны в действии. Существующие ключи, не упомянутые в действии, сохраняются без изменений. Если секрета по пути ещё нет, действие завершается с ошибкой; -- `merge_or_create` – как `merge`, если секрет уже существует; если секрета по пути нет, он создаётся (полная запись значений из действия). +- `false` (по умолчанию) — действие завершается с ошибкой, если секрет уже существует; +- `true` — создаётся новая версия секрета со значениями, переданными в действии; +- `merge` — обновляются или создаются только те ключи секрета, которые указаны в действии. Существующие ключи, не упомянутые в действии, сохраняются без изменений. Если секрета по пути ещё нет, действие завершается с ошибкой; +- `merge_or_create` — как `merge`, если секрет уже существует; если секрета по пути нет, он создаётся (полная запись значений из действия). ## DeleteVaultSecret @@ -1100,9 +1100,9 @@ path: example/data/path |---------------------------|----------------|----------------------------------------------------------------------------------------------------| | path | Да | Путь, по которому находится секрет в Vault, который необходимо удалить | -### Учетные данные +### Учётные данные -* **token** — Vault-токен, который имеет необходимые права для удаления секретов. +* `token` — Vault-токен, который имеет необходимые права для удаления секретов. ## DeleteDefectdojoProduct @@ -1120,13 +1120,13 @@ id: 1 |-------------|----------------|----------------------------------------------------|------------------------| | id | Да | Идентификатор продукта, который необходимо удалить | - | -### Учетные данные +### Учётные данные -* **token** — API v2 Key пользователя, от имени которого будет запускаться выполнение действия. +* `token` — API v2 Key пользователя, от имени которого будет запускаться выполнение действия. ## DeleteGitlabProject -DeleteGitlabProject - удаляет существующий проект в GitLab. Действие осуществляет вызов GitLab API для удаление проекта. Для аутентификации используется GitLab token, который должен быть предоставлен в креденшилах. +DeleteGitlabProject — удаляет существующий проект в GitLab. Действие осуществляет вызов GitLab API для удаления проекта. Для аутентификации используется GitLab token, который должен быть предоставлен в учётных данных. ### Пример запроса @@ -1140,14 +1140,14 @@ project_id: 0 |---------------------------|----------------|----------------------------------------------------------------------------------------------------| | project_id | Да | Идентификатор проекта, который необходимо удалить | -### Учетные данные +### Учётные данные -* **token** — токен пользователя, от имени которого будет запускаться выполнение действия. +* `token` — токен пользователя, от имени которого будет запускаться выполнение действия. ### Примечание -Для выполнения действия необходимо наличие корректных реквизитов с GitLab token. -Этот токен передается через механизм учетных данных и используется для аутентификации при вызове GitLab API (HTTP-заголовок `Private-Token`). +Для выполнения действия необходимо наличие токена GitLab. +Токен передаётся через механизм учётных данных и используется для аутентификации при вызове GitLab API (HTTP-заголовок `Private-Token`). Действие осуществляет DELETE-запрос по URL: `/api/v4/projects/:id`. @@ -1209,7 +1209,7 @@ acls: | securityProtocol | Да | Протокол для подключения к Kafka. Подробнее — [в документации Kafka](https://kafka.apache.org/documentation/#adminclientconfigs_security.protocol) | PLAINTEXT, SASL_PLAINTEXT, SASL_SSL | - | | saslMechanism | Нет | Механизм аутентификации, который будет использовать SASL. Обязателен при использовании протокола SASL_PLAINTEXT или SASL_SSL. Подробнее — [в документации Kafka](https://kafka.apache.org/documentation/#security_sasl_mechanism) | PLAIN, SCRAM-SHA-256, SCRAM-SHA-512 | - | | acls | Да | Набор ACL, которые необходимо создать | - | - | -| acls.ops | Да | Список операций, для которых будет создано правило. | [Список возможных операций](#список-возможных-операций) | - | +| acls.ops | Да | Список операций, для которых будет создано правило | [Список возможных операций](#список-возможных-операций) | - | | acls.pattern | Да | Тип шаблона | [Список возможных шаблонов](#список-возможных-шаблонов) | - | | acls.any_resource | Нет | Все ресурсы | - | false | | acls.topics | Нет | Список из названий топиков, для которых применять правило | - | - | @@ -1229,10 +1229,10 @@ acls: | acls.deny_hosts | Нет | Список хостов, для которых запретить операцию | - | - | | acls.any_deny_hosts | Нет | Любой хост, с которого запрещено проводить операцию | - | false | -### Учетные данные +### Учётные данные -* **user** — имя пользователя, от которого будет запускаться выполнение действия. -* **password** — пароль пользователя, от имени которого будет запускаться выполнение действия. +* `user` — имя пользователя, от которого будет запускаться выполнение действия. +* `password` — пароль пользователя, от имени которого будет запускаться выполнение действия. ### Список возможных pattern @@ -1243,9 +1243,9 @@ acls: ### Список возможных операций -Подробное описание — [в документации Kafka](https://kafka.apache.org/39/documentation/#operations_resources_and_protocols) +Подробное описание — [в документации Kafka](https://kafka.apache.org/39/documentation/#operations_resources_and_protocols). -**Topic:** +Topic: * ALL. * ALTER. @@ -1257,20 +1257,20 @@ acls: * READ. * WRITE. -**Group:** +Group: * ALL. * DELETE. * DESCRIBE. * READ. -**TransactionalID:** +TransactionalID: * ALL. * DESCRIBE. * WRITE. -**Token:** +Token: * DESCRIBE. @@ -1295,10 +1295,10 @@ topics: | auth_type | Да | Тип авторизации в Kafka | PLAINTEXT, SCRAM-SHA-256, SCRAM-SHA-512 | | topics | Да | Список названий топиков, которые необходимо удалить | - | -### Учетные данные +### Учётные данные -* **user** — имя пользователя, от которого будет запускаться выполнение действия. -* **password** — пароль пользователя, от имени которого будет запускаться выполнение действия. +* `user` — имя пользователя, от которого будет запускаться выполнение действия. +* `password` — пароль пользователя, от имени которого будет запускаться выполнение действия. ## DeleteKafkaUsers @@ -1326,10 +1326,10 @@ users: | users.user | Да | Имя удаляемого пользователя | - | | users.mechanism | Да | Механизм аутентификации удаляемого пользователя | SCRAM-SHA-256, SCRAM-SHA-512 | -### Учетные данные +### Учётные данные -* **user** — имя пользователя, от которого будет запускаться выполнение действия. -* **password** — пароль пользователя, от имени которого будет запускаться выполнение действия. +* `user` — имя пользователя, от которого будет запускаться выполнение действия. +* `password` — пароль пользователя, от имени которого будет запускаться выполнение действия. ## DeleteKubernetesResource @@ -1355,9 +1355,9 @@ namespace: example | resource_name | Да | Название конкретного ресурса, который необходимо удалить | - | | namespace | Да | Неймспейс, в котором находится ресурс | - | -### Учетные данные +### Учётные данные -* **token** — токен сервисного аккаунта в Kubernetes. +* `token` — токен сервисного аккаунта в Kubernetes. ### Определение требуемых Group и Version @@ -1367,14 +1367,14 @@ namespace: example Если неизвестно, какие требуются Group и Version, можно использовать актуальные значения. Существует несколько способов их определить: -#### С помощью утилиты kubectl +#### С помощью утилиты `d8 k` -Команда `kubectl explain` показывает `apiVersion` для ресурса. +Команда `d8 k explain` показывает `apiVersion` для ресурса. Пример: ```bash -kubectl explain deployment +d8 k explain deployment ``` Вывод: @@ -1403,8 +1403,8 @@ FIELDS: ``` Здесь: - * **API Group** - apps - * **Version** - v1 + * «API Group» — apps; + * «Version» — v1. ## DeleteSonarqubeProject @@ -1422,9 +1422,9 @@ project: example-project |------------------|------------------|-----------------------------------------------------------------|------------------------| | project | Да | Идентификатор (Project Key) проекта, который необходимо удалить | - | -### Учетные данные +### Учётные данные -* **token** — токен Sonarqube с типом User Token, сгенерированный пользователем, от имени которого будет запускаться выполнение действия. +* `token` — токен Sonarqube с типом User Token, сгенерированный пользователем, от имени которого будет запускаться выполнение действия. ## DeleteSonarqubeProjects @@ -1450,9 +1450,9 @@ qualifiers: TRK | q | Нет | Удалить все проекты, в названии или ключе которых содержится заданная подстрока | - | example | | qualifiers | Нет | Фильтровать проекты по указанным квалификаторам | TRK, VW, APP | | -### Учетные данные +### Учётные данные -* **token** — токен Sonarqube с типом User Token, сгенерированный пользователем, от имени которого будет запускаться выполнение действия. +* `token` — токен Sonarqube с типом User Token, сгенерированный пользователем, от имени которого будет запускаться выполнение действия. ## StartGitlabPipeline @@ -1478,14 +1478,14 @@ variables: | variables.key | Да | Название переменной | | variables.value | Да | Значение переменной | -### Учетные данные +### Учётные данные -* **token** — токен пользователя, от имени которого будет запускаться выполнение действия. +* `token` — токен пользователя, от имени которого будет запускаться выполнение действия. ### Примечание -Для выполнения действия необходимо наличие корректных реквизитов с GitLab token. -Этот токен передается через механизм учетных данных и используется для аутентификации при вызове GitLab API (HTTP-заголовок `Private-Token`). +Для выполнения действия необходимо наличие токена GitLab. +Токен передаётся через механизм учётных данных и используется для аутентификации при вызове GitLab API (HTTP-заголовок `Private-Token`). Действие осуществляет POST-запрос по URL: `/api/v4/projects/:id/pipeline`. @@ -1514,11 +1514,11 @@ optional: | Название | Обязательность | Описание | |-------------------------------------|----------------|-----------------------------------------------------------------------------------| -| mountPath | обязательно | Путь монтирования Kubernetes auth backend в Vault (например, kubernetes) | -| role | обязательно | Название роли, которая создаётся в Vault | -| bound_service_account_names | обязательно | Список имён service account'ов, которым разрешён доступ через данную роль | -| bound_service_account_namespaces | обязательно | Список пространств имён (namespaces), в которых разрешён доступ через данную роль | -| optional | необязательно | Дополнительные параметры роли (приведены в следующей таблице) | +| mountPath | Обязательно | Путь монтирования Kubernetes auth backend в Vault (например, kubernetes) | +| role | Обязательно | Название роли, которая создаётся в Vault | +| bound_service_account_names | Обязательно | Список имён service account'ов, которым разрешён доступ через данную роль | +| bound_service_account_namespaces | Обязательно | Список неймспейсов (namespaces), в которых разрешён доступ через данную роль | +| optional | Необязательно | Дополнительные параметры роли (приведены в следующей таблице) | Поддерживаемые значения в optional: @@ -1538,13 +1538,13 @@ optional: Полный список поддерживаемых параметров приведён в [официальной документации](https://developer.hashicorp.com/vault/docs/auth/kubernetes#parameters) HashiCorp Vault. -### Учетные данные +### Учётные данные -* **token** — Vault-токен, обладающий правами на создание/обновление ролей Kubernetes auth backend. +* `token` — Vault-токен, обладающий правами на создание/обновление ролей Kubernetes auth backend. ## CreateNexusRepository -**CreateNexusRepository** — создаёт новый репозиторий любого поддерживаемого типа (maven, docker, npm и др.) в Nexus Repository Manager 3 с помощью REST API. +`CreateNexusRepository` — создаёт новый репозиторий любого поддерживаемого типа (maven, docker, npm и др.) в Nexus Repository Manager 3 с помощью REST API. Параметры формата, типа и другие ключевые настройки полностью настраиваются и соответствуют Nexus API. ### Пример запроса (Maven hosted) @@ -1596,33 +1596,33 @@ docker: |-------------|-----------------|---------------------------------------------------------------------------------------------------|----------------------------------------| | `description` | Нет | Документация по назначению этого действия/репозитория. Не используется самим Nexus, только для UI | - | | `name` | Да | Название создаваемого репозитория. Должно быть уникальным в рамках Nexus | my-maven-repo | -| `format` | Да | Формат (`maven`, `docker`, `npm`, `raw` и т.д.) | maven | +| `format` | Да | Формат (`maven`, `docker`, `npm`, `raw` и т. д.) | maven | | `type` | Да | Тип: `hosted`, `proxy` или `group` | hosted | | `online` | Да | Доступен ли репозиторий (`true`/`false`) | true | | `storage` | Да | Объект storage: `blobStoreName`, `strictContentTypeValidation`, `writePolicy` | [Пример](#пример-запроса-maven-hosted) | | `cleanup` | Нет | Привязанные политики очистки (`policyNames`) | policyNames: [maven-cleanup] | -| `maven` | для maven | Только для maven: `versionPolicy`, `layoutPolicy` | [Пример](#пример-запроса-maven-hosted) | -| `proxy` | для proxy | Прокси-репозиторий: `remoteUrl`, `contentMaxAge`, `metadataMaxAge` | - | -| `group` | для group | Список включенных memberNames | [Пример](#пример-запроса-docker-group) | -| `docker` | для docker | docker-specific: `httpPort`, `v1Enabled`, `forceBasicAuth` | [Пример](#пример-запроса-docker-group) | -| `component` | очень редко | Только для некоторых нестандартных сценариев | - | +| `maven` | Для maven | Только для maven: `versionPolicy`, `layoutPolicy` | [Пример](#пример-запроса-maven-hosted) | +| `proxy` | Для proxy | Прокси-репозиторий: `remoteUrl`, `contentMaxAge`, `metadataMaxAge` | - | +| `group` | Для group | Список включённых memberNames | [Пример](#пример-запроса-docker-group) | +| `docker` | Для docker | docker-specific: `httpPort`, `v1Enabled`, `forceBasicAuth` | [Пример](#пример-запроса-docker-group) | +| `component` | Очень редко | Только для некоторых нестандартных сценариев | - | | `attributes`| Нет | Любые кастомные поля | - | ### Требования -- Используйте **только те блоки** (`maven`, `group`, `proxy`, `docker` и пр.), которые поддерживаются для вашего типа/формата. +- Используйте только те блоки (`maven`, `group`, `proxy`, `docker` и пр.), которые поддерживаются для вашего типа/формата. - Для maven hosted обязательно `maven: {versionPolicy, layoutPolicy}`. - Для group — обязательно `group.memberNames`. - Для proxy — обязательно `proxy.remoteUrl`. - Для docker — специфичные поля в `docker`. -### Учетные данные +### Учётные данные -* **token** — строка base64(`admin:password`), используется как Basic Auth при запросах к Nexus. +* `token` — строка base64(`admin:password`), используется как Basic Auth при запросах к Nexus. ## DeleteNexusRepository -**DeleteNexusRepository** — удаляет существующий репозиторий из Nexus Repository Manager 3. +`DeleteNexusRepository` — удаляет существующий репозиторий из Nexus Repository Manager 3. ### Пример запроса @@ -1642,9 +1642,9 @@ name: my-repo-to-delete - Если репозиторий найден и удалён — возвращается 204. - Если не найден — возвращается ошибка 404. -### Учетные данные +### Учётные данные -* **token** — строка base64(`admin:password`), используется как Basic Auth при запросах к Nexus. +* `token` — строка base64(`admin:password`), используется как Basic Auth при запросах к Nexus. ## CreateNexusPrivilege @@ -1706,9 +1706,9 @@ actions: Для типа `repository-content-selector` селектор контента должен существовать в Nexus до создания привилегии. Если селектор контента не указан или невалиден, действие автоматически преобразует тип привилегии в `repository-view`. -### Учетные данные +### Учётные данные -* **token** — строка base64(`admin:password`), используется как Basic Auth при запросах к Nexus. +* `token` — строка base64(`admin:password`), используется как Basic Auth при запросах к Nexus. ## AssignNexusPrivilege @@ -1733,12 +1733,12 @@ privileges: ### Алгоритм работы 1. Получает текущую конфигурацию роли из Nexus. -2. Объединяет существующие привилегии роли с новыми привилегиями из запроса. -3. Обновляет роль с объединённым списком привилегий. +1. Объединяет существующие привилегии роли с новыми привилегиями из запроса. +1. Обновляет роль с объединённым списком привилегий. -### Учетные данные +### Учётные данные -* **token** — строка base64(`admin:password`), используется как Basic Auth при запросах к Nexus. +* `token` — строка base64(`admin:password`), используется как Basic Auth при запросах к Nexus. ### Примечание @@ -1760,9 +1760,9 @@ name: example-privilege |------|-----------------|---------------------------------------------| | name | Да | Название привилегии, которую требуется удалить | -### Учетные данные +### Учётные данные -* **token** — строка base64(`admin:password`), используется как Basic Auth при запросах к Nexus. +* `token` — строка base64(`admin:password`), используется как Basic Auth при запросах к Nexus. ## CreateNexusRole @@ -1790,9 +1790,9 @@ roles: [] | privileges | Нет | Список названий привилегий, которые назначаются роли | | roles | Нет | Список идентификаторов других ролей, которые включаются в данную роль | -### Учетные данные +### Учётные данные -* **token** — строка base64(`admin:password`), используется как Basic Auth при запросах к Nexus. +* `token` — строка base64(`admin:password`), используется как Basic Auth при запросах к Nexus. ## AssignNexusRole @@ -1817,12 +1817,12 @@ roles: ### Алгоритм работы 1. Получает текущую конфигурацию пользователя из Nexus. -2. Объединяет существующие роли пользователя с новыми ролями из запроса. -3. Обновляет пользователя с объединённым списком ролей. +1. Объединяет существующие роли пользователя с новыми ролями из запроса. +1. Обновляет пользователя с объединённым списком ролей. -### Учетные данные +### Учётные данные -* **token** — строка base64(`admin:password`), используется как Basic Auth при запросах к Nexus. +* `token` — строка base64(`admin:password`), используется как Basic Auth при запросах к Nexus. ### Примечание @@ -1844,9 +1844,9 @@ id: example-role |------|-----------------|-----------------------------------------| | id | Да | Идентификатор роли, которую требуется удалить | -### Учетные данные +### Учётные данные -* **token** — строка base64(`admin:password`), используется как Basic Auth при запросах к Nexus. +* `token` — строка base64(`admin:password`), используется как Basic Auth при запросах к Nexus. ## CreateNexusUser @@ -1877,9 +1877,9 @@ roles: | status | Да | Статус пользователя: `active` или `disabled` | | roles | Нет | Список идентификаторов ролей, которые назначаются пользователю при создании | -### Учетные данные +### Учётные данные -* **token** — строка base64(`admin:password`), используется как Basic Auth при запросах к Nexus. +* `token` — строка base64(`admin:password`), используется как Basic Auth при запросах к Nexus. ## DeleteNexusUser @@ -1897,13 +1897,13 @@ userId: example-user |--------|-----------------|---------------------------------------------| | userId | Да | Идентификатор пользователя, которого требуется удалить | -### Учетные данные +### Учётные данные -* **token** — строка base64(`admin:password`), используется как Basic Auth при запросах к Nexus. +* `token` — строка base64(`admin:password`), используется как Basic Auth при запросах к Nexus. ## Wait -**Wait** ожидает заданное число секунд; дополнительно может применяться случайная добавка к длительности (джиттер). Предназначено для использования в процессах в качестве элемента задержки, в том числе для ожидания применения результатов предыдущего действия. +Wait ожидает заданное число секунд; дополнительно может применяться случайная добавка к длительности (джиттер). Предназначено для использования в процессах в качестве элемента задержки, в том числе для ожидания применения результатов предыдущего действия. ### Пример запроса @@ -1923,7 +1923,7 @@ description: "Waiting for release" ## Fail -**Fail** эмулирует ошибку исполнения действия. Предназначен для использования в процессах в качестве отладочного элемента. +Fail эмулирует ошибку исполнения действия. Предназначен для использования в процессах в качестве отладочного элемента. ### Пример запроса diff --git a/content/documentation/admin/architecture/functional-architecture.ru.md b/content/documentation/admin/architecture/functional-architecture.ru.md index cf6bdf06..07877af2 100644 --- a/content/documentation/admin/architecture/functional-architecture.ru.md +++ b/content/documentation/admin/architecture/functional-architecture.ru.md @@ -5,25 +5,27 @@ weight: 10 ## Описание компонентов +В состав Deckhouse Development Platform (DDP) входят следующие компоненты. + ### DDP Frontend -**DDP Frontend** — это веб-интерфейс платформы, построенный на Vue.js 3 с TypeScript. Компонент предоставляет пользователям графический интерфейс для работы с платформой через веб-браузер. +DDP Frontend — это веб-интерфейс платформы, построенный на Vue.js 3 с TypeScript. Компонент предоставляет пользователям графический интерфейс для работы с платформой через веб-браузер. -**Основные функции:** +Основные функции: * Отображение пользовательского интерфейса для управления сервисами, окружениями и ресурсами. * Обработка пользовательских действий и передача запросов в DDP Backend через REST API. -**Технические характеристики:** +Технические характеристики: * Принимает входящие соединения от пользователей. * Взаимодействует с DDP Backend. ### DDP Backend -**DDP Backend** — это серверная часть платформы, реализованная на языке Go. Компонент предоставляет REST API для управления всеми механизмами платформы. +DDP Backend — это серверная часть платформы, реализованная на языке Go. Компонент предоставляет REST API для управления всеми механизмами платформы. -**Основные функции:** +Основные функции: * Предоставление REST API для программного взаимодействия с платформой. * Обработка бизнес-логики платформы. @@ -31,7 +33,7 @@ weight: 10 * Интеграция с внешними инфраструктурными сервисами для выполнения различных операций. * Управление данными через взаимодействие с PostgreSQL и Redis. -**Технические характеристики:** +Технические характеристики: * Принимает API-запросы от пользователей и DDP Frontend. * Выполняет валидацию токенов доступа локально, используя кэшированные ключи подписи. @@ -40,15 +42,15 @@ weight: 10 ### DDP Worker -**DDP Worker** — это компонент для выполнения фоновых задач и асинхронных операций, реализованный на языке Go. Worker обрабатывает задачи из очередей Redis Streams и выполняет операции по запуску действий и синхронизации источников данных. +DDP Worker — это компонент для выполнения фоновых задач и асинхронных операций, реализованный на языке Go. Worker обрабатывает задачи из очередей Redis Streams и выполняет операции по запуску действий и синхронизации источников данных. -**Основные функции:** +Основные функции: * Синхронизация данных из внешних источников. * Выполнение действий в асинхронном режиме. * Выполнение проверок статуса сущностей. -**Технические характеристики:** +Технические характеристики: * Может быть развернут в нескольких экземплярах для обеспечения масштабируемости. * Использует Redis Streams для получения задач из очередей. @@ -57,20 +59,20 @@ weight: 10 ### Dex -**Dex** — это компонент системы аутентификации и авторизации, выполняющий роль identity provider. Dex обеспечивает единую точку входа для пользователей и интегрируется с различными внешними провайдерами аутентификации. +Dex — это компонент системы аутентификации и авторизации, выполняющий роль identity provider. Dex обеспечивает единую точку входа для пользователей и интегрируется с различными внешними провайдерами аутентификации. {{< alert level="warning" >}} -**Dex** не входит в состав модуля DDP (Deckhouse Development Platform) и является частью DKP (Deckhouse Kubernetes Platform). +Dex не входит в состав модуля DDP и является частью Deckhouse Kubernetes Platform (DKP). {{< /alert >}} -**Основные функции:** +Основные функции: * Управление процессом аутентификации пользователей. * Выдача токенов доступа. * Интеграция с внешними провайдерами аутентификации (Keycloak, LDAP и другими). * Предоставление ключей подписи для проверки токенов. -**Технические характеристики:** +Технические характеристики: * Выписывает токены для аутентификации в DDP Backend. * Периодически предоставляет ключи подписи токенов для проверки. @@ -78,25 +80,25 @@ weight: 10 ### Redis -**Redis** — это хранилище данных в памяти, используемое платформой для работы с очередями задач. +Redis — это хранилище данных в памяти, используемое платформой для работы с очередями задач. {{< alert level="info" >}} Redis может быть установлен в составе модуля DDP для тестовых и демонстрационных целей. В промышленной эксплуатации рекомендуется использование выделенных инстансов Redis. {{< /alert >}} -**Основные функции:** +Основные функции: * Реализация очередей задач через Redis Streams для асинхронной обработки. * Поддержка распределенных блокировок для координации работы нескольких экземпляров Worker. * Хранение событий, генерируемых при изменениях сущностей. -**Технические характеристики:** +Технические характеристики: * Используется для хранения очередей задач, которые обрабатываются DDP Worker. ### PostgreSQL -**PostgreSQL** — это основная реляционная база данных платформы, используемая для хранения всей постоянной информации. +PostgreSQL — это основная реляционная база данных платформы, используемая для хранения всей постоянной информации. {{< alert level="info" >}} PostgreSQL может быть установлен в составе модуля DDP для тестовых и демонстрационных целей. В промышленной эксплуатации рекомендуется использование выделенных инстансов PostgreSQL. @@ -108,20 +110,20 @@ PostgreSQL может быть установлен в составе модул ### Входящие соединения -* Пользователи подключаются к **DDP Frontend** по протоколу HTTPS (TCP/443) для работы с веб-интерфейсом. -* Пользователи могут напрямую обращаться к **DDP Backend** по протоколу HTTPS (TCP/443) для использования REST API. +* Пользователи подключаются к DDP Frontend по протоколу HTTPS (TCP/443) для работы с веб-интерфейсом. +* Пользователи могут напрямую обращаться к DDP Backend по протоколу HTTPS (TCP/443) для использования REST API. ### Взаимодействие между компонентами платформы -* **DDP Frontend** → **DDP Backend** (TCP/8080, опционально mTLS): Frontend передает запросы пользователей в Backend для обработки. -* **DDP Backend** ↔ **Dex** (TCP/443): Backend получает ключи подписи от Dex для проверки токенов. -* **DDP Backend** ↔ **Redis** (TCP/6379): Backend использует Redis для координации очередей задач и хранения событий. -* **DDP Backend** ↔ **PostgreSQL** (TCP/5432): Backend выполняет операции чтения и записи постоянных данных. -* **DDP Worker** ↔ **Redis** (TCP/6379): Worker получает задачи из очередей Redis Streams и использует распределенные блокировки. -* **DDP Worker** ↔ **PostgreSQL** (TCP/5432): Worker обновляет данные в базе после выполнения задач. +* DDP Frontend → DDP Backend (TCP/8080, опционально mTLS): Frontend передает запросы пользователей в Backend для обработки. +* DDP Backend ↔ Dex (TCP/443): Backend получает ключи подписи от Dex для проверки токенов. +* DDP Backend ↔ Redis (TCP/6379): Backend использует Redis для координации очередей задач и хранения событий. +* DDP Backend ↔ PostgreSQL (TCP/5432): Backend выполняет операции чтения и записи постоянных данных. +* DDP Worker ↔ Redis (TCP/6379): Worker получает задачи из очередей Redis Streams и использует распределенные блокировки. +* DDP Worker ↔ PostgreSQL (TCP/5432): Worker обновляет данные в базе после выполнения задач. ### Интеграция с внешними сервисами -* **Dex** ↔ **Провайдеры аутентификации** (Keycloak, LDAP и др.): Dex интегрируется с внешними системами управления пользователями. -* **DDP Backend** ↔ **Инфраструктурные сервисы** (TCP/443): Backend взаимодействует с внешними сервисами для получения информации. -* **DDP Worker** ↔ **Инфраструктурные сервисы** (TCP/443): Worker выполняет операции с внешними сервисами при синхронизации данных и выполнении действий. +* Dex ↔ Провайдеры аутентификации (Keycloak, LDAP и др.): Dex интегрируется с внешними системами управления пользователями. +* DDP Backend ↔ Инфраструктурные сервисы (TCP/443): Backend взаимодействует с внешними сервисами для получения информации. +* DDP Worker ↔ Инфраструктурные сервисы (TCP/443): Worker выполняет операции с внешними сервисами при синхронизации данных и выполнении действий. diff --git a/content/documentation/admin/architecture/high-level-architecture.ru.md b/content/documentation/admin/architecture/high-level-architecture.ru.md index 7f3fc3fc..a221ef21 100644 --- a/content/documentation/admin/architecture/high-level-architecture.ru.md +++ b/content/documentation/admin/architecture/high-level-architecture.ru.md @@ -10,7 +10,7 @@ Deckhouse Development Platform (DDP) — это IDP (Internal Developer Platform Платформа предоставляет единый слой взаимодействия с инфраструктурными и инженерными сервисами и используется для автоматизации операций, связанных с жизненным циклом продуктов. DDP обеспечивает единый доступ к инструментам и ресурсам, формализует и автоматизирует процессы разработки, а также упрощает подключение новых пользователей и команд. -**Основные задачи платформы:** +Основные задачи платформы: - Обеспечение единых стандартов разработки для команд через шаблоны и типовые конфигурации. - Управление динамическими окружениями с автоматическим созданием, обновлением и удалением сред. @@ -44,7 +44,7 @@ DDP обеспечивает единый доступ к инструмента ### Администраторы Администраторы — пользователи, обладающие полными правами на настройку и сопровождение платформы. -Они управляют учетными записями пользователей, настраивают роли и права доступа через систему RBAC, конфигурируют интеграции с внешними сервисами, управляют учетными данными, ресурсами, автоматизациями и параметрами платформы, а также просматривают аудит-логи. +Они управляют учётными записями пользователей, настраивают роли и права доступа через систему RBAC, конфигурируют интеграции с внешними сервисами, управляют учётными данными, ресурсами, автоматизациями и параметрами платформы, а также просматривают аудит-логи. Права доступа для всех групп пользователей настраиваются через систему ролевого доступа (RBAC), которая обеспечивает гибкое управление разрешениями на уровне глобальных ролей, ролей ресурсов и ролей сущностей. @@ -52,31 +52,31 @@ DDP обеспечивает единый доступ к инструмента ### Веб-интерфейс -Все группы пользователей получают доступ к платформе через веб-интерфейс **DDP Frontend**, предназначенный для работы с платформой в веб-браузере. +Все группы пользователей получают доступ к платформе через веб-интерфейс DDP Frontend, предназначенный для работы с платформой в веб-браузере. -**Протокол доступа:** HTTPS (TCP/443) +Протокол доступа: HTTPS (TCP/443) -**Аутентификация:** Пользователи проходят аутентификацию через компонент **Dex**, который интегрируется с внешними провайдерами аутентификации (Keycloak, LDAP и др.) через стандартные протоколы (OIDC, LDAP). После успешной аутентификации пользователь получает JWT токен доступа, который используется для авторизации запросов к платформе. +Аутентификация: Пользователи проходят аутентификацию через компонент Dex, который интегрируется с внешними провайдерами аутентификации (Keycloak, LDAP и др.) через стандартные протоколы (OIDC, LDAP). После успешной аутентификации пользователь получает JWT токен доступа, который используется для авторизации запросов к платформе. ### REST API -Администраторы и разработчики могут напрямую обращаться к **DDP Backend** через REST API для программного взаимодействия с платформой. +Администраторы и разработчики могут напрямую обращаться к DDP Backend через REST API для программного взаимодействия с платформой. -**Протокол доступа:** HTTPS (TCP/443) +Протокол доступа: HTTPS (TCP/443) -**Аутентификация:** -- Браузер: сессия по httpOnly cookie (JWT от Dex). +Аутентификация: +- Браузер: сессия по файлу cookie с флагом `HttpOnly` (JWT от Dex). - Программный доступ: API-токен из раздела «Профиль», заголовок `Authorization: Bearer `. REST API предоставляет полный набор функций для управления всеми объектами платформы: сущностями, ресурсами, действиями, источниками данных, виджетами, процессами и другими компонентами. ## Доступ снаружи/внутри периметра компании -Платформа DDP развертывается в кластере Kubernetes и может быть доступна как внутри корпоративного периметра, так и снаружи, в зависимости от конфигурации сетевой инфраструктуры. +DDP развёртывается в кластере Kubernetes и может быть доступна как внутри корпоративного периметра, так и снаружи в зависимости от конфигурации сетевой инфраструктуры. ### Доступ внутри периметра -**Типичный сценарий:** Пользователи получают доступ к платформе через внутреннюю сеть компании. +Типичный сценарий: Пользователи получают доступ к платформе через внутреннюю сеть компании. - Веб-интерфейс и REST API доступны через внутренний Ingress-контроллер. - Доступ осуществляется по внутренним доменным именам (например, `ddp.internal.company.com`). @@ -85,7 +85,7 @@ REST API предоставляет полный набор функций дл ### Доступ снаружи периметра -**Типичный сценарий:** Пользователи получают доступ к платформе извне корпоративной сети. +Типичный сценарий: Пользователи получают доступ к платформе извне корпоративной сети. - Веб-интерфейс и REST API доступны через публичный Ingress-контроллер. - Доступ осуществляется по публичным доменным именам (например, `ddp.company.com`). diff --git a/content/documentation/admin/architecture/workers.ru.md b/content/documentation/admin/architecture/workers.ru.md index e4636193..194240a8 100644 --- a/content/documentation/admin/architecture/workers.ru.md +++ b/content/documentation/admin/architecture/workers.ru.md @@ -29,7 +29,7 @@ weight: 20 ## Мониторинг -Для мониторинга работы воркеров и очереди задач доступен виджет **Очередь задач** ([подробнее](../../widgets/types/#очередь-задач)), который отображает: +Для мониторинга работы воркеров и очереди задач доступен виджет [«Очередь задач»](../../widgets/types/#очередь-задач), который отображает: - Размер очереди (общее количество задач). - Количество ожидающих задач. @@ -49,10 +49,11 @@ weight: 20 export WORKER_MAX_TASKS=15 ``` -**Приоритет настроек:** +Приоритет настроек: + 1. Значение из конфигурационного файла. -2. Значение из переменной окружения. -3. Значение по умолчанию. +1. Значение из переменной окружения. +1. Значение по умолчанию. ## Типы обрабатываемых задач diff --git a/content/documentation/admin/automations.ru.md b/content/documentation/admin/automations.ru.md index db7e5fb7..a5c1f626 100644 --- a/content/documentation/admin/automations.ru.md +++ b/content/documentation/admin/automations.ru.md @@ -1,13 +1,11 @@ --- title: Автоматизации menuTitle: Автоматизации -d8Edition: ee -moduleStatus: experimental --- -Автоматизации - механизм реагирования платформы на изменения спецификации сущностей. +Автоматизации — механизм реагирования платформы на изменения спецификации сущностей. -Каждая автоматизация может подписываться на обновления сущностей какого-либо ресурса по определенным правилам. При возникновении события обновления автоматизация запускает выполнение действия, процесса или синхронизации источника данных. +Каждая автоматизация может подписываться на обновления сущностей какого-либо ресурса по определённым правилам. При возникновении события обновления автоматизация запускает выполнение действия, процесса или синхронизации источника данных. Автоматизация может запускать выполнение как для сущности, которая вызвала триггер, так и для связанных с ней сущностей в соответствии с настройками. @@ -17,7 +15,7 @@ moduleStatus: experimental ## Интерфейс настройки автоматизации -Форма создания и редактирования автоматизации разделена на логические секции: +Форма создания и редактирования автоматизации разделена на логические секции. ### Триггеры @@ -25,13 +23,13 @@ moduleStatus: experimental При настройке каждого триггера указываются: -* **Ресурс** — ресурс, события с сущностями которого будут являться триггером для запуска автоматизации -* **Условие** — условие в формате [Go template](https://developer.hashicorp.com/nomad/docs/reference/go-template-syntax), описывающее, изменения какого параметра будет считаться триггером для запуска автоматизации и какое именно значение должен принять измененный параметр. +* «Ресурс» — ресурс, события с сущностями которого будут являться триггером для запуска автоматизации; +* «Условие» — условие в формате [Go template](https://developer.hashicorp.com/nomad/docs/reference/go-template-syntax), описывающее, изменения какого параметра будет считаться триггером для запуска автоматизации и какое именно значение должен принять изменённый параметр. Примеры условий триггера: -* `{{ ne .entity.properties.id 0 }}` — автоматизация будет запускаться, если значение параметра `id` изменилось и после изменения стало не равным нулю -* `{{ eq .entity.properties.status "Failed" }}` — автоматизация будет запускаться, если значение параметра `status` изменилось на `Failed` с любого другого +* `{{ ne .entity.properties.id 0 }}` — автоматизация будет запускаться, если значение параметра `id` изменилось и после изменения стало не равным нулю; +* `{{ eq .entity.properties.status "Failed" }}` — автоматизация будет запускаться, если значение параметра `status` изменилось на `Failed` с любого другого. ### Выполнение @@ -39,12 +37,12 @@ moduleStatus: experimental Настраиваются: -* **Тип выполнения** — тип объекта, который будет выполняться: действие, процесс или синхронизация источника данных -* **Объект выполнения** — конкретный объект (действие, процесс или источник данных), который будет выполняться +* «Тип выполнения» — тип объекта, который будет выполняться: действие, процесс или синхронизация источника данных; +* «Объект выполнения» — конкретный объект (действие, процесс или источник данных), который будет выполняться. Для действий и процессов доступна дополнительная настройка: -* **Запускать выполнение для связанных ресурсов** — при включении этой опции выполнение будет автоматически запускаться для всех сущностей, имеющих соответствующую связь с изменённой сущностью. При этом выполнение не будет запущено на сущность, вызвавшую событие +* «Запускать выполнение для связанных ресурсов» — при включении этой опции выполнение будет автоматически запускаться для всех сущностей, имеющих соответствующую связь с изменённой сущностью. При этом выполнение не будет запущено на сущность, вызвавшую событие. ### Синхронизация @@ -52,18 +50,20 @@ moduleStatus: experimental Настраиваются: -* **Периодическая синхронизация** — включение/выключение периодической синхронизации -* **Периодичность запуска** — cron-выражение для настройки частоты запуска автоматизации (например, `0 0 * * *` для ежедневного запуска в полночь) +* «Периодическая синхронизация» — включение/выключение периодической синхронизации; +* «Периодичность запуска» — cron-выражение для настройки частоты запуска автоматизации (например, `0 0 * * *` для ежедневного запуска в полночь). ## Триггеры -Механизм работы триггеров автоматизаций основан на событиях (event's), которые генерируются при каждом создании, изменении, либо удалении любой сущности любого ресурса. +Механизм работы триггеров автоматизаций основан на событиях (events), которые генерируются при каждом создании, изменении либо удалении любой сущности любого ресурса. Автоматизации: -1. Прослушивают события указанных в конфигурации триггеров ресурсов -2. Проверяют, изменилось ли значение параметра, указанного в условиях триггера -3. При изменении сравнивают текущее значение параметра с условием -4. При соответствии условию запускают выполнение +1. Прослушивают события указанных в конфигурации триггеров ресурсов. +1. Проверяют, изменилось ли значение параметра, указанного в условиях триггера. +1. При изменении сравнивают текущее значение параметра с условием. +1. При соответствии условию запускают выполнение. -**Важно:** Новые автоматизации обрабатывают только события, которые произошли после их создания. События, произошедшие до создания автоматизации, не будут обработаны. +{{< alert level="warning" >}} +Новые автоматизации обрабатывают только события, которые произошли после их создания. События, произошедшие до создания автоматизации, не будут обработаны. +{{< /alert >}} diff --git a/content/documentation/admin/datasets.ru.md b/content/documentation/admin/datasets.ru.md index ebdcab20..aa3d24c3 100644 --- a/content/documentation/admin/datasets.ru.md +++ b/content/documentation/admin/datasets.ru.md @@ -1,11 +1,9 @@ --- title: Наборы данных menuTitle: Наборы данных -d8Edition: ee -moduleStatus: experimental --- -Наборы данных - это предварительно настроенные конфигурации, предназначенные для быстрого развертывания готовых интеграций с внешними системами и настройки необходимых компонентов платформы. +Наборы данных — это предварительно настроенные конфигурации, предназначенные для быстрого развёртывания готовых интеграций с внешними системами и настройки необходимых компонентов платформы. Каждый набор данных содержит: @@ -13,7 +11,7 @@ moduleStatus: experimental - Виджеты для отображения информации. - Источники данных для синхронизации. - Внешние сервисы для подключения к API. -- Типы учетных данных для аутентификации. +- Типы учётных данных для аутентификации. - Роли и права доступа. - Другие необходимые компоненты платформы. @@ -21,27 +19,27 @@ moduleStatus: experimental ### Просмотр доступных наборов -В разделе «Администрирование» → «Наборы данных» отображается список всех доступных наборов данных. Каждая карточка содержит: +В разделе «Администрирование» → «Наборы данных» отображается список всех доступных наборов данных. Каждая карточка содержит: -- **Название** - название набора данных. -- **Краткое описание** - общее описание функциональности. -- **Кнопка «Описание»** - открывает подробную информацию о наборе данных, включая: - - Подробное описание с полной информацией о компонентах. - - Список объектов, которые будут созданы при применении. -- **Кнопка «Применить»** - запускает процесс установки набора данных. -- **Кнопка «Удалить»** - удаляет ранее примененный набор данных. +- «Название» — название набора данных. +- «Краткое описание» — общее описание функциональности. +- Кнопка «Описание» — открывает подробную информацию о наборе данных, включая: + - подробное описание с полной информацией о компонентах; + - список объектов, которые будут созданы при применении. +- Кнопка «Применить» — запускает процесс установки набора данных. +- Кнопка «Удалить» — удаляет ранее применённый набор данных. ### Применение набора данных -1. Нажмите кнопку **«Применить»** на карточке нужного набора данных. +1. Нажмите кнопку «Применить» на карточке нужного набора данных. 1. Если набор данных требует настройки параметров, откроется форма конфигурации. -1. Заполните необходимые параметры и нажмите **«Применить»**. +1. Заполните необходимые параметры и нажмите «Применить». 1. Если параметры не требуются, появится окно подтверждения. 1. После успешного применения все компоненты набора данных будут созданы в системе. ### Удаление набора данных -1. Нажмите кнопку **«Удалить»** на карточке примененного набора данных. +1. Нажмите кнопку «Удалить» на карточке примененного набора данных. 1. Подтвердите удаление в диалоговом окне. 1. Все компоненты набора данных будут удалены из системы. @@ -49,8 +47,8 @@ moduleStatus: experimental После применения некоторых наборов данных может потребоваться дополнительная настройка: -1. Перейдите в **«Профиль»** → **«Учетные данные»**. -1. Заполните необходимые учетные данные (токены, пароли и т.д.). +1. Перейдите в «Профиль» → «Учётные данные». +1. Заполните необходимые учётные данные (токены, пароли и т.д.). 1. Сохраните изменения. ## Доступные наборы данных @@ -59,40 +57,40 @@ moduleStatus: experimental Набор данных предназначен для работы с GitLab-репозиториями и анализа процессов CI/CD. -**Дашборды:** +Дашборды: -- **Статистика репозитория** - для анализа статистики пайплайнов. -- **Управление репозиторием** - для управления репозиториями. +- «Статистика репозитория» — для анализа статистики пайплайнов. +- «Управление репозиторием» — для управления репозиториями. -**Виджеты:** +Виджеты: -- **Статистика пайплайнов GitLab** - для детальной аналитики пайплайнов. -- **GitLab пайплайны** - для управления пайплайнами. -- **Редактор пайплайнов GitLab** - для редактирования конфигурации пайплайнов. +- «Статистика пайплайнов GitLab» — для детальной аналитики пайплайнов. +- «GitLab пайплайны» — для управления пайплайнами. +- «Редактор пайплайнов GitLab» — для редактирования конфигурации пайплайнов. -**Настройка:** +Настройка: -Набор данных настраивает подключение к GitLab API через внешний сервис, создает типы учетных данных для токена и имени пользователя и подключает источник данных для синхронизации репозиториев GitLab в каталог. +Набор данных настраивает подключение к GitLab API через внешний сервис, создаёт типы учётных данных для токена и имени пользователя и подключает источник данных для синхронизации репозиториев GitLab в каталог. {{< alert level="info" >}} -После применения необходимо заполнить в профиле супер-администратора учетные данные GitLab token. +После применения необходимо заполнить в профиле супер-администратора учётные данные GitLab token. {{< /alert >}} -**Параметры настройки:** +Параметры настройки: -- **GitLab URL** - адрес вашего GitLab сервера (по умолчанию: ). +- «GitLab URL» — адрес вашего GitLab-сервера (по умолчанию: `https://gitlab.example.com`). -**Требования:** +Требования: - Доступ к GitLab API. - Токен доступа GitLab с правами на чтение репозиториев и пайплайнов. -**Применение:** +Применение: 1. Примените набор данных GitLab. -1. Укажите URL вашего GitLab сервера. +1. Укажите URL вашего GitLab-сервера. 1. Перейдите в профиль супер-администратора. -1. Заполните учетные данные «GitLab token» вашим токеном доступа. +1. Заполните учётные данные «GitLab token» вашим токеном доступа. 1. Сохраните изменения. После этого в разделе «Каталог» появятся ваши репозитории GitLab, а на дашбордах будет отображаться статистика и управление пайплайнами. diff --git a/content/documentation/admin/datasources/overview.ru.md b/content/documentation/admin/datasources/overview.ru.md index afe18246..d4880464 100644 --- a/content/documentation/admin/datasources/overview.ru.md +++ b/content/documentation/admin/datasources/overview.ru.md @@ -4,7 +4,7 @@ weight: 10 --- -Источники данных — механизм DDP, который позволяет синхронизировать информацию из внешних инфраструктурных систем (например, GitLab, либо Kubernetes) и преобразовывать её в параметры той или иной сущности. +Источники данных — механизм Deckhouse Development Platform (DDP), который позволяет синхронизировать информацию из внешних инфраструктурных систем (например, GitLab или Kubernetes) и преобразовывать её в параметры той или иной сущности. Также источники данных позволяют: @@ -109,20 +109,20 @@ metadata: ##### Настройка в интерфейсе -1. На вкладке **«Основная информация»** выберите ресурс, к которому будет привязан источник данных. -1. В диалоге редактирования источника данных откройте вкладку **«Правила»**. -1. В блоке «Правила обновления» нажмите кнопку **«Импортировать из спецификации»**. +1. На вкладке «Основная информация» выберите ресурс, к которому будет привязан источник данных. +1. В диалоге редактирования источника данных откройте вкладку «Правила». +1. В блоке «Правила обновления» нажмите кнопку «Импортировать из спецификации». ##### Шаги по настройке -1. **Загрузка данных** — выберите формат (автоопределение, JSON, YAML, OpenAPI 3.x, Swagger 2.0) и вставьте содержимое спецификации в поле «Данные». Если в спецификации несколько схем, на следующем шаге в поле «Выберите схему для импорта» можно выбрать схему для маппинга. -2. **Настройка маппинга** — в таблице отображаются столбцы «Путь в данных», «Тип в источнике», «Идентификатор параметра», «Название параметра», «Тип параметра». Можно редактировать идентификатор, название и тип параметра, отметить галочками строки для применения. Строки, для которых в ресурсе уже есть параметр с таким идентификатором или названием, помечаются меткой «Существует». -3. **Применение** — нажмите «Применить»: в блок «Правила обновления» источника данных добавятся сформированные правила. Новые параметры ресурса будут созданы при сохранении источника данных. +1. «Загрузка данных» — выберите формат (автоопределение, JSON, YAML, OpenAPI 3.x, Swagger 2.0) и вставьте содержимое спецификации в поле «Данные». Если в спецификации несколько схем, на следующем шаге в поле «Выберите схему для импорта» можно выбрать схему для маппинга. +1. «Настройка маппинга» — в таблице отображаются столбцы «Путь в данных», «Тип в источнике», «Идентификатор параметра», «Название параметра», «Тип параметра». Можно редактировать идентификатор, название и тип параметра, отметить галочками строки для применения. Строки, для которых в ресурсе уже есть параметр с таким идентификатором или названием, помечаются меткой «Существует». +1. «Применение» — нажмите «Применить»: в блок «Правила обновления» источника данных добавятся сформированные правила. Новые параметры ресурса будут созданы при сохранении источника данных. ##### Поведение системы при импорте -1. **Автосоздание параметров ресурса** — для полей спецификации, по которым в ресурсе ещё нет параметра, предлагаются новые параметры; они добавляются в ресурс при сохранении источника данных. -2. **Автозаполнение правил обновления** — по каждому выбранному полю создаётся правило: источник задаётся выражением [Go template](https://developer.hashicorp.com/nomad/docs/reference/go-template-syntax) по пути в данных (например, `{{ .metadata.name }}`), параметр — идентификатор параметра ресурса. После нажатия «Применить» эти правила появляются в блоке «Правила обновления» на вкладке «Правила» источника данных. +1. «Автосоздание параметров ресурса» — для полей спецификации, по которым в ресурсе ещё нет параметра, предлагаются новые параметры; они добавляются в ресурс при сохранении источника данных. +1. «Автозаполнение правил обновления» — по каждому выбранному полю создаётся правило: источник задаётся выражением [Go template](https://developer.hashicorp.com/nomad/docs/reference/go-template-syntax) по пути в данных (например, `{{ .metadata.name }}`), параметр — идентификатор параметра ресурса. После нажатия «Применить» эти правила появляются в блоке «Правила обновления» на вкладке «Правила» источника данных. ##### Поддерживаемые форматы @@ -189,7 +189,7 @@ metadata: При включении параметра «Удаление несуществующих сущностей» источник данных будет сравнивать список ресурсов, полученных из внешней инфраструктурной системы и список существующих сущностей ресурса. При обнаружении в DDP сущностей, которые отсутствуют в списке полученных, они будут удалены из DDP. -При включении параметра «Удаление только сущностей, созданных этим источником данных» источник данных будет дополнительно сравнивать, каким образом была создана сущность, которую необходимо удалить. Если сущность была создана этим источником данных, то она будет удалена, если нет, то источник данных перейдет к обработке следующей сущности в списке без удаления текущей. +При включении параметра «Удаление только сущностей, созданных этим источником данных» источник данных будет дополнительно сравнивать, каким образом была создана сущность, которую необходимо удалить. Если сущность была создана этим источником данных, то она будет удалена, если нет, то источник данных перейдёт к обработке следующей сущности в списке без удаления текущей. Поиск создателя (origin) сущности производится по двум полям в спецификации сущности: @@ -212,13 +212,13 @@ metadata: Записи в БД с полным логом запуска источника данных создаются независимо от значения параметра `datasources.logging.enabled`. {{< /alert >}} -## Системная учетная запись +## Системная учётная запись -При настройке источника данных необходимо выбрать системную учетную запись для запуска синхронизации. +При настройке источника данных необходимо выбрать системную учётную запись для запуска синхронизации. -Реквизиты данной учетной записи будут использоваться источником данных для доступа к опрашиваемой инфраструктурной системе. +Реквизиты данной учётной записи будут использоваться источником данных для доступа к опрашиваемой инфраструктурной системе. -Помимо системной учетной записи необходимо указание того, какие ее реквизиты будут использованы при запуске источника данных. Для этого в секции «Безопасность / Учетные данные» добавляются новые учетные данные с определенным идентификатором. +Помимо системной учётной записи необходимо указание того, какие ее реквизиты будут использованы при запуске источника данных. Для этого в секции «Безопасность / Учётные данные» добавляются новые учётные данные с определенным идентификатором. Значение данного идентификатора может быть подставлено в конфигурацию источника данных с использованием синтаксиса [Go template](https://developer.hashicorp.com/nomad/docs/reference/go-template-syntax). diff --git a/content/documentation/admin/datasources/types.ru.md b/content/documentation/admin/datasources/types.ru.md index 2f6dec7a..f42089d6 100644 --- a/content/documentation/admin/datasources/types.ru.md +++ b/content/documentation/admin/datasources/types.ru.md @@ -4,7 +4,7 @@ title: Типы источников данных ## DefectdojoProducts -Источник данных типа **DefectdojoProducts** возвращает список продуктов в Defectdojo. +Источник данных типа `DefectdojoProducts` возвращает список продуктов в Defectdojo. ### Авторизация @@ -16,7 +16,7 @@ title: Типы источников данных ### Конфигурация -* **URL** — URL DefectDojo в формате `https://example.com`. +* `URL` — URL DefectDojo в формате `https://example.com`. ### Параметры @@ -24,7 +24,7 @@ title: Типы источников данных ## GitlabGroups -Источник данных типа **GitlabGroups** возвращает список групп в GitLab. +Источник данных типа `GitlabGroups` возвращает список групп в GitLab. ### Авторизация @@ -36,7 +36,7 @@ title: Типы источников данных ### Конфигурация -* **URL** — URL GitLab в формате `https://gitlab.com`, без части `/api/v4`. +* `URL` — URL GitLab в формате `https://gitlab.com`, без части `/api/v4`. ### Параметры @@ -44,7 +44,7 @@ title: Типы источников данных ## GitlabProjects -Источник данных типа **GitlabProjects** возвращает список проектов в GitLab. +Источник данных типа `GitlabProjects` возвращает список проектов в GitLab. ### Авторизация @@ -54,15 +54,15 @@ title: Типы источников данных В зависимости от [конфигурации параметров](#gitlabprojectsparameters), платформа выполняет GET-запрос к API GitLab и возвращает соответствующую спецификацию. -Если значение параметра **all** равно `true`, выполняется GET-запрос по URL: `/api/v4/projects`. Платформа возвращает все доступные значения. [Спецификация ответа](https://docs.gitlab.com/api/projects/#list-all-projects). +Если значение параметра `all` равно `true`, выполняется GET-запрос по URL: `/api/v4/projects`. Платформа возвращает все доступные значения. [Спецификация ответа](https://docs.gitlab.com/api/projects/#list-all-projects). -Если значение параметра **all** равно `false`, выполняется GET-запрос по URL: `/api/v4/groups/:id/projects`. Платформа возвращает все доступные значения. [Спецификация ответа](https://docs.gitlab.com/api/projects/#list-all-projects). +Если значение параметра `all` равно `false`, выполняется GET-запрос по URL: `/api/v4/groups/:id/projects`. Платформа возвращает все доступные значения. [Спецификация ответа](https://docs.gitlab.com/api/projects/#list-all-projects). -Если значение параметра **tags** равно `true`, платформа дополнительно получает git-теги. Для получения git-тегов выполняется GET-запрос по URL: `/api/v4/projects/:id/repository/tags`. Платформа получает список всех git-тегов и расширяет [спецификацию ответа](https://docs.gitlab.com/api/projects/#list-all-projects) полем `ddp_repository_tags`, которое соответствует [спецификации ответа list-project-repository-tags](https://docs.gitlab.com/api/tags/#list-project-repository-tags). +Если значение параметра `tags` равно `true`, платформа дополнительно получает git-теги. Для получения git-тегов выполняется GET-запрос по URL: `/api/v4/projects/:id/repository/tags`. Платформа получает список всех git-тегов и расширяет [спецификацию ответа](https://docs.gitlab.com/api/projects/#list-all-projects) полем `ddp_repository_tags`, которое соответствует [спецификации ответа list-project-repository-tags](https://docs.gitlab.com/api/tags/#list-project-repository-tags). ### Конфигурация -* **URL** — URL GitLab в формате `https://gitlab.com`, без части `/api/v4`. +* `URL` — URL GitLab в формате `https://gitlab.com`, без части `/api/v4`. @@ -70,17 +70,17 @@ title: Типы источников данных |Название |Обязательность |Описание |Возможные значения |По умолчанию | |-----------------|--------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------|------------------------------------------------------------------------------| -|all |опционально |В явном виде указывает, что необходимо собирать репозитории всех групп, к которым есть доступ. |true, false |false | -|group_ids |Обязательно, если **all** в значении `false`|Источник данных будет собирать проекты групп с указанным ID. ID групп указываются через запятую. |Пример: 1001,1002 |\- | -|tags |опционально |Платформа дополнительно получает список всех git тегов и расширяет [спецификацию ответа](https://docs.gitlab.com/api/projects/#list-all-projects) полем `ddp_repository_tags`, которое соответствует [спецификации ответа list-project-repository-tags](https://docs.gitlab.com/api/tags/#list-project-repository-tags). |true, false |false | -|include_subgroups|опционально |Если указан параметр **group_ids**, то параметр **include_subgroups** определяет, собирать ли проекты подгрупп указанных групп. |true, false |false | -|tags_order_by |опционально |Соответствует спецификации [GitLab Tags API order_by](https://docs.gitlab.com/api/tags/#list-project-repository-tags) |[документация](https://docs.gitlab.com/api/tags/#list-project-repository-tags)|[документация](https://docs.gitlab.com/api/tags/#list-project-repository-tags)| -|tags_sort |опционально |Соответствует спецификации [GitLab Tags API sort](https://docs.gitlab.com/api/tags/#list-project-repository-tags) |[документация](https://docs.gitlab.com/api/tags/#list-project-repository-tags)|[документация](https://docs.gitlab.com/api/tags/#list-project-repository-tags)| -|tags_search |опционально |Соответствует спецификации [GitLab Tags API search](https://docs.gitlab.com/api/tags/#list-project-repository-tags) |[документация](https://docs.gitlab.com/api/tags/#list-project-repository-tags)|[документация](https://docs.gitlab.com/api/tags/#list-project-repository-tags)| +|all |Опционально |В явном виде указывает, что необходимо собирать репозитории всех групп, к которым есть доступ |true, false |false | +|group_ids |Обязательно, если `all` в значении `false`|Источник данных будет собирать проекты групп с указанным ID. ID групп указываются через запятую |Пример: 1001,1002 |\- | +|tags |Опционально |Платформа дополнительно получает список всех git тегов и расширяет [спецификацию ответа](https://docs.gitlab.com/api/projects/#list-all-projects) полем `ddp_repository_tags`, которое соответствует [спецификации ответа list-project-repository-tags](https://docs.gitlab.com/api/tags/#list-project-repository-tags) |true, false |false | +|include_subgroups|Опционально |Если указан параметр `group_ids`, то параметр `include_subgroups` определяет, собирать ли проекты подгрупп указанных групп |true, false |false | +|tags_order_by |Опционально |Поле для сортировки тегов. Описание параметра — в [GitLab Tags API](https://docs.gitlab.com/api/tags/#list-project-repository-tags) |`updated`, `name`, `version` |`updated` | +|tags_sort |Опционально |Направление сортировки тегов. Описание параметра — в [GitLab Tags API](https://docs.gitlab.com/api/tags/#list-project-repository-tags) |`asc`, `desc` |`desc` | +|tags_search |Опционально |Строка для поиска тегов по имени. Описание параметра — в [GitLab Tags API](https://docs.gitlab.com/api/tags/#list-project-repository-tags) |Строка |\- | ## HarborArtifacts -Источник данных типа **HarborArtifacts** собирает информацию о всех артефактах в Harbor. +Источник данных типа `HarborArtifacts` собирает информацию о всех артефактах в Harbor. ### Авторизация @@ -92,7 +92,7 @@ title: Типы источников данных ### Конфигурация -* **URL** — URL Harbor в формате `https://example.com`. +* `URL` — URL Harbor в формате `https://example.com`. ### Параметры @@ -100,7 +100,7 @@ title: Типы источников данных ## HarborProjects -Источник данных типа **HarborProjects** собирает информацию о всех проектах в Harbor. +Источник данных типа `HarborProjects` собирает информацию о всех проектах в Harbor. ### Авторизация @@ -112,7 +112,7 @@ title: Типы источников данных ### Конфигурация -* **URL** — URL Harbor в формате `https://example.com`. +* `URL` — URL Harbor в формате `https://example.com`. ### Параметры @@ -120,7 +120,7 @@ title: Типы источников данных ## HarborRepositories -Источник данных типа **HarborRepositories** собирает информацию о всех репозиториях в Harbor. +Источник данных типа `HarborRepositories` собирает информацию о всех репозиториях в Harbor. ### Авторизация @@ -132,7 +132,7 @@ title: Типы источников данных ### Конфигурация -* **URL** — URL Harbor в формате `https://example.com`. +* `URL` — URL Harbor в формате `https://example.com`. ### Параметры @@ -140,7 +140,7 @@ title: Типы источников данных ## HarborTags -Источник данных типа **HarborTags** собирает информацию о всех тегах у артефактов в Harbor. +Источник данных типа `HarborTags` собирает информацию о всех тегах у артефактов в Harbor. ### Авторизация @@ -152,7 +152,7 @@ title: Типы источников данных ### Конфигурация -* **URL** — URL Harbor в формате `https://example.com`. +* `URL` — URL Harbor в формате `https://example.com`. ### Параметры @@ -160,7 +160,7 @@ title: Типы источников данных ## HelmReleases -Источник данных типа **HelmReleases** возвращает список всех HelmReleases в кластере Kubernetes. +Источник данных типа `HelmReleases` возвращает список всех HelmReleases в кластере Kubernetes. ### Авторизация @@ -208,7 +208,7 @@ title: Типы источников данных } // ... другие шаблоны. ], - "values": "object", // Объект с доступными настройками Helm чарта. + "values": "object", // Объект с доступными настройками Helm-чарта. "schema": "null", // Схема (может быть null). "files": [ // Массив объектов с файлами. { @@ -232,7 +232,7 @@ title: Типы источников данных }, "manifest": "string", // Отрендеренные манифесты. "version": "integer", // Версия HelmRelease. - "namespace": "string" // Пространство имен, где развернут релиз. + "namespace": "string" // Неймспейс, где развёрнут релиз. }, // ... другие ресурсы типа HelmRelease. ] @@ -241,7 +241,7 @@ title: Типы источников данных ### Конфигурация -* **URL** — URL Kubernetes API в формате `https://api.example.com`. +* `URL` — URL Kubernetes API в формате `https://api.example.com`. ### Параметры @@ -249,7 +249,7 @@ title: Типы источников данных ## KafkaAcls -Источник данных типа **KafkaAcls** собирает информацию о доступных ACL. +Источник данных типа `KafkaAcls` собирает информацию о доступных ACL. ### Авторизация @@ -263,12 +263,12 @@ title: Типы источников данных [ { "Cluster": "string", // Название кластера Kafka. - "ResourceType": "string", // Тип ресурса (TOPIC, GROUP и т.д.). + "ResourceType": "string", // Тип ресурса (TOPIC, GROUP и т. д.). "ResourceName": "string", // Название ресурса. - "PatternType": "string", // Тип паттерна (LITERAL, PREFIXED и т.д.). + "PatternType": "string", // Тип паттерна (LITERAL, PREFIXED и т. д.). "Principal": "string", // Principal пользователя (например: "User:Alice"). "Host": "string", // Хост (обычно "*" для любого хоста). - "Operation": "string", // Операция (READ, WRITE, DESCRIBE и т.д.). + "Operation": "string", // Операция (READ, WRITE, DESCRIBE и т. д.). "PermissionType": "string" // Тип разрешения (ALLOW, DENY). }, // ... другие записи ACL. @@ -277,20 +277,20 @@ title: Типы источников данных ### Конфигурация -* **URL** — URL Kafka в формате `example.com`. +* `URL` — URL Kafka в формате `example.com`. ### Параметры |Название |Обязательность | Описание |Возможные значения | |-----------------|-----------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------| -|SecurityProtocol | **обязательно** | Протокол для подключения к Kafka — [в документации Kafka](https://kafka.apache.org/documentation/#adminclientconfigs_security.protocol) | PLAINTEXT, SASL_PLAINTEXT, SASL_SSL | -|SaslMechanism | опционально | Механизм аутентификации, который будет использовать SASL. Обязателен при использовании протокола SASL_PLAINTEXT или SASL_SSL — [в документации Kafka](https://kafka.apache.org/documentation/#security_sasl_mechanism) | PLAIN, SCRAM-SHA-256, SCRAM-SHA-512 | -|User | **обязательно** | Имя пользователя для подключения к Kafka | - | -|Pass | **обязательно** | Пароль пользователя для подключения к Kafka | - | +|SecurityProtocol | Обязательно | Протокол для подключения к Kafka — [в документации Kafka](https://kafka.apache.org/documentation/#adminclientconfigs_security.protocol) | PLAINTEXT, SASL_PLAINTEXT, SASL_SSL | +|SaslMechanism | Опционально | Механизм аутентификации, который будет использовать SASL. Обязателен при использовании протокола SASL_PLAINTEXT или SASL_SSL — [в документации Kafka](https://kafka.apache.org/documentation/#security_sasl_mechanism) | PLAIN, SCRAM-SHA-256, SCRAM-SHA-512 | +|User | Обязательно | Имя пользователя для подключения к Kafka | - | +|Pass | Обязательно | Пароль пользователя для подключения к Kafka | - | ## KafkaBrokers -Источник данных типа **KafkaBrokers** собирает информацию о доступных брокерах. +Источник данных типа `KafkaBrokers` собирает информацию о доступных брокерах. ### Авторизация @@ -335,20 +335,20 @@ title: Типы источников данных ### Конфигурация -* **URL** — URL Kafka в формате `example.com`. +* `URL` — URL Kafka в формате `example.com`. ### Параметры |Название |Обязательность | Описание |Возможные значения | |-----------------|-----------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------| -|SecurityProtocol | **обязательно** | Протокол для подключения к Kafka — [в документации Kafka](https://kafka.apache.org/documentation/#adminclientconfigs_security.protocol) | PLAINTEXT, SASL_PLAINTEXT, SASL_SSL | -|SaslMechanism | опционально | Механизм аутентификации, который будет использовать SASL. Обязателен при использовании протокола SASL_PLAINTEXT или SASL_SSL — [в документации Kafka](https://kafka.apache.org/documentation/#security_sasl_mechanism) | PLAIN, SCRAM-SHA-256, SCRAM-SHA-512 | -|User | **обязательно** | Имя пользователя для подключения к Kafka | - | -|Pass | **обязательно** | Пароль пользователя для подключения к Kafka | - | +|SecurityProtocol | Обязательно | Протокол для подключения к Kafka — [в документации Kafka](https://kafka.apache.org/documentation/#adminclientconfigs_security.protocol) | PLAINTEXT, SASL_PLAINTEXT, SASL_SSL | +|SaslMechanism | Опционально | Механизм аутентификации, который будет использовать SASL. Обязателен при использовании протокола SASL_PLAINTEXT или SASL_SSL — [в документации Kafka](https://kafka.apache.org/documentation/#security_sasl_mechanism) | PLAIN, SCRAM-SHA-256, SCRAM-SHA-512 | +|User | Обязательно | Имя пользователя для подключения к Kafka | - | +|Pass | Обязательно | Пароль пользователя для подключения к Kafka | - | ## KafkaTopics -Источник данных типа **KafkaTopics** собирает информацию о доступных топиках в Kafka. +Источник данных типа `KafkaTopics` собирает информацию о доступных топиках в Kafka. ### Авторизация @@ -377,20 +377,20 @@ title: Типы источников данных ### Конфигурация -* **URL** — URL Kafka в формате `example.com`. +* `URL` — URL Kafka в формате `example.com`. ### Параметры |Название |Обязательность | Описание |Возможные значения | |-----------------|-----------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------| -|SecurityProtocol | **обязательно** | Протокол для подключения к Kafka — [в документации Kafka](https://kafka.apache.org/documentation/#adminclientconfigs_security.protocol) | PLAINTEXT, SASL_PLAINTEXT, SASL_SSL | -|SaslMechanism | опционально | Механизм аутентификации, который будет использовать SASL. Обязателен при использовании протокола SASL_PLAINTEXT или SASL_SSL — [в документации Kafka](https://kafka.apache.org/documentation/#security_sasl_mechanism) | PLAIN, SCRAM-SHA-256, SCRAM-SHA-512 | -|User | **обязательно** | Имя пользователя для подключения к Kafka | - | -|Pass | **обязательно** | Пароль пользователя для подключения к Kafka | - | +|SecurityProtocol | Обязательно | Протокол для подключения к Kafka — [в документации Kafka](https://kafka.apache.org/documentation/#adminclientconfigs_security.protocol) | PLAINTEXT, SASL_PLAINTEXT, SASL_SSL | +|SaslMechanism | Опционально | Механизм аутентификации, который будет использовать SASL. Обязателен при использовании протокола SASL_PLAINTEXT или SASL_SSL — [в документации Kafka](https://kafka.apache.org/documentation/#security_sasl_mechanism) | PLAIN, SCRAM-SHA-256, SCRAM-SHA-512 | +|User | Обязательно | Имя пользователя для подключения к Kafka | - | +|Pass | Обязательно | Пароль пользователя для подключения к Kafka | - | ## KubernetesResources -Источник данных типа **KubernetesResources** возвращает список ресурсов Kubernetes. Тип возвращаемых ресурсов задается через параметры источника данных. Поддерживаются как встроенные в Kubernetes типы ресурсов, так и любые кастомные ресурсы. +Источник данных типа `KubernetesResources` возвращает список ресурсов Kubernetes. Тип возвращаемых ресурсов задаётся через параметры источника данных. Поддерживаются как встроенные в Kubernetes типы ресурсов, так и любые кастомные ресурсы. ### Авторизация @@ -400,11 +400,11 @@ title: Типы источников данных Спецификация ответа зависит от типа ресурса, который планируется получить. Для получения точной информации необходимо обратиться к документации. Для встроенных в Kubernetes ресурсов доступна [официальная документация](https://kubernetes.io/docs/reference/kubernetes-api/). -В случае отсутствия возможности обратиться к документации, можно получить описание спецификации с помощью утилиты `kubectl`. +При отсутствии возможности обратиться к документации можно получить описание спецификации с помощью команды `d8 k explain`. Пример для deployment: -`kubectl explain deployment --recursive` +`d8 k explain deployment --recursive` Примерный вывод: @@ -429,17 +429,17 @@ FIELDS: ### Конфигурация -* **URL** — URL Kubernetes API в формате `https://api.example.com`. +* `URL` — URL Kubernetes API в формате `https://api.example.com`. ### Параметры |Название |Обязательность | Описание |Возможные значения | |------------|---------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------| -|apiGroup |опционально | API группа ресурса. Для ресурсов в core API группе поле не задается. |[См. определение требуемых Group и Version](#определение-требуемых-group-и-version)| -|version |**обязательно**| Версия API ресурса. |[См. определение требуемых Group и Version](#определение-требуемых-group-и-version)| -|isNamespaced|**обязательно**| Принадлежность ресурса неймспейсам. Проверить принадлежность можно с помощью команды `kubectl api-resources` |true, false | -|namespace |опционально | Пространство имен, из которого будут собираться ресурсы. Если не указан, ресурсы будут собираться из всех пространств имен. Значение параметра учитывается только если значение **isNamespaced** равно `true` | | -|resource |**обязательно**| Название ресурса. Указывается маленькими буквами во множественном числе, как в поле NAME вывода команды `kubectl api-resources`. | | +|apiGroup |Опционально | API-группа ресурса. Для ресурсов в core API-группе поле не задаётся |[См. определение требуемых Group и Version](#определение-требуемых-group-и-version)| +|version |Обязательно| Версия API ресурса |[См. определение требуемых Group и Version](#определение-требуемых-group-и-version)| +|isNamespaced|Обязательно| Принадлежность ресурса неймспейсам. Проверить принадлежность можно с помощью команды `d8 k api-resources` |true, false | +|namespace |Опционально | Неймспейс, из которого будут собираться ресурсы. Если не указан, ресурсы будут собираться из всех неймспейсов. Значение параметра учитывается, только если значение `isNamespaced` равно `true` | | +|resource |Обязательно| Название ресурса. Указывается маленькими буквами во множественном числе, как в поле NAME вывода команды `d8 k api-resources` | | ### Примеры @@ -460,7 +460,7 @@ isNamespaced: true resource: pods ``` -Собрать все поды Kubernetes-кластера в namespace `d8-development-platform`: +Собрать все поды Kubernetes-кластера в неймспейсе `d8-development-platform`: ```yaml version: v1 @@ -469,7 +469,7 @@ resource: pods namespace: d8-development-platform ``` -Собрать все пространства имен Kubernetes-кластера: +Собрать все неймспейсы Kubernetes-кластера: ```yaml version: v1 @@ -490,12 +490,12 @@ resource: modulereleases Каждому типу ресурса соответствует своя версия и группа. Полный список API-ресурсов с их группами и версиями — в [документации Kubernetes](https://kubernetes.io/docs/reference/kubernetes-api/). -Если неизвестно, какие требуются Group и Version, можно попробовать подставить актуальные значения. Есть несколько вариантов, как их посмотреть, например с помощью утилиты kubectl: команда `kubectl explain` показывает `version` и `apiGroup` для ресурса. +Если неизвестно, какие требуются Group и Version, можно попробовать подставить актуальные значения. Есть несколько вариантов, как их посмотреть, например с помощью утилиты `d8 k`: команда `d8 k explain` показывает `version` и `apiGroup` для ресурса. Пример: ```bash -kubectl explain deployment +d8 k explain deployment ``` Вывод: @@ -514,7 +514,7 @@ FIELDS: ## NexusArtifacts -Источник данных типа **NexusArtifacts** возвращает список артефактов в Nexus. +Источник данных типа `NexusArtifacts` возвращает список артефактов в Nexus. ### Авторизация @@ -526,7 +526,7 @@ FIELDS: ### Конфигурация -* **URL** — URL Nexus в формате `https://example.com`. +* `URL` — URL Nexus в формате `https://example.com`. ### Параметры @@ -534,7 +534,7 @@ FIELDS: ## NexusRepositories -Источник данных типа **NexusRepositories** возвращает список репозиториев в Nexus. +Источник данных типа `NexusRepositories` возвращает список репозиториев в Nexus. ### Авторизация @@ -546,7 +546,7 @@ FIELDS: ### Конфигурация -* **URL** — URL Nexus в формате `https://example.com`. +* `URL` — URL Nexus в формате `https://example.com`. ### Параметры @@ -554,7 +554,7 @@ FIELDS: ## PrometheusMetrics -Источник данных типа **PrometheusMetrics** возвращает результат запроса PromQL в Prometheus. +Источник данных типа `PrometheusMetrics` возвращает результат запроса PromQL в Prometheus. ### Авторизация @@ -566,8 +566,8 @@ FIELDS: ### Конфигурация -* **URL** — URL Prometheus API в формате `https://example.com/api/v1/query`. -* **Query** — запрос [в формате PromQL](https://prometheus.io/docs/prometheus/latest/querying/basics/), на основе которого будет сформирован ответ. +* `URL` — URL Prometheus API в формате `https://example.com/api/v1/query`. +* «Query» — запрос [в формате PromQL](https://prometheus.io/docs/prometheus/latest/querying/basics/), на основе которого будет сформирован ответ. ### Параметры @@ -575,7 +575,7 @@ FIELDS: ## SonarqubeProjects -Источник данных типа **SonarqubeProjects** возвращает список проектов в SonarQube. +Источник данных типа `SonarqubeProjects` возвращает список проектов в SonarQube. ### Авторизация @@ -587,7 +587,7 @@ FIELDS: ### Конфигурация -* **URL** — URL SonarQube в формате `https://example.com`. +* `URL` — URL SonarQube в формате `https://example.com`. ### Параметры @@ -595,25 +595,25 @@ FIELDS: ## GenericAPI -Источник данных типа **GenericAPI** позволяет подключаться к любому REST API и получать данные в формате JSON. Поддерживаются различные типы пагинации и настраиваемые параметры запроса. +Источник данных типа `GenericAPI` позволяет подключаться к любому REST API и получать данные в формате JSON. Поддерживаются различные типы пагинации и настраиваемые параметры запроса. ### Авторизация -GenericAPI поддерживает любые типы аутентификации через настройку заголовков HTTP. Наиболее распространенные способы: +GenericAPI поддерживает любые типы аутентификации через настройку заголовков HTTP. Наиболее распространённые способы: -**Bearer Token:** +Bearer Token: ```sh Authorization: Bearer <токен> ``` -**Basic Authentication:** +Basic Authentication: ```sh Authorization: Basic ``` -**API Key:** +API Key: ```sh X-API-Key: <ключ> @@ -623,13 +623,13 @@ X-API-Key: <ключ> * `URL` — базовый URL API в формате `https://api.example.com`. * `Method` — HTTP-метод (GET, POST, PUT, PATCH, DELETE). -* `Query` — дополнительные query параметры (например, для фильтрации или поиска). +* `Query` — дополнительные query-параметры (например, для фильтрации или поиска). ### Параметры | Название | Обязательность | Описание | Возможные значения | Примеры | По умолчанию | |---------------------|----------------|-------------------------------------------------------------------------------------------|---------------------------------------------------|---------------------------------------|--------------| -| `paginationType` | Опционально | Тип пагинации для обработки больших объемов данных | `none`, `offset`, `cursor`, `page`, `link_header` | `none` | `none` | +| `paginationType` | Опционально | Тип пагинации для обработки больших объёмов данных | `none`, `offset`, `cursor`, `page`, `link_header` | `none` | `none` | | `path` | Опционально | Путь к эндпоинту API, который будет добавлен к базовому URL | Любая строка, начинающаяся с `/` | `/api/v1/users`, `/projects` | `""` | | `dataPath` | Опционально | Путь к данным в ответе (цепочка ключей через точку) | Любая строка | `data`, `results.items`, `.` | `.` | | `responseFormat` | Опционально | Формат ответа | `array`, `map` | `array`, `map` | `array` | @@ -673,9 +673,9 @@ X-API-Key: <ключ> } ``` -Перед обработкой ответ с `responseFormat: map` преобразуется в массив с учетом значения параметра `mapKeyField`. +Перед обработкой ответ с `responseFormat: map` преобразуется в массив с учётом значения параметра `mapKeyField`. -При **`mapKeyField: example`** в обработку передаётся массив с добавленным полем `example` со значением, взятым из ключа объекта: +При `mapKeyField: example` в обработку передаётся массив с добавленным полем `example` со значением, взятым из ключа объекта: ```json [ @@ -684,7 +684,7 @@ X-API-Key: <ключ> ] ``` -Если **`mapKeyField`** не задан (пустая строка), в обработку передаётся массив без добавления нового поля: +Если `mapKeyField` не задан (пустая строка), в обработку передаётся массив без добавления нового поля: ```json [ diff --git a/content/documentation/admin/examples/service-autoupdates.ru.md b/content/documentation/admin/examples/service-autoupdates.ru.md index 7ef2a9d2..400d050a 100644 --- a/content/documentation/admin/examples/service-autoupdates.ru.md +++ b/content/documentation/admin/examples/service-autoupdates.ru.md @@ -6,111 +6,119 @@ title: Автоматическое обновление сервисов ## Компоненты системы и их назначение -Для реализации автоматического обновления сервисов используются следующие компоненты платформы DDP: +Для реализации автоматического обновления сервисов используются следующие компоненты Deckhouse Development Platform (DDP): -- Ресурс: +- Ресурсы — это элементы модели данных каталога DDP, которые определяют структуру хранения информации. Каждый ресурс может содержать параметры для хранения метаданных сущностей, а также связи с другими ресурсами для отображения зависимостей. - - В рамках инструкции используются два ресурса: + - В рамках инструкции используются два ресурса (названия могут отличаться, в зависимости от ваших настроек): - - **«Шаблоны»** — хранит информацию о шаблонных репозиториях (URL и ID репозитория, последний тег версии). - - **«Сервисы»** — хранит информацию о созданных сервисах (URL и ID репозитория, переменные шаблонизации, ветка по умолчанию). + - «Шаблоны» — хранит информацию о шаблонных репозиториях (URL и ID репозитория, последний тег версии). + - «Сервисы» — хранит информацию о созданных сервисах (URL и ID репозитория, переменные шаблонизации, ветка по умолчанию). - > Названия могут отличаться, в зависимости от ваших настроек. + {{< alert level="info" >}} + Названия могут отличаться, в зависимости от ваших настроек. + {{< /alert >}} - Связь: - - Устанавливает связь между шаблоном и созданными из него сервисами. + - Устанавливает зависимость между ресурсами и обеспечивают возможность автоматического нахождения всех сервисов, связанных с конкретным шаблоном. -- Источник данных: +- [Источник данных](../datasources/overview/) — механизм DDP, который позволяет синхронизировать информацию из внешних инфраструктурных систем (например, GitLab) в каталог платформы. Источники данных периодически опрашивают внешние системы, получают актуальную информацию и обновляют соответствующие сущности в каталоге: - Синхронизирует информацию о шаблонных репозиториях из GitLab. - Обновляет список тегов для каждого шаблона. - Автоматически обновляет параметр «Последний тег» в сущностях ресурса «Шаблоны». -- Действие: +- Действие — механизм DDP, который позволяет пользователям платформы взаимодействовать с внешними инфраструктурными сервисами через API. Действия могут создавать проекты в GitLab, создавать секреты в системах управления секретами, развёртывать приложения и выполнять другие операции. - - В данной настройке используются три действия: + - В данной настройке используются три действия (названия могут отличаться, в зависимости от ваших настроек): - - создает новый проект в GitLab для размещения сервиса. + - создаёт новый проект в GitLab для размещения сервиса. - клонирует код из шаблонного репозитория в новый репозиторий сервиса с применением переменных шаблонизации. - - создает Merge Request в репозитории сервиса с изменениями из новой версии шаблона. + - создаёт Merge Request в репозитории сервиса с изменениями из новой версии шаблона. - > Названия могут отличаться, в зависимости от ваших настроек. + {{< alert level="info" >}} + Названия могут отличаться, в зависимости от ваших настроек. + {{< /alert >}} -- Процесс: +- Процесс — механизм автоматизации сложных бизнес-процессов, который позволяет создавать визуальные схемы выполнения действий с поддержкой последовательного или параллельного выполнения. Процессы объединяют несколько действий в единую цепочку выполнения. - В данной настройке процесс объединяет два действия: - Последовательно запускает создание проекта в GitLab, а затем создание репозитория из шаблона. - Обеспечивает интерфейс для пользователя при создании сервиса из шаблона. -- Автоматизация +- Автоматизация — механизм реагирования платформы на изменения спецификации сущностей. Автоматизации подписываются на события обновления сущностей ресурсов по определённым правилам (триггерам) и запускают выполнение действий, процессов или синхронизацию источников данных. - Отслеживает изменения параметра «Последний тег» в сущностях ресурса «Шаблоны». - При обнаружении нового тега автоматически запускает действие «Обновление сервиса из шаблона» (название зависит от ваших настроек) для всех связанных сервисов. - - Создает Merge Request в каждом репозитории сервиса с изменениями из новой версии шаблона. + - Создаёт Merge Request в каждом репозитории сервиса с изменениями из новой версии шаблона. ![workflow](../images/service-autoupdates/workflow.png) -**Последовательность работы:** +Последовательность работы: -1. **Источник данных** периодически синхронизирует информацию о шаблонах из GitLab и обновляет параметр с идентификатором `repository_last_tag` (может отличаться в зависимости от ваших настроек) в сущностях ресурса «Шаблоны». -1. **Автоматизация** отслеживает изменения параметра с идентификатором `repository_last_tag` (может отличаться в зависимости от ваших настроек) через триггеры. -1. При обнаружении нового тега **автоматизация** запускает действие «Обновление сервиса из шаблона» (название может отличаться в зависимости от ваших настроек) для всех сервисов, связанных с обновленным шаблоном. -1. **Действие** создает Merge Request в репозитории каждого сервиса, включающий изменения из новой версии шаблона. +1. «Источник данных» периодически синхронизирует информацию о шаблонах из GitLab и обновляет параметр с идентификатором `repository_last_tag` (может отличаться в зависимости от ваших настроек) в сущностях ресурса «Шаблоны». +2. «Автоматизация» отслеживает изменения параметра с идентификатором `repository_last_tag` (может отличаться в зависимости от ваших настроек) через триггеры. +3. При обнаружении нового тега автоматизация запускает действие «Обновление сервиса из шаблона» (название может отличаться в зависимости от ваших настроек) для всех сервисов, связанных с обновлённым шаблоном. +4. «Действие» создаёт Merge Request в репозитории каждого сервиса, включающий изменения из новой версии шаблона. Таким образом, при добавлении нового тега в шаблонный репозиторий все связанные сервисы автоматически получают предложение обновиться через Merge Request. ## Настройка компонентов -В следующих разделах описывается конфигурация каждого компонента системы. При настройке учитывайте, что названия ресурсов и параметров могут отличаться от приведенных в инструкции. В этом случае необходимо обеспечить согласованность названий между всеми компонентами: если вы используете другие названия параметров в ресурсах, их нужно использовать во всех действиях, автоматизациях и источниках данных, которые ссылаются на эти параметры. +В следующих разделах описывается конфигурация каждого компонента системы. При настройке учитывайте, что названия ресурсов и параметров могут отличаться от приведённых в инструкции. В этом случае необходимо обеспечить согласованность названий между всеми компонентами: если вы используете другие названия параметров в ресурсах, их нужно использовать во всех действиях, автоматизациях и источниках данных, которые ссылаются на эти параметры. Будет описано: 1. Требуемые ресурсы в DDP и их параметры. -2. Требуемые [связи](../../user/catalog/#связи-между-ресурсами) между ресурсами. -3. Требуемые [источники данных](../datasources/overview/) для получения информации о новых версиях шаблонов. -4. Требуемые [действия](../actions/overview/) для создания сервиса из шаблона. -5. Требуемый процесс для реализации последовательного запуска цепочки [действий](../actions/overview/). -6. Требуемая [автоматизация](../automations) для реализации следующей функциональности: - - автоматическая проверка платформой DDP наличия новой версии шаблона, +1. Требуемые [связи](../../user/catalog/#связи-между-ресурсами) между ресурсами. +1. Требуемые [источники данных](../datasources/overview/) для получения информации о новых версиях шаблонов. +1. Требуемые [действия](../actions/overview/) для создания сервиса из шаблона. +1. Требуемый процесс для реализации последовательного запуска цепочки [действий](../actions/overview/). +1. Требуемая [автоматизация](../automations) для реализации следующей функциональности: + - автоматическая проверка DDP наличия новой версии шаблона; - автоматическое создание в сервисах, созданных из шаблона, Merge Request с изменениями из новой версии. ## Создание ресурсов и связи -> **Ресурсы** — это элементы модели данных каталога DDP, которые определяют структуру хранения информации. Каждый ресурс может содержать параметры для хранения метаданных сущностей, а также связи с другими ресурсами для отображения зависимостей. +«Ресурсы» — это элементы модели данных каталога DDP, которые определяют структуру хранения информации. Каждый ресурс может содержать параметры для хранения метаданных сущностей, а также связи с другими ресурсами для отображения зависимостей. ### Ресурс «Шаблоны» -У вас должен быть создан ресурс для хранения информации о шаблонных репозиториях. В рамках данной инструкции он назван `Шаблоны`, однако вы можете использовать любое удобное для вас название. Если ресурса еще нет, [создайте его](#создание-ресурса). +У вас должен быть создан ресурс для хранения информации о шаблонных репозиториях. В рамках данной инструкции он назван «Шаблоны», однако вы можете использовать любое удобное для вас название. Если ресурса ещё нет, [создайте его](#создание-ресурса). Ресурс должен содержать следующие параметры для хранения данных о шаблонных репозиториях: -- **Параметр «URL»** типа URL — используется для хранения URL-адреса репозитория шаблона в GitLab. Этот параметр необходим для действий, которые работают с репозиторием шаблона. +- Параметр «URL» типа URL — используется для хранения URL-адреса репозитория шаблона в GitLab. Этот параметр необходим для действий, которые работают с репозиторием шаблона. -- **Параметр «ID репозитория»** типа Number — хранит внутренний ID репозитория в GitLab. Используется для действий, которые требуют указания ID проекта GitLab. +- Параметр «ID репозитория» типа Number — хранит внутренний ID репозитория в GitLab. Используется для действий, которые требуют указания ID проекта GitLab. -- **Параметр «Последний тег»** типа String — содержит название последнего тега (версии) шаблона. Этот параметр используется автоматизацией для отслеживания появления новых версий шаблона. При каждом обновлении этого параметра источником данных автоматизация проверяет изменение и запускает обновление связанных сервисов. +- Параметр «Последний тег» типа String — содержит название последнего тега (версии) шаблона. Этот параметр используется автоматизацией для отслеживания появления новых версий шаблона. При каждом обновлении этого параметра источником данных автоматизация проверяет изменение и запускает обновление связанных сервисов. -**Обратите внимание:** убедитесь, что идентификаторы параметров корректно указаны во всех действиях, автоматизациях и источниках данных, которые ссылаются на эти параметры. +{{< alert level="warning" >}} +Убедитесь, что идентификаторы параметров корректно указаны во всех действиях, автоматизациях и источниках данных, которые ссылаются на эти параметры. +{{< /alert >}} Если параметры отсутствуют, откройте ресурс на редактирование и добавьте их на вкладке «Параметры» ресурса, нажав кнопку «Добавить параметр». ### Ресурс «Сервисы» -У вас должен быть создан второй ресурс для хранения информации о созданных сервисах. В рамках инструкции он называется `Сервисы`, но вы можете выбрать любое удобное для вас название. Если ресурса еще нет, [создайте его](#создание-ресурса). +У вас должен быть создан второй ресурс для хранения информации о созданных сервисах. В рамках инструкции он называется «Сервисы», но вы можете выбрать любое удобное для вас название. Если ресурса ещё нет, [создайте его](#создание-ресурса). Ресурс должен содержать следующие параметры для хранения метаданных о созданных сервисах: -- **Параметр «URL»** типа URL — ссылка на репозиторий сервиса в GitLab. Используется действиями для работы с репозиторием сервиса. +- Параметр «URL» типа URL — ссылка на репозиторий сервиса в GitLab. Используется действиями для работы с репозиторием сервиса. -- **Параметр «ID репозитория»** типа Number — внутренний ID репозитория в GitLab. Необходим для действий, которые требуют указания ID проекта GitLab. +- Параметр «ID репозитория» типа Number — внутренний ID репозитория в GitLab. Необходим для действий, которые требуют указания ID проекта GitLab. -- **Параметр «Переменные использованные при шаблонизации»** типа YAML — содержит переменные, которые были применены при клонировании кода из шаблона в сервис. Эти переменные необходимы при обновлении сервиса из шаблона, так как они должны быть применены повторно для корректного рендеринга новых изменений из шаблона. +- Параметр «Переменные использованные при шаблонизации» типа YAML — содержит переменные, которые были применены при клонировании кода из шаблона в сервис. Эти переменные необходимы при обновлении сервиса из шаблона, так как они должны быть применены повторно для корректного рендеринга новых изменений из шаблона. -- **Параметр «Ветка по умолчанию»** типа String — название основной ветки репозитория (например, `main` или `master`). Используется действием обновления сервиса для определения целевой ветки Merge Request. +- Параметр «Ветка по умолчанию» типа String — название основной ветки репозитория (например, `main` или `master`). Используется действием обновления сервиса для определения целевой ветки Merge Request. -**Обратите внимание:** убедитесь, что идентификаторы параметров корректно указаны во всех действиях, автоматизациях и источниках данных, которые ссылаются на эти параметры. +{{< alert level="warning" >}} +Убедитесь, что идентификаторы параметров корректно указаны во всех действиях, автоматизациях и источниках данных, которые ссылаются на эти параметры. +{{< /alert >}} Если параметры отсутствуют, откройте ресурс на редактирование и добавьте их на вкладке «Параметры» ресурса, нажав кнопку «Добавить параметр». @@ -120,23 +128,23 @@ title: Автоматическое обновление сервисов Откроется окно по созданию нового ресурса с различными вкладками. -**Основная информация:** +Основная информация: Заполните следующие поля на вкладке «Основная информация»: -- **Название**: [Укажите название ресурса]. +- «Название»: [Укажите название ресурса]. -- **Владелец**: [Укажите владельца]. +- «Владелец»: [Укажите владельца]. -- **Команда владелец**: [Укажите команду владелец]. +- «Команда владелец»: [Укажите команду владелец]. -**Параметры:** +Параметры: Перейдите на вкладку «Параметры» и добавьте требуемые параметры ресурса. Для добавления нового параметра нажмите кнопку «Добавить параметр». Пример требуемых параметров: -**Шаблоны:** +Шаблоны: | Название | Идентификатор | Описание | Тип | |----------------|---------------------|-------------------------------------------|--------| @@ -144,7 +152,7 @@ title: Автоматическое обновление сервисов | ID репозитория | project_id | Внутренний ID репозитория в GitLab | Number | | Последний тег | repository_last_tag | Последний созданный тег в git репозитории | String | -**Сервисы:** +Сервисы: | Название | Идентификатор | Описание | Тип | |--------------------------------------------|---------------------|----------------------------------------------------------------|--------| @@ -155,15 +163,13 @@ title: Автоматическое обновление сервисов ### Связь -> **Связи** позволяют установить зависимость между ресурсами и обеспечивают возможность автоматического нахождения всех сервисов, связанных с конкретным шаблоном. - -У вас должна быть настроена связь, которая отражает зависимость между шаблонами и созданными из них сервисами. Если связи еще нет, [создайте её](#создание-связи). +У вас должна быть настроена связь, которая отражает зависимость между шаблонами и созданными из них сервисами. Если связи ещё нет, [создайте её](#создание-связи). Связь должна быть настроена следующим образом: -- **Родительский ресурс**: выбран ресурс, хранящий информацию о шаблонах. +- «Родительский ресурс»: выбран ресурс, хранящий информацию о шаблонах. -- **Дочерний ресурс**: выбран ресурс, хранящий информацию о сервисах. +- «Дочерний ресурс»: выбран ресурс, хранящий информацию о сервисах. ### Создание связи @@ -174,30 +180,28 @@ title: Автоматическое обновление сервисов | Параметр | Значение | |---------------------|------------------------------------------------------| | Название | [Введите название связи, например `Шаблоны-Сервисы`] | -| Родительский ресурс | [Выберите название ресурса с шаблонами] | +| Родительский ресурс | [Выберите название ресурса с шаблонами] | | Дочерний ресурс | [Выберите название ресурса с сервисами] | ## Источник данных -> **[Источник данных](../datasources/overview/)** — механизм DDP, который позволяет синхронизировать информацию из внешних инфраструктурных сервисов (например, GitLab) в каталог платформы. Источники данных периодически опрашивают внешние системы, получают актуальную информацию и обновляют соответствующие сущности в каталоге. - -У вас должен быть настроен источник данных, который автоматически получает информацию об актуальном состоянии шаблонов из GitLab. Если источника данных еще нет, [создайте его](#создание-источника-данных). +У вас должен быть настроен источник данных, который автоматически получает информацию об актуальном состоянии шаблонов из GitLab. Если источника данных ещё нет, [создайте его](#создание-источника-данных). Проверьте следующие настройки: -**Основная информация:** +Основная информация: - **Ресурс**: выбран ресурс «Шаблоны» (или соответствующий ресурс, если он назван иначе). +- «Ресурс»: выбран ресурс «Шаблоны» (или соответствующий ресурс, если он назван иначе). -**Бэкенд:** +Бэкенд: -На вкладке «Бэкенд» проверьте подключение к GitLab, а именно, что происходит автоматическая синхронизация: +На вкладке «Бэкенд» проверьте подключение к GitLab, а именно что происходит автоматическая синхронизация: -- **Периодическая синхронизация**: должна быть включена, для автоматического обновления информации о шаблонах при их изменении в GitLab. +- «Периодическая синхронизация»: должна быть включена, для автоматического обновления информации о шаблонах при их изменении в GitLab. -- **Периодичность запуска**: должно быть указано расписание в формате CRON (например, `1 * * * *` для запуска каждый час). Расписание определяет, как часто источник данных будет проверять наличие новых тегов в репозиториях шаблонов. +- «Периодичность запуска»: должно быть указано расписание в формате CRON (например, `1 * * * *` для запуска каждый час). Расписание определяет, как часто источник данных будет проверять наличие новых тегов в репозиториях шаблонов. -**Параметры бэкенда:** +Параметры бэкенда: Должны быть заданы следующие ключи: @@ -206,23 +210,21 @@ title: Автоматическое обновление сервисов | group_ids | [ID группы с шаблонами] | Указано ID группы GitLab, в которой находятся шаблонные репозитории | | tags | true | Включено получение информации о тегах для каждого репозитория | -[Подробнее](../datasources/types/#gitlabprojects) о доступных параметрах. +Подробнее о доступных параметрах — в разделе [«GitlabProjects»](../datasources/types/#gitlabprojects). -**Правила:** +Правила: -**Правила обновления:** +Правила обновления: Настройте правила обновления параметров ресурса «Шаблоны» данными, полученными из GitLab: -- **Параметр «URL»**: необходимо хранить URL репозитория шаблона в GitLab. В качестве источника должен использоваться `{{ .web_url }}`. +- Параметр «URL»: необходимо хранить URL репозитория шаблона в GitLab. В качестве источника должен использоваться `{{ .web_url }}`. -- **Параметр «ID репозитория»**: необходимо хранить внутренний ID репозитория в GitLab. В качестве источника должен использоваться `{{ .id }}`. +- Параметр «ID репозитория»: необходимо хранить внутренний ID репозитория в GitLab. В качестве источника должен использоваться `{{ .id }}`. -- **Параметр «Последний тег»**: необходимо хранить последний тег git репозитория (в рамках данной инструкции используется как версия шаблона). Используется источник `{{ ( index ( .ddp_repository_tags ) 0 ).name }}`. Данное выражение получает последний тег, созданный в git-репозитории, беря первый элемент из массива тегов. Этот параметр критически важен для работы автоматизации, так как изменение его значения является триггером для обновления сервисов. - - - **Примечание**: данный способ получения версии шаблона является лишь примером, а не строгой необходимости. При необходимости способ получения тега можно настроить удобным для вас способом. +- Параметр «Последний тег»: необходимо хранить последний тег git-репозитория (в рамках данной инструкции используется как версия шаблона). Например, можно использовать источник `{{ ( index ( .ddp_repository_tags ) 0 ).name }}` — данное выражение получает последний тег, созданный в git-репозитории, беря первый элемент из массива тегов. При необходимости способ получения тега можно настроить иначе. Этот параметр критически важен для работы автоматизации, так как изменение его значения является триггером для обновления сервисов. -**Примечание**: идентификаторы источников берутся из спецификации [Projects API GitLab](https://docs.gitlab.com/api/projects/#get-a-single-project). +Идентификаторы источников берутся из спецификации [Projects API GitLab](https://docs.gitlab.com/api/projects/#get-a-single-project). ### Создание источника данных @@ -230,29 +232,29 @@ title: Автоматическое обновление сервисов Откроется окно по созданию нового [источника данных](../datasources/overview/) с различными вкладками. -**Основная информация:** +Основная информация: -- **Название**: укажите название источника данных (например, `Шаблоны сервисов`). +- «Название»: укажите название источника данных (например, `Шаблоны сервисов`). -- **Ресурс**: выберите ресурс, который содержит информацию о шаблонах. +- «Ресурс»: выберите ресурс, который содержит информацию о шаблонах. -- **Владелец**: назначьте владельца источника данных. +- «Владелец»: назначьте владельца источника данных. -- **Команда владелец**: укажите команду, ответственную за источник данных. +- «Команда владелец»: укажите команду, ответственную за источник данных. -**Бэкенд:** +Бэкенд: На вкладке «Бэкенд» настройте подключение к GitLab: -- **Бэкенд**: выберите встроенный тип источника данных `GitlabProjects` для работы с проектами GitLab. +- «Бэкенд»: выберите встроенный тип источника данных `GitlabProjects` для работы с проектами GitLab. -- **Периодическая синхронизация**: включите автоматический запуск синхронизации, для автоматического обновления информации о шаблонах при их изменении в GitLab. +- «Периодическая синхронизация»: включите автоматический запуск синхронизации, для автоматического обновления информации о шаблонах при их изменении в GitLab. -- **Периодичность запуска**: укажите расписание в формате CRON (например, `1 * * * *` для запуска каждый час). Расписание определяет, как часто источник данных будет проверять наличие новых тегов в репозиториях шаблонов. +- «Периодичность запуска»: укажите расписание в формате CRON (например, `1 * * * *` для запуска каждый час). Расписание определяет, как часто источник данных будет проверять наличие новых тегов в репозиториях шаблонов. -- **URL**: укажите URL вашего экземпляра GitLab (например, `https://gitlab.example.com`). +- «URL»: укажите URL вашего экземпляра GitLab (например, `https://gitlab.example.com`). -**Параметры бэкенда:** +Параметры бэкенда: Настройте параметры запроса к GitLab API: @@ -261,172 +263,169 @@ title: Автоматическое обновление сервисов | group_ids | [ID группы с шаблонами] | Укажите ID группы GitLab, в которой находятся шаблонные репозитории | | tags | true | Включает получение информации о тегах для каждого репозитория | -[Подробнее](../datasources/types/#gitlabprojects) о доступных параметрах. +Подробнее о доступных параметрах — в разделе [«GitlabProjects»](../datasources/types/#gitlabprojects). -**Правила:** +Правила: На вкладке «Правила» настройте логику создания и обновления сущностей: -- **Создание новых сущностей**: включите создание новых сущностей. DDP автоматически будет создавать записи о новых шаблонах, если шаблонный репозиторий обнаружен в GitLab, но еще не существует в каталоге. +- «Создание новых сущностей»: включите создание новых сущностей. DDP автоматически будет создавать записи о новых шаблонах, если шаблонный репозиторий обнаружен в GitLab, но ещё не существует в каталоге. -- **Владелец создаваемых сущностей**: назначьте владельца для новых сущностей. +- «Владелец создаваемых сущностей»: назначьте владельца для новых сущностей. -- **Команда владелец создаваемых сущностей**: укажите команду-владельца для новых сущностей. +- «Команда владелец создаваемых сущностей»: укажите команду-владельца для новых сущностей. -**Правила создания:** +Правила создания: Настройте правила для создания идентификатора и названия новой сущности в платформе: -- **Идентификатор**: идентификатор создаваемой сущности. Например, можно использовать выражение `{{ replaceChar .path_with_namespace "/" "-" }}` - - - **Примечание**: является лишь примером, а не строгой необходимостью. Данное выражение преобразует путь с пространством имен (`.path_with_namespace` из спецификации [Projects API GitLab](https://docs.gitlab.com/api/projects/#get-a-single-project)), заменяя слеши на дефисы для получения уникального ID. +- «Идентификатор»: идентификатор создаваемой сущности. Например, можно использовать выражение `{{ replaceChar .path_with_namespace "/" "-" }}` — оно преобразует путь с неймспейсом, заменяя слеши на дефисы для получения уникального ID. +- «Название»: название создаваемой сущности. Например, можно использовать выражение `{{ .name }}` — оно использует название проекта из GitLab. -- **Название**: название создаваемой сущность. Например, можно использовать выражение `{{ .name }}` - - - **Примечание**: является лишь примером, а не строгой необходимостью. Данное выражение использует название из GitLab (`.name` из спецификации [Projects API GitLab](https://docs.gitlab.com/api/projects/#get-a-single-project)) +При необходимости вы можете задать свои собственные правила на основе Go template. -**Примечание**: При необходимости вы можете задать свои собственные правила на основе Go Template. - -**Правила сопоставления:** +Правила сопоставления: Настройте правила сопоставления уже существующих сущностей при синхронизации: -- **Идентификатор**: идентификатор сущности, которую необходимо обновить. Например, можно использовать выражение `{{ replaceChar .path_with_namespace "/" "-" }}` - - - **Примечание**: является лишь примером, а не строгой необходимостью. Данное выражение преобразует путь с пространством имен (`.path_with_namespace` из спецификации [Projects API GitLab](https://docs.gitlab.com/api/projects/#get-a-single-project)), заменяя слеши на дефисы для получения уникального ID. - -- **Название**: название сущности, которую необходимо обновить. Например, можно использовать выражение `{{ .name }}` - - - **Примечание**: является лишь примером, а не строгой необходимостью. Данное выражение использует название из GitLab (`.name` из спецификации [Projects API GitLab](https://docs.gitlab.com/api/projects/#get-a-single-project)). +- «Идентификатор»: идентификатор сущности, которую необходимо обновить. Например, можно использовать то же выражение `{{ replaceChar .path_with_namespace "/" "-" }}`, что и в правилах создания. +- «Название»: название сущности, которую необходимо обновить. Например, можно использовать то же выражение `{{ .name }}`, что и в правилах создания. -**Примечание**: При необходимости вы можете задать свои собственные правила на основе Go Template. Если не планируется вручную создавать сущности ресурса, рекомендуется использовать одинаковые правила для сопоставления и создания. +При необходимости вы можете задать свои собственные правила на основе Go template. Если не планируется вручную создавать сущности ресурса, рекомендуется использовать одинаковые правила для сопоставления и создания. -**Правила обновления:** +Правила обновления: Настройте правила обновления параметров ресурса «Шаблоны» данными, полученными из GitLab: -- **Параметр «URL»**: в качестве значения используется URL репозитория шаблона в GitLab. В качестве источника используйте `{{ .web_url }}`. +- Параметр «URL»: в качестве значения используется URL репозитория шаблона в GitLab. В качестве источника используйте `{{ .web_url }}`. -- **Параметр «ID репозитория»**: в качестве значения используется внутренний ID репозитория в GitLab. В качестве источника используйте `{{ .id }}`. +- Параметр «ID репозитория»: в качестве значения используется внутренний ID репозитория в GitLab. В качестве источника используйте `{{ .id }}`. -- **Параметр «Последний тег»**: в качестве значения используется тег git репозитория. Используйте источник `{{ ( index ( .ddp_repository_tags ) 0 ).name }}`. Данное выражение получает последний тег, созданный в git-репозитории, беря первый элемент из массива тегов. Этот параметр критически важен для работы автоматизации, так как изменение его значения является триггером для обновления сервисов. - - - **Примечание**: данный способ получения версии шаблона является лишь примером, а не строгой необходимости. При необходимости способ получения тега можно настроить удобным для вас способом. +- Параметр «Последний тег»: в качестве значения используется тег git-репозитория. Например, можно использовать источник `{{ ( index ( .ddp_repository_tags ) 0 ).name }}` — данное выражение получает последний тег, созданный в git-репозитории, беря первый элемент из массива тегов. При необходимости способ получения тега можно настроить иначе. Этот параметр критически важен для работы автоматизации, так как изменение его значения является триггером для обновления сервисов. -**Примечание**: идентификаторы источников берутся из спецификации [Projects API GitLab](https://docs.gitlab.com/api/projects/#get-a-single-project). +Идентификаторы источников берутся из спецификации [Projects API GitLab](https://docs.gitlab.com/api/projects/#get-a-single-project). -**Авторизация:** +Авторизация: -На вкладке «Авторизация» настройте заголовки и учетные данные, необходимые для подключения к GitLab: +На вкладке «Авторизация» настройте заголовки и учётные данные, необходимые для подключения к GitLab: -Настройте учетные данные: +Настройте учётные данные: -- **Идентификатор**: `token`. +- «Идентификатор»: `token`. -- **Реквизиты**: укажите реквизиты, которые содержат токен GitLab с необходимыми правами доступа к репозиториям. Токен должен иметь права на чтение проектов и информации о тегах в указанной группе GitLab. +- «Реквизиты»: укажите реквизиты, которые содержат токен GitLab с необходимыми правами доступа к репозиториям. Токен должен иметь права на чтение проектов и информации о тегах в указанной группе GitLab. Так же необходимо настроить заголовок: -- **Ключ**: `Private-Token`. +- «Ключ»: `Private-Token`. -- **Значение**: `{{ .credentials.token }}` — используется значение, которое было настроено для учётных данных. Если в качестве идентификатора учётных данных используется не `token`, необходимо заменить `token` на заданное вами. +- «Значение»: `{{ .credentials.token }}` — используется значение, которое было настроено для учётных данных. Если в качестве идентификатора учётных данных используется не `token`, необходимо заменить `token` на заданное вами. -[Подробнее](../datasources/types/#gitlabprojects) о доступных заголовках и [системной учетной записи](../datasources/overview/#системная-учетная-запись). +Подробнее о доступных заголовках — в разделе [«GitlabProjects»](../datasources/types/#gitlabprojects) и [«Системная учётная запись»](../datasources/overview/#системная-учётная-запись). ## Создание действий -> **Действия** — механизм DDP, который позволяет пользователям платформы взаимодействовать с внешними инфраструктурными сервисами через API. Действия могут создавать проекты в GitLab, создавать секреты в системах управления секретами, развертывать приложения и выполнять другие операции. - Необходимо настроить три действия, которые будут отвечать за создание сервиса из шаблона и их обновление в случае выпуска новых версий шаблона. ### Действие «Создать проект в GitLab» -У вас должно быть создано действие, которое отвечает за инициализацию нового проекта в GitLab. Оно запускается первым при создании нового сервиса для создания проекта в GitLab, в который будет помещен созданный из шаблона сервис. Если действия еще нет, [создайте его](#создание-действия). +У вас должно быть создано действие, которое отвечает за инициализацию нового проекта в GitLab. Оно запускается первым при создании нового сервиса и создаёт проект в GitLab, в который будет помещён сервис, созданный из шаблона. Если действия ещё нет, [создайте его](#создание-действия). Проверьте, что действие содержит следующие настройки: -**Основная информация:** +Основная информация: -- **Ресурс**: выбран ресурс, который содержит информацию о сервисах. +- «Ресурс»: выбран ресурс, который содержит информацию о сервисах. -**Обновление:** +Обновление: -На вкладке «Обновление» активирована опция «Обновление параметров сущности» и настроены правила обновления, которые записывают ID, URL и ветку по умолчанию только что созданного проекта в сущность, для которой запускалось действие: +На вкладке «Обновление» активирована опция «Обновление параметров сущности» и настроены правила обновления, которые записывают ID, URL и ветку по умолчанию только что созданного проекта в сущность, для которой запускалось действие. -> Ниже указаны примеры названий параметров сущности. В поле `параметр сущности` необходимо указывать идентификатор соответствующего параметра ресурса, который хранит информацию о сервисах. +{{< alert level="info" >}} +Ниже указаны примеры названий параметров сущности. В поле `параметр сущности` необходимо указывать идентификатор соответствующего параметра ресурса, который хранит информацию о сервисах. +{{< /alert >}} -- **Параметр «ID репозитория»** используется источник `{{ .response.id }}` — сохраняет ID созданного проекта из ответа GitLab API в параметр сущности. +- Параметр «ID репозитория» используется источник `{{ .response.id }}` — сохраняет ID созданного проекта из ответа GitLab API в параметр сущности. -- **Параметр «URL»**: используется источник `{{ .response.web_url }}` — сохраняет URL проекта в GitLab созданного проекта в параметр сущности. +- Параметр «URL»: используется источник `{{ .response.web_url }}` — сохраняет URL проекта в GitLab созданного проекта в параметр сущности. -- **Параметр «Ветка по умолчанию»**: используется источник `{{ .response.default_branch }}` — сохраняет название ветки по умолчанию в параметр сущности. +- Параметр «Ветка по умолчанию»: используется источник `{{ .response.default_branch }}` — сохраняет название ветки по умолчанию в параметр сущности. -**Примечание**: идентификаторы источников (`id`, `web_url`, `default_branch`) берутся из спецификации [Projects API GitLab](https://docs.gitlab.com/api/projects/#get-a-single-project). +{{< alert level="info" >}} +Идентификаторы источников (`id`, `web_url`, `default_branch`) берутся из спецификации [Projects API GitLab](https://docs.gitlab.com/api/projects/#get-a-single-project). +{{< /alert >}} ### Действие «Создать репозиторий из шаблона» -У вас должно быть создано действие для клонирования кода из шаблонного репозитория в новый репозиторий сервиса с применением переменных шаблонизации. Это действие будет запускаться после создания проекта в GitLab и заполнять его кодом из шаблона. Если действия еще нет, [создайте его](#создание-действия). +У вас должно быть создано действие для клонирования кода из шаблонного репозитория в новый репозиторий сервиса с применением переменных шаблонизации. Это действие будет запускаться после создания проекта в GitLab и заполнять его кодом из шаблона. Если действия ещё нет, [создайте его](#создание-действия). Проверьте, что действие содержит следующие настройки: -**Основная информация:** +Основная информация: -- **Ресурс**: выбран ресурс, который содержит информацию о сервисах (действие запускается для сущности сервиса, который нужно обновить). +- «Ресурс»: выбран ресурс, который содержит информацию о сервисах (действие запускается для сущности сервиса, который нужно обновить). -**Пользовательская форма:** +Пользовательская форма: Проверьте наличие следующих полей в пользовательской форме: -- **Параметр «Идентификатор шаблонного репозитория»** с идентификатором `template_ddp_slug` (или другим, если это необходимо) типа Entities — будет автоматически подставляться идентификатор сущности шаблона внутри DDP, из которого будет клонироваться код. В дополнительных настройках укажите: **Ресурс:** «Шаблоны» (или соответствующий ресурс), **Связь:** «Шаблоны-Сервисы» (или название вашей связи), **Поле:** «Идентификатор». Это позволяет выбрать нужный шаблон из связанных сущностей. Данный параметр можно сделать скрытым. +- Параметр «Идентификатор шаблонного репозитория» с идентификатором `template_ddp_slug` (или другим, если это необходимо) типа Entities — будет автоматически подставляться идентификатор сущности шаблона внутри DDP, из которого будет клонироваться код. В дополнительных настройках укажите: Ресурс: «Шаблоны» (или соответствующий ресурс), Связь: «Шаблоны-Сервисы» (или название вашей связи), Поле: «Идентификатор». Это позволяет выбрать нужный шаблон из связанных сущностей. Данный параметр можно сделать скрытым. -**Обновление:** +Обновление: -На вкладке «Обновление» активирована опция «Обновление параметров сущности» и настроено сохранение переменных, использованных при шаблонизации, обратно в сущность, для которой запускалось действие: +На вкладке «Обновление» активирована опция «Обновление параметров сущности» и настроено сохранение переменных, использованных при шаблонизации, обратно в сущность, для которой запускалось действие. -> Ниже указан пример названия параметра сущности. В поле `параметр сущности` необходимо указывать идентификатор соответствующего параметра ресурса, который хранит информацию о сервисах. +{{< alert level="info" >}} +Ниже указан пример названия параметра сущности. В поле `параметр сущности` необходимо указывать идентификатор соответствующего параметра ресурса, который хранит информацию о сервисах. +{{< /alert >}} -- **Параметр «Переменные использованные при шаблонизации»**: используйте источник `{{ toYAML .response.values.merged }}` — данное выражение сохраняет переменные в формате YAML. Эти переменные критически важны для будущего обновления сервиса из шаблона, так как они должны быть применены повторно. Данные получены в качестве ответа на успешное выполнение действия. +- Параметр «Переменные использованные при шаблонизации»: используйте источник `{{ toYAML .response.values.merged }}` — данное выражение сохраняет переменные в формате YAML. Эти переменные критически важны для будущего обновления сервиса из шаблона, так как они должны быть применены повторно. Данные получены в качестве ответа на успешное выполнение действия. Активирована опция «Создание связей сущности», чтобы действие автоматически устанавливало связь между созданным сервисом и его шаблоном: -- **Ресурс**: выбран ресурс «Сервисы» (или соответствующий ресурс, если он назван иначе) +- «Ресурс»: выбран ресурс «Сервисы» (или соответствующий ресурс, если он назван иначе). + +- «Связь»: выбрана связь «Шаблоны-Сервисы» (или название вашей связи, если оно отличается). -- **Связь**: выбрана связь «Шаблоны-Сервисы» (или название вашей связи, если оно отличается) +- «Идентификатор родительской сущности»: используйте `{{ .property.template_ddp_slug }}` — идентификатор шаблона из параметра действия. -- **Идентификатор родительской сущности**: используйте `{{ .property.template_ddp_slug }}` — идентификатор шаблона из параметра действия - - **Важно**: если идентификатор параметра не `template_ddp_slug`, замените на корректный + {{< alert level="warning" >}} + Если идентификатор параметра не `template_ddp_slug`, замените на корректный. + {{< /alert >}} -- **Идентификатор дочерней сущности**: оставьте пустым — будет использована текущая сущность, для которой запускается действие +- «Идентификатор дочерней сущности»: оставьте пустым — будет использована текущая сущность, для которой запускается действие. ### Действие «Обновление сервиса из шаблона» -У вас должно быть создано действие, которое будет использоваться в автоматизации для создания нового Merge Request в репозиторий сервиса. Этот MR будет содержать изменения из новой версии (нового тега) связанного шаблона. Если действия еще нет, [создайте его](#создание-действия). +У вас должно быть создано действие, которое будет использоваться в автоматизации для создания нового Merge Request в репозиторий сервиса. Этот MR будет содержать изменения из новой версии (нового тега) связанного шаблона. Если действия ещё нет, [создайте его](#создание-действия). Проверьте, что действие содержит следующие настройки: -**Основная информация:** +Основная информация: -- **Ресурс**: выбран ресурс, который содержит информацию о сервисах. +- «Ресурс»: выбран ресурс, который содержит информацию о сервисах. -**Пользовательская форма:** +Пользовательская форма: Проверьте наличие следующих полей в пользовательской форме: -- **Параметр «Переменные используемые при шаблонизации"** с идентификатором `template_values` (или другим, если это необходимо) типа String — он хранит переменные, которые были использованы при изначальной шаблонизации (хранятся в параметре сущности). Значение по умолчанию: `{{ .entity.properties.template_values }}` — использует сохраненные переменные из параметра сущности. Важно: если параметр называется иначе (например, `template_vars`), используйте соответствующий идентификатор. +- Параметр «Переменные используемые при шаблонизации» с идентификатором `template_values` (или другим, если это необходимо) типа String — он хранит переменные, которые были использованы при изначальной шаблонизации (хранятся в параметре сущности). Значение по умолчанию: `{{ .entity.properties.template_values }}` — использует сохранённые переменные из параметра сущности. Важно: если параметр называется иначе (например, `template_vars`), используйте соответствующий идентификатор. -- **Параметр «Версия»** с идентификатором `version` (или другим, если это необходимо) типа Entities — получает значение нового тега (версии) из сущности шаблона. В дополнительных настройках укажите: **Ресурс:** "Шаблоны" (или соответствующий ресурс, если он назван иначе), **Связь:** «Шаблоны-Сервисы» (или название вашей связи), **Поле:** "Параметр", **Параметр:** «Последний тег» (или аналогичный). +- Параметр «Версия» с идентификатором `version` (или другим, если это необходимо) типа Entities — получает значение нового тега (версии) из сущности шаблона. В дополнительных настройках укажите: Ресурс: «Шаблоны» (или соответствующий ресурс, если он назван иначе), Связь: «Шаблоны-Сервисы» (или название вашей связи), Поле: «Параметр», Параметр: «Последний тег» (или аналогичный). -- **Параметр «Обновляемый репозиторий»** с идентификатором `target_project_id` (или другим, если это необходимо) типа String — это ID репозитория сервиса в GitLab, в который создается MR. Значение по умолчанию: `{{ .entity.properties.project_id }}` — использует ID проекта из параметра сущности. Если идентификатор (`project_id`) параметра, который хранит внутренний ID проекта в GitLab в ресурсе называется иначе, используйте соответствующий идентификатор. +- Параметр «Обновляемый репозиторий» с идентификатором `target_project_id` (или другим, если это необходимо) типа String — это ID репозитория сервиса в GitLab, в который создаётся MR. Значение по умолчанию: `{{ .entity.properties.project_id }}` — использует ID проекта из параметра сущности. Если идентификатор (`project_id`) параметра, который хранит внутренний ID проекта в GitLab в ресурсе, называется иначе, используйте соответствующий идентификатор. -- **Параметр «Шаблонный репозиторий»** с идентификатором `source_project_id` (или другим, если это необходимо) типа Entities — это ID репозитория шаблона в GitLab. В дополнительных настройках укажите: **Ресурс:** «Шаблоны» (или соответствующий ресурс, если он назван иначе), **Связь:** «Шаблоны-Сервисы» (или название вашей связи), **Поле:** «Параметр», **Параметр:** «ID репозитория» (или аналогичный). +- Параметр «Шаблонный репозиторий» с идентификатором `source_project_id` (или другим, если это необходимо) типа Entities — это ID репозитория шаблона в GitLab. В дополнительных настройках укажите: Ресурс: «Шаблоны» (или соответствующий ресурс, если он назван иначе), Связь: «Шаблоны-Сервисы» (или название вашей связи), Поле: «Параметр», Параметр: «ID репозитория» (или аналогичный). -- **Параметр «Ветка обновляемого репозитория»** с идентификатором `target_repo_branch` (или другим, если это необходимо) типа String — это основная ветка репозитория сервиса (например, `master` или `main`), куда будет направлен MR. При необходимости можете указать любую другую. Значение по умолчанию: `{{ .entity.properties.default_branch }}` — использует ветку по умолчанию из параметра сущности. Если идентификатор параметра (`default_branch`) называется иначе, используйте соответствующий идентификатор. +- Параметр «Ветка обновляемого репозитория» с идентификатором `target_repo_branch` (или другим, если это необходимо) типа String — это основная ветка репозитория сервиса (например, `master` или `main`), куда будет направлен MR. При необходимости можете указать любую другую. Значение по умолчанию: `{{ .entity.properties.default_branch }}` — использует ветку по умолчанию из параметра сущности. Если идентификатор параметра (`default_branch`) называется иначе, используйте соответствующий идентификатор. -**Конфигурация запроса:** +Конфигурация запроса: -**Тело запроса:** +Тело запроса: -> В качестве идентификаторов используется те, которые предлагались выше. Если были заданы другие, необходимо так же изменить их ниже в теле запроса. +{{< alert level="info" >}} +В качестве идентификаторов используются те, которые предлагались выше. Если были заданы другие, необходимо также изменить их ниже в теле запроса. +{{< /alert >}} Тело запроса должно быть настроено примерно таким образом: @@ -443,84 +442,84 @@ values: {{ .template_values | nindent 4 }} В теле запроса: -- `source_branch` — название ветки, содержащая изменения. В качестве примера, используется ветка с названием, включающим версию тега. +- `source_branch` — название ветки, содержащей изменения. В качестве примера используется ветка с названием, включающим версию тега. - `target_branch` — целевая ветка сервиса, куда будет направлен MR. - `title` — заголовок MR с указанием версии. - `source_project_tag` — тег версии шаблона, из которого берутся изменения. - `source_project_id` и `target_project_id` — ID репозиториев шаблона и сервиса. - `values` — переменные шаблонизации применяются повторно для корректного рендеринга изменений. -[Подробнее](../actions/types/#creategitlabmergerequest) о настройках встроенного бэкенда. +Подробнее о настройках встроенного бэкенда — в разделе [«CreateGitlabMergeRequest»](../actions/types/#creategitlabmergerequest). ### Создание действия -Для создания [действия](../actions/overview/) перейдите в раздел «Самообслуживание» пункт «Действия». Создайте новое действие. Для этого нажмите справа вверху кнопку «Создать». Откроется окно по созданию нового [действия](../actions/overview/) с различными вкладками. - -Откроется окно по созданию нового действия с различными вкладками. +Для создания [действия](../actions/overview/) перейдите в раздел «Самообслуживание», пункт «Действия». Создайте новое действие. Для этого нажмите справа вверху кнопку «Создать». Откроется окно по созданию нового [действия](../actions/overview/) с различными вкладками. -**Вкладка «Основная информация»:** +Вкладка «Основная информация»: Заполните следующие поля на вкладке «Основная информация»: -- **Название**: [Укажите название действия]. +- «Название»: [Укажите название действия]. -- **Ресурс**: выберите ресурс «Сервисы» (или соответствующий ресурс, если он назван иначе). +- «Ресурс»: выберите ресурс «Сервисы» (или соответствующий ресурс, если он назван иначе). -- **Владелец**: [Укажите владельца]. +- «Владелец»: [Укажите владельца]. -- **Команда владелец**: [Укажите команду владелец]. +- «Команда владелец»: [Укажите команду владелец]. -**Пользовательская форма:** +Пользовательская форма: -На вкладке «Пользовательская форма» настройте поля для заполнения при запуске действия. Параметры, которые необходимо настроить зависят от действия, которое вы создаёте: +На вкладке «Пользовательская форма» настройте поля для заполнения при запуске действия. Параметры, которые необходимо настроить, зависят от действия, которое вы создаёте. -**Действие «Создать проект в GitLab»:** +Действие «Создать проект в GitLab»: -- **Параметр «Название»** с идентификатором `name` (или иным при необходимости) типа String — это название нового проекта. Значение по умолчанию: `{{ .entity.name }}` — использует название сущности в DDP. +- Параметр «Название» с идентификатором `name` (или иным при необходимости) типа String — это название нового проекта. Значение по умолчанию: `{{ .entity.name }}` — использует название сущности в DDP. -- **Параметр «Путь»** с идентификатором `path` (или иным при необходимости) типа String — это URL-путь до репозитория в GitLab. Значение по умолчанию: `{{ .entity.slug }}` — использует идентификатор сущности в DDP. +- Параметр «Путь» с идентификатором `path` (или иным при необходимости) типа String — это URL-путь до репозитория в GitLab. Значение по умолчанию: `{{ .entity.slug }}` — использует идентификатор сущности в DDP. -- **Параметр «Группа репозиториев»** с идентификатором `group` (или иным при необходимости) типа String — ID группы GitLab, где будет создан сервис. Значение по умолчанию: укажите ID группы в GitLab, в котором необходимо создать проект. +- Параметр «Группа репозиториев» с идентификатором `group` (или иным при необходимости) типа String — ID группы GitLab, где будет создан сервис. Значение по умолчанию: укажите ID группы в GitLab, в которой необходимо создать проект. -**Действие «Создать репозиторий из шаблона»:** +Действие «Создать репозиторий из шаблона»: -- **Параметр «Идентификатор шаблонного репозитория»** с идентификатором `template_ddp_slug` (или иным при необходимости) типа Entities — это идентификатор сущности шаблона внутри DDP, из которого будет клонироваться код. В дополнительных настройках укажите: **Ресурс:** «Шаблоны» (или соответствующий ресурс), **Связь:** «Шаблоны-Сервисы» (или название вашей связи), **Поле:** «Идентификатор». Это позволяет выбрать нужный шаблон из связанных сущностей. +- Параметр «Идентификатор шаблонного репозитория» с идентификатором `template_ddp_slug` (или иным при необходимости) типа Entities — это идентификатор сущности шаблона внутри DDP, из которого будет клонироваться код. В дополнительных настройках укажите: Ресурс: «Шаблоны» (или соответствующий ресурс), Связь: «Шаблоны-Сервисы» (или название вашей связи), Поле: «Идентификатор». Это позволяет выбрать нужный шаблон из связанных сущностей. -- **Параметр «URL сервисного репозитория»** с идентификатором `service_git_url` (или иным при необходимости) типа URL — это URL репозитория, в который будет помещен отрендеренный шаблон. Значение по умолчанию: `{{ .entity.properties.web_url }}` — использует URL сущности сервиса из каталога. Если параметр URL в ресурсе называется иначе, используйте соответствующий идентификатор (например, `{{ .entity.properties.service_url }}`). +- Параметр «URL сервисного репозитория» с идентификатором `service_git_url` (или иным при необходимости) типа URL — это URL репозитория, в который будет помещён отрендеренный шаблон. Значение по умолчанию: `{{ .entity.properties.web_url }}` — использует URL сущности сервиса из каталога. Если параметр URL в ресурсе называется иначе, используйте соответствующий идентификатор (например, `{{ .entity.properties.service_url }}`). -- **Параметр «URL шаблонного репозитория»** с идентификатором `template_git_url` (или иным при необходимости) типа Entities — это URL репозитория шаблона, который используется бэкендом для клонирования. В дополнительных настройках укажите: **Ресурс:** «Шаблоны» (или соответствующий ресурс), **Связь:** «Шаблоны-Сервисы» (или название вашей связи), **Поле:** «Параметр», **Параметр:** "URL" (или иной аналогичный, в зависимости от ваших настроек). +- Параметр «URL шаблонного репозитория» с идентификатором `template_git_url` (или иным при необходимости) типа Entities — это URL репозитория шаблона, который используется бэкендом для клонирования. В дополнительных настройках укажите: Ресурс: «Шаблоны» (или соответствующий ресурс), Связь: «Шаблоны-Сервисы» (или название вашей связи), Поле: «Параметр», Параметр: «URL» (или иной аналогичный, в зависимости от ваших настроек). -> Дополнительные параметры зависят от вашего шаблона и должны быть настроены в соответствии с переменными, используемыми в шаблоне. +{{< alert level="info" >}} +Дополнительные параметры зависят от вашего шаблона и должны быть настроены в соответствии с переменными, используемыми в шаблоне. +{{< /alert >}} -**Действие «Обновление сервиса из шаблона»:** +Действие «Обновление сервиса из шаблона»: Необходимо настроить поля для сбора данных, которые нужны бэкенду для создания Merge Request. Эти данные будут автоматически заполняться из сущностей ресурса «Сервисы» или связанной с ним сущности из ресурса «Шаблоны»: -- **Параметр «Переменные используемые при шаблонизации"** с идентификатором `template_values` (или иным при необходимости) типа String — это переменные, которые были использованы при изначальной шаблонизации (хранятся в параметре сущности). Значение по умолчанию: `{{ .entity.properties.template_values }}` — использует сохраненные переменные из параметра сущности. Важно: если параметр называется иначе (например, `template_vars`), используйте соответствующий идентификатор +- Параметр «Переменные используемые при шаблонизации» с идентификатором `template_values` (или иным при необходимости) типа String — это переменные, которые были использованы при изначальной шаблонизации (хранятся в параметре сущности). Значение по умолчанию: `{{ .entity.properties.template_values }}` — использует сохранённые переменные из параметра сущности. Важно: если параметр называется иначе (например, `template_vars`), используйте соответствующий идентификатор. -- **Параметр «Версия»** с идентификатором `version` (или иным при необходимости) типа Entities — получает значение нового тега (версии) из сущности шаблона. В дополнительных настройках укажите: **Ресурс:** «Шаблоны» (или соответствующий ресурс), **Связь:** «Шаблоны-Сервисы» (или название вашей связи), **Поле:** «Параметр», **Параметр:** «Последний тег» (или аналогичный). +- Параметр «Версия» с идентификатором `version` (или иным при необходимости) типа Entities — получает значение нового тега (версии) из сущности шаблона. В дополнительных настройках укажите: Ресурс: «Шаблоны» (или соответствующий ресурс), Связь: «Шаблоны-Сервисы» (или название вашей связи), Поле: «Параметр», Параметр: «Последний тег» (или аналогичный). -- **Параметр «Обновляемый репозиторий»** с идентификатором `target_project_id` (или иным при необходимости) типа String — это внутренний ID репозитория сервиса в GitLab, в который создается MR. Значение по умолчанию: `{{ .entity.properties.project_id }}` — использует ID проекта из параметра сущности. Если параметр ID в ресурсе называется иначе, используйте соответствующий идентификатор +- Параметр «Обновляемый репозиторий» с идентификатором `target_project_id` (или иным при необходимости) типа String — это внутренний ID репозитория сервиса в GitLab, в который создаётся MR. Значение по умолчанию: `{{ .entity.properties.project_id }}` — использует ID проекта из параметра сущности. Если параметр ID в ресурсе называется иначе, используйте соответствующий идентификатор. -- **Параметр «Шаблонный репозиторий»** с идентификатором `source_project_id` (или иным при необходимости) типа Entities — это внутренний ID репозитория шаблона в GitLab. В дополнительных настройках укажите: **Ресурс:** «Шаблоны» (или соответствующий ресурс), **Связь:** «Шаблоны-Сервисы» (или название вашей связи), **Поле:** «Параметр», **Параметр:** "ID репозитория" (или аналогичный) +- Параметр «Шаблонный репозиторий» с идентификатором `source_project_id` (или иным при необходимости) типа Entities — это внутренний ID репозитория шаблона в GitLab. В дополнительных настройках укажите: Ресурс: «Шаблоны» (или соответствующий ресурс), Связь: «Шаблоны-Сервисы» (или название вашей связи), Поле: «Параметр», Параметр: «ID репозитория» (или аналогичный). -- **Параметр «Ветка обновляемого репозитория»** с идентификатором `target_repo_branch` (или иным при необходимости) типа String — основная ветка репозитория сервиса (например, `master` или `main`), куда будет направлен MR. Значение по умолчанию: `{{ .entity.properties.default_branch }}` — использует ветку по умолчанию из параметра сущности. Если идентификатор параметра называется иначе, используйте свой +- Параметр «Ветка обновляемого репозитория» с идентификатором `target_repo_branch` (или иным при необходимости) типа String — основная ветка репозитория сервиса (например, `master` или `main`), куда будет направлен MR. Значение по умолчанию: `{{ .entity.properties.default_branch }}` — использует ветку по умолчанию из параметра сущности. Если идентификатор параметра называется иначе, используйте свой. -**Конфигурация запроса:** +Конфигурация запроса: -> В качестве идентификаторов используется те, которые предлагались выше. Если были заданы другие, необходимо так же изменить их ниже в теле запроса. +{{< alert level="info" >}} +В качестве идентификаторов используются те, которые предлагались выше. Если были заданы другие, необходимо также изменить их ниже в теле запроса. +{{< /alert >}} На вкладке «Конфигурация запроса» настройте логику выполнения действия. Логика зависит от настраиваемого действия. -**Действие «Создать проект в GitLab»:** +Действие «Создать проект в GitLab»: -- **Тип действия**: выберите встроенный тип действия (значение `BuiltIn`). +- «Тип действия»: выберите встроенный тип действия (значение `BuiltIn`). +- «Встроенный тип действия»: выберите `CreateGitlabProject` для создания проекта в GitLab. +- «URL»: укажите URL вашего экземпляра GitLab (например, `https://gitlab.example.com`). -- **Встроенный тип действия**: выберите `CreateGitlabProject` для создания проекта в GitLab. - -- **URL**: укажите URL вашего экземпляра GitLab (например, `https://gitlab.example.com`). - -**Тело запроса:** +Тело запроса: ```yaml initialize_with_readme: false @@ -529,17 +528,17 @@ namespace_id: '{{ .group }}' path: '{{ .path }}' ``` -Это тело запроса передает в GitLab API название проекта, ID группы и путь репозитория. Подробнее о настройках в [документации](../actions/types/#creategitlabproject). +Это тело запроса передаёт в GitLab API название проекта, ID группы и путь репозитория. Подробнее о настройках — в разделе [«CreateGitlabProject»](../actions/types/#creategitlabproject). -**Действие «Создать репозиторий из шаблона»:** +Действие «Создать репозиторий из шаблона»: -- **Тип действия**: выберите встроенный тип действия (значение `BuiltIn`). +- «Тип действия»: выберите встроенный тип действия (значение `BuiltIn`). -- **Встроенный тип действия**: выберите `CreateRepositoryFromTemplate` для создания репозитория из шаблона. +- «Встроенный тип действия»: выберите `CreateRepositoryFromTemplate` для создания репозитория из шаблона. -- **URL**: укажите URL вашего экземпляра GitLab (например, `https://gitlab.example.com`). +- «URL»: укажите URL вашего экземпляра GitLab (например, `https://gitlab.example.com`). -**Тело запроса:** +Тело запроса: ```yaml sourceBranch: "master" @@ -559,17 +558,17 @@ values: - `values` — блок должен содержать пары ключ-значение, которые будут использованы для замены переменных в файлах шаблона. Формат и состав этих переменных полностью зависит от того, как настроен ваш шаблон. -Подробнее о настройках в [документации](../actions/types/#createrepositoryfromtemplate). +Подробнее о настройках — в разделе [«CreateRepositoryFromTemplate»](../actions/types/#createrepositoryfromtemplate). -**Действие «Обновление сервиса из шаблона»:** +Действие «Обновление сервиса из шаблона»: -- **Тип действия**: выберите встроенный тип действия (значение `BuiltIn`). +- «Тип действия»: выберите встроенный тип действия (значение `BuiltIn`). -- **Встроенный тип действия**: выберите `CreateGitlabMergeRequest` для создания Merge Request в GitLab. +- «Встроенный тип действия»: выберите `CreateGitlabMergeRequest` для создания Merge Request в GitLab. -- **URL**: укажите URL вашего экземпляра GitLab (например, `https://gitlab.example.com`). +- «URL»: укажите URL вашего экземпляра GitLab (например, `https://gitlab.example.com`). -**Тело запроса:** +Тело запроса: ```yaml merge_request_spec: @@ -584,7 +583,7 @@ values: {{ .template_values | nindent 4 }} В теле запроса: -- `source_branch` — создается новая ветка с названием, включающим версию тега. +- `source_branch` — создаётся новая ветка с названием, включающим версию тега. - `target_branch` — целевая ветка сервиса, куда будет направлен MR. @@ -596,85 +595,84 @@ values: {{ .template_values | nindent 4 }} - `values` — переменные шаблонизации применяются повторно для корректного рендеринга изменений. -Подробнее о настройках в [документации](../actions/types/#creategitlabmergerequest). +Подробнее о настройках — в разделе [«CreateGitlabMergeRequest»](../actions/types/#creategitlabmergerequest). -**Обновление:** +Обновление: -**Обновление параметров сущности:** +Обновление параметров сущности: Для действий «Создать проект в GitLab» и «Создать репозиторий из шаблона» необходимо активировать опцию «Обновление параметров сущности» и настроить правила обновления, которые запишут некоторую информацию (зависит от действия) в сущность, для которой запускалось действие. Дополнительно необходимо настроить правила обновления сущности. Правила обновления сущности зависят от настраиваемого действия. -**Действие «Создать проект в GitLab»:** - -> Используйте идентификаторы соответствующих параметров ресурса +Для действия «Создать проект в GitLab» используйте идентификаторы соответствующих параметров ресурса: -- **Параметр «ID репозитория»**: используйте источник `{{ .response.id }}` — сохраняет ID созданного проекта из ответа GitLab API. +- Параметр «ID репозитория»: используйте источник `{{ .response.id }}` — сохраняет ID созданного проекта из ответа GitLab API. -- **Параметр «URL»**: используйте источник `{{ .response.web_url }}` — сохраняет URL созданного проекта. +- Параметр «URL»: используйте источник `{{ .response.web_url }}` — сохраняет URL созданного проекта. -- **Параметр «Ветка по умолчанию»**: используйте источник `{{ .response.default_branch }}` — сохраняет название ветки по умолчанию. +- Параметр «Ветка по умолчанию»: используйте источник `{{ .response.default_branch }}` — сохраняет название ветки по умолчанию. -**Примечание**: идентификаторы источников (`id`, `.web_url`, `.default_branch`) берутся из спецификации [Projects API GitLab](https://docs.gitlab.com/api/projects/#get-a-single-project). +Идентификаторы источников (`id`, `.web_url`, `.default_branch`) берутся из спецификации [Projects API GitLab](https://docs.gitlab.com/api/projects/#get-a-single-project). -**Действие «Создать репозиторий из шаблона»:** +Для действия «Создать репозиторий из шаблона» используйте идентификатор соответствующего параметра ресурса: -> Используйте идентификатор соответствующего параметров ресурса. +- Параметр «Переменные использованные при шаблонизации»: используйте источник `{{ toYAML .response.values.merged }}` — данное выражение сохраняет переменные в формате YAML. Эти переменные критически важны для будущего обновления сервиса из шаблона, так как они должны быть применены повторно. Данные получены в качестве ответа на успешное выполнение действия. -- **Параметр «Переменные использованные при шаблонизации»**: используйте источник `{{ toYAML .response.values.merged }}` — данное выражение сохраняет переменные в формате YAML. Эти переменные критически важны для будущего обновления сервиса из шаблона, так как они должны быть применены повторно. Данные получены в качестве ответа на успешное выполнение действия. +Создание связей сущности: -**Создание связей сущности:** +Для действия «Создать репозиторий из шаблона» также должна быть активирована опция «Создание связей сущности», чтобы действие автоматически устанавливало связь между созданным сервисом и его шаблоном: -Для действия «Создать репозиторий из шаблона» так же должна быть активирована опция «Создание связей сущности», чтобы действие автоматически устанавливало связь между созданным сервисом и его шаблоном: +- «Ресурс»: выберите «Сервисы» (или соответствующий ресурс, если он назван иначе). -- **Ресурс**: выберите «Сервисы» (или соответствующий ресурс, если он назван иначе). +- «Связь»: выберите связь «Шаблоны-Сервисы» (или название вашей связи, если оно отличается). -- **Связь**: выберите связь «Шаблоны-Сервисы» (или название вашей связи, если оно отличается). +- «Идентификатор родительской сущности»: используйте `{{ .property.template_ddp_slug }}` — идентификатор шаблона из параметра действия. -- **Идентификатор родительской сущности**: используйте `{{ .property.template_ddp_slug }}` — идентификатор шаблона из параметра действия. - > **Важно**. Если идентификатор параметра не `template_ddp_slug`, замените на корректный. + {{< alert level="warning" >}} + Если идентификатор параметра не `template_ddp_slug`, замените на корректный. + {{< /alert >}} -- **Идентификатор дочерней сущности**: оставьте пустым — будет использована текущая сущность, для которой запускается действие. +- «Идентификатор дочерней сущности»: оставьте пустым — будет использована текущая сущность, для которой запускается действие. -**Авторизация:** +Авторизация: На вкладке «Авторизация» настройте учётные данные для выполнения действия. Настройки зависят от действия. -**Действие «Создать проект в GitLab»:** +Действие «Создать проект в GitLab»: -- **Идентификатор**: `token`. +- «Идентификатор»: `token`. -- **Реквизиты**: укажите реквизиты, которые содержат токен GitLab с необходимыми правами доступа для создания проектов в указанной группе. +- «Реквизиты»: укажите реквизиты, которые содержат токен GitLab с необходимыми правами доступа для создания проектов в указанной группе. -**Действие «Создать репозиторий из шаблона»:** +Действие «Создать репозиторий из шаблона»: -- **Идентификатор**: `password` — реквизиты, которые содержат пароль (токен) GitLab с необходимыми правами доступа к репозиториям. +- «Идентификатор»: `password` — реквизиты, которые содержат пароль (токен) GitLab с необходимыми правами доступа к репозиториям. -- **Идентификатор**: `username` — реквизиты, которые содержат GitLab username. +- «Идентификатор»: `username` — реквизиты, которые содержат GitLab username. -**Действие «Обновление сервиса из шаблона»:** +Действие «Обновление сервиса из шаблона»: -- **Идентификатор**: `password` — реквизиты, которые содержат пароль (токен) GitLab с необходимыми правами доступа к репозиториям. +- «Идентификатор»: `password` — реквизиты, которые содержат пароль (токен) GitLab с необходимыми правами доступа к репозиториям. -- **Идентификатор**: `username` — реквизиты, которые содержат GitLab username. +- «Идентификатор»: `username` — реквизиты, которые содержат GitLab username. ## Процесс -> **Процессы** — механизм автоматизации сложных бизнес-процессов, который позволяет создавать визуальные схемы выполнения действий с поддержкой последовательного или параллельного выполнения. Процессы объединяют несколько действий в единую цепочку выполнения. - -У вас должен быть создан процесс, который объединяет действия по созданию проекта в GitLab и создания сервиса из шаблона в единую последовательную автоматизированную цепочку. Процесс должен последовательно запускать создание проекта в GitLab, а затем создание репозитория из шаблона. Если процесса еще нет, [создайте его](#создание-процесса). +У вас должен быть создан процесс, который объединяет действия по созданию проекта в GitLab и созданию сервиса из шаблона в единую последовательную автоматизированную цепочку. Процесс должен последовательно запускать создание проекта в GitLab, а затем создание репозитория из шаблона. Если процесса ещё нет, [создайте его](#создание-процесса). Проверьте следующие настройки: -**Основная информация:** +Основная информация: - **Ресурс**: выбран ресурс «Сервисы» (или соответствующий ресурс, если он назван иначе). +- «Ресурс»: выбран ресурс «Сервисы» (или соответствующий ресурс, если он назван иначе). -**Конфигурация:** +Конфигурация: -> Названия действий могут отличаться в зависимости от ваших настроек. +{{< alert level="info" >}} +Названия действий могут отличаться в зависимости от ваших настроек. +{{< /alert >}} -Действия находится в следующей последовательности: +Действия находятся в следующей последовательности: 1. Start. 1. Создать проект в GitLab. @@ -683,23 +681,25 @@ values: {{ .template_values | nindent 4 }} ### Создание процесса -Для создания процесса перейдите в раздел «Самообслуживание» пункт «Процессы». Создайте новый процесс. Для этого справа вверху нажмите кнопку «Создать». +Для создания процесса перейдите в раздел «Самообслуживание», пункт «Процессы». Создайте новый процесс. Для этого справа вверху нажмите кнопку «Создать». Откроется окно по созданию нового процесса с различными вкладками. -**Основная информация:** +Основная информация: -- **Название**: [Укажите название ресурса]. +- «Название»: [Укажите название ресурса]. -- **Ресурс**: выберите ресурс «Сервисы» (или соответствующий ресурс, если он назван иначе). +- «Ресурс»: выберите ресурс «Сервисы» (или соответствующий ресурс, если он назван иначе). -- **Владелец**: [Укажите владельца]. +- «Владелец»: [Укажите владельца]. -- **Команда владелец**: [Укажите команду владелец]. +- «Команда владелец»: [Укажите команду владелец]. -**Конфигурация:** +Конфигурация: -> Названия задач и названия действий указываются в качестве примера. При необходимости укажите ваши. +{{< alert level="info" >}} +Названия задач и названия действий указываются в качестве примера. При необходимости укажите ваши. +{{< /alert >}} На вкладке «Конфигурация» настройте шаги процесса и их порядок выполнения: @@ -716,35 +716,35 @@ values: {{ .template_values | nindent 4 }} ## Автоматизация -> **Автоматизации** — механизм реагирования платформы на изменения спецификации сущностей. Автоматизации подписываются на события обновления сущностей ресурсов по определенным правилам (триггерам) и запускают выполнение действий, процессов или синхронизацию источников данных. - -У вас должна быть настроена автоматизация, которая запускает действие по созданию Merge Request для обновления сервисов при появлении новой версии шаблона. Автоматизация отслеживает изменения параметра «Последний тег» (или аналогичный) в сущностях ресурса «Шаблоны» (или аналогичный) и при обнаружении нового тега автоматически запускает действие «Обновление сервиса из шаблона» (или аналогичный) для всех связанных сервисов. Если автоматизации еще нет, [создайте её](#создание-автоматизации). +У вас должна быть настроена автоматизация, которая запускает действие по созданию Merge Request для обновления сервисов при появлении новой версии шаблона. Автоматизация отслеживает изменения параметра «Последний тег» (или аналогичный) в сущностях ресурса «Шаблоны» (или аналогичный) и при обнаружении нового тега автоматически запускает действие «Обновление сервиса из шаблона» (или аналогичный) для всех связанных сервисов. Если автоматизации ещё нет, [создайте её](#создание-автоматизации). Проверьте следующие настройки: -**Конфигурация:** +Конфигурация: -**Триггеры:** +Триггеры: -- **Ресурс**: выбран «Шаблоны» (или соответствующий ресурс, если он назван иначе) +- «Ресурс»: выбран «Шаблоны» (или соответствующий ресурс, если он назван иначе). -- **Условие**: указано `{{ ne .entity.properties.repository_last_tag "v1.0.0" }}` (или аналогичное, если проверка у вас настроена иначе). +- «Условие»: указано `{{ ne .entity.properties.repository_last_tag "v1.0.0" }}` (или аналогичное, если проверка у вас настроена иначе). -> **Примечание:** данное условие срабатывает каждый раз, когда параметр с идентификатором `repository_last_tag` в сущности ресурса «Шаблоны» (или аналогичным) не равен указанному значению (`v1.0.0`). Условие будет проверяться только один раз при изменении параметра `repository_last_tag`. Важно: если параметр «Последний тег» (или аналогичный) имеет другой идентификатор (например, `last_tag`), используйте его в условии: `{{ ne .entity.properties.last_tag "v1.0.0" }}` +{{< alert level="info" >}} +Данное условие срабатывает каждый раз, когда параметр с идентификатором `repository_last_tag` в сущности ресурса «Шаблоны» (или аналогичным) не равен указанному значению (`v1.0.0`). Условие будет проверяться только один раз при изменении параметра `repository_last_tag`. Если параметр «Последний тег» (или аналогичный) имеет другой идентификатор (например, `last_tag`), используйте его в условии: `{{ ne .entity.properties.last_tag "v1.0.0" }}`. +{{< /alert >}} -**Выполнение:** +Выполнение: -- **Тип выполнения**: выбрано «Действия». +- «Тип выполнения»: выбрано «Действия». -- **Объект выполнения**: выбрано действие «Обновление сервиса из шаблона» (или соответствующее действие, если оно названо иначе). +- «Объект выполнения»: выбрано действие «Обновление сервиса из шаблона» (или соответствующее действие, если оно названо иначе). -**Запускать выполнение для связанных ресурсов:** +Запускать выполнение для связанных ресурсов: Параметр «Запускать выполнение для связанных ресурсов» включён и настроены связи ресурса: -- **Ресурс**: выбрано «Шаблоны» (или соответствующий ресурс). +- «Ресурс»: выбрано «Шаблоны» (или соответствующий ресурс). -- **Связь**: выбрана связь «Шаблоны-Сервисы» (или название вашей связи, если оно отличается). +- «Связь»: выбрана связь «Шаблоны-Сервисы» (или название вашей связи, если оно отличается). ### Создание автоматизации @@ -752,60 +752,66 @@ values: {{ .template_values | nindent 4 }} Откроется окно по созданию новой автоматизации с различными вкладками. -**Основная информация:** +Основная информация: -- **Название**: [Укажите название автоматизации]. +- «Название»: [Укажите название автоматизации]. -- **Владелец**: [Укажите владельца]. +- «Владелец»: [Укажите владельца]. -- **Команда владелец**: [Укажите команду владелец]. +- «Команда владелец»: [Укажите команду владелец]. -**Конфигурация:** +Конфигурация: На вкладке «Конфигурация» настройте логику запуска автоматизации. -**Триггеры:** +Триггеры: Триггер определяет, когда автоматизация должна запускаться. Добавьте новый триггер: -- **Ресурс**: выберите «Шаблоны» (или соответствующий ресурс, если он назван иначе). +- «Ресурс»: выберите «Шаблоны» (или соответствующий ресурс, если он назван иначе). + +- «Условие»: укажите `{{ ne .entity.properties.repository_last_tag "v1.0.0" }}`. -- **Условие**: укажите `{{ ne .entity.properties.repository_last_tag "v1.0.0" }}`. **Важно:** используется идентификатор параметра ресурса «Шаблоны» (или аналогичного), который хранит информацию о последнем теге git репозитория. Если идентификатор отличается, используйте корректный. + {{< alert level="warning" >}} + Используется идентификатор параметра ресурса «Шаблоны» (или аналогичного), который хранит информацию о последнем теге git-репозитория. Если идентификатор отличается, используйте корректный. + {{< /alert >}} -Данное условие срабатывает каждый раз, когда параметр `repository_last_tag` в сущности ресурса «Шаблоны» (или аналогичном) не равен указанному значению (`v1.0.0`). Условие будет проверяться только один раз при изменении параметра `repository_last_tag`. Важно: если параметр «Последний тег» имеет другой идентификатор (например, `last_tag`), используйте его в условии: `{{ ne .entity.properties.last_tag "v1.0.0" }}`. +Данное условие срабатывает каждый раз, когда параметр `repository_last_tag` в сущности ресурса «Шаблоны» (или аналогичном) не равен указанному значению (`v1.0.0`). Условие будет проверяться только один раз при изменении параметра `repository_last_tag`. Если параметр «Последний тег» имеет другой идентификатор (например, `last_tag`), используйте его в условии: `{{ ne .entity.properties.last_tag "v1.0.0" }}`. -> **Примечание:** если планируется создание нескольких автоматизаций, каждая из которых должна реагировать на изменения параметров сущностей одного и того же ресурса, рекомендуется указывать условие в формате `{{ and (ne .entity.properties.repository_last_tag "v1.0.0") (eq .entity.slug "example") }}` для того, чтобы дополнительно фильтровать, какая из автоматизаций будет запускаться в каждом конкретном случае. Без добавления условия `(eq .entity.slug "example")` каждая из автоматизаций будет реагировать на изменения каждой сущности. +{{< alert level="info" >}} +Если планируется создание нескольких автоматизаций, каждая из которых должна реагировать на изменения параметров сущностей одного и того же ресурса, рекомендуется указывать условие в формате `{{ and (ne .entity.properties.repository_last_tag "v1.0.0") (eq .entity.slug "example") }}` для того, чтобы дополнительно фильтровать, какая из автоматизаций будет запускаться в каждом конкретном случае. Без добавления условия `(eq .entity.slug "example")` каждая из автоматизаций будет реагировать на изменения каждой сущности. +{{< /alert >}} -**Выполнение:** +Выполнение: Настройте выполнение действия: -- **Тип выполнения**: выберите «Действия». +- «Тип выполнения»: выберите «Действия». -- **Объект выполнения**: выберите действие «Обновление сервиса из шаблона» (или соответствующее действие, если оно названо иначе). +- «Объект выполнения»: выберите действие «Обновление сервиса из шаблона» (или соответствующее действие, если оно названо иначе). -**Запускать выполнение для связанных ресурсов:** +Запускать выполнение для связанных ресурсов: Автоматизация просматривает изменения в сущности ресурса «Шаблоны», но действие будет обновлять сущности ресурса «Сервисы», которые связаны с шаблоном, в котором произошло обновление параметра `repository_last_tag`. Необходимо включить параметр «Запускать выполнение для связанных ресурсов» и настроить связи ресурса: -- **Ресурс**: выберите «Шаблоны» (или соответствующий ресурс). +- «Ресурс»: выберите «Шаблоны» (или соответствующий ресурс). -- **Связь**: выберите связь «Шаблоны-Сервисы» (или название вашей связи, если оно отличается). +- «Связь»: выберите связь «Шаблоны-Сервисы» (или название вашей связи, если оно отличается). -При обновлении тега в ресурсе «Шаблоны» (или соответствующий ресурс) система найдет все связанные с этим шаблоном сущности ресурса «Сервисы» (или соответствующий ресурс) и запустит для каждой из них действие «Обновление сервиса из шаблона» (или аналогичное), создавая Merge Request с изменениями из новой версии шаблона. +При обновлении тега в ресурсе «Шаблоны» (или соответствующий ресурс) система найдёт все связанные с этим шаблоном сущности ресурса «Сервисы» (или соответствующий ресурс) и запустит для каждой из них действие «Обновление сервиса из шаблона» (или аналогичное), создавая Merge Request с изменениями из новой версии шаблона. ## Создание сервиса -Настройка платформы для возможности создания сервисов на основе шаблона и последующим их автоматическим обновлением при выпуске новой версии шаблона завершена. +Настройка платформы для создания сервисов на основе шаблона с последующим автоматическим обновлением при выпуске новой версии шаблона завершена. Для создания сервиса необходимо следующее: 1. Перейдите во вкладку «Каталог» в ресурс «Сервисы». 1. В правом верхнем углу нажмите кнопку «Создать». -1. В открывшемся окне во вкладке «Основная информация» заполните требуемые поля. Если настройки были произведены в соответствии с данной инструкцией, заполнение данных в других вкладках не требуются. Данные будут заполнены автоматически в дальнейшем. -1. Справа от появившейся записи о новом сервисе, нажмите на синюю кнопку с тремя вертикальными точками и выберите пункт «Запустить процесс». +1. В открывшемся окне во вкладке «Основная информация» заполните требуемые поля. Если настройки были произведены в соответствии с данной инструкцией, заполнение данных в других вкладках не требуется. Данные будут заполнены автоматически в дальнейшем. +1. Справа от появившейся записи о новом сервисе нажмите на синюю кнопку с тремя вертикальными точками и выберите пункт «Запустить процесс». 1. В выпадающем списке выберите процесс `Создание сервиса из шаблона`. 1. При необходимости заполните переменные шаблона и запустите процесс. -1. При корректных настройках сервис будет создан. При наличии обновлений шаблона для сервиса будут формироваться MR с изменениями. Проверить корректность создания можно перейдя в него и открыв вкладку «Запуски действий». Все [действия](../actions/overview/) должны быть в статусе `Success`. +1. При корректных настройках сервис будет создан. При наличии обновлений шаблона для сервиса будут формироваться MR с изменениями. Проверить корректность создания можно, перейдя в него и открыв вкладку «Запуски действий». Все [действия](../actions/overview/) должны быть в статусе `Success`. diff --git a/content/documentation/admin/external-services.ru.md b/content/documentation/admin/external-services.ru.md index bffb6080..9a156478 100644 --- a/content/documentation/admin/external-services.ru.md +++ b/content/documentation/admin/external-services.ru.md @@ -1,8 +1,6 @@ --- title: Внешние сервисы menuTitle: Внешние сервисы -d8Edition: ee -moduleStatus: experimental --- Внешние сервисы — это механизм, позволяющий настраивать параметры авторизации для внешних инфраструктурных систем (например, GitLab, Kubernetes, DefectDojo и др.). @@ -15,15 +13,15 @@ moduleStatus: experimental | Название параметра | Описание | |------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| **Название** | Название внешнего сервиса — отображается в интерфейсе | -| **Идентификатор** | Уникальный человекочитаемый идентификатор (slug) | -| **Владелец** | Пользователь, ответственный за внешний сервис | -| **Команда-владелец** | Команда, которой принадлежит внешний сервис | -| **URL** | Базовый URL для обращения к внешнему сервису | -| **Учётные данные** | Список доступных учётных данных (например, токенов), которые могут быть подставлены в запросы | -| **Заголовки** | HTTP-заголовки, автоматически добавляемые к запросам | -| **Отключить проверку SSL** | Отключение проверки SSL-сертификата внешнего сервиса (например, при использовании самоподписанных сертификатов). Рекомендуется вместо этого добавить нужные сертификаты в [«доверенные»](../trusted-certificates/) | -| **Системная учётная запись** | Учётная запись, которая будет использоваться для периодически запускаемых заданий: источников данных, проверок статуса и т.д. | +| «Название» | Название внешнего сервиса — отображается в интерфейсе | +| «Идентификатор» | Уникальный человекочитаемый идентификатор (slug) | +| «Владелец» | Пользователь, ответственный за внешний сервис | +| «Команда-владелец» | Команда, которой принадлежит внешний сервис | +| «URL» | Базовый URL для обращения к внешнему сервису | +| «Учётные данные» | Список доступных учётных данных (например, токенов), которые могут быть подставлены в запросы | +| «Заголовки» | HTTP-заголовки, автоматически добавляемые к запросам | +| «Отключить проверку SSL» | Отключение проверки SSL-сертификата внешнего сервиса (например, при использовании самоподписанных сертификатов). Рекомендуется вместо этого добавить нужные сертификаты в [«доверенные»](../trusted-certificates/) | +| «Системная учётная запись» | Учётная запись, которая будет использоваться для периодически запускаемых заданий: источников данных, проверок статуса и т. д | ## Использование внешних сервисов @@ -37,7 +35,7 @@ moduleStatus: experimental Подключение сервиса выполняется на вкладке «Авторизация» в настройках соответствующего объекта. Для каждого объекта можно в явном виде переопределить параметры, заданные во внешнем сервисе. -Например, если внешний сервис содержит токен авторизации, но в конкретном действии используются другие учетные данные — можно указать альтернативные значения. В этом случае будет переопределён **только** указанный параметр, остальные значения будут взяты из конфигурации внешнего сервиса. +Например, если внешний сервис содержит токен авторизации, но в конкретном действии используются другие учётные данные, можно указать альтернативные значения. В этом случае будет переопределён только указанный параметр, остальные значения будут взяты из конфигурации внешнего сервиса. ## Особенности подключения к объектам @@ -45,7 +43,7 @@ moduleStatus: experimental - К одному действию можно подключить несколько внешних сервисов. - Можно выбрать сервис по умолчанию. -- Параметр системная учетная запись не используется в действиях. +- Параметр «Системная учётная запись» не используется в действиях. - При запуске действия можно выбрать, для какого внешнего сервиса оно будет запускаться. Если ни один сервис не выбран, будет использоваться сервис по умолчанию. Если сервис по умолчанию не задан, то будет использоваться первый внешний сервис в списке. ### Виджеты @@ -53,7 +51,7 @@ moduleStatus: experimental - Для одного виджета также поддерживается подключение нескольких внешних сервисов. - Один из них может быть выбран как используемый по умолчанию. - В последующих релизах будет добавлена возможность изменения сервиса во время просмотра виджета. -- Параметр системная учетная запись не используется в виджетах. +- Параметр «Системная учётная запись» не используется в виджетах. ### Источники данных @@ -67,23 +65,23 @@ moduleStatus: experimental ## Заголовки авторизации для внешних сервисов -При настройке внешних сервисов необходимо указать соответствующие HTTP-заголовки для авторизации. Ниже приведен список внешних сервисов, поддерживаемых платформой, с указанием типа авторизации и необходимых заголовков. +При настройке внешних сервисов необходимо указать соответствующие HTTP-заголовки для авторизации. Ниже приведён список внешних сервисов, поддерживаемых платформой, с указанием типа авторизации и необходимых заголовков. {{< alert level="info" >}} -Приведенные ниже примеры демонстрируют возможные способы авторизации для каждого сервиса. В некоторых сервисах могут использоваться другие механизмы. Платформа поддерживает все варианты, которые можно передать через HTTP-заголовки. +Приведённые ниже примеры демонстрируют возможные способы авторизации для каждого сервиса. В некоторых сервисах могут использоваться другие механизмы. Платформа поддерживает все варианты, которые можно передать через HTTP-заголовки. {{< /alert >}} ### CodeScoring -**Тип авторизации:** API Token. +Тип авторизации: API Token. -**Заголовки:** +Заголовки: | Заголовок | Формат значения | |-----------|-----------------| | `Authorization` | `<токен>` | -**Пример:** +Пример: ```sh Authorization: <ваш-api-token> @@ -91,15 +89,15 @@ Authorization: <ваш-api-token> ### DefectDojo -**Тип авторизации:** API v2 Key Token. +Тип авторизации: API v2 Key Token. -**Заголовки:** +Заголовки: | Заголовок | Формат значения | |-----------|-----------------| | `Authorization` | `Token <токен>` | -**Пример:** +Пример: ```sh Authorization: Token <ваш-defectdojo-api-v2-key> @@ -107,15 +105,15 @@ Authorization: Token <ваш-defectdojo-api-v2-key> ### Bitbucket -**Тип авторизации:** Bearer Token (Personal Access Token). +Тип авторизации: Bearer Token (Personal Access Token). -**Заголовки:** +Заголовки: | Заголовок | Формат значения | |-----------------|------------------| | `Authorization` | `Bearer <токен>` | -**Пример:** +Пример: ```sh Authorization: Bearer <ваш-bitbucket-personal-access-token> @@ -123,15 +121,15 @@ Authorization: Bearer <ваш-bitbucket-personal-access-token> ### Docker Registry -**Тип авторизации:** Basic Authentication. +Тип авторизации: Basic Authentication. -**Заголовки:** +Заголовки: | Заголовок | Формат значения | |-----------|-----------------| | `Authorization` | `Basic ` | -**Пример:** +Пример: 1. Сформируйте строку `username:password`. 1. Закодируйте её в Base64: `echo "username:password" | base64`. @@ -143,15 +141,15 @@ Authorization: Basic ### GitLab -**Тип авторизации:** Personal Access Token или Project Access Token. +Тип авторизации: Personal Access Token или Project Access Token. -**Заголовки:** +Заголовки: | Заголовок | Формат значения | |-----------|-----------------| | `Private-Token` | `<токен>` | -**Пример:** +Пример: ```sh Private-Token: <ваш-gitlab-token> @@ -161,15 +159,15 @@ Private-Token: <ваш-gitlab-token> ### GitHub -**Тип авторизации:** Personal Access Token. +Тип авторизации: Personal Access Token. -**Заголовки:** +Заголовки: | Заголовок | Формат значения | |-----------------|--------------------| | `Authorization` | `Bearer <токен>` | -**Пример:** +Пример: ```sh Authorization: Bearer <ваш-github-token> @@ -179,15 +177,15 @@ Authorization: Bearer <ваш-github-token> ### Harbor -**Тип авторизации:** Basic Authentication. +Тип авторизации: Basic Authentication. -**Заголовки:** +Заголовки: | Заголовок | Формат значения | |-----------|-----------------| | `Authorization` | `Basic ` | -**Пример:** +Пример: 1. Сформируйте строку `username:password`. 1. Закодируйте её в Base64: `echo "username:password" | base64`. @@ -199,15 +197,15 @@ Authorization: Basic ### Jenkins -**Тип авторизации:** Basic Authentication (Username/Password). +Тип авторизации: Basic Authentication (Username/Password). -**Заголовки:** +Заголовки: | Заголовок | Формат значения | |-----------|-----------------| | `Authorization` | `Basic ` | -**Пример:** +Пример: 1. Сформируйте строку `username:password`, где: - `username` — имя пользователя в Jenkins. @@ -221,15 +219,15 @@ Authorization: Basic ### Jira -**Тип авторизации:** Basic Authentication. +Тип авторизации: Basic Authentication. -**Заголовки:** +Заголовки: | Заголовок | Формат значения | |-----------|-----------------| | `Authorization` | `Basic ` | -**Пример:** +Пример: 1. Сформируйте строку `username:password`. 1. Закодируйте её в Base64: `echo "username:password" | base64`. @@ -241,15 +239,15 @@ Authorization: Basic ### Kaiten -**Тип авторизации:** API Token. +Тип авторизации: API Token. -**Заголовки:** +Заголовки: | Заголовок | Формат значения | |-----------|-----------------| | `Authorization` | `Bearer <токен>` | -**Пример:** +Пример: ```sh Authorization: Bearer <ваш-kaiten-api-token> @@ -257,15 +255,15 @@ Authorization: Bearer <ваш-kaiten-api-token> ### Kubernetes -**Тип авторизации:** Bearer Token (Service Account Token или User Token). +Тип авторизации: Bearer Token (Service Account Token или User Token). -**Заголовки:** +Заголовки: | Заголовок | Формат значения | |-----------|-----------------| | `Authorization` | `Bearer <токен>` | -**Пример:** +Пример: ```sh Authorization: Bearer <ваш-kubernetes-token> @@ -273,15 +271,15 @@ Authorization: Bearer <ваш-kubernetes-token> ### Nexus -**Тип авторизации:** Basic Authentication. +Тип авторизации: Basic Authentication. -**Заголовки:** +Заголовки: | Заголовок | Формат значения | |-----------|-----------------| | `Authorization` | `Basic ` | -**Пример:** +Пример: 1. Сформируйте строку `username:password`. 1. Закодируйте её в Base64: `echo "username:password" | base64`. @@ -293,15 +291,15 @@ Authorization: Basic ### OpenSearch -**Тип авторизации:** Basic Authentication. +Тип авторизации: Basic Authentication. -**Заголовки:** +Заголовки: | Заголовок | Формат значения | |-----------|-----------------| | `Authorization` | `Basic ` | -**Пример:** +Пример: 1. Сформируйте строку `username:password`. 1. Закодируйте её в Base64: `echo "username:password" | base64`. @@ -313,21 +311,21 @@ Authorization: Basic ### Prometheus -**Тип авторизации:** Bearer Token или Basic Authentication. +Тип авторизации: Bearer Token или Basic Authentication. -**Заголовки:** +Заголовки: | Заголовок | Формат значения | |-----------|-----------------| | `Authorization` | `Bearer <токен>` или `Basic ` | -**Пример Bearer Token:** +Пример Bearer Token: ```sh Authorization: Bearer <ваш-токен> ``` -**Пример Basic Authentication:** +Пример Basic Authentication: ```sh Authorization: Basic @@ -335,15 +333,15 @@ Authorization: Basic ### SonarQube -**Тип авторизации:** Bearer Token. +Тип авторизации: Bearer Token. -**Заголовки:** +Заголовки: | Заголовок | Формат значения | |-----------|-----------------| | `Authorization` | `Bearer <токен>` | -**Пример:** +Пример: ```sh Authorization: Bearer <ваш-токен> @@ -351,15 +349,15 @@ Authorization: Bearer <ваш-токен> ### Vault -**Тип авторизации:** Token Authentication. +Тип авторизации: Token Authentication. -**Заголовки:** +Заголовки: | Заголовок | Формат значения | |-----------|-----------------| | `X-Vault-Token` | `<токен>` | -**Пример:** +Пример: ```sh X-Vault-Token: <ваш-vault-token> diff --git a/content/documentation/admin/healthchecks/overview.ru.md b/content/documentation/admin/healthchecks/overview.ru.md index 667bdf18..44ad4cde 100644 --- a/content/documentation/admin/healthchecks/overview.ru.md +++ b/content/documentation/admin/healthchecks/overview.ru.md @@ -5,27 +5,31 @@ weight: 10 Для каждого ресурса можно настроить набор правил, по которым будет определяться статус его сущностей. Возможно добавление произвольного количества правил. Поле `Условие` определяет, должны ли выполняться: -- все правила (**AllOf**) -- хотя бы одно из них (**AnyOf**). +- все правила (`AllOf`); +- хотя бы одно из них (`AnyOf`). -> Если хотя бы одна из проверок завершилась с ошибкой, то статус сущности будет выставлен в **error**, независимо от результата остальных проверок и условия. +{% alert level="info" %} +Если хотя бы одна из проверок завершилась с ошибкой, то статус сущности будет выставлен в `error` независимо от результата остальных проверок и условия. +{% endalert %} Проверка выполнения каждого правила производится раз в минуту. Логи последних нескольких проверок доступны в меню ресурса в разделе «Проверки статуса». Возможны четыре варианта статуса: -- **healthy** — правила заданы, и параметры сущности соответствуют этим правилам; -- **unhealthy** — правила заданы, но параметры сущности им не соответствуют; -- **unknown** — правила не заданы либо проверка не может быть выполнена по каким-либо причинам; -- **error** — во время выполнения хотя бы одного из правил произошла ошибка. +- `healthy` — правила заданы, и параметры сущности соответствуют этим правилам; +- `unhealthy` — правила заданы, но параметры сущности им не соответствуют; +- `unknown` — правила не заданы либо проверка не может быть выполнена по каким-либо причинам; +- `error` — во время выполнения хотя бы одного из правил произошла ошибка. -Для каждой сущности, при клике на плашку со статусом, открывается таблица с результатами выполнения правил и дополнительной информацией. +Для каждой сущности при клике на плашку со статусом открывается таблица с результатами выполнения правил и дополнительной информацией. -> Событие **ENTITY_UPDATED** генерируется только при изменении статуса сущности. +{% alert level="info" %} +Событие `ENTITY_UPDATED` генерируется только при изменении статуса сущности. +{% endalert %} ### Property -Правило типа **Property** проверяет, соответствует ли конкретный параметр сущности заданному шаблонному выражению. +Правило типа `Property` проверяет, соответствует ли конкретный параметр сущности заданному шаблонному выражению. Конфигурация правила состоит из одного параметра — выражения. Для описания выражения используется синтаксис [Go template](https://developer.hashicorp.com/nomad/docs/reference/go-template-syntax). diff --git a/content/documentation/admin/healthchecks/types.ru.md b/content/documentation/admin/healthchecks/types.ru.md index 35a35436..afb16151 100644 --- a/content/documentation/admin/healthchecks/types.ru.md +++ b/content/documentation/admin/healthchecks/types.ru.md @@ -4,7 +4,7 @@ title: Типы проверок статуса ## Prometheus -Правило типа **Prometheus** проверяет, соответствует ли указанная метрика заданному пороговому значению. В конфигурации указывается запрос PromQL, который должен возвращать результат типа Scalar или Vector с одним значением. +Правило типа Prometheus проверяет, соответствует ли указанная метрика заданному пороговому значению. В конфигурации указывается запрос PromQL, который должен возвращать результат типа Scalar или Vector с одним значением. Поддерживается шаблонизация, например: @@ -22,7 +22,9 @@ avg(ingress_nginx_detail_request_seconds_sum{location="/{{ .entity.slug }}"}) | Оператор | Оператор сравнения между результатом запроса и пороговым значением | Equal, NotEqual, LessThan, GreaterThan | | Порог | Пороговое значение для сравнения с результатом запроса | | -> Для проверки каждой сущности выполняется отдельный запрос к Prometheus. Рекомендуется учитывать это при планировании нагрузки на систему. +{{< alert level="info" >}} +Для проверки каждой сущности выполняется отдельный запрос к Prometheus. Рекомендуется учитывать это при планировании нагрузки на систему. +{{< /alert >}} ### Авторизация @@ -30,7 +32,7 @@ avg(ingress_nginx_detail_request_seconds_sum{location="/{{ .entity.slug }}"}) ## Gitlab Pipeline -Правило типа **GitlabPipeline** проверяет, соответствует ли статус последнего pipeline в Gitlab для выбранного Ref (ветка или тег) заданному статусу. +Правило типа `GitlabPipeline` проверяет, соответствует ли статус последнего pipeline в Gitlab для выбранного Ref (ветка или тег) заданному статусу. Во всех текстовых полях поддерживается шаблонизация, например, при подобном выражении в поле `Ref`: @@ -48,7 +50,9 @@ avg(ingress_nginx_detail_request_seconds_sum{location="/{{ .entity.slug }}"}) | Ref | Ветка или тег для которых будет искаться последний pipeline | | | Статус | Статус pipeline, который будет считаться успешным | created, waiting_for_resource, preparing, pending, running, success, failed, canceled, skipped, manual, scheduled | -> Для проверки каждой сущности выполняется отдельный запрос к Gitlab. Рекомендуется учитывать это при планировании нагрузки на систему. +{{< alert level="info" >}} +Для проверки каждой сущности выполняется отдельный запрос к Gitlab. Рекомендуется учитывать это при планировании нагрузки на систему. +{{< /alert >}} ### Авторизация @@ -56,7 +60,7 @@ avg(ingress_nginx_detail_request_seconds_sum{location="/{{ .entity.slug }}"}) ## DefectDojo Findings -Правило типа **DefectDojoFindings** выполняет проверку по количеству активных уязвимостей различной критичности (severity) для заданного продукта в DefectDojo. +Правило типа `DefectDojoFindings` выполняет проверку по количеству активных уязвимостей различной критичности (severity) для заданного продукта в DefectDojo. Проверка проводится по условиям в блоке `conditions`, где можно указать ожидаемое количество уязвимостей для каждой severity и оператор сравнения (например, Critical < 5). @@ -99,7 +103,7 @@ conditions: ## CodeScoring Vulnerabilities -Правило типа **CodeScoringVulnerabilities** выполняет проверку по количеству уязвимостей различной критичности (severity) для заданного проекта в CodeScoring. +Правило типа `CodeScoringVulnerabilities` выполняет проверку по количеству уязвимостей различной критичности (severity) для заданного проекта в CodeScoring. Проверка проводится по условиям в блоке `conditions`, где можно указать ожидаемое количество уязвимостей для каждой severity и оператор сравнения. Поддерживается проверка как по CVSS2, так и по CVSS3 метрикам. @@ -145,7 +149,7 @@ conditions: ## SonarQube Metrics -Правило типа **SonarqubeMetrics** выполняет проверку по метрикам проекта в SonarQube на основании заданных условий. +Правило типа `SonarqubeMetrics` выполняет проверку по метрикам проекта в SonarQube на основании заданных условий. Проверка выполняется с использованием REST API вызова SonarQube `/api/measures/component`, где сравниваются текущие значения указанных метрик c ожидаемыми значениями, заданными в разделе «Условия». @@ -159,9 +163,9 @@ conditions: | Название | Обязательность | Описание | Возможные значения | |---------------------|----------------|------------------------------------------------------------|---------------------| -| Ключ проекта | **Да** | Идентификатор проекта в SonarQube | | +| Ключ проекта | Да | Идентификатор проекта в SonarQube | | | Ветка | Нет | Ветка проекта для которой будут браться метрики | | -| Условия | **Да** | Условия для сравнения метрик в SonarQube | | +| Условия | Да | Условия для сравнения метрик в SonarQube | | #### Условия @@ -191,7 +195,7 @@ conditions: ## SonarQube Quality Gate -Правило типа **SonarqubeQualityGate** проверяет статус Quality Gate проекта в SonarQube. Проверка выполняется с использованием REST API вызова SonarQube `/api/qualitygates/project_status`. +Правило типа `SonarqubeQualityGate` проверяет статус Quality Gate проекта в SonarQube. Проверка выполняется с использованием REST API вызова SonarQube `/api/qualitygates/project_status`. Правило возвращает `true` (выполняется), если Quality Gate проекта имеет статус `OK`, и `false` (не выполняется) во всех остальных случаях (статусы `WARN`, `ERROR`, `NONE`). @@ -205,10 +209,12 @@ conditions: | Название | Обязательность | Описание | Возможные значения | |---------------------|----------------|------------------------------------------------------------|---------------------| -| Ключ проекта | **Да** | Идентификатор проекта в SonarQube | | +| Ключ проекта | Да | Идентификатор проекта в SonarQube | | | Ветка | Нет | Ветка проекта для которой будет проверяться Quality Gate. Если не указана, проверяется основная ветка | | -> Для проверки каждой сущности выполняется отдельный запрос к SonarQube. Рекомендуется учитывать это при планировании нагрузки на систему. +{{< alert level="info" >}} +Для проверки каждой сущности выполняется отдельный запрос к SonarQube. Рекомендуется учитывать это при планировании нагрузки на систему. +{{< /alert >}} ### Авторизация @@ -216,7 +222,7 @@ conditions: ## URL -Правило типа **URL** проверяет доступность HTTP/HTTPS-эндпоинта: отправляется запрос с заданными параметрами, результат оценивается по одному или нескольким **условиям** — выражениям Go template. В условиях можно проверять код ответа, заголовки, тело ответа и параметры сущности. +Правило типа `URL` проверяет доступность HTTP/HTTPS-эндпоинта: отправляется запрос с заданными параметрами, результат оценивается по одному или нескольким условиям — выражениям Go template. В условиях можно проверять код ответа, заголовки, тело ответа и параметры сущности. Во всех строковых полях (URL, тело запроса, заголовки) доступна шаблонизация с подстановкой данных сущности (`.entity`), например: `{{ .entity.slug }}`. @@ -224,12 +230,12 @@ conditions: | Название | Обязательность | Описание | Примеры | |----------------------------|-----------------|----------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------| -| URL | **Да** | Полный адрес, по которому выполняется запрос | `https://example.com` | +| URL | Да | Полный адрес, по которому выполняется запрос | `https://example.com` | | Метод | Нет | HTTP-метод запроса | GET, POST | | Query | Нет | Значение query, подставляемое в исходящий запрос | | | Сохранять детали | Нет | Если включено — в таблице проверок сохраняются и отображаются тело ответа и статус (код, заголовки). Если выключено — только условие, результат и ошибка | | -| Условия | Нет | Выражения Go template, по которым оценивается ответ | см. ниже | -| При нескольких условиях | Нет | **AllOf** — должны выполниться все условия; **AnyOf** — достаточно одного | AllOf, AnyOf | +| Условия | Нет | Выражения Go template, по которым оценивается ответ | См. ниже | +| При нескольких условиях | Нет | `AllOf` — должны выполниться все условия; `AnyOf` — достаточно одного | AllOf, AnyOf | | Тело запроса | Нет | Тело запроса в формате YAML. После подстановки шаблонов преобразуется в JSON и отправляется | | Если условия не заданы, по умолчанию используется проверка кода ответа 200: `{{ eq .status.code 200 }}`. @@ -238,9 +244,9 @@ conditions: В условиях доступны: -- **`.status`** — данные ответа: `.status.code` (код HTTP), `.status.status` (строка статуса), `.status.headers` (заголовки), `.status.contentLength`. **`.status.headers`** — карта «название заголовка → массив значений» (названия в нижнем регистре). Пример: первый элемент заголовка — `{{ index (index .status.headers "content-type") 0 }}`; перебор — `{{ range index .status.headers "set-cookie" }}...{{ end }}`. -- **`.response`** — тело ответа с приведёнными типами (для JSON-ответа). -- **`.entity`** — параметры проверяемой сущности. +- `.status` — данные ответа: `.status.code` (код HTTP), `.status.status` (строка статуса), `.status.headers` (заголовки), `.status.contentLength`. `.status.headers` — карта «название заголовка → массив значений» (названия в нижнем регистре). Пример: первый элемент заголовка — `{{ index (index .status.headers "content-type") 0 }}`; перебор — `{{ range index .status.headers "set-cookie" }}...{{ end }}`. +- `.response` — тело ответа с приведёнными типами (для JSON-ответа). +- `.entity` — параметры проверяемой сущности. Примеры условий: diff --git a/content/documentation/admin/install.md b/content/documentation/admin/install.md index 54710398..137d50f9 100644 --- a/content/documentation/admin/install.md +++ b/content/documentation/admin/install.md @@ -26,7 +26,7 @@ spec: After installation, the Deckhouse Development Platform web UI will be available at `https://ddp.`. -When you do not specify `postgres` and `redis` sections, the platform deploys **internal** PostgreSQL and Redis instances inside the cluster. This scenario is not recommended for production and is suitable only for testing and pilot use; for production, use [external resources](#installation-with-external-instances). +When you do not specify `postgres` and `redis` sections, the platform deploys internal PostgreSQL and Redis instances inside the cluster. This scenario is not recommended for production and is suitable only for testing and pilot use; for production, use [external resources](#installation-with-external-instances). ### Configuring internal instances (optional) diff --git a/content/documentation/admin/install.ru.md b/content/documentation/admin/install.ru.md index d367f0f8..0e5f7977 100644 --- a/content/documentation/admin/install.ru.md +++ b/content/documentation/admin/install.ru.md @@ -3,11 +3,11 @@ title: Установка weight: 11 --- -Deckhouse Development Platform можно установить двумя способами: с [внешними инстансами](#установка-с-внешними-инстансами) PostgreSQL и Redis (подключение к уже развёрнутым базам данных вне кластера) или с [внутренними инстансами](#установка-с-внутренними-инстансами) (развёртывание PostgreSQL и Redis внутри кластера). Внешние инстансы рекомендуются для production, внутренние подходят для тестов и пилотной эксплуатации. +Deckhouse Development Platform (DDP) можно установить двумя способами: с [внешними инстансами](#установка-с-внешними-инстансами) PostgreSQL и Redis (подключение к уже развёрнутым базам данных вне кластера) или с [внутренними инстансами](#установка-с-внутренними-инстансами) (развёртывание PostgreSQL и Redis внутри кластера). Внешние инстансы рекомендуются для production, внутренние подходят для тестов и пилотной эксплуатации. ## Установка с внутренними инстансами -Для установки Deckhouse Development Platform включите модуль `development-platform` в вашем Kubernetes-кластере под управлением Deckhouse Kubernetes Platform. Для этого можно использовать [ModuleConfig](/products/kubernetes-platform/documentation/v1/reference/api/cr.html#moduleconfig) с минимальным количеством настроек: +Для установки DDP включите модуль `development-platform` в вашем кластере Kubernetes под управлением Deckhouse Kubernetes Platform. Для этого можно использовать [ModuleConfig](/products/kubernetes-platform/documentation/v1/reference/api/cr.html#moduleconfig) с минимальным количеством настроек: ```yaml apiVersion: deckhouse.io/v1alpha1 @@ -21,12 +21,12 @@ spec: rbac: superAdminEmail: admin@deckhouse.io # Email супер-администратора, который будет иметь полный доступ к конфигурации платформы. Может быть изменен в любой момент. security: - secretKey: "16charssecretkey" # Секретный ключ для шифрования приватных данных. При изменении потребуется перегенерация токенов доступа к API платформы и повторное заполнение учетных данных пользователями. + secretKey: "16charssecretkey" # Секретный ключ для шифрования приватных данных. При изменении потребуется перегенерация токенов доступа к API платформы и повторное заполнение учётных данных пользователями. ``` -После установки веб-интерфейс Deckhouse Development Platform будет доступен по адресу `https://ddp.<ваш домен>`. +После установки веб-интерфейс DDP будет доступен по адресу `https://ddp.<ваш домен>`. -При развёртывании без указания секций `postgres` и `redis` платформа разворачивает **внутренние** инстансы PostgreSQL и Redis внутри кластера. Такой сценарий не рекомендуется для production и подходит только для тестов и пилотной эксплуатации; для промышленной эксплуатации используйте [внешние ресурсы](#установка-с-внешними-инстансами). +При развёртывании без указания секций `postgres` и `redis` платформа разворачивает внутренние инстансы PostgreSQL и Redis внутри кластера. Такой сценарий не рекомендуется для production и подходит только для тестов и пилотной эксплуатации; для промышленной эксплуатации используйте [внешние ресурсы](#установка-с-внешними-инстансами). ### Настройка внутренних инстансов (опционально) diff --git a/content/documentation/admin/overview.ru.md b/content/documentation/admin/overview.ru.md index b39574ed..d69e72d6 100644 --- a/content/documentation/admin/overview.ru.md +++ b/content/documentation/admin/overview.ru.md @@ -3,4 +3,4 @@ title: Обзор weight: 10 --- -Данный документ представляет собой руководство администратора Deckhouse Development Platform и является частью эксплуатационной документации продукта Deckhouse Development Platform. +Данный документ представляет собой руководство администратора Deckhouse Development Platform (DDP) и является частью эксплуатационной документации продукта. diff --git a/content/documentation/admin/processes.ru.md b/content/documentation/admin/processes.ru.md index d83de931..f3c3ec8f 100644 --- a/content/documentation/admin/processes.ru.md +++ b/content/documentation/admin/processes.ru.md @@ -1,8 +1,6 @@ --- title: Процессы menuTitle: Процессы -d8Edition: ee -moduleStatus: experimental --- Процессы — это механизм автоматизации сложных бизнес-сценариев, который позволяет создавать визуальные схемы выполнения действий с поддержкой условной логики, параллельного выполнения и обработки ошибок. @@ -13,14 +11,14 @@ moduleStatus: experimental Процесс состоит из различных типов элементов: -* **Начало** — точка входа в процесс. -* **Задача** — выполнение конкретного действия. -* **Эксклюзивный шлюз** — условное ветвление. -* **Параллельный шлюз** — объединение нескольких веток процесса в одну. -* **Цикл** — повторение части процесса заданное число раз. -* **Примечание** — текстовый блок. -* **Ошибка** — немедленная остановка процесса со статусом `Failed`. -* **Конец** — завершение процесса. +* «Начало» — точка входа в процесс. +* «Задача» — выполнение конкретного действия. +* «Эксклюзивный шлюз» — условное ветвление. +* «Параллельный шлюз» — объединение нескольких веток процесса в одну. +* «Цикл» — повторение части процесса заданное число раз. +* «Примечание» — текстовый блок. +* «Ошибка» — немедленная остановка процесса со статусом `Failed`. +* «Конец» — завершение процесса. ## Создание процесса @@ -30,13 +28,13 @@ moduleStatus: experimental Заполните следующие поля: -* **Название** — название процесса. -* **Описание** — подробное описание назначения процесса. -* **Ресурс** — один или несколько ресурсов, для которых может запускаться процесс. -* **Владелец** — пользователь, ответственный за процесс. -* **Команда владелец** — команда, ответственная за процесс. -* **Теги** — теги для категоризации процесса. -* **Иконка** — иконка для отображения в интерфейсе. +* «Название» — название процесса. +* «Описание» — подробное описание назначения процесса. +* «Ресурс» — один или несколько ресурсов, для которых может запускаться процесс. +* «Владелец» — пользователь, ответственный за процесс. +* «Команда владелец» — команда, ответственная за процесс. +* «Теги» — теги для категоризации процесса. +* «Иконка» — иконка для отображения в интерфейсе. ### Настройка процесса @@ -77,8 +75,8 @@ moduleStatus: experimental В конфигурации параллельного шлюза можно настроить параметры ожидания: -- Ожидать выполнения **всех входящих элементов** для продолжения выполнения. -- Ожидать выполнения как минимум **одного входящего элемента** для продолжения выполнения. +- Ожидать выполнения всех входящих элементов для продолжения выполнения. +- Ожидать выполнения как минимум одного входящего элемента для продолжения выполнения. При этом можно настроить, что именно считать «выполнением»: - Только успешное завершение входящих в шлюз задач. @@ -88,15 +86,15 @@ moduleStatus: experimental ##### Цикл -Элемент **Цикл** предназначен для выполнения одной и той же части процесса заданное число раз, после выполнения активируется элемент, подключенный к выходу из цикла. +Элемент «Цикл» предназначен для выполнения одной и той же части процесса заданное число раз, после выполнения активируется элемент, подключенный к выходу из цикла. В конфигурации цикла можно настроить количество итераций: от 1 до 10000. ###### Исходящие связи -Из элемента «Цикл» должны выходить **ровно две связи** к **разным** элементам: -- **Тело цикла** — нижний порт; от него строится ветка, которая выполняется на каждой итерации. -- **Выход из цикла** — правый порт; по этой ветке выполнение продолжается после последней итерации. +Из элемента «Цикл» должны выходить ровно две связи к разным элементам: +- «Тело цикла» — нижний порт; от него строится ветка, которая выполняется на каждой итерации. +- «Выход из цикла» — правый порт; по этой ветке выполнение продолжается после последней итерации. ###### Использование @@ -106,12 +104,12 @@ moduleStatus: experimental ##### Примечание -Элемент **Примечание** предназначен для текстовых пояснений на схеме процесса: он не выполняется при запуске и не соединяется с другими элементами. +Элемент Примечание предназначен для текстовых пояснений на схеме процесса: он не выполняется при запуске и не соединяется с другими элементами. В конфигурации примечания можно задать: -- **Текст** — содержимое с поддержкой markdown разметки. -- **Цвет фона** — цвет заливки фона. -- **Цвет текста** — цвет текста. +- «Текст» — содержимое с поддержкой markdown разметки. +- «Цвет фона» — цвет заливки фона. +- «Цвет текста» — цвет текста. Примечание всегда позиционируется за остальными элементами и может использоваться для визуального выделения частей процесса. Также это единственный элемент, размер которого можно изменить. @@ -133,18 +131,18 @@ moduleStatus: experimental #### Основные характеристики -- **Одно хранилище на запуск процесса** — каждый запуск процесса имеет своё хранилище. -- **Плоские ключи** — в хранилище используются только логические ключи (например `projectId`, `deployJobId`). -- **Запись только по правилам** — в хранилище записывается только то, что задано в настройках действий, входящих в процесс (см. [«Обновление хранилища процесса»](../actions/overview/#обновление-хранилища-процесса)). Если правил записи нет — в хранилище ничего не записывается. -- **Чтение через плейсхолдеры** — в конфигурации действий (URL, заголовки, body и т. д.) можно использовать Go-шаблоны вида `{{ .store.<ключ> }}` (см. [«Хранилище процесса»](../../user/templating/#хранилище-процесса)). +- «Одно хранилище на запуск процесса» — каждый запуск процесса имеет своё хранилище. +- «Плоские ключи» — в хранилище используются только логические ключи (например `projectId`, `deployJobId`). +- «Запись только по правилам» — в хранилище записывается только то, что задано в настройках действий, входящих в процесс (см. [«Обновление хранилища процесса»](../actions/overview/#обновление-хранилища-процесса)). Если правил записи нет — в хранилище ничего не записывается. +- «Чтение через плейсхолдеры» — в конфигурации действий (URL, заголовки, body и т. д.) можно использовать Go-шаблоны вида `{{ .store.<ключ> }}` (см. [«Хранилище процесса»](../../user/templating/#хранилище-процесса)). #### Как данные попадают в хранилище 1. Действие в процессе завершилось успешно. 1. У действия настроены правила «Запись в хранилище процесса». -1. Для каждого правила выполняется Go-шаблон из поля **Источник** с данными ответа действия; полученная строка записывается в хранилище под ключом, указанным в поле **Ключ в хранилище**. +1. Для каждого правила выполняется Go-шаблон из поля «Источник» с данными ответа действия; полученная строка записывается в хранилище под ключом, указанным в поле «Ключ в хранилище». -Если для одного и того же ключа пишут несколько действий (или одно и то же действие при повторном запуске), **значение перезаписывается**. +Если для одного и того же ключа пишут несколько действий (или одно и то же действие при повторном запуске), значение перезаписывается. #### Поведение при отсутствующих данных @@ -164,9 +162,9 @@ moduleStatus: experimental При запуске процесса доступны: -* **Общие параметры процесса** — параметры, определённые в конфигурации процесса. -* **Параметры действий** — параметры для каждого действия в процессе. -* **Переменные окружения** — дополнительные переменные для выполнения. +* «Общие параметры процесса» — параметры, определённые в конфигурации процесса. +* «Параметры действий» — параметры для каждого действия в процессе. +* «Переменные окружения» — дополнительные переменные для выполнения. ## Управление выполнением @@ -174,21 +172,21 @@ moduleStatus: experimental Процесс может находиться в следующих статусах: -* **Создан** — процесс создан, но не запущен. -* **Выполняется** — процесс находится в процессе выполнения. -* **Приостановлен** — выполнение процесса приостановлено. -* **Завершен** — процесс успешно завершен. -* **Неудачно** — процесс завершился с ошибкой. -* **Отменен** — выполнение процесса было отменено. +* «Создан» — процесс создан, но не запущен. +* «Выполняется» — процесс находится в процессе выполнения. +* «Приостановлен» — выполнение процесса приостановлено. +* «Завершен» — процесс успешно завершен. +* «Неудачно» — процесс завершился с ошибкой. +* «Отменен» — выполнение процесса было отменено. ### Управление выполнением Для активных процессов доступны следующие операции: -* **Приостановить** — временно остановить выполнение. -* **Возобновить** — продолжить выполнение после приостановки. -* **Остановить** — полностью остановить выполнение. -* **Принудительный перезапуск** — перезапустить процесс с начала. +* «Приостановить» — временно остановить выполнение. +* «Возобновить» — продолжить выполнение после приостановки. +* «Остановить» — полностью остановить выполнение. +* «Принудительный перезапуск» — перезапустить процесс с начала. ### Отслеживание состояния @@ -207,22 +205,22 @@ moduleStatus: experimental ### Создание проекта с настройкой -1. **Начало** — запуск процесса. -1. **Задача** — создание проекта в GitLab. -1. **Эксклюзивный шлюз** — проверка успешности создания. -1. **Задача** (при успехе) — настройка переменных проекта. -1. **Задача** (при ошибке) — отправка уведомления об ошибке. -1. **Конец** — завершение процесса. +1. «Начало» — запуск процесса. +1. «Задача» — создание проекта в GitLab. +1. «Эксклюзивный шлюз» — проверка успешности создания. +1. «Задача» (при успехе) — настройка переменных проекта. +1. «Задача» (при ошибке) — отправка уведомления об ошибке. +1. «Конец» — завершение процесса. ### Развертывание приложения -1. **Начало** — запуск процесса развертывания. -1. **Параллельный шлюз** — разделение на ветки. -1. **Задача** (ветка 1) — создание namespace в Kubernetes. -1. **Задача** (ветка 2) — создание секретов в Vault. -1. **Параллельный шлюз** — ожидание завершения обеих веток. -1. **Задача** — развертывание приложения. -1. **Конец** — завершение процесса. +1. «Начало» — запуск процесса развертывания. +1. «Параллельный шлюз» — разделение на ветки. +1. «Задача» (ветка 1) — создание namespace в Kubernetes. +1. «Задача» (ветка 2) — создание секретов в Vault. +1. «Параллельный шлюз» — ожидание завершения обеих веток. +1. «Задача» — развертывание приложения. +1. «Конец» — завершение процесса. ## Ограничения diff --git a/content/documentation/admin/security/audit-logs.ru.md b/content/documentation/admin/security/audit-logs.ru.md index 572ed843..6a5b2749 100644 --- a/content/documentation/admin/security/audit-logs.ru.md +++ b/content/documentation/admin/security/audit-logs.ru.md @@ -3,8 +3,7 @@ title: Аудит-логи weight: 40 --- -Аудит-логи — это механизм записи всех операций, выполняемых пользователями через API платформы DDP. -Логи сохраняются в базе данных PostgreSQL и используются для аудита действий пользователей. +Аудит-логи — это механизм записи всех операций, выполняемых пользователями через API Deckhouse Development Platform (DDP). Логи сохраняются в базе данных PostgreSQL и используются для аудита действий пользователей. ## Компоненты @@ -31,9 +30,9 @@ weight: 40 Для снижения нагрузки на базу данных используется буферизация записей со следующими параметрами: -1. Размер батча — 40 записей. -1. Интервал записи — 20 секунд. -1. Размер буфера в памяти — 4 записи. +- Размер батча — 40 записей. +- Интервал записи — 20 секунд. +- Размер буфера в памяти — 4 записи. ## Хранение @@ -45,21 +44,20 @@ weight: 40 ## Просмотр логов -Аудит-логи доступны через веб-интерфейс в разделе «Администрирование» → «Аудит». Логи можно фильтровать по следующим -параметрам: +Аудит-логи доступны через веб-интерфейс в разделе «Администрирование» → «Аудит». Логи можно фильтровать по следующим параметрам: -- Период (дата и время начала и окончания). -- Email пользователя. -- IP-адрес. -- Путь. -- Метод запроса. +- Период (дата и время начала и окончания); +- Email пользователя; +- IP-адрес; +- Путь; +- Метод запроса; - Статус ответа. ## Выгрузка в CSV -На странице просмотра аудит-логов доступна кнопка **«Скачать .csv»**. Выгрузка выполняется только при наличии разрешения на чтение аудит-логов. +На странице просмотра аудит-логов доступна кнопка «Скачать .csv». Выгрузка выполняется только при наличии разрешения на чтение аудит-логов. -В файл попадают **все** записи, соответствующие текущим фильтрам и сортировке. Если число подходящих событий превышает лимит в 100 000 записей, выгрузка не выполняется. +В файл попадают все записи, соответствующие текущим фильтрам и сортировке. Если число подходящих событий превышает лимит в 100 000 записей, выгрузка не выполняется. ## Настройка diff --git a/content/documentation/admin/security/credentials.ru.md b/content/documentation/admin/security/credentials.ru.md index 9a64e40d..3e0e3384 100644 --- a/content/documentation/admin/security/credentials.ru.md +++ b/content/documentation/admin/security/credentials.ru.md @@ -1,71 +1,75 @@ --- -title: Учетные данные +title: Учётные данные weight: 30 --- -Механизм учетных данных позволяет безопасно хранить и использовать реквизиты доступа к внешним сервисам в действиях, источниках данных, виджетах и других компонентах платформы DDP. Все учетные данные шифруются перед сохранением в базе данных и расшифровываются только при использовании. +Механизм учётных данных позволяет безопасно хранить и использовать реквизиты доступа к внешним сервисам в действиях, источниках данных, виджетах и других компонентах Deckhouse Development Platform (DDP). Все учётные данные шифруются перед сохранением в базе данных и расшифровываются только при использовании. ## Принцип работы -### Типы учетных данных +### Типы учётных данных -Администратор платформы создает типы учетных данных в разделе «Администрирование» → «Учетные данные». Каждый тип имеет: -- **Название** — отображаемое название типа. -- **Идентификатор** — уникальный идентификатор для использования в конфигурациях. -- **Описание** — подсказка для пользователей. +Администратор платформы создаёт типы учётных данных в разделе «Администрирование» → «Учётные данные». Каждый тип имеет: -### Учетные данные пользователей +- «Название» — отображаемое название типа. +- «Идентификатор» — уникальный идентификатор для использования в конфигурациях. +- «Описание» — подсказка для пользователей. -Пользователи заполняют свои персональные учетные данные в разделе «Профиль» → «Учетные данные». Для каждого типа учетных данных пользователь может указать свое значение (например, токен доступа, пароль, ключ API). +### Учётные данные пользователей -После сохранения пользователь не может просмотреть значение учетных данных, только обновить его. В профиле отображается информация о том, заполнены ли те или иные учетные данные. +Пользователи заполняют свои персональные учётные данные в разделе «Профиль» → «Учётные данные». Для каждого типа учётных данных пользователь может указать свое значение (например, токен доступа, пароль, ключ API). + +После сохранения пользователь не может просмотреть значение учётных данных, только обновить его. В профиле отображается информация о том, заполнены ли те или иные учётные данные. ### Выбор хранилища для типа учётных данных При создании или редактировании типа учётных данных указывается хранилище: -- **База данных** — значения хранятся в PostgreSQL (по умолчанию). -- **Vault** — значения хранятся в HashiCorp Vault или в Deckhouse Stronghold. Доступно только если в платформе включена и настроена интеграция с Vault. + +- «База данных» — значения хранятся в PostgreSQL (по умолчанию). +- Vault — значения хранятся в HashiCorp Vault или в Deckhouse Stronghold. Доступно только если в платформе включена и настроена интеграция с Vault. Один и тот же тип учётных данных всегда использует одно выбранное хранилище. Изменить хранилище для существующего типа можно; при этом уже сохранённые учётные данные в старом хранилище не переносятся автоматически. ### Хранение в базе данных -Учетные данные с типом хранилища «База данных» сохраняются в PostgreSQL. Перед сохранением значения шифруются с использованием алгоритма AES-GCM. +Учётные данные с типом хранилища «База данных» сохраняются в PostgreSQL. Перед сохранением значения шифруются с использованием алгоритма AES-GCM. Параметры шифрования: -- **Алгоритм:** AES-GCM. -- **Размер ключа:** 16, 24 или 32 байта (128, 192 или 256 бит). -- **Размер nonce:** 12 байт. -- **Ключ шифрования:** задается в конфигурации DDP в поле `security.secretKey`. + +- Алгоритм: AES-GCM. +- Размер ключа: 16, 24 или 32 байта (128, 192 или 256 бит). +- Размер nonce: 12 байт. +- Ключ шифрования: задается в конфигурации DDP в поле `security.secretKey`. Зашифрованные значения сохраняются в базе данных с префиксом `GCM:`, что позволяет системе определить метод шифрования при расшифровке. {{< alert level="warning" >}} -При изменении ключа шифрования (`security.secretKey`) в конфигурации все текущие учетные данные станут невалидными и не смогут быть расшифрованы. +При изменении ключа шифрования (`security.secretKey`) в конфигурации все текущие учётные данные станут невалидными и не смогут быть расшифрованы. {{< /alert >}} ### Хранение в HashiCorp Vault -Если для типа учётных данных выбрано хранилище **Vault**, то реквизиты пользователей сохраняются платформой в HashiCorp Vault или в Deckhouse Stronghold. +Если для типа учётных данных выбрано хранилище Vault, то реквизиты пользователей сохраняются платформой в HashiCorp Vault или в Deckhouse Stronghold. Как это устроено: -- В Vault используется движок **KV Secrets Engine v2**. Путь к секретам задаётся в настройках Vault в DDP (например, `secrets/data/ddp`). -- Для каждого пользователя создаётся отдельный секрет по пути `{path}/credentials/{uuid_типа}/users/{uuid_пользователя}`. Внутри секрета один ключ **value**, значение — зашифрованные учетные данные. Шифрование выполняется ключом DDP (`security.secretKey`). -- Подключение к Vault выполняется по **AppRole** (AppRole Role ID и AppRole Secret ID). AppRole Role ID и AppRole Secret ID сохраняются в БД DDP в зашифрованном виде. Токен Vault продлевается автоматически; при сбое продления выполняется повторный вход по AppRole. + +- В Vault используется движок KV Secrets Engine v2. Путь к секретам задаётся в настройках Vault в DDP (например, `secrets/data/ddp`). +- Для каждого пользователя создаётся отдельный секрет по пути `{path}/credentials/{uuid_типа}/users/{uuid_пользователя}`. Внутри секрета один ключ `value`, значение — зашифрованные учётные данные. Шифрование выполняется ключом DDP (`security.secretKey`). +- Подключение к Vault выполняется по `AppRole` (AppRole Role ID и AppRole Secret ID). AppRole Role ID и AppRole Secret ID сохраняются в БД DDP в зашифрованном виде. Токен Vault продлевается автоматически; при сбое продления выполняется повторный вход по AppRole. Настройка Vault в DDP: -1. В разделе «Администрирование» → «Учетные данные» нажмите «Настройки Vault». -2. Включите использование Vault (Включено). -3. Заполните параметры: - - **URL** — адрес сервера Vault (например, `https://vault.example.com`). - - **AppRole Role ID** — идентификатор AppRole, полученный при создании роли в Vault. - - **AppRole Secret ID** — секрет AppRole, используется вместе с Role ID для аутентификации в Vault. - - **Путь** — путь к секретам в KV v2. Для KV v2 путь должен содержать сегмент `/data/` (например, `secrets/data/ddp` или `secrets/data/ddp/credentials`). Mount (например, `secrets`) должен быть заранее создан в Vault; подкаталоги после `data/` создаются платформой автоматически при сохранении учётных данных. -4. Нажмите «Проверить подключение», чтобы убедиться, что DDP может аутентифицироваться и обращаться к Vault. -5. Сохраните конфигурацию. +1. В разделе «Администрирование» → «Учётные данные» нажмите «Настройки Vault». +1. Включите использование Vault (Включено). +1. Заполните параметры: + - `URL` — адрес сервера Vault (например, `https://vault.example.com`). + - «AppRole Role ID» — идентификатор AppRole, полученный при создании роли в Vault. + - «AppRole Secret ID» — секрет AppRole, используется вместе с Role ID для аутентификации в Vault. + - «Путь» — путь к секретам в KV v2. Для KV v2 путь должен содержать сегмент `/data/` (например, `secrets/data/ddp` или `secrets/data/ddp/credentials`). Mount (например, `secrets`) должен быть заранее создан в Vault; подкаталоги после `data/` создаются платформой автоматически при сохранении учётных данных. +1. Нажмите «Проверить подключение», чтобы убедиться, что DDP может аутентифицироваться и обращаться к Vault. +1. Сохраните конфигурацию. -После сохранения конфигурации при создании или редактировании типа учётных данных в списке хранилищ будет доступен вариант **Vault**. Если Vault выключен или не настроен, типы с хранилищем Vault останутся в списке, но учётные данные такого типа заполнять и использовать будет нельзя до включения и настройки Vault. +После сохранения конфигурации при создании или редактировании типа учётных данных в списке хранилищ будет доступен вариант Vault. Если Vault выключен или не настроен, типы с хранилищем Vault останутся в списке, но учётные данные такого типа заполнять и использовать будет нельзя до включения и настройки Vault. #### Права доступа @@ -78,58 +82,64 @@ weight: 30 - Очистить все сохранённые значения типа из текущего хранилища (база данных или Vault) в любой момент можно через действие «Очистить хранилище» в таблице типов учётных данных. - Смена ключа шифрования DDP (`security.secretKey`) делает нечитаемыми и учётные данные в Vault, так как значения в Vault хранятся в зашифрованном виде. -### Использование учетных данных +### Использование учётных данных -Учетные данные расшифровываются только при необходимости их использования, непосредственно перед обращением к внешнему сервису. После использования расшифрованные значения не сохраняются в памяти дольше необходимого. +Учётные данные расшифровываются только при необходимости их использования, непосредственно перед обращением к внешнему сервису. После использования расшифрованные значения не сохраняются в памяти дольше необходимого. ## Интеграция в компоненты платформы ### Действия -В конфигурации действия можно указать список требуемых учетных данных через поле **Учетные данные**. Каждое учетное данное определяется: -- **Идентификатор** — идентификатор учетного данного (соответствует идентификатору типа учетных данных). -- **Тип учетных данных** — выбор типа учетных данных из списка. +В конфигурации действия можно указать список требуемых учётных данных через поле «Учётные данные». Каждое учётное данное определяется: + +- «Идентификатор» — идентификатор учётного данного (соответствует идентификатору типа учётных данных). +- «Тип учётных данных» — выбор типа учётных данных из списка. При выполнении действия система: -1. Определяет пользователя, от имени которого выполняется действие (инициатор или учетная запись, выбранная в поле **«Учётная запись для запуска»**, если включена опция **«Выбрать учётную запись для запуска»**). -1. Извлекает учетные данные этого пользователя из базы данных. -1. Расшифровывает значения учетных данных. + +1. Определяет пользователя, от имени которого выполняется действие (инициатор или учётная запись, выбранная в поле «Учётная запись для запуска», если включена опция «Выбрать учётную запись для запуска»). +1. Извлекает учётные данные этого пользователя из базы данных. +1. Расшифровывает значения учётных данных. 1. Подставляет расшифрованные значения в шаблоны конфигурации действия (URL, заголовки, тело запроса) через плейсхолдеры вида `{{.credentials.идентификатор}}`. ### Источники данных -В конфигурации источника данных можно указать список требуемых учетных данных аналогично действиям. При синхронизации данных система: -1. Использует учетные данные системного пользователя, указанного в конфигурации источника данных (поле **«Системная учетная запись»**). -1. Извлекает и расшифровывает учетные данные системного пользователя. +В конфигурации источника данных можно указать список требуемых учётных данных аналогично действиям. При синхронизации данных система: + +1. Использует учётные данные системного пользователя, указанного в конфигурации источника данных (поле «Системная учётная запись»). +1. Извлекает и расшифровывает учётные данные системного пользователя. 1. Подставляет значения в шаблоны запросов источника данных. {{< alert level="warning" >}} -Источники данных всегда используют учетные данные системного пользователя, а не инициатора запуска синхронизации. +Источники данных всегда используют учётные данные системного пользователя, а не инициатора запуска синхронизации. {{< /alert >}} ### Виджеты -Виджеты могут использовать учетные данные для получения данных из внешних сервисов. Механизм работы аналогичен действиям: -1. Определяется пользователь (инициатор запроса или учетная запись, выбранная в поле **"Учётная запись для виджета"**, если включена опция **"Выбрать учётную запись для виджета"**). -2. Извлекаются и расшифровываются учетные данные. -3. Значения подставляются в конфигурацию виджета. +Виджеты могут использовать учётные данные для получения данных из внешних сервисов. Механизм работы аналогичен действиям: + +1. Определяется пользователь (инициатор запроса или учётная запись, выбранная в поле «Учётная запись для виджета», если включена опция «Выбрать учётную запись для виджета»). +1. Извлекаются и расшифровываются учётные данные. +1. Значения подставляются в конфигурацию виджета. ### Проверки статуса -Проверки статуса используют учетные данные для выполнения проверок состояния сущностей. В конфигурации правил проверки статуса можно указать список требуемых учетных данных. При выполнении проверки система: -1. Использует учетные данные системного пользователя, указанного в конфигурации правила проверки статуса (поле **«Системная учетная запись»**). -1. Извлекает и расшифровывает учетные данные системного пользователя. +Проверки статуса используют учётные данные для выполнения проверок состояния сущностей. В конфигурации правил проверки статуса можно указать список требуемых учётных данных. При выполнении проверки система: + +1. Использует учётные данные системного пользователя, указанного в конфигурации правила проверки статуса (поле «Системная учётная запись»). +1. Извлекает и расшифровывает учётные данные системного пользователя. 1. Подставляет значения в шаблоны конфигурации правила (URL, заголовки, параметры запросов) через плейсхолдеры вида `{{.credentials.идентификатор}}`. {{< alert level="warning" >}} -Проверки статуса всегда используют учетные данные системного пользователя, указанного в конфигурации правила. Если системный пользователь не указан, правило пропускается при выполнении проверки. +Проверки статуса всегда используют учётные данные системного пользователя, указанного в конфигурации правила. Если системный пользователь не указан, правило пропускается при выполнении проверки. {{< /alert >}} ### Внешние сервисы -Внешние сервисы могут иметь собственный список учетных данных. Если действие, источник данных или виджет использует внешний сервис (включена опция **«Использовать внешний сервис»**), то: -1. Учетные данные из конфигурации внешнего сервиса наследуются компонентом, если в его конфигурации не указаны собственные учетные данные. -1. Приоритет имеют учетные данные, указанные непосредственно в конфигурации компонента. +Внешние сервисы могут иметь собственный список учётных данных. Если действие, источник данных или виджет использует внешний сервис (включена опция «Использовать внешний сервис»), то: + +1. Учётные данные из конфигурации внешнего сервиса наследуются компонентом, если в его конфигурации не указаны собственные учётные данные. +1. Приоритет имеют учётные данные, указанные непосредственно в конфигурации компонента. ## Настройка @@ -150,10 +160,10 @@ security: ### Интеграция с Vault -Подключение к HashiCorp Vault (URL, AppRole, путь к KV v2) настраивается в веб-интерфейсе в разделе «Администрирование» → «Учетные данные» → «Настройки Vault». В конфигурационном файле DDP задаётся только ключ шифрования (`security.secretKey`), который используется в том числе для шифрования значений, хранящихся в Vault. +Подключение к HashiCorp Vault (URL, AppRole, путь к KV v2) настраивается в веб-интерфейсе в разделе «Администрирование» → «Учётные данные» → «Настройки Vault». В конфигурационном файле DDP задаётся только ключ шифрования (`security.secretKey`), который используется в том числе для шифрования значений, хранящихся в Vault. ## Безопасность -- Учетные данные никогда не передаются пользователю в расшифрованном виде. +- Учётные данные никогда не передаются пользователю в расшифрованном виде. - Расшифровка происходит только непосредственно перед отправкой запроса. - Расшифрованные значения не логируются. diff --git a/content/documentation/admin/security/http-security-headers.ru.md b/content/documentation/admin/security/http-security-headers.ru.md index de2ee109..59b2fee4 100644 --- a/content/documentation/admin/security/http-security-headers.ru.md +++ b/content/documentation/admin/security/http-security-headers.ru.md @@ -3,35 +3,35 @@ title: HTTP-заголовки безопасности weight: 50 --- -DDP поддерживает следующие HTTP-заголовки для повышения безопасности взаимодействия: +Deckhouse Development Platform (DDP) поддерживает следующие HTTP-заголовки для повышения безопасности взаимодействия: -1. **Content-Security-Policy** +1. `Content-Security-Policy` - Настраиваемая политика безопасности контента. - Подробное описание приведено в разделе [Content Security Policy](#content-security-policy). -2. **X-Frame-Options** +1. `X-Frame-Options` - Защита от clickjacking-атак. - Значение по умолчанию: `SAMEORIGIN`. - Настраивается в конфигурации DDP в секции `security.headers.xFrameOptions`. - Возможные значения: `DENY`, `SAMEORIGIN`. -3. **X-Content-Type-Options** +1. `X-Content-Type-Options` - Предотвращение MIME-sniffing. - Значение: `nosniff`. -4. **X-XSS-Protection** +1. `X-XSS-Protection` - Защита от XSS-атак (для устаревших браузеров). - Значение: `1; mode=block`. -5. **Referrer-Policy** +1. `Referrer-Policy` - Контроль передачи информации о реферере. - Значение: `strict-origin-when-cross-origin`. -6. **Permissions-Policy** (ранее Feature-Policy) +1. `Permissions-Policy` (ранее Feature-Policy) - Ограничение использования функций браузера. - Значение: `geolocation=(), microphone=(), camera=(), payment=(), usb=(), magnetometer=(), gyroscope=(), accelerometer=()`. -7. **Strict-Transport-Security (HSTS)** +1. `Strict-Transport-Security (HSTS)` - Принудительное использование HTTPS. - Значение: `max-age=31536000; includeSubDomains; preload`. @@ -59,8 +59,8 @@ security: ## Применение -- **Frontend**: Заголовки добавляются на уровне веб-сервера для раздачи статических файлов и HTML страниц в компоненте DDP Frontend. -- **Backend API**: Заголовки добавляются через middleware для всех API ответов в компоненте DDP Backend. +- Frontend: Заголовки добавляются на уровне веб-сервера для раздачи статических файлов и HTML страниц в компоненте DDP Frontend. +- Backend API: Заголовки добавляются через middleware для всех API ответов в компоненте DDP Backend. {{< alert level="info" >}} Все заголовки безопасности включены по умолчанию (`enabled: true`). При необходимости их можно отключить или настроить в конфигурации DDP. diff --git a/content/documentation/admin/security/overview.ru.md b/content/documentation/admin/security/overview.ru.md index 57140e0e..335358c1 100644 --- a/content/documentation/admin/security/overview.ru.md +++ b/content/documentation/admin/security/overview.ru.md @@ -3,7 +3,7 @@ title: Обзор weight: 10 --- -DDP предоставляет набор встроенных механизмов безопасности, обеспечивающих контроль доступа, защиту учетных данных и аудит действий пользователей при работе с платформой. +Deckhouse Development Platform (DDP) предоставляет набор встроенных механизмов безопасности, обеспечивающих контроль доступа, защиту учётных данных и аудит действий пользователей при работе с платформой. ## Аутентификация @@ -19,11 +19,11 @@ DDP Backend использует ключи подписи, получаемые Модель поддерживает иерархию ролей и проверку разрешений на уровне супер-администратора, глобальных ролей, ролей ресурсов и ролей сущностей. Подробнее — в [документации по ролевой модели](../rbac/). -## Учетные данные +## Учётные данные -DDP обеспечивает централизованное и безопасное хранение учетных данных, используемых для интеграции с внешними системами и сервисами. Хранение и обработка учетных данных выполняются на стороне DDP Backend с использованием базы данных PostgreSQL. +DDP обеспечивает централизованное и безопасное хранение учётных данных, используемых для интеграции с внешними системами и сервисами. Хранение и обработка учётных данных выполняются на стороне DDP Backend с использованием базы данных PostgreSQL. -Перед сохранением в базе данных учетные данные шифруются с применением алгоритма AES-GCM. Расшифровка выполняется DDP Backend только в момент использования учетных данных в действиях, источниках данных или виджетах. +Перед сохранением в базе данных учётные данные шифруются с применением алгоритма AES-GCM. Расшифровка выполняется DDP Backend только в момент использования учётных данных в действиях, источниках данных или виджетах. Подробнее — в [документации по учетным данным](../credentials/). ## Доверенные сертификаты @@ -44,7 +44,7 @@ DDP позволяет добавлять в хранилище корневые ## HTTP-заголовки безопасности -Для защиты веб-интерфейса и API платформы DDP используются стандартные HTTP-заголовки безопасности. +Для защиты веб-интерфейса и API DDP используются стандартные HTTP-заголовки безопасности. Их формирование и применение выполняется на стороне DDP Frontend и DDP Backend. Заголовки направлены на снижение рисков XSS-атак, clickjacking, предотвращения MIME-sniffing, контроля передачи информации о реферере, а также на принудительное использование защищённого соединения HTTPS. diff --git a/content/documentation/admin/security/rbac.ru.md b/content/documentation/admin/security/rbac.ru.md index 2d18573f..dec5ccec 100644 --- a/content/documentation/admin/security/rbac.ru.md +++ b/content/documentation/admin/security/rbac.ru.md @@ -3,7 +3,7 @@ title: Ролевая модель weight: 20 --- -Ролевая модель DDP определяет, какие действия пользователи могут выполнять в платформе и к каким объектам они имеют доступ. Модель используется для разграничения прав при работе с API и веб-интерфейсом и применяется на уровне платформы в целом и отдельных объектов. +Ролевая модель Deckhouse Development Platform (DDP) определяет, какие действия пользователи могут выполнять в платформе и к каким объектам они имеют доступ. Модель используется для разграничения прав при работе с API и веб-интерфейсом и применяется на уровне платформы в целом и отдельных объектов. Ролевая модель реализована в DDP Backend и использует базу данных PostgreSQL для хранения ролей, разрешений и их связей. @@ -11,9 +11,9 @@ weight: 20 Ролевая модель состоит из следующих компонентов: -* **Разрешение** — соответствует конкретному действию в DDP. -* **Роль** — объединяет в себе набор тех или иных разрешений. -* **Привязка роли** — связывает роль и пользователей, либо команды. +* «Разрешение» — соответствует конкретному действию в DDP. +* «Роль» — объединяет в себе набор тех или иных разрешений. +* «Привязка роли» — связывает роль и пользователей, либо команды. Для каждого объекта DDP существует свой набор разрешений, ролей и привязок ролей. Также есть глобальные роли, разрешения и привязки ролей, которые разрешают операции на глобальном уровне. @@ -60,11 +60,11 @@ weight: 20 - `update:automations` — редактирование автоматизаций. - `delete:automations` — удаление автоматизаций. -Рабочие процессы: -- `create:workflows` — создание рабочих процессов. -- `read:workflows` — просмотр рабочих процессов. -- `update:workflows` — редактирование рабочих процессов. -- `delete:workflows` — удаление рабочих процессов. +Сценарии: +- `create:workflows` — создание сценариев. +- `read:workflows` — просмотр сценариев. +- `update:workflows` — редактирование сценариев. +- `delete:workflows` — удаление сценариев. Вебхуки: - `create:webhooks` — создание вебхуков. @@ -216,8 +216,8 @@ weight: 20 Опция `ownerIsAdmin` задаёт поведение прав доступа для владельцев объектов. -- **Включена (true)** — владельцы объектов получают полные права администратора на свои объекты. -- **Отключена (false)** — владельцы объектов не получают автоматических прав; доступ контролируется только через роли. +- «Включена (true)» — владельцы объектов получают полные права администратора на свои объекты. +- «Отключена (false)» — владельцы объектов не получают автоматических прав; доступ контролируется только через роли. {{< alert level="info" >}} Опция `ownerIsAdmin` должна быть настроена администратором платформы в конфигурационном файле. По умолчанию опция выключена. diff --git a/content/documentation/admin/trusted-certificates.ru.md b/content/documentation/admin/trusted-certificates.ru.md index 4e2646f0..b414a2a6 100644 --- a/content/documentation/admin/trusted-certificates.ru.md +++ b/content/documentation/admin/trusted-certificates.ru.md @@ -3,7 +3,7 @@ title: Доверенные сертификаты menuTitle: Доверенные сертификаты --- -Механизм доверенных сертификатов позволяет загрузить в DDP корневые и промежуточные сертификаты (CA) или сертификаты серверов. Платформа использует их при проверке TLS/SSL при подключении к внешним сервисам по HTTPS — например, при обращении к API внешних сервисов в источниках данных, виджетах и т.д. +Механизм доверенных сертификатов позволяет загрузить в Deckhouse Development Platform (DDP) корневые и промежуточные сертификаты (CA) или сертификаты серверов. Платформа использует их при проверке TLS/SSL при подключении к внешним сервисам по HTTPS — например, при обращении к API внешних сервисов в источниках данных, виджетах и т. д. Это даёт возможность безопасно работать с сервисами, использующими самоподписанные или корпоративные сертификаты, без отключения проверки SSL. @@ -19,8 +19,8 @@ menuTitle: Доверенные сертификаты | Параметр | Описание | |-----------------------|-------------------------------------------------------------------------------| -| **Название** | Отображаемое название сертификата в интерфейсе (например, «Корпоративный CA») | -| **Сертификат (PEM)** | Содержимое сертификата в формате PEM. Обязателен при создании. | +| «Название» | Отображаемое название сертификата в интерфейсе (например, «Корпоративный CA») | +| «Сертификат (PEM)» | Содержимое сертификата в формате PEM. Обязателен при создании | Сертификат задаётся в формате PEM, например: @@ -31,7 +31,7 @@ MIIDXTCCAkWgAwIBAgIJAKL... -----END CERTIFICATE----- ``` -После сохранения в карточке сертификата отображаются данные, извлечённые из PEM: субъект, издатель, срок действия, альтернативные имена и т.д. +После сохранения в карточке сертификата отображаются данные, извлечённые из PEM: субъект, издатель, срок действия, альтернативные имена и т. д. При редактировании сертификата поле «Сертификат (PEM)» скрыто. Сохранённое значение не возвращается API из соображений безопасности. Чтобы обновить сертификат, создайте новую запись и, при необходимости, удалите старую. diff --git a/content/documentation/admin/webhooks.ru.md b/content/documentation/admin/webhooks.ru.md index 9c8de059..34c7f6e0 100644 --- a/content/documentation/admin/webhooks.ru.md +++ b/content/documentation/admin/webhooks.ru.md @@ -1,8 +1,6 @@ --- title: Вебхуки menuTitle: Вебхуки -d8Edition: ee -moduleStatus: experimental --- По механизму действия вебхуки похожи на источники данных. При этом, если источник данных работает по pull-модели, то есть сам опрашивает инфраструктурные системы и пытается загрузить из них данные, то вебхуки ожидают, что данные будут отправлены извне, то есть работают по push-модели. diff --git a/content/documentation/admin/widgets/overview.ru.md b/content/documentation/admin/widgets/overview.ru.md index 52b709dc..49533a61 100644 --- a/content/documentation/admin/widgets/overview.ru.md +++ b/content/documentation/admin/widgets/overview.ru.md @@ -3,26 +3,27 @@ title: Обзор weight: 10 --- -Виджеты - карточки для визуализации данных, хранящихся в платформе, а также информации из инфраструктурных сервисов. В отличие от источников данных, виджеты получают информацию из инфраструктурных сервисов непосредственно в момент их отображения в интерфейсе. +Виджеты — карточки для визуализации данных, хранящихся в платформе, а также информации из инфраструктурных сервисов. В отличие от источников данных, виджеты получают информацию из инфраструктурных сервисов непосредственно в момент их отображения в интерфейсе. -Виджеты могут быть добавлены на дашборды, дашборды в свою очередь могут быть привязаны: -- к статическим страницам (каталог, самообслуживание, главная страница, администрирование), +Виджеты могут быть добавлены на дашборды; дашборды, в свою очередь, могут быть привязаны: + +- к статическим страницам (каталог, самообслуживание, главная страница, администрирование); - к карточкам сущностей. ## Конфигурация Конфигурация виджета включает общие параметры и набор полей, специфичных для конкретного типа виджета. -В конфигурации поддерживается использование синтаксиса [Go template](https://developer.hashicorp.com/nomad/docs/reference/go-template-syntax) для шаблонизации, при обработке виджета, например: +В конфигурации поддерживается использование синтаксиса [Go template](https://developer.hashicorp.com/nomad/docs/reference/go-template-syntax) для шаблонизации при обработке виджета, например: -* `{{ .entity.name }}` - подстановка значения параметра сущности «name». -* `{{ .credentials.token }}` - подстановка учетных данных с названием «token». +* `{{ .entity.name }}` — подстановка значения параметра сущности «name». +* `{{ .credentials.token }}` — подстановка учётных данных с названием «token». Для каждого виджета доступно задание области видимости: -* **Global** - виджет не поддерживает получение параметров сущности через механизм [Go template](https://developer.hashicorp.com/nomad/docs/reference/go-template-syntax); -* **Resource** - виджет поддерживает получение параметров сущности через механизм [Go template](https://developer.hashicorp.com/nomad/docs/reference/go-template-syntax). Виджеты с областью видимости Resource можно прикрепить только к страницам сущности. +* «Global» — виджет не поддерживает получение параметров сущности через механизм [Go template](https://developer.hashicorp.com/nomad/docs/reference/go-template-syntax); +* «Resource» — виджет поддерживает получение параметров сущности через механизм [Go template](https://developer.hashicorp.com/nomad/docs/reference/go-template-syntax). Виджеты с областью видимости Resource можно прикрепить только к страницам сущности. -В конфигурации виджетов возможно задание учетной записи, с данными которой виджет будет взаимодействовать с инфраструктурными системами, а также выбрать тип учетных данных, который будет использоваться. +В конфигурации виджетов возможно задание учётной записи, с данными которой виджет будет взаимодействовать с инфраструктурными системами, а также выбрать тип учётных данных, который будет использоваться. -В случае, если учетная запись не задана, виджет будет использовать учетные данные пользователя, взаимодействующего с платформой в текущий момент. +Если учётная запись не задана, виджет будет использовать учётные данные пользователя, взаимодействующего с платформой в текущий момент. diff --git a/content/documentation/admin/widgets/types.ru.md b/content/documentation/admin/widgets/types.ru.md index c95975ee..b0de901e 100644 --- a/content/documentation/admin/widgets/types.ru.md +++ b/content/documentation/admin/widgets/types.ru.md @@ -4,21 +4,21 @@ title: Типы виджетов ### AI-чат -Виджет **AI-чат** позволяет отправлять запросы к языковой модели через выбранный AI-провайдер: задаются общие инструкции (**Глобальный промпт**) и набор кнопок быстрых вопросов (**Быстрые вопросы**). +Виджет «AI-чат» позволяет отправлять запросы к языковой модели через выбранный AI-провайдер: задаются общие инструкции («Глобальный промпт») и набор кнопок быстрых вопросов («Быстрые вопросы»). #### Конфигурация | Название | Обязательность | Описание | |---------------------|----------------|--------------------------------------------------------------------------------------------------------------------------------| -| Глобальный промпт | нет | Общие инструкции к каждому запросу; при отправке объединяются с промптом выбранной кнопки быстрого вопроса. | -| Быстрые вопросы | **да** | Набор кнопок с подписью и текстом промпта (до 20 штук); для корректной работы виджета необходимо добавить хотя бы один вопрос. | +| Глобальный промпт | Нет | Общие инструкции к каждому запросу; при отправке объединяются с промптом выбранной кнопки быстрого вопроса | +| Быстрые вопросы | Да | Набор кнопок с подписью и текстом промпта (до 20 штук); для корректной работы виджета необходимо добавить хотя бы один вопрос | Для каждого быстрого вопроса задаются поля: | Название | Обязательность | Описание | |------------------|----------------|----------------------------------------------------------------------------------------------| -| Название вопроса | **да** | Короткая подпись, отображается на нижней панели виджета и в чате. | -| Промпт | **да** | Инструкция для модели при нажатии на эту кнопку; допускается использование Go-шаблонизации. | +| Название вопроса | Да | Короткая подпись, отображается на нижней панели виджета и в чате | +| Промпт | Да | Инструкция для модели при нажатии на эту кнопку; допускается использование Go-шаблонизации | При заполнении промпта рекомендуется в явном виде указывать названия MCP-инструментов, которые должна вызвать модель при подготовке ответа. @@ -48,24 +48,24 @@ title: Типы виджетов | Название | Обязательность | Описание | Возможные значения | Значение по умолчанию | |-------------------|----------------|--------------------------------------------------------------------|--------------------------------------|-----------------------| -| Тип спецификации | **Да** | Тип спецификации | OpenAPI (Swagger), Protocol Buffers | - | -| Тип источника | **Да** | Тип источника, из которого будет загружаться файл со спецификацией | URL, GitLab | - | +| Тип спецификации | Да | Тип спецификации | OpenAPI (Swagger), Protocol Buffers | - | +| Тип источника | Да | Тип источника, из которого будет загружаться файл со спецификацией | URL, GitLab | - | #### Конфигурация типа источника: URL | Название | Обязательность | Описание | Значение по умолчанию | |-----------|----------------|------------------------------------------------|-----------------------| -| URL | **Да** | Ссылка на файл со спецификацией | - | +| URL | Да | Ссылка на файл со спецификацией | - | | Заголовки | Нет | Заголовки для доступа к файлу со спецификацией | - | #### Конфигурация типа источника: GitLab | Название | Обязательность | Описание | Значение по умолчанию | |--------------|-----------------|------------------------------------------------------------------------|-----------------------| -| GitLab URL | **Да** | URL GitLab | - | -| ID проекта | **Да** | Идентификатор проекта, из которого будет браться файл со спецификацией | - | -| Ветка | **Да** | Ветка, из которой будет браться файл со спецификацией | - | -| Путь к файлу | **Да** | Путь к файлу со спецификацией относительно корня репозитория | - | +| GitLab URL | Да | URL GitLab | - | +| ID проекта | Да | Идентификатор проекта, из которого будет браться файл со спецификацией | - | +| Ветка | Да | Ветка, из которой будет браться файл со спецификацией | - | +| Путь к файлу | Да | Путь к файлу со спецификацией относительно корня репозитория | - | #### Авторизация @@ -83,17 +83,17 @@ title: Типы виджетов | Название | Обязательность | Описание | Пример | |---------------------------|-----------------|----------------------------------------------------------|------------------------------------------------------------------------| -| Ключ проекта | **Да** | Часть URL репозитория, которая идёт сразу после **/projects/** | Для репозитория `.../projects/MYTEAM/repos/backend` укажите `MYTEAM` | -| Идентификатор репозитория | **Да** | Часть URL репозитория, которая идёт сразу после **/repos/** | Для репозитория `.../projects/MYTEAM/repos/backend` укажите `backend` | +| Ключ проекта | Да | Часть URL репозитория, которая идёт сразу после `/projects/` | Для репозитория `.../projects/MYTEAM/repos/backend` укажите `MYTEAM` | +| Идентификатор репозитория | Да | Часть URL репозитория, которая идёт сразу после `/repos/` | Для репозитория `.../projects/MYTEAM/repos/backend` укажите `backend` | #### Фильтрация по статусу Виджет позволяет фильтровать отображаемые Pull Requests по статусу. В настройках запроса виджета можно выбрать один из следующих статусов: -- **Открыт** — показывает только открытые PR. -- **Слит** — показывает только слитые PR. -- **Отклонён** — показывает только отклонённые PR. -- **Все** — показывает PR в любом статусе. +- «Открыт» — показывает только открытые PR. +- «Слит» — показывает только слитые PR. +- «Отклонён» — показывает только отклонённые PR. +- «Все» — показывает PR в любом статусе. По умолчанию отображаются только открытые PR. @@ -101,11 +101,11 @@ title: Типы виджетов При активированной функции действий в настройках виджет позволяет выполнять следующие действия с Pull Requests: -- **Слить** — слияние открытого запроса на слияние (доступно только для открытых PR). -- **Закрыть** — отклонение (decline) запроса на слияние. -- **Просмотр изменений** — просмотр диффа (изменений) в запросе на слияние. -- **Комментарии** — просмотр и добавление комментариев к PR. -- **Создать PR** — создание нового Pull Request с указанием исходной и целевой ветки, ревьюеров, названия и описания. +- «Слить» — слияние открытого запроса на слияние (доступно только для открытых PR). +- «Закрыть» — отклонение (decline) запроса на слияние. +- «Просмотр изменений» — просмотр диффа (изменений) в запросе на слияние. +- «Комментарии» — просмотр и добавление комментариев к PR. +- «Создать PR» — создание нового Pull Request с указанием исходной и целевой ветки, ревьюеров, названия и описания. {{< alert level="info" >}} Для выполнения действий с PR требуются соответствующие права доступа в репозитории Bitbucket. @@ -118,38 +118,38 @@ title: Типы виджетов #### Авторизация Конфигурация авторизации описана в разделе [«Внешние сервисы»](../external-services/#github). -В настройках внешнего сервиса или в конфигурации виджета в поле **URL** необходимо указать `https://api.github.com`. +В настройках внешнего сервиса или в конфигурации виджета в поле «URL» необходимо указать `https://api.github.com`. #### Учётная запись и автор действий -Запросы к GitHub выполняются с токеном из учётных данных того пользователя платформы, от имени которого вызывается действие. Если в настройках виджета включено **Выбрать учётную запись для виджета**, используются учётные данные выбранного пользователя платформы, а не текущего. +Запросы к GitHub выполняются с токеном из учётных данных того пользователя платформы, от имени которого вызывается действие. Если в настройках виджета включено «Выбрать учётную запись для виджета», используются учётные данные выбранного пользователя платформы, а не текущего. -При **создании**, **слиянии** и **закрытии** Pull Request в GitHub автором PR и исполнителем действий считается учётная запись GitHub, которой принадлежит этот токен. Логин и имя в интерфейсе GitHub могут не совпадать с именем в профиле DDP. +При создании, слиянии и закрытии Pull Request в GitHub автором PR и исполнителем действий считается учётная запись GitHub, которой принадлежит этот токен. Логин и имя в интерфейсе GitHub могут не совпадать с именем в профиле Deckhouse Development Platform (DDP). #### Конфигурация | Название | Обязательность | Описание | Пример | |----------------------|----------------|------------------------------------------------------|------------------------------------------------------------| -| Владелец репозитория | **Да** | Владелец репозитория (организация или пользователь). | Для `https://github.com/example/my-repo` укажите `example` | -| Репозиторий | **Да** | Название репозитория без `.git`. | Для `https://github.com/example/my-repo` укажите `my-repo` | +| Владелец репозитория | Да | Владелец репозитория (организация или пользователь) | Для `https://github.com/example/my-repo` укажите `example` | +| Репозиторий | Да | Название репозитория без `.git` | Для `https://github.com/example/my-repo` укажите `my-repo` | #### Статус В настройках запроса виджета можно фильтровать PR по статусу: -- **Открыт** — только открытые PR (не черновики). -- **Черновик** — только черновики. -- **Закрыт** — только закрытые PR. -- **Все** — любые PR. +- «Открыт» — только открытые PR (не черновики). +- «Черновик» — только черновики. +- «Закрыт» — только закрытые PR. +- «Все» — любые PR. По умолчанию отображаются открытые PR. В таблице отображаются: номер, название, описание, статус, метки, автор, дата создания, дата обновления; для каждого PR доступны действия через меню. #### Действия -- **Изменения** — просмотр списка изменённых файлов и диффа по каждому файлу. -- **Слить** — слияние открытого PR (доступно только для открытых PR, не черновиков). -- **Закрыть** — закрытие PR без слияния. -- **Создать PR** — создание нового Pull Request. В диалоге указываются название, исходная ветка, целевая ветка и описание. +- «Изменения» — просмотр списка изменённых файлов и диффа по каждому файлу. +- «Слить» — слияние открытого PR (доступно только для открытых PR, не черновиков). +- «Закрыть» — закрытие PR без слияния. +- «Создать PR» — создание нового Pull Request. В диалоге указываются название, исходная ветка, целевая ветка и описание. {{< alert level="info" >}} Для выполнения действий с PR требуются соответствующие права доступа в репозитории GitHub. @@ -162,39 +162,39 @@ title: Типы виджетов #### Авторизация Конфигурация авторизации описана в разделе [«Внешние сервисы»](../external-services/#github). -В настройках внешнего сервиса в поле **URL** необходимо указать `https://api.github.com`. +В настройках внешнего сервиса в поле «URL» необходимо указать `https://api.github.com`. #### Учётная запись и автор действий -Запросы к GitHub выполняются с токеном из учётных данных того пользователя платформы, от имени которого вызывается действие. Если в настройках виджета включено **Выбрать учётную запись для виджета**, используются учётные данные выбранного пользователя платформы, а не текущего. +Запросы к GitHub выполняются с токеном из учётных данных того пользователя платформы, от имени которого вызывается действие. Если в настройках виджета включено «Выбрать учётную запись для виджета», используются учётные данные выбранного пользователя платформы, а не текущего. -При **запуске**, **отмене запуска** и **перезапуске** workflow, работе с **артефактами** и **логами** в GitHub инициатором считается учётная запись GitHub, которой принадлежит токен. Логин в интерфейсе GitHub может не совпадать с именем в профиле DDP. +При запуске, отмене запуска и перезапуске workflow, работе с артефактами и логами в GitHub инициатором считается учётная запись GitHub, которой принадлежит токен. Логин в интерфейсе GitHub может не совпадать с именем в профиле DDP. #### Конфигурация | Название | Обязательность | Описание | Пример | |----------------------|----------------|------------------------------------------------------|------------------------------------------------------------| -| Владелец репозитория | **да** | Владелец репозитория (организация или пользователь). | Для `https://github.com/example/my-repo` укажите `example` | -| Репозиторий | **да** | Название репозитория без `.git`. | Для `https://github.com/example/my-repo` укажите `my-repo` | +| Владелец репозитория | Да | Владелец репозитория (организация или пользователь) | Для `https://github.com/example/my-repo` укажите `example` | +| Репозиторий | Да | Название репозитория без `.git` | Для `https://github.com/example/my-repo` укажите `my-repo` | #### Параметры запроса В настройках запроса виджета можно задать фильтры: -- **Ветка** — только запуски с указанной head-веткой. -- **Событие** — только запуски с выбранным типом события. -- **Статус** — только запуски в выбранном статусе или с выбранным итогом (conclusion). -- **Workflow** — только запуски для выбранного файла workflow. -- **Кто запустил** — только запуски, начатые указанным пользователем GitHub. -- **Фильтр по дате создания** — интервал дат создания запуска (дата начала и дата окончания). +- «Ветка» — только запуски с указанной head-веткой. +- «Событие» — только запуски с выбранным типом события. +- «Статус» — только запуски в выбранном статусе или с выбранным итогом (conclusion). +- «Workflow» — только запуски для выбранного файла workflow. +- «Кто запустил» — только запуски, начатые указанным пользователем GitHub. +- «Фильтр по дате создания» — интервал дат создания запуска (дата начала и дата окончания). #### Действия В виджете доступны следующие действия: -- **Запустить workflow** — ручной запуск workflow с триггером `workflow_dispatch`: выбираются **Workflow** и **Ветка или тег**; при объявленных во входном YAML параметрах отображаются **Входные параметры**. -- **Перезапустить workflow**, **Перезапустить упавшие jobs**, **Отменить workflow** — для выбранного запуска. -- **Перезапустить job** — для job в статусе «завершён» с итогом failure или cancelled. +- «Запустить workflow» — ручной запуск workflow с триггером `workflow_dispatch`: выбираются «Workflow» и «Ветка или тег»; при объявленных во входном YAML параметрах отображаются «Входные параметры». +- «Перезапустить workflow», «Перезапустить упавшие jobs», «Отменить workflow» — для выбранного запуска. +- «Перезапустить job» — для job в статусе «завершён» с итогом failure или cancelled. - Просмотр логов job, скачивание артефактов, открытие запуска на GitHub, дерево jobs и шагов. {{< alert level="info" >}} @@ -213,8 +213,8 @@ title: Типы виджетов | Название | Обязательность | Описание | Значение по умолчанию | |-------------------|-----------------|-------------------------------------|-----------------------| -| URL | **Да** | URL CodeScoring | - | -| ID проекта | **Да** | Идентификатор проекта в CodeScoring | - | +| URL | Да | URL CodeScoring | - | +| ID проекта | Да | Идентификатор проекта в CodeScoring | - | ### CodeScoring. Уязвимости @@ -228,8 +228,8 @@ title: Типы виджетов | Название | Обязательность | Описание | Значение по умолчанию | |-------------------|-----------------|-------------------------------------|-----------------------| -| URL | **Да** | URL CodeScoring | - | -| ID проекта | **Да** | Идентификатор проекта в CodeScoring | - | +| URL | Да | URL CodeScoring | - | +| ID проекта | Да | Идентификатор проекта в CodeScoring | - | ### CodeScoring. Секреты @@ -243,8 +243,8 @@ title: Типы виджетов | Название | Обязательность | Описание | Значение по умолчанию | |-------------------|-----------------|-------------------------------------|-----------------------| -| URL | **Да** | URL CodeScoring | - | -| ID проекта | **Да** | Идентификатор проекта в CodeScoring | - | +| URL | Да | URL CodeScoring | - | +| ID проекта | Да | Идентификатор проекта в CodeScoring | - | ### DefectDojo. Уязвимости в продукте (детали) @@ -258,15 +258,15 @@ title: Типы виджетов | Название | Обязательность | Описание | Значение по умолчанию | |-------------------|-----------------|--------------------------------------------------------|-----------------------| -| URL | **Да** | URL DefectDojo. Указывается без пути к API (`/api/v2`) | - | -| Название продукта | **Да** | Название продукта в DefectDojo | - | +| URL | Да | URL DefectDojo. Указывается без пути к API (`/api/v2`) | - | +| Название продукта | Да | Название продукта в DefectDojo | - | #### Дополнительные возможности виджета При просмотре виджета доступна настройка следующих параметров: -* **Активные уязвимости** - если включено, то загружаются уязвимости продукта с флагом ‘Active’ = true. Если отключено, то загружаются уязвимости продукта с флагом ‘Active’ = false. Включено по умолчанию. -* **Дублирующиеся уязвимости** - если включено, то загружаются уязвимости продукта с флагом ‘Duplicate’ = true. Если отключено, то загружаются уязвимости продукта с флагом ‘Duplicate’ = false. Отключено по умолчанию. +* «Активные уязвимости» — если включено, то загружаются уязвимости продукта с флагом ‘Active’ = true. Если отключено, то загружаются уязвимости продукта с флагом ‘Active’ = false. Включено по умолчанию. +* «Дублирующиеся уязвимости» — если включено, то загружаются уязвимости продукта с флагом ‘Duplicate’ = true. Если отключено, то загружаются уязвимости продукта с флагом ‘Duplicate’ = false. Отключено по умолчанию. ### DefectDojo. Уязвимости в продукте (общая статистика) @@ -280,15 +280,15 @@ title: Типы виджетов | Название | Обязательность | Описание | Значение по умолчанию | |-------------------|-----------------|----------------------------------------------------------------------------------------------------------------------------------|-----------------------| -| URL | **Да** | URL DefectDojo. Указывается без пути к API (`/api/v2`) | - | -| Название продукта | **Да** | Название продукта в DefectDojo | - | +| URL | Да | URL DefectDojo. Указывается без пути к API (`/api/v2`) | - | +| Название продукта | Да | Название продукта в DefectDojo | - | #### Дополнительные возможности виджета При просмотре виджета доступна настройка следующих параметров: -* **Активные уязвимости** - если включено, то загружаются уязвимости продукта с флагом ‘Active’ = true. Если отключено, то загружаются уязвимости продукта с флагом ‘Active’ = false. Включено по умолчанию. -* **Дублирующиеся уязвимости** - если включено, то загружаются уязвимости продукта с флагом ‘Duplicate’ = true. Если отключено, то загружаются уязвимости продукта с флагом ‘Duplicate’ = false. Отключено по умолчанию. +* «Активные уязвимости» — если включено, то загружаются уязвимости продукта с флагом ‘Active’ = true. Если отключено, то загружаются уязвимости продукта с флагом ‘Active’ = false. Включено по умолчанию. +* «Дублирующиеся уязвимости» — если включено, то загружаются уязвимости продукта с флагом ‘Duplicate’ = true. Если отключено, то загружаются уязвимости продукта с флагом ‘Duplicate’ = false. Отключено по умолчанию. ### Docker образы @@ -302,7 +302,7 @@ title: Типы виджетов | Название | Обязательность | Описание | Значение по умолчанию | |------------|----------------|--------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------| -| URL | **Да** | URL Docker Registry. Используется для получения данных о доступных образах | - | +| URL | Да | URL Docker Registry. Используется для получения данных о доступных образах | - | | Название | Нет | Название репозитория, из которого будут загружаться данные в виджет. Пример: `repo`. Без указания названия, будут получены все доступные образы | - | ### GitLab. Запросы слияния @@ -317,17 +317,17 @@ title: Типы виджетов | Название | Обязательность | Описание | Значение по умолчанию | |------------|-----------------|----------------------------------------------------------------------------|-----------------------| -| URL | **Да** | URL GitLab API. Используется для получения данных из GitLab | - | -| ID проекта | **Да** | ID проекта, из которого будут загружаться данные в виджет. Пример: `12345` | - | +| URL | Да | URL GitLab API. Используется для получения данных из GitLab | - | +| ID проекта | Да | ID проекта, из которого будут загружаться данные в виджет. Пример: `12345` | - | #### Фильтрация по статусу Виджет позволяет фильтровать отображаемые Merge Requests по статусу. В настройках запроса виджета можно выбрать один из следующих статусов: -- **Открытые** - показывает только открытые MR. -- **Закрытые** - показывает только закрытые MR. -- **Слитые** - показывает только слитые MR. -- **Заблокированные** - показывает только заблокированные MR. +- «Открытые» — показывает только открытые MR. +- «Закрытые» — показывает только закрытые MR. +- «Слитые» — показывает только слитые MR. +- «Заблокированные» — показывает только заблокированные MR. По умолчанию отображаются только открытые MR. @@ -335,10 +335,10 @@ title: Типы виджетов При активированной функции действий в настройках виджет позволяет выполнять следующие действия с Merge Requests: -- **Слить** - слияние открытого запроса на слияние (доступно только для открытых MR). -- **Закрыть** - закрытие запроса на слияние. -- **Отметить как черновик/готово** - изменение статуса черновика запроса на слияние. -- **Просмотр изменений** - просмотр диффа (изменений) в запросе на слияние. +- «Слить» — слияние открытого запроса на слияние (доступно только для открытых MR). +- «Закрыть» — закрытие запроса на слияние. +- «Отметить как черновик/готово» — изменение статуса черновика запроса на слияние. +- «Просмотр изменений» — просмотр диффа (изменений) в запросе на слияние. {{< alert level="info" >}} Для выполнения действий с MR требуются соответствующие права доступа в репозитории GitLab. @@ -356,20 +356,20 @@ title: Типы виджетов | Название | Обязательность | Описание | Значение по умолчанию | |------------|-----------------|----------------------------------------------------------------------------|-----------------------| -| URL | **Да** | URL GitLab API. Используется для получения данных из GitLab | - | -| ID проекта | **Да** | ID проекта, из которого будут загружаться данные в виджет. Пример: `12345` | - | +| URL | Да | URL GitLab API. Используется для получения данных из GitLab | - | +| ID проекта | Да | ID проекта, из которого будут загружаться данные в виджет. Пример: `12345` | - | #### Дополнительные возможности виджета ##### Запуск пайплайнов -Виджет позволяет запускать пайплайны в GitLab напрямую из платформы DDP. +Виджет позволяет запускать пайплайны в GitLab напрямую из DDP. ###### Конфигурация | Название | Обязательность | Описание | Значение по умолчанию | |------------|----------------|------------------------------------------------------------------------------------|-----------------------| -| Ref | **Да** | Целевая ветка или тег для запуска пайплайна | - | +| Ref | Да | Целевая ветка или тег для запуска пайплайна | - | | Переменные | Нет | Переменные в формате ключ-значение, которые будут переданы в запускаемый пайплайн | - | ### GitLab. Редактор пайплайна @@ -384,15 +384,15 @@ title: Типы виджетов | Название | Обязательность | Описание | Значение по умолчанию | |------------|-----------------|----------------------------------------------------------------------------|-----------------------| -| URL | **Да** | URL GitLab API. Используется для получения данных из GitLab | - | -| ID проекта | **Да** | ID проекта, из которого будут загружаться данные в виджет. Пример: `12345` | - | +| URL | Да | URL GitLab API. Используется для получения данных из GitLab | - | +| ID проекта | Да | ID проекта, из которого будут загружаться данные в виджет. Пример: `12345` | - | #### Отображаемые данные Виджет отображает: -* **Редактор кода** - Monaco Editor для редактирования файла `.gitlab-ci.yml`. -* **Дифф-просмотр** - отображение изменений между оригинальной и редактируемой версией конфигурации. +* «Редактор кода» — Monaco Editor для редактирования файла `.gitlab-ci.yml`. +* «Дифф-просмотр» — отображение изменений между оригинальной и редактируемой версией конфигурации. #### Дополнительные возможности виджета @@ -404,11 +404,11 @@ title: Типы виджетов | Название | Обязательность | Описание | Значение по умолчанию | |-------------------|--------------|--------------------------------------------------------------|-----------------------| -| Заголовок MR | **Да** | Краткий заголовок, описывающий цель запроса на слияние | - | +| Заголовок MR | Да | Краткий заголовок, описывающий цель запроса на слияние | - | | Описание MR | Нет | Подробное описание запроса на слияние и изменений | - | -| Название новой ветки | **Да** | Название новой ветки, которая будет содержать ваши изменения | - | -| Целевая ветка | **Да** | Ветка, в которую будет выполнен запрос на слияние | main | -| Сообщение коммита | **Да** | Описание изменений, внесенных в конфигурацию пайплайна | - | +| Название новой ветки | Да | Название новой ветки, которая будет содержать ваши изменения | - | +| Целевая ветка | Да | Ветка, в которую будет выполнен запрос на слияние | main | +| Сообщение коммита | Да | Описание изменений, внесенных в конфигурацию пайплайна | - | ##### Ограничения @@ -428,8 +428,8 @@ title: Типы виджетов | Название | Обязательность | Описание | Значение по умолчанию | |------------|-----------------|----------------------------------------------------------------------------|-----------------------| -| URL | **Да** | URL GitLab API. Используется для получения данных из GitLab | - | -| ID проекта | **Да** | ID проекта, из которого будут загружаться данные в виджет. Пример: `12345` | - | +| URL | Да | URL GitLab API. Используется для получения данных из GitLab | - | +| ID проекта | Да | ID проекта, из которого будут загружаться данные в виджет. Пример: `12345` | - | #### Отображаемые данные @@ -437,10 +437,10 @@ title: Типы виджетов ##### Основные метрики -* **Общее количество пайплайнов** - общее число пайплайнов за выбранный период. -* **Процент успеха** - процент успешно выполненных пайплайнов. -* **Процент неудач** - процент неудачно выполненных пайплайнов. -* **Средняя длительность** - среднее время выполнения пайплайнов. +* «Общее количество пайплайнов» — общее число пайплайнов за выбранный период. +* «Процент успеха» — процент успешно выполненных пайплайнов. +* «Процент неудач» — процент неудачно выполненных пайплайнов. +* «Средняя длительность» — среднее время выполнения пайплайнов. ##### Распределение по статусам @@ -472,8 +472,8 @@ title: Типы виджетов | Название | Обязательность | Описание | Значение по умолчанию | |-------------|----------------|------------------------------------------------------------------------------------------|-----------------------| -| Начальная дата | **Да** | Начальная дата для анализа пайплайнов в формате ISO 8601. Пример: `2024-01-01T00:00:00Z` | - | -| Конечная дата | **Да** | Конечная дата для анализа пайплайнов в формате ISO 8601. Пример: `2024-01-31T23:59:59Z` | - | +| Начальная дата | Да | Начальная дата для анализа пайплайнов в формате ISO 8601. Пример: `2024-01-01T00:00:00Z` | - | +| Конечная дата | Да | Конечная дата для анализа пайплайнов в формате ISO 8601. Пример: `2024-01-31T23:59:59Z` | - | | Ветка | Нет | Фильтр по конкретной ветке. Если не указана, анализируются все ветки | - | #### Ограничения @@ -494,21 +494,21 @@ title: Типы виджетов | Название | Обязательность | Описание | Значение по умолчанию | |------------|-----------------|----------------------------------------------------------------------------|-----------------------| -| URL | **Да** | URL GitLab API. Используется для получения данных из GitLab | - | -| ID проекта | **Да** | ID проекта, из которого будут загружаться данные в виджет. Пример: `12345` | - | +| URL | Да | URL GitLab API. Используется для получения данных из GitLab | - | +| ID проекта | Да | ID проекта, из которого будут загружаться данные в виджет. Пример: `12345` | - | #### Дополнительные возможности виджета ##### Создание тегов -Виджет позволяет создать теги в GitLab напрямую из платформы DDP. +Виджет позволяет создать теги в GitLab напрямую из DDP. ###### Конфигурация | Название | Обязательность | Описание | Значение по умолчанию | |------------|----------------|---------------------------------------------|-----------------------| -| Название | **Да** | Название создаваемого тега | - | -| Создать из | **Да** | Ветка или существующий тег, от которого создаётся новый тег | - | +| Название | Да | Название создаваемого тега | - | +| Создать из | Да | Ветка или существующий тег, от которого создаётся новый тег | - | | Описание | Нет | Описание создаваемого тега | - | ### Bitbucket. Теги @@ -523,28 +523,28 @@ title: Типы виджетов | Название | Обязательность | Описание | Пример | |--------------|-----------------|-----------------------------------------------------------------|------------------------------------------------------------------------| -| Ключ проекта | **Да** | Часть URL репозитория, которая идёт сразу после **/projects/** | Для репозитория `.../projects/MYTEAM/repos/backend` укажите `MYTEAM` | -| Репозиторий | **Да** | Часть URL репозитория, которая идёт сразу после **/repos/** | Для репозитория `.../projects/MYTEAM/repos/backend` укажите `backend` | +| Ключ проекта | Да | Часть URL репозитория, которая идёт сразу после `/projects/` | Для репозитория `.../projects/MYTEAM/repos/backend` укажите `MYTEAM` | +| Репозиторий | Да | Часть URL репозитория, которая идёт сразу после `/repos/` | Для репозитория `.../projects/MYTEAM/repos/backend` укажите `backend` | #### Отображаемые данные Виджет отображает список тегов репозитория с информацией о каждом теге: -* **Название тега** — название тега. -* **Коммит** — хеш коммита, сообщение коммита, автор, дата создания, ссылка на коммит в Bitbucket. +* «Название тега» — название тега. +* «Коммит» — хеш коммита, сообщение коммита, автор, дата создания, ссылка на коммит в Bitbucket. #### Дополнительные возможности виджета ##### Создание тегов -Виджет позволяет создавать теги в Bitbucket напрямую из платформы DDP. +Виджет позволяет создавать теги в Bitbucket напрямую из DDP. ###### Конфигурация | Название | Обязательность | Описание | |------------|----------------|------------------------------------------------------------------------------------| -| Название | **Да** | Название создаваемого тега | -| Создать из | **Да** | Ветка или существующий тег, от которого создаётся новый тег (выбирается из списка) | +| Название | Да | Название создаваемого тега | +| Создать из | Да | Ветка или существующий тег, от которого создаётся новый тег (выбирается из списка) | | Описание | Нет | Описание создаваемого тега | ### GitHub. Теги @@ -554,24 +554,24 @@ title: Типы виджетов #### Авторизация Конфигурация авторизации описана в разделе [«Внешние сервисы»](../external-services/#github). -В настройках внешнего сервиса в поле **URL** необходимо указать `https://api.github.com`. +В настройках внешнего сервиса в поле «URL» необходимо указать `https://api.github.com`. #### Учётная запись и автор действий -Запросы к GitHub выполняются с токеном из учётных данных того пользователя платформы, от имени которого вызывается действие. Если в настройках виджета включено **Выбрать учётную запись для виджета**, используются учётные данные выбранного пользователя платформы, а не текущего. +Запросы к GitHub выполняются с токеном из учётных данных того пользователя платформы, от имени которого вызывается действие. Если в настройках виджета включено «Выбрать учётную запись для виджета», используются учётные данные выбранного пользователя платформы, а не текущего. -**Аннотированный тег** (поле **Описание** заполнено): в метаданных git-тега поля автора аннотации (**tagger**) заполняются из имени и email пользователя платформы, выполнившего действие (как в профиле в DDP). Если имя не задано, может подставляться email. +«Аннотированный тег» (поле «Описание» заполнено): в метаданных git-тега поля автора аннотации (`tagger`) заполняются из имени и email пользователя платформы, выполнившего действие (как в профиле в DDP). Если имя не задано, может подставляться email. -**Лёгкий тег** (без описания): отдельный автор тега в git не задаётся; создаётся ссылка на коммит. +«Лёгкий тег» (без описания): отдельный автор тега в git не задаётся; создаётся ссылка на коммит. -Создание тега через API выполняется от учётной записи GitHub по токену; данные **tagger** при этом берутся из профиля DDP и могут не совпадать с логином GitHub. +Создание тега через API выполняется от учётной записи GitHub по токену; данные `tagger` при этом берутся из профиля DDP и могут не совпадать с логином GitHub. #### Конфигурация | Название | Обязательность | Описание | Пример | |----------------------|----------------|------------------------------------------------------|------------------------------------------------------------| -| Владелец репозитория | **Да** | Владелец репозитория (организация или пользователь). | Для `https://github.com/example/my-repo` укажите `example` | -| Репозиторий | **Да** | Название репозитория без `.git`. | Для `https://github.com/example/my-repo` укажите `my-repo` | +| Владелец репозитория | Да | Владелец репозитория (организация или пользователь) | Для `https://github.com/example/my-repo` укажите `example` | +| Репозиторий | Да | Название репозитория без `.git` | Для `https://github.com/example/my-repo` укажите `my-repo` | #### Отображаемые данные @@ -585,8 +585,8 @@ title: Типы виджетов | Название | Обязательность | Описание | Значение по умолчанию | |---------------|----------------|-------------------------------------------------------------------------------------------|-----------------------| -| Название тега | **Да** | Уникальное название тега, например `v1.0.0` или `release-2024-01` | — | -| Создать из | **Да** | Ветка или существующий тег, от которого создаётся новый тег | — | +| Название тега | Да | Уникальное название тега, например `v1.0.0` или `release-2024-01` | — | +| Создать из | Да | Ветка или существующий тег, от которого создаётся новый тег | — | | Описание | Нет | Аннотация к тегу (например, описание релиза). Если указано, создаётся аннотированный тег | — | {{< alert level="info" >}} @@ -605,18 +605,18 @@ title: Типы виджетов | Название | Обязательность | Описание | Значение по умолчанию | |------------|-----------------|----------------------------------------------------------------------------|-----------------------| -| ID проекта | **Да** | ID проекта, из которого будут загружаться данные в виджет. Пример: `12345` | - | +| ID проекта | Да | ID проекта, из которого будут загружаться данные в виджет. Пример: `12345` | - | #### Дополнительные возможности виджета ##### Создание релиза -Виджет позволяет создать релиз в GitLab напрямую из платформы DDP: +Виджет позволяет создать релиз в GitLab напрямую из DDP: | Название | Обязательность | Описание | Значение по умолчанию | |-----------------|----------------|---------------------------------------------------------------------------------------------------|-----------------------| -| Название релиза | **Да** | Название релиза, отображаемое в списке | - | -| Тег | **Да** | Существующий тег, на основе которого будет сформирован релиз (выбирается из списка тегов проекта) | - | +| Название релиза | Да | Название релиза, отображаемое в списке | - | +| Тег | Да | Существующий тег, на основе которого будет сформирован релиз (выбирается из списка тегов проекта) | - | | Описание | Нет | Описание релиза в формате Markdown | - | Созданный релиз автоматически появляется в списке, а последний релиз подсвечивается. @@ -633,11 +633,11 @@ title: Типы виджетов | Название | Обязательность | Описание | Значение по умолчанию | |------------|-----------------|----------------------------------------------------------------------------|-----------------------| -| ID проекта | **Да** | ID проекта, из которого будут загружаться данные в виджет. Пример: `12345` | - | +| ID проекта | Да | ID проекта, из которого будут загружаться данные в виджет. Пример: `12345` | - | ### Просмотр репозитория -Виджет позволяет просматривать структуру и содержимое файлов в репозитории. Поддерживаются репозитории **GitLab**, **Bitbucket** и **GitHub**. +Виджет позволяет просматривать структуру и содержимое файлов в репозитории. Поддерживаются репозитории GitLab, Bitbucket и GitHub. #### Авторизация @@ -651,7 +651,7 @@ title: Типы виджетов | Название | Обязательность | Описание | Значение по умолчанию | |--------------|----------------|--------------------------------------------------------------------|-----------------------| -| Провайдер | **Да** | Сервис, в котором размещён репозиторий (GitLab, GitHub, Bitbucket) | - | +| Провайдер | Да | Сервис, в котором размещён репозиторий (GitLab, GitHub, Bitbucket) | - | | Ветка / Тег | Нет | Название ветки, тег или SHA коммита (по умолчанию: main) | main | | Путь | Нет | Путь к директории в репозитории (оставьте пустым для корня) | - | | Рекурсивно | Нет | Получать файлы рекурсивно из поддиректорий | false | @@ -660,21 +660,21 @@ title: Типы виджетов | Название | Обязательность | Описание | Значение по умолчанию | |--------------|-----------------|--------------------------------------------------|-----------------------| -| ID проекта | **Да** | ID проекта в GitLab (например, 12345). | - | +| ID проекта | Да | ID проекта в GitLab (например, 12345) | - | #### Конфигурация для Bitbucket | Название | Обязательность | Описание | Пример | Значение по умолчанию | |---------------------------|----------------|------------------------------------------------------------|----------|-----------------------| -| Ключ проекта | **Да** | Ключ проекта в Bitbucket (например, MYPROJ) | MYPROJ | - | -| Идентификатор репозитория | **Да** | Идентификатор репозитория в Bitbucket (например, my-repo) | my-repo | - | +| Ключ проекта | Да | Ключ проекта в Bitbucket (например, MYPROJ) | MYPROJ | - | +| Идентификатор репозитория | Да | Идентификатор репозитория в Bitbucket (например, my-repo) | my-repo | - | #### Конфигурация для GitHub | Название | Обязательность | Описание | Значение по умолчанию | |----------------------|----------------|-------------------------------------------------------------------------------------------------------------------------|-----------------------| -| Владелец репозитория | **Да** | Владелец репозитория (организация или пользователь). Пример: для `https://github.com/example/my-repo` укажите «example» | - | -| Репозиторий | **Да** | Название репозитория без `.git`. Пример: для `https://github.com/example/my-repo` укажите «my-repo» | - | +| Владелец репозитория | Да | Владелец репозитория (организация или пользователь). Пример: для `https://github.com/example/my-repo` укажите «example» | - | +| Репозиторий | Да | Название репозитория без `.git`. Пример: для `https://github.com/example/my-repo` укажите «my-repo» | - | ### Jenkins. Пайплайны @@ -688,8 +688,8 @@ title: Типы виджетов | Название | Обязательность | Описание | Значение по умолчанию | |------------|-----------------|----------------------------------------------------------------------------|-----------------------| -| URL | **Да** | URL Jenkins. Используется для получения данных из Jenkins | - | -| Название | **Да** | Название пайплайна в Jenkins. Поддерживается вложенность: `folder1/folder2/jobName` | - | +| URL | Да | URL Jenkins. Используется для получения данных из Jenkins | - | +| Название | Да | Название пайплайна в Jenkins. Поддерживается вложенность: `folder1/folder2/jobName` | - | #### Отображаемые данные @@ -699,16 +699,16 @@ title: Типы виджетов Для обычных пайплайнов виджет отображает: -* **Список сборок** — таблица со всеми сборками пайплайна с информацией о номере, статусе, длительности, времени выполнения и пользователе. -* **Последняя сборка** — информация о последней выполненной сборке. -* **Последняя успешная сборка** — информация о последней успешной сборке. -* **Последняя неудачная сборка** — информация о последней неудачной сборке. +* «Список сборок» — таблица со всеми сборками пайплайна с информацией о номере, статусе, длительности, времени выполнения и пользователе. +* «Последняя сборка» — информация о последней выполненной сборке. +* «Последняя успешная сборка» — информация о последней успешной сборке. +* «Последняя неудачная сборка» — информация о последней неудачной сборке. ##### Multibranch пайплайны Для multibranch пайплайнов виджет отображает: -* **Список веток** — таблица со всеми ветками с информацией о статусе, количестве сборок и последней сборке для каждой ветки. +* «Список веток» — таблица со всеми ветками с информацией о статусе, количестве сборок и последней сборке для каждой ветки. * Всю информацию, описанную в разделе «обычные пайплайны», в разрезе каждой ветки. #### Дополнительные возможности виджета @@ -717,21 +717,21 @@ title: Типы виджетов ##### Для обычных пайплайнов -* **Запустить сборку** — запуск новой сборки. Если у сборки есть параметры, отображается диалог для их ввода: - * Строковые параметры. - * Пароли. - * Выбор из списка. - * Булевы значения. -* **Отменить сборку** — отмена выполняющейся сборки. -* **Повторить сборку** — повторный запуск последней сборки. -* **Просмотр логов** — просмотр логов выполнения сборки. +* «Запустить сборку» — запуск новой сборки. Если у сборки есть параметры, отображается диалог для их ввода: + * Строковые параметры; + * Пароли; + * Выбор из списка; + * Булевые значения. +* «Отменить сборку» — отмена выполняющейся сборки. +* «Повторить сборку» — повторный запуск последней сборки. +* «Просмотр логов» — просмотр логов выполнения сборки. ##### Для multibranch пайплайнов -* **Запустить сборку ветки** — запуск новой сборки для конкретной ветки. Если у сборки есть параметры, отображается диалог для их ввода. -* **Получить сборки ветки** — загрузка списка сборок для конкретной ветки. -* **Сканировать multibranch** — запуск сканирования multibranch пайплайна для обнаружения новых веток. -* **Просмотр логов** — просмотр логов выполнения сборки. +* «Запустить сборку ветки» — запуск новой сборки для конкретной ветки. Если у сборки есть параметры, отображается диалог для их ввода. +* «Получить сборки ветки» — загрузка списка сборок для конкретной ветки. +* «Сканировать multibranch» — запуск сканирования multibranch пайплайна для обнаружения новых веток. +* «Просмотр логов» — просмотр логов выполнения сборки. ### Jira. Задачи @@ -745,8 +745,8 @@ title: Типы виджетов | Название | Обязательность | Описание | Значение по умолчанию | |------------|-----------------|-----------------------------------------------------------------------------|-----------------------| -| URL | **Да** | URL Jira. Используется для получения данных из Jira | - | -| JQL | **Да** | JQL-запрос для фильтрации задач. Пример: `project = PROJ AND status = Open` | - | +| URL | Да | URL Jira. Используется для получения данных из Jira | - | +| JQL | Да | JQL-запрос для фильтрации задач. Пример: `project = PROJ AND status = Open` | - | #### Параметры запроса @@ -757,19 +757,19 @@ title: Типы виджетов #### Дополнительные возможности виджета -* **Просмотр описания** — при клике на кнопку "Просмотр описания" открывается диалоговое окно с полным описанием задачи. -* **Переход в Jira** — клик по ключу задачи открывает задачу в Jira в новой вкладке. -* **Динамическая фильтрация** — возможность изменить JQL-запрос и максимальное количество результатов прямо в виджете без изменения конфигурации. +* «Просмотр описания» — при клике на кнопку «Просмотр описания» открывается диалоговое окно с полным описанием задачи. +* «Переход в Jira» — клик по ключу задачи открывает задачу в Jira в новой вкладке. +* «Динамическая фильтрация» — возможность изменить JQL-запрос и максимальное количество результатов прямо в виджете без изменения конфигурации. ### Helm. Релизы -Виджет позволяет отображать данные о Helm Releases в Kubernetes и производить rollback на предыдущие версии. +Виджет позволяет отображать данные о Helm-релизах в Kubernetes и производить rollback на предыдущие версии. Данные, отображаемые на виджете: -* **Список релизов Helm**: информация о текущих релизах, созданных с помощью Helm в указанном Kubernetes пространстве. -* **Манифесты релизов**: манифесты, связанные с Helm-релизами в указанном Kubernetes пространстве. Это включает в себя файлы YAML, которые определяют конфигурацию и состояние ресурсов. -* **Values**: переменные, которые использовались для развертывания Helm-релизов. +* «Список релизов Helm» — информация о текущих релизах, созданных с помощью Helm в указанном неймспейсе Kubernetes. +* «Манифесты релизов» — манифесты, связанные с Helm-релизами в указанном неймспейсе Kubernetes. Это включает в себя файлы YAML, которые определяют конфигурацию и состояние ресурсов. +* «Values» — переменные, которые использовались для развёртывания Helm-релизов. #### Авторизация @@ -785,7 +785,7 @@ title: Типы виджетов ### Iframe {{< alert level="warning" >}} -Виджет Iframe работает только при включенной опции `allowIframe: true` в конфигурации заголовков безопасности (`security.headers.csp.allowIframe`). По умолчанию эта опция отключена, поэтому виджет не будет отображать контент до изменения конфигурации. +Виджет Iframe работает только при включённой опции `allowIframe: true` в конфигурации заголовков безопасности (`security.headers.csp.allowIframe`). По умолчанию эта опция отключена, поэтому виджет не будет отображать контент до изменения конфигурации. {{< /alert >}} Виджет позволяет отображать данные из внешнего источника. @@ -794,7 +794,7 @@ title: Типы виджетов | Название | Обязательность | Описание | Значение по умолчанию | |------------|-----------------|------------------------------------------------------------------------|-----------------------| -| URL | **Да** | URL внешнего источника. Используется для отображения данных в виджете | - | +| URL | Да | URL внешнего источника. Используется для отображения данных в виджете | - | ### Kafka. ACLs @@ -822,11 +822,11 @@ title: Типы виджетов | Название | Обязательность | Описание | Значение по умолчанию | |-------------------------|----------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------| -| URL | **Да** | URL Kafka кластера | - | -| Протокол аутентификации | **Да** | Протокол для подключения к Kafka. [Подробнее](https://kafka.apache.org/documentation/#adminclientconfigs_security.protocol) | - | -| Механизм SASL | Нет | Механизм аутентификации, который будет использовать SASL. Обязателен при использовании протокола SASL_PLAINTEXT или SASL_SSL. [Подробнее](https://kafka.apache.org/documentation/#security_sasl_mechanism) | - | -| Пользователь Kafka | **Да** | Username учётной записи для взаимодействия с Kafka | - | -| Пароль | **Да** | Пароль учётной записи для взаимодействия с Kafka | - | +| URL | Да | URL Kafka-кластера | - | +| Протокол аутентификации | Да | Протокол для подключения к Kafka. [Список протоколов в документации Kafka](https://kafka.apache.org/documentation/#adminclientconfigs_security.protocol) | - | +| Механизм SASL | Нет | Механизм аутентификации, который будет использовать SASL. Обязателен при использовании протокола SASL_PLAINTEXT или SASL_SSL. [Список механизмов SASL в документации Kafka](https://kafka.apache.org/documentation/#security_sasl_mechanism) | - | +| Пользователь Kafka | Да | Username учётной записи для взаимодействия с Kafka | - | +| Пароль | Да | Пароль учётной записи для взаимодействия с Kafka | - | | Типы ресурсов | Нет | Фильтр по типам ресурсов | - | | Типы шаблонов | Нет | Фильтр по типам шаблонов | - | | Операции | Нет | Фильтр по операциям | - | @@ -848,7 +848,7 @@ title: Типы виджетов Для каждого топика доступно: * Общая информация о топике: основные параметры, конфигурация и статус. -* Информация о партициях: лидер и оффсеты, количество реплик и т.д. +* Информация о партициях: лидер и оффсеты, количество реплик и т. д. * Информация о консьюмерах: список активных потребителей, их группы, текущие оффсеты и лаги. * Сообщения: просмотр содержимого сообщений топиков. * Поиск сообщений: фильтрация сообщений по timestamp и offset. @@ -870,32 +870,32 @@ title: Типы виджетов | Название | Обязательность | Описание | Значение по умолчанию | |-------------------------|----------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------| -| URL | **Да** | URL Kafka кластера | - | -| Протокол аутентификации | **Да** | Протокол для подключения к Kafka. [Подробнее](https://kafka.apache.org/documentation/#adminclientconfigs_security.protocol) | - | -| Механизм SASL | Нет | Механизм аутентификации, который будет использовать SASL. Обязателен при использовании протокола SASL_PLAINTEXT или SASL_SSL. [Подробнее](https://kafka.apache.org/documentation/#security_sasl_mechanism) | - | -| Пользователь Kafka | **Да** | username учётной записи для взаимодействия с Kafka | - | -| Пароль | **Да** | пароль учётной записи для взаимодействия с Kafka | - | -| Топики Kafka | Нет | Название топика или регулярное выражение для фильтрации отображаемых топиков в виджете; при пустом значении отображаются все доступные пользователю топики. | - | +| URL | Да | URL Kafka-кластера | - | +| Протокол аутентификации | Да | Протокол для подключения к Kafka. [Список протоколов в документации Kafka](https://kafka.apache.org/documentation/#adminclientconfigs_security.protocol) | - | +| Механизм SASL | Нет | Механизм аутентификации, который будет использовать SASL. Обязателен при использовании протокола SASL_PLAINTEXT или SASL_SSL. [Список механизмов SASL в документации Kafka](https://kafka.apache.org/documentation/#security_sasl_mechanism) | - | +| Пользователь Kafka | Да | Username учётной записи для взаимодействия с Kafka | - | +| Пароль | Да | Пароль учётной записи для взаимодействия с Kafka | - | +| Топики Kafka | Нет | Название топика или регулярное выражение для фильтрации отображаемых топиков в виджете; при пустом значении отображаются все доступные пользователю топики | - | #### Дополнительные возможности виджета При активированной функции действий в настройках виджет позволяет: -* Создавать новые топики. -* Удалять существующие топики. -* Отправлять сообщение в топик. +* Создавать новые топики; +* Удалять существующие топики; +* Отправлять сообщение в топик; * Очищать топик от сообщений. ### Kubernetes deployments -Виджет Kubernetes deployments позволяет выводить основную информацию обо всех deployments в Kubernetes кластере. Доступна фильтрация по namespace и/или по label selector. +Виджет Kubernetes deployments позволяет выводить основную информацию обо всех deployments в кластере Kubernetes. Доступна фильтрация по неймспейсу и/или по label selector. Для каждого ресурса Deployment доступны: -- **Просмотр спецификации и статуса Deployment**. -- **Масштабирование количества реплик Deployment**. Для применения изменений после выбора требуемого количества реплик необходимо нажать кнопку «Сохранить» с иконкой дискеты. -- **Просмотр информации о подах**, управляемых Deployment, и контейнерах этих подов, включая просмотр логов каждого контейнера. -- **Просмотр и редактирование ресурсов контейнеров**. Виджет отображает все настроенные ресурсы контейнеров, включая CPU, Memory, ephemeral-storage и другие типы ресурсов. Редактирование доступно только для CPU и Memory в секциях `requests` и `limits`. Изменения применяются на уровне Deployment и распространяются на все поды, управляемые данным Deployment. При очистке значений CPU или Memory соответствующие ресурсы удаляются из конфигурации контейнера. Остальные ресурсы (например, `ephemeral-storage`) отображаются, но не могут быть отредактированы через виджет. +- «Просмотр спецификации и статуса Deployment». +- «Масштабирование количества реплик Deployment». Для применения изменений после выбора требуемого количества реплик необходимо нажать кнопку «Сохранить» с иконкой дискеты. +- «Просмотр информации о подах», управляемых Deployment, и контейнерах этих подов, включая просмотр логов каждого контейнера. +- «Просмотр и редактирование ресурсов контейнеров». Виджет отображает все настроенные ресурсы контейнеров, включая CPU, Memory, ephemeral-storage и другие типы ресурсов. Редактирование доступно только для CPU и Memory в секциях `requests` и `limits`. Изменения применяются на уровне Deployment и распространяются на все поды, управляемые данным Deployment. При очистке значений CPU или Memory соответствующие ресурсы удаляются из конфигурации контейнера. Остальные ресурсы (например, `ephemeral-storage`) отображаются, но не могут быть отредактированы через виджет. #### Авторизация @@ -905,13 +905,13 @@ title: Типы виджетов | Название | Обязательность | Описание | Значение по умолчанию | |---------------------|----------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------| -| Kubernetes API | **Да** | URL API сервера Kubernetes. Используется для получения данных из Kubernetes | - | -| Namespace | Нет | Kubernetes namespace из которого будут загружаться deployment. В случае, если namespace не указан, виджет будет пытаться загрузить все deployment кластера. Пример: `default` | - | +| Kubernetes API | Да | URL API сервера Kubernetes. Используется для получения данных из Kubernetes | - | +| Namespace | Нет | Неймспейс Kubernetes, из которого будут загружаться deployment. Если неймспейс не указан, виджет будет пытаться загрузить все deployment кластера. Пример: `default` | - | | Label selector | Нет | Селекторы для фильтрации получаемых deployment. Перечисляются через запятую. Пример: `app.kubernetes.io/name=example` | - | ### Kubernetes ingresses -Виджет позволяет отображать данные о Ingress в платформе Kubernetes. +Виджет позволяет отображать данные об Ingress в кластере Kubernetes. Для каждого Ingress доступны: @@ -927,13 +927,13 @@ title: Типы виджетов | Название | Обязательность | Описание | Значение по умолчанию | |----------------|----------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------| -| URL | **Да** | URL API сервера Kubernetes. Используется для получения данных из Kubernetes | - | -| Namespace | Нет | Неймспейс Kubernetes из которого будут загружаться ingresses. В случае, если неймспейс не указан, виджет будет пытаться загрузить все ingress кластера. Пример: `default` | - | +| URL | Да | URL API сервера Kubernetes. Используется для получения данных из Kubernetes | - | +| Namespace | Нет | Неймспейс Kubernetes, из которого будут загружаться ingresses. Если неймспейс не указан, виджет будет пытаться загрузить все ingress кластера. Пример: `default` | - | | Label selector | Нет | Селекторы для фильтрации получаемых ingress. Перечисляются через запятую. Пример: `app.kubernetes.io/name=example` | - | ### Kubernetes pods -Виджет позволяет отображать данные о подах в платформе Kubernetes. +Виджет позволяет отображать данные о подах в кластере Kubernetes. Для каждого pod доступны: @@ -949,7 +949,7 @@ title: Типы виджетов | Название | Обязательность | Описание | Значение по умолчанию | |----------------|----------------|------------------------------------------------------------------------------------------------------------------|-----------------------| -| URL | **Да** | URL API сервера Kubernetes. Используется для получения данных из Kubernetes | - | +| URL | Да | URL API сервера Kubernetes. Используется для получения данных из Kubernetes | - | | Namespace | Нет | Неймспейс, из которого будут загружаться данные в виджет. Пример: `default` | - | | Label selector | Нет | Селекторы для фильтрации получаемых подов. Перечисляются через запятую. Пример: `app.kubernetes.io/name=example` | - | @@ -961,7 +961,7 @@ title: Типы виджетов | Название | Обязательность | Описание | Значение по умолчанию | |------------|-----------------|---------------------------------------------------------------------------------------|-----------------------| -| Markdown | **Да** | Текст в формате Markdown. Отображается в виджете в отформатированном виде | - | +| Markdown | Да | Текст в формате Markdown. Отображается в виджете в отформатированном виде | - | ### Nexus artifacts @@ -975,13 +975,13 @@ title: Типы виджетов | Название | Обязательность | Описание | Значение по умолчанию | |------------|----------------|-------------------------------------------------------------------------------------|-----------------------| -| URL | **Да** | URL Nexus API. Используется для получения данных из Nexus | - | -| Repository | **Да** | Название репозитория, данные из которого будут отображаться в виджете. Пример: `my-repo` | - | +| URL | Да | URL Nexus API. Используется для получения данных из Nexus | - | +| Repository | Да | Название репозитория, данные из которого будут отображаться в виджете. Пример: `my-repo` | - | | Name | Нет | Название артефакта, данные о котором будут отображаться в виджете | - | ### Opensearch index -Виджет Opensearch index позволяет отобразить данные из определенного index или index pattern в платформе. Данные по умолчанию сортируются от более новых к более старым. Доступен полнотекстовый поиск для фильтрации отображаемых данных. Для каждой записи (строки таблицы) доступно отображение в формате «ключ-значение», либо в JSON. При указании index pattern в виджете будет выводиться ссылка на страницу Discover в OpenSearch Dashboards. +Виджет Opensearch index позволяет отобразить данные из определённого index или index pattern в платформе. Данные по умолчанию сортируются от более новых к более старым. Доступен полнотекстовый поиск для фильтрации отображаемых данных. Для каждой записи (строки таблицы) доступно отображение в формате «ключ-значение», либо в JSON. При указании index pattern в виджете будет выводиться ссылка на страницу Discover в OpenSearch Dashboards. #### Авторизация @@ -991,9 +991,9 @@ title: Типы виджетов | Название | Обязательность | Описание | Значение по умолчанию | |--------------------------|----------------|-------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------| -| API URL | **Да** | URL Opensearch API. Используется для получения данных из Opensearch | - | -| Dashboards URL | **Да** | URL Opensearch Dashboards. Используется при генерации ссылки для перехода в Opensearch и просмотра данных непосредственно в системе | - | -| Index pattern | **Да** | Название index pattern из которого будут загружаться данные в виджет. Может содержать символ «*». Примеры: `security-auditlog`, `security-auditlog-*` | - | +| API URL | Да | URL Opensearch API. Используется для получения данных из Opensearch | - | +| Dashboards URL | Да | URL Opensearch Dashboards. Используется при генерации ссылки для перехода в Opensearch и просмотра данных непосредственно в системе | - | +| Index pattern | Да | Название index pattern, из которого будут загружаться данные в виджет. Может содержать символ «*». Примеры: `security-auditlog`, `security-auditlog-*` | - | | Timestamp field | Нет | Название поля с timestamp. Значение поля выводится в таблице с данными в отдельной колонке | @timestamp | ### Prometheus metrics (range) @@ -1010,13 +1010,13 @@ rate(nginx_ingress_controller_nginx_process_connections[5m]) | Название | Обязательность | Описание | Значение по умолчанию | |-----------------------|----------------|--------------------------------------------------------------------------------------------------------------------------------------|-----------------------| -| URL | **Да** | URL Prometheus | - | -| Query | **Да** | Запрос метрики из Prometheus в формате PromQL | - | -| Шаг разрешения (сек.) | **Да** | Интервал между отсчетами на горизонтальной оси (в секундах) | 60 | -| Метка | **Да** | Метка в результатах запроса, чье уникальное значение присваивается в качестве названий соответствующих линий на графике визуализации | - | +| URL | Да | URL Prometheus | - | +| Query | Да | Запрос метрики из Prometheus в формате PromQL | - | +| Шаг разрешения (сек) | Да | Интервал между отсчётами на горизонтальной оси (в секундах) | 60 | +| Метка | Да | Метка в результатах запроса, чьё уникальное значение присваивается в качестве названий соответствующих линий на графике визуализации | - | | Порог | Нет | Порог, отображаемый в виде горизонтальной красной полосы на графике | - | -| Минимальное значение | Нет | Начальная точка отсчета для вертикальной линии на графике | - | -| Максимальное значение | Нет | Предельная точка отсчета для вертикальной линии на графике | - | +| Минимальное значение | Нет | Начальная точка отсчёта для вертикальной линии на графике | - | +| Максимальное значение | Нет | Предельная точка отсчёта для вертикальной линии на графике | - | | InsecureSkipVerify | Нет | Отключение проверки подлинности TLS/SSL-сертификата Prometheus | false | #### Авторизация @@ -1028,8 +1028,8 @@ rate(nginx_ingress_controller_nginx_process_connections[5m]) При просмотре виджета возможно настроить диапазон отображаемых значений. Доступные параметры отображения диапазона: * Интервал. -* Минимальное значение (начальная точка отсчета для вертикальной линии на графике). -* Максимальное значение (предельная точка отсчета для вертикальной линии на графике). +* Минимальное значение (начальная точка отсчёта для вертикальной линии на графике). +* Максимальное значение (предельная точка отсчёта для вертикальной линии на графике). ### Prometheus metrics (single) @@ -1045,15 +1045,15 @@ sum(ingress_nginx_detail_requests_total) | Название | Обязательность | Описание | Значение по умолчанию | |----------------------------------|----------------|-------------------------------------------------------------------------------------------------------------------------------|-----------------------| -| URL | **Да** | URL Prometheus | - | -| Query | **Да** | Query для запроса метрики из Prometheus в формате PromQL | - | +| URL | Да | URL Prometheus | - | +| Query | Да | Query для запроса метрики из Prometheus в формате PromQL | - | | Количество цифр после запятой | Нет | Точность, с которой будет выводиться полученное значение | - | | Единица измерения | Нет | Постфикс, с которым будет выводиться полученное значение | - | | Отображать пороговое значение | Нет | Отображать пороговое значение в формате <значение метрики> / <пороговое значение> | false | | Пороговое значение | Нет | Пороговое значение | - | | Меньшее значение считается лучше | Нет | Метрика считается «хорошей», когда её значение ниже заданного порогового значения | false | | Порог предупреждения (%) | Нет | Граница между красным и оранжевым цветами. Если значение метрики превышает этот процент от порога, оно получит оранжевый цвет | 60 | -| Порог успеха (%) | Нет | Граница между оранжевым и зелёным цветами. Если значение метрики превышает этот процент от порога, оно получит зеленый цвет | 90 | +| Порог успеха (%) | Нет | Граница между оранжевым и зелёным цветами. Если значение метрики превышает этот процент от порога, оно получит зелёный цвет | 90 | | InsecureSkipVerify | Нет | Отключение проверки подлинности TLS/SSL-сертификата Prometheus | false | #### Авторизация @@ -1072,10 +1072,10 @@ sum(ingress_nginx_detail_requests_total) | Название | Обязательность | Описание | Значение по умолчанию | |--------------|----------------|--------------------------------------------------------------------------------------------|-----------------------------------------| -| URL | **Да** | Адрес SonarQube, например, `https://sonarqube.example.com` | - | -| Ключ проекта | **Да** | Идентификатор проекта в SonarQube | - | -| Ветка | Нет | Ветка проекта для которой будут браться метрики | Согласно настройкам проекта в Sonarqube | -| Метрики | **Да** | Метрики проекта, которые будут выводиться в виджете. В конфигурации указывается Metric key | | +| URL | Да | Адрес SonarQube, например, `https://sonarqube.example.com` | - | +| Ключ проекта | Да | Идентификатор проекта в SonarQube | - | +| Ветка | Нет | Ветка проекта, для которой будут браться метрики | Согласно настройкам проекта в Sonarqube | +| Метрики | Да | Метрики проекта, которые будут выводиться в виджете. В конфигурации указывается Metric key | | [Список возможных метрик](https://docs.sonarsource.com/sonarqube-server/latest/user-guide/code-metrics/metrics-definition) для текущей версии SonarQube. @@ -1092,7 +1092,7 @@ sum(ingress_nginx_detail_requests_total) * Просмотр списка объектов в контейнере (bucket) с информацией о размере, дате изменения и классе хранения. * Поиск объектов по префиксу (пути). * Загрузка файлов из bucket. -* Просмотр детальной метаинформации объектов (размер, тип контента, метаданные, настройки кеширования и т.д.). +* Просмотр детальной метаинформации объектов (размер, тип контента, метаданные, настройки кеширования и т. д.). * Навигация по папкам bucket. #### Аутентификация @@ -1110,8 +1110,8 @@ sum(ingress_nginx_detail_requests_total) Для повышения безопасности можно использовать механизм шаблонизации с учётными данными: -* `{{ .credentials.accessKeyId }}` - подставить Access Key ID из учётных данных. -* `{{ .credentials.secretAccessKey }}` - подставить Secret Access Key из учётных данных. +* `{{ .credentials.accessKeyId }}` — подставить Access Key ID из учётных данных. +* `{{ .credentials.secretAccessKey }}` — подставить Secret Access Key из учётных данных. {{< alert level="info" >}} Доступность информации в виджете определяется уровнем прав подключённой учётной записи. @@ -1121,11 +1121,11 @@ sum(ingress_nginx_detail_requests_total) | Название | Обязательность | Описание | Значение по умолчанию | |--------------------|----------------|--------------------------------------------------------------------------------------|-----------------------| -| Название bucket | **Да** | Название S3 Bucket для просмотра | - | -| Endpoint | **Да** | Эндпоинт URL S3-совместимого хранилища (например, `https://storage.yandexcloud.net`) | - | -| Регион | **Да** | Регион, в котором находится Bucket | - | -| Access Key ID | **Да** | Идентификатор ключа доступа для аутентификации | - | -| Secret Access Key | **Да** | Секретный ключ доступа для аутентификации | - | +| Название bucket | Да | Название S3 Bucket для просмотра | - | +| Endpoint | Да | Эндпоинт URL S3-совместимого хранилища (например, `https://storage.yandexcloud.net`) | - | +| Регион | Да | Регион, в котором находится Bucket | - | +| Access Key ID | Да | Идентификатор ключа доступа для аутентификации | - | +| Secret Access Key | Да | Секретный ключ доступа для аутентификации | - | | Префикс | Нет | Префикс (путь) для фильтрации объектов при первоначальной загрузке | - | | Максимум объектов | Нет | Максимальное количество объектов для отображения за один запрос (по умолчанию 100) | 100 | @@ -1157,14 +1157,14 @@ sum(ingress_nginx_detail_requests_total) #### Подгрузка дополнительных объектов -При наличии большого количества объектов в bucket доступна функция «Загрузить еще» для пошаговой загрузки объектов без потери производительности. +При наличии большого количества объектов в bucket доступна функция «Загрузить ещё» для пошаговой загрузки объектов без потери производительности. ### Vault. Секреты Виджет позволяет просматривать секреты в HashiCorp Vault или Deckhouse Stronghold. Поддерживается работа с KV v2 секретами. {{< alert level="info" >}} -Виджет не передает значения секретов пользователю. На клиентскую сторону передаются только метаданные секретов (версия, время создания и т.д.) и структура ключей без их значений. +Виджет не передаёт значения секретов пользователю. На клиентскую сторону передаются только метаданные секретов (версия, время создания и т. д.) и структура ключей без их значений. {{< /alert >}} Для каждого секрета доступно: @@ -1182,7 +1182,7 @@ sum(ingress_nginx_detail_requests_total) | Название | Обязательность | Описание | Значение по умолчанию | |------------|----------------|---------------------------------------------------------------------------------------------------------------------------------------------|-----------------------| -| Путь | **Да** | Путь к секрету или директории в Vault. Необходимо явно указывать путь с `/data/`. Примеры: `services/data/`, `services/data/example` | - | +| Путь | Да | Путь к секрету или директории в Vault. Необходимо явно указывать путь с `/data/`. Примеры: `services/data/`, `services/data/example` | - | | Префикс UI | Нет | Префикс для URL интерфейса. Используйте `vault` для HashiCorp Vault или `stronghold` для Deckhouse Stronghold | - | #### Особенности работы с путями @@ -1199,44 +1199,44 @@ sum(ingress_nginx_detail_requests_total) ##### Структура секретов -* **Директории** — отображаются с завершающим слешем (например, `nested/`) и всегда помечаются как директории, даже если содержат ключи. -* **Секреты** — отображаются без завершающего слеша и содержат ключи. +* «Директории» — отображаются с завершающим слешем (например, `nested/`) и всегда помечаются как директории, даже если содержат ключи. +* «Секреты» — отображаются без завершающего слеша и содержат ключи. ##### Метаданные секрета Для каждого секрета отображаются следующие метаданные (если доступны): -* **Версия** — версия секрета в KV v2. -* **Время создания** — дата и время создания секрета. -* **Время удаления** — дата и время удаления секрета (для удаленных версий). -* **Статус уничтожения** — индикатор того, что секрет был уничтожен. +* «Версия» — версия секрета в KV v2. +* «Время создания» — дата и время создания секрета. +* «Время удаления» — дата и время удаления секрета (для удалённых версий). +* «Статус уничтожения» — индикатор того, что секрет был уничтожен. ##### Ключи секрета Ключи секрета отображаются в формате таблицы «ключ/значение»: -* **Ключ** — полный путь к ключу в структуре секрета (например, `database.host`). -* **Значение** — всегда маскируется символами `********` и не может быть раскрыто. +* Ключ — полный путь к ключу в структуре секрета (например, `database.host`). +* Значение — всегда маскируется символами `********` и не может быть раскрыто. ### График Виджет позволяет выводить информацию об объектах DDP в виде одного из следующих типов графиков: -* Столбчатая диаграмма. -* Кольцевая диаграмма. -* Круговая диаграмма. -* Полярная диаграмма. +* Столбчатая диаграмма; +* Кольцевая диаграмма; +* Круговая диаграмма; +* Полярная диаграмма; * Радарная диаграмма. #### Конфигурация | Название | Обязательность | Описание | Значение по умолчанию | |---------------------|----------------|--------------------------------------------------------------------------------------------|------------------------| -| Тип графика | **Да** | Тип визуализации графика | - | -| Название таблицы | **Да** | Название таблицы в базе данных, из которой будут браться записи для визуализации | - | -| Название поля | **Да** | Название поля, по которому будет происходить агрегация записей | - | +| Тип графика | Да | Тип визуализации графика | - | +| Название таблицы | Да | Название таблицы в базе данных, из которой будут браться записи для визуализации | - | +| Название поля | Да | Название поля, по которому будет происходить агрегация записей | - | | Фильтры | Нет | Поля, по которым будут фильтроваться полученные записи, и их значения | - | -| Тип агрегации | **Да** | Принцип, по которому будут группироваться полученные записи | - | +| Тип агрегации | Да | Принцип, по которому будут группироваться полученные записи | - | | Параметры агрегации | Нет | Выбор временного периода и шага группировки при агрегации записей по дате | - | При настройке виджета следует учитывать, что названия полей в базе данных могут отличаться от названий полей в спецификации объектов. Общий принцип таков: формат camelCase в спецификации объектов при сохранении структур в базу данных преобразуется в snake_case. Например: @@ -1258,8 +1258,8 @@ sum(ingress_nginx_detail_requests_total) В параметрах агрегации можно задать параметры: -- **Единица измерения шага** — например: секунды, минуты, часы, дни и т.д. -- **Количество единиц в одном шаге** — например: 5 минут, 2 часа, 1 день и т.п. +- «Единица измерения шага» — например: секунды, минуты, часы, дни и т. д. +- «Количество единиц в одном шаге» — например: 5 минут, 2 часа, 1 день и т. п. Это позволяет управлять детализацией отображения данных во времени и адаптировать график под нужный масштаб анализа. @@ -1269,22 +1269,22 @@ sum(ingress_nginx_detail_requests_total) Для каждого уникального значения в исходном наборе данных: - Выполняется подсчёт количества вхождений. -- На графике отображается пара: **значение - количество**. +- На графике отображается пара: значение — количество. Это позволяет быстро увидеть распределение и частоту повторения различных значений. ##### Разбивка по интервалам -Тип агрегации **«Разбивка по интервалам»** позволяет гибко настроить отображение данных на графике, разделяя значения по заданным числовым диапазонам (интервалам). Это удобно для построения гистограмм и анализа распределения данных. +Тип агрегации «Разбивка по интервалам» позволяет гибко настроить отображение данных на графике, разделяя значения по заданным числовым диапазонам (интервалам). Это удобно для построения гистограмм и анализа распределения данных. Доступны два режима настройки интервалов: -1. **Автоматическая разбивка по количеству интервалов**. +1. «Автоматическая разбивка по количеству интервалов». Указывается только количество интервалов, на которые нужно разделить доступные данные. Интервалы будут рассчитаны автоматически — равномерно от минимального до максимального значения. -1. **Ручное задание границ интервалов**. +1. «Ручное задание границ интервалов». Указывается массив числовых границ интервалов. Например: `0, 10, 20, 50` @@ -1297,17 +1297,17 @@ sum(ingress_nginx_detail_requests_total) В параметрах агрегации должно быть указано хотя бы одно из двух: -- `Количество` — количество интервалов, +- `Количество` — количество интервалов; - `Границы` — границы интервалов. Примеры: -- `Количество = 5` - построится 5 равных интервалов на основании данных. -- `Границы = 100, 0, 50` - после сортировки: `[0, 50, 100]`, график будет построен по интервалам `[0, 50)`, `[50, 100]`. +- `Количество = 5` — построится 5 равных интервалов на основании данных. +- `Границы = 100, 0, 50` — после сортировки: `[0, 50, 100]`, график будет построен по интервалам `[0, 50)`, `[50, 100]`. ### Квоты ресурсов Kubernetes -Виджет позволяет отображать данные о квотах ресурсов в платформе Kubernetes. +Виджет позволяет отображать данные о квотах ресурсов в кластере Kubernetes. Для каждой квоты происходит визуализация занятых ресурсов. @@ -1319,8 +1319,8 @@ sum(ingress_nginx_detail_requests_total) | Название | Обязательность | Описание | Значение по умолчанию | |----------------|-----------------|-----------------------------------------------------------------------------|-----------------------| -| URL | **Да** | URL API сервера Kubernetes. Используется для получения данных из Kubernetes | - | -| Namespace | **Да** | Неймспейс, из которого будут загружаться данные в виджет. Пример: `default` | - | +| URL | Да | URL API сервера Kubernetes. Используется для получения данных из Kubernetes | - | +| Namespace | Да | Неймспейс, из которого будут загружаться данные в виджет. Пример: `default` | - | ### Процентное значение @@ -1335,7 +1335,7 @@ sum(ingress_nginx_detail_requests_total) ### Таблицы сущностей -Виджет позволяет отображать сущности, созданные в платформе DDP, в виде таблицы. +Виджет позволяет отображать сущности, созданные в DDP, в виде таблицы. #### Конфигурация @@ -1350,17 +1350,17 @@ sum(ingress_nginx_detail_requests_total) #### Отображаемые данные -- **График временной шкалы** — горизонтальная диаграмма, где каждая сущность отображается в виде полосы, показывающей период времени (от даты начала до даты окончания). -- **Информация о сущностях** — при наведении на полосу отображается название сущности, дата начала и дата окончания периода. -- **Сортировка** — сущности отсортированы от самых старых (сверху) к самым новым (снизу). +- «График временной шкалы» — горизонтальная диаграмма, где каждая сущность отображается в виде полосы, показывающей период времени (от даты начала до даты окончания). +- «Информация о сущностях» — при наведении на полосу отображается название сущности, дата начала и дата окончания периода. +- «Сортировка» — сущности отсортированы от самых старых (сверху) к самым новым (снизу). #### Конфигурация | Название | Обязательность | Описание | Значение по умолчанию | |---------------------|----------------|-------------------------------------------------------------------------------------------------------------------------------------|-----------------------| -| Ресурс | **Да** | Ресурс, для которого отображается временная шкала | - | -| Поле даты начала | **Да** | Поле, из которого берется дата начала периода. Может быть системным полем (`createdAt`, `updatedAt`) или параметром типа `Date` | - | -| Поле даты окончания | **Да** | Поле, из которого берется дата окончания периода. Может быть системным полем (`createdAt`, `updatedAt`) или параметром типа `Date` | - | +| Ресурс | Да | Ресурс, для которого отображается временная шкала | - | +| Поле даты начала | Да | Поле, из которого берётся дата начала периода. Может быть системным полем (`createdAt`, `updatedAt`) или параметром типа `Date` | - | +| Поле даты окончания | Да | Поле, из которого берётся дата окончания периода. Может быть системным полем (`createdAt`, `updatedAt`) или параметром типа `Date` | - | #### Особенности @@ -1373,17 +1373,17 @@ sum(ingress_nginx_detail_requests_total) #### Отображаемые данные -- **Недельный календарь** — сетка из 7 дней текущей недели. -- **Сущности по датам** — для каждого дня отображаются все сущности, у которых дата в выбранном поле соответствует этому дню. -- **Информация о сущностях** — для каждой сущности отображаются название и описание (если указано). -- **Навигация по неделям** — кнопки для перехода к предыдущей и следующей неделе. +- «Недельный календарь» — сетка из 7 дней текущей недели. +- «Сущности по датам» — для каждого дня отображаются все сущности, у которых дата в выбранном поле соответствует этому дню. +- «Информация о сущностях» — для каждой сущности отображаются название и описание (если указано). +- «Навигация по неделям» — кнопки для перехода к предыдущей и следующей неделе. #### Конфигурация | Название | Обязательность | Описание | Значение по умолчанию | |-----------|-----------------|--------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------| -| Ресурс | **Да** | Ресурс, для которого отображается календарь | - | -| Поле даты | **Да** | Поле, из которого берется дата для отображения сущности в календаре. Может быть системным полем (`createdAt`, `updatedAt`) или параметром типа `Date` | - | +| Ресурс | Да | Ресурс, для которого отображается календарь | - | +| Поле даты | Да | Поле, из которого берётся дата для отображения сущности в календаре. Может быть системным полем (`createdAt`, `updatedAt`) или параметром типа `Date` | - | #### Особенности @@ -1403,39 +1403,39 @@ sum(ingress_nginx_detail_requests_total) ##### Общий статус -- **Прогресс-бар** — визуальное отображение общего статуса сущности с указанием процента успешно пройденных проверок; -- **Счетчик успешных проверок** — количество пройденных проверок из общего числа настроенных проверок статуса. +- «Прогресс-бар» — визуальное отображение общего статуса сущности с указанием процента успешно пройденных проверок. +- «Счётчик успешных проверок» — количество пройденных проверок из общего числа настроенных проверок статуса. ##### Список проверок Для каждой проверки статуса отображается: -- **Название проверки** — название правила проверки. -- **Статус** — результат выполнения проверки: - - **Пройдено** — проверка успешно пройдена. - - **Не пройдено** — проверка не пройдена (ошибок выполнения нет). - - **Ошибка** — при выполнении проверки произошла ошибка. -- **Время последней проверки** — дата и время последнего выполнения проверки. -- **Сообщение об ошибке** — текст ошибки (отображается, если проверка завершилась с ошибкой). +- «Название проверки» — название правила проверки. +- «Статус» — результат выполнения проверки: + - «Пройдено» — проверка успешно пройдена. + - «Не пройдено» — проверка не пройдена (ошибок выполнения нет). + - «Ошибка» — при выполнении проверки произошла ошибка. +- «Время последней проверки» — дата и время последнего выполнения проверки. +- «Сообщение об ошибке» — текст ошибки (отображается, если проверка завершилась с ошибкой). ##### Статистика В нижней части виджета отображается сводная статистика по проверкам: -- **Пройдено** — количество успешно пройденных проверок. -- **Не пройдено** — количество проверок, которые не были пройдены (без ошибок выполнения). -- **Ошибка** — количество проверок, завершившихся с ошибкой. +- «Пройдено» — количество успешно пройденных проверок. +- «Не пройдено» — количество проверок, которые не были пройдены (без ошибок выполнения). +- «Ошибка» — количество проверок, завершившихся с ошибкой. ##### Заблокированные действия Виджет автоматически определяет и отображает действия, которые недоступны при текущем статусе сущности. -- **Условия отображения:** +- Условия отображения: - действие должно быть доступно для ресурса, связанного с сущностью; - - у действия должны быть настроены разрешенные статусы; - - текущий статус сущности не входит в список разрешенных статусов для этого действия. + - у действия должны быть настроены разрешённые статусы; + - текущий статус сущности не входит в список разрешённых статусов для этого действия. -- **Отображаемая информация:** +- Отображаемая информация: - название действия; - описание действия (если указано). @@ -1453,22 +1453,22 @@ sum(ingress_nginx_detail_requests_total) ### Статистика событий -Виджет отображает статистику событий, происходящих с сущностями в платформе DDP. Виджет содержит три таба: +Виджет отображает статистику событий, происходящих с сущностями в DDP. Виджет содержит три таба: -1. **Статистика событий** - график, показывающий количество событий по типам за выбранный временной период с настраиваемой группировкой по времени. -1. **Топ сущностей** - таблица с сущностями, для которых было сгенерировано максимальное количество событий. -1. **События в Redis** - таблица со стримами событий из Redis, показывающая для каждого стрима: - - Название стрима (кликабельное для просмотра всех событий). - - Ресурс, к которому относится стрим. - - Количество событий в стриме. - - Информацию о последнем событии (сущность, ресурс, тип события, время). +1. «Статистика событий» — график, показывающий количество событий по типам за выбранный временной период с настраиваемой группировкой по времени. +1. «Топ сущностей» — таблица с сущностями, для которых было сгенерировано максимальное количество событий. +1. «События в Redis» — таблица со стримами событий из Redis, показывающая для каждого стрима: + - название стрима (кликабельное для просмотра всех событий); + - ресурс, к которому относится стрим; + - количество событий в стриме; + - информацию о последнем событии (сущность, ресурс, тип события, время). #### Параметры запроса | Название | Обязательность | Описание | Значение по умолчанию | |-----------------|-----------------|--------------------------------------------------------------------------------------------|-----------------------| -| Дата от | **Да** | Начальная дата для выборки событий | 3 дня назад | -| Дата до | **Да** | Конечная дата для выборки событий | текущая дата | +| Дата от | Да | Начальная дата для выборки событий | 3 дня назад | +| Дата до | Да | Конечная дата для выборки событий | Текущая дата | | Интервал | Нет | Интервал группировки событий на графике (секунды, минуты, часы, дни, недели, месяцы, годы) | час | | Шаг интервала | Нет | Количество единиц интервала для группировки | 1 | | Топ сущностей | Нет | Количество сущностей с максимальным количеством событий для отображения в таблице | 10 | @@ -1477,15 +1477,15 @@ sum(ingress_nginx_detail_requests_total) Виджет поддерживает следующие типы событий: -- **ENTITY_CREATED** - создание сущности. -- **ENTITY_UPDATED** - обновление сущности. -- **ENTITY_DELETED** - удаление сущности. +- `ENTITY_CREATED` — создание сущности. +- `ENTITY_UPDATED` — обновление сущности. +- `ENTITY_DELETED` — удаление сущности. ##### Особенности -- График показывает события за выбранный временной период с настраиваемой группировкой по времени (по умолчанию - по часам). +- График показывает события за выбранный временной период с настраиваемой группировкой по времени (по умолчанию — по часам). - Таблица отображает все события для каждой сущности (без фильтрации по дате). -- Для удаленных сущностей отображается их название, извлеченное из спецификации события. +- Для удалённых сущностей отображается их название, извлечённое из спецификации события. - Вкладка «События в Redis» позволяет отслеживать события, хранящиеся в Redis Streams: - Для каждого стрима отображается количество событий и информация о последнем событии. - При клике на название стрима открывается диалог со всеми событиями из этого стрима. @@ -1493,7 +1493,7 @@ sum(ingress_nginx_detail_requests_total) - При просмотре событий из стрима отображаются последние 1000 событий (новые первыми). Если в стриме больше 1000 событий, более старые события не отображаются. - Каждая строка в таблице содержит информацию о последнем событии для сущности. - Доступен просмотр детальной истории изменений для каждой сущности. -- События для удаленных ресурсов не отображаются (удаляются из БД при удалении ресурса). +- События для удалённых ресурсов не отображаются (удаляются из БД при удалении ресурса). ### Числовое значение @@ -1508,21 +1508,21 @@ sum(ingress_nginx_detail_requests_total) ### Kaiten. Карточки пространства -Виджет позволяет отображать структуру задач в пространстве Kaiten в виде многоуровневой таблицы **Доска → Карточки**, просматривать задачи на всех уровнях организации работы и получать информацию о критичных параметрах карточек (статус, срочность, блокировки, исполнители и др.). +Виджет позволяет отображать структуру задач в пространстве Kaiten в виде многоуровневой таблицы «Доска → Карточки», просматривать задачи на всех уровнях организации работы и получать информацию о критичных параметрах карточек (статус, срочность, блокировки, исполнители и др.). #### Конфигурация | Название | Обязательность | Описание | Значение по умолчанию | |-----------------|----------------|-------------------------------------|-----------------------| -| ID пространства | **Да** | Идентификатор пространства в Kaiten | - | +| ID пространства | Да | Идентификатор пространства в Kaiten | - | #### Параметры запроса | Название | Обязательность | Описание | Значение по умолчанию | |---------------|----------------|---------------------------------|-----------------------| | Мои задачи | Нет | Фильтр по текущему пользователю | false | -| Создано после | **Да** | Начальная дата для выборки | 1 месяц назад | -| Создано до | **Да** | Конечная дата для выборки | сейчас | +| Создано после | Да | Начальная дата для выборки | 1 месяц назад | +| Создано до | Да | Конечная дата для выборки | сейчас | #### Авторизация @@ -1548,14 +1548,14 @@ sum(ingress_nginx_detail_requests_total) | Название | Обязательность | Описание | Значение по умолчанию | |-----------------|----------------|------------------------------------ |-----------------------| -| ID пространства | **Да** | Идентификатор пространства в Kaiten | - | +| ID пространства | Да | Идентификатор пространства в Kaiten | - | #### Параметры запроса | Название | Обязательность | Описание | Значение по умолчанию | |---------------|-----------------|----------------------------|-----------------------| -| Создано после | **Да** | Начальная дата для анализа | 1 месяц назад | -| Создано до | **Да** | Конечная дата для анализа | сейчас | +| Создано после | Да | Начальная дата для анализа | 1 месяц назад | +| Создано до | Да | Конечная дата для анализа | сейчас | #### Авторизация @@ -1570,7 +1570,7 @@ sum(ingress_nginx_detail_requests_total) Основные метрики: - В очереди: задачи в очереди на выполнение. -- Выполнено: завершенные задачи. +- Выполнено: завершённые задачи. - В работе: активные задачи. Дополнительные метрики: @@ -1597,9 +1597,9 @@ sum(ingress_nginx_detail_requests_total) Карточки, которые не обновлялись с момента создания. -##### Последние обновленные +##### Последние обновлённые -Десять последних обновленных карточек. +Десять последних обновлённых карточек. ### Очередь задач @@ -1613,18 +1613,18 @@ sum(ingress_nginx_detail_requests_total) В верхней части виджета отображаются четыре ключевых показателя: -- **Размер очереди** — общее количество задач в очереди. -- **Ожидающие задачи** — количество задач, ожидающих обработки. -- **Активные воркеры** — количество активных воркеров (консьюмеров), обрабатывающих задачи. -- **Задачи в очереди** — общее количество задач, включая новые и обрабатываемые. +- «Размер очереди» — общее количество задач в очереди. +- «Ожидающие задачи» — количество задач, ожидающих обработки. +- «Активные воркеры» — количество активных воркеров (консьюмеров), обрабатывающих задачи. +- «Задачи в очереди» — общее количество задач, включая новые и обрабатываемые. ##### Таблица воркеров Таблица содержит информацию о каждом активном воркере: -- **Название консьюмера** — идентификатор воркера (консьюмера). -- **Ожидающие задачи** — количество задач, назначенных данному воркеру и ожидающих обработки. -- **Время простоя** — время с момента последней активности воркера. +- «Название консьюмера» — идентификатор воркера (консьюмера). +- «Ожидающие задачи» — количество задач, назначенных данному воркеру и ожидающих обработки. +- «Время простоя» — время с момента последней активности воркера. {{< alert level="info" >}} В таблице отображаются только активные воркеры. Воркеры, которые не обрабатывают задачи и неактивны более 5 минут, автоматически скрываются из списка. @@ -1634,15 +1634,15 @@ sum(ingress_nginx_detail_requests_total) Таблица содержит детальную информацию о всех задачах в очереди: -- **UUID задачи** — уникальный идентификатор задачи. -- **Тип** — тип задачи (например, `health_check`). -- **UUID ресурса** — идентификатор ресурса или сущности, к которой относится задача. -- **Консьюмер** — название консьюмера, обрабатывающего задачу. -- **Время простоя** — время с момента доставки задачи воркеру. -- **Время доставки** — время, когда задача была доставлена воркеру. -- **Статус** — текущий статус задачи: - - **Новая** — задача добавлена в очередь, но еще не назначена воркеру. - - **В обработке** — задача назначена воркеру и обрабатывается. +- «UUID задачи» — уникальный идентификатор задачи. +- «Тип» — тип задачи (например, `health_check`). +- «UUID ресурса» — идентификатор ресурса или сущности, к которой относится задача. +- «Консьюмер» — название консьюмера, обрабатывающего задачу. +- «Время простоя» — время с момента доставки задачи воркеру. +- «Время доставки» — время, когда задача была доставлена воркеру. +- «Статус» — текущий статус задачи: + - «Новая» — задача добавлена в очередь, но ещё не назначена воркеру. + - «В обработке» — задача назначена воркеру и обрабатывается. #### Конфигурация @@ -1658,15 +1658,15 @@ sum(ingress_nginx_detail_requests_total) | Название | Обязательность | Описание | |---------------------|----------------|--------------------------------------------------------------| -| Квадранты | **да** | Названия квадрантов. | -| Элементы | нет | Список элементов на радаре (не более 200) и их конфигурация. | +| Квадранты | Да | Названия квадрантов | +| Элементы | Нет | Список элементов на радаре (не более 200) и их конфигурация | ##### Конфигурация элемента | Название | Обязательность | Описание | |-----------|----------------|--------------------------------------------------------------------------| -| Название | **да** | Название элемента. | -| Номер | **да** | Целое число от 0 до 9999. | -| Описание | нет | Описание элемента, в диалоге просмотра отображается в формате Markdown. | -| Квадрант | **да** | Квадрант, к которому относится элемент. | -| Кольцо | **да** | Кольцо, к которому относится элемент: Adopt, Trial, Assess или Hold. | +| Название | Да | Название элемента | +| Номер | Да | Целое число от 0 до 9999 | +| Описание | Нет | Описание элемента, в диалоге просмотра отображается в формате Markdown | +| Квадрант | Да | Квадрант, к которому относится элемент | +| Кольцо | Да | Кольцо, к которому относится элемент: Adopt, Trial, Assess или Hold | diff --git a/content/documentation/admin/workflows.ru.md b/content/documentation/admin/workflows.ru.md index 2b23b596..6c262d39 100644 --- a/content/documentation/admin/workflows.ru.md +++ b/content/documentation/admin/workflows.ru.md @@ -1,26 +1,26 @@ --- title: Сценарии menuTitle: Сценарии -d8Edition: ee -moduleStatus: experimental --- -Сценарии - механизм, позволяющий объединять действия в цепочку, управляя ходом выполнения. +Сценарии — механизм, позволяющий объединять действия в цепочку, управляя ходом выполнения. -Сценарии, как и действия привязываются к конкретным ресурсам и могут быть запущены только для сущностей того ресурса, к которому они привязаны. +Сценарии, как и действия, привязываются к конкретным ресурсам и могут быть запущены только для сущностей того ресурса, к которому они привязаны. ### Тип запуска действий -Действия в одном сценарии могут запускаться параллельно, либо последовательно. +Действия в одном сценарии могут запускаться параллельно либо последовательно. -При выборе параллельного запуска все действия запустятся одновременно. При выборе последовательного запуска, действия будут запускаться в порядке их расположения в списке действий сценария. При этом, если одно из действий выполнилось неуспешно, все последующие будут созданы, но не будут запущены. +При выборе параллельного запуска все действия запустятся одновременно. При выборе последовательного запуска действия будут запускаться в порядке их расположения в списке действий сценария. При этом, если одно из действий выполнилось неуспешно, все последующие будут созданы, но не будут запущены. -> При выборе последовательного запуска и в случае, если какое-либо из вышестоящих действий требует подтверждения, следующие за ним запустятся сразу после того, как данное действие перейдет в статус «Unapproved». +{% alert level="info" %} +При выборе последовательного запуска и в случае, если какое-либо из вышестоящих действий требует подтверждения, следующие за ним запустятся сразу после того, как данное действие перейдёт в статус «Unapproved». +{% endalert %} -Каждое действие сценария может быть обязательным, либо опциональным: +Каждое действие сценария может быть обязательным либо опциональным: -* Если действие является обязательным для сценария, то пользователь, запускающий сценарий, не может выключить выполнение данного действия. -* Если действие является опциональным, то при запуске сценария пользователь может отключить его и действие не запустится. +* если действие является обязательным для сценария, то пользователь, запускающий сценарий, не может выключить выполнение данного действия; +* если действие является опциональным, то при запуске сценария пользователь может отключить его, и действие не запустится. ### Запуск сценария diff --git a/content/documentation/product-info/functional.ru.md b/content/documentation/product-info/functional.ru.md index dbff7659..9872d788 100644 --- a/content/documentation/product-info/functional.ru.md +++ b/content/documentation/product-info/functional.ru.md @@ -5,21 +5,22 @@ weight: 10 ## Общая информация -Программное обеспечение «Express 42 Platform. Платформа для реализации DevOps-практик (Инфраструктурный оркестратор на основе Kubernetes, внутренняя CI/CD-платформа для команд разработки, SDLC & TM-мониторинг) (альтернативное наименование - Deckhouse Development Platform)» обеспечивает выполнение следующих функций: -- Ведение сервисного каталога, включающего информационные системы, микросервисы, репозитории кода, окружения, инфраструктурные ресурсы, команды, ответственных лиц и другие связанные сущности. -- Настройка иерархической модели данных, атрибутов сущностей и ролей владения. -- Агрегация данных и автоматическая синхронизация сервисного каталога с внешними источниками и инфраструктурными и корпоративными системами организации. -- Построение и отображение связей между информационными системами, инфраструктурными ресурсами, владельцами и связанными сущностями. -- Формирование дашбордов, отчетов, графиков, списков и аналитических представлений. -- Настройка пользовательского интерфейса, страниц, виджетов и отображаемых данных. -- Предоставление пользователям (разработчики и команды эксплуатации) функций самообслуживания через веб-интерфейс. -- Создание новых микросервисов на основе шаблонов репозиториев и стандартных конфигураций. -- Автоматизация заказа инфраструктурных ресурсов организации такие как: базы данных, файловые хранилища, виртуальные машины и т.п.. -- Развертывание информационных систем и композиций микросервисов в целевых окружениях. -- Создание, обновление и автоматическое удаление временных тестовых окружений. -- Запуск задач по анализу и поиску уязвимостей в исходном коде и артефактах сборки. -- Настройка и выполнение комплексных процессов автоматизации с условиями, таймерами, параллельными шагами, триггерами событий и маршрутизацией согласований и подтверждений действий уполномоченными пользователями. -- Разграничение прав доступа пользователей и аудит операций. +Программное обеспечение «Express 42 Platform. Платформа для реализации DevOps-практик (Инфраструктурный оркестратор на основе Kubernetes, внутренняя CI/CD-платформа для команд разработки, SDLC & TM-мониторинг) (альтернативное наименование — Deckhouse Development Platform)» обеспечивает выполнение следующих функций: + +- ведение сервисного каталога, включающего информационные системы, микросервисы, репозитории кода, окружения, инфраструктурные ресурсы, команды, ответственных лиц и другие связанные сущности; +- настройка иерархической модели данных, атрибутов сущностей и ролей владения; +- агрегация данных и автоматическая синхронизация сервисного каталога с внешними источниками и инфраструктурными и корпоративными системами организации; +- построение и отображение связей между информационными системами, инфраструктурными ресурсами, владельцами и связанными сущностями; +- формирование дашбордов, отчетов, графиков, списков и аналитических представлений; +- настройка пользовательского интерфейса, страниц, виджетов и отображаемых данных; +- предоставление пользователям (разработчикам и командам эксплуатации) функций самообслуживания через веб-интерфейс; +- создание новых микросервисов на основе шаблонов репозиториев и стандартных конфигураций; +- автоматизация заказа инфраструктурных ресурсов организации, таких как базы данных, файловые хранилища, виртуальные машины и т.п.; +- развёртывание информационных систем и композиций микросервисов в целевых окружениях; +- создание, обновление и автоматическое удаление временных тестовых окружений; +- запуск задач по анализу и поиску уязвимостей в исходном коде и артефактах сборки; +- настройка и выполнение комплексных процессов автоматизации с условиями, таймерами, параллельными шагами, триггерами событий и маршрутизацией согласований и подтверждений действий уполномоченными пользователями; +- разграничение прав доступа пользователей и аудит операций. ## Архитектура diff --git a/content/documentation/product-info/licensing.ru.md b/content/documentation/product-info/licensing.ru.md index 29998df6..5d64c0b5 100644 --- a/content/documentation/product-info/licensing.ru.md +++ b/content/documentation/product-info/licensing.ru.md @@ -5,7 +5,7 @@ weight: 40 ## Общая информация -Программное обеспечение «Express 42 Platform. Платформа для реализации DevOps-практик (Инфраструктурный оркестратор на основе Kubernetes, внутренняя CI/CD-платформа для команд разработки, SDLC & TM-мониторинг) (альтернативное наименование - Deckhouse Development Platform)» лицензируется на ограниченный срок или бессрочно. Разные типы лицензий предоставляют разные уровни доступа к поддержке и обновлениям. +Программное обеспечение «Express 42 Platform. Платформа для реализации DevOps-практик (Инфраструктурный оркестратор на основе Kubernetes, внутренняя CI/CD-платформа для команд разработки, SDLC & TM-мониторинг) (альтернативное наименование — Deckhouse Development Platform)» лицензируется на ограниченный срок или бессрочно. Разные типы лицензий предоставляют разные уровни доступа к поддержке и обновлениям. Стоимость и условия покупки лицензии рассчитываются индивидуально. Свяжитесь с нами для проведения демонстрации и приобретения. @@ -17,21 +17,25 @@ weight: 40 #### Срок использования -1, 2 или 3 года. +Лицензия предоставляется на 1, 2 или 3 года. #### Срок предоставления обновлений -1, 2 или 3 года. +Обновления предоставляются в течение 1, 2 или 3 лет. -#### Подходит для +#### Сценарии использования -- Сред разработки, тестирования и проектов с жизненным циклом менее 3 лет. -- Сценариев с бюджетированием по модели ОPEX. +Срочная лицензия подходит для следующих сценариев: -#### Что входит +- среды разработки и тестирования, а также проекты с жизненным циклом менее 3 лет; +- сценарии с бюджетированием по модели ОPEX. -- Гарантийная техническая поддержка (доступ к обновлениям, исправления уязвимостей и ошибок) в течение срока действия лицензии. -- Возможность продления лицензии после окончания срока действия. +#### Состав лицензии + +В рамках срочной лицензии предоставляются: + +- гарантийная техническая поддержка (доступ к обновлениям, исправления уязвимостей и ошибок) в течение срока действия лицензии; +- возможность продления лицензии после окончания срока действия. ### Бессрочная лицензия @@ -39,23 +43,27 @@ weight: 40 #### Срок использования -Бессрочно. +Лицензия предоставляется бессрочно. #### Срок предоставления обновлений -1, 2, 3 или 5 лет. +Обновления предоставляются в течение 1, 2, 3 или 5 лет. + +#### Сценарии использования + +Бессрочная лицензия подходит для следующих сценариев: -#### Подходит для +- длительное использование; +- сценарии с бюджетированием по модели CAPEX; +- среды, где размер инсталляций не будет уменьшаться. -- Длительного использования решения. -- Сценариев с бюджетированием по модели CAPEX. -- Сред, где размер инсталляций не будет уменьшаться. +#### Состав лицензии -#### Что входит +В рамках бессрочной лицензии предоставляются: -- Гарантийная техническая поддержка (доступ к обновлениям, исправления уязвимостей и ошибок) в течение выбранного срока действия (1, 2, 3 или 5 лет). -- Для продления доступа к обновлениям приобретаются дополнительные лицензии на обновления. +- гарантийная техническая поддержка (доступ к обновлениям, исправления уязвимостей и ошибок) в течение выбранного срока действия (1, 2, 3 или 5 лет); +- возможность продления доступа к обновлениям путём приобретения дополнительных лицензий на обновления. ## Метрики лицензирования -Программное обеспечение «Express 42 Platform. Платформа для реализации DevOps-практик (Инфраструктурный оркестратор на основе Kubernetes, внутренняя CI/CD-платформа для команд разработки, SDLC & TM-мониторинг) (альтернативное наименование - Deckhouse Development Platform)» лицензируется по количеству активных учетных записей, заведенных в продукте. +Программное обеспечение «Express 42 Platform. Платформа для реализации DevOps-практик (Инфраструктурный оркестратор на основе Kubernetes, внутренняя CI/CD-платформа для команд разработки, SDLC & TM-мониторинг) (альтернативное наименование — Deckhouse Development Platform)» лицензируется по количеству активных учетных записей, заведённых в продукте. diff --git a/content/documentation/product-info/lifecycle.ru.md b/content/documentation/product-info/lifecycle.ru.md index 35ae7b7c..601db7a9 100644 --- a/content/documentation/product-info/lifecycle.ru.md +++ b/content/documentation/product-info/lifecycle.ru.md @@ -5,97 +5,103 @@ weight: 20 ## Общая информация -Поддержание жизненного цикла программного обеспечения «Express 42 Platform. Платформа для реализации DevOps-практик (Инфраструктурный оркестратор на основе Kubernetes, внутренняя CI/CD-платформа для команд разработки, SDLC & TM-мониторинг) (альтернативное наименование - Deckhouse Development Platform)» осуществляется за счет: -- Выпуска обновлений ПО, включающих в себя обновление функционала и обновление пользовательского интерфейса. -- Устранения обнаруженных уязвимостей. -- Сопровождения и устранения неисправностей, выявленных при эксплуатации. +Поддержание жизненного цикла программного обеспечения «Express 42 Platform. Платформа для реализации DevOps-практик (Инфраструктурный оркестратор на основе Kubernetes, внутренняя CI/CD-платформа для команд разработки, SDLC & TM-мониторинг) (альтернативное наименование — Deckhouse Development Platform)» включает: + +- выпуск обновлений ПО, включающих в себя обновление функционала и пользовательского интерфейса; +- устранение обнаруженных уязвимостей; +- сопровождение и устранение неисправностей, выявленных при эксплуатации. ## Устранение неисправностей, выявленных в ходе эксплуатации При возникновении неисправностей, выявленных в ходе эксплуатации, предусматривается следующая последовательность действий: -- Диагностика неисправности. -- При невозможности самостоятельной диагностики и устранения неисправности обращение в службу технической поддержки для диагностики неисправности. + +- диагностика неисправности; +- при невозможности самостоятельной диагностики и устранения неисправности обращение в службу технической поддержки для диагностики неисправности. Устранение неисправностей, выявленных в ходе эксплуатации, выполняется путем: -- Модификации конфигурации текущей версии ПО. -- Модификации конфигурации окружения, используемого для установки ПО, например, добавление аппаратных ресурсов для обеспечения корректности работы ПО. -- Установки обновленной версии ПО, содержащей программный код для устранения неисправности. + +- изменения конфигурации текущей версии ПО; +- изменения конфигурации окружения, используемого для установки ПО. Например, добавление аппаратных ресурсов для обеспечения корректности работы ПО; +- установки обновлённой версии ПО, содержащей программный код для устранения неисправности. ## Совершенствование ПО -Процесс совершенствования ПО «Express 42 Platform. Платформа для реализации DevOps-практик (Инфраструктурный оркестратор на основе Kubernetes, внутренняя CI/CD-платформа для команд разработки, SDLC & TM-мониторинг) (альтернативное наименование - Deckhouse Development Platform)» включает в себя следующие этапы: -- Определение функционала, добавляемого в ПО. -- Выявление неисправностей в текущей версии дистрибутива ПО. -- Проектирование технического решения, формирование технического -задания на разработку. -- Реализация функционала, описанного в техническом задании. -– Тестирование функционала, добавленного в ПО. -- Подготовка документации по обновленной версии дистрибутива ПО. -- Подготовка обновленной версии дистрибутива ПО. +Процесс совершенствования ПО «Express 42 Platform. Платформа для реализации DevOps-практик (Инфраструктурный оркестратор на основе Kubernetes, внутренняя CI/CD-платформа для команд разработки, SDLC & TM-мониторинг) (альтернативное наименование — Deckhouse Development Platform)» включает в себя следующие этапы: + +- определение функционала, добавляемого в ПО; +- выявление неисправностей в текущей версии дистрибутива ПО; +- проектирование технического решения, формирование технического задания на разработку; +- реализация функционала, описанного в техническом задании; +- тестирование функционала, добавленного в ПО; +- подготовка документации по обновленной версии дистрибутива ПО; +- подготовка обновлённой версии дистрибутива ПО. ### Определение функционала, добавляемого в ПО -Определение функционала, добавляемого в ПО «Express 42 Platform. Платформа для реализации DevOps-практик (Инфраструктурный оркестратор на основе Kubernetes, внутренняя CI/CD-платформа для команд разработки, SDLC & TM-мониторинг) (альтернативное наименование - Deckhouse Development Platform)» при обновлении, происходит с использованием продуктового подхода. В качестве используемых методов применяются: -- Проведение опросов пользователей ПО с целью выявления уровня удовлетворенности. -- Проведение опросов пользователей ПО с целью выявления потребностей, возникающих при разработке программных продуктов. -- Анализ процессов разработки программных продуктов, реализуемых пользователями ПО, их визуализация и определение мест, подлежащих оптимизации. -- Анализ обращений пользователей в службу технической поддержки. +Определение функционала, добавляемого в ПО «Express 42 Platform. Платформа для реализации DevOps-практик (Инфраструктурный оркестратор на основе Kubernetes, внутренняя CI/CD-платформа для команд разработки, SDLC & TM-мониторинг) (альтернативное наименование — Deckhouse Development Platform)» при обновлении, происходит с использованием продуктового подхода. В качестве используемых методов применяются: + +- проведение опросов пользователей ПО с целью выявления уровня удовлетворённости; +- проведение опросов пользователей ПО с целью выявления потребностей, возникающих при разработке программных продуктов; +- анализ процессов разработки программных продуктов, реализуемых пользователями ПО, их визуализация и определение мест, подлежащих оптимизации; +- анализ обращений пользователей в службу технической поддержки. ### Выявление неисправностей в текущей версии дистрибутива ПО -Выявление неисправностей в текущей версии дистрибутива ПО «Express 42 Platform. Платформа для реализации DevOps-практик (Инфраструктурный оркестратор на основе Kubernetes, внутренняя CI/CD-платформа для команд разработки, SDLC & TM-мониторинг) (альтернативное наименование - Deckhouse Development Platform)» производится на основе: -- Анализа метрик систем мониторинга. -- Анализа инцидентов, возникающих при эксплуатации ПО. -- Анализа обращений пользователей в службу технической поддержки. +Выявление неисправностей в текущей версии дистрибутива ПО «Express 42 Platform. Платформа для реализации DevOps-практик (Инфраструктурный оркестратор на основе Kubernetes, внутренняя CI/CD-платформа для команд разработки, SDLC & TM-мониторинг) (альтернативное наименование — Deckhouse Development Platform)» производится на основе анализа: + +- метрик систем мониторинга; +- инцидентов, возникающих при эксплуатации ПО; +- обращений пользователей в службу технической поддержки. ### Проектирование технического решения, формирование технического задания на разработку -Проектирование технического решения осуществляется на основе информации о неисправностях, выявленных в текущей версии ПО «Express 42 Platform. Платформа для реализации DevOps-практик (Инфраструктурный оркестратор на основе Kubernetes, внутренняя CI/CD-платформа для команд разработки, SDLC & TM-мониторинг) (альтернативное наименование - Deckhouse Development Platform)» и функционала, определенного как необходимого в следующей версии. +Проектирование технического решения осуществляется на основе информации о неисправностях, выявленных в текущей версии ПО «Express 42 Platform. Платформа для реализации DevOps-практик (Инфраструктурный оркестратор на основе Kubernetes, внутренняя CI/CD-платформа для команд разработки, SDLC & TM-мониторинг) (альтернативное наименование — Deckhouse Development Platform)» и функционала, определённого как необходимого в следующей версии. При проектировании технического решения и формировании технического задания учитываются: -- Квалификация и количество сотрудников, участвующих в разработке ПО. -- Целевые сроки реализации выпуска обновленной версии дистрибутива ПО. -- Критичность обнаруженных в ходе эксплуатации неисправностей и -уязвимостей безопасности. -- Практики и подходы к решению задач по разработке программного -обеспечения. - -На этапе формирования технического задания определяются: -- Детальные требования к функционалу обновления ПО. -- Детальные требования к пользовательскому интерфейсу ПО. -- Детальные требования к сценариям тестирования ПО. + +- квалификация и количество сотрудников, участвующих в разработке ПО; +- целевые сроки реализации выпуска обновлённой версии дистрибутива ПО; +- критичность обнаруженных в ходе эксплуатации неисправностей и уязвимостей безопасности; +- практики и подходы к решению задач по разработке ПО. + +На этапе формирования технического задания определяются следующие детальные требования: + +- к функционалу обновления ПО; +- к пользовательскому интерфейсу ПО; +- к сценариям тестирования ПО. ### Реализация функционала, описанного в техническом задании Реализация функционала, описанного в техническом задании, осуществляется сотрудниками, обладающими квалификацией, указанной в разделе [«Сведения о персонале»](../staff/). -При разработке ПО «Express 42 Platform. Платформа для реализации DevOps-практик (Инфраструктурный оркестратор на основе Kubernetes, внутренняя CI/CD-платформа для команд разработки, SDLC & TM-мониторинг) (альтернативное наименование - Deckhouse Development Platform)» применяется система -контроля версий, а также прочие современные практики разработки программных -продуктов. +При разработке ПО «Express 42 Platform. Платформа для реализации DevOps-практик (Инфраструктурный оркестратор на основе Kubernetes, внутренняя CI/CD-платформа для команд разработки, SDLC & TM-мониторинг) (альтернативное наименование — Deckhouse Development Platform)» применяется система контроля версий, а также прочие современные практики разработки программных продуктов. ### Тестирование функционала, добавленного в ПО -Тестирование функционала, добавленного в ПО «Express 42 Platform. Платформа для реализации DevOps-практик (Инфраструктурный оркестратор на основе Kubernetes, внутренняя CI/CD-платформа для команд разработки, SDLC & TM-мониторинг) (альтернативное наименование - Deckhouse Development Platform)» производится с целью: -- Поиска неисправностей в добавляемом функционале. -- Недопущения некорректного поведения ПО при при эксплуатации. +Тестирование функционала, добавленного в ПО «Express 42 Platform. Платформа для реализации DevOps-практик (Инфраструктурный оркестратор на основе Kubernetes, внутренняя CI/CD-платформа для команд разработки, SDLC & TM-мониторинг) (альтернативное наименование — Deckhouse Development Platform)», производится с целью: + +- поиска неисправностей в добавляемом функционале; +- недопущения некорректного поведения ПО при при эксплуатации. При тестировании ПО применяются следующие виды тестов: -- Сканирование программного кода и собираемого дистрибутива на отсутствие известных уязвимостей. -- Модульные тесты, запускаемые автоматически при появлении нового программного кода ПО в системе контроля версий, и проверяющие корректность работы отдельных модулей программного обеспечения. -- Интеграционные тесты, запускаемые автоматически при появлении нового программного кода ПО в системе контроля версий, и проверяющие корректность интеграции отдельных модулей программного обеспечения. -- Сквозные тесты, запускаемые автоматически при появлении нового программного кода ПО в системе контроля версий, и проверяющие корректность работы сценариев, реализуемых пользователями программного обеспечения. -### Подготовка документации по обновленной версии дистрибутива ПО +- сканирование программного кода и собираемого дистрибутива на отсутствие известных уязвимостей; +- модульные тесты, запускаемые автоматически при появлении нового программного кода ПО в системе контроля версий и проверяющие корректность работы отдельных модулей ПО; +- интеграционные тесты, запускаемые автоматически при появлении нового программного кода ПО в системе контроля версий и проверяющие корректность интеграции отдельных модулей программного обеспечения; +- сквозные тесты, запускаемые автоматически при появлении нового программного кода ПО в системе контроля версий и проверяющие корректность работы сценариев, реализуемых пользователями программного обеспечения. + +### Подготовка документации по обновлённой версии дистрибутива ПО + +Документация по обновлённой версии дистрибутива ПО «Express 42 Platform. Платформа для реализации DevOps-практик (Инфраструктурный оркестратор на основе Kubernetes, внутренняя CI/CD-платформа для команд разработки, SDLC & TM-мониторинг) (альтернативное наименование — Deckhouse Development Platform)» описывает: -Документация по обновленной версии дистрибутива ПО «Express 42 Platform. Платформа для реализации DevOps-практик (Инфраструктурный оркестратор на основе Kubernetes, внутренняя CI/CD-платформа для команд разработки, SDLC & TM-мониторинг) (альтернативное наименование - Deckhouse Development Platform)» содержит: -- Описание функционала, добавленного в ПО. -- Описание неисправностей, исправленных в обновлении дистрибутива ПО. -- Описание инструкций по обновлению ПО при необходимости. +- функционал, добавленного в ПО; +- неисправности, исправленные в обновлении дистрибутива ПО; +- инструкции по обновлению ПО при необходимости. -### Подготовка обновленной версии дистрибутива ПО +### Подготовка обновлённой версии дистрибутива ПО -Подготовка обновленной версии дистрибутива ПО «Express 42 Platform. Платформа для реализации DevOps-практик (Инфраструктурный оркестратор на основе Kubernetes, внутренняя CI/CD-платформа для команд разработки, SDLC & TM-мониторинг) (альтернативное наименование - Deckhouse Development Platform)» происходит путем автоматизированной сборки дистрибутива при условии положительного результата, полученного на этапе тестирования функционала. +Подготовка обновлённой версии дистрибутива ПО «Express 42 Platform. Платформа для реализации DevOps-практик (Инфраструктурный оркестратор на основе Kubernetes, внутренняя CI/CD-платформа для команд разработки, SDLC & TM-мониторинг) (альтернативное наименование — Deckhouse Development Platform)» происходит путем автоматизированной сборки дистрибутива при условии положительного результата, полученного на этапе тестирования функционала. -Обновленная версия дистрибутива публикуется в хранилище артефактов, доступном пользователям ПО. +Обновлённая версия дистрибутива публикуется в хранилище артефактов, доступном пользователям ПО. -Информация об обновлении версии ПО доводится до пользователей путем публикации сообщения об обновлении на официальном сайте ПО в разделе [«История изменений»](../../release-notes/). +Информация об обновлении версии ПО доводится до пользователей путём публикации сообщения об обновлении на официальном сайте ПО в разделе [«История изменений»](../../release-notes/). diff --git a/content/documentation/product-info/staff.ru.md b/content/documentation/product-info/staff.ru.md index 64b64758..b86a6627 100644 --- a/content/documentation/product-info/staff.ru.md +++ b/content/documentation/product-info/staff.ru.md @@ -5,17 +5,15 @@ weight: 30 ## Требования к персоналу, задействованному в процессе разработки ПО -Персонал, задействованный в процессе разработке ПО «Express 42 Platform. Платформа для реализации DevOps-практик (Инфраструктурный оркестратор на основе Kubernetes, внутренняя CI/CD-платформа для команд разработки, SDLC & TM-мониторинг) (альтернативное наименование - Deckhouse Development Platform)», обладает следующей квалификацией: -- Навыки работы с ПО, применяемым для контейнерной оркестрации. -- Навыки разработки на языках программирования Go, TypeScript. -- Понимание практик «Инфраструктура как код», «Непрерывная интеграция», -«Непрерывное развертывание». -- Навыки работы с системами мониторинга и логирования. -- Навыки работы с системами хранения секретов и системами хранения -артефактов. -- Навыки работы с инструментами, используемыми для развертывания -программных продуктов. -- Навыки работы с инструментами для описания инфраструктуры в виде кода. +Персонал, задействованный в процессе разработки ПО «Express 42 Platform. Платформа для реализации DevOps-практик (Инфраструктурный оркестратор на основе Kubernetes, внутренняя CI/CD-платформа для команд разработки, SDLC & TM-мониторинг) (альтернативное наименование — Deckhouse Development Platform)», обладает следующими компетенциями: + +- навыки работы с ПО, применяемым для контейнерной оркестрации; +- навыки разработки на языках программирования Go и TypeScript; +- понимание практик «Инфраструктура как код», «Непрерывная интеграция» и «Непрерывное развёртывание»; +- навыки работы с системами мониторинга и логирования; +- навыки работы с системами хранения секретов и артефактов; +- навыки работы с инструментами, используемыми для развёртывания программных продуктов; +- навыки работы с инструментами для описания инфраструктуры в виде кода. ## Сведения о персонале, задействованном в процессе разработки ПО @@ -28,12 +26,13 @@ weight: 30 ## Требования к персоналу, задействованному в процессе сопровождения ПО -Персонал, задействованный в процессе сопровождения ПО «Express 42 Platform. Платформа для реализации DevOps-практик (Инфраструктурный оркестратор на основе Kubernetes, внутренняя CI/CD-платформа для команд разработки, SDLC & TM-мониторинг) (альтернативное наименование - Deckhouse Development Platform)», обладает следующей квалификацией: -- Навыки эксплуатации ПО, применяемого для контейнерной оркестрации. -- Навыки эксплуатации операционных систем семейства Unix. -- Навыки управления учетными записями пользователей. -- Навыки эксплуатации систем мониторинга и логирования. -- Навыки диагностики и выявления неисправностей ПО. +Персонал, задействованный в процессе сопровождения ПО «Express 42 Platform. Платформа для реализации DevOps-практик (Инфраструктурный оркестратор на основе Kubernetes, внутренняя CI/CD-платформа для команд разработки, SDLC & TM-мониторинг) (альтернативное наименование — Deckhouse Development Platform)», обладает следующими навыками: + +- эксплуатация ПО, применяемого для контейнерной оркестрации; +- эксплуатация операционных систем семейства Unix; +- управление учётными записями пользователей; +- эксплуатация систем мониторинга и логирования; +- диагностика и выявление неисправностей ПО. ## Сведения о персонале, задействованном в процессе сопровождения ПО @@ -50,8 +49,8 @@ weight: 30 ## Фактический адрес размещения разработчиков -Разработка осуществляется дистанционно штатными специалистами компании АО «Флант» вне места нахождения юридического лица, его филиала, представительства, вне стационарного рабочего места, территории или объекта, находящихся под контролем работодателя (дистанционная работа, ст. 312.1 ТК РФ). +Разработка осуществляется дистанционно штатными специалистами АО «Флант» вне места нахождения юридического лица, его филиала, представительства, вне стационарного рабочего места, территории или объекта, находящихся под контролем работодателя (дистанционная работа, ст. 312.1 ТК РФ). ## Фактический адрес размещения службы поддержки -Поддержка осуществляется дистанционно штатными специалистами компании АО «Флант» вне места нахождения юридического лица, его филиала, представительства, вне стационарного рабочего места, территории или объекта, находящихся под контролем работодателя (дистанционная работа, ст. 312.1 ТК РФ). +Поддержка осуществляется дистанционно штатными специалистами АО «Флант» вне места нахождения юридического лица, его филиала, представительства, вне стационарного рабочего места, территории или объекта, находящихся под контролем работодателя (дистанционная работа, ст. 312.1 ТК РФ). diff --git a/content/documentation/product-info/tech-support.ru.md b/content/documentation/product-info/tech-support.ru.md index 1267099b..6a219d11 100644 --- a/content/documentation/product-info/tech-support.ru.md +++ b/content/documentation/product-info/tech-support.ru.md @@ -7,7 +7,7 @@ weight: 50 ### Гарантийная техническая поддержка -Доступ к обновлениям решения в рамках установленного в ней срока поддержки с новой функциональностью, исправлениями ошибок и решениями инцидентов безопасности. +Доступ к обновлениям решения в рамках установленного срока поддержки с новой функциональностью, исправлениями ошибок и решениями инцидентов безопасности. Входит в основную лицензию и не требует дополнительной оплаты. diff --git a/content/documentation/release-notes/v1.0.0.ru.md b/content/documentation/release-notes/v1.0.0.ru.md index 4387cd50..b9182a50 100644 --- a/content/documentation/release-notes/v1.0.0.ru.md +++ b/content/documentation/release-notes/v1.0.0.ru.md @@ -14,14 +14,14 @@ description: Заметки о выпуске v1.0.0 — виджеты, ист #### Kaiten виджеты -Добавлены два виджета для интеграции с платформой управления проектами Kaiten ([подробнее](../../admin/widgets/types/#kaiten-карточки-пространства)). +Добавлены два виджета для интеграции с [платформой управления проектами Kaiten](../../admin/widgets/types/#kaiten-карточки-пространства). -- **Kaiten. Карточки пространства** — просмотр задач в пространстве: +- «Kaiten. Карточки пространства» — просмотр задач в пространстве: - Многоуровневое отображение структуры «Доска → Карточки». - Фильтрация по текущему пользователю и диапазону дат создания. - Отображение статусов, владельцев, участников, сроков и блокировок. -- **Kaiten. Статистика пространства** — аналитика и метрики по задачам: +- «Kaiten. Статистика пространства» — аналитика и метрики по задачам: - Общие показатели (в очереди, в работе, выполнено). - Статистика по пользователям и чеклистам. - Долго не обновлявшиеся и последние обновленные карточки. @@ -29,14 +29,14 @@ description: Заметки о выпуске v1.0.0 — виджеты, ист #### Kafka виджеты -Расширены возможности работы с Kafka ([подробнее](../../admin/widgets/types/#kafka-acls)). +Расширены возможности работы с [Kafka ACL](../../admin/widgets/types/#kafka-acls). -- **Действия для виджета Kafka Topics**: +- Действия для виджета Kafka Topics: - Создание и удаление топиков. - Отправка сообщений в топик. - Очистка топиков от сообщений. -- **Виджет Kafka ACLs** — управление доступом в Kafka кластере: +- «Виджет Kafka ACLs» — управление доступом в Kafka кластере: - Просмотр списка правил доступа (ACL). - Фильтрация по типам ресурсов, шаблонам, операциям и разрешениям. - Создание и удаление правил доступа. @@ -45,25 +45,25 @@ description: Заметки о выпуске v1.0.0 — виджеты, ист Добавлены новые возможности для работы с GitLab. -- **Редактор пайплайна** — редактирование `.gitlab-ci.yml` ([подробнее](../../admin/widgets/types/#gitlab-редактор-пайплайна)): +- [«GitLab. Редактор пайплайна»](../../admin/widgets/types/#gitlab-редактор-пайплайна) — редактирование `.gitlab-ci.yml`: - Редактирование конфигурации пайплайнов. - Просмотр различий между версиями. - Создание Merge Requests с изменениями. -- **Статистика пайплайнов** — аналитика по пайплайнам ([подробнее](../../admin/widgets/types/#gitlab-статистика-пайплайнов)): +- [«GitLab. Статистика пайплайнов»](../../admin/widgets/types/#gitlab-статистика-пайплайнов) — аналитика по пайплайнам: - Общие метрики (количество, процент успеха/неудач, средняя длительность). - Распределение по статусам и источникам. - Статистика по участникам и веткам. -Расширены функции виджета **Запросы слияния** ([подробнее](../../admin/widgets/types/#gitlab-запросы-слияния)): -- **Действия виджета** — добавлена возможность выполнения действий с Merge Requests (MR): +Расширены функции виджета [«GitLab. Запросы слияния»](../../admin/widgets/types/#gitlab-запросы-слияния): +- «Действия виджета» — добавлена возможность выполнения действий с Merge Requests (MR): - Слияние и закрытие MR. - Изменение статуса черновика. - Просмотр изменений в дифф-редакторе. #### S3 bucket виджет -Добавлен виджет для работы с S3-совместимыми хранилищами ([подробнее](../../admin/widgets/types/#s3-bucket)): +Добавлен [виджет для работы с S3-совместимыми хранилищами](../../admin/widgets/types/#s3-bucket): - Просмотр содержимого бакета. - Поиск объектов по префиксу. - Загрузка файлов из бакета. @@ -72,7 +72,7 @@ description: Заметки о выпуске v1.0.0 — виджеты, ист #### Виджет статистики событий -Виджет для анализа событий сущностей в системе ([подробнее](../../admin/widgets/types/#статистика-событий)): +[Виджет для анализа событий сущностей в системе](../../admin/widgets/types/#статистика-событий): - График событий по типам за выбранный период. - Топ сущностей по количеству событий. - Настраиваемая группировка по времени. @@ -82,7 +82,7 @@ description: Заметки о выпуске v1.0.0 — виджеты, ист #### GenericAPI -Добавлен тип источника данных **Generic API** для работы с произвольными инфраструктурными сервисами ([подробнее](../../admin/datasources/types/#genericapi)): +Добавлен тип источника данных [Generic API](../../admin/datasources/types/#genericapi) для работы с произвольными инфраструктурными сервисами: - Подключение к любому сервису с REST API. - Поддержка разных типов пагинации для получения больших объёмов данных. - Настраиваемые параметры запросов (заголовки, авторизация, query-параметры). @@ -91,15 +91,15 @@ description: Заметки о выпуске v1.0.0 — виджеты, ист #### Nexus -Добавлены действия для работы с репозиториями Nexus ([подробнее](../../admin/actions/types/#createnexusrepository)): -- **CreateNexusRepository** — создание репозиториев любого поддерживаемого типа (maven, docker, npm и др.) в Nexus Repository Manager 3. -- **DeleteNexusRepository** — удаление репозиториев из Nexus Repository Manager 3. +Добавлены действия для работы с [репозиториями Nexus](../../admin/actions/types/#createnexusrepository): +- `CreateNexusRepository` — создание репозиториев любого поддерживаемого типа (maven, docker, npm и др.) в Nexus Repository Manager 3. +- `DeleteNexusRepository` — удаление репозиториев из Nexus Repository Manager 3. ### Наборы данных #### GitLab -Добавлен набор данных **GitLab** для быстрого подключения к GitLab и начала сбора и анализа репозиториев ([подробнее](../../admin/datasets/#gitlab)): +Добавлен [набор данных GitLab](../../admin/datasets/#gitlab) для быстрого подключения к GitLab и начала сбора и анализа репозиториев: - Преднастроенные дашборды для просмотра статистики и управления репозиториями. - Готовые виджеты для аналитики пайплайнов. - Автоматическая настройка внешнего сервиса и источника данных. @@ -109,7 +109,7 @@ description: Заметки о выпуске v1.0.0 — виджеты, ист #### Внешние сервисы -Добавлен механизм внешних сервисов ([подробнее](../../admin/external-services/)): +Добавлен механизм [внешних сервисов](../../admin/external-services/): - Централизованная настройка подключений к инфраструктурным сервисам. - Переиспользование настроек подключений для виджетов, действий, источников данных и проверок статуса. diff --git a/content/documentation/release-notes/v1.0.1.ru.md b/content/documentation/release-notes/v1.0.1.ru.md index d60dbf4e..369a1cf1 100644 --- a/content/documentation/release-notes/v1.0.1.ru.md +++ b/content/documentation/release-notes/v1.0.1.ru.md @@ -14,9 +14,9 @@ description: Заметки о выпуске v1.0.1 — действия HashiC #### HashiCorp Vault -Обновлено действие **CreateVaultSecret** — добавлен параметр `allow_update`. При значении `true` действие создаст новую версию секрета, если секрет с таким именем уже существует. При значении `false` действие вернёт ошибку, если секрет уже существует. +Обновлено действие `CreateVaultSecret` — добавлен параметр `allow_update`. При значении `true` действие создаст новую версию секрета, если секрет с таким именем уже существует. При значении `false` действие вернёт ошибку, если секрет уже существует. -Добавлено новое действие **DeleteVaultSecret** — удаляет секрет из HashiCorp Vault. +Добавлено новое действие `DeleteVaultSecret` — удаляет секрет из HashiCorp Vault. ## Исправления diff --git a/content/documentation/release-notes/v1.1.0.ru.md b/content/documentation/release-notes/v1.1.0.ru.md index 8ee1c273..860d1548 100644 --- a/content/documentation/release-notes/v1.1.0.ru.md +++ b/content/documentation/release-notes/v1.1.0.ru.md @@ -14,10 +14,10 @@ description: Заметки о выпуске v1.1.0 — несовместим По умолчанию включены HTTP-заголовки безопасности (Content Security Policy, X-Frame-Options и др.), что может привести к следующим проблемам: -- **Iframe виджеты перестанут работать** — виджеты, использующие iframe для отображения внешнего контента, будут заблокированы политикой CSP. -- **Иконки из внешних источников не будут отображаться** — если для объектов DDP используются иконки, загружаемые из внешних источников, они будут заблокированы. +- «Iframe виджеты перестанут работать» — виджеты, использующие iframe для отображения внешнего контента, будут заблокированы политикой CSP. +- «Иконки из внешних источников не будут отображаться» — если для объектов DDP используются иконки, загружаемые из внешних источников, они будут заблокированы. -**Чтобы сохранить предыдущее поведение:** +Чтобы сохранить предыдущее поведение: 1. Отключите заголовки безопасности полностью: @@ -38,26 +38,29 @@ description: Заметки о выпуске v1.1.0 — несовместим allowExternalImages: true ``` -Подробнее о настройке заголовков безопасности — в [документации](../../admin/security/http-security-headers/). +Подробнее о настройке — в разделе [«HTTP-заголовки безопасности»](../../admin/security/http-security-headers/). ### Группировка ресурсов в каталоге -Изменён механизм группировки ресурсов в каталоге. Ранее ресурсы группировались по префиксу в названии с разделителем `:` (например, «Gitlab: группы», «Gitlab: проекты»). Теперь группировка осуществляется через иерархическую структуру с использованием родительских ресурсов ([подробнее](../../user/catalog/#группировка-ресурсов)). +Изменён механизм группировки ресурсов в каталоге. Ранее ресурсы группировались по префиксу в названии с разделителем `:` (например, «Gitlab: группы», «Gitlab: проекты»). Теперь группировка осуществляется через [иерархическую структуру с использованием родительских ресурсов](../../user/catalog/#группировка-ресурсов). + +Что изменилось: -**Что изменилось:** - Ресурсы больше не группируются по префиксу в названии с разделителем `:`. - Для группировки ресурсов необходимо создать родительский ресурс и привязать к нему дочерние ресурсы через drag and drop в сайдбаре каталога. - В интерфейсе каталога ресурсы отображаются в виде иерархического дерева с возможностью раскрытия/сворачивания групп. -**Требуется ручная перенастройка:** +Требуется ручная перенастройка: + - Если у вас были ресурсы с группировкой по двоеточию (например, «Gitlab: группы», «Gitlab: проекты»), необходимо: 1. Создать родительский ресурс (например, «Gitlab»), 1. Убрать префикс из названий дочерних ресурсов (например, «Группы», «Проекты»), 1. Привязать дочерние ресурсы к родительскому через drag and drop в сайдбаре каталога (перетащить дочерний ресурс на родительский), 1. Скорректировать настройки ролевой модели, разрешить пользователям просмотр не только дочернего ресурса, но и всей иерархии родительских. - 1. **Важно:** Идентификатор ресурса должен оставаться уникальным в пределах всей платформы и может сохранить префикс (например, `gitlab-groups`, `gitlab-projects`), в то время как название ресурса может быть любым. + 1. Учесть, что идентификатор ресурса должен оставаться уникальным в пределах всей платформы и может сохранить префикс (например, `gitlab-groups`, `gitlab-projects`), в то время как название ресурса может быть любым. + +Важно: -**Важно:** - Название ресурса может быть любым, но идентификатор должен оставаться уникальным в пределах всей платформы. - При миграции существующих ресурсов рекомендуется сохранить идентификатор с префиксом для обратной совместимости, но изменить отображаемое название. @@ -82,55 +85,55 @@ description: Заметки о выпуске v1.1.0 — несовместим #### AI-ассистент -**AI-ассистент** — интеллектуальный помощник, интегрированный в интерфейс платформы, который предоставляет пользователям доступ к AI-моделям через удобный чат-интерфейс ([подробнее](../../user/ai-assistant/)): +[AI-ассистент](../../user/ai-assistant/) — интеллектуальный помощник, интегрированный в интерфейс платформы, который предоставляет пользователям доступ к AI-моделям через удобный чат-интерфейс: -- **Настраиваемые провайдеры** — поддержка различных AI-провайдеров (OpenAI, локальные модели и др.). -- **Интеграция с MCP-инструментами** — AI-ассистент автоматически использует доступные инструменты MCP-сервера для выполнения запросов. +- «Настраиваемые провайдеры» — поддержка различных AI-провайдеров (OpenAI, локальные модели и др.). +- «Интеграция с MCP-инструментами» — AI-ассистент автоматически использует доступные инструменты MCP-сервера для выполнения запросов. #### MCP-сервер -**MCP-сервер** — сервер, реализующий протокол MCP (Model Context Protocol) для предоставления инструментов внешним AI-клиентам ([подробнее](../../user/mcp-server/)): +[MCP-сервер](../../user/mcp-server/) — сервер, реализующий протокол MCP (Model Context Protocol) для предоставления инструментов внешним AI-клиентам: -- **Протокол MCP** — стандартизированный интерфейс для взаимодействия с AI-моделями через JSON-RPC 2.0. -- **Доступные инструменты**: +- «Протокол MCP» — стандартизированный интерфейс для взаимодействия с AI-моделями через JSON-RPC 2.0. +- «Доступные инструменты»: - `get_resource_entities` — получение сущностей ресурсов платформы для анализа, - `get_external_data` — выполнение HTTP-запросов к внешним сервисам (GitLab, SonarQube, Kubernetes и др.). -- **Интеграция с внешними клиентами** — поддержка подключения через LM Studio, Claude Desktop и другие MCP-совместимые клиенты. -- **Безопасность** — аутентификация через API-токены, права доступа соответствуют правам пользователя. +- «Интеграция с внешними клиентами» — поддержка подключения через LM Studio, Claude Desktop и другие MCP-совместимые клиенты. +- «Безопасность» — аутентификация через API-токены, права доступа соответствуют правам пользователя. ### Виджеты #### Kubernetes deployments -Обновлен виджет Kubernetes deployments ([подробнее](../../admin/widgets/types/#kubernetes-deployments)): добавлена возможность просмотра и редактирования ресурсов контейнеров (CPU и Memory для requests и limits). +Обновлён виджет [«Kubernetes Deployments»](../../admin/widgets/types/#kubernetes-deployments): добавлена возможность просмотра и редактирования ресурсов контейнеров (CPU и Memory для requests и limits). #### Статистика событий -Обновлен виджет Статистика событий ([подробнее](../../admin/widgets/types/#статистика-событий)): добавлена вкладка «События в Redis» для отслеживания событий, хранящихся в Redis Streams. +Обновлён виджет [«Статистика событий»](../../admin/widgets/types/#статистика-событий): добавлена вкладка «События в Redis» для отслеживания событий, хранящихся в Redis Streams. #### CodeScoring виджеты Добавлены виджеты для интеграции с платформой анализа безопасности кода CodeScoring: -- **CodeScoring. Зависимости** — просмотр зависимостей продукта с информацией о версиях, лицензиях и количестве уязвимостей ([подробнее](../../admin/widgets/types/#codescoring-зависимости)). -- **CodeScoring. Уязвимости** — таблица уязвимостей с уровнем критичности (CVSS2/CVSS3), наличием эксплойта и исправленными версиями ([подробнее](../../admin/widgets/types/#codescoring-уязвимости)). +- [«CodeScoring. Зависимости»](../../admin/widgets/types/#codescoring-зависимости) — просмотр зависимостей продукта с информацией о версиях, лицензиях и количестве уязвимостей. +- [«CodeScoring. Уязвимости»](../../admin/widgets/types/#codescoring-уязвимости) — таблица уязвимостей с уровнем критичности (CVSS2/CVSS3), наличием эксплойта и исправленными версиями. Оба виджета поддерживают запуск и отмену SCA-анализа, пагинацию и фильтрацию данных. #### Очередь задач -Добавлен виджет **Очередь задач** для мониторинга очереди задач и работы воркеров ([подробнее](../../admin/widgets/types/#очередь-задач)): +Добавлен виджет [«Очередь задач»](../../admin/widgets/types/#очередь-задач) для мониторинга очереди задач и работы воркеров: -- **Статистика очереди** — размер очереди, количество ожидающих задач, активных воркеров. -- **Таблица воркеров** — информация о каждом активном воркере (название, ожидающие задачи, время простоя). -- **Таблица задач** — детальная информация о всех задачах в очереди с их статусами. -- **Фильтрация неактивных воркеров** — автоматическое скрытие воркеров, неактивных более 5 минут. +- «Статистика очереди» — размер очереди, количество ожидающих задач, активных воркеров. +- «Таблица воркеров» — информация о каждом активном воркере (название, ожидающие задачи, время простоя). +- «Таблица задач» — детальная информация о всех задачах в очереди с их статусами. +- «Фильтрация неактивных воркеров» — автоматическое скрытие воркеров, неактивных более 5 минут. Виджет не требует дополнительной конфигурации и может быть добавлен на любой дашборд. #### GitLab. Релизы -Добавлен виджет **GitLab. Релизы** ([подробнее](../../admin/widgets/types/#gitlab-релизы)): +Добавлен виджет [«GitLab. Релизы»](../../admin/widgets/types/#gitlab-релизы): - отображает список релизов проекта с подсветкой актуального (последнего) релиза; - показывает тег, ссылку на коммит, дату и автора релиза, описание поддерживает Markdown; @@ -138,7 +141,7 @@ description: Заметки о выпуске v1.1.0 — несовместим #### Статус сущности -Добавлен виджет «Статус сущности» ([подробнее](../../admin/widgets/types/#статус-сущности)), который: +Добавлен виджет [«Статус сущности»](../../admin/widgets/types/#статус-сущности), который: - отображает общий статус сущности; - показывает детальную информацию по каждой проверке (текущий статус, время последней проверки, сообщения об ошибках); @@ -146,20 +149,21 @@ description: Заметки о выпуске v1.1.0 — несовместим #### Временная шкала сущностей -Добавлен виджет «Временная шкала сущностей» ([подробнее](../../admin/widgets/types/#временная-шкала-сущностей)), который отображает сущности выбранного ресурса на временной шкале. +Добавлен виджет [«Временная шкала сущностей»](../../admin/widgets/types/#временная-шкала-сущностей), который отображает сущности выбранного ресурса на временной шкале. #### Календарь сущностей -Добавлен виджет «Календарь сущностей» ([подробнее](../../admin/widgets/types/#календарь-сущностей)), который отображает сущности выбранного ресурса в календаре. +Добавлен виджет [«Календарь сущностей»](../../admin/widgets/types/#календарь-сущностей), который отображает сущности выбранного ресурса в календаре. ### Воркеры -Добавлена поддержка воркеров для асинхронной обработки задач ([подробнее](../../admin/architecture/workers/)): +Добавлена поддержка [воркеров для асинхронной обработки задач](../../admin/architecture/workers/): + +- «Фоновая обработка задач» — задачи выполняются в фоновом режиме, не блокируя основной сервер. +- «Масштабируемость» — настраиваемое количество реплик воркеров и параллельных задач. -- **Фоновая обработка задач** — задачи выполняются в фоновом режиме, не блокируя основной сервер. -- **Масштабируемость** — настраиваемое количество реплик воркеров и параллельных задач. +Параметры конфигурации: -**Параметры конфигурации:** - `workers.replicas` — количество реплик воркеров (по умолчанию: 2); - `workers.maxTasks` — максимальное количество параллельных задач на воркер (по умолчанию: 10). @@ -167,11 +171,11 @@ description: Заметки о выпуске v1.1.0 — несовместим #### CodeScoring Vulnerabilities -Добавлена проверка статуса для CodeScoring ([подробнее](../../admin/healthchecks/types/#codescoring-vulnerabilities)): **CodeScoring Vulnerabilities** — проверка количества уязвимостей по метрикам CVSS2 и CVSS3 для проекта в CodeScoring с настраиваемыми пороговыми значениями для каждого уровня критичности. +Добавлена [проверка статуса «CodeScoring Vulnerabilities»](../../admin/healthchecks/types/#codescoring-vulnerabilities) — проверка количества уязвимостей по метрикам CVSS2 и CVSS3 для проекта в CodeScoring с настраиваемыми пороговыми значениями для каждого уровня критичности. #### SonarQube Quality Gate -Добавлена проверка статуса для SonarQube Quality Gate ([подробнее](../../admin/healthchecks/types/#sonarqube-quality-gate)): **SonarQube Quality Gate** — проверка статуса Quality Gate проекта в SonarQube. +Добавлена [проверка статуса «SonarQube Quality Gate»](../../admin/healthchecks/types/#sonarqube-quality-gate) — проверка статуса Quality Gate проекта в SonarQube. ### Действия @@ -179,23 +183,23 @@ description: Заметки о выпуске v1.1.0 — несовместим Добавлены действия для работы с CodeScoring: -- **CreateCodeScoringProject** — регистрирует новый проект в CodeScoring с указанием репозитория, VCS системы и опцией автоматического запуска SCA-анализа ([подробнее](../../admin/actions/types/#createcodescoringproject)). -- **DeleteCodeScoringProject** — удаляет проект в CodeScoring по его ID ([подробнее](../../admin/actions/types/#deletecodescoringproject)). +- [`CreateCodeScoringProject`](../../admin/actions/types/#createcodescoringproject) — регистрирует новый проект в CodeScoring с указанием репозитория, VCS системы и опцией автоматического запуска SCA-анализа. +- [`DeleteCodeScoringProject`](../../admin/actions/types/#deletecodescoringproject) — удаляет проект в CodeScoring по его ID. #### GitLab -**CreateGitlabRelease** — позволяет создавать релизы на основе существующих тегов GitLab ([подробнее](../../admin/actions/types/#creategitlabrelease)). +[`CreateGitlabRelease`](../../admin/actions/types/#creategitlabrelease) — позволяет создавать релизы на основе существующих тегов GitLab. #### Vault -**CreateVaultSecret** — расширена опция `allow_update`: добавлено значение `merge`. При выставлении значения `merge` обновляются или создаются только те ключи секрета, которые указаны в действии. Существующие ключи, не упомянутые в действии, сохраняются без изменений. +`CreateVaultSecret` — расширена опция `allow_update`: добавлено значение `merge`. При выставлении значения `merge` обновляются или создаются только те ключи секрета, которые указаны в действии. Существующие ключи, не упомянутые в действии, сохраняются без изменений. ### Шаблонизация Добавлены функции для работы с Unicode строками: -- **encodeUnicode** — кодирует строку в Unicode escape-последовательности ([подробнее](../../user/templating/#encodeunicode)); -- **decodeUnicode** — декодирует Unicode escape-последовательности обратно в строку ([подробнее](../../user/templating/#decodeunicode)). +- [`encodeUnicode`](../../user/templating/#encodeunicode) — кодирует строку в Unicode escape-последовательности; +- [`decodeUnicode`](../../user/templating/#decodeunicode) — декодирует Unicode escape-последовательности обратно в строку. ## Исправления diff --git a/content/documentation/release-notes/v1.2.0.ru.md b/content/documentation/release-notes/v1.2.0.ru.md index 1a717a50..666b70b0 100644 --- a/content/documentation/release-notes/v1.2.0.ru.md +++ b/content/documentation/release-notes/v1.2.0.ru.md @@ -18,31 +18,31 @@ description: Заметки о выпуске v1.2.0 — иконки, AI-асс ### AI-ассистент -Добавлен механизм безопасного хранения учётных данных для AI-провайдеров ([подробнее](../../user/ai-assistant/#учетные-данные-для-провайдеров)). +Добавлен механизм [безопасного хранения учётных данных для AI-провайдеров](../../user/ai-assistant/#учётные-данные-для-провайдеров). ### Действия -- Добавлен параметр конфигурации `actions.logging.enabled`, позволяющий управлять выводом логов действий в stdout ([подробнее](../../admin/actions/overview/#логирование-запусков)). -- Добавлена возможность настройки временного ответа для действий ([подробнее](../../admin/actions/overview/#временный-ответ)). +- Добавлен параметр конфигурации `actions.logging.enabled`, позволяющий управлять [выводом логов действий в stdout](../../admin/actions/overview/#логирование-запусков). +- Добавлена возможность настройки [временного ответа для действий](../../admin/actions/overview/#временный-ответ). - Добавлена панель управления действиями, которая позволяет просмотреть все действия, запущенные пользователем, подтвердить назначенные действия или удалить временный ответ. - Добавлены действия для управления Nexus Repository Manager 3: - - `CreateNexusPrivilege` — создание привилегий ([подробнее](../../admin/actions/types/#createnexusprivilege)); - - `AssignNexusPrivilege` — назначение привилегий ролям ([подробнее](../../admin/actions/types/#assignnexusprivilege)); - - `DeleteNexusPrivilege` — удаление привилегий ([подробнее](../../admin/actions/types/#deletenexusprivilege)); - - `CreateNexusRole` — создание ролей ([подробнее](../../admin/actions/types/#createnexusrole)); - - `AssignNexusRole` — назначение ролей пользователям ([подробнее](../../admin/actions/types/#assignnexusrole)); - - `DeleteNexusRole` — удаление ролей ([подробнее](../../admin/actions/types/#deletenexusrole)); - - `CreateNexusUser` — создание пользователей ([подробнее](../../admin/actions/types/#createnexususer)); - - `DeleteNexusUser` — удаление пользователей ([подробнее](../../admin/actions/types/#deletenexususer)). + - [`CreateNexusPrivilege`](../../admin/actions/types/#createnexusprivilege) — создание привилегий; + - [`AssignNexusPrivilege`](../../admin/actions/types/#assignnexusprivilege) — назначение привилегий ролям; + - [`DeleteNexusPrivilege`](../../admin/actions/types/#deletenexusprivilege) — удаление привилегий; + - [`CreateNexusRole`](../../admin/actions/types/#createnexusrole) — создание ролей; + - [`AssignNexusRole`](../../admin/actions/types/#assignnexusrole) — назначение ролей пользователям; + - [`DeleteNexusRole`](../../admin/actions/types/#deletenexusrole) — удаление ролей; + - [`CreateNexusUser`](../../admin/actions/types/#createnexususer) — создание пользователей; + - [`DeleteNexusUser`](../../admin/actions/types/#deletenexususer) — удаление пользователей. ### Владение объектами -Добавлена автоматическая установка текущего пользователя в качестве владельца создаваемых объектов ([подробнее](../../admin/security/rbac/#автоматическое-назначение-владельца-при-создании)). +Добавлена [автоматическая установка текущего пользователя в качестве владельца создаваемых объектов](../../admin/security/rbac/#автоматическое-назначение-владельца-при-создании). ### Ролевая модель - Добавлены новые глобальные разрешения для управления иконками: `create:icons` и `delete:icons`. -- Добавлен пресет глобальной роли `Developer` ([подробнее](../../admin/security/rbac/#пресет-developer)). +- Добавлен [пресет глобальной роли `Developer`](../../admin/security/rbac/#пресет-developer). ## Исправления diff --git a/content/documentation/release-notes/v1.2.1.ru.md b/content/documentation/release-notes/v1.2.1.ru.md index bb2991eb..9021d879 100644 --- a/content/documentation/release-notes/v1.2.1.ru.md +++ b/content/documentation/release-notes/v1.2.1.ru.md @@ -12,6 +12,6 @@ description: Заметки о выпуске v1.2.1 — улучшения ве ### Действия -- Добавлена возможность выбора формата тела запроса для вебхук-действий ([подробнее](../../admin/actions/overview/#формат-тела-запроса)). -- Добавлена опция расширенного логирования для вебхук-действий ([подробнее](../../admin/actions/overview/#расширенное-логирование)). -- Добавлена возможность автоматического обновления учётных данных пользователя после выполнения действия ([подробнее](../../admin/actions/overview/#обновление-учётных-данных-пользователя)). +- Добавлена возможность выбора [формата тела запроса для вебхук-действий](../../admin/actions/overview/#формат-тела-запроса). +- Добавлена опция [расширенного логирования для вебхук-действий](../../admin/actions/overview/#расширенное-логирование). +- Добавлена возможность [автоматического обновления учётных данных пользователя](../../admin/actions/overview/#обновление-учётных-данных-пользователя) после выполнения действия. diff --git a/content/documentation/release-notes/v1.4.0.ru.md b/content/documentation/release-notes/v1.4.0.ru.md index 38c1cb93..15d0584d 100644 --- a/content/documentation/release-notes/v1.4.0.ru.md +++ b/content/documentation/release-notes/v1.4.0.ru.md @@ -83,7 +83,7 @@ CREATE EXTENSION IF NOT EXISTS pg_trgm; - «Wait» — для [паузы на заданное время](../../admin/actions/types/#wait). - «Fail» — для [принудительного завершения с ошибкой](../../admin/actions/types/#fail). -Изменения в существующих действиях: для действия «CreateVaultSecret» для параметра `allow_update` добавлено значение [`merge_or_create`](../../admin/actions/types/#createvaultsecret). +Изменения в существующих действиях: в действии [`CreateVaultSecret`](../../admin/actions/types/#createvaultsecret) для параметра `allow_update` добавлено значение `merge_or_create`. ### Источники данных diff --git a/content/documentation/release-notes/v1.6.0.ru.md b/content/documentation/release-notes/v1.6.0.ru.md index 3f47810e..9ab3ea54 100644 --- a/content/documentation/release-notes/v1.6.0.ru.md +++ b/content/documentation/release-notes/v1.6.0.ru.md @@ -1,6 +1,7 @@ --- title: v1.6.0 weight: 910 +description: Заметки о выпуске v1.6.0 — выгрузка аудит-логов в CSV, формат map в GenericAPI, функция toSlug, улучшения интерфейса и исправления. --- {{< alert level="info" >}} @@ -24,9 +25,9 @@ weight: 910 ## Улучшения интерфейса - Добавлена возможность создания новых действий, либо редактирования существующих, из окна конфигурации элемента процесса. -- Добавлена возможность создания новых учетных данных из окна конфигурации внешних сервисов, действий, виджетов и источников данных. +- Добавлена возможность создания новых учётных данных из окна конфигурации внешних сервисов, действий, виджетов и источников данных. - Добавлено поле «Дата окончания» для элементов процессов и действий. ## Исправления -- Удалена возможность создания параметра типа «Entities» для ресурсов. +Удалена возможность создания параметра типа «Entities» для ресурсов. diff --git a/content/documentation/user/ai-assistant.ru.md b/content/documentation/user/ai-assistant.ru.md index a0813d9b..16d51087 100644 --- a/content/documentation/user/ai-assistant.ru.md +++ b/content/documentation/user/ai-assistant.ru.md @@ -6,7 +6,7 @@ title: AI-ассистент Экспериментальный функционал {{< /alert >}} -AI-ассистент — это интеллектуальный помощник, встроенный в Deckhouse Development Platform. Он отвечает на вопросы о платформе, анализирует данные каталога и выполняет различные задачи с использованием инструментов MCP (Model Context Protocol). +AI-ассистент — это интеллектуальный помощник, встроенный в Deckhouse Development Platform (DDP). Он отвечает на вопросы о платформе, анализирует данные каталога и выполняет различные задачи с использованием инструментов MCP (Model Context Protocol). AI-ассистент использует настраиваемые AI-провайдеры для обработки запросов и может работать с различными языковыми моделями, включая OpenAI GPT, Ollama и любые модели, доступные через совместимый REST API. @@ -26,20 +26,20 @@ AI-ассистент использует настраиваемые AI-про Примеры для распространённых API приведены в разделе [«Примеры конфигурации»](#примеры-конфигурации). -## Учетные данные для провайдеров +## Учётные данные для провайдеров Для безопасного хранения токенов и ключей используется система учётных данных: они шифруются в базе и подставляются в заголовки запросов через шаблонизацию. -### Добавление учетных данных +### Добавление учётных данных -Для добавления новых учетных данных: +Для добавления новых учётных данных: -1. В форме создания или редактирования провайдера нажмите «Управление учетными данными». -1. В диалоге нажмите «Добавить учетные данные». +1. В форме создания или редактирования провайдера нажмите «Управление учётными данными». +1. В диалоге нажмите «Добавить учётные данные». 1. Введите пару «Ключ» / «Значение» (например, `api_key` и секрет). 1. Нажмите «Сохранить». -### Изменение учетных данных +### Изменение учётных данных Обратите внимание, что: @@ -116,7 +116,7 @@ OpenAI-совместимый чат: ``` {{< alert level="info" >}} -Шаблон должен быть валидным JSON. В него можно добавлять поля вроде `temperature`, `max_tokens` и т.д. +Шаблон должен быть валидным JSON. В него можно добавлять поля вроде `temperature`, `max_tokens` и т. д. {{< /alert >}} ## Примеры конфигурации @@ -127,7 +127,7 @@ OpenAI-совместимый чат: 1. «Модель» — например, `gpt-4` или `gpt-3.5-turbo`. 1. «URL» — `https://api.openai.com/v1/chat/completions`. 1. «Метод» — `POST`. -1. «Заголовки» — например, `Authorization: Bearer {{ .credentials.openai_api_key }}` (ключ `openai_api_key` заведите в «Управлении учетными данными»). +1. «Заголовки» — например, `Authorization: Bearer {{ .credentials.openai_api_key }}` (ключ `openai_api_key` заведите в «Управлении учётными данными»). 1. «Поле ответа» — `choices.0.message.content`. 1. «Шаблон тела» — как в [первом примере](#примеры-структуры) в разделе «Шаблон тела запроса». @@ -152,7 +152,7 @@ OpenAI-совместимый чат: - «Метод» — обычно `POST`. - «Заголовки» — например, `Authorization: Bearer {{ .credentials.api_key }}`, `Content-Type: application/json`. - «Поле ответа» — путь к полю с текстом в вашем JSON. -- «Шаблон тела» — на базе первого примера в разделе [«Шаблон тела запроса»](#шаблон-тела-запроса), при необходимости добавьте поля (`max_tokens` и т.д.). +- «Шаблон тела» — на базе первого примера в разделе [«Шаблон тела запроса»](#шаблон-тела-запроса), при необходимости добавьте поля (`max_tokens` и т. д.). ## Работа с AI-ассистентом diff --git a/content/documentation/user/catalog.ru.md b/content/documentation/user/catalog.ru.md index f21706b7..208b0e40 100644 --- a/content/documentation/user/catalog.ru.md +++ b/content/documentation/user/catalog.ru.md @@ -17,8 +17,8 @@ weight: 30 При именовании ресурсов следуйте правилам: -- **Название ресурса** может быть любым и не требует специальных префиксов или разделителей. -- **Идентификатор ресурса** должен быть уникальным в пределах всей платформы. +- «Название ресурса» может быть любым и не требует специальных префиксов или разделителей. +- «Идентификатор ресурса» должен быть уникальным в пределах всей платформы. ### Группировка ресурсов @@ -26,11 +26,11 @@ weight: 30 Для создания группы ресурсов необходимо: -1. **Создать ресурсы** — создать все необходимые ресурсы, которые будут входить в группу. Например, ресурс «GitLab» может быть родительским для ресурсов «Репозитории», «Группы» и т.д. +1. «Создать ресурсы» — создать все необходимые ресурсы, которые будут входить в группу. Например, ресурс «GitLab» может быть родительским для ресурсов «Репозитории», «Группы» и т. д. -1. **Связать дочерние ресурсы с родительскими** — в сайдбаре каталога перетащить дочерний ресурс на родительский ресурс. Дочерние ресурсы будут автоматически привязаны к родительскому и отобразятся в интерфейсе как вложенные элементы. +1. «Связать дочерние ресурсы с родительскими» — в сайдбаре каталога перетащить дочерний ресурс на родительский ресурс. Дочерние ресурсы будут автоматически привязаны к родительскому и отобразятся в интерфейсе как вложенные элементы. -1. **Настроить отображение** — в сайдбаре каталога родительские ресурсы отображаются с иконкой раскрытия/сворачивания, позволяющей показывать или скрывать дочерние элементы. +1. «Настроить отображение» — в сайдбаре каталога родительские ресурсы отображаются с иконкой раскрытия/сворачивания, позволяющей показывать или скрывать дочерние элементы. {{< alert level="info" >}} Для изменения группировки ресурсов (перетаскивания ресурсов в сайдбаре каталога) требуется глобальное разрешение `update:resources-order`. Подробнее о правах доступа — в разделе [«Ролевая модель»](../../admin/security/rbac/). @@ -52,19 +52,19 @@ weight: 30 В форме редактирования ресурса задаются три независимых варианта использования дашбордов: -1. **Использовать дашборд на странице ресурса** — выбранный дашборд выводится на странице ресурса вместо таблицы или карточек сущностей. +1. «Использовать дашборд на странице ресурса» — выбранный дашборд выводится на странице ресурса вместо таблицы или карточек сущностей. -1. **Использовать дашборд на странице сущности** — выбранный дашборд выводится на странице сущности вместо встроенного содержимого вкладки «Обзор». +1. «Использовать дашборд на странице сущности» — выбранный дашборд выводится на странице сущности вместо встроенного содержимого вкладки «Обзор». -1. **Дополнительные вкладки с дашбордами** — дополнительные дашборды в виде вкладок на странице каждой сущности ресурса. Порядок отображения дашбордов зависит от порядка в конфигурации ресурса, доступно изменение порядка перетаскиванием. Один и тот же дашборд нельзя добавить несколько раз для одного и того же ресурса. +1. «Дополнительные вкладки с дашбордами» — дополнительные дашборды в виде вкладок на странице каждой сущности ресурса. Порядок отображения дашбордов зависит от порядка в конфигурации ресурса, доступно изменение порядка перетаскиванием. Один и тот же дашборд нельзя добавить несколько раз для одного и того же ресурса. ### Режим просмотра сущностей -Когда на странице ресурса отображается список сущностей, над списком доступен переключатель **«Таблица»** и **«Карточки»**. +Когда на странице ресурса отображается список сущностей, над списком доступен переключатель «Таблица» и «Карточки». -1. **Таблица** — сущности в виде таблицы с сортировкой, пагинацией и поиском; при необходимости доступно массовое удаление. +1. «Таблица» — сущности в виде таблицы с сортировкой, пагинацией и поиском; при необходимости доступно массовое удаление. -1. **Карточки** — сущности в виде карточек с основными параметрами; список подгружается при прокрутке страницы. +1. «Карточки» — сущности в виде карточек с основными параметрами; список подгружается при прокрутке страницы. 1. Выбранный режим сохраняется в браузере отдельно для каждого ресурса. @@ -86,19 +86,19 @@ weight: 30 При именовании сущностей следуйте правилам: -- **Название сущности** может быть любым и не требует специальных префиксов или разделителей. -- **Идентификатор сущности** должен быть уникальным в пределах ресурса. +- «Название сущности» может быть любым и не требует специальных префиксов или разделителей. +- «Идентификатор сущности» должен быть уникальным в пределах ресурса. ### Страница сущности Страница сущности состоит из встроенных панелей и вкладок с дашбордами. Встроенные панели: -- **Обзор** — содержит блоки с указанием владельца сущности, её описанием, параметрами и связями. -- **Запуски действий** — содержит список действий, которые запускались для данной сущности. -- **Запуски процессов** — содержит список процессов, которые запускались для данной сущности. -- **События** — содержит список событий, сгенерированных для данной сущности. +- «Обзор» — содержит блоки с указанием владельца сущности, её описанием, параметрами и связями. +- «Запуски действий» — содержит список действий, которые запускались для данной сущности. +- «Запуски процессов» — содержит список процессов, которые запускались для данной сущности. +- «События» — содержит список событий, сгенерированных для данной сущности. -Вкладки с дашбордами из поля **Дополнительные вкладки с дашбордами** в настройках ресурса отображаются на странице сущности рядом со встроенными панелями; порядок вкладок соответствует порядку в настройках ресурса. +Вкладки с дашбордами из поля «Дополнительные вкладки с дашбордами» в настройках ресурса отображаются на странице сущности рядом со встроенными панелями; порядок вкладок соответствует порядку в настройках ресурса. ### Связи между сущностями @@ -110,14 +110,14 @@ weight: 30 При создании, удалении либо изменении спецификации любой сущности генерируется событие соответствующего типа: `ENTITY_CREATED`, `ENTITY_DELETED`, `ENTITY_UPDATED`. Эти события нужны для следующих целей: -- **Аудит** — фиксация изменений, происходящих с сущностью в течение её жизненного цикла. -- **Настройка автоматизированных реакций** — настройка реакций на изменения спецификации сущности. +- «Аудит» — фиксация изменений, происходящих с сущностью в течение её жизненного цикла. +- «Настройка автоматизированных реакций» — настройка реакций на изменения спецификации сущности. Время хранения событий ограничено и может быть настроено через файл конфигурации платформы. ### Избранное -Пользователь может добавить любую сущность в избранное. Для этого на странице сущности нажмите на круглую кнопку со всплывающей подсказкой **Добавить в избранное** рядом с названием сущности. Посмотреть добавленные в избранное сущности можно в разделе каталога «Избранное». +Пользователь может добавить любую сущность в избранное. Для этого на странице сущности нажмите на круглую кнопку со всплывающей подсказкой «Добавить в избранное» рядом с названием сущности. Посмотреть добавленные в избранное сущности можно в разделе каталога «Избранное». {{< alert level="info" >}} Каждый пользователь видит в разделе «Избранное» только его добавленные сущности. @@ -133,7 +133,7 @@ weight: 30 1. Откройте страницу ресурса в каталоге. -1. Рядом с названием ресурса нажмите на круглую кнопку со всплывающей подсказкой **Выгрузить сущности ресурса в CSV**. +1. Рядом с названием ресурса нажмите на круглую кнопку со всплывающей подсказкой «Выгрузить сущности ресурса в CSV». 1. В выгруженный файл будут включены все сущности ресурса с учётом применённых фильтров, сортировки и пагинации. @@ -141,11 +141,11 @@ weight: 30 Для выгрузки сущностей из нескольких ресурсов одновременно: -1. В сайдбаре каталога нажмите кнопку **Выгрузить сущности**. +1. В сайдбаре каталога нажмите кнопку «Выгрузить сущности». 1. В открывшемся диалоге выберите один или несколько ресурсов. -1. Нажмите кнопку **Скачать .csv**. +1. Нажмите кнопку «Скачать .csv». 1. Все сущности выбранных ресурсов будут объединены в один CSV-файл. diff --git a/content/documentation/user/credentials.ru.md b/content/documentation/user/credentials.ru.md index 78bc6d6c..2e2e32b0 100644 --- a/content/documentation/user/credentials.ru.md +++ b/content/documentation/user/credentials.ru.md @@ -1,23 +1,21 @@ --- -title: Учетные данные -menuTitle: Учетные данные -d8Edition: ee -moduleStatus: experimental +title: Учётные данные +menuTitle: Учётные данные --- -Учетные данные — это механизм безопасного хранения и использования реквизитов доступа к внешним сервисам (токены, пароли, ключи API и т.д.) в платформе DDP. +Учётные данные — это механизм безопасного хранения и использования реквизитов доступа к внешним сервисам (токены, пароли, ключи API и т. д.) в Deckhouse Development Platform (DDP). ## Как это работает -Все взаимодействие с инфраструктурными сервисами в DDP происходит с использованием учётных данных конкретного пользователя. Учетные данные шифруются перед сохранением в базе данных и расшифровываются только при необходимости их использования в действиях, источниках данных и виджетах. +Всё взаимодействие с инфраструктурными сервисами в DDP происходит с использованием учётных данных конкретного пользователя. Учётные данные шифруются перед сохранением в базе данных и расшифровываются только при необходимости их использования в действиях, источниках данных и виджетах. Подробнее о механизме работы, шифровании и настройке — [в документации](../../admin/security/credentials/). ## Заполнение учётных данных -Администратор платформы создает типы учётных данных в разделе «Администрирование» → «Учетные данные». Для каждого типа учётных данных вы можете указать свои персональные реквизиты в профиле в разделе «Учетные данные». +Администратор платформы создаёт типы учётных данных в разделе «Администрирование» → «Учётные данные». Для каждого типа учётных данных вы можете указать свои персональные реквизиты в профиле в разделе «Учётные данные». -Например, если администратор создал тип учётных данных **Kubernetes token**, то вы в своем профиле сможете добавить персональный токен для доступа в Kubernetes. +Например, если администратор создал тип учётных данных «Kubernetes token», то вы в своём профиле сможете добавить персональный токен для доступа в Kubernetes. ## Особенности работы с учётными данными diff --git a/content/documentation/user/interface.md b/content/documentation/user/interface.md index fd701a91..dc743397 100644 --- a/content/documentation/user/interface.md +++ b/content/documentation/user/interface.md @@ -5,10 +5,10 @@ weight: 20 The Deckhouse Development Platform interface consists of the following sections: -- **Home**: the platform’s landing page. You can place one or more dashboards with widgets here. -- **Catalog**: a service catalog for viewing resources, entities, and relationships, and for running actions and scenarios. -- **Self-Service**: a section for configuring data sources, actions, webhooks, automations, scenarios, dashboards, and widgets. Access to this section can be restricted by the RBAC model. -- **Administration**: a section for managing teams, users, access policies, and credentials. Access to this section can be restricted by the RBAC model. +- "Home": the platform’s landing page. You can place one or more dashboards with widgets here. +- "Catalog": a service catalog for viewing resources, entities, and relationships, and for running actions and scenarios. +- "Self-Service": a section for configuring data sources, actions, webhooks, automations, scenarios, dashboards, and widgets. Access to this section can be restricted by the RBAC model. +- "Administration": a section for managing teams, users, access policies, and credentials. Access to this section can be restricted by the RBAC model. ## Global search diff --git a/content/documentation/user/interface.ru.md b/content/documentation/user/interface.ru.md index 2621461a..3f56e8aa 100644 --- a/content/documentation/user/interface.ru.md +++ b/content/documentation/user/interface.ru.md @@ -3,12 +3,12 @@ title: Интерфейс weight: 20 --- -Интерфейс Deckhouse Development Platform состоит из следующих разделов: +Интерфейс Deckhouse Development Platform (DDP) состоит из следующих разделов: -- **Главная** — стартовая страница платформы. Здесь можно размещать один или несколько дашбордов с виджетами. -- **Каталог** — сервисный каталог для просмотра ресурсов, сущностей и связей, а также для запуска действий и сценариев. -- **Самообслуживание** — раздел для настройки источников данных, действий, вебхуков, автоматизаций, сценариев, дашбордов и виджетов. Доступ к разделу может быть ограничен ролевой моделью. -- **Администрирование** — раздел для управления командами, пользователями, политиками доступа и учетными данными. Доступ к разделу может быть ограничен ролевой моделью. +- «Главная» — стартовая страница платформы. Здесь можно размещать один или несколько дашбордов с виджетами. +- «Каталог» — сервисный каталог для просмотра ресурсов, сущностей и связей, а также для запуска действий и сценариев. +- «Самообслуживание» — раздел для настройки источников данных, действий, вебхуков, автоматизаций, сценариев, дашбордов и виджетов. Доступ к разделу может быть ограничен ролевой моделью. +- «Администрирование» — раздел для управления командами, пользователями, политиками доступа и учётными данными. Доступ к разделу может быть ограничен ролевой моделью. ## Глобальный поиск diff --git a/content/documentation/user/mcp-server.ru.md b/content/documentation/user/mcp-server.ru.md index 8815b885..0430b285 100644 --- a/content/documentation/user/mcp-server.ru.md +++ b/content/documentation/user/mcp-server.ru.md @@ -6,7 +6,7 @@ title: MCP-сервер Экспериментальный функционал {{< /alert >}} -MCP-сервер — компонент Deckhouse Development Platform, который реализует протокол MCP (Model Context Protocol) и обеспечивает взаимодействие внешних AI-клиентов (таких как LM Studio, Claude Desktop и других) с платформой. +MCP-сервер — компонент Deckhouse Development Platform (DDP), который реализует протокол MCP (Model Context Protocol) и обеспечивает взаимодействие внешних AI-клиентов (таких как LM Studio, Claude Desktop и других) с платформой. Сервер работает по JSON-RPC 2.0 и предоставляет набор инструментов для работы с ресурсами платформы и проксирования запросов во внешние инфраструктурные сервисы. MCP — это открытый протокол для взаимодействия AI-моделей с внешними системами. Подробнее о протоколе можно узнать на [официальном сайте MCP](https://modelcontextprotocol.io/). @@ -17,11 +17,11 @@ MCP — это открытый протокол для взаимодейств Получить список ресурсов. -**Параметры**: нет. +Параметры: нет. -**Возвращает**: список ресурсов. +Возвращает: список ресурсов. -**Пример**: +Пример: ```sh Получи список ресурсов @@ -31,13 +31,13 @@ MCP — это открытый протокол для взаимодейств ### get_external_services -Получить список внешних сервисов (GitLab, SonarQube и т.д.). +Получить список внешних сервисов (GitLab, SonarQube и т. д.). -**Параметры**: нет. +Параметры: нет. -**Возвращает**: список внешних сервисов. +Возвращает: список внешних сервисов. -**Пример**: +Пример: ```sh Получи список внешних сервисов @@ -49,15 +49,15 @@ MCP — это открытый протокол для взаимодейств Получить все сущности выбранного ресурса. -**Параметры**: +Параметры: -| Название | Тип | Обязательный | Описание | -|------------------|--------|--------------|-----------------| -| `resource_uuid` | строка | да | UUID ресурса. | +| Название | Тип | Обязательность | Описание | +|------------------|--------|----------------|---------------| +| `resource_uuid` | строка | Да | UUID ресурса | -**Возвращает**: список сущностей ресурса. +Возвращает: список сущностей ресурса. -**Пример**: +Пример: ```sh Получи все сервисы и покажи название и дату создания @@ -69,15 +69,15 @@ MCP — это открытый протокол для взаимодейств Получить одну сущность по UUID. -**Параметры**: +Параметры: -| Название | Тип | Обязательность | Описание | -|-----------------|--------|----------------|----------------| -| `entity_uuid` | строка | **да** | UUID сущности. | +| Название | Тип | Обязательность | Описание | +|-----------------|--------|----------------|---------------| +| `entity_uuid` | строка | Да | UUID сущности | -**Возвращает**: данные одной сущности. +Возвращает: данные одной сущности. -**Пример**: +Пример: ```sh Получи сущность с UUID 3fa85f64-5717-4562-b3fc-2c963f66afa6 @@ -89,16 +89,16 @@ MCP — это открытый протокол для взаимодейств Получить связи сущности. -**Параметры**: +Параметры: -| Название | Тип | Обязательность | Описание | -|------------------|--------|----------------|-------------------------| -| `resource_uuid` | строка | **да** | UUID ресурса. | -| `entity_slug` | строка | **да** | Идентификатор сущности. | +| Название | Тип | Обязательность | Описание | +|------------------|--------|----------------|------------------------| +| `resource_uuid` | строка | Да | UUID ресурса | +| `entity_slug` | строка | Да | Идентификатор сущности | -**Возвращает**: список связей сущности. +Возвращает: список связей сущности. -**Пример**: +Пример: ```sh Получи связи сущности «api-gateway» ресурса «Сервисы» @@ -110,21 +110,21 @@ MCP — это открытый протокол для взаимодейств Выполнить HTTP-запрос к внешнему сервису с учётными данными пользователя. -**Параметры**: +Параметры: -| Название | Тип | Обязательный | Описание | -|----------------------------|--------|--------------|--------------------------------------------------------------------------| -| `external_service_uuid` | строка | да | UUID внешнего сервиса. | -| `query` | строка | да | Описание запроса (например: «получить пайплайны проекта 123»). | -| `api_path` | строка | да | Путь к API с параметрами запроса (например, пагинация). | -| `method` | строка | нет | HTTP-метод. По умолчанию: `GET`. | -| `body` | строка | нет | Тело запроса для POST/PUT/PATCH (JSON-строка). | +| Название | Тип | Обязательность | Описание | +|----------------------------|--------|----------------|------------------------------------------------------------------------| +| `external_service_uuid` | строка | Да | UUID внешнего сервиса | +| `query` | строка | Да | Описание запроса (например: «получить пайплайны проекта 123») | +| `api_path` | строка | Да | Путь к API с параметрами запроса (например, пагинация) | +| `method` | строка | Нет | HTTP-метод. По умолчанию: `GET` | +| `body` | строка | Нет | Тело запроса для POST/PUT/PATCH (JSON-строка) | Учётные данные и заголовки берутся из настроек внешнего сервиса в платформе. -**Возвращает**: результат HTTP-запроса к внешнему сервису. +Возвращает: результат HTTP-запроса к внешнему сервису. -**Пример**: +Пример: ```sh Получи список проектов из внешнего сервиса GitLab @@ -136,11 +136,11 @@ MCP — это открытый протокол для взаимодейств Получить список действий. -**Параметры**: нет. +Параметры: нет. -**Возвращает**: список действий. +Возвращает: список действий. -**Пример**: +Пример: ```sh Получи список действий @@ -152,11 +152,11 @@ MCP — это открытый протокол для взаимодейств Получить список источников данных. -**Параметры**: нет. +Параметры: нет. -**Возвращает**: список источников данных. +Возвращает: список источников данных. -**Пример**: +Пример: ```sh Получи список источников данных @@ -168,11 +168,11 @@ MCP — это открытый протокол для взаимодейств Получить список процессов. -**Параметры**: нет. +Параметры: нет. -**Возвращает**: список процессов. +Возвращает: список процессов. -**Пример**: +Пример: ```sh Получи список процессов @@ -211,7 +211,7 @@ MCP — это открытый протокол для взаимодейств - LM Studio попытается подключиться к серверу. - Если подключение успешно, вы увидите список доступных инструментов: - `get_resources` — получить список ресурсов. - - `get_external_services` — получить список внешних сервисов (GitLab, SonarQube и т.д.). + - `get_external_services` — получить список внешних сервисов (GitLab, SonarQube и т. д.). - `get_resource_entities` — получить все сущности выбранного ресурса. - `get_entity` — получить одну сущность по UUID. - `get_entity_relations` — получить связи сущности по ресурсу и идентификатору. @@ -239,14 +239,14 @@ MCP-сервер Deckhouse Development Platform совместим с любым ### Пример запроса к MCP-серверу -**HTTP-заголовки:** +HTTP-заголовки: ```sh Authorization: Bearer your-api-token-here Content-Type: application/json ``` -**Тело запроса:** +Тело запроса: ```json { @@ -289,12 +289,12 @@ Content-Type: application/json Права доступа: - Инструменты работают с теми же правами, что и пользователь. -- Если у вас нет доступа к ресурсу, инструмент вернет ошибку доступа. +- Если у вас нет доступа к ресурсу, инструмент вернёт ошибку доступа. - Данные фильтруются в соответствии с вашими правами RBAC. ## Устранение неполадок -### Не удается подключиться к серверу +### Не удаётся подключиться к серверу Если не получается подключиться к серверу: diff --git a/content/documentation/user/overview.ru.md b/content/documentation/user/overview.ru.md index 77843b00..be720df2 100644 --- a/content/documentation/user/overview.ru.md +++ b/content/documentation/user/overview.ru.md @@ -3,4 +3,4 @@ title: Обзор weight: 10 --- -Данный документ представляет собой руководство пользователя Deckhouse Development Platform и является частью эксплуатационной документации продукта Deckhouse Development Platform. +Данный документ представляет собой руководство пользователя Deckhouse Development Platform (DDP) и является частью эксплуатационной документации продукта. diff --git a/content/documentation/user/properties.ru.md b/content/documentation/user/properties.ru.md index 37593e36..db3bbb79 100644 --- a/content/documentation/user/properties.ru.md +++ b/content/documentation/user/properties.ru.md @@ -4,22 +4,22 @@ title: Параметры Для каждого ресурса, действия или сценария администратор платформы может добавить неограниченное количество параметров одного из следующих типов: -* **Array** - список значений -* **Boolean** - булево значение -* **Date** - дата -* **JSON** - текст в JSON формате -* **Entities** - сущность, один из параметров которой можно выбрать в качестве значения -* **Enum** - перечисление значений с ключом и отображаемым значением -* **List** - список значений с возможностью выбора одного из них -* **Markdown** - текст в Markdown формате -* **Number** - число -* **Object** - произвольный объект в JSON формате -* **Percentage** - процент -* **String** - строка -* **YAML** - текст в YAML формате -* **Teams** - команды -* **URL** - строка в формате URL -* **Users** - пользователи +* «Array» — список значений; +* «Boolean» — булево значение; +* «Date» — дата; +* JSON — текст в JSON-формате; +* «Entities» — сущность, один из параметров которой можно выбрать в качестве значения; +* «Enum» — перечисление значений с ключом и отображаемым значением; +* «List» — список значений с возможностью выбора одного из них; +* Markdown — текст в Markdown-формате; +* «Number» — число; +* «Object» — произвольный объект в JSON-формате; +* «Percentage» — процент; +* «String» — строка; +* YAML — текст в YAML-формате; +* «Teams» — команды; +* `URL` — строка в формате URL; +* «Users» — пользователи. ## Ресурсы @@ -29,44 +29,44 @@ title: Параметры ### Синхронизация параметров ресурса -По различным причинам у сущностей могут появиться параметры, которых нет у ресурса. Для того, чтобы удалить подобные параметры доступна кнопка "Синхронизировать параметры" в меню ресурса. +По различным причинам у сущностей могут появиться параметры, которых нет у ресурса. Для того чтобы удалить подобные параметры, доступна кнопка «Синхронизировать параметры» в меню ресурса. При синхронизации параметров: -* Для каждого параметра ресурса будет получен его идентификатор. -* Для каждой сущности ресурса будут получен список ее параметров. -* Те параметры сущности, название которых не соответствует ни одному из идентификаторов параметров ресурса, будут удалены из спецификации сущности. +* для каждого параметра ресурса будет получен его идентификатор; +* для каждой сущности ресурса будет получен список её параметров; +* те параметры сущности, название которых не соответствует ни одному из идентификаторов параметров ресурса, будут удалены из спецификации сущности. ## Действия и сценарии -Для каждого действия и сценария задается пользовательская форма, состоящая из параметров, которые пользователь должен заполнить при запуске. +Для каждого действия и сценария задаётся пользовательская форма, состоящая из параметров, которые пользователь должен заполнить при запуске. ## Ограничения -Идентификатор кажого параметра должен: +Идентификатор каждого параметра должен: -* Содержать символы `a-z`, `A-Z`, цифры, либо подчеркивания -* Не начинаться с цифры +* содержать символы `a-z`, `A-Z`, цифры либо подчёркивания; +* не начинаться с цифры. ## Конфигурация -* **Редактируемый параметр** - для каждого параметра можно настроить разрешение, либо запрет редактирования пользователем. В случае запрета редактирования пользователь при запуске действий или сценариев не сможет изменить значение параметра, то есть всегда будет использоваться значение по умолчанию. -* **Обязательный параметр** - каждый параметр может быть обязательным, либо опциональным. Значение обязательного параметра не может быть пустым при запуске действий или сценариев. При этом значение опционального параметра может оставаться пустым без влияния на работоспособность действия. -* **Скрытый параметр** - скрытый параметр не отображается в таблицах и карточках сущностей, а также при запуске действий и сценариев. +* «Редактируемый параметр» — для каждого параметра можно настроить разрешение либо запрет редактирования пользователем. В случае запрета редактирования пользователь при запуске действий или сценариев не сможет изменить значение параметра, то есть всегда будет использоваться значение по умолчанию. +* «Обязательный параметр» — каждый параметр может быть обязательным либо опциональным. Значение обязательного параметра не может быть пустым при запуске действий или сценариев. При этом значение опционального параметра может оставаться пустым без влияния на работоспособность действия. +* «Скрытый параметр» — скрытый параметр не отображается в таблицах и карточках сущностей, а также при запуске действий и сценариев. ## Типы параметров ### Date -Параметр типа "Date" может принимать значение даты с определенным пользователем форматом. При этом в спецификации значение всегда хранится в формате ISO 8601 (`YYYY-MM-DDTHH:mm:ss.sssZ`). +Параметр типа «Date» может принимать значение даты с определённым пользователем форматом. При этом в спецификации значение всегда хранится в формате ISO 8601 (`YYYY-MM-DDTHH:mm:ss.sssZ`). #### Конфигурация параметра -* Формат - настройка отображения даты. Если формат не задан явно, то используется формат по умолчанию: `YYYY-MM-DDTHH:mm:ss.sssZ`. Описание конфигурации формата доступно по [ссылке](https://day.js.org/docs/en/display/format). Настройка формата влияет на: +* «Формат» — настройка отображения даты. Если формат не задан явно, то используется формат по умолчанию: `YYYY-MM-DDTHH:mm:ss.sssZ`. Описание конфигурации формата доступно в [документации Day.js](https://day.js.org/docs/en/display/format). Настройка формата влияет на: * отображение даты в таблицах и карточках сущностей; * значение параметра при запуске действий или сценариев. -* Текущая дата по умолчанию - подстановка текущей даты в качестве значения по умолчанию при редактировании сущностей, а также при запуске действий или сценариев. -* Значение по умолчанию - заранее заданное значение по умолчанию. Не применяется, если активирован переключатель "Текущая дата по умолчанию". +* «Текущая дата по умолчанию» — подстановка текущей даты в качестве значения по умолчанию при редактировании сущностей, а также при запуске действий или сценариев. +* «Значение по умолчанию» — заранее заданное значение по умолчанию. Не применяется, если активирован переключатель «Текущая дата по умолчанию». {{< alert level="info" >}} При запуске действий или сценариев и использовании текущей даты по умолчанию, параметр не должен быть скрытым в пользовательской форме. В противном случае текущая дата подставлена не будет. @@ -76,8 +76,8 @@ title: Параметры ### List -Параметр типа "List" позволяет выбрать одно значение из предопределенного списка. +Параметр типа «List» позволяет выбрать одно значение из предопределённого списка. ### Enum -Параметр типа "Enum" позволяет выбрать один элемент из предопределенного списка. В отличие от типа "List", параметр "Enum" использует пару ключ-значение, где ключ хранится в спецификации, а значение отображается пользователю. Это позволяет изменять отображаемый текст без изменения ключей. +Параметр типа «Enum» позволяет выбрать один элемент из предопределённого списка. В отличие от типа «List», параметр «Enum» использует пару «ключ — значение», где ключ хранится в спецификации, а значение отображается пользователю. Это позволяет изменять отображаемый текст без изменения ключей. diff --git a/content/documentation/user/teams-users.ru.md b/content/documentation/user/teams-users.ru.md index b2c04b91..87c91b90 100644 --- a/content/documentation/user/teams-users.ru.md +++ b/content/documentation/user/teams-users.ru.md @@ -2,15 +2,15 @@ title: Команды и пользователи --- -В платформе существует две встроенные сущности - команды и пользователи. Основным источником данных для авторизации является Dex, установленный в Deckhouse Kubernetes Platform. Создание встроенных пользователей и команд не поддерживается. +В Deckhouse Development Platform (DDP) существует две встроенные сущности — команды и пользователи. Основным источником данных для авторизации является Dex, установленный в Deckhouse Kubernetes Platform. Создание встроенных пользователей и команд не поддерживается. Принадлежность пользователя к командам определяется на основе информации из Dex и обновляется при каждой аутентификации пользователя. Каждый пользователь может состоять в произвольном количестве команд. Принадлежность пользователя к командам определяется на основе групп в Dex. -## Сихронизация +## Синхронизация -При первой авторизации пользователя в платформу для него создается внутренняя учетная запись. Команды пользователя синхронизируются при первой и каждой последующей авторизации пользователя. +При первой авторизации пользователя в платформу для него создаётся внутренняя учётная запись. Команды пользователя синхронизируются при первой и каждой последующей авторизации пользователя. ### Фильтрация групп при синхронизации @@ -20,12 +20,12 @@ title: Команды и пользователи Правила применяются по порядку цепочкой: каждое правило фильтрует результат предыдущего. Пустой список правил означает отсутствие фильтрации — синхронизируются все группы. -**Режимы правил:** +Режимы правил: -- **Включить** — оставить только команды, совпадающие с паттерном. Остальные исключаются. -- **Исключить** — оставить только команды, не совпадающие с паттерном. Совпадающие исключаются. +- «Включить» — оставить только команды, совпадающие с паттерном. Остальные исключаются. +- «Исключить» — оставить только команды, не совпадающие с паттерном. Совпадающие исключаются. -**Паттерн** задаётся в виде регулярного выражения (regex). Например: +«Паттерн» задаётся в виде регулярного выражения (regex). Например: - `^dev-.*` — группы, начинающиеся с `dev-`; - `^team-(frontend|backend)$` — группы `team-frontend` и `team-backend`; @@ -41,6 +41,8 @@ title: Команды и пользователи ### Последняя активность -Время последней активности пользователя в платформе. Отображается в таблице пользователей в разделе «Администрирование» → «Пользователи». Обновляется при авторизации, либо при автоматической ротации JWT токена пользователя (интервал ротации зависит от конфигурации Dex и по умолчанию равен 10 минутам). +Время последней активности пользователя в платформе. Отображается в таблице пользователей в разделе «Администрирование» → «Пользователи». Обновляется при авторизации, либо при автоматической ротации JWT-токена пользователя (интервал ротации зависит от конфигурации Dex и по умолчанию равен 10 минутам). -> Время последней активности не обновляется при использовании API-токена, выписанного пользователем, либо при каких-либо действиях пользователя в платформе в интервале между автоматическими ротациями JWT токена. +{{< alert level="info" >}} +Время последней активности не обновляется при использовании API-токена, выписанного пользователем, либо при каких-либо действиях пользователя в платформе в интервале между автоматическими ротациями JWT-токена. +{{< /alert >}} diff --git a/content/documentation/user/templating.ru.md b/content/documentation/user/templating.ru.md index 910a1dc1..28fc1f38 100644 --- a/content/documentation/user/templating.ru.md +++ b/content/documentation/user/templating.ru.md @@ -3,14 +3,16 @@ title: Шаблонизация description: Шаблоны Go template в DDP, встроенные функции и sprig, глобальные и командные переменные, контексты действия, сущности, процесса и сценария, хранилище процесса. --- -Платформа поддерживает шаблонизацию на базе [Go template](https://developer.hashicorp.com/nomad/docs/reference/go-template-syntax): выражения в фигурных скобках подставляются в полях конфигурации, где это предусмотрено (действия, виджеты, источники данных и т.д.). Ниже — встроенные функции и контекстные переменные (`{{ .property.* }}`, `{{ .entity.* }}` и другие). +Deckhouse Development Platform поддерживает шаблонизацию на базе [Go template](https://developer.hashicorp.com/nomad/docs/reference/go-template-syntax): выражения в фигурных скобках подставляются в полях конфигурации, где это предусмотрено (действия, виджеты, источники данных и т.д.). Ниже — встроенные функции и контекстные переменные (`{{ .property.* }}`, `{{ .entity.* }}` и другие). Помимо стандартных функций доступны: * Встроенные функции платформы. * Функции библиотеки [sprig](https://masterminds.github.io/sprig/). -> Функции библиотеки [sprig](https://masterminds.github.io/sprig/) не поддерживаются в источниках данных. +{{< alert level="info" >}} +Функции библиотеки [sprig](https://masterminds.github.io/sprig/) не поддерживаются в источниках данных. +{{< /alert >}} ## Встроенные функции @@ -363,7 +365,9 @@ description: Шаблоны Go template в DDP, встроенные функц - `slug` — идентификатор набора глобальных переменных. - `key` — ключ переменной, значение которой необходимо подставить. -> Глобальные переменные хранятся в базе данных DDP в открытом виде, их значение может быть получено пользователями через веб-интерфейс. Не рекомендуется помещать конфиденциальные данные в глобальные переменные. +{{< alert level="warning" >}} +Глобальные переменные хранятся в базе данных DDP в открытом виде, их значение может быть получено пользователями через веб-интерфейс. Не рекомендуется помещать конфиденциальные данные в глобальные переменные. +{{< /alert >}} ### Настройка глобальных переменных @@ -441,9 +445,9 @@ description: Шаблоны Go template в DDP, встроенные функц Формат ответа смотрите в документации по конкретному действию или в интерфейсе DDP: 1. Откройте меню действия (кнопка с тремя точками в карточке действия). -1. Выберите пункт `Запуски действия`. +1. Выберите пункт «Запуски действия». 1. Откройте конфигурацию одного из запусков действия. -1. Найдите в таблице колонку **Response**. +1. Найдите в таблице колонку «Response». Примеры использования: @@ -453,7 +457,9 @@ description: Шаблоны Go template в DDP, встроенные функц {{ .response.headers.auth }} // Значение заголовка авторизации ``` -> **Внимание.** Контекст `{{ .response.* }}` может использоваться только в полях, описывающих правила обновления сущности после запуска действия. +{{< alert level="warning" >}} +Контекст `{{ .response.* }}` может использоваться только в полях, описывающих правила обновления сущности после запуска действия. +{{< /alert >}} ## Учётные данные @@ -481,7 +487,7 @@ description: Шаблоны Go template в DDP, встроенные функц {{ .credentials.accessKeyId }} // Access Key ID для S3 {{ .credentials.secretAccessKey }} // Secret Access Key для S3 {{ .credentials.apiKey }} // API ключ -{{ .credentials.bearerToken }} // Bearer токен +{{ .credentials.bearerToken }} // Bearer-токен ``` ## Сущность (entity) @@ -597,7 +603,7 @@ description: Шаблоны Go template в DDP, встроенные функц где: - `store` — указывает на то, что идёт обращение к хранилищу процесса. -- `key` — ключ в хранилище, под которым сохранено значение (то же имя, что в поле **Ключ в хранилище** в правилах записи; в примерах ниже — `projectId`, `orderRef`). +- `key` — ключ в хранилище, под которым сохранено значение (то же имя, что в поле «Ключ в хранилище» в правилах записи; в примерах ниже — `projectId`, `orderRef`). Особенности использования: