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

О документе#

В руководстве приведены инструкции по установке компонента DS Lab (DSLB) (далее — DS Lab или компонент) продукта Platform V DataSpace (APT).

DS Lab — компонент, предоставляющий возможность описывать модель данных предметной области через UI и разворачивать модель в виде сервиса Platform V Dataspace для работы с этими данными: создание, изменение, удаление, объединение в транзакционные группы, гибкие возможности поиска и получения данных.

Расшифровку основных понятий см. в перечне "Терминов и определений".

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

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

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

Имеются следующие требования к ПО:

• На серверы приложений, использующих DataSpace, должна быть установлена среда контейнеризации Kubernetes, Red Hat OpenShift или аналогичная среда контейнеризации приложений.

• Наличие БД для модуля dataspace-core-meta в режиме Standby.

• Созданы и настроены два namespace в Kubernetes (или OpenShift):

  • namespace для клиентских сервисов;

  • namespace для остальных сервисов (nginx/dslab/prometheus).

• Наличие Kubectl (CLI) на ПК, с которого производится установка.

• Наличие пакетного менеджера Helm на ПК, с которого производится установка.

• Наличие docker на машине для сборки images dataspace-core-meta/dataspace-meta/dslab-builder.

• Наличие пакета Liquibase.

• Опционально наличие jdbc-драйвера Oracle версии не ниже 21.5.0.0 в случае использования БД Oracle.

• Доступ к частному или публичному registry image.

• Доступ к частному или публичному package repository.

• Доступ к следующим общим образам (в скобках приведены ссылки на hub.docker.com):

  • curlimages/curl;

  • maven:3.8.1-adoptopenjdk-11;

  • alpine/helm;

  • liquibase/liquibase;

  • node:14.18.2-alpine.

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

Примечание:

*

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

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

**

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

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

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

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

Примечание:

***

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

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

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

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

Минимальные требования для работы модулей DS Lab:

• Для модуля dataspace-core-meta:

  • Процессор: 2 x CPU.

  • Оперативная память: 2 ГБ или больше.

• Для модуля dataspace-meta:

  • Процессор: 1 x CPU.

  • Оперативная память: 1 ГБ или больше.

Минимальные требования для каждого разворачиваемого клиентского сервиса:

• Процессор: 0.25 x CPU.

• Оперативная память: 512 МБ.

Минимальные требования для вспомогательных модулей, запускаемых dataspace-meta:

• Процессор: 2 x CPU.

• Оперативная память: 2 ГБ или больше.

Типовые требования к серверу БД для модуля dataspace-core-meta:

• СУБД на базе PostgreSQL;

• CPU — 2 шт.;

• RAM — 4 ГБ;

• HDD — 40 ГБ;

• IOPS — 1000.

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

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

Дистрибутив компонента DSLB представляет собой набор ZIP-архивов:

*dslb-bin-<номер дистрибутива>-distrib.zip, содержащий папки:

• package/docker — папка с содержимым для формирования образов сервисов DataSpace;

• package/db — папка с архивом для проливки Liquibase-скриптов;

• package/ext — папка с model-jpa-артефактами для формирования образов.

*dslb-cfg-<номер дистрибутива>-distrib.zip, содержащий папку package/conf/helm — папка с Helm-манифестами для установки сервисов в среду контейнеризации.

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

Настройка namespace#

Namespace Kubernetes (OpenShift) будет считаться готовым к развертыванию компонента DS Lab после выполнения всех следующих требований:

• Для namespace создан secret типа Dockersecret с логином и паролем ТУЗ для image pull.

• Созданный secret прописан в service accounts: default.

• Для namespace, в котором разворачивается ControlPlane и клиентские сервисы, создан ServiceAccount.

• Для namespace, в котором разворачивается ControlPlane, создан secret с параметрами подключения к БД.

• Для namespace клиентских сервисов создан секрет с kubeconfig.

• Для namespace клиентских сервисов создан секрет с settings.xml.

Создание pull image secret#

Pull image secret создается в namespace:

kubectl create secret docker-registry <secret-name> --docker-server=<your-registry-server> --docker-username=<your-name> --docker-password=<your-pword> --docker-email=<your-email>

Создание ServiceAccount и выдача прав#

Необходимо выполнить следующие действия:

1. Создать ServiceAccount в namespace, в котором разворачивается ControlPlane и клиентские dataspace:

kubectl apply -f - <<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
  name: sa-dataspace
EOF

2. Для созданных ServiceAccount сгенерировать токен:

kubectl apply -f - <<EOF
apiVersion: v1
kind: Secret
metadata:
  name: sa-dataspace-secret
  annotations:
    kubernetes.io/service-account.name: sa-dataspace
type: kubernetes.io/service-account-token
EOF

3. Создать RoleBinding для ServiceAccount в namespace ControlPlane:

kubectl create rolebinding sa-dataspace-admin --clusterrole=admin --serviceaccount=<ns_controlPlane>:sa-dataspace --namespace=<ns_controlPlane>

4. Создать RoleBinding для ServiceAccount в namespace клиентских dataspace:

kubectl create rolebinding sa-dataspace-admin --clusterrole=admin --serviceaccount=<ns_clients>:sa-dataspace --serviceaccount=<ns_controlPlane>:sa-dataspace --namespace=<ns_clients>

Примечание

Если для ControlPlane и клиентских dataspace используется общий namespace, данный шаг можно пропустить.

5. Для созданных ServiceAccount привязать pull image secret, созданный на шаге Создание pull image secret:

kubectl patch serviceaccount sa-dataspace -p '{"imagePullSecrets": [{"name": "<secret-name>"}]}'

6. При установке сервисов dataspace-core-meta и dataspace-meta в values.yaml указать имя используемого ServiceAccount:

serviceAccount:
  name: sa-dataspace

Создание secret для подключения к БД#

Пример команды:

kubectl create secret generic <secret-name> --from-file=<имя файла>

Пример файла:

apiVersion: v1
kind: Secret
metadata:
  name: main-db-secret
