Як розгорнути Metabase на власній інфраструктурі у 2026 році: база даних застосунку, TLS і резервні копії

Якщо ви вже намагалися розгорнути Metabase на власній інфраструктурі, вам, імовірно, знайома ця неприємна ситуація: інтерфейс відкривається, але база даних застосунку відсутня, хоча вихідні бази даних для дашбордів залишаються. Повторне створення контейнера рідко усуває розбіжності між URL-адресами, станом і залежностями.

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

Облікові дані, ролі та відкриті поверхні

Моделюйте загрози для дій, які виконує Metabase, а не лише для його форми входу. У цьому випадку найнебезпечніша помилка — використовувати вбудовану базу даних застосунку H2 як єдину production-копію. Реалізуйте таку межу: за можливості надавайте Metabase ролі бази даних лише для читання та розділяйте дозволи колекцій і облікові дані бази даних.

Згенеруйте MB_ENCRYPTION_SECRET_KEY один раз, не зберігайте його в Git і додайте до маніфесту відновлення, оскільки його зміна може зробити зашифрований або підписаний стан застосунку недійсним. Не вирішуйте помилку доступу, запускаючи контейнер від імені root або широко монту ючи файлову систему хоста. Обмеження ресурсів також належать до дизайну безпеки, оскільки користувачі можуть створювати навантаження на JVM heap, паралельні запити, кешування результатів і кожне джерело аналітичних даних.

Відокремте Metabase від його залежностей

Мінімальна відповідальна топологія Metabase містить один приватний listener на 3000, маршрут ingress і документовану межу стану. Мережевий контракт Metabase передбачає окрему базу даних застосунку PostgreSQL, відокремлену від джерел аналітичних даних. Зберігайте приватні endpoint-и у внутрішньому DNS, дозволяйте лише необхідні вихідні підключення та надайте Metabase service credential з обмеженими правами.

Перевірте топологію: підключіть із чистого клієнта тестову базу даних лише для читання, збережіть запит, створіть дашборд і доставте підписку через налаштований поштовий канал. Під час виконання перевірки відстежуйте JVM heap, паралельні запити, кешування результатів і навантаження, передане кожному джерелу аналітичних даних. Результат покаже, чи потрібно наступне покращення в пам’яті, сховищі, мережі або окремому worker, замість того щоб заохочувати довільне збільшення розміру контейнера.

Базова конфігурація Docker для Metabase

Наведена нижче команда показує межі контейнера, не створюючи ілюзії, що всі зовнішні сервіси вже налаштовані.

docker run -d \
  --name metabase \
  --restart unless-stopped \
  -p 127.0.0.1:3000:3000 \
  -v metabase-data:/metabase-data \
  -e MB_ENCRYPTION_SECRET_KEY=replace-with-a-long-random-value \
  -e MB_DB_TYPE=h2 \
  -e MB_DB_FILE=/metabase-data/metabase.db \
  metabase/metabase:latest

Перш ніж відкривати ingress, перевірте фактичні змінні середовища, монтування та listener. Додайте перевірені параметри підключення до окремої бази даних застосунку PostgreSQL, відокремленої від джерел аналітичних даних; для приватних сервісів використовуйте приватні імена. Успішний запуск завершується тоді, коли ви можете підключити тестову базу даних лише для читання, зберегти запит, створити дашборд і доставити підписку через налаштований поштовий канал, а не тоді, коли docker ps виводить Up.

Перевірте розгортання Metabase від початку до кінця

Production-перевірка для Metabase має бути виконуваною людиною, яка не створювала це розгортання. Надайте їй зафіксовану версію, тестовий обліковий запис без конфіденційних даних і таке завдання: підключити тестову базу даних лише для читання, зберегти запит, створити дашборд і доставити підписку через налаштований поштовий канал. Якщо інструкції вимагають недокументованого доступу до shell, сервіс ще не готовий до експлуатації.

Повторіть перевірку, замінивши лише контейнер. Потім відновіть базу даних застосунку Metabase, а не тільки джерела даних, до порожньої інфраструктури, і переконайтеся, що користувачі, колекції, запити, фільтри дашбордів і підписки знову з’явилися та виконуються на основі відновлених метаданих підключень. Вимірюйте JVM heap, паралельні запити, кешування результатів і навантаження, передане кожному джерелу аналітичних даних, під час обох успішних запусків; несподівані відмінності часто вказують на відсутній кеш, індекс, worker або монтування даних.

Додайте перевірку відмови: тимчасово забороніть тестовій identity доступ до окремої бази даних застосунку PostgreSQL, відокремленої від джерел аналітичних даних. Metabase має показати зрозумілу помилку, зберегти наявний стан і відновити роботу після повернення коректної умови. Збережіть часові мітки та відповідні рядки журналу, попередньо видаливши секрети. Ці докази стануть еталоном для наступної зміни образу або конфігурації.

