Установка EMIP#

Порядок установки#

Порядок установки компонента EMIP зависит от способа развертывания компонента.

Способы развертывания компонента:

  • ручная установка с использованием Ansible;

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

Для установки компонента EMIP необходимо выполнить установку для каждого микросервиса, входящего в состав компонента EMIP.

Обязательные настройки и функции#

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

  1. Настройка интеграции компонента EMIP с Istio. Подробнее описано в подразделе «Настройка интеграции с Istio».

  2. Подготовка базы данных. Подробнее описано в подразделе «Подготовка базы данных».

  3. Масштабирование количества pods. Подробнее описано в подразделе «Масштабирование количества pods».

  4. Создание сервисных топиков. Подробнее описано в подразделе «Создание служебных топиков».

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

Важно: В первую очередь необходимо установить микросервис istio. Далее для каждого микросервиса (event_discovery, approval-policy, rlm_deploy, saga, schema_registry, catalog, aiem-autentification, frontend, change-requests) требуется предварительно заполнить файл vars.yml и отдельно запустить Jenkins Job «db-init».

Установка компонента EMIP выполняется в следующем порядке установки каждого микросервиса:

  • istio (обязательно устанавливается первым);

  • db-init (запускается для каждого микросервиса, для которого используется база данных: event_discovery, approval-policy, rlm_deploy, saga, schema_registry, catalog, aiem-autentification, frontend, change-requests);

  • event-discovery;

  • approval-policy;

  • rlm-deploy;

  • saga;

  • schema-registry;

  • catalog;

  • autentification;

  • frontend;

  • meta-adapter;

  • tors;

  • change-requests;

  • search.

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

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

  2. Заполнить для каждого микросервиса параметры в файле vars.yml. Примеры заполнения файла vars.yml для каждого сервиса описаны в разделе Подготовка окружения EMIP, подразделы:

  • Пример заполненного файла vars.yml для системы сетевых взаимодействий между микросервисами (istio)

  • Пример заполненного файла vars.yml для микросервиса Event Discovery (event-discovery)

  • Пример заполненного файла vars.yml для микросервиса управления разрешениями (approval-policy)

  • Пример заполненного файла vars.yml для микросервиса деплоя (rlm-deploy)

  • Пример заполненного файла vars.yml для микросервиса сага (saga)

  • Пример заполненного файла vars.yml для микросервиса управления схемами (schema-registry)

  • Пример заполненного файла vars.yml для микросервиса каталогов (catalog)

  • Пример заполненного файла vars.yml для микросервиса аутентификации и авторизации (autentification)

  • Пример заполненного файла vars.yml для микросервиса Web-интерфейса (frontend)

  • Пример заполненного файла vars.yml для микросервиса адаптер СУППД/META (meta-adapter)

  • Пример заполненного файла vars.yml для микросервиса регистрации транспортных объектов (tors)

  • Пример заполненного файла vars.yml для микросервиса управления изменениями (change-requests)

  • Пример заполненного файла vars.yml для микросервиса поиска (search)

  1. Выполнить ручную установку EMIP с использованием Ansible. Подробнее описано в подразделе «Ручная установка с использованием Ansible».

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

Важно: В первую очередь необходимо установить микросервис istio. Далее для каждого микросервиса (event_discovery, approval-policy, rlm_deploy, saga, schema_registry, catalog, aiem-autentification, frontend, change-requests) требуется предварительно заполнить файл vars.yml и отдельно запустить Jenkins Job «db-init».

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

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

  2. Создать задания в Jenkins для автоматической установки EMIP. Подробнее описано в разделе Подготовка окружения EMIP, подраздел «Создание Jenkins Job для автоматической установки».

  3. Выполнить шифрование пароля. Подробнее описано в разделе Использование утилиты «ansible-vault» для шифрования паролей.

  4. Заполнить для каждого микросервиса параметры в файле vars.yml. Примеры заполнения файла vars.yml для каждого сервиса описаны в разделе Подготовка окружения EMIP, подразделы:

  • Пример заполненного файла vars.yml для системы сетевых взаимодействий между микросервисами (istio)

  • Пример заполненного файла vars.yml для микросервиса Event Discovery (event-discovery)

  • Пример заполненного файла vars.yml для микросервиса управления разрешениями (approval-policy)

  • Пример заполненного файла vars.yml для микросервиса деплоя (rlm-deploy)

  • Пример заполненного файла vars.yml для микросервиса сага (saga)

  • Пример заполненного файла vars.yml для микросервиса управления схемами (schema-registry)

  • Пример заполненного файла vars.yml для микросервиса каталогов (catalog)

  • Пример заполненного файла vars.yml для микросервиса аутентификации и авторизации (autentification)

  • Пример заполненного файла vars.yml для микросервиса Web-интерфейса (frontend)

  • Пример заполненного файла vars.yml для микросервиса адаптер СУППД/META (meta-adapter)

  • Пример заполненного файла vars.yml для микросервиса регистрации транспортных объектов (tors)

  • Пример заполненного файла vars.yml для микросервиса управления изменениями (change-requests)

  • Пример заполненного файла vars.yml для микросервиса поиска (search)

  1. Выполнить автоматическую установку EMIP с использованием Jenkins. Подробнее описано в подразделе «Автоматическая установка с использованием Jenkins».

Создание служебных топиков#

Создать служебные топики в транспортной среде событийного домена (кластер EVTD / Platform V Corax / Apache Kafka).

Микросервис «event-discovery»:

Название топика

Чтение/Запись

Описание

aiem-event-discovery-clusters

Запись

События о создании/изменении/удалении кластеров

aiem-event-discovery-channels

Запись

События о создании/изменении/удалении каналов

aiem-event-discovery-segments

Запись

События о создании/изменении/удалении сегментов

Микросервис «approval-policy»:

Название топика

Чтение/Запись

Описание

change-request-resolution

Запись

События с резолюцией по заявке на изменение

change-request-cancelled

Чтение

Событие с отменой процесса согласования заявки пользователем

Микросервис «meta-adapter»:

Название топика

Чтение/Запись

Описание

repl-earepo-control_object_view

Чтение

Событие о создании/изменении системы

repl-earepo-v_kafka_deployment_location

Чтение

Событие о создании/изменении/удалении ТК на ТР

repl-earepo-v_kafka_interaction_point

Чтение

Событие о создании/изменении/удалении точек взаимодействия

repl-earepo-v_kafka_interaction_point_version

Чтение

Событие о создании/изменении/удалении версий точек взаимодействия

system-status

Чтение

Событие по обновлению систем, а именно ссылку на систему из микросервиса каталогов

techservice-status

Чтение

Событие по обновлению статуса ТР

service-catalog-system

Запись

Событие с системами полученными из топика от меты Edas

service-catalog-ts

Запись

Событие с техсервисом для создания в микросервисе каталогов

Микросервис «rlm-deploy»:

Название топика

Чтение/Запись

Описание

aiem-deploy-status

Запись

Событие с результатом выполнения конкретного шага (саги), для случая ошибки - лог с описанием произошедшей ошибки

Микросервис «saga»:

Название топика

Чтение/Запись

Описание

aiem-saga-status

Запись

Событие с ответом о результатах выполнение саг, для случая ошибки - лог с описанием произошедшей ошибки

