Перейти до змісту

Посібник зі встановлення digna Release 2026.11 на Linux

Випуск: 2026.11

Останнє оновлення: 7 листопада 2026 р.


Зміст

  1. Вступ
  2. Системні вимоги
  3. Підготовка до встановлення
  4. Налаштування сервера PostgreSQL
  5. Налаштування веб‑сервера
  6. Початкове встановлення
  7. Налаштування серверної частини
  8. Налаштування панелі
  9. Запуск digna як служби systemd
  10. Оновлення до нового випуску

Вступ

Про digna

digna — це комплексна платформа на основі AI, призначена для оптимізації управління якістю даних у різних середовищах даних, таких як сховища даних (warehouses), озера даних (lakes) і lakehouses. Побудована з розрахунком на високу масштабованість та адаптивність, digna вирішує сучасні завдання роботи з даними завдяки автоматизації, моніторингу в реальному часі та виявленню аномалій.

digna складається з двох основних компонентів:

  • digna: ядро застосунку, відповідальне за обробку даних і виконання перевірок якості. Воно поєднує серверну частину та інтерфейс командного рядка в одному виконуваному файлі, замінюючи окремі програми dignabackend і dignacli з попередніх випусків.
  • dignadashboard: веб‑інтерфейс, розміщений на веб‑сервері, що забезпечує зручний спосіб взаємодії з платформою digna та візуалізації метрик якості даних.

Що нового в Release 2026.11

Цей випуск додає digna Data Reconciliation, digna Agentic із digna MCP Server, а також digna Engine, який може профілювати дані всередині digna та перевіряти референтну цілісність між різними технологіями баз даних. Повні відомості див. у примітках до випуску.

Для встановлення випуск приносить новий механізм міграції репозиторію, необов'язковий розділ [duckdb] у config.toml для digna Engine і новий файл ліцензії. Кожну з цих змін описано в розділі про оновлення.

Шукаєте Windows або macOS?

Цей посібник охоплює Linux. Для інших платформ див. Посібник зі встановлення на Windows або Посібник зі встановлення на macOS.

Які дистрибутиви охоплює цей посібник?

Інструкції написано для двох найпоширеніших сімейств серверних дистрибутивів. Там, де вони відрізняються, наведено обидві команди:

  • Сімейство Debian — Debian, Ubuntu. Менеджер пакетів: apt.
  • Сімейство RHEL — Red Hat Enterprise Linux, Rocky Linux, AlmaLinux, Fedora. Менеджер пакетів: dnf.

Підійде будь-який сучасний дистрибутив із systemd; змінюються лише назви пакетів і кілька шляхів конфігурації.


Системні вимоги

Перш ніж почати встановлення, переконайтеся, що ваша система відповідає таким мінімальним вимогам:

Вимога Специфікація
Операційна система Ubuntu 22.04 LTS або новіша, Debian 12 або новіша, RHEL 9 / Rocky 9 / AlmaLinux 9 або новіша
Архітектура x86_64 (amd64) або arm64
Система ініціалізації systemd
Пам'ять (мінімальна конфігурація) 16 GB RAM
Дисковий простір 10 GB вільного місця
База даних PostgreSQL Server 12 або новіший
Веб‑сервер nginx, Apache httpd або аналог

digna Engine

Підключення до баз даних, які використовують digna Engine як місце профілювання, профілюються на самому хості digna. Заплануйте для них додаткові пам'ять і дисковий простір, див. розділ [duckdb].

Варіанти встановлення бази даних

Якщо PostgreSQL уже встановлено: Ви можете додати нову базу даних для digna до наявного сервера PostgreSQL.

Якщо PostgreSQL встановлюється на тій самій машині, що й digna:

Рекомендовані характеристики

  • Пам'ять: 32 GB RAM (замість 16 GB)
  • Дисковий простір: 50 GB вільного місця (замість 10 GB)

Ці підвищені характеристики розраховані на одночасну роботу digna та бази даних PostgreSQL.

Перевірка дистрибутива та архітектури

Кілька команд у цьому посібнику відрізняються для сімейств Debian і RHEL. Щоб перевірити, яке у вас, виконайте:

cat /etc/os-release
uname -m
  • ID=ubuntu або ID=debian — використовуйте команди apt.
  • ID=rhel, rocky, almalinux або fedora — використовуйте команди dnf.
  • x86_64 або aarch64 — архітектура інсталяційного пакета, який вам потрібен.

Підготовка до встановлення

Перед встановленням digna переконайтеся, що наявні дві ключові передумови:

  1. Сервер PostgreSQL – для зберігання обчислених метрик і даних про продуктивність
  2. Веб‑сервер – для розміщення панелі digna (digna Dashboard)

Якщо ці компоненти ще не налаштовано, скористайтеся наведеними нижче розділами, щоб установити та налаштувати їх.

Оновлення індексу пакетів

Перш ніж щось установлювати, оновіть списки пакетів:

sudo apt update
sudo dnf check-update

Примітка

У всьому цьому посібнику перша команда з пари призначена для сімейства Debian, а друга — для сімейства RHEL. Виконуйте лише ту, що відповідає вашій системі.


Налаштування сервера PostgreSQL

Якщо у вас уже є PostgreSQL

Якщо PostgreSQL уже встановлено й запущено на вашій локальній машині або ви використовуєте керований віддалений сервер PostgreSQL, можете перейти до наступного розділу.

Встановлення PostgreSQL

Крок 1: Встановіть пакет сервера

sudo apt install -y postgresql postgresql-contrib
sudo dnf install -y postgresql-server postgresql-contrib

Порада

Пакети дистрибутива можуть відставати від поточного випуску PostgreSQL. Якщо вам потрібна конкретна новіша версія, використовуйте натомість офіційний репозиторій PostgreSQL для apt або yum.

Крок 2: Ініціалізуйте кластер бази даних

У сімействі Debian пакет автоматично створює та запускає кластер — переходьте до наступного кроку.

