Vikunjan itse ylläpito vuonna 2026: julkinen URL, tietokanta ja tiedostotallennus
Ylläpidä Vikunjaa itse oikeilla porteilla, pysyvällä tallennustilalla, HTTPS:llä, salaisuuksilla, varmuuskopioilla ja päivitystarkistuksilla. Opi korjaamaan tilanne, jossa APIn julkinen URL on väärä.
Jos olet jo yrittänyt ylläpitää Vikunjaa itse, tämä turhauttava tilanne on luultavasti tuttu: käyttöliittymä näkyy, mutta APIn julkinen URL on väärä tai ladatut tiedostot eivät ole volyymilla. Kontin luominen uudelleen korjaa harvoin URL-osoitteiden, tilan ja riippuvuuksien välisen ristiriidan.
Tässä ohjeessa käytetään yhtä konkreettista onnistumiskriteeriä: luo projekti, tehtävä, liite ja muistutus, siirrä tehtävää taululla ja varmista sen kalenteritapahtuma sekä ilmoitus. Jokainen määritysvalinta arvioidaan tämän kriteerin perusteella, ei vihreän konttimerkin perusteella.
Mistä Vikunja riippuu
Rajaa Vikunjan ympärille kolme aluetta: porttiin 3456 tuleva liikenne, pysyvä tila ja tukivaatimukset. Kontti voidaan vaihtaa, mutta kahdelle muulle on määritettävä selkeät omistajat. Vikunjan verkkosopimus tuotantotiimeille koostuu Postgres- tai MySQL-tietokannasta ja SMTP:stä. Pidä yksityiset päätepisteet sisäisessä DNS:ssä, salli vain tarvittavat ulospäin suuntautuvat kutsut ja anna Vikunjalle rajatuilla oikeuksilla varustettu palvelutunnus.
Kaavio on valmis, kun puhdas asiakas voi luoda projektin, tehtävän, liitteen ja muistutuksen, siirtää tehtävää taululla ja varmistaa sen kalenteritapahtuman sekä ilmoituksen. Kerää ajoitus- ja resurssitiedot liiteliikenteestä, tietokantakyselyistä, taustatöistä ja lähtevistä sähköposteista, älä vain pienestä API-prosessista. Jos tapahtuma epäonnistuu, ensimmäinen dokumentoidulla tavalla toimimaton rajapinta kertoo, pitääkö tutkia reititystä, paikallista kapasiteettia vai tukipalvelua.
Volyymit ovat vasta ensimmäinen palautuskerros
Luettele tila ennen ensimmäisen oikean tietueen luomista: tietokanta, ladatut tiedostot ja määritykset. Liitä /app/vikunja/files ennen alustusta, kirjoita sinne vaaratonta esimerkkidataa ja vaihda kontti varmistaaksesi, että polku on todella pysyvä. Vahvista liitos kirjoittamalla vaaratonta dataa, vaihtamalla Vikunja ja lukemalla data takaisin.
Snapshotit ovat hyödyllisiä nopeassa palautuksessa, mutta erillinen varmuuskopio tarvitaan, jos isäntä tai volyymi katoaa. Palauta tiedot tyhjään ympäristöön käyttäen lukittua image-versiota ja varmista, että projektit, tehtävähistoria, liitteet, muistutukset ja käyttäjät palautuvat ja ajastettu ilmoitus lähetetään edelleen. Hyödynnä pysyviä volyymeja ja snapshoteja pitääksesi nämä kaksi palautusmekanismia erillään.
Suojaa Vikunjan arvokas osa
Ensimmäisen kirjautumisen jälkeen tarkista, mitä anonyymi vierailija, tavallinen käyttäjä ja ylläpitäjä voivat kukin tehdä. Vikunjan vältettävä ongelma on muuttumattoman JWT-salaisuuden käyttäminen tai rekisteröitymisen jättäminen vahingossa avoimeksi. Tavoiteltu käytäntö on käyttää pysyvää JWT-salaisuutta, sulkea rekisteröityminen ilmoittautumisjakson päätyttyä ja erottaa tavalliset jäsenet projektien ylläpitäjistä.
Luo VIKUNJA_SERVICE_JWTSECRET-arvolle pitkä ja satunnainen arvo. Sen vaihtaminen mitätöi yleensä istunnot tai tokenit, joten suunnittele vaikutus käyttäjille sen sijaan, että kutsuisit sitä salauksen siirroksi. Pidä riippuvuuksien tunnukset erillään ihmisten käyttäjätileistä, estä tarpeettomat ulospäin suuntautuvat yhteydet mahdollisuuksien mukaan ja rajoita liiteliikenteen, tietokantakyselyiden, taustatöiden ja lähtevän sähköpostin kuormaa aiheuttavia töitä, älä vain pientä API-prosessia.
Muuta Vikunjan smoke-testi julkaisun tarkistukseksi
Vikunjan release candidate ansaitsee liikennettä suorittamalla ennalta määritetyn skenaarion: luo projekti, tehtävä, liite ja muistutus, siirrä tehtävää taululla ja varmista sen kalenteritapahtuma sekä ilmoitus. Tallenna tätä skenaariota varten imagen digest, tehokas ei-salainen määritys, julkinen origin ja aikaleimat. Testidatan tulee olla hävitettävää, mutta riittävän realistista käyttäjien käyttämän saman polun testaamiseen.
Suorita testi runtimen vaihtamisen jälkeen ja rakenna palvelu sitten uudelleen tietokannasta, ladatuista tiedostoista ja määrityksistä. Palautus onnistuu, kun projektit, tehtävähistoria, liitteet, muistutukset ja käyttäjät palautuvat ja ajastettu ilmoitus lähetetään edelleen. Vertaa liiteliikenteen, tietokantakyselyiden, taustatöiden ja lähtevän sähköpostin resurssimittauksia aiempaan julkaisuun, älä vain pientä API-prosessia, ja tutki merkittävä poikkeama ennen käyttöönottoa.
Testaa lopuksi tämä hallittu vikatilanne: estä testitunnukselta väliaikaisesti pääsy Postgres- tai MySQL-tietokantaan ja tuotantotiimien SMTP-palveluun. Varmista, että Vikunja kuvaa vian, ei vahingoita olemassa olevaa tilaa ja jatkaa toimintaansa, kun oikea tila palautuu. Tallenna sensuroitu lokikatkelma ja palautumisaika. Yhdessä nämä tarkistukset kattavat toiminnan, säilyvyyden ja operoitavuuden eivätkä vain prosessin käynnissäoloa.
Rakenna vaihdettava Vikunja-kontti
Seuraava komento tekee kontin rajapinnan näkyväksi ilman, että se teeskentelee kaikkien ulkoisten palvelujen käyttöönottoa.
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
Ennen liikenteen avaamista tarkista ratkaistu ympäristö, liitokset ja kuuntelija. Lisää tarkistetut Postgres- tai MySQL-yhteysasetukset sekä tuotantotiimien SMTP-asetukset ja käytä yksityisille palveluille yksityisiä nimiä. Käynnistys onnistuu vasta, kun voit luoda projektin, tehtävän, liitteen ja muistutuksen, siirtää tehtävää taululla ja varmistaa sen kalenteritapahtuman sekä ilmoituksen – ei silloin, kun docker ps tulostaa Up.
Reititä Vikunja ilman virheellistä HTTPS-tietoa
Vältä väliaikaisia ja pysyviä julkisia origineja Vikunjalle. Aseta sen sijaan VIKUNJA_SERVICE_PUBLICURL täsmälleen oikeaan HTTPS-originiin, osoita valittu DNS-nimi alustan reitille ja välitä liikenne vain porttiin 3456.
Suorita tämä testi isännän ulkopuolelta: luo projekti, tehtävä, liite ja muistutus, siirrä tehtävää taululla ja varmista sen kalenteritapahtuma sekä ilmoitus. Jos liikenteen sisääntulo epäonnistuu, 502-virheiden vianmääritysopas käsittelee portti- ja kuunteluvirheitä. Jos Vikunja vastaanottaa pyynnön, mutta APIn julkinen URL on väärä tai ladatut tiedostot eivät ole volyymilla, näyttö viittaa nyt välityspalvelimen ulkopuoliseen ongelmaan.
Vianmääritys terveen näköisessä Vikunjassa
Valvo Vikunjassa tapahtumaa prosessin sijaan: luo projekti, tehtävä, liite ja muistutus, siirrä tehtävää taululla ja varmista sen kalenteritapahtuma sekä ilmoitus. Yhdistä sen viive ja virhesuhde liiteliikenteeseen, tietokantakyselyihin, taustatöihin ja lähtevään sähköpostiin, älä vain pieneen API-prosessiin, jotta hälytys kertoo rajoittuneen komponentin.
Päivitysharjoituksen on katettava se, että tietokantamigraatiot ja frontend/APIn yhteensopivuus on testattava ennen Vikunjan version vaihtamista. Palauta tiedot, suorita migraatio ja aja tapahtuma ennen tuotantokorvausta. Jos APIn julkinen URL on väärä tai ladatut tiedostot eivät ole volyymilla, älä poista dataa saadaksesi käynnistyksen onnistumaan, vaan vertaa tässä järjestyksessä versiota, muuttujia, liitoksia ja riippuvuuksien tavoitettavuutta.
Ota Vikunja käyttöön Dockupissa säilyttäen rajat
Dockup voi hallinnoida vaihdettavan alustan osia: reitittää liikenteen porttiin 3456, ottaa käyttöön domainin ja sertifikaatin, välittää salaisuudet, liittää pysyvän tallennustilan ja yhdistää Vikunjan hallittuihin tai yksityisesti liitettyihin palveluihin. Tämä voidaan tehdä Dockupin infrastruktuurissa tai liittämässäsi palvelimessa.
Vikunjan hyväksyntätestit on silti tehtävä erikseen. Yhden napsautuksen käyttöönoton jälkeen aseta VIKUNJA_SERVICE_PUBLICURL täsmälleen oikeaan HTTPS-originiin, yhdistä ja testaa Postgres- tai MySQL-tietokanta sekä tuotantotiimien SMTP ja suorita tämä skenaario: luo projekti, tehtävä, liite ja muistutus, siirrä tehtävää taululla ja varmista sen kalenteritapahtuma sekä ilmoitus. Tämä jako on tarkoituksellinen: Dockup poistaa toistuvan infrastruktuurin määritystyön teeskentelemättä, että sovellusroolit, palveluntarjoajan tunnukset tai palautuskäytäntö valikoituisivat itsestään.
Usein kysytyt kysymykset
Mitä Vikunja tarvitsee tuotantokäyttöönottoon?
Reititä Vikunja-kontti portissa 3456 yhden HTTPS-originin kautta. Verkon tukivaatimuksiin kuuluvat Postgres- tai MySQL-tietokanta ja tuotantotiimien SMTP. Älä pidä Vikunjaa valmiina, ennen kuin voit luoda projektin, tehtävän, liitteen ja muistutuksen, siirtää tehtävää taululla ja varmistaa sen kalenteritapahtuman sekä ilmoituksen.
Mitkä Vikunjan tiedot kuuluvat varmuuskopioihin?
Säilytä /app/vikunja/files ja sisällytä tietokanta, ladatut tiedostot ja määritykset samaan palautusmanifestiin. Vikunjan puhdas palautus onnistuu vain, kun projektit, tehtävähistoria, liitteet, muistutukset ja käyttäjät palautuvat ja ajastettu ilmoitus lähetetään edelleen.
Vaatiiko Vikunja HTTPS:n käänteisen välityspalvelimen takana?
Käytä julkisena Vikunja-originina HTTPS:ää ja pidä portti 3456 sisäisessä reitissä. Määritä Vikunjan asetus oikein: aseta VIKUNJA_SERVICE_PUBLICURL täsmälleen oikeaan HTTPS-originiin. Vikunjassa HTTPS suojaa tunnuksia ja käyttäjäsisältöä siirron aikana sekä pitää originista riippuvan asiakaskäyttäytymisen yhdenmukaisena.
Miten Vikunjan päivitys pitäisi testata?
Palauta Vikunjan nykyinen tila eristettyyn käyttöönottoon, ota ehdokasversio käyttöön ja toista sen hyväksyntätapahtuma. Kiinnitä erityistä huomiota siihen, että tietokantamigraatiot ja frontend/APIn yhteensopivuus on testattava ennen Vikunjan version vaihtamista. Säilytä aiempi Vikunja-image, kunnes sen datamigraation ja palautuksen rajat on ymmärretty.