HedgeDocin itsehostaus vuonna 2026: WebSockets, OAuth ja ladatut tiedostot

“HedgeDocin ajamisesta” on kaksi versiota: käytössä on kontti tai palvelu suorittaa oikean tehtävänsä. Vain jälkimmäisellä on merkitystä. Tässä onnistumisen osoittaa se, että voit luoda muistiinpanon, muokata sitä samanaikaisesti kahdella selaimella, ladata kuvan ja autentikoitua valitun palveluntarjoajan kautta.

HedgeDoc on tarkoitettu reaaliaikaisiin yhteistyössä muokattaviin Markdown-muistiinpanoihin. Käyttöönoton on säilytettävä tämän toiminnan taustalla olevat osat; portti, volume ja varmenne ovat lähtökohtia, eivät lopputulos.

Varmuuskopioi tila, jota HedgeDoc ei pysty luomaan uudelleen

Määritä HedgeDocille palautuspiste ja palautumisaika tietokannan, ladattujen tiedostojen ja autentikointiasetusten perusteella. Liitä /hedgedoc/public/uploads ennen alustusta, kirjoita vaaratonta esimerkkidataa ja vaihda kontti varmistaaksesi, että kyseinen polku on todella pysyvä. Named volume ratkaisee redeployn jälkeisen säilyvyyden, mutta se ei suojaa tietomurrolta tai palvelimen menetykseltä.

Rakenna puhdas palautusympäristö, käytä samaa pinattua sovellusversiota ja varmista, että muistiinpanot, revisiot, käyttäjät ja ladatut tiedostot palautuvat ja että kaksi selainta pystyy tekemään yhteistyötä palautetun muistiinpanon parissa. Kirjaa komennot, omistajuuden korjaukset ja kulunut aika. Varmuuskopiointiopas tarjoaa hyödyllisen standardin: varmuuskopioon voi luottaa palautuksen jälkeen, ei sen jälkeen kun se on ladattu.

Pidä HedgeDoc erillään riippuvuuksistaan

Prosessin health ja tuotteen health ovat HedgeDocissa eri asioita. Portti 3000 voi vastata, vaikka käyttäjän suorittama toiminto epäonnistuisi edelleen. HedgeDocin verkkosopimus koostuu Postgresista sekä valinnaisista OAuth- ja SMTP-palveluntarjoajista. Pidä yksityiset endpointit sisäisessä DNS:ssä, salli vain tarvittavat lähtevät yhteydet ja anna HedgeDocille rajatuilla oikeuksilla varustettu service credential.

Käytä tätä readiness-harjoitusta merkittävien asetusten muutosten jälkeen: luo muistiinpano, muokkaa sitä samanaikaisesti kahdella selaimella, lataa kuva ja autentikoiudu valitun palveluntarjoajan kautta. Älä sisällytä kalliita ulkoisia tarkistuksia liveness probeihin, jotta palveluntarjoajan käyttökatkos ei aiheuta restart loopia. Kapasiteettia suunnitellessa seuraa WebSocket-yhteyksiä, tietokantakirjoituksia, ladattua mediaa ja dokumenttihistoriaa, sillä ne kuvaavat HedgeDocin todellista kuormaa paremmin kuin sivupyynnöt.

Viisi konttien health checkiä vahvempaa tarkistusta

Muunna HedgeDocin smoke test toistettavaksi release-komennoksi tai lyhyeksi runbookiksi. Sen tulosteen on osoitettava seuraava lopputulos: luo muistiinpano, muokkaa sitä samanaikaisesti kahdella selaimella, lataa kuva ja autentikoiudu valitun palveluntarjoajan kautta. Kirjaa tuloksen yhteyteen sovellusversio, kontin digest, reitin hostname ja testidatan tunniste.

Suorita sama tarkistus tavallisen kontin vaihdon jälkeen sekä tietokannan, ladattujen tiedostojen ja autentikointiasetusten palauttamisen jälkeen toisessa ympäristössä. Palautus on onnistunut, kun muistiinpanot, revisiot, käyttäjät ja ladatut tiedostot palautuvat ja kaksi selainta pystyy tekemään yhteistyötä palautetun muistiinpanon parissa. Vertaa WebSocket-yhteyksiin, tietokantakirjoituksiin, ladattuun mediaan ja dokumenttihistoriaan liittyvää ajoitusta ja kulutusta; suuri muutos kannattaa tutkia, vaikka viimeinen toiminto edelleen onnistuisi.

