Wiki.js:n itsehostaus vuonna 2026: tietokannan määritys, TLS ja palautustestit

Useimmat Wiki.js:n asennusohjeet päättyvät ensimmäisen sivulatauksen jälkeen. Se on liian aikaista: DB_HOST on kontin sisällä localhost tai TLS-proxyn headerit puuttuvat. Hyödyllinen tuotantotesti on vaativampi — viimeistele määritys, luo ja muokkaa sivua, lataa mediaa, etsi se ja tarkista version historia uudelleenkäynnistyksen jälkeen.

Wiki.js:n rooli on selkeä: Markdown-pohjainen wiki versionhallinnalla ja modernilla editorilla. Sen operationalinen kokonaisuus ulottuu web-prosessia laajemmalle, joten riippuvuus, tallennettu tila ja julkinen reitti on nimettävä eksplisiittisesti ennen oikean datan saapumista.

Rajaa Wiki.js:n runtime-ympäristö

Pienin vastuullinen Wiki.js-topologia sisältää yhden yksityisen listenerin portissa 3000, ingress-reitin ja dokumentoidun tilarajan. Wiki.js:n verkkosopimus edellyttää saavutettavissa olevaa Postgres-, MySQL-, MariaDB-, MSSQL- tai SQLite-tietokantaa. Pidä yksityiset endpointit sisäisessä DNS:ssä, salli vain tarvittavat lähtevät yhteydet ja anna Wiki.js:lle rajatuin oikeuksin varustettu service credential.

Vahvista topologia pyytämällä puhdasta clientia viimeistelemään määritys, luomaan ja muokkaamaan sivu, lataamaan mediaa, etsimään se ja tarkistamaan version historia uudelleenkäynnistyksen jälkeen. Seuraa ajon aikana tietokannan vasteaikaa, haun indeksointia, median tallennusta ja authentication-providerin latenssia. Tulos kertoo, kuuluuko seuraava parannus muistiin, tallennukseen, verkkoon vai erilliseen workeriin, sen sijaan että konttia mitoitettaisiin sattumanvaraisesti.

Suunnittele Wiki.js:n palautus ennen julkaisua

Wiki.js:n vakioimagen sisällä ei odoteta olevan kirjoitettavaa sovellustilaa. Säilytä tietokanta sekä mahdolliset paikalliset uploadit ja custom assetit, mukaan lukien pinnattu digest ja tarkistettu reittimääritys, sen sijaan että varmuuskopioisit tyhjän kontin tiedostojärjestelmän.

Luo Wiki.js tyhjästä toisella hostilla ja varmista, että sivut, historia, käyttäjät, ryhmät, media ja navigaatio palautuvat ja että tunnettu sivu löytyy edelleen haulla. Jos mukaan lisätään erillinen tietokanta, room server tai authentication-kerros, anna kyseiselle komponentille oma, eksplisiittinen palautusvastuu. Git-to-production-opas näyttää, miten toistettava artifact korvaa kontin varmuuskopion.

Kirjaa rebuild-komento ja odotettuun tulokseen perustuva testi julkaisun yhteyteen. Tilattoman palautussuunnitelman onnistuminen perustuu toiminnan toistamiseen luotetuista lähtötiedoista; sen ei pidä riippua läpinäkymättömän käynnissä olevan kontin kopioimisesta.

Valitse Wiki.js:n trust boundary

Turvallinen Wiki.js-deployment alkaa oikeuksien vähentämisestä. Älä jätä setup-näkymää näkyviin ensimmäisen administratorin luonnin jälkeen, vaan poista setupin julkinen käyttö, rajoita administrationia ja anna wikien tietokannalle omat tunnuksensa.

Käsittele DB_PASS-arvoa sen Wiki.js-roolin mukaisesti: pidä arkaluonteiset arvot Gitin ulkopuolella, dokumentoi rotaation vaikutukset äläkä koskaan korvaa tuotantoarvoa julkisella esimerkillä. Rajoita administration-reittejä, käytä riippuvuuksille yksityistä DNS:ää ja tarkista jokainen bind mount. Kun logit toimitetaan keskitetysti, suodata salaisuudet ja yksityinen sisältö ennen niiden poistumista palvelimelta.