У сімействі RHEL кластер потрібно створити явно:

sudo postgresql-setup --initdb

Крок 3: Запустіть службу й увімкніть автозапуск

sudo systemctl enable --now postgresql

Ця команда одразу запускає PostgreSQL і налаштовує його автоматичний запуск під час завантаження системи.

Крок 4: Перевірте встановлення

psql --version
sudo systemctl status postgresql

Ви повинні побачити версію PostgreSQL і службу в стані active (running).

Крок 5: Підключіться до сервера

Пакет PostgreSQL для Linux створює системний обліковий запис postgres, якому належить кластер. Підключайтеся через нього:

sudo -u postgres psql

Примітка — тут Linux відрізняється від Windows

Інсталятор для Windows під час налаштування пропонує задати пароль суперкористувача postgres. Пакети для Linux цього не роблять. Натомість локальні підключення автентифікуються за допомогою peer‑автентифікації: користувачеві операційної системи postgres дозволено підключатися як користувач бази даних postgres без пароля.

Саме тому команда вище використовує sudo -u postgres. Серверна частина digna підключається через TCP з ім'ям користувача та паролем, тож ви створите окремого користувача digna в розділі Початкове встановлення.

Крок 6: Перевірте порт

Стандартний порт PostgreSQL — 5432. Щоб перевірити, який порт прослуховує ваш сервер:

sudo -u postgres psql -c "SHOW port;"

Запишіть це значення — воно знадобиться під час налаштування серверної частини digna.

Крок 7: Увімкніть автентифікацію за паролем для користувача digna

digna підключається до PostgreSQL через TCP як digna_user, що потребує автентифікації за паролем, а не peer‑автентифікації. Переконайтеся, що ваш pg_hba.conf це дозволяє.

Знайдіть файл:

sudo -u postgres psql -c "SHOW hba_file;"

Відкрийте його в редакторі й переконайтеся, що рядки для локального TCP використовують scram-sha-256 (або md5 на старіших серверах), а не ident:

# TYPE  DATABASE  USER  ADDRESS         METHOD
host    all       all   127.0.0.1/32    scram-sha-256
host    all       all   ::1/128         scram-sha-256

Після будь-яких змін перезавантажте конфігурацію PostgreSQL:

sudo systemctl reload postgresql

Важливо

Якщо digna повідомляє FATAL: Ident authentication failed for user "digna_user", причина саме в цьому налаштуванні.

Крок 8: Якщо PostgreSQL працює на іншій машині

Щоб приймати підключення з іншого хоста, задайте listen_addresses у postgresql.conf і додайте відповідний рядок host для вашої мережі в pg_hba.conf:

listen_addresses = '*'

Потім відкрийте порт у брандмауері та перезапустіть службу:

sudo ufw allow 5432/tcp
sudo firewall-cmd --permanent --add-port=5432/tcp && sudo firewall-cmd --reload
sudo systemctl restart postgresql


Налаштування веб‑сервера

digna потребує веб‑сервера для розміщення панелі. Виберіть один із таких варіантів:

  • nginx — легкий і рекомендований
  • Apache httpd — широко поширена альтернатива

Потрібно встановити й налаштувати лише один із цих серверів.

Обидва розділи налаштовують дві речі, від яких залежить панель:

  • Резервний маршрут для односторінкового застосунку (SPA fallback), щоб оновлення URL панелі не повертало 404
  • Тип MIME для .md, щоб файли Markdown віддавалися коректно

Налаштування nginx

Огляд

nginx — легкий високопродуктивний веб‑сервер, що добре підходить для віддавання статичної панелі digna.

Встановлення

sudo apt install -y nginx
sudo dnf install -y nginx

Запуск nginx

sudo systemctl enable --now nginx

Перевірте встановлення

  1. Відкрийте браузер
  2. Перейдіть за адресою http://localhost
  3. Ви повинні побачити сторінку привітання nginx

Відкриття брандмауера

Якщо до сервера звертаються з інших машин, дозвольте трафік HTTP:

sudo ufw allow 'Nginx Full'
sudo firewall-cmd --permanent --add-service=http && sudo firewall-cmd --reload

Налаштування сайту для панелі

В обох сімействах дистрибутивів nginx підключає кожен файл зі свого каталогу conf.d. Створіть там окремий файл конфігурації для digna:

sudo nano /etc/nginx/conf.d/digna.conf

Вставте наведене нижче, замінивши /opt/digna/dashboard фактичним шляхом до розпакованої теки dashboard:

server {
    listen       80 default_server;
    listen       [::]:80 default_server;
    server_name  _;

    root   /opt/digna/dashboard;
    index  index.html;

    # Serve Markdown files with the correct MIME type.
    types {
        text/markdown  md;
    }

    # Single-page-application fallback: unknown paths return index.html
    # instead of a 404, so dashboard routes survive a browser refresh.
    location / {
        try_files $uri $uri/ /index.html;
    }
}

Важливо

Без директиви try_files перезавантаження будь-якої сторінки панелі, окрім кореневого URL, повертає 404. Це відповідник модуля URL Rewrite, якого потребує IIS у Windows.

Вимкніть сайт за замовчуванням

Лише один блок server може бути default_server для порту. У сімействі Debian видаліть стандартний сайт із пакета, щоб він не конфліктував:

sudo rm /etc/nginx/sites-enabled/default

У сімействі RHEL закоментуйте або видаліть блок server { ... } у /etc/nginx/nginx.conf.

Застосуйте конфігурацію

Перевірте конфігурацію на синтаксичні помилки, а потім перезавантажте nginx:

sudo nginx -t
sudo systemctl reload nginx

Налаштування Apache httpd

Огляд

Apache httpd доступний у стандартних репозиторіях кожного підтримуваного дистрибутива. У сімействі Debian пакет називається apache2, а в сімействі RHEL — httpd.

Встановлення

sudo apt install -y apache2
sudo dnf install -y httpd

Запуск Apache

