Slik drifter du Metabase selv i 2026: applikasjonsdatabase, TLS og sikkerhetskopier

Hvis du allerede har prøvd å drifte Metabase selv, kjenner du sannsynligvis den frustrerende situasjonen: Grensesnittet vises, men applikasjonsdatabasen mangler, selv om kildedatabasene for dashboardene fortsatt finnes. Å opprette containeren på nytt løser sjelden uoverensstemmelser mellom URL-er, state og avhengigheter.

Denne gjennomgangen bruker ett konkret ferdigkriterium — koble til en skrivebeskyttet eksempeldatabase, lagre et spørsmål, bygg et dashboard og lever et abonnement gjennom den konfigurerte e-postkanalen. Alle konfigurasjonsvalg vurderes opp mot dette kriteriet, ikke mot et grønt containermerke.

Påloggingsopplysninger, roller og eksponerte flater

Trusselmodeller handlingen Metabase utfører, ikke bare innloggingsskjemaet. Den største risikoen her er å bruke den innebygde H2-applikasjonsdatabasen som eneste produksjonskopi. Implementer denne grensen: Gi Metabase skrivebeskyttede databasetilganger der det er mulig, og hold rettigheter til collections adskilt fra databasepåloggingsopplysninger.

Generer MB_ENCRYPTION_SECRET_KEY én gang, hold den utenfor Git og bevar den sammen med recovery-manifestet, fordi en endring kan ugyldiggjøre kryptert eller signert applikasjonsstate. Ikke løs et rettighetsproblem ved å kjøre containeren som root eller montere hele vertsmaskinen bredt. Ressursbegrensninger inngår også i sikkerhetsdesignet når JVM-heap, samtidige spørringer, result caching og belastningen som overføres til hver analytics-datakilde kan utløses av brukere.

Skill Metabase fra avhengighetene

Den minste ansvarlige Metabase-topologien består av én privat listener på 3000, en ingress-rute og en dokumentert state-grense. Nettverkskontrakten for Metabase er en dedikert Postgres-applikasjonsdatabase, atskilt fra analytics-kildene. Hold private endepunkter på intern DNS, tillat bare nødvendige utgående kall og gi Metabase en begrenset servicekonto.

Valider topologien ved å be en ren klient koble til en skrivebeskyttet eksempeldatabase, lagre et spørsmål, bygge et dashboard og levere et abonnement gjennom den konfigurerte e-postkanalen. Følg med på JVM-heap, samtidige spørringer, result caching og belastningen som overføres til hver analytics-datakilde mens den kjører. Resultatet viser om neste forbedring hører hjemme i minne, lagring, nettverk eller en separat worker, i stedet for å oppmuntre til vilkårlig dimensjonering av containere.

Et Docker-grunnlag for Metabase

Følgende kommando synliggjør containergrensen uten å late som om alle eksterne tjenester blir provisjonert.

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

Før du åpner ingress, kontroller det evaluerte miljøet, mounts og listeneren. Legg til de gjennomgåtte tilkoblingsinnstillingene for en dedikert Postgres-applikasjonsdatabase, atskilt fra analytics-kildene, og bruk private navn for private tjenester. En vellykket oppstart er først fullført når du kan koble til en skrivebeskyttet eksempeldatabase, lagre et spørsmål, bygge et dashboard og levere et abonnement gjennom den konfigurerte e-postkanalen — ikke når docker ps skriver ut Up.

Verifiser Metabase-distribusjonen fra ende til ende

En produksjonsport for Metabase bør kunne gjennomføres av noen som ikke bygget distribusjonen. Gi personen den låste versjonen, en ikke-sensitiv testkonto og denne oppgaven: Koble til en skrivebeskyttet eksempeldatabase, lagre et spørsmål, bygg et dashboard og lever et abonnement gjennom den konfigurerte e-postkanalen. Hvis instruksjonene krever udokumentert shell-tilgang, er tjenesten ennå ikke driftsklar.

Gjenta testen etter at du bare har byttet ut containeren. Gjenopprett deretter Metabase-applikasjonsdatabasen, ikke bare spurte datakilder, til en tom infrastruktur, og verifiser at brukere, collections, spørsmål, dashboard-filtre og abonnementer vises igjen og kjører mot de gjenopprettede tilkoblingsmetadataene. Mål JVM-heap, samtidige spørringer, result caching og belastningen som overføres til hver analytics-datakilde under begge vellykkede kjøringer. Uventede forskjeller avslører ofte en manglende cache, indeks, worker eller datamount.

Legg til en feiløvelse: Nekt testidentiteten midlertidig tilgang til en dedikert Postgres-applikasjonsdatabase, atskilt fra analytics-kildene. Metabase bør vise en nyttig feilmelding, bevare eksisterende state og hente seg inn når den gyldige tilstanden gjenopprettes. Lagre tidsstemplene og relevante logglinjer, med secrets maskert. Dette beviset blir referansen for neste image- eller konfigurasjonsendring.

Hold interne og eksterne URL-er adskilt

Nettleseren, API-klienten og Metabase må være enige om én origin. For å oppnå dette setter du MB_SITE_URL til den offentlige HTTPS-origin-en. Bevar den opprinnelige hosten og protokollen, samtidig som port 3000 ikke er tilgjengelig som en konkurrerende offentlig adresse.

