Установка EDMN#

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

  1. Перед началом установки убедиться, что выполнена подготовка окружения. Подробнее в разделе Подготовка окружения EDMN.

  2. Заполнить соответствующие inventory. Подробнее в разделе Подготовка окружения EDMN, подраздел «Настройка inventory».

  3. Скопировать директорию Ansible со скриптами развертывания из состава дистрибутива ./EDMN-scripts-{version}-distrib.zip на клиент, с которого будет производиться установка.

  4. Создать в корне директории Ansible директорию files.

  5. Распаковать дистрибутив ./EDMN-app-{version}-distrib.zip.

  6. Перейти в директорию package/bh и заархивировать содержимое командой:

cd edmn
zip -r ../monitoring-boot.zip
cd ..
  1. Перенести содержимое package/bh (кроме библиотеки encryptor-cli-{version}-fatjar.jar и папки edmn) в директорию files.

  2. Библиотеку encryptor-cli-{version}-fatjar.jar перенести в корень директории Ansible.

  3. Запустить установку командой из директории Ansible:

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

, где:

  • ID — название созданной директории;

  • playbook — необходимый playbook: - collector.yml — установка коллекторов; - etcd.yml — установка etcd; - influxdb.yml — установка InfluxDB; - monitoring.yml — установка monitoring; - prometheus.yml — установка Prometheus; - synapse_monitoring.yml — установка всех компонентов EDMN (в файле inventory необходимо указать список серверов компонента, который будет устанавливаться; если список серверов пустой — установка компонента производиться не будет); - <сервис>_system_service.yml — установка system service по указанному сервису; - <сервис>_user_service.yml — установка user service по указанному сервису.

  1. Установка всех компонентов EDMN будет производиться на сервера из выбранного inventory.

  2. Проверить работоспособность сервиса. Убедиться, что установка завершена без ошибок.

  3. Проверить доступ до почтового сервиса.

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

  1. Необходимо убедиться, что выполнена подготовка окружения. Подробнее в разделе Подготовка окружения EDMN.

  2. Заполнить inventory. Inventory должны быть заполнены согласно разделу Подготовка окружения EDMN, подраздел «Настройка inventory».

  3. Убедиться, что созданы необходимые Jenkins Job из состава архива ./EDMN-scripts-{version}-distrib.zip. Jenkins Job должны быть настроены согласно инструкции в разделе Подготовка окружения EDMN, подраздел «Создание Jenkins Job для автоматической установки».

  4. Заполнить параметры созданной Jenkins Job для установки (добавлены ссылки на дистрибутив, добавлены inventory, выбор сервера и т.д).

  5. Запустить Jenkins Job, дождаться окончания выполнения работы со статусом SUCCESS.

  6. Проверить работоспособность сервиса.

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

Возможны следующие варианты настройки способов аутентификации в EDMN:

  1. С помощью Platform V IAM SE.

  2. С помощью LDAP.

  3. С помощью файла.

Настройка аутентификации через IAMProxy#

  1. После регистрации приложения в СУДИР NGAM и установки и настройки IAM Proxy пользователь входит в браузере на адрес IAM Proxy, настроенного на работу с EDMN. IAM Proxy предоставляет форму для авторизации, где происходит авторизация по логину и паролю.

  2. IAM Proxy пытается авторизовать пользователя в СУДИР NGAM и, в случае успеха, получает данные (access token, refresh token …) и в формате JWT отдает в EDMN в HTTP-заголовке Authorization, где из JWT можно извлечь информацию о пользователе и идентифицировать его.

  3. Происходит авторизация пользователя согласно ролевой модели.

Настройки задаются в конфигурационном файле vars.yml в блоке oauth:

oauth:
  type: iamproxy # Включенные сервисы аутентификации (названия соответствуют полям в "authentication.oauth.clients")
    requireTokenOnEveryRequest: false  # Для успешной аутентификации необходимо передавать токен на каждый запрос (по умолчанию отключено)
    disableEndpoints: true  # Отключить конечные точки аутентификации для работы с Proxy IAM
    clients:
      iamproxy:
        autoUpdateUserProfile: true # пользователь будет создаваться на основе ID Token
        claims: # Поле в котором хранится логин пользователя (по умолчанию preferred_username)
          username: "sub" # Поле в котором хранится список назначенных пользователю ролей
        security:
          skipAllValidators: false # Отключение проверки токена
        endpoints:
          jwks:
              url: http://hostname/openid-connect/certs # Конечная точка открытых ключей

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

