Jak si v roce 2026 hostovat Vikunju: veřejná URL, databáze a úložiště souborů

Pokud jste se už pokoušeli hostovat Vikunju na vlastní infrastruktuře, nejspíš znáte frustrující stav, kdy se zobrazí UI, ale veřejná URL API je nesprávná nebo nahrané soubory nejsou uložené na volume. Opětovné vytvoření containeru jen zřídka vyřeší nesoulad mezi URL, stavem a závislostmi.

Tento postup používá jedno konkrétní kritérium dokončení — vytvořit projekt, úkol, přílohu a připomínku, přesunout úkol na boardu a ověřit událost v kalendáři i notifikaci. Každé konfigurační rozhodnutí posuzujeme podle tohoto kritéria, nikoli podle zeleného odznaku containeru.

Na čem Vikunja závisí

Kolem Vikunji si vymezte tři hranice: ingress na port 3456, trvalý stav a podpůrné požadavky. Container lze nahradit, ale u zbývajících dvou oblastí je potřeba explicitně určit vlastníka. Síťová smlouva Vikunji pro produkční týmy zahrnuje Postgres nebo MySQL a SMTP. Soukromé endpointy ponechte na interním DNS, povolte pouze nezbytná odchozí volání a Vikunje přidělte service credential s omezeným rozsahem oprávnění.

Diagram je kompletní ve chvíli, kdy čistý klient dokáže vytvořit projekt, úkol, přílohu a připomínku, přesunout úkol na boardu a ověřit událost v kalendáři i notifikaci. Ukládejte údaje o čase a prostředcích pro přenosy příloh, databázové dotazy, background jobs a odchozí e-maily, nikoli pouze pro malý API proces. Pokud transakce selže, první hranice, která se nechová podle dokumentace, ukáže, zda je třeba prověřit routing, lokální kapacitu nebo podpůrnou službu.

Volumes jsou pouze první vrstvou obnovy

Ještě před vytvořením prvního skutečného záznamu si vypište, kde se nachází stav aplikace: databáze, nahrané soubory a konfigurace. Připojte /app/vikunja/files před bootstrapem, zapište neškodná testovací data a nahraďte container, abyste ověřili, že je tato cesta skutečně persistentní. Připojení ověřte zápisem neškodných dat, nahrazením Vikunji a jejich opětovným načtením.

Snapshoty jsou cenné pro rychlý rollback, ale v případě zmizení hostitele nebo volume potřebujete nezávislou zálohu. Obnovte data do prázdného prostředí s připnutým image a ověřte, že se vrátí projekty, historie úkolů, přílohy, připomínky a uživatelé a že se stále odešle naplánovaná notifikace. Pro zachování rozdílu mezi těmito dvěma mechanismy obnovy použijte persistent volumes and snapshots.

Chraňte to cenné ve Vikunje

Po prvním přihlášení zkontrolujte, co může dělat anonymní návštěvník, běžný uživatel a administrátor. Selháním Vikunji, kterému se chcete vyhnout, je použití nezměněného JWT secretu nebo nechtěně otevřená registrace. Zamýšlená politika spočívá v použití stabilního JWT secretu, uzavření registrace po skončení náboru a oddělení běžných členů od administrátorů projektů.

Vygenerujte VIKUNJA_SERVICE_JWTSECRET jako dlouhou náhodnou hodnotu; její změna obvykle zneplatní sessions nebo tokeny, proto si naplánujte dopad na uživatele a neoznačujte ji za migraci šifrování. Účty pro závislosti držte odděleně od účtů lidí, pokud možno zakažte nepotřebný egress a omezte práci ovlivněnou přenosem příloh, databázovými dotazy, background jobs a odchozími e-maily, nikoli pouze malým API procesem.

Proměňte smoke test Vikunji v kontrolu před vydáním

Release candidate Vikunji získá povolení k obsluze provozu po dokončení pevně daného scénáře: vytvořit projekt, úkol, přílohu a připomínku, přesunout úkol na boardu a ověřit událost v kalendáři i notifikaci. Pro tento scénář zaznamenejte digest image, efektivní konfiguraci bez tajných údajů, veřejný origin a časová razítka. Testovací data by měla být odstranitelná, ale dostatečně realistická, aby pokryla stejnou cestu jako u uživatelů.

Spusťte tento test po nahrazení runtime a poté službu znovu sestavte z databáze, nahraných souborů a konfigurace. Obnova je úspěšná, pokud se vrátí projekty, historie úkolů, přílohy, připomínky a uživatelé a stále se odešle naplánovaná notifikace. Porovnejte s předchozím vydáním měření prostředků pro přenosy příloh, databázové dotazy, background jobs a odchozí e-maily, nikoli pouze pro malý API proces, a před nasazením prozkoumejte významné odchylky.

Nakonec proveďte toto řízené selhání: dočasně odeberte testovací identitě přístup k Postgresu nebo MySQL a SMTP pro produkční týmy. Ověřte, že Vikunja selhání vysvětlí, nepoškodí existující stav a po obnovení platných podmínek bude pokračovat v provozu. Uložte redigovaný výňatek z logu a dobu obnovy. Tyto kontroly společně pokrývají chování, trvanlivost dat i provozuschopnost, nikoli pouze dostupnost procesu.