stringData:
  secret.properties: |-
    spring.datasource.username=<имя пользователя для DML операций>
    spring.datasource.password=<пароль пользователя>
    spring.datasource.url=<jdbc строка для подключения к <БД>
    dataspace.datasource.primary.dbschema=<имя схемы>
    spring.datasource.driver-class-name=<java driver class>

Создание secret с settings.xml#

Пример команды:

kubectl apply -f <имя файла>

Пример файла:

apiVersion: v1
kind: Secret
metadata:
  name: maven-settings
stringData:
  settings.xml: |-
    <settings xmlns="http://maven.apache.org/SETTINGS/1.0.0"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
                      http://maven.apache.org/xsd/settings-1.0.0.xsd">
        <servers>
            <server>
                <id>release.repo</id>
                <username></username>
                <password></password>
            </server>
            <server>
                <id>internal</id>
                <username></username>
                <password></password>
            </server>
        </servers>
        <profiles>
            <profile>
                <id>settings</id>
                <repositories>
                    <repository>
                        <id>release.repo</id>
                        <url></url>
                    </repository>
                </repositories>
                <pluginRepositories>
                    <pluginRepository>
                        <id>release.repo</id>
                        <url></url>
                    </pluginRepository>
                </pluginRepositories>
            </profile>
        </profiles>
        <activeProfiles>
            <activeProfile>settings</activeProfile>
        </activeProfiles>
  </settings>

Создание secret для работы DS Lab#

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

Для работы DS Lab требуется развернуть БД. Поддерживается СУБД PostgreSQL (далее PostgreSQL или PG). Рекомендуется использовать продукт Platform V Pangolin SE, правообладателем которого является АО «СберТех» (см. раздел "Системные требования").

Примечание

Для именования объектов БД (учетных записей, ролей, схем, табличных пространств и т.д.) следует руководствоваться требованиями используемой СУБД в части имен без использования кавычек. Обычно в допустимый набор символов входят латинские буквы (a-z, A-Z), цифры (0-9) и символ подчеркивания (_), имена должны начинаться с буквы или символа подчеркивания.

Для подготовки БД ознакомьтесь с разделом "Подготовка базы данных" документа "Руководство по установке" компонента DSPC.

Внимание!

Для компонента DSLB необходимо использовать отличную от используемой в компоненте DSPC базу данных и иную роль для подключения к БД.

Пример скрипта для создания роли:

CREATE ROLE dsl_appl WITH PASSWORD <пароль> LOGIN
CREATEDB CREATEROLE NOSUPERUSER;

GRANT ALL PRIVILEGES ON SCHEMA dslb TO dsl_appl WITH GRANT OPTION;

GRANT ALL PRIVILEGES ON TABLESPACE dslb_t TO dsl_appl WITH GRANT OPTION;

GRANT ALL PRIVILEGES ON database dslb_db TO dsl_appl WITH GRANT OPTION;

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

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

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

• рекомендованная автоматизированная установка.

Установка#

Подготовка параметров для установки#

Параметры для dataspace-core-meta#

Пример заполнения файла конфигурации для dataspace-core-meta:

```yaml
releaseName: ds-core-meta
values:
replicaCount: 2 # количество поднимаемых pods
appConfig:
  packagesToScan: "com.sbt.meta.model" # groupId модели DS Lab
  fluentBit:
    enabled: false
  db:
    main:
      secret: "ds-db-main-secret" # имя секрета, созданного в разделе "Создание secret для подключения к БД"
  overrideProperties:
    graphiql:
      endpoint:
        graphql: /ds-core-meta/graphql #Т.к. используется Nginx необходимо переопределить пути статики. Должно совпадать с путем в Ingress
        subscriptions: /ds-core-meta/subscriptions #Т.к. используется Nginx необходимо переопределить пути статики. Должно совпадать с путем в Ingress
      basePath: /ds-core-meta/ #Т.к. используется Nginx необходимо переопределить пути статики. Должно совпадать с путем в Ingress
    dataspace:
      endpoint:
        graphiql:
          enabled: true
        graphql:
          enabled: true
    server:
      tomcat:
        general-thread-analytics: true
        threadstatistics: false
    spring:
      jpa:
        database-platform: org.hibernate.dialect.H2Dialect
        show-sql: false
service:
  port: 8080
  type: NodePort
  unsecPort: 9999
ingress:
  enabled: true
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/rewrite-target: /$2
  tls:
    - secretName: ds-tls-secret
      hosts:
        - dsmeta.ddns.net
  hosts:
    - host: 'dsmeta.ddns.net'
      paths:
        - path: /ds-core-meta(/|$)(.*)
    - host: ''
      paths:
        - path: /ds-core-meta(/|$)(.*)
resources:
  limits:
    cpu: 2000m
    memory: 2048Mi
  requests:
    cpu: 2000m
    memory: 2048Mi
image:
  registryUrl: "<адрес registry>"
  registryProject: "<путь к проекту>"
imagePullSecrets:
  - name: default-secret
  - name: nexusbasesw # имя секрета, созданного в разделе "Создание pull image secret"
```

Параметры для dataspace-meta#

Список параметров для установки Helm Charts:

Примечание

Для корректной работы в среде контейнеризации Kubernetes необходимо указать:

volumes.defaultMode: 288

securityContext.runAsNonRoot: false

Параметры приложения#

Список параметров, который можно переопределить через appConfig.overrideProperties:

Использование RDS SberCloud для клиентских dataspace-core#

Внимание!

Для использования сервиса RDS SberCloud необходимо, чтобы компонент DS Lab был развернут в тенанте SberCloud. В ином случае данную функциональность использовать невозможно, однако на работоспособность компонента DS Lab это не влияет.

Для взаимодействия с Managed PostgreSQL от SberCloud клиентских dataspace необходимо добавить в секцию appConfig.overrideProperties следующий набор параметров:

Использование Customer DB для клиентских dataspace-core#

Для работы с внешними БД клиентских dataspace необходимо добавить в секцию appConfig.overrideProperties следующий набор параметров (пример):

