Jak v roce 2026 provozovat Kanboard ve vlastní režii: SQLite, pluginy a bezpečné aktualizace

Neúspěšné nasazení Kanboardu nemusí vždy skončit pádem. Aplikace může zobrazovat přihlašovací stránku, i když SQLite nemůže zapisovat, protože připojený datový adresář má nesprávného vlastníka. Místo toho začněte komplexní kontrolou: změňte výchozí přihlašovací údaje, vytvořte projekt a úkol, přesouvejte ho mezi sloupci, nahrajte soubor a otestujte jeden nainstalovaný plugin.

Tato kontrola odpovídá deklarovanému účelu Kanboardu: minimalistické kanbanové tabuli postavené na SQLite. Odhalí také chybějící závislosti, nesprávné předpoklady o proxy a pomíjivá data dříve než kontrola dostupnosti.

Oddělte Kanboard od jeho závislostí

Nejmenší zodpovědná topologie Kanboardu obsahuje jeden privátní listener na portu 80, ingress route a zdokumentovanou hranici stavu. Lokální požadavek runtime je zapisovatelný datový volume a volitelně SMTP. Životní cyklus udržujte explicitní, aby přesun Kanboardu mezi hosty tiše nezměnil jeho chování.

Topologii ověřte tak, že z čistého klienta změníte výchozí přihlašovací údaje, vytvoříte projekt a úkol, přesunete ho mezi sloupci, nahrajete soubor a otestujete jeden nainstalovaný plugin. Během běhu sledujte zamykání SQLite, objem příloh, akce na pozadí a chování pluginu při souběžném používání více uživateli. 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 náhodnému dimenzování kontejneru.

Domény, hlavičky proxy a port 80

Vydání TLS certifikátu je pouze polovinou cesty Kanboardu. Tabuli zpřístupněte přes HTTPS a nastavte URL aplikace, pokud ho pluginy potřebují. Interně směrujte provoz na port 80 a předávejte externí schéma, aby generované URL a secure cookies zůstaly konzistentní.

Kompletní scénář Kanboardu proveďte z čisté sítě, ne pouze načtením kořenové stránky. Chybu 502 nebo problém s certifikátem lze izolovat pomocí automatického nastavení domény a TLS. Pokud provoz dorazí k procesu a SQLite nemůže zapisovat, protože připojený datový adresář má nesprávného vlastníka, diagnostikujte tento stav přímo tam, kde vzniká, místo abyste vrstvili další redirecty.

Zajistěte reprodukovatelný start Kanboardu

Launch odpovídající produkci je záměrně nudný: pojmenovaný state, explicitní port a žádný secret uvnitř image.

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

Tento příklad je základ, nikoli kompletní supporting stack. Před vystavením služby ověřte lokální požadavek: zapisovatelný datový volume a volitelně SMTP. Zkontrolujte skutečně připojené volumes a listener, poté se pokuste změnit výchozí přihlašovací údaje, vytvořit projekt a úkol, přesunout ho mezi sloupci, nahrát soubor a otestovat jeden nainstalovaný plugin. Před dalším restartem image připněte na konkrétní funkční verzi.

Sledujte workload, ne pouze kontejner

U Kanboardu monitorujte transakci, nikoli proces: změňte výchozí přihlašovací údaje, vytvořte projekt a úkol, přesouvejte ho mezi sloupci, nahrajte soubor a otestujte jeden nainstalovaný plugin. Její latenci a chybovost kombinujte se zamykáním SQLite, objemem příloh, akcemi na pozadí a chováním pluginu při souběžném používání více uživateli, aby alert identifikoval omezenou komponentu.

Rehearsal aktualizace musí zahrnovat skutečnost, že databázové migrace a kompatibilita pluginů vyžadují snapshot před aktualizací image Kanboardu. Před nahrazením produkční instance proveďte restore, migraci a transakci. Pokud SQLite nemůže zapisovat, protože připojený datový adresář má nesprávného vlastníka, nemažte data jen proto, aby startup skončil úspěšně; v uvedeném pořadí porovnejte verzi, proměnné, připojení a dostupnost závislostí.

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

Produkční gate pro Kanboard musí být proveditelný někým, kdo nasazení nevytvořil. Této osobě předejte připnutou verzi, testovací účet bez citlivých údajů a tento úkol: změnit výchozí přihlašovací údaje, vytvořit projekt a úkol, přesunout ho mezi sloupci, nahrát soubor a otestovat jeden nainstalovaný plugin. Pokud pokyny vyžadují nedokumentovaný shell access, služba ještě není provozně připravená.

Gate zopakujte po nahrazení pouze kontejneru. Poté obnovte SQLite databázi, nahrané soubory, pluginy a konfiguraci do prázdné infrastruktury a ověřte, že se vrátí projekty, historie úkolů, uživatelé, přílohy a pluginy a že obnovená tabule přijme nový úkol. Během obou úspěšných běhů měřte zamykání SQLite, objem příloh, akce na pozadí a chování pluginu při souběžném používání více uživateli; neočekávané rozdíly často odhalí chybějící cache, index, worker nebo datový mount.