aiem-deploy-status

Чтение

Событие с результатом выполнения конкретного шага (саги), для случая ошибки - лог с описанием произошедшей ошибки

Микросервис «schema-registry»:

Название топика

Чтение/Запись

Описание

schema

Чтение

Создание схем через топи

system-status

Чтение

Удаление всех схем связанных с системой

Микросервис «catalog»:

Название топика

Чтение/Запись

Описание

service-catalog-system

Чтение

Чтение событий из ЕДАС о системах

service-catalog-event-resource

Чтение

Чтение событий из событийных ресурсов

system-status

Запись

Запись изменения систем

techservice-status

Запись

Запись изменения техсервисов

event-resource-status

Запись

Запись изменения событийных ресурсов

Микросервис «autentification»:

Название топика

Чтение/Запись

Описание

aiem-system-status

Чтение

Событие с системой для создания группы

aiem-techservice-status

Чтение

Событие с техническим микросервисом для создания группы

Микросервис «change-requests»:

Название топика

Чтение/Запись

Описание

aiem-change-request-to-approve

Запись

Событие с заявкой, отправленной на согласование

aiem-change-request-resolution

Чтение

Получение подтверждения заявик от сервиса Approval-Policies

aiem-change-request-cancelled

Запись

Отправка запросов на отзыв заявки с подтверждения

aiem-catalog-event-resources-operations

Запись

Отправка запросов на создание событийных ресурсов

aiem-change-request-create

Чтение

Получение заявок из адаптера внешних систем (МЕТА)

aiem-saga-status

Чтение

Получение ответа от Saga сервиса

Выдать права на чтение и запись для DN сертификата экземпляра продукта к этим топикам. Убедиться, что на топики выданы права describe_configs - в таком случае проверка cleanup.policy будет срабатывать корректно.

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

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

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

  3. В директории Ansible создайте директорию helm.

  4. Распакуйте дистрибутивы каждого микросервиса ./EMIP-<название микросервиса>-{version}-distrib.zip. Убедитесь, что появилась директория conf.

  5. В директорию Ansible/helm скопируйте содержимое директории conf/helm/application/catalog.

  6. Перенесите библиотеку encryptor-cli-(version)-fatjar.jar из директории ./package/bh в корень директории Ansible.

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

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

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

Список возможных PLAYBOOKS:

  • approval-policy.yml — микросервис управления разрешениями (политиками доступа);

  • authentication.yml — микросервис аутентификации и авторизации;

  • catalog.yml — микросервис каталогов;

  • change-requests.yml — микросервис управления изменениями;

  • db.yml — скрипты миграции db;

  • event_discovery.yml — микросервис Event Discovery;

  • frontend.yml — Web-интерфейс;

  • istio.yml — система сетевых взаимодействий между микросервисами;

  • keycloak.yml — микросервис аутентификации и авторизации;

  • meta_adapter.yml — адаптер СУППД/ META;

  • rlm_deploy.yml — микросервис деплоя;

  • saga.yml — сага-микросервис;

  • schema_registry.yml — микросервис управления схемами;

  • search.yml — микросервис поиска;

  • tors.yml — микросервис регистрации транспортных объектов.

  1. Проверьте работоспособность микросервиса:

  • убедиться, что установка завершена без ошибок;

  • убедиться, что в логах pod нет информации об ошибках.

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

1. Запуск установки скриптов миграции с помощью Jenkins#

Запуск установки скриптов миграции выполняется для микросервисов в следующем порядке:

  • event-discovery;

  • approval-policy;

  • rlm-deploy;

  • saga;

  • schema-registry;

  • catalog;

  • autentification;

  • frontend;

  • meta-adapter;

  • tors;

  • change-requests;

  • search.

  1. Запустить задание Jenkins «db-init» (для всех микросервисов кроме: istio, tors) для установки скриптов миграции с помощью пункта меню Собрать с параметрами. Процесс создания задания Jenkins «db-init» приведен в разделе Подготовка окружения EMIP, подраздел «Создание Jenkins Job db-init для установки».

  2. Выбрать необходимый inventory.

  3. Заполнить параметр nexusUrl ссылкой на конфигурационный дистрибутив со скриптами миграции EMIP: EMIP-<название компонента>-dbinit-<Версия компонента>.zip.

  4. Заполнить параметр db_action значением update.

  5. Заполнить параметр ansible_branch.

  6. Заполнить параметр nexus_user_cred.

  7. Заполнить параметр vault_cred.

  8. Нажать кнопку Собрать.

  9. Дождаться окончания выполнения задания Jenkins со статусом SUCCESS.

2. Запуск установки с помощью Jenkins#

  1. Предварительно заполнить inventory для всех микросервисов.

  2. Запустить задание Jenkins «deploy» поочередно для каждого миктросервиса.

  3. Выбрать соответствующий playbook:

  • approval-policy.yml — микросервис управления разрешениями (политиками доступа);

  • authentication.yml — микросервис аутентификации и авторизации;

  • catalog.yml — микросервис каталогов;

  • change-requests.yml — микросервис управления изменениями;

  • db.yml — скрипты миграции db;

  • event_discovery.yml — микросервис Event Discovery;

  • frontend.yml — Web-интерфейс;

  • istio.yml — система сетевых взаимодействий между микросервисами;

  • keycloak.yml — микросервис аутентификации и авторизации;

  • meta_adapter.yml — адаптер СУППД/ META;

  • rlm_deploy.yml — микросервис деплоя;

  • saga.yml — сага-микросервис;

  • schema_registry.yml — микросервис управления схемами;

  • search.yml — микросервис поиска;

  • tors.yml — микросервис регистрации транспортных объектов.

  1. Указать в параметре nexusHelmUrl ссылку на EMIP-cfg-<Версия компонента>-distrib.zip.

  2. Заполнить параметр ansible_branch.

  3. Заполнить параметр nexus_user_cred.

  4. Заполнить параметр vault_cred.

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

  6. Проверка работы:

  • Jenkins job завершилась успешно.

  • Зайти в логи пода, и убедиться, что нет ошибок.

Установка с использованием Jenkins Job «SynapseInstaller»#

Для установки компонента EMIP можно воспользоваться универсальным Jenkins Job «SynapseInstaller». Об инициировании создания Jenkins Job «SynapseInstaller» подробнее описано в разделе Подготовка окружения EMIP, подраздел «Создание универсального Jenkins Job «SynapseInstaller»».

  1. Перед установкой компонента EMIP с помощью Jenkins Job «SynapseInstaller» необходимо создать файл values.yaml.

Все параметры для установки компонента EMIP с помощью Jenkins Job «SynapseInstaller» хранятся в конфигурационном репозитории в файле values.yaml, размещенном по пути: <имя_namespace>/package/conf/helm/<Название микросервиса>/values.yaml.

  1. Особенности заполнения файла values.yaml:

Не используется Ansible-синтаксис {% raw %}:

Пример для Ansible:

vault.hashicorp.com/agent-inject-template-key.pem: |
{%- raw %}
{{- with secret "PKI/issue/role_name" "common_name=emip.sbt" "format=pem" "ttl=20h" "private_key_format=pkcs8" -}}
{{ .Data.private_key }}
{{- end }}
{%- endraw %}

Соответствующий пример файла values.yaml:

