VK Dev Platform logo
Помощь
Обновлена 17 июля 2026 г. в 15:36

Дополнительные настройки

В пользовательских параметрах (answers_raw_custom_params) файла ответов answers_file.yaml можно задать настройки, поддерживаемые компонентами. Подробнее — в разделе Подготовка файла ответов.

Все параметры для настройки описаны в roles/*/README.md. Примеры дополнительных настроек представлены ниже.

Настройка ЗКУ

Начиная с версии 26.1.0, дополнительно настраивать Закрытый Контур Управления (ЗКУ) в VK Dev Platform не нужно. Чтобы включить ЗКУ, укажите в файле answers_file.yaml значение true для параметра gitlab_zku_enabled. Чтобы отключить — значение false.

Пример:

answers_raw_custom_params:  gitlab_zku_enabled: false # ЗКУ отключен

Настройка SSH-доступа к репозиториям GitLab

Инсталлятор поддерживает настройку протокола SSH для доступа к репозиториям GitLab. Чтобы включить доступ, укажите в файле answers_file.yaml:

answers_raw_custom_params:  gitlab_ssh_enable: true

Если нужно развернуть несколько экземпляров VK Dev Platform в одном кластере Kubernetes (сценарий для dev-стендов), задайте дополнительные параметры:

answers_raw_custom_params:  gitlab_ssh_separate_lb: true  gitlab_ssh_create_dns_record: true  gitlab_ssh_dns_record_name: ""

Настройка сбора логов

Агрегатор Vector принимает обработанные логи от агентов Vector и сохраняет их в Persistent Volume (PV). Вы можете настроить пересылку логов из агрегатора во внешние системы, задать размер PV и настроить работу утилиты logrotate. Полный список параметров для настройки — в файле roles/vector/README.md.

Перенаправление логов во внешние системы

В агрегаторе Vector входящие логи разделяются на два потока:

  • логи аудита route_by_category.audit;
  • логи приложений route_by_category.app.

Настройка интеграции с внешними системами сбора и обработки логов выполняется в переменной vector_sinks_extra.

Пример:

answers_raw_custom_params:  vector_aggregator:    vector_secret_generic:      password: "{% raw %}{{ all_vector_auth_password }}{% endraw %}"      clickhouse-password: "{% raw %}{{ all_clickhouse_password }}{% endraw %}"    vector_envs:      - name: HTTP_AUTH_PASSWORD        valueFrom:          secretKeyRef:            name: "{% raw %}{{ vector_release_name }}{% endraw %}"            key: password      - name: CLICKHOUSE_PASSWORD        valueFrom:          secretKeyRef:            name: vector-aggregator            key: clickhouse-password    vector_sinks_extra:      clickhouse:        auth:          password: "${CLICKHOUSE_PASSWORD}"          strategy: basic          user: default        batch:          max_events: 10000          timeout_secs: 1        database: my_ch_db        encoding:          timestamp_format: unix_ms        endpoint: http://clickhouse.example.com        inputs:          - route_by_category.audit          - route_by_category.app        skip_unknown_fields: true        table: logs        type: clickhouse

В этом примере:

  • Нужно добавить зашифрованный пароль от ClickHouse all_clickhouse_password в файл /shepherd/inventories/<ИМЯ_INVENTORY>/group_vars/all/secrets_custom.yaml.
  • В секциях vector_secret_generic и vector_envs указаны параметры, значения которых определены в файле base.yaml. Это нужно, чтобы не потерять эти значения, так как добавление в список новых параметров недоступно.

Сбор логов аудита

Логи аудита собираются из компонентов Samsara и Nexus. Их можно перенаправить из агрегатора Vector во внешние системы из потока route_by_category.audit.

Управление сбором логов

Централизованное включение и отключение логирования настраивается в файле answers_file.yaml параметром answers_logs_collection_enabled.

Дополнительное включение или отключение логирования отдельных сервисов выполняется через соответствующие переменные, которые можно получить командой:

$ grep -r "_log_collect_enabled" roles/**/README.md

Пример вывода:

