Установка EVTA#
Порядок установки EVTA#
Порядок установки компонента EVTA зависит от способа развертывания компонента.
Способы развертывания компонента:
ручная установка с использованием Ansible;
автоматическая установка с использованием Jenkins.
Ручная установка с использованием Ansible#
Для выполнения ручной установки с использованием Ansible необходимо выполнить следующие действия:
Заполнить файлы в директории
inventories. Подробнее описано в разделе Подготовка окружения EVTA, подраздел «Настройка inventory для EVTA».Создать:
нового пользователя;
системные или пользовательские сервисы обслуживания.
Подробнее описано в разделе Подготовка окружения EVTA, подраздел «Создание системных и пользовательских сервисов обслуживания для EVTA».
Выполнить шифрование пароля. Подробнее описано в разделе Использование утилиты «ansible-vault» для шифрования паролей.
Задать настройки подключения к IBM MQ. Подробнее описано в разделе Подготовка окружения EVTA, подраздел «Настройки подключения EVTA к IBM MQ».
Задать настройки пресетов для подключения к внешним сервисам. Подробнее описано в разделе Подготовка окружения EVTA, подраздел «Примеры пресетов для подключения к внешним сервисам для EVTA».
Заполнить файл vars.yml. Подробнее описано в разделе Подготовка окружения EVTA, подраздел «Пример заполненного файла vars.yml для EVTA».
Выполнить ручную установку EVTA с использованием Ansible. Подробнее описано в подразделе «Ручная установка EVTA с использованием Ansible».
Автоматическая установка с использованием Jenkins#
Для выполнения автоматической установки с использованием Jenkins необходимо выполнить следующие действия:
Заполнить файлы в директории
inventories. Подробнее описано в разделе Подготовка окружения EVTA, подраздел «Настройка inventory для EVTA».Создать:
нового пользователя;
системные и пользовательские сервисы обслуживания.
Подробнее описано в разделе Подготовка окружения EVTA, подраздел «Создание системных и пользовательских сервисов обслуживания для EVTA».
Создать задания в Jenkins для автоматической установки EVTA. Подробнее описано в разделе Подготовка окружения EVTA, подраздел «Создание Jenkins Job для автоматической установки EVTA».
Выполнить шифрование пароля. Подробнее описано в разделе Использование утилиты «ansible-vault» для шифрования паролей.
Задать настройки подключения к IBM MQ. Подробнее описано в разделе Подготовка окружения EVTA, подраздел «Настройки подключения EVTA к IBM MQ».
Задать настройки пресетов для подключения к внешним сервисам. Подробнее описано в разделе Подготовка окружения EVTA, подраздел «Примеры пресетов для подключения к внешним сервисам для EVTA».
Заполнить файл vars.yml. Подробнее описано в разделе Подготовка окружения EVTA, подраздел «Пример заполненного файла vars.yml для EVTA».
Выполнить автоматическую установку EVTA с использованием Jenkins. Подробнее описано в подразделе «Автоматическая установка EVTA с использованием Jenkins».
Дополнительные настройки и функции#
Дополнительно при установке (ручной/автоматической) могут быть использованы следующие настройки и функции:
Запуск установки под другим пользователем. Подробнее описано в подразделе «Запуск установки EVTA под другим пользователем».
Настройка интеграции с сервисными системами. Подробнее описано в подразделе «Настройка интеграции EVTA с сервисными системами».
Настройка интеграции с Istio. Подробнее описано в подразделе «Настройка интеграции EVTA с Istio».
Масштабирование количества pods. Подробнее описано в подразделе «Масштабирование количества pods».
Задание константных значений конфигурационным параметрам#
При установке компонентов есть возможность задать константные значения конфигурационным параметрам. В таком случае, данные значения будут считаться приоритетными и их нельзя будет переопределить через inventories.
Для задания константных значений необходимо:
создать файл preferred_ansible_vars.yml в директории
Pipeline, которая размещается в скриптах установки;указать в файле preferred_ansible_vars.yml* необходимые параметры с константными значениями. Параметры необходимо указывать в том же формате, как и в файле vars.yml в
inventories.
Структура заполненного файла vars.yml приведена в разделе Подготовка окружения EVTA, подраздел «Пример заполненного файла vars.yml для EVTA».
Логика приоритетов:
При наличии файла preferred_ansible_vars.yml в директории
Pipelineзначения, указанные в нем, применяются как самые приоритетные и не могут быть изменены черезinventories;При наличии файла preferred_ansible_vars.yml в директории
Pipelineи попытке изменить значения параметров в файле vars.yml новые заданные параметры не применятся — остается приоритет у данных из файла preferred_ansible_vars.yml;При отсутствии файла preferred_ansible_vars.yml все параметры применяются из файла vars.yml.
Функциональность приоритетных параметров можно использовать при работе с jenkins job reactive_stream_adapter_vm (установка на ВМ) и reactive_stream_adapter (установка в облачной среде).
Ручная установка EVTA с использованием Ansible#
Установка на ВМ#
Перед началом установки убедитесь, что выполнена Подготовка окружения EVTA.
Заполните соответствующие inventory. Подробнее в разделе Подготовка окружения EVTA, подраздел «Настройка inventory для EVTA».
Распакуйте дистрибутив ./EVTA-bin-[version]-distrib.zip и поместите содержимое директории
package/bhв папкуfilesскриптов ansible на сервере установки с помощью команды:
mv package/bh files
Поместите утилиту для шифрования паролей encryptor-cli-[version].jar из
filesв корень директории скриптов ansible.Запустите установку EVTA из папки
Ansibleскриптов развертывания командой:
ansible-playbook -i inventories/<ID>/inventory <playbook> --ask-vault-pass
, где:
ID— имя недавно созданного inventory;playbook– необходимый сценарий установки, где:reactive_stream_adapter_vm.yml — запуск EVTA на ВМ;
reactive_stream_adapter_vm_system_service.yml — создание системных сервисов EVTA;
reactive_stream_adapter_vm_user_service.yml — создание пользовательских сервисов EVTA;
reactive_stream_adapter_vm_system_service_delete.yml - удаление системного сервиса обслуживания EVTA на виртуальной машине;
reactive_stream_adapter_vm_user_service_delete.yml - удаление пользовательского сервиса обслуживания EVTA на виртуальной машине.
reencrypt_password.yml — перешифрование паролей.
Убедитесь, что установка завершена без ошибок согласно разделу Чек-лист проверки корректности работы EVTA.
Проверка работоспособности основной функциональности EVTA осуществляется запросами POST и GET на сервер, где устанавливается EVTA. Подробнее в документе «Руководство пользователя EVTA», раздел «Использование приложения».
Установка в облачной среде#
Перед началом установки убедитесь, что выполнена Подготовка окружения EVTA.
Заполните соответствующие inventory. Подробнее в разделе Подготовка окружения EVTA, подраздел «Настройка inventory для EVTA».
В директории Ansible создайте директорию
helm.Распакуйте дистрибутив ./EVTA-cfg-[version]-distrib.zip. Убедитесь, что появилась директория
conf.В директорию
Ansible/helmскопируйте содержимое директорииconf/helm/application/reactivestreamadapter.Перенесите библиотеку encryptor-cli-[version].jar из директории
./package/bhв корень директории Ansible.Запустите установку командой в терминале из папки
Ansible:
ansible-playbook -i inventories/<ID>/inventory <playbook> --ask-vault-pass
, где:
ID— имя недавно созданного inventory;playbook— необходимый playbook:reactive_stream_adapter.yml — устанавливает EVTA в облачной среде.
Проверьте работоспособность сервиса:
убедиться, что установка завершена без ошибок;
убедиться, что в логах pod веб-интерфейса облачной среды нет информации об ошибках.
Автоматическая установка EVTA с использованием Jenkins#
Перед началом установки убедитесь, что выполнена Подготовка окружения EVTA.
Заполните inventory согласно инструкции в разделе Подготовка окружения EVTA, подраздел «Настройка inventory для EVTA».
Убедитесь, что созданы необходимые Jenkins jobs из состава архива ./EVTA-scripts-[version]-distrib.zip:
reactive_stream_adapter_vm – для установки компонента EVTA на виртуальную машину;
reactive_stream_adapter_os – для установки компонента EVTA в облачной среде;
evta_config_create – для создания конфигурационных дистрибутивов.
Подробнее о работе с заданиями Jenkins в разделе Подготовка окружения EVTA, подраздел «Создание Jenkins Job для автоматической установки EVTA».
Заполните параметры созданной Jenkins job для установки EVTA.
Запустите Jenkins job, дождитесь окончания выполнения работы.
Убедитесь, что установка завершена без ошибок, просмотрев лог консоли Jenkins и проверив код завершения (статус «Finished: SUCCESS»).
Успешным результатом работы Jenkins job будет запущенный EVTA на серверах, указанных в inventory.
Запуск установки EVTA под другим пользователем#
Данный подраздел применим при установке компонента на ВМ
В случае запрета удаленного подключения под пользователем adapter возможно использовать механизм запуска установки EVTA под другим пользователем (не под тем, что используется для подключения к серверу установки EVTA).
Для этого предварительно необходимо добавить параметры в конфигурационный файл vars.yml:
# авторизация под другим пользователем и его паролем
ansible_become: 1 # Использование данного механизма при установке. Доступные значения: 0 и 1. Если 1 — при авторизации на сервере, представляемся другим пользователем. Установка будет производиться под пользователем, указанным в параметре *ansible_become_user* ниже. Значение по умолчанию: 0 (не используем данный механизм)
ansible_become_method: su # Способ представления пользователя в Linux. Доступные значения: su или sudo. При использовании sudo - можно не запрашивать пароль пользователя. Значение по умолчанию: sudo
ansible_become_flags: --login #
ansible_become_user: <имя пользователя> # пользователь, под которым будет производиться установка. Например, adapter. В таком случае, в параметре ansible_user указывается пользователь, под которым осуществляется вход на сервер
ansible_become_pass: <пароль пользователя> # пароль пользователя, под которым будет производиться установка (Например, adapter)
Способ представления пользователя с использованием sudo (если пароль пользователя неизвестен):
# авторизация под другим пользователем с использованием sudo (при добавлении в /etc/sudoers: user ALL=(<имя пользователя>) NOPASSWD:ALL)
ansible_become: 1
ansible_become_user: <имя пользователя> # пользователь, под которым будет производиться установка
Здесь в примерах adapter — имя пользователя из раздела «Создание системных и пользовательских сервисов обслуживания для EVTA».
После запуска установки с описанными параметрами установка EVTA будет осуществляться под пользователем, указанным в параметре ansible_become_user.
Настройка интеграции EVTA с сервисными системами#
Ниже описана процедура интеграции с рекомендованным АО «СберТех» продуктами:
Platform V Audit SE (компонент AUDT);
Platform V Monitor (компонент LOGA);
Platform V Corax (компонент KFKA);
Platform V Synapse Event-domain management (компонент EDMN Synapse Event Monitoring system (Mayak));
Platform V Synapse Streaming Event Processing (компонент EVPC Synapse Cloud Event Streaming Processing);
Platform V Synapse Messaging (компонент SMBX Синапс.Брокер сообщений).
На усмотрение пользователя может быть настроена интеграция с аналогичным по функциональности продуктом от других производителей.
Элементы дистрибутива, содержащие файлы скриптов развертывания и управления, описаны в разделе Состав дистрибутива и информация о дистрибутиве EVTA.
1. Интеграция с компонентом AUDT продукта Platform V Audit SE#
Настройка интеграции компонента EVTA с компонентом AUDT продукта Platform V Audit SE производится в файле vars.yml, блок настроек:
audit: # Блок настроек аудита
audit.service.type: http
audit.service.url: http://audit.endpoint
audit.service.request.timeout.ms: 10000
audit.service.metamodel.path: ./audit/adapter-metamodel.json
audit.service.send.metamodel: "false"
audit.service.pretty.print: "false"
audit.service.ssl.enabled: "false"
audit.service.verify.hostname: "false"
audit.service.add.redelivery.headers: "false"
audit.service.redelivery.enabled: "true"
audit.service.redelivery.interval.ms: 15000
audit.service.redelivery.initial.delay.ms: 10000
audit.service.redelivery.stop.on.error: "true"
audit.service.redelivery.retries: -1
audit.service.stop.timeout.ms: 3000
audit.service.redelivery.buffers: in-memory-buffer
audit.service.redelivery.in-memory-buffer.type: queue
audit.service.redelivery.in-memory-buffer.clear.logger.name: memory
audit.service.dead.letter.redelivery.enabled: "true"
audit.service.dead.letter.redelivery.interval.ms: 15000
audit.service.dead.letter.redelivery.initial.delay.ms: 10000
audit.service.dead.letter.redelivery.stop.on.error: false
audit.service.dead.letter.redelivery.retries: -1
audit.service.dead.letter.redelivery.buffers: queue-fallback
audit.service.dead.letter.redelivery.queue-fallback.type: queue
audit.service.dead.letter.redelivery.queue-fallback.queue.name: logger-fallback
audit.service.ssl.keystore.location: "ssl/audit_keystore.jks"
audit.service.ssl.keystore.password: __PLACEHOLDER__
audit.service.ssl.key.password: __PLACEHOLDER__
audit.service.ssl.truststore.location: "ssl/audit_truststore.jks"
audit.service.ssl.truststore.password: __PLACEHOLDER__
audit.service.secret: "file:./ssl/secret.pass"
## Настройка kafka-транспорта для событий аудита
audit.service.transport.type: kafka # Тип транспорта, http или kafka, по умолчанию http
audit.service.metamodel.topic: metamodel-topic # Имя топика для отправки метамодели
audit.service.event.topic: event-topic # Имя топика для отправки событий
audit.service.kafka.bootstrap.servers: "localhost:9093" # Адреса kafka
audit.service.node.id: "hostname-1" # Идентификатор узла, может брать значение переменной окружения (например env:HOSTNAME)
audit.service.source.system: "source.system" # Название инсталяции, может брать значение переменной окружения (например env:HOSTNAME)
## ОПЦИОНАЛЬНО Сериализаторы (по умолчанию org.apache.kafka.common.serialization.StringSerializer)
audit.service.kafka.key.serializer: org.apache.kafka.common.serialization.StringSerializer
audit.service.kafka.value.serializer: org.apache.kafka.common.serialization.StringSerializer
## ОПЦИОНАЛЬНО идентификатор клиента
audit.service.kafka.client.id: audit-producer
## ОПЦИОНАЛЬНО настройки ssl
audit.service.kafka.security.protocol: SSL
audit.service.kafka.ssl.keystore.location: ssl/keystore.jks
audit.service.kafka.ssl.keystore.password: password
audit.service.kafka.ssl.truststore.location: ssl/truststore.jks
audit.service.kafka.ssl.truststore.password: password
audit.service.kafka.ssl.endpoint.identification.algorithm: ""
2. Интеграция с компонентом LOGA продукта Platform V Monitor#
Настройка интеграции компонента EVTA с компонентом LOGA продукта Platform V Monitor производится в файле vars.yml. Подробная настройка интеграции компонента EVTA с централизованной системой журналирования приведена в «Руководство администратора» в разделе «Системный журнал».
3. Интеграция с компонентом KFKA продукта Platform V Corax#
Настройка интеграции компонента EVTA с компонентом KFKA продукта Platform V Corax производится в файле vars.yml. Подробнее настройка интеграции представлена в разделе Подготовка окружения EVTA, подраздел «Пример заполненного файла vars.yml для EVTA».
4. Интеграция с компонентом EDMN (Mayak) продукта Platform V Synapse Event-domain management#
Настройка интеграции компонента EVTA с компонентом EDMN (Mayak) продукта Platform V Synapse Event-domain management производится в файле конфигурации adapter.conf. В блоке metrics необходимо указать следующие настройки:
"metrics": {
}
Параметры:
- `metrics` - настройки метрик
* `jmx` - настройки метрик JMX
* `enabled` - включение метрик, значение по умолчанию true
* `domain` - корневой пакет для метрик, значение по умолчанию "ru.sbt.ss.reactive.stream.adapter"
* `step` - интервал для агрегирующих функций, по умолчанию 1 минута
* `prometheus` - настройки метрик Prometheus
* `enabled` - включение метрик, значение по умолчанию false
* `histogramFlavor` - тип формата гистограмм, значение по умолчанию Prometheus
* `step` - интервал для агрегирующих функций, по умолчанию 1 минута
5. Интеграция с компонентом EVPC (облачная среда)#
Настройка интеграции компонента EVTA с компонентом EVPC производится только в облачной среде. Необходимо добавить в файл vars.yml обязательный набор параметров в блок reactive_stream_adapter:
reactive_stream_adapter:
# EVPC соединяется только по протоколу GRPC
egressType: grpc
# отключение механизма автоматического коммита сообщения при вычитке адаптером
autoCommit: false
# Включить механизм подтверждения получения/обработки сообщения со стороны EVPC
needInfoAboutAcknowledge: true
# Отключение механизма остановки консьюмера при простое потока
useStorageTime: false
Также для компонента EVPC должны быть указаны соответствующие параметры в файле vars.yml. Подробнее оп/исано в документе «Руководство по установке» компонента EVPC.
6. Интеграция с компонентом SMBX продукта Platform V Synapse Messaging#
Настройка интеграции компонента EVTA с компонентом SMBX продукта Platform V Synapse Messaging производится в файле vars.yml. Подробнее настройка интеграции представлена в разделе Подготовка окружения EVTA, подраздел «Пример заполненного файла vars.yml для EVTA».
Настройка интеграции EVTA с Istio#
Для работы EVTA с Istio возможно указание параметров в конфигурационном файле vars.yml.
В аннотации развертывания (поле annotations файла vars.yml) необходимо добавить:
sidecar.istio.io/inject: 'true'
Блок настроек файла vars.yml, относящихся к Istio:
istio: # настройки манифестов Istio
# destinationRule: # параметры для манифеста DestinationRule Istio
# outlierDetection:
# consecutive5xxErrors: 3
# interval: 30s
# baseEjectionTime: 1m
# maxEjectionPercent: 10
peerAuthentication:
create: false
# name: peer-auth-0
# mtls_mode: PERMISSIVE # UNSET (default) | DISABLE | PERMISSIVE | STRICT
ingress:
deployment:
create: false # создавать ли Deployment для istio ingressgateway
name: evta # Суффикс названия деплоймента и сервиса входного граничного прокси. К этому названию автоматически будет добавлен префикс "ingressgateway-"
# resources:
# limits:
# cpu: 0.1
# memory: 128M
# requests:
# cpu: 0.1
# memory: 64M
podAntiAffinity:
enabled: true # Если значение установлено в true, то антитенантность будет применена к подам ingressgateway
readinessProbe: {}
# initialDelaySeconds: 1
# timeoutSeconds: 1
# periodSeconds: 2
# successThreshold: 1
# failureThreshold: 30
annotations:
sidecar.istio.io/inject: 'false'
# # Дополнительные аннотации для граничного прокси. Здесь можно описать импорт сертификатов из vault/secman
# vault.hashicorp.com/agent-inject-secret-ca.pem: 'true'
# vault.hashicorp.com/secret-volume-path-ca.pem: /vault/ingress
# vault.hashicorp.com/namespace: DEV_DZO
# vault.hashicorp.com/role: role-ga-secman-eda
# 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-ga-secman-eda"
# "common_name=evta.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-ga-secman-eda"
# "common_name=evta.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-ga-secman-eda"
# "common_name=evta.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 # название discovery сервиса панели истио к которой подключен ваш неймспейс
# istioControlPlane: control-plane-01 # название неймспейса контрольной панели истио к которой подключен ваш неймспейс
# proxyImage: image # ссылка на образ граничного прокси (IGEG)
service: # параметры сервиса Ingress
create: false # создавать ли манифест сервиса
# name: evta-ingressgateway-svc # имя сервиса Ingress (по умолчанию имя генерируется автоматически)
# port:
# name: https-8082
# number: 8082
# protocol: TCP
# selector: # Селектор для интеграции с уже существующим подом ingressgateway
# istio: ingressgateway-tribe-sy-synes-nt
# app: ingressgateway-tribe-sy-synes-nt
# route, ссылающийся на имя описанного в ingress service порт, по которому будет производиться маршрутизация внутри ingress.
route:
create: false # создавать ли манифест Route
# host: test1-https-ingress.apps.stands-vdc01.solution.sbt
# annotations: {}
# tls:
# termination: passthrough
# service:
# port: https-8082
# name: evta-ingressgateway-svc
# gateway, в котором указывается параметр содержащий ingress url, который указан в route, и порт из service ingress'a, в который будет заворачиваться трафик.
gateway:
create: false # создавать ли манифест Gateway
# name: evta-ingressgateway-gw # имя манифеста (по умолчанию имя генерируется автоматически)
# hosts: test1-https-ingress.apps.stands-vdc01.solution.sbt
# port:
# name: https
# number: 8082
# protocol: HTTPS
# tls:
# caCertificates: /etc/istio/egressgateway0-ca-certs/ca-chain.cert.pem
# cipherSuites:
# - ECDHE-RSA-AES256-GCM-SHA384
# - ECDHE-ECDSA-AES128-GCM-SHA256
# - ECDHE-RSA-AES128-GCM-SHA256
# - AES256-GCM-SHA384
# - AES128-GCM-SHA256
# minProtocolVersion: TLSV1_2
# mode: MUTUAL
# privateKey: /etc/istio/egressgateway0-certs/tls.key
# serverCertificate: /etc/istio/egressgateway0-certs/tls.crt
# virtualService
virtualService:
create: false # создавать ли манифест VirtualService
# hosts: 'test1-https-ingress.apps.stands-vdc01.solution.sbt'
# http:
# # example for rest
# - prefix: /publish
# port: 8080
# - prefix: /subscribe
# port: 8081
# # example for grpc
# - prefix: /ru.sbt.synapse.fpss.adapter.grpc.api.PublishService
# port: 8080
# - prefix: /ru.sbt.synapse.fpss.adapter.grpc.api.SubscribeService
# port: 8081
# массив serviceEntry, которые нужно создать
# serviceEntry:
# - host: my_hostname
# addresses: { IP_ADDRESS }/32
# resolution: NONE
# port:
# name: tcp-kafka
# number: 9092
# protocol: TCP
# # annotations: # раскомментировать, если нужно, чтобы serviceEntry осталась после helm uninstall
# # "helm.sh/resource-policy": keep
# - host: secman-dzo.solution.sbt
# resolution: DNS
# port:
# name: tcp-vault
# number: 8443
# protocol: TCP
# - host: ext.audit2-http-proxy.apps.stands-vdc01.solution.sbt
# resolution: DNS
# port:
# name: https-audit
# number: 443
# protocol: HTTPS
egress:
deployment:
create: false # создавать ли Deployment для istio egressgateway
name: evta # Суффикс названия деплоймента и сервиса выходного граничного прокси. К этому названию автоматически будет добавлен префикс "egressgateway-"
# resources:
# limits:
# cpu: 0.1
# memory: 128M
# requests:
# cpu: 0.1
# memory: 64M
podAntiAffinity:
enabled: true # Если значение установлено в true, то антитенантность будет применена к подам egressgateway
readinessProbe: {}
# initialDelaySeconds: 1
# timeoutSeconds: 1
# periodSeconds: 2
# successThreshold: 1
# failureThreshold: 30
annotations:
sidecar.istio.io/inject: 'false'
# # Дополнительные аннотации для граничного прокси. Здесь можно описать импорт сертификатов из vault/secman
# vault.hashicorp.com/agent-inject-template-cert.pem: |
# {%- raw %}
# {{- with secret "A/DEV/SY/EVTD/KV/example-audit-cert" -}}
# {{ index .Data "cert" }}
# {{- end }}
# {%- endraw %}
# vault.hashicorp.com/agent-inject-secret-ca.pem: 'true'
# vault.hashicorp.com/secret-volume-path-ca.pem: /vault
# vault.hashicorp.com/namespace: DEV_DZO
# vault.hashicorp.com/role: role-ga-secman-eda
# vault.hashicorp.com/agent-inject-secret-cert.pem: 'true'
# vault.hashicorp.com/secret-volume-path-key.pem: /vault
# vault.hashicorp.com/agent-inject: 'true'
# vault.hashicorp.com/secret-volume-path-cert.pem: /vault
# vault.hashicorp.com/agent-inject-secret-key.pem: '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-key.pem: |
# {%- raw %}
# {{- with secret "A/DEV/SY/EVTD/KV/example-audit-cert" -}}
# {{ index .Data "key" }}
# {{- end }}
# {%- endraw %}
# vault.hashicorp.com/agent-inject-template-ca.pem: |
# {%- raw %}
# {{- with secret "A/DEV/SY/EVTD/KV/example-audit-cert" -}}
# {{ index .Data "ca" }}
# {{- end }}
# {%- endraw %}
labels: {}
# secman-injector: enabled # метка для активации интеграции с secman vault agent injector
# istioDiscoveryService: istiod # название discovery сервиса панели истио к которой подключен ваш неймспейс
# istioControlPlane: control-plane-01 # название неймспейса контрольной панели истио к которой подключен ваш неймспейс
# proxyImage: image # ссылка на образ граничного прокси (IGEG)
service: # параметры сервиса Egress
name: evta-egressgateway-svc # имя сервиса Egress (по умолчанию имя генерируется автоматически)
create: false # создавать ли манифест сервиса
# internalPort: 9443 # внутренний порт Egress
# internalPortName: http-9443
# internalPortProtocol: http
# selector: # содержимое поля spec.selector в манифесте. По умолчанию выбирается создаваемый выше egressgateway
# app: egressgateway-tribe-sy-synes-nt
# istio: egressgateway-tribe-sy-synes-nt
gateway: # параметры манифеста Gateway для Istio Egress
create: false # создавать ли манифест
# name: evta-egressgateway-gw # имя манифеста (по умолчанию имя генерируется автоматически)
# selector: # содержимое поля spec.selector в манифесте. По умолчанию выбирается создаваемый выше egressgateway
# istio: egressgateway-tribe-sy-synes-nt
destinationRule: # Конфигурация destination rule к сервису egressgateway
create: false
# name: evta-egressgateway-dr # имя манифеста (по умолчанию имя генерируется автоматически)
# outlierDetection:
# consecutive5xxErrors: 3
# interval: 30s
# baseEjectionTime: 1m
# maxEjectionPercent: 10
# # При создании 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 # создавать ли манифест
# 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 для кафки
# create: true # создавать ли манифест
# serviceEntry: # параметры для манифеста ServiceEntry для кафки
# create: true # создавать ли манифест
vault: # параметры для интеграции с HashiCorp Vault
# host: vault.url # хост сервиса HashiCorp Vault
# port: 8443 # порт сервиса HashiCorp Vault
# externalPort: 8443 # порт сервиса HashiCorp Vault для обращения из приклада
# # Порты и протоколы ниже используются в манифестах VirtualService, Gateway, Gateway Service
# # Поддерживаемые gwSvc протоколы - "SCTP", "TCP", "UDP"
# gwPort: 9447 # порт на egressGateway
# gwProtocol: TLS # протокол на egressGateway
# gwSvcProtocol: TCP # протокол на service egressGateway
# gwTls:
# mode: ISTIO_MUTUAL # Валидные значения: "PASSTHROUGH", "SIMPLE", "MUTUAL", "AUTO_PASSTHROUGH", "ISTIO_MUTUAL", "OPTIONAL_MUTUAL"
destinationRule: # параметры для манифеста DestinationRule Istio
create: false # создавать ли манифест
# name: evta-vault-dr # имя манифеста (по умолчанию имя генерируется автоматически)
# tls:
# mode: MUTUAL
# caCertificates: /vault/ca.pem
# clientCertificate: /vault/cert.pem
# privateKey: /vault/key.pem
# outlierDetection:
# consecutive5xxErrors: 3
# interval: 30s
# baseEjectionTime: 1m
# maxEjectionPercent: 10
virtualService: # параметры для манифеста VirtualService
create: false # создавать ли манифест VirtualService
# name: evta-vault-vs # имя манифеста (по умолчанию имя генерируется автоматически)
# protocol: tls # протокол для создания virtual service. Валидные значения: http, tls, tcp
audit: # параметры для интеграции с сервисом Аудита
# host: audit.url # хост сервиса Аудита
# port: 80 # порт сервиса Аудита для обращения из pod'а
# externalPort: 443 # порт сервиса Аудита
# # Порты и протоколы ниже используются в манифестах VirtualService, Gateway, Gateway Service
# # Поддерживаемые gwSvc протоколы - "SCTP", "TCP", "UDP"
# gwPort: 9446 # порт на egressGateway
# gwProtocol: HTTP # протокол на egressGateway
# gwSvcProtocol: TCP # протокол на service egressGateway
# gwTls:
# mode: ISTIO_MUTUAL # Валидные значения: "PASSTHROUGH", "SIMPLE", "MUTUAL", "AUTO_PASSTHROUGH", "ISTIO_MUTUAL", "OPTIONAL_MUTUAL"
destinationRule: # параметры для манифеста DestinationRule Istio
create: false # создавать ли манифест
# name: audit-dr # имя манифеста (по умолчанию имя генерируется автоматически)
# tls:
# mode: MUTUAL
# caCertificates: /path/to/egress/certificates/ca-chain.cert.pem
# clientCertificate: /path/to/egress/certificates/tls.crt
# privateKey: /path/to/egress/certificates/tls.key
# outlierDetection:
# consecutive5xxErrors: 3
# interval: 30s
# baseEjectionTime: 1m
# maxEjectionPercent: 10
virtualService: # параметры для манифеста VirtualService
create: false # создавать ли манифест VirtualService
# name: audit-vs # имя манифеста (по умолчанию имя генерируется автоматически)
# protocol: http # протокол для создания virtual service. Валидные значения: http, tls, tcp
telemetry: # параметры для интеграции с сервисом телеметрии
# host: telemetry.url # хост сервиса телеметрии
# port: 4317 # порт сервиса телеметрии для обращения из pod'а
# externalPort: 4317 # порт сервиса телеметрии
# # Порты и протоколы ниже используются в манифестах VirtualService, Gateway, Gateway Service
# # Поддерживаемые gwSvc протоколы - "SCTP", "TCP", "UDP"
# gwPort: 9478 # порт на egressGateway
# gwProtocol: HTTPS # протокол на egressGateway
# gwSvcProtocol: TCP # протокол на service egressGateway
# gwTls:
# mode: ISTIO_MUTUAL
destinationRule: # параметры для манифеста DestinationRule Istio
create: false # создавать ли манифест
# tls:
# mode: MUTUAL
# clientCertificate: /vault/evta-pki-cert-telemetry.pem
# privateKey: /vault/evta-pki-key-telemetry.pem
# caCertificates: /vault/evta-pki-truststore-telemetry.pem
# outlierDetection:
# consecutive5xxErrors: 3
# interval: 30s
# baseEjectionTime: 1m
# maxEjectionPercent: 10
virtualService: # параметры для манифеста VirtualService
create: false # создавать ли манифест VirtualService
# name: telemetry-vs # имя манифеста (по умолчанию имя генерируется автоматически)
# protocol: http # протокол виртуального сервиса
Получение сертификатов из Vault#
В блоке параметров для работы с Istio некоторые значения являются сертификатами, находящимися в egress/ingress контейнерах. Данные сертификаты могут быть получены из Vault.
Для этого в развертывании указанных контейнеров необходимо добавить аннотации для работы с Vault:
Аннотация |
Описание |
Значение |
|---|---|---|
|
Используемая для аутентификации роль |
Роль |
|
Используемое пространство имен, которое будет использоваться при запросе секретов из Vault |
Namespace |
|
Включение инъекции Vault Agent Sidecar |
|
|
Должны ли быть получены секреты до старта самого контейнера приложения |
|
|
Включать ли контейнер init для предварительного заполнения тома общей памяти секретами перед запуском контейнеров |
|
|
Сохранять ли регистр секретных имен при создании секретных файлов |
|
|
Настраивает ограничения на использование CPU в контейнерах Vault Agent |
По умолчанию 500m, пустая строка отключает ограничения |
|
Настраивает ограничения на запрос CPU в контейнерах Vault Agent |
По умолчанию 250m, пустая строка отключает ограничения |
|
Настраивает ограничения на использование памяти в контейнерах Vault Agent |
По умолчанию 128Mi, пустая строка отключает ограничения |
|
Настраивает ограничения на запрос памяти в контейнерах Vault Agent |
По умолчанию 64Mi, пустая строка отключает ограничения |
|
Секрет, полученный из хранилища, будет добавлен в контейнер с указанным именем файла. Если используется agent-inject-template, то для того, чтобы полученный секрет был записан в файл, необходимо указать данную аннотацию с любым значением (будет переписано шаблоном) |
|
|
Секрет будет добавлен в контейнер с указанным именем файла в указанную директорию, если имя файла не указано, будет установлено значение по умолчанию для всех отображаемых секретов в модуле |
В какую директорию будет записан полученный секрет |
|
Секрет, полученный после выполнения шаблона, будет добавлен в контейнер с указанным именем файла |
Шаблон для получения секрета |
Пример аннотаций для выгрузки KV секрета:#
annotations:
vault.hashicorp.com/agent-inject-secret-test.yml: 'true'
vault.hashicorp.com/secret-volume-path-test.yml: /vault/test
vault.hashicorp.com/namespace: namespace
vault.hashicorp.com/role: role
vault.hashicorp.com/agent-inject: 'true'
vault.hashicorp.com/agent-init-first: 'true'
После запуска в контейнере в директории /vault/test появится файл test.yml. В файле будут содержаться ключи и значения секрета PATH/TO/KV/test.
Предположим, что в секрете содержатся следующие значения: key1 -> value1 и key2 -> value2, тогда содержимое файла будет:
sh-4.4$ cat /vault/test/test.yml
key: value1
keystore: value2
Если необходимо получить конкретное значение:
annotations:
vault.hashicorp.com/agent-inject-secret-test.yml: 'true'
vault.hashicorp.com/secret-volume-path-test.yml: /vault/test
vault.hashicorp.com/agent-inject-template-test.yml: |
{%- raw %}
{{- with secret "PATH/TO/KV/test" -}}
{{ index .Data "key1" }}
{{- end }}
{%- endraw %}
vault.hashicorp.com/namespace: namespace
vault.hashicorp.com/role: role
vault.hashicorp.com/agent-inject: 'true'
vault.hashicorp.com/agent-init-first: 'true'
После запуска в контейнере в директории /vault/test появится файл test.yml. В файле будет содержаться значения key1 секрета PATH/TO/KV/test:
sh-4.4$ cat /vault/test/test.yml
value1
Пример аннотаций для выпуска сертификата через Vault:#
annotations:
vault.hashicorp.com/agent-inject-secret-ca.cert: 'true'
vault.hashicorp.com/secret-volume-path-ca.cert: /vault/test
vault.hashicorp.com/agent-inject-template-ca.cert: >
{{- with secret "PKI/issue/role" "common_name=test" -}}
{{ .Data.issuing_ca }}
{{- end }}
vault.hashicorp.com/agent-inject-secret-server.key: 'true'
vault.hashicorp.com/secret-volume-path-server.key: /vault/test
vault.hashicorp.com/agent-inject-template-server.key: >
{{- with secret "PKI/issue/role" "common_name=test" -}}
{{ .Data.private_key }}
{{- end }}
vault.hashicorp.com/namespace: namespace
vault.hashicorp.com/role: role
vault.hashicorp.com/agent-inject: 'true'
vault.hashicorp.com/agent-init-first: 'true'
vault.hashicorp.com/agent-inject-secret-server.cert: 'true'
vault.hashicorp.com/secret-volume-path-server.cert: /vault/test
vault.hashicorp.com/agent-inject-template-server.cert: >
{{- with secret "PKI/issue/role" "common_name=test" -}}
{{ .Data.certificate }}
{{- end }}
После запуска в контейнере в директории /vault/test появится три файла: server.cert, server.key, ca.cert.
Пример аннотаций для получения сертификата через Vault:#
annotations:
vault.hashicorp.com/agent-inject-secret-ca.cert: 'true'
vault.hashicorp.com/secret-volume-path-ca.cert: /vault/test
vault.hashicorp.com/agent-inject-template-ca.cert: >
{{- with secret "PATH/TO/KV/cert" -}}
{{ base64Decode (index .Data "ca.cert") }}
{{- end }}
vault.hashicorp.com/agent-inject-secret-server.key: 'true'
vault.hashicorp.com/secret-volume-path-server.key: /vault/test
vault.hashicorp.com/agent-inject-template-server.key: >
{{- with secret "PATH/TO/KV/cert" -}}
{{ base64Decode (index .Data "server.key") }}
{{- end }}
vault.hashicorp.com/namespace: namespace
vault.hashicorp.com/role: role
vault.hashicorp.com/agent-inject: 'true'
vault.hashicorp.com/agent-init-first: 'true'
vault.hashicorp.com/agent-inject-secret-server.cert: 'true'
vault.hashicorp.com/secret-volume-path-server.cert: /vault/test
vault.hashicorp.com/agent-inject-template-server.cert: >
{{- with secret "PATH/TO/KV/cert" -}}
{{ base64Decode (index .Data "server.cert") }}
{{- end }}
После запуска в контейнере в директории /vault/test появится три файла: server.cert, server.key, ca.cert.
Настройка egress/ingress для работы с Vault#
Ниже приведены примеры шаблонов, которые необходимы для настройки работы контейнеров, использующих egress/ingress с Vault:
Service:
apiVersion: v1
kind: Service
metadata:
name: egressgateway-svc
labels:
egress: {{.Values.istio.egress.projectName}}
spec:
ports:
- name: http-{{ .Values.istio.egress.egressPort }}
port: {{ .Values.istio.egress.egressPort }}
protocol: TCP
- name: tls-8550
protocol: TCP
port: 8550
targetPort: 8550
{{- range .Values.istio.egress.services_ports }}
- name: tcp-{{.}}
protocol: TCP
port: {{.}}
targetPort: {{.}}
{{- end }}
selector:
app: egressgateway-{{ .Values.istio.egress.projectName }}
istio: egressgateway-{{ .Values.istio.egress.projectName }}
Gateway:
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: egress-secman-gw
labels:
egress: {{.Values.istio.egress.projectName}}
spec:
selector:
istio: egressgateway-{{ .Values.istio.egress.projectName }}
servers:
- hosts:
- {{ .Values.istio.egress.secmanHost }}
port:
name: tls-8550
number: 8550
protocol: TLS
tls:
mode: PASSTHROUGH
VirtualService:
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
namespace: {{ .Values.istio.egress.projectName }}
name: egress-secman-vs
labels:
egress: {{.Values.istio.egress.projectName}}
spec:
exportTo:
- .
gateways:
- egress-secman-gw
- mesh
hosts:
- {{ .Values.istio.egress.secmanHost }}
tls:
- match:
- gateways:
- mesh
port: 443
sniHosts:
- {{ .Values.istio.egress.secmanHost }}
route:
- destination:
host: egressgateway-svc.{{ .Values.istio.egress.projectName }}.svc.cluster.local
port:
number: 8550
- match:
- gateways:
- egress-secman-gw
port: 8550
sniHosts:
- {{ .Values.istio.egress.secmanHost }}
route:
- destination:
host: {{ .Values.istio.egress.secmanHost }}
port:
number: 443
ServiceEntry:
apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
name: egress-secman-se
namespace: {{ .Values.istio.egress.projectName }}
labels:
egress: {{.Values.istio.egress.projectName}}
spec:
exportTo:
- .
hosts:
- {{ .Values.istio.egress.secmanHost }}
location: MESH_EXTERNAL
ports:
- name: tls-443
number: 443
protocol: TLS
resolution: DNS
PeerAuthentication:
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
name: egress-pa
namespace: {{ .Values.istio.egress.projectName }}
labels:
egress: {{.Values.istio.egress.projectName}}
spec:
portLevelMtls:
'8550':
mode: DISABLE
selector:
matchLabels:
app: egressgateway-{{ .Values.istio.egress.projectName }}
DestinationRule:
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
name: egress-secman-dr
namespace: {{ .Values.istio.egress.projectName }}
labels:
egress: {{ .Values.istio.egress.projectName }}
spec:
exportTo:
- .
host: egressgateway-svc.{{ .Values.istio.egress.projectName }}.svc.cluster.local
trafficPolicy:
portLevelSettings:
- port:
number: 8550
tls:
mode: DISABLE
Масштабирование количества pods#
Данный подраздел применим при установке компонента в облачной среде.
При необходимости масштабирования количества pods следует:
изменить параметр replicas в конфигурационном файле Ansible/roles/reactive_stream_adapter/defaults/main.yml:
reactive_stream_adapter:
replicas: 2 # количество pods в EVTA (2 по умолчанию)
перезапустить установку EVTA одним из методов, указанных в разделе Выбор способа установки.
EVTA (оператор)#
Описание EVTA (оператора)#
EVTA (оператор) предназначен для управления процессом автоматического развертывания адаптера EVTA и обновления конфигураций, используемых адаптером.
С помощью REST/gRPC адаптера сервисы в кластере могут принимать и отправлять сообщения в транспорт (kafka, artemis, rabbit).
Управление адаптером осуществляется через специальные манифесты (SynapseEvtaGateway, SynapseEvtaPublication, SynapseEvtaSubscription).
Конфигурация для запуска EVTA (оператора)#
Имя |
Значение по умолчанию |
Описание |
|---|---|---|
k8s.namespaces |
Список пространств, в которых оператор отслеживает ресурсы |
|
grpc.port |
8080 |
Порт, на котором запускается сервер в операторе |
grpc.retries.count |
1 |
Количество повторных отправок сообщений (при ошибке отправки) сервером |
grpc.retries.interval |
1000 |
Интервал между повторными отправками сообщений (при ошибке отправки) сервером |
grpc.retries.multiplier |
1 |
Множитель для интервала между повторными отправками сообщений (при ошибке отправки) сервером |
grpc.healthcheck.port |
8081 |
Порт, на котором запускается healthcheck сервер в операторе |
grpc.healthcheck.host |
0.0.0.0 |
Хост, на котором запускается healthcheck сервер в операторе |
audit.enabled |
false |
При значении true, необходимо задать настройки для инициализации аудит клиента |
Пример конфигурации:
{
"k8s": {
"namespaces": ["operator-test"]
},
"grpc": {
"port": 8089,
"retries": {
"count": 4,
"interval": 1000,
"multiplier": 2
}
},
"healthcheck": {
"host": "0.0.0.0",
"port": 9000
},
"audit": {
"enabled": false
}
}
Сценарии использования#
Развертывание адаптера#
Для развертывания используется ресурс SynapseEvtaGateway.
SynapseEvtaGateway#
Ресурс SynapseEvtaGateway позволяет управлять развертыванием адаптера (Deployment, Service).
Описание параметров:
Имя |
Описание |
|---|---|
annotations |
Аннотации, добавляемые в Deployment адаптера |
environment |
Аеременные окружения, добавляемые в Deployment адаптера |
labels |
Метки, добавляемые в Deployment адаптера |
port |
Порт, на котором разворачивается адаптер (так же используется в создаваемом Service) |
service |
Имя Service разворачиваемого адаптера |
secret |
Имя, используемого Secret (Данные монтируются в /ssl) |
template |
Название ConfigMap шаблона адаптера (Данные монтируются в /reactivestreamadapter/conf) |
templateProperties |
Набор параметров шаблона развертывания манифестов адаптера |
additionalProperties |
Дополнительные свойства развертывания адаптера |
Описание templateProperties:
Имя |
Значение по умолчанию |
Описание |
|---|---|---|
image |
Образ адаптера, который будет разворачиваться оператором. Обязательно для заполнения |
|
replicas |
1 |
Количество реплик на старте |
serviceAccountName |
default |
Используемый serviceAccountName |
imagePullSecrets |
Используемый imagePullSecrets |
|
containerArgs |
Дополнительные аргументы запуска адаптера |
|
affinityWeight |
100 |
Используется для настроек affinity |
topologyKey |
topology.kubernetes.io/hostname |
Используется для настроек affinity |
containerPort |
9090 |
Значение containerPort в ports |
containerPortName |
callback |
Значение name в ports |
resourceLimitsCpu |
500m |
Значение cpu в limits |
resourceLimitsMemory |
600Mi |
Значение memory в limits |
resourceRequestsCpu |
300m |
Значение cpu в requests |
resourceRequestsMemory |
40Mi |
Значение memory в requests |
rollingUpdateMaxUnavailable |
25% |
Значение maxUnavailable в rollingUpdate strategy |
rollingUpdateMaxSurge |
25% |
Значение maxSurge в rollingUpdate strategy |
minReadySeconds |
10 |
Значение minReadySeconds в rollingUpdate strategy |
revisionHistoryLimit |
10 |
Значение revisionHistoryLimit в rollingUpdate strategy |
progressDeadlineSeconds |
120 |
Значение progressDeadlineSeconds в rollingUpdate strategy |
schedulerName |
default-scheduler |
Значение schedulerName |
terminationGracePeriodSeconds |
30 |
Значение terminationGracePeriodSeconds |
imagePullPolicy |
Always |
Значение imagePullPolicy |
readinessProbePort |
8081 |
Порт для readinessProbe |
readinessProbeInitialDelaySeconds |
60 |
initialDelaySeconds для readinessProbe |
readinessProbeTimeoutSeconds |
10 |
timeoutSeconds для readinessProbe |
readinessProbePeriodSeconds |
10 |
readinessProbePeriodSeconds для readinessProbe |
readinessProbeSuccessThreshold |
1 |
readinessProbeSuccessThreshold для readinessProbe |
readinessProbeFailureThreshold |
20 |
readinessProbeFailureThreshold для readinessProbe |
livenessProbePort |
8081 |
Порт для livenessProbe |
livenessProbeInitialDelaySeconds |
30 |
initialDelaySeconds для livenessProbe |
livenessProbeTimeoutSeconds |
10 |
timeoutSeconds для livenessProbe |
livenessProbePeriodSeconds |
10 |
livenessProbePeriodSeconds для livenessProbe |
livenessProbeSuccessThreshold |
1 |
livenessProbeSuccessThreshold для livenessProbe |
livenessProbeFailureThreshold |
20 |
livenessProbeFailureThreshold для livenessProbe |
CRD
kind: CustomResourceDefinition
apiVersion: apiextensions.k8s.io/v1
metadata:
name: gateways.ru.sbertech.platformv.synapse.shared
spec:
group: ru.sbertech.platformv.synapse.shared
names:
plural: gateways
singular: gateway
shortNames:
- gtw
kind: SynapseEvtaGateway
listKind: SynapseEvtaGatewayList
scope: Namespaced
versions:
- name: v1
served: true
storage: true
schema:
openAPIV3Schema:
type: object
properties:
spec:
type: object
required:
- service
- port
properties:
port:
type: integer
annotations:
type: object
additionalProperties:
type: string
templateProperties:
type: object
additionalProperties:
type: string
secret:
type: string
environment:
type: object
additionalProperties:
type: string
service:
type: string
template:
type: string
additionalProperties:
type: object
additionalProperties:
type: string
labels:
type: object
additionalProperties:
type: string
Добавление эндпоинта для публикации#
Для добавления эндпоинта для публикации используется ресурс SynapseEvtaPublication.
SynapseEvtaPublication#
Ресурс SynapseEvtaPublication позволяет публиковать определенные сообщения через определенный экземпляр адаптера.
Описание параметров:
Имя |
Описание |
|---|---|
format |
Формат сообщения (json, xml, avro) |
props |
Параметры подключения к транспорту |
schemas |
Список поддерживаемых схем |
selector |
Метки адаптера к которому необходимо применить конфигурацию |
size |
Размер сообщения |
source |
Источник сообщения из формата CloudEvent (будет использоваться в запросе на публикацию) |
throughput |
Пропускная способность в сообщениях в секунду |
endpoint |
Название топика, адреса или очереди для подключения |
transport |
Тип транспорта: kafka, artemis, rabbit |
CRD
kind: CustomResourceDefinition
apiVersion: apiextensions.k8s.io/v1
metadata:
name: publications.ru.sbertech.platformv.synapse.shared
spec:
group: ru.sbertech.platformv.synapse.shared
names:
plural: publications
singular: publication
shortNames:
- pub
kind: SynapseEvtaPublication
listKind: SynapseEvtaPublicationList
scope: Namespaced
versions:
- name: v1
served: true
storage: true
schema:
openAPIV3Schema:
type: object
properties:
spec:
type: object
required:
- source
- endpoint
properties:
size:
type: string
transport:
type: string
throughput:
type: integer
props:
type: object
additionalProperties:
type: string
schemas:
type: array
items:
type: string
endpoint:
type: string
format:
type: string
source:
type: string
selector:
type: object
additionalProperties:
type: string
Добавление эндпоинта для подписки (запуск webhook в случае rest-адаптера)#
Для добавления эндпоинта для подписки или запуска webhook используется ресурс SynapseEvtaSubscription.
SynapseEvtaSubscription#
Ресурс SynapseEvtaSubscription позволяет получать определенные сообщения по протоколу gRPC через определенный экземлпяр адаптера или адаптер сам отправляет полученные сообщения по заданному адресу.
Описание параметров:
Имя |
Описание |
|---|---|
format |
Формат сообщения (json, xml, avro) |
props |
Параметры подключения к транспорту |
schemas |
Список поддерживаемых схем |
selector |
Метки адаптера к которому необходимо применить конфигурацию |
size |
Размер сообщения |
source |
Источник сообщения из формата CloudEvent (будет использоваться в запросе на публикацию) |
throughput |
Пропускная способность в сообщениях в секунду |
endpoint |
Название топика, адреса или очереди для подключения |
transport |
Тип транспорта: kafka, artemis, rabbit |
url |
Адрес отправки полученных сообщений по протоколу http в случае rest-адаптера |
CRD
kind: CustomResourceDefinition
apiVersion: apiextensions.k8s.io/v1
metadata:
name: subscriptions.ru.sbertech.platformv.synapse.shared
spec:
group: ru.sbertech.platformv.synapse.shared
names:
plural: subscriptions
singular: subscription
shortNames:
- sub
kind: SynapseEvtaSubscription
listKind: SynapseEvtaSubscriptionList
scope: Namespaced
versions:
- name: v1
served: true
storage: true
schema:
openAPIV3Schema:
type: object
properties:
spec:
type: object
required:
- source
- endpoint
properties:
size:
type: string
transport:
type: string
throughput:
type: integer
url:
type: string
props:
type: object
additionalProperties:
type: string
schemas:
type: array
items:
type: string
endpoint:
type: string
format:
type: string
source:
type: string
selector:
type: object
additionalProperties:
type: string
Примеры заполненных файлов vars.yml для манифестов и EVTA (оператора)#
Пример заполненного файла vars.yml для манифестов#
ansible_no_log: true # маскирование сенситивных сообщений в ansible
wait_for_start: 120 # время в секундах на старт приложения
#helm_cli: helm # путь до helm
#kubeconfig_path: /home/user/kubeconfig # путь до файла kubeconfig (может быть зашифрован через ansible-vault)
api_url: https://api.example.ru:6443 # URL API openshift/k8s (не требуется при наличии kubeconfig_path)
token: __PLACEHOLDER__ # токен пользователя (сервис аккаунта) для установки (не требуется при наличии kubeconfig_path)
skip_tls_verify: false # игнорировать проверку доверия для URL API (не требуется при наличии kubeconfig_path)
namespace: my-evta-namespace # наименование проекта в openshift/k8s
gateway_operator_crd:
# Наименование деплоймента. Результат: sharedgatewayoperator-example
#name: example
crd:
install: 'true'
Примеры заполненного файла vars.yml EVTA (оператора)#
Базовый файл#
namespace: operator-test # наименование проекта в openshift
skip_tls_verify: true
kubeconfig_path: "{{ inventory_dir }}/kube-config-da" # путь до файла kubeconfig (может быть зашифрован через ansible-vault)
gateway_operator:
# Наименование деплоймента. Результат: sharedgatewayoperator-example
name: test-gateway
# Тип установки kubernetes или openshift
kubernetesInstall: true
# Адрес репозитория артефактов
registry: "Registry_address"
# Путь к образу репозитория артефактов
registry_path: "registry_path"
# Признак монтирования токена для работы с KubeAPI. Если установлено false, то токен будет примонтирован автоматически. Если true — токен будет примонтирован в рамках Deployment.
projectedKubeAPI: false
# Количество репликаций
replicaCount: 1
# Пользовательские метки
labels: {}
# Пользовательские аннотации
annotations: {}
# Название секрета извлечения образа
imagePullSecrets: " example_imagePullSecrets"
kubernetesNamespacesWatched: [ "tests", "operator-tests"] # список пространств имен, за которыми следит оператор
serviceAccountName: "evta-operator" # Имя учетной записи сервиса
serviceAccount:
# Указывает, нужно ли создавать учетную запись сервиса
create: true
# Автоматически монтировать учетные данные API учетной записи ServiceAccount?
automount: true
roleType: Role
# Аннотации для добавления к учетной записи сервиса
annotations: { }
audit:
enabled: false
gateway_operator_crd:
# Наименование деплоймента. Результат: sharedgatewayoperator-example
name: test-gateway-crd
crd:
install: 'true'
Расширенный файл#
ansible_no_log: true # маскирование сенситивных сообщений в ansible
wait_for_start: 120 # время в секундах на старт приложения
#helm_cli: helm # путь до helm
#kubeconfig_path: /home/user/kubeconfig # путь до файла kubeconfig (может быть зашифрован через ansible-vault)
api_url: https://api.example.ru:6443 # URL API openshift/k8s (не требуется при наличии kubeconfig_path)
token: __PLACEHOLDER__ # токен пользователя (сервис аккаунта) для установки (не требуется при наличии kubeconfig_path)
skip_tls_verify: false # игнорировать проверку доверия для URL API (не требуется при наличии kubeconfig_path)
namespace: my-evta-namespace # наименование проекта в openshift/k8s
gateway_operator:
# Наименование деплоймента. Результат: sharedgatewayoperator-example
#name: example
# Тип установки kubernetes или openshift
kubernetesInstall: true
# Адрес репозитория артефактов
registry: ""
# Путь к образу репозитория артефактов
registry_path: ""
# Признак монтирования токена для работы с KubeAPI. Если установлено false, то токен будет примонтирован автоматически. Если true — токен будет примонтирован в рамках Deployment.
projectedKubeAPI: false
# Количество репликаций
replicaCount: 1
# Пользовательские метки
labels: {}
# Пользовательские аннотации
annotations: {}
# Название секрета извлечения образа
imagePullSecrets: ""
# Название класса приоритетов
priorityClassName: ""
# Пример переопределения дефолтных ресурсов
resources:
limits:
cpu: 300m
memory: 512M
requests:
cpu: 150m
memory: 256M
# Стратегия Rolling update
rollngUpdateMaxSurge: "25%" # максимальный выброс rolling update
rollingUpdateMaxUnavailable: "25%" # Максимально недоступно rolling update
kubernetesNiamespacesWatched: ["shared-gateway"] # список пространств имен, за которыми следит оператор
serviceAccountName: "shared-gateway-operator" # Имя учетной записи сервиса
serviceAccount:
# Указывает, нужно ли создавать учетную запись сервиса
create: true
# Автоматически монтировать учетные данные API учетной записи ServiceAccount?
automount: true
# Аннотации для добавления к учетной записи сервиса
annotations: {}
grpc: # grpc-сервер, запущенный на стороне оператора
port: 8089 # порт сервера grpc
retries:
count: 4 # количество повторных попыток
interval: 1000 # интервал между повторными попытками
multiplier: 2 # множитель для интервала между повторными попытками
healthcheck:
host: 0.0.0.0 # хост сервера healthcheck
port: 9000 # порт сервера healthcheck
audit:
enabled: false
# transport.type: http # Тип транспорта, http или kafka, по умолчанию http
#
# url.base: "http://ext-http.audit.example.ru" # Базовый URL аудит-сервиса
# url.event.path: "/v1/event" # URI аудита, на который будут отправляться события
# url.metamodel.path: "/v1/metamodel" # URI, на который будет отправляться метамодель
#
# ssl.enabled: false # Флаг, отвечающий за использование SSL
# ssl.keystore: ssl/keystore.jks # Путь до хранилища приватного ключа
# ssl.keystore.password: pass # Пароль от хранилища приватного ключа
# ssl.truststore: ssl/truststore.jks # Путь до хранилища доверенных сертификатов
# ssl.truststore.password: pass # Пароль от хранилища доверенных сертификатов
# ssl.protocol: TLSv1.2 # Версия протокола TLS
# verify.hostname: false # Верификация имени хоста аудита
#
# metamodel.topic: metamodel-topic # Имя топика для отправки метамодели
# event.topic: event-topic # Имя топика для отправки событий
#
# kafka.bootstrap.servers: localhost:9093 # Адреса Kafka
# kafka.client.id: audit-producer # Идентификатор клиента Kafka
# kafka.security.protocol: SSL # Протокол безопасности Kafka
# kafka.ssl.keystore.location: ssl/keystore.jks # Путь до хранилища приватного ключа Kafka
# kafka.ssl.keystore.password: password # Пароль от хранилища приватного ключа Kafka
# kafka.ssl.truststore.location: ssl/truststore.jks # Путь до хранилища доверенных сертификатов Kafka
# kafka.ssl.truststore.password: password # Пароль от хранилища доверенных сертификатов Kafka
# kafka.ssl.endpoint.identification.algorithm: # Алгоритм идентификации конечной точки Kafka
#
# metamodel.path: config/metamodel.yml # Путь до используемой метамодели
# metamodel.module: module.id # Переопределение модуля метамодели
# send.metamodel: true # Отправка метамодели в аудит при создании аудит-клиента
#
# redelivery.response.code.regex: (?:400.4|401|404|429|500|503.2) # Регулярное выражение для определения типа переотправки
# add.redelivery.headers: true # Добавление заголовков при переотправке событий
# redelivery.enabled: true # Включение переотправки событий
# redelivery.interval.ms: 60000 # Интервал попыток переотправки
# redelivery.initial.delay.ms: 60000 # Задержка перед первой попыткой переотправки
# redelivery.stop.on.error: true # Остановка попытки переотправки при первой ошибке
# redelivery.retries: -1 # Максимальное количество повторных попыток доставки (-1 для бесконечных попыток)
# # Неудачные запросы будут отправлены в первый по списку доступный буфер
# redelivery.buffers: kafka-buffer, file-buffer, memory-buffer, logger-fallback # Список буферов для хранения запросов при переотправке
#
# redelivery.kafka-buffer.type: kafka # Тип буфера Kafka
# redelivery.kafka-buffer.topic: audit-redelivery # Используемый топик Kafka
# redelivery.kafka-buffer.force.rebalance.on.start: true # Флаг принудительной перебалансировки группы Kafka при запуске
# redelivery.kafka-buffer.timeout.ms: 10000 # Общий тайм-аут для вычисления тайм-аутов Kafka-клиента
# redelivery.kafka-buffer.bootstrap.servers: localhost:9093 # Адреса Kafka для буфера
# redelivery.kafka-buffer.group.id: audit-redelivery-group # Идентификатор группы Kafka
#
# redelivery.file-buffer.type: file # Тип буфера файла
# redelivery.file-buffer.file.name: buffers/redelivery.txt # Используемый файл
# redelivery.file-buffer.file.permissions: rw-r--r-- # Права доступа к файлу при автоматическом создании
# redelivery.file-buffer.max.size: 100m # Максимальный размер буфера
# redelivery.file-buffer.encryption.enabled: true # Включение шифрования событий
# redelivery.file-buffer.encryption.class: ru.sbt.ss.password.BaseEncryptor # Класс шифрования
# redelivery.file-buffer.encryption.encrypt.key: file:path/to/key.txt # Ключ шифрования
# redelivery.file-buffer.encryption.encrypt.algorithm: PBEWithHmacSHA512AndAES_256 # Алгоритм шифрования
#
# redelivery.memory.type: queue # Тип буфера очереди в памяти
# redelivery.memory-buffer.max.size: 100m # Максимальный размер буфера
# redelivery.memory-buffer.clear.logger.name: ClearLogger # Имя логгера для удаления старых событий
#
# redelivery.logger-fallback.type: logger # Тип буфера логгера
# redelivery.logger-fallback.logger.name: LoggerRequestBuffer # Имя логгера
#
# dead.letter.enabled: false # Включение dead-letter буферов
#
# request.timeout.ms: 10000 # Тайм-аут отправки запроса аудита
# stop.timeout.ms: 10000 # Тайм-аут остановки для буферов повторной доставки
#
# thread.pool.min.size: 2 # Минимальное количество потоков аудит-клиента
# thread.pool.max.size: 10 # Максимальное количество потоков аудит-клиента
# thread.pool.keep.alive.ms: 60000 # Время жизни неиспользуемых потоков
# thread.pool.name.prefix: audit-client # Префикс имен потоков для основного пула
# http.thread.pool.name.prefix: audit-http-client # Префикс имен потоков для дополнительного пула HTTP-клиента
# use.legacy.thread.pool: false # Использование старого thread-pool с неограниченным количеством потоков
# thread.pool.max.async.requests: 100000 # Максимальное количество запросов, хранящихся в очереди на асинхронную обработку
Установка компонента EVTA с помощью оператора#
1. Настройка конфигурационных файлов vars.yaml для манифестов и оператора EVTA#
Настройте конфигурационные файлы vars.yaml для манифестов и оператора EVTA. Примеры заполненных файлов vars.yml приведены подробнее в подразделе «Примеры заполненных файлов vars.yml для манифестов и оператора EVTA».
2. Создание манифестов#
Необходимо создать CRD для следующих ресурсов:
SynapseEvtaGateway;SynapseEvtaPublication;SynapseEvtaSubscription.
Для создания данных CRD ресурсов с помощью Jenkins используйте задание Jenkins по установке EVTA (название задания Jenkins задается при создании задания, например, может быть задано как «reactive_stream_adapter_os»). Процесс создания задания Jenkins «reactive_stream_adapter_os» приведен в разделе Подготовка окружения EVTA, подраздел «Создание Jenkins Job для автоматической установки EVTA».
Запустите задание Jenkins для установки с помощью пункта меню Собрать с параметрами.
Выберите playbook gateway_operator_crd.yml.
Нажмите кнопку Собрать.
Дождитесь окончания выполнения задания Jenkins.
3. Запуск установки оператора EVTA с помощью Jenkins#
Для запуска установки оператора EVTA с помощью Jenkins используйте задание Jenkins по установке EVTA (название задания Jenkins задается при создании задания, например, может быть задано как «reactive_stream_adapter_os»). Процесс создания задания Jenkins «reactive_stream_adapter_os» приведен в разделе Подготовка окружения EVTA, подраздел «Создание Jenkins Job для автоматической установки EVTA».
Запустите задание Jenkins для установки с помощью пункта меню Собрать с параметрами.
Выберите playbook gateway_operator.yml.
Нажмите кнопку Собрать.
Дождитесь окончания выполнения задания Jenkins.
Проверьте работоспособность сервиса:
убедиться, что установка завершена без ошибок;
убедиться, что в логах pod нет информации об ошибках.
4. Запуск компонента EVTA с помощью Jenkins#
Для автоматического запуска компонента EVTA необходимо в namespace (за которым следит оператор EVTA) добавить заполненные ресурсы согласно ранее созданным CRD. Примеры заполненных ресурсов SynapseEvtaGateway, SynapseEvtaPublication и SynapseEvtaSubscription приведены в подразделе «Описание оператора EVTA».