sudo systemctl enable --now apache2
sudo systemctl enable --now httpd

Перевірте встановлення

  1. Відкрийте браузер
  2. Перейдіть за адресою http://localhost
  3. Ви повинні побачити стандартну сторінку Apache вашого дистрибутива

Обов'язково: увімкніть mod_rewrite

Панель потребує перезапису URL.

У сімействі Debian увімкніть модуль і перезапустіть сервер:

sudo a2enmod rewrite
sudo systemctl restart apache2

У сімействі RHEL mod_rewrite завантажується за замовчуванням. Переконайтеся в цьому:

httpd -M | grep rewrite

Обов'язково: дозвольте перевизначення через .htaccess

Відкрийте файл конфігурації для кореневого каталогу документів:

sudo nano /etc/apache2/apache2.conf
sudo nano /etc/httpd/conf/httpd.conf

Знайдіть блок <Directory>, що охоплює кореневий каталог документів (/var/www/html в обох сімействах), і змініть:

AllowOverride None

на:

AllowOverride All

Обов'язково: тип MIME для файлів Markdown

У тому самому файлі додайте такий рядок, щоб файли Markdown віддавалися коректно:

AddType text/markdown .md

Важливо

Без цього налаштування файли .md можуть віддаватися некоректно.

Застосуйте конфігурацію

Перевірте конфігурацію на синтаксичні помилки, а потім перезапустіть Apache:

sudo apachectl configtest
sudo systemctl restart apache2
sudo apachectl configtest
sudo systemctl restart httpd


Початкове встановлення

Крок 1: Налаштуйте репозиторій digna

Репозиторій digna зберігає всі метрики, обчислені digna. Він слугує центральною базою даних для аналітичних даних і даних про продуктивність.

Створіть схему репозиторію та користувача

Відкрийте свій клієнт PostgreSQL (psql, pgAdmin або подібний) і виконайте такі SQL‑команди:

CREATE SCHEMA <digna_repo_schema>;

CREATE USER <digna_repo_user> WITH PASSWORD '<digna_repo_password>';

GRANT ALL PRIVILEGES ON SCHEMA <digna_repo_schema> TO <digna_repo_user>;

Замініть такі заповнювачі:

  • <digna_repo_schema> — бажана назва схеми (наприклад, dignarepo)
  • <digna_repo_user> — бажане ім'я користувача (наприклад, digna_user)
  • <digna_repo_password> — надійний пароль для цього користувача

Приклад:

CREATE SCHEMA dignarepo;

CREATE USER digna_user WITH PASSWORD 'YourSecurePassword123!';

GRANT ALL PRIVILEGES ON SCHEMA dignarepo TO digna_user;

Щоб виконати їх з оболонки за один крок:

sudo -u postgres psql

Потім вставте оператори в запрошенні postgres=# і введіть \q, щоб вийти.

Найкраща практика

Використовуйте надійні, складні паролі для користувачів бази даних. Уникайте облікових даних, які легко вгадати.


Крок 2: Розпакуйте інсталяційний пакет digna

  1. Знайдіть наданий вам ZIP‑файл інсталяції digna
  2. Розпакуйте його в бажане місце встановлення — наприклад, /opt/digna
  3. Після розпакування ви побачите такі елементи:
  4. dashboard/ — веб‑інтерфейс панелі
  5. digna — основний виконуваний файл (серверна частина та CLI разом)

Файли конфігурації та ліцензії не входять до пакета

Ні config.toml, ні dashboard/dashboard_config.toml не постачаються разом зі встановленням — ви створюєте обидва файли самостійно, у розділах Налаштування серверної частини і Налаштування панелі. license.toml також не постачається; digna надає його окремо, як описано в кроці 3.

Щоб розпакувати з оболонки:

sudo mkdir -p /opt/digna
sudo unzip digna-2026.11-linux-x86_64.zip -d /opt/digna

Примітка

Якщо unzip не встановлено, додайте його командою sudo apt install -y unzip або sudo dnf install -y unzip.

Зробіть файл виконуваним

Залежно від того, як передавався архів, біт виконання може не зберегтися після розпакування. Задайте його явно:

cd /opt/digna
sudo chmod +x digna

Створіть службовий обліковий запис

Для production‑розгортань рекомендується запускати серверну частину від імені окремого непривілейованого користувача:

sudo useradd --system --no-create-home --shell /usr/sbin/nologin digna
sudo chown -R digna:digna /opt/digna

Примітка

У сімействі RHEL відповідний шлях до оболонки — /sbin/nologin.

Крок 3: Встановіть файл ліцензії

Важливо

Файл ліцензії не входить до інсталяційного пакета й надається digna окремо.

  1. Знайдіть наданий вам файл license.toml
  2. Скопіюйте його в кореневий каталог встановлення digna (там, де розташовані config.toml і виконуваний файл digna)

Чому це важливо: Файл ліцензії містить відомості про клієнта, дату закінчення терміну дії ліцензії та цифровий підпис. Не змінюйте цей файл — будь‑які зміни зроблять його недійсним.

Структура каталогу після налаштування:

/opt/digna/
├── config.toml         (configuration file)
├── license.toml        (YOUR LICENSE FILE - copy here)
├── digna               (main executable)
├── bin/                (service management scripts)
└── dashboard/          (web interface)
    └── (dashboard files)

Налаштування серверної частини

Крок 1: Створіть і відредагуйте файл конфігурації

Файл config_template.toml постачається у вашому каталозі встановлення digna. Потрібно лише перейменувати його на config.toml.

cd /opt/digna
sudo mv config_template.toml config.toml

Розташування: /opt/digna/config.toml

Відкрийте config.toml у текстовому редакторі й налаштуйте кожен із наведених нижче розділів.

Розділ [app]

Цей розділ налаштовує спільне використання ресурсів між джерелами (CORS) для панелі та серверної частини:

[app]
DIGNA_APP_CORS_ALLOW_ORIGINS = ["http://localhost:5173"]
DIGNA_APP_CORS_ALLOW_CREDENTIALS = true
Параметр Значення Примітки
DIGNA_APP_CORS_ALLOW_ORIGINS URL панелі URL, з яких віддається панель. Запити браузера з будь-якого іншого джерела відхиляються
DIGNA_APP_CORS_ALLOW_CREDENTIALS true Обов'язково, щоб браузер надсилав cookie сесії з кожним запитом

Примітка

Якщо ви віддаєте панель через nginx або Apache на стандартному порту HTTP, дозволити потрібно джерело http://localhost — або публічний URL сервера, якщо до панелі звертаються з інших машин.

Розділ [app] необов'язковий

Починаючи з Release 2026.11, обидва ключі, а також увесь розділ [app], можна не вказувати. Це правильне налаштування, коли зворотний проксі віддає панель і серверну частину з одного джерела: тоді браузер не робить запитів між джерелами, і за замовчуванням жоден такий запит не дозволено.

Розділ [repo]

Цей розділ налаштовує підключення до бази даних PostgreSQL:

[repo]
DIGNA_REPO_HOST = "localhost"
DIGNA_REPO_PORT = 5432
DIGNA_REPO_DB = "postgres"
DIGNA_REPO_SCHEMA = "dignarepo"
DIGNA_REPO_USER = "digna_user"
DIGNA_REPO_PASSWORD = "YourSecurePassword123!"
DIGNA_REPO_SSLMODE = "prefer"
DIGNA_REPO_NUM_CONNS = 16
Параметр Значення Примітки
DIGNA_REPO_HOST localhost або IP Ім'я хоста / IP сервера PostgreSQL
DIGNA_REPO_PORT 5432 (за замовчуванням) Порт PostgreSQL
DIGNA_REPO_DB postgres Назва бази даних
DIGNA_REPO_SCHEMA dignarepo Схема, створена раніше
DIGNA_REPO_USER digna_user Користувач, створений під час налаштування PostgreSQL
DIGNA_REPO_PASSWORD Ваш пароль Пароль, заданий під час створення схеми
DIGNA_REPO_SSLMODE prefer (за замовчуванням) Необов'язково. Режим SSL для PostgreSQL: disable, allow, prefer, require, verify-ca або verify-full
DIGNA_REPO_NUM_CONNS 16 (за замовчуванням) Необов'язково. Кількість підключень до репозиторію, які digna тримає відкритими

Найкраща практика

config.toml містить пароль до бази даних у відкритому вигляді. Обмежте права доступу до нього, щоб читати його міг лише службовий обліковий запис:

sudo chown digna:digna /opt/digna/config.toml
sudo chmod 600 /opt/digna/config.toml

Розділ [base]

Цей розділ містить параметри безпеки, cookie та інспекцій:

[base]
DIGNA_FERNET_KEY = "DU4a0yJ-OqvbKCL4hNQn_CsknH-V1vWmHZqBUl-AY44="
DIGNA_COOKIE_DOMAIN = "localhost"
DIGNA_COOKIE_SECURE = false
DIGNA_COOKIE_HTTPONLY = true
DIGNA_TOKEN_EXPIRES_IN = 86400
DIGNA_MAX_WORKERS = 4
DIGNA_FRONTEND_BASEURL = "http://localhost/"
DIGNA_SOURCE_QUERY_TIMEOUT_SEC = 3600
DIGNA_SOURCE_LOGIN_TIMEOUT_SEC = 30
Параметр Значення Примітки
DIGNA_FERNET_KEY Значення, наведене вище Ключ шифрування, яке використовували попередні випуски. Він має бути присутнім; залиште наведене значення
DIGNA_COOKIE_DOMAIN localhost Хост, за яким відкривається панель. "" не задає домену — це правильно за проксі, який віддає панель і серверну частину з одного джерела
DIGNA_COOKIE_SECURE false (HTTP) / true (HTTPS) Має бути true щоразу, коли digna працює через HTTPS
DIGNA_COOKIE_HTTPONLY true Робить cookie сесії недоступним для скриптів
DIGNA_TOKEN_EXPIRES_IN 86400 (24 години) Тайм‑аут сесії в секундах
DIGNA_MAX_WORKERS Кількість ядер CPU - 1 Кількість інспекцій, які можуть виконуватися одночасно
DIGNA_FRONTEND_BASEURL URL панелі Обов'язково. Використовується для посилань у сповіщеннях, тож це має бути URL, який одержувачі можуть відкрити
DIGNA_SOURCE_QUERY_TIMEOUT_SEC 3600 (за замовчуванням) Необов'язково. Скільки секунд може виконуватися один запит до вихідної бази даних, перш ніж його буде перервано; 0 вимикає тайм‑аут
DIGNA_SOURCE_LOGIN_TIMEOUT_SEC 30 (за замовчуванням) Необов'язково. Скільки секунд чекати на підключення до вихідної бази даних; 0 — чекати без обмежень

Порада

Щоб дізнатися кількість ядер CPU, доступних на вашому сервері, виконайте nproc.

Розділ [encryption]

Цей розділ містить ключ, яким шифруються конфіденційні значення, що зберігаються в репозиторії. Він обов'язковий — config check повідомляє про розділ [encryption] як FAILED, якщо ключа немає.

[encryption]
DIGNA_ENCRYPTION_KEY = 'ycELf6IbcO55dYIZHpPv6kQv/bbnUXoIaHLh2bh1kMg='
Параметр Значення Примітки
DIGNA_ENCRYPTION_KEY Ключ у кодуванні Base64 Шифрує конфіденційні значення, що зберігаються в репозиторії digna

Захистіть config.toml

Цей ключ — фіксоване значення, однакове в усіх установленнях digna, і саме він розшифровує конфіденційні значення у вашому репозиторії. Обмежте доступ до config.toml обліковим записом, під яким працює digna, тримайте файл поза системою контролю версій і спільними дисками та виключіть його з будь-якої резервної копії, що зберігається менш захищено, ніж сам репозиторій.