vault.hashicorp.com/agent-inject-template-key.pem: |
{{- with secret "PKI/issue/role_name" "common_name=emip.sbt" "format=pem" "ttl=20h" "private_key_format=pkcs8" -}}
{{ .Data.private_key }}
{{- end }}
  1. Далее для установки компонента EMIP необходимо:

  • запустить Jenkins Job «SynapseInstaller» с помощью пункта меню Собрать с параметрами. Об особенностях работы с Jenkins Job «SynapseInstaller» и заполяемых параметрах запуска для установки подробно описано в документации компонента «DevOps инструменты Service Mesh» (SMDL) продукта Platform V Synapse Service Mesh (SSM) в документе «Руководство оператора» раздел «SynapseInstaller»;

  • нажать кнопку Собрать и дождаться окончания выполнения задания Jenkins Job.

Установка Keycloak#

Настройка credentials для Ansible-Vault#

Выполнить настройку credentials для Ansible-Vault. Подробнее о настройке описано в разделе Подготовка окружения EMIP, подраздел «Настройка credentials для Ansible-Vault».

Создание Jenkins Job «Keycloak_install» для установки Keycloak#

Создать Jenkins Job «Keycloak_install» для установки Keycloak. Подробнее о создании Jenkins Job «Keycloak_install» описано в разделе Подготовка окружения EMIP, подраздел «Создание Jenkins Job «Keycloak_install» для установки Keycloak».

Настройка inventory для установки Keycloak#

Перед установкой необходимо заполнить inventory. Базовый пример находится в дистрибутиве со скриптами развертывания по пути: Ansible/inventories/keycloak-EXAMPLE/group_vars/all/vars.yml.

Пример файла vars.yml:

container: # Блок настроек контейнера
  image: "keycloak/keycloak:latest" # Название образа
  config_path: "/opt/keycloak" # Путь до конфигурационного файла аутентификации, для скачивания образа
  registries: # Список репозиториев для скачивания образов
    - registry: "myregistry1.example.com" # Название репозитория
      auth: __PLACEHOLDER__ # base64 закодированные учетные данные пользователя для доступа к репозиторию
    - registry: "myregistry2.example.com" # Название репозитория
      auth: __PLACEHOLDER__ # base64 закодированные учетные данные пользователя для доступа к репозиторию
keycloak: # Блок настроек приложения
  installdir: /opt/keycloak # Путь до директории с конфигурационными файлами
  datadir: /opt/keycloak_data # Путь до примонтированной директории
  admin_user: "admin" # Администратор keycloak
  admin_password: __PLACEHOLDER__ # Пароль администратора keycloak
  hostname: hostname # ИАдрес, по которому открыт доступ к серверу
  realm: # Блок создания realm
    create: true # Создание realm
    realm_name: "emip" # Название realm
  ssl: # Настройки сертификата
    keystore_path: ssl/keycloak.jks # Путь до файла с сертификатом JKS
    keystore_password: __PLACEHOLDER__ # Пароль к сертификату JKS
    truststore_path: ssl/keycloak.jks # Путь до файла с сертификатом JKS
    truststore_password: __PLACEHOLDER__ # Пароль к сертификату JKS

Для установки Keycloak необходимо указать контейнерный образ и адрес registry, из которого будет происходить загрузка.

Также требуется определить директории: каталог установки, каталог для данных и путь к файлу конфигурации, который создается при скачивании образа.

Необходимо задать имя и пароль первичного администратора. При желании можно сразу создать один или несколько realm во время начальной конфигурации.

В поле hostname указывается IP-адрес или FQDN сервера, на котором будет развернут Keycloak.

Для SSL доступны два варианта: использование сертификатов в формате JKS или сертификатов и ключей в формате PEM.

Более расширенный пример файла vars.yml размещается в дистрибутиве со скриптами развертывания по пути: Ansible/roles/keycloak/defaults/main.yml.

Выполнение установки Keycloak#

  1. Запустите задание Jenkins «Keycloak_install».

  2. Укажите параметры:

  • inventories_repo — репозиторий с inventory. Данный пункт применим, если inventory были созданы в другом репозитории, отличном от того, где расположены скрипты;

  • inventories_branch — ветка репозитория. Данный пункт применим, если inventory были созданы в другом репозитории, отличном от того, где расположены скрипты;

  • inventories_path — путь до inventories от корня репозитория;

  • nexus_user_cred — Jenkins username with password credential ID для выкачивания дистрибутива из Nexus;

  • vault_cred - параметр для расшифровки Ansible-vault;

  • ansible_branch — ветка скриптов развертывания;

  • jenkins_slave — выбор Jenkins Slave;

  • job_config_renew — обновление параметров.

  1. Запустите установку (в процессе подтянутся созданные inventory и скрипты развертывания).

  2. Далее необходимо выбрать параметры:

  • inventory — имя inventory для установки;

  • tags — теги выполнения сценария, выбрать: install, restart;

  • playbook — убедиться, что выбран keycloak.yml;

  • only_on_host — параметр для установки Keycloak на конкретные сервера, указанные в инвентори.

  1. Запустите установку и дождаться окончания выполнения задания Jenkins со статусом SUCCESS.

  2. Проверьте работу:

  • Jenkins job завершилась успешно.

  • Зайти в логи пода, и убедиться, что нет ошибок.

  • В случае ошибок необходмо проанализировать логи Jenkins Job, а также логи контейнера на сервере.

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

Настройка интеграции СУДИР/ Platform V IAM SE (компонент AUTH (IAM Proxy))#

Ниже описана процедура интеграции EMIP с внешними системами: СУДИР/ Platform V IAM SE (компонент AUTH (IAM Proxy)).

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

Для сервисов, где требуется аутентификация, необходимо указать точку обнаружения OpenID Connect поставщика аутентификации. Это может быть СУДИР, KeyCloack OpenSource и другая система поддерживающая протокол OpenID Connect.

Данная настройка необходима, чтобы проверять сигнатуру (подпись) токенов, запросы с которыми идут в приложении.

Настройки интеграции для сервисов (кроме сервиса авторизации)#

Настройка интеграции производится в файле vars.yml.

Описание настроек:

# Возможно указание как одной точки, так и несколько. Указываются через запятую.
# Список конечных точек обнаружения OpenID Connect
# spring.security.oauth2.resourceserver.jwt.issuer-uri: http://0.0.0.0:0/auth/realms/aiem
spring.security.oauth2.resourceserver.jwt.issuer-uri: http://0.0.0.0:0/auth/realms/aiem, http://localhost:8080/realms/aiem

# Список допустимых значений поля aud (аудитории) в JWT-токене. Токен будет отклонен, если его aud не совпадает с указанным.
# spring.security.oauth2.resourceserver.jwt.audiences: aiem-audience

# Значение claim (утверждение) из JWT-токена, используемое как principal (основной идентификатор пользователя).
# Если для аутентификации используется сервис авторизации, то значение claim используется для вывода в логи, а основной
# идентификатор пользователя будет получен от сервиса авторизации
spring.security.oauth2.resourceserver.jwt.principal-claim-name: preferred_username

# Также задается адрес сервиса авторизации (кроме сервиса авторизации)
# Конечная точка сервиса авторизации
application.security.oauth2.resourceserver.authorizer.hosts: http://localhost:7001