Testaa seuraavaksi turvallinen vikatilanne: estä testikäyttäjän pääsy Postgresiin sekä valinnaisiin OAuth- ja SMTP-palveluntarjoajiin. Varmista, että HedgeDoc näyttää vian käyttäjälle ja palautuu normaaliksi ilman tuhoisia manuaalisia muutoksia. Säilytä vain tarpeellinen, sensuroitu lokikatkelma. Tämä neliosainen portti kattaa käynnistymisen, pysyvyyden, palautumisen ja vikatilanteiden käsittelyn.

Käynnistä HedgeDoc piilottamatta liikkuvia osia

Minimikomento on hyödyllinen, kun se paljastaa, mitä alusta tulee myöhemmin hallitsemaan.

docker run -d \
  --name hedgedoc \
  --restart unless-stopped \
  -p 127.0.0.1:3000:3000 \
  -v hedgedoc-data:/hedgedoc/public/uploads \
  -e CMD_SESSION_SECRET=replace-with-a-long-random-value \
  -e CMD_DOMAIN=app.example.com \
  -e CMD_PROTOCOL_USESSL=true \
  -e CMD_DB_URL=postgres://hedgedoc:replace-password@postgres.internal:5432/hedgedoc \
  quay.io/hedgedoc/hedgedoc:latest

Tässä portti 3000 pysyy vain hostin sisäisessä käytössä ja kaikki tarvittavat polut on määritetty eksplisiittisesti. Lisää Postgresin sekä valinnaisten OAuth- ja SMTP-palveluntarjoajien tarkistetut yhteysasetukset; käytä yksityisille palveluille yksityisiä nimiä. Varmista käynnistyminen sekä lokeista että sovelluskohtaisella testillä: luo muistiinpano, muokkaa sitä samanaikaisesti kahdella selaimella, lataa kuva ja autentikoiudu valitun palveluntarjoajan kautta. Kun toiminta on varmistettu, lukitse image-versio, jotta tavallinen vaihto ei muuta toimintaa huomaamatta.

Älä anna HedgeDocille koko hostia

HedgeDocin kannalta arvokkain surface ei välttämättä ole landing page. Yleisin virhe on käyttää esimerkin session secretiä tai sallia anonyymi muistiinpanojen luonti vahingossa. Torju tämä tarkoituksellisesti: käytä pysyvää session secretiä, päätä, onko anonyymi muistiinpanojen luonti hyväksyttävää, ja rajoita pääsyä yksityisiin muistiinpanoihin.

Luo CMD_SESSION_SECRET pitkästä satunnaisarvosta; sen kierrättäminen mitätöi tavallisesti sessiot tai tokenit, joten suunnittele vaikutus käyttäjiin sen sijaan, että kutsuisit muutosta encryption migrationiksi. Käytä oikeuksiltaan rajoitettua kontin käyttäjää, jos image tukee sitä, äläkä liitä mukaan asiaankuulumattomia tunnistetietoja. Aseta ingressissä rate- tai size-limitit paikkoihin, joissa epäluotettu työ voi kuluttaa WebSocket-yhteyksiä, tietokantakirjoituksia, ladattua mediaa ja dokumenttihistoriaa.

Testaa HedgeDoc palvelimen ulkopuolelta

Valitse lopullinen HedgeDoc-hostname ennen kuin käyttäjät tallentavat callbackeja tai client-asetuksia, ja määritä CMD_DOMAIN sekä CMD_PROTOCOL_USESSL julkista URL-osoitetta varten. Platform route päättää TLS:n kerran ja ohjaa liikenteen yksityiseen porttiin 3000.

Suorita hyväksymistesti ulkoisesti. Jos client ei koskaan saavuta HedgeDocia, käytä SSL-validoinnin tarkistuslistaa DNS- ja varmennetarkistuksiin. Jos pyyntö saavuttaa HedgeDocin mutta reaaliaikaiset muokkaukset epäonnistuvat WebSocketsin tai virheellisten domain-asetusten vuoksi, lopeta proxy redirectien muuttaminen ja tarkista sen sijaan sovelluskohtainen rajapinta.

Käytä HedgeDocia sen todellisen pullonkaulan ympärillä

