Установка EMIP#
Порядок установки#
Порядок установки компонента EMIP зависит от способа развертывания компонента.
Способы развертывания компонента:
ручная установка с использованием Ansible;
автоматическая установка с использованием Jenkins.
Для установки компонента EMIP необходимо выполнить установку для каждого микросервиса, входящего в состав компонента EMIP.
Обязательные настройки и функции#
При установке (ручной/автоматической) могут быть использованы следующие обязательные настройки и функции:
Настройка интеграции компонента EMIP с Istio. Подробнее описано в подразделе «Настройка интеграции с Istio».
Подготовка базы данных. Подробнее описано в подразделе «Подготовка базы данных».
Масштабирование количества pods. Подробнее описано в подразделе «Масштабирование количества pods».
Создание сервисных топиков. Подробнее описано в подразделе «Создание служебных топиков».
Ручная установка с использованием 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 необходимо выполнить следующие действия:
Заполнить файлы в директории
inventories. Подробнее описано в разделе Подготовка окружения EMIP, подраздел «Настройка inventory».Заполнить для каждого микросервиса параметры в файле 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)
Выполнить ручную установку 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 необходимо выполнить следующие действия:
Заполнить файлы в директории
inventories. Подробнее описано в разделе Подготовка окружения EMIP, подраздел «Настройка inventory».Создать задания в Jenkins для автоматической установки EMIP. Подробнее описано в разделе Подготовка окружения EMIP, подраздел «Создание Jenkins Job для автоматической установки».
Выполнить шифрование пароля. Подробнее описано в разделе Использование утилиты «ansible-vault» для шифрования паролей.
Заполнить для каждого микросервиса параметры в файле 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)
Выполнить автоматическую установку 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#
Перед началом установки необходимо убедиться, что выполнена подготовка окружения. Подробнее описано в разделе Подготовка окружения EMIP.
Заполните соответствующие inventory. Подробнее описано в разделе Подготовка окружения EMIP, подраздел «Настройка inventory».
В директории Ansible создайте директорию
helm.Распакуйте дистрибутивы каждого микросервиса ./EMIP-<название микросервиса>-{version}-distrib.zip. Убедитесь, что появилась директория
conf.В директорию
Ansible/helmскопируйте содержимое директорииconf/helm/application/catalog.Перенесите библиотеку
encryptor-cli-(version)-fatjar.jarиз директории./package/bhв корень директорииAnsible.Запустите установку командой в терминале из папки
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— микросервис регистрации транспортных объектов.
Проверьте работоспособность микросервиса:
убедиться, что установка завершена без ошибок;
убедиться, что в логах pod нет информации об ошибках.
Автоматическая установка с использованием Jenkins#
1. Запуск установки скриптов миграции с помощью Jenkins#
Запуск установки скриптов миграции выполняется для микросервисов в следующем порядке:
event-discovery;approval-policy;rlm-deploy;saga;schema-registry;catalog;autentification;frontend;meta-adapter;tors;change-requests;search.
Запустить задание Jenkins «db-init» (для всех микросервисов кроме:
istio,tors) для установки скриптов миграции с помощью пункта меню Собрать с параметрами. Процесс создания задания Jenkins «db-init» приведен в разделе Подготовка окружения EMIP, подраздел «Создание Jenkins Job db-init для установки».Выбрать необходимый
inventory.Заполнить параметр
nexusUrlссылкой на конфигурационный дистрибутив со скриптами миграции EMIP:EMIP-<название компонента>-dbinit-<Версия компонента>.zip.Заполнить параметр
db_actionзначениемupdate.Заполнить параметр
ansible_branch.Заполнить параметр
nexus_user_cred.Заполнить параметр
vault_cred.Нажать кнопку Собрать.
Дождаться окончания выполнения задания Jenkins со статусом
SUCCESS.
2. Запуск установки с помощью Jenkins#
Предварительно заполнить inventory для всех микросервисов.
Запустить задание Jenkins «deploy» поочередно для каждого миктросервиса.
Выбрать соответствующий 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— микросервис регистрации транспортных объектов.
Указать в параметре
nexusHelmUrlссылку наEMIP-cfg-<Версия компонента>-distrib.zip.Заполнить параметр
ansible_branch.Заполнить параметр
nexus_user_cred.Заполнить параметр
vault_cred.Запустить установку и дождаться окончания выполнения задания Jenkins со статусом
SUCCESS.Проверка работы:
Jenkins job завершилась успешно.
Зайти в логи пода, и убедиться, что нет ошибок.
Установка с использованием Jenkins Job «SynapseInstaller»#
Для установки компонента EMIP можно воспользоваться универсальным Jenkins Job «SynapseInstaller». Об инициировании создания Jenkins Job «SynapseInstaller» подробнее описано в разделе Подготовка окружения EMIP, подраздел «Создание универсального Jenkins Job «SynapseInstaller»».
Перед установкой компонента EMIP с помощью Jenkins Job «SynapseInstaller» необходимо создать файл values.yaml.
Все параметры для установки компонента EMIP с помощью Jenkins Job «SynapseInstaller» хранятся в конфигурационном репозитории в файле values.yaml, размещенном по пути: <имя_namespace>/package/conf/helm/<Название микросервиса>/values.yaml.
Особенности заполнения файла 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 }}
Далее для установки компонента 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#
Запустите задание Jenkins «Keycloak_install».
Укажите параметры:
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— обновление параметров.
Запустите установку (в процессе подтянутся созданные inventory и скрипты развертывания).
Далее необходимо выбрать параметры:
inventory— имя inventory для установки;tags— теги выполнения сценария, выбрать:install,restart;playbook— убедиться, что выбранkeycloak.yml;only_on_host— параметр для установки Keycloak на конкретные сервера, указанные в инвентори.
Запустите установку и дождаться окончания выполнения задания Jenkins со статусом
SUCCESS.Проверьте работу:
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»».
Конфигурация входящего трафика в кластер#
Для конфигурации входящего трафика в кластер необходимо:
Заполнить блок
ingress:
ingress:
....
В блоке
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>
В параметре
endpoints.hostnameнеобходимо указать суффикс ингресса.Следующие блоки отвечают за создание сущностей для
istio-ingress:
gateway: # Создание gateway-ingress
......
service: # Создание микросервиса, к которому будет направлен входящий трафик от Ingress/Gateway.
......
virtualService: # Создает Istio Virtual Service для маршрутизации между gateway и приложением.
......
deployment: # Создает граничный прокси как отдельный под
......
Примечание: Все блоки обязательны, их необходимо заполнить по аналогии с файлом vars.yml.
Конфигурация исходящего трафика из кластера#
Для конфигурации входящего трафика в кластер необходимо:
Заполнить блок
egress:
egress:
....
Следующие блоки отвечают за создание сущностей для
istio-egress:
deployment: # Создает egress gateway (граничный прокси для исходящего трафика).
......
service: # создание микросервиса, через который приложения будут направлять исходящий трафик к Egress Gateway для доступа к внешним сервисам
......
gateway: # параметры манифеста Gateway для Istio Egress
......
destinationRule: # создание правил маршрутизации для исходящего трафика
......
Примечание: Все блоки обязательны, их необходимо заполнить по аналогии с файлом vars.yml.
Подключение проксирования трафика к внешним интеграциям#
В конфигурации заложена возможность проксировать как к Kafka, так и к сервисам.
Проксирование к Kafka#
Для проксирования траффика к Kafka необходимо заполнить блок kafka по примеру заполнения файла vars.yml.
Подготовка базы данных#
Предусловия#
Предварительно необходимо создать inventory и заполнить параметры в конфигурационном файле vars.yml для
db-init. Ознакомиться с примером можно в разделе Подготовка окружения EMIP, подраздел «Пример заполненного файла vars.yml для микросервиса «db-init».При ручной настройке базы данных необходимо:
разархивировать архив
./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 по умолчанию)
перезапустить установку EMIP одним из методов, указанных в разделе Выбор способа установки.