Настройка аутентификации через LDAP#

Аутентификация пользователей через LDAPS осуществляется по логину и паролю с применением политик AD компании.

Настройки LDAPS задаются в файле vars.yml в блоке authentication.:

authentication:
  type: ldap
  userList:
    - login: # testuser
      # - login: username
      # password: *
  groupsList:
    - # Путь к группе пользователей в LDAP
  ssl:
    protocol: TLSv1.3
    keystore: vault:ldap.jks # путь к сертификату
    truststore: vault:ldap.jks # путь к хранилищу сертификатов
  ldap:
    url: # адрес LDAP сервера
    port: 389                           # 389 - порт LDAP (без SSL)

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

Настройки аутентификации через файл#

Настройки аутентификации через файл задаются в конфигурационном файле vars.yml в блоке authentification.type:

authentication: # Блок аутентификации
    type: basic # Поддерживаемые типы: ldap, basic
    userList: # Список пользователей
      - login: <user>
        password: __PLACEHOLDER__ # Обязательное поле при аутентификации типа basic. При его отсутствии сгенерируется пустой пароль

, где:

  • в параметре type необходимо указать значение basic;

  • в параметре userList указать список пользователей для аутентификации.

Пароли указываются в vault.yaml в зашифрованном виде и передаются в виде переменной.

В дальнейшем данные для аутентификации хранятся на файловой системе в зашифрованном файле (логины и пароли).

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

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

Настройка интеграции мониторинга с Hashicorp Vault#

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

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

vault: #Настройки интеграции с Vault
  enabled: #Признак использования интеграции: true - выключена, false - выключена. По умолчанию false
  address: #Host и port для подключения к vault, указывается без https://
  timeout: #Время ожидания ответа от Vault в секундах
  ssl: #Настройки ssl подключения к Vault
    keystore: #Абсолютный путь до файла хранилища ключей на сервере для подключения к Vault
    keystore-password: #Пароль от хранилища ключей для подключения к Vault
    truststore: #Абсолютный путь до хранилища доверенных сертификатов на сервере для подключения к Vault
    truststore-password: #Пароль от хранилища доверенных сертификатов для подключения к Vault
    key-password: #Пароль от ключа в хранилище для подключения к Vault
  auth: #Настройки аутентификации Vault
    type: #Тип аутентификации. Поддерживаются 1 из 4 вариантов: APPROLE, CERTIFICATE, TOKEN или PASSWORD. При аутентификации с помощью CERTIFICATE используется блок настроек vault.ssl
    app-role: #Настройки аутентификации APPROLE
      role: #role_id
      secret: #secret_id
    token: #Настройки аутентификации TOKEN
      token: #Токен Vault
    user_pass: #Настройки аутентификации PASSWORD
      username: #Логин пользователя
      password: #Пароль пользователя
  namespace: # Пространство выдаваемое Vault
  login-path: #Путь до метода авторизации в vault. По-умолчанию не обязательный параметр
  secret-path: #Путь до хранилища секретов в Vault
  cert-path: #Путь до хранилища, где находится роль выпуска сертификатов и выпущенные сертификаты
  secret-cron: #Задача cron с помощью которой происходит периодический опрос секретов Vault. Формат Quartz - * * * * * *, который расшифровывается: (секунда) (минута) (час) (день месяца) (месяц) (день недели)
  cert-cron: #Задача cron с помощью которой происходит проверка сертификатов Vault. Формат Quartz - * * * * * *, который расшифровывается: (секунда) (минута) (час) (день месяца) (месяц) (день недели)
  encrypt-secrets: #Требуется ли шифровать секреты в 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: #Алиас сертификата в хранилище
      path: #Абсолютный путь на сервере, где будет храниться выпущенный сертификат
      csr-path: #Путь до запроса на сертификат
      alt-names: #Список альтернативных hostname в виде строк
      alt-ips: #Список альтернативных IP-адресов в виде строк
      ttl: #Срок годности выпускаемого сертификата. Возможны градации: D - дни, H - часы, M - минуты, S - секунды
      common-name: #CN выпускаемого сертификата
      type: #Тип хранилища, поддерживаемые варианты - JKS или PKCS12
      vault-secret: #Пароль от хранилища, хранимый в переменной Vault
      password: #Пароль от создаваемого хранилища сертификатов, если указан vault-secret, то значение игнорируется
      renew_less_than: #Разница между текущей датой во время проверки и сроком истечения сертификата. Если она будет меньше чем указано, то сертификат будет считаться недействительным и надо его перевыпустить
      role: #Роль из под которой выпускается сертификаты в Vault
      email: #Почтовый адрес на который будут приходить уведомления о сертификате
      max-wait-time: #Время ожидания начала действия сертификата

