diff --git a/.github/workflows/deploy-dev.yaml b/.github/workflows/deploy-dev.yaml index 9bfca9b..65626c2 100644 --- a/.github/workflows/deploy-dev.yaml +++ b/.github/workflows/deploy-dev.yaml @@ -77,7 +77,7 @@ jobs: projects/data/6db2f1ee-9b6f-4f4f-8381-2fb43060478a/github/registry_host DECKHOUSE_DEV_REGISTRY_HOST | DECKHOUSE_DEV_REGISTRY_HOST ; projects/data/101ceaca-97cd-462f-aed5-070d9b9de175/dev-registry/writetoken login | DECKHOUSE_DEV_REGISTRY_USER ; projects/data/101ceaca-97cd-462f-aed5-070d9b9de175/dev-registry/writetoken password | DECKHOUSE_DEV_REGISTRY_PASSWORD ; - projects/data/6db2f1ee-9b6f-4f4f-8381-2fb43060478a/github/documentation_deploy_secret KUBECONFIG_BASE64_DEV | KUBECONFIG_BASE64_DEV ; + projects/data/6db2f1ee-9b6f-4f4f-8381-2fb43060478a/github/documentation_deploy_secret KUBECONFIG_BASE64_DEV_25 | KUBECONFIG_BASE64_DEV ; - name: Check dev registry credentials id: check_dev_registry @@ -107,8 +107,8 @@ jobs: env: ${{ steps.env.outputs.env }} env: WERF_REPO: ${{ steps.check_dev_registry.outputs.web_registry_path }} - WERF_SET_URL: "global.url=deckhouse.${{ steps.env.outputs.env }}.flant.com" - WERF_SET_URL_RU: "global.url_ru=deckhouse.ru.${{ steps.env.outputs.env }}.flant.com" + WERF_SET_URL: "global.url=deckhouse.${{ steps.env.outputs.env }}.flant.dev" + WERF_SET_URL_RU: "global.url_ru=deckhouse-ru.${{ steps.env.outputs.env }}.flant.dev" - name: Update comment - deployment succeeded if: success() && steps.comment.outputs.result @@ -124,8 +124,8 @@ jobs: } const repoName = context.repo.repo; const appName = repoName.startsWith('website-') ? repoName.replace(/^website-/, '') : repoName; - const urlEn = `https://deckhouse.${env}.flant.com/products/${appName}/documentation/`; - const urlRu = `https://deckhouse.ru.${env}.flant.com/products/${appName}/documentation/`; + const urlEn = `https://deckhouse.${env}.flant.dev/products/${appName}/documentation/`; + const urlRu = `https://deckhouse-ru.${env}.flant.dev/products/${appName}/documentation/`; await github.rest.issues.updateComment({ owner: context.repo.owner, diff --git a/.helm/templates/10-cm.yaml b/.helm/templates/10-cm.yaml index bf2de54..431a740 100644 --- a/.helm/templates/10-cm.yaml +++ b/.helm/templates/10-cm.yaml @@ -52,7 +52,7 @@ data: "deckhouse.ru" "ru"; "*.deckhouse.ru" "ru"; # for test environments - "deckhouse.ru.*" "ru"; + "deckhouse-ru.*" "ru"; default "en"; } diff --git a/.helm/templates/20-ingress.yaml b/.helm/templates/20-ingress.yaml index d8e679b..c395766 100644 --- a/.helm/templates/20-ingress.yaml +++ b/.helm/templates/20-ingress.yaml @@ -33,7 +33,7 @@ spec: {{- if eq $.Values.werf.env "production" }} secretName: star-{{ .URL | replace "." "-" }} {{- else }} - secretName: tls-{{ .URL }} + secretName: {{ pluck $.Values.werf.env $.Values.wildCertificateSecret | first | default $.Values.wildCertificateSecret._default }} {{- end }} rules: - host: {{ .URL }} diff --git a/.helm/values.yaml b/.helm/values.yaml index 7bb0f9d..6c64ea7 100644 --- a/.helm/values.yaml +++ b/.helm/values.yaml @@ -13,6 +13,10 @@ certificateClusterIssuer: _default: letsencrypt production: letsencrypt-nginx +wildCertificateSecret: + _default: wildcard-test-flant-dev + web-stage: wildcard-stage-flant-dev + resources: requests: memory: diff --git a/.werf/nginx-local.conf b/.werf/nginx-local.conf index b25bad4..2ba29cb 100644 --- a/.werf/nginx-local.conf +++ b/.werf/nginx-local.conf @@ -9,7 +9,15 @@ events { } http { + resolver 127.0.0.11 valid=30s ipv6=off; + resolver_timeout 30s; proxy_cache_path /cache keys_zone=dcache:10m max_size=200m inactive=30d; + + # Global timeout settings + keepalive_timeout 65; + client_body_timeout 60s; + client_header_timeout 60s; + send_timeout 60s; log_format json_combined escape=json '{ "time_local": "$time_local", ' '"host": "$host", ' @@ -36,7 +44,7 @@ http { hostnames; ".deckhouse.ru" "ru"; # for test environments - ".deckhouse.ru.*" "ru"; + ".deckhouse-ru.*" "ru"; "ru.localhost" "ru"; default "en"; } @@ -59,6 +67,11 @@ http { default "deckhouse.ru"; } + map $http_upgrade $connection_upgrade { + default upgrade; + '' close; + } + upstream deckhouse_io { server deckhouse.io:443; } @@ -67,6 +80,16 @@ http { server deckhouse.ru:443; } + upstream hugo_1313 { + zone hugo_1313 64k; + server hugo:1313 resolve max_fails=0; + } + + upstream hugo_1314 { + zone hugo_1314 64k; + server hugo:1314 resolve max_fails=0; + } + server { root /app; index index.html; @@ -101,27 +124,46 @@ http { proxy_pass $publicdocupstream; } - location ~* /products/development-platform/(livereload|documentation/).*$ { + # Specific location for livereload WebSocket endpoint + location ~* ^.*/(livereload|livereload\.js) { + # Don't retry WebSocket connections - they can't be retried + proxy_next_upstream off; + proxy_next_upstream_timeout 0; + proxy_next_upstream_tries 1; + proxy_redirect off; - proxy_intercept_errors on; + proxy_intercept_errors off; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Original-URI $request_uri; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; - # WebSocket support for livereload + proxy_connect_timeout 10s; + proxy_send_timeout 3600s; + proxy_read_timeout 3600s; + + proxy_buffering off; + proxy_request_buffering off; + + # WebSocket support - ensure proper headers proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; - proxy_set_header Connection "upgrade"; + proxy_set_header Connection $connection_upgrade; + proxy_set_header X-Forwarded-Proto $scheme; + proxy_set_header X-Forwarded-Host $host; proxy_pass http://$hugo_upstream; } - } - upstream hugo_1313 { - server hugo:1313; - } - upstream hugo_1314 { - server hugo:1314; + location ~* ^/products/development-platform/documentation/.*$ { + proxy_redirect off; + proxy_intercept_errors on; + proxy_set_header Host $host; + proxy_set_header X-Real-IP $remote_addr; + proxy_set_header X-Original-URI $request_uri; + proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; + + proxy_pass http://$hugo_upstream; + } } } diff --git a/README.md b/README.md index 7a12b6e..914536a 100644 --- a/README.md +++ b/README.md @@ -2,6 +2,12 @@ This is the source for the Deckhouse Development Platform documentation website. +The project uses [Hugo](https://gohugo.io/) SSG and the [hugo-web-product-module](https://github.com/deckhouse/hugo-web-product-module/) module for a theme. + +Read [`hugo-web-product-module` README.md](https://github.com/deckhouse/hugo-web-product-module/blob/main/README.md) for information about content markup and other details. + +## How to run the documentation site locally + To run locally: 1. Install werf and docker. 1. Run: @@ -11,5 +17,3 @@ To run locally: ``` 1. Open `http://localhost/products/development-platform/documentation/` in your browser (for the english version) or `http://ru.localhost/products/development-platform/documentation/` (for the russian version). - -The project uses the [hugo-web-product-module](https://github.com/deckhouse/hugo-web-product-module/). diff --git a/content/documentation/admin/actions/overview.ru.md b/content/documentation/admin/actions/overview.ru.md index c9381e0..60c30dc 100644 --- a/content/documentation/admin/actions/overview.ru.md +++ b/content/documentation/admin/actions/overview.ru.md @@ -3,21 +3,22 @@ title: Обзор weight: 10 --- -Действия — механизм, позволяющий пользователям платформы взаимодействовать с внешними по отношению к платформе инфраструктурными сервисами. Например: +Действия — это механизм платформы, предназначенный для выполнения операций во внешних инфраструктурных системах и сервисах, находящихся за пределами платформы. +С помощью действий можно, например, создавать: -- Создавать в Gitlab проекты, переменные, ветки либо теги для проектов. -- Создавать ресурсы в Kubernetes. -- Создавать секреты в Deckhouse Stronghold, либо в HashiCorp Vault. -- Создавать проекты в SonarQube, DefectDojo, и других системах. -- Создавать топики и ACL в Kafka. +- проекты, переменные, ветки либо теги для проектов в Gitlab. +- ресурсы в Kubernetes. +- секреты в Deckhouse Stronghold, либо в HashiCorp Vault. +- проекты в SonarQube, DefectDojo, и других системах. +- топики и ACL в Kafka. Каждое действие может быть привязано к одному или нескольким ресурсам и может быть запущено для любой сущности данных ресурсов. -## Конфигурация +## Конфигурация действия ### Основная информация -Для каждого действия при создании или изменении указывается основная информация: +Для каждого действия, при его создании или изменении, указывается основная информация: - **Название** (обязательно) — название действия в произвольном формате. - **Идентификатор** (обязательно) — идентификатор действия. Генерируется автоматически из названия. @@ -32,42 +33,41 @@ weight: 10 #### Параметры -В разделе «Пользовательская форма» указываются параметры действия, которые будут доступны для заполнения при запуске действия. Типы параметров описаны в документации в разделе «Параметры». +В разделе «Пользовательская форма» указываются параметры, которые будут доступны для заполнения при запуске действия. Типы параметров описаны в документации в разделе [«Параметры»](../../user/properties/). Для каждого параметра доступен выбор следующих опций: -- **Редактируемый** — значение редактируемых параметров можно изменять при запуске действия. В случае, если параметр нередактируемый, изменение его значения при запуске действия будет недоступно. -- **Обязательный** — обязательные параметры, значение которых необходимо заполнить при запуске действия. -- **Скрытый** — скрытые параметры не будут появляться в пользовательской форме при запуске действия. +- **Редактируемый** — позволяет изменить значение параметра при запуске действия. Если опция отключена, значение параметра изменить нельзя. +- **Обязательный** — требует указания значения при запуске действия. +- **Скрытый** — параметр не отображается в пользовательской форме при запуске действия. Для каждого параметра можно задать значение по умолчанию, которое будет подставляться в пользовательскую форму при запуске действия. {{< alert level="info" >}} -Для нередактируемых или скрытых параметров рекомендуется всегда указывать значение по умолчанию, так как у пользователя, запускающего действие, нет возможности изменить их значения. +Для нередактируемых или скрытых параметров рекомендуется всегда указывать значение по умолчанию, так как при запуске действия пользователь не может их изменить. {{< /alert >}} -Описание каждого параметра будет отображаться при запуске действия при нажатии на кнопку со значком «info». Поэтому рекомендуется всегда заполнять описание параметра для упрощения понимания, зачем он необходим. +Описание каждого параметра будет отображаться при запуске действия при нажатии на кнопку со значком «info». Заполнение описаний рекомендуется, так как они упрощают понимание назначения параметров и снижают риск ошибок при запуске. В качестве значений для пользовательской формы возможно использование шаблонных функций [Go template](https://developer.hashicorp.com/nomad/tutorials/templates/go-template-syntax). Например, выражение `{{ .entity.name }}`, заданное в качестве значения параметра, будет означать, что при запуске действия подставится название сущности, для которой запускается действие. #### Условия параметров -Параметры могут быть скрыты или показаны в пользовательской форме в зависимости от значения другого параметра типа `Boolean`. Настройка скрытия или показа параметров осуществляется в разделе «Условия параметров». +Параметры могут быть скрыты или показаны в пользовательской форме в зависимости от значения параметра типа `Boolean`. Настройка скрытия или показа параметров осуществляется в разделе «Условия параметров». -### Backend +### Бэкенд #### Тип -Backend для действия может быть одного двух типов: +Действие может выполняться с использованием одного из двух типов бэкенда: - **Встроенный (BuiltIn)** — основная логика действия выполняется внутри платформы. -- **Webhook** — основная логика действия выполняется сторонным сервисом, куда отправляется webhook. -#### Встроенный Backend + > При выборе встроенного бэкенда необходимо указать конкретный тип встроенного действия. В зависимости от выбранного типа платформа автоматически формирует пример тела запроса и определяет перечень учетных данных, необходимых для выполнения действия. -При выборе встроенного backend будет предложено указать, какой именно встроенный backend должен использоваться. В зависимости от этого будет сгенерирован пример тела запроса действия и учетные данные, которые необходимы для запуска. +- **Вебхук (Webhook)** — основная логика действия выполняется внешним сервисом, которому платформа отправляет HTTP-запрос. -#### Маскировать поля действия +#### Маскирование полей действия Для каждого действия можно настроить маскировку полей, содержащих потенциально конфиденциальную информацию. @@ -79,19 +79,20 @@ Backend для действия может быть одного двух тип #### Количество перезапусков -В случае, если действие завершилось неуспешно, оно может быть автоматически перезапущено. Параметр **количество перезапусков** задает максимальное количество автоматических перезапусков действия. +Если выполнение действия завершается с ошибкой, платформа может автоматически выполнить повторные попытки. Параметр **количество перезапусков** задает максимальное количество автоматических перезапусков действия. #### Базовая задержка (сек.) Параметр **базовая задержка** задает интервал между попытками перезапуска действия. Интервал увеличивается при каждом перезапуске, например, если базовая задержка задана в 2 секунды, то первая попытка перезапуска действия будет через 2 секунды, вторая попытка через 4 секунды, третья - через 8 секунд и так далее. -#### Пример тела запроса +#### Тело запроса -Каждое действие отправляет HTTP-запрос на встроенный бэкенд, либо на URL webhook backend. В подавляющем большинстве случаев запрос должен содержать тело, в котором описывается спецификация данного запроса. +Каждое действие отправляет HTTP-запрос на встроенный бэкенд, либо на URL вебхука бэкенда. +В большинстве случаев запрос должен содержать тело, в котором описывается спецификация данного запроса. -Для встроенных backend при редактировании действия доступен пример тела запроса. +Для встроенного бэкенда при редактировании действия доступен пример тела запроса. -#### Тело запроса +#### Пример тела запроса В тело запроса действия могут быть подставлены параметры из пользовательской формы в формате [Go template](https://developer.hashicorp.com/nomad/tutorials/templates/go-template-syntax) с использованием синтаксиса YAML. @@ -105,25 +106,27 @@ project_id: {{ .project_id }} #### Итоговое тело запроса -Поле **итоговое тело запроса** показывает, как будет выглядеть запрос после форматирования. При валидном JSON будет работать подсветка синтаксиса. При отсутствии подсветки синтаксиса рекомендуется обратить внимание на корректность формирования тела запроса. +Поле **итоговое тело запроса** показывает, как будет выглядеть запрос после форматирования. При валидном JSON будет работать подсветка синтаксиса. При отсутствии подсветки обратите внимание на корректность формирования тела запроса. #### URL -Для любого webhook действия в поле **URL** указывается URL стороннего backend, на который будет отправлен запрос. +Для выполнения любого действия вебхука, в поле **URL** необходимо указать URL внешнего бэкенда, на который будет отправлен запрос. Для встроенных действий в поле **URL** может указываться URL инфраструктурного сервиса, с которым будет происходить взаимодействие, либо данное поле может оставаться пустым. Подробности указаны в описании конкретных встроенных действий. #### Выключить проверку SSL -Параметр определяет, будет ли проверяться SSL-сертификат backend при выполнении webhook действия, либо SSL-сертификат инфраструктурного сервиса с которым происходит взаимодействие при выполнении встроенного действия. В случае использования самоподписных и/или недоверенных сертификатов параметр должен быть активирован. +Параметр определяет, будет ли проверяться SSL-сертификат бэкенда при выполнении вебхук-действия либо SSL-сертификат инфраструктурного сервиса, с которым происходит взаимодействие при выполнении встроенного действия. + +При использовании самоподписных и (или) недоверенных сертификатов параметр должен быть активирован. #### Метод -HTTP-метод, который будет использоваться при запросе на webhook backend. Для встроенных действий метод определяется автоматически в зависимости от типа действия. +HTTP-метод, который будет использоваться при запросе на вебхук бэкенда. Для встроенных действий метод определяется автоматически в зависимости от типа действия. #### Headers -HTTP-хедеры в формате ключ-значение, которые будут добавлены в запрос на webhook backend. Для встроенных действий хедеры добавляются автоматически в зависимости от типа действия. +Headers — HTTP-заголовки в формате ключ-значение, которые будут добавлены в запрос к вебхуку бэкенда. Для встроенных действий заголовки добавляются автоматически в зависимости от типа действия. ### Обновление сущности @@ -142,24 +145,25 @@ HTTP-хедеры в формате ключ-значение, которые б Если после создания проекта в GitLab необходимо сразу заполнить параметр `repository_id` сущности, для которой этот проект был создан, в правилах обновления следует использовать следующую конструкцию: -* Источник: `{{ .response.id }}` -* Параметр сущности: `repository_id` +* Источник: `{{ .response.id }}`. +* Параметр сущности: `repository_id`. #### Создание связей сущностей Если опция **создание связей сущностей** включена, то после выполнения действия для выбранной сущности будут автоматически созданы новые связи согласно заданным правилам. Для каждого ресурса можно определить свой набор правил. -**Важно:** при создании связи ресурсов задаётся родительский и дочерний ресурс. при указании идентификатора родительской сущности, поиск будет произведен только по сущностям из родительского ресурса. Если указать идентификатор дочерней сущности, то поиск будет произведен только по сущностям дочернего ресурса. В рамках создания правила необходимо указывать либо родительский идентификатор, либо дочерний. При одновременном указании в рамках одного правила обоих идентификаторов, поиск будет производиться только по родительскому ресурсу. +При создании связи задаются родительский и дочерний ресурсы. Поиск сущностей выполняется в зависимости от указанного идентификатора: по родительскому или дочернему ресурсу. +В одном правиле следует указывать только один идентификатор. При одновременном указании родительского и дочернего идентификаторов поиск выполняется по родительскому ресурсу. ### Безопасность #### Подтверждение перед запуском -Действиям можно назначать подтверждающих и их количество. В случае, если действие необходимо подтвердить, оно не будет выполняться до того момента, пока не будет собрано необходимое количество подтверждающих. +Для действий может быть настроено обязательное подтверждение и количество подтверждающих перед запуском. В этом случае действие не будет выполнено до тех пор, пока не будет получено заданное количество подтверждений от заданных пользователей. Посмотреть текущее количество подтвердивших и список тех, от кого ожидается подтверждение, можно в таблице запуска действий для каждой сущности. -При этом, если подтверждение ожидается от конкретного пользователя, то данному пользователю будет выведено уведомление в верхней панели (иконка колокольчика). +Если подтверждение требуется от конкретного пользователя, ему будет отправлено уведомление в интерфейсе платформы. #### Учетная запись для запуска действия @@ -169,21 +173,31 @@ HTTP-хедеры в формате ключ-значение, которые б #### Учетные данные -Для встроенных действий заранее известно, какие учетные данные понадобятся для их запуска. Идентификаторы этих учетных данных подгружаются при выбора встроенного backend. Для каждого из идентификаторов необходимо выбрать, какой тип учетных данных будет использоваться. +Для встроенных действий платформа заранее определяет перечень необходимых учетных данных. Идентификаторы этих учетных данных подгружаются при выборе встроенного бэкенда. Для каждого из идентификаторов необходимо выбрать, какой тип учетных данных будет использоваться. -Для webhook действий обращение к учетным данным возможно в теле запроса с использованием конструкции `{{ .credentials.<идентификатор типа учетных данных> }}`. +Для вебхук-действий обращение к учетным данным возможно в теле запроса с использованием конструкции `{{ .credentials.<идентификатор типа учетных данных> }}`. ## Запуски действий ### Записи запусков действий -При каждом запуске действия создается запись, в которой указан инициатор запуска, статус выполнения и подробный лог запуска. Записи запущенных действий для каждой сущности можно посмотреть в карточке сущности во вкладке `Запуски действий`. Если для запуска действия необходимо подтверждение, то подтвердить запуск также можно во вкладке `Запуски действий`. +При каждом запуске действия создается запись, в которой указан инициатор запуска, статус выполнения и подробный лог. Записи запущенных действий для каждой сущности можно посмотреть в карточке сущности на вкладке «Запуски действий». Если для запуска действия необходимо подтверждение, оно выполняется в этой же вкладке. + +Запись о запуске действия можно удалить, либо перезапустить действие. При перезапуске создается новая запись запуска. -Каждую запись о запуске действия можно удалить, либо перезапустить действие. При этом при перезапуске будет создана новая запись. +### Логирование запусков + +Для каждого запуска действия создается запись в БД, содержащая полный лог выполнения. + +Параметр `actions.logging.enabled` в конфигурационном файле DDP позволяет выводить в stdout, либо скрывать логи запуска действия. При значении `true` логи запуска будут выводиться в stdout, при значении `false` логи выводиться не будут. + +{{< alert level="info" >}} +Записи в БД с полным логом запуска действия создаются независимо от значения параметра `actions.logging.enabled`. +{{< /alert >}} ### Статусы действий -Для каждого запуска действия создается запись, которая может иметь один из следующих статусов: +Для каждого запуска действия создается запись о его статусе. Статусы могут быть следующими: - **Created** — запись создана, но действие еще не было запущено. - **Unapproved** — действие ожидает подтверждения. diff --git a/content/documentation/admin/actions/types.ru.md b/content/documentation/admin/actions/types.ru.md index c1111bc..4e4b3df 100644 --- a/content/documentation/admin/actions/types.ru.md +++ b/content/documentation/admin/actions/types.ru.md @@ -4,7 +4,7 @@ title: Типы действий ## CreateDefectdojoEngagement -CreateDefectdojoEngagement — создает новый engagements в системе DefectDojo. Действие использует DefectDojo API v2. Поддерживаемые параметры соответствуют спецификации API. +CreateDefectdojoEngagement — создаёт новый [Engagement](https://docs.defectdojo.com/en/working_with_findings/organizing_engagements_tests/product_hierarchy/#what-can-an-engagement-represent) в системе DefectDojo. Действие использует DefectDojo API v2. ### Пример запроса @@ -18,7 +18,7 @@ lead: '1' ### Спецификация запроса -Список полей соответствует официальному API DefectDojo, `/api/v2/engagements`: [документация](https://demo.defectdojo.org/api/v2/oa3/swagger-ui/). +Список полей соответствует официальному API DefectDojo, `/api/v2/engagements`, подробнее [в документации Defectdojo](https://demo.defectdojo.org/api/v2/oa3/swagger-ui/). ### Учетные данные @@ -26,7 +26,7 @@ lead: '1' ## CreateDefectdojoProduct -CreateDefectdojoProduct — создает новый продукт в системе DefectDojo. Действие использует DefectDojo API v2. Поддерживаемые параметры соответствуют спецификации API. +CreateDefectdojoProduct — создает новый продукт в системе DefectDojo. Действие использует DefectDojo API v2. ### Пример запроса @@ -38,7 +38,7 @@ prod_type: 1 ### Спецификация запроса -Список полей соответствует официальному API DefectDojo, `/api/v2/products`: [документация](https://demo.defectdojo.org/api/v2/oa3/swagger-ui/). +Список полей соответствует официальному API DefectDojo, `/api/v2/products`, подробнее [в документации Defectdojo](https://demo.defectdojo.org/api/v2/oa3/swagger-ui/). ### Учетные данные @@ -72,13 +72,13 @@ branches: ### Примечание -Для выполнения действия необходимо наличие корректных реквизитов с GitLab token. Этот токен передается через механизм учетных данных и используется для аутентификации при вызове GitLab API (HTTP-заголовок `Private-Token`). +Для выполнения действия необходимо наличие корректных реквизитов GitLab token. Этот токен передается через механизм учетных данных и используется для аутентификации при вызове GitLab API (HTTP-заголовок `Private-Token`). Действие осуществляет POST-запрос по URL: `/api/v4/projects/:id/repository/branches`. В случае успешного создания проекта GitLab возвращает информацию о созданных ветках. ## CreateGitlabGroupVariables -CreateGitlabGroupVariables — создает переменные на уровне группы в GitLab. +CreateGitlabGroupVariables — создает переменные (variables) на уровне группы в GitLab. ### Пример запроса @@ -96,7 +96,7 @@ variables: | group_id | **обязательно** | Идентификатор группы, в котором необходимо создать переменные | | variables | **обязательно** | Список создаваемых переменных | -Список полей для variables соответствует официальному GitLab Group-level Variables API, `/groups/:id/variables`: [документация](https://docs.gitlab.com/api/group_level_variables/#create-variable). +Список полей для переменных соответствует официальному GitLab Group-level Variables API, `/groups/:id/variables`, подробнее [в документации Gitlab](https://docs.gitlab.com/api/group_level_variables/#create-variable). ### Учетные данные @@ -110,7 +110,7 @@ variables: ## CreateGitlabMergeRequest -CreateGitlabMergeRequest - создает новый merge request в целевой репозиторий. В данный merge request добавляются файлы, хранящиеся в репозитории источнике. Файлы могут содержать переменные, значение которых будет подставлено в момент создания MR. +CreateGitlabMergeRequest - создает новый Merge Request (MR) в целевом репозитории. В Merge Request добавляются файлы, хранящиеся в репозитории источнике. Файлы могут содержать переменные, значение которых будет подставлено в момент создания MR. ### Пример запроса @@ -148,23 +148,23 @@ values: ### Учетные данные * **password** — пароль (токен) пользователя, от имени которого будет запускаться выполнение действия. -* **username** — username пользователя, от имени которого будет запускаться выполнение действия. +* **username** — имя пользователя, от которого будет запускаться выполнение действия. ### Алгоритм работы Платформа: -1. Клонирует шаблонный репозиторий, который является шаблоном для генерации MR, согласно его ID (**source_project_id**). [Подробнее о шаблонизации](#детали-работы). +1. Клонирует репозиторий-шаблон для генерации MR по его идентификатору (**source_project_id**). Подробнее [о шаблонизации](#детали-работы). 1. Считывает файл `values.yaml`, хранящийся в корне репозитория, и определяет переменные по умолчанию для шаблонизации. -1. Считывает переменные, передаваемые при запуске действия, и делает их merge с переменными из `values.yaml`. Приоритет при merge отдается переменным, передаваемым при запуске действия. +1. Считывает переменные, передаваемые при запуске действия, и объединяет (merge) их с переменными из `values.yaml`. Приоритет отдаётся переменным, передаваемым при запуске действия. 1. Считывает файл `.templateignore` и определяет директории и файлы, исключаемые из шаблонизации. -1. Рендерит из шаблонов файлы, учитывая `values.yaml` и переданные в действие переменные. -1. Изменяет remote репозитория на целевой, согласно его ID (**target_project_id**), и делает git push в целевую ветку (**source_project_branch**), либо в ветку **main**. +1. Рендерит файлы из шаблонов, учитывая `values.yaml` и переданных в действие переменных. +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 token. Этот токен передается через механизм учетных данных и используется для аутентификации при вызове GitLab API (HTTP-заголовок `Private-Token`). Действие осуществляет POST-запрос по URL: `/api/v4/projects/:id/merge_requests`. @@ -189,7 +189,7 @@ namespace_id: '0' |------------------------|------------------|--------------------------------------------------------------------------------------------|-----------------------| | name | **обязательно** | Название проекта, который будет создан в GitLab | - | | path | **обязательно** | URL-совместимый путь проекта. Обычно совпадает с названием, но может отличаться | - | -| default_branch | **обязательно** | Название ветки, которая будет использоваться по умолчанию, например, "main" | - | +| default_branch | **обязательно** | Название ветки, которая будет использоваться по умолчанию, например, «main» | - | | namespace_id | **обязательно** | Идентификатор пространства имен (namespace) в GitLab, в котором будет создан проект | - | | initialize_with_readme | опционально | Флаг, определяющий, нужно ли инициализировать проект с файлом README | false | | description | опционально | Описание проекта, которое будет видно пользователям | - | @@ -200,7 +200,7 @@ namespace_id: '0' ### Примечание -Для выполнения действия необходимо наличие корректных реквизитов с GitLab token. Этот токен передается через механизм учетных данных и используется для аутентификации при вызове GitLab API (HTTP-заголовок `Private-Token`). +Для выполнения действия необходимо наличие корректных реквизитов GitLab token. Токен, содержащий реквизиты, передаётся через механизм учетных данных и используется для аутентификации при вызове GitLab API (HTTP-заголовок `Private-Token`). Действие осуществляет POST-запрос по URL: `/api/v4/projects`, передавая параметры запроса в формате JSON. В случае успешного создания проекта GitLab возвращает данные о вновь созданном проекте. @@ -224,7 +224,7 @@ variables: | project_id | **обязательно** | Идентификатор проекта, в котором необходимо создать переменные | | variables | **обязательно** | Список создаваемых переменных | -Список полей для variables соответствует официальному GitLab Project-level CI/CD variables API, `/projects/:id/variables`: [документация](https://docs.gitlab.com/api/project_level_variables/#create-a-variable) +Список полей для переменных соответствует официальному GitLab Project-level CI/CD variables API, `/projects/:id/variables`, подробнее [в документации Gitlab](https://docs.gitlab.com/api/project_level_variables/#create-a-variable) ### Учетные данные @@ -232,13 +232,13 @@ variables: ### Примечание -Для выполнения действия необходимо наличие корректных реквизитов с GitLab token. Этот токен передается через механизм учетных данных и используется для аутентификации при вызове GitLab API (HTTP-заголовок `Private-Token`). +Для выполнения действия необходимо наличие корректных реквизитов GitLab token. Токен, содержащий реквизиты, передаётся через механизм учетных данных и используется для аутентификации при вызове GitLab API (HTTP-заголовок `Private-Token`). Действие осуществляет POST-запрос по URL: `/api/v4/projects/:id/variables`. ## CreateGitlabProjectWebhook -CreateGitlabProjectWebhook — создает webhook в проекте GitLab. +CreateGitlabProjectWebhook — создает вебхук в проекте GitLab. ### Пример запроса @@ -253,14 +253,14 @@ pipeline_events: true ### Спецификация запроса -| Название | Обязательность | Описание | -|----------------------|-----------------|-------------------------------------------------------------------------| -| project_id | **обязательно** | Идентификатор проекта, в котором необходимо создать webhook | -| url | **обязательно** | URL-адрес вебхука | -| push_events | **обязательно** | Запускать вебхук при push в репозиторий | -| issues_events | **обязательно** | Запускать вебхук при создании issue | -| merge_request_events | **обязательно** | Запускать вебхук при создании merge request | -| pipeline_events | **обязательно** | Запускать вебхук при запуске pipeline | +| Название | Обязательность | Описание | +|----------------------|-----------------|------------------------------------------------------------| +| project_id | **обязательно** | Идентификатор проекта, в котором необходимо создать вебхук | +| url | **обязательно** | URL-адрес вебхука | +| push_events | **обязательно** | Запускать вебхук при push в репозиторий | +| issues_events | **обязательно** | Запускать вебхук при создании Issue | +| merge_request_events | **обязательно** | Запускать вебхук при создании Merge rRequest | +| pipeline_events | **обязательно** | Запускать вебхук при запуске Pipeline | ### Учетные данные @@ -268,7 +268,7 @@ pipeline_events: true ### Примечание -Для выполнения действия необходимо наличие корректных реквизитов с GitLab token. Этот токен передается через механизм учетных данных и используется для аутентификации при вызове GitLab API (HTTP-заголовок `Private-Token`). +Для выполнения действия необходимо наличие корректных реквизитов GitLab token. Токен, содержащий реквизиты, передаётся через механизм учетных данных и используется для аутентификации при вызове GitLab API (HTTP-заголовок `Private-Token`). Действие осуществляет POST-запрос по URL: `/api/v4/projects/:id/hooks`. @@ -300,7 +300,7 @@ message: Tag description ### Примечание -Для выполнения действия необходимо наличие корректных реквизитов с GitLab token. Этот токен передается через механизм учетных данных и используется для аутентификации при вызове GitLab API (HTTP-заголовок `Private-Token`). +Для выполнения действия необходимо наличие корректных реквизитов GitLab token. Токен, содержащий реквизиты, передается через механизм учетных данных и используется для аутентификации при вызове GitLab API (HTTP-заголовок `Private-Token`). Действие осуществляет POST-запрос по URL: `/api/v4/projects/:id/repository/tags`. @@ -315,9 +315,9 @@ project_id: '0' tag_name: v1.0.0 name: Release v1.0.0 description: | - ## Изменения - - Новая функция - - Исправления ошибок + ## Изменения: + - Новая функция. + - Исправления ошибок. ``` ### Спецификация запроса @@ -335,7 +335,7 @@ description: | ### Примечание -Для выполнения действия необходимо наличие корректных реквизитов с GitLab token. Этот токен передается через механизм учетных данных и используется для аутентификации при вызове GitLab API (HTTP-заголовок `Private-Token`). +Для выполнения действия необходимо наличие корректных реквизитов GitLab token. Токен, содержащий реквизиты, передается через механизм учетных данных и используется для аутентификации при вызове GitLab API (HTTP-заголовок `Private-Token`). Действие осуществляет POST-запрос по URL: `/api/v4/projects/:id/releases`. @@ -383,66 +383,66 @@ acls: ### Спецификация запроса -| Название | Обязательность | Описание | Возможные значения | Значение по умолчанию | -|-------------------------|------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------|------------------------| -| securityProtocol | **обязательно** | Протокол для подключения к Kafka. [Подробнее](https://kafka.apache.org/documentation/#adminclientconfigs_security.protocol) | PLAINTEXT, SASL_PLAINTEXT, SASL_SSL | - | -| saslMechanism | опционально | Механизм аутентификации, который будет использовать SASL. Обязателен при использовании протокола SASL_PLAINTEXT или SASL_SSL. [Подробнее](https://kafka.apache.org/documentation/#security_sasl_mechanism) | PLAIN, SCRAM-SHA-256, SCRAM-SHA-512 | - | -| acls | **обязательно** | Набор ACL, которые необходимо создать | - | - | -| acls.ops | **обязательно** | Список операций, для которых будет создано правило. | См. список возможных операций | - | -| acls.pattern | **обязательно** | Тип шаблона | См. список возможных pattern | - | -| acls.topics | опционально | Список из названий топиков, для которых применять правило | - | - | -| acls.groups | опционально | Список из названий групп, для которых применять правило | - | - | -| acls.transactional_ids | опционально | Список из ID транзакций, для которых применять правило | - | - | -| acls.tokens | опционально | Список токенов, для которых применять правило | - | - | -| acls.allow | опционально | Список принципалов (user, group), для которых разрешить правило | - | - | -| acls.allow_hosts | опционально | Список хостов, для которых разрешить операцию | - | - | -| acls.deny | опционально | Список принципалов (user, group), для которых запретить правило | - | - | -| acls.deny_hosts | опционально | Список хостов, для которых запретить операцию | - | - | +| Название | Обязательность | Описание | Возможные значения | Значение по умолчанию | +|-------------------------|------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------|------------------------| +| 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.pattern | **обязательно** | Тип шаблона | См. список возможных шаблонов | - | +| acls.topics | опционально | Список из названий топиков, для которых применяется правило | - | - | +| acls.groups | опционально | Список из названий групп, для которых применяется правило | - | - | +| acls.transactional_ids | опционально | Список из ID транзакций, для которых применяется правило | - | - | +| acls.tokens | опционально | Список токенов, для которых применяется правило | - | - | +| acls.allow | опционально | Список принципалов (user, group), для которых разрешается правило | - | - | +| acls.allow_hosts | опционально | Список хостов, для которых разрешается операция | - | - | +| acls.deny | опционально | Список принципалов (user, group), для которых запрещается правило | - | - | +| acls.deny_hosts | опционально | Список хостов, для которых запрещается операция | - | - | ### Учетные данные -* **user** — username пользователя, от имени которого будет запускаться выполнение действия. +* **user** — имя пользователя, от которого будет запускаться выполнение действия. * **password** — пароль пользователя, от имени которого будет запускаться выполнение действия. ### Список возможных паттернов -* ANY -* MATCH -* LITERAL -* PREFIXED +* ANY. +* MATCH. +* LITERAL. +* PREFIXED. ### Список возможных операций -[Документация Kafka](https://kafka.apache.org/39/documentation/#operations_resources_and_protocols) +Подробнее — [в документации Kafka](https://kafka.apache.org) **Topic:** -* ALL -* ALTER -* ALTER_CONFIGS -* CREATE -* DELETE -* DESCRIBE -* DESCRIBE_CONFIGS -* READ -* WRITE +* ALL. +* ALTER. +* ALTER_CONFIGS. +* CREATE. +* DELETE. +* DESCRIBE. +* DESCRIBE_CONFIGS. +* READ. +* WRITE. **Group:** -* ALL -* DELETE -* DESCRIBE -* READ +* ALL. +* DELETE. +* DESCRIBE. +* READ. **TransactionalID:** -* ALL -* DESCRIBE -* WRITE +* ALL. +* DESCRIBE. +* WRITE. **Tokens:** -* DESCRIBE +* DESCRIBE. ## CreateKafkaTopics @@ -465,16 +465,16 @@ topics: | Название | Обязательность | Описание | Возможные значения | |-------------------------|------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------| -| securityProtocol | **обязательно** | Протокол для подключения к Kafka. [Подробнее](https://kafka.apache.org/documentation/#adminclientconfigs_security.protocol) | PLAINTEXT, SASL_PLAINTEXT, SASL_SSL | +| securityProtocol | **обязательно** | Протокол для подключения к Kafka. Подробнее [в документации Kafka](https://kafka.apache.org/documentation/#adminclientconfigs_security.protocol) | PLAINTEXT, SASL_PLAINTEXT, SASL_SSL | | saslMechanism | опционально | Механизм аутентификации, который будет использовать SASL. Обязателен при использовании протокола SASL_PLAINTEXT или SASL_SSL. [Подробнее](https://kafka.apache.org/documentation/#security_sasl_mechanism) | PLAIN, SCRAM-SHA-256, SCRAM-SHA-512 | -| partitions | **обязательно** | Количество разделов (партиций), на которые будет разбит топик | - | +| partitions | **обязательно** | Количество разделов (партиций), на которые будет разделён топик | - | | replication_factor | **обязательно** | Количество копий (реплик) каждой партиции топика, которые необходимо разместить на разных брокерах | - | -| configs | **обязательно** | Конфигурация в формате ключ значение для создаваемых топиков | [Документация](https://kafka.apache.org/documentation/#topicconfigs) | +| configs | **обязательно** | Конфигурация в формате ключ-значение для создаваемых топиков | [Документация](https://kafka.apache.org/documentation/#topicconfigs) | | topics | **обязательно** | Список названий топиков, которые необходимо создать | - | ### Учетные данные -* **user** — username пользователя, от имени которого будет запускаться выполнение действия. +* **user** — имя пользователя, от которого будет запускаться выполнение действия. * **password** — пароль пользователя, от имени которого будет запускаться выполнение действия. ## CreateKafkaUsers @@ -511,12 +511,13 @@ users: ### Учетные данные -* **user** — username пользователя, от имени которого будет запускаться выполнение действия. +* **user** — имя пользователя, от которого будет запускаться выполнение действия. * **password** — пароль пользователя, от имени которого будет запускаться выполнение действия. ## CreateCodeScoringProject -CreateCodeScoringProject — создает новый проект в системе CodeScoring. Действие использует CodeScoring API для регистрации проекта с указанными параметрами: название проекта, URL репозитория, ID VCS системы и опция автоматического запуска SCA-анализа после клонирования репозитория. +CreateCodeScoringProject — создаёт новый проект в системе CodeScoring. +Действие использует CodeScoring API для регистрации проекта с указанными параметрами: название проекта, URL репозитория, ID VCS системы и опция автоматического запуска SCA-анализа после клонирования репозитория ### Пример запроса @@ -529,12 +530,12 @@ run_sca_after_clone: true ### Спецификация запроса -| Название | Обязательность | Описание | -|--------------------|-----------------|--------------------------------------------------------------------------| -| name | **обязательно** | Название проекта в CodeScoring | -| repository | **обязательно** | URL репозитория (например, ) | -| vcs_id | **обязательно** | ID VCS системы в CodeScoring (должен быть больше 0) | -| run_sca_after_clone| опционально | Запускать ли SCA-анализ автоматически после клонирования репозитория | +| Название | Обязательность | Описание | +|--------------------|-----------------|-------------------------------------------------------------------------------| +| name | **обязательно** | Название проекта в CodeScoring | +| repository | **обязательно** | URL репозитория (например, ) | +| vcs_id | **обязательно** | ID VCS системы в CodeScoring (должен быть больше 0) | +| run_sca_after_clone| опционально | Автоматический запуск SCA-анализа после клонирования репозитория | ### Ответ @@ -558,7 +559,7 @@ id: 1 ## CreateKeycloakClient -CreateKeycloakClient — создает нового клиента в Keycloak. +CreateKeycloakClient — создаёт нового клиента в Keycloak. ### Пример запроса @@ -589,12 +590,12 @@ config: ### Учетные данные -* **username** — username пользователя, от имени которого будет запускаться выполнение действия. +* **username** — имя пользователя, от которого будет запускаться выполнение действия. * **password** — пароль пользователя, от имени которого будет запускаться выполнение действия. ## CreateKubernetesResource -CreateKubernetesResource — создает новый ресурс или ресурсы в кластере Kubernetes или обновляет существующие. +CreateKubernetesResource — создаёт новый ресурс или ресурсы в кластере Kubernetes или обновляет существующие. ### Пример запроса @@ -622,7 +623,7 @@ manifests: ## CreateRepositoryFromTemplate -CreateRepositoryFromTemplate — создает новый репозиторий из шаблона в Gitlab. Механизм рендеринга основан на [Go template](https://developer.hashicorp.com/nomad/tutorials/templates/go-template-syntax) и поддерживает все встроенные методы, а также расширения, добавленные в платформу. +CreateRepositoryFromTemplate — создаёт новый репозиторий из шаблона в Gitlab. Механизм рендеринга основан на [Go template](https://developer.hashicorp.com/nomad/tutorials/templates/go-template-syntax) и поддерживает все встроенные методы, а также расширения, добавленные в платформу. ### Пример запроса @@ -657,7 +658,7 @@ values: ### Учетные данные * **password** — пароль (токен) пользователя, от имени которого будет запускаться выполнение действия. -* **username** — username пользователя, от имени которого будет запускаться выполнение действия. +* **username** — имя пользователя, от которого будет запускаться выполнение действия. ### Алгоритм работы @@ -668,13 +669,14 @@ values: 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/tutorials/templates/go-template-syntax), например директория `src/{{ .module }}/utils` при наличии value **module** со значением **example** будет отрендерена в директорию `src/example/utils` в целевом репозитории. +Действие поддерживает шаблонизацию имён директорий и файлов. Для этого необходимо в их название добавить выражение в формате [Go template](https://developer.hashicorp.com/nomad/tutorials/templates/go-template-syntax). +Например директория `src/{{ .module }}/utils` при наличии value **module** со значением **example** будет отрендерена в директорию `src/example/utils` в целевом репозитории. -Если после рендеринга из шаблона содержимое файла будет отсутствовать, то он не будет создан. Например файл с содержимым: +Если после рендеринга из шаблона содержимое файла будет отсутствовать, файл не создаётся. Например файл с содержимым: ```go {{- if .createContent }} @@ -742,23 +744,24 @@ docs/** ### Локальная отладка -Для локальной отладки шаблонов подготовлена утилита **ddp-render-dir**. +Для локальной отладки шаблонов доступна утилита **ddp-render-dir**. Утилита: 1. Создает копию исходной директории. -2. Рендерит файлы в созданной директории аналогично тому, как это делает действие по созданию репозиториев из шаблонов. +1. Выполняет рендеринг файлов в этой директории по тем же правилам, что и действие создания репозиториев из шаблонов. Ключи командной строки для запуска: * **--source-dir** — исходная директория, которую необходимо отрендерить. * **--target-dir** — директория, в которую будет помещен результат рендеринга. * **--values** (опционально) — путь к файлу `values.yaml` с переменными, которые будут использоваться при рендеринге. -* **--ignore-files** (опционально) — список файлов, содержащих пути для для исключения из целевого репозитория. +* **--ignore-files** (опционально) — список файлов, содержащих пути для исключения из целевого репозитория. ## CreateSonarqubeProject -CreateSonarqubeProject — создает новый проект в SonarQube. Действие использует SonarQube Web API для создания проекта с указанными параметрами, такими как ключ (project key), название проекта, главная ветка, параметры определения нового кода (new code definition) и видимость проекта. Аутентификация осуществляется с использованием SonarQube token, который должен быть передан в учетных данных. +CreateSonarqubeProject — создаёт новый проект в SonarQube. +Действие использует SonarQube Web API для создания проекта с указанными параметрами, такими как ключ (project key), название проекта, главная ветка, параметры определения нового кода (new code definition) и видимость проекта. Аутентификация осуществляется с использованием SonarQube token, который должен быть передан в учетных данных. ### Пример запроса @@ -779,7 +782,7 @@ visibility: public | name | **обязательно** | Название проекта, отображаемое в интерфейсе SonarQube | - | - | | mainBranch | опционально | Название главной ветки проекта | - | master | | newCodeDefinitionType | опционально | Метод определения «нового кода» | PREVIOUS_VERSION, NUMBER_OF_DAYS, REFERENCE_BRANCH | - | -| newCodeDefinitionValue | опционально | Значение для определения "нового кода" (например, количество дней, если тип - NUMBER_OF_DAYS) | - | - | +| newCodeDefinitionValue | опционально | Значение для определения «нового кода» (например, количество дней, если тип - NUMBER_OF_DAYS) | - | - | | visibility | опционально | Видимость проекта | private, public | private | ### Учетные данные @@ -788,7 +791,7 @@ visibility: public ## CreateVaultSecret -CreateVaultSecret — создает секрет с одним или несколькими значениями в HashiCorp Vault. +CreateVaultSecret — создаёт секрет с одним или несколькими значениями в HashiCorp Vault. ### Пример запроса @@ -885,7 +888,8 @@ project_id: 0 ### Примечание -Для выполнения действия необходимо наличие корректных реквизитов с GitLab token. Этот токен передается через механизм учетных данных и используется для аутентификации при вызове GitLab API (HTTP-заголовок `Private-Token`). +Для выполнения действия необходимо наличие корректных реквизитов с GitLab token. +Этот токен передается через механизм учетных данных и используется для аутентификации при вызове GitLab API (HTTP-заголовок `Private-Token`). Действие осуществляет DELETE-запрос по URL: `/api/v4/projects/:id`. @@ -969,48 +973,48 @@ acls: ### Учетные данные -* **user** — username пользователя, от имени которого будет запускаться выполнение действия. +* **user** — имя пользователя, от которого будет запускаться выполнение действия. * **password** — пароль пользователя, от имени которого будет запускаться выполнение действия. ### Список возможных pattern -* ANY -* MATCH -* LITERAL -* PREFIXED +* ANY. +* MATCH. +* LITERAL. +* PREFIXED. ### Список возможных операций -[Документация Kafka](https://kafka.apache.org/39/documentation/#operations_resources_and_protocols) +Подробное описание - [в документации Kafka](https://kafka.apache.org/39/documentation/#operations_resources_and_protocols) **Topic:** -* ALL -* ALTER -* ALTER_CONFIGS -* CREATE -* DELETE -* DESCRIBE -* DESCRIBE_CONFIGS -* READ -* WRITE +* ALL. +* ALTER. +* ALTER_CONFIGS. +* CREATE. +* DELETE. +* DESCRIBE. +* DESCRIBE_CONFIGS. +* READ. +* WRITE. **Group:** -* ALL -* DELETE -* DESCRIBE -* READ +* ALL. +* DELETE. +* DESCRIBE. +* READ. **TransactionalID:** -* ALL -* DESCRIBE -* WRITE +* ALL. +* DESCRIBE. +* WRITE. **Token:** -* DESCRIBE +* DESCRIBE. ## DeleteKafkaTopics @@ -1035,7 +1039,7 @@ topics: ### Учетные данные -* **user** — username пользователя, от имени которого будет запускаться выполнение действия. +* **user** — имя пользователя, от которого будет запускаться выполнение действия. * **password** — пароль пользователя, от имени которого будет запускаться выполнение действия. ## DeleteKafkaUsers @@ -1066,7 +1070,7 @@ users: ### Учетные данные -* **user** — username пользователя, от имени которого будет запускаться выполнение действия. +* **user** — имя пользователя, от которого будет запускаться выполнение действия. * **password** — пароль пользователя, от имени которого будет запускаться выполнение действия. ## DeleteKubernetesResource @@ -1090,8 +1094,8 @@ namespace: example | group | **обязательно** | API-группа ресурса. Указывает, к какой группе API относится удаляемый объект | См. определение требуемых Group и Version | | version | **обязательно** | Версия API ресурса | См. определение требуемых Group и Version | | resource_type | **обязательно** | Тип удаляемого ресурса | pods, services, deployments, statefulsets, daemonsets, replicasets, jobs, cronjobs, nodes, namespaces, configmaps, secrets, persistentvolumes, persistentvolumeclaims, limitranges, resourcequotas, horizontalpodautoscalers, ingresses, networkpolicies, serviceaccounts, roles, clusterroles, rolebindings, clusterrolebindings, podsecuritypolicies, storageclasses, volumeattachments, events, endpoints, customresourcedefinitions | -| resource_name | **обязательно** | Название конкретного ресурса, который необходимо удалить | - | -| namespace | **обязательно** | Namespace, в котором находится ресурс | - | +| resource_name | **обязательно** | Название конкретного ресурса, который необходимо удалить | - | +| namespace | **обязательно** | Неймспейс, в котором находится ресурс | - | ### Учетные данные @@ -1099,9 +1103,10 @@ namespace: example ### Определение требуемых Group и Version -Каждому типу ресурса соответствует своя версия и группа. Полный список API-ресурсов с их группами и версиями: [документация Kubernetes](https://kubernetes.io/docs/reference/kubernetes-api/) +Каждому типу ресурса соответствует своя версия и группа. Полный список API-ресурсов с их группами и версиями, подробнее [в документации Kubernetes](https://kubernetes.io/docs/reference/kubernetes-api/) -Если неизвестно, какие требуются Group и Version, можно попробовать подставить актуальные значения. Есть несколько вариантов как их посмотреть: +Если неизвестно, какие требуются Group и Version, можно использовать актуальные значения. +Существует несколько способов их определить: #### С помощью утилиты kubectl @@ -1219,7 +1224,8 @@ variables: ### Примечание -Для выполнения действия необходимо наличие корректных реквизитов с GitLab token. Этот токен передается через механизм учетных данных и используется для аутентификации при вызове GitLab API (HTTP-заголовок `Private-Token`). +Для выполнения действия необходимо наличие корректных реквизитов с GitLab token. +Этот токен передается через механизм учетных данных и используется для аутентификации при вызове GitLab API (HTTP-заголовок `Private-Token`). Действие осуществляет POST-запрос по URL: `/api/v4/projects/:id/pipeline`. @@ -1256,19 +1262,19 @@ optional: Поддерживаемые значения в optional: -| Поле | Тип | Описание | -|-------------------------|---------------|------------------------------------------------------------------------| -| token_ttl | string | Время жизни (TTL) токена, выданного при логине | -| token_max_ttl | string | Максимальное TTL токена | -| token_policies | []string | Дополнительные политики, назначаемые при логине | -| audience | string | JWT audience (aud), который Vault ожидает от токена | -| token_period | string | Если задано, выдаёт периодический токен | -| token_explicit_max_ttl | string | Устанавливает явный верхний предел TTL токена | -| token_num_uses | int | Ограничение на количество использований токена | -| token_type | string | Тип выдаваемого токена (например, service, batch) | -| alias_name_source | string | Источник alias name для identity | -| token_no_default_policy | bool | Не включать default policy в выданный токен | -| token_bound_cidrs | []string | Ограничение CIDR-диапазонов, откуда можно использовать выданный токен | +| Поле | Тип | Описание | +|-------------------------|---------------|-----------------------------------------------------------------------| +| token_ttl | string | Время жизни (TTL) токена, выданного при логине | +| token_max_ttl | string | Максимальное TTL токена | +| token_policies | []string | Дополнительные политики, назначаемые при логине | +| audience | string | Значение JWT audience (aud), которое Vault ожидает от токена | +| token_period | string | Периодичность выдачи токена | +| token_explicit_max_ttl | string | Явный верхний предел TTL токена | +| token_num_uses | int | Ограничение на количество использований токена | +| token_type | string | Тип выдаваемого токена (например, service, batch) | +| alias_name_source | string | Источник alias name для identity | +| token_no_default_policy | bool | Исключение default policy из состава токена | +| token_bound_cidrs | []string | Ограничение CIDR-диапазонов, откуда можно использовать выданный токен | Полный список поддерживаемых параметров см. в [официальной документации](https://developer.hashicorp.com/vault/docs/auth/kubernetes#parameters) HashiCorp Vault. @@ -1378,7 +1384,7 @@ name: my-repo-to-delete - Выполняется `DELETE` по адресу `/service/rest/v1/repositories/{name}`, где `{name}` — это значение поля `name`. - Если репозиторий найден и удалён — возвращается 204. -- Если не найден — ошибка 404. +- Если не найден — возвращается ошибка 404. ### Учетные данные @@ -1386,4 +1392,4 @@ name: my-repo-to-delete ### Документация API -- [Nexus 3 REST API: Repository Management](https://help.sonatype.com/en/repositories-api.html) +- [Nexus 3 REST API: Repository Management](https://help.sonatype.com/en/repositories-api.html). diff --git a/content/documentation/admin/architecture/functional-architecture.ru.md b/content/documentation/admin/architecture/functional-architecture.ru.md index c0cb988..cf6bdf0 100644 --- a/content/documentation/admin/architecture/functional-architecture.ru.md +++ b/content/documentation/admin/architecture/functional-architecture.ru.md @@ -12,7 +12,7 @@ weight: 10 **Основные функции:** * Отображение пользовательского интерфейса для управления сервисами, окружениями и ресурсами. -* Обработка пользовательских действий и передача запросов в Backend через REST API. +* Обработка пользовательских действий и передача запросов в DDP Backend через REST API. **Технические характеристики:** @@ -81,7 +81,7 @@ weight: 10 **Redis** — это хранилище данных в памяти, используемое платформой для работы с очередями задач. {{< alert level="info" >}} -**Redis** может быть установлен в составе модуля DDP для тестовых и демонстрационных целей. В промышленной эксплуатации рекомендуется использование выделенных инстансов Redis. +Redis может быть установлен в составе модуля DDP для тестовых и демонстрационных целей. В промышленной эксплуатации рекомендуется использование выделенных инстансов Redis. {{< /alert >}} **Основные функции:** @@ -99,7 +99,7 @@ weight: 10 **PostgreSQL** — это основная реляционная база данных платформы, используемая для хранения всей постоянной информации. {{< alert level="info" >}} -**PostgreSQL** может быть установлен в составе модуля DDP для тестовых и демонстрационных целей. В промышленной эксплуатации рекомендуется использование выделенных инстансов PostgreSQL. +PostgreSQL может быть установлен в составе модуля DDP для тестовых и демонстрационных целей. В промышленной эксплуатации рекомендуется использование выделенных инстансов PostgreSQL. {{< /alert >}} ## Описание сетевых взаимодействий diff --git a/content/documentation/admin/architecture/high-level-architecture.ru.md b/content/documentation/admin/architecture/high-level-architecture.ru.md index 3fab2ef..659e90a 100644 --- a/content/documentation/admin/architecture/high-level-architecture.ru.md +++ b/content/documentation/admin/architecture/high-level-architecture.ru.md @@ -5,49 +5,54 @@ weight: 5 ## Цель и назначение системы -Deckhouse Development Platform (DDP) — это IDP (Internal Developer Platform), которая ускоряет и упрощает процессы разработки. Платформа представляет собой комплексное решение для управления всеми этапами разработки через единое окно. +Deckhouse Development Platform (DDP) — это IDP (Internal Developer Platform), внутренняя платформа разработки, которая объединяет в себе инструменты, инфраструктурные сервисы и процессы разработки. -DDP помогает ИТ-специалистам работать эффективнее — автоматизирует операции, связанные с жизненным циклом продуктов. Платформа обеспечивает централизованный доступ к ресурсам и инструментам, прозрачность процессов разработки и их автоматизацию, а также быстрый онбординг новых сотрудников. +Платформа предоставляет единый слой взаимодействия с инфраструктурными и инженерными сервисами и используется для автоматизации операций, связанных с жизненным циклом продуктов. +DDP обеспечивает единый доступ к инструментам и ресурсам, формализует и автоматизирует процессы разработки, а также упрощает подключение новых пользователей и команд. **Основные задачи платформы:** -- Обеспечение единых стандартов разработки для команд через шаблоны и типовые конфигурации -- Управление динамическими окружениями с автоматическим созданием, обновлением и удалением сред -- Интеграция с внешними инфраструктурными сервисами через API -- Упрощённый онбординг разработчиков и команд за счёт шаблонных решений и документации -- Оцифровка процессов и сценариев разработки через BPMN-подобный механизм описания процессов -- Встроенная CMDB для автоматического сбора данных из инфраструктурных сервисов и визуализации зависимостей -- Контроль параметров сущностей через механизм проверок статуса +- Обеспечение единых стандартов разработки для команд через шаблоны и типовые конфигурации. +- Управление динамическими окружениями с автоматическим созданием, обновлением и удалением сред. +- Интеграция с внешними инфраструктурными сервисами через API. +- Упрощённый онбординг разработчиков и команд за счёт шаблонных решений и документации. +- Оцифровка процессов и сценариев разработки через BPMN-подобный механизм описания процессов. +- Встроенная CMDB для автоматического сбора данных из инфраструктурных сервисов и визуализации зависимостей. +- Контроль параметров сущностей через механизм проверок статуса. ## Пользователи системы ### Команды разработки -Команды разработки потребляют предоставляемые платформой ресурсы. Пользователи работают с сущностями и ресурсами платформы: создают и управляют сущностями, запускают действия, просматривают данные из источников данных, используют виджеты и работают с процессами. +Команды разработки используют DDP для работы с сущностями и ресурсами платформы. +Эти команды создают и управляют сущностями, запускают действия, просматривают данные из источников данных, используют виджеты и работают с процессами. ### Менеджмент -Менеджмент получает статистику и данные для принятия решений. Пользователи могут просматривать дашборды с метриками, анализировать эффективность разработки, отслеживать ключевые показатели и получать отчеты о работе команд. +Менеджмент получает статистику и данные для принятия решений. Пользователи управленческого уровня могут просматривать дашборды с метриками, анализировать эффективность разработки, отслеживать ключевые показатели и получать отчеты о работе команд. ### Команды инфраструктуры и платформенные команды -Команды инфраструктуры и платформенные команды предоставляют инфраструктурные и платформенные сервисы компании в удобном для разработки виде. Пользователи настраивают интеграции с внешними сервисами, конфигурируют ресурсы, создают шаблоны и автоматизации, управляют окружениями и обеспечивают работу платформы. +Эти команды отвечают за предоставление сервисов и ресурсов через DDP. +Они настраивают интеграции с внешними сервисами, конфигурируют ресурсы, создают шаблоны и автоматизации, управляют окружениями и обеспечивают работу платформы. ### Команды безопасности -Команды безопасности предоставляют инструменты безопасности через DDP, проводят аудит и наблюдают за выполнением требований. Пользователи настраивают политики безопасности, управляют правами доступа, просматривают аудит-логи, контролируют соблюдение требований безопасности и настраивают механизмы защиты. +Команды безопасности используют DDP для предоставления и управления средствами защиты, проведения аудита и контроля соблюдения требований. +В рамках платформы они настраивают политики безопасности и права доступа, просматривают аудит-логи и управляют механизмами защиты. ### Администраторы -Администраторы — это пользователи, которые могут настраивать все компоненты платформы. Могут управлять пользователями, настраивать роли и права доступа через систему RBAC, конфигурировать интеграции с внешними сервисами, управлять учетными данными, просматривать аудит-логи, настраивать ресурсы, конфигурацию платформы и автоматизации. +Администраторы — пользователи, обладающие полными правами на настройку и сопровождение платформы. +Они управляют учетными записями пользователей, настраивают роли и права доступа через систему RBAC, конфигурируют интеграции с внешними сервисами, управляют учетными данными, ресурсами, автоматизациями и параметрами платформы, а также просматривают аудит-логи. -Права доступа для всех групп пользователей настраиваются через систему ролевого доступа (RBAC), которая позволяет гибко управлять разрешениями на уровне глобальных ролей, ролей ресурсов и ролей сущностей. +Права доступа для всех групп пользователей настраиваются через систему ролевого доступа (RBAC), которая обеспечивает гибкое управление разрешениями на уровне глобальных ролей, ролей ресурсов и ролей сущностей. ## Доступ к системе ### Веб-интерфейс -Все группы пользователей получают доступ к платформе через веб-интерфейс **DDP Frontend**, который предоставляет графический интерфейс для работы с платформой через веб-браузер. +Все группы пользователей получают доступ к платформе через веб-интерфейс **DDP Frontend**, предназначенный для работы с платформой в веб-браузере. **Протокол доступа:** HTTPS (TCP/443) @@ -67,30 +72,31 @@ REST API предоставляет полный набор функций дл ## Доступ снаружи/внутри периметра компании -Платформа DDP развертывается в Kubernetes кластере и может быть доступна как внутри корпоративного периметра, так и снаружи, в зависимости от конфигурации сетевой инфраструктуры. +Платформа DDP развертывается в кластере Kubernetes и может быть доступна как внутри корпоративного периметра, так и снаружи, в зависимости от конфигурации сетевой инфраструктуры. ### Доступ внутри периметра **Типичный сценарий:** Пользователи получают доступ к платформе через внутреннюю сеть компании. -- Веб-интерфейс и REST API доступны через внутренний Ingress контроллер -- Доступ осуществляется по внутренним доменным именам (например, `ddp.internal.company.com`) -- Аутентификация может быть интегрирована с корпоративным LDAP или Active Directory через Dex -- Дополнительная защита может обеспечиваться на уровне сетевых политик Kubernetes +- Веб-интерфейс и REST API доступны через внутренний Ingress-контроллер. +- Доступ осуществляется по внутренним доменным именам (например, `ddp.internal.company.com`). +- Аутентификация может быть интегрирована с корпоративным LDAP или Active Directory через Dex. +- Дополнительная защита может обеспечиваться на уровне сетевых политик Kubernetes. ### Доступ снаружи периметра **Типичный сценарий:** Пользователи получают доступ к платформе извне корпоративной сети. -- Веб-интерфейс и REST API доступны через публичный Ingress контроллер -- Доступ осуществляется по публичным доменным именам (например, `ddp.company.com`) -- Аутентификация может быть интегрирована с внешними провайдерами аутентификации через Dex +- Веб-интерфейс и REST API доступны через публичный Ingress-контроллер. +- Доступ осуществляется по публичным доменным именам (например, `ddp.company.com`). +- Аутентификация может быть интегрирована с внешними провайдерами аутентификации через Dex. ### Гибридный доступ Платформа может быть настроена для поддержки обоих сценариев одновременно: -- Внутренние пользователи получают доступ через внутренний Ingress -- Внешние пользователи (например, удаленные сотрудники) получают доступ через публичный Ingress или VPN -- Различные группы пользователей могут использовать разные провайдеры аутентификации через Dex -Конфигурация доступа настраивается администратором при развертывании платформы через параметры Ingress контроллера и сетевые политики Kubernetes. +- Внутренние пользователи получают доступ через внутренний Ingress. +- Внешние пользователи (например, удаленные сотрудники) получают доступ через публичный Ingress или VPN. +- Различные группы пользователей могут использовать разные провайдеры аутентификации через Dex. + +Конфигурация доступа настраивается администратором при развёртывании платформы через параметры Ingress-контроллера и сетевые политики Kubernetes. diff --git a/content/documentation/admin/architecture/workers.ru.md b/content/documentation/admin/architecture/workers.ru.md index 23a837e..a17757b 100644 --- a/content/documentation/admin/architecture/workers.ru.md +++ b/content/documentation/admin/architecture/workers.ru.md @@ -5,11 +5,11 @@ weight: 20 Воркеры — это компоненты платформы, которые обрабатывают задачи из очереди в фоновом режиме. Они обеспечивают асинхронное выполнение различных операций, таких как: -- Синхронизация данных из источников данных -- Запуск действий и процессов -- Проверки статуса сущностей +- Синхронизация данных из источников данных. +- Запуск действий и процессов. +- Проверки статуса сущностей. -Воркеры работают независимо от основного приложения и позволяют масштабировать нагрузку на систему, перенося ресурсоемкие операции на выделенные реплики. +Воркеры работают независимо от основного приложения и позволяют масштабировать нагрузку на систему, перенося ресурсоёмкие операции на выделенные реплики. ## Конфигурация @@ -23,34 +23,36 @@ weight: 20 Параметр `workers.maxTasks` определяет, сколько задач может обрабатываться параллельно каждым воркером. -**Важно:** Общее количество задач, обрабатываемых одновременно всей системой, рассчитывается как `workers.replicas × workers.maxTasks`. Например, при 2 воркерах и 10 задачах на воркер система может обрабатывать до 20 задач одновременно. +{{< alert level="info" >}} +Общее количество задач, обрабатываемых одновременно всей системой, рассчитывается как `workers.replicas × workers.maxTasks`. Например, при 2 воркерах и 10 задачах на каждый воркер, система может обрабатывать до 20 задач одновременно. +{{< /alert >}} ## Мониторинг Для мониторинга работы воркеров и очереди задач доступен виджет **Очередь задач** ([подробнее](../../widgets/types/#очередь-задач)), который отображает: -- Размер очереди (общее количество задач) -- Количество ожидающих задач -- Количество активных воркеров (консьюмеров) -- Детальную информацию о задачах в очереди -- Статус каждой задачи (новая, в обработке) +- Размер очереди (общее количество задач). +- Количество ожидающих задач. +- Количество активных воркеров (консьюмеров). +- Детальную информацию о задачах в очереди. +- Статус каждой задачи (новая, в обработке). ## Настройка через переменные окружения Параметры воркеров также можно настроить через переменные окружения: -- `WORKER_MAX_TASKS` — максимальное количество параллельных задач на воркер (по умолчанию: 10) +- `WORKER_MAX_TASKS` — максимальное количество параллельных задач на воркер (по умолчанию: 10). -**Пример:** +Пример применения настроек: ```bash export WORKER_MAX_TASKS=15 ``` **Приоритет настроек:** -1. Значение из конфигурационного файла -2. Значение из переменной окружения -3. Значение по умолчанию +1. Значение из конфигурационного файла. +2. Значение из переменной окружения. +3. Значение по умолчанию. ## Типы обрабатываемых задач @@ -58,53 +60,55 @@ export WORKER_MAX_TASKS=15 ### Задачи проверки статуса сущностей -Задачи проверки статуса сущностей выполняются воркерами для определения статуса сущностей на основе настроенных правил. Это позволяет: +Задачи проверки статуса выполняются воркерами, которые определяют состояние сущностей на основе настроенных правил. Такой подход позволяет: -- Разгрузить основной сервер от выполнения проверок -- Обеспечить стабильность работы при большом количестве сущностей -- Гарантировать выполнение проверок даже при высокой нагрузке на основное приложение +- Снизить нагрузку на основной сервер. +- Обеспечить стабильность работы при большом количестве сущностей. +- Гарантировать выполнение проверок даже при высокой нагрузке на основное приложение. ### Задачи синхронизации источников данных Воркеры обрабатывают задачи синхронизации данных из внешних источников, что позволяет: -- Выполнять синхронизацию в фоновом режиме -- Не блокировать интерфейс пользователя -- Обрабатывать большие объемы данных +- Выполнять синхронизацию в фоновом режиме. +- Не блокировать интерфейс пользователя. +- Обрабатывать большие объемы данных. ### Задачи выполнения действий Действия, требующие длительного выполнения, обрабатываются воркерами, что обеспечивает: -- Асинхронное выполнение действий -- Возможность отслеживания прогресса выполнения -- Стабильность работы интерфейса +- Асинхронное выполнение действий. +- Возможность отслеживания прогресса выполнения. +- Стабильность работы интерфейса. ## Масштабирование При необходимости увеличения производительности системы можно: -1. **Увеличить количество реплик воркеров** — это позволит обрабатывать больше задач одновременно -2. **Увеличить количество параллельных задач на воркер** — это повысит утилизацию каждого воркера +1. Увеличить количество реплик воркеров — это позволит обрабатывать больше задач одновременно +1. Увеличить количество параллельных задач на воркер — это повысит утилизацию каждого воркера -**Важно:** При увеличении нагрузки на воркеры необходимо убедиться, что у кластера достаточно ресурсов (CPU, память) для обработки всех задач. +*{{< alert level="info" >}} +При увеличении нагрузки на воркеры необходимо убедиться, что у кластера достаточно ресурсов (CPU, память) для обработки всех задач. +{{< /alert >}} -## Устранение проблем +## Устранение неполадок ### Воркеры не обрабатывают задачи Если задачи накапливаются в очереди и не обрабатываются: -1. Проверьте, что воркеры развернуты и работают (через виджет `Очередь задач`) -2. Убедитесь, что количество реплик воркеров больше 0 -3. Проверьте логи воркеров на наличие ошибок -4. Убедитесь, что у воркеров достаточно ресурсов (CPU, память) +1. Проверьте, что воркеры развернуты и работают (через виджет «Очередь задач»). +1. Убедитесь, что количество реплик воркеров больше 0. +1. Проверьте логи воркеров на наличие ошибок. +1. Убедитесь, что у воркеров достаточно ресурсов (CPU, память). ### Медленная обработка задач Если задачи обрабатываются медленно: -1. Увеличьте количество реплик воркеров -2. Увеличьте количество параллельных задач на воркер (если позволяет ресурсная база) -3. Проверьте производительность внешних систем, с которыми работают воркеры -4. Убедитесь, что нет узких мест в сети или базе данных +1. Увеличьте количество реплик воркеров. +1. Увеличьте количество параллельных задач на воркер (если позволяет ресурсная база). +1. Проверьте производительность внешних систем, с которыми работают воркеры. +1. Убедитесь, что нет узких мест в сети или базе данных. diff --git a/content/documentation/admin/datasets.ru.md b/content/documentation/admin/datasets.ru.md index 3aaf727..ebdcab2 100644 --- a/content/documentation/admin/datasets.ru.md +++ b/content/documentation/admin/datasets.ru.md @@ -5,92 +5,94 @@ d8Edition: ee moduleStatus: experimental --- -Наборы данных - это предварительно настроенные конфигурации, которые позволяют быстро развернуть готовые интеграции с внешними системами и настроить необходимые компоненты платформы. +Наборы данных - это предварительно настроенные конфигурации, предназначенные для быстрого развертывания готовых интеграций с внешними системами и настройки необходимых компонентов платформы. Каждый набор данных содержит: -- Дашборды для визуализации данных -- Виджеты для отображения информации -- Источники данных для синхронизации -- Внешние сервисы для подключения к API -- Типы учетных данных для аутентификации -- Роли и права доступа -- Другие необходимые компоненты платформы +- Дашборды для визуализации данных. +- Виджеты для отображения информации. +- Источники данных для синхронизации. +- Внешние сервисы для подключения к API. +- Типы учетных данных для аутентификации. +- Роли и права доступа. +- Другие необходимые компоненты платформы. ## Управление наборами данных ### Просмотр доступных наборов -В разделе `Администрирование → Наборы данных` отображается список всех доступных наборов данных. Каждая карточка содержит: +В разделе «Администрирование» → «Наборы данных» отображается список всех доступных наборов данных. Каждая карточка содержит: -- **Название** - название набора данных -- **Краткое описание** - краткая информация о функциональности -- **Кнопка "Описание"** - открывает подробную информацию с двумя вкладками: - - Подробное описание с полной информацией о компонентах - - Список объектов, которые будут созданы при применении -- **Кнопка "Применить"** - запускает процесс установки набора данных -- **Кнопка "Удалить"** - удаляет ранее примененный набор данных +- **Название** - название набора данных. +- **Краткое описание** - общее описание функциональности. +- **Кнопка «Описание»** - открывает подробную информацию о наборе данных, включая: + - Подробное описание с полной информацией о компонентах. + - Список объектов, которые будут созданы при применении. +- **Кнопка «Применить»** - запускает процесс установки набора данных. +- **Кнопка «Удалить»** - удаляет ранее примененный набор данных. ### Применение набора данных -1. Нажмите кнопку **"Применить"** на карточке нужного набора данных -2. Если набор данных требует настройки параметров, откроется форма конфигурации -3. Заполните необходимые параметры и нажмите **"Применить"** -4. Если параметры не требуются, появится окно подтверждения -5. После успешного применения все компоненты набора данных будут созданы в системе +1. Нажмите кнопку **«Применить»** на карточке нужного набора данных. +1. Если набор данных требует настройки параметров, откроется форма конфигурации. +1. Заполните необходимые параметры и нажмите **«Применить»**. +1. Если параметры не требуются, появится окно подтверждения. +1. После успешного применения все компоненты набора данных будут созданы в системе. ### Удаление набора данных -1. Нажмите кнопку **"Удалить"** на карточке примененного набора данных -2. Подтвердите удаление в диалоговом окне -3. Все компоненты набора данных будут удалены из системы +1. Нажмите кнопку **«Удалить»** на карточке примененного набора данных. +1. Подтвердите удаление в диалоговом окне. +1. Все компоненты набора данных будут удалены из системы. ### Настройка после применения После применения некоторых наборов данных может потребоваться дополнительная настройка: -1. Перейдите в **"Профиль"** → **"Учетные данные"** -2. Заполните необходимые учетные данные (токены, пароли и т.д.) -3. Сохраните изменения +1. Перейдите в **«Профиль»** → **«Учетные данные»**. +1. Заполните необходимые учетные данные (токены, пароли и т.д.). +1. Сохраните изменения. ## Доступные наборы данных ### GitLab -Набор данных для работы с GitLab репозиториями и анализа CI/CD процессов +Набор данных предназначен для работы с GitLab-репозиториями и анализа процессов CI/CD. **Дашборды:** -- **Статистика репозитория** - для анализа статистики пайплайнов -- **Управление репозиторием** - для управления репозиториями +- **Статистика репозитория** - для анализа статистики пайплайнов. +- **Управление репозиторием** - для управления репозиториями. **Виджеты:** -- **Статистика пайплайнов GitLab** - для детальной аналитики пайплайнов -- **GitLab пайплайны** - для управления пайплайнами -- **Редактор пайплайнов GitLab** - для редактирования конфигурации пайплайнов +- **Статистика пайплайнов GitLab** - для детальной аналитики пайплайнов. +- **GitLab пайплайны** - для управления пайплайнами. +- **Редактор пайплайнов GitLab** - для редактирования конфигурации пайплайнов. **Настройка:** Набор данных настраивает подключение к GitLab API через внешний сервис, создает типы учетных данных для токена и имени пользователя и подключает источник данных для синхронизации репозиториев GitLab в каталог. -> **Важно:** После применения необходимо заполнить в профиле супер-администратора учетные данные **GitLab token**. +{{< alert level="info" >}} +После применения необходимо заполнить в профиле супер-администратора учетные данные GitLab token. +{{< /alert >}} **Параметры настройки:** -- **GitLab URL** - адрес вашего GitLab сервера (по умолчанию: ) +- **GitLab URL** - адрес вашего GitLab сервера (по умолчанию: ). **Требования:** -- Доступ к GitLab API -- Токен доступа GitLab с правами на чтение репозиториев и пайплайнов +- Доступ к GitLab API. +- Токен доступа GitLab с правами на чтение репозиториев и пайплайнов. **Применение:** -1. Примените набор данных GitLab -2. Укажите URL вашего GitLab сервера -3. Перейдите в профиль супер-администратора -4. Заполните учетные данные "GitLab token" вашим токеном доступа -5. Сохраните изменения +1. Примените набор данных GitLab. +1. Укажите URL вашего GitLab сервера. +1. Перейдите в профиль супер-администратора. +1. Заполните учетные данные «GitLab token» вашим токеном доступа. +1. Сохраните изменения. -После этого в разделе "Каталог" появятся ваши GitLab репозитории, а на дашбордах будет отображаться статистика и управление пайплайнами. +После этого в разделе «Каталог» появятся ваши репозитории GitLab, а на дашбордах будет отображаться статистика и управление пайплайнами. diff --git a/content/documentation/admin/datasources/overview.ru.md b/content/documentation/admin/datasources/overview.ru.md index ada6303..ac7c754 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) и преобразовывать данную информацию в параметры той или иной сущности. +Источники данных — механизм DDP, который позволяет синхронизировать информацию из внешних инфраструктурных систем (например, GitLab, либо Kubernetes) и преобразовывать её в параметры той или иной сущности. Также источники данных позволяют: @@ -16,8 +16,8 @@ weight: 10 ## Типы источников данных -* Встроенные (BuiltIn) — источники данных, для которых логика опроса инфраструктурных систем поставляется в рамках DDP -* Вебхуки (Webhooks) — см. страницу «Вебхуки». +* Встроенные (BuiltIn) — источники данных, для которых логика опроса инфраструктурных систем поставляется в рамках DDP. +* Вебхуки (Webhooks) — механизм приёма данных во входящих POST-запросах от внешних систем, подробнее в разделе [«Вебхуки»](../../admin/webhooks/). ## Правила источников данных @@ -116,7 +116,7 @@ metadata: Правила создания связей определяют, какие связи создавать для сущности, которая соответствует правилам сопоставления. При задании правил создания связей заполняется: * Связь ресурса. -* Поле из спецификации ресурса внешней инфраструктурной системы, на основании которого производить поиск связи. +* Поле из спецификации ресурса внешней инфраструктурной системы, на основании которого нужно производить поиск связи. Например, при следующей спецификации одного из ресурсов внешней инфраструктурной системы, полученного через источник данных: @@ -142,7 +142,7 @@ metadata: будет: -* Среди сущностей, которые при создании связи были указаны как родительские, был произведен поиск той, идентификатор (slug) которой соответствует значению `default`. **Важно:** при создании связи ресурсов задаётся родительский и дочерний ресурс. при указании идентификатора родительской сущности, поиск будет произведен только по сущностям из родительского ресурса. Если указать идентификатор дочерней сущности, то поиск будет произведен только по сущностям дочернего ресурса. В рамках создания правила необходимо указывать либо родительский идентификатор, либо дочерний. При одновременном указании в рамках одного правила обоих идентификаторов, поиск будет производиться только по родительскому ресурсу. +* Среди сущностей, которые при создании связи были указаны как родительские, был произведен поиск той, идентификатор (slug) которой соответствует значению `default`. При создании связи ресурсов задаётся родительский и дочерний ресурс. при указании идентификатора родительской сущности, поиск будет произведен только по сущностям из родительского ресурса. Если указать идентификатор дочерней сущности, то поиск будет произведен только по сущностям дочернего ресурса. В рамках создания правила необходимо указывать либо родительский идентификатор, либо дочерний. При одновременном указании в рамках одного правила обоих идентификаторов, поиск будет производиться только по родительскому ресурсу. * В случае существования сущности родительского ресурса с идентификатором `default`, создана связь между данной сущностью, и сущностью ресурса, к которому привязан источник данных, и которая соответствует правилам сопоставления @@ -155,7 +155,7 @@ metadata: При включенном параметре «Периодическая синхронизация» источник данных будет автоматически обновлять информацию из внешних инфраструктурных систем с интервалом, определенным в параметре «Периодичность запуска». -Также каждый источник данных может быть синхронизирован вручную в любой момент времени через веб-интерфейс (пункт `Синхронизировать` в меню источника данных), либо через API. +Также каждый источник данных может быть синхронизирован вручную в любой момент времени через веб-интерфейс (пункт «Синхронизировать» в меню источника данных), либо через API. ## Удаление сущностей @@ -183,10 +183,11 @@ metadata: Для каждого запуска источника данных создается запись в БД, содержащая полный лог выполнения. Максимальное количество подобных записей регулируется параметром «максимальное количество записей» в конфигурации источника данных. При достижении максимального количества старые записи будут удаляться. -Параметр `datasources.logging.enabled` в конфигурационном файле DDP backend управляет выводом логов запуска источника данных в stdout. -При значении `true` логи выводятся в stdout, при значении `false` — нет. +Параметр `datasources.logging.enabled` в конфигурационном файле DDP позволяет выводить в stdout, либо скрывать логи синхронизации источника данных. При значении `true` логи будут выводиться в stdout, при значении `false` логи выводиться не будут. +{{< alert level="info" >}} Записи в БД с полным логом запуска источника данных создаются независимо от значения параметра `datasources.logging.enabled`. +{{< /alert >}} ## Системная учетная запись @@ -198,7 +199,7 @@ metadata: Значение данного идентификатора может быть подставлено в конфигурацию источника данных с использованием синтаксиса [Go template](https://developer.hashicorp.com/nomad/tutorials/templates/go-template-syntax). -Например, если в Header для источника данных необходимо передать секретное значение с идентификатором `token`, то оно может быть указано в следующем виде: +Например, если в заголовке для источника данных необходимо передать секретное значение с идентификатором `token`, то оно может быть указано в следующем виде: ```go {{ .credentials.token }} diff --git a/content/documentation/admin/datasources/types.ru.md b/content/documentation/admin/datasources/types.ru.md index 8da78c4..2b57775 100644 --- a/content/documentation/admin/datasources/types.ru.md +++ b/content/documentation/admin/datasources/types.ru.md @@ -175,29 +175,29 @@ title: Типы источников данных ```json [ { - "name": "string", // Название + "name": "string", // Название. "info": { - "first_deployed": "string", // Дата и время первого деплоя - "last_deployed": "string", // Дата и время последнего деплоя - "deleted": "string", // Дата и время удаления (может быть пустой строкой) - "description": "string", // Описание - "status": "string", // Статус - "notes": "string" // Заметки + "first_deployed": "string", // Дата и время первого деплоя. + "last_deployed": "string", // Дата и время последнего деплоя. + "deleted": "string", // Дата и время удаления (может быть пустой строкой). + "description": "string", // Описание. + "status": "string", // Статус. + "notes": "string" // Заметки. }, "chart": { "metadata": { - "name": "string", // Название чарта - "home": "string", // Домашняя страница - "sources": "array", // Массив строк с URL-адресами источников - "version": "string", // Версия чарта - "description": "string", // Описание чарта - "keywords": "array", // Массив строк с ключевыми словами - "maintainers": "array", // Массив объектов с информацией о мейнтейнерах - "icon": "string", // URL иконки - "apiVersion": "string", // Версия API - "appVersion": "string" // Версия приложения + "name": "string", // Название чарта. + "home": "string", // Домашняя страница. + "sources": "array", // Массив строк с URL-адресами источников. + "version": "string", // Версия чарта. + "description": "string", // Описание чарта. + "keywords": "array", // Массив строк с ключевыми словами. + "maintainers": "array", // Массив объектов с информацией о мейнтейнерах. + "icon": "string", // URL иконки. + "apiVersion": "string", // Версия API. + "appVersion": "string" // Версия приложения. }, - "templates": [ // Массив объектов с шаблонами + "templates": [ // Массив объектов с шаблонами. { "name": "templates/NOTES.txt", "data": "..." @@ -206,11 +206,11 @@ title: Типы источников данных "name": "templates/_helpers.tpl", "data": "..." } - // ... другие шаблоны + // ... другие шаблоны. ], - "values": "object", // Объект с доступными настройками Helm чарта - "schema": "null", // Схема (может быть null) - "files": [ // Массив объектов с файлами + "values": "object", // Объект с доступными настройками Helm чарта. + "schema": "null", // Схема (может быть null). + "files": [ // Массив объектов с файлами. { "name": ".helmignore", "data": "..." @@ -219,22 +219,22 @@ title: Типы источников данных "name": "LICENSE", "data": "..." } - // ... другие файлы + // ... другие файлы. ] }, - "config": { // Текушая конфигурацию + "config": { // Текушая конфигурация. "caSecretName": "string", "cache": { "enabled": "boolean", "expireHours": "integer" } - // ... другие настройки + // ... другие настройки. }, - "manifest": "string", // Отрендеренные манифесты - "version": "integer", // Версия helmrelease - "namespace": "string" // Пространство имен, где развернут релиз + "manifest": "string", // Отрендеренные манифесты. + "version": "integer", // Версия HelmRelease. + "namespace": "string" // Пространство имен, где развернут релиз. }, - // ... другие helmreleases + // ... другие ресурсы типа HelmRelease. ] ``` @@ -253,7 +253,7 @@ title: Типы источников данных ### Авторизация -Платформа поддерживает аутентификацию в Kafka с помощью SASL/PLAIN и SASL/SCRAM. Документация: [Kafka SASL/PLAIN](https://kafka.apache.org/documentation/#security_sasl_plain), [Kafka SASL/SCRAM](https://kafka.apache.org/documentation/#security_sasl_scram). +Платформа поддерживает аутентификацию в Kafka с помощью [SASL/PLAIN](https://kafka.apache.org/documentation/#security_sasl_plain), [SASL/SCRAM](https://kafka.apache.org/documentation/#security_sasl_scram). ### Спецификация ответа @@ -262,16 +262,16 @@ title: Типы источников данных ```json [ { - "Cluster": "string", // Название кластера Kafka - "ResourceType": "string", // Тип ресурса (TOPIC, GROUP и т.д.) - "ResourceName": "string", // Название ресурса - "PatternType": "string", // Тип паттерна (LITERAL, PREFIXED и т.д.) - "Principal": "string", // Principal пользователя (например: "User:Alice") - "Host": "string", // Хост (обычно "*" для любого хоста) - "Operation": "string", // Операция (READ, WRITE, DESCRIBE и т.д.) - "PermissionType": "string" // Тип разрешения (ALLOW, DENY) + "Cluster": "string", // Название кластера Kafka. + "ResourceType": "string", // Тип ресурса (TOPIC, GROUP и т.д.). + "ResourceName": "string", // Название ресурса. + "PatternType": "string", // Тип паттерна (LITERAL, PREFIXED и т.д.). + "Principal": "string", // Principal пользователя (например: "User:Alice"). + "Host": "string", // Хост (обычно "*" для любого хоста). + "Operation": "string", // Операция (READ, WRITE, DESCRIBE и т.д.). + "PermissionType": "string" // Тип разрешения (ALLOW, DENY). }, - // ... другие записи ACL + // ... другие записи ACL. ] ``` @@ -281,12 +281,12 @@ title: Типы источников данных ### Параметры -|Название |Обязательность |Описание |Возможные значения | +|Название |Обязательность | Описание |Возможные значения | |-----------------|-----------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------| |SecurityProtocol | **обязательно** | Протокол для подключения к Kafka. [Подробнее](https://kafka.apache.org/documentation/#adminclientconfigs_security.protocol) | PLAINTEXT, SASL_PLAINTEXT, SASL_SSL | |SaslMechanism | опционально | Механизм аутентификации, который будет использовать SASL. Обязателен при использовании протокола SASL_PLAINTEXT или SASL_SSL. [Подробнее](https://kafka.apache.org/documentation/#security_sasl_mechanism) | PLAIN, SCRAM-SHA-256, SCRAM-SHA-512 | -|User | **обязательно** | Username пользователя для подключения к Kafka | - | -|Pass | **обязательно** | Password пользователя для подключения к Kafka | - | +|User | **обязательно** | Имя пользователя для подключения к Kafka | - | +|Pass | **обязательно** | Пароль пользователя для подключения к Kafka | - | ## KafkaBrokers @@ -294,7 +294,7 @@ title: Типы источников данных ### Авторизация -Платформа поддерживает аутентификацию в Kafka с помощью SASL/PLAIN и SASL/SCRAM. Документация: [Kafka SASL/PLAIN](https://kafka.apache.org/documentation/#security_sasl_plain), [Kafka SASL/SCRAM](https://kafka.apache.org/documentation/#security_sasl_scram). +Платформа поддерживает аутентификацию в Kafka с помощью [SASL/PLAIN](https://kafka.apache.org/documentation/#security_sasl_plain), [SASL/SCRAM](https://kafka.apache.org/documentation/#security_sasl_scram). ### Спецификация ответа @@ -302,30 +302,30 @@ title: Типы источников данных ```json { - "Cluster": "string", // Название кластера Kafka (из kafkaBrokerMetadata.Cluster) - "Leader": "boolean", // Является ли брокер лидером-контроллером (true/false) - "NodeID": "number", // Уникальный ID брокера (из broker.NodeID) - "Port": "number", // Порт брокера (из broker.Port) - "Host": "string", // Хост брокера (из broker.Host) - "Rack": "string|null", // Рек (зона доступности) брокера (из broker.Rack) - "Configs": { // Конфигурации брокера + "Cluster": "string", // Название кластера Kafka (из kafkaBrokerMetadata.Cluster). + "Leader": "boolean", // Является ли брокер лидером-контроллером (true/false). + "NodeID": "number", // Уникальный ID брокера (из broker.NodeID). + "Port": "number", // Порт брокера (из broker.Port). + "Host": "string", // Хост брокера (из broker.Host). + "Rack": "string|null", // Рек (зона доступности) брокера (из broker.Rack). + "Configs": { // Конфигурации брокера. { - "Name": "number", // Уникальный ID брокера - "Configs": [ // Массив отдельных конфигураций + "Name": "number", // Уникальный ID брокера. + "Configs": [ // Массив отдельных конфигураций. { - "Key": "listeners", // Ключ конфигурации - "Value": "CLIENT://:9092,INTERNAL://:9094", // Значение конфигурации - "Source": "STATIC_BROKER_CONFIG" // Источник конфигурации + "Key": "listeners", // Ключ конфигурации. + "Value": "CLIENT://:9092,INTERNAL://:9094", // Значение конфигурации. + "Source": "STATIC_BROKER_CONFIG" // Источник конфигурации. }, { - "Key": "log.retention.hours", // Ключ конфигурации - "Value": 168, // Значение конфигурации - "Source": "DEFAULT_CONFIG" // Источник конфигурации + "Key": "log.retention.hours", // Ключ конфигурации. + "Value": 168, // Значение конфигурации. + "Source": "DEFAULT_CONFIG" // Источник конфигурации. }, { - "...": "..." // Другие параметры - // Полный список параметров см. в официальной документации: - // https://kafka.apache.org/documentation/#brokerconfigs + "...": "..." // Другие параметры. + // Полный список параметров — в официальной документации: + // https://kafka.apache.org/documentation/#brokerconfigs. } ] } @@ -339,12 +339,12 @@ title: Типы источников данных ### Параметры -|Название |Обязательность |Описание |Возможные значения | +|Название |Обязательность | Описание |Возможные значения | |-----------------|-----------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------| |SecurityProtocol | **обязательно** | Протокол для подключения к Kafka. [Подробнее](https://kafka.apache.org/documentation/#adminclientconfigs_security.protocol) | PLAINTEXT, SASL_PLAINTEXT, SASL_SSL | |SaslMechanism | опционально | Механизм аутентификации, который будет использовать SASL. Обязателен при использовании протокола SASL_PLAINTEXT или SASL_SSL. [Подробнее](https://kafka.apache.org/documentation/#security_sasl_mechanism) | PLAIN, SCRAM-SHA-256, SCRAM-SHA-512 | -|User | **обязательно** | Username пользователя для подключения к Kafka | - | -|Pass | **обязательно** | Password пользователя для подключения к Kafka | - | +|User | **обязательно** | Имя пользователя для подключения к Kafka | - | +|Pass | **обязательно** | Пароль пользователя для подключения к Kafka | - | ## KafkaTopics @@ -352,7 +352,7 @@ title: Типы источников данных ### Авторизация -Платформа поддерживает аутентификацию в Kafka с помощью SASL/PLAIN и SASL/SCRAM. Документация: [Kafka SASL/PLAIN](https://kafka.apache.org/documentation/#security_sasl_plain), [Kafka SASL/SCRAM](https://kafka.apache.org/documentation/#security_sasl_scram). +Платформа поддерживает аутентификацию в Kafka с помощью [SASL/PLAIN](https://kafka.apache.org/documentation/#security_sasl_plain), [SASL/SCRAM](https://kafka.apache.org/documentation/#security_sasl_scram). ### Спецификация ответа @@ -360,33 +360,33 @@ title: Типы источников данных ```json { - "Cluster": "string", // Название кластера Kafka - "Topic": "string", // Название топика - "ID": "string", // Уникальный идентификатор топика - "IsInternal": "boolean", // Является ли топик внутренним (Пример внутреннего топика: __consumer_offsets) - "Partitions": "number", // Количество партиций в топике - "Configs": { // Конфигурации топика (динамические параметры) - "retention.ms": 604800000, // Пример параметра: время хранения сообщений - "cleanup.policy": "delete", // Пример параметра: политика очистки - "...": "..." // Другие параметры - // Полный список параметров см. в официальной документации: - // https://kafka.apache.org/documentation/#topicconfigs + "Cluster": "string", // Название кластера Kafka. + "Topic": "string", // Название топика. + "ID": "string", // Уникальный идентификатор топика. + "IsInternal": "boolean", // Является ли топик внутренним (Пример внутреннего топика: __consumer_offsets). + "Partitions": "number", // Количество партиций в топике. + "Configs": { // Конфигурации топика (динамические параметры). + "retention.ms": 604800000, // Пример параметра: время хранения сообщений. + "cleanup.policy": "delete", // Пример параметра: политика очистки. + "...": "..." // Другие параметры. + // Полный список параметров — в официальной документации: + // https://kafka.apache.org/documentation/#topicconfigs. } } ``` ### Конфигурация -* **URL** — URL Kafka в формате `example.com` +* **URL** — URL Kafka в формате `example.com`. ### Параметры -|Название |Обязательность |Описание |Возможные значения | +|Название |Обязательность | Описание |Возможные значения | |-----------------|-----------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------| |SecurityProtocol | **обязательно** | Протокол для подключения к Kafka. [Подробнее](https://kafka.apache.org/documentation/#adminclientconfigs_security.protocol) | PLAINTEXT, SASL_PLAINTEXT, SASL_SSL | |SaslMechanism | опционально | Механизм аутентификации, который будет использовать SASL. Обязателен при использовании протокола SASL_PLAINTEXT или SASL_SSL. [Подробнее](https://kafka.apache.org/documentation/#security_sasl_mechanism) | PLAIN, SCRAM-SHA-256, SCRAM-SHA-512 | -|User | **обязательно** | Username пользователя для подключения к Kafka | - | -|Pass | **обязательно** | Password пользователя для подключения к Kafka | - | +|User | **обязательно** | Имя пользователя для подключения к Kafka | - | +|Pass | **обязательно** | Пароль пользователя для подключения к Kafka | - | ## KubernetesDeployments @@ -394,7 +394,7 @@ title: Типы источников данных ### Авторизация -Конфигурация авторизации описана в разделе [внешний сервис Kubernetes](../external-services/#kubernetes). +Конфигурация авторизации описана в разделе [Внешние сервисы](../external-services/#kubernetes). ### Спецификация ответа @@ -493,13 +493,13 @@ FIELDS: ### Параметры -|Название |Обязательность |Описание |Возможные значения | -|------------|---------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------| -|apiGroup |опционально |API группа ресурса. Для ресурсов в core API группе поле не задается. |[См. определение требуемых Group и Version](#определение-требуемых-group-и-version)| -|version |**обязательно**|Версия API ресурса. |[См. определение требуемых Group и Version](#определение-требуемых-group-и-version)| -|isNamespaced|**обязательно**|Является ли ресурс namespaced или нет. Проверить, является ли ресурс namespaced можно с помощью команды `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|**обязательно**| Принадлежность ресурса неймспейсам. Проверить принадлежность можно с помощью команды `kubectl api-resources` |true, false | +|namespace |опционально | Пространство имен, из которого будут собираться ресурсы. Если не указан, ресурсы будут собираться из всех пространств имен. Значение параметра учитывается только если значение **isNamespaced** равно `true` | | +|resource |**обязательно**| Название ресурса. Указывается маленькими буквами во множественном числе, как в поле NAME вывода команды `kubectl api-resources`. | | ## Примеры конфигурации @@ -710,23 +710,23 @@ GenericAPI возвращает массив объектов JSON. Структ ### Конфигурация * **URL** — базовый URL API в формате `https://api.example.com`. -* **Method** — HTTP метод (GET, POST, PUT, PATCH, DELETE). +* **Method** — HTTP-метод (GET, POST, PUT, PATCH, DELETE). * **Query Type** — тип запроса (Generic). * **Query** — дополнительные query параметры (например, для фильтрации или поиска). ### Параметры -| Название | Обязательность | Описание | Возможные значения | Примеры | По умолчанию | -|------------------|----------------|----------------------------------------------------------------------------------|-----------------------------------------|--------------------------------|--------------| -| paginationType | опционально | Тип пагинации для обработки больших объемов данных | none, offset, cursor, page, link_header | none | none | -| path | опционально | Путь к endpoint API, который будет добавлен к базовому URL | Любая строка, начинающаяся с / | /api/v1/users, /projects | "" | -| dataPath | опционально | JSONPath для извлечения массива данных из ответа API | Любая строка | data, results.items, . | . | -| pageParam | опционально | Название параметра для номера страницы (для offset и page пагинации) | Любая строка | page, _page, pageNumber | page | -| limitParam | опционально | Название параметра для количества элементов на странице (для offset пагинации) | Любая строка | limit, per_page,_limit, size | limit | -| sizeParam | опционально | Название параметра для размера страницы (для page пагинации) | Любая строка | size, pageSize, _size | size | -| cursorParam | опционально | Название параметра для курсора (для cursor пагинации) | Любая строка | cursor, after, next | cursor | -| pageSize | опционально | Количество элементов на странице для пагинации | Положительное целое число | 10, 20, 50, 100 | 100 | -| requestBody | опционально | Тело запроса для POST/PUT/PATCH методов | Любая строка | {"query": "example"} | "" | +| Название | Обязательность | Описание | Возможные значения | Примеры | По умолчанию | +|------------------|----------------|--------------------------------------------------------------------------------|-----------------------------------------|--------------------------------|--------------| +| paginationType | опционально | Тип пагинации для обработки больших объемов данных | none, offset, cursor, page, link_header | none | none | +| path | опционально | Путь к эндпоинту API, который будет добавлен к базовому URL | Любая строка, начинающаяся с / | /api/v1/users, /projects | "" | +| dataPath | опционально | JSONPath для извлечения массива данных из ответа API | Любая строка | data, results.items, . | . | +| pageParam | опционально | Название параметра для номера страницы (для offset- и page- пагинации) | Любая строка | page, _page, pageNumber | page | +| limitParam | опционально | Название параметра для количества элементов на странице (для offset-пагинации) | Любая строка | limit, per_page,_limit, size | limit | +| sizeParam | опционально | Название параметра для размера страницы (для page-пагинации) | Любая строка | size, pageSize, _size | size | +| cursorParam | опционально | Название параметра для курсора (для cursor-пагинации) | Любая строка | cursor, after, next | cursor | +| pageSize | опционально | Количество элементов на странице для пагинации | Положительное целое число | 10, 20, 50, 100 | 100 | +| requestBody | опционально | Тело запроса для POST/PUT/PATCH-методов | Любая строка | {"query": "example"} | "" | ### Типы пагинации @@ -795,7 +795,7 @@ limitParam: limit query: "filter=active&sort=name" ``` -**POST запрос с телом:** +**POST-запрос с телом:** ```yaml url: https://api.example.com diff --git a/content/documentation/admin/examples/service-autoupdates.ru.md b/content/documentation/admin/examples/service-autoupdates.ru.md index 75786bb..a2f1b2a 100644 --- a/content/documentation/admin/examples/service-autoupdates.ru.md +++ b/content/documentation/admin/examples/service-autoupdates.ru.md @@ -8,74 +8,59 @@ title: Автоматическое обновление сервисов Для реализации автоматического обновления сервисов используются следующие компоненты платформы DDP: -- Ресурс +- Ресурс: - В рамках инструкции используются два ресурса: - **«Шаблоны»** — хранит информацию о шаблонных репозиториях (URL и ID репозитория, последний тег версии). - - **«Сервисы»** — хранит информацию о созданных сервисах (URL и ID репозитория, переменные шаблонизации, ветка по умолчанию). > Названия могут отличаться, в зависимости от ваших настроек. -- Связь - - - Устанавливает связь между шаблоном и созданными из него сервисами. -- Источник данных +- Связь: - - В данной настройке источник данных: - - - Периодически синхронизирует информацию о шаблонных репозиториях из GitLab. + - Устанавливает связь между шаблоном и созданными из него сервисами. - - Обновляет список тегов для каждого шаблона. +- Источник данных: - - Автоматически обновляет параметр «Последний тег» в сущностях ресурса «Шаблоны». + - Синхронизирует информацию о шаблонных репозиториях из GitLab. + - Обновляет список тегов для каждого шаблона. + - Автоматически обновляет параметр «Последний тег» в сущностях ресурса «Шаблоны». -- Действие +- Действие: - В данной настройке используются три действия: - - **Создание проекта в GitLab** — создает новый проект в GitLab для размещения сервиса. - - - **Создание репозитория из шаблона** — клонирует код из шаблонного репозитория в новый репозиторий сервиса с применением переменных шаблонизации. - - - **Обновление сервиса из шаблона** — создает Merge Request в репозитории сервиса с изменениями из новой версии шаблона. + - создает новый проект в GitLab для размещения сервиса. + - клонирует код из шаблонного репозитория в новый репозиторий сервиса с применением переменных шаблонизации. + - создает Merge Request в репозитории сервиса с изменениями из новой версии шаблона. > Названия могут отличаться, в зависимости от ваших настроек. -- Процесс + +- Процесс: - В данной настройке процесс объединяет два действия: - Последовательно запускает создание проекта в GitLab, а затем создание репозитория из шаблона. - - Обеспечивает интерфейс для пользователя при создании сервиса из шаблона. - Автоматизация - - В данной настройке автоматизация: - - - Отслеживает изменения параметра «Последний тег» в сущностях ресурса «Шаблоны». - - - При обнаружении нового тега автоматически запускает действие «Обновление сервиса из шаблона» (название зависит от ваших настроек) для всех связанных сервисов. - - - Создает Merge Request в каждом репозитории сервиса с изменениями из новой версии шаблона. + - Отслеживает изменения параметра «Последний тег» в сущностях ресурса «Шаблоны». + - При обнаружении нового тега автоматически запускает действие «Обновление сервиса из шаблона» (название зависит от ваших настроек) для всех связанных сервисов. + - Создает Merge Request в каждом репозитории сервиса с изменениями из новой версии шаблона. ![workflow](../images/service-autoupdates/workflow.png) **Последовательность работы:** 1. **Источник данных** периодически синхронизирует информацию о шаблонах из GitLab и обновляет параметр с идентификатором `repository_last_tag` (может отличаться в зависимости от ваших настроек) в сущностях ресурса «Шаблоны». - -2. **Автоматизация** отслеживает изменения параметра с идентификатором `repository_last_tag` (может отличаться в зависимости от ваших настроек) через триггеры. - -3. При обнаружении нового тега **автоматизация** запускает действие «Обновление сервиса из шаблона» (название может отличаться в зависимости от ваших настроек) для всех сервисов, связанных с обновленным шаблоном. - -4. **Действие** создает Merge Request в репозитории каждого сервиса, включающий изменения из новой версии шаблона. +1. **Автоматизация** отслеживает изменения параметра с идентификатором `repository_last_tag` (может отличаться в зависимости от ваших настроек) через триггеры. +1. При обнаружении нового тега **автоматизация** запускает действие «Обновление сервиса из шаблона» (название может отличаться в зависимости от ваших настроек) для всех сервисов, связанных с обновленным шаблоном. +1. **Действие** создает Merge Request в репозитории каждого сервиса, включающий изменения из новой версии шаблона. Таким образом, при добавлении нового тега в шаблонный репозиторий все связанные сервисы автоматически получают предложение обновиться через Merge Request. ---- - ## Настройка компонентов В следующих разделах описывается конфигурация каждого компонента системы. При настройке учитывайте, что названия ресурсов и параметров могут отличаться от приведенных в инструкции. В этом случае необходимо обеспечить согласованность названий между всеми компонентами: если вы используете другие названия параметров в ресурсах, их нужно использовать во всех действиях, автоматизациях и источниках данных, которые ссылаются на эти параметры. @@ -522,6 +507,7 @@ values: {{ .template_values | nindent 4 }} - **Параметр «Ветка обновляемого репозитория»** с идентификатором `target_repo_branch` (или иным при необходимости) типа String — основная ветка репозитория сервиса (например, `master` или `main`), куда будет направлен MR. Значение по умолчанию: `{{ .entity.properties.default_branch }}` — использует ветку по умолчанию из параметра сущности. Если идентификатор параметра называется иначе, используйте свой **Backend:** + > В качестве идентификаторов используется те, которые предлагались выше. Если были заданы другие, необходимо так же изменить их ниже в теле запроса. На вкладке «Backend» настройте логику выполнения действия. Логика зависит от настраиваемого действия. @@ -691,9 +677,9 @@ values: {{ .template_values | nindent 4 }} Действия находится в следующей последовательности: 1. Start. -2. Создать проект в GitLab. -3. Создать репозиторий из шаблона. -4. End. +1. Создать проект в GitLab. +1. Создать репозиторий из шаблона. +1. End. ### Создание процесса @@ -718,15 +704,15 @@ values: {{ .template_values | nindent 4 }} На вкладке «Конфигурация» настройте шаги процесса и их порядок выполнения: 1. Добавьте элемент типа «Задача» с названием «Создать проект в GitLab» и выберите действие «Создать проект в GitLab» для запуска. -2. Добавьте элемент типа «Задача» с названием «Создать репозиторий из шаблона» и выберите действие «Создать репозиторий из шаблона» для запуска. -3. Добавьте элемент типа «Конец» для завершения процесса. +1. Добавьте элемент типа «Задача» с названием «Создать репозиторий из шаблона» и выберите действие «Создать репозиторий из шаблона» для запуска. +1. Добавьте элемент типа «Конец» для завершения процесса. После добавления всех элементов настройте последовательность выполнения: 1. Start. -2. Создать проект в GitLab. -3. Создать репозиторий из шаблона. -4. End. +1. Создать проект в GitLab. +1. Создать репозиторий из шаблона. +1. End. ## Автоматизация @@ -816,9 +802,9 @@ values: {{ .template_values | nindent 4 }} Для создания сервиса необходимо следующее: 1. Перейдите во вкладку «Каталог» в ресурс «Сервисы». -2. В правом верхнем углу нажмите кнопку «Создать». -3. В открывшемся окне во вкладке «Основная информация» заполните требуемые поля. Если настройки были произведены в соответствии с данной инструкцией, заполнение данных в других вкладках не требуются. Данные будут заполнены автоматически в дальнейшем. -4. Справа от появившейся записи о новом сервисе, нажмите на синюю кнопку с тремя вертикальными точками и выберите пункт «Запустить процесс». -5. В выпадающем списке выберите процесс `Создание сервиса из шаблона`. -6. При необходимости заполните переменные шаблона и запустите процесс. -7. При корректных настройках сервис будет создан. При наличии обновлений шаблоны для сервиса будут формироваться MR с изменениями. Проверить корректность создания можно перейдя в него и открыв вкладку «Запуски действий». Все [действия](../actions/overview/) должны быть в статусе `Success`. +1. В правом верхнем углу нажмите кнопку «Создать». +1. В открывшемся окне во вкладке «Основная информация» заполните требуемые поля. Если настройки были произведены в соответствии с данной инструкцией, заполнение данных в других вкладках не требуются. Данные будут заполнены автоматически в дальнейшем. +1. Справа от появившейся записи о новом сервисе, нажмите на синюю кнопку с тремя вертикальными точками и выберите пункт «Запустить процесс». +1. В выпадающем списке выберите процесс `Создание сервиса из шаблона`. +1. При необходимости заполните переменные шаблона и запустите процесс. +1. При корректных настройках сервис будет создан. При наличии обновлений шаблоны для сервиса будут формироваться MR с изменениями. Проверить корректность создания можно перейдя в него и открыв вкладку «Запуски действий». Все [действия](../actions/overview/) должны быть в статусе `Success`. diff --git a/content/documentation/admin/external-services.ru.md b/content/documentation/admin/external-services.ru.md index 2787fbb..c40f0d2 100644 --- a/content/documentation/admin/external-services.ru.md +++ b/content/documentation/admin/external-services.ru.md @@ -7,7 +7,7 @@ moduleStatus: experimental Внешние сервисы — это механизм, позволяющий настраивать параметры авторизации для внешних инфраструктурных систем (например, GitLab, Kubernetes, DefectDojo и др.). -Настройка внешних сервисов осуществляется в разделе `Администрирование → Внешние сервисы`. +Настройка внешних сервисов осуществляется в разделе «Администрирование» → «Внешние сервисы». ## Конфигурация diff --git a/content/documentation/admin/healthchecks/overview.ru.md b/content/documentation/admin/healthchecks/overview.ru.md index 588fb22..95dfb12 100644 --- a/content/documentation/admin/healthchecks/overview.ru.md +++ b/content/documentation/admin/healthchecks/overview.ru.md @@ -10,7 +10,7 @@ weight: 10 > Если хотя бы одна из проверок завершилась с ошибкой, то статус сущности будет выставлен в **error**, независимо от результата остальных проверок и условия. -Проверка выполнения каждого правила производится раз в минуту. Логи последних нескольких проверок доступны в меню ресурса в разделе `Проверки статуса`. +Проверка выполнения каждого правила производится раз в минуту. Логи последних нескольких проверок доступны в меню ресурса в разделе «Проверки статуса». Возможны четыре варианта статуса: diff --git a/content/documentation/admin/healthchecks/types.ru.md b/content/documentation/admin/healthchecks/types.ru.md index 19d62e3..5d6547b 100644 --- a/content/documentation/admin/healthchecks/types.ru.md +++ b/content/documentation/admin/healthchecks/types.ru.md @@ -147,7 +147,7 @@ conditions: Правило типа **SonarqubeMetrics** выполняет проверку по метрикам проекта в SonarQube на основании заданных условий. -Проверка выполняется с использованием REST API вызова SonarQube `/api/measures/component`, где сравниваются текущие значения указанных метрик c ожидаемыми значениями, заданными в разделе `Условия`. +Проверка выполняется с использованием REST API вызова SonarQube `/api/measures/component`, где сравниваются текущие значения указанных метрик c ожидаемыми значениями, заданными в разделе «Условия». Во всех текстовых полях поддерживается шаблонизация, например, можно подставить ключ компонента из параметров сущности: @@ -233,7 +233,7 @@ conditions: | URL | **Обязательно** | Полный адрес ресурса, к которому будет выполняться запрос | `https://example.com` | | Метод | Опционально | HTTP-метод запроса | GET, POST | | Тело запроса | Опционально | Тело запроса | | -| Ожидаемый статус | **Обязательно** | HTTP статус-код, с которым сравнивается полученный ответ | 200, 204. | +| Ожидаемый статус | **Обязательно** | Код HTTP-статуса, с которым сравнивается полученный ответ | 200, 204. | ### Обработка шаблонов @@ -254,7 +254,7 @@ name: "{{ .entity.name }}" ### Проверка результата -Метод сравнивает фактический HTTP статус ответа с ожидаемым значением. В случае несовпадения возвращается ошибка со значением кода ответа. +Метод сравнивает фактический HTTP-статус ответа с ожидаемым значением. В случае несовпадения возвращается ошибка со значением кода ответа. Учитывайте, что `URL` также может быть динамическим и шаблонизироваться на основе параметров сущности: diff --git a/content/documentation/admin/processes.ru.md b/content/documentation/admin/processes.ru.md index fbcb237..81e3951 100644 --- a/content/documentation/admin/processes.ru.md +++ b/content/documentation/admin/processes.ru.md @@ -130,7 +130,7 @@ moduleStatus: experimental ### Мониторинг -В разделе `История запусков` можно просмотреть: +В разделе «История запусков» можно просмотреть: * Список всех запусков процесса * Детальную информацию о каждом запуске diff --git a/content/documentation/admin/security/audit-logs.ru.md b/content/documentation/admin/security/audit-logs.ru.md index a6b7d32..1ba9e3e 100644 --- a/content/documentation/admin/security/audit-logs.ru.md +++ b/content/documentation/admin/security/audit-logs.ru.md @@ -3,55 +3,54 @@ title: Аудит-логи weight: 40 --- -Аудит-логи — это механизм записи всех операций, выполняемых пользователями через API платформы DDP. Логи сохраняются в базе данных PostgreSQL и используются для аудита действий пользователей. +Аудит-логи — это механизм записи всех операций, выполняемых пользователями через API платформы DDP. +Логи сохраняются в базе данных PostgreSQL и используются для аудита действий пользователей. ## Компоненты -**Компоненты:** DDP Backend, PostgreSQL +В формировании и хранении аудит-логов участвуют следующие компоненты: -**Функции:** -- Функция логирования операций пользователей -- Аудит действий через API -- Отслеживание изменений данных +- **DDP Backend** — формирует записи аудит-логов. +- **PostgreSQL** — обеспечивает хранение данных. -## Что логируется +## Содержимое аудит-логов -Для каждого HTTP запроса (кроме GET) создается запись аудит-лога, содержащая: +Для каждого HTTP-запроса (кроме GET) создается запись аудит-лога, содержащая: -- **Email** — адрес электронной почты пользователя, выполнившего запрос -- **IP** — IP адрес клиента -- **Endpoint** — путь API endpoint -- **Method** — HTTP метод (POST, PUT, DELETE, PATCH) -- **Status** — HTTP статус код ответа -- **Body** — тело HTTP запроса -- **Timestamp** — время выполнения запроса +- **Email** — адрес электронной почты пользователя, выполнившего запрос. +- **IP** — IP-адрес клиента. +- **Endpoint** — путь API, к которому был выполнен запрос. +- **Method** — HTTP-метод запроса (POST, PUT, DELETE, PATCH). +- **Status** — HTTP-код ответа. +- **Body** — тело HTTP-запроса. +- **Timestamp** — время выполнения запроса. ## Принцип работы -Аудит-логи создаются автоматически через middleware в DDP Backend для всех HTTP запросов, кроме GET. +Аудит-логи формируются автоматически в DDP Backend с использованием промежуточного слоя обработки запросов (middleware) для всех HTTP-запросов, кроме GET. -**Параметры буферизации:** -- Размер батча: 40 записей -- Интервал записи: 20 секунд -- Размер буфера в памяти: 4 записи - -Логи хранятся в партиционированной таблице PostgreSQL, разделенной по дням. Партиции создаются автоматически на 7 дней вперед. Ежедневно в 00:00 UTC запускается задача, которая создает партиции на следующие 7 дней. +Для снижения нагрузки на базу данных используется буферизация записей со следующими параметрами: +- Размер батча — 40 записей. +- Интервал записи — 20 секунд. +- Размер буфера в памяти — 4 записи. ## Хранение -Аудит-логи хранятся в таблице `audit_logs` в базе данных PostgreSQL. Таблица партиционирована по полю `timestamp` с разделением по дням. +Аудит-логи хранятся в таблице audit_logs базы данных PostgreSQL. Таблица партиционирована на основе поля `timestamp` с разделением по дням. + +Структура таблицы поддерживается автоматически: ежедневно в 00:00 по серверному времени подготавливается пространство для записи логов на следующие 7 дней. -**Время хранения:** Логи хранятся неограниченно долго. Автоматическая очистка старых записей не выполняется. Для управления временем хранения необходимо настроить автоматическое удаление старых партиций через внешние инструменты (например, cron задачи или скрипты очистки базы данных). +Логи хранятся неограниченно долго. Автоматическая очистка старых записей не выполняется. Для управления временем хранения необходимо настроить автоматическое удаление старых групп логов через внешние инструменты (например, cron-задачи или скрипты очистки базы данных). ## Просмотр логов -Аудит-логи доступны через веб-интерфейс в разделе **Администрирование** → **Аудит**. Логи можно фильтровать по: -- Email пользователя -- IP адресу -- Endpoint -- Методу запроса -- Статусу ответа +Аудит-логи доступны через веб-интерфейс в разделе «Администрирование» → «Аудит». Логи можно фильтровать по следующим параметрам: +- Email пользователя. +- IP-адрес. +- Эндпоинт. +- Метод запроса. +- Статус ответа. ## Настройка -Механизм аудит-логирования работает автоматически, дополнительная настройка не требуется. Для управления временем хранения логов необходимо настроить автоматическое удаление старых партиций базы данных. +Механизм аудит-логирования включён по умолчанию и не требует дополнительной настройки. Для управления временем хранения логов необходимо настроить автоматическое удаление старых партиций базы данных. diff --git a/content/documentation/admin/security/credentials.ru.md b/content/documentation/admin/security/credentials.ru.md index c73827a..0eb3e3d 100644 --- a/content/documentation/admin/security/credentials.ru.md +++ b/content/documentation/admin/security/credentials.ru.md @@ -9,14 +9,14 @@ weight: 30 ### Типы учетных данных -Администратор платформы создает типы учетных данных в разделе **Администрирование** → **Учетные данные**. Каждый тип имеет: -- **Название** — отображаемое название типа -- **Идентификатор** — уникальный идентификатор для использования в конфигурациях -- **Описание** — подсказка для пользователей +Администратор платформы создает типы учетных данных в разделе «Администрирование» → «Учетные данные». Каждый тип имеет: +- **Название** — отображаемое название типа. +- **Идентификатор** — уникальный идентификатор для использования в конфигурациях. +- **Описание** — подсказка для пользователей. ### Учетные данные пользователей -Пользователи заполняют свои персональные учетные данные в разделе **Профиль** → **Учетные данные**. Для каждого типа учетных данных пользователь может указать свое значение (например, токен доступа, пароль, ключ API). +Пользователи заполняют свои персональные учетные данные в разделе «Профиль» → «Учетные данные». Для каждого типа учетных данных пользователь может указать свое значение (например, токен доступа, пароль, ключ API). После сохранения пользователь не может просмотреть значение учетных данных, только обновить его. В профиле отображается информация о том, заполнены ли те или иные учетные данные. @@ -25,10 +25,10 @@ weight: 30 Учетные данные хранятся в базе данных 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:`, что позволяет системе определить метод шифрования при расшифровке. @@ -36,10 +36,6 @@ weight: 30 При изменении ключа шифрования (`security.secretKey`) в конфигурации все текущие учетные данные станут невалидными и не смогут быть расшифрованы. {{< /alert >}} -### Хранение в HashiCorp Vault - -В разработке находится механизм, позволяющий хранить учетные данные во внешнем хранилище, совместимом с HashiCorp Vault, вместо базы данных PostgreSQL. - ### Использование учетных данных Учетные данные расшифровываются только при необходимости их использования, непосредственно перед обращением к внешнему сервису. После использования расшифрованные значения не сохраняются в памяти дольше необходимого. @@ -49,21 +45,21 @@ weight: 30 ### Действия В конфигурации действия можно указать список требуемых учетных данных через поле **Учетные данные**. Каждое учетное данное определяется: -- **Идентификатор** — идентификатор учетного данного (соответствует идентификатору типа учетных данных) -- **Тип учетных данных** — выбор типа учетных данных из списка +- **Идентификатор** — идентификатор учетного данного (соответствует идентификатору типа учетных данных). +- **Тип учетных данных** — выбор типа учетных данных из списка. При выполнении действия система: -1. Определяет пользователя, от имени которого выполняется действие (инициатор или учетная запись, выбранная в поле **"Учётная запись для запуска"**, если включена опция **"Выбрать учётную запись для запуска"**) -2. Извлекает учетные данные этого пользователя из базы данных -3. Расшифровывает значения учетных данных -4. Подставляет расшифрованные значения в шаблоны конфигурации действия (URL, заголовки, тело запроса) через плейсхолдеры вида `{{.credentials.идентификатор}}` +1. Определяет пользователя, от имени которого выполняется действие (инициатор или учетная запись, выбранная в поле **«Учётная запись для запуска»**, если включена опция **«Выбрать учётную запись для запуска»**). +1. Извлекает учетные данные этого пользователя из базы данных. +1. Расшифровывает значения учетных данных. +1. Подставляет расшифрованные значения в шаблоны конфигурации действия (URL, заголовки, тело запроса) через плейсхолдеры вида `{{.credentials.идентификатор}}`. ### Источники данных В конфигурации источника данных можно указать список требуемых учетных данных аналогично действиям. При синхронизации данных система: -1. Использует учетные данные системного пользователя, указанного в конфигурации источника данных (поле **"Системная учетная запись"**) -2. Извлекает и расшифровывает учетные данные системного пользователя -3. Подставляет значения в шаблоны запросов источника данных +1. Использует учетные данные системного пользователя, указанного в конфигурации источника данных (поле **«Системная учетная запись»**). +1. Извлекает и расшифровывает учетные данные системного пользователя. +1. Подставляет значения в шаблоны запросов источника данных. {{< alert level="warning" >}} Источники данных всегда используют учетные данные системного пользователя, а не инициатора запуска синхронизации. @@ -72,16 +68,16 @@ weight: 30 ### Виджеты Виджеты могут использовать учетные данные для получения данных из внешних сервисов. Механизм работы аналогичен действиям: -1. Определяется пользователь (инициатор запроса или учетная запись, выбранная в поле **"Учётная запись для виджета"**, если включена опция **"Выбрать учётную запись для виджета"**) -2. Извлекаются и расшифровываются учетные данные -3. Значения подставляются в конфигурацию виджета +1. Определяется пользователь (инициатор запроса или учетная запись, выбранная в поле **"Учётная запись для виджета"**, если включена опция **"Выбрать учётную запись для виджета"**). +2. Извлекаются и расшифровываются учетные данные. +3. Значения подставляются в конфигурацию виджета. ### Проверки статуса Проверки статуса используют учетные данные для выполнения проверок состояния сущностей. В конфигурации правил проверки статуса можно указать список требуемых учетных данных. При выполнении проверки система: -1. Использует учетные данные системного пользователя, указанного в конфигурации правила проверки статуса (поле **"Системная учетная запись"**) -2. Извлекает и расшифровывает учетные данные системного пользователя -3. Подставляет значения в шаблоны конфигурации правила (URL, заголовки, параметры запросов) через плейсхолдеры вида `{{.credentials.идентификатор}}` +1. Использует учетные данные системного пользователя, указанного в конфигурации правила проверки статуса (поле **«Системная учетная запись»**). +1. Извлекает и расшифровывает учетные данные системного пользователя. +1. Подставляет значения в шаблоны конфигурации правила (URL, заголовки, параметры запросов) через плейсхолдеры вида `{{.credentials.идентификатор}}`. {{< alert level="warning" >}} Проверки статуса всегда используют учетные данные системного пользователя, указанного в конфигурации правила. Если системный пользователь не указан, правило пропускается при выполнении проверки. @@ -89,9 +85,9 @@ weight: 30 ### Внешние сервисы -Внешние сервисы могут иметь собственный список учетных данных. Если действие, источник данных или виджет использует внешний сервис (включена опция **"Использовать внешний сервис"**), то: -1. Учетные данные из конфигурации внешнего сервиса наследуются компонентом, если в его конфигурации не указаны собственные учетные данные -2. Приоритет имеют учетные данные, указанные непосредственно в конфигурации компонента +Внешние сервисы могут иметь собственный список учетных данных. Если действие, источник данных или виджет использует внешний сервис (включена опция **«Использовать внешний сервис»**), то: +1. Учетные данные из конфигурации внешнего сервиса наследуются компонентом, если в его конфигурации не указаны собственные учетные данные. +1. Приоритет имеют учетные данные, указанные непосредственно в конфигурации компонента. ## Настройка @@ -105,13 +101,13 @@ security: ``` **Требования к ключу:** -- Длина: 16, 24 или 32 байта (128, 192 или 256 бит) -- Символы: только печатаемые ASCII символы -- Не должен быть слабым или часто используемым ключом -- Не должен состоять из одного повторяющегося символа +- Длина: 16, 24 или 32 байта (128, 192 или 256 бит). +- Только печатаемые ASCII символы. +- Не должен быть слабым или часто используемым ключом. +- Не должен состоять из одного повторяющегося символа. ## Безопасность -- Учетные данные никогда не передаются пользователю в расшифрованном виде -- Расшифровка происходит только непосредственно перед отправкой запроса -- Расшифрованные значения не логируются +- Учетные данные никогда не передаются пользователю в расшифрованном виде. +- Расшифровка происходит только непосредственно перед отправкой запроса. +- Расшифрованные значения не логируются. diff --git a/content/documentation/admin/security/http-security-headers.ru.md b/content/documentation/admin/security/http-security-headers.ru.md index 81efc16..de2ee10 100644 --- a/content/documentation/admin/security/http-security-headers.ru.md +++ b/content/documentation/admin/security/http-security-headers.ru.md @@ -3,37 +3,37 @@ title: HTTP-заголовки безопасности weight: 50 --- -DDP поддерживает следующие заголовки HTTP для повышения безопасности взаимодействия: +DDP поддерживает следующие HTTP-заголовки для повышения безопасности взаимодействия: -1. **Content Security Policy** - - Настраиваемая политика безопасности контента - - Подробное описание см. в разделе [Content Security Policy](#content-security-policy) +1. **Content-Security-Policy** + - Настраиваемая политика безопасности контента. + - Подробное описание приведено в разделе [Content Security Policy](#content-security-policy). -2. **X Frame Options** - - Защита от clickjacking атак - - По умолчанию: `SAMEORIGIN` - - Настраивается в конфигурации DDP в секции `security.headers.xFrameOptions` - - Возможные значения: `DENY`, `SAMEORIGIN` +2. **X-Frame-Options** + - Защита от clickjacking-атак. + - Значение по умолчанию: `SAMEORIGIN`. + - Настраивается в конфигурации DDP в секции `security.headers.xFrameOptions`. + - Возможные значения: `DENY`, `SAMEORIGIN`. -3. **X Content Type Options** - - Предотвращение MIME-sniffing - - Значение: `nosniff` +3. **X-Content-Type-Options** + - Предотвращение MIME-sniffing. + - Значение: `nosniff`. -4. **X XSS Protection** - - Защита от XSS атак (для старых браузеров) - - Значение: `1; mode=block` +4. **X-XSS-Protection** + - Защита от XSS-атак (для устаревших браузеров). + - Значение: `1; mode=block`. -5. **Referrer Policy** - - Контроль передачи информации о реферере - - Значение: `strict-origin-when-cross-origin` +5. **Referrer-Policy** + - Контроль передачи информации о реферере. + - Значение: `strict-origin-when-cross-origin`. -6. **Permissions Policy** (ранее Feature Policy) - - Отключение неиспользуемых функций браузера - - Значение: `geolocation=(), microphone=(), camera=(), payment=(), usb=(), magnetometer=(), gyroscope=(), accelerometer=()` +6. **Permissions-Policy** (ранее Feature-Policy) + - Ограничение использования функций браузера. + - Значение: `geolocation=(), microphone=(), camera=(), payment=(), usb=(), magnetometer=(), gyroscope=(), accelerometer=()`. -7. **Strict Transport Security (HSTS)** - - Принудительное использование HTTPS - - Значение: `max-age=31536000; includeSubDomains; preload` +7. **Strict-Transport-Security (HSTS)** + - Принудительное использование HTTPS. + - Значение: `max-age=31536000; includeSubDomains; preload`. ## Конфигурация @@ -42,25 +42,25 @@ DDP поддерживает следующие заголовки HTTP для ```yaml security: headers: - # Включить/выключить все заголовки безопасности + # Включить/выключить все заголовки безопасности. enabled: true csp: - # Разрешить загрузку изображений из внешних источников + # Разрешить загрузку изображений из внешних источников. allowExternalImages: false - # Разрешить использование iframe виджетов + # Разрешить использование iframe виджетов. allowIframe: false - # Дополнительные источники, добавляемые к директивам CSP: img-src, connect-src, frame-src, frame-ancestors. Например: https://example.com + # Дополнительные источники, добавляемые к директивам CSP: img-src, connect-src, frame-src, frame-ancestors. Например: https://example.com. additionalSources: "" - # Значение заголовка X-Frame-Options (DENY или SAMEORIGIN) + # Значение заголовка X-Frame-Options (DENY или SAMEORIGIN). xFrameOptions: "SAMEORIGIN" ``` -Опция `enabled` управляет включением или отключением всех заголовков безопасности. При значении `true` все заголовки добавляются к HTTP ответам, при `false` — заголовки не добавляются. +Опция enabled определяет включение или отключение всех заголовков безопасности. При значении true заголовки добавляются к HTTP-ответам, при значении false — заголовки не добавляются. -## Где применяются +## Применение -- **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. @@ -90,6 +90,6 @@ upgrade-insecure-requests {{< alert level="info" >}} Отключение или ослабление политик может потребоваться в следующих случаях: -- Использование iframe виджетов (требует настройки `allowIframe: true`) -- Добавление иконок из внешних источников для объектов DDP (требует настройки `allowExternalImages: true`) +- Использование iframe виджетов (требует настройки `allowIframe: true`). +- Добавление иконок из внешних источников для объектов DDP (требует настройки `allowExternalImages: true`). {{< /alert >}} diff --git a/content/documentation/admin/security/overview.ru.md b/content/documentation/admin/security/overview.ru.md index 0641a37..fefa228 100644 --- a/content/documentation/admin/security/overview.ru.md +++ b/content/documentation/admin/security/overview.ru.md @@ -3,81 +3,51 @@ title: Обзор weight: 10 --- -В DDP реализованы различные механизмы безопасности для защиты данных и предотвращения несанкционированного доступа. Ниже представлен обзор основных механизмов безопасности платформы. +DDP предоставляет набор встроенных механизмов безопасности, обеспечивающих контроль доступа, защиту учетных данных и аудит действий пользователей при работе с платформой. ## Аутентификация -**Компоненты:** Dex (внешний компонент DKP), DDP Backend +Аутентификация пользователей в DDP выполняется с использованием внешнего сервиса Dex, развернутого в составе Deckhouse Kubernetes Platform. -**Функции:** -- Аутентификация пользователей -- Выдача токенов доступа -- Проверка токенов доступа - -**Принцип работы:** -DDP Backend получает ключи подписи от Dex для проверки JWT токенов пользователей. Dex интегрируется с внешними провайдерами аутентификации (Keycloak, LDAP и др.) через стандартные протоколы (OIDC, LDAP). - -**Настройка:** Dex настраивается в составе DKP (Deckhouse Kubernetes Platform). DDP Backend автоматически использует ключи подписи от Dex для проверки токенов. +Dex обеспечивает интеграцию с внешними провайдерами аутентификации (Keycloak, LDAP и другими) через стандартные протоколы OIDC и LDAP. +DDP Backend использует ключи подписи, получаемые от Dex, для проверки JWT-токенов и аутентификации запросов к API. Настройка выполняется на стороне DKP, дополнительная настройка в DDP не требуется. ## Ролевая модель (RBAC) -**Компоненты:** DDP Backend - -**Функции:** -- Функция разграничения доступа -- Контроль действий пользователей -- Управление правами доступа к объектам платформы +В DDP реализована ролевая модель доступа, обеспечивающая разграничение прав пользователей и контроль операций, выполняемых в платформе. -**Принцип работы:** -Ролевая модель использует иерархическую систему проверки разрешений на уровне супер-администратора, глобальных ролей, ролей ресурсов и ролей сущностей. - -**Настройка:** Подробнее см. в [документации по ролевой модели](../rbac/). +Модель поддерживает иерархию ролей и проверку разрешений на уровне супер-администратора, глобальных ролей, ролей ресурсов и ролей сущностей. +Подробнее — в [документации по ролевой модели](../rbac/). ## Учетные данные -**Компоненты:** DDP Backend, PostgreSQL - -**Функции:** -- Безопасное хранение учетных данных пользователей -- Шифрование и расшифровка учетных данных -- Интеграция учетных данных в действия, источники данных и виджеты +DDP обеспечивает централизованное и безопасное хранение учетных данных, используемых для интеграции с внешними системами и сервисами. Хранение и обработка учетных данных выполняются на стороне DDP Backend с использованием базы данных PostgreSQL. -**Принцип работы:** -Учетные данные шифруются перед сохранением в базе данных с использованием алгоритма AES-GCM и расшифровываются только при необходимости их использования. - -**Настройка:** Подробнее см. в [документации по учетным данным](../credentials/). +Перед сохранением в базе данных учетные данные шифруются с применением алгоритма AES-GCM. Расшифровка выполняется DDP Backend только в момент использования учетных данных в действиях, источниках данных или виджетах. +Подробнее — в [документации по учетным данным](../credentials/). ## Аудит-логи -**Компоненты:** DDP Backend, PostgreSQL - -**Функции:** -- Функция логирования операций пользователей -- Аудит действий через API +Аудит-логи предназначены для регистрации действий пользователей и контроля операций, выполняемых через API платформы. Формирование аудит-логов выполняется на стороне DDP Backend. -**Принцип работы:** -Аудит-логи создаются автоматически для всех HTTP запросов (кроме GET) и содержат информацию о пользователе, IP адресе, endpoint, методе, статусе ответа и теле запроса. +Такие логи создаются автоматически для всех HTTP-запросов, за исключением GET. Каждая запись содержит информацию о пользователе, IP-адресе клиента, эндпоинте, HTTP-методе и статусе ответа. -**Настройка:** Подробнее см. в [документации по аудит-логам](../audit-logs/). +Аудит-логи сохраняются в базе данных PostgreSQL и доступны для просмотра через веб-интерфейс платформы. +Подробнее — в [документации по аудит-логам](../audit-logs/). ## HTTP-заголовки безопасности -**Компоненты:** DDP Frontend, DDP Backend - -**Функции:** -- Защита от XSS атак -- Защита от clickjacking атак -- Предотвращение MIME-sniffing -- Контроль передачи информации о реферере -- Принудительное использование HTTPS - -**Реализованные заголовки:** -- Content Security Policy (CSP) -- X-Frame-Options -- X-Content-Type-Options -- X-XSS-Protection -- Referrer-Policy -- Permissions-Policy -- Strict-Transport-Security (HSTS) - -**Настройка:** В конфигурации DDP в секции `security.headers`. Подробнее см. в [документации по HTTP заголовкам безопасности](../http-security-headers/). +Для защиты веб-интерфейса и API платформы DDP используются стандартные HTTP-заголовки безопасности. +Их формирование и применение выполняется на стороне DDP Frontend и DDP Backend. +Заголовки направлены на снижение рисков XSS-атак, clickjacking, предотвращения MIME-sniffing, контроля передачи информации о реферере, а также на принудительное использование защищённого соединения HTTPS. + +В платформе применяются следующие HTTP-заголовки безопасности: +- Content Security Policy (CSP). +- X-Frame-Options. +- X-Content-Type-Options. +- X-XSS-Protection. +- Referrer-Policy. +- Permissions-Policy. +- Strict-Transport-Security (HSTS). + +Настройка осуществляется в конфигурации DDP в секции `security.headers`. Подробнее — в [документации по HTTP-заголовкам безопасности](../http-security-headers/). diff --git a/content/documentation/admin/security/rbac.ru.md b/content/documentation/admin/security/rbac.ru.md index f5ea5a0..f428c21 100644 --- a/content/documentation/admin/security/rbac.ru.md +++ b/content/documentation/admin/security/rbac.ru.md @@ -3,28 +3,23 @@ title: Ролевая модель weight: 20 --- -Ролевая модель в DDP — это система управления доступом, которая обеспечивает безопасность и контроль над действиями пользователей в платформе. Ролевая модель позволяет администраторам гибко настраивать права доступа для разных пользователей и команд, обеспечивая принцип минимальных привилегий и централизованное управление безопасностью. +Ролевая модель DDP определяет, какие действия пользователи могут выполнять в платформе и к каким объектам они имеют доступ. Модель используется для разграничения прав при работе с API и веб-интерфейсом и применяется на уровне платформы в целом и отдельных объектов. -## Зачем нужна ролевая модель - -Ролевая модель решает следующие задачи: - -- **Безопасность данных** — предотвращает несанкционированный доступ к конфиденциальной информации -- **Контроль действий** — ограничивает возможности пользователей только необходимыми операциями -- **Упрощение управления** — позволяет назначать права группам пользователей через команды -- **Соответствие требованиям** — обеспечивает соблюдение политик безопасности организации +Ролевая модель реализована в DDP Backend и использует базу данных PostgreSQL для хранения ролей, разрешений и их связей. ## Компоненты ролевой модели Ролевая модель состоит из следующих компонентов: -* **Разрешение** - соответствует конкретному действию в DDP. -* **Роль** - объединяет в себе набор тех или иных разрешений. -* **Привязка роли** - связывает роль и пользователей, либо команды. +* **Разрешение** — соответствует конкретному действию в DDP. +* **Роль** — объединяет в себе набор тех или иных разрешений. +* **Привязка роли** — связывает роль и пользователей, либо команды. Для каждого объекта DDP существует свой набор разрешений, ролей и привязок ролей. Также есть глобальные роли, разрешения и привязки ролей, которые разрешают операции на глобальном уровне. -**Важно:** Если у пользователя нет соответствующих разрешений, он не сможет выполнять никакие операции на платформе. Система проверяет разрешения для каждой операции. +{{< alert level="info" >}} +Если у пользователя нет соответствующих разрешений, он не сможет выполнять никакие операции на платформе. Система проверяет разрешения для каждой операции. +{{< /alert >}} ## Типы объектов и разрешения @@ -32,117 +27,133 @@ weight: 20 Глобальные разрешения действуют на уровне всей платформы и предоставляют доступ ко всем объектам определенного типа: -Ресурсы: -- `create:resources` - создание ресурсов -- `read:resources` - просмотр ресурсов -- `update:resources` - редактирование ресурсов -- `delete:resources` - удаление ресурсов +РРесурсы: +- `create:resources` — создание ресурсов. +- `read:resources` — просмотр ресурсов. +- `update:resources` — редактирование ресурсов. +- `delete:resources` — удаление ресурсов. Сущности: -- `create:entities` - создание сущностей -- `read:entities` - просмотр сущностей -- `update:entities` - редактирование сущностей -- `delete:entities` - удаление сущностей +- `create:entities` — создание сущностей. +- `read:entities` — просмотр сущностей. +- `update:entities` — редактирование сущностей. +- `delete:entities` — удаление сущностей. Источники данных: -- `create:datasources` - создание источников данных -- `read:datasources` - просмотр источников данных -- `update:datasources` - редактирование источников данных -- `sync:datasources` - синхронизация источников данных -- `delete:datasources` - удаление источников данных +- `create:datasources` — создание источников данных. +- `read:datasources` — просмотр источников данных. +- `update:datasources` — редактирование источников данных. +- `sync:datasources` — синхронизация источников данных. +- `delete:datasources` — удаление источников данных. Действия: -- `create:actions` - создание действий -- `read:actions` - просмотр действий -- `update:actions` - редактирование действий -- `run:actions` - выполнение действий -- `delete:actions` - удаление действий +- `create:actions` — создание действий. +- `read:actions` — просмотр действий. +- `update:actions` — редактирование действий. +- `run:actions` — выполнение действий. +- `delete:actions` — удаление действий. Автоматизации: -- `create:automations` - создание автоматизаций -- `read:automations` - просмотр автоматизаций -- `update:automations` - редактирование автоматизаций -- `delete:automations` - удаление автоматизаций +- `create:automations` — создание автоматизаций. +- `read:automations` — просмотр автоматизаций. +- `update:automations` — редактирование автоматизаций. +- `delete:automations` — удаление автоматизаций. Рабочие процессы: -- `create:workflows` - создание рабочих процессов -- `read:workflows` - просмотр рабочих процессов -- `update:workflows` - редактирование рабочих процессов -- `delete:workflows` - удаление рабочих процессов +- `create:workflows` — создание рабочих процессов. +- `read:workflows` — просмотр рабочих процессов. +- `update:workflows` — редактирование рабочих процессов. +- `delete:workflows` — удаление рабочих процессов. Вебхуки: -- `create:webhooks` - создание вебхуков -- `read:webhooks` - просмотр вебхуков -- `update:webhooks` - редактирование вебхуков -- `delete:webhooks` - удаление вебхуков +- `create:webhooks` — создание вебхуков. +- `read:webhooks` — просмотр вебхуков. +- `update:webhooks` — редактирование вебхуков. +- `delete:webhooks` — удаление вебхуков. Виджеты: -- `create:widgets` - создание виджетов -- `read:widgets` - просмотр виджетов -- `update:widgets` - редактирование виджетов -- `run:widget-actions` - выполнение действий виджетов -- `delete:widgets` - удаление виджетов +- `create:widgets` — создание виджетов. +- `read:widgets` — просмотр виджетов. +- `update:widgets` — редактирование виджетов. +- `run:widget-actions` — выполнение действий виджетов. +- `delete:widgets` — удаление виджетов. Дашборды: -- `create:dashboards` - создание дашбордов -- `read:dashboards` - просмотр дашбордов -- `update:dashboards` - редактирование дашбордов -- `delete:dashboards` - удаление дашбордов +- `create:dashboards` — создание дашбордов. +- `read:dashboards` — просмотр дашбордов. +- `update:dashboards` — редактирование дашбордов. +- `delete:dashboards` — удаление дашбордов. Внешние сервисы: -- `create:external-services` - создание внешних сервисов -- `read:external-services` - просмотр внешних сервисов -- `update:external-services` - редактирование внешних сервисов -- `delete:external-services` - удаление внешних сервисов +- `create:external-services` — создание внешних сервисов. +- `read:external-services` — просмотр внешних сервисов. +- `update:external-services` — редактирование внешних сервисов. +- `delete:external-services` — удаление внешних сервисов. Процессы: -- `create:processes` - создание процессов -- `read:processes` - просмотр процессов -- `update:processes` - редактирование процессов -- `delete:processes` - удаление процессов +- `create:processes` — создание процессов. +- `read:processes` — просмотр процессов. +- `update:processes` — редактирование процессов. +- `delete:processes` — удаление процессов. + +Команды: +- `create:teams` — создание команд. +- `update:teams` — редактирование команд. +- `delete:teams` — удаление команд. +- `update:team-variables` — редактирование переменных команд. + +Иконки: +- `create:icons` — создание иконок. +- `delete:icons` — удаление иконок. + +{{< alert level="info" >}} +Разрешение `update:team-variables` позволяет редактировать переменные только тех команд, участником которых является пользователь. Даже супер-администратор не сможет изменить переменные команд, в которых не состоит. +{{< /alert >}} #### Разрешения на просмотр страниц Разрешения `view:` контролируют доступ к различным разделам интерфейса платформы: - `view:admin-page` - доступ к разделу "Администрирование" -- `view:self-service-page` - доступ к разделу "Self Service" +- `view:self-service-page` - доступ к разделу "Самообслуживание" -**Важно:** Без соответствующих `view:` разрешений пользователь не сможет увидеть соответствующие разделы в навигационном меню, даже если у него есть другие разрешения для работы с объектами в этих разделах. +{{< alert level="info" >}} +Без соответствующих `view:` разрешений пользователь не сможет увидеть разделы в навигационном меню, даже если у него есть другие разрешения для работы с объектами в этих разделах. +{{< /alert >}} ### Разрешения на уровне объектов Для каждого типа объекта существуют разрешения, которые действуют только на конкретный объект: Для ресурсов: -- `read:resource` - просмотр конкретного ресурса -- `update:resource` - редактирование конкретного ресурса -- `delete:resource` - удаление конкретного ресурса -- `create:entities` - создание сущностей ресурса -- `read:entities` - просмотр сущностей ресурса -- `update:entities` - редактирование сущностей ресурса -- `delete:entities` - удаление сущностей ресурса -- `run:actions` - выполнение действий для сущностей ресурса -- `control:processes` - управление процессами для сущностей ресурса -- `edit:role-bindings` - редактирование привязок ролей для ресурса +- `read:resource` — просмотр конкретного ресурса. +- `update:resource` — редактирование конкретного ресурса. +- `delete:resource` — удаление конкретного ресурса. +- `create:entities` — создание сущностей ресурса. +- `read:entities` — просмотр сущностей ресурса. +- `update:entities` — редактирование сущностей ресурса. +- `delete:entities` — удаление сущностей ресурса. +- `run:actions` — выполнение действий для сущностей ресурса. +- `control:processes` — управление процессами для сущностей ресурса. +- `edit:role-bindings` — редактирование привязок ролей для ресурса. Для сущностей: -- `read:entity` - просмотр конкретной сущности -- `update:entity` - редактирование конкретной сущности -- `delete:entity` - удаление конкретной сущности -- `run:actions` - выполнение действий для сущности -- `control:processes` - управление процессами для сущности -- `edit:role-bindings` - редактирование привязок ролей для сущности - -Для других объектов (действия, автоматизации, процессы, вебхуки, виджеты, дашборды, внешние сервисы и т.д.): -- `read:[object-type]` - просмотр объекта -- `update:[object-type]` - редактирование объекта -- `delete:[object-type]` - удаление объекта -- `edit:role-bindings` - редактирование привязок ролей для объекта +- `read:entity` — просмотр конкретной сущности. +- `update:entity` — редактирование конкретной сущности. +- `delete:entity` — удаление конкретной сущности. +- `run:actions` — выполнение действий для сущности. +- `control:processes` — управление процессами для сущности. +- `edit:role-bindings` — редактирование привязок ролей для сущности. + +Для других объектов (действия, автоматизации, процессы, вебхуки, виджеты, дашборды, внешние сервисы и т. д.): +- `read:[object-type]` — просмотр объекта. +- `update:[object-type]` — редактирование объекта. +- `delete:[object-type]` — удаление объекта. +- `edit:role-bindings` — редактирование привязок ролей для объекта. ## Иерархия проверки разрешений -Ролевая модель иерархическая, например для того, чтобы проверить, можно ли изменять пользователю конкретную сущность будет выполняться следующая последовательность действий: +Ролевая модель иерархическая, при обработке запроса DDP Backend проверяет права доступа в определенном порядке. Например для того, чтобы проверить, можно ли изменять пользователю конкретную сущность, будет выполняться следующая последовательность действий: ### 1. Супер-администратор @@ -172,163 +183,177 @@ weight: 20 Если ни на одном уровне не было найдено соответствующего разрешения, то действие будет запрещено. -**Примечание:** Проверка владения включается только если в конфигурации платформы включена опция `ownerIsAdmin`. Подробнее о владении объектами см. раздел [Владение объектами](#владение-объектами). +{{< alert level="info" >}} +Проверка владения включается только если в конфигурации платформы включена опция `ownerIsAdmin`. Подробнее о владении объектами — в разделе [«Владение объектами»](#владение-объектами). +{{< /alert >}} ## Владение объектами Владение объектами — это механизм, который позволяет пользователям и командам становиться владельцами определённых объектов в системе и автоматически получать все права администратора на эти объекты. -### Кто такой владелец - -**Владелец объекта** — это пользователь или команда, которая была назначена владельцем конкретного объекта. +Владелец объекта — это пользователь или команда, которая была назначена владельцем конкретного объекта. -### Как владение влияет на права доступа +### Влияние владения на права доступа -Владение объектом предоставляет полные права администратора на этот объект, если включена опция `ownerIsAdmin` в конфигурации платформы. Это означает, что: +При включённой опции `ownerIsAdmin` владелец объекта получает все права администратора для этого объекта. В этом случае владелец может: -- **Владелец объекта** получает полный доступ для чтения, редактирования и удаления объекта -- **Владелец может редактировать привязки ролей** для объекта, управляя доступом других пользователей -- **Владелец может выполнять любые действия** с объектом +- читать, изменять и удалять объект; +- управлять привязками ролей и доступом других пользователей; +- выполнять любые действия, доступные администратору объекта. ### Опция OwnerAsAdmin -В конфигурации платформы доступна опция `ownerIsAdmin`, которая контролирует применение прав владения: +Опция `ownerIsAdmin` задаёт поведение прав доступа для владельцев объектов. - **Включена (true)** — владельцы объектов получают полные права администратора на свои объекты - **Отключена (false)** — владельцы объектов не получают автоматических прав; доступ контролируется только через роли -**Важно:** Опция `ownerIsAdmin` должна быть настроена администратором платформы в конфигурационном файле. По умолчанию опция выключена. +{{< alert level="info" >}} +Опция `ownerIsAdmin` должна быть настроена администратором платформы в конфигурационном файле. По умолчанию опция выключена. +{{< /alert >}} + +### Автоматическое назначение владельца при создании + +При создании нового объекта (действия, источника данных, виджета, ресурса и других объектов) платформа автоматически устанавливает текущего пользователя в качестве владельца объекта. При необходимости можно переназначить владельца, либо создать объект без владельца. ### Примеры использования владения #### Владение ресурсом Если пользователь создаёт ресурс, он автоматически становится его владельцем. При включенной опции `ownerIsAdmin` он получает все права администратора на этот ресурс, включая: -- Управление сущностями ресурса -- Настройку привязок ролей -- Полное редактирование и удаление ресурса +- Управление сущностями ресурса. +- Настройку привязок ролей. +- Полное редактирование и удаление ресурса. #### Владение сущностью Если пользователь создаёт сущность, он становится её владельцем и может: -- Просматривать и редактировать сущность -- Управлять привязками ролей для сущности -- Удалять сущность +- Просматривать и редактировать сущность. +- Управлять привязками ролей для сущности. +- Удалять сущность. #### Команда-владелец -Если объект принадлежит команде, все участники этой команды получают права администратора на объект при включенной опции `ownerIsAdmin`. +Если владельцем объекта назначена команда, то при включенной опции `ownerIsAdmin` все участники этой команды получают права администратора на объект. ## Роль по умолчанию -Платформа позволяет назначить одну глобальную роль по умолчанию. Разрешения этой роли применяются ко всем авторизованным пользователям. Роль по умолчанию задается в разделе "Администрирование / Управление доступом" переключателем в таблице "Роли". +Платформа позволяет назначить одну глобальную роль по умолчанию, разрешения к которой применяются ко всем авторизованным пользователям. Настройка выполняется в разделе «Администрирование → Управление доступом» с помощью переключателя в таблице «Роли». -**Важно:** Ролью по умолчанию может быть назначена только глобальная роль. +Ролью по умолчанию может быть назначена только глобальная роль. ## Команды -Команды позволяют группировать пользователей и назначать им роли коллективно. Пользователь может состоять в нескольких командах, в этом случае его разрешения будут объединены из всех команд, в которых он состоит. +Команды используются для группировки пользователей и коллективного назначения ролей. Пользователь может состоять в нескольких командах, в этом случае его разрешения будут объединены из всех команд, в которых он состоит. -**Важно:** Команды и их состав синхронизируются из внешней системы аутентификации (Dex). Управление командами через интерфейс DDP недоступно. +{{< alert level="info" >}} +Команды и их состав синхронизируются из внешней системы аутентификации (Dex). Управление командами через интерфейс DDP недоступно. +{{< /alert >}} ## Настройка ролей и управление доступом ### Создание роли -1. Перейдите в раздел `Администрирование -> Управление доступом` -2. Выберите вкладку "Роли" -3. Нажмите кнопку "Создать роль" -4. Заполните форму: - - Название - уникальное название роли - - Описание - описание назначения роли - - Тип объекта - выберите уровень действия роли: - - `Глобальные` - для глобальных разрешений - - `Ресурсы` - для разрешений на уровне ресурсов - - `Сущности` - для разрешений на уровне сущностей - - `Действия` - для разрешений на уровне действий - - И другие типы объектов - - Разрешения - выберите необходимые разрешения из списка -5. Нажмите "Сохранить" +1. Перейдите в раздел «Администрирование -> Управление доступом». +1. Выберите вкладку «Роли». +1. Нажмите кнопку «Создать роль». +1. Заполните форму: + - Название - уникальное название роли. + - Описание - описание назначения роли. + - Тип объекта - выберите уровень действия роли: + - `Глобальные` - для глобальных разрешений. + - `Ресурсы` - для разрешений на уровне ресурсов. + - `Сущности` - для разрешений на уровне сущностей. + - `Действия` - для разрешений на уровне действий. + - И другие типы объектов. + - Разрешения - выберите необходимые разрешения из списка. +1. Нажмите «Сохранить». ### Назначение роли пользователям -1. Перейдите в раздел `Администрирование -> Управление доступом` -2. Выберите вкладку "Привязки ролей" -3. Нажмите кнопку "Создать привязку роли" -4. Заполните форму: - - Название - название привязки роли - - Описание - описание назначения привязки - - Роль - выберите созданную роль - - Объект - выберите конкретный объект (если роль не глобальная) - - Пользователи - добавьте пользователей, которым назначается роль - - Команды - добавьте команды, которым назначается роль -5. Нажмите "Сохранить" +1. Перейдите в раздел «Администрирование -> Управление доступом». +1. Выберите вкладку «Привязки ролей». +1. Нажмите кнопку «Создать привязку роли». +1. Заполните форму: + - Название - название привязки роли. + - Описание - описание назначения привязки. + - Роль - выберите созданную роль. + - Объект - выберите конкретный объект (если роль не глобальная). + - Пользователи - добавьте пользователей, которым назначается роль. + - Команды - добавьте команды, которым назначается роль. +1. Нажмите «Сохранить». ### Настройка роли по умолчанию -1. Перейдите в раздел `Администрирование -> Управление доступом` -2. Выберите вкладку "Роли" -3. Найдите глобальную роль, которую хотите сделать ролью по умолчанию -4. Включите переключатель "Роль по умолчанию" -5. Подтвердите действие +1. Перейдите в раздел «Администрирование -> Управление доступом». +1. Выберите вкладку «Роли». +1. Найдите глобальную роль, которую хотите сделать ролью по умолчанию. +1. Включите переключатель «Роль по умолчанию». +1. Подтвердите действие. -**Важно:** Ролью по умолчанию может быть только глобальная роль. +{{< alert level="info" >}} +Ролью по умолчанию может быть только глобальная роль. +{{< /alert >}} ### Редактирование существующих ролей -1. Перейдите в раздел `Администрирование -> Управление доступом` -2. Выберите вкладку "Роли" -3. Найдите нужную роль и нажмите "Редактировать" -4. Внесите необходимые изменения: - - Измените название или описание - - Добавьте или удалите разрешения -5. Нажмите "Сохранить" +1. Перейдите в раздел «Администрирование -> Управление доступом». +1. Выберите вкладку «Роли». +1. Найдите нужную роль и нажмите «Редактировать». +1. Внесите необходимые изменения: + - Измените название или описание. + - Добавьте или удалите разрешения. +1. Нажмите «Сохранить». ### Редактирование привязок ролей -1. Перейдите в раздел `Администрирование -> Управление доступом` -2. Выберите вкладку "Привязки ролей" -3. Найдите нужную привязку и нажмите "Редактировать" -4. Внесите необходимые изменения: - - Измените название или описание - - Добавьте или удалите пользователей - - Добавьте или удалите команды -5. Нажмите "Сохранить" +1. Перейдите в раздел «Администрирование -> Управление доступом». +1. Выберите вкладку «Привязки ролей». +1. Найдите нужную привязку и нажмите «Редактировать». +1. Внесите необходимые изменения: + - Измените название или описание. + - Добавьте или удалите пользователей. + - Добавьте или удалите команды. +1. Нажмите «Сохранить». ### Удаление ролей и привязок -1. Перейдите в соответствующий раздел -2. Найдите нужную роль или привязку -3. Нажмите кнопку "Удалить" -4. Подтвердите удаление +1. Перейдите в соответствующий раздел. +1. Найдите нужную роль или привязку. +1. Нажмите кнопку «Удалить». +1. Подтвердите удаление. -**Внимание:** Удаление роли приведет к удалению всех связанных привязок ролей. +{{< alert level="info" >}} +Удаление роли приведет к удалению всех связанных привязок ролей. +{{< /alert >}} ### Просмотр разрешений пользователя или команды #### Для пользователя -1. Перейдите в раздел `Администрирование -> Пользователи` -2. Откройте профиль нужного пользователя -3. Перейдите на вкладку "Разрешения" -4. Просмотрите: - - Глобальные разрешения - - Разрешения по объектам - - Роли, назначенные пользователю - - Команды, в которых состоит пользователь +1. Перейдите в раздел «Администрирование -> Пользователи». +1. Откройте профиль нужного пользователя. +1. Перейдите на вкладку «Разрешения». +1. Просмотрите: + - Глобальные разрешения. + - Разрешения по объектам. + - Роли, назначенные пользователю, + - Команды, в которых состоит пользователь. #### Для команды -1. Перейдите в раздел `Администрирование -> Команды` -2. Откройте профиль нужной команды -3. Перейдите на вкладку "Разрешения" -4. Просмотрите: - - Глобальные разрешения команды - - Разрешения по объектам - - Роли, назначенные команде - - Пользователи, состоящие в команде +1. Перейдите в раздел «Администрирование -> Команды». +1. Откройте профиль нужной команды. +1. Перейдите на вкладку «Разрешения». +1. Просмотрите: + - Глобальные разрешения команды. + - Разрешения по объектам. + - Роли, назначенные команде. + - Пользователи, состоящие в команде. -**Примечание:** Состав команды синхронизируется из внешней системы аутентификации (Dex). +{{< alert level="info" >}} +Состав команды синхронизируется из внешней системы аутентификации (Dex). +{{< /alert >}} ### Пресеты ролей @@ -336,103 +361,107 @@ weight: 20 #### Глобальные пресеты -##### Пресет "Admin" +##### Пресет «Admin» + +- Тип: `global`. +- Разрешения: все глобальные разрешения. +- Назначение: администраторы системы. + +##### Пресет «Viewer» -- Тип: `global` -- Разрешения: Все глобальные разрешения -- Назначение: Супер-администраторы системы +- Тип: `global`. +- Разрешения: + - `read:actions`, `read:automations`, `read:dashboards`. + - `read:datasources`, `read:entities`, `read:external-services`. + - `read:processes`, `read:resource-relations`, `read:resources`. + - `read:seeds`, `read:system-alerts`, `read:webhooks`. + - `read:widgets`, `read:workflows`. + - `read:audit-logs`, `view:admin-page`, `view:self-service-page`. +- Назначение: Пользователи с правами только на просмотр. -##### Пресет "Viewer" +##### Пресет «Developer» -- Тип: `global` +- Тип: `global`. - Разрешения: - - `read:actions`, `read:automations`, `read:dashboards` - - `read:datasources`, `read:entities`, `read:resources` - - `read:webhooks`, `read:widgets`, `read:workflows` - - `read:resource-relations`, `read:system-alerts` - - `view:admin-page`, `view:self-service-page` - - `read:audit-logs`, `read:processes` -- Назначение: Пользователи с правами только на просмотр + - `read:actions`, `read:dashboards`, `read:external-services`. + - `read:processes`, `read:widgets`, `read:workflows`. + - `run:actions`, `run:widget-actions`, `control:processes`. + - `update:team-variables`. +- Назначение: Разработчики, которым нужен доступ к просмотру информации и выполнению действий, но не требуется доступ к созданию, изменению или удалению объектов. Разработчики видят только те сущности, к которым им предоставлен доступ через привязки ролей на уровне ресурсов или сущностей. #### Пресеты для процессов -##### Пресет "Process admin" +##### Пресет «Process admin» -- Тип: `process-definitions` -- Разрешения: `delete:process`, `edit:role-bindings`, `read:process`, `update:process` -- Назначение: Администраторы процессов +- Тип: `process-definitions`. +- Разрешения: `delete:process`, `edit:role-bindings`, `read:process`, `update:process`. +- Назначение: Администраторы процессов. -##### Пресет "Process viewer" +##### Пресет «Process viewer» -- Тип: `process-definitions` -- Разрешения: `read:process` -- Назначение: Пользователи с правами на просмотр процессов +- Тип: `process-definitions`. +- Разрешения: `read:process`. +- Назначение: Пользователи с правами на просмотр процессов. #### Пресеты для ресурсов -##### Пресет "Resource admin" +##### Пресет «Resource admin» -- Тип: `resources` -- Разрешения: Все разрешения для ресурсов -- Назначение: Администраторы конкретных ресурсов +- Тип: `resources`. +- Разрешения: Все разрешения для ресурсов. +- Назначение: Администраторы конкретных ресурсов. #### Использование пресетов -1. Перейдите в раздел `Администрирование -> Управление доступом` -2. Выберите вкладку "Роли" -3. Нажмите "Создать роль" -4. Выберите тип объекта -5. В разделе "Пресеты" нажмите на нужный пресет -6. Настройте параметры роли: - - Измените название и описание при необходимости - - Добавьте или удалите разрешения -7. Нажмите "Сохранить" +1. Перейдите в раздел «Администрирование -> Управление доступом». +1. Выберите вкладку «Роли». +1. Нажмите «Создать роль». +1. Выберите тип объекта. +1. В разделе «Пресеты» нажмите на нужный пресет. +1. Настройте параметры роли: + - Измените название и описание при необходимости. + - Добавьте или удалите разрешения. +1. Нажмите «Сохранить». ### Примеры настройки ролей -#### Роль "Администратор системы" - -- Тип: `global` -- Разрешения: Все глобальные разрешения (используйте пресет "Admin") -- Назначение: Супер-администраторы - -#### Роль "Просмотрщик" +#### Роль «Администратор системы» -- Тип: `global` -- Разрешения: Только права на чтение (используйте пресет "Viewer") -- Назначение: Пользователи с ограниченными правами +- Тип: `global`. +- Разрешения: все глобальные разрешения (используйте пресет «Admin»). +- Назначение: супер-администраторы. -#### Роль "Администратор ресурса" +#### Роль «Администратор ресурса» -- Тип: `resources` -- Разрешения: Все разрешения для ресурсов (используйте пресет "Resource admin") -- Назначение: Конкретный ресурс, команда "Администраторы" +- Тип: `resources`. +- Разрешения: все разрешения для ресурсов (используйте пресет «Resource admin»). +- Назначение: конкретный ресурс, команда «Администраторы». -#### Роль "Оператор процессов" +#### Роль «Оператор процессов» -- Тип: `process-definitions` -- Разрешения: `delete:process`, `edit:role-bindings`, `read:process`, `update:process` (используйте пресет "Process admin") -- Назначение: Команда "Операторы процессов" +- Тип: `process-definitions`. +- Разрешения: `delete:process`, `edit:role-bindings`, `read:process`, `update:process` (используйте пресет «Process admin»). +- Назначение: команда «Операторы процессов». ## Практические рекомендации ### Создание ролей -1. Определите уровень доступа: решите, нужна ли глобальная роль или роль для конкретного объекта -2. Выберите необходимые разрешения: используйте принцип минимальных привилегий -3. Создайте роль в соответствующем разделе администрирования -4. Назначьте роль пользователям или командам через привязки ролей +1. Определите уровень доступа: решите, нужна ли глобальная роль или роль для конкретного объекта. +1. Выберите необходимые разрешения: используйте принцип минимальных привилегий. +1. Создайте роль в соответствующем разделе администрирования. +1. Назначьте роль пользователям или командам через привязки ролей. ### Управление доступом -1. Используйте команды для группового управления доступом -2. Применяйте роли по умолчанию для базовых разрешений всех пользователей -3. Используйте иерархию - глобальные роли для широких прав, роли объектов для специфических прав -4. Регулярно пересматривайте назначенные роли и привязки +1. Используйте команды для группового управления доступом. +1. Применяйте роли по умолчанию для базовых разрешений всех пользователей. +1. Используйте иерархию - глобальные роли для широких прав, роли объектов для специфических прав. +1. Регулярно пересматривайте назначенные роли и привязки. ### Безопасность -1. Принцип минимальных привилегий: предоставляйте только необходимые разрешения -2. Регулярный аудит: проверяйте назначенные роли и их использование -3. Используйте команды вместо индивидуальных назначений для упрощения управления -4. Документируйте роли - используйте описания для понимания назначения ролей +1. Принцип минимальных привилегий: предоставляйте только необходимые разрешения. +1. Регулярный аудит: проверяйте назначенные роли и их использование. +1. Используйте команды вместо индивидуальных назначений для упрощения управления. +1. Документируйте роли - используйте описания для понимания назначения ролей. diff --git a/content/documentation/admin/webhooks.ru.md b/content/documentation/admin/webhooks.ru.md index 7751e88..9c8de05 100644 --- a/content/documentation/admin/webhooks.ru.md +++ b/content/documentation/admin/webhooks.ru.md @@ -9,4 +9,4 @@ moduleStatus: experimental При этом настройка правил обработки (создание, сопоставление, обновление, создание связей) аналогична настройке подобных правил в источниках данных. -Каждый webhook обладает собственным URL, который формируется следующим образом `/webhooks/`. На данном URL вебхук принимает POST запросы с массивом данных любого формата, который обрабатывается на основе правил вебхука. +У каждого вебхука есть уникальный URL, который формируется по шаблону: `/webhooks/`. Вебхук принимает POST-запросы с массивом данных любого формата, который обрабатывается на основе правил вебхука. diff --git a/content/documentation/admin/widgets/overview.ru.md b/content/documentation/admin/widgets/overview.ru.md index ab88f68..6577945 100644 --- a/content/documentation/admin/widgets/overview.ru.md +++ b/content/documentation/admin/widgets/overview.ru.md @@ -3,20 +3,22 @@ title: Обзор weight: 10 --- -Виджеты - карточки для визуализации каких-либо данных, хранящихся в платформе, а также информации из инфраструктурных сервисов. В отличие от источников данных, виджеты получают информацию из инфраструктурных сервисов непосредственно в момент их отображения в интерфейсе. +Виджеты - карточки для визуализации данных, хранящихся в платформе, а также информации из инфраструктурных сервисов. В отличие от источников данных, виджеты получают информацию из инфраструктурных сервисов непосредственно в момент их отображения в интерфейсе. -Виджеты могут быть добавлены на дашборды, дашборды в свою очередь могут быть привязаны либо к статическим страницам: каталог, самообслуживание, главная страница, администрирование, либо к карточкам сущностей. +Виджеты могут быть добавлены на дашборды, дашборды в свою очередь могут быть привязаны: +- к статическим страницам (каталог, самообслуживание, главная страница, администрирование), +- к карточкам сущностей. ## Конфигурация -Конфигурация каждого виджета содержит как общие поля, так и специфичные поля, характерные для каждого типа виджетов. +Конфигурация виджета включает общие параметры и набор полей, специфичных для конкретного типа виджета. -В конфигурации виджетов допустимо использование синтаксиса [Go template](https://developer.hashicorp.com/nomad/tutorials/templates/go-template-syntax) для шаблонизации, например: +В конфигурации поддерживается использование синтаксиса [Go template](https://developer.hashicorp.com/nomad/tutorials/templates/go-template-syntax) для шаблонизации, при обработке виджета, например: -* `{{ .entity.name }}` - подставить при обработке виджета параметр сущности "name". -* `{{ .credentials.token }}` - подставить при обработке виджета учетные данные с названием "token" +* `{{ .entity.name }}` - подстановка значения параметра сущности «name». +* `{{ .credentials.token }}` - подстановка учетных данных с названием «token». -У каждого виджета доступно задание области видимости: +Для каждого виджета доступно задание области видимости: * **Global** - виджет не поддерживает получение параметров сущности через механизм [Go template](https://developer.hashicorp.com/nomad/tutorials/templates/go-template-syntax); * **Resource** - виджет поддерживает получение параметров сущности через механизм [Go template](https://developer.hashicorp.com/nomad/tutorials/templates/go-template-syntax). Виджеты с областью видимости Resource можно прикрепить только к страницам сущности. diff --git a/content/documentation/admin/widgets/types.ru.md b/content/documentation/admin/widgets/types.ru.md index 62bff7f..99e1fd7 100644 --- a/content/documentation/admin/widgets/types.ru.md +++ b/content/documentation/admin/widgets/types.ru.md @@ -31,7 +31,7 @@ title: Типы виджетов ### Авторизация -Конфигурация авторизации описана в разделе [внешний сервис GitLab](../external-services/#gitlab). +Конфигурация авторизации описана в разделе [Внешние сервисы](../external-services/#gitlab). ## CodeScoring. Зависимости @@ -39,7 +39,7 @@ title: Типы виджетов ### Авторизация -Конфигурация авторизации описана в разделе [внешний сервис CodeScoring](../external-services/#codescoring). +Конфигурация авторизации описана в разделе [Внешние сервисы](../external-services/#codescoring). ### Конфигурация @@ -54,7 +54,7 @@ title: Типы виджетов ### Авторизация -Конфигурация авторизации описана в разделе [внешний сервис CodeScoring](../external-services/#codescoring). +Конфигурация авторизации описана в разделе [Внешние сервисы](../external-services/#codescoring). ### Конфигурация @@ -69,7 +69,7 @@ title: Типы виджетов ### Авторизация -Конфигурация авторизации описана в разделе [внешний сервис DefectDojo](../external-services/#defectdojo). +Конфигурация авторизации описана в разделе [Внешние сервисы](../external-services/#defectdojo). ### Конфигурация @@ -91,7 +91,7 @@ title: Типы виджетов ### Авторизация -Конфигурация авторизации описана в разделе [внешний сервис DefectDojo](../external-services/#defectdojo). +Конфигурация авторизации описана в разделе [Внешние сервисы](../external-services/#defectdojo). ### Конфигурация @@ -113,7 +113,7 @@ title: Типы виджетов ### Авторизация -Конфигурация авторизации описана в разделе [внешний сервис Docker Registry](../external-services/#docker-registry). +Конфигурация авторизации описана в разделе [Внешние сервисы](../external-services/#docker-registry). ### Конфигурация @@ -124,11 +124,11 @@ title: Типы виджетов ## Gitlab. Запросы слияния -Виджет позволяет отображать данные о Merge Requests в платформе GitLab и выполнять действия с ними. +Виджет позволяет отображать данные о Merge Requests (MR) в платформе GitLab и выполнять действия с ними. ### Авторизация -Конфигурация авторизации описана в разделе [внешний сервис GitLab](../external-services/#gitlab). +Конфигурация авторизации описана в разделе [Внешние сервисы](../external-services/#gitlab). ### Конфигурация @@ -141,10 +141,10 @@ title: Типы виджетов Виджет позволяет фильтровать отображаемые Merge Requests по статусу. В настройках запроса виджета можно выбрать один из следующих статусов: -- **Открытые** - показывает только открытые MR -- **Закрытые** - показывает только закрытые MR -- **Слитые** - показывает только слитые MR -- **Заблокированные** - показывает только заблокированные MR +- **Открытые** - показывает только открытые MR. +- **Закрытые** - показывает только закрытые MR. +- **Слитые** - показывает только слитые MR. +- **Заблокированные** - показывает только заблокированные MR. По умолчанию отображаются только открытые MR. @@ -152,12 +152,14 @@ title: Типы виджетов При активированной функции действий в настройках виджет позволяет выполнять следующие действия с Merge Requests: -- **Слить** - слияние открытого запроса на слияние (доступно только для открытых MR) -- **Закрыть** - закрытие запроса на слияние -- **Отметить как черновик/готово** - изменение статуса черновика запроса на слияние -- **Просмотр изменений** - просмотр диффа (изменений) в запросе на слияние +- **Слить** - слияние открытого запроса на слияние (доступно только для открытых MR). +- **Закрыть** - закрытие запроса на слияние. +- **Отметить как черновик/готово** - изменение статуса черновика запроса на слияние. +- **Просмотр изменений** - просмотр диффа (изменений) в запросе на слияние. -**Важно:** для выполнения действий с MR требуются соответствующие права доступа в GitLab репозитории. +{{< alert level="info" >}} +Для выполнения действий с MR требуются соответствующие права доступа в GitLab репозитории. +{{< /alert >}} ## Gitlab. Пайплайны @@ -165,7 +167,7 @@ title: Типы виджетов ### Авторизация -Конфигурация авторизации описана в разделе [внешний сервис GitLab](../external-services/#gitlab). +Конфигурация авторизации описана в разделе [Внешние сервисы](../external-services/#gitlab). ### Конфигурация @@ -193,7 +195,7 @@ title: Типы виджетов ### Авторизация -Конфигурация авторизации описана в разделе [внешний сервис GitLab](../external-services/#gitlab). +Конфигурация авторизации описана в разделе [Внешние сервисы](../external-services/#gitlab). ### Конфигурация @@ -206,8 +208,8 @@ title: Типы виджетов Виджет отображает: -* **Редактор кода** - Monaco Editor для редактирования файла `.gitlab-ci.yml` -* **Дифф-просмотр** - отображение изменений между оригинальной и редактируемой версией конфигурации +* **Редактор кода** - Monaco Editor для редактирования файла `.gitlab-ci.yml`. +* **Дифф-просмотр** - отображение изменений между оригинальной и редактируемой версией конфигурации. ### Дополнительные возможности виджета @@ -227,9 +229,9 @@ title: Типы виджетов #### Ограничения -* Виджет работает только с файлом `.gitlab-ci.yml` в корне проекта -* Для создания запроса на слияние требуются права на запись в репозиторий -* Максимальный размер файла конфигурации ограничен возможностями GitLab API +* Виджет работает только с файлом `.gitlab-ci.yml` в корне проекта. +* Для создания запроса на слияние требуются права на запись в репозиторий. +* Максимальный размер файла конфигурации ограничен возможностями GitLab API. ## GitLab. Статистика пайплайнов @@ -237,7 +239,7 @@ title: Типы виджетов ### Авторизация -Конфигурация авторизации описана в разделе [внешний сервис GitLab](../external-services/#gitlab). +Конфигурация авторизации описана в разделе [Внешние сервисы](../external-services/#gitlab). ### Конфигурация @@ -252,36 +254,36 @@ title: Типы виджетов #### Основные метрики -* **Общее количество пайплайнов** - общее число пайплайнов за выбранный период -* **Процент успеха** - процент успешно выполненных пайплайнов -* **Процент неудач** - процент неудачно выполненных пайплайнов -* **Средняя длительность** - среднее время выполнения пайплайнов +* **Общее количество пайплайнов** - общее число пайплайнов за выбранный период. +* **Процент успеха** - процент успешно выполненных пайплайнов. +* **Процент неудач** - процент неудачно выполненных пайплайнов. +* **Средняя длительность** - среднее время выполнения пайплайнов. #### Распределение по статусам -* Успешные пайплайны -* Неудачные пайплайны -* Отмененные пайплайны -* Пропущенные пайплайны -* Ручные пайплайны +* Успешные пайплайны. +* Неудачные пайплайны. +* Отмененные пайплайны. +* Пропущенные пайплайны. +* Ручные пайплайны. #### Распределение по источникам -* Push (коммиты) -* Merge requests (запросы слияния) -* Schedule (по расписанию) -* Web (через веб-интерфейс) +* Push (коммиты). +* Merge requests (запросы слияния). +* Schedule (по расписанию). +* Web (через веб-интерфейс). #### Топ участников -* Список участников с наибольшим количеством запущенных пайплайнов -* Аватары участников (при наличии) -* Количество пайплайнов для каждого участника +* Список участников с наибольшим количеством запущенных пайплайнов. +* Аватары участников (при наличии). +* Количество пайплайнов для каждого участника. #### Активность веток -* Список веток с наибольшим количеством пайплайнов -* Количество пайплайнов для каждой ветки +* Список веток с наибольшим количеством пайплайнов. +* Количество пайплайнов для каждой ветки. ### Параметры запроса @@ -293,9 +295,9 @@ title: Типы виджетов ### Ограничения -* Виджет анализирует максимум 100 пайплайнов за один запрос для оптимизации производительности -* Статистика рассчитывается только для пайплайнов с валидными данными (имеющими статус и время выполнения) -* Данные обновляются при каждом обновлении виджета +* Виджет анализирует максимум 100 пайплайнов за один запрос для оптимизации производительности. +* Статистика рассчитывается только для пайплайнов с валидными данными (имеющими статус и время выполнения). +* Данные обновляются при каждом обновлении виджета. ## Gitlab. Теги @@ -303,7 +305,7 @@ title: Типы виджетов ### Авторизация -Конфигурация авторизации описана в разделе [внешний сервис GitLab](../external-services/#gitlab). +Конфигурация авторизации описана в разделе [Внешние сервисы](../external-services/#gitlab). ### Конфигурация @@ -332,7 +334,7 @@ title: Типы виджетов ### Авторизация -Конфигурация авторизации описана в разделе [внешний сервис GitLab](../external-services/#gitlab). +Конфигурация авторизации описана в разделе [Внешние сервисы](../external-services/#gitlab). ### Конфигурация @@ -360,7 +362,7 @@ title: Типы виджетов ### Авторизация -Конфигурация авторизации описана в разделе [внешний сервис GitLab](../external-services/#gitlab). +Конфигурация авторизации описана в разделе [Внешние сервисы](../external-services/#gitlab). ### Конфигурация @@ -380,7 +382,7 @@ title: Типы виджетов ### Авторизация -Конфигурация авторизации описана в разделе [внешний сервис Kubernetes](../external-services/#kubernetes). +Конфигурация авторизации описана в разделе [Внешние сервисы](../external-services/#kubernetes). ### Конфигурация @@ -409,21 +411,21 @@ title: Типы виджетов Для каждого ACL отображается следующая информация: -* Субъект -* Тип ресурса -* Шаблон -* Тип шаблона -* Хост -* Операция -* Тип разрешения +* Субъект. +* Тип ресурса. +* Шаблон. +* Тип шаблона. +* Хост. +* Операция. +* Тип разрешения. ### Аутентификация Для работы с виджетом требуется учётная запись пользователя. Система поддерживает следующие методы аутентификации: -* PLAINTEXT -* SCRAM-SHA-256 -* SCRAM-SHA-512 +* PLAINTEXT. +* SCRAM-SHA-256. +* SCRAM-SHA-512. ### Конфигурация @@ -445,8 +447,8 @@ title: Типы виджетов При активированной функции действий в настройках виджет позволяет: -* Создавать новые правила ACL -* Удалять существующие правила ACL +* Создавать новые правила ACL. +* Удалять существующие правила ACL. ## Kafka. Топики @@ -454,21 +456,23 @@ title: Типы виджетов Для каждого топика доступно: -* Общая информация о топике: основные параметры, конфигурация и статус -* Информация о партициях:информацию о лидере, оффсетах -* Информация о консьюмерах: список активных потребителей, их группы, текущие офсеты и лаги -* Сообщения: просмотр содержимого сообщений топиков в удобном формате -* Поиск сообщений: фильтрация сообщений по timestamp и offset +* Общая информация о топике: основные параметры, конфигурация и статус. +* Информация о партициях:информацию о лидере, оффсетах. +* Информация о консьюмерах: список активных потребителей, их группы, текущие оффсеты и лаги. +* Сообщения: просмотр содержимого сообщений топиков в удобном формате. +* Поиск сообщений: фильтрация сообщений по timestamp и offset. ### Аутентификация Для работы с виджетом требуется учётная запись пользователя. Система поддерживает следующие методы аутентификации: -* PLAINTEXT -* SCRAM-SHA-256 -* SCRAM-SHA-512 +* PLAINTEXT. +* SCRAM-SHA-256. +* SCRAM-SHA-512. -**Важно:** доступность информации в виджете определяется уровнем прав подключённой учётной записи. +{{< alert level="info" >}} +Доступность информации в виджете определяется уровнем прав подключённой учётной записи. +{{< /alert >}} ### Конфигурация @@ -485,25 +489,25 @@ title: Типы виджетов При активированной функции действий в настройках виджет позволяет: -* Создавать новые топики -* Удалять существующие топики -* Отправлять сообщение в топик -* Очищать топик от сообщений +* Создавать новые топики. +* Удалять существующие топики. +* Отправлять сообщение в топик. +* Очищать топик от сообщений. ## Kubernetes deployments Виджет Kubernetes deployments позволяет выводить основную информацию обо всех deployments в Kubernetes кластере. Доступна фильтрация по namespace и/или по label selector. -Для каждого deployment доступны: +Для каждого ресурса 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`) отображаются, но не могут быть отредактированы через виджет. ### Авторизация -Конфигурация авторизации описана в разделе [внешний сервис Kubernetes](../external-services/#kubernetes). +Конфигурация авторизации описана в разделе [Внешние сервисы](../external-services/#kubernetes). ### Конфигурация @@ -517,45 +521,45 @@ title: Типы виджетов Виджет позволяет отображать данные о Ingress в платформе Kubernetes. -Для каждого ingress доступны: +Для каждого Ingress доступны: -* Просмотр спецификации ingress в виде yaml конфигурации -* Правила ingress -* Настройки TLS +* Просмотр спецификации Ingress в виде YAML-конфигурации. +* Правила Ingress. +* Настройки TLS. ### Авторизация -Конфигурация авторизации описана в разделе [внешний сервис Kubernetes](../external-services/#kubernetes). +Конфигурация авторизации описана в разделе [Внешние сервисы](../external-services/#kubernetes). ### Конфигурация -| Название | Опциональность | Описание | Значение по умолчанию | -|----------------|-----------------|---------------------------------------------------------------------------------------------------------------------|-----------------------| -| URL | **обязательно** | URL API сервера Kubernetes. Используется для получения данных из Kubernetes | - | -| Namespace | опционально | Kubernetes namespace из которого будут загружаться ingresses. В случае, если namespace не указан, виджет будет пытаться загрузить все ingress кластера. Пример: `default` | - | -| Label selector | опционально | Селекторы для фильтрации получаемых ingress. Перечисляются через запятую. Пример: `app.kubernetes.io/name=example` | - | +| Название | Опциональность | Описание | Значение по умолчанию | +|----------------|-----------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------| +| URL | **обязательно** | URL API сервера Kubernetes. Используется для получения данных из Kubernetes | - | +| Namespace | опционально | Неймспейс Kubernetes из которого будут загружаться ingresses. В случае, если неймспейс не указан, виджет будет пытаться загрузить все ingress кластера. Пример: `default` | - | +| Label selector | опционально | Селекторы для фильтрации получаемых ingress. Перечисляются через запятую. Пример: `app.kubernetes.io/name=example` | - | ## Kubernetes pods -Виджет позволяет отображать данные о pod в платформе Kubernetes. +Виджет позволяет отображать данные о подах в платформе Kubernetes. Для каждого pod доступны: -* Просмотр спецификации pod в виде yaml конфигурации -* Логи контейнеров +* Просмотр спецификации пода в виде YAML-конфигурации. +* Логи контейнеров. * Различная информация о состоянии пода: статус, количество перезапусков и др. ### Авторизация -Конфигурация авторизации описана в разделе [внешний сервис Kubernetes](../external-services/#kubernetes). +Конфигурация авторизации описана в разделе [Внешние сервисы](../external-services/#kubernetes). ### Конфигурация -| Название | Опциональность | Описание | Значение по умолчанию | -|----------------|-----------------|-----------------------------------------------------------------------------------------------------------------|-----------------------| -| URL | **обязательно** | URL API сервера Kubernetes. Используется для получения данных из Kubernetes | - | -| Namespace | опционально | Пространство имен, из которого будут загружаться данные в виджет. Пример: `default` | - | -| Label selector | опционально | Селекторы для фильтрации получаемых pod. Перечисляются через запятую. Пример: `app.kubernetes.io/name=example` | - | +| Название | Опциональность | Описание | Значение по умолчанию | +|----------------|-----------------|------------------------------------------------------------------------------------------------------------------|-----------------------| +| URL | **обязательно** | URL API сервера Kubernetes. Используется для получения данных из Kubernetes | - | +| Namespace | опционально | Неймспейс, из которого будут загружаться данные в виджет. Пример: `default` | - | +| Label selector | опционально | Селекторы для фильтрации получаемых подов. Перечисляются через запятую. Пример: `app.kubernetes.io/name=example` | - | ## Markdown @@ -573,7 +577,7 @@ title: Типы виджетов ### Авторизация -Конфигурация авторизации описана в разделе [внешний сервис Nexus](../external-services/#nexus). +Конфигурация авторизации описана в разделе [Внешние сервисы](../external-services/#nexus). ### Конфигурация @@ -585,11 +589,11 @@ title: Типы виджетов ## Opensearch index -Виджет Opensearch index позволяет отобразить данные из определенного index или index pattern в платформе. Данные по умолчанию сортируются от более новых к более старым. Доступен полнотекстовый поиск для фильтрации отображаемых данных. Для каждой записи (строки таблицы) доступно отображение в формате "ключ-значение", либо в JSON. При указании index pattern в виджете будет выводиться ссылка на страницу Discover в OpenSearch Dashboards. +Виджет Opensearch index позволяет отобразить данные из определенного index или index pattern в платформе. Данные по умолчанию сортируются от более новых к более старым. Доступен полнотекстовый поиск для фильтрации отображаемых данных. Для каждой записи (строки таблицы) доступно отображение в формате «ключ-значение», либо в JSON. При указании index pattern в виджете будет выводиться ссылка на страницу Discover в OpenSearch Dashboards. ### Авторизация -Конфигурация авторизации описана в разделе [внешний сервис OpenSearch](../external-services/#opensearch). +Конфигурация авторизации описана в разделе [Внешние сервисы](../external-services/#opensearch). ### Конфигурация @@ -602,9 +606,9 @@ title: Типы виджетов ## Prometheus metrics (range) -Виджет позволяет построить график из диапазона значений на основе метрики из Prometheus, задать для него единицу измерения и выбрать пороговое значение. Query, указанная в виджете, должна возвращать тип Scalar или тип Vector с одним значением. +Виджет позволяет построить график из диапазона значений на основе метрики из Prometheus, задать для него единицу измерения и выбрать пороговое значение. Запрос (query), указанный в виджете, должен возвращать тип Scalar или тип Vector с одним значением. -Пример корректной query для виджета: +Пример корректного запроса для виджета: ```sh rate(nginx_ingress_controller_nginx_process_connections[5m]) @@ -615,25 +619,25 @@ rate(nginx_ingress_controller_nginx_process_connections[5m]) | Название | Опциональность | Описание | Значение по умолчанию | |-----------------------|-----------------|--------------------------------------------------------------------------------------------------------------------------------------|-----------------------| | URL | **обязательно** | URL Prometheus | - | -| Query | **обязательно** | Query для запроса метрики из Prometheus в формате PromQL | - | +| Query | **обязательно** | Запрос метрики из Prometheus в формате PromQL | - | | Шаг разрешения (сек.) | **обязательно** | Интервал между отсчетами на горизонтальной оси (в секундах) | 60 | | Метка | **обязательно** | Метка в результатах запроса, чье уникальное значение присваивается в качестве названий соответствующих линий на графике визуализации | - | | Порог | опционально | Порог, отображаемый в виде горизонтальной красной полосы на графике | - | | Минимальное значение | опционально | Начальная точка отсчета для вертикальной линии на графике | - | | Максимальное значение | опционально | Предельная точка отсчета для вертикальной линии на графике | - | -| InsecureSkipVerify | опционально | Отключить проверку подлинности TLS/SSL-сертификата Prometheus | false | +| InsecureSkipVerify | опционально | Отключение проверки подлинности TLS/SSL-сертификата Prometheus | false | ### Авторизация -Конфигурация авторизации описана в разделе [внешний сервис Prometheus](../external-services/#prometheus). +Конфигурация авторизации описана в разделе [Внешние сервисы](../external-services/#prometheus). ### Дополнительные возможности виджета При просмотре виджета возможно настроить диапазон отображаемых значений. Доступные параметры отображения диапазона: -* Интервал -* Минимальное значение (начальная точка отсчета для вертикальной линии на графике) -* Максимальное значение (предельная точка отсчета для вертикальной линии на графике) +* Интервал. +* Минимальное значение (начальная точка отсчета для вертикальной линии на графике). +* Максимальное значение (предельная точка отсчета для вертикальной линии на графике). ## Prometheus metrics (single) @@ -658,11 +662,11 @@ sum(ingress_nginx_detail_requests_total) | Меньшее значение считается лучше | опционально | Метрика считается «хорошей», когда её значение ниже заданного порогового значения | false | | Порог предупреждения (%) | опционально | Граница между красным и оранжевым цветами. Если значение метрики превышает этот процент от порога, оно получит оранжевый цвет | 60 | | Порог успеха (%) | опционально | Граница между оранжевым и зелёным цветами. Если значение метрики превышает этот процент от порога, оно получит зеленый цвет | 90 | -| InsecureSkipVerify | опционально | Отключить проверку подлинности TLS/SSL-сертификата Prometheus | false | +| InsecureSkipVerify | опционально | Отключение проверки подлинности TLS/SSL-сертификата Prometheus | false | ### Авторизация -Конфигурация авторизации описана в разделе [внешний сервис Prometheus](../external-services/#prometheus). +Конфигурация авторизации описана в разделе [Внешние сервисы](../external-services/#prometheus). ## Sonarqube @@ -670,7 +674,7 @@ sum(ingress_nginx_detail_requests_total) ### Авторизация -Конфигурация авторизации описана в разделе [внешний сервис SonarQube](../external-services/#sonarqube). +Конфигурация авторизации описана в разделе [Внешние сервисы](../external-services/#sonarqube). ### Конфигурация @@ -693,41 +697,45 @@ sum(ingress_nginx_detail_requests_total) Для каждого объекта доступно: -* Просмотр списка объектов в bucket с информацией о размере, дате изменения и классе хранения -* Поиск объектов по префиксу (пути) -* Загрузка файлов из bucket -* Просмотр детальной метаинформации объектов (размер, тип контента, метаданные, настройки кэширования и т.д.) -* Навигация по папкам bucket +* Просмотр списка объектов в контейнере (bucket) с информацией о размере, дате изменения и классе хранения. +* Поиск объектов по префиксу (пути). +* Загрузка файлов из bucket. +* Просмотр детальной метаинформации объектов (размер, тип контента, метаданные, настройки кеширования и т.д.). +* Навигация по папкам bucket. ### Аутентификация -Для работы с виджетом требуется учётная запись с правами доступа к S3 bucket. Система поддерживает следующие методы аутентификации: +Для работы с виджетом требуется учётная запись с правами доступа к S3 Bucket. Система поддерживает следующие методы аутентификации: -* Access Key ID и Secret Access Key -* Поддержка различных S3-совместимых провайдеров через настройку endpoint +* Access Key ID и Secret Access Key. +* Поддержка различных S3-совместимых провайдеров через настройку эндпоинта. -**Важно:** в отличие от других виджетов, S3 Bucket виджет не поддерживает использование внешних сервисов для передачи учётных данных. Все параметры аутентификации указываются непосредственно в конфигурации виджета. +{{< alert level="info" >}} +В отличие от других виджетов, S3 Bucket виджет не поддерживает использование внешних сервисов для передачи учётных данных. Все параметры аутентификации указываются непосредственно в конфигурации виджета. +{{< /alert >}} ### Использование шаблонов для учётных данных Для повышения безопасности можно использовать механизм шаблонизации с учётными данными: -* `{{ .credentials.accessKeyId }}` - подставить Access Key ID из учётных данных -* `{{ .credentials.secretAccessKey }}` - подставить Secret Access Key из учётных данных +* `{{ .credentials.accessKeyId }}` - подставить Access Key ID из учётных данных. +* `{{ .credentials.secretAccessKey }}` - подставить Secret Access Key из учётных данных. -**Важно:** доступность информации в виджете определяется уровнем прав подключённой учётной записи. +{{< alert level="info" >}} +Доступность информации в виджете определяется уровнем прав подключённой учётной записи. +{{< /alert >}} ### Конфигурация -| Название | Опциональность | Описание | Значение по умолчанию | -|--------------------|-----------------|---------------------------------------------------------------------------------------|-----------------------| -| Название bucket | **обязательно** | Название S3 bucket для просмотра | - | -| Endpoint | **обязательно** | URL endpoint S3-совместимого хранилища (например, `https://storage.yandexcloud.net`) | - | -| Регион | **обязательно** | Регион, в котором находится bucket | - | -| Access Key ID | **обязательно** | Идентификатор ключа доступа для аутентификации | - | -| Secret Access Key | **обязательно** | Секретный ключ доступа для аутентификации | - | -| Префикс | опционально | Префикс (путь) для фильтрации объектов при первоначальной загрузке | - | -| Максимум объектов | опционально | Максимальное количество объектов для отображения за один запрос (по умолчанию 100) | 100 | +| Название | Опциональность | Описание | Значение по умолчанию | +|--------------------|-----------------|--------------------------------------------------------------------------------------|-----------------------| +| Название bucket | **обязательно** | Название S3 Bucket для просмотра | - | +| Endpoint | **обязательно** | Эндпоинт URL S3-совместимого хранилища (например, `https://storage.yandexcloud.net`) | - | +| Регион | **обязательно** | Регион, в котором находится Bucket | - | +| Access Key ID | **обязательно** | Идентификатор ключа доступа для аутентификации | - | +| Secret Access Key | **обязательно** | Секретный ключ доступа для аутентификации | - | +| Префикс | опционально | Префикс (путь) для фильтрации объектов при первоначальной загрузке | - | +| Максимум объектов | опционально | Максимальное количество объектов для отображения за один запрос (по умолчанию 100) | 100 | ### Дополнительные возможности виджета @@ -735,9 +743,11 @@ sum(ingress_nginx_detail_requests_total) Виджет позволяет искать объекты по префиксу (пути). При поиске список объектов обновляется в соответствии с заданным префиксом. -**Важно:** поиск работает только если вводить символы с начала названия объекта. Поиск по символам из середины названия не поддерживается. +{{< alert level="info" >}} +Поиск работает только при вводе символов с начала названия объекта. Поиск по символам из середины названия не поддерживается. +{{< /alert >}} -**Ограничение поиска:** если в конфигурации виджета задан изначальный префикс, то поиском в самом виджете уже не получится подгрузить файлы с другим префиксом. Поиск будет работать только в рамках заданного изначального префикса. +Если в конфигурации виджета задан начальный префикс, поиск в виджете ограничивается этим префиксом. Загрузка и отображение файлов с другим префиксом недоступны. ### Загрузка файлов @@ -747,11 +757,11 @@ sum(ingress_nginx_detail_requests_total) При клике на иконку документа для каждого объекта отображается детальная информация: -* Основные параметры: ключ, размер, дата изменения, класс хранения, тип контента, ETag -* Информация о контенте: кодировка, язык, диспозиция -* Настройки кэширования: Cache-Control, срок действия -* Безопасность: серверное шифрование -* Пользовательские метаданные +* Основные параметры: ключ, размер, дата изменения, класс хранения, тип контента, ETag. +* Информация о контенте: кодировка, язык, диспозиция. +* Настройки кэширования: Cache-Control, срок действия. +* Безопасность: серверное шифрование. +* Пользовательские метаданные. ### Подгрузка дополнительных объектов @@ -761,11 +771,11 @@ sum(ingress_nginx_detail_requests_total) Виджет позволяет выводить информацию об объектах DDP в виде одного из следующих типов графиков: -* Столбчатая диаграмма -* Кольцевая диаграмма -* Круговая диаграмма -* Полярная диаграмма -* Радарная диаграмма +* Столбчатая диаграмма. +* Кольцевая диаграмма. +* Круговая диаграмма. +* Полярная диаграмма. +* Радарная диаграмма. ### Конфигурация @@ -780,8 +790,8 @@ sum(ingress_nginx_detail_requests_total) При настройке виджета следует учитывать, что названия полей в базе данных могут отличаться от названий полей в спецификации объектов. Общий принцип таков: формат camelCase в спецификации объектов при сохранении структур в базу данных преобразуется в snake_case. Например: -* Поле `createdAt` в спецификации следует указывать в конфигурации виджета как `created_at` -* Поле `resourceUuid` в спецификации следует указывать в конфигурации виджета как `resource_uuid` +* Поле `createdAt` в спецификации следует указывать в конфигурации виджета как `created_at`. +* Поле `resourceUuid` в спецификации следует указывать в конфигурации виджета как `resource_uuid`. Доступно обращение к вложенным значениям. В таком случае разделителем для вложенности служит символ точки. Например, чтобы выполнить агрегацию по статусу сущностей, виджет следует настроить следующим образом: @@ -795,9 +805,9 @@ sum(ingress_nginx_detail_requests_total) Данные на графике будут отсортированы и сгруппированы по выбранным временным интервалам. -В параметрах агрегации можно задать: +В параметрах агрегации можно задать параметры: -- **Единицу измерения шага** — например: секунды, минуты, часы, дни и т.д. +- **Единица измерения шага** — например: секунды, минуты, часы, дни и т.д. - **Количество единиц в одном шаге** — например: 5 минут, 2 часа, 1 день и т.п. Это позволяет управлять детализацией отображения данных во времени и адаптировать график под нужный масштаб анализа. @@ -818,12 +828,12 @@ sum(ingress_nginx_detail_requests_total) Доступны два режима настройки интервалов: -1. **Автоматическая разбивка по количеству интервалов** +1. **Автоматическая разбивка по количеству интервалов**. Указывается только количество интервалов, на которые нужно разделить доступные данные. Интервалы будут рассчитаны автоматически — равномерно от минимального до максимального значения. -2. **Ручное задание границ интервалов** +1. **Ручное задание границ интервалов**. Указывается массив числовых границ интервалов. Например: `0, 10, 20, 50` @@ -852,14 +862,14 @@ sum(ingress_nginx_detail_requests_total) ### Авторизация -Конфигурация авторизации описана в разделе [внешний сервис Kubernetes](../external-services/#kubernetes). +Конфигурация авторизации описана в разделе [Внешние сервисы](../external-services/#kubernetes). ### Конфигурация -| Название | Опциональность | Описание | Значение по умолчанию | -|----------------|-----------------|-----------------------------------------------------------------------------------------------------------------|-----------------------| -| URL | **обязательно** | URL API сервера Kubernetes. Используется для получения данных из Kubernetes | - | -| Namespace | **обязательно** | Пространство имен, из которого будут загружаться данные в виджет. Пример: `default` | - | +| Название | Опциональность | Описание | Значение по умолчанию | +|----------------|-----------------|-----------------------------------------------------------------------------|-----------------------| +| URL | **обязательно** | URL API сервера Kubernetes. Используется для получения данных из Kubernetes | - | +| Namespace | **обязательно** | Неймспейс, из которого будут загружаться данные в виджет. Пример: `default` | - | ## Процентное значение @@ -889,8 +899,8 @@ sum(ingress_nginx_detail_requests_total) ### Отображаемые данные -- **График временной шкалы** — горизонтальная диаграмма, где каждая сущность отображается в виде полосы, показывающей период времени (от даты начала до даты окончания); -- **Информация о сущностях** — при наведении на полосу отображается название сущности, дата начала и дата окончания периода; +- **График временной шкалы** — горизонтальная диаграмма, где каждая сущность отображается в виде полосы, показывающей период времени (от даты начала до даты окончания). +- **Информация о сущностях** — при наведении на полосу отображается название сущности, дата начала и дата окончания периода. - **Сортировка** — сущности отсортированы от самых старых (сверху) к самым новым (снизу). ### Конфигурация @@ -994,13 +1004,13 @@ sum(ingress_nginx_detail_requests_total) Виджет отображает статистику событий, происходящих с сущностями в платформе DDP. Виджет содержит три таба: -1. **Статистика событий** - график, показывающий количество событий по типам за выбранный временной период с настраиваемой группировкой по времени -2. **Топ сущностей** - таблица с сущностями, для которых было сгенерировано максимальное количество событий +1. **Статистика событий** - график, показывающий количество событий по типам за выбранный временной период с настраиваемой группировкой по времени. +2. **Топ сущностей** - таблица с сущностями, для которых было сгенерировано максимальное количество событий. 3. **События в Redis** - таблица со стримами событий из Redis, показывающая для каждого стрима: - - Название стрима (кликабельное для просмотра всех событий) - - Ресурс, к которому относится стрим - - Количество событий в стриме - - Информацию о последнем событии (сущность, ресурс, тип события, время) + - Название стрима (кликабельное для просмотра всех событий). + - Ресурс, к которому относится стрим. + - Количество событий в стриме. + - Информацию о последнем событии (сущность, ресурс, тип события, время). ### Параметры запроса @@ -1016,23 +1026,23 @@ sum(ingress_nginx_detail_requests_total) Виджет поддерживает следующие типы событий: -- **ENTITY_CREATED** - создание сущности -- **ENTITY_UPDATED** - обновление сущности -- **ENTITY_DELETED** - удаление сущности +- **ENTITY_CREATED** - создание сущности. +- **ENTITY_UPDATED** - обновление сущности. +- **ENTITY_DELETED** - удаление сущности. #### Особенности -- График показывает события за выбранный временной период с настраиваемой группировкой по времени (по умолчанию - по часам) -- Таблица отображает все события для каждой сущности (без фильтрации по дате) -- Для удаленных сущностей отображается их название, извлеченное из спецификации события -- Таб "События в Redis" позволяет отслеживать события, хранящиеся в Redis Streams: - - Для каждого стрима отображается количество событий и информация о последнем событии - - При клике на название стрима открывается диалог со всеми событиями из этого стрима - - Стримы автоматически привязываются к ресурсам по UUID, указанному в названии стрима - - При просмотре событий из стрима отображаются последние 1000 событий (новые первыми). Если в стриме больше 1000 событий, более старые события не отображаются -- Каждая строка в таблице содержит информацию о последнем событии для сущности -- Доступен просмотр детальной истории изменений для каждой сущности -- События для удаленных ресурсов не отображаются (удаляются из БД при удалении ресурса) +- График показывает события за выбранный временной период с настраиваемой группировкой по времени (по умолчанию - по часам). +- Таблица отображает все события для каждой сущности (без фильтрации по дате). +- Для удаленных сущностей отображается их название, извлеченное из спецификации события. +- Вкладка «События в Redis» позволяет отслеживать события, хранящиеся в Redis Streams: + - Для каждого стрима отображается количество событий и информация о последнем событии. + - При клике на название стрима открывается диалог со всеми событиями из этого стрима. + - Стримы автоматически привязываются к ресурсам по UUID, указанному в названии стрима. + - При просмотре событий из стрима отображаются последние 1000 событий (новые первыми). Если в стриме больше 1000 событий, более старые события не отображаются. +- Каждая строка в таблице содержит информацию о последнем событии для сущности. +- Доступен просмотр детальной истории изменений для каждой сущности. +- События для удаленных ресурсов не отображаются (удаляются из БД при удалении ресурса). ## Числовое значение @@ -1065,19 +1075,19 @@ sum(ingress_nginx_detail_requests_total) ### Авторизация -Конфигурация авторизации описана в разделе [внешний сервис Kaiten](../external-services/#kaiten). +Конфигурация авторизации описана в разделе [Внешние сервисы](../external-services/#kaiten). ### Отображаемые данные Каждая карточка содержит: -- Название карточки -- Колонка (статус в доске) -- Статус (очередь,в работе, готово) -- Линия -- Владелец (аватар, имя, email) -- Участники -- Срок (дата дедлайна, срочность) -- Блокированная/незаблокированная +- Название карточки. +- Колонка (статус в доске). +- Статус (очередь,в работе, готово). +- Линия. +- Владелец (аватар, имя, email). +- Участники. +- Срок (дата дедлайна, срочность). +- Блокированная/незаблокированная. ## Kaiten. Статистика пространства @@ -1098,7 +1108,7 @@ sum(ingress_nginx_detail_requests_total) ### Авторизация -Конфигурация авторизации описана в разделе [внешний сервис Kaiten](../external-services/#kaiten). +Конфигурация авторизации описана в разделе [Внешние сервисы](../external-services/#kaiten). ### Отображаемые данные @@ -1108,37 +1118,37 @@ sum(ingress_nginx_detail_requests_total) Основные метрики: -- В очереди: задачи в очереди на выполнение -- Выполнено: завершенные задачи -- В работе: активные задачи +- В очереди: задачи в очереди на выполнение. +- Выполнено: завершенные задачи. +- В работе: активные задачи. Дополнительные метрики: -- Заблокировано: количество заблокированных задач -- Блокирующих: количество задач, блокирующих другие -- Архивировано: количество задач в архиве -- Срочных: количество срочных задач -- В среднем на выполнение: среднее время выполнения (в минутах) +- Заблокировано: количество заблокированных задач. +- Блокирующих: количество задач, блокирующих другие. +- Архивировано: количество задач в архиве. +- Срочных: количество срочных задач. +- В среднем на выполнение: среднее время выполнения (в минутах). Статистика по чеклистам: -- Всего с чеклистом: общее количество задач с чеклистами -- Чеклист полностью выполнен: задачи с полностью выполненными чеклистами -- Чеклист не выполнен: задачи с невыполненными чеклистами +- Всего с чек-листом: общее количество задач с чек-листами. +- Чеклист полностью выполнен: задачи с полностью выполненными чек-листами. +- Чеклист не выполнен: задачи с невыполненными чек-листами. #### По пользователю -- Список пользователей с количеством назначенных задач -- Визуализация в виде прогресс-баров -- Количество задач на каждого пользователя +- Список пользователей с количеством назначенных задач. +- Визуализация в виде прогресс-баров. +- Количество задач на каждого пользователя. #### Забытые задачи -Карточки, которые не обновлялись с момента создания +Карточки, которые не обновлялись с момента создания. #### Последние обновленные -Десять последних обновленных карточек +Десять последних обновленных карточек. ## Очередь задач @@ -1152,34 +1162,36 @@ sum(ingress_nginx_detail_requests_total) В верхней части виджета отображаются четыре ключевых показателя: -- **Размер очереди** — общее количество задач в очереди -- **Ожидающие задачи** — количество задач, ожидающих обработки -- **Активные воркеры** — количество активных воркеров (консьюмеров), обрабатывающих задачи -- **Задачи в очереди** — общее количество задач, включая новые и обрабатываемые +- **Размер очереди** — общее количество задач в очереди. +- **Ожидающие задачи** — количество задач, ожидающих обработки. +- **Активные воркеры** — количество активных воркеров (консьюмеров), обрабатывающих задачи. +- **Задачи в очереди** — общее количество задач, включая новые и обрабатываемые. #### Таблица воркеров Таблица содержит информацию о каждом активном воркере: -- **Название консьюмера** — идентификатор воркера (консьюмера) -- **Ожидающие задачи** — количество задач, назначенных данному воркеру и ожидающих обработки -- **Время простоя** — время с момента последней активности воркера +- **Название консьюмера** — идентификатор воркера (консьюмера). +- **Ожидающие задачи** — количество задач, назначенных данному воркеру и ожидающих обработки. +- **Время простоя** — время с момента последней активности воркера. -**Важно:** В таблице отображаются только активные воркеры. Воркеры, которые не обрабатывают задачи и неактивны более 5 минут, автоматически скрываются из списка. +{{< alert level="info" >}} +В таблице отображаются только активные воркеры. Воркеры, которые не обрабатывают задачи и неактивны более 5 минут, автоматически скрываются из списка. +{{< /alert >}} #### Таблица задач Таблица содержит детальную информацию о всех задачах в очереди: -- **UUID задачи** — уникальный идентификатор задачи -- **Тип** — тип задачи (например, `health_check`) -- **UUID ресурса** — идентификатор ресурса или сущности, к которой относится задача -- **Консьюмер** —название консьюмера, обрабатывающего задачу -- **Время простоя** — время с момента доставки задачи воркеру -- **Время доставки** — время, когда задача была доставлена воркеру +- **UUID задачи** — уникальный идентификатор задачи. +- **Тип** — тип задачи (например, `health_check`). +- **UUID ресурса** — идентификатор ресурса или сущности, к которой относится задача. +- **Консьюмер** —название консьюмера, обрабатывающего задачу. +- **Время простоя** — время с момента доставки задачи воркеру. +- **Время доставки** — время, когда задача была доставлена воркеру. - **Статус** — текущий статус задачи: - - **Новая** — задача добавлена в очередь, но еще не назначена воркеру - - **В обработке** — задача назначена воркеру и обрабатывается + - **Новая** — задача добавлена в очередь, но еще не назначена воркеру. + - **В обработке** — задача назначена воркеру и обрабатывается. ### Конфигурация diff --git a/content/documentation/release-notes/v1.0.0.ru.md b/content/documentation/release-notes/v1.0.0.ru.md index 6633933..d3f0006 100644 --- a/content/documentation/release-notes/v1.0.0.ru.md +++ b/content/documentation/release-notes/v1.0.0.ru.md @@ -141,4 +141,4 @@ weight: 1000 ### Самообслуживание и каталог -- Исправлена сортировка по ресурсу в разделе `Самообслуживание`. +- Исправлена сортировка по ресурсу в разделе «Самообслуживание». diff --git a/content/documentation/release-notes/v1.1.0.ru.md b/content/documentation/release-notes/v1.1.0.ru.md index f48fc3c..a9719d8 100644 --- a/content/documentation/release-notes/v1.1.0.ru.md +++ b/content/documentation/release-notes/v1.1.0.ru.md @@ -13,8 +13,8 @@ weight: 980 По умолчанию включены HTTP-заголовки безопасности (Content Security Policy, X-Frame-Options и др.), что может привести к следующим проблемам: -- **Iframe виджеты перестанут работать** — виджеты, использующие iframe для отображения внешнего контента, будут заблокированы политикой CSP -- **Иконки из внешних источников не будут отображаться** — если для объектов DDP используются иконки, загружаемые из внешних источников, они будут заблокированы +- **Iframe виджеты перестанут работать** — виджеты, использующие iframe для отображения внешнего контента, будут заблокированы политикой CSP. +- **Иконки из внешних источников не будут отображаться** — если для объектов DDP используются иконки, загружаемые из внешних источников, они будут заблокированы. **Чтобы сохранить предыдущее поведение:** @@ -93,9 +93,9 @@ weight: 980 - **Протокол MCP** — стандартизированный интерфейс для взаимодействия с AI моделями через JSON-RPC 2.0. - **Доступные инструменты**: - `get_resource_entities` — получение сущностей ресурсов платформы для анализа, - - `get_external_data` — выполнение HTTP запросов к внешним сервисам (GitLab, SonarQube, Kubernetes и др.). + - `get_external_data` — выполнение HTTP-запросов к внешним сервисам (GitLab, SonarQube, Kubernetes и др.). - **Интеграция с внешними клиентами** — поддержка подключения через LM Studio, Claude Desktop и другие MCP-совместимые клиенты. -- **Безопасность** — аутентификация через API токены, права доступа соответствуют правам пользователя. +- **Безопасность** — аутентификация через API-токены, права доступа соответствуют правам пользователя. ### Виджеты diff --git a/content/documentation/release-notes/v1.1.1.ru.md b/content/documentation/release-notes/v1.1.1.ru.md index da468e1..a1b6ba7 100644 --- a/content/documentation/release-notes/v1.1.1.ru.md +++ b/content/documentation/release-notes/v1.1.1.ru.md @@ -4,9 +4,10 @@ weight: 970 --- {{< alert level="info" >}} -Выпуск релиза планируется 17.12.2025 +Релиз выпущен 17.12.2025 {{< /alert >}} ## Исправленные проблемы -- Исправлена ошибка, при которой действия в последовательных сценариях не могли получить доступ к обновленным свойствам сущности, измененным предыдущими действиями. +- Решена проблема с доступом к обновленным свойствам сущности в последовательных сценариях. +- Решена проблема с удалением командных переменных. diff --git a/content/documentation/release-notes/v1.2.0.ru.md b/content/documentation/release-notes/v1.2.0.ru.md new file mode 100644 index 0000000..ef9bcdd --- /dev/null +++ b/content/documentation/release-notes/v1.2.0.ru.md @@ -0,0 +1,42 @@ +--- +title: v1.2.0 +weight: 960 +--- + +{{< alert level="info" >}} +Выпуск релиза планируется 29.01.2026 +{{< /alert >}} + +## Изменения, влияющие на обратную совместимость + +### Иконки + +Иконки теперь выбираются из централизованного каталога (встроенные иконки из библиотек или загруженные пользователями). Если ранее использовались иконки, заданные через URL, они перестанут отображаться. + +## Новые возможности + +### AI-агент + +Добавлен механизм безопасного хранения учетных данных для AI-провайдеров ([подробнее](../../user/ai-agent/#учетные-данные-для-провайдеров)). + +### Действия + +Добавлен параметр конфигурации `actions.logging.enabled`, позволяющий управлять выводом логов действий в stdout ([подробнее](../../admin/actions/overview/#логирование-запусков)). + +### Владение объектами + +Добавлена автоматическая установка текущего пользователя в качестве владельца создаваемых объектов ([подробнее](../../admin/security/rbac/#автоматическое-назначение-владельца-при-создании)). + +### Ролевая модель + +- Добавлены новые глобальные разрешения для управления иконками: `create:icons` и `delete:icons`. +- Добавлен пресет глобальной роли «Developer» для разработчиков с правами на чтение информации и выполнение действий. + +## Исправленные проблемы + +- Решена проблема с принудительной перегенерацией идентификатора объекта при открытии формы редактирования. +- Исправлена ролевая модель для редактирования переменных команд. +- Исправлено поведение параметра конфигурации `datasources.logging.enabled`. +- Исправлено зависание при создании секрета в Vault без параметра `allow_update`. +- Исправлена работа механизмов подтверждения и пропуска действий в процессах. +- Исправлен выбор внешних сервисов для действий в процессах. diff --git a/content/documentation/user/ai-agent.ru.md b/content/documentation/user/ai-agent.ru.md index a51fcf2..1a69dc5 100644 --- a/content/documentation/user/ai-agent.ru.md +++ b/content/documentation/user/ai-agent.ru.md @@ -19,6 +19,60 @@ AI-агент использует настраиваемые AI-провайд 1. **Ollama** — для работы с локальными моделями через Ollama. 1. **Custom** — для работы с любым кастомным REST API, совместимым с форматом запросов/ответов AI-агента. +### Учетные данные для провайдеров + +Для безопасного хранения токенов и ключей доступа к AI-провайдерам используется система учетных данных. Учетные данные шифруются и хранятся в базе данных, а в заголовки запросов к AI-провайдерам передаются через механизм шаблонизации. + +#### Добавление учетных данных + +Для добавления новых учетных данных для AI-провайдеров: + +1. В форме создания или редактирования провайдера нажмите кнопку **Управление учетными данными**. +1. В открывшемся диалоге нажмите **Добавить учетные данные**. +1. Введите пару ключ-значение: + - **Ключ**: название ключа учетных данных (например, `api_key`, `openai_token`, `bearer_token`). + - **Значение**: сам токен или ключ доступа. +1. Нажмите **Сохранить**. + +**Важно:** +- Ключ существующих учетных данных нельзя изменить. Для изменения ключа удалите старые учетные данные и создайте новые. +- Значение существующих учетных данных можно обновить, введя новое значение. +- Учетные данные шифруются при сохранении и никогда не передаются в веб-интерфейс после сохранения. + +#### Использование учетных данных в заголовках + +Вместо прямого указания токена в заголовках провайдера используйте синтаксис шаблонизации: + +```sh +Authorization: Bearer {{ .credentials.api_key }} +``` + +где `api_key` — это название ключа, которое вы указали при добавлении учетных данных. + +**Примеры:** + +Вместо: + +```sh +Authorization: Bearer sk-1234567890abcdef +``` + +Используйте: + +```sh +Authorization: Bearer {{ .credentials.openai_api_key }} +``` + +**Преимущества использования шаблонизации:** +- Токены не хранятся в открытом виде в базе данных. +- Учетные данные можно обновить без изменения конфигурации провайдера. +- Один набор учетных данных можно использовать в нескольких провайдерах. + +**Как это работает:** +1. Вы добавляете учетные данные через профиль пользователя. +2. В заголовках провайдера указываете шаблон `{{ .credentials.название_ключа }}`. +3. При выполнении запроса система автоматически заменяет шаблон на фактическое значение учетных данных. + ### Создание провайдера OpenAI (ChatGPT) Для настройки провайдера OpenAI выполните следующие шаги: @@ -31,13 +85,13 @@ AI-агент использует настраиваемые AI-провайд - **Модель**: укажите название модели, например `gpt-4` или `gpt-3.5-turbo`. - **URL**: `https://api.openai.com/v1/chat/completions`. - **Метод**: `POST`. - - **Заголовки**: добавьте заголовок авторизации: + - **Заголовки**: добавьте заголовок авторизации, используя учетные данные: ```sh - Authorization: Bearer YOUR_OPENAI_API_KEY + Authorization: Bearer {{ .credentials.openai_api_key }} ``` - где `YOUR_OPENAI_API_KEY` — ваш API ключ от OpenAI. + где `openai_api_key` — название ключа учетных данных (см. раздел [Учетные данные для провайдеров](#учетные-данные-для-провайдеров)). 1. Нажмите **Сохранить**. @@ -155,10 +209,12 @@ choices.0.message.content 1. **Заголовки**: ```sh - Authorization: Bearer YOUR_API_KEY + Authorization: Bearer {{ .credentials.api_key }} Content-Type: application/json ``` + где `api_key` — название ключа учетных данных (см. раздел [Учетные данные для провайдеров](#учетные-данные-для-провайдеров)). + 1. **Поле ответа**: `choices.0.message.content`. 1. **Шаблон тела запроса**: diff --git a/content/documentation/user/catalog.ru.md b/content/documentation/user/catalog.ru.md index 9ce4683..79d5a80 100644 --- a/content/documentation/user/catalog.ru.md +++ b/content/documentation/user/catalog.ru.md @@ -3,14 +3,12 @@ title: Каталог weight: 30 --- -Каталог — раздел платформы, который содержит список всех ресурсов, их параметров и связей, а также предоставляет пользователям возможность запускать сценарии для сущностей ресурсов. +Каталог — это раздел платформы, который содержит список всех ресурсов, их параметров и связей, а также предоставляет пользователям возможность запускать сценарии для сущностей ресурсов. Наполнение каталога возможно в ручном режиме, либо автоматизированно с использованием источников данных или вебхуков. ## Ресурсы -### Что такое ресурс - Ресурс — это шаблон или тип сущности в каталоге платформы. Ресурс определяет структуру данных, параметры и свойства, которые будут наследовать все сущности данного типа. Например, ресурс «Репозитории GitLab» описывает структуру данных для репозиториев GitLab, а каждая конкретная сущность этого ресурса представляет отдельный репозиторий. Основной принцип, заложенный в платформу, заключается в том, что модель данных настраивается администратором платформы. Администратор может самостоятельно создавать те ресурсы, которые ему необходимы. @@ -60,9 +58,7 @@ weight: 30 ## Сущности -### Что такое сущность - -Если ресурс — это шаблон или тип данных, то сущность — это конкретная единица каждого ресурса. Например, если ресурс называется «Группы» и является дочерним для ресурса «Gitlab», то каждая группа в Gitlab, зарегистрированная в платформе, является сущностью данного ресурса. +Сущность — это конкретная единица каждого ресурса. Например, если ресурс называется «Группы» и является дочерним для ресурса «Gitlab», то каждая группа в Gitlab, зарегистрированная в платформе, является сущностью этого ресурса. Сущности наследуют параметры ресурсов, при этом возможно задание параметров отдельно для каждой сущности. @@ -94,9 +90,9 @@ weight: 30 ### События -При создании, удалении, либо изменении спецификации любой сущности генерируется событие соответствующего типа: `ENTITY_CREATED`, `ENTITY_DELETED`, `ENTITY_UPDATED`. Эти события нужны для: +При создании, удалении, либо изменении спецификации любой сущности генерируется событие соответствующего типа: `ENTITY_CREATED`, `ENTITY_DELETED`, `ENTITY_UPDATED`. Эти события нужны для следующих целей: -- **Аудита** — какие изменения происходили с сущностью в течение ее жизненного цикла. -- **Настройки автоматизированных реакций** — на изменения спецификации сущности. +- **Аудит** — фиксация изменений, происходящих с сущностью в течение ее жизненного цикла. +- **Настройка автоматизированных реакций** — настройка реакций на изменения спецификации сущности. Время хранения событий ограничено и может быть настроено через файл конфигурации платформы. diff --git a/content/documentation/user/credentials.ru.md b/content/documentation/user/credentials.ru.md index 33b8388..72023a2 100644 --- a/content/documentation/user/credentials.ru.md +++ b/content/documentation/user/credentials.ru.md @@ -9,19 +9,20 @@ moduleStatus: experimental ## Как это работает -Все взаимодействие с инфраструктурными сервисами в DDP происходит с использованием учетных данных конкретного пользователя. Учетные данные шифруются перед сохранением в базе данных и расшифровываются только при необходимости их использования в действиях, источниках данных и виджетах. +Все взаимодействие с инфраструктурными сервисами в DDP происходит с использованием учётных данных конкретного пользователя. Учетные данные шифруются перед сохранением в базе данных и расшифровываются только при необходимости их использования в действиях, источниках данных и виджетах. Подробнее о механизме работы, шифровании и настройке см. в [документации](../../admin/security/credentials/). -## Заполнение учетных данных +## Заполнение учётных данных -Администратор платформы создает типы учетных данных в разделе **Администрирование** → **Учетные данные**. Для каждого типа учетных данных вы можете указать свои персональные реквизиты в профиле в разделе **Учетные данные**. +Администратор платформы создает типы учётных данных в разделе «Администрирование» → «Учетные данные». Для каждого типа учётных данных вы можете указать свои персональные реквизиты в профиле в разделе «Учетные данные». -Например, если администратор создал тип учетных данных **"Kubernetes token"**, то вы в своем профиле сможете добавить персональный токен для доступа в Kubernetes. +Например, если администратор создал тип учётных данных **Kubernetes token**, то вы в своем профиле сможете добавить персональный токен для доступа в Kubernetes. -**Важно:** -- После сохранения учетных данных вы не сможете посмотреть их значение, только обновить его -- В профиле отображается информация о том, заполнены ли те или иные учетные данные -- Учетные данные используются автоматически в действиях, источниках данных и виджетах, где они указаны в конфигурации +## Особенности работы с учётными данными -Подход к использованию учетных данных в действиях, источниках данных и виджетах описан в соответствующих разделах документации. +- После сохранения учётных данных вы не сможете посмотреть их значение, только обновить его. +- В профиле отображается информация о том, заполнены ли те или иные учётные данные. +- Учётные данные используются автоматически в действиях, источниках данных и виджетах, где они указаны в конфигурации. + +Подход к использованию учётных данных в действиях, источниках данных и виджетах описан в соответствующих разделах документации. diff --git a/content/documentation/user/mcp-server.ru.md b/content/documentation/user/mcp-server.ru.md index 94ece99..344a688 100644 --- a/content/documentation/user/mcp-server.ru.md +++ b/content/documentation/user/mcp-server.ru.md @@ -41,7 +41,7 @@ MCP — это открытый протокол для взаимодейств ### get_external_data -Выполнение HTTP запроса к внешнему сервису с использованием учетных данных пользователя. +Выполнение HTTP-запроса к внешнему сервису с использованием учетных данных пользователя. **Параметры:** @@ -49,14 +49,14 @@ MCP — это открытый протокол для взаимодейств |-------------------------|--------|-------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------| | `external_service_name` | строка | Название внешнего сервиса. Будет выполнен поиск по имени или slug сервиса | `sonarqube`, `gitlab`, `kubernetes` | | `query` | строка | Описание запроса | `get pipelines for project 123`, `get sonarqube projects`, `get all namespaces` | -| `api_path` | строка | Путь к API endpoint с параметрами запроса. Генерируется моделью на основе `query` и `external_service_name` | `/api/v4/projects?per_page=100&page=1` | +| `api_path` | строка | Путь к API-эндпоинт с параметрами запроса. Генерируется моделью на основе `query` и `external_service_name` | `/api/v4/projects?per_page=100&page=1` | | `method` | строка | HTTP-метод. По умолчанию: GET. Модель определяет правильный метод на основе `query` | `GET`, `POST`, `PUT`, `DELETE`, `PATCH` | -| `body` | строка | Тело запроса для POST/PUT/PATCH методов (JSON строка). Модель формирует правильное тело запроса на основе `query` | `{"title":"New MR","source_branch":"feature"}` | +| `body` | строка | Тело запроса для POST/PUT/PATCH-методов (JSON строка). Модель формирует правильное тело запроса на основе `query` | `{"title":"New MR","source_branch":"feature"}` | **Описание:** -Инструмент позволяет выполнять HTTP запросы к внешним сервисам, настроенным в платформе. Сервис находится по имени, затем автоматически получаются необходимые учетные данные пользователя (credentials), и выполняется HTTP запрос к указанному API endpoint. +Инструмент позволяет выполнять HTTP-запросы к внешним сервисам, настроенным в платформе. Сервис находится по имени, затем автоматически получаются необходимые учетные данные пользователя (credentials), и выполняется HTTP-запрос к указанному API-эндпоинту. -Модель должна самостоятельно определить правильный API endpoint, HTTP метод и тело запроса на основе описания запроса (`query`) и названия сервиса (`external_service_name`), используя свои знания об API различных сервисов. +Модель должна самостоятельно определить правильный API-эндпоинт, HTTP-метод и тело запроса на основе описания запроса (`query`) и названия сервиса (`external_service_name`), используя свои знания об API различных сервисов. **Важно:** - Для запросов типа «получить все» (get all) модель должна добавить параметры пагинации в `api_path` с максимальными значениями для сервиса. @@ -87,8 +87,8 @@ MCP — это открытый протокол для взаимодейств **Возвращаемые данные:** - `externalServiceName` — название внешнего сервиса. - `url` — полный URL запроса. -- `method` — использованный HTTP метод. -- `statusCode` — HTTP статус код ответа. +- `method` — использованный HTTP-метод. +- `statusCode` — HTTP-статус код ответа. - `headers` — заголовки ответа. - `body` — тело ответа (парсится как JSON, если возможно). @@ -123,7 +123,7 @@ MCP — это открытый протокол для взаимодейств 1. **Получение параметров** - Войдите в Deckhouse Development Platform. - - Получите ваш API токен в разделе настроек профиля. + - Получите ваш API-токен в разделе настроек профиля. - Запишите URL вашей платформы (например: `https://ddp.example.com`). 1. **Настройка в LM Studio** @@ -144,7 +144,7 @@ MCP — это открытый протокол для взаимодейств - **Authentication**: - **Type**: `Custom Header` или `API Key`. - **Header Name**: `X-API-TOKEN`. - - **Token**: вставьте ваш API токен от платформы. + - **Token**: вставьте ваш API-токен от платформы. 1. **Проверка подключения** @@ -171,7 +171,7 @@ MCP-сервер Deckhouse Development Platform совместим с любым 1. **Протокол**: JSON-RPC 2.0. 1. **Аутентификация**: - Заголовок: `X-API-TOKEN: YOUR_API_TOKEN`. - - Где `YOUR_API_TOKEN` — ваш API токен от платформы. + - Где `YOUR_API_TOKEN` — ваш API-токен от платформы. 1. **Метод**: POST. ### Пример запроса к MCP-серверу @@ -234,7 +234,7 @@ Content-Type: application/json ### Не удается подключиться к серверу - Проверьте правильность URL (должен заканчиваться на `/api/v2/mcp`). -- Убедитесь, что API токен действителен. +- Убедитесь, что API-токен действителен. - Проверьте, что платформа доступна с вашего компьютера. - Проверьте настройки файрвола и прокси. diff --git a/content/documentation/user/teams-users.ru.md b/content/documentation/user/teams-users.ru.md index 0c3524e..a4ec4a9 100644 --- a/content/documentation/user/teams-users.ru.md +++ b/content/documentation/user/teams-users.ru.md @@ -16,6 +16,6 @@ title: Команды и пользователи ### Последняя активность -Время последней активности пользователя в платформе. Отображается в таблице пользователей в разделе `Администрирование / Пользователи`. Обновляется при авторизации, либо при автоматической ротации JWT токена пользователя (интервал ротации зависит от конфигурации Dex и по умолчанию равен 10 минутам). +Время последней активности пользователя в платформе. Отображается в таблице пользователей в разделе «Администрирование» → «Пользователи». Обновляется при авторизации, либо при автоматической ротации JWT токена пользователя (интервал ротации зависит от конфигурации Dex и по умолчанию равен 10 минутам). -> Время последней активности не обновляется при использовании API токена, выписанного пользователем, либо при каких-либо действиях пользователя в платформе в интервале между автоматическими ротациями JWT токена. +> Время последней активности не обновляется при использовании API-токена, выписанного пользователем, либо при каких-либо действиях пользователя в платформе в интервале между автоматическими ротациями JWT токена. diff --git a/content/documentation/user/templating.ru.md b/content/documentation/user/templating.ru.md index f030af3..dcb0d9a 100644 --- a/content/documentation/user/templating.ru.md +++ b/content/documentation/user/templating.ru.md @@ -281,7 +281,7 @@ title: Шаблонизация ### Настройка глобальных переменных -Настройка глобальных переменных производится в разделе `Самообслуживание -> Глобальные переменные`. +Настройка глобальных переменных производится в разделе «Самообслуживание» → «Глобальные переменные». Применяются следующие правила именования: @@ -298,7 +298,7 @@ title: Шаблонизация Во всех действиях, сценариях и процессах можно использовать командные переменные. -Командные переменные настраиваются в разделе `Администрирование -> Команды` в меню редактирования команды. +Командные переменные настраиваются в разделе «Администрирование» → «Команды» в меню редактирования команды. Каждый пользователь может редактировать переменные тех команд, в которые он входит - это можно сделать в профиле пользователя. Чтобы получить значение командной переменной, используйте следующую конструкцию: @@ -384,7 +384,7 @@ title: Шаблонизация - `credentials` — указывает на то, что идет обращение к учётным данным. - `credentials_slug` — идентификатор учётных данных, значение которого необходимо подставить. -В данном случае идентификаторы учетных данных - это те идентификаторы, которые задается во вкладке `Авторизация` в разделе `Учетные данные` в диалогах конфигурации объектов DDP. +В данном случае идентификаторы учетных данных - это те идентификаторы, которые задается во вкладке «Авторизация» в разделе «Учетные данные» в диалогах конфигурации объектов DDP. Примеры использования: @@ -493,7 +493,7 @@ title: Шаблонизация Примеры использования: ```go -{{ .workflow.apiEndpoint }} // API endpoint из параметров сценария +{{ .workflow.apiEndpoint }} // API-эндпоинт из параметров сценария {{ .workflow.notificationEmail }} // Email для уведомлений из параметров сценария {{ .workflow.retryAttempts }} // Количество попыток повтора из параметров сценария ``` diff --git a/docker-compose.yml b/docker-compose.yml index 40d546c..1e3ea4a 100644 --- a/docker-compose.yml +++ b/docker-compose.yml @@ -6,7 +6,8 @@ services: ports: - "80:80" depends_on: - - hugo + hugo: + condition: service_healthy hugo: image: hugomods/hugo:debian-ci-0.150.1 @@ -18,3 +19,9 @@ services: volumes: - "./:/src" - "../hugo-web-product-module/:/hugo-web-product-module:ro" + healthcheck: + test: ["CMD-SHELL", "curl -s http://localhost:1313 > /dev/null || exit 1"] + interval: 5s + timeout: 2s + retries: 10 + start_period: 1s diff --git a/go.mod b/go.mod index ee1917e..fdb8258 100644 --- a/go.mod +++ b/go.mod @@ -4,4 +4,4 @@ module github.com/deckhouse/website-development-platform go 1.24.2 -require github.com/deckhouse/hugo-web-product-module v0.1.4 // indirect +require github.com/deckhouse/hugo-web-product-module v0.1.7 // indirect diff --git a/go.sum b/go.sum index 287fd5e..99c3c68 100644 --- a/go.sum +++ b/go.sum @@ -1,2 +1,2 @@ -github.com/deckhouse/hugo-web-product-module v0.1.4 h1:P+L59/PGPm6dFV9yAooOahyzzw2qcP1mzdAwJmI8COs= -github.com/deckhouse/hugo-web-product-module v0.1.4/go.mod h1:iLVlLSCkbOoi7RjYm5RjwAQi+Whs6DjSumhaH1GBjqw= +github.com/deckhouse/hugo-web-product-module v0.1.7 h1:Ld6iFf1G6QdyWGCxyCl5z7yQvtyVLMdwYAfXgWL3/YM= +github.com/deckhouse/hugo-web-product-module v0.1.7/go.mod h1:iLVlLSCkbOoi7RjYm5RjwAQi+Whs6DjSumhaH1GBjqw=