Vytvořte nahraditelný container Vikunji

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

docker run -d \
  --name vikunja \
  --restart unless-stopped \
  -p 127.0.0.1:3456:3456 \
  -v vikunja-data:/app/vikunja/files \
  -e VIKUNJA_SERVICE_JWTSECRET=replace-with-a-long-random-value \
  vikunja/vikunja:latest

Před otevřením ingressu zkontrolujte výsledné environment variables, mounts a listener. Přidejte ověřené connection settings pro Postgres nebo MySQL a SMTP pro produkční týmy; pro soukromé služby používejte soukromé názvy. Úspěšné spuštění končí ve chvíli, kdy dokážete vytvořit projekt, úkol, přílohu a připomínku, přesunout úkol na boardu a ověřit událost v kalendáři i notifikaci — ne ve chvíli, kdy docker ps vypíše Up.

Směrujte Vikunju, aniž byste zkreslili HTTPS

Vyhněte se dočasným i trvalým veřejným originům Vikunji. Místo toho nastavte VIKUNJA_SERVICE_PUBLICURL na přesný HTTPS origin, nasměrujte zvolený DNS název na route platformy a proxy směrujte pouze na port 3456.

Proveďte tuto operaci mimo hostitele: vytvořte projekt, úkol, přílohu a připomínku, přesuňte úkol na boardu a ověřte událost v kalendáři i notifikaci. Pokud ingress selže, průvodce řešením chyby 502 popisuje chyby portu a listeneru. Pokud Vikunja požadavek přijme, ale veřejná URL API je nesprávná nebo nahrané soubory nejsou na volume, důkazy nyní ukazují mimo proxy.

Diagnostikujte Vikunju, která vypadá zdravě

U Vikunji monitorujte transakci, nikoli proces: vytvořte projekt, úkol, přílohu a připomínku, přesuňte úkol na boardu a ověřte událost v kalendáři i notifikaci. Její latenci a chybovost kombinujte s přenosy příloh, databázovými dotazy, background jobs a odchozími e-maily, nikoli pouze s malým API procesem, aby alert identifikoval omezenou komponentu.

Rehearsal upgradu musí zahrnovat testování databázových migrací a kompatibility frontendu s API před změnou verze Vikunji. Před nahrazením produkční instance proveďte obnovu, migraci a transakci. Pokud je veřejná URL API nesprávná nebo nahrané soubory nejsou na volume, nemažte data jen proto, aby spuštění vypadalo úspěšně; v uvedeném pořadí porovnejte verzi, proměnné, mounts a dostupnost závislostí.

Nasazujte Vikunju na Dockupu, aniž byste přišli o její hranice

Dockup může převzít nahraditelné části platformy: směrovat provoz na port 3456, vystavit doménu a certifikát, injectovat secrets, připojit persistentní úložiště a propojit Vikunju s managed nebo privátně připojenými službami. To vše může proběhnout na infrastruktuře Dockupu nebo na serveru, který připojíte.

Akceptační práce pro Vikunju zůstává explicitní. Po nasazení jedním kliknutím nastavte VIKUNJA_SERVICE_PUBLICURL na přesný HTTPS origin, připojte a otestujte Postgres nebo MySQL a SMTP pro produkční týmy a spusťte tento scénář: vytvořte projekt, úkol, přílohu a připomínku, přesuňte úkol na boardu a ověřte událost v kalendáři i notifikaci. Toto rozdělení je záměrné: Dockup odstraňuje opakované nastavování infrastruktury, aniž by předstíral, že se role v aplikaci, credentials poskytovatelů nebo pravidla obnovy rozhodnou samy.

Často kladené otázky

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

Směrujte container Vikunji na portu 3456 přes jeden HTTPS origin. Požadavkem podpůrné sítě jsou Postgres nebo MySQL a SMTP pro produkční týmy. Vikunju nepovažujte za připravenou, dokud nedokážete vytvořit projekt, úkol, přílohu a připomínku, přesunout úkol na boardu a ověřit událost v kalendáři i notifikaci.

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

Zachovejte /app/vikunja/files a zahrňte databázi, nahrané soubory a konfiguraci do stejného manifestu obnovy. Čistá obnova Vikunji je úspěšná pouze tehdy, když se vrátí projekty, historie úkolů, přílohy, připomínky a uživatelé a stále se odešle naplánovaná notifikace.

Vyžaduje Vikunja HTTPS za reverse proxy?

Pro veřejný origin Vikunji používejte HTTPS a port 3456 ponechte na interní route. Nastavení Vikunji aplikujte správně: nastavte VIKUNJA_SERVICE_PUBLICURL na přesný HTTPS origin. U Vikunji HTTPS chrání credentials nebo obsah uživatelů během přenosu a zachovává konzistentní chování klienta závislé na originu.

Jak testovat upgrade Vikunji?

Obnovte aktuální stav Vikunji do izolovaného nasazení, aplikujte kandidátní verzi a zopakujte akceptační transakci. Zvláštní pozornost věnujte tomu, že databázové migrace a kompatibilita frontendu s API se musí otestovat před změnou verze Vikunji. Předchozí image Vikunji si ponechte, dokud nebudete rozumět hranici migrace dat a rollbacku.