database:
  enabled: true
  instance:
    <db_alias>:
      jdbcUrl: jdbc:postgresql://<host>:<port>/<db_name>
      jdbcDriver: org.postgresql.Driver
      user: <user>
      password: <password>
      defaultSchemaName: <schema_name>
      tableSpaceT: <tablespaceT_name>
      tableSpaceI: <tablespaceI_name>
      tableSpaceL: <tablespaceL_name>
      dialect: org.hibernate.dialect.PostgreSQLDialect

Внимание!

Пользователь БД, указываемый для DS Lab, должен иметь права на создание БД, пользователя и выдачу GRANT.

Подробное описание параметров представлено в таблице:

Использование API Gateway SberCloud#

Внимание!

Для использования сервиса API Gateway SberCloud необходимо, чтобы DS Lab был развернут в тенанте SberCloud. В ином случае данная функциональность использовать невозможно, однако на работоспособность DS Lab это не влияет.

Для использования сервиса API Gateway Sbercloud требуется задать ряд настроек в секции:

Кастомизация Ingress для клиентских dataspace#

Внимание!

Данные настройки применимы в том случае, если параметр sbt.install.ingress.enabled имеет значение "true".

Использование Grafana#

Настройки подключения:

• execution_time — среднее время выполнения задачи. Значение суммируется со временем выполнения остальных задач в конвейере для расчета времени разворачивания модели (значение по умолчанию — 10 сек).

• isMandatory — определяет обязательность выполнения задачи в конвейере. Если — "true", то при неуспешном выполнении задачи конвейер будет прерван с ошибкой. Если — "false", то задача считается опциональной и при неуспешном выполнении задачи выполнение конвейера будет продолжено.

• url — URL во внутренней подсети.

• exturl — внешняя ссылка на созданный дашборд.

• apikey — API-ключ, используемый для аутентификации DS Lab, при вызове вызывающего API Grafana.

• username — имя пользователя.

• password — пароль.

• userprefix — префикс, добавляемый к номеру модели.

• dataSourceUrl — URL к Prometheus.

• dataSourceType — допустимое значение — "PROMETHEUS".

• dataSourcePrometheusScrapeInterval — интервал между очистками.

• dataSourcePrometheusQueryTimeout — тайм-аут запроса.

• dataSourcePrometheusHttpMethod — допустимое значение — "POST".

Использование Stitching#

Для использования функциональности dataspace-stitching требуется задать ряд настроек в секции:

Переопределение используемых ресурсов клиентских dataspace-core#

Для управления ресурсами клиентских dataspace можно переопределить в appConfig.overrideProperties секцию sbt.flavour.cfg.FREE.

Пример заполнения:

sbt:
  flavour: true
  cfg:
    FREE:
      limits:
        cpu: 2
        memory: 1024Mi
      requests:
        cpu: 1
        memory: 1024Mi
      jvmArguments: "-XX:+AlwaysPreTouch -server -XX:InitialRAMPercentage=50.0 -XX:MaxRAMPercentage=70.0 -XX:+UseG1GC -XX:MaxGCPauseMillis=100 -XX:ParallelGCThreads=2 -XX:+ParallelRefProcEnabled -XX:-ResizePLAB -XX:G1ReservePercent=10 -XX:+UnlockExperimentalVMOptions -XX:G1NewSizePercent=20 -XX:HeapDumpPath=./ -XX:+UnlockDiagnosticVMOptions -XX:+HeapDumpOnOutOfMemoryError -XX:+DisableExplicitGC -XX:+ScavengeBeforeFullGC -XX:PrintSafepointStatisticsCount=1 -XX:+PrintClassHistogram -XX:+PrintFlagsFinal -XX:+LogVMOutput -Xlog:gc*=info:file=/tmp/gc_log_memory.log:time,uptime,level,tags:filesize=50m,filecount=100 -Xlog:safepoint=info:file=/tmp/gc_log_memory.log:time,uptime,level,tags:filesize=50m,filecount=100 -Djdk.attach.allowAttachSelf=true --add-exports java.base/jdk.internal.perf=ALL-UNNAMED --add-exports java.management/com.sun.jmx=ALL-UNNAMED"

Подробное описание параметров сведено в таблицу:

Примечание

На текущий момент рекомендованы два набора jvm-аргументов:

• Для pods с малым количеством ресурсов (не рекомендуется для промышленной эксплуатации): sbt.flavour.cfg.FREE.jvmArguments: -XX:+HeapDumpOnOutOfMemoryError -Xshare:off -XX:+AlwaysPreTouch -XX:ReservedCodeCacheSize=77m -XX:ProfiledCodeHeapSize=50m -XX:NonProfiledCodeHeapSize=25m -XX:NonNMethodCodeHeapSize=2m -XX:InitialRAMPercentage=10.0 -XX:MaxRAMPercentage=20.0 -XX:+PrintFlagsFinal -XX:+TieredCompilation -XX:+UseSerialGC -XX:ThreadStackSize=256 -XX:+UseNUMA -XX:MetaspaceSize=50m -XX:MaxMetaspaceSize=150m -XX:MaxDirectMemorySize=30m -XX:-UseBiasedLocking -Djdk.attach.allowAttachSelf=true --add-exports java.base/jdk.internal.perf=ALL-UNNAMED --add-exports java.management/com.sun.jmx=ALL-UNNAMED -Djdk.nio.maxCachedBufferSize=1024000.

