---
metadata:
  - name: generator
    content: Diplodoc Platform v5.63.0
alternate:
  - ru/cookbook/common-issues
  - href: ru/cookbook/common-issues.md
    type: text/markdown
    title: Markdown version
csp:
  - script-src:
      - https://mc.yandex.ru
    img-src:
      - https://mc.yandex.ru
    connect-src:
      - https://mc.yandex.ru
      - wss://mc.yandex.ru
    child-src:
      - 'blob:'
      - https://mc.yandex.ru
    frame-src:
      - 'blob:'
      - https://mc.yandex.ru
    frame-ancestors:
      - 'blob:'
      - https://mc.yandex.ru
canonical: ru/cookbook/common-issues.html
title: Типовые проблемы DataLens On-premises
description: >-
  В статье собраны типовые проблемы, с которыми вы можете столкнуться при
  использовании DataLens On-premises, и варианты их решения.
vcsPath: ru/cookbook/common-issues.md
---

# Типовые проблемы

Здесь собраны типовые проблемы, с которыми вы можете столкнуться при использовании DataLens On-premises, и варианты их решения.

## Типовые проблемы {#issues}

1. Сброс ключа шифрования `CONTROL_API_CRYPTO_KEY`.
1. Запуск на Oracle Linux 8/9 (RHEL).
1. Развертывание через Argo CD.
1. Замена стандартных портов Ingress-контроллера Traefik.
1. Редиректы с HTTP на HTTPS.

## Сброс ключа шифрования `CONTROL_API_CRYPTO_KEY` {#reset-crypto-key}

В логах control-api появляется ошибка `InvalidSignature: Signature did not match digest`.

Если используется подключение к внешней базе:

```shell
#!/bin/bash
set -eo pipefail

# fill this values
CONTROL_API_CRYPTO_KEY="..."
POSTGRES_HOST="..."
POSTGRES_PORT="..."
POSTGRES_USER_US="..."
POSTGRES_DB_US="..."
POSTGRES_PASSWORD_US="..."
# fill this values

cat >./crypto.py <<EOL
import sys
from cryptography.fernet import Fernet
def main():
  fernet = Fernet(sys.argv[1])
  encrypted = fernet.encrypt(sys.argv[2].encode('utf-8')).decode()
  print(encrypted)
main()
EOL

export PGPASSWORD="${POSTGRES_PASSWORD_US}"
NULL_PASSWORD=$(python3 ./crypto.py "${CONTROL_API_CRYPTO_KEY}" null)

psql \
  --host "${POSTGRES_HOST}" \
  --port "${POSTGRES_PORT}" \
  --username "${POSTGRES_USER_US}" \
  --dbname "${POSTGRES_DB_US}" <<-EOSQL
  UPDATE entries SET unversioned_data = jsonb_set(unversioned_data, '{password,cypher_text}', '"${NULL_PASSWORD}"', true) WHERE unversioned_data #> '{password,cypher_text}' IS NOT NULL;
  UPDATE entries SET unversioned_data = jsonb_set(unversioned_data, '{token,cypher_text}', '"${NULL_PASSWORD}"', true) WHERE unversioned_data #> '{token,cypher_text}' IS NOT NULL;
EOSQL
```

Если база встроенная:

```shell
./init.sh --pg /init/us-restore.sh --reset-crypto-key
```

### Решение

Проблема связана с ключом шифрования подключений, который хранится в секрете в переменной `CONTROL_API_CRYPTO_KEY`. Необходимо вернуть старый ключ либо выполнить сброс ключа вручную через скрипт `./init.sh --pg /init/us-restore.sh --reset-crypto-key`.

Если ключ шифрования был изменен, то все подключения остаются зашифрованными старым ключом.

При сложностях с выполнением скрипта через `./init.sh` можно собрать скрипт вручную:

```shell
#!/bin/bash
set -eo pipefail

# fill this values
CONTROL_API_CRYPTO_KEY="..."
POSTGRES_HOST="..."
POSTGRES_PORT="..."
POSTGRES_USER_US="..."
POSTGRES_DB_US="..."
POSTGRES_PASSWORD_US="..."
# fill this values

cat >./crypto.py <<EOL
import sys
from cryptography.fernet import Fernet
def main():
  fernet = Fernet(sys.argv[1])
  encrypted = fernet.encrypt(sys.argv[2].encode('utf-8')).decode()
  print(encrypted)
main()
EOL

export PGPASSWORD="${POSTGRES_PASSWORD_US}"
NULL_PASSWORD=$(python3 ./crypto.py "${CONTROL_API_CRYPTO_KEY}" null)

psql \
  --host "${POSTGRES_HOST}" \
  --port "${POSTGRES_PORT}" \
  --username "${POSTGRES_USER_US}" \
  --dbname "${POSTGRES_DB_US}" <<-EOSQL
  UPDATE entries SET unversioned_data = jsonb_set(unversioned_data, '{password,cypher_text}', '"${NULL_PASSWORD}"', true) WHERE unversioned_data #> '{password,cypher_text}' IS NOT NULL;
  UPDATE entries SET unversioned_data = jsonb_set(unversioned_data, '{token,cypher_text}', '"${NULL_PASSWORD}"', true) WHERE unversioned_data #> '{token,cypher_text}' IS NOT NULL;
EOSQL
```

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

