.. _config_description: Описание конфигурационного файла Агента ПОДД ============================================== Состав и содержание файлов конфигурирования --------------------------------------------- Состав дистрибутива Агента ПОДД СМЭВ (/distr/einfahrt): - ``/distr/einfahrt/s3_creds.properties`` – (опционально) креденшелы для подключения к хранилищу S3; - ``/distr/einfahrt/customLogLevels.xml`` – файл описания настроек логирования; - ``/distr/einfahrt/postgresql.json`` – файл описания профиля Витрины; - ``/conf/*.yml`` – заготовки конфигурационных файлов для Потребителя и Поставщика, для тестовой и продуктивной среды. В директории ``/conf/`` пакета находятся типовые заготовки конфигурационного файла. Необходимо взять заготовку конфигурационного файла в соответствии с потребностями: - шаблоны конфигурационного файла Агента для продуктивной среды: - ``conf/prod-consumer-application.yml`` – для Потребителя. - ``conf/prod-producer-application.yml`` – для Поставщика. - шаблоны конфигурационного файла Агента для продуктивной среды (2-х ЦОДовая конфигурация: ФЦОД, РЦОД): - ``conf/prodMC-consumer-application.yml`` – для Потребителя. - ``conf/prodMC-producer-application.yml`` – для Поставщика. - шаблоны конфигурационного файла Агента для тестовой среды (ТПОДД): - ``conf/test-consumer-application.yml`` – для Потребителя. - ``conf/test-producer-application.yml`` – для Поставщика. Скопировать выбранный файл в каталог ``/distr/einfahrt`` под именем ``application.yml``. В скопированном конфигурационном файле ``application.yml`` задать необходимые параметры (в заготовке обозначены звездочками ``*``). Более подробное описание необходимых настроек файла ``application.yml`` указаны в разделах ниже. .. _changes_reestr: Реестр изменений файлов конфигурирования ----------------------------------------- :numref:`tab_reestr` содержит Реестр изменений. Фиксация изменений в данном документе ведётся с версии 2.11.0. .. _tab_reestr: .. table:: Реестр изменений файлов конфигурирования +--------+----------------------------------------------------------------------------+ | Версия | Перечень изменений (относительно предыдущей версии) | +========+============================================================================+ | 3.8.0 | - Версия JDK обновлена до 17.0.7. | | | | | | - Изменен формат указания подключения к keycloak: | | | nodes.ID.pulsar.auth.keycloak-oauth.auth-server-url изменен на список | | | адресов url в параметре nodes.ID.pulsar.auth.keycloak-oauth.auth-server; | | | | | | - Добавлены параметры времени активации Агента (:ref:`time_set`); | | | | | | - Добавлен параметр управления используемым транспортом (pulsar/rsocket): | | | agent.use-ca (:ref:`common_settings`); | | | | | | - Удален параметр настройки передачи событий Витрины в СЦЛ через | | | rsocket cls.datamart.use-ca, транспорт определяется общим параметром | | | agent.use-ca (:ref:`common_settings`); | | | | | | - Добавлено ограничение на использование транспорта rsocket при обмене | | | по Регламентированным REST-запросам (см. :ref:`connect_smev`) | | | | | | - значение параметра agent.use-ca должно быть true как на стороне | | | Потребителя, так и на стороне Поставщика (:ref:`common_settings`); | | | | | | - версия Агента Потребителя и Поставщика должна быть не ниже 3.7.0; | | | | | | - Потребитель и Поставщик должны использовать единый транспорт | | | (rsocket/pulsar). | | | | | | - удалены параметры подключения к pulsar: | | | | | | - data-center.default-node.pulsar.auth.keycloak-oauth.realm | | | | | | - data-center.default-node.pulsar.auth.keycloak-oauth.grant_type | | | | | | - data-center.default-node.pulsar.auth.keycloak-oauth.client_id | | | | | | - добавлены параметры (:ref:`auth_type_set`) выбора способа аутентификации | | | | | | - data-center.default-node.pulsar.auth.keycloak-oauth.auth-type | | | | | | - data-center.default-node.pulsar.auth.keycloak-oauth.auth-protocol | | | | | | - добавлен параметр, управляющий сохранением метаданных на локальном | | | диске (:ref:`meta_local_store_set`) | | | | | | - query.metadata.storeToDb | +--------+----------------------------------------------------------------------------+ .. _config: Формирование конфигурационного файла Агента ПОДД ------------------------------------------------- .. _common_settings: Общие настройки Агента ~~~~~~~~~~~~~~~~~~~~~~ .. attention:: Не поддерживается одновременная работа более одного экземпляра Агента с одним и тем же agent.id. Исключение – масштабируемый Агент-Потребитель (см. :ref:`set_agent`) 1. При необходимости настроить список активного функционала Агента ПОДД. *Предоставляемый шаблон конфигурационного файла имеет настройку по умолчанию для данного параметра. Применять изменения следует только в случае, если значения по умолчанию не подходят для данного Агента ПОДД.* Параметр необязательный и может отсутствовать в конфигурационном файле. По умолчанию активен весь функционал Агента ПОДД. .. code-block:: yaml # Общие настройки агента # Оставить только нужные профили (т.е. только профили используемого функционала) spring: profiles: active: # потребитель SQL-запросов - QueryConsumer # поставщик ответов на SQL-запросы - QueryProvider # потребитель уведомлений - ReplicationConsumer # поставщик дельт по подпискам - ReplicationProvider # потребитель REST РЗ - ApiGwConsumer # поставщик ответов по REST РЗ - ApiGwProvider Пример: в случае использования Агента только как Инициатора (Поставщика), следует указать в данном списке в конфигурационном файле только значения *Consumer 2. Указать идентификатор Агента ПОДД и задать настройки используемого транспорта (pulsar/rsocket): .. code-block:: yaml agent: # Идентификатор (мнемоника) агента # При использовании id или ogrn состоящих только из цифр, их следует заключать в одинарные или двойные кавычки id: *** ИДЕНТИФИКАТОР (МНЕМОНИКА) АГЕНТА *** ogrn: '*** ОГРН АГЕНТА ***' # использовать традиционный транспорт обмена с Ядром (pulsar, значение false) # либо прогрессивный вариант транспорта (rsocket, значение true) use-ca: false .. _cryptopro_set: Настройка CryptoPro ~~~~~~~~~~~~~~~~~~~~ Указать идентификатор и пароль ключа CryptoPro: .. code-block:: yaml keys: alias: *** ИДЕНТИФИКАТОР КЛЮЧА CryptoPro *** В случае, если алиас ключа КриптоПро содержит пробелы, его следует заключить в одинарные кавычки. Ключ с указанным алиасом должен быть в наличии на стороне компонента **notarius**, также необходимо его упоминание в списке ключей в конфигурационном файле компонента notarius, см. раздел :ref:`set_notarius`. .. _reg_set: Настройка регистрации Витрин данных и подключения к kafka (при использовании Витрин) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .. _topic_set: Настройка создания топиков Агентом ПОДД ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Далее приведено описание раздела конфигурации для настройки создания топиков Агентом ПОДД. Доступна настройка взаимодействия нескольких схем Витрины данных через одну группу топиков. Схемы Витрины могут общаться через одну группу топиков только в случае, если относятся к одному ПО «Витрина данных» и являются схемами одной (физической) Витрины. Блок параметров ``datamarts.create-topics`` может отсутствовать в конфигурационном файле, в этом случае используются значения по умолчанию: включено автоматическое создание топиков для всех видов информационного обмена (Регламентированные SQL-запросы, Рассылки), отключено автоматическое создание топиков регистрации и настройки Витрин. :numref:`tab_params` содержит соответствие создаваемых топиков Apache Kafka параметрам конфигурационного файла. .. _tab_params: .. table:: Соответствие параметров конфигурационного файла и создаваемых топиков +---+----------------------------------+---------------------+-------------------------------------------------+ | № | Настройка | Параметр | Создаваемые топики [#]_ | +===+==================================+=====================+=================================================+ | 1 | Топики для информационного | query | - Топики для обеспечения информационного обмена | | | обмена с использованием | | с использованием SQL-запросов; | | | Регламентированных SQL-запросов | | | | | | | - Топики для получения статистики по Витринам; | | | | | | | | | | - Топики для получения событий Витрины. | +---+----------------------------------+---------------------+-------------------------------------------------+ | 2 | Топики для информационного | Replication, | - Топики для обеспечения информационного обмена | | | обмена с использованием Рассылок | | с использованием подписок (для Поставщика); | | | | ReplicationProvider | | | | | | - Топики для получения событий Витрины. | | | +---------------------+-------------------------------------------------+ | | | Replication, | - Топики для обеспечения информационного обмена | | | | ReplicationConsumer | с использованием подписок (для Потребителя); | | | | | | | | | | - Топики для получения событий Витрины | +---+----------------------------------+---------------------+-------------------------------------------------+ | 3 | Топики регистрации и настройки | config | Топики регистрации и настройки Витрин | | | Витрин | | | +---+----------------------------------+---------------------+-------------------------------------------------+ .. [#] В соответствии с разделами 2.3 и 2.5 документа «Методические рекомендации по работе с ПОДД СМЭВ», размещенном на портале ЕСКС – https://info.gosuslugi.ru/ Для настройки создания топиков для обмена по Рассылкам только для Поставщика или Потребителя необходимо использовать настройки активного функционала Агента ПОДД ``Replication``, указанные в :ref:`common_settings`. Если инициатором обмена по Рассылке является Витрина или ИС Потребителя для корректного осуществления обмена необходимо задать один из видов настроек: - при использовании режима COMPATIBLE прописать Витрину в блоке ``datamarts:[]`` - установить режим ENABLED для создания общей группы топиков при старте Агента. В случае отсутствия Витрин у Агента ПОДД есть возможность отключить функционал в соответствии с :ref:`common_settings`. В этом случае раздел ``datamart-registration`` может полностью отсутствовать в конфигурационном файле. .. code-block:: yaml # Общие настройки витрин datamart: # автоматическое создание топиков витрины create-topics: # регистрация и настройка витрины config: false # информационный обмен с использованием SQL query: true # репликация replication: true # подключение к Kafka для взаимодействия с витринами kafka-bootstrap-servers: {{ kafka_link }} # Настройки регистрации витрин. # - Витрины могут регистрироваться в агенте двумя способами: # - статически - витрина прописывается в конфиге агента (блок datamarts:), в этом случае используются # прописанные для данной витрины настройки, топики витрины создаются и слушаются агентом при старте; # - динамически - автоматическая регистрация, в этом случае используется общий набор настроек (блок dynamic:); # - Если агенту приходит сообщение из ядра для незарегистрированной витрины, агент регистрирует её динамически. # - Регистрация витрины также может быть инициирована со стороны витрины, через специальный топик, в # этом случае витрина регистрируется динамически, если она не прописана статически. Это позволяет # получать профиль запросом с витрины при динамической регистрации. # - Через некоторый таймаут (inactive-cleanup-delay) если к витрине не приходят запросы, агент её # деактивирует (выключаются потребители и удаляются топики) для экономии ресурсов; # - Если агенту приходит сообщение из ядра для деактивированной витрины, агент её активирует обратно. # - Профиль витрины отсылается в ядро каждый раз при старте агента для всех динамически и статически # зарегистрированных витрин, а также во время динамической регистрации витрин; datamart-registration: # Список статически регистрируемых витрин. # Можно задать пустой список [], параметры витрины: # id - *** ИДЕНТИФИКАТОР ВИТРИНЫ (мнемоника витрины ПОДД в нижнем регистре) *** # defined-profile - путь к файлу с предустановленным профилем витрины # Например file:C:/profile.json, по умолчанию используется встроенный профиль datamart_profile/postgresql.json; # inactive-cleanup-delay - задержка перед деактивацией витрины, 0 - никогда не деактивировать, по умолчанию 0; # topic-name-prefix - *** ЛИБО ИДЕНТИФИКАТОР ВИТРИНЫ (если не указывать, то по умолчанию id витрины) / ЛИБО ИДЕНТИФИКАТОР ГРУППЫ ВИТРИН *** datamarts: - id: {{ vitrine_id1 }} # Предустановленный профиль. В данном примере используется профиль витрины по умолчанию, находящийся внутри исполняемого пакета Агента definedProfile: datamart_profile/postgresql.json - id: {{ vitrine_id2 }} # Профиль витрины. Используется конфигурируемый пользователем файл postgresql.json. # В данном примере файл находится в корневом каталоге Агента (там же, где конфигурационный файл application.yml). # Возможно расположение файла профиля витрины по любому пути с любым названием. # В этом случае исползуется формат file:/путь/к/файлу/имя.файла definedProfile: file:postgresql.json # Настройки для динамически регистрируемых витрин dynamic: # Режим работы динамической регистрации: # - ENABLED - динамическая регистрация включена, общие топики создаются и слушаются агентом при старте; # - COMPATIBLE - режим по умолчанию, для обратной совместимости. Если список статических витрин пуст (datamarts: []) # то работает аналогично как в режиме ENABLED. Если список статических витрин не пуст, то общие топики создаются # при первой динамической регистрации витрины; # - DISABLED - динамическая регистрация отключена; mode: COMPATIBLE # Путь к файлу с предустановленным профилем витрины. Например file:C:/profile.json defined-profile: datamart_profile/postgresql.json # Задержка перед деактивацией витрины, 0 - никогда не деактивировать inactive-cleanup-delay: 0 # Префикс имен топиков, по умолчанию без префикса topic-name-prefix: '' Если схема Витрины не прописана в блоке ``datamart-registration.datamarts``, то она будет подключена через группу топиков, используемую по умолчанию. Если прописать в конфиге несколько Витрин статически, а префикс оставить по умолчанию, то будет создана отдельная группа топиков для каждой из прописанных статически Витрин (с соответствующим префиксом). Если прописать в конфиге несколько Витрин статически и задать префикс, то все Витрины, прописанные статически, будут общаться через общую группу с указанным префиксом. Схемы Витрины, указанные в блоке ``datamart-registration.datamarts``, могут быть сконфигурированы для общения через отдельную группу топиков или через группу топиков по умолчанию. Например:. .. code-block:: yaml datamart-registration: datamarts: # подключение через группу топиков со значением префикса по умолчанию - id: {{ vitrine_id1 }} topic-name-prefix: 'vitrine_id1' # подключение нескольких схем Витрин через отдельную группу топиков - id: {{ vitrine_id2 }} topic-name-prefix: 'common' - id: {{ vitrine_id3 }} topic-name-prefix: 'common' # подключение через группу топиков по умолчанию, в соответствии с настройками в блоке dynamic - id: {{ vitrine_id4 }} topic-name-prefix: '' dynamic: mode: COMPATIBLE inactive-cleanup-delay: 0 topic-name-prefix: '' Настройка взаимодействия через пользовательские топики (опционально) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Для настройки взаимодействия с Витриной через пользовательские топики необходимо: 1. Отключить автосоздание топиков Apache Kafka Агентом, указав следующие значения параметров в конфигурационном файле Агента: .. code-block:: yaml datamart: # автоматическое создание топиков витрины create-topics: # регистрация и настройка витрин config: false # информационный обмен с использованием SQL query: false # репликация replication: false 2. Отключить возможность автосоздания топиков на стороне kafka. Для этого в конфигурации Apache Kafka указать параметр auto.create.topics.enable=false в соответствии с https://kafka.apache.org/documentation/. 3. Создать в Apache Kafka необходимые топики вручную в соответствии с https://kafka.apache.org/documentation/#basic_ops_add_topic. 4. Если имена созданных топиков отличаются от имен по умолчанию, указать в конфигурационном файле Агента имена используемых топиков. В примере указаны имена топиков, используемые по умолчанию: .. code-block:: yaml replication: subscription: # Топик запросов на регистрацию подписки (Агент -> Витрина) registration-request-topic: replication.rq # Топик ответов с успешным результатом регистрации подписки (Витрина -> Агент) registration-result-topic: replication.rs # Топик ответов с ошибками регистрации подписки (Витрина -> Агент) registration-error-topic: replication.err # Топик запросов на отмену подписки у поставщика (Агент -> Витрина) cancel-request-topic: replication.cancel.rq # Топик ответов с результатом отмены подписки у поставщика (Витрина -> Агент) cancel-result-topic: replication.cancel.rs # Топик запросов на отмену подписки у потребителя (Агент -> Витрина) cancel-consumer-request-topic: replication.cancel.in.rq # Топик ответов с результатом отмены подписки у потребителя (Витрина -> Агент) cancel-consumer-result-topic: replication.cancel.in.rs # Топик команд по репликации посылаемых от витрины в сторону ядра (Витрина -> Агент) command-topic: command.podd # Параметры конфигурирования топиков для запросов/ответов на создание хранилищ реплик (Агент <-> Витрина) storage: # Топик запросов на создание структуры для хранения реплик (Агент -> Витрина) request-topic: replication.in.rq # Топик ответов с ошибками создания структуры хранения реплик (Витрина -> Агент) error-topic: replication.in.err # Топик ответов с успешным результатом создания структуры хранения реплик (Витрина -> Агент) response-topic: replication.in.rs # Параметры конфигурирования топиков работы с дельтами (Агент <-> Витрина) delta: # Топик запросов на получение дельт от поставщиков (Агент -> Витрина) request-topic: delta.rq # Топик запросов на получение дельт от поставщиков (Агент -> Витрина) request-tp-topic: delta.tp # Топик чанков с дельтами (Витрина -> Агент) response-topic: delta.rs # Топик ответов с ошибками для реплик (Витрина -> Агент) error-topic: delta.err # Топик чанков на применение дельты потребителем (Агент -> Витрина). # По умолчанию топик настроен под старую реализацию витрины. Для новой реализации витрины # которая поддерживает распределенные подписки, не важно, используете вы распределенные # подписки или обычные, в настройках агента за которым стоит новая реализация витрины # надо поменять имя топика на delta.in.tp: apply-request-topic: delta.in.rq # Топик чанков на применение дельты потребителем (Агент -> Витрина) apply-request-tp-topic: delta.in.tp # Топик ответов с ошибками применения дельты (Витрина -> Агент) apply-error-topic: delta.in.err # Топик ответов с успешным результатом применения дельты (Витрина -> Агент) apply-response-topic: delta.in.rs # Топик уведомлений о новых данных по подпискам от поставщика (Витрина -> Агент) notification-topic: delta.notification # Топик уведомлений потребителя о новых данных по подпискам (Агент -> Витрина) notification-datamart-topic: delta.notification.in # Настройки модуля обработки SQL подзапросов из ядра ПОДД к витрине данных sub-query: # Настройки получения SQL подзапроса из ядра и отправки его в витрину request: # Топик отправки подзапросов к витрине (Агент -> Витрина) request-topic-name: query.rq # Топик подзапросов для вызова регламентированного запроса (хранимой процедуры) (Агент -> Витрина) regulated-query-request-topic-name: procedure.query.rq # Топик для передачи чанков табличного параметра (Агент -> Витрина) table-param-topic-name: query.tp # Топик для передачи чанков табличного параметра, нарезанных бинарно (Агент -> Витрина) binary-table-param-topic-name: query.tp.bin result: # Топик получения результатов исполнения SQL подзапросов от витрины (Витрина -> Агент) result-topic-name: query.rs # Топик получения ошибок исполнения SQL подзапросов от витрины (Витрина -> Агент) error-topic-name: query.err # Топик ответов с оценкой (статистикой) по исполнению подзапросов (Витрина -> Агент) query-estimation-topic-name: query.estimation.rs # Настройки модуля обработки SQL запросов отправляемых в ядро ПОДД query: # Обработчик отмены SQL запросов cancel: # Топик нотификаций витрины об отмене SQL запроса (Агент -> Витрина) request-topic-name: cancel.rq # Топик передачи результата об отмене SQL запроса (Витрина -> Агент) result-topic-name: cancel.rs # Топик передачи ошибок отмены SQL запроса (Витрина -> Агент) error-topic-name: cancel.err # Настройки получения BLOB по ссылке load-reference-data: # Топик запроса по BLOB ссылке (Агент -> Витрина) request-topic-name: blob.rq # Ответный топик с данными (чанки) по BLOB ссылке (Витрина -> Агент) result-topic-name: blob.rs # Ответный топик с ошибками обработки запроса по BLOB ссылке (Витрина -> Агент) error-topic-name: blob.err # Настройки модуля сбора Статистики statistic: # Топик с запросами на сбор статистики (Агент -> Витрина) requestTopicName: statistic.rq # Топик с результатами сбора статистики (Витрина -> Агент) responseTopicName: statistic.rs # Конфиг модуля регистрации профиля витрины в ядре datamart-profile: # Топик с запросами профиля у витрины (Агент -> Витрина) datamartRequestTopic: profile.rq # Топик ответов за запросы профиля у витрины (Витрина -> Агент) datamartResponseTopic: profile.rs # Топик с неуспешными ответами на запросы профиля у витрины (Витрина -> Агент) datamartErrorTopic: profile.err cls: datamart-topic: scl.signal 5. Если имена созданных топиков отличаются от имён по умолчанию, указать использование пользовательских топиков на стороне Витрины в конфигурации ПОДД-Адаптера – Модуль исполнения запросов, согласно разделу «7.1.1 Спецификация модуля ПОДД-адаптера – Модуль исполнения запросов» Руководства администратора Типового ПО «Витрина данных». .. _geo_config_set: Настройка подключения к Ядру ПОДД, в том числе для работы в гео-распределенной конфигурации ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ *Предоставляемый шаблон конфигурационного файла имеет настройку по умолчанию для данного параметра. Применять изменения следует только в случае, если значения по умолчанию не подходят для данного Агента ПОДД.* Для настройки Агентов необходимо перечислить все Ядра ПОДД (nodes), к которым подключается Агент ПОДД, с указанием адресов брокеров, ссылки на Pulsar и сервис авторизации Ядра ПОДД. .. attention:: Масштабируемый Агент (:ref:`set_agent`) должен работать только с одним Ядром ПОДД при использовании транспорта Pulsar, при использовании транспорта RSocket данного ограничения нет. Не масштабированный может работать с двумя Ядрами ПОДД через любой из транспортов (Pulsar, RSocket). Пример раздела конфигурации: .. code-block:: yaml # Настройки подключения ко всем ЦОД с установленным ПО ядра data-center: … nodes: - node-id: {{ node1_name }} # Адреса брокеров (транспорт rsocket) broker-addresses: - host: {{ broker1-host }} port: {{ broker1-port }} - host: {{ broker2-host }} port: {{ broker2-host }} # Настройки подключения к Pulsar (транспорт pulsar) pulsar: # есть возможность указания нескольких адресов pulsar, для этого необходимо в переменную "serviceUrl" через запятую прописать все адреса # пример - serviceUrl: pulsar://{{ address1:port }}, pulsar://{{ address2:port }} client: serviceUrl: pulsar://{{ pulsar_kernel1_link }} ... auth: keycloak-oauth: auth-server: # список адресов серверов авторизации. # Может быть указано несколько адресов списком. - url: {{ keycloak_kernel1_link_1 }} - url: {{ keycloak_kernel1_link_2 }} - node-id: {{ node2_name }} broker-addresses: {...} pulsar: {...} client: serviceUrl: pulsar://{{ pulsar_kernel2_link }} {...} keycloak-oauth: auth-server: - url: {{ keycloak_kernel2_link }} {...} В разделе ``data-center.default-node`` описаны параметры, общие для подключения ко всем Ядрам ПОДД. Как правило, их изменение не требуется относительно значений по умолчанию. .. _printable_form_set: Настройка подключения к сервису подписания и верификации сообщений ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Пример раздела конфигурации .. code-block:: yaml notarius: target-host: *** IP АДРЕС СЕРВЕРА NOTARIUS *** target-port: *** ПОРТ NOTARIUS *** Настройка модуля подписания печатных форм ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Для настройки модуля подписания печатных форм необходимо перечислить используемые сертификаты для данного модуля и данные о них. При отсутствии используемых печатных форм необходимо указать пустой массив ([]). Пример раздела конфигурации: .. code-block:: yaml printable-form: # Максимальный размер данных для подписания max-content-length: 268435456 # Настройка каким сертификатом подписать результат какого запроса. # Пары значений "название регламентированного запроса": "алиас сертификата" forms: {{ form1_name }}: {{ key1 }} {{ form2_name }}: {{ key2 }} {...} signature: # не изменять, всегда указывается пустой массив printable-form-keys: [] Настройка использования S3 для передачи блобов (опционально) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .. _blob_auto_download: Настройка автоматического скачивания БЛОБ по ссылке Агентом ПОДД ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ *Раздел применим для Агента Потребителя. Предоставляемый шаблон конфигурационного файла имеет настройку по умолчанию для данного параметра. Применять изменения следует только в случае, если значения по умолчанию не подходят для данного Агента ПОДД.* По умолчанию ссылка на скачивание БЛОБ возвращается ИС Потребителя. При необходимости настроить автоматическую выгрузку Агентом Потребителя БЛОБ по ссылке, полученной в ответе на запрос через REST-интерфейс, следует указать параметр в конфигурационном файле: .. code-block:: yaml # Настройки REST сервера исполнения SQL запросов rest-query-endpoint: # Агент автоматически запрашивает блоб, при получении ссылки(на ЦА не влияет) blobAutoresolve: true .. note:: Настройка может быть задана при использовании передачи данных через Pulsar (раздел pulsar) и не распространяется на передачу данных с использованием транспорта RSocket (раздел ``broker-addresses``). Описание указанных разделов приведено в :ref:`geo_config_set`. Примечание: механизм автоматической выгрузки БЛОБ по ссылке Агентом Потребителя является устаревшим и поддерживается временно, может быть убран без предупреждения в последующих релизах Настройка использования S3 для передачи БЛОБов ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ *Раздел применим только при использовании S3 storage (на стороне Поставщика). В случае если хранилище S3 не используется, данный раздел в конфигурационном файле может отсутствовать.* Для настройки использования S3 для передачи блобов следует указать адрес точки доступа и ссылку на файл с учётными данными для подключения к S3. Bucket с соответствующим именем должен быть предварительно создан на стороне S3. Также в файле ``s3_creds.properties`` необходимо прописать корректные значения логина и пароля для подключения к хранилищу S3 согласно образцу в файле ``/distr/einfahrt/s3_creds.properties``. В случае, если S3 не используется (т.е. параметр blob-source имеет значение "DATAMART"), адрес, bucket и путь могут быть указаны любые, либо отсутствовать. Пример раздела конфигурации: .. code-block:: yaml query: # Настройки получения BLOB по ссылке load-reference-data: # Источник получения данных для BLOB ссылок, # S3 - данные загружаются агентом из хранилища S3, DATAMART - запрос пересылается витрине blob-source: DATAMART # Настройки подключения к хранилищу S3 s3-storage: endpoint: http://{{ s3_url }}/ # Имя бакета bucket-name: {{ bucket name }} # Путь к файлу с данными для авторизации pathToCredentialFile: {{ /absolute/path/to/s3_creds.properties }} Настройки разбиения получаемой информации на чанки (опционально) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ *Предоставляемый шаблон конфигурационного файла имеет настройку по умолчанию для данного параметра. Применять изменения следует только в случае, если значения по умолчанию не подходят для данного Агента ПОДД. * Доступна возможность указать способ разбиения получаемой информации при выполнении Регламентированных SQL-запросов на чанки. Для настройки разбиения получаемой информации на чанки при выполнении запроса через REST-интерфейс необходимо в конфигурационном файле Агента ПОДД задать параметр ``tableParamChunkType``, который может принимать значения: - EXACTLY_CUT – позволяет разбивать информацию на чанки исходя из размера чанка (размер чанка указывается параметром ``tableParamChunkSize``, значение по умолчанию 900 KB); - EVEN_ROWS – запрещает разбиение информации между чанками (автономно десериализуемые чанки), не гарантируется соблюдение размера чанка. Пример раздела конфигурации для настройки выполнения запросов через REST-интерфейс: .. code-block:: yaml # Настройки REST сервера исполнения SQL запросов rest-query-endpoint: ... # Размер чанка пользовательского табличного параметра tableParamChunkSize: 900KB # Способ разбиения пользовательского табличного параметра на чанки tableParamChunkType: EXACTLY_CUT Для настройки разбиения получаемой информации на чанки для JDBC драйвера необходимо добавить в свойства драйвера параметр ``tableParamChunkType``, который может принимать значения: - EXACTLY_CUT – позволяет разбивать информацию на чанки исходя из размера чанка (размер чанка указывается дополнительным свойством в настройках драйвера ``tableParamChunkSize``, например ``tableParamChunkSize =100KB``); - EVEN_ROWS – запрещает разбиение информации между чанками (автономно десериализуемые чанки), не гарантируется соблюдение размера чанка. .. _set_timeout: Настройка организации информационного обмена через API Gateway (опционально) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Настройка информационного обмена через API Gateway для выполнения запросов к REST-сервису ИС Поставщика. Все шаги опциональны! Если требуется настройка, то: - шаги 1-4 выполняются только в рамках организации информационного обмена через API Gateway по HTTPS; при обмене по HTTP не требуются. - шаг 5 только для Агента Поставщика/ответчика; - шаг 6 только для Агента Потребителя/инициатора запроса. 1. Скопировать файл cacerts java в локальный каталог (java должна быть установлена, см. :ref:`pre_requisites`) .. code-block:: bash cp /usr/java/lib/security/cacerts /distr/einfahrt/certs/cacerts 2. Произвести импорт сертификата в java cacerts. Пример раздела конфигурации: .. code-block:: bash keytool -importcert -keystore /distr/einfahrt/certs/cacerts -storepass changeit -alias api-gateway -file cert.crt - ``changeit`` - пароль по умолчанию для cacerts; - ``cert.crt`` – файл с сертификатом используемым на стороне https сервера. 3. В параметры запуска агента добавить ключи ``-Djavax.net.ssl.keyStore=certs/cacerts`` и ``-Djavax.net.ssl.trustStore=certs/cacerts``. При использовании systemd (:ref:`agent_start`) данные параметры добавить в описание ``Environment="JDK_JAVA_OPTIONS=…``. 4. Произвести настройку модуля для работы по HTTPS. Пример раздела конфигурации: .. code-block:: yaml # Настройка модуля API gateway api-gateway: # Параметры HTTP-клиента для отправки запросов на стороне поставщика client: impl: APACHE options: # указать адрес и порт https сервера default-host: *** адрес подключения к серверу *** default-port: *** адрес подключения к серверу *** ssl: true verifyHost: false maxPoolSize: 100 5. При необходимости настройки таймаутов указать опциональные параметры (ниже приведены дефолтные значения, которые используются если параметры не указаны явно): .. code-block:: yaml # Настройка модуля API gateway api-gateway: # Параметры HTTP-клиента для отправки запросов на стороне поставщика client: options: connectTimeout: 10000 #таймаут подключения, мс idleTimeout: 60000 #таймаут бездействия, мс maxPoolSize: 100 #размер пула соединений maxWaitQueueSize: 0 #0 - не ждать, возвращает инициатору ошибку 503(service unavailable) #для impl=VERTX - число ожидающих запросов при исчерпании #пула соединений (-1 - неограниченная очередь), #для impl=APACHE - таймаут ожидания соединения #при исчерпании пула (-1 - неограниченное время #ожидания), мс 6. При необходимости изменения порта, используемого ИС Потребителя при обращении к Агенту ПОДД по Регламентированным REST-запросам требуется указать значения следующих параметров: - при использовании транспорта pulsar (по умолчанию 8171): .. code-block:: yaml # Настройка модуля API gateway api-gateway: # Параметры HTTP-сервера для приёма запросов на стороне потребителя (транспорт pulsar) server: port: 8171 - при использовании транспорта rsocket (по умолчанию 8172). .. attention:: Версия Агента ПОДД должна быть 3.7.0 или выше как у инициатора обмена, так и у ответчика .. code-block:: yaml # Настройка модуля API gateway api-gateway: # Параметры HTTP-сервера для приёма запросов на стороне потребителя (транспорт rsocket) target-arch: server-port: 8172 .. _time_set: Настройка параметров времени активации агента (опционально) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Данные параметры применяются для обеспечения обновления масштабированного Агента с нулевым временем простоя. В примере ниже указаны значения по умолчанию. .. code-block:: yaml agent-activation: # Таймаут ожидания активации экземпляра Агента при получении запроса component-activation-timeout: 1s # Код ошибки HTTP при попытке выполнения SQL запроса на неактивированном экземпляре агента inactive-query-http-error-code: 501 # Код ошибки HTTP при попытке выполнения APIGateway запроса на неактивированном экземпляре агента inactive-api-gw-http-error-code: 501 При последовательном обновлении экземпляров масштабированного Агента до новой мажорной версии, экземпляр Агента с новой версией не будет активирован до момента обновления других экземпляров. Выполнение запроса к не активированному экземпляру Агента приведет к сообщению об ошибке (коды ошибок в соответствии с примером конфигурации выше), в таком случае система - инициатор запроса должна перенаправить запрос на другой экземпляр Агента. .. _set_agent: Настройка подключения к Агентам ПОДД при использовании масштабированного Агента ПОДД, запускаемого более чем в одном экземпляре (опционально) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .. attention:: Масштабирование поддерживается для Агента Инициатора (Потребителя) при использовании любого из транспортов (Pulsar, RSocket). Для Агента Ответчика (Поставщика), т.е. в случае подключённой к Агенту Витрины, масштабирование Агента поддерживается только при использовании транспорта RSocket. ВЫ случае использования транспорта Pulsar Агент должен работать строго в одном экземпляре. 1. Указать URL подключения к агентам. Для масштабированного агента-потребителя(поставщика), пример раздела конфигурации: .. code-block:: yaml # Настройки REST сервера исполнения SQL запросов rest-query-endpoint: # URL подключения к агентам по JDBC (только для implementation = JDBC) jdbc-url: jdbc:podd://:${query-server.port},:${query-server.port},:${query-server.port} где, ```` - адреса всех экземпляров масштабированного агента. Для немасштабированного Агента Потребителя, а также для Агента Поставщика, можно указать значение ``jdbc:podd://localhost:${query-server.port}``. 2. Указать идентификатор экземпляра Агента ПОДД. В случае использования масштабируемого Агента ПОДД, значение параметра должно быть уникальным для каждого экземпляра Агента ПОДД. Пример раздела конфигурации: .. code-block:: yaml # Настройки модуля "информация об агенте" agent-info: # идентификатор экземпляра агента instanceId: ${HOSTNAME:instance-1} .. _ntp_set: Настройка подключения к NTP ~~~~~~~~~~~~~~~~~~~~~~~~~~~ *Предоставляемый шаблон конфигурационного файла имеет настройку по умолчанию для данного параметра. Применять изменения следует только в случае, если значения по умолчанию не подходят для данного Агента ПОДД.* В данном разделе необходимо указать один или более IP адрес или HOSTNAME NTP сервера. .. code-block:: yaml ntp: - host: {{ IP адрес или HOSTNAME NTP }} В случае, если используется поставляемый в комплекте с Агентом ПОДД пакет chrony, в данном параметре конфигурационного файла Агента ПОДД следует указать ip адрес, на котором работает chrony. .. _meta_local_store_set: Настройка сохранения метаданных на локальном диске ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ При запуске, Агент получает от ядра достаточно большой объем метаданных. Имеется возможность включения/отключения данной функциональности. Включение данного параметра снижает сетевой трафик в момент запуска агента, однако дает значительную нагрузку на локальный диск, что может быть неприемлимо при использовании медленного диск. .. code-block:: yaml query: metadata: storeToDb: false значение по умолчанию: false .. _auth_type_set: Настройка типа аутентификации агента в ядре ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ В зависимости от использования либо неиспользования mTLS, должен быть выбран один из возможных способов аутентификации агента в ядре (mTLS, при его использовании, обеспечивается средствами инфраструктуры - см (:ref:`mtls`)) .. code-block:: yaml pulsar: auth: keycloak-oauth: # Способ аутентификации в Keycloak: # - TLS_PUB_KEY - проверка агента на сервере аутентификации выполняется по открытому ключу получаемому # из сертификата используемого агентом при Mutual-TLS # - SIGNED_JWT - аутентификация через проверку подписи переданного агентом JWT, при данном способе # использование Mutual-TLS опционально auth-type: SIGNED_JWT # Протокол подключения # - GOST_TLS - Mutual-TLS по ГОСТ алгоритмам, с использованием ключа CryptoPro # - PLAIN_HTTP - обычный HTTP/HTTPS auth-protocol: PLAIN_HTTP Значения по умолчанию: SIGNED_JWT и PLAIN_HTTP Настройка передачи информации в аудит гостех ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Для передачи информации аудита, используются следующие параметры: .. code-block:: yaml gostech: audit: host: *audit_server_host* port: *audit_server_port*