Розділ [logging]

Цей розділ налаштовує поведінку журналювання:

[logging]
DIGNA_LOGGING_MODE = "INFO"
DIGNA_LOGGING_DIR = "logs"
DIGNA_LOGGING_MAX_FILES = 30
Параметр Значення Примітки
DIGNA_LOGGING_MODE INFO або DEBUG INFO — для production, DEBUG — для усунення несправностей. Також приймаються TRACE, WARN і ERROR
DIGNA_LOGGING_DIR logs (за замовчуванням) Необов'язково. Каталог для файлів журналу з ротацією, відносно робочого каталогу
DIGNA_LOGGING_MAX_FILES 30 (за замовчуванням) Необов'язково. Кількість файлів журналу після ротації, які зберігаються

Розділ [duckdb] (необов'язковий)

Нове в Release 2026.11. Цей розділ задає ресурси digna Engine, який профілює дані всередині digna для підключень до баз даних, місцем профілювання яких є digna Engine, і виконує перевірки референтної цілісності між джерелами даних на різних підключеннях до баз даних. Див. Місце профілювання.

Розділ необов'язковий. Без нього діють наведені нижче значення за замовчуванням.

[duckdb]
DIGNA_DUCKDB_MEMORY_LIMIT_MB = 1024
DIGNA_DUCKDB_TEMP_DIRECTORY = "/opt/digna/tmp"
Параметр Значення Примітки
DIGNA_DUCKDB_MEMORY_LIMIT_MB 1024 (за замовчуванням) Пам'ять у MB, яку може використовувати один запуск digna Engine. Одночасно можуть бути активними до DIGNA_MAX_WORKERS запусків
DIGNA_DUCKDB_TEMP_DIRECTORY За замовчуванням: системний тимчасовий каталог ($TMPDIR або /tmp, якщо змінну не задано) Каталог для тимчасових файлів, коли дані не вміщаються в пам'ять

Розрахунок ресурсів для digna Engine

Заплануйте до DIGNA_MAX_WORKERS × DIGNA_DUCKDB_MEMORY_LIMIT_MB пам'яті на хості digna понад те, що використовує сама digna, а також достатньо вільного місця на диску в тимчасовому каталозі, щоб умістити дані найбільшої інспектованої дати джерел даних, які використовують digna Engine. Спрямуйте DIGNA_DUCKDB_TEMP_DIRECTORY на диск із таким обсягом вільного місця, доступний для запису обліковому запису, під яким працює digna:

sudo mkdir -p /opt/digna/tmp
sudo chown digna:digna /opt/digna/tmp

Цей розділ потрібен, лише якщо принаймні одне підключення до бази даних використовує digna Engine або перевірка референтної цілісності порівнює джерела даних на різних підключеннях.


Крок 2: Перевірте конфігурацію

Перед ініціалізацією репозиторію переконайтеся, що config.toml повний і правильно сформований. У каталозі встановлення digna виконайте:

./digna config check

Кожен розділ перевіряється окремо, тож одна помилка не приховує стан решти:

Configuration validation report (source: config.toml):
 - App config: OK
 - Repository config: OK
 - Base config: OK
 - Logging config: OK
 - Encryption config: OK
 - OIDC config(s): OK
 - Template overrides: OK
 - Unknown keys: OK

Overall: OK

Виправте все, про що повідомлено як FAILED, і виконайте команду ще раз, перш ніж продовжувати. WARNING у пункті Unknown keys перелічує ключі в config.toml, які digna не зчитує; вони ні на що не впливають, тож вилучіть їх або виправте їхнє написання. Повний перелік параметрів наведено в довіднику CLI.

Крок 3: Ініціалізуйте репозиторій

  1. Відкрийте термінал
  2. Перейдіть до каталогу встановлення digna (там, де розташовані config.toml і виконуваний файл digna)
  3. Запустіть перевірку підключення:
cd /opt/digna
./digna repo check

Для нової схеми команда підключається, а потім повідомляє, що репозиторій ще не встановлено:

Error: No repo installed. Use the 'digna repo upgrade' command to install it.

На цьому етапі це очікуваний результат: він підтверджує, що digna дістається до PostgreSQL і схеми. Натомість помилка підключення чи автентифікації вказує на розділ [repo] або на налаштування PostgreSQL.

Примітка

У Linux поточний каталог не входить до PATH, тож виконуваний файл викликається як ./digna, а не digna. Щоб скрізь використовувати коротшу форму, додайте символьне посилання:

sudo ln -s /opt/digna/digna /usr/local/bin/digna

Крок 4: Встановіть схему репозиторію

У тому самому каталозі виконайте:

./digna repo upgrade

Ця команда встановлює необхідні таблиці у схемі репозиторію й завершується повідомленням:

✅ Repo schema 'dignarepo' is up to date.

repo upgrade встановлює та оновлює

Починаючи з Release 2026.11, repo upgrade встановлює новий репозиторій і оновлює наявний. repo install і далі працює як інша назва тієї самої команди.

Крок 5: Створіть користувача‑адміністратора

Користувач‑адміністратор створюється безпосередньо у схемі репозиторію, тож сервер поки що не мусить працювати. У каталозі встановлення digna виконайте:

./digna user add <email> <password> "<display_name>" --admin

Приклад:

./digna user add admin@example.com 'AdminPassword123!' "Admin User" --admin

Це створює користувача з адресою електронної пошти admin@example.com і повними адміністративними правами.

Порада

Беріть пароль в одинарні лапки. bash і zsh обробляють такі символи, як !, $ і *, по-особливому, і пароль без лапок, що містить їх, не буде передано так, як його введено.

Найкраща практика

Використовуйте надійний пароль, що поєднує великі й малі літери, цифри та спеціальні символи.

Крок 6: Запустіть сервер digna

У каталозі встановлення digna запустіть сервер командою:

./digna serve --address <host> --port <port>

Параметри: - --address — ім'я хоста / IP сервера (за замовчуванням 127.0.0.1) - --port — порт сервера (за замовчуванням 8000)

Коли сервер запущено, він виводить адресу, яку прослуховує:

Server running on http://127.0.0.1:8082

Порада

Якщо панель розміщено на іншій машині, ніж серверну частину, відкрийте в брандмауері також порт API:

sudo ufw allow 8082/tcp
sudo firewall-cmd --permanent --add-port=8082/tcp && sudo firewall-cmd --reload

Сервер займає термінал

serve виконується на передньому плані й працює, доки ви не зупините його комбінацією Ctrl+C. Залиште його працювати, доки завершуєте налаштування; щоб натомість запускати його автоматично під час завантаження системи, див. Запуск digna як служби systemd.


Налаштування панелі

Крок 1: Розгорніть панель на веб‑сервері

Панель digna зчитує власну конфігурацію з dashboard/dashboard_config.toml. Цей файл не постачається разом зі встановленням — ви створюєте його в каталозі dashboard/ поруч із файлами панелі.

Його вміст описано в розділі Single Sign-On, і саме там цей файл і потрібен: він містить варіанти входу, які пропонує панель, а для розгортань із кількома екземплярами — підключення до серверної частини.

Виберіть свій веб‑сервер і виконайте відповідні кроки розгортання.

Розгортання в nginx

Якщо ви виконали кроки розділу Налаштування nginx, блок server уже вказує на вашу теку dashboard, і нічого копіювати не потрібно.

  1. Перевірте шлях
  2. Відкрийте /etc/nginx/conf.d/digna.conf
  3. Переконайтеся, що root вказує на розпаковану теку dashboard

  4. Переконайтеся, що теку можна читати

    sudo chmod -R a+rX /opt/digna/dashboard
    

  5. Перезавантажте nginx

    sudo nginx -t
    sudo systemctl reload nginx
    

  6. Перевірте встановлення

  7. Відкрийте браузер
  8. Перейдіть за адресою http://localhost (або за налаштованим вами URL)
  9. Ви повинні побачити сторінку входу панелі digna

Розгортання в Apache httpd

  1. Скопіюйте панель до кореневого каталогу документів

    sudo cp -R /opt/digna/dashboard /var/www/html/digna
    

  2. Додайте правила перезапису

Створіть файл .htaccess у розгорнутій теці, щоб маршрути панелі зберігалися після оновлення сторінки в браузері:

sudo nano /var/www/html/digna/.htaccess

Вставте наведене нижче:

RewriteEngine On
RewriteBase /digna/

# Serve existing files and directories as-is.
RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]