Mitkä tarkistukset on läpäistävä ennen todellisen Wiki.js-datan saapumista

Wiki.js:n tuotantokriteerin pitäisi olla sellainen, että sen voi suorittaa henkilö, joka ei rakentanut deploymentia. Anna hänelle pinnattu versio, ei-arkaluonteinen testitili ja tämä tehtävä: viimeistele määritys, luo ja muokkaa sivua, lataa mediaa, etsi se ja tarkista version historia uudelleenkäynnistyksen jälkeen. Jos ohjeet edellyttävät dokumentoimatonta shell-käyttöä, palvelu ei ole vielä operationalisesti valmis.

Toista testi, kun vaihdat ainoastaan kontin. Palauta sitten tietokanta sekä mahdolliset paikalliset uploadit ja custom assetit tyhjään infrastruktuuriin ja osoita, että sivut, historia, käyttäjät, ryhmät, media ja navigaatio palautuvat ja että tunnettu sivu löytyy edelleen haulla. Mittaa onnistuneiden ajojen aikana tietokannan vasteaikaa, haun indeksointia, median tallennusta ja authentication-providerin latenssia; odottamattomat erot paljastavat usein puuttuvan cachen, indeksin, workerin tai datamäppelin.

Lisää mukaan failure drill: estä testitunnukselta väliaikaisesti pääsy saavutettavissa olevaan Postgres-, MySQL-, MariaDB-, MSSQL- tai SQLite-tietokantaan. Wiki.js:n pitäisi tuottaa hyödyllinen virheilmoitus, säilyttää olemassa oleva tila ja palautua, kun kelvollinen tila palaa. Tallenna aikaleimat ja olennaiset logirivit sekä poista niistä salaisuudet. Tästä evidenssistä tulee vertailukohta seuraavalle imagelle tai määritys muutokselle.

Käynnistä Wiki.js piilottamatta liikkuvia osia

Pidä ensimmäinen Wiki.js-käynnistys riittävän toistettavana, jotta sen voi tarkistaa pull requestissa.

docker run -d \
  --name wiki-js \
  --restart unless-stopped \
  -p 127.0.0.1:3000:3000 \
  -e DB_PASS=replace-with-a-long-random-value \
  -e DB_TYPE=postgres \
  -e DB_HOST=postgres.internal \
  -e DB_PORT=5432 \
  -e DB_USER=wiki \
  -e DB_NAME=wiki \
  ghcr.io/requarks/wiki:2

Älä luota latest-tagiin oikean datan käyttöönoton jälkeen. Tallenna toimiva digest, kontin käyttäjä ja mounttien omistajuus. Seuraa sovelluslogia kokonaisen testin ajan — viimeistele määritys, luo ja muokkaa sivua, lataa mediaa, etsi se ja tarkista version historia uudelleenkäynnistyksen jälkeen — ja kirjaa mahdolliset migraatiot ennen reitin ohjaamista tuotantoliikenteeseen.

Pidä sisäiset ja ulkoiset URL-osoitteet erillään

Käsittele ulkoista Wiki.js-URL-osoitetta määrityksenä, joka säilyy redeployn yli. Määritä ensin site URL, kun olet ohjannut palvelun HTTPS:n kautta, ja ohjaa sitten hostname porttiin 3000 alkuperäisen hostin ja schemen säilyessä ennallaan.

Deploymentin saavutettavuuden tarkistuslista voi osoittaa, että pyynnöt päätyvät konttiin. Sen jälkeen tunnettuun vikaan — DB_HOST on kontin sisällä localhost tai TLS-proxyn headerit puuttuvat — pitää etsiä syytä Wiki.js:stä, sen tilasta tai workloadista, ei sertifikaattiautomatiosta.

Seuraa workloadia, älä vain konttia