# Включить логирование содержимого JWT-токена
application.security.oauth2.resourceserver.authorizer.jwt.logging: true

# Значение claim (утверждение) из JWT-токена, используемое для получения идентификатора учетной записи пользователя
application.security.oauth2.resourceserver.authorizer.jwt.claim.user-id: "sub"

# Значение claim (утверждение) из JWT-токена, используемое для получения табельного номера сотрудника
application.security.oauth2.resourceserver.authorizer.jwt.claim.employee-id: "employee_id"

# Значение claim (утверждение) из JWT-токена, используемое для получения ролей или прав (authorities) пользователя
application.security.oauth2.resourceserver.authorizer.jwt.claim.authorities: "roles"

# Значение claim (утверждение) из JWT-токена, используемое для получения групп пользователя
application.security.oauth2.resourceserver.authorizer.jwt.claim.groups: "groups"

Пример настроек интеграции в файле vars.yml:

app:
  application:
    security:
      oauth2:
        resourceserver:
          authorizer:
            hosts: keycloack_url/auth/realms/emip # URL до keycloack

  spring:
    security:
      oauth2:
        resourceserver:
          jwt:
            issuer-uri: keycloack_url/auth/realms/emip # URL для автоматического получения публичных ключей валидации JWT
            principal-claim-name: preferred_username # Имя поля в JWT, из которого брать имя пользователя (principal)

Настройки интеграции для сервиса авторизации#

Описание настроек:

# Адреса брокеров Kafka, к которым будет выполняться подключение
spring.kafka.consumer.bootstrap-servers: { IP_ADDRESS }

# Идентификатор для всех групп потребителей Kafka
spring.kafka.consumer.group-id: auth-service

# Включить управление группами сервиса авторизации через Kafka (по умолчанию true)
application.module.kafka.management.group.enabled: true

# Топик Kafka для получения событий о системах (используется для создания групп пользователей и администраторов систем). По умолчанию используется топик "system-status"
application.module.kafka.consumer.system.topics: system-status

# Топик Kafka для получения событий о тех. сервисах (используется для создания групп администраторов тех. сервисов). По умолчанию используется топик "techservice-status"
application.module.kafka.consumer.techservice.topics: techservice-status

Пример настроек интеграции в файле vars.yml:

app: # Блок настройки приложения
  spring: # Блок настройки Spring
    kafka: # Блок настройки Kafka
      consumer: # Блок настройки потребителя Kafka
        bootstrap-servers: kafka:9092 # URL Kafka брокера
        group-id: auth-service # Идентификатор группы
    
    application:
      module: # Блок настройки модулей приложения
        kafka: # Блок настройки Kafka
          management: # Блок настройки управления Kafka
            group:
              enabled: true # Включить управление группами сервиса авторизации через Kafka (по умолчанию true)          
          consumer: # Блок настройки потребителя Kafka
            system: # Блок настройки системного потребителя Kafka
              topics: system-status # Топик для получения статуса системы
            techservice: # Блок настройки технического сервиса
              topics: techservice-status # Топик для получения статуса технического сервиса

Описание настроек:

# Конечная точка SCIM-адаптера для предоставления конфигурации
application.module.scim.endpoint.path.config: /ServiceProviderConfig

# Конечная точка SCIM-адаптера для предоставления групп пользователей
application.module.scim.endpoint.path.fos-nodes: /SberFosNodes

# Конечная точка SCIM-адаптера для предоставления ролей пользователей
application.module.scim.endpoint.path.roles: /SberRoles

# Конечная точка SCIM-адаптера для предоставления списка пользователей
application.module.scim.endpoint.path.users: /Users

Пример настроек интеграции в файле vars.yml:

app: # Блок настройки приложения
  application:
    module: # Блок настройки модулей приложения
      scim: # Блок настройки SCIM адаптера
        endpoint: # Блок настройки конечных точек SCIM-адаптера
          path: # Блок настройки путей конечных точек
            config: /ServiceProviderConfig  # Конечная точка SCIM-адаптера для предоставления конфигурации
            fos-nodes: /SberFosNodes # Конечная точка SCIM-адаптера для предоставления групп пользователей
            roles: /SberRoles # Конечная точка SCIM-адаптера для предоставления ролей пользователей
            users: /Users  # Конечная точка SCIM-адаптера для предоставления списка пользователей

Настройка интеграции HashiCorp Vault через vault-agent (sidecar)#

Для настройки интеграции с системой хранения ключей и сертификатов (HashiCorp Vault) через vault-agent необходимо заранее задать соответствующие аннотации в конфигурационном файле vars.yml перед установкой EMIP.

Пример настроек:

annotations: # Аннотации для деплоймента
    vault.hashicorp.com/agent-run-as-same-user: "true" # Запуск Vault Agent с тем же пользователем, что и приложение
    vault.hashicorp.com/agent-init-first: 'true' # Инициализация Vault Agent до запуска основного контейнера
    vault.hashicorp.com/agent-set-security-context: 'true' # Установка security context для Vault Agent
    vault.hashicorp.com/agent-pre-populate: 'false' # Отключение предварительной загрузки секретов перед запуском контейнера
    vault.hashicorp.com/agent-inject-secret-ca.pem: 'true' # Внедрение секрета ca.pem через Vault Agent
    vault.hashicorp.com/secret-volume-path-ca.pem: /vault # Путь к директории, где будет размещен секрет ca.pem
    vault.hashicorp.com/namespace: Vault_Namespace # Название namespace в Vault
    vault.hashicorp.com/role: vault_role # Название роли в Vault, используемой для получения секретов
    vault.hashicorp.com/agent-run-as-group: '10001' # Указывает, что агент должен запускаться от имени группы с идентификатором 10001.
    vault.hashicorp.com/agent-run-as-same-user: 'false' # Указывает, что агент не должен запускаться от имени того же пользователя, от которого запущен контейнер.
    vault.hashicorp.com/agent-run-as-user: '10001' # Указывает, что агент должен запускаться от имени пользователя с идентификатором 10001.
    vault.hashicorp.com/secret-volume-path-key.pem: /vault # Путь к директории, где будет размещен секрет key.pem
    vault.hashicorp.com/agent-inject: 'true' # Включение функции внедрения секретов Vault Agent
    vault.hashicorp.com/agent-inject-secret-key.pem: 'true' # Внедрение секрета key.pem через Vault Agent
    vault.hashicorp.com/agent-limits-cpu: 100m # Ограничение CPU для Vault Agent (в millicores)
    vault.hashicorp.com/agent-requests-cpu: 100m # Запрос CPU для Vault Agent (в millicores)
    vault.hashicorp.com/secret-volume-path-crt.pem: /vault # Путь к директории, где будет размещен секрет crt.pem
    vault.hashicorp.com/agent-inject-secret-crt.pem: 'true' # Внедрение секрета crt.pem через Vault Agent
 Шаблон для генерации содержимого файла key.pem из секрета Vault
    vault.hashicorp.com/agent-inject-template-key.pem: |
      {%- raw %}
      {{- with secret "PKI/issue/vault_role"
      "common_name=emip.solution" "format=pem" "ttl=20h"
      "private_key_format=pkcs8" -}}
      {{ .Data.private_key }}
      {{- end }}
      {%- endraw %}
 Шаблон для генерации содержимого файла ca.pem из секрета Vault
    vault.hashicorp.com/agent-inject-template-ca.pem: |
      {%- raw %}
      {{- with secret "PKI/issue/vault_role"
      "common_name=emip.solution" "format=pem" "ttl=20h"
      "private_key_format=pkcs8" -}}
      {{- range $idx, $cert := .Data.ca_chain }}
      {{ $cert }}
      {{- end }}
      {{- end }}
      {%- endraw %}
 Шаблон для генерации содержимого файла crt.pem из секрета Vault
    vault.hashicorp.com/agent-inject-template-crt.pem: |
      {%- raw %}
      {{- with secret "PKI/issue/vault_role"
      "common_name=emip.solution" "format=pem" "ttl=20h"
      "private_key_format=pkcs8" -}}
      {{ .Data.private_key }}
      {{ .Data.certificate }}
      {{- end }}
      {%- endraw %}
   vault.hashicorp.com/secret-volume-path-password.properties: /vault # Указывает путь в контейнере, куда будет смонтирован файл `password.properties` со значением секрета.
   vault.hashicorp.com/agent-inject-secret-password.properties: "путь до секретов/emip" # Указывает путь к секрету в HashiCorp Vault, который будет использоваться для генерации файла `password.properties`.
   vault.hashicorp.com/agent-inject-template-password.properties: |  # Шаблон, который определяет содержимое файла `password.properties`. Извлекает значение `db_password` из секрета Vault и записывает его в виде: `db_password = <значение>`
     {%- raw %}
     {{- with secret "путь до секретов/emip" -}}
     db_password = {{ .Data.db_password }}
     {{- end }}
     {%- endraw %}
  waitVault: true # Ожидагние запуска sidecar vault

