Посібник зі встановлення digna Release 2026.11 на macOS¶
Випуск: 2026.11
Останнє оновлення: 7 листопада 2026 р.
Зміст¶
- Вступ
- Системні вимоги
- Підготовка до встановлення
- Налаштування сервера PostgreSQL
- Налаштування веб‑сервера
- Початкове встановлення
- Налаштування серверної частини
- Налаштування панелі
- Запуск digna як фонової служби
- Оновлення до нового випуску
Вступ¶
Про 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 або Linux?¶
Цей посібник охоплює macOS. Для інших платформ див. Посібник зі встановлення на Windows або Посібник зі встановлення на Linux.
Системні вимоги¶
Перш ніж почати встановлення, переконайтеся, що ваша система відповідає таким мінімальним вимогам:
| Вимога | Специфікація |
|---|---|
| Операційна система | macOS 13 (Ventura) або новіша |
| Архітектура | Apple Silicon (arm64) або Intel (x86_64) |
| Пам'ять (мінімальна конфігурація) | 16 GB RAM |
| Дисковий простір | 10 GB вільного місця |
| База даних | PostgreSQL Server 12 або новіший |
| Веб‑сервер | nginx, Apache httpd або аналог |
| Інструменти командного рядка | Xcode Command Line Tools (потрібні для Homebrew) |
digna Engine
Підключення до баз даних, які використовують digna Engine як місце профілювання, профілюються на самому хості digna. Заплануйте для них додаткові пам'ять і дисковий простір, див. розділ [duckdb].
Варіанти встановлення бази даних¶
Якщо PostgreSQL уже встановлено: Ви можете додати нову базу даних для digna до наявного сервера PostgreSQL.
Якщо PostgreSQL встановлюється на тій самій машині, що й digna:
Рекомендовані характеристики
- Пам'ять: 32 GB RAM (замість 16 GB)
- Дисковий простір: 50 GB вільного місця (замість 10 GB)
Ці підвищені характеристики розраховані на одночасну роботу digna та бази даних PostgreSQL.
Перевірка архітектури¶
Кілька шляхів у цьому посібнику відрізняються для Mac з Apple Silicon і з Intel. Щоб перевірити, який у вас, відкрийте Terminal і виконайте:
arm64— Apple Silicon. Homebrew встановлюється до/opt/homebrew.x86_64— Intel. Homebrew встановлюється до/usr/local.
Порада
Замість того щоб жорстко прописувати будь-який із цих шляхів, цей посібник використовує $(brew --prefix), що розгортається в правильне розташування на обох архітектурах. Команди можна копіювати без змін.
Підготовка до встановлення¶
Перед встановленням digna переконайтеся, що наявні три ключові передумови:
- Homebrew – менеджер пакетів, яким установлюються наведені нижче компоненти
- Сервер PostgreSQL – для зберігання обчислених метрик і даних про продуктивність
- Веб‑сервер – для розміщення панелі digna (digna Dashboard)
Якщо ці компоненти ще не налаштовано, скористайтеся наведеними нижче розділами, щоб установити та налаштувати їх.
Встановлення Homebrew¶
Homebrew — стандартний менеджер пакетів для macOS, який у всьому цьому посібнику використовується для встановлення PostgreSQL і nginx.
Крок 1: Перевірте, чи Homebrew уже встановлено¶
Відкрийте Terminal (натисніть Cmd + Space, введіть Terminal, натисніть Enter) і виконайте:
Якщо повертається номер версії, перейдіть до розділу Налаштування сервера PostgreSQL.
Крок 2: Встановіть Homebrew¶
Якщо команду не знайдено, установіть Homebrew за інструкціями на офіційному сайті Homebrew. Інсталятор також установлює Xcode Command Line Tools, якщо їх ще немає.
Крок 3: Додайте Homebrew до PATH¶
На Apple Silicon інсталятор виводить дві команди для додавання Homebrew до середовища вашої оболонки. Виконайте їх, як зазначено, а потім перевірте:
Команда має вивести /opt/homebrew на Apple Silicon або /usr/local на Intel.
Налаштування сервера PostgreSQL¶
Якщо у вас уже є PostgreSQL¶
Якщо PostgreSQL уже встановлено й запущено на вашій локальній машині або ви використовуєте керований віддалений сервер PostgreSQL, можете перейти до наступного розділу.
Варіанти встановлення¶
macOS пропонує два простих способи встановити PostgreSQL. Виберіть один:
- Homebrew — встановлення з командного рядка, рекомендоване для серверних розгортань
- Postgres.app — графічне встановлення, зручне для локального ознайомлення
Встановлення PostgreSQL за допомогою Homebrew¶
Крок 1: Встановіть формулу PostgreSQL¶
Крок 2: Додайте PostgreSQL до PATH¶
Формули PostgreSQL із версією є keg-only, тобто Homebrew не додає їхні команди до PATH автоматично. Додайте їх самостійно:
Примітка
Це передбачає стандартну для macOS оболонку zsh. Якщо ви використовуєте bash, натомість додайте той самий рядок до ~/.bash_profile.
Крок 3: Запустіть службу PostgreSQL¶
Ця команда одразу запускає PostgreSQL і налаштовує його автоматичний запуск під час вашого входу в систему.
Крок 4: Перевірте встановлення¶
Якщо встановлення пройшло успішно, ви побачите версію PostgreSQL.
Крок 5: Підключіться до сервера¶
Важливо — тут macOS відрізняється від Windows
Інсталятор для Windows пропонує створити суперкористувача postgres і пароль. Homebrew цього не робить. Натомість він створює суперкористувача з іменем вашого облікового запису macOS, без пароля, доступного лише з локальної машини.
Це означає, що в щойно встановленому через Homebrew PostgreSQL ролі postgres немає. Коли вам потрібен суперкористувач, використовуйте ім'я свого облікового запису, а окремого користувача digna створіть, як описано в розділі Початкове встановлення.
Крок 6: Перевірте порт¶
Стандартний порт PostgreSQL — 5432. Щоб перевірити, який порт прослуховує ваш сервер:
Запишіть це значення — воно знадобиться під час налаштування серверної частини digna.
Встановлення PostgreSQL за допомогою Postgres.app¶
Якщо ви віддаєте перевагу графічному встановленню:
- Завантажте Postgres.app і перетягніть його до теки Applications
- Відкрийте застосунок і натисніть Initialize, щоб створити новий сервер
- Дотримуйтеся інструкцій застосунку, щоб додати його інструменти командного рядка до PATH
- Перевірте встановлення:
Postgres.app також створює суперкористувача з іменем вашого облікового запису macOS.
Налаштування веб‑сервера¶
digna потребує веб‑сервера для розміщення панелі. Виберіть один із таких варіантів:
- nginx — встановлюється через Homebrew, рекомендований
- Apache httpd — входить до складу macOS
Потрібно встановити й налаштувати лише один із цих серверів.
Обидва розділи налаштовують дві речі, від яких залежить панель:
- Резервний маршрут для односторінкового застосунку (SPA fallback), щоб оновлення URL панелі не повертало 404
- Тип MIME для
.md, щоб файли Markdown віддавалися коректно
Налаштування nginx¶
Огляд¶
nginx — легкий високопродуктивний веб‑сервер, що добре підходить для віддавання статичної панелі digna.
Встановлення¶
Запуск nginx¶
Перевірте встановлення¶
- Відкрийте браузер
- Перейдіть за адресою
http://localhost:8080 - Ви повинні побачити сторінку привітання nginx
Примітка — порт за замовчуванням 8080, а не 80
Homebrew налаштовує nginx на прослуховування порту 8080, щоб він міг працювати без прав адміністратора. У macOS прив'язка до порту 80 або будь-якого іншого порту нижче 1024 потребує прав root.
Щоб віддавати панель на порту 80, змініть listen 8080; на listen 80; у наведеній нижче конфігурації та запускайте nginx командою sudo brew services start nginx.
Налаштування сайту для панелі¶
Конфігурація nginx від Homebrew підключає кожен файл зі свого каталогу servers. Створіть там окремий файл конфігурації для digna:
Вставте наведене нижче, замінивши /path/to/digna/dashboard фактичним шляхом до розпакованої теки dashboard:
server {
listen 8080;
server_name localhost;
root /path/to/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.
Застосуйте конфігурацію¶
Перевірте конфігурацію на синтаксичні помилки, а потім перезавантажте nginx:
Налаштування Apache httpd¶
Огляд¶
Apache httpd входить до складу macOS, тож установлювати його не потрібно. За замовчуванням він вимкнений.
Запуск Apache¶
Перевірте встановлення¶
- Відкрийте браузер
- Перейдіть за адресою
http://localhost - Ви повинні побачити повідомлення "It works!"
Обов'язково: увімкніть mod_rewrite¶
Панель потребує перезапису URL. Відкрийте конфігурацію Apache:
Знайдіть наведений нижче рядок і видаліть початковий символ #, щоб розкоментувати його:
Обов'язково: дозвольте перевизначення через .htaccess¶
У тому самому файлі знайдіть блок <Directory "/Library/WebServer/Documents"> і змініть:
на:
Обов'язково: тип MIME для файлів Markdown¶
Там само в httpd.conf додайте такий рядок, щоб файли Markdown віддавалися коректно:
Важливо
Без цього налаштування файли .md можуть віддаватися некоректно.
Застосуйте конфігурацію¶
Перевірте конфігурацію на синтаксичні помилки, а потім перезапустіть Apache:
Початкове встановлення¶
Крок 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;
Щоб виконати їх із Terminal за один крок:
Потім вставте оператори в запрошенні postgres=# і введіть \q, щоб вийти.
Найкраща практика
Використовуйте надійні, складні паролі для користувачів бази даних. Уникайте облікових даних, які легко вгадати.
Крок 2: Розпакуйте інсталяційний пакет digna¶
- Знайдіть наданий вам ZIP‑файл інсталяції digna
- Розпакуйте його в бажане місце встановлення — наприклад,
/opt/dignaабо~/digna - Після розпакування ви побачите такі елементи:
dashboard/— веб‑інтерфейс панеліdigna— основний виконуваний файл (серверна частина та CLI разом)
Файли конфігурації та ліцензії не входять до пакета
Ні config.toml, ні dashboard/dashboard_config.toml не постачаються разом зі встановленням — ви створюєте обидва файли самостійно, у розділах Налаштування серверної частини і Налаштування панелі. license.toml також не постачається; digna надає його окремо, як описано в кроці 3.
Щоб розпакувати з Terminal:
Зробіть файл виконуваним¶
Залежно від того, як передавався архів, біт виконання може не зберегтися після розпакування. Задайте його явно:
Якщо macOS блокує застосунок¶
Файли, завантажені через браузер або поштовий клієнт, позначаються атрибутом карантину. Якщо macOS повідомляє, що застосунок «неможливо відкрити, оскільки не вдається перевірити розробника», зніміть цей атрибут із каталогу встановлення:
Або ж відкрийте System Settings → Privacy & Security, знайдіть заблокований елемент унизу сторінки й натисніть Open Anyway.
Примітка
Цей крок потрібен лише тоді, коли macOS справді блокує виконуваний файл. Пакети, передані через SSH або з внутрішніх файлових ресурсів, зазвичай не потрапляють у карантин.
Крок 3: Встановіть файл ліцензії¶
Важливо
Файл ліцензії не входить до інсталяційного пакета й надається digna окремо.
- Знайдіть наданий вам файл
license.toml - Скопіюйте його в кореневий каталог встановлення 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.
Розташування: /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 від Homebrew на його стандартному порту, дозволити потрібно джерело http://localhost:8080.
Розділ [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 тримає відкритими |
Розділ [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, доступних на вашому Mac, виконайте sysctl -n hw.ncpu.
Розділ [encryption]¶
Цей розділ містить ключ, яким шифруються конфіденційні значення, що зберігаються в репозиторії. Він обов'язковий — config check повідомляє про розділ [encryption] як FAILED, якщо ключа немає.
| Параметр | Значення | Примітки |
|---|---|---|
DIGNA_ENCRYPTION_KEY | Ключ у кодуванні Base64 | Шифрує конфіденційні значення, що зберігаються в репозиторії digna |
Захистіть config.toml
Цей ключ — фіксоване значення, однакове в усіх установленнях digna, і саме він розшифровує конфіденційні значення у вашому репозиторії. Обмежте доступ до config.toml обліковим записом, під яким працює digna, тримайте файл поза системою контролю версій і спільними дисками та виключіть його з будь-якої резервної копії, що зберігається менш захищено, ніж сам репозиторій.
Розділ [logging]¶
Цей розділ налаштовує поведінку журналювання:
| Параметр | Значення | Примітки |
|---|---|---|
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, і виконує перевірки референтної цілісності між джерелами даних на різних підключеннях до баз даних. Див. Місце профілювання.
Розділ необов'язковий. Без нього діють наведені нижче значення за замовчуванням.
| Параметр | Значення | Примітки |
|---|---|---|
DIGNA_DUCKDB_MEMORY_LIMIT_MB | 1024 (за замовчуванням) | Пам'ять у MB, яку може використовувати один запуск digna Engine. Одночасно можуть бути активними до DIGNA_MAX_WORKERS запусків |
DIGNA_DUCKDB_TEMP_DIRECTORY | За замовчуванням: системний тимчасовий каталог ($TMPDIR облікового запису, під яким працює digna) | Каталог для тимчасових файлів, коли дані не вміщаються в пам'ять |
Розрахунок ресурсів для digna Engine
Заплануйте до DIGNA_MAX_WORKERS × DIGNA_DUCKDB_MEMORY_LIMIT_MB пам'яті на хості digna понад те, що використовує сама digna, а також достатньо вільного місця на диску в тимчасовому каталозі, щоб умістити дані найбільшої інспектованої дати джерел даних, які використовують digna Engine. Спрямуйте DIGNA_DUCKDB_TEMP_DIRECTORY на диск із таким обсягом вільного місця, доступний для запису обліковому запису, під яким працює digna:
Цей розділ потрібен, лише якщо принаймні одне підключення до бази даних використовує digna Engine або перевірка референтної цілісності порівнює джерела даних на різних підключеннях.
Крок 2: Перевірте конфігурацію¶
Перед ініціалізацією репозиторію переконайтеся, що config.toml повний і правильно сформований. У каталозі встановлення digna виконайте:
Кожен розділ перевіряється окремо, тож одна помилка не приховує стан решти:
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: Ініціалізуйте репозиторій¶
- Відкрийте Terminal
- Перейдіть до каталогу встановлення digna (там, де розташовані
config.tomlі виконуваний файлdigna) - Запустіть перевірку підключення:
Для нової схеми команда підключається, а потім повідомляє, що репозиторій ще не встановлено:
На цьому етапі це очікуваний результат: він підтверджує, що digna дістається до PostgreSQL і схеми. Натомість помилка підключення чи автентифікації вказує на розділ [repo] або на налаштування PostgreSQL.
Примітка
У macOS команди з поточного каталогу не входять до PATH, тож виконуваний файл викликається як ./digna, а не digna. Щоб скрізь використовувати коротшу форму, додайте каталог встановлення до PATH:
Крок 4: Встановіть схему репозиторію¶
У тому самому каталозі виконайте:
Ця команда встановлює необхідні таблиці у схемі репозиторію й завершується повідомленням:
repo upgrade встановлює та оновлює
Починаючи з Release 2026.11, repo upgrade встановлює новий репозиторій і оновлює наявний. repo install і далі працює як інша назва тієї самої команди.
Крок 5: Створіть користувача‑адміністратора¶
Користувач‑адміністратор створюється безпосередньо у схемі репозиторію, тож сервер поки що не мусить працювати. У каталозі встановлення digna виконайте:
Приклад:
Це створює користувача з адресою електронної пошти admin@example.com і повними адміністративними правами.
Порада
Беріть пароль в одинарні лапки. zsh обробляє такі символи, як !, $ і *, по-особливому, і пароль без лапок, що містить їх, не буде передано так, як його введено.
Найкраща практика
Використовуйте надійний пароль, що поєднує великі й малі літери, цифри та спеціальні символи.
Крок 6: Запустіть сервер digna¶
У каталозі встановлення digna запустіть сервер командою:
Параметри: - --address — ім'я хоста / IP сервера (за замовчуванням 127.0.0.1) - --port — порт сервера (за замовчуванням 8000)
Коли сервер запущено, він виводить адресу, яку прослуховує:
Порада
Під час першого запуску сервера macOS може запитати, чи дозволити застосунку приймати вхідні мережеві з'єднання. Натисніть Allow, інакше панель не зможе звертатися до серверної частини.
Сервер займає термінал
serve виконується на передньому плані й працює, доки ви не зупините його комбінацією Ctrl+C. Залиште його працювати, доки завершуєте налаштування; щоб натомість запускати його автоматично під час завантаження системи, див. Запуск digna як фонової служби.
Налаштування панелі¶
Крок 1: Розгорніть панель на веб‑сервері¶
Панель digna зчитує власну конфігурацію з dashboard/dashboard_config.toml. Цей файл не постачається разом зі встановленням — ви створюєте його в каталозі dashboard/ поруч із файлами панелі.
Його вміст описано в розділі Single Sign-On, і саме там цей файл і потрібен: він містить варіанти входу, які пропонує панель, а для розгортань із кількома екземплярами — підключення до серверної частини.
Виберіть свій веб‑сервер і виконайте відповідні кроки розгортання.
Розгортання в nginx¶
Якщо ви виконали кроки розділу Налаштування nginx, блок server уже вказує на вашу теку dashboard, і нічого копіювати не потрібно.
- Перевірте шлях
- Відкрийте
$(brew --prefix)/etc/nginx/servers/digna.conf -
Переконайтеся, що
rootвказує на розпаковану текуdashboard -
Переконайтеся, що теку можна читати
-
Перезавантажте nginx
-
Перевірте встановлення
- Відкрийте браузер
- Перейдіть за адресою
http://localhost:8080(або за налаштованим вами URL) - Ви повинні побачити сторінку входу панелі digna
Розгортання в Apache httpd¶
-
Скопіюйте панель до кореневого каталогу документів
-
Додайте правила перезапису
Створіть файл .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]
-
Перезапустіть Apache
-
Відкрийте панель
- Відкрийте браузер
- Перейдіть за адресою
http://localhost/digna - Ви повинні побачити сторінку входу панелі digna
Запуск digna як фонової служби¶
Навіщо запускати digna як службу?¶
Запуск серверної частини digna як фонової служби гарантує, що вона:
- Автоматично запускається під час завантаження машини
- Працює у фоновому режимі без відкритого вікна Terminal
- Автоматично перезапускається в разі збою
- Керується через
launchctl— менеджер служб macOS
Файли керування службою¶
Усі необхідні файли розташовані в каталозі встановлення digna, у підкаталозі bin/
Доступні такі скрипти оболонки:
install_service.sh— реєструє digna в launchduninstall_service.sh— скасовує реєстрацію службиstart_service.sh— запускає зареєстровану службуstop_service.sh— зупиняє запущену службу
Потрібні права адміністратора
Усі скрипти потрібно виконувати через sudo, оскільки реєстрація служби, що запускається під час завантаження системи, записує дані до /Library/LaunchDaemons.
Як зробити скрипти виконуваними¶
Розпакування може не зберегти біт виконання. Перед першим використанням виконайте:
Встановлення служби¶
-
Відкрийте Terminal
-
Перейдіть до теки bin
-
Запустіть скрипт встановлення
Тепер сервер digna зареєстровано в launchd з увімкненим автоматичним запуском. Служба не запускається одразу — щоб запустити її, див. наступний розділ.
Запуск і зупинка служби¶
Щоб запустити службу¶
- Відкрийте Terminal
- Перейдіть до
/opt/digna/bin - Виконайте:
Щоб зупинити службу¶
- Відкрийте Terminal
- Перейдіть до
/opt/digna/bin - Виконайте:
Порада
Завжди зупиняйте службу перед оновленням файлів застосунку.
Перевірка служби¶
Щоб переконатися, що службу зареєстровано й вона працює:
Рядок, що починається з ідентифікатора процесу, означає, що служба працює. Символ - у першому стовпці означає, що службу зареєстровано, але її зупинено.
Перенесення служби до нового каталогу¶
launchd зберігає абсолютний шлях до виконуваного файлу, тож перенесення встановлення потребує повторної реєстрації служби:
-
Видаліть поточну службу
-
Перемістіть файли застосунку
-
Повторно встановіть службу
-
Запустіть службу
Видалення служби¶
-
Зупиніть запущену службу
-
Видаліть службу
Реєстрацію сервера digna в launchd скасовано.
Оновлення до нового випуску¶
Цей розділ описує оновлення встановлення Release 2026.06 до Release 2026.11. Якщо ваше встановлення старіше, спершу прочитайте розділ Оновлення з випуску, старішого за 2026.06.
Перед оновленням¶
Створення резервної копії репозиторію digna обов'язкове
Перед оновленням digna створіть резервну копію свого репозиторію (PostgreSQL), щоб захиститися від втрати даних. Резервна копія дає змогу відновитися, якщо під час оновлення виникнуть непередбачені проблеми.
Щоб створити резервну копію з Terminal:
Запит файлу ліцензії для 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 працює як фонова служба, спершу зупиніть її:
Якщо digna працює на передньому плані, натисніть Ctrl+C у її вікні Terminal.
Крок 2: Створіть резервну копію поточного встановлення¶
У каталозі встановлення digna перейменуйте виконуваний файл і теку панелі поточного встановлення, щоб новий випуск можна було розгорнути поруч із ними:
Зберігайте digna_old, доки не перевірите оновлення, а dashboard_old — доки не відновите з неї свої файли конфігурації (див. крок 4). Після цього обидва можна видалити.
Оновлення з випуску, старішого за 2026.06
Перейменуйте теки dignabackend і dignacli замість виконуваного файлу: mv dignabackend dignabackend_old і mv dignacli dignacli_old. Жодна з них не використовується в Release 2026.11.
Крок 3: Розпакуйте та розгорніть нову версію¶
- Розпакуйте ZIP‑файл нової інсталяції digna
- Скопіюйте новий виконуваний файл
dignaі текуdashboardдо свого каталогу встановлення - Відновіть біт виконання та за потреби зніміть атрибут карантину:
Важливо
Ні config.toml, ні dashboard/dashboard_config.toml ніколи не входять до інсталяційного ZIP‑файлу — команда digna ніколи не постачає жодного з цих файлів. Тож оновлення не зачіпає вашої наявної конфігурації, а копії в перейменованих теках *_old — це єдині копії, які у вас є.
Крок 4: Відновіть свої файли конфігурації¶
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, а потім перезавантажте сторінку з примусовим оновленням (Cmd+Shift+R).
Крок 6: Перевірте конфігурацію¶
Перш ніж торкатися репозиторію, переконайтеся, що config.toml повний:
Кожен розділ має повідомити OK. Виправте все, про що повідомлено як FAILED, вилучіть ключі, перелічені в пункті Unknown keys, і виконайте команду ще раз, перш ніж продовжувати.
Крок 7: Замініть файл ліцензії¶
Файл ліцензії зазвичай переходить з одного випуску в наступний. Release 2026.11 — виняток: він додає два ліцензовані модулі, digna Data Reconciliation і digna Agentic, а ліцензія, видана до 2026.11, їх не містить. Скопіюйте license.toml, який команда digna надала для Release 2026.11, до каталогу встановлення, замінивши старий:
Не залишайте попередню ліцензію
З попередньою ліцензією digna запускається, але digna Data Reconciliation і digna MCP Server залишаються вимкненими. Кожна команда, що перевіряє ліцензію, — user, inspection, repo — завершується, не торкаючись репозиторію, якщо перевірка не пройдена. Перевірте нову ліцензію, перш ніж продовжувати:
Крок 8: Оновіть схему репозиторію¶
У каталозі встановлення digna виконайте:
Release 2026.11 керує схемою репозиторію за допомогою версійованих міграцій. Перше оновлення з попереднього випуску доводить схему до останньої версії попередньої системи, записує це як вихідну точку, а потім застосовує міграції Release 2026.11. Воно завершується так:
Усі наявні дані зберігаються. Щоб будь-коли побачити стан репозиторію, виконайте ./digna repo check: команда показує останню застосовану міграцію та всі ще не застосовані.
digna не запускається із застарілим репозиторієм
Починаючи з Release 2026.11, сервер відмовляється запускатися, доки репозиторій потребує оновлення, і повідомляє про це, наприклад:
Виконайте repo upgrade, перш ніж запускати сервер або службу.
Крок 9: Перезапустіть служби¶
Якщо digna працює як фонова служба:
Якщо сервер запускається вручну, перезапустіть його:
Якщо використовуєте nginx або Apache, перезапустіть відповідний веб‑сервер:
Крок 10: Перевірте оновлення¶
-
Перевірте випуск нового виконуваного файлу:
Перший рядок має бути
Release: 2026.11. -
Відкрийте панель digna і переконайтеся, що інтерфейс завантажується коректно.
- Перевірте вивід сервера та файли в каталозі
logsна наявність помилок. - Перевірте свої підключення до баз даних — див. Перевірка підключення. Після оновлення з випуску, старішого за 2026.06, спершу переведіть на ODBC кожне підключення, яке його ще не використовувало.
Щоб почати роботу з новими модулями, див. digna Data Reconciliation, Підключення AI-агента для digna MCP Server і Місце профілювання для digna Engine.