# Everything else falls back to the single-page application entry point.
RewriteRule ^ index.html [L]
  1. Перезапустіть Apache

    sudo systemctl restart apache2
    
    sudo systemctl restart httpd
    

  2. Відкрийте панель

  3. Відкрийте браузер
  4. Перейдіть за адресою http://localhost/digna
  5. Ви повинні побачити сторінку входу панелі digna

Крок 2: SELinux (лише сімейство RHEL)

У RHEL, Rocky, AlmaLinux і Fedora SELinux за замовчуванням працює в примусовому режимі й блокуватиме веб‑серверу читання файлів поза очікуваними розташуваннями. Перевірте, чи він активний:

getenforce

Якщо результат — Enforcing і ви віддаєте панель з /opt/digna/dashboard, позначте каталог міткою, щоб веб‑сервер міг його читати:

sudo semanage fcontext -a -t httpd_sys_content_t "/opt/digna/dashboard(/.*)?"
sudo restorecon -Rv /opt/digna/dashboard

Примітка

Якщо semanage не знайдено, встановіть його командою sudo dnf install -y policycoreutils-python-utils.

Важливо

Якщо панель на щойно налаштованому сервері RHEL повертає 403 Forbidden, це майже завжди проблема міток SELinux, а не прав доступу до файлів. Перевірте це командою sudo ausearch -m avc -ts recent.


Запуск digna як служби systemd

Навіщо запускати digna як службу?

Запуск серверної частини digna як служби systemd гарантує, що вона:

  • Автоматично запускається під час завантаження машини
  • Працює у фоновому режимі без відкритого вікна термінала
  • Автоматично перезапускається в разі збою
  • Керується через systemctl — стандартний менеджер служб Linux

Файли керування службою

Усі необхідні файли розташовані в каталозі встановлення digna, у підкаталозі bin/

Доступні такі скрипти оболонки:

  • install_service.sh — реєструє digna в systemd
  • uninstall_service.sh — скасовує реєстрацію служби
  • start_service.sh — запускає зареєстровану службу
  • stop_service.sh — зупиняє запущену службу

Потрібні права root

Усі скрипти потрібно виконувати через sudo, оскільки реєстрація служби, що запускається під час завантаження системи, записує unit‑файл до /etc/systemd/system.

Як зробити скрипти виконуваними

Розпакування може не зберегти біт виконання. Перед першим використанням виконайте:

cd /opt/digna/bin
sudo chmod +x *.sh

Встановлення служби

  1. Відкрийте термінал

  2. Перейдіть до теки bin

    cd /opt/digna/bin
    

  3. Запустіть скрипт встановлення

    sudo ./install_service.sh
    

Тепер сервер digna зареєстровано в systemd з увімкненим автоматичним запуском. Служба не запускається одразу — щоб запустити її, див. наступний розділ.

Запуск і зупинка служби

Щоб запустити службу

  1. Відкрийте термінал
  2. Перейдіть до /opt/digna/bin
  3. Виконайте:
    sudo ./start_service.sh
    

Щоб зупинити службу

  1. Відкрийте термінал
  2. Перейдіть до /opt/digna/bin
  3. Виконайте:
    sudo ./stop_service.sh
    

Порада

Завжди зупиняйте службу перед оновленням файлів застосунку.

Керування службою через systemctl

