Slik drifter du Kanboard selv i 2026: SQLite, plugins og trygge oppgraderinger

En mislykket Kanboard-deployment krasjer ikke alltid. Den kan vise en login-side selv om SQLite ikke kan skrive fordi den monterte datakatalogen har feil eier. Start i stedet med en end-to-end-kontroll: Bytt ut standardinnloggingen, opprett et prosjekt og en oppgave, flytt oppgaven mellom kolonner, last opp en fil og test én installert plugin.

Denne kontrollen samsvarer med det dokumenterte formålet til Kanboard: et minimalistisk kanban-brett støttet av SQLite. Den avdekker også manglende avhengigheter, feil antakelser om proxyen og ephemeral data tidligere enn en uptime-kontroll kan.

Skill Kanboard fra avhengighetene

Den minste ansvarlige topologien for Kanboard består av én privat listener på port 80, en ingress-rute og en dokumentert grense for state. Det lokale runtime-kravet er et skrivbart data-volume og valgfri SMTP. Hold livssyklusen eksplisitt, slik at flytting av Kanboard mellom verter ikke endrer oppførselen i det stille.

Valider topologien ved å be en ren klient om å bytte ut standardinnloggingen, opprette et prosjekt og en oppgave, flytte oppgaven mellom kolonner, laste opp en fil og teste én installert plugin. Følg med på SQLite-locking, volumet for vedlegg, bakgrunnshandlinger og plugin-oppførsel med samtidige brukere mens dette kjører. Resultatet viser om neste forbedring hører hjemme i minne, storage, nettverk eller en separat worker, i stedet for å oppmuntre til vilkårlig dimensjonering av containeren.

Domener, proxy-headere og port 80

TLS-utstedelse er bare halve Kanboard-ruten. Server brettet over HTTPS, og angi applikasjons-URL-en hvis plugins trenger den. Send trafikken internt til port 80, og videresend det eksterne scheme slik at genererte URL-er og sikre cookies forblir konsistente.

Bruk hele Kanboard-scenarioet fra et rent nettverk, ikke bare rot-siden. En 502-feil eller sertifikatfeil kan isoleres med automatisk domene- og TLS-oppsett. Hvis trafikken når prosessen og SQLite ikke kan skrive fordi den monterte datakatalogen har feil eier, må du diagnostisere tilstanden der den oppstår, i stedet for å legge på flere redirects.

Gjør oppstart av Kanboard reproduserbar

En produksjonslignende oppstart er bevisst kjedelig: navngitt state, eksplisitt port og ingen secrets inne i imaget.

docker run -d \
  --name kanboard \
  --restart unless-stopped \
  -p 127.0.0.1:80:80 \
  -v kanboard-data:/var/www/app/data \
  kanboard/kanboard:latest

Eksempelet er et utgangspunkt, ikke en komplett supporting stack. Bekreft det lokale kravet før eksponering: et skrivbart data-volume og valgfri SMTP. Kontroller de aktive mountene og listeneren, og prøv deretter å bytte ut standardinnloggingen, opprette et prosjekt og en oppgave, flytte oppgaven mellom kolonner, laste opp en fil og teste én installert plugin. Pin imaget som fungerer før neste restart.

Følg med på workloaden, ikke bare containeren

For Kanboard bør du overvåke en transaksjon, ikke bare en prosess: bytt ut standardinnloggingen, opprett et prosjekt og en oppgave, flytt oppgaven mellom kolonner, last opp en fil og test én installert plugin. Kombiner latency og error rate med SQLite-locking, volumet for vedlegg, bakgrunnshandlinger og plugin-oppførsel med samtidige brukere, slik at et alert identifiserer den begrensende komponenten.

Oppgraderingsøvelsen må dekke at database-migreringer og plugin-kompatibilitet krever et snapshot før en Kanboard image update. Gjenopprett, migrer og kjør transaksjonen før du erstatter produksjonsinstansen. Hvis SQLite ikke kan skrive fordi den monterte datakatalogen har feil eier, må du ikke slette data for å få en grønn oppstart. Sammenlign versjon, variabler, mounts og tilgjengelighet til avhengigheter, i den rekkefølgen.

Bevis Kanboard-deploymenten end-to-end

En produksjonskontroll for Kanboard bør kunne utføres av noen som ikke bygget deploymenten. Gi personen den pinnede versjonen, en ikke-sensitiv testkonto og denne oppgaven: Bytt ut standardinnloggingen, opprett et prosjekt og en oppgave, flytt oppgaven mellom kolonner, last opp en fil og test én installert plugin. Hvis instruksjonene krever udokumentert shell-tilgang, er tjenesten ennå ikke driftsklar.

Gjenta kontrollen etter at du bare har byttet ut containeren. Gjenopprett SQLite-database, opplastede filer, plugins og konfigurasjon til blank infrastruktur, og bevis at prosjekter, oppgavehistorikk, brukere, vedlegg og plugins kommer tilbake, og at det gjenopprettede brettet godtar en ny oppgave. Mål SQLite-locking, volumet for vedlegg, bakgrunnshandlinger og plugin-oppførsel med samtidige brukere under begge vellykkede kjøringer. Uventede forskjeller avslører ofte en manglende cache, indeks, worker eller datamount.