Feilsøkingsveiledningen for et nettsted som er nede hjelper deg med å skille mellom en utilgjengelig rute og en applikasjon som svarer. Dette skillet er viktig her: Applikasjonsdatabasen mangler, selv om kildedatabasene for dashboardene fortsatt finnes. Bare det førstnevnte løses med ingress-endringer; det sistnevnte krever inspeksjon av Metabase-logger, state eller arbeidsbelastning.

Driftssett Metabase rundt den faktiske flaskehalsen

For Metabase bør du overvåke en transaksjon, ikke en prosess: Koble til en skrivebeskyttet eksempeldatabase, lagre et spørsmål, bygg et dashboard og lever et abonnement gjennom den konfigurerte e-postkanalen. Kombiner forsinkelsen og feilraten med JVM-heap, samtidige spørringer, result caching og belastningen som overføres til hver analytics-datakilde, slik at et alert identifiserer den begrensede komponenten.

Oppgraderingsøvelsen må dekke at Metabase-applikasjonsdatabasen og plugin-versjonene må migreres sammen; spurte forretningsdatabaser er ikke en erstatning for denne staten. Gjenopprett, migrer og kjør transaksjonen før produksjonsbytte. Hvis applikasjonsdatabasen mangler, selv om kildedatabasene for dashboardene fortsatt finnes, må du ikke slette data for å få en grønn oppstart. Sammenlign versjon, variabler, mounts og tilgjengelighet til avhengigheter i denne rekkefølgen.

Volumer er bare det første laget for gjenoppretting

Beskytt Metabase-state før du optimaliserer containeren. Det nødvendige settet er Metabase-applikasjonsdatabasen, ikke bare spurte datakilder. Monter /metabase-data før bootstrap, skriv ufarlige eksempeldata og bytt ut containeren for å bevise at banen faktisk er persistent. Hvis flere lagre må være konsistente, dokumenter rekkefølgen for når skriving settes på pause og sikkerhetskopier tas.

Oppbevar kopier utenfor distribusjonsserveren, og krypter materiale som inneholder påloggingsopplysninger eller privat innhold. Gjenopprettingen er vellykket når brukere, collections, spørsmål, dashboard-filtre og abonnementer vises igjen og kjører mot de gjenopprettede tilkoblingsmetadataene. Forskjellen mellom en persistent mount og en uavhengig kopi er beskrevet i persistent lagring og snapshots.

Distribuer Metabase på Dockup uten å miste grensene

En Dockup-mal bør definere image, port 3000, mounts, health-timing, domene, TLS og levering av secrets. Dockup bør holde private deler av en dedikert Postgres-applikasjonsdatabase atskilt fra analytics-kildene på internt nettverk og ikke eksponere noen ekstra offentlig port. Den samme distribusjonen kan målrettes mot Dockup-servere eller kundetilknyttet kapasitet.

Når ruten er aktiv, bruker du den offentlige innstillingen og prøver å koble til en skrivebeskyttet eksempeldatabase, lagre et spørsmål, bygge et dashboard og levere et abonnement gjennom den konfigurerte e-postkanalen. Sikkerhetskopier Metabase-applikasjonsdatabasen, ikke bare spurte datakilder, og ta med gjenopprettingsøvelsen i driftsplanen. Dette er Metabase-ansvar som fortsatt er synlig etter at infrastrukturen er provisjonert.

Vanlige spørsmål

Hva trenger Metabase for en produksjonsdistribusjon?

Rout Metabase-containeren på port 3000 gjennom én HTTPS-origin. Nettverkskravet er en dedikert Postgres-applikasjonsdatabase, atskilt fra analytics-kildene. Ikke erklær Metabase klar før du kan koble til en skrivebeskyttet eksempeldatabase, lagre et spørsmål, bygge et dashboard og levere et abonnement gjennom den konfigurerte e-postkanalen.

Hvilke Metabase-data skal inngå i en sikkerhetskopi?

Gjør /metabase-data persistent og inkluder Metabase-applikasjonsdatabasen, ikke bare spurte datakilder, i det samme recovery-manifestet. En ren Metabase-gjenoppretting er først vellykket når brukere, collections, spørsmål, dashboard-filtre og abonnementer vises igjen og kjører mot de gjenopprettede tilkoblingsmetadataene.

Krever Metabase HTTPS bak en reverse proxy?

Bruk HTTPS for den offentlige Metabase-origin-en, og hold port 3000 på den interne ruten. Bruk Metabase-innstillingen riktig: Sett MB_SITE_URL til den offentlige HTTPS-origin-en. For Metabase beskytter HTTPS påloggingsopplysninger eller brukerinnhold under transport og sørger for konsekvent klientatferd som er avhengig av origin.

Hvordan bør en Metabase-oppgradering testes?

Gjenopprett gjeldende Metabase-state til en isolert distribusjon, bruk kandidatversjonen og gjenta akseptansetransaksjonen. Vær spesielt oppmerksom på at Metabase-applikasjonsdatabasen og plugin-versjonene må migreres sammen; spurte forretningsdatabaser er ikke en erstatning for denne staten. Behold det forrige Metabase-imaget til grensen for datamigrering og rollback er forstått.