Настройка интеграции коллекторов с Hashicorp Vault#

Настройка интеграции коллекторов с Vault задается в inventory в блоке collector.vault.

Для создания сертификатов для других компонентов необходимо описать параметры, которые указаны в разделе Подготовка окружения EDMN, подраздел «Настройка inventory».

  # Настройки интеграции с Vault
  vault:
    enabled: false # Включение vault
    vaultUrl: https://vault.url/ # address для подключения к vault (можно опустить `https://`)
    vaultNamespace: '' # Рекомендовано указать наименование АС+КЭ
    vaultRetries: 1 # Количество попыток подключения к vault
    vaultTimeout: 3 # Тайм-аут ожидания подключения к vault
    vaultVersion: 1  # Версия vault
    vaultRetryInterval: 500
    vaultREPLICATORUserPasswordPath: kv1/edmn/collector/replicator/jmx # путь до секрета jmxPassword для replicator
    vaultREPLICATORUserPasswordKey: __PLACEHOLDER__ # имя секрета jmxPassword для replicator
    vaultKAFKAUserPasswordPath: kv1/edmn/collector/kafka/jmx # путь до секрета jmxPassword для kafka
    vaultKAFKAUserPasswordKey: __PLACEHOLDER__ # имя секрета jmxPassword для Kafka
    vaultINFLUXUserPasswordPath: kv1/edmn/collector/influx # путь до секрета jmxPassword для influx
    vaultINFLUXUserPasswordKey: __PLACEHOLDER__ # имя секрета jmxPassword для influx
    vaultFLINKUserPasswordPath: kv1/edmn/collector/flink/jmx # путь до секрета jmxPassword для flink
    vaultFLINKUserPasswordKey: __PLACEHOLDER__ # имя секрета jmxPassword для flink
    vaultARTEMISUserPasswordPath: kv1/edmn/collector/artemis/jmx # путь до секрета jmxPassword для artemis
    vaultARTEMISUserPasswordKey: __PLACEHOLDER__ # имя секрета jmxPassword для artemis
    ssl:     # ssl access to Vault:
      enabled: true # Использовать ssl при подключении к vault
      vaultSslProtocol: TLSv1.2
      vaultSslKeyPassword: __PLACEHOLDER__
      vaultSslKeystoreLocation: ssl/vault.jks
      vaultSslKeystorePassword: __PLACEHOLDER__
      vaultSslTruststoreLocation: ssl/vault.jks
      vaultSslTruststorePassword: __PLACEHOLDER__
      vaultSslEndpointIdentificationAlgorithm: ''
    vaultAuthType: approle # [approle, token, password, certificate] `approle` for default
    vaultAuthRoleId: "role_id"
    vaultAuthRoleSecret: "role_secret"
    vaultAuthRoleMount: ''
    #vaultAuthType: token
    #vaultAuthToken: __placeholder__
    #vaultAuthTokenMount:__placeholder__

    #vaultAuthType: password
    #vaultAuthUsername=test
    #vaultAuthPassword=__placeholder__

    #vaultAuthType: certificate
    #vaultAuthPasswordMount=__placeholder__
    #vaultAuthCertificateMount=__placeholder__

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

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

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

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

Настройки подключения блока аудита описаны в разделе Подготовка окружения EDMN, подраздел «Пример заполненного файла vars.yml».

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

Интеграция с внешними источниками для сбора метрик настраивается через JMX-порт, при этом в блоке collector указывается тип источника (list), например, Kafka, Flink, Replicator, Etcd или Artemis.

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

Функционал описан в документе Руководство пользователя EDMN в разделе: Внешние метрики для Prometheus.