Käytä jokaisen käyttöönoton jälkeen HedgeDocin smoke testinä tätä kokonaisuutta: luo muistiinpano, muokkaa sitä samanaikaisesti kahdella selaimella, lataa kuva ja autentikoiudu valitun palveluntarjoajan kautta. Sitä tukevia mittareita ovat WebSocket-yhteydet, tietokantakirjoitukset, ladattu media ja dokumenttihistoria; hälytä, kun jokin näistä resursseista lähestyy pistettä, jossa käyttäjän toiminto heikkenee.

Suurin muutosriski liittyy siihen, että HedgeDocin tietokantamigraatiot, OAuth-asetukset ja plugin- tai renderer-muutokset vaativat vaiheistetun releasen. Turvallinen release alkaa palautettavasta snapshotista ja varmistaa yksisuuntaisen tilamuutoksen ennen liikenteen siirtämistä. Kun reaaliaikaiset muokkaukset epäonnistuvat WebSocketsin tai domain-asetusten vuoksi, säilytä viallinen kontti riittävän pitkään sen asetusten ja ensimmäisen virheen lukemista varten.

Miten Dockup vähentää HedgeDocin työtä

Dockup voi hallita vaihdettavia platform-osia: ohjata liikenteen porttiin 3000, luoda domainin ja varmenteen, välittää secretit, liittää pysyvän tallennustilan ja yhdistää HedgeDocin hallittuihin tai yksityisesti liitettyihin palveluihin. Tämä voidaan tehdä Dockupin infrastruktuurissa tai liittämässäsi palvelimessa.

HedgeDocin hyväksymistyö on edelleen tehtävä eksplisiittisesti. One-click deploymentin jälkeen määritä CMD_DOMAIN ja CMD_PROTOCOL_USESSL julkista URL-osoitetta varten, yhdistä HedgeDoc Postgresiin sekä valinnaisiin OAuth- ja SMTP-palveluntarjoajiin ja suorita seuraava skenaario: luo muistiinpano, muokkaa sitä samanaikaisesti kahdella selaimella, lataa kuva ja autentikoiudu valitun palveluntarjoajan kautta. Tämä jako on tarkoituksellinen: Dockup poistaa toistuvan infrastruktuurin käyttöönoton ilman, että se teeskentelee sovellusroolien, palveluntarjoajien tunnistetietojen tai palautuskäytännön valikoituvan itsestään.

Usein kysytyt kysymykset

Mitä HedgeDoc tarvitsee tuotantokäyttöönottoon?

Ohjaa HedgeDoc-kontti portin 3000 kautta yhden HTTPS-originiin. Verkon tukivaatimus on Postgres sekä valinnaiset OAuth- ja SMTP-palveluntarjoajat. Älä kutsu HedgeDocia valmiiksi, ennen kuin voit luoda muistiinpanon, muokata sitä samanaikaisesti kahdella selaimella, ladata kuvan ja autentikoiutua valitun palveluntarjoajan kautta.

Mitkä HedgeDocin tiedot kuuluvat varmuuskopioon?

Säilytä /hedgedoc/public/uploads ja sisällytä tietokanta, ladatut tiedostot sekä autentikointiasetukset samaan palautusmanifestiin. Puhdas HedgeDoc-palautus on onnistunut vasta, kun muistiinpanot, revisiot, käyttäjät ja ladatut tiedostot palautuvat ja kaksi selainta pystyy tekemään yhteistyötä palautetun muistiinpanon parissa.

Edellyttääkö HedgeDoc HTTPS:ää reverse proxyn takana?

Käytä julkisessa HedgeDoc-originissa HTTPS:ää ja pidä portti 3000 sisäisessä reitissä. Määritä HedgeDocin asetus oikein: aseta CMD_DOMAIN ja CMD_PROTOCOL_USESSL julkista URL-osoitetta varten. HedgeDocissa HTTPS suojaa tunnistetietoja ja käyttäjien sisältöä siirron aikana sekä pitää originista riippuvan client-käyttäytymisen yhdenmukaisena.

Miten HedgeDoc-päivitys pitäisi testata?

Palauta HedgeDocin nykyinen tila eristettyyn käyttöönottoon, ota ehdokasversio käyttöön ja toista sen hyväksymistesti. Kiinnitä erityistä huomiota siihen, että HedgeDocin tietokantamigraatiot, OAuth-asetukset ja plugin- tai renderer-muutokset vaativat vaiheistetun releasen. Säilytä edellinen HedgeDoc-image, kunnes sen datamigraation ja rollbackin rajat on ymmärretty.