Після реєстрації службою також можна керувати стандартними командами systemd з будь-якого каталогу:

sudo systemctl start digna
sudo systemctl stop digna
sudo systemctl restart digna
sudo systemctl status digna

Перевірка служби

Щоб переконатися, що службу зареєстровано й вона працює:

systemctl is-enabled digna
systemctl is-active digna

enabled означає, що служба запускається під час завантаження системи; active означає, що вона працює зараз.

Перегляд журналів служби

systemd перехоплює все, що серверна частина виводить на консоль. Щоб прочитати це:

sudo journalctl -u digna -n 100

Щоб стежити за журналом наживо під час відтворення проблеми:

sudo journalctl -u digna -f

Порада

Це найшвидший спосіб діагностувати службу, яка запускається й одразу зупиняється. Тут з'являються повідомлення про збій підключення до репозиторію або відсутній license.toml.

Перенесення служби до нового каталогу

Unit‑файл зберігає абсолютний шлях до виконуваного файлу, тож перенесення встановлення потребує повторної реєстрації служби:

  1. Видаліть поточну службу

    cd /old/path/digna/bin
    sudo ./uninstall_service.sh
    

  2. Перемістіть файли застосунку

    sudo mv /old/path/digna /new/path/digna
    

  3. Повторно встановіть службу

    cd /new/path/digna/bin
    sudo ./install_service.sh
    

  4. Запустіть службу

    sudo ./start_service.sh
    

Видалення служби

  1. Зупиніть запущену службу

    cd /opt/digna/bin
    sudo ./stop_service.sh
    

  2. Видаліть службу

    sudo ./uninstall_service.sh
    

Реєстрацію сервера digna в systemd скасовано.


Оновлення до нового випуску

Цей розділ описує оновлення встановлення Release 2026.06 до Release 2026.11. Якщо ваше встановлення старіше, спершу прочитайте розділ Оновлення з випуску, старішого за 2026.06.

Перед оновленням

Створення резервної копії репозиторію digna обов'язкове

Перед оновленням digna створіть резервну копію свого репозиторію (PostgreSQL), щоб захиститися від втрати даних. Резервна копія дає змогу відновитися, якщо під час оновлення виникнуть непередбачені проблеми.

Щоб створити резервну копію з оболонки:

pg_dump -h localhost -p 5432 -U digna_user -n dignarepo postgres > digna_repo_backup.sql

Запит файлу ліцензії для Release 2026.11

Release 2026.11 потребує нового license.toml. Запросіть його в команди digna до початку оновлення та майте його напоготові для кроку 7.

Оновлення з випуску, старішого за 2026.06

Release 2026.06 приніс три зміни, які досі діють, коли ви оновлюєте старіше встановлення одразу до 2026.11:

  • Лише ODBC. digna звертається до кожної технології-джерела через ODBC. Кожне підключення до бази даних, яке ще не використовує ODBC, після оновлення потрібно перевести на ODBC; автоматичного перетворення немає. Заздалегідь встановіть драйвери ODBC на хості digna, див. Встановлення драйвера ODBC на хості digna, і підготуйте властивості кожного підключення з посібників за технологіями. Конектора Databricks Legacy більше не існує; переведіть такі підключення на конектор Databricks.
  • Один виконуваний файл. dignabackend і dignacli замінено одним виконуваним файлом digna, що поєднує серверну частину та CLI.
  • config.toml. Розділ [encryption] обов'язковий, а DIGNA_APP_HOST і DIGNA_APP_PORT більше не зчитуються: адресу та порт сервер бере з digna serve. Порівняйте свій файл із розділом Налаштування серверної частини.

Наведені нижче кроки вказують, де старіше встановлення потребує інших дій. Оновлення репозиторію в кроці 8 переводить репозиторій будь-якого попереднього випуску одразу до 2026.11.

Процес оновлення

Крок 1: Зупиніть службу digna

Якщо digna працює як служба systemd, спершу зупиніть її:

cd /opt/digna/bin
sudo ./stop_service.sh

Якщо digna працює на передньому плані, натисніть Ctrl+C у вікні її термінала.

Крок 2: Створіть резервну копію поточного встановлення

У каталозі встановлення digna перейменуйте виконуваний файл і теку панелі поточного встановлення, щоб новий випуск можна було розгорнути поруч із ними:

cd /opt/digna
sudo mv digna digna_old
sudo mv dashboard dashboard_old

Зберігайте digna_old, доки не перевірите оновлення, а dashboard_old — доки не відновите з неї свої файли конфігурації (див. крок 4). Після цього обидва можна видалити.

Оновлення з випуску, старішого за 2026.06

Перейменуйте теки dignabackend і dignacli замість виконуваного файлу: sudo mv dignabackend dignabackend_old і sudo mv dignacli dignacli_old. Жодна з них не використовується в Release 2026.11.

Крок 3: Розпакуйте та розгорніть нову версію

  1. Розпакуйте ZIP‑файл нової інсталяції digna
  2. Скопіюйте новий виконуваний файл digna і теку dashboard до свого каталогу встановлення
  3. Відновіть біт виконання та належність файлів службовому обліковому запису:
sudo chmod +x /opt/digna/digna
sudo chown -R digna:digna /opt/digna

Важливо

Ні config.toml, ні dashboard/dashboard_config.toml ніколи не входять до інсталяційного ZIP‑файлу — команда digna ніколи не постачає жодного з цих файлів. Тож оновлення не зачіпає вашої наявної конфігурації, а копії в перейменованих теках *_old — це єдині копії, які у вас є.

Крок 4: Відновіть свої файли конфігурації

sudo cp dashboard_old/dashboard_config.toml dashboard/dashboard_config.toml

Release 2026.11 не потребує змін у config.toml: файл, який працює з Release 2026.06, і далі працюватиме. Дві зміни необов'язкові:

  • Додайте розділ [duckdb], якщо підключення до баз даних мають використовувати digna Engine, а його значення за замовчуванням не підходять для вашого хоста.
  • Не вказуйте розділ [app], якщо зворотний проксі віддає панель і серверну частину з одного джерела.