Přidejte také nácvik selhání: odešlete neškodný vstup poblíž limitu zdrojů nebo formátu souvisejícího s touto hranicí: SQLite nemůže zapisovat, protože připojený datový adresář má nesprávného vlastníka. Kanboard by měl vypsat užitečnou chybu, zachovat stávající stav a po návratu platných podmínek se zotavit. Uložte časové značky a relevantní řádky logu, přičemž začerňte secrets. Tyto důkazy se stanou referencí pro další změnu image nebo konfigurace.

Volumes jsou pouze první vrstvou obnovy

Vytvořte pro Kanboard recovery manifest: SQLite databázi, nahrané soubory, pluginy a konfiguraci. Před bootstrapem připojte /var/www/app/data, zapište neškodná ukázková data a nahraďte kontejner, abyste prokázali, že je tato cesta skutečně persistentní. Vlastnictví a volné místo zkontrolujte hned, protože připojená, ale nezapisovatelná cesta se chová, jako by žádná persistence neexistovala.

Zálohujte do failure domain oddělené od běžícího serveru. Znovu vytvořte Kanboard z připnuté image a ověřte, že se vrátí projekty, historie úkolů, uživatelé, přílohy a pluginy a že obnovená tabule přijme nový úkol. Průvodce persistentními volumes pomůže převést toto cvičení do politiky snapshotů a retence.

Chraňte to, na čem Kanboardu záleží

Bezpečné nasazení Kanboardu začíná odebráním oprávnění. Nenechávejte výchozí přihlašovací údaje admin/admin; místo toho účet admin/admin ihned odstraňte, omezte přístup k projektům a před udělením přístupu k produkčním datům pluginy zkontrolujte.

Kanboard v tomto základním scénáři nevyžaduje povinný bootstrap secret; chraňte místo toho skutečný účet administrátora nebo upstream authentication. Omezte administrativní routes, pro závislosti používejte privátní DNS a zkontrolujte každý bind mount. Při centrálním odesílání logů odfiltrujte secrets a soukromý obsah ještě před jejich opuštěním serveru.

Kde Dockup odstraňuje práci s Kanboardem

Šablona Dockup by měla zapouzdřit image, port 80, mounty, načasování health checků, doménu, TLS a předávání secretů. Dockup by měl zachovat runtime nastavení Kanboardu, zatímco operátor ověří tento lokální požadavek: zapisovatelný datový volume a volitelně SMTP. Stejné nasazení může cílit na servery Dockup nebo kapacitu připojenou zákazníkem.

Po zprovoznění route nastavte veřejné nastavení a pokuste se změnit výchozí přihlašovací údaje, vytvořit projekt a úkol, přesunout ho mezi sloupci, nahrát soubor a otestovat jeden nainstalovaný plugin. Zálohujte SQLite databázi, nahrané soubory, pluginy a konfiguraci a obnovu ponechte součástí provozního plánu; to jsou odpovědnosti Kanboardu, které zůstávají viditelné i po provisioningu infrastruktury.

Často kladené otázky

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

Kontejner Kanboardu směrujte přes jeden HTTPS origin na port 80. Lokální požadavek runtime je zapisovatelný datový volume a volitelně SMTP. Kanboard nepovažujte za připravený, dokud nemůžete změnit výchozí přihlašovací údaje, vytvořit projekt a úkol, přesunout ho mezi sloupci, nahrát soubor a otestovat jeden nainstalovaný plugin.

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

Zachovejte /var/www/app/data a do stejného recovery manifestu zahrňte SQLite databázi, nahrané soubory, pluginy a konfiguraci. Čistý restore Kanboardu je úspěšný pouze tehdy, když se vrátí projekty, historie úkolů, uživatelé, přílohy a pluginy a obnovená tabule přijme nový úkol.

Vyžaduje Kanboard za reverse proxy HTTPS?

Pro veřejný origin Kanboardu používejte HTTPS a na interní route ponechte port 80. Nastavení Kanboardu aplikujte správně: tabuli zpřístupněte přes HTTPS a nastavte URL aplikace, pokud ho pluginy potřebují. U Kanboardu HTTPS chrání přihlašovací údaje nebo uživatelský obsah při přenosu a zachovává konzistentní chování klienta závislé na originu.

Jak testovat aktualizaci Kanboardu?

Obnovte aktuální stav Kanboardu do izolovaného nasazení, aplikujte kandidátní verzi a zopakujte jeho akceptační transakci. Zvláštní pozornost věnujte tomu, že databázové migrace a kompatibilita pluginů vyžadují snapshot před aktualizací image Kanboardu. Předchozí image Kanboardu ponechte, dokud nebudete rozumět hranici migrace dat a rollbacku.