Установка для промышленной эксплуатации
Гибкая настройка конфигурации через файл values.yaml
При промышленной эксплуатации с множеством настроек целесообразно использовать файл values.yaml для указания аргументов и настроек развертывания.
Важно
Никогда не редактируйте ./helm/values.yaml напрямую! Иначе при ошибке в файле нарушится работа сервиса.
Для редактирования скопируйте файл ./helm/values.yaml и работайте с ним. Так вы всегда сможете вернуться к изначальной конфигурации. Затем передайте путь к вашему файлу через аргумент --values. Пример заполнения и форматирования файла можно найти в ./help/values.example.yaml.
При использовании параметра --values все остальные аргументы, переданные в скрипт ./init.sh и связанные с конфигурацией развертывания дистрибутива, проигнорируются. Скрипт будет считать аргументы из вашего файла приоритетными, а недостающие аргументы будут браться из оригинального ./helm/values.yaml, который является частью базового шаблона развертывания.
cp ./help/values.example.yaml ./my-prod-values.yaml
# ... отредактируйте my-prod-values.yaml ...
./init.sh --values ./my-prod-values.yaml
При обновлениях DataLens значения настроек по умолчанию в ./helm/values.yaml могут меняться, поэтому мы рекомендуем оставить в вашем собственном файле только те настройки, которые вы переопределяете и которые отвечают за использование функциональных возможностей.
Использование параметра --values-merge
Для использования настроек из файла values.yaml совместно с аргументами командной строки используйте параметр --values-merge. Такое развертывание может быть полезно для выполнения разовых операций вроде генерации сертификатов или запуска с отдельными функциональными возможностями при общих настройках из values.yaml.
cp ./helm/values.yaml ./my-prod-values.yaml
# ... отредактируйте my-prod-values.yaml ...
./init.sh --values ./my-prod-values.yaml --ingress-domain <domain> --ingress-tls --ingress-tls-gen --values-merge
Совет
Аргументы из values.yaml перекрываются аргументами, заданными с --values-merge. Прочие аргументы принимают значения по умолчанию. Например, если не указать --ingress-domain, будет взято значение datalens.enterprise.
Перечень аргументов и их значений по умолчанию приведены в разделе «Доступные аргументы развертывания» статьи «Установка и запуск DataLens On-premises».
Обзор сервисов дистрибутива и их сетевого взаимодействия
DataLens — это набор микросервисов. Скрипт установки развернет их в Kubernetes. Внешний трафик от пользователя пройдет на Ingress-контроллер, который направит его на сервис ui. Далее ui будет взаимодействовать с бэкенд-сервисами (us, control_api, data_api) по внутренним сетевым именам Kubernetes.
Наглядно это можно отразить на схеме:

Развертывание с внешним кластером PostgreSQL
Встроенная БД для промышленной эксплуатации — неэффективная практика. Нужно использовать внешний управляемый кластер PostgreSQL. При большом количестве пользователей это позволит гибко работать с объектами сервиса и выстроить отказоустойчивую архитектуру.
Алгоритм действий
-
В файле
my-prod-values.yamlотключите встроенный PostgreSQL.infra: postgres: enabled: false # Отключите встроенный PostgreSQL -
В том же файле в секции
postgresукажите параметры подключения к внешнему кластеру.postgres: POSTGRES_HOST: 'your-pg-host.db.example.com' POSTGRES_PORT: '5432' # ... и другие параметры пользователей и баз, если они отличаются от стандартных -
На старте пароли можно указать в
./init.sh, но это небезопасно — лучше передавать их через секреты.
При запуске установки с таким values.yaml DataLens не будет создавать свой под с PostgreSQL, а сразу подключится к указанному внешнему кластеру.
Использование собственных TLS-сертификатов
Самоподписанные сертификаты подходят для тестирования, но в промышленной эксплуатации браузеры покажут пользователям предупреждения — нужно использовать сертификаты, выпущенные вашим корпоративным или публичным центром сертификации (CA).
Для этого используются аргументы --ingress-tls-crt и --ingress-tls-key.
./init.sh \
--k3s-install \
--ingress-domain datalens.mycompany.com \
--ingress-tls \
--ingress-tls-crt /path/to/your/cert.pem \
--ingress-tls-key /path/to/your/private.key
Скрипт сохранит эти сертификаты в секреты Kubernetes, и Ingress-контроллер использует их для терминирования TLS-трафика.
Сертификаты можно и непосредственно прописать в файл values.yaml.
Подробнее о секретах можно прочитать в статье Секреты DataLens On-premises.
Рекомендации по проектированию отказоустойчивой архитектуры
Высокая доступность (High Availability, или HA) достигается за счет дублирования компонентов. В Kubernetes это можно сделать через увеличение количества реплик.
В файле values.yaml есть секция application, в которой для каждого сервиса можно указать replicas.
application:
control_api:
replicas: 2 # Запустите два экземпляра control-api — сервиса управления подключениями и датасетами
data_api:
replicas: 3 # Запустите три экземпляра data-api — сервиса, который обращается в источник
us:
replicas: 2 # Запустите два экземпляра us — сервиса для хранения метаданных
# ... и так далее
Рекомендации по масштабированию
Начинайте масштабировать самые нагруженные компоненты: data_api, control_api, us.
Для полноценного HA нужен отказоустойчивый кластер Kubernetes из нескольких нод (серверов). Установка с флагом --k3s-install создает кластер из одной ноды и не является отказоустойчивой.
Используйте внешний отказоустойчивый кластер PostgreSQL и Redis.
Итоги
Вы разобрали важные аспекты установки DataLens для промышленной эксплуатации. Теперь вы знаете, как управлять конфигурацией через values.yaml и подключать внешние системы.