roles/front/README.md:| front_log_collect_enabled | false | Переключатель сбора логов агентом vector  |roles/gitlab/README.md:| gitlab_log_collect_enabled | `false` | Переключатель сбора логов агентом vector |roles/keycloak/README.md:| keycloak_log_collect_enabled | false | Переключатель сбора логов агентом vector  |roles/nexus/README.md:| nexus_log_collect_enabled | false | Флаг активации сбора логов |roles/oidc-proxy/README.md:| oidc_proxy_log_collect_enabled | false | Флаг активации сбора логов |roles/redis/README.md:| redis_log_collect_enabled | false | Переключатель сбора логов агентом vector |roles/samsara/README.md:| samsara_log_collect_enabled | false | Переключатель сбора логов агентом vector  |roles/sonarqube/README.md:| sonarqube_log_collect_enabled | false | Флаг активации сбора логов |roles/zalando/README.md:| zalando_log_collect_enabled | false | Переключатель сбора логов агентом vector |

Изменения применяются после генерации Inventory и запуска плейбука playbooks/data-plane.yaml для роли.

Настройка уровня логирования

Настройка уровня логирования поддерживается для компонентов Samsara и Nexus.

Для Samsara укажите в файле answers_file.yaml:

answers_raw_custom_params:  samsara_logger_level: "INFO"

Для Nexus укажите в файле answers_file.yaml:

answers_raw_custom_params:  nexus_log_level: "INFO"

Настройка мониторинга

Начиная с версии 1.7.0, доступен сбор метрик с подов приложений на базе VMAgent.

VMAgent устанавливается опционально и выключен по умолчанию. Для его установки добавьте в файл answers_file.yaml:

answers_raw_custom_params:  vmagent_enable: true  vmagent_install: true

Все доступные параметры для настройки указаны в файле roles/vmagent/README.md.

Пример настройки для отправки метрик во внешнюю систему сбора метрик:

answers_raw_custom_params:  vmagent_remote_write_list:    - url: http://victoria-metrics.example.com/api/v1/write

Чтобы включить сбор метрик компонента Samsara, дополнительно добавьте в файл answers_file.yaml:

answers_raw_custom_params:  samsara_metrics_scrape_enabled: true

Настройка класса хранения

Если в кластере Kubernetes не установлен класс хранения по умолчанию или нужно изменить это значение, задайте класс хранения в соответствующих переменных файла answers_file.yaml:

answers_raw_custom_params:  nexus_storage_class: "storage-class-name"  pgadmin_storage_class: "storage-class-name"  redis_master_pv_storage_class: "storage-class-name"  samsara_temp_storage_class_name: "storage-class-name"  sonarqube_persistent_storage_class: "storage-class-name"  zalando_pg_cluster_storage_class: "storage-class-name"

Настройка почты для обращения в поддержку

Чтобы указать почту для обращения в техническую поддержку, заполните следующий параметр в файле answers_file.yaml:

answers_raw_custom_params:  front_env_support_email: support@example.com

Переопределение доменных имен сервисов

Доменные имена сервисов, которые используются по умолчанию, заданы в параметрах секции all_dns_records_extra:

all_dns_records_default:  portal: "portal.{{ all_domain }}"  gitlab: "gitlab.{{ all_domain }}"  keycloak: "keycloak.{{ all_domain }}"  nexus: "nx.{{ all_domain }}"  nexus_anonymous: "nxa.{{ all_domain }}"  pgadmin: "pgadmin.{{ all_domain }}"  sonarqube: "sonarqube.{{ all_domain }}"  vector_aggregator: "vector-aggregator.{{ all_domain }}"

Изменить эти значения можно через переменную all_dns_records_extra.

Пример переопределения доменного имени для компонента gitlab с сохранением поддоменной части в файле answers_file.yaml:

answers_raw_custom_params:  all_dns_records_extra:    gitlab: "{% raw %}code.{{ all_domain }}{% endraw %}"

В этом примере доменное имя gitlab.mydomain.ru заменяется на code.mydomain.ru.

Настройка интеграции с внешними системами

Интеграция с VK Cloud

