Установка#
Порядок установки компонентов продукта SAI рекомендуется начинать с AUSC, далее порядок установки остальных компонентов (PREM, WLDT) не важен.
Состав дистрибутива#
Компонент AUSC предоставляет 2 архива (бинарные файлы и конфигурации), а также дополнителнье файлы:
ausc-bin-{version}-{build}-distrib#
Элемент дистрибутива |
Описание |
|---|---|
./package/bh/synai_autoscaler_adapter |
Бинарные файлы приложения «Adapter» |
./package/bh/synai_autoscaler_controller |
Бинарные файлы приложения «Controller» |
./package/docker/adapter/Dockerfile |
Dockerfile для сборки приложения «Adapter» |
./package/docker/controller/Dockerfile |
Dockerfile для сборки приложения «Controller» |
ausc-cfg-{version}-{build}-distrib#
Конфигурации для установки.
Элемент дистрибутива |
Описание |
|---|---|
./package/conf/helm/application/ausc/* |
Конфигурации развертывавния компонента |
ausc-bin-{version}-{build}–cyclonedx-distrib.json#
В данном файле находится спецификация программного обеспечения SBOM (Software Bill Of Materials) — это список всех open source и других сторонних компонент, использующихся в кодовой базе программного продукта.
SBOM состоит из сторонних библиотек с открытым исходным кодом, программных пакетов и собственных артефактов, созданных командной. Дополнительно SBOM может содержать информацию по уязвимостям, подлинности, дочерним зависимостям и множество других контекстных данных.
С помощью SBOM вы можете просмотреть версии сборки, номера выпусков компонентов программного обеспечения и решить, продолжать их использование или нет. Это необходимо во избежание проблем с безопасностью в цепочках зависимостей. Поэтому, если в одной из библиотек обнаруживается проблема, вам необходимо знать, уязвимо ли приложение в целом.
CycloneDX — это стандарт SBOM от фонда OWASP, разработанный для контекстов безопасности приложений и анализа компонентов цепочки поставок, обеспечивающий инвентаризацию всех компонентов программного обеспечения как собственных, так и сторонних производителей.
Компонент PREM предоставляет 2 архива (бинарные файлы и конфигурации), а также дополнителнье файлы:
prem-bin-{version}-{build}-distrib#
Элемент дистрибутива |
Описание |
|---|---|
./package/bh/prem_calculator |
Бинарные файлы приложения «Calculator» |
./package/bh/prem-adapter |
Бинарные файлы приложения «Adapter» |
./package/docker/prem-calculator/Dockerfile |
Dockerfile для сборки приложения «Calculator» |
./package/docker/prem-adapter/Dockerfile |
Dockerfile для сборки приложения «Adapter» |
prem-cfg-{version}-{build}-distrib#
Конфигурации для установки.
Элемент дистрибутива |
Описание |
|---|---|
./package/conf/helm/application/prem/* |
Конфигурации развертывавния компонента |
prem-bin-{version}-{build}–cyclonedx-distrib.json#
В данном файле находится спецификация программного обеспечения SBOM (Software Bill Of Materials) — это список всех open source и других сторонних компонент, использующихся в кодовой базе программного продукта.
SBOM состоит из сторонних библиотек с открытым исходным кодом, программных пакетов и собственных артефактов, созданных командной. Дополнительно SBOM может содержать информацию по уязвимостям, подлинности, дочерним зависимостям и множество других контекстных данных.
С помощью SBOM вы можете просмотреть версии сборки, номера выпусков компонентов программного обеспечения и решить, продолжать их использование или нет. Это необходимо во избежание проблем с безопасностью в цепочках зависимостей. Поэтому, если в одной из библиотек обнаруживается проблема, вам необходимо знать, уязвимо ли приложение в целом.
CycloneDX — это стандарт SBOM от фонда OWASP, разработанный для контекстов безопасности приложений и анализа компонентов цепочки поставок, обеспечивающий инвентаризацию всех компонентов программного обеспечения как собственных, так и сторонних производителей.
Компонент WLDT предоставляет 2 архива (бинарные файлы и конфигурации), а также дополнителнье файлы:
wldt-bin-{version}-{build}-distrib#
Элемент дистрибутива |
Описание |
|---|---|
./package/bh/frontend |
Бинарные файлы приложения «frontend» |
./package/bh/modeler |
Бинарные файлы приложения «modeler» |
./package/docker/frontend/Dockerfile |
Dockerfile для сборки приложения «frontend» |
./package/docker/modeler/Dockerfile |
Dockerfile для сборки приложения «modeler» |
wldt-cfg-{version}-{build}-distrib#
Конфигурации для установки.
Элемент дистрибутива |
Описание |
|---|---|
./package/conf/helm/application/wldt/* |
Конфигурации развертывавния компонента |
wldt-bin-{version}-{build}–cyclonedx-distrib.json#
В данном файле находится спецификация программного обеспечения SBOM (Software Bill Of Materials) — это список всех open source и других сторонних компонент, использующихся в кодовой базе программного продукта.
SBOM состоит из сторонних библиотек с открытым исходным кодом, программных пакетов и собственных артефактов, созданных командной. Дополнительно SBOM может содержать информацию по уязвимостям, подлинности, дочерним зависимостям и множество других контекстных данных.
С помощью SBOM вы можете просмотреть версии сборки, номера выпусков компонентов программного обеспечения и решить, продолжать их использование или нет. Это необходимо во избежание проблем с безопасностью в цепочках зависимостей. Поэтому, если в одной из библиотек обнаруживается проблема, вам необходимо знать, уязвимо ли приложение в целом.
CycloneDX — это стандарт SBOM от фонда OWASP, разработанный для контекстов безопасности приложений и анализа компонентов цепочки поставок, обеспечивающий инвентаризацию всех компонентов программного обеспечения как собственных, так и сторонних производителей.
Порядок установки#
Шаг 1. Установка необходимой ролевой модели для работы продукта
Шаг 2. Сборка и установка бинарных файлов
Шаг 3. Развертывание сервисов c помощью Helm чарта
Шаг 1. Установка необходимой ролевой модели для работы продукта#
Примечание: данный шаг применим только для компонента AUSC. Необходимые ролевые модели для работы компонентов PREM и WLDT не предусмотрены.
Цель выполнения#
Настроить ролевую модель для компонента, чтобы обеспечить его работу в пространстве имен .
Последовательность действий#
Для ручной установки ролевой модели добавьте приложения «Adapter» и «Controller», можно воспользоваться шаблоном ниже. Для установки через helm chart доступен один из двух вариантов:
Использование кастомных средств развертывания ролей в рамках папки custom-role-model.
Использование конфигураций в рамках папки ext-role-model (ВНИМАНИЕ! У вас в данной папке может не быть ни одной конфигурации, в этом случае рекомендуется первый вариант).
Приложение «Adapter»#
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: autoscalerHPAMetricsReader
rules:
- apiGroups:
- "external.metrics.k8s.io"
resources:
- synapse_autoscaler_scaler_replicas
verbs:
- get
- list
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: autoscaler-system-auth-delegator
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: system:auth-delegator
subjects:
- kind: ServiceAccount
name: synai-adapter
namespace: {{.Release.Namespace}}
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: autoscaler-auth-reader
namespace: kube-system
subjects:
- kind: ServiceAccount
name: synai-adapter
namespace: {{.Release.Namespace}}
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: extension-apiserver-authentication-reader
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: autoscalerHPAMetricsReader
namespace: {{$ns}}
subjects:
- kind: ServiceAccount
name: horizontal-pod-autoscaler
namespace: kube-system
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: autoscalerHPAMetricsReader
Приложение «Controller»#
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: synai-autoscaler-controller
labels:
{{- include "addVersionComponentInfo" . | nindent 4 }}
rules:
- apiGroups:
- ""
resources:
- limitranges
- pods
verbs:
- get
- list
- watch
- apiGroups:
- ""
resources:
- events
verbs:
- create
- patch
- apiGroups:
- apps
resources:
- deployments/scale
- statefulsets/scale
verbs:
- get
- list
- patch
- update
- watch
- apiGroups:
- apps
resources:
- deployments
- statefulsets
verbs:
- get
- list
- watch
- apiGroups:
- autoscaling
resources:
- horizontalpodautoscalers
verbs:
- create
- delete
- get
- list
- patch
- update
- watch
- apiGroups:
- autoscaler.synapse.sber
resources:
- scaledobjects
verbs:
- get
- list
- watch
- patch
- update
- apiGroups:
- autoscaler.synapse.sber
resources:
- scaledobjects/finalizers
- scaledobjects/status
verbs:
- get
- list
- patch
- update
- watch
- apiGroups:
- autoscaler.synapse.sber
resources:
- projectcapacitypolicies
verbs:
- get
- list
- watch
- apiGroups:
- autoscaler.synapse.sber
resources:
- projectcapacitypolicies/status
verbs:
- update
- verbs:
- list
apiGroups:
- metrics.k8s.io
resources:
- pods
---
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: synai-autoscaler-controller-minimal
namespace: {{ .Release.Namespace }}
labels:
{{- include "addVersionComponentInfo" . | nindent 4 }}
rules:
- verbs:
- get
- list
- watch
- create
- update
- patch
- delete
apiGroups:
- coordination.k8s.io
resources:
- leases
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: synai-autoscaler-controller-minimal
namespace: {{ .Release.Namespace }}
labels:
{{- include "addVersionComponentInfo" . | nindent 4 }}
subjects:
- kind: ServiceAccount
name: synai-controller
namespace: {{ .Release.Namespace }}
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: synai-autoscaler-controller-minimal
{{- if eq .Values.ownNamespaceScope "true" }}
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: synai-autoscaler-controller
labels:
{{- include "addVersionComponentInfo" . | nindent 4 }}
subjects:
- kind: ServiceAccount
name: synai-controller
namespace: {{ .Release.Namespace }}
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: synai-autoscaler-controller
Проверка результата#
Если всё выполнено верно:
Role и RoleBinding существуют в указанном namespace.
ServiceAccount имеет необходимые права.
AUSC успешно взаимодействует с ресурсами в наблюдаемых namespace’ах.
Шаг 2. Сборка и установка бинарных файлов#
Цель выполнения#
Цель выполнения шага - подготовить бинарные файлы приложения, собрать их в контейнерный образ (image) и интегрировать его в конфигурации установки, чтобы обеспечить корректную работу системы.
Последовательность действий#
Используйте инструменты сборки, чтобы создать исполняемые файлы или артефакты.
Скомпилируйте Docker-образ, включающий собранные бинарные файлы.
docker build -t my-app-image:latest
Обновите конфигурационные файлы (например, Helm-chart, Kubernetes Deployment), указав новый образ:
image:
repository: your-registry/my-app-image
tag: latest
Проверка результата#
Если всё выполнено верно, система будет использовать актуальный образ с собранными бинарными файлами, и конфигурации установки будут работать без ошибок.
Шаг 3. Развертывание сервисов c помощью Helm чарта#
Цель выполнения#
Цель выполнения шага - развернуть сервисы с использованием Helm-чарта, используя подготовленный Docker-образ с бинарными файлами, чтобы обеспечить корректную работу системы в кластере Kubernetes.
Последовательность действий#
Убедитесь, что Helm-чарт существует и содержит конфигурации для развертывания сервисов.
Установите зависимости Helm-чарта.
Выполните команду для установки чарта в кластер Kubernetes:
helm install my-release ./path/to/chart --namespace my-namespace
Проверка результата#
Если всё выполнено верно:
Helm-релиз будет отображаться в списке (helm list).
Все поды будут работать без ошибок.
Сервис будет доступен по указанному endpoint’у.