Установка EDMS#

Получение скриптов развертывания Ansible#

Скачать и разархивировать дистрибутив ./EDMS-scripts-{version}-distrib.zip, содержащий ansible роли и Jenkins скрипты развертывания.

При установке с помощью ansible: поместить содержимое директории Ansible на сервер, с которого будет производиться установка.
При установке через Jenkins: поместить директории Ansible и Pipeline в корень git-репозитория.

Ручная установка с использованием Ansible#

Перед началом установки убедитесь, что выполнена подготовка окружения. Подробнее в разделе Подготовка окружения EDMS.
Скопировать все ansible-скрипты развертывания из состава дистрибутива (./EDMS-scripts-{version}-distrib.zip) на сервер, с которого будет производиться установка.
Заполнить соответствующие inventory. Подробнее про заполнение inventory в разделе Подготовка окружения EDMS, подраздел «Настройка inventory».
Перенести содержимое дистрибутива (./EDMS-app-{version}-distrib.zip) в новую папку files на сервере установки. Если папки нет, то папку необходимо создать.
Скопировать папки с inventory из пункта 3 в папку Ansible, в подпапку inventories.
Запустить установку командой в терминале из папки Ansible:

ansible-playbook -i inventories/<ID>/inventory <PLAYBOOK>.yml --ask-vault-pass

, где ID - имя недавно созданного inventory.

Список возможных PLAYBOOK:
emc.yml - устанавливает emc;
emc_system_service.yml - устанавливает system service по указанному сервису;
emc_user_service.yml - устанавливает user service по указанному сервису;

Установка всех частей EDMS будет производиться на все host из inventory.
Проверить работоспособность сервиса:

убедиться, что сборка завершена без ошибок;
убедиться, что в директории с логами в файле emc.log нет информации об ошибках;
при переходе по ссылке сервер,на который была произведена установка:порт/emc открывается UI приложения и есть возможность авторизоваться.

Автоматическая установка с использованием Jenkins#

Убедитесь, что выполнена подготовка окружения. Подробнее в разделе Подготовка окружения EDMS.
Заполните inventory. Inventory должны быть заполнены согласно инструкции в разделе Подготовка окружения EDMS, подраздел «Настройка inventory».
Убедитесь, что созданы необходимые Jenkins job из состава архива ./EDMS-scripts-{version}-distrib.zip. Jenkins Job должны быть настроены согласно инструкции в разделе Подготовка окружения EDMS, подраздел «Создание Jenkins Job для автоматической установки EDMS».
Заполните параметры созданной Jenkins job (добавлены ссылки на дистрибутив, добавлены inventory, выбор host и тд).
Запустите Jenkins job, дождитесь окончания выполнения работы со статусом «SUCCESS».
Проверьте работоспособность сервиса.

Настройки способов аутентификации#

Возможны разные настройки способов аутентификации в EDMS:

С помощью СУДИР.
С помощью LDAP.
С помощью БД.

С полным описанием настроек vars.yml можно ознакомиться в разделе Подготовка окружения EDMS, подраздел «Пример заполненного файла vars.yml».

Аутентификация с помощью СУДИР#

При использовании СУДИР в качестве системы аутентификации необходимо предварительно выполнить следующие действия:

На стенде размещения EDMS установить сервис управления пользователями GenericAccountManagementImpl, завести логин и пароль для подключения к другим компонентам СУДИР, выпустить mTLS-сертификат для взаимодействия с другими компонентами. Настройки логина и пароля для данного сервиса указываются в конфигурационном файле group_vars/all/vars.yml в блоке:

auth-sudir:
  ...
  user: user  // Логин
  password: password //  Пароль
  ...

На стенде размещения EDMS установить сервис GenericSupportingDataReconciliationImpl, предназначенный для получения списка ролей и матрицы их совместимости СУДИРОМ из EDMS, выпустить mTLS-сертификат для взаимодействия с другими компонентами;
Должен быть предоставлен доступ к сервису СУДИР JWKS по TLS-сертификату, предназначенный для проверки токена пользователя.

Аутентификация с помощью LDAP#

При использовании LDAP необходимо предварительно его установить. При использовании защищенного подключения необходимо предварительно получить TLS-сертификаты для подключения к LDAP.

Аутентификация с помощью БД#

Использование Hashicorp Vault для хранения паролей и выпуска сертификатов#

Hashicorp Vault используется для хранения паролей и выпуска сертификатов.

Настройка интеграции с Vault задается в inventory в блоке emc.vault. Подробнее в разделе Подготовка окружения EDMS, подраздел «Настройка inventory».

Блок настроек vars.yml для интеграции с Hashicorp Vault:

vault: # Блок vault
  enabled: false # Включение блока
  address: _vault_host_:_vault_port_ # Host и port для подключения к vault
  timeout: 15 # Время ожидания для подключения к vault
  ssl: # блок ssl
    keystore_path: ssl/vaultclient.jks # jks для подключения к vault
    keystore_password: _PLACEHOLDER_ # Пароль для jks
    truststore_path: ssl/vaultclient.jks
    truststore_password: _PLACEHOLDER_
    key_password: _PLACEHOLDER_
  auth: #  Блок аутентификация в vault
    type: APPROLE  # Тип аутентификации в vault: APPROLE, CERTIFICATE, TOKEN и PASSWORD
    approle:
      role: _vault_role # role для подключения vault
      secret: _PLACEHOLDER_ # secret для подключения vault
  #   token:  # Настройки аутентификации TOKEN
  #      token: _vault_token #Токен Vault
  #    user_pass: # Настройки аутентификации PASSWORD
  #      username: # Логин пользователя
  #      password: # Пароль пользователя
  namespace: "" # Область хранения секретов
  secret_path: kv1/edms/emc # Путь до хранилища с секретами
  cert_path: pki # Путь до хранилища, где генерируется сертификат
  secret_cron: 0 */5 * * * * # Задача cron с помощью которой происходит периодически опрос секретов Vault. Формат Quartz - * * * * * *, который расшифровывается: (секунда) (минута) (час) (день месяца) (месяц) (день недели)
  cert_cron: 0 */10 * * * *
  encrypt_secrets: true # Нужно ли шифровать секреты в Environment. Если да, то необходимы параметры для шифрования. Для работы нужно прописать дополнительные параметры шифрования: security.encoding.class и security.encoding.key
  keys: # Маппинг секретов на значения в application.yml
    - name: # Название секрета в Vault
      type: MAP # Тип мапинга секрета в стиле словаря. Когда есть параметр в application.yml, а внутри него есть еще несколько параметров. Работает как Map.
      key: # Название параметра который содержит словарь параметров
      mapped-to: # Коллекция значений параметров, которые изменяются значением из Vault, в данном случае название параметра в Map
    - name: # Название секрета в Vault
      type: SIMPLE # Тип маппинга секрета на параметр в Application.yml, например notifications.mail.password
      mapped-to: # Коллекция значений параметров, которые изменяются значением из Vault
  certs:
    - alias: edms # alias сертификата
      truststore-secret-keys: edms1, edms2, edms3 # aliases сертификатов применятся при множестве УЦ
      path: ssl/edms.jks # Путь на сервере, где будет храниться сертификат
      alt-names: # Список альтернативных имен
        - "some.alt.name"
      alt-ips: # Список альтернативных IP-адресов
        - "some.alt.ip"
      csr-path:  # Абсолютный путь до запроса на сертификат (если используется csr, в остальных случаях оставить пустым)
      ttl: 128D # Срок годности выпускаемого сертификата. Возможны градации: D - дни, H - часы, M - минуты, S - секунды
      common-name: "EDMS.AWESOME.CERT" # CN выпускаемого сертификата
      type: JKS # Тип хранилища
      vault-secret: certPass # Пароль от хранилища, хранимый в переменной Vault
      password: test # Пароль от хранилища. Если указан vault-secret, то пароль будет браться из Vault, а не из password.
      renew-less-than: 2D # Разница между текущей датой во время проверки и сроком истечения сертификата. Если она будет меньше чем указано, то сертификат будет считаться недействительным и надо его перевыпустить
      role: edms # Роль из под которой выпускается сертификаты в Vault
      email: edms@edms.com # Почтовый адрес на который будут приходить уведомления о сертификате
      max-wait-time: 2S # Время ожидания начала действия сертификата(сек), если параметр не определен, то по умолчанию будет 2 секунды
      pki-method: issue # ISSUE / FETCH один из двух видов получения сертификатов из Vault - 'issue' (default), 'fetch' (только движок SberCA)
      revocation: true # Включение проверки отзыва сертификата
      prefer-crl: true # Включение проверки попадания сертификата в список отозванных по CRL перед проверкой по OCSP. По-умолчанию проверка проводится с помощью CRL, затем, в случае неудачи, с помощью OCSP
      fallback: true   # Включение резервной проверки, если первая проверка завершилась ошибкой
      soft-fail: true  # При наличии сетевых проблем с проверкой по OCSP и CRL, проверка отзыва не выполняется

security:
  encoding:
    class: # Класс, используемый для расшифровки паролей
    key: # Ключ для расшифровки паролей. Может быть указан непосредственно, либо передан через файл

Настройки аудита#

Для компонента EDMS существует интеграция с подсистемой аудита продукта Platform V Audit SE. Так же совместимо с Platform V Monitor.

Для использования в качестве системы аудита продукта Platform V Audit SE необходимо получить TLS-сертификаты для подключения к системе, а также прописать соответствующие настройки аудита в конфигурационном файле vars.yml. В Блоке audit.