Правильно налаштуйте внутрішні та зовнішні URL

Браузер, API-клієнт і Metabase мають використовувати один origin. Щоб забезпечити це, встановіть MB_SITE_URL як публічний HTTPS origin. Зберігайте початкові host і protocol, водночас не допускаючи доступу до порту 3000 як до конкуруючої публічної адреси.

Посібник із діагностики недоступного сайту допоможе відрізнити недоступний маршрут від застосунку, який відповідає. Тут ця відмінність важлива: база даних застосунку відсутня, хоча вихідні бази даних для дашбордів залишаються. Лише першу проблему можна виправити змінами ingress; друга потребує перевірки журналів Metabase, стану або навантаження.

Експлуатуйте Metabase з урахуванням реального вузького місця

Для Metabase відстежуйте транзакцію, а не процес: підключіть тестову базу даних лише для читання, збережіть запит, створіть дашборд і доставте підписку через налаштований поштовий канал. Поєднуйте її затримку та частоту помилок із показниками JVM heap, паралельних запитів, кешування результатів і навантаження, переданого кожному джерелу аналітичних даних, щоб alert визначав компонент, який є обмеженням.

Репетиція оновлення має враховувати, що база даних застосунку Metabase і версії plugin-ів повинні мігрувати разом; робочі бази даних бізнесу не замінюють цей стан. Відновіть, мігруйте та виконайте транзакцію до заміни production-середовища. Якщо база даних застосунку відсутня, хоча вихідні бази даних для дашбордів залишаються, не видаляйте дані заради успішного запуску; послідовно порівняйте версію, змінні, монтування та доступність залежностей.

Volumes — лише перший рівень відновлення

Захистіть стан Metabase, перш ніж оптимізувати його контейнер. Необхідний набір — база даних застосунку Metabase, а не лише джерела даних, до яких виконуються запити. Змонтуйте /metabase-data до bootstrap, запишіть нешкідливі тестові дані та замініть контейнер, щоб довести фактичну постійність цього шляху. Якщо кілька сховищ мають залишатися узгодженими, задокументуйте порядок призупинення записів і створення резервних копій.

Зберігайте копії за межами сервера розгортання та шифруйте матеріали, що містять облікові дані або приватний вміст. Відновлення вважається успішним, коли користувачі, колекції, запити, фільтри дашбордів і підписки знову з’являються та виконуються на основі відновлених метаданих підключень. Відмінність між постійним монтуванням і незалежною копією описано в матеріалі постійне сховище та snapshots.

Розгортайте Metabase на Dockup, не втрачаючи встановлених меж

Шаблон Dockup має містити образ, порт 3000, монтування, параметри health check, домен, TLS і доставку секретів. Dockup має зберігати приватні частини окремої бази даних застосунку PostgreSQL окремо від джерел аналітичних даних у внутрішній мережі та не відкривати додаткових публічних портів. Те саме розгортання може працювати на серверах Dockup або на ресурсах, підключених клієнтом.

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

Поширені запитання

Що потрібно Metabase для production-розгортання?

Маршрутизуйте контейнер Metabase на порту 3000 через один HTTPS origin. Мережева вимога для підтримки — окрема база даних застосунку PostgreSQL, відокремлена від джерел аналітичних даних. Не вважайте Metabase готовим, доки не зможете підключити тестову базу даних лише для читання, зберегти запит, створити дашборд і доставити підписку через налаштований поштовий канал.

Які дані Metabase потрібно включати до резервної копії?

Забезпечте постійність /metabase-data і включіть до того самого маніфесту відновлення базу даних застосунку Metabase, а не лише джерела даних, до яких виконуються запити. Чисте відновлення Metabase є успішним лише тоді, коли користувачі, колекції, запити, фільтри дашбордів і підписки знову з’являються та виконуються на основі відновлених метаданих підключень.

Чи потрібен Metabase HTTPS за reverse proxy?

Використовуйте HTTPS для публічного origin Metabase і залишайте порт 3000 у внутрішньому маршруті. Коректно застосуйте налаштування Metabase: встановіть MB_SITE_URL як публічний HTTPS origin. Для Metabase HTTPS захищає облікові дані або користувацький вміст під час передавання та забезпечує узгоджену поведінку клієнта, чутливу до origin.

Як тестувати оновлення Metabase?

Відновіть поточний стан Metabase в ізольованому розгортанні, застосуйте candidate-версію та повторіть acceptance-транзакцію. Зверніть особливу увагу на те, що база даних застосунку Metabase і версії plugin-ів повинні мігрувати разом; робочі бази даних бізнесу не замінюють цей стан. Зберігайте попередній образ Metabase, доки не зрозумієте межі міграції даних і rollback.