Полный список всех возможных параметров аннотации приведен по ссылке Agent annotations.

Важно: Сущности volume-path (например, secret-volume-path-key, secret-volume-path-crt) должны быть отличными от тех, что указаны в StatefulSet или Deployment.

Также обязательно необходимо в файле vars.yml задать параметр secman-injector: enabled:

#labels: # Блок лейблов, которые добавляются к поду
#  secman-injector: enabled # Лейбл для активации интеграции с SecMan Vault Agent Injector (внедрение секретов из Vault)

Настройка logs-agent (sidecar)#

logsAgent позволяет отправлять логи микросервисов в Kafka или loki.

Для этого необходимо добавить в файл vars.yml из файла с расширенными параметрами: Ansible/roles/<микросервис>/defaults/main.yml.

Необходимо добавить в блок cloud данный блок:

logsAgent: # Блок настроек агента логов
enabled: false # Включить агента логов
fullImagePath: "gatm/gatm_logs_agent" # путь в репозитории до образа
debug: false # Включить дебаг
interval: "2s" # Интервал сбора метрик. Возможные значения: "1s", "1m", "1h"
flushInterval: "2s" # Интервал отправки данных во внешний сервис. Возможные значения: "1s", "1m", "1h"
resources: # Ресурсы пода
  limits: # Ограничения ресурсов пода
    cpu: 200m  # CPU
    memory: 200Mi # Объем памяти
  requests: # Запросы ресурсов пода
    cpu: 200m # CPU
    memory: 200Mi # Объем памяти
output: # Блок настроек сервисов для выгрузки
    kafka: # Блок настроек kafka
        - topic: "topic" # Топик для выгрузки
          brokers: "kafka:9092" # Брокеры для выгрузки
          routingTag: "message" # Тег для маршрутизации данных
          startupErrorBehavior: "retry" # Поведение при ошибке запуска
    loki: # Блок настроек loki
        - LokiAddress: "loki:3100" # Адрес loki
          metricNameLabel: "authentication" # Метка метрик

Можно указать любое количество эндпоинтов, и включить как одновременно отправку логов в Kafka и логи, так и отдельно.

Настройки интеграции с МЕТА#

Настройка интеграции компонента EMIP с МЕТА производится в файле vars.yml микросервиса «Адаптер СУППД/ META» (meta-adapter):

app: # Блок настройки приложения
  kafka: # Настройка подключения к Kafka
    read: # Настройка чтения из Kafka
      consumers: # Настройка консьюмеров
        edas:
          name: edas # имя должно быть идентично названию консьюмера т.е в данном случае consumer-edas
          bootstrap-servers: _PLACEHOLDER_
          topic: edas-topic # имя топика
          group-id: edasGroup # consumer group
        tc-on-tr:
          name: tc-on-tr # имя должно быть идентично названию консьюмера т.е в данном случае consumer-tc-on-tr
          bootstrap-servers: _PLACEHOLDER_
          topic: tctr-topic  # имя топика
          group-id: tctr-group # consumer group
        interaction-point:
          name: interaction-point # имя должно быть идентично названию консьюмера т.е в данном случае consumer-interaction-point
          bootstrap-servers: _PLACEHOLDER_
          topic: ip-topic  # имя топика
          group-id: earepo_ipGroup # consumer group
        version-interaction-point:
          name: version-interaction-point # имя должно быть идентично названию консьюмера т.е в данном случае consumer-version-interaction-point
          bootstrap-servers: _PLACEHOLDER_
          topic: repl-earepo-v_kafka_interaction_point_version  # имя топика#
          group-id: earepo_interaction_point_versionGroup

Настройки интеграции с СУППД#

Настройка интеграции компонента EMIP с СУППД производится в файле vars.yml микросервиса «Адаптер СУППД/ META» (meta-adapter):

app: # Блок настройки приложения
  kafka: # Настройка подключения к Kafka
    read: # Настройка чтения из Kafka
      consumers: # Настройка консьюмеров
        ppd:
          name: ppd #имя должно быть идентично названию консьюмера т.е в данном случае consumer-ppd
          bootstrap-servers: _PLACEHOLDER_
          topic: ppd-topic  # имя топика
          group-id: ppd-group # consumer group
  emip: # Настройка EMIP
    ppd-adapter:
      endpoint: _PLACEHOLDER_/ppd/%s # Адрес адаптера ppd
    process-ppd:
      get-api:
        rest:
          url: _PLACEHOLDER_ # Адрес API для получения данных
      get-version-api:
        rest:
          url: _PLACEHOLDER_ # Адрес API для получения данных

Настройки интеграции с IGEG (Граничный прокси)#

Настройка интеграции компонента EMIP с IGEG (Граничный прокси) производится в файле vars.yml микросервиса системы сетевых взаимодействий между микросервисами («istio»):

#helm_cli: helm # путь до утилиты helm (генерируется автоматически из Jenkins)
#kubectl_cli: helm # путь до утилиты kubectl (генерируется автоматически из Jenkins)
#kubeconfig_path: {{ inventory_dir }}/.kubeconfig # путь до файла kubeconfig (может быть зашифрован через ansible-vault)
#api_url: https://api.example.ru:6443 # URL API k8s/openshift (не требуется при наличии kubeconfig_path)
#token: __PLACEHOLDER__ # токен пользователя (сервис аккаунта) для установки (не требуется при наличии kubeconfig_path)
#skip_tls_verify: false # игнорировать проверку доверия для URL API (не требуется при наличии kubeconfig_path)
namespace: my-namespace # наименование проекта в k8s/openshift