Для интеграции с публичным облаком VK Cloud требуется токен Hoe — сервисный токен для авторизации в облачном сервисе Hoe.

  1. Обратитесь в техническую поддержку VK Cloud, чтобы получить токен Hoe.

  2. Зашифруйте токен Hoe с помощью Ansible Vault и сохраните его в переменной samsara_vkc_service_token:

    $ ansible-vault encrypt_string --vault-password-file /shepherd/.env/<ФАЙЛ_С_ПАРОЛЕМ_ДЛЯ_VAULT> --name samsara_vkc_service_token "<ТОКЕН_HOE>"
  3. Скопируйте вывод команды в файл /shepherd/inventories/<ИМЯ_INVENTORY>/group_vars/samsara/secrets_custom.yaml.

  4. Запустите развертывание c тегом --tags samsara-role для настройки токена на бэкенде VK Dev Platform (подробнее — в разделе Запуск развертывания отдельной роли).

Интеграция с TeamStorm

  1. Создайте сервисную учетную запись в TeamStorm, если она еще не создана (подробнее — в разделе Внешние интеграции). После создания вы получите токен TeamStorm.

  2. Зашифруйте токен TeamStorm с помощью Ansible Vault и сохраните его в переменной samsara_teamstorm_token:

    $ ansible-vault encrypt_string --vault-password-file /shepherd/.env/<ФАЙЛ_С_ПАРОЛЕМ_ДЛЯ_VAULT>` --name samsara_teamstorm_token "<ТОКЕН_TEAMSTORM>"
  3. Скопируйте вывод команды в файл /shepherd/inventories/<ИМЯ_INVENTORY>/group_vars/samsara/secrets_custom.yaml.

  4. Запустите развертывание с тегом --tags samsara-role для настройки токена на бэкенде VK Dev Platform (подробнее — в разделе Запуск развертывания отдельной роли).

Интеграция с Test IT

  1. Создайте сервисную учетную запись в Test IT, если она еще не создана (подробнее — в разделе Внешние интеграции). После создания вы получите токен Test IT.

  2. Зашифруйте токен Test IT с помощью Ansible Vault и сохраните его в переменной samsara_testit_token:

    $ ansible-vault encrypt_string --vault-password-file /shepherd/.env/<ФАЙЛ_С_ПАРОЛЕМ_ДЛЯ_VAULT>` --name samsara_testit_token "<ТОКЕН_TEST_IT>"
  3. Скопируйте вывод команды в файл /shepherd/inventories/<ИМЯ_INVENTORY>/group_vars/samsara/secrets_custom.yaml.

  4. Запустите развертывание c тегом --tags samsara-role для настройки токена на бэкенде VK Dev Platform (подробнее — в разделе Запуск развертывания отдельной роли).

Настройки для повышения безопасности (Hardening)

Начиная с версии 26.2.0, доступны дополнительные настройки для повышения безопасности компонентов VK Dev Platform.

Повышение безопасности Zalando Postgres

Чтобы повысить безопасность паролей, включите хеширование scram-sha-256 вместо md5.