Legg til en feilsøkingsøvelse: Send inn ufarlige data nær ressurs- eller formatgrensen som er knyttet til denne grensen: SQLite kan ikke skrive fordi den monterte datakatalogen har feil eier. Kanboard skal skrive ut en nyttig feil, bevare eksisterende state og gjenopprettes når den gyldige tilstanden kommer tilbake. Lagre tidsstemplene og relevante logglinjer, med secrets maskert. Disse bevisene blir referansen for neste image- eller konfigurasjonsendring.

Volumes er bare det første gjenopprettingslaget

Lag et recovery-manifest for Kanboard: SQLite-database, opplastede filer, plugins og konfigurasjon. Mount /var/www/app/data før bootstrap, skriv ufarlige eksempeldata og bytt ut containeren for å bevise at banen faktisk er persistent. Kontroller eierskap og ledig plass nå, fordi en montert, men ikke-skrivbar bane i praksis ikke gir persistence i det hele tatt.

Sikkerhetskopier til et failure domain som er separat fra serveren som kjører. Gjenopprett Kanboard fra det pinnede imaget, og bekreft at prosjekter, oppgavehistorikk, brukere, vedlegg og plugins kommer tilbake, og at det gjenopprettede brettet godtar en ny oppgave. Veiledningen for persistent volumes hjelper deg med å omsette denne øvelsen til en policy for snapshots og retention.

Beskytt den verdifulle delen av Kanboard

En sikker Kanboard-deployment starter med å fjerne privilegier. Unngå å beholde standardlegitimasjonen admin/admin. Fjern i stedet admin/admin umiddelbart, begrens prosjekttilgang og vurder plugins før de får tilgang til produksjonsdata.

Kanboard har ingen obligatorisk bootstrap-secret i dette utgangspunktet. Beskytt den faktiske administratorbrukeren eller upstream-autentiseringen i stedet. Begrens administrative ruter, bruk privat DNS for avhengigheter og vurder alle bind mounts. Når logger sendes sentralt, må secrets og privat innhold filtreres før de forlater serveren.

Slik fjerner Dockup arbeid for Kanboard

En Dockup-mal bør angi imaget, port 80, mounts, health-timing, domene, TLS og levering av secrets. Dockup bør bevare runtime-innstillingene for Kanboard mens operatøren bekrefter dette lokale kravet: et skrivbart data-volume og valgfri SMTP. Den samme deploymenten kan målrettes mot Dockup-servere eller kapasitet som kunden kobler til.

Når ruten er aktiv, bruker du den offentlige innstillingen og prøver å bytte ut standardinnloggingen, opprette et prosjekt og en oppgave, flytte oppgaven mellom kolonner, laste opp en fil og teste én installert plugin. Sikkerhetskopier SQLite-database, opplastede filer, plugins og konfigurasjon, og behold gjenopprettingsøvelsen i driftsplanen. Dette er Kanboard-ansvar som fortsatt er synlig etter at infrastrukturprovisioneringen er fullført.

Vanlige spørsmål

Hva trenger Kanboard for en produksjonsdeployment?

Rout Kanboard-containeren på port 80 gjennom én HTTPS-origin. Det lokale runtime-kravet er et skrivbart data-volume og valgfri SMTP. Ikke erklær Kanboard som klar før du kan bytte ut standardinnloggingen, opprette et prosjekt og en oppgave, flytte oppgaven mellom kolonner, laste opp en fil og teste én installert plugin.

Hvilke Kanboard-data bør inngå i en sikkerhetskopi?

Persist /var/www/app/data, og inkluder SQLite-database, opplastede filer, plugins og konfigurasjon i det samme recovery-manifestet. En ren Kanboard-gjenoppretting er bare vellykket når prosjekter, oppgavehistorikk, brukere, vedlegg og plugins kommer tilbake, og det gjenopprettede brettet godtar en ny oppgave.

Krever Kanboard HTTPS bak en reverse proxy?

Bruk HTTPS for den offentlige Kanboard-origin-en, og behold port 80 på den interne ruten. Bruk Kanboard-innstillingen riktig: Server brettet over HTTPS, og angi applikasjons-URL-en hvis plugins trenger den. For Kanboard beskytter HTTPS credentials eller brukerinnhold under transport og sørger for konsistent klientoppførsel som avhenger av origin.

Hvordan bør en Kanboard-oppgradering testes?

Gjenopprett den gjeldende Kanboard-staten i en isolert deployment, bruk kandidatversjonen og gjenta akseptansetransaksjonen. Vær spesielt oppmerksom på at database-migreringer og plugin-kompatibilitet krever et snapshot før en Kanboard image update. Behold det forrige Kanboard-imaget til grensen for datamigrering og rollback er forstått.