cloud:
  release_name: istio # наименование релиза в helm, от него будут вычисляться производные имена манифестов
  registry_proxyimage: example.registry.addr # адрес репозитория с образом proxy (POLM)
  registry_path_proxyimage: example_repo/example_path # путь в репозитории до образа proxy (POLM)

istio: # настройки манифестов Istio
  openshiftInstall: false # установка в openshift (true) или в k8s (false)
  pullImage: example-secret # наименование секрета для доступа в реджистри (скачивание образа)
  api_gateway:
    gateway:
      create: true
      # name: my_api_gw
      # selector: # выбор поды гейтвея, дефолтно - ингресс
      #   app: ingressgateway
      #   istio: ingressgateway
    virtual_service:
      create: true
      # name: my_api_vs
    # host: api-gateway.internal
    service_entry:
      create: true
      # gateway_service: ingressgateway-svc # выбор сервиса гейтвея, дефолтно ингресс
    routes: # обязательно, если create: true
      # prefix: app-svc
    trim_prefix: true # обрезать ли prefix из routes: /my/prefix/ -> /
  ingress:
    filter: # rbac envoy filter
      create: false
      # name: my_filter
      # selector: # выбор поды гейтвея, дефолтно - ингресс
      #   app: ingressgateway
      #   istio: ingressgateway
      policies:
        allow: []
          # - name: do_not_allow_private_paths_to_anyone
          #   permissions:
          #     - and_rules:
          #         rules:
          #           - not_rule:
          #               header:
          #                 name: ':path'
          #                 prefix_match: /private
          #   principals:
          #     - any: true
          # - name: allow_regex_dn_to_specific_path
          #   permissions:
          #     - or_rules:
          #         rules:
          #           - header:
          #               name: ':path'
          #               prefix_match: /specific
          #   principals:
          #     - or_ids:
          #         ids:
          #           - header:
          #               name: x-forwarded-client-cert
          #               safe_regex_match:
          #                 google_re2:
          #                   max_program_size: 4000
          #                 regex: .*CN=emip_client.my.domain.*
          # - name: allow_from_ingress_authority_to_specific_principal
          #   permissions:
          #     - or_rules:
          #         rules:
          #           - header:
          #               name: ':authority'
          #               safe_regex_match:
          #                 google_re2:
          #                   max_program_size: 4000
          #                 regex: .*ingress.apps.my.kubernetes.domain
          #   principals:
          #     - authenticated:
          #         principal_name:
          #           exact: CN=emip_client.my.domain,O=MY.ORG
        deny: []
    mode: dns # 'dns' (creating dns names my_service.my.domain.com) or 'path' (creating my.domain.com/my_service)
    tls: # обязательно
      ca: /vault/ingress/ca.pem # поменять в соответствии аннотациями vault-agent
      server: /vault/ingress/crt.pem # поменять в соответствии аннотациями vault-agent
      key: /vault/ingress/key.pem # поменять в соответствии аннотациями vault-agent
    endpoints:
      app_services: []
        # - my-app-svc
      annotations: {}
        # kubernetes.io/ingress.class: nginx
        # nginx.ingress.kubernetes.io/enable-cors: "true"
        # nginx.ingress.kubernetes.io/ssl-passthrough: "true"
        # # ingress.kubernetes.io/rewrite-target: '/' # не включает endpoint в запрос (/server/endpoint -> /endpoint)
      hostname: 'my_cluster' # суффикс ингресса (в случае ingress.mode: path - весь хостнейм) - зависит от кластера (пример: apps.dap.devpub-01.solution.sbt)
    gateway: # создание Gateway манифеста
      # name: ingressgateway
      create: true
      # selector: # выбор поды гейтвея, на которую применить Gateway манифест
      #   app: ingressgateway
      #   istio: ingressgateway
    service: # создание сервиса для Gateway, на который будет роутиться трафик с ингресса
      create: true
      # name: ingressgateway-svc
      # selector: # выбор поды гейтвея, на которую применить Service манифест
      #   app: ingressgateway
      #   istio: ingressgateway
    virtualService: # создание Virtual Service для маршрутизации трафика между гейтвеем и сервисом поды приклада
      create: true
      # name: ingress-vs
    destinationRule:
      create: true
      # name: ingress-dr
      # selector: # выбор поды гейтвея, на которую применить DR манифест
      #   app: ingressgateway
      #   istio: ingressgateway
      # outlierDetection:
      #   consecutive5xxErrors: 5
      #   interval: 5m
      #   baseEjectionTime: 5m
      #   maxEjectionPercent: 50
    deployment: # для создания граничного прокси (гейтвей как пода, а не kind: Gateway)
      create: true
      # name: ingressgateway
      resources:
        limits:
          cpu: 0.1
          memory: 128M
        requests:
          cpu: 0.1
          memory: 128M
      hpa: {} # Настройки horizontal pod autoscaler
        # create: false
        # minReplicas: 1 # Минимальное кол-во под
        # maxReplicas: 10 # Максимальное кол-во под
        # cpuUtilPercent: 70 # Процент утилизации cpu, при котором начинается скалирование
        # memUtilPercent: 70 # Процент утилизации memory, при котором начинается скалирование
        # # behavior:
        # #   scaleUp:
        # #     stabilizationWindowSeconds: 30 # Окно, в которое hpa наблюдает за кол-вом под и нагрузкой
        # #     selectPolicy: Min # Выбор политики, вносящей минимальные изменения
        # #     policies:
        # #       - type: Percent
        # #         value: 100 # Удвоить кол-во реплик за periodSeconds
        # #         periodSeconds: 15
        # #       - type: Pods
        # #         value: 5 # Максимум добавить 5 реплик в periodSeconds
        # #         periodSeconds: 15
        # #   scaleDown:
        # #     stabilizationWindowSeconds: 300 # Окно, в которое hpa наблюдает за кол-вом под и нагрузкой
        # #     selectPolicy: Min # Выбор политики, вносящей минимальные изменения
        # #     policies:
        # #       - type: Percent
        # #         value: 50 # Допустимо снизить на 50% кол-во реплик за periodSeconds
        # #         periodSeconds: 60
      readinessProbe: {}
      #   initialDelaySeconds: 1
      #   timeoutSeconds: 1
      #   periodSeconds: 2
      #   successThreshold: 1
      #   failureThreshold: 30
      annotations: {}
        # vault.hashicorp.com/agent-inject-secret-ca.pem: 'true'
        # vault.hashicorp.com/secret-volume-path-ca.pem: /vault/ingress
        # vault.hashicorp.com/namespace: NAMESPACE
        # vault.hashicorp.com/role: ROLE
        # vault.hashicorp.com/secret-volume-path-key.pem: /vault/ingress
        # vault.hashicorp.com/agent-inject: 'true'
        # vault.hashicorp.com/agent-inject-secret-key.pem: 'true'
        # vault.hashicorp.com/agent-init-first: 'true'
        # vault.hashicorp.com/agent-limits-cpu: 100m
        # vault.hashicorp.com/agent-requests-cpu: 100m
        # vault.hashicorp.com/secret-volume-path-crt.pem: /vault/ingress
        # vault.hashicorp.com/agent-inject-secret-crt.pem: 'true'
        # vault.hashicorp.com/agent-inject-template-key.pem: |
        #   {%- raw %}
        #   {{- with secret "PKI/issue/ROLE"
        #   "common_name=emip.eda.solution.sbt" "format=pem" "ttl=20h"
        #   "private_key_format=pkcs8" -}}
        #   {{ .Data.private_key }}
        #   {{- end }}
        #   {%- endraw %}
        # vault.hashicorp.com/agent-inject-template-ca.pem: |
        #   {%- raw %}
        #   {{- with secret "PKI/issue/ROLE"
        #   "common_name=emip.eda.solution.sbt" "format=pem" "ttl=20h"
        #   "private_key_format=pkcs8" -}}
        #   {{- range $idx, $cert := .Data.ca_chain }}
        #   {{ $cert }}
        #   {{- end }}
        #   {{- end }}
        #   {%- endraw %}
        # vault.hashicorp.com/agent-inject-template-crt.pem: |
        #   {%- raw %}
        #   {{- with secret "PKI/issue/ROLE"
        #   "common_name=emip.eda.solution.sbt" "format=pem" "ttl=20h"
        #   "private_key_format=pkcs8" -}}
        #   {{ .Data.certificate }}
        #   {{- end }}
        #   {%- endraw %}
      labels: {}
        # secman-injector: enabled # Лейбл для активации интеграции с secman vault agent injector
      istioDiscoveryService: istiod-sbt-syn-cp-01
      istioControlPlane: sbt-syn-cp-01
  peerAuthentication: # ограничение на допуск mtls в между подами
    create: true