Для развернутых кластеров Zalando Postgres:

  1. Получите список пользователей и их хешированные пароли:

    SELECT rolname, left(rolpassword, 30) AS pass_hashFROM pg_authidWHERE rolcanlogin = trueORDER BY rolname;

    Пример вывода:

    rolname              |           pass_hash-------------------------------+-------------------------------- postgres                      | md5aac48381e758a9aa01d7242e188 standby                       | md5c08f4d484ac35adce891687ab2e example-cluster-devplatform-portal.samsara | md5e5258c1d482834c18a968d63617 example-cluster-gitlab.gitlab | md54429bcdbdcce25aa78e875eb1cd example-cluster-gitlab.gitlab_praefect | md5b2b6748fc720b31948f3f272900 example-cluster-keycloak.keycloak | md56c3557fb053cc134347d09f924e example-cluster-nexus.nexus   | md50585ef3e0fbb17c38dcaf076dc1 example-cluster-sonarqube.sonarqube | md554885e435887e95f79152a5ef28(8 rows)

    Если все хеши начинаются с md5, пароли хранятся в формате MD5. Их нужно захешировать заново.

  2. Убедитесь, что параметр password_encryption принимает значение scram-sha-256:

    SHOW password_encryption;

    Пример вывода:

    password_encryption--------------------- scram-sha-256(1 row)

    Если значение отличается, установите его:

    SET password_encryption = 'scram-sha-256';
  3. Зашифруйте заново пароли для всех ролей:

    1. Получите текущий пароль пользователя из соответствующего секрета Kubernetes:

      $ kubectl -n zalando get secret example-cluster-gitlab.gitlab \  -o jsonpath='{.data.password}' | base64 -d
    2. Укажите пароль, чтобы захешировать его заново с использованием scram-sha-256:

      ALTER USER postgres PASSWORD '<ПАРОЛЬ_ИЗ_СЕКРЕТА>';ALTER USER standby PASSWORD '<ПАРОЛЬ_ИЗ_СЕКРЕТА>';
    3. Повторите для всех ролей.

  4. Укажите механизм хеширования в файле answers_file.yaml:

    answers_raw_custom_params:  zalando_postgres_pg_hba_password_encryption: scram-sha-256
  5. Запустите плейбук playbooks/data-plane.yaml:

    $ ansible-playbook -i inventories/<ИМЯ_INVENTORY> --vault-password-file .env/<ФАЙЛ_С_ПАРОЛЕМ_ДЛЯ_VAULT> playbooks/data-plane.yaml

Новые подключения будут использовать аутентификацию scram-sha-256.

Повышение безопасности OIDC Proxy

В файле answers_file.yaml укажите настройки OIDC Proxy:

  1. Для роли nexus:

    1. Настройте тайм-ауты:

      answers_raw_custom_params:  nexus_oidc_proxy_haproxy_timeout_client: 50000ms  nexus_oidc_proxy_haproxy_timeout_connect: 5000ms  nexus_oidc_proxy_haproxy_timeout_server: 50000ms
    2. Установите дополнительные параметры в переменных nexus_oidc_proxy_haproxy_global_extra и nexus_oidc_proxy_haproxy_defaults_extra:

      answers_raw_custom_params:  nexus_oidc_proxy_haproxy_global_extra:    - "ssl-default-bind-ciphers ECDHE-ECDSA-AES128-GCM-SHA256"    - "ssl-default-bind-options ssl-min-ver TLSv1.2"    nexus_oidc_proxy_haproxy_defaults_extra:    - "timeout http-request 5s"    - "option http-buffer-request"
  2. Для роли sonarqube:

    1. Настройте тайм-ауты:

      answers_raw_custom_params:  sonarqube_oidc_proxy_haproxy_timeout_client: 50000ms  sonarqube_oidc_proxy_haproxy_timeout_connect: 5000ms  sonarqube_oidc_proxy_haproxy_timeout_server: 50000ms
    2. Установите дополнительные параметры в переменных sonarqube_oidc_proxy_haproxy_global_extra и sonarqube_oidc_proxy_haproxy_defaults_extra:

      answers_raw_custom_params:    sonarqube_oidc_proxy_haproxy_global_extra:      - "ssl-default-bind-ciphers ECDHE-ECDSA-AES128-GCM-SHA256"      - "ssl-default-bind-options ssl-min-ver TLSv1.2"        sonarqube_oidc_proxy_haproxy_defaults_extra:      - "timeout http-request 5s"      - "option http-buffer-request"

Повышение безопасности Nexus

Роль nexus позволяет задать кастомный ключ шифрования для секретов в БД. Ключ задается в переменной nexus_custom_encryption_key в виде произвольной буквенно-цифровой строки, зашифрованной с помощью Ansible Vault.

По умолчанию переменная nexus_custom_encryption_key не задана. В этом случае Nexus использует ключ шифрования по умолчанию — в разделе System Status пользовательского интерфейса Nexus будет отображаться соответствующее предупреждение.

Чтобы задать ключ шифрования:

  1. Укажите значение переменной nexus_custom_encryption_key в файле answers_file.yaml.
  2. Запустите роль nexus повторно. Секреты в БД будут зашифрованы заново новым ключом.