Rakenna dashboardit tietokannan vasteajan, haun indeksoinnin, median tallennuksen ja authentication-providerin latenssin ympärille. Ilman tätä workload-kontekstia CPU-graafi ei voi selittää, miksi Wiki.js on hidas. Lisää synteettinen tai ajastettu tarkistus, joka yrittää viimeistellä määrityksen, luoda ja muokata sivua, ladata mediaa, etsiä sen ja tarkistaa version historian uudelleenkäynnistyksen jälkeen käyttäen harmitonta testidataa.

Ota ennen päivitystä huomioon tämä sovelluskohtainen riski: Wiki.js:n tietokantamigraatiot ja authentication-moduulit pitäisi vaiheistaa ennen siirtymistä toiseen release-linjaan. Palauta tuore varmuuskopio eristettyyn deploymentiin, aja migraatiot siellä ja vertaa toimintaa. Jos DB_HOST on kontin sisällä localhost tai TLS-proxyn headerit puuttuvat, tarkista kyseinen raja — julkinen origin, tallennus tai riippuvuus — ennen kuin muutat asiaan liittymättömiä asetuksia.

Pidä Wiki.js eksplisiittisenä, kun Dockup hoitaa reitityksen

Reititys, sertifikaatit, palvelun korvaaminen ja liitetty tallennustila ovat järkeviä automaation kohteita. Dockup hoitaa ne Wiki.js:lle ja voi provisioida siihen liittyvän managed-tietokannan tai yhdistää asiakkaan omalla palvelimella toimiviin palveluihin.

Sen ei pidä keksiä Wiki.js:n trust policya. Määritä käyttöönoton jälkeen site URL, kun olet ohjannut palvelun HTTPS:n kautta, valvo tätä rajaa — poista setupin julkinen käyttö, rajoita administrationia ja anna wikien tietokannalle omat tunnuksensa — ja varmista tämän skenaarion tulos: viimeistele määritys, luo ja muokkaa sivua, lataa mediaa, etsi se ja tarkista version historia uudelleenkäynnistyksen jälkeen. Lopputuloksena on yhden klikkauksen infrastruktuuri, johon kuuluu sovelluskohtainen hyväksymistesti.

Usein kysytyt kysymykset

Mitä Wiki.js tarvitsee tuotantodeploymentiin?

Ohjaa Wiki.js-kontti portista 3000 yhden HTTPS-originin kautta. Taustalla tarvitaan saavutettavissa oleva Postgres-, MySQL-, MariaDB-, MSSQL- tai SQLite-tietokanta. Älä pidä Wiki.js:ää valmiina, ennen kuin pystyt viimeistelemään määrityksen, luomaan ja muokkaamaan sivua, lataamaan mediaa, etsimään sen ja tarkistamaan version historian uudelleenkäynnistyksen jälkeen.

Mitkä Wiki.js:n tiedot kuuluvat varmuuskopioon?

Wiki.js:n vakioimagessa ei ole pakollista sovellusdatan mountia. Säilytä sen deployment-määritykset ja varmuuskopioi yhdistetty tila erikseen; palautus on onnistunut, kun sivut, historia, käyttäjät, ryhmät, media ja navigaatio palautuvat ja tunnettu sivu löytyy edelleen haulla.

Vaatiiko Wiki.js HTTPS:n reverse proxyn takana?

Käytä julkisessa Wiki.js-originissa HTTPS:ää ja pidä portti 3000 sisäisessä reitissä. Ota Wiki.js:n asetus käyttöön oikein: määritä site URL, kun olet ohjannut palvelun HTTPS:n kautta. Wiki.js:n tapauksessa HTTPS suojaa tunnuksia tai käyttäjäsisältöä siirron aikana ja pitää originista riippuvan client-käyttäytymisen yhdenmukaisena.

Miten Wiki.js-päivitys pitäisi testata?

Palauta nykyinen Wiki.js:n tila eristettyyn deploymentiin, ota ehdokasversio käyttöön ja toista sen hyväksymistapahtuma. Kiinnitä erityistä huomiota siihen, että Wiki.js:n tietokantamigraatiot ja authentication-moduulit pitäisi vaiheistaa ennen siirtymistä toiseen release-linjaan. Säilytä edellinen Wiki.js-image, kunnes sen datamigraation ja rollbackin rajat on ymmärretty.