Rejstřík deníkuDockup / terénní poznámka
Note / self-host-metabase

Jak provozovat Metabase na vlastním serveru v roce 2026: aplikační databáze, TLS a zálohy

Praktický návod na provoz Metabase na vlastním serveru, který pokrývá Docker, porty, trvalá data, TLS, zabezpečení, zálohy a problémy bránící produkčnímu nasazení. Včetně kontrol.

Pokud jste se už pokoušeli provozovat Metabase na vlastním serveru, nejspíš znáte frustrující stav, kdy se zobrazí UI, ale chybí aplikační databáze, přestože zdrojové databáze dashboardů zůstaly zachované. Opětovné vytvoření kontejneru obvykle nevyřeší nesoulad mezi URL, stavem a závislostmi.

Tento návod používá jedno konkrétní kritérium dokončení — připojit databázi se vzorovými daty pouze pro čtení, uložit otázku, vytvořit dashboard a doručit odběr prostřednictvím nakonfigurovaného e-mailového kanálu. Každé konfigurační rozhodnutí hodnotíme podle tohoto kritéria, nikoli podle zeleného odznaku kontejneru.

Přihlašovací údaje, role a vystavené plochy

Modelujte hrozby podle operací, které Metabase provádí, ne pouze podle přihlašovacího formuláře. Zde je nejrizikovější chybou použití vestavěné aplikační databáze H2 jako jediné produkční kopie. Nastavte tuto hranici: Metabase přidělte, kde je to možné, databázové role pouze pro čtení a oddělte oprávnění ke kolekcím od databázových přihlašovacích údajů.

Vygenerujte MB_ENCRYPTION_SECRET_KEY jednou, uchovávejte ho mimo Git a zachovejte ho spolu s manifestem pro obnovu, protože jeho změna může zneplatnit zašifrovaný nebo podepsaný stav aplikace. Chybu s oprávněními neřešte spuštěním kontejneru pod uživatelem root ani širokým připojením hostitelského systému. Limity zdrojů patří také do návrhu zabezpečení, protože uživatelé mohou vytížit JVM heap, souběžné dotazy, ukládání výsledků do cache i zatížení přenášené na jednotlivé zdroje analytických dat.

Oddělte Metabase od jeho závislostí

Nejmenší odpovědná topologie Metabase obsahuje jeden privátní listener na portu 3000, ingress routu a zdokumentovanou hranici stavu. Síťová smlouva pro Metabase vyžaduje dedikovanou aplikační databázi PostgreSQL oddělenou od analytických zdrojů. Privátní endpointy ponechte na interním DNS, povolte pouze potřebná odchozí spojení a Metabase přidělte omezené servisní přihlašovací údaje.

Topologii ověřte tak, že čistému klientovi připojíte databázi se vzorovými daty pouze pro čtení, uložíte otázku, vytvoříte dashboard a doručíte odběr prostřednictvím nakonfigurovaného e-mailového kanálu. Během běhu sledujte JVM heap, souběžné dotazy, ukládání výsledků do cache a zatížení přenášené na jednotlivé zdroje analytických dat. Výsledek vám ukáže, zda další zlepšení patří do oblasti paměti, úložiště, sítě nebo samostatného workeru, místo aby vás vedl k libovolnému nastavování velikosti kontejneru.

Základní konfigurace Metabase v Dockeru

Následující příkaz zviditelní hranici kontejneru, aniž by předstíral, že zajišťuje všechny externí služby.

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

Před otevřením ingressu zkontrolujte výsledné prostředí, mounty a listener. Přidejte prověřené parametry připojení k dedikované aplikační databázi PostgreSQL oddělené od analytických zdrojů; pro privátní služby používejte privátní názvy. Úspěšné spuštění nastává ve chvíli, kdy můžete připojit databázi se vzorovými daty pouze pro čtení, uložit otázku, vytvořit dashboard a doručit odběr prostřednictvím nakonfigurovaného e-mailového kanálu, nikoli ve chvíli, kdy docker ps vypíše Up.

Ověřte nasazení Metabase od začátku do konce

Produkční brána pro Metabase by měla být proveditelná někým, kdo nasazení nevytvořil. Předejte této osobě připnutou verzi, testovací účet bez citlivých údajů a tento úkol: připojit databázi se vzorovými daty pouze pro čtení, uložit otázku, vytvořit dashboard a doručit odběr prostřednictvím nakonfigurovaného e-mailového kanálu. Pokud pokyny vyžadují nedokumentovaný přístup přes shell, služba ještě není provozně připravená.

Bránu zopakujte po nahrazení pouze kontejneru. Poté obnovte aplikační databázi Metabase, nikoli pouze dotazované zdroje dat, do prázdné infrastruktury a ověřte, že se znovu objeví uživatelé, kolekce, otázky, filtry dashboardů a odběry a že se spustí nad obnovenými metadaty připojení. Během obou úspěšných běhů měřte JVM heap, souběžné dotazy, ukládání výsledků do cache a zatížení přenášené na jednotlivé zdroje analytických dat; neočekávané rozdíly často odhalí chybějící cache, index, worker nebo datový mount.

Přidejte také test selhání: dočasně odeberte testovací identitě přístup k dedikované aplikační databázi PostgreSQL oddělené od analytických zdrojů. Metabase by měla vypsat užitečnou chybu, zachovat existující stav a po obnovení platné podmínky se zotavit. Uložte časové značky a relevantní řádky logu, přičemž citlivé údaje začerňte. Tyto důkazy se stanou referencí pro další změnu image nebo konfigurace.