Для использования в качестве системы аудита продукта Platform V Monitor необходимо получить TLS-сертификаты для подключения к системе, а также прописать соответствующие настройки аудита в конфигурационном файле vars.yml. В Блоке audit.

Блок настроек приведен в разделе Подготовка окружения EDMS, подраздел «Пример заполненного файла vars.yml».

Настройки интеграции для подключения внешних систем#

Интеграция с внешними системами настраивается в файле vars.yml. Более подробную информацию и пример настройки можно найти в файле vars.yml: в разделе Подготовка окружения EDMS, подраздел «Пример заполненного файла vars.yml».

Способы установки заявок в EDMS#

Разворачивание дистрибутивов по заявкам может осуществляться двумя способами:

с помощью RLM;
через прямое развертывание дистрибутива (direct_deploy).

Настройка механизма развертывания дистрибутивов осуществляется в файле application.yml:

deploy:
  jenkins-deploy: тип развертывания дистрибутивов jenkins
  direct-deploy: тип развертывания дистрибутивов direct
  rlm-deploy: тип развертывания дистрибутивов rlm

В случае использования механизма RLM в настройках каждого домена пользователю с ролью DomainAdmin указывается ссылка на сервис RLM, отвечающий за установку по заявкам EDMS, в соответствии с данной настройкой.

В случае использования RLM осуществляется авторизация с помощью токена. Предварительно необходимо получить данный токен.

В случае использования прямого развертывания осуществляется авторизация с помощью сертификата. Предварительно необходимо получить данный сертификат.

Данный сертификат используемый для подключения, необходимо указать в vars.yml, в блоке direct_deploy:

Этим сертификатом будет осуществляться подключение к kafka/replicator/flink, поэтому должны быть прописаны необходимые: cn, alt-ip, alt-name

Механизм развертывания дистрибутивов по заявкам#

deploy:
  type: direct
  direct: # Блок настроек прямого деплоя
    timeout: 5000 # Таймаут в миллисекундах для ожидания ответа
    properties: # Блок настроек ssl для подключения к Kafka/replicator/Flink
      "[security.protocol]": SSL # Тип протокола подключения (НЕ МЕНЯТЬ)
      "[ssl.keystore.location]": ssl/direct.jks # Сертификат для direct-deploy, для подключения к Kafka/replicator/Flink
      "[ssl.keystore.password]": __PLACEHOLDER__ # Пароль для сертификата direct-deploy
      "[ssl.truststore.location]": ssl/direct.jks # Сертификат для direct-deploy, для подключения к Kafka/replicator/Flink
      "[ssl.truststore.password]": __PLACEHOLDER__ # Пароль для сертификата direct-deploy
      "[ssl.key.password]": __PLACEHOLDER__ # Пароль для сертификата direct-deploy
  rlm: # Блок настроек rlm
    rlm-url: https://rlm.ru # Адрес rlm
    service-token: __PLACEHOLDER__ # Токен для подключения к rlm
    table-id: kafka # Идентификатор таблицы с Kafka-ресурсами
    consumerGroupDeletion: false # Флаг удаления прав доступа consumerGroup при откате заявки на подписку
    timeout: # Блок параметров проверки джоб rlm по времени
      job-update-cron: 0 */5 * * * * # Задача cron, с помощью которой происходит периодическая проверка состояния RLM-джоб. Формат Quartz - * * * * * *, который расшифровывается: (секунда) (минута) (час) (день месяца) (месяц) (день недели)
      task-update-cron: 0 */2 * * * * # Задача cron, с помощью которой происходит обновление статусов заявок. Формат Quartz - * * * * * *, который расшифровывается: (секунда) (минута) (час) (день месяца) (месяц) (день недели)
    #        ssl: # Блок настроек ssl для подключения при взаимодействии с кафкой через привод rlm. Указываются в зависимости от настроек spring.ssl.bundle.[тип jks/pem].[имя бандла]
    #          bundle: default-bundle # Имя бандла
    #          certificate-alias: cert-alias # Имя сертификата
    jobs: # Список джоб rlm
      create-topic: # Название джобы
        service: createtopicKafka # Параметр service джобы
        action: aktag_create_topic,aktag_modify_topic # Параметр action джобы
      add-acls: # Название джобы
        service: ak_add_acl # Параметр service джобы
        action: aktag_add_acls # Параметр action джобы
      modify-topic: # Название джобы
        service: ak_modify_topic # Параметр service джобы
        action: aktag_modify_topic # Параметр action джобы
      delete-topic: # Название джобы
        service: ak_delete_topic # Параметр service джобы
        action: aktag_delete_topics # Параметр action джобы
      delete-acls: # Название джобы
        service: ak_delete_acl # Параметр service джобы
        action: aktag_delete_acls # параметр action джобы