• Для остальных случаев: sbt.flavour.cfg.FREE.jvmArguments: -XX:+AlwaysPreTouch -server -XX:InitialRAMPercentage=50.0 -XX:MaxRAMPercentage=70.0 -XX:+UseG1GC -XX:MaxGCPauseMillis=100 -XX:ParallelGCThreads=2 -XX:+ParallelRefProcEnabled -XX:-ResizePLAB -XX:G1ReservePercent=10 -XX:+UnlockExperimentalVMOptions -XX:G1NewSizePercent=20 -XX:HeapDumpPath=./ -XX:+UnlockDiagnosticVMOptions -XX:+HeapDumpOnOutOfMemoryError -XX:+DisableExplicitGC -XX:+ScavengeBeforeFullGC -XX:PrintSafepointStatisticsCount=1 -XX:+PrintClassHistogram -XX:+PrintFlagsFinal -XX:+LogVMOutput -Xlog:gc*=info:file=/tmp/gc_log_memory.log:time,uptime,level,tags:filesize=50m,filecount=100 -Xlog:safepoint=info:file=/tmp/gc_log_memory.log:time,uptime,level,tags:filesize=50m,filecount=100 -Djdk.attach.allowAttachSelf=true --add-exports java.base/jdk.internal.perf=ALL-UNNAMED --add-exports java.management/com.sun.jmx=ALL-UNNAMED.

Типы работы controlPlane#

Допустимые значения:

• CUSTOMER_DB — при данном значении выполняется сборка и развертывание клиентского сервиса. В качестве БД для клиентского сервиса будет использована одна из БД, указанных в database.instance. Соответственно значение параметра database.enabled необходимо установить в "true" и указать не менее одной БД. Выбор базы данных будет осуществляться на UI.

• ARCHETYPE_ONLY — при данном значении осуществляется сборка шаблонного проекта (сервис не разворачивается).

• DEFAULT — при данном значении CI/CD зависит от значения параметра sbercloud.database.type. Если sbercloud.database.type=H2, то клиентский сервис разворачивается со встроенной H2 БД. Если sbercloud.database.type=H2, то клиентский сервис разворачивается в режиме работы с RDS.

Пример заполнения конфигурационного файла для dataspace-meta#

```yaml
releaseName: ds-meta
values:
  replicaCount: 2
  appConfig:
    k8s:
      secret: "k8s-certifacte" # значение, имя созданного secret
    fluentBit:
      enabled: true
      image: "fluent/fluent-bit:1.4.5"
    overrideProperties:
      zuul:
        routes:
          gql-plgr-stitching:
            url: http://svc-ds-stitching-{{modelId}}.dataspace-tenant.svc.cluster.local:8080/graphql
      customer-dataspace-host: http://svc-ds-{{modelId}}.dataspace-tenant.svc.cluster.local:8080
      database:
        enabled: false
      sbercloud:
        database:
          type: PG
        grafana:
          url: <url>
          extUrl: <extUrl>
          dataSource:
            url: <путь к dataSource>
        k8s:
          url: <адрес>
          caCertFile: file:/deployments/config/secrets/k8s/ca.crt
          clientCertFile: file:/deployments/config/secrets/k8s/client.crt
          clientKeyFile: file:/deployments/config/secrets/k8s/client.key
          builder:
            image-pull-secrets: nexusdzosw
            container-image: <путь к образу>
            docker-config: nexusdzosw
            nexus.type: nexus3
            nexus: 
              url: <путь к репозиторию>
              repository: sbt-maven
            docker:
              registry: <путь к registry>
              username: <ТУЗ>
              password: <пароль>
          helm:
            init-container-image: curlimages/curl
            container-image: <путь к образу>
          liquibase:
            init-container-image: curlimages/curl
            container-image: <путь к образу>
            image-pull-secrets: default,nexusdzosw
        nexus:
          username: <username>
          password: <password>
          restEndpoint: <путь к endpoint>
      sber:
        cloud:
          k8s:
            tenant:
              namespace: dataspace-tenant
        controlplane:
          mock:
            endpointprefix: "<префикс>"
          pipelines:
            "[default]":
              deploy: RollScriptToDbDeployTask,SecretRegistrationDeployTask,BuilderTask,FilePersistingDeployTask,LiquibaseDeployTask,DeployTask,GrafanaDeployTask,ApiGatewayDeployTask
              rollback: LiquibaseRollbackTask,SecretRegistrationRollbackTask,RollScriptToDbRollbackTask
          taskProperties: 
            "[GrafanaDeployTask]": 
              "[url]": <url>
              "[exturl]": <extUrl>
              "[apikey]": Bearer <api key in base64>"
              "[username]": <username>
              "[password]": <password>
              "[userprefix]": dash_
              "[dataSourceUrl]": <dataSource url>
              "[dataSourceType]": PROMETHEUS
              "[dataSourcePrometheusScrapeInterval]": 10s
              "[dataSourcePrometheusQueryTimeout]": 10s
              "[dataSourcePrometheusHttpMethod]": POST
            "[ApiGatewayDeployTask]":
              "[execution_time]": 10
              "[externalIp]": <ip-адрес>
        build:
          groupIdPrefix: ru.sbt.platformv.dev
          #groupId: sbp.com.sbt.dataspace.smartapp
          dataspacebom:
            version: 4.3.255
      endpoints:
        env:
          keys-to-sanitize: secret,credentials,password
      server:
        port: 8080
      core:
        unsecure:
          url: "http://svc-ds-core-meta.dataspace.svc.cluster.local:9999"
        url: "http://svc-ds-core-meta.dataspace.svc.cluster.local:8080"
      controlPlaneUrl: "http://localhost:8080/controlPlane"
  service:
    port: 8080
    type: NodePort
  ingress:
    enabled: true
    annotations:
      kubernetes.io/ingress.class: nginx
    hosts:
      - host: 'dsmeta.ddns.net'
        paths:
          - path: /
      - host: ''
        paths:
          - path: /
  resources:
    limits:
      cpu: 600m
      memory: 512Mi
    requests:
      cpu: 300m
      memory: 256Mi
  image:
    registryUrl: <адрес registry>
    registryProject: <путь к проекту>
  imagePullSecrets:
    - name: default-secret
    #- name: nexus3swpublic
    - name: nexusbasesw
  hostAliases: #При наличии проблем с DNS.
    - ip: <ip-адрес>
      hostnames:
        - <имя хоста>
    - ip: <ip-адрес>
      hostnames:
        - <имя хоста>
    - ip: <ip-адрес>
      hostnames:
        - <имя хоста>
  core:
    readinessProbe:
      failureThreshold: 10
    livenessProbe:
      failureThreshold: 10


```

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

Ручная установка при помощи Ansible#

На компьютере, с которого будут запускаться playbooks, должно быть установлено следующее ПО: Ansible и Helm (см. раздел "Системные требования").

Необходимо выполнить следующие действия:

1. Распаковать архив со скриптами и перейти в папку scripts/ansible-playbooks.

2. Перед запуском необходимо заполнить файл vars.yml:

   • Для проливки Liquibase-скриптов необходимо заполнить секцию LIQUIBASE:

     ############################# LIQUIBASE ########################
     liquibaseVersion: <версия Liquibase> 
     liquibaseTempDirectory: <временная директория, куда расспаковать архив с Liquibase и со скриптами ( после окончания автоматически удалиться)>
     liquibaseCLIPath: <путь к архиву с бинарными файлами Liquibase (архив расспаковывать не нужно, playbook сам это делает) или ссылка на загрузку данного архива (например для Github — https://github.com/liquibase/liquibase/releases/download/v{{ liquibaseVersion }}/liquibase-{{ liquibaseVersion }}.tar.gz, в качестве версии сюда подставляется значение из переменной liquibaseVersion)> 
     liquibasePropertiesFilePath: <путь к файлу liquibase.properties>
     liquibaseChangeLogFile: <имя changelog-файла>
     liquibaseSearchPath: <путь к Liquibase-скриптам>
     ################################################################
   

   Также для проливки Liquibase-скриптов необходимо заполнить файл liquibase.properties:

      username: <пользователь с правами DDL>
      password: <пароль пользователя>
      url: <jdbc адрес подключения к бд>
      defaultSchemaName: <имя схемы>
      driver: org.postgresql.Driver
      parameter.defaultSchemaName: <имя схемы>
      parameter.tablespace_t: <имя tablespace для таблиц>
      parameter.tablespace_l: <имя tablespace для ЛОБов>
      parameter.tablespace_i: <имя tablespace для индексов>
   

   • Для установки DSLB с помощью Helm необходимо заполнить секцию HELM:

   ############################# HELM #############################
   gitConfigRepo: <ссылка на репозиторий с конфигурационными файлами>
   gitConfigBranch: <ветка репозитория>
   configPath: <путь к файлу конфигурации>
   distribPath: <путь к архиву с дистрибутивом (архив распаковывать не нужно)>
   projectName: <имя проекта (может быть dataspace-meta или dataspace-core-meta>
   distribTempDirectory: <временная директория, куда распаковать дистрибутив (после окончания автоматически удалиться)>
   kubernetesNamespace: <namespace Kubernetes>
   ################################################################
   

3. Для запуска playbooks можно запустить файл run.sh в папке со скриптами и выбрать нужный пункт меню, или запустить вручную нужные playbooks:

   • Для проливки Liquibase-скриптов:

   ansible-playbook -i localhost, scripts/ansible-playbook/liquibase-roll.yml
   

   • Для установки DSLB с помощью Helm:

   ansible-playbook -i localhost, scripts/ansible-playbook/helm-installer.yml
   

Ручная сборка образов модулей DS Lab#

Сборка образа dataspace-core-meta#

Примечание

Должен быть собран базовый образ сервиса dataspace-core из дистрибутива компонента DSPC.

Данный образ будет использоваться в качестве BASE_IMAGE на этом этапе.

В составе дистрибутива в папке docker лежит все необходимое для сборки базового дистрибутива компонентов DataSpace.

Произвести сборку образа, пример:

docker build -t dataspace-core-meta:4.3.455 . --build-arg BASE_IMAGE=<image>

docker push specify.docker.registry/specify_project/dslb/dataspace-core-meta:4.3.455

Сборка образа dataspace-meta#

В составе дистрибутива в папке docker лежит все необходимое для сборки базового дистрибутива компонентов DataSpace.

Произвести сборку образа, пример:

docker build -t dataspace-core-meta:4.3.455 . --build-arg registryUrl=<url> --build-arg rhelOpenJdkUrl=<image> --build-arg version=<version>

docker push specify.docker.registry/specify_project/dslb/dataspace-core-meta:4.3.455

Сборка образа DS builder#

Необходимо положить папку m2 из дистрибутива продукта Platform V DataSpace в каталог с Dockefile, остальное для сборки лежит в составе дистрибутива рядом с Dockerfile.

Примечание

В качестве базового образа BASE_IMAGE необходимо использовать образ, содержащий как минимум:

• maven версии 3.8.X;

• python версии 3.X.X;

• unzip.

Пример сборки базового образа:

ARG BASE_IMAGE=specify.docker.registry/specify_project/maven:3.8.1-adoptopenjdk-11
FROM $BASE_IMAGE
 
RUN apt update && \
    apt install -y python3 && \
    apt install -y unzip && \
    rm -f /var/cache/apt/archives/*.rpm \
          /var/cache/apt/*.bin \
          /var/lib/apt/lists/*.*

Произвести сборку образа, пример:

docker build -t ds-builder:<версия dataspace-bom> . --build-arg BASE_IMAGE=maven:3.8.1-adoptopenjdk-11-python-unzip

docker push specify.docker.registry/specify_project/dslb/ds-builder:<версия dataspace-bom>

Сборка образа DS builder stitching#

Все необходимое для сборки лежит в составе дистрибутива рядом с Dockerfile.

Примечание

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

Произвести сборку образа, например:

docker build -t ds-builder-stitching:<версия dataspace-bom> . --build-arg BASE_IMAGE=maven:3.8.1-adoptopenjdk-11

docker push specify.docker.registry/specify_project/dslb/ds-builder-stitching:<версия dataspace-bom>

Шаги установки#

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

1. Распаковать дистрибутив компонента DS Lab.

2. Выполнить скрипты Liquibase при помощи любой формы Liquibase.

   Примечание

   Все необходимое для проливки Liquibase-скрипов находится в архиве по пути package/db/db-scripts.zip.

   Описание параметров и пример самой команды для проливки Liquibase-скриптов приведены в разделе "Ручная проливка Liquibase-скриптов на СУБД" документа "Руководство по установке" компонента DSPC.

3. Установка DS Lab производится с помощью пакетного менеджера Helm для установки.

4. Установить модуль dataspace-core-meta c помощью Helm, используя сформированный конфигурационный файл из раздела "Параметры для dataspace-core-meta":

   helm upgrade dataspace-core-meta ./dataspace-core-meta -f ./<file-name-config>.yaml --wait --install --namespace <namespace-name>
   

5. Установить модуль dataspace-meta c помощью Helm, используя сформированный конфигурационный файл из раздела "Параметры для dataspace-meta":

   helm upgrade dataspace-meta ./dataspace-meta -f ./<file-name-config>.yaml --wait --install --namespace <namespace-name>
   

Автоматизированная установка сервиса с использованием Deploy Tools (CDJE)#

Дистрибутив для установки (cм. раздел "Состав дистрибутива") представляет собой архив, состоящий из двух частей: архива с бинарными артефактами и архива с конфигурацией (инсталляционными манифестами для установки приложения в среду контейнеризации).

При использовании способа развертывания с помощью компонента Deploy tools (CDJE) продукта Platform V DevOps Tools (DOT) по всем возникающим вопросам рекомендуется обращаться к эксплуатационной документации данного компонента. Ниже представлен краткий алгоритм действий, необходимых для разворачивания дистрибутива Platform V DataSpace.

Подготовка к установке#

Для установки необходимо соблюдение следующих условий:

1. Наличие у пользователя, производящего установку, возможности создания репозиториев в хранилище (например, Git) и доступов в целевые области хранилища дистрибутива (в Nexus).

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

3. Созданы и проинициализированы следующие Git-репозитории в проектной области с веткой master по умолчанию:

   • Репозитории для работы с pipeline Build tools (CIJE):

     • pipeline — репозиторий с кодовой базой релизов pipeline (на каждый стенд формируется свой репозиторий, например, ci90000026_dspc_pipeline_ift / ci90000026_dspc_pipeline_lt);

     • common — репозиторий с глобальными (одинаковыми для всех компонент в рамках одного стенда) переменными среды (на каждый стенд формируется свой репозиторий, например, ci90000026_dspc_common_ift / ci90000026_dspc_common_lt).

   • Репозитории с конфигурациями функциональных подсистем (для каждого модуля формируется свой репозиторий, например, для dataspace-meta — ci90000026_dspc_dataspace-meta_ift / ci90000026_dspc_dataspace-meta_lt).

Должны быть сконфигурированы следующие инструменты развертывания:

• JOB Service — job обновления (первичная загрузка кода JOB Deploy, обновление кода JOB Deploy при выпуске новых релизов JOB Deploy).

• JOB Deploy — job для развертывания дистрибутивов.

После настройки репозиториев pipeline и common через JOB Service необходимо заполнить и зашифровать файл _passwords.conf в репозитории common по пути /ansible. _password.conf — файл, содержащий пароли для баз данных, Kafka и т.д., которые будут использоваться для создания secrets в среде контейнеризации:

 # пароли для подключения к БД и проливки lq скриптов 
 dataspace_main_db_password = "user_main_password"

Примечание

Также имеется возможность получать пароли из HashiCorp Vault. Если требуется использовать пароль из HashiCorp Vault для проливки Liquibase-скриптов, необходимо обратиться к документации компонента Deploy tools (CDJE) продукта Platform V DevOps Tools (DOT).

Необходимо добавить ФП для развертывания в конфигурационный файл subsystems.json в корне common проекта, например:

...
  "DSLAB": {
    "fpi_name": "dataspace-meta",
    "artifactId": "dataspace-meta-cfg",
    "groupId": "nexusProject/dslb",
    "versionFilter": "1.1",
    "strict": "false",
    "fpType": "fp",
  }
...

Необходимо добавить стенд для развертывания в конфигурационный файл multiClusters.json в корне common проекта, например:

 "Test1": {
   "openshiftCluster"                   : "https://api.apps.example.com:6443",
   "openshiftSATokenCred"               : "jenkins_auth_stand_token",  
   "openshiftProjectName"               : "project",
   "openshiftAppsDomain"                : "apps.example.com",
   "openshiftWebConsole"                : "https://console-openshift-console.apps.example.com/k8s/cluster/projects",
   "openshiftRoutersFQDN"               : "1.1.1.1",
   "overrides"                          : ["k8s/overrides/"],
   "openshiftControlPlane"              : "example-controlplanev20",
   "openshiftControlPlaneIstiodService" : "istiod-common-install"      
 },
где openshiftSATokenCred — созданный кред в Jenkins, содержащий токен подключения к среде контейнеризации (это может быть токен пользователя или ServiceAccount)

После выполнения всех действий произвести миграцию конфигурационных файлов ФП через playbook MIGRATION_FP_CONF (миграция конфигурационных файлов ФП) в JOB Deploy.

Заполнить конфигурационные файлы приложений values.yaml по пути conf/helm/application в репозитории ФП в соответствии с окружением стенда и документацией.

Проливка Liquibase-скриптов на базу данных#

Предварительно необходимо заполнить файл custom_property.conf.yml в репозитории ФП по пути conf/custom_property.conf.yml:

# Данные для проливки lq скриптов на main
dataspace_main_db_user: "user_main"
dataspace_main_db_url: "jdbc:postgresql://url:port/user_main_db"
dataspace_main_db_schema: "user_main_schema"
dataspace_main_db_driver: "org.postgresql.Driver"
dataspace_main_db_dialect: "org.hibernate.dialect.PostgreSQLDialect"
dataspace_main_db_tablespace_t: "user_main_tablespace_t"
dataspace_main_db_tablespace_i: "user_main_tablespace_i"
dataspace_main_db_tablespace_l: "user_main_tablespace_l"

Проливка скриптов выполняется путем запуска JOB Deploy с playbook DB_UPDATE (запуск Liquibase-скриптов).

Установка дистрибутива на стенд#

Внимание!

Перед установкой предварительно необходимо выполнить конфигурирование параметров (см. описание в разделе "Подготовка параметров для установки".

Установка дистрибутива на стенд выполняется путем запуска JOB Deploy с playbook HELM_DEPLOY (установка нативным Helm приложения в среду контейнеризации).

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

Интеграция с Fluent Bit#

Для интеграции с Fluent Bit необходимо при установке сервисов dataspace-core-meta и dataspace-meta задать следующую секцию для helm charts (пример):

          fluentBit:
            enabled: true
            image: "fluent/fluent-bit:1.9.10"

Подробнее параметры описаны в разделе "Параметры для dataspace-meta".

Интеграция с Istio Service Mesh#

Для интеграции с Istio Service Mesh необходимо при установке сервисов dataspace-core-meta и dataspace-meta задать следующую секцию для helm charts (пример):

        istio:
          enabled: true
          # Для proxyEnv необходимо передать yaml-файл, который затем конвертируется к json-файл. Пример: '{ "TERMINATION_DRAIN_DURATION_SECONDS": "60" }'
          # Параметр необходим для graceful shutdown
          proxyEnv:
            TERMINATION_DRAIN_DURATION_SECONDS: "60"
          proxyCPU: 200m
          proxyMemory: 256Mi
          proxyCPULimit: 200m
          proxyMemoryLimit: 256Mi
          virtualService:
            enabled: true
            gateways: 
              - ingressgateway-gw-mgmt
            hosts: 
              - '*'
            http:
              - match:
                  - uri: 
                      prefix: /ds-core-meta/
                rewrite:
                  uri: /
                route:
                  - destination:
                      host: svc-ds-core-meta.dataspace-mgmt.cluster.local
                      port:
                        number: 8080

Подробнее параметры описаны в разделе "Параметры для dataspace-meta".

Интеграция с Prometheus и Grafana#

Интеграция по умолчанию включена для autodiscovering в kind Service сервисов dataspace-meta и dataspace-core-meta.

apiVersion: v1
kind: Service
metadata:
  annotations:
    prometheus.io.path: /actuator/prometheus
    prometheus.io.port: "8080"
    prometheus.io.scrape: "true"

Интеграция с Keycloak#

Описание интеграции с Keycloak приведено в разделе "Пример настройки интеграции c внешней IAM-системой (Keycloak)" документа "Руководство по системному администрированию".

Обновление#

Для обновления версии модулей DS Lab необходимо повторить шаги, описанные в разделе "Установка".

Удаление предыдущей версии не требуется.

Удаление#

Удаление компонента DS Lab с помощью Helm#

В случае установки сервисов с помощью helm charts удаление всех ресурсов осуществляется поочередно с помощью команды:

helm delete <имя> -n <имя namespace>

Удаление компонента DS Lab с помощью утилит Kubectl#

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

• ConfigMaps, Secrets, Deployments, Services, PODs, VirtualServices (только при использовании Istio);

• схему базы данных.

Для удаления ресурса необходимо подключиться к Kubernetes (или OpenShift) через терминал и выполнить команду:

kubectl -n <имя namespace> delete <тип компонента Kubernetes (или Openshift)> <имя компонента Kubernetes (или Openshift)>

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

Удаление схемы базы данных#

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

• В случае PostrgeSQL:

  DROP SCHEMA <имя схемы> CASCADE; 
  

• В случае Oracle:

  BEGIN
    FOR c IN (SELECT table_name FROM all_tables WHERE OWNER='<имя схемы>') LOOP
      EXECUTE IMMEDIATE (\'DROP TABLE <имя схемы>.\'|| c.table_name ||\' CASCADE CONSTRAINTS\');
    END LOOP;
  END;
  

Допускается использование любого клиента для работы с БД, совместимого с используемой DSLB СУБД.

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

Для проверки работоспособности необходимо выполнить HTTP-запрос get на адрес <адрес сервиса>/actuator/health. В случае успеха будет возвращен ответ вида:

{
    "status": "UP",
    "components": {
        "activeDataSource": {
            "status": "UP",
            "details": {
                "database": "H2",
                "validationQuery": "isValid()"
            }
        },
        "db": {
            "status": "UP",
            "components": {
                "activeDataSource": {
                    "status": "UP",
                    "details": {
                        "database": "H2",
                        "validationQuery": "isValid()"
                    }
                },
                "dataSource": {
                    "status": "UP",
                    "details": {
                        "database": "H2",
                        "validationQuery": "isValid()"
                    }
                },
                "standinDataSource": {
                    "status": "UP",
                    "details": {
                        "database": "H2",
                        "validationQuery": "isValid()"
                    }
                }
            }
        },
        "discoveryComposite": {
            "description": "Discovery Client not initialized",
            "status": "UNKNOWN",
            "components": {
                "discoveryClient": {
                    "description": "Discovery Client not initialized",
                    "status": "UNKNOWN"
                }
            }
        },
        "diskSpace": {
            "status": "UP",
            "details": {
                "total": 499963174912,
                "free": 331588116480,
                "threshold": 10485760,
                "exists": true
            }
        },
        "hystrix": {
            "status": "UP"
        },
        "ping": {
            "status": "UP"
        },
        "reactiveDiscoveryClients": {
            "description": "Discovery Client not initialized",
            "status": "UNKNOWN",
            "components": {
                "Simple Reactive Discovery Client": {
                    "description": "Discovery Client not initialized",
                    "status": "UNKNOWN"
                }
            }
        },
        "refreshScope": {
            "status": "UP"
        }
    },
    "groups": [
        "liveness",
        "readiness"
    ]
}

Для представленных выше настроек необходимо наличие соответствующих значений работоспособности: UP, isValid().

Чек-лист проверки работоспособности интеграций#

Проверка работоспособности интеграции с Fluent Bit#

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

kubectl get pod/<pod_name> -o jsonpath='{.spec.containers[*].name}' -n <namespace>

В запросе:

• pod_name — имя pod сервиса dataspace-meta или dataspace-core-meta,

• namespace — имя namespace, где развернуты сервисы.

Результат будет выглядеть следующим образом:

dataspace-meta fluentbit istio-proxy

Проверка работоспособности интеграции с Istio Service Mesh#

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

kubectl get pod/<pod_name> -o jsonpath='{.spec.containers[*].name}' -n <namespace>

В запросе:

• pod_name — имя pod сервиса dataspace-meta или dataspace-core-meta,

• namespace — имя namespace, где развернуты сервисы

Результат будет выглядеть следующим образом:

dataspace-meta fluentbit istio-proxy

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

При корректной настройке интеграции с Prometheus/Grafana можно увидеть отображение метрик сервисов DS Lab.

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

Проверка работоспособности интеграции с Keycloak осуществляется путем авторизации в Keycloak. При корректной интеграции с Keycloak невозможно попасть в UI компонента DS Lab без успешного осуществления авторизации в Keycloak.

Откат#

В разделе описаны шаги, которые необходимо выполнить для отката изменений в модулях DS Lab и используемых базах данных.

Откат модулей DS Lab необходимо производить в следующей последовательности:

1. Откат модулей DS Lab. В пространство Kubernetes необходимо установить старую версию модулей. Для этого достаточно выполнить шаги, описанные в разделе "Установка".

2. Откат изменений БД (если необходимо). С принципами отката с помощью Liquibase можно ознакомиться в официальной документации утилиты.

   Необходимо распаковать дистрибутив, перейти в db и запустить утилиту Liquibase:

   liquibase --changeLogFile=changelog.xml rollback <tag>
   

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

Формирование тега rollback#

После выпуска новой релизной версии модели в changelog добавляются все изменения БД относительно предыдущего выпуска. Все изменения размещаются между тегами:

• <modelName>-<version>-before — тег, обозначающий начало новых изменений;

• <modelName>-<version>-applied — тег, обозначающий окончание изменений.

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

Ручной откат с помощью Liquibase#

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

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

Проблемы модуля dataspace-meta#

При разворачивании модуля dataspace-meta при проверке статуса отображается следующая информация:

NAME                                      READY   STATUS             RESTARTS   AGE
ds-meta-74cdcdfc4b-9jthb             0/2     ImagePullBackOff   0          21h

В этом случае требуется проверить:

• доступность image registry с кластера kubernetes;

• аутентификацию в image registry на основе созданного secret на шаге "Создание pull image secret" (см. раздел Настройка namespace);

• корректность указания в deployment imagePullSecrets.

При разворачивании модуля dataspace-core-meta при проверке статуса отображается следующая информация:

NAME                                      READY   STATUS             RESTARTS   AGE
ds-core-meta-74cdcdfc4b-9jthb             1/2     CrashLoopBackOff   0          21h

В этом случае требуется получить логи с pod с помощью команды в консоли:

kubectl  logs ds-core-meta-74cdcdfc4b-9jthb -c dataspace-core-meta -n <namespace>

Логи передать линии поддержки.

При разворачивании модуля dataspace-core-meta при проверке статуса отображается следующая информация:

NAME                                      READY   STATUS             RESTARTS   AGE
ds-meta-75564d9d6c-h9j49                  0/2     ImagePullBackOff   1          21h

В этом случае требуется проверить:

• доступность image registry с кластера Kubernetes;

• аутентификацию в image registry на основе созданного secret на шаге "Создание pull image secret" (см. раздел Настройка namespace);

• корректность указания в deployment imagePullSecrets.

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

Выполнены следующие действия:

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

2. Подготовлена БД (см. раздел "Подготовка базы данных").

3. Проверено наличие собранных образов поставляемого дистрибутива (см. раздел "Состав дистрибутива").

   Примечание

   Образы собираются вручную (см. раздел "Ручная сборка образов модулей DS Lab") или разложены автоматически средствами компонента Delivery Tools (DTDS) продукта Platform V DevOps Tools (DOT) во время перекладки базового дистрибутива продукта.

4. Произведена настройка helm-конфигураций в соответствии с разделом "Подготовка параметров для установки".

5. Произведена настройка необходимых интеграций в соответствии с разделом "Настройка интеграции" и проведена сверка с пунктами раздела "Чек-лист проверки работоспособности интеграций".

6. Произведена helm-установка в соответствии с выбранным способом установки из раздела "Выбор способа установки".

Проверка успешной установки модуля dataspace-core-meta#

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

kubectl get pod -n <namespace>

Пример вывода в консоли:

NAME                                      READY   STATUS             RESTARTS   AGE
deploy-dataspace-nginx-695b8dbbbb-p8wtd   0/1     CrashLoopBackOff   9847       34d
ds-core-meta-74cdcdfc4b-9jthb             2/2     Running            0          21h
ds-core-meta-74cdcdfc4b-flhzq             2/2     Running            0          21h
ds-meta-75564d9d6c-h9j49                  2/2     Running            1          21h
ds-meta-75564d9d6c-kkr6x                  2/2     Running            0          21h

В списке выведенных pods найти ds-core-meta и убедиться, что статус поднятых pods — STATUS=Running.

Проверка успешной установки модуля dataspace-meta#

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

kubectl get pod -n <namespace>

Пример вывода в консоли:

NAME                                      READY   STATUS             RESTARTS   AGE
deploy-dataspace-nginx-695b8dbbbb-p8wtd   0/1     CrashLoopBackOff   9847       34d
ds-core-meta-74cdcdfc4b-9jthb             2/2     Running            0          21h
ds-core-meta-74cdcdfc4b-flhzq             2/2     Running            0          21h
ds-meta-75564d9d6c-h9j49                  2/2     Running            1          21h
ds-meta-75564d9d6c-kkr6x                  2/2     Running            0          21h

В списке выведенных pods найти ds-meta и убедиться, что статус поднятых pods — STATUS=Running.