Параметри, які digna не зчитує

Попередні версії цього посібника наводили деякі параметри, які digna не зчитує. Вони ні на що не впливають, а config check у кроці 6 перелічує їх у пункті Unknown keys. Вилучіть або виправте їх:

  • DIGNA_SCHEDULER_MAX_DELAY, DIGNA_CLEANUP_TIME, digna_COOKIE_PATH, digna_COOKIE_SAME_SITE, digna_APP_CORS_ALLOW_METHODS, digna_APP_CORS_ALLOW_HEADERS і digna_LOGGING_BACKUP_COUNT не існують. Вилучіть їх.
  • Назви параметрів чутливі до регістру. digna зчитує DIGNA_REPO_HOST, а не digna_REPO_HOST. Пишіть кожну назву великими літерами, як у розділі Налаштування серверної частини.

Єдиний вхід: залиште [[oidc_clients]]

digna зчитує постачальників єдиного входу як список записів [[oidc_clients]], кожен із власним DIGNA_OIDC_KEY. Якщо ви змінили своїх постачальників на розділи [oidc_clients.<key>], як показувала попередня версія цього посібника, поверніть попередню форму. config check повідомляє про OIDC config(s) як FAILED, доки діє така форма:

[[oidc_clients]]
DIGNA_OIDC_KEY = 'microsoft'
DIGNA_OIDC_CLIENT_ID = '<client_id>'
DIGNA_OIDC_CLIENT_SECRET = '<client_secret>'
DIGNA_OIDC_REDIRECT_URI = 'http://localhost:3000/oidc/callback'
DIGNA_OIDC_CONFIGURATION_URL = 'https://login.microsoftonline.com/<tenant_id>/v2.0/.well-known/openid-configuration'

Повторіть запис для кожного постачальника і стежте, щоб кожен DIGNA_OIDC_KEY збігався з key у dashboard_config.toml. Це стосується лише встановлень, що використовують єдиний вхід.

Крок 5: Перезавантажте веб‑сервер

Панель — це набір статичних файлів, тож ваш веб‑сервер — і браузер — можуть досі віддавати попередню версію. Перезавантажте або перезапустіть веб‑сервер, на якому розміщено теку dashboard, а потім перезавантажте сторінку з примусовим оновленням (Ctrl+F5).

Крок 6: Перевірте конфігурацію

Перш ніж торкатися репозиторію, переконайтеся, що config.toml повний:

./digna config check

Кожен розділ має повідомити OK. Виправте все, про що повідомлено як FAILED, вилучіть ключі, перелічені в пункті Unknown keys, і виконайте команду ще раз, перш ніж продовжувати.

Крок 7: Замініть файл ліцензії

Файл ліцензії зазвичай переходить з одного випуску в наступний. Release 2026.11 — виняток: він додає два ліцензовані модулі, digna Data Reconciliation і digna Agentic, а ліцензія, видана до 2026.11, їх не містить. Скопіюйте license.toml, який команда digna надала для Release 2026.11, до каталогу встановлення, замінивши старий:

sudo cp /path/to/new/license.toml /opt/digna/license.toml

Не залишайте попередню ліцензію

З попередньою ліцензією digna запускається, але digna Data Reconciliation і digna MCP Server залишаються вимкненими. Кожна команда, що перевіряє ліцензію, — user, inspection, repo — завершується, не торкаючись репозиторію, якщо перевірка не пройдена. Перевірте нову ліцензію, перш ніж продовжувати:

./digna license check

Крок 8: Оновіть схему репозиторію

У каталозі встановлення digna виконайте:

cd /opt/digna
./digna repo upgrade

Release 2026.11 керує схемою репозиторію за допомогою версійованих міграцій. Перше оновлення з попереднього випуску доводить схему до останньої версії попередньої системи, записує це як вихідну точку, а потім застосовує міграції Release 2026.11. Воно завершується так:

✅ Baseline migration recorded as applied.
✅ Repo schema 'dignarepo' is up to date.

Усі наявні дані зберігаються. Щоб будь-коли побачити стан репозиторію, виконайте ./digna repo check: команда показує останню застосовану міграцію та всі ще не застосовані.

digna не запускається із застарілим репозиторієм

Починаючи з Release 2026.11, сервер відмовляється запускатися, доки репозиторій потребує оновлення, і повідомляє про це, наприклад:

Error: Legacy repo version 3.0.2 installed. Use the 'digna repo upgrade' command to upgrade it.

Виконайте repo upgrade, перш ніж запускати сервер або службу.

Крок 9: Перезапустіть служби

Якщо digna працює як служба systemd:

cd /opt/digna/bin
sudo ./start_service.sh

Якщо сервер запускається вручну, перезапустіть його:

cd /opt/digna
./digna serve --address <address> --port <port>

Якщо використовуєте nginx або Apache, перезавантажте відповідний веб‑сервер:

sudo systemctl reload nginx
sudo systemctl restart apache2

У сімействі RHEL повторно застосуйте мітки SELinux, якщо каталог dashboard було замінено:

sudo restorecon -Rv /opt/digna/dashboard

Крок 10: Перевірте оновлення

  1. Перевірте випуск нового виконуваного файлу:

    ./digna version
    

    Перший рядок має бути Release: 2026.11.

  2. Відкрийте панель digna і переконайтеся, що інтерфейс завантажується коректно.

  3. Перевірте журнали сервера на наявність помилок:

    sudo journalctl -u digna -n 100
    
  4. Перевірте свої підключення до баз даних — див. Перевірка підключення. Після оновлення з випуску, старішого за 2026.06, спершу переведіть на ODBC кожне підключення, яке його ще не використовувало.

Щоб почати роботу з новими модулями, див. digna Data Reconciliation, Підключення AI-агента для digna MCP Server і Місце профілювання для digna Engine.