## Запуск на Oracle Linux 8/9 (RHEL) {#oracle-linux-8}

Для запуска K3s на Oracle Linux 8 необходимо либо полностью отключить firewalld, либо настроить в файрволе правила для корректной работы сети Kubernetes.

Основные порты, которые требуются для работы K3s:

* 6443/tcp — основной API-сервер Kubernetes (master);
* 2379–2380/tcp — etcd (для многомастерной установка);
* 10250/tcp — kubelet API;
* 8472/udp — VXLAN (Flunnel-сеть, если используется);
* 30000–32767/tcp — диапазон портов для NodePort-сервисов.

### Решение

**Вариант 1**. Отключить firewalld:

```shell
sudo systemctl stop firewalld
sudo systemctl disable firewalld
```

**Вариант 2**. Добавить правила для нужных портов или для сетевых интерфейсов.

Пример для firewalld:

```shell
# traffic between k8s pod network subnets
sudo firewall-cmd --permanent --zone=trusted --add-source=10.42.0.0/16
sudo firewall-cmd --permanent --zone=trusted --add-source=10.43.0.0/16
# or
sudo firewall-cmd --permanent --zone=trusted --add-interface=cni0
sudo firewall-cmd --permanent --zone=trusted --add-interface=flannel.1


# k8s api server access for all nodes (optional)
sudo firewall-cmd --permanent --add-port=6443/tcp
# client requests to etcd and peer communication between etcd members (optional)
sudo firewall-cmd --permanent --add-port=2379-2380/tcp
# kubelet api port on each node (optional)
sudo firewall-cmd --permanent --add-port=10250/tcp
# flannel vxlan pod network communication (optional)
sudo firewall-cmd --permanent --add-port=8472/udp
# node port external traffic (optional)
sudo firewall-cmd --permanent --add-port=30000-32767/tcp

sudo firewall-cmd --reload
```

{% note tip %}

Если файрвол не мешает работе, предпочтительнее настроить только необходимые порты вместо полного его отключения. Это поможет сохранить базовую безопасность системы при допустимых настройках для Kubernetes.

{% endnote %}

## Развертывание через Argo CD {#argo-cd}

В Argo CD есть проблема с использованием функции `lookup` — отсутствует проверка существования секрета.

Подробнее о функции `lookup`:

* [https://github.com/argoproj/argo-cd/issues/5202](https://github.com/argoproj/argo-cd/issues/5202)
* [https://github.com/argoproj/argo-cd/issues/21745](https://github.com/argoproj/argo-cd/issues/21745)

### Решение

Чтобы избежать проблем при обновлении, нужно вручную указать ссылку на ресурс с секретами через values в `secrets.ref`:


![image](../_assets/datalens/cookbook/argo.png)


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

## Замена стандартных портов Ingress-контроллера Traefik {#ports-config}

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

`/var/lib/rancher/k3s/server/manifests/traefik-config.yaml`

Содержимое файла:

```yaml
apiVersion: helm.cattle.io/v1
kind: HelmChartConfig
metadata:
  name: traefik
  namespace: kube-system
spec:
  valuesContent: |-
    ports:
      web:
        exposedPort: 80
      websecure:
        exposedPort: 443
```

Порты 80 и 443 — внешние порты Ingress-контроллера.

После сохранения файла изменения автоматически применятся. Сервис K3s автоматически отслеживает эту директорию с манифестами и сам обновит Traefik (Ingress).

Порт 443 все еще будет доступен до момента перезагрузки сервиса Traefik. Для принудительного обновления выполните команду:

```shell
sudo k3s kubectl rollout restart deployment traefik -n kube-system
```

## Редиректы с HTTP на HTTPS {#https-redirect}

При использовании nginx-контроллера аннотация Kubernetes, которая автоматически перенаправляет все HTTP-запросы на HTTPS, выглядит так:

```shell
nginx.ingress.kubernetes.io/ssl-redirect: "true"
```

### Ошибка: не работает загрузка файлов

Не работает загрузка файлов на домене первого (верхнего) уровня (TLD), например `datalensnb`:


![image](../_assets/datalens/cookbook/file-upload-error.png)


### Решение

Всегда использовать домен второго уровня, например `datalens.nb`.

### Ошибка: проблемный релиз

Проблемный релиз, релиз завис в статусе `Error: UPGRADE FAILED: another operation (install/upgrade/rollback) is in progress`.

### Решение

1. Получите последний удачный релиз:

    ```shell
    ./bin/helm-amd64 -n datalens-enterprise history datalens-enterprise | grep 'Upgrade complete' | tail -n1
    ```

1. Определите номер релиза, в данном случае 11:

    ```shell
    11          Jun 18 10:00:30 2025    deployed    datalens-enterprise-0.0.4    25.9.0    Upgrade complete
    ```

1. Откатитесь к последнему удачному релизу:

    ```shell
    ./bin/helm-amd64 -n datalens-enterprise rollback datalens-enterprise 11
    ```

1. Заново запустите нужный релиз через `./init.sh`.

## Итоги {#results}

Вы узнали о типовых проблемах при работе с сервисом и способах их решения. Далее мы перечислим полезные команды, которые пригодятся при поддержке DataLens.