Udržujte interní a externí URL konzistentní

Prohlížeč, API klient i Metabase se musí shodovat na jednom originu. Aby tomu tak bylo, nastavte MB_SITE_URL na veřejný HTTPS origin. Zachovejte původního hostitele a protokol a zároveň ponechte port 3000 nedostupný jako konkurenční veřejnou adresu.

Průvodce řešením problémů s nedostupným webem pomáhá rozlišit nedostupnou routu od aplikace, která odpovídá. Toto rozlišení je zde důležité: aplikační databáze chybí, přestože zdrojové databáze dashboardů zůstaly zachované. Změny ingressu opraví pouze první problém; druhý vyžaduje kontrolu logů Metabase, stavu nebo zatížení.

Provozujte Metabase s ohledem na skutečné úzké hrdlo

U Metabase sledujte transakci, nikoli proces: připojit databázi se vzorovými daty pouze pro čtení, uložit otázku, vytvořit dashboard a doručit odběr prostřednictvím nakonfigurovaného e-mailového kanálu. Její latenci a chybovost kombinujte s JVM heap, souběžnými dotazy, ukládáním výsledků do cache a zatížením přenášeným na jednotlivé zdroje analytických dat, aby alert identifikoval omezenou komponentu.

Test aktualizace musí pokrýt skutečnost, že aplikační databáze Metabase a verze pluginů se musí migrovat společně; dotazované firemní databáze tuto část stavu nenahrazují. Před produkční výměnou proveďte obnovu, migraci a transakci. Pokud aplikační databáze chybí, přestože zdrojové databáze dashboardů zůstaly zachované, nemažte data jen proto, aby spuštění skončilo zeleně; v tomto pořadí porovnejte verzi, proměnné, mounty a dostupnost závislostí.

Svazky jsou pouze první vrstvou obnovy

Chraňte stav Metabase dříve, než začnete optimalizovat jeho kontejner. Povinnou součástí je aplikační databáze Metabase, nikoli pouze dotazované zdroje dat. Připojte /metabase-data před bootstrapem, zapište neškodná vzorová data a nahraďte kontejner, abyste ověřili, že je tato cesta skutečně trvalá. Pokud musí být konzistentních více úložišť, zdokumentujte pořadí pozastavení zápisů a vytvoření záloh.

Kopie uchovávejte mimo server s nasazením a zašifrujte materiál obsahující přihlašovací údaje nebo soukromý obsah. Obnova je úspěšná tehdy, když se znovu objeví uživatelé, kolekce, otázky, filtry dashboardů a odběry a spustí se nad obnovenými metadaty připojení. Rozdíl mezi trvalým mountem a nezávislou kopií popisuje článek trvalé úložiště a snapshoty.

Nasazení Metabase na Dockup bez ztráty hranic

Šablona Dockup by měla obsahovat image, port 3000, mounty, časování health checku, doménu, TLS a předávání secretů. Dockup by měl ponechat privátní části dedikované aplikační databáze PostgreSQL oddělené od analytických zdrojů v interní síti a nevystavovat žádný další veřejný port. Stejné nasazení lze cílit na servery Dockup nebo kapacitu připojenou zákazníkem.

Po zprovoznění routy nastavte veřejnou adresu a pokuste se připojit databázi se vzorovými daty pouze pro čtení, uložit otázku, vytvořit dashboard a doručit odběr prostřednictvím nakonfigurovaného e-mailového kanálu. Zálohujte aplikační databázi Metabase, nikoli pouze dotazované zdroje dat, a zahrňte test obnovy do provozního plánu; tyto odpovědnosti Metabase zůstávají viditelné i po zajištění infrastruktury.

Často kladené otázky

Co Metabase potřebuje pro produkční nasazení?

Veďte kontejner Metabase na portu 3000 přes jediný HTTPS origin. Požadavkem podpůrné sítě je dedikovaná aplikační databáze PostgreSQL oddělená od analytických zdrojů. Metabase nepovažujte za připravenou, dokud nemůžete připojit databázi se vzorovými daty pouze pro čtení, uložit otázku, vytvořit dashboard a doručit odběr prostřednictvím nakonfigurovaného e-mailového kanálu.

Která data Metabase patří do zálohy?

Zachovejte /metabase-data a do stejného manifestu pro obnovu zahrňte aplikační databázi Metabase, nikoli pouze dotazované zdroje dat. Čistá obnova Metabase je úspěšná pouze tehdy, když se znovu objeví uživatelé, kolekce, otázky, filtry dashboardů a odběry a spustí se nad obnovenými metadaty připojení.

Vyžaduje Metabase za reverzní proxy HTTPS?

Pro veřejný origin Metabase používejte HTTPS a port 3000 ponechte na interní routě. Nastavení Metabase aplikujte správně: nastavte MB_SITE_URL na veřejný HTTPS origin. U Metabase HTTPS chrání přihlašovací údaje nebo uživatelský obsah během přenosu a zajišťuje konzistentní chování klienta závislé na originu.

Jak testovat aktualizaci Metabase?

Obnovte aktuální stav Metabase do izolovaného nasazení, použijte kandidátní verzi a zopakujte akceptační transakci. Věnujte tomu zvláštní pozornost, protože aplikační databáze Metabase a verze pluginů se musí migrovat společně; dotazované firemní databáze tuto část stavu nenahrazují. Předchozí image Metabase si ponechte, dokud nebudete rozumět hranici migrace dat a návratu k předchozí verzi.