Установка для промышленной эксплуатации

Гибкая настройка конфигурации через файл 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.

Наглядно это можно отразить на схеме:

image

Развертывание с внешним кластером PostgreSQL

Встроенная БД для промышленной эксплуатации — неэффективная практика. Нужно использовать внешний управляемый кластер PostgreSQL. При большом количестве пользователей это позволит гибко работать с объектами сервиса и выстроить отказоустойчивую архитектуру.

Алгоритм действий

  1. В файле my-prod-values.yaml отключите встроенный PostgreSQL.

    infra:
    postgres:
        enabled: false # Отключите встроенный PostgreSQL
    
  2. В том же файле в секции postgres укажите параметры подключения к внешнему кластеру.

    postgres:
    POSTGRES_HOST: 'your-pg-host.db.example.com'
    POSTGRES_PORT: '5432'
    # ... и другие параметры пользователей и баз, если они отличаются от стандартных
    
  3. На старте пароли можно указать в ./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 и подключать внешние системы.