#    name: peer-auth-0
    mtls_mode: STRICT # UNSET | DISABLE | PERMISSIVE | STRICT (default)
  egress: # для создания граничного прокси (гейтвей как пода, а не kind: Gateway)
    deployment: # для создания граничного прокси (гейтвей как пода, а не kind: Gateway)
      create: true
      # name: egressgateway
      resources:
        limits:
          cpu: 0.1
          memory: 128M
        requests:
          cpu: 0.1
          memory: 128M
      hpa: {} # Настройки horizontal pod autoscaler
        # create: false
        # minReplicas: 1 # Минимальное кол-во под
        # maxReplicas: 10 # Максимальное кол-во под
        # cpuUtilPercent: 70 # Процент утилизации cpu, при котором начинается скалирование
        # memUtilPercent: 70 # Процент утилизации memory, при котором начинается скалирование
        # # behavior:
        # #   scaleUp:
        # #     stabilizationWindowSeconds: 30 # Окно, в которое hpa наблюдает за кол-вом под и нагрузкой
        # #     selectPolicy: Min # Выбор политики, вносящей минимальные изменения
        # #     policies:
        # #       - type: Percent
        # #         value: 100 # Удвоить кол-во реплик за periodSeconds
        # #         periodSeconds: 15
        # #       - type: Pods
        # #         value: 5 # Максимум добавить 5 реплик в periodSeconds
        # #         periodSeconds: 15
        # #   scaleDown:
        # #     stabilizationWindowSeconds: 300 # Окно, в которое hpa наблюдает за кол-вом под и нагрузкой
        # #     selectPolicy: Min # Выбор политики, вносящей минимальные изменения
        # #     policies:
        # #       - type: Percent
        # #         value: 50 # Допустимо снизить на 50% кол-во реплик за periodSeconds
        # #         periodSeconds: 60
      readinessProbe: {}
      #   initialDelaySeconds: 1
      #   timeoutSeconds: 1
      #   periodSeconds: 2
      #   successThreshold: 1
      #   failureThreshold: 30
      annotations: {}
        # vault.hashicorp.com/agent-inject-template-secret1.secret: |
        #   {%- raw %}
        #   {{- with secret "PATH/TO/MY/SECRET" -}}
        #   {{ index .Data "KEY1" }}
        #   {{- end }}
        #   {%- endraw %}
        # vault.hashicorp.com/agent-inject-secret-secret2.secret: 'true'
        # vault.hashicorp.com/secret-volume-path-secret2.secret: /vault
        # vault.hashicorp.com/namespace: NAMESPACE
        # vault.hashicorp.com/role: ROLE
        # vault.hashicorp.com/agent-inject-secret-secret1.secret: 'true'
        # vault.hashicorp.com/secret-volume-path-secret3.secret: /vault
        # vault.hashicorp.com/agent-inject: 'true'
        # vault.hashicorp.com/secret-volume-path-secret1.secret: /vault
        # vault.hashicorp.com/agent-inject-secret-secret3.secret: 'true'
        # vault.hashicorp.com/agent-init-first: 'true'
        # vault.hashicorp.com/agent-limits-cpu: 200m
        # vault.hashicorp.com/agent-requests-cpu: 200m
        # vault.hashicorp.com/agent-inject-template-secret3.secret: |
        #   {%- raw %}
        #   {{- with secret "PATH/TO/MY/SECRET" -}}
        #   {{ index .Data "KEY2" }}
        #   {{- end }}
        #   {%- endraw %}
        # vault.hashicorp.com/agent-inject-template-secret2.secret: |
        #   {%- raw %}
        #   {{- with secret "PATH/TO/MY/SECRET" -}}
        #   {{ index .Data "KEY3" }}
        #   {{- end }}
        #   {%- endraw %}
      labels: {}
        # secman-injector: enabled # Лейбл для активации интеграции с secman vault agent injector
      istioDiscoveryService: istiod-sbt-syn-cp-01
      istioControlPlane: sbt-syn-cp-01
    service: # параметры сервиса Egress
#      name: "egressgateway0-svc" # имя сервиса Egress
      create: true # создавать ли манифест сервиса
      internalPort: 15021 # внутренний порт Egress
      internalPortName: status-port # имя внутреннего порта Egress
      internalPortProtocol: TCP # протокол внутреннего порта Egress
#      selector: # содержимое поля spec.selector в манифесте сервиса
#        app: egressgateway
#        istio: egressgateway
    gateway: # параметры манифеста Gateway для Istio Egress
#      name: egressgateway0-gw # имя манифеста
      create: true # создавать ли манифест
#      selector: # содержимое поля spec.selector в манифесте
#        app: egressgateway
#        istio: egressgateway
    destinationRule:
#     name: egressgateway0-dr
      create: true
#      outlierDetection:
#        consecutive5xxErrors: 5
#        interval: 5m
#        baseEjectionTime: 5m
#        maxEjectionPercent: 50
# # При создании istio манифестов для проксирования трафика kafka из прикладного приложения к bootstrap серверу нужно обращаться на хост следующего формата:
# # {название_сервиса_egressgateway}.{имя_неймспейса}.svc.cluster.local:{gwPort_для_Kafka_указываемый_ниже}
    kafka: [] # параметры для направления kafka трафика через istio egressgateway. Можно указать список bootstrap серверов Kafka
#    - hosts: bootstrap.server1.host:9093,bootstrap.server2.host:9093 # хостнейм и порт bootstrap серверов Kafka. Если кластер, можно указать несколько. Разделитель ","
#      gwPort: 10092 # порт сервиса egressgateway по которому будет доступна кафка изнутри неймспейса
#      gwTls:
#        mode: ISTIO_MUTUAL # Валидные значения: "PASSTHROUGH", "SIMPLE", "MUTUAL", "AUTO_PASSTHROUGH", "ISTIO_MUTUAL", "OPTIONAL_MUTUAL"
#      destinationRule: # параметры для манифеста DestinationRule Istio для Kafka
#        create: true # создавать ли манифест
#        gatewaySelector: egressgateway
#        outlierDetection:
#          consecutive5xxErrors: 5
#          interval: 5m
#          baseEjectionTime: 5m
#          maxEjectionPercent: 50
#        tls:
#          mode: MUTUAL
#          clientCertificate: /path/to/egress/certificates/ca-chain.cert.pem
#          privateKey: /path/to/egress/certificates/tls.crt
#          caCertificates: /path/to/egress/certificates/tls.key
#      virtualService: # параметры для манифеста VirtualService для Kafka
#        create: true # создавать ли манифест
#      serviceEntry: # параметры для манифеста serviceEntry для Kafka
#        create: true # создавать ли манифест
    external_services: [] # настройки манифестов Istio для работы с внешними сервисами (vault, audit, postgres, loki и др.)
      # - name: my_external_service_name
      #   host: "my.external.hostname" # хост сервиса external_services; указывать валидный SAN из сертификата
      #   port: 4321 # порт сервиса external_services для обращения из pod'а
      #   externalPort: 4321 # порт сервиса external_services
      #   # Порты и протоколы ниже используются в манифестах VirtualService, Gateway, Gateway Service
      #   # Поддерживаемые gwSvc протоколы - "SCTP", "TCP", "UDP"
      #   gwPort: 44321 # порт на egressGateway
      #   gwProtocol: TCP # протокол на egressGateway
      #   gwSvcProtocol: TCP # протокол на service egressGateway
      #   gwTls:
      #     mode: ISTIO_MUTUAL # Валидные значения: "PASSTHROUGH", "SIMPLE", "MUTUAL", "AUTO_PASSTHROUGH", "ISTIO_MUTUAL", "OPTIONAL_MUTUAL"
      #   destinationRule:
      #     create: true # создавать ли манифест
      #     tls:
      #       mode: MUTUAL # DISABLE | SIMPLE | MUTUAL (own certs) | ISTIO_MUTUAL (control plane certs)
      #       caCertificates: /vault/ca.pem
      #       clientCertificate: /vault/crt.pem
      #       privateKey: /vault/key.pem
      #     # outlierDetection:
      #     #   consecutive5xxErrors: 5
      #     #   interval: 5m
      #     #   baseEjectionTime: 5m
      #     #   maxEjectionPercent: 50
      #   virtualService: # параметры для манифеста VirtualService
      #     create: true # создавать ли манифест VirtualService
      #     protocol: tcp # tcp, tls, http
# # Массив serviceEntry, которые нужно создать
#  serviceEntry:
#    - host: my_hostname
#      ports:
#        - name: tcp-port
#          number: 9092
#          protocol: TCP
#      annotations: # расскомментировать если нужно чтобы serviceEntry осталась после helm uninstall
#        "helm.sh/resource-policy": keep

Настройки интеграции с SVPX (Сервисный прокси)#

Настройка интеграции компонента EMIP с SVPX (Сервисный прокси) производится в файле vars.yml для каждого микросервиса:

cloud:
  annotations: # Аннотации для деплоймента
    sidecar.istio.io/inject: "true" # Включение istio-сайдкара в контейнер

Настройка интеграции с Istio#

Для работы микросервисов EMIP с Istio необходимо указание параметров в конфигурационном файле vars.yml.

В аннотации развертывания (поле annotations файла vars.yml) необходимо добавить:

sidecar.istio.io/inject: 'true'

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

Конфигурация входящего трафика в кластер#

Для конфигурации входящего трафика в кластер необходимо:

  1. Заполнить блок ingress:

ingress:
    ....
  1. В блоке endpoints.app_services необходимо указать список микросервисов, которые будут доступны через ingress, например:

  ingress:
    endpoints:
      app_services:
        - event-discovery-svc
        - schema-dev-svc

Примечание: это позволит из браузера заходить на UI микросервисов, указанных в списке. Сама ссылка формируется по принципу:

https://app.release_name-<Название микросервиса в endpoint>-ingress.<istio.ingress.endpoint.hostname>
  1. В параметре endpoints.hostname необходимо указать суффикс ингресса.

  2. Следующие блоки отвечают за создание сущностей для istio-ingress:

    gateway: # Создание gateway-ingress
        ......
    service: # Создание микросервиса, к которому будет направлен входящий трафик от Ingress/Gateway.
        ......
    virtualService: # Создает Istio Virtual Service для маршрутизации между gateway и приложением.
        ......
    deployment: # Создает граничный прокси как отдельный под
        ......

Примечание: Все блоки обязательны, их необходимо заполнить по аналогии с файлом vars.yml.

Конфигурация исходящего трафика из кластера#

Для конфигурации входящего трафика в кластер необходимо:

  1. Заполнить блок egress:

egress:
    ....
  1. Следующие блоки отвечают за создание сущностей для istio-egress:

deployment: # Создает egress gateway (граничный прокси для исходящего трафика).
    ......
service: # создание микросервиса, через который приложения будут направлять исходящий трафик к Egress Gateway для доступа к внешним сервисам
    ......
gateway: # параметры манифеста Gateway для Istio Egress
    ......
destinationRule: # создание правил маршрутизации для исходящего трафика
    ......

Примечание: Все блоки обязательны, их необходимо заполнить по аналогии с файлом vars.yml.

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

В конфигурации заложена возможность проксировать как к Kafka, так и к сервисам.

Проксирование к Kafka#

Для проксирования траффика к Kafka необходимо заполнить блок kafka по примеру заполнения файла vars.yml.

Подготовка базы данных#

Предусловия#

  1. Предварительно необходимо создать inventory и заполнить параметры в конфигурационном файле vars.yml для db-init. Ознакомиться с примером можно в разделе Подготовка окружения EMIP, подраздел «Пример заполненного файла vars.yml для микросервиса «db-init».

  2. При ручной настройке базы данных необходимо:

  • разархивировать архив ./EMIP-<название микросервиса>dbinit-[version]-distrib.zip в папку files;

Ручной способ с помощью Ansible#

Запустите настройку базы данных командой в терминале из папки Ansible:

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

где:

  • ID — имя недавно созданного inventory;

  • PLAYBOOK — playbook для настройки базы дынных: db.yml.

При помощи Jenkins#

Для настройки базы данных с помощью Jenkins используйте задание Jenkins db-init с выбором playbook db.yml без указания тегов. Процесс создания задания Jenkins db-init приведен в разделе Подготовка окружения EMIP, подраздел «Создание Jenkins Job для автоматической установки» (подраздел «Создание Jenkins Job db-init для установки»).

Использование задания Jenkins db-init описано подробнее в подразделе «Автоматическая установка с использованием Jenkins» (подраздел «1. Запуск установки скриптов миграции с помощью Jenkins»).

Масштабирование количества pods#

При необходимости масштабирования количества pods следует:

  • изменить параметр replicas в конфигурационном файле inventories/<наименование инвентори>/group_vars/all/vars.yml:

cloud:
  replicas: 2 # количество pods в EMIP (2 по умолчанию)