Руководство по установке#

В настоящем документе приведены инструкции по установке компонента JDBC Gateway (код JDBC), далее — JDBC Gateway, из состава программного продукта Platform V Synapse Enterprise Integration (код SEI).

Термины и определения#

Термин/Аббревиатура

Определение

Deployment

Файл, содержащий набор инструкций для запуска приложения в Kubernetes

Pod

Абстрактный объект, набор контейнеров в архитектуре Kubernetes

Liveness-проба

Программный зонд для определения живучести контейнера

Лимит

Максимальный объем ресурсов, который выдается на работу приложения

Реквест

Объем ресурсов, который необходим для запуска приложения

БД

База данных

URL

Uniform Resource Locator, унифицированный указатель ресурса

CPU

Central Processing Unit, центральный процессор

RAM

Random Access Memory, оперативная память

SVPX

Компонент Сервисный прокси Продукт Platform V Synapse Service Mesh (SSM). Применение сетевых политик кластера для внутренних взаимодействий

LOGA

Компонент Журналирование Продукт Platform V Monitor (OPM). Извлечение записей журнала JDBC Gateway и передача их в подсистему журналирования

MONA

Компонент Мониторинг Продукт Platform V Monitor (OPM). Объединенный мониторинг Unimon (prometheus)

PSQL

Компонент Platform V Pangolin Продукт Platform V Pangolin SE (PSQ). Система управления базами данных, основанная на PostgreSQL

AUDT

Компонент Platform V Audit Продукт Platform V Audit SE (AUD). Сервис для аудирования событий.

HashiCorp Vault

HashiCorp Vault реализует безопасное хранилище секретной информации

Назначение документа#

Настоящий документ содержит руководство по установке Компонента «JDBC Gateway» программного продукта Platform V Synapse Enterprise Integration (далее так же «JDBC Gateway»), который предоставляет облачным приложениям возможность вызова процедур, хранящихся во внешней БД.

Важно!

Компонент «JDBC Gateway» поставляется в виде собранного Docker-образа, размещаемого в целевом Docker-репозитории, и предназначен для использования в составе прикладных интеграционных решений, разрабатываемых продуктовыми командами.

Для этого команды, реализующие прикладную интеграцию, выпускают дистрибутив, содержащий набор конфигурационных артефактов Kubernetes, обеспечивающих развертывание и настройку отдельного экземпляра JDBC Gateway под требования этой интеграции.

Компонент «JDBC Gateway» не предназначен для самостоятельной эксплуатации вне рамок прикладных интеграционных решений.

Системные требования#

Настройки безопасности окружения и перечень платформенных (дополнительных внешних) продуктов, используемых для установки, настройки и контроля в конечной информационной системе (далее — ИС), выбираются клиентом при разработке конечной ИС, исходя из характера обрабатываемой в ней информации и иных требований информационной безопасности (далее — ИБ), предъявляемых к ней.

Системное программное обеспечение#

Ниже представлены категории системного программного обеспечения (далее — ПО), которые обязательны или опциональны для установки, настройки, контроля и функционирования компонента. В каждой категории перечислены все поддерживаемые продукты сторонних правообладателей. Отдельно обозначены варианты, которые рекомендует АО «СберТех» (маркировка «Рекомендовано» в столбце «Продукт, функциональная совместимость с которым подтверждена»). Клиенту необходимо выбрать один из продуктов в каждой категории, исходя из условий использования конечной ИС.

Категория ПО

Обязательность установки (да/нет)*

Наименование ПО

Версия

Продукт, функциональная совместимость с которым подтверждена**

Описание

Операционная система

Да

Alt Linux SP8

10

Рекомендовано. Правообладателем АО «СберТех» также рекомендована ОС – Platform V SberLinux OS Server, см. раздел «Платформенные зависимости»

ОС контейнеров для запуска модулей компонента

Red Hat Enterprise Linux

8

Опционально

Среда контейнеризации

Да

Kubernetes

1.19 и выше

Рекомендовано. Правообладателем АО «СберТех» также рекомендована среда контейнеризации – Platform V DropApp, см. раздел «Платформенные зависимости»

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

Red Hat OpenShift

4.2 и выше

Опционально

Инструмент контейнеризации

Да

Docker CE

19.03.14 и выше

Рекомендовано

Инструмент для автоматизации работы с контейнерами

Java-машина

Да

OpenJDK

11

Рекомендовано

Набор программного обеспечения, позволяющий запускать программы написанные на JVM совместимых языках

Система управления базами данных (СУБД)

Да

PostgreSQL

4.6.0

Рекомендовано. Правообладателем АО «СберТех» также рекомендована СУБД, основанная на PostgreSQL – Platform V Pangolin SE, см. раздел «Платформенные зависимости»

ПО, взаимодействующее с конечными пользователями, приложениями и базой данных для сбора и анализа данных

Oracle Database

19с

Опционально

Система, реализующее безопасное хранилище секретной информации

Нет

HashiCorp Vault

2.0

Рекомендовано

Инструмент с открытым исходным кодом, который обеспечивает безопасное хранение и доступ к различным секретам (паролям, сертификатам, токенам)

Сервис интеграции и оркестрации микросервисов в облаке

Да

Istio

1.6 и выше

Рекомендовано. Правообладателем АО «СберТех» также рекомендован сервис интеграции и оркестрации микросервисов в облаке, основанный на Istio – Platform V Synapse Service Mesh, см. раздел «Платформенные зависимости»

Сервис интеграции микросервисов в облаке

Сервис централизованного хранения репозиториев артефактов (хранилище артефактов)

Да

Nexus-public

3.42.0

Рекомендовано

Хранилище образов

Примечание:

*

  • Да — категория ПО обязательна для функционирования сервиса (это означает, что сервис не может выполнять свои основные функции без установки данной категории ПО).

  • Нет — категория ПО необязательна для функционирования сервиса (это означает, что сервис может выполнять свои основные функции без установки данной категории ПО).

**

  • Рекомендовано — рекомендованный правообладателем АО «СберТех» продукт.

  • Опционально — альтернативный по отношению к рекомендованному правообладателем АО «СберТех» продукт.

Платформенные зависимости#

Для настройки, контроля и функционирования компонента реализована интеграция с программными продуктами, правообладателем которых является АО «СберТех»:

Наименование продукта

Код

Версия продукта

Код и наименование компонента

Обязательность установки (да/нет)***

Описание

Аналог других производителей****

Platform V SberLinux OS Core

SLC

9.2

CORE Базовая ОС

Да

ОС предназначена для безопасного развертывания сред контейнеризации с поддержкой масштабирования

ОС Альт 8 СП

Platform V SberLinux OS Server

SLO

8.7

INST Операционная система

Да

ОС контейнеров для запуска модулей компонента

ОС Альт 8 СП
Red Hat Enterprise Linux

Platform V DropApp

K8S

1.3

K8SC K8S Core

Да

Дистрибутив Kubernetes со встроенными механизмами мультитенантности и бессерверным исполнением

Kubernetes
Red Hat OpenShift Container Platform

Platform V Synapse Service Mesh

SSM

2.10 и выше

SVPX Сервисный прокси

Нет

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

Istio proxy 1.12

IGEG Граничный прокси

Нет

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

Platform V Pangolin SE

PSQ

5.1.0

PSQL Platform V Pangolin

Нет

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

PostgreSQL 11

Platform V Monitor

OPM

4.1

LOGA Журналирование

Нет

Сервис для хранения лог-файлов

Любой сервис сбора записей о событиях, совместимый с fluent-bit, например: Elasticsearch, InfluxDB

MONA Объединенный мониторинг Unimon

Нет

Сервис для сбора прикладных и инфраструктурных метрик и отправки их в целевую систему хранения

Prometheus 2.21.0

Если версия не указана, значит компонент будет работать с любой версией продукта.

Примечание:

***

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

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

**** Рекомендуется установка программного продукта, правообладателем которого является АО «СберТех», при этом не исключена возможность (допускается правообладателем) использования аналога других производителей. Аналоги, в отношении которых продукт успешно прошел испытания и подтвердил свою работоспособность, указаны в разделе «Системное программное обеспечение».

Аппаратные требования#

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

Тип стенда

DEV

ИФТ/ПСИ

НТ/ПРОМ

Конфигурация в среде контейнеризации (в рамках одного POD'а)

CPU: 250m

RAM: 256Mi

CPU: 500m

RAM: 700Mi

CPU: 700m

RAM: 700Mi

Состав дистрибутива#

Элемент дистрибутива

Описание

/documentation/

Документация на компонент

/package/bh/waitingSecrets.sh

Скрипт, исполняемый после старта docker контейнера

/package/bh/entrypoint.sh

Скрипт запуска приложения

/package/bh/org/springframework/boot/loader/

Загрузчик классов от spring boot, используется для запуска java приложения

/package/bh/BOOT-INF/lib/

Jar-бибилиотеки, зависимости, которые используются приложением

/package/bh/BOOT-INF/classpath.idx

Пути до бибилиотек с зависимостям

/package/bh/BOOT-INF/classes/

Все ресурсы java приложения, в том числе и классы

/package/bh/org/springframework/boot/loader/

Загрузчик классов от spring boot, используется для запуска java приложения

/package/ReleaseNotes.json

Метаинформация по дистрибутиву, формируемая сборщиком дистрибутива

/package/conf/

Конфигурация дистрибутива (примеры конфигурационных файлов, на основе которых необходимо описать целевую конфигурацию для промышленных стендов)

Выбор способа установки#

На данный момент поддерживается только ручная установка.

Подготовка окружения#

Для установки JDBC Gateway в составе прикладного дистрибутива должно быть выполнено следующее:

  1. Развернут и настроен кластер Kubernetes в соответствии с требованиями, предъявляемыми к Платформе.

  2. В кластере создан проект (namespace), в котором будет разворачиваться JDBC Gateway.

  3. В проекте создана учетная запись с правами на загрузку артефактов.

  4. Выпуск сертификатов для защищенного соединения с БД

  5. Docker-образ JDBC Gateway размещен в целевом Docker-репозитории по ссылке, указанной в конфигурационном артефакте Deployment.

  6. В проект добавлен Secret для загрузки Docker-образов из целевого Docker-репозитория.

  7. Подготовлен комплект настроенных конфигурационных артефактов.

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

  9. В БД созданы необходимые процедуры и к ним предоставлен соответствующий доступ.

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

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

При опциональном использовании совместно с JDBC Gateway Сайдкара компонента «Сервисный прокси» (SVPX) продукта «Platform V Synapse Service Mesh» (SSM) минимальные ресурсы, необходимые для запуска, следует уточнить в соответствующей документации используемого компонента.

Перечень программных продуктов, используемых при установке:

Наименование

Функции

Kubernetes

Подключение к проекту Kubernetes, загрузка артефактов конфигурации в проект в консольном режиме

Kubernetes

Подключение к проекту Kubernetes, загрузка артефактов конфигурации в проект в интерактивном режиме

Установка#

Ручная установка сервиса#

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

Для ручной установки сервиса выполните следующие действия:

Пререквизиты#

  1. Базовый образ для сборки docker image загружен в docker registry.

  2. Установлен клиент kubectl.

  3. Установлен docker.

Публикация базового образа#

  1. Загрузить образ из файла командой docker load

  2. Поставить тег полученному образу и залить в docker registry (командами docker tag, docker push)

Сборка образа из owned и party частей#

  1. Скачать party и owned дистрибутивы.

  2. Разархивировать party дистрибутив.

  3. Разархивировать owned дистрибутив и разархивировать архив в нем.

  4. Скопировать содержимое party дистрибутива в разархивированную owned часть по пути package/bh/BOOT-INF/lib.

  5. Перейти в терминале в директорию package/ дистрибутива owned.

  6. Скопировать в данную директорию dockerfile из package/conf/k8s/base/synapse-esb-database-adapter/Dockerfile и отредактировать его, указав путь до базового образа:

    cp conf/k8s/base/synapse-esb-database-adapter/Dockerfile .
    
  7. Выполнить сборку докер образа, предварительно авторизоваться в docker registry (командой docker login):

     docker build .
    
  8. Поставить тег полученному образу и залить в docker registry (командами docker tag, docker push)

Добавление скрипта ожидания в образ приложения#

В приложение добавляются скрипт ожидания секретов из HashiCorp Vault waitingSecrets.sh и скрипт entrypoint.sh с командой запуска приложения.

В DockerFile прописывается последовательность запуска скрипта (waitingSecrets.sh вызывает entrypoint.sh) и собирается новый образ приложения.
Пример DockerFile:

 FROM registry.****.*****.ru/base/redhat/openjdk/openjdk-11-rhel8:latest
  
 COPY jarName.jar jarName.jar
 COPY  ./src/main/resources/waitingSecrets.sh waitingSecrets.sh
 COPY  ./src/main/resources/entrypoint.sh entrypoint.sh
 ENTRYPOINT ["sh","waitingSecrets.sh"]

При запуске приложения сначала появится информация ожидания загрузки секретов из HashiCorp Vault, а затем после их успешной загрузки начнется запуск приложения.

 using /tmp/secman/config/secman.txt
 Secman config found
 Waiting for secrets:
 /deployments/config/db/certs/ca.crt
 /deployments/config/db/certs/cert.crt
 /deployments/config/db/certs/key.pk8
 file /deployments/config/db/certs/ca.crt exist
 file /deployments/config/db/certs/cert.crt exist
 file /deployments/config/db/certs/key.pk8 exist
 Waiting 1 s.
  
   .   ____          _            __ _ _
  /\\ / ___'_ __ _ _(_)_ __  __ _ \ \ \ \
 ( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
  \\/  ___)| |_)| | | | | || (_| |  ) ) ) )
   '  |____| .__|_| |_|_| |_\__, | / / / /
  =========|_|==============|___/=/_/_/_/
  :: Spring Boot ::                (v2.4.4)
  
 2022-05-31 15:42:56.295 [INFO ] [main] [com.sbt.synapse.Application] [T:] - Starting Application using Java 11.0.4 on service-db-module-857f66986-68lkt with PID 9 (/home/jboss/services-db-module-1.3.4.jar started by ? in /home/jboss)
 2022-05-31 15:42:56.381 [DEBUG] [main] [com.sbt.synapse.Application] [T:] - Running with Spring Boot v2.4.4, Spring v5.3.5
 2022-05-31 15:42:56.384 [INFO ] [main] [com.sbt.synapse.Application] [T:] - No active profile set, falling back to default profiles: default

Установка общих компонентов#

  1. Добавление к проекту механизмов ServiceMesh Kubernetes/Istio

        kubectl label namespace имя_неймспейса istio-injection=enabled
    
  2. Для установки Компонента «Сервисный прокси» (SVPX) продукта «Platform V Synapse Service Mesh» (SSM) нужно отредактировать deployment dc.yaml по пути package/conf/k8s/base/synapse-esb-database-adapter, и заполнить необходимые переменные:

    jdbc.istio.enabled - включение/отключение контейнера Компонента «Сервисный прокси» (например, true/false)
    jdbc.ose.deployment.metadata.annotations.sidecar.istio.io.proxyCPU - cpu request для контейнера Компонента «Сервисный прокси» (например, 500m)
    jdbc.ose.deployment.metadata.annotations.sidecar.istio.io.proxyCPULimit - cpu limit для контейнера Компонента «Сервисный прокси» (например, 500m)
    jdbc.ose.deployment.metadata.annotations.sidecar.istio.io.proxyMemory - memory request для контейнера Компонента «Сервисный прокси» (например, 512m)
    jdbc.ose.deployment.metadata.annotations.sidecar.istio.io.proxyMemoryLimit - memory limit для контейнера Компонента «Сервисный прокси» (например, 512m)
    
  3. Для установки Компонента «Журналирование» (LOGA) нужно отредактировать конфигурационный файл deployment dc.yaml по пути package/conf/k8s/base/synapse-esb-database-adapter, вставив блок ниже:

    spec:
      volumes:
        - name: sendkafka 
          emptyDir: {}
        - name: filebeat-tmp
          emptyDir: {}
        - name: filebeat
          configMap:
            name: filebeat-jdbc
            defaultMode: 256
      containers:
        - name: filebeat
          image: <образ Компонента «Журналирование»>
          resources:
            limits:
              cpu: 200m
              memory: 200Mi
            requests:
              cpu: 100m
              memory: 100Mi
          volumeMounts:
            - name: sendkafka
              mountPath: /send
            - name: filebeat-tmp
              mountPath: /usr/share/filebeat/data/
            - name: filebeat
              readOnly: true
              mountPath: /usr/share/filebeat/filebeat.yml
              subPath: filebeat.yml
            - name: synapselogs
              mountPath: /opt/synapse/logs
          terminationMessagePath: /dev/termination-log
          terminationMessagePolicy: File
          imagePullPolicy: Always
          securityContext:
            runAsNonRoot: true
            readOnlyRootFilesystem: true
    

А также создать ConfigMap с конфигурацией:

   kind: ConfigMap
   apiVersion: v1
   metadata:
      name: filebeat-jdbc
   data:
      filebeat.yml: |-
         filebeat.inputs:
           - type: log
             enabled: true
             close_removed: true
             close_inactive: 2m
             tail_files: true
             scan_frequency: 1s
             max_bytes: 1000000000
             paths:
               - /opt/synapse/logs/*.log

         output.logstash:
           hosts: ["logstash-jdbc-service:5055"]
           loadbalance: true

         filebeat.shutdown_timeout: 10s
         logging.level: error
         logging.metrics.enabled: true
  1. Для установки Компонента HashiCorp Vault нужно отредактировать deployment dc.yaml по пути package/conf/k8s/base/synapse-esb-database-adapter, и заполнить необходимые переменные:

    jdbc.secman.enabled - подключить сайдкар Secman (например, true)
    jdbc.ose.deployment.spec.template.metadata.annotations.vault.hashicorp.com.log-level - уровень логирования для HashiCorp Vault (например, info)
    jdbc.ose.deployment.spec.template.metadata.annotations.vault.hashicorp.com.namespace - имя созданного хранилища в HashiCorp Vault (например, DEV_DZO)
    jdbc.ose.deployment.spec.template.metadata.annotations.vault.hashicorp.com.role - имя полученной роли в HashiCorp Vault (например, role-ga-secman-syte)
    jdbc.secman.vault.path - путь до хранилища с секретами в HashiCorp Vault (например, A/IFT/FS/JDBC/KV/POSTGRES)
    jdbc.secman.vault.mount-path - путь для загрузки секретов в файловой системе Pod (например, /deployments/config/db)
    jdbc.ose.deployment.spec.template.metadata.annotations.vault.hashicorp.com.agent-limits-cpu - cpu limit для HashiCorp Vault (например, 250m)
    jdbc.ose.deployment.spec.template.metadata.annotations.vault.hashicorp.com.agent-limits-mem - memory limit для HashiCorp Vault (например, 128Mi)
    jdbc.ose.deployment.spec.template.metadata.annotations.vault.hashicorp.com.agent-requests-cpu - cpu request для HashiCorp Vault (например, 125m)
    jdbc.ose.deployment.spec.template.metadata.annotations.vault.hashicorp.com.agent-requests-mem - memory request для HashiCorp Vault (например, 64Mi)
    

А также отредактировать configmap-secman-mount.yaml по пути package/conf/k8s/base/configmaps/ заполнив параметр:

jdbc.prop.sslrootcertpath - путь к корневому сертификату (например, /deployments/config/db/ca.crt)
jdbc.prop.sslcertpath - путь к клиентскому сертификату (например, /deployments/config/db/cert.crt)
jdbc.prop.sslkeypath - путь к файлу клиентского ключа (например, /deployments/config/db/key.pk8)
jdbc.prop.dbsecretpath - путь к файлу с конфиденциальными данными, такими как пароль пользователя базы данных  (например, /deployments/config/db/db-secret.yml)
  1. Для интеграции с компонентом MONA продукта Platform V Monitor необходимо в конфигурацию deployment dc.yaml добавить следующие аннотации:

  annotations:
    prometheus.io.path: /actuator/prometheus        # контроллер, с которого собирать метрики
    prometheus.io.port: '8080'                      # порт, на котором доступен web server
    prometheus.io.scrape: 'true'                    # включание сбора метрик с помощью MONA

Установка сервера базы данных#

Установка сервера базы данных Postgres осуществляется по инструкции Руководство по установке Компонента «Platform V Pangolin» (PSQL) продукта «Platform V Pangolin SE». Для выпуска клиентского сертификата и ключа можно воспользоваться инструкцией Порядок создания хранилищ ключей и сертификатов для JDBC Gateway в Руководстве по безопасности. Создание серверного сертификата и ключа для базы данных описано в разделе Настройка базы данных в Руководстве по безопасности.

Установка JDBC Gateway#

  1. Отредактировать deployment dc.yaml по пути package/conf/k8s/base/synapse-esb-database-adapter, а также заполнить необходимые переменные:

    jdbc.ose.deployment.spec.replicas - количество реплик пода (например, 2)
    jdbc.ose.deployment.spec.strategy.rollingUpdate.maxUnavailable -  максимальное количество подов, которые могут быть недоступны при обновлении (например, 0)
    jdbc.ose.deployment.spec.strategy.rollingUpdate.maxSurge - максимальное количество подов, которое можно создать сверх желаемого количества подов (например, 25%)
    jdbc.ose.deployment.spec.template.spec.terminationGracePeriodSeconds - время, которое даётся приложению на корректную остановку (например, 50)
    jdbc.ose.deployment.spec.template.spec.priorityClassName - параметр, для управления приоритетом компонентов через механизм PriorityClass (например, '')
    jdbc.ose.deployment.spec.template.spec.containers.jdbc.resources.limits.cpu - cpu limit для контейнера приложения (например, 800m)
    jdbc.ose.deployment.spec.template.spec.containers.jdbc.resources.limits.memory - memory limit для контейнера приложения (например, 800Mi)
    jdbc.ose.deployment.spec.template.spec.containers.jdbc.resources.requests.cpu  - cpu request для контейнера приложения (например, 800m)
    jdbc.ose.deployment.spec.template.spec.containers.jdbc.resources.requests.memory - memory request для контейнера приложения (например, 800Mi)
    jdbc.ose.deployment.spec.template.spec.containers.jdbc.livenessProbe.failureThreshold - количество ошибочных запросов необходимых для провального прохождения liveness пробы (например, 5)
    jdbc.ose.deployment.spec.template.spec.containers.jdbc.livenessProbe.initialDelaySeconds - время инициализации liveness пробы в секундах (например, 60)
    jdbc.ose.deployment.spec.template.spec.containers.jdbc.livenessProbe.periodSeconds - частота запросов liveness пробы в секундах (например, 10)
    jdbc.ose.deployment.spec.template.spec.containers.jdbc.livenessProbe.successThreshold - количество успешных запросов необходимых для успешного прохождения liveness пробы (например, 1)
    jdbc.ose.deployment.spec.template.spec.containers.jdbc.livenessProbe.timeoutSeconds - таймаут в секундах, за который приложение должно ответить по запросу liveness пробы (например, 10)
    jdbc.ose.deployment.spec.template.spec.containers.jdbc.readinessProbe.failureThreshold - количество ошибочных запросов необходимых для провального прохождения readiness пробы (например, 5)
    jdbc.ose.deployment.spec.template.spec.containers.jdbc.readinessProbe.initialDelaySeconds - время инициализации readiness пробы в секундах (например, 60)
    jdbc.ose.deployment.spec.template.spec.containers.jdbc.readinessProbe.periodSeconds - частота запросов readiness пробы в секундах (например, 10)
    jdbc.ose.deployment.spec.template.spec.containers.jdbc.readinessProbe.successThreshold - количество успешных запросов необходимых для успешного прохождения readiness пробы (например, 1)
    jdbc.ose.deployment.spec.template.spec.containers.jdbc.readinessProbe.timeoutSeconds - таймаут в секундах, за который приложение должно ответить по запросу readiness пробы (например, 10)
    jdbc.ose.configmap.javaArguments - параметры запуска JVM (например, -Xms1000m -Xmx1000m -XX:+UseG1GC -XX:+ExitOnOutOfMemoryError)
    registry - хост docker registry (например, dzo.sw.sbc.space)
    registry_path - путь docker registry до образа  (например, /sbt_dev/ci90000017_synapse_dev)
    distrib.release.version - версия дистрибутива (например, v1)
    
  2. Также в файле dc.yaml в поле image указать тег образа, полученный на шаге 8 этапа сборки.

  3. Отредактировать configmap-service-db-module.yaml по пути package/conf/k8s/base/configmaps/ заполнив параметр:

    jdbc.threadpool.maxconcurrentconsumers - максимальное количество потоков обработки gRPC-запросов, которое может использовать сервер (например, 20)
    jdbc.threadpool.concurrentconsumers - количество потоков обработки gRPC-запросов при старте сервера (например, 5)
    jdbc.logs.enabled - логический параметр, отвечающий за журналирование IN/OUT-параметров, передаваемых и получаемых из хранимых процедур (например, false)
    jdbc.datasource.dburl - адрес базы данных (например, jdbc:postgresql://<host>:<port>/<database>)
    jdbc.datasource.maxpoolsize - # максимальное количество подключений в пуле базы данных (например, 20)
    jdbc.debug.enabled - логический параметр, отвечающий за включение уровня логирования типа debug для jvm (например, false)
    jdbc.prop.tlsprotocol - требуемая версия TLS протокола JVM (например, TLSv1.2)
    jdbc.prop.cipherSuites - требуемый алгоритм шифрования JVM (например, TLS_DHE_RSA_WITH_AES_256_GCM_SHA384)
    jdbc.prop.ssl - логический параметр, отвечающий за включение ssl соединения (например, true)
    jdbc.datasource.username - имя пользователя базы данных (например, postgres)
    jdbc.prop.sslmode- метод аутентификации при заданном параметре ssl: true (например, verify-full)
    jdbc.prop.sslhostnameverifier - проверка всего DN серверного сертиката, работает при sslmode=verify-full (например, com.sbt.synapse.dnverify.DnHostnameVerifier)
    jdbc.prop.sslalloweddn - разрешенный список DN серверных сертификатов в формате строки, работает при значении sslhostnameverifier=com.sbt.synapse.dnverify.DnHostnameVerifier (например, 'CN=10.xx.xx.xx, O=xxxx, C=RU;CN=hostname.ru, O=xxxx, C=RU')
    jdbc.prop.dnmaxcount - параметр, указывающий максимальное количество разрешенных DN (например, 2)
    jdbc.prop.sslrootcertpath - путь к корневому сертификату (например, /deployments/config/db/ca.crt)
    jdbc.prop.sslcertpath - путь к клиентскому сертификату (например, /deployments/config/db/cert.crt)
    jdbc.prop.sslkeypath - путь к файлу клиентского ключа (например, /deployments/config/db/key.pk8)
    jdbc.prop.dbsecretpath - путь к файлу с паролем пользователя или других конфидециальных данных ( например, /deployments/config/db/db-secret.yml)
    jdbc.crypto.enabled - логический параметр, отвечающий за включение/выключение поддержки шифрования (например, true)
    jdbc.crypto.keyExpirationHours - интервал обновления симметричного ключа в часах (например, 24)
    jdbc.crypto.keySize - размер симметричного ключа в битах (например, 256)
    jdbc.crypto.asymmetricAlgorithmName - алгоритм ассиметричного шифрования (например, RSA)
    jdbc.crypto.asymmetricMode - режим ассиметричного шифрования (например, ECB)
    jdbc.crypto.asymmetricPadding - схема заполнения для ассиметричного шифрования (например, PKCS1Padding)
    jdbc.crypto.symmetricAlgorithmName - алгоритм симметричного шифрования (например, AES)
    jdbc.crypto.symmetricMode - режим симметричного шифрования (например, GCM)
    jdbc.crypto.symmetricPadding - схема заполнения для ассиметричного шифрования (например, NoPadding)
    jdbc.crypto.provider - крипто провайдер (например, BC)
    jdbc.crypto.returnAsIsOnError - если true и при расшифровке сообщения возникнет ошибка JDBC Gateway вернет сообщение в исходном виде, если он равен false, то при возникновении ошибки выбросит exception и обработка сообщения прекратится
    jdbc.crypto.secman.role - роль Secman в кластере (например, role-ga-secman-syte)
    jdbc.crypto.secman.vaultaddr - стенд Secman (например, secman-dzo.solution.sbt:8443)
    jdbc.crypto.secman.osaddr - стенд кластера (например, stands-vdc01.solution.sbt)
    jdbc.crypto.secman.vaultpath - путь в Secman, где лежат сертификаты шифратора (Ключи в секрете должны быть названы pem и key) (например, A/IFT/FS/JDBC/KV/POSTGRESCYPHER)
    jdbc.crypto.secman.vaultns - имя хранилища в Secman (например, DEV_DZO)
    
  4. Отредактировать synapse-esb-adapter-se.yaml по пути package/conf/k8s/base/istio/config/egress, а также заполнить необходимые переменные:

    jdbc.ose.istio.endpoint.enable - включение указания ip базы данных (например, true)
    jdbc.ose.istio.endpoint - ip базы данных (например, 10.xx.xx.xx)
    jdbc.ose.istio.databasehost - имя хоста базы данных (например, ignite)
    jdbc.ose.istio.egress.databaseport - порт базы данных (например, 5432)
    
  5. Установить компоненты, необходимые для работы адаптера (kubectl apply -f <имя компонента>):

    • Deployment;

    • Service;

    • ServiceEntry с точками подключения к серверам БД;

    • ConfigMap с настройками JDBC Gateway;

    • ConfigMap с параметрами вызова процедур/функций в базе данных;

    • ConfigMap со списком секретов, которые нужно ждать из HashiCorp Vault;

     kubectl apply -f conf/k8s/base/configmaps/configmap-entity.yaml
     kubectl apply -f conf/k8s/base/configmaps/configmap-secman-mount.yaml
     kubectl apply -f conf/k8s/base/configmaps/configmap-service-db-module.yaml
     kubectl apply -f conf/k8s/base/istio/config/egress/synapse-esb-adapter-se.yaml
     kubectl apply -f conf/k8s/base/synapse-esb-database-adapter/dc.yaml
     kubectl apply -f conf/k8s/base/synapse-esb-database-adapter/svc.yaml
     kubectl apply -f conf/k8s/base/empty-service/svc.yaml
    

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

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

Интеграция с продуктом Platform V Pangolin SE производится через компонент Platform V Pangolin (PSQL) путем конфигурирования параметра jdbc.datasource.dburl в 3 шаге подраздела "Установка JDBC Gateway", подробнее описано в инструкции "Руководство по установке". Интеграция с продуктом Platform V Monitor производится через компонент Журналирование (LOGA), процесс конфигурации описан в документации на этот компонент "Руководство по установке". Интеграция с продуктом Platform V Synapse Service Mesh производится компонент Сервисный прокси (SVPX) в автоматическом режиме после подключения проекта в контрольной панели Synapse Service Mesh, подробности описаны в документации на это компонент. Интеграция с HashiCorp Vault производится путем конфигурирования параметров в разделе "Установка общих компонентов", детальнее можно ознакомится в документации на этот компонент, и в нижеследующем разделе Интеграция JDBC Gateway с HashiCorp Vault. Интеграция с продуктом Platform V Audit SE производится путем конфигурирования параметров в разделе "Установка общих компонентов", детальнее можно ознакомится в документации на этот компонент, и в нижеследующем разделе Интеграция JDBC Gateway с АС Аудит.

Интеграция JDBC Gateway с HashiCorp Vault#

Пререквизиты:

  • создано хранилище в HashiCorp Vault;

  • в хранилище загружены секреты (подробнее в разделе Хранение секретов в Secret Management в Руководстве по безопасности);

  • получена роль HashiCorp Vault на данное хранилище;

  • выдан доступ к данному хранилищу HashiCorp Vault на проект, в который устанавливается Deployment;

Интеграция JDBC Gateway с HashiCorp Vault для базы Postgres#
  1. Для интеграции необходимо отредактировать Deployment, добавив следующие аннотации:

    Настройка Deployment для интеграции с HashiCorp Vault

    spec:
      template:
        metadata:
          annotations:
            vault.hashicorp.com/agent-inject: 'true'                        # включить sidecar HashiCorp Vault
            vault.hashicorp.com/namespace: <NAMESPACE_VAULT>                # имя созданного хранилища в HashiCorp Vault (например, CI01994970_CI02129749)
            vault.hashicorp.com/role: <SECMAN_ROLE>                         # имя полученной роли в HashiCorp Vault (например, ci01994970_ci02129749_a_snps_osh_ift_ac)
            vault.hashicorp.com/secret-volume-path: <SECMAN_MOUNT_PATH>     # путь для загрузки секретов в файловой системе Pod (например, /deployments/config/db/certs)
            vault.hashicorp.com/agent-inject-secret-cert.crt: 'true'        # включить чтение секрета cert.crt
            vault.hashicorp.com/agent-inject-template-cert.crt: |           # создается файл cert.crt в файловой системе
              {{- with secret <SECRET_PATH> -}}                             # путь до секрета в HashiCorp Vault (например, CI01994970_CI02129749/A/SNPS/OSH/IFT/KV/JDBC)
              {{ base64Decode .Data.cert }}                                 # значение из HashiCorp Vault по ключу cert, переведенное из base64
              {{- end }}                                                                                               
            vault.hashicorp.com/agent-inject-secret-ca.crt: 'true'          # включить чтение секрета ca.crt
            vault.hashicorp.com/agent-inject-template-ca.crt: |             # создается файл ca.crt
              {{- with secret <SECRET_PATH> -}}                             # путь до секрета в HashiCorp Vault (например, CI01994970_CI02129749/A/SNPS/OSH/IFT/KV/JDBC)
              {{ base64Decode .Data.ca }}                                   # значение из HashiCorp Vault по ключу ca, переведенное из base64
              {{- end }}
            vault.hashicorp.com/agent-inject-secret-key.pk8: 'true'         # включить чтение секрета key.pk8
            vault.hashicorp.com/agent-inject-template-key.pk8: |            # создается файл key.pk8 в файловой системе
              {{- with secret <SECRET_PATH> -}}                             # путь до секрета в HashiCorp Vault (например, CI01994970_CI02129749/A/SNPS/OSH/IFT/KV/JDBC)
                {{ base64Decode .Data.key }}                                # значение из HashiCorp Vault по ключу key, переведенное из base64
              {{- end }}
            vault.hashicorp.com/agent-inject-secret-db-secret.yml: 'true'   # включить чтение секрета db-secret.yml
            vault.hashicorp.com/agent-inject-template-db-secret.yml: |      # создается файл db-secret.yml
              {{- with secret <SECRET_PATH> -}}                             # путь до секрета (например, CI01994970_CI02129749/A/SNPS/OSH/IFT/KV/JDBC)
              {{ base64Decode .Data.secret }}                               # значение из HashiCorp Vault по ключу db-secret.yml, переведенное из base64
              {{- end }}
        spec:
          volumes:
            - name: db-postgre-secman # новая ConfigMap со списком секретов, которые нужно ждать
              configMap:
                name: db-postgre-secman
                items:
                  - key: secman.txt
                    path: secman.txt
                defaultMode: 256
          containers:
            - volumeMounts:
                - name: db-postgre-secman # новая ConfigMap со списком секретов, которые нужно ждать
                  readOnly: true
                  mountPath: /tmp/secman/config
    
  2. Добавить в ConfigMap, в котором прописываются настройки подключения к базе данных, пути до сертификатов:

ConfigMap с настройками подключения к базе данных

 kind: ConfigMap
 apiVersion: v1
 metadata:
    name: service-db-module-app-config
 data:
    application.yml: |-
       ...
       ds:
         prop:
           sslrootcert: /deployments/config/db/certs/ca.crt
           sslcert: /deployments/config/db/certs/cert.crt
           sslkey: /deployments/config/db/certs/key.pk8
  1. Добавить ConfigMap, в котором прописывается список файлов, загружаемых в Pod из HashiCorp Vault:

ConfigMap со списком загружаемых файлов из HashiCorp Vault

  kind: ConfigMap
  apiVersion: v1
  metadata:
     name: db-postgre-secman
  data:
     secman.txt: |-
        /deployments/config/db/certs/ca.crt     # указывается путь, который мы указали в аннотации vault.hashicorp.com/secret-volume-path
        /deployments/config/db/certs/cert.crt
        /deployments/config/db/certs/key.pk8
        /deployments/config/db/db-secret.yml

После этого в файловой системе Pod должны примонтироваться сертификаты. Чтобы проверить их наличие, можно выполнить команду:

Пример проверки загрузки секретов из HashiCorp Vault в файловую систему Pod

 ls -a /deployments/config/db/certs/
Интеграция JDBC Gateway с HashiCorp Vault для базы Oracle#
  1. Для интеграции необходимо отредактировать Deployment, добавив следующие аннотации:

    Настройка Deployment для интеграции с HashiCorp Vault

    spec:
      template:
        metadata:
          labels:
            secman-injector: enabled                                        # включить sidecar HashiCorp Vault
          annotations:
            vault.hashicorp.com/agent-inject: 'true'                        # включить sidecar HashiCorp Vault
            vault.hashicorp.com/namespace: <NAMESPACE_VAULT>                # имя созданного хранилища в HashiCorp Vault (например, CI01994970_CI02129749)
            vault.hashicorp.com/role: <SECMAN_ROLE>                         # имя полученной роли в HashiCorp Vault (например, ci01994970_ci02129749_a_snps_osh_ift_ac)
            vault.hashicorp.com/secret-volume-path: <SECMAN_MOUNT_PATH>     # путь для загрузки секретов в файловой системе Pod (например, /deployments/config/db/certs)
            vault.hashicorp.com/agent-inject-secret-keystore.jks: 'true'    # включить чтение секрета keystore.jks
            vault.hashicorp.com/agent-inject-template-keystore.jks: |       # создается файл keystore.jks
              {{- with secret <SECRET_PATH> -}}                             # путь до секрета (например, CI01994970_CI02129749/A/SNPS/OSH/IFT/KV/JDBC)
              {{ base64Decode (index .Data "keystore.jks") }}               # значение из HashiCorp Vault по ключу keystore.jks, переведенное из base64
              {{- end }}
            vault.hashicorp.com/agent-inject-secret-truststore.jks: 'true'  # включить чтение секрета truststore.jks
            vault.hashicorp.com/agent-inject-template-truststore.jks: |     # создается файл truststore.jks
              {{- with secret <SECRET_PATH> -}}                             # путь до секрета (например, CI01994970_CI02129749/A/SNPS/OSH/IFT/KV/JDBC)
              {{ base64Decode (index .Data "truststore.jks") }}             # значение из HashiCorp Vault по ключу truststore.jks, переведенное из base64
              {{- end }}
            vault.hashicorp.com/agent-inject-secret-db-secret.yml: 'true'   # включить чтение секрета db-secret.yml
            vault.hashicorp.com/agent-inject-template-db-secret.yml: |      # создается файл db-secret.yml
              {{- with secret <SECRET_PATH> -}}                             # путь до секрета (например, CI01994970_CI02129749/A/SNPS/OSH/IFT/KV/JDBC)
              {{ index .Data "db-secret.yml" }}                             # значение из HashiCorp Vault по ключу db-secret.yml
              {{- end }}                    
        spec:
          volumes:
            - name: db-oracle-secman 										# новая ConfigMap со списком секретов, которые нужно ждать
              configMap:
                name: db-oracle-secman
                items:
                  - key: secman.txt
                    path: secman.txt
                defaultMode: 256
          containers:
            - volumeMounts:
                - name: db-oracle-secman 									# новая ConfigMap со списком секретов, которые нужно ждать
                  readOnly: true
                  mountPath: /tmp/secman/config
    
  2. Добавить в ConfigMap, в котором прописываются настройки подключения к базе данных, пути до сертификатов:

ConfigMap с настройками подключения к базе данных

 kind: ConfigMap
 apiVersion: v1
 metadata:
    name: service-db-module-app-config
 data:
    application.yml: |-
       ...
       ds:
         prop:
           oracle:
             net:
               ssl_server_dn_match: true
               ssl_cipher_suites: (TLS_DHE_RSA_WITH_AES_256_GCM_SHA384)
               authentication_services: (TCPS)
           javax:
             net:
               ssl:
                 trustStore: /deployments/config/db/certs/ewallet.jks
                 trustStorePassword: password
                 trustStoreType: JKS
                 keyStore: /deployments/config/db/certs/ewallet.jks
                 keyStorePassword: password
                 keyPassword: password
                 keyStoreType: JKS
  1. Добавить ConfigMap, в котором прописывается список файлов, загружаемых в Pod из HashiCorp Vault:

    ConfigMap со списком загружаемых файлов из HashiCorp Vault

  kind: ConfigMap
  apiVersion: v1
  metadata:
     name: db-oracle-secman
  data:
     secman.txt: |-
        /deployments/config/db/certs/ca.crt     							# указывается путь, который мы указали в аннотации vault.hashicorp.com/secret-volume-path
        /deployments/config/db/certs/cert.crt
        /deployments/config/db/certs/key.pk8
        /deployments/config/db/db-secret.yml

После этого в файловой системе Pod должны примонтироваться сертификаты. Чтобы проверить их наличие, можно выполнить команду:

Пример проверки загрузки секретов из HashiCorp Vault в файловую систему Pod

ls -a /deployments/config/db/certs/

Интеграция JDBC Gateway с АС Аудит#

Для интеграции с компонентом AUDT Аудит продукта Platform V Audit SE необходимо в ConfigMap заполнить параметры:

  audit:
    enabled: true                     # Регистрация событий аудита включена
    service:
      host: "http://audit"            # Url ТС Audit
      metamodel-route: "/metamodel"   # Endpoint для отправки метамодели
      event-route: "/event"           # Endpoint для отправки событий
    metamodel:
      version: v1                     # Версия метамодели
      module-id: JDBC                 # Код модуля Шлюза БД
      retry:
        max-attempts: 5               # Максимальное количество попыток отправки метамодели в аудит
        wait-duration: 3000           # Время между попытками в мс
    event:
      retry:
        max-attempts: 5               # Максимальное количество попыток отправки событий в аудит
        wait-duration: 3000           # Время между попытками в мс
    buffer:
      size: 10                        # Размер буфера событий
    listener:
      pool-size: 1                    # Размер пула сервиса, отправляющего события из буфера в аудит
      period: 2000                    # Период проверки буфера на наличие событий для отправки в аудит в мс

После этого нужно запустить Pod с новыми настройками. В логах Pod появятся сообщения вида "Метамодель успешно зарегистрировалась", "Отправка события аудита", "Ответ запроса на отправку аудита <201".

Ротация сертификатов#

Существует возможность включить механизм обновления сертификатов, полученных из HashiCorp Vault. Обновленные сертификаты и ключи монтируются в файловую систему JDBC Gateway и применяются в режиме runtime без прерывания основных функций JDBC Gateway. Для этого необходимо использовать PKI хранилище HashiCorp Vault, добавив аннотации в Deployment:

 annotations:
    vault.hashicorp.com/role: <SECMAN_ROLE>						# SECMAN_ROLE - роль в HashiCorp Vault
    vault.hashicorp.com/agent-init-first: 'true'					# запускать контейнер vault-agent первым
    vault.hashicorp.com/agent-pre-populate: 'false'					# отключение запуска init контейнера vault-agent
 vault.hashicorp.com/secret-volume-path: /deployments/config/db		# путь, куда монтировать сертификаты и ключ
    vault.hashicorp.com/agent-inject-template-check-root.crt: >				# запрос на генерацию корневого сертификата
       {{- with secret "<SECRET_PATH>/PKI/issue/<SECMAN_ROLE>"				# SECRET_PATH - путь до хранилища PKI
       "common_name=<GENERATED_COMMON_NAME>" "format=pem"  "ttl=8760h"		        # установка GENERATED_COMMON_NAME - СN клиентского сертификата, формата сертификата, времени обновления сертификата в часах
       "private_key_format=pkcs8"  -}} {{ .Data.issuing_ca }}  {{- end }}	        # установка формата приватного ключа
    vault.hashicorp.com/agent-inject-template-check-cert.crt: >				# запрос на генерацию клиентского сертификата
       {{- with secret "<SECRET_PATH>/PKI/issue/<SECMAN_ROLE>"
       "common_name=<GENERATED_COMMON_NAME>" "format=pem"  "ttl=8760h"
       "private_key_format=pkcs8"  -}} {{ .Data.certificate }}  {{- end }}
    vault.hashicorp.com/agent-inject-template-check-key.pk8: >
       {{- with secret "<SECRET_PATH>/PKI/issue/<SECMAN_ROLE>"
       "common_name=<GENERATED_COMMON_NAME>" "format=pem"   "ttl=8760h"
       "private_key_format=pkcs8" -}} {{
        (index .Data.private_key)}}  {{- end }}
    vault.hashicorp.com/agent-inject-template-db-secret.yml: |				# запрос на получение файла с конфиденциальными данными из хранилища KV
       {{- with secret "<SECRET_PATH_KV>" -}}						# SECRET_PATH_KV - путь до хранилища KV
       {{base64Decode (index .Data "secret") }}								
       {{- end }}
    vault.hashicorp.com/agent-inject-secret-check-root.crt: 'true'
    vault.hashicorp.com/agent-inject-secret-check-cert.crt: 'true'
 vault.hashicorp.com/agent-inject-secret-check-key.pk8: 'true'
    vault.hashicorp.com/agent-inject-secret-db-secret.yml: 'true'

Обновление#

Обновите все развернутые в окружении артефакты сервиса, кроме БД и информации в БД.

  1. Перед обновлением требуется сохранить бэкап предыдущей конфигурации:

    kubectl get deployment service-db-module > depl.yml
    kubectl get service service-db-module > svc.yml
    kubectl get service empty-service > svc_empty.yml
    kubectl get se db-service-entry > se.yml
    kubectl get configmap service-db-module-app-config > cm_app.yml
    kubectl get configmap db-postgre-secman > cm_secman.yml
    kubectl get configmap service-db-module-entity-config > cm_ent.yml
  1. Остановить JDBC Gateway:

kubectl scale --replicas=0 deployment/service-db-module`
  1. Удалить все предыдущие ресурсы JDBC Gateway:

    kubectl delete deployment service-db-module 
    kubectl delete service service-db-module 
    kubectl delete service empty-service 
    kubectl delete se db-service-entry 
    kubectl delete configmap service-db-module-app-config 
    kubectl delete configmap db-postgre-secman 
    kubectl delete configmap service-db-module-entity-config 
  1. Провести установку новой версии компонента по инструкции из раздела Установка. Чтение процедур и функций из базы данных новой версии JDBC Gateway начинается автоматически после его старта в Kubernetes.

Удаление#

Удалите все развернутые в окружении артефакты сервиса, кроме базы данных, сертификатов и ключей базы данных.

  1. Остановите JDBC Gateway:

С использованием веб-интерфейса

Шаг

Действия

Остановка JDBC Gateway

1. В меню выберите пункт Workload -> Deployments.
2. На странице найдите нужный Deployment (при необходимости воспользуйтесь поиском по имени).
3. Перейдите по ссылке в наименовании на вкладку Detail.
4. Стрелкой вниз (Decrease the pod count) уменьшите количество Pod JDBC Gateway до 0.

С использованием консоли

Шаг

Действия

Остановка JDBC Gateway

В консоли выполните команду
kubectl scale --replicas=0 deployment/<имя Deployment>

  1. Удалите артефакты действующей версии:

С использованием веб-интерфейса

Шаг

Действия

Удаление Deployment

1. В меню выберите пункт Workload -> Deployments.
2. На странице найдите нужный Deployment (при необходимости воспользуйтесь поиском по имени).
3. Перейдите по ссылке в наименовании на вкладку Detail.
4. Раскройте меню Action в правом верхнем углу окна, выберите пункт Delete Deployment.
5. В появившемся окне подтвердите действие.

Удаление конфигурации

1. В меню выберите пункт Workload -> Config Maps.
2. На странице найдите нужный артефакт (при необходимости воспользуйтесь поиском по имени).
3. Перейдите по ссылке в наименовании на вкладку Detail.
4. Раскройте меню Action в правом верхнем углу окна, выберите пункт Delete Config Map.
5. В появившемся окне подтвердите действие.

С использованием консоли

Шаг

Действия

Удаление Deployment

В консоли выполните команду:
kubectl delete deployment <имя Deployment>

Удаление конфигурации

В консоли выполните команду:
kubectl delete configmap <имя config map>

Проверка работоспособности#

С использованием веб-интерфейса

Шаг

Действие

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

1. В меню выберите пункт Workload → Pods.
2. На странице найдите нужный Pod JDBC Gateway.
3. Перейдите по ссылке в имени на вкладку Detail.
4. Перейдите на вкладку Terminal.
5. В терминале Pod выполните команду: curl localhost:<portnum>/actuator/health, где <portnum> — номер порта, указанный в параметре server/port конфигурации JDBC Gateway. В ответном сообщении должна быть строка: "ping":{"status":"UP"}

С использованием консоли

Шаг

Действие

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

1. В консоли задайте команду: kubectl port-forward pod/<имя Pod> <portnum>:<portnum>, где <portnum> — номер порта, указанный в параметре server/port конфигурации JDBC Gateway.
2. Запустите еще одно окно консоли и в нем выполните команду: curl localhost:<portnum>/actuator/health. В ответном сообщении должна быть строка: "ping":{"status":"UP"}.
3. Завершите перенаправление портов нажатием Ctrl+C

Шаги проверки работоспособности платформенных зависимостей и модулей компонента

Шаг

Проверка

Интеграция с HashiCorp Vault

1. В меню выберите пункт Workload → Pods.
2. На странице найдите нужный Pod JDBC Gateway.
3.Перейдите на вкладку Logs.
4. Перейдите в контейнер Secman (vault-agent) и убедитесь, что в журнале сообщений нет ошибок типа ERROR и секреты загружены по заданному пути.
5. Перейдите в Контейнер JDBC Gateway (service-db-module) и убедитесь, что он ожидает данные секреты и после загрузки секретов происходит запуск контейнера.

Интеграция с Сервисный прокси

1. В меню выберите пункт Workload → Pods.
2. На странице найдите нужный Pod JDBC Gateway.
3.Перейдите на вкладку Logs.
4. Перейдите в контейнер Сервисный прокси (istio-proxy) и убедитесь, что в журнале сообщений есть запись Envoy proxy is ready
5. Перейдите в Контейнер JDBC Gateway (service-db-module) и убедитесь, что он успешно подключается к базе данных без ошибок.

Интеграция с Агентом журналирования

1. В меню выберите пункт Workload → Pods.
2. На странице найдите нужный Pod JDBC Gateway.
3.Перейдите на вкладку Logs.
4. Перейдите в контейнер Агента журналирования (filebeat) и убедитесь, что в журнале сообщений нет ошибок типа ERROR и у контейнера есть доступ к файлу /opt/synapse/logs/*.log.

Интеграция с Platform V Pangolin

1. В меню выберите пункт Workload → Pods.
2. На странице найдите нужный Pod JDBC Gateway.
3.Перейдите на вкладку Logs.
4. Перейдите в контейнер JDBC Gateway (service-db-module) и убедитесь, что он успешно подключается к базе данных без ошибок.

Интеграция с АС Аудит

1. В меню выберите пункт Workload → Pods.
2. На странице найдите нужный Pod JDBC Gateway.
3.Перейдите на вкладку Logs.
4. Перейдите в контейнер JDBC Gateway (service-db-module) и убедитесь, что в логах есть записи вида "Метамодель успешно зарегистрировалась", "Отправка события аудита", "Ответ запроса на отправку аудита <201".

Интеграция с MONA Мониторинг

1. В меню выберите пункт Workload → Pods.
2. На странице найдите нужный Pod JDBC Gateway.
3.Перейдите на вкладку Logs.
4. Перейдите в контейнер JDBC Gateway (service-db-module) и выполните команду curl localhost:<portnum>/actuator/prometheus
5. В терминале пода JDBC Gateway service-db-module будут выведены мгновенные значения метрик мониторинга

Откат#

Релиз 4.2 совместим с версией 3.9. Версия 3.9 не поддерживает интеграцию с АС Аудит.

  1. Остановить JDBC Gateway:

kubectl scale --replicas=0 deployment/service-db-module`
  1. Удалить все предыдущие ресурсы адаптера:

    kubectl delete deployment service-db-module 
    kubectl delete service service-db-module 
    kubectl delete service empty-service 
    kubectl delete se db-service-entry 
    kubectl delete configmap service-db-module-app-config 
    kubectl delete configmap db-postgre-secman 
    kubectl delete configmap service-db-module-entity-config 
  1. Провести установку бэкапа по инструкции из раздела Установка.

Часто встречающиеся проблемы и пути их устранения#

Проблема

Причина

Решение

Ошибка при подключении к проекту

Пользователю не предоставлен доступ в проект

Запросите доступ к проекту

Ошибка при подключении к проекту

Нет физического доступа к кластеру

Зарегистрируйте обращение в поддержку для восстановления доступа

Ошибка при загрузке артефактов

У пользователя, от имени которого производится загрузка, отсутствуют необходимые права

Проверьте и скорректируйте настройку прав доступа пользователя

Ошибка при загрузке Docker-образа из репозитория

Отсутствуют права на загрузку образа из репозитория

Запросите права

Ошибка при загрузке Docker-образа из репозитория

Недоступен репозиторий

Зарегистрируйте обращение в поддержку для восстановления доступа

Ошибка при загрузке Docker-образа из репозитория

Неверная ссылка на имя образа Docker-контейнера в Deployment JDBC Gateway

Проверьте ссылку, при необходимости скорректируйте Deployment

Отсутствует подключение к БД

Установленная configmap является некорректной

Проверьте конфигурационные файлы, найдите и устраните опечатки

Не видны необходимые процедуры

Установленная configmap является некорректной

Проверьте конфигурационные файлы, найдите и устраните опечатки

Ошибка TCPS-подключения

Загруженные Secret некорректны

Проверьте конфигурационные файлы, найдите и устраните опечатки

Чек-лист валидации установки#

Для проверки валидности установки проверьте наличие всех установленных компонентов:

 kubectl get deployment service-db-module 
 kubectl get service service-db-module 
 kubectl get service empty-service 
 kubectl get se db-service-entry 
 kubectl get configmap service-db-module-app-config 
 kubectl get configmap db-postgre-secman 
 kubectl get configmap service-db-module-entity-config 

Все компоненты должны присутствовать в проекте и должна отсутствовать ошибка <<Error from server (NotFound)>>.

Чек-лист успешной настройки интеграции с платформенными зависимостями

Шаг

Проверка

Интеграция с HashiCorp Vault

1. В меню выберите пункт Workload → Pods.
2. На странице найдите нужный Pod JDBC Gateway.
3. Перейдите на вкладку Details.
4. В разделе Containers найдите контейнер Secman (vault-agent) и убедитесь, что он в статусе Running и нет рестартов контейнера.

Интеграция с Сервисный прокси

1. В меню выберите пункт Workload → Pods.
2. На странице найдите нужный Pod JDBC Gateway.
3. Перейдите на вкладку Details.
4. В разделе Containers найдите контейнер Сервисный прокси (istio-proxy) и убедитесь, что он в статусе Running и нет рестартов контейнера.

Интеграция с Агентом журналирования

1. В меню выберите пункт Workload → Pods.
2. На странице найдите нужный Pod JDBC Gateway.
3. Перейдите на вкладку Details.
4. В разделе Containers найдите контейнер Агента журналирования (filebeat) и убедитесь, что он в статусе Running и нет рестартов контейнера.

Интеграция с Platform V Pangolin

1. В меню выберите пункт Workload → Pods.
2. На странице найдите нужный Pod JDBC Gateway.
3. Перейдите на вкладку Logs.
4. Перейдите в контейнер JDBC Gateway (service-db-module) и убедитесь, что он успешно подключается к базе данных без ошибок.

Интеграция с Platform V Audit

1. В меню выберите пункт Workload → Pods.
2. На странице найдите нужный Pod JDBC Gateway.
3.Перейдите на вкладку Logs.
4. Перейдите в контейнер JDBC Gateway (service-db-module) и убедитесь, что есть записи об успешной регистрации метамодели и отправке событий в Аудит.

Интеграция с MONA Мониторинг

1. В меню выберите пункт Workload → Pods.
2. На странице найдите нужный Pod JDBC Gateway.
3.Перейдите на вкладку Logs.
4. Перейдите в контейнер JDBC Gateway (service-db-module) и выполните команду curl localhost:<portnum>/actuator/prometheus
5. В терминале пода JDBC Gateway service-db-module будут